Introducci贸n

1

Lo que aprender谩s sobre DevOps con GitLab

2

驴Qu茅 es Devops?

3

El ciclo de vida del Devops

4

Introducci贸n a Gitlab

5

Gitlab vs Github

Administraci贸n

6

Autenticaci贸n

7

Grupos

8

Autorizaci贸n

9

Auditor铆a

10

Proyectos

Planificaci贸n

11

Tipos de desarrollo

12

Planificaci贸n en Gitlab-Issues

13

Planificaci贸n en Gitlab-Etiquetas

14

Planificaci贸n en Gitlab-Pesos

15

Planificaci贸n en Gitlab-Milestones

16

Planificaci贸n en Gitlab-Boards

17

Planificaci贸n en Gitlab-Service Desk

18

Planificaci贸n en Gitlab-Quick actions

Verificaci贸n

19

Inicializaci贸n del repositorio

20

Merge requests

21

Profundizando en Merge requests

22

Continuous Integration-CI

23

Gitlab CI

24

Automatizacion con GitLab Cl

25

Validacion de la configuracion con GitLab Cl

26

gitlab-ci.yml

27

Gitlab pages

28

Implementando Gitlab pages

29

驴Qu茅 es el Desarrollo 脕gil?

30

Gitlab autodevops

31

Implementando GitLab autodevops

32

Habilitando autodevops

Empaquetaci贸n

33

Gitlab container registry

34

Introducci贸n a contenedores

Seguridad

35

Introducci贸n a DevSecOps

36

Firmas de seguridad

37

Pruebas est谩ticas de seguridad

38

Escaneo de contenedores

39

Escaneo de dependencias

40

Pruebas din谩micas de seguridad

41

Gitlab security dashboard

Distribuci贸n

42

Continuous Delivery (CD)

43

Ambientes

44

Review apps

45

Estrategias de Distribuci贸n

46

Feature Flags

47

Rollback

Monitoreo

48

驴Por qu茅 monitorear?

49

M茅tricas de desempe帽o (performance metrics)

50

M茅tricas de salud (health metrics)

51

Metricas de equipo

52

Rastreo de errores

Conclusiones

53

驴Por qu茅 desarrollar con Gitlab?

gitlab-ci.yml

26/53

Lectura

El archivo .gitlab-ci.yml sirve para configurar el comportamiento de Gitlab CI en cada proyecto. En el archivo define la estructura y el orden de los pipelines y determina qu茅 ejecutar con el Gitlab runner y qu茅 decisiones tomar cuando condiciones espec铆ficas se cumplen (como cuando un proceso falla o termina exitosamente).

El archivo tiene muchas opciones de configuraci贸n, pero aqu铆 nos vamos a enfocar en tres: image, stages y jobs.

La primera opci贸n de configuraci贸n es image. image nos sirve para determinar qu茅 imagen de Docker vamos a utilizar para ejecutar el runner. Hay que recordar que, en su nivel m谩s b谩sico, los trabajos de CI son simplemente automatizaci贸n de scripts. Con esto en mente, tenemos que determinar qu茅 ambiente necesita nuestro script para correr de manera exitosa. 驴Necesitas instalar dependencias desde NPM y ejecutar scripts de package.json? Entonces es muy probable que la imagen de Node te sirva como base. Quiz谩 necesitas correr pruebas unitarias de una aplicaci贸n de Python e instalar dependencias desde PyPi; entonces deber铆as instalar la imagen de Python.

Al final del d铆a, el keyword image nos permite 鈥減reinstalar鈥 los paquetes que nuestro script necesitar谩 para correr: desde sistema operativo y lenguajes de programaci贸n, hasta software espec铆fico como bases de datos.

Un 煤ltimo punto, image puede utilizarse de manera global o por cada job que ejecutemos. Es decir, si nuestro proyecto lo requiere podemos utilizar una imagen de Node para un job y otra de Ruby para otro.

# gitlab-ci.yml
image: node:11.1.0

# 贸

job1:
  image: python:3.7

Por su parte, los stages nos permiten definir las etapas que atravesar谩 nuestro pipeline cuando corra. Cada stage (etapa) puede contener uno o m谩s jobs que correr谩n en paralelo. Los stages permiten agrupar los jobs que pertenezcan a una categor铆a y permiten crear diversas dependencias entre cada job. Un ejemplo de un pipeline multietapa ser铆a el siguiente:

Install -> Test -> Build -> Deploy

Dicho pipeline lo podr铆amos configurar en .gitlab-ci.yml de la siguiente manera:

# gitlab-ci.yml

stages:
  - install
  - test
  - build
  - deploy

job1:
  stage: install
鈥

Es importante recordar que para configurar nuestros pipelines de manera correcta, tenemos que declarar el nombre de nuestras etapas como una lista bajo el keyword stages y luego indicar en cada job a qu茅 etapa pertenece con el keyword stage.

