Daemonized buildbot start

Question

J'essaye de composer l'image maître de buildbot de docker la plus simple possible qui exécute buildbot start en instructions ENTRYPOINT/CMDDockerfile.
J'ai essayé d'utiliser beaucoup de combinaisons de dumb-init, gosu et exec, mais sans succès.
La situation est la suivante:

1. Lorsque je tente de lancer deamonized buildroot avec la commande docker run -d -v $local/vol/bldbot/master:/var/lib/buildbot buildbot-master-test, le conteneur démarre correctement, mais il est mis fin brusquement. Le journal se présente comme suit:

   [horodatage] [-] Journal ouvert.
   [horodatage] [-] twistd 16.0.0 (/ usr/bin/python 2.7.12) démarrage.
   [horodateur] [-] Classe de réacteur: twisted.internet.epollreactor.EPollReactor.
   [timestamp] [-] A partir BuildMaster - buildbot.version: 0.9.2
   [timestamp] [-] configuration de chargement de '/var/lib/buildbot/master.cfg'
   [timestamp] [-] Configuration de la base de données avec l'URL 'sqlite: /state.sqlite'
   [timestamp] [-] Définition du mode de journalisation de la base de données sur 'wal'
   [timestamp] [-] exécution du nettoyage pour le maître 1 c8aa8b0d5ca3:/var/lib/buildbot
   [timestamp] [-] ajoutant 1 changesources nouveaux, en supprimant 0
   [timestamp] [-] en ajoutant 1 nouveaux adjuvants, en supprimant 0
   [timestamp] [-] en ajoutant 2 nouveaux ordonnanceurs, en supprimant 0
   [timestamp] [-] Aucun serveur web configuré sur ce maître
   [timestamp] [-] ajouter 1 nouveaux travailleurs, la suppression 0
   [timestamp] [-] PBServerFactory à partir de 9989
   [timestamp] [-] à partir usine
   [timestamp] [-] BuildMaster est en cours d'exécution

2. Quand je lance le conteneur en mode interactif avec la commande suivante docker run --rm -it -v $local/vol/bldbot/master:/var/lib/buildbot buildbot-master-test /bin/sh et je lance la commande buildbot start tous les travaux comme un charme.

Je l'ai déjà étudié le contenu de l'image maître officiel de buildbot docker, à savoir buildbot/buildbot-master. Je vois que les auteurs ont décidé d'utiliser la commande exec twistd -ny $B/buildbot.tac dans start_buildbot.sh, pas leur propre buildbot start.

Donc la question est, comment composer les instructions ENTRYPOINT/CMD dans le Dockerfile qui s'exécute simplement buildbot start.

---

ADDITIF 1

Dockerfile contenu

FROM  alpine:3.4 

ENV BASE_DIR=/var/lib/buildbot SRC_DIR=/usr/src/buildbot 
COPY start $SRC_DIR/ 
RUN \ 
    echo @testing http://nl.alpinelinux.org/alpine/edge/testing >> /etc/apk/repositories && \ 
    echo @community http://nl.alpinelinux.org/alpine/edge/community >> /etc/apk/repositories && \ 
    apk add --no-cache \ 
     python \ 
     py-pip \ 
     py-twisted \ 
     py-cffi \ 
     py-cryptography@community \ 
     py-service_identity@community \ 
     py-sqlalchemy@community \ 
     gosu@testing \ 
     dumb-init@community \ 
     py-jinja2 \ 
     tar \ 
     curl && \ 
# install pip dependencies 
    pip install --upgrade pip setuptools && \ 
    pip install "buildbot" && \ 
    rm -r /root/.cache 

WORKDIR $BASE_DIR 

RUN \ 
    adduser -D -s /bin/sh bldbotmaster && \ 
    chown bldbotmaster:bldbotmaster . 

VOLUME $BASE_DIR 

CMD ["dumb-init", "/usr/src/buildbot/start","buildbot","master"] 

---

ADDITIF 2

contenu du script start

#!/bin/sh 
set -e 
BASE_DIR=/var/lib/buildbot 

if [[ "$1" = 'buildbot' && "$2" = 'master' ]]; then 

    if [ -z "$(ls -A "$BASE_DIR/master.cfg" 2> /dev/null)" ]; then 
     gosu bldbotmaster buildbot create-master -r $BASE_DIR 
     gosu bldbotmaster cp $BASE_DIR/master.cfg.sample $BASE_DIR/master.cfg 
    fi 

    exec gosu bldbotmaster buildbot start $BASE_DIR 
fi 

exec "$@" 

Answer 1

Buildbot bootstrap est basé sur les fichiers ".tac" de Twisted, qui doivent être démarrés en utilisant twistd -y buildbot.tac. Le script buildbot start est en fait juste un emballage pratique autour de twistd. En fait, il suffit de lancer twistd, puis surveille les logs pour confirmer que buildbot a bien démarré. Il n'y a pas de valeur ajoutée au-delà de cette surveillance du journal, il n'est donc pas strictement obligatoire de démarrer buildbot avec le démarrage de buildbot. Vous pouvez simplement le démarrer avec twistd -y buildbot.tac.

Comme vous l'avez l'image officielle de docker commence buildbot avec twistd -ny buildbot.tac Si vous regardez l'aide de twistd, -y signifie que le démon Twisted exécutera un fichier .tac et le -n signifie qu'il ne sera pas daemonize . Ceci est dû au fait que docker est en train de regarder les processus de lui-même, et ne veut pas que son entrypoint soit démonisé.

La commande buildbot start dispose également d'une option --nodaemon, qui est en réalité seulement «exécutée» à twistd -ny. Donc pour votre dockerfile, vous pouvez aussi nous twistd -ny ou buildbot start --nodaemon, cela fonctionnera de la même manière.

Un autre Docker spécifique est que le buildbot.tac est différent. Il a configuré les logs twistd pour les sortir sur stdout au lieu de les sortir sur twisted.log. Cela est dû au fait que la conception de docker s'attend à ce que les journaux soient dans stdout de sorte que vous puissiez configurer n'importe quel programme de transfert de journaux de fantaisie indépendamment de la technologie de l'application.

Answer 2

J'ai étudié à nouveau la référence docker et le manuel buildbot et j'ai trouvé un indice.
Il y a une remarque avec un ngnix exemple

Ne pas passer une commande service x start à un conteneur détaché. Par exemple, cette commande tente de démarrer le service nginx.

$ docker run -d -p 80:80 my_image service nginx start

Cela réussit à démarrer le service nginx à l'intérieur du conteneur. Cependant, il échoue le paradigme de conteneur détaché en ce que le processus racine (service nginx start) renvoie et le conteneur détaché s'arrête comme prévu. Par conséquent, le service nginx est démarré mais n'a pas pu être utilisé. Au lieu de cela, de lancer un processus tel que le serveur Web nginx procédez comme suit:

$ docker run -d -p 80:80 my_image nginx -g 'daemon off;'

D'autre part, il y a une option

L'option --nodaemon indique Buildbot sauter daemonizing. Le processus commencera au premier plan. Il reviendra seulement à la ligne de commande quand il est arrêté.

Les deux sentiers supérieurs au rendement

exec gosu bldbotmaster buildbot start --nodaemon $BASE_DIR 

ligne dans la ligne de scénario start qui résout phénomène de terminaison au moins brusque.