• 10 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 22/02/2021

Codifiez votre infrastructure

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Dans ce chapitre, nous allons voir comment l'Infrastructure-as-Code permet de faciliter le déploiement des applications grâce aux fameux conteneurs. Si vous ne savez pas ce qu'est un conteneur, je vous recommande de suivre le cours Optimisez votre déploiement en créant des conteneurs avec Docker.

Construisez les images de votre application avec Docker

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 :

register
Changez la version de l'openjdk dans le dockerfile

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 :

register
Changez la version des images Docker créées dans les fichiers pom.xml

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 :

register
Le pipeline se lance à nouveau

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.

Déployez votre application avec Docker Compose

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.

En résumé

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.

Exemple de certificat de réussite
Exemple de certificat de réussite