Por 煤ltimo, los jobs son los encargados de ejecutar los scripts de automatizaci贸n en cada etapa. En este sentido, un job puede tener casi cualquier nombre (aunque siempre debes intentar nombrar de acuerdo a la funci贸n de lo que est谩s nombrando) y debe contener un script que se ejecutar谩. Los jobs se ejecutan por los runners cuando se encuentran disponibles. Gran parte de la configuraci贸n adicional de los jobs est谩 relacionada con las condiciones sobre las cuales se debe ejecutar y que artefactos exporta para otros jobs en el pipeline.

# gitlab-ci.yml

job1:
  script:
    - echo 鈥淗ello, world鈥
    - npm install
    - echo 鈥渆tc.鈥

鈥

Recuerda que el archivo .gitlab-ci.yml es fundamental para configurar nuestro CI, pero nuestro IDE no posee las reglas para determinar si su estructura es v谩lida. De hecho, si tienes el tiempo, crear un plugin de VS Code o de VIM para estos efectos ser铆a una gran idea. Por esto, es importante validar nuestra configuraci贸n con la herramienta de linting de Gitlab. La puedes encontrar en cada uno de tus proyectos si configuras la siguiente URL con tus datos.

https://gitlab.com/group/proyect/-/ci/lint

Aportes 29

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

En esta p谩gina hay una serie de templates del archivo .gitlab-ci.yml, para distintos lenguajes y frameworks

Seria conveniente, mover este documento antes del video anterior.

Seria bueno que nos mostraran como configurar gitlab en un servidor propio鈥on todo lo hemos visto en clase

Seria muy conveniente que este antes que el video 25.

Tengo muchas dudas pero avanzo con fe.

Excelente Explicacion

Gracias por este resumen y explicaci贸n!

Entend铆 varias cosas que no ten铆a claro.

Basicamente hay que estar familiarizados con Docker y agregar estas funcionalidades que proporciona gitlab para completar el ciclo

Pregunta no me quedo claro si los test pueden correr sin haber configurado un Gitlab Runner, y en todo caso cuando seria necesario instalar un Gitlab Runner , gracias

Este texto deber铆a de estar antes de la clase anterior鈥

Hola a todos.
Quisiera saber si yo puedo tener tiempo ilimitado en los CI con alguna configuraci贸n de mis propios pipelines, runners, jobs, etc en mi servidor

Entonces el GitLab Runner trabaja internamente con Docker ? y aparte este runner se puede modificar, es correcto 驴?

Las tres configuraciones m谩s importantes son image, stages y jobs.

image: es como una configuraci贸n inicial de lo que necesitamos instalar para correr nuestros jobs.

imagen, se puede usar a nivel global o por cada job.

Stages: es una forma de agrupar jobs que pueden correr en paralelo.

job: es una automatizaci贸n de un script en su nivel m谩s bajo.
Un job puede exportar artefactos para otros jobs.

Tengo el siguiente .yaml con gitlab-runner que por alguna razon hay veces que falla en el comando cd
`stages:

  • init
  • deploy_testing

deploy:
stage: deploy_testing
script:
- cd /var/www/test.prueba.com.ar/private
- /opt/php-7.2/bin/php artisan down
- git pull origin develop
- npm run production
- /opt/php-7.2/bin/php composer.phar install
- /opt/php-7.2/bin/php composer.phar dump-autoload
- /opt/php-7.2/bin/php artisan config:cache
- /opt/php-7.2/bin/php artisan route:clear
- /opt/php-7.2/bin/php artisan cache:clear
- /opt/php-7.2/bin/php artisan view:cache
- /opt/php-7.2/bin/php artisan syncDBs
- /opt/php-7.2/bin/php artisan migrate
- /opt/php-7.2/bin/php artisan update-version
- cp -avr public/* 鈥/web/
- rm -R public
- /opt/php-7.2/bin/php artisan up
only:
- develop`

He aqui la issue en gitlab https://gitlab.com/gitlab-org/gitlab-runner/issues/1379

el tema es bastante extenso,la verdad para esto creo que se requiere mas practica, ya que las posibilidades son muy amplias

Ruta del validador de sintaxis: [PROYECTO] => [CI / CD] => PipeLines => CI Lint

me parece que se deber铆a hacer una prueba en otro entorno que no sea node.js para que quedara mas claro este tema, yo ya tengo un servidor propio de gitlab y sufrimos un poco montando esto para LAMP.

Buen aporte.

Hola, estoy tratando de correr gitlab runner desde una maquina en docker para el proceso de deploy ya que ahi en esa maquina tengo docker swarm.

Pero rengo un problema al querer registrar el runner con esa maquina, corro este comando:

gitlab-runner \
    register -n \
    --name "Docker Runner" \
    --executor docker \
    --docker-image docker:latest \
    --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
    --url https://gitlab.com/ \
    --registration-token xxxxxx \
    --tag-list tag

