Réussir son déploiement continu avec Docker, Helm et Jenkins : notre guide

Des images “prerelease” prêtes pour la production

Parlons-en de la production. Il est temps de transporter ces images Laradock pour recevoir la production. Par exemple pour le container php-fpm nous allons réaliser les actions ci-dessous pour déployer cette image dans la registry de google

mat@vm:~/project/laradock$ vi cloudbuild-php-fpm.yml
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build',
           '--build-arg', 'LARADOCK_PHP_VERSION=7.2',
           '--build-arg', 'LARADOCK_PHALCON_VERSION=3.4.1',
           '--build-arg', 'INSTALL_MYSQLI=true',
....
           '--build-arg', 'PHP_FPM_ADDITIONAL_LOCALES="es_ES.UTF-8 fr_FR.UTF8"',
           '-t',
           'eu.gcr.io/myProject/myAppli/prerelease/php-fpm',
           '.']
images: [
    'eu.gcr.io/myProject/myAppli/prerelease/php-fpm',
]
mat@vm:~/project/laradock$ cd php-fpm
mat@vm:~/project/laradock/php-fpm$ gcloud builds submit --
config=../cloudbuild-php-fpm.yaml

On créé ainsi des images de Laradock dans lesquelles on va pouvoir déployer notre code source. Quelques réflexes sont à acquérir :

toutes les options sélectionnées dans Laradock, sont à reporter dans l’image
dès que Laradock est modifié, il faut penser à régénérer ces images Il faut ensuite faire le même exercice pour chaque container, à savoir ici dans notre exemple nginx et php-fpm

Un sprint de développement

Une fois les premières lignes de code développées, nous allons vouloir pousser ce code dans notre chaîne d’intégration continue et peupler différents environnements : intégration, release et au final la production. Nous allons faire la même chose qu’en local sauf qu’on va s’appuyer sur une image prerelease Laradock et on va y placer à l’intérieur le code source.

Préparer les images pour les environnements

Par contre, dans cette image destinée à la production, on ne place pas forcément les mêmes fichiers qu’en développement. Par exemple, le fichier php.ini est très certainement différent entre la production et le développement. Il faut collaborer entre tous les acteurs DevOps du projet pour tenir compte des exigences de chacun et créer ces fichiers.

mat@vm:~/project$ mkdir -p build/docker/php-fpm && cd build/docker/php-fpm
mat@vm:~/project/build/docker/php-fpm$ vi Dockerfile
FROM eu.gcr.io/myProject/myAppli/prerelease/php-fpm:latest
ARG BUILD_ENV
RUN curl --silent --show-error https://getcomposer.org/installer | php -- -
-install-dir=/usr/local/bin --filename=composer
ENV COMPOSER_ALLOW_SUPERUSER=1
COPY build/docker/php-fpm/php7.2.ini /usr/local/etc/php/php.ini
COPY . /var/www/
RUN composer install
RUN php artisan ........
COPY build/docker/php-fpm/docker-entrypoint.sh /usr/local/bin/dockerentrypoint
RUN chmod +x /usr/local/bin/docker-entrypoint
WORKDIR /var/www
ENTRYPOINT ["docker-entrypoint"]
CMD ["php-fpm"]

On ajoute donc pour chaque container un builder docker qui sera exécuté par notre pipeline d’intégration continue.

mat@vm:~/project/build/docker$ vi cloudbuild-php-fpm.yml
steps:
- name: 'gcr.io/cloud-builders/docker'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
  docker pull eu.gcr.io/myProject/myAppli/release/php-fpm:${_RELEASE_TAG}
|| exit 0

- name: 'gcr.io/cloud-builders/docker'
args: ['build',
         '--build-arg',
         'BUILD_ENV=${_BUILD_ENV}',
          '-t',
          'eu.gcr.io/myProject/myAppli/release/php-fpm:${_RELEASE_TAG}',
          '-f',
          '.build/docker/php-fpm/Dockerfile',
          '--cache-from', 'eu.gcr.io/myProject/myAppli/release/phpfpm:${_RELEASE_TAG}',
          '.']
images: [
          'eu.gcr.io/myProject/myAppli/release/php-fpm:${_RELEASE_TAG}',
]

Et le chef d’orchestre s’appelle Jenkins

Une fois que tout est prêt, c’est à dire le contenant avec les images prerelease et le contenu avec le code source, il est temps de lancer le build depuis notre plateforme de déploiement continu Jenkins. Pour ce faire, on créé un Jenkinsfile pour exécuter les différentes étapes. Premièrement, compiler l’image à partir de l’image prerelease créée précédemment.

stage('Build and push release') {
      parallel {
          stage('PHP-FPM') {
              agent { label "jenkins-slave" }
              steps {
                     script {
                        if (BRANCH_NAME == 'develop'){
                           env.RELEASE_TAG='int'
                           env.BUILD_ENV='int'
                      } else if (BRANCH_NAME == 'release'){
                          env.RELEASE_TAG='release'
                          env.BUILD_ENV='release'
                       }
                }
               container('slave') {
                   withCredentials([file(credentialsId: 'gcp-login',
variable: 'GCP_LOGIN')]) {
                         sh "./build/scripts/init.sh"
                         sh "gcloud builds submit --
config=build/docker/cloudbuild-php-fpm.yml \
--
substitutions=_BUILD_ENV='$BUILD_ENV',_RELEASE_TAG='$RELEASE_TAG'"
                        }
                  }
            }
       }
   }
}

