Imaginez la situation suivante : vous commencez à travailler sur un nouveau projet, peut-être aussi avec un langage de programmation différent auquel vous n’êtes pas habitué. Le projet est donc là et vous devriez pouvoir l’exécuter.
Vous vous attendez à ce qu’il y ait une documentation vous indiquant quoi faire, ce qui n’est pas si courant, et s’il y en a, cela ne fonctionne généralement pas. Tu dois savoir Quoi Installer, où pour l’installer, Quoi pour le configurer, etc. Ce n’est pas un scénario rare, et vous pouvez vous y attendre à un moment donné. Et s’il y avait un moyen de s’assurer que cela ne se reproduise plus ?
Tout au long de cet article, nous examinerons différentes approches que nous pourrions utiliser pour faciliter cela en utilisant uniquement Docker.
Premier niveau : Utiliser des alias avec Docker
Exemple avec Java + Maven
Considérons un projet Java, par exemple. Généralement, pour exécuter une application Java, vous exécutez java -jar application.jar.
Pour générer le jar archiver et gérer les dépendances du projet, vous pouvez utiliser de nombreux outils différents, les plus connus étant Maven et Gradle. Considérons Maven pour cet exemple. Regardons quelques commandes Maven :
mvn dependency:copy-dependencies
Téléchargez les dépendances si elles ne l’ont pas déjà été.mvn package
Construisez l’application et générez lejar. Il télécharge également les dépendances si elles n’ont pas déjà été téléchargées. Si vous souhaitez ignorer l’exécution des tests dans le processus de construction, vous pouvez également passer le-Dmaven.test.skip=trueparamètre.
En supposant que nous ayons besoin de Maven 3 et Java 11, voici comment vous pouvez utiliser Docker :
alias java="docker run -v "$PWD":/home -w /home openjdk:11-jre-slim java"
alias mvn='docker run -it --rm --name maven -v "$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3-jdk-11-slim mvn'De cette façon, vous pouvez exécuter toutes les commandes Maven et Java sans avoir à installer Java ou Maven. Vous pouvez tester les commandes en exécutant java -version Soit mvn -version. L’image Docker officielle de ces outils vous donne généralement des instructions sur la façon de les exécuter, et vous pouvez créer un alias pour cela.
Avantage:
- Si vous n’avez plus besoin de l’utiliser, vous pouvez supprimer l’image Docker associée.
- Il est facile de changer de version.
Les inconvénients:
- Dans cet exemple, vous devez encore savoir quelle version de Java est utilisée et quel outil est utilisé (dans ce cas Maven) et sa version.
- S’il s’agit d’un langage de programmation que vous ne connaissez pas, il vous faudra encore plus de temps pour comprendre quoi faire.
- Encore faut-il savoir quelles commandes exécuter.
C’est une approche équitable, surtout si vous savez ce que vous faites. Mais cela ne vient pas avec le projet lui-même. Essayons donc de l’améliorer un peu.
Deuxième niveau : utiliser Docker pour exécuter l’application
C’est là que Dockerfile commence à briller. Nous savons exécuter des commandes en utilisant uniquement Docker, mais comment exécuter l’application ?
Un Dockerfile courant pour cette situation pourrait être :
FROM openjdk:11-jre-slim
ARG JAR_FILE=target/*.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]Et vous pouvez le construire de la même manière que vous construisez normalement une image docker, en utilisant docker build -t my-application .par exemple.
Vous pouvez voir que cela dépend d’un existant JAR fichier pour le construire. Comme vous l’avez vu dans le sujet précédent, nous savons comment le générer, mais nous serions en difficulté s’il s’agissait d’un autre langage ou outil de programmation.
Cela semble être une amélioration vraiment mineure, mais cela aide déjà beaucoup, comme vous pouvez le voir d’après ses avantages/inconvénients :
avantage
- Le Dockerfile doit venir à l’intérieur du projet. Ainsi, il vous indique déjà comment exécuter l’application indépendamment de la connaissance du langage de programmation.
- Il vous indique également quelle version et quelle image sont utilisées.
- Bénéficiez des avantages de Premier niveau thème s’il s’applique également Premier niveau connaissances.
Les inconvénients
- Vous devez encore comprendre comment créer l’application.
- Cela signifie également que vous devez toujours savoir quelles commandes exécuter.
C’est une bonne approche. tu peux fusionner Premier niveau Oui Niveau deux pour obtenir un meilleur résultat. Le projet devrait avoir un Dockerfile, et la vie devient déjà un peu plus facile. Mais voyons comment la vie peut être encore plus facile.
Troisième niveau : utiliser Docker pour créer et exécuter l’application
Et si vous ne connaissiez rien à Java et Maven, et que vous pouviez créer l’application avec une seule commande que vous connaissez déjà ?
C’est là que les constructions en plusieurs étapes brillent.
Avec les builds en plusieurs étapes, vous utilisez plusieurs instructions « FROM » dans votre Dockerfile. Chaque instruction `FROM` peut utiliser une base différente et chacune démarre une nouvelle étape de la construction. Vous pouvez copier sélectivement des artefacts d’une étape à une autre, en laissant derrière vous tout ce que vous ne voulez pas dans l’image finale.
Comment cela peut-il nous aider ? Eh bien, considérons le Dockerfile ci-dessus. nous avions besoin d’un JAR pour créer l’image Docker. Avec Multi-Stage Build, le Dockerfile lui-même peut être responsable de sa génération. Dans une approche simple, ce Dockerfile ressemblerait à ceci :
# ============= DEPENDENCY + BUILD ===========================
# Download the dependencies on container and build application
# ============================================================
FROM maven:3-jdk-11-slim AS builder
COPY ./pom.xml /app/pom.xml
COPY . /app
WORKDIR /app
RUN mvn package $MAVEN_CLI_OPTS -Dmaven.test.skip=true
# ============= DOCKER IMAGE ================
# Prepare container image with application artifacts
# ===========================================
FROM openjdk:11-jre-slim
COPY --from=builder /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]Voyons ce qui se passe ici.
Depuis le début FROM au premier RUN , vous faites des choses liées à Maven : copiez les fichiers qui doivent être copiés et exécutez la commande qui télécharge les dépendances et construit l’application. Il le fait en utilisant le maven:3-jdk-11-slim image, et définit le nom builder.
Après cela, vous voyez le second. FROM déclaration à l’aide de la openjdk:11-jre-slim image. Vous voyez également un COPY déclaration que les copies à partir d’un endroit appelé builder. mais qu’est-ce que c’est que ça place? Qu’est ce que c’est constructeur?
C’est le nom que nous avons défini pour l’image Maven au début FROM déclaration. copie le jar fichier de ce conteneur. Ainsi, vous pouvez littéralement jouer avec différents FROM entrées pour construire ce que vous voulez, et la commande pour construire l’image Docker reste la même : docker build -t my-application ..
Avantage:
- Quel que soit le langage de programmation, si votre projet adopte cette approche, vous pouvez exécuter l’application sans rien installer d’autre que Docker.
- Bénéficiez des avantages de Premier niveau Oui Niveau deux.
Cela vaut la peine de dire que vous pouvez également utiliser ce Dockerfile avec Docker Compose, qui peut être très puissant, surtout si votre application doit exposer des ports, partager des volumes ou s’appuyer sur d’autres images.
Annexe : Utilisation de Docker pour chaque commande principale
Maintenant que vous savez comment jouer avec différents FROM déclarations, un autre Dockerfile possible pourrait être :
# ============= DEPENDENCY RESOLVER =============
# Download the dependencies on container
# ===============================================
FROM maven:3-jdk-11-slim AS dependency_resolver
# Download all library dependencies
COPY ./pom.xml /app/pom.xml
WORKDIR /app
RUN mvn dependency:copy-dependencies $MAVEN_CLI_OPTS
# ============= TESTING =================
# Run tests on container
# =======================================
FROM dependency_resolver AS tester
WORKDIR /app
CMD mvn clean test $MAVEN_CLI_OPTS
# ============= BUILDER =================
# Build the artifact on container
# =======================================
FROM dependency_resolver as builder
# Build application
COPY . /app
RUN mvn package $MAVEN_CLI_OPTS -Dmaven.test.skip=true
# ============= DOCKER IMAGE ================
# Prepare container image with application artifacts
# ===========================================
FROM openjdk:11-jre-slim
COPY --from=builder /app/target/*.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]Nous avons donc maintenant quatre étapes différentes : dependency_resolver, tester, builderet l’application elle-même.
Si nous voulons construire l’application ou la tester, nous avons besoin des dépendances du projet. Il y a donc un dependency_resolver étape là. Dans les deuxième et troisième FROM déclarations, vous pouvez voir qu’ils dépendent de dependency_resolver.
Important: Si vous essayez de créer l’image docker avec docker build -t my-application .seulement la première, la troisième et la dernière étape (dependency_resolver, builderet l’application elle-même, respectivement) s’exécuteraient.
Mais pourquoi?
Lorsqu’il essaiera de construire l’image, il essaiera de voir quel est l’état final de l’image, qui serait l’application elle-même. Comme nous le savons et pouvons le voir, la dernière étape dépend de builder (COPY déclaration). Si nous vérifions le builder étape, nous verrons que cela dépend de dependency_resolver (FROM déclaration). Ainsi, il fonctionnera dans cet ordre:
dependency_resolver -> builder -> application
Quel est donc le tester étape faire là-bas? Y a-t-il un moyen d’y accéder ?
Vous pouvez spécifier une destination à l’aide de --target: docker build --target tester -t my-application ..
Ceci est également compatible avec Docker Compose.
conclusion
Nous avons vu comment utiliser uniquement Docker pour créer et exécuter des applications et des commandes, éliminant ainsi le besoin de connaissances préalables de tout outil ou langage de programmation. De plus, cela vaut la peine de dire que même si nous utilisons Docker pour ces exemples, cela fonctionnerait également avec d’autres runtimes de conteneurs comme Podman.
J’espère que vous trouverez cet article utile et que vous ferez passer le mot sur Docker.
(Oui oui)