ERROR: Registering runner... forbidden (check registration token)  runner=xxxxx
PANIC: Failed to register this runner. Perhaps you are having network problems

Como lo puedo resolver?

Excelente, fuera bueno un post montando un CI para un entorno con php

Hay alguna forma de exportar un archivo circleci.yml a gitlab-ci.yml (se que es mucho pedir pero prefiero pregunta XD)

Muy buen resumen!!!

Gracias por el res煤men, a煤n tengo muchas dudas pero seguro las ire aclarando en el resto del curso.

Bueno resumen 馃槂

No se entiende, no queda claro

Presente unos problemas en el momento en el que se ejecutaba los Test en el Pipeline de Gitlab.

Encontre este muy buen video: Clic

Comparto los c贸digos de los archivos modificados

.gitlab-ci.yml

`image: node:11.1.0
stages:

  • install
  • test

install-dependencies:
stage: install
script:
- npm install
artifacts:
expire_in: 1hr
paths:
- node_modules/
cache:
paths:
- node_modules/

test-apps:
stage: test
variables:
CHROME_BIN: google-chrome
dependencies:
- install-dependencies
before_script:
- apt-get update && apt-get install -y apt-transport-https
- wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
- sh -c 鈥榚cho 鈥渄eb https://dl.google.com/linux/chrome/deb/ stable main鈥 >> /etc/apt/sources.list.d/google.list鈥
- apt-get update && apt-get install -y google-chrome-stable
script:
- npm run test:ci`

Karma.congi
module.exports = function (config) { config.set({ basePath: '', frameworks: ['jasmine', '@angular-devkit/build-angular'], plugins: [ require('karma-jasmine'), require('karma-chrome-launcher'), require('karma-jasmine-html-reporter'), require('karma-coverage-istanbul-reporter'), require('@angular-devkit/build-angular/plugins/karma') ], client: { clearContext: false // leave Jasmine Spec Runner output visible in browser }, coverageIstanbulReporter: { dir: require('path').join(__dirname, '../coverage/login'), reports: ['html', 'lcovonly', 'text-summary'], fixWebpackSourcePaths: true }, reporters: ['progress', 'kjhtml'], port: 9876, colors: true, logLevel: config.LOG_INFO, autoWatch: true, ** browsers: ['Chrome'], customLaunchers: { ChromeHeadlessCI: { base: 'ChromeHeadless', flags: ['--no-sandbox'] } },** singleRun: false, restartOnFileChange: true }); };

{ "name": "login", "version": "0.0.0", "scripts": { "ng": "ng", "start": "ng serve", "build": "ng build", "test": "ng test", **"test:ci": "ng test --no-watch --code-coverage --browsers=ChromeHeadlessCI",** "lint": "ng lint", "e2e": "ng e2e" }, "private": true, "dependencies": { "@angular/animations": "~7.2.0", "@angular/common": "~7.2.0", "@angular/compiler": "~7.2.0", "@angular/core": "~7.2.0", "@angular/forms": "~7.2.0", "@angular/platform-browser": "~7.2.0", "@angular/platform-browser-dynamic": "~7.2.0", "@angular/router": "~7.2.0", "core-js": "^2.5.4", "rxjs": "~6.3.3", "tslib": "^1.9.0", "zone.js": "~0.8.26" }, "devDependencies": { "@angular-devkit/build-angular": "~0.13.0", "@angular/cli": "~7.3.6", "@angular/compiler-cli": "~7.2.0", "@angular/language-service": "~7.2.0", "@types/node": "~8.9.4", "@types/jasmine": "~2.8.8", "@types/jasminewd2": "~2.0.3", "codelyzer": "~4.5.0", "jasmine-core": "~2.99.1", "jasmine-spec-reporter": "~4.2.1", "karma": "~4.0.0", "karma-chrome-launcher": "~2.2.0", "karma-coverage-istanbul-reporter": "~2.0.1", "karma-jasmine": "~1.1.2", "karma-jasmine-html-reporter": "^0.2.2", "protractor": "~5.4.0", "ts-node": "~7.0.0", "tslint": "~5.11.0", "typescript": "~3.2.2" } }

Que resumen, con este texto toda la clase anterior me quedo re clara

  • Un proyecto puede tener uno o mas pipelines

  • los pipelines se ejectuta por el runner

  • un pipeline tiene uno o mas stages, se ejecutan el el orden definido

  • un stage tiene uno o mas jobs (o scripts), se ejecutan en paralelo

  • el pipeline se ejecuta por el runner haciendo uso de una imagen de docker

  • puedes definir una imagen de docker distinta para cada job

pueden usar esta Extencion de vscode para GitLab , se llama GitLab Workflow:
https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow

y pueden hacer uso de su validador, ejecutando el comando GitLab: Validate GitLab CI config en el command palette