Mettez en place l'intégration et la livraison continues avec la démarche DevOps

Notre application PetClinic est construite à partir de fichiers, nommés dockerfiles, déjà présents dans le contrôle de code source. Ces dockerfiles sont présents dans le répertoire Docker du projet et contiennent les lignes suivantes :

FROM openjdk:8-jre-alpine

VOLUME /tmp

ARG DOCKERIZE_VERSION
ARG ARTIFACT_NAME
ARG EXPOSED_PORT

ENV SPRING_PROFILES_ACTIVE docker

ADD https://github.com/jwilder/dockerize/releases/download/${DOCKERIZE_VERSION}/dockerize-alpine-linux-amd64-${DOCKERIZE_VERSION}.tar.gz dockerize.tar.gz
RUN tar xzf dockerize.tar.gz
RUN chmod +x dockerize

ADD ${ARTIFACT_NAME}.jar /app.jar

RUN touch /app.jar

EXPOSE ${EXPOSED_PORT}

ENTRYPOINT ["java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Ce dockerfile part d'une image qui contient déjà la version 8 de Java et copie tous les .jar des différents projets, afin de construire les différentes images associées. Enfin, la dernière étape de ce dockerfile est de lancer la commande Java avec le jar associé.

Dans cette partie du cours, vous allez modifier le dockerfile pour voir l'impact de l'Infrastructure-as-Code sur votre pipeline de déploiement. Pour ce faire, ouvrez le fichierDockerfile présent dans le dossier Docker, afin de modifier la version du runtime de Java en version openjdk:13-alpine :

Avant de pousser ce fichier sur Git, vous allez modifier la version de release de chaque pom.xml présent dans le projet, pour incrémenter le numéro de version des images Docker créées, et ainsi ne pas écraser les versions précédemment buildées :

Une fois ces modifications faites, poussez les fichiers sur Git :

git add .
git commit -m "Modification de la version de Java et incrémentation du numéro de version"
git push origin master

Le pipeline d'intégration continue devrait se lancer :

Et la registry Docker devrait contenir les nouvelles images buildées grâce au pipeline.

Vous venez de voir à quel point l'Infrastructure-as-Code est pratique pour tester rapidement le changement de version d'un framework, ou le changement de version d'un middleware comme Apache ou IIS. En ne changeant que quelques lignes, nous pouvons alors relancer tout le pipeline, afin de voir s'il y a un impact sur le code applicatif.

L'Infrastructure-as-Code ne s'arrête pas là. Dans le cas de Docker, toute l'application peut être déployée grâce au fichier docker-compose.yml qui contient toute la définition de l'application, la relation entre les images Docker et le sens de démarrage de celles-ci.

Le fichier docker-compose.yml présent dans le repository Git définit des images en dur. Vous allez remplacer le nom des images par les nouvelles images que vous venez de créer.

Remplacez alors toutes les lignes contenant mszarlinski/ par votre nom de registry (chez moi, registry.gitlab.com/laurentgrangeau/). De plus, ajoutez aussi en bout de ligne le numéro de version de l'image que vous venez de créer :2.0.7

Le fichier docker-compose.yml devrait ressembler à ceci (le fichier est volontairement tronqué) :

version: '2'

volumes:
  graf-data:

services:
  config-server:
    image: registry.gitlab.com/laurentgrangeau/spring-petclinic-microservices/spring-petclinic-config-server:2.0.7
    container_name: config-server
    mem_limit: 512M
    ports:
     - 8888:8888

  discovery-server:
    image: registry.gitlab.com/laurentgrangeau/spring-petclinic-microservices/spring-petclinic-discovery-server:2.0.7
    container_name: discovery-server
    mem_limit: 512M
    depends_on:
      - config-server
    entrypoint: ["./dockerize","-wait=tcp://config-server:8888","-timeout=120s","--","java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
    ports:
     - 8761:8761

...

Et voilà, vos fichiers Docker et Docker Compose sont prêts à être lancés par votre pipeline de livraison continue.

Dans ce chapitre, vous avez simplement modifié les fichiers Dockerfile, pom.xml et Docker Compose, pour voir que l'Infrastructure-as-Code fonctionne bien sur ce projet. Il vous donne donc un bon exemple de l'intérêt de l'Infrastructure-as-Code et de Docker, pour déployer facilement votre application !

Dans le prochain chapitre, vous verrez comment configurer votre pipeline pour qu'il déploie votre code grâce à Docker et Docker Compose, ainsi que le lancement automatique des tests.