.gitlab-ci.yml

stage

stages:
- build-docker
- deploy

Le stage permet de grouper les jobs des pipeline en séquences chronologiques. Le Build des images précède le déploiement de ces images.

Job build des images

docker-build:
  stage: build-docker
  rules:
  - if: $CI_COMMIT_TAG =~ /^P_[0-9][0-9\.]*$/
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint:
    - ""
  script:
  - version=$(echo "${CI_COMMIT_TAG}"|sed 's/P_//')
  - mkdir -p /kaniko/.docker
  - |
    cat <<EOF > /kaniko/.docker/config.json
    {
      "auths": {
        "$CI_REGISTRY": {
          "username": "$CI_REGISTRY_USER",
          "password": "$CI_REGISTRY_PASSWORD"
        }
      }
    }
    EOF
  - ""
  - /kaniko/executor --context "${CI_PROJECT_DIR}/html" --dockerfile "${CI_PROJECT_DIR}/docker/nginx/Dockerfile"
    --registry-mirror registry-proxy.infra.cloud.e2.rie.gouv.fr --destination "CI_REGISTRY/$CI_PROJECT_PATH/nginx:${version}"
  - ""
  - /kaniko/executor --context "${CI_PROJECT_DIR}/html" --dockerfile "${CI_PROJECT_DIR}/docker/php/Dockerfile"
    --registry-mirror registry-proxy.infra.cloud.e2.rie.gouv.fr --destination "CI_REGISTRY/$CI_PROJECT_PATH/php:${version}"

Explications

stage: le job est fait en phase amont, durant le stage build-docker.
rules: le job n'est exécuté que si le pipeline est déclenché par la création d'une etiquette (COMMIT_TAG) commençant par P_, suivi de chiffre et de point ( P_1.0, P_25.09.01, P_3.8.9.12, ...)
image: gitlab-forge du ministère interdit l'usage de doker (contournement de la faille du doker in docker), les runner sont des dockers. On utilise donc kaniko/executor, avec le tag debug pour avoir le maximum de trace.
script: il faut extraire la version du COMMIT_TAG en supprimant le P_, paramétrer kaniko avec les comptes provisoires permettant de déposer une image dans la registrie Gitlab-forge, creer les images, les tagger avec la version et les pousser dans la registrie.

Conseils

L'option --context permet de se positionner dans le contexte et pouvoir copier des sources.
L'option --cleanup permet d'enchainer plusieurs build sans saturer l'espace du conteneur du runner.
L'option --registry-mirror permet d'utiliser le cache des registries (docker.hub) d'images et optimiser le temps de construction.
Kaniko accepte la syntaxe de docker, mais interprête différemment les instructions, comme ADD avec un .zip ou un .git!
Pour les langages qui nécessitent de la compilation, de la génération de code, de la récupération de librairies, il faut faire du multi-staging et ne pas utiliser des images de développement.

Job déploiement en Preprod

docker-deploy-preprod:
  stage: deploy
  rules:
  - if: $CI_COMMIT_TAG =~ /^P_[0-9][0-9\.]*$/
  image:
    name: alpine
    entrypoint:
    - ""
  variables:
    APP_WORK_PATH: ${CI_PROJECT_DIR}/docker
  script:
  - version=$(echo "${CI_COMMIT_TAG}"|sed "s/P_//")
  - wget  --output-document=- --post-data="user=$CI_REGISTRY_USER&pwd=$CI_REGISTRY_PASSWORD&caas_token=$CAAS_TOKEN&version=$version&ref=$CI_COMMIT_REF_NAME&file=docker/docker-compose-assistance-gsil.yml"  http://caas-console-edd.gsil-preprod.r2.eco4.cloud.e2.rie.gouv.fr/caas/deploy.php
  needs:
  - docker-build

Explications

