63 lines
2.6 KiB
Markdown
63 lines
2.6 KiB
Markdown
# CI
|
|
|
|
## GitlabRunner
|
|
|
|
[Instalar el runner](https://docs.gitlab.com/runner/install/docker.html)
|
|
|
|
`docker volume create gitlab-runner-config`
|
|
|
|
```bash
|
|
docker run -d --name gitlab-runner --restart always \
|
|
-v /var/run/docker.sock:/var/run/docker.sock \
|
|
-v gitlab-runner-config:/etc/gitlab-runner \
|
|
gitlab/gitlab-runner:latest
|
|
```
|
|
|
|
- [Registrar el runner](https://docs.gitlab.com/runner/register/index.html#docker)
|
|
- [Variables predefinidas](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
|
|
|
|
`docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register`
|
|
|
|
Pide una URL y un Token que se consiguen en `<REPO> > Settings > CI/CD > Runners`, usar `docker` como executor. y `docker:latest` como imagen
|
|
|
|
Hay que modificar el archivo `config.toml` del runner. Se puede acceder al mismo desde el host (la configuracion se monto como volumen) o desde el container. Hay que agregar `privileged=true` y en volumes: `["/cache", "/var/run/docker.sock:/var/run/docker.sock"]`.
|
|
|
|
## Pipeline
|
|
|
|
Para crear un pipeline dentro de gitlab vamos a definir un archivo llamado `.gitlab-ci.yml` en la raiz del proyecto. En este caso, vamos a usar un pipeline que ejecute en docker, por eso la imagen del mismo sera `image: docker:latest`.
|
|
|
|
La estructura basica del archivo consiste en:
|
|
|
|
```yaml
|
|
image: docker:latest
|
|
|
|
variables:
|
|
IMAGE_BASE: "$CI_REGISTRY/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME"
|
|
...
|
|
|
|
stages:
|
|
- prep
|
|
- build
|
|
- test
|
|
- deliver
|
|
- deploy
|
|
|
|
job1:
|
|
...
|
|
job2:
|
|
...
|
|
```
|
|
[GitLab CI reference](https://docs.gitlab.com/ee/ci/yaml/)
|
|
|
|
En este caso estamos declarando la imagen mencionada, declaramos variables a ser utilizadas en el pipeline, definimos el orden y nombre de los stages y declaramos los jobs en cuestión.
|
|
|
|
En nuestro caso utilizamos un stage llamado `prep` para realizar tareas de preparacion previas a la ejecucion del pipeline. En particular, se utiliza este stage para definir los nombres de todas las imagenes a ser creadas a lo largo del pipeline. Estos valores sera almacendas en un artifact llamado `context.env`. Luego, a medida que sea necesario, cada job solicitara el artifact y obtendra los valores requeridos.
|
|
|
|
El uso de tags es importante para separar la ejecucion en los distinto ambientes. En este caso, eel ambiente de build + test y el ambiente productivo final.
|
|
|
|
## Imagenes Docker
|
|
|
|
La idea de las imagenes es generar imagenes de testing que sean lo mas parecido a la imagen final. En el caso de python, la imagen de testing es una extension de la imagen productiva, se agregan las dependencias de testing y se hacen los ajustes pertinentes.
|
|
|
|
|