Riot Games

Dans ce premier tutoriel de la série Docker, vous apprendrez:

• Ce que nous essayons d’accomplir chez Riot

• Configuration de base pour Docker

• Commandes de Traction Docker de Base

• Comment exécuter des conteneurs Docker en tant que démons

• Options de configuration de base de Jenkins

Lorsque j’ai commencé à apprendre Docker il y a un an et à explorer son utilisation, j’ai eu du mal à trouver une excellente documentation et des exemples – même aujourd’hui, beaucoup décrivent des cas d’utilisation simples qui ne sont finalement pas prêts pour la production. La production d’applications avec des conteneurs Docker nécessite de s’adapter à leur nature éphémère et à leur focalisation sur un seul processus. Cela présente des défis pour les applications ayant des besoins de persistance des données ou des architectures multi-processus.

Comme je l’ai mentionné dans mon dernier post, nous utilisons Jenkins comme un logiciel open source fondamental sur lequel nous construisons notre automatisation. Jenkins est également une excellente application pour démontrer une façon de penser à « Dockeriser » vos applications. Nous déployons Jenkins avec ces composants architecturaux à l’esprit:

• Serveur maître Jenkins (processus Java)

• Données de base Jenkins (Plugins, Définitions de tâches, etc)

• Proxy web NGINX (nous utilisons des certificats SSL, etc., avec NGINX est un choix facile ici)

• Construire des agents esclaves (machines en SSH dans, ou connexion JNLP à, maître Jenkins)

C’est un bon point de départ. Au cours de cette série d’articles de blog, je couvrirai les façons de penser à tout ce qui précède en tant que conteneurs et terminerai par un aperçu avancé des façons d’utiliser les conteneurs Docker comme esclaves de construction. Pour commencer, nous allons créer un serveur maître Jenkins dans un conteneur Docker. Ensuite, nous passerons à la gestion de la persistance des données et à l’ajout d’un proxy Web avec NGINX.

Toute cette série de blogs couvrira les concepts Docker suivants:

• Créer vos propres Dockerfiles

• Minimiser les dépendances d’image sur les images publiques

• Création et utilisation de volumes de données, y compris les sauvegardes

• Créer des  » Environnements de construction  » conteneurisés à l’aide de conteneurs

• Gestion des données « secrètes » avec des images et des Jenkins

Si vous n’avez pas jeté un œil à l’image du docker Cloudbees Jenkins, commencez par là car c’est vraiment très bon. C’était mon point de référence lorsque j’ai d’abord pensé à exécuter Jenkins dans un conteneur Docker et pour beaucoup de gens, cela pourrait suffire. Vous pouvez trouver leur documentation ici et leur dépôt/Dockerfile Git ici.

Ce premier blog est divisé en deux plans de cours. Chacun est dimensionné pour prendre environ 30 minutes à compléter. Tout d’abord, la première partie consiste à préparer votre environnement de développement et à apprendre à travailler avec le conteneur Docker Jenkins par défaut proposé par Cloudbees. La deuxième partie consiste à jeter les bases pour envelopper cette image dans votre propre fichier Dockerfile et à prendre un contrôle plus élégant de l’image. Ensemble, ils sont conçus pour vous aider à démarrer, surtout si vous n’avez jamais travaillé avec Docker auparavant ou si vous êtes relativement nouveau sur Docker — bien qu’ils supposent que vous savez et comprenez déjà comment travailler avec Jenkins. Si vous êtes expérimenté avec Docker, une partie du matériel de la leçon 1 sera un peu une relecture de choses que vous connaissez probablement déjà.

LEÇON 1: CONFIGUREZ ET EXÉCUTEZ VOTRE PREMIÈRE IMAGE

Préparez-vous à rouler. Chez Riot, nous travaillons avec Docker (et Jenkins) sur Windows, Mac OSX et Linux. Je préfère travailler avec Docker sur OSX, bien qu’il soit parfaitement fonctionnel sous Windows depuis Docker 1.6. De nos jours, il existe d’excellents installateurs pour les deux systèmes d’exploitation. Je travaillerai du point de vue d’OSX mais les mêmes outils existent pour Windows.

PRÉREQUIS:

1. Vous aurez besoin de Windows 10 Pro ou Mac OSX Yosemite 10.10.3 (ou version ultérieure)