Et helm pour ajouter la touche finale

En effet, la dernière étape, celle du déploiement dans le cluster Kubernetes se fera au travers de helm. On créé donc pour chaque service un template helm

mat@vm:~/project$ mkdir -p build/helm && cd build/helm

mat@vm:~/project/build/helm$ vi values.yaml

….

global:

       releaseTag:

php:

       repository: eu.gcr.io/myProject/myAppli/php-fpm/release/php-fpm

      pullPolicy: Always

     replicaCount: 1

….

mat@vm:~/project/build/helm$ vi templates/php-service.yaml apiVersion: v1 kind: Service metadata:     name: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php labels:    app: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace « + » « _ » }}    release: {{ .Release.Name }}    heritage: {{ .Release.Service }} spec:    type: ClusterIP    ports:      – port: 9000 selector:      app: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php      release: {{ .Release.Name }} mat@vm:~/project/build/helm$ vi templates/php-deployment.php apiVersion: apps/v1 kind: Deployment metadata:          name: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php labels:         app: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php         chart: {{ .Chart.Name }}-{{ .Chart.Version | replace « + » « _ » }}         release: {{ .Release.Name }}         heritage: {{ .Release.Service }} spec:         replicas: {{ .Values.php.replicaCount }}         selector:            matchLabels:                 app: {{ .Chart.Name }}-{{ .Values.global.releaseTag }}-php         template:               metadata:                       labels:                             app: {{ template « name » . }}-{{ .Values.global.releaseTag }}-php          release: {{ .Release.Name }}         date: « {{ .Release.Time.Seconds }} »    spec:          containers:         – name: {{ .Chart.Name }}-{{ .Values.global.releaseTag }}-php          image: « {{ .Values.php.repository }}:{{ .Values.global.imageTag }} »          imagePullPolicy: {{ .Values.php.pullPolicy }}

           ports:           – containerPort: 9000

Noter que vous aurez besoin d’un script shell replace_myvalues.sh pour permettre de contextualiser le fichier values.yaml à partir des informations portées dans le Jenkinsfile. Par exemple le tag de la version en cours de déploiement :

sed -i "s//$RELEASE_TAG/g" build/helm/values.yaml

Il faut ensuite lancer le déploiement helm dans le Jenkinsfile :

stage('Deploy release') {
        agent { label "jenkins-slave" }
        steps {
           script {
                env.REPLICAS=1
                if (BRANCH_NAME == 'develop'){
                    env.TAG_APP_NAME='int'
                    env.RELEASE_TAG='int'
       } else if (BRANCHNAME == 'release'){
                 env.TAG_APP_NAME='release'
                env.RELEASE_TAG='release'
         }
    }
         container('slave') {
             withCredentials([file(credentialsId: 'gcp-login', variable:
'GCP_LOGIN')]) {
           sh "./build/scripts/init.sh"
           sh "./build/scripts/replace_myvalues.sh"
           sh "helm init --client-only"
           sh script: "helm upgrade --force --install myProject-
$TAG_APP_NAME ./build/helm \
                               --namespace=myProject-$TAG_APP_NAME"
                     }
               }
       }
}

Dans cette dernière étape, via le Jenkinsfile, on peut amener de la variablité qui sera poussée dans le container : par exemple, le mot de passe de connexion de l’admin de l’application. Ce secret est stocké dans le keystore de Jenkins de manière sécurisé et confidentielle.

environment {
          ROOT_PASSWORD_INT = credentials('root-password-no-prod')
         ROOT_PASSWORD_RELEASE = credentials('root-password-prod')
}
script {
        if (BRANCH_NAME == 'develop'){
             env.PASSWORD=$ROOT_PASSWORD_INT
       } else if (BRANCH_NAME == 'release'){
            env.PASSWORD=$ROOT_PASSWORD_RELEASE
      }
}

Il faut ensuite remonter cette variable PASSWORD dans le fichier key:value values.yaml du déploiement helm puis dans l’environnement d’exécution du container php en ajoutant un environnement au déploiement helm :

mat@vm:~/project/build/helm$ vi templates/php-deployment.php
spec:
         template:
             spec:
                 containers:
                   - env:
                         - name: APPLI_PASSWORD
                          valueFrom:
                              secretKeyRef:
                                    name: {{ template "name" . }}-{{
.Values.global.releaseTag }}
key: appli-password

Cette variable d’environnement APPLI_PASSWORD sera alors disponible dans fichier docker-entrypoint.sh et on pourra faire des manipulations de fichiers postdéploiements:

mat@vm:~/project/build/docker/php-fpm$ vi docker-entrypoint.sh
sed -i "s/APPLI_PASSWORD>/$APPLI_PASSWORD/g" /var/www/config.php

Docker, helm et Jenkins… comment nous les intégrons dans nos démarches au sein d’Inside Group ?

Au sein d’Inside Group, en utilisant les containers Docker, nous pouvons déployer notre application dans tous les environnements en étant représentatif de la production. Pour ce faire, on utilise le pipeline Jenkins pour orchestrer la construction et le déploiement via helm de notre application.

A vous de jouer … Et pourquoi pas venir nous rencontrer pour partager nos expériences !