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
:

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.
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é) :
: '2'
:
:
:
:
: registry.gitlab.com/laurentgrangeau/spring-petclinic-microservices/spring-petclinic-config-server:2.0.7
: config-server
: 512M
:
- 8888:8888
:
: registry.gitlab.com/laurentgrangeau/spring-petclinic-microservices/spring-petclinic-discovery-server:2.0.7
: discovery-server
: 512M
:
- config-server
: ["./dockerize","-wait=tcp://config-server:8888","-timeout=120s","--","java", "-XX:+UnlockExperimentalVMOptions", "-XX:+UseCGroupMemoryLimitForHeap", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
:
- 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.