2. Si vous utilisez Windows, vous devez vous assurer que la virtualisation Windows est activée (voir la documentation fournie par Docker)

Une NOTE RAPIDE SUR KITEMATIC

Avec Docker 1.8 et la sortie de Docker Toolbox, Docker inclut désormais « Kitematic », un outil graphique astucieux pour vous aider à gérer et à visualiser ce qui se passe avec vos images et conteneurs Docker. La plupart de ce tutoriel se concentre sur l’utilisation des arguments de ligne de commande et le travail avec Docker sans l’interface graphique Kitematic. C’est pour mieux vous exposer aux mécanismes sous-jacents. De même, dans les blogs ultérieurs, je commence à couvrir l’utilisation de Compose pour démarrer et arrêter plusieurs conteneurs à la fois.

ÉTAPE 1: INSTALLEZ DOCKER

1. Aller à : https://www.docker.com/docker-mac ou https://www.docker.com/docker-windows

2. Téléchargez et installez la version appropriée de Docker pour votre système d’exploitation

3. Suivez toutes les instructions de configuration.

4. Vérifiez que votre installation fonctionne en ouvrant le shell recommandé pour votre système d’exploitation (Terminal pour OSX, Powershell pour Windows) en exécutant « Docker Quickstart Terminal ». Sous Windows, ce sera un raccourci sur votre bureau. Sur OSX, vous le trouverez dans votre dossier applications/Docker. Vérifiez les commandes suivantes et assurez-vous que vous n’obtenez aucune erreur

docker ps

docker info

5. Avant de faire autre chose, nous devrions augmenter la mémoire par défaut et les paramètres du processeur utilisés par Docker. Plus tard, nous allons régler Jenkins pour utiliser plus de mémoire et si nous n’ajustons pas ces paramètres en premier, Jenkins peut se bloquer.

• Accédez à votre widget Docker dans votre barre d’outils et sélectionnez « Préférences »

• Accédez à l’onglet Configuration avancée

• Augmenter l’utilisation du processeur à au moins 4 cœurs

6. Augmentez l’utilisation de la mémoire à au moins 8 Go, de préférence plus, quelque chose comme 12 Go pour être sûr (si vous l’avez disponible)

ÉTAPE 2: TIREZ ET EXÉCUTEZ LE CONTENEUR CLOUDBEES JENKINS

1. Restez dans la fenêtre de votre terminal Docker.

2. Retirer Jenkins du dépôt public en courant:

docker pull jenkins/jenkins

docker run -p 8080:8080 --name=jenkins-master jenkins/jenkins

