Enchaînement Docker Images et exécuter pour

Question

Je tends l'image APIMan/wildfly Docker avec ma propre image qui fera deux choses:

1) Laissez tomber ma demande de fichier .war dans les autonomes/déploiements wildfly

2) Exécuter une série de commandes cURL qui interrogeraient le serveur Wildfly afin de configurer APIMan.

Dans un premier temps, j'ai essayé de créer deux images Docker (le premier à déposer dans le fichier .war et la seconde pour exécuter les commandes cURL), mais je supposé à tort que l'instruction CMD dans l'image la plus interne serait exécutée en premier et les CMD seraient exécutés à l'extérieur.

Par exemple:

ImageA: 
FROM jboss/apiman-wildfly:1.1.6.Final 
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent 
COPY /RatedRestfulServer/target/RatedRestfulServer-1.0-SNAPSHOT.war /opt/jboss/wildfly/standalone/deployments/ 

CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c", "standalone-apiman.xml"] 

Et

ImageB: 
FROM ImageA 
COPY /configure.sh /opt/jboss/wildfly/ 

CMD ["/opt/jboss/wildfly/configure.sh"] 

j'avais d'abord cru qui serait lancé au cours de l'exécution wildfly/APIMAN premier (par l'instruction CMD ImageA) et mon script personnalisé serait exécuter (par l'instruction ImageB CMD). Je suppose que c'est incorrect parce que dans toute la hiérarchie entière, seulement 1 instruction CMD est exécutée (le dernier dans le Dockerfile externe au sein de la chaîne)? Donc, j'ai alors tenté de tout fusionner en 1 Dockerfile qui démarrerait (dans le processus de construction) Wildfly/APIMAN, lancerait les commandes cURL, fermerait le serveur wildfly et ensuite la commande CMD le redémarrerait pendant l'exécution et Wildfly/APIMan serait configuré. Toutefois, cela ne fonctionne pas car lorsque je lance Wildfly (dans le cadre de la construction), il contrôle la console et attend l'affichage des messages de journal, ainsi la construction ne se termine jamais. Si j'ajoute un '&' à la fin de la commande RUN, il ne s'exécute pas (Dockerfile : RUN results in a No op).

Voici mon Dockerfile pour cette tentative:

FROM jboss/apiman-wildfly:1.1.6.Final 
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent 
COPY /RatedRestfulServer/target/RatedRestfulServer-1.0-SNAPSHOT.war /opt/jboss/wildfly/standalone/deployments/ 
COPY /configure.sh /opt/jboss/wildfly/ 
RUN /opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -c standalone-apiman.xml 
RUN /opt/jboss/wildfly/configure.sh 
RUN /opt/jboss/wildfly/bin/jboss-cli.sh --connect controller=127.0.0.1 command=:shutdown 

CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c", "standalone-apiman.xml"] 

Y a-t-il des solutions à cela? J'essaie de faire exécuter mon script "configure.sh" APRÈS Wildfly/APIMan. Cela ne me dérange pas si cela est fait pendant le processus de construction ou au moment de l'exécution, mais je ne vois aucun moyen de le faire pendant le processus de construction, car Wildfly n'a pas de mode démon.

Answer 1

La prémisse originale derrière mon problème (même si elle n'a pas été explicitement mentionnée dans le message original) était de configurer APIMan dans l'image et sans aucune intervention extérieure de l'image.

C'est un peu un hack, mais j'ai été capable de résoudre ce problème en créant 3 scripts. Un pour démarrer Wildfly, un pour exécuter le script de configuration et un troisième pour les exécuter tous les deux. Espérons que cela épargnera à une autre pauvre âme de passer une journée à comprendre tout cela.

En raison de la nature du Dockerfile autorisant uniquement un appel d'exécution au moment de l'exécution, cet appel devait correspondre à un script personnalisé.

Voici les fichiers avec les commentaires.

Dockerfile

FROM jboss/apiman-wildfly:1.1.6.Final 
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent 
COPY /RatedRestfulServer/target/RatedRestfulServer-1.0-SNAPSHOT.war /opt/jboss/wildfly/standalone/deployments/ 
COPY /configure.sh /opt/jboss/wildfly/ 
COPY /execute.sh /opt/jboss/wildfly/ 
COPY /runWF.sh /opt/jboss/wildfly/ 

CMD ["/opt/jboss/wildfly/execute.sh"] 

Remarque, les 3 scripts sont intégrés dans l'image. Le script execute.sh est exécuté à l'exécution (instantiation) et non au moment de la construction.

execute.sh

#!/bin/sh 

/opt/jboss/wildfly/configure.sh & 
/opt/jboss/wildfly/runWF.sh 

Remarque, le script configure.sh est envoyé à l'arrière-plan afin que nous puissions passer au script runWF.sh alors que configure.sh est encore en cours d'exécution)

configure.sh

#!/bin/sh 

done="" 
while [ "$done" != "200" ] 
do 
     done=$(curl --write-out %{http_code} --silent --output /dev/null -u username:password -X GET -H "Accept: application/json" http://127.0.0.1:8080/apiman/system/status) 
     sleep 3 
done 

# configuration curl commands 
curl ... 
curl ... 

Le script configure.sh ci-dessus fonctionne en une boucle interrogeant le serveur wildfly/apiman via curl toutes les 3 secondes vérifiant son état.Une fois qu'il récupère un code d'état HTTP de 200 (représentant un état «opérationnel»), il quitte la boucle et se déplace librement vers la configuration. Notez que ceci devrait probablement être rendu un peu plus sûr en fournissant un autre moyen de quitter la boucle (par exemple après un certain nombre de requêtes, etc.). J'imagine que cela donnerait un palpitations de coeur de développeur de production et je ne suggérerais pas de le déployer dans la production, cependant cela fonctionne pour le moment.

runWF.sh

#!/bin/sh 

/opt/jboss/wildfly/bin/standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -c standalone-apiman.xml 

Ce script commence tout simplement le serveur. Les paramètres lient divers modules à 0.0.0.0 et demandent à wildfly d'utiliser le fichier xml apiman standalone pour la configuration.

Sur ma machine, il faut environ 15 à 15 secondes (en fonction de l'ordinateur sur lequel je l'ai exécuté) wildfly + apiman (avec mon fichier war personnalisé) pour charger complètement, mais une fois que c'est fait, le script configure pourra pour interroger avec succès, puis passer aux commandes de configuration curl. Pendant ce temps, wildfly contrôle toujours la console car elle a été démarrée en dernier et vous pouvez surveiller l'activité et terminer le processus avec ctrl-c.

Answer 2

seulement 1 instruction CMD est exécutée (la dernière dans le Dockerfile externe de la chaîne)?

Oui, c'est correct, et gardez à l'esprit que CMD n'est pas exécuté au moment de la construction mais au moment de l'instanciation. Essentiellement ce que vous faites dans votre deuxième CMD de Dockerfile est primordial le premier lorsque vous instancié le récipient de ImageB

Si vous faites une sorte de API Rest ou cli ou cURL pour vous connecter à votre serveur wildfly je vous suggère de faire cette configuration après l'instanciation du conteneur, pas après la construction du conteneur. De cette façon:

CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c", "standalone-apiman.xml"]` 

est toujours votre dernière commande. Si vous avez besoin de fichiers supplémentaires ou de modifications aux fichiers de configuration, vous pouvez les placer dans le Dockerfile afin qu'ils soient copiés au moment de la compilation avant que CMD ne soit appelé lors de l'instanciation.

Donc, en résumé:

1) Construire votre conteneur Docker avec ce Dockerfile (build docker):

FROM jboss/apiman-wildfly:1.1.6.Final 
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent 
COPY /RatedRestfulServer/target/RatedRestfulServer-1.0-SNAPSHOT.war /opt/jboss/wildfly/standalone/deployments/ 
COPY /configure.sh /opt/jboss/wildfly/ 
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c", "standalone-apiman.xml"] 

2) Exécuter (instancier votre conteneur à partir de votre image nouvellement créée)

docker run <image-id> 

3) Exécutez ce qui suit à partir d'un conteneur ou de votre hôte sur lequel Wildfly est configuré de la même manière. Cela en supposant que vous utilisez une API Rest pour configurer les choses (par exemple en utilisant cURL):

/opt/jboss/wildfly/configure.sh 

Vous pouvez instancier un second conteneur pour exécuter cette commande avec quelque chose comme ceci:

docker run -ti <image-id> /bin/bash 

Answer 3

Construire une image:

FROM jboss/apiman-wildfly:1.1.6.Final 
RUN /opt/jboss/wildfly/bin/add-user.sh admin admin --silent 
COPY /RatedRestfulServer/target/RatedRestfulServer-1.0-SNAPSHOT.war /opt/jboss/wildfly/standalone/deployments/ 
COPY /configure.sh /opt/jboss/wildfly/ 
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c", "standalone-apiman.xml"] 

Le démarrage. Une fois le démarrage terminé, utilisez la commande docker exec pour lancer votre script configure dans le conteneur en cours d'exécution.

docker run -d --name wildfly <image name> 
docker exec wildfly /opt/jboss/wildfly/configure.sh