stage: le job est fait en phase aval, durant le stage deploy.
rules: le job n'est exécuté que si le pipeline est déclenché par la création d'une etiquette (COMMIT_TAG) commençant par P_, suivi de chiffre et de point ( P_1.0, P_25.09.01, P_3.8.9.12, ...)
image: nous n'avons besoin que d'un unix léger pour faire une requete http en post, alpine suffit et est la plus légère.
script: il faut passer les informations dans les data en post pour que ConteneursFaciles puisse effectuer quelques contrôles et déployer le bon docker-compose du dépôt.
needs: ne se lance que si la création des images n'a pas échoué

Variables à transmettre

user/pwd à alimenter avec les variables CI/CD de Gitlab, pour pouvoir se connecter à la registrie et récupérer les images.
caas_token: $CAAS_TOKEN est une variable CI/CD créée et déposée par ConteneursFacile, créant un lien unique entre le projet et la pile de services
version: calculé à partir du $COMMIT_TAG, assure l'identification d'une image entre la PREPROD et la PROD
ref: $COMMIT_TAG ou $CI_COMMIT_REF_NAME assurent que le fichier docker-compose à récupérer par ConteneursFaciles sera le bon, surtout s'il existe plusieurs branches.
file: le chemin complet du fichier docker-compose.yml à déployer
Vous pouvez transmettre des variables personnelles, avec des valeurs stockées dans les variables CI/CD Gitlab. Elles sont masquées, absentes des sources et transmissibles à la section environnement du fichier docker-compose. C'est idéal pour les password, à transmettre aux services de BDD et du backend par exemple.

Job déploiement en Prod

docker-deploy:
  stage: deploy
  rules:
  - if: $CI_COMMIT_TAG =~ /^[0-9][0-9\.]*$/
  image:
    name: alpine
    entrypoint:
    - ""
  variables:
    APP_WORK_PATH: ${CI_PROJECT_DIR}/docker
  script:
  - version=$(echo "${CI_COMMIT_TAG}"|sed "s/P_//")
  - wget --output-document=- --post-data="user=$CI_REGISTRY_USER&pwd=$CI_REGISTRY_PASSWORD&caas_token=$CAAS_TOKEN&version=$version&ref=$CI_COMMIT_REF_NAME&file=docker/docker-compose-assistance-gsil.yml&noredirecthttps=1" http://caas-console-edd.gsil.r2.eco4.cloud.e2.rie.gouv.fr/caas/deploy.php

Explications

stage: le job est fait en phase aval, durant le stage deploy.
rules: le job n'est exécuté que si le pipeline est déclenché par la création d'une etiquette (COMMIT_TAG) contenant que des chiffres et des "."( 1.0, 25.09.01, 3.8.9.12, ...)
image: nous n'avons besoin que d'un unix léger pour faire une requete http en post, alpine suffit et est la plus légère.
script: il faut passer les informations dans les data en post pour que ConteneursFaciles puisse effectuer quelques contrôles et déployer le bon docker-compose du dépôt.

Variables à transmettre

user/pwd à alimenter avec les variables CI/CD de Gitlab, pour pouvoir se connecter à la registrie et récupérer les images.
caas_token: $CAAS_TOKEN est une variable CI/CD créée et déposée par ConteneursFacile, créant un lien unique entre le projet et la pile de services
version: calculé à partir du $COMMIT_TAG, assure l'identification d'une image entre la PREPROD et la PROD
ref: $COMMIT_TAG ou $CI_COMMIT_REF_NAME assurent que le fichier docker-compose à récupérer par ConteneursFaciles sera le bon, surtout s'il existe plusieurs branches.
file: le chemin complet du fichier docker-compose.yml à déployer
Vous pouvez transmettre des variables personnelles, avec des valeurs stockées dans les variables CI/CD Gitlab. Elles sont masquées, absentes des sources et transmissibles à la section environnement du fichier docker-compose. C'est idéal pour les password, à transmettre aux services de BDD et du backend par exemple.

Attention!

Tant que votre fichier n'est pas validé, sur l'écran "Mes Projets", aucun déploiement ne sera tenté par ConteneursFaciles. Lors des contrôles, les anomalies sont testées, et un correctif vous est proposé.