Utiliser rien d’autre que Docker pour les projets

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é. Donc, le projet est là, et vous devriez pouvoir l’exécuter.

Vous espérez qu’il existe une documentation vous indiquant quoi faire – ce qui n’est pas si courant – et si / quand il y en a, cela ne fonctionne généralement pas. Tu dois savoir Quel à installer, où pour l’installer, comment 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 verrons différentes approches que nous pourrions utiliser pour faciliter cela en utilisant uniquement Docker.

Premier niveau : Utiliser un alias avec Docker

Exemple avec Java + Maven

Considérons un projet Java, par exemple. Habituellement, pour exécuter une application Java, vous exécutez java -jar application.jar.

Pour générer le jar fichier 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. Voyons quelques commandes Maven :

• mvn dependency:copy-dependencies
  Télécharge les dépendances si elles ne sont pas encore téléchargées.
• mvn package
  Construit l’application et génère le jar. Il télécharge également les dépendances si elles ne sont pas encore 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=true paramètre.

En supposant que nous ayons besoin de Maven 3 et Java 11, c’est ainsi que vous pourriez 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 ou mvn -version. Habituellement, l’image Docker officielle de ces outils vous donne des instructions sur la façon de l’exécuter, et vous pouvez simplement créer un alias pour cela.

Avantages:

• 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 toujours savoir quelle version de Java est utilisée et quel outil est utilisé (dans ce cas, Maven) et sa version.
• Si vous avez affaire à un langage de programmation que vous ne connaissez pas, il vous faudra encore plus de temps pour comprendre ce qu’il faut 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.

Niveau deux : Utiliser Docker pour exécuter l’application

C’est là que Fichier Docker 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 sur 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 dans ses avantages/inconvénients :

Avantages

• Le Dockerfile devrait faire partie du projet. Ainsi, il vous indique déjà comment exécuter l’application indépendamment des connaissances en langage de programmation.
• Il vous indique également quelle version et quelle image sont utilisées.
• Il hérite des avantages du Premier niveau sujet si vous postulez également Premier niveau connaissances.

Les inconvénients

• Encore faut-il savoir comment construire l’application.
• Cela signifie également que vous devez toujours savoir quelles commandes exécuter.

C’est une bonne approche. Vous pouvez fusionner Premier niveau et Niveau deux pour obtenir un meilleur résultat. Le projet devrait avoir Dockerfile, et la vie devient déjà un peu plus facile. Mais voyons comment la vie peut être encore Plus facile.

Niveau trois : Utiliser Docker pour créer et exécuter l’application

Et si vous ne connaissiez rien à Java et Maven, et que vous pouviez toujours créer l’application avec une seule commande que vous connaissez déjà ?

C’est là que Constructions en plusieurs étapes briller.

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’elles commence 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 précédent. Nous avions besoin d’un JAR fichier pour créer l’image Docker. Avec Multi-Stage Build, 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 premier FROM au premier RUN , il fait des choses liées à Maven – copier les fichiers qui doivent être copiés et exécuter 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 il définit le nom builder.

Après cela, vous voyez le deuxième FROM déclaration à l’aide de la openjdk:11-jre-slim image. Vous voyez également un COPY déclaration qui copie d’un endroit appelé builder. Mais qu’est-ce que c’est 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. C’est copier 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 est toujours la même : docker build -t my-application ..

Avantages:

• Quel que soit le langage de programmation, si le projet a cette approche, vous pouvez exécuter l’application sans rien installer d’autre que Docker.
• Il hérite des avantages de Premier niveau et Niveau deux.

Cela vaut la peine de dire que vous pouvez également utiliser ce Dockerfile avec Docker Composerce qui peut être très puissant, surtout si votre application doit exposer des ports, partager des volumes ou dépendre d’autres images.

Annexe : Utilisation de Docker pour chaque commande majeure

Maintenant que vous savez comment jouer avec différents FROM instructions, 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. Ainsi, il y a un dependency_resolver étape là. Au deuxième et au 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 .seules 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?

Lorsque vous essayez 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 -> candidature

Alors quel est le tester étape faire là-bas? Y a-t-il un moyen d’y accéder ?

Vous pouvez spécifier une cible en utilisant --target: docker build --target tester -t my-application ..

C’est aussi compatible avec Docker Compose.

Conclusion

Nous avons vu comment utiliser uniquement Docker pour créer et exécuter des applications et des commandes, supprimant ainsi le besoin de connaissances préalables dans certains outils ou langages de programmation. De plus, cela vaut la peine de dire que même si nous avons utilisé 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.

(yk, il)