Clase 26 de 53 • Curso de DevOps con GitLab
Contenido del curso
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 “preinstalar” 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 “Hello, world” - npm install - echo “etc.” …
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.
Edwin Garcia
Danny Andres Barrientos Agudelo
Edwin Garcia
Jose Manuel Salazar García
Emiliano Heredia
Marcelo Javier Pedernera
Jesús Rubén Esparza Soto
Dany Pascual Gomez Sanchez
Elias Ojeda Medina
Nelson Aranda
Juan Esteban Galvis
Roger Daza Caba
Fabian Andres Villon Garcia
Gonzalo Amador Hernández
Alexis Otaño
Gonzalo Amador Hernández
Juan Stiven Muñoz Garcia
Julio Pérez Hernández
Julio Pérez Hernández
Francisco J. López
Gonzalo Amador Hernández
Gustavo Alvarez Leyton
Gustavo Fabian Sandoval
![Francisco Garcia [C6]](https://static.platzi.com/media/avatars/avatars/garciafran_c845c2fe-2ea4-42db-a305-a7f4ef13b0fd.jpeg){kind=small}
Francisco Garcia [C6]
Mauricio Rodriguez
Wilmer Ariel Moina Rivera
Nicolas Molina
David Toca
Nicolas Molina
Kenet Andrés Chungandro Montenegro
Seria bueno que nos mostraran como configurar gitlab en un servidor propio...con todo lo hemos visto en clase
Esto me gustaria saberlo. te pregunto te dieron algun tipo de respuesta @Edwin Garcia o como llego a configurarlo ?
No todavia ninguna @Danny Andres Barrientos Agudelo
Seria conveniente, mover este documento antes del video anterior.
Seria muy conveniente que este antes que el video 25.
Tengo muchas dudas pero avanzo con fe.
Con dudas pero sin miedo 💪
Ruta del validador de sintaxis: [PROYECTO] => [CI / CD] => PipeLines => CI Lint
Basicamente hay que estar familiarizados con Docker y agregar estas funcionalidades que proporciona gitlab para completar el ciclo
Excelente Explicacion
Gracias por este resumen y explicación!
Entendí varias cosas que no tenía claro.
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
Si lo haces en gitlab ya existen runners compartidos para esto. Si lo haces en un gitlab con docker, tu debes montar los runner y definirles tags (de los runners) para poderlos vincular a los proyectos.
si usas el servicio de GitLab estos ya estan configurados, pero puedes confurar el tuyo si es que necesitas mas poder de procesamiento y mas velocidad, o si gustas ahorrar mas plata
Autoscale GitLab CI/CD runners and save 90% on EC2 costs: https://about.gitlab.com/blog/2017/11/23/autoscale-ci-runners/
Este texto debería de estar antes de la clase anterior..
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
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
No puedes tener tiempo ilimitado gratis en Gitlab directamente. Literalmente, la empresa vende esos servicios. Hay cosas de pricing por minutos de CI/CD, con lo cual puedes comprar planes que tienen tiempo de CI/CD.
Otra cosa es que uses tu propio Gitlab en un servidor tuyo, que se puede. Pero de eso ya no sé tanto
Un compañero en otra respuesta puso este artículo https://about.gitlab.com/blog/2017/11/23/autoscale-ci-runners/
Que es básicamente una configuración para que corras tus runners y Jobs en una instancia propia de AWS. Promete, pero no la he probado...
Entonces el GitLab Runner trabaja internamente con Docker ? y aparte este runner se puede modificar, es correcto ¿?
Asi es el runner trabaja internamente con docker, y si puedes modificarlo, es mas puedes setear tu propio runner y asi ahorrar unos dolares
checa este articulo Autoscale GitLab CI/CD runners and save 90% on EC2 costs:
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:
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
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?
donde dice registration docker debes reemplazar las xxxx por el que te da en https://docs.gitlab.com/runner/register/index.html
Hola! David si eso lo hice solo que puse xxxxx para no compartir el token en publico.
Excelente, fuera bueno un post montando un CI para un entorno con php