3. Notez que le message « Configuration initiale de Jenkins » dans votre fenêtre shell générera un mot de passe pour vous. Notez cela comme vous en aurez besoin plus tard. Si vous le perdez, vous pouvez exécuter ‘docker exec jenkins-master cat /var/jenkins_home/secrets`initialAdminPassword’ avec votre conteneur en cours d’exécution pour le récupérer.

4. Ouvrez votre navigateur préféré et pointez-le sur http://localhost:8080

Veuillez noter que vous verrez que j’utilise l’indicateur Dockernamename et nommez le conteneur jenkins-master – c’est une convention que j’utiliserai tout au long de ce blog. Nommer vos conteneurs est une bonne pratique pratique avec trois avantages :

1. Cela les rend faciles à mémoriser et à interagir avec

2. Docker ne permet pas à deux conteneurs d’avoir le même nom, ce qui évite les erreurs comme démarrer accidentellement deux conteneurs identiques

3. De nombreux outils Docker courants (comme Docker Compose) utilisent des noms de conteneurs spécifiques, donc s’habituer à nommer vos conteneurs est une bonne pratique.

ÉTAPE 3: RENDRE CELA UN PEU PLUS PRATIQUE

L’étape précédente démarre Jenkins avec ses paramètres de démarrage les plus basiques. Vous pouvez même voir que Jenkins a besoin d’une configuration de base et vous demande un mot de passe administrateur (que vous pouvez obtenir à partir des journaux affichés sur votre écran au démarrage). Si vous êtes comme Riot, il est peu probable que vous exécutiez Jenkins avec les paramètres par défaut. Passons en revue l’ajout de quelques options utiles. Nous ne nous embêterons pas encore à configurer Jenkins; il suffit de savoir qu’il peut démarrer et fonctionner.

ÉTAPE 3A: DÉMONISER

Vous ne voulez probablement pas voir les journaux Jenkins cracher à la norme la plupart du temps. Utilisez donc l’indicateur de démon Docker pour démarrer le conteneur (-d).

1. Ctrl-c sur la fenêtre du terminal exécutant votre conteneur pour l’arrêter

2. Exécutez les commandes suivantes

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d jenkins/jenkins

Maintenant, vous devriez simplement afficher une chaîne de hachage et être renvoyé à votre terminal. Si vous êtes nouveau sur Docker, cette chaîne de hachage est en fait l’ID unique de votre conteneur (utile si vous commencez à automatiser ces commandes).

ÉTAPE 3B: PARAMÈTRES DE MÉMOIRE

Nous avons tendance à exécuter Jenkins avec des paramètres costauds chez Riot. Rappelez-vous quand vous avez augmenté le processeur / mémoire utilisé par Docker plus tôt? C’est la raison principale pour laquelle. Pour un démarrage de base, exécutez les commandes suivantes

docker stop jenkins-master

docker rm jenkins-master

docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" jenkins/jenkins

Cela devrait donner à Jenkins un joli pool de mémoire de 8 Go et de la place pour gérer la collecte des ordures.

ÉTAPE 3C: AUGMENTER LE POOL DE CONNEXIONS

Chez Riot, nous recevons beaucoup de trafic vers notre serveur Jenkins, nous avons donc appris à donner un peu plus de répit à Jenkins. Exécutez ce qui suit

docker stop jenkins-master

docker rm jenkins-master

Cela donnera à Jenkins un bon bassin de gestionnaires et une casquette. Par coïncidence, vous avez maintenant appris à utiliser les OPTIONS JAVA et JENKINS comme variables d’environnement de manière significative. Veuillez noter que cela fonctionne en raison de la façon dont Cloudbees a structuré de manière pratique son fichier Dockerfile Jenkins.

ÉTAPE 4: TOUT ASSEMBLER

J’ai placé tout ce que nous avons appris ici dans un simple makefile afin que vous puissiez utiliser les commandes make pour contrôler l’exécution de votre conteneur docker Jenkins. Vous pouvez le trouver ici:

• https://github.com/maxfields2000/docker Jenkins_tutorial/tree/master/didacticiel_01

Vous pouvez utiliser les commandes suivantes:

• make build – Tire l’image Jenkins

• make run – Exécute le conteneur

• faire stop – Arrête le conteneur

• effectuer des arrêts de nettoyage et supprimer le conteneur existant

Vous n’avez pas besoin d’utiliser le makefile, je trouve juste plus facile que de taper toute la commande run. Vous pouvez facilement les mettre dans un script de votre choix à la place.

J’espère que vous verrez à quel point il est facile de se mettre en marche avec Docker et Jenkins. J’ai essayé de vous donner quelques options de base pour prendre le conteneur Cloudbees Jenkins par défaut et le rendre un peu plus utilisable. Cloudbees propose de nombreux tutoriels utiles pour exécuter leur conteneur, tels que la préinstallation des plugins et le stockage des données Jenkins.

Cela m’amène à de futurs articles sur le sujet. Ce conteneur / image est utile mais présente quelques inconvénients: pas de journalisation cohérente, pas de persistance, pas de proxy de serveur web devant lui, et aucun moyen propre de vous garantir d’utiliser la version de Jenkins que vous voulez. Cela soulève des questions comme: et si vous voulez vous en tenir à une ancienne version? Ou si vous souhaitez utiliser la dernière période de publication disponible?

Dans la prochaine leçon, je couvrirai de rendre ce conteneur un peu plus robuste. Notamment:

• Créer votre propre fichier Dockerfile pour envelopper la base Cloudbees

• Déplacement de certaines variables d’environnement dans cette nouvelle image

• Création d’un dossier de journal, définition d’autorisations et d’autres répertoires Jenkins utiles, et récupération des journaux Jenkins pendant son exécution

LEÇON 2 – Un WRAPPER D’IMAGE DE BASE JENKINS

Dans la leçon précédente, j’ai discuté de la configuration d’un environnement de développement pour exécuter Docker et j’ai expérimenté l’image Docker Jenkins fournie par Cloudbees. Nous avons constaté qu’il était simple et facile à utiliser, avec de superbes fonctionnalités prêtes à l’emploi. Pour progresser dans les domaines d’amélioration que nous avons identifiés, les concepts Docker abordés dans cette leçon sont:

• Créer votre propre fichier Dockerfile

• Définition de variables d’environnement dans un fichier Dockerfile

• Création de dossiers et d’autorisations dans un fichier Dockerfile

• Utilisation de docker exec pour exécuter des commandes sur un conteneur en cours d’exécution

FAIRE VOTRE FICHIER DOCKERFILE DE BASE

Nous voulons apporter quelques modifications à la façon dont Jenkins démarre par défaut. Dans le dernier blog, nous avons géré cela en créant un makefile qui a passé des arguments en tant que variables d’environnement. Étant donné que nous voulons le faire à chaque fois, nous pouvons simplement les déplacer dans notre propre fichier Dockerfile. De plus, notre propre fichier Dockerfile nous permettra de verrouiller la version de Jenkins que nous utilisons au cas où Cloudbees mettrait à jour la leur et que nous ne soyons pas prêts à la mettre à niveau.

Nous le faisons en quatre étapes:

1. Créez un répertoire de travail

2. Dans votre éditeur de texte préféré, créez un nouveau fichier appelé « Dockerfile »

3. Ajoutez ce qui suit au fichier et enregistrez-le:

FROM jenkins/jenkins:2.112LABEL maintainer=""

4. Ensuite, à la ligne de commande, entrez:

docker build -t myjenkins .

Ce que nous avons fait ici, c’est d’extraire une version particulière de l’image Jenkins du dépôt docker public. Vous trouverez toutes les versions disponibles ici:

• Vous pouvez toujours définir la clause FROM pour qu’elle soit la version de l’image disponible. Cependant, vous ne pouvez pas simplement définir la version sur la version de Jenkins que vous voulez. Il s’agit de la version de l’image « tag » ou « label », et Cloudbees est assez agréable pour la faire correspondre à la version Jenkins à l’intérieur de l’image. Cloudbees propose « jenkins/jenkins » comme moyen pratique d’obtenir la dernière version, ou « jenkins/jenkins:lts » pour obtenir la version la plus récente de « Support à long terme ». Dans cet exemple, j’utilise une version spécifique. Ces balises qui étiquettent les types de versions sont géniales, mais leur utilisation signifie que la version de Jenkins peut changer sous vous, ce qui peut entraîner des complications si vous n’étiez pas prêt à mettre à niveau. Je recommande le « verrouillage de version » comme une meilleure pratique générale pour gérer les dépendances dans Docker ou d’autres outils de gestion des dépendances. Vous voulez que les choses changent quand vous en avez l’intention, pas avant. C’est pourquoi j’utilise une version spécifique ici.

  EN TESTANT LE NOUVEAU FICHIER DOCKERFILE

  Nous pouvons basculer très facilement vers l’image en modifiant notre commande docker run de la manière suivante:

  docker run -p 8080:8080 --name=jenkins-master -d --env JAVA_OPTS="-Xmx8192m" --env JENKINS_OPTS=" --handlerCountMax=300" myjenkins

  Nous pouvons maintenant nettoyer ces variables d’environnement en les plaçant dans notre propre fichier Dockerfile.

  AJOUT DE VARIABLES D’ENVIRONNEMENT À NOTRE FICHIER DOCKERFILE

  Il est facile d’ajouter des paramètres par défaut pour des éléments tels que des variables d’environnement aux fichiers Dockerfiles. Cela fournit également un bon morceau d’auto-documentation. Et, comme vous pouvez toujours les écraser lors de l’exécution du conteneur Docker, il n’y a vraiment aucun inconvénient.

  1. Dans votre fichier Dockerfile, ajoutez les lignes suivantes après la ligne « MAINTENEUR »:

  ENV JAVA_OPTS="-Xmx8192m"ENV JENKINS_OPTS=" --handlerCountMax=300"

  2. Enregistrez et reconstruisez votre image:

  • je n’ai pas de problème.

  docker build -t myjenkins .

  Assez simple! Vous pouvez tester que cela fonctionne toujours en entrant les trois commandes suivantes:

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  

  Votre image devrait commencer dès le départ! Mais comment savez-vous que les variables d’environnement ont fonctionné? Simple: de la même manière que vous vérifieriez pour voir quels arguments ont démarré votre application Jenkins en utilisant normalement ps. Et cela fonctionne même si vous développez sous Windows.

  EN EXÉCUTANT UNE COMMANDE DE BASE SUR VOTRE CONTENEUR

  Pour confirmer que les options Java et Jenkins sont correctement définies, nous pouvons exécuter ps dans notre conteneur et voir le processus Java Jenkins en cours d’exécution en utilisant docker exec

  docker exec jenkins-master ps -ef | grep java

  Vous devriez voir quelque chose de similaire revenir

  jenkins 1 0 99 21:28 ? 00:00:35 java -Xmx8192m -jar /usr/share/jenkins/jenkins.war --handlerCountMax=300

  

  De là, vous pouvez facilement voir que nos paramètres sont bloqués. docker exec est un moyen simple d’exécuter des commandes shell à l’intérieur de votre conteneur et aussi un moyen incroyablement simple de les inspecter. Cela fonctionne même sous Windows car, rappelez-vous, la commande après « exec » est exécutée à l’intérieur de votre conteneur et est donc basée sur l’image de base utilisée par votre conteneur.

  CONFIGURATION D’UN DOSSIER DE JOURNAL

  Dans le blog précédent, nous avons noté que nous avions perdu la visibilité sur les journaux Jenkins lors de l’exécution de notre conteneur avec l’indicateur daemonize (-d). Nous voulons utiliser la fonctionnalité Jenkins intégrée pour définir un dossier de journal. Nous allons devoir le faire dans notre Dockerfile, puis passer l’option de journalisation à Jenkins.

  Modifions à nouveau notre fichier Dockerfile. Entre le « MAINTENEUR » et la première ligne ENV, nous allons ajouter ce qui suit

  RUN mkdir /var/log/jenkins

  Nous plaçons la commande à cet emplacement dans le fichier pour suivre les meilleures pratiques. Il est plus probable que nous changions les variables d’environnement que ces répertoires de configuration, et chaque ligne de commande d’un fichier Dockerfile devient essentiellement sa propre couche d’image. Vous maximisez la réutilisation des calques en plaçant les éléments fréquemment modifiés près du bas.

  Construisez à nouveau votre image:

  docker build -t myjenkins

  Vous obtiendrez une erreur qui ressemble à

  ---> Running in 0b5ac2bce13bmkdir: cannot create directory '/var/log/jenkins': Permission denied

  

  Pas de soucis. En effet, le conteneur Cloudbees par défaut définit l’utilisateur en cours d’exécution sur l’utilisateur « Jenkins « . Si vous regardez leur fichier Dockerfile (trouvé ici: https://github.com/ Jenkinsci/docker/blob/master/Dockerfile), vous devriez voir, près du bas

  USER ${user}

  Cette syntaxe peut être un peu déroutante. Il utilise les « arguments » de construction de Docker pour vous permettre de définir l’utilisateur. Si vous regardez plus loin le fichier Docker, vous trouverez la valeur par défaut. Regardez près du haut du fichier Dockerfile pour

  ARG user=jenkins

  Cela crée l’argument « user » (ARG) et le définit sur l’utilisateur Jenkins. Cela vous permet de changer le nom d’utilisateur que Jenkins utilise lorsque vous appelez docker build buildbuild-arg somevariable=somevalue. Notez que cela ne fonctionne que si vous construisez le Dockerfile à partir de zéro. Vous ne pouvez pas modifier ces valeurs avec un pull docker ou une exécution docker. Vous pouvez en savoir plus sur les arguments de construction ici. Parce que nous utilisons une version prédéfinie dans notre clause FROM, nous nous retrouvons avec l’utilisateur par défaut: « jenkins ».

  Sous Linux normal, vous utiliseriez simplement SUDO ou d’autres moyens pour créer le dossier (/var/log appartient à root). Heureusement pour nous, Docker nous permet de changer d’utilisateur.

  Ajoutez ce qui suit à votre fichier Dockerfile :

  1. Avant votre ligne RUN mkdir ajouter

  USER root

  2. Après votre ligne RUN mkdir, ajoutez

  RUN chown -R jenkins:jenkins /var/log/jenkins

  3. Après votre ligne RUN chown, ajoutez:

  USER jenkins

  Notez que nous avons également dû ajouter une commande chown car nous voulons que l’utilisateur Jenkins puisse écrire dans le dossier. Ensuite, nous définissons root, puis réinitialisons Jenkins afin que le comportement du fichier Dockerfile soit préservé.

  Construisez à nouveau votre image:

  docker build -t myjenkins .

  

  Et… vos erreurs devraient disparaître.

  Avec le répertoire log défini (remarque: vous pouvez placer ce dossier où vous le souhaitez, nous utilisons /var/log pour plus de cohérence), nous pouvons maintenant dire à Jenkins d’écrire dans ce dossier au démarrage en modifiant les variables d’environnement JENKINS_OPTS.

  Dans votre fichier Dockerfile, modifiez la ligne JENKINS_OPTS pour qu’elle ressemble à ceci:

  • ENV JENKINS_OPTS = »handhandlerCountMax=300ilefichier journal=/var/log/jenkins/jenkins.log »

  ENV JENKINS_OPTS="--handlerCountMax=300 --logfile=/var/log/jenkins/jenkins.log"

  Maintenant, construisez votre image une fois de plus

  docker build -t myjenkins .

  Testons notre nouvelle image et si nous pouvons terminer le fichier journal! Essayez les commandes suivantes

  docker stop jenkins-master

  docker rm jenkins-master

  docker run -p 8080:8080 --name=jenkins-master -d myjenkins

  Avec le conteneur en cours d’exécution, nous pouvons terminer le fichier journal si tout a fonctionné

  docker exec jenkins-master tail -f /var/log/jenkins/jenkins.log

  RÉCUPÉRER les JOURNAUX SI JENKINS SE BLOQUE

  Temps pour un tour de bonus! Tant que nous discutons des journaux, Docker présente un problème intéressant si Jenkins se bloque. Le conteneur cessera de fonctionner et docker exec ne fonctionnera plus. Alors que faire?

  Nous discuterons des moyens plus avancés de conserver le fichier journal plus tard. Pour l’instant, comme le conteneur est arrêté, nous pouvons en copier des fichiers à l’aide de la commande docker cp. Simulons un crash en arrêtant le conteneur, puis en récupérant les journaux :

  1. ctrl-c pour sortir de la queue du fichier journal

  2. Exécutez les commandes suivantes

  docker stop jenkins-master

  docker cp jenkins-master:/var/log/jenkins/jenkins.log jenkins.log

  cat jenkins.log

  

  PENSÉES DE CONCLUSION

  Vous pouvez trouver tout le travail dans mon tutoriel Git repo (et le makefile de commodité mis à jour) ici:

  • https://github.com/maxfields2000/docker Jenkins_tutorial/tree/master/didacticiel_02

  En créant notre propre fichier Dockerfile qui enveloppe le fichier Cloudbees, nous avons pu nous rendre la vie un peu plus facile. Nous avons mis en place un endroit pratique pour stocker les journaux et avons appris à les regarder avec la commande docker exec. Nous avons déplacé nos paramètres par défaut dans le Dockerfile et maintenant nous pouvons les stocker dans le contrôle de source comme un bon morceau d’auto-documentation.

  Nous avons encore un défi de persistance des données. Nous avons appris à extraire des fichiers journaux d’un conteneur arrêté (pratique lorsque Jenkins se bloque). Mais en général, si notre conteneur s’arrête, nous perdons toujours tous les emplois que nous avons créés. Donc, sans persistance, cette image Jenkins n’est utile que pour le développement et les tests locaux.

  Cela nous amène au prochain article. Avec nos fondations en place – notre propre wrapper Dockerfile, verrouillé sur une version pratique de Jenkins – nous pouvons résoudre le problème de persistance. Le prochain article explorera ces concepts:

  • Préservation des données du travail et du plugin Jenkins

  • Persistance des données Docker avec des Volumes

  • Création d’un conteneur de volume de données

  • Partage de données en volumes avec d’autres conteneurs

  Pour plus d’informations, consultez le reste de cette série :

  Partie I : Penser à l’intérieur du Conteneur
  Partie II : Placer Jenkins dans un conteneur Docker (cet article)
  Partie III : Docker & Jenkins : Données qui persistent
  Partie IV : Jenkins, Docker, Proxies et Compose
  Partie V: Prendre le contrôle de votre Image Docker
  Partie VI : Construire avec Jenkins À l’intérieur d’un Conteneur Docker Éphémère
  Partie VII : Tutoriel : Construire avec Jenkins À l’intérieur d’un Conteneur Docker Éphémère
  Partie VIII : DockerCon Talk et l’Histoire Jusqu’à présent