C’est l\u2019occasion de revenir sur les probl\u00e8mes que nous avons rencontr\u00e9s ainsi que les solutions apport\u00e9es, et sur certaines bonnes pratiques autour des builds Maven \/ Gradle \/ Android dans des conteneurs Docker, le tout g\u00e9r\u00e9 par du Pipeline as Code de Jenkins.<\/p>\n
Comme toute migration technique importante, nous l’avons r\u00e9alis\u00e9e \u00e9tape par \u00e9tape. Les 3 grandes \u00e9tapes ont \u00e9t\u00e9 les suivantes:<\/p>\n
- \n
- Cr\u00e9er nos propres images CI Docker<\/li>\n
- Utiliser les plugins Jenkins Pipeline & Pipeline Docker<\/li>\n
- G\u00e9n\u00e9rer tous les jobs Pipeline avec le Job DSL plugin<\/li>\n<\/ul>\n
Le diagramme suivant repr\u00e9sente le flux de travail lorsque toutes ces \u00e9tapes sont effectu\u00e9es:<\/p>\n
![\"Diagramme](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Jenkins.png\")
<\/a>Dans cet article, nous d\u00e9taillerons le contexte (pourquoi nous l’avons fait) et la premi\u00e8re \u00e9tape de cette migration sur la cr\u00e9ation de vos propres images CI Docker.<\/p>\nQu\u2019avions-nous \u00e0 construire ?<\/h3>\n
eXo Platform est b\u00e2tie sur l\u2019open-source et les standards ouverts<\/a><\/strong>. La plateforme est compatible avec la pile Java EE et s\u2019appuie sur de nombreuses biblioth\u00e8ques et composants open-source.<\/p>\n
![\"Mobile](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Mobile-1.jpg\")
<\/a>![\"Mobile](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Mobile-2.png\")
<\/a>![\"Desktop\"](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Desktop.png\")
<\/a><\/p>\nPour diff\u00e9rentes raisons que nous allons vous expliquer, nous avons \u00e0 g\u00e9rer un grand nombre de builds sur nos serveurs d\u2019Int\u00e9gration Continue .<\/p>\n
Composants d\u2019eXo Platform et Add-ons<\/h4>\n
La premi\u00e8re raison est que nous avons des d\u00e9p\u00f4ts git pour chacun des composants requis dans les livrables des distributions d\u2019eXo Platform:<\/p>\n
- \n
- 25+ composants \u00e0 construire\n
- \n
- projets pour la plateforme (cf. diagramme ci-dessous)<\/li>\n
- projets Juzu…<\/li>\n<\/ul>\n<\/li>\n
- De nombreux Add-ons\n
- \n
- 15+ Add-ons support\u00e9s<\/li>\n
- 100+ Add-ons communautaires<\/li>\n<\/ul>\n<\/li>\n
- Projets natifs pour le mobile\n
- \n
- application Android<\/li>\n
- application iOS<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
![\"Composants](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Composants-d\u2019eXo-Platform-et-Add-ons.png\")
<\/a>Git Workflow<\/h4>\nNous utilisons un workflow git <\/a><\/strong>bas\u00e9 sur un mod\u00e8le de branches que tous les projets eXo doivent suivre<\/strong>:<\/p>\n
- \n
- develop<\/strong> : branche qui contient les derniers d\u00e9veloppements valid\u00e9s<\/li>\n
- feature\/xxx<\/strong> : branches d\u00e9di\u00e9es aux nouvelles fonctionnalit\u00e9s majeures (de nombreux commits), “xxx” correspond au nom de la fonctionnalit\u00e9.<\/li>\n
- stable\/xxx<\/strong> : branches utilis\u00e9es pour faire des releases et pour corriger des probl\u00e8mes sur des versions stables. “xxx” correspond au num\u00e9ro de version stabilis\u00e9e (e.g 1.0.x).<\/li>\n
- fix\/xxx<\/strong> : branches d\u00e9di\u00e9es aux correctifs qui doivent \u00eatre ensuite int\u00e9gr\u00e9s dans la branche develop<\/strong>. Dans certains cas, ces corrections peuvent \u00eatre aussi appliqu\u00e9es sur la branche stable<\/strong>.<\/li>\n
- integration\/xxx<\/strong> : branches d\u00e9di\u00e9es aux processus automatiques (exemple: processus de traductions\u2026).<\/li>\n
- poc\/xxx<\/strong> : branches d\u00e9di\u00e9es \u00e0 la r\u00e9alisation de Proof of Concept (PoC)<\/li>\n<\/ul>\n
![\"Workflow](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Workflow-git-mod\u00e8le-de-branches-pour-suivre-les-projets-eXo.png\")
<\/a>Clients et versions d\u2019eXo Platform<\/h4>\nDepuis pr\u00e8s de 15 ans maintenant, eXo a publi\u00e9 de nombreuses versions d\u2019eXo Platform. Avec eXo Platform 5 en cours de d\u00e9veloppement et les versions que nous devons maintenir pour nos clients (eXo Platform 4.x: 4.0, 4.1, 4.2, 4.3, 4.4), nous avons ainsi plusieurs versions de nos environnements de build \u00e0 g\u00e9rer.
\nActuellement, nous devons \u00eatre en mesure de construire des projets avec les versions JDK6, JDK7 ou JDK8 et Maven 3.0, Maven 3.2 ou Maven 3.3. L’application Android native est construite par Gradle.<\/p>\nVous vous souvenez comment cr\u00e9er un job Maven dans l\u2019interface Jenkins ?<\/h4>\n
M\u00eame si Jenkins 2 a fait de nombreux efforts pour l’am\u00e9liorer, il est toujours contraignant de cr\u00e9er de nouveaux jobs Maven via l’interface utilisateur, comme vous pouvez le voir ci-dessous:<\/p>\n
![\"comment](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/comment-cr\u00e9er-un-job-Maven-dans-l\u2019interface-Jenkins.png\")
<\/a><\/p>\n\u201cJenkins DSL et jobs Pipeline dans Docker \u00e0 la rescousse !\u201d<\/strong><\/p>\n
Pour ces diff\u00e9rentes raisons, nous devions g\u00e9rer beaucoup de jobs Maven \u00e0 partir de l’interface utilisateur<\/strong> de Jenkins et maintenir nombre d\u2019outils dans plusieurs versions<\/strong> (Maven, JDK …) sur les agents Jenkins ainsi que sur les postes de d\u00e9veloppeurs. Ce travail n\u2019\u00e9tant ni int\u00e9ressant ni efficace, nous avons d\u00e9cid\u00e9 de trouver une solution pour l’automatiser et le g\u00e9rer diff\u00e9remment.<\/p>\n
La technologie bas\u00e9e sur les conteneurs (Docker)<\/a><\/strong>, combin\u00e9e \u00e0 l’\u00e9mergence d’outils d’automatisation dans Jenkins avec Pipeline<\/a><\/strong> et l’efficacit\u00e9 du DSL Job plugin<\/a><\/strong>, nous a alors sembl\u00e9 \u00eatre la meilleure solution dans le contexte eXo.<\/p>\n
1ere \u00e9tape: Cr\u00e9er ses propres images Docker<\/h3>\n
Il est important de respecter les bonnes pratiques g\u00e9n\u00e9rales lorsque l\u2019on cr\u00e9\u00e9 nos propres images Docker, mais \u00e9galement quelques sp\u00e9cificit\u00e9s propres aux environnements de build.<\/p>\n
![\"Cr\u00e9ation](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Cr\u00e9ation-de-nos-propres-images-Docker.png\")
<\/a>Choisir une image de base pour la distribution<\/h4>\nTous nos serveurs qui font office d\u2019agents Jenkins sont g\u00e9r\u00e9s \u00e0 partir de Puppet et sont bas\u00e9s sur la distribution Ubuntu. Nous avons donc d\u00e9cid\u00e9 d’utiliser une image Docker plus l\u00e9g\u00e8re bas\u00e9e sur cette distribution nomm\u00e9e baseimage-docker<\/a><\/strong>.<\/p>\n
C’\u00e9tait un bon compromis entre une image tr\u00e8s l\u00e9g\u00e8re comme Alpine qui avait des probl\u00e8mes li\u00e9s \u00e0 l’installation de JDK et l’image Docker officielle d\u2019Ubuntu trop volumineuse.<\/p>\n
FROM phusion\/baseimage:0.9.21
\nLABEL MAINTAINER “eXo Platform <docker@exoplatform.com>”<\/p>\nD\u00e9finir la locale<\/h4>\n
Qui n’a jamais eu de tests en \u00e9chec en raison de probl\u00e8mes d’encodage ? Les tests passent sur mon poste Linux, mais ils \u00e9chouent sur le portable de mon coll\u00e8gue sous Windows !<\/i><\/p>\n
Il est tr\u00e8s fortement recommand\u00e9 de d\u00e9finir une locale pour s’assurer que tous les d\u00e9veloppeurs auront le m\u00eame comportement quel que soit leur environnement et que ce comportement sera conforme \u00e0 la configuration du serveur d\u2019Int\u00e9gration Continue.<\/p>\n
# Set the locale\nRUN locale-gen en_US.UTF-8\nENV LANG en_US.UTF-8\nENV LANGUAGE en_US:en\nENV LC_ALL en_US.UTF-8\n<\/pre>\n
Cr\u00e9er un utilisateur CI d\u00e9di\u00e9<\/h4>\n
\u201c…take care of running your processes inside the containers as non-privileged users (i.e., non-root).<\/i>\u201d est l’une des recommandations les plus importantes du guide de s\u00e9curit\u00e9 Docker<\/a>.<\/strong><\/p>\n
Dans le contexte de Jenkins, il est important de cr\u00e9er un utilisateur de CI d\u00e9di\u00e9 qui correspond \u00e0 l’<\/strong>uid:gid<\/i><\/strong> de l’utilisateur utilis\u00e9 par Jenkins sur vos agents<\/strong>.<\/p>\n
# eXo CI User\nARG EXO_CI_USER_UID=13000\nENV EXO_CI_USER ciagent\nENV EXO_GROUP ciagent\n...\n# Create user and group with specific ids\nRUN useradd --create-home --user-group -u ${EXO_CI_USER_UID} --shell \/bin\/bash ${EXO_CI_USER}<\/pre>\nEn effet, lorsque Jenkins ex\u00e9cute un job Pipeline avec Docker, il partage l’espace de travail du job ainsi que d’autres dossiers requis dans le conteneur Docker.<\/p>\n
Par exemple, Jenkins ex\u00e9cute la commande suivante sur l’agent:<\/p>\n
$ docker run -t -d -u 13000:13000\n-v m2-cache-ecms-develop-ci:\/home\/ciagent\/.m2\/repository\n-v \/srv\/ciagent\/workspace\/ecms-develop-ci:\/srv\/ciagent\/workspace\/ecms-develop-ci:rw\n-v \/srv\/ciagent\/workspace\/ecms-develop-ci@tmp:\/srv\/ciagent\/workspace\/ecms-develop-ci@tmp:rw\n... -e ******** --entrypoint cat exoplatform\/ci:jdk8-maven33\n<\/pre>\n
La cr\u00e9ation d\u2019un utilisateur CI d\u00e9di\u00e9 vous \u00e9vite ainsi les probl\u00e8mes d’autorisations avec les volumes Docker<\/strong>.<\/p>\n
Vous pouvez constater que nous d\u00e9finissons la variable EXO_CI_USER_UID<\/i><\/strong> avec l’instruction Docker ARG<\/i><\/strong>, elle aura son importance pour aider le d\u00e9veloppeur dans son environnement de de d\u00e9veloppement local et nous expliquerons pourquoi plus loin dans cette s\u00e9rie d’articles.<\/p>\n
ENTRYPOINT et CMD<\/h4>\n
Dans un Dockerfile, l’instruction ENTRYPOINT est une d\u00e9finition facultative pour la premi\u00e8re partie de la commande \u00e0 ex\u00e9cuter. Ainsi, les instructions ENTRYPOINT ou CMD<\/a><\/strong>, sp\u00e9cifi\u00e9es dans votre Dockerfile, identifient l’ex\u00e9cutable par d\u00e9faut pour l’image Docker. Mais la meilleure solution est de combiner ces deux instructions en utilisant CMD pour fournir des arguments par d\u00e9faut pour le ENTRYPOINT.<\/p>\n
Dans les versions ant\u00e9rieures du plugin Jenkins Docker Pipeline, Jenkins n\u2019utilisait pas l’option –entrypoint<\/i><\/strong> lors du d\u00e9marrage des conteneurs, la commande ex\u00e9cut\u00e9e \u00e9tait alors:<\/p>\n
$ docker run ... -e ******** exoplatform\/ci:jdk8-maven33 cat<\/pre>\n
<\/p>\n
Dans ce cas, si votre image Docker utilisait l\u2019instruction ENTRYPOINT pour d\u00e9clarer une commande \u00e0 ex\u00e9cuter, Jenkins ne pouvait pas utiliser votre image.<\/p>\n
C’est pourquoi nous avons ajout\u00e9 un script personnalis\u00e9 dans nos images Docker, comme solution de contournement, afin de pouvoir ex\u00e9cuter Maven comme commande au d\u00e9marrage du conteneur, mais \u00e9galement la commande cat<\/i> et d’autres commandes \u00e0 partir du moment o\u00f9 elles sont appel\u00e9es via un chemin absolu:<\/p>\n
Dockerfile<\/i><\/p>\n
COPY docker-entrypoint.sh \/usr\/bin\/docker-entrypoint\n# Workaround to be able to execute others command than \"mvn\" as entrypoint\nENTRYPOINT [\"\/usr\/bin\/docker-entrypoint\"]\n\nCMD [\"mvn\", \"--help\"]<\/pre>\n
docker-entrypoint.sh<\/i><\/p>\n
# Hack for Jenkins Pipeline: authorize cat without absolute path\nif [[ \"$1\" == \"\/\"* ]] || [[ \"$1\" == \"cat\" ]]; then\nexec \"$@\"\nfi\n\nexec mvn \"$@\"<\/pre>\n
Depuis plusieurs versions du plugin Jenkins Docker Pipeline<\/a><\/strong>, ce probl\u00e8me a \u00e9t\u00e9 corrig\u00e9 pour utiliser l’option –entrypoint<\/i> afin que l’instruction ENTRYPOINT soit toujours surcharg\u00e9e:<\/p>\n
$ docker run ... -e ******** --entrypoint cat exoplatform\/ci:jdk8-maven33<\/pre>\n
Utiliser l\u2019h\u00e9ritage pour \u00e9viter la duplication de code<\/h4>\n
Nous avons cr\u00e9\u00e9 et continuons \u00e0 cr\u00e9er des images Docker pour couvrir toutes nos environnements de build, aujourd\u2019hui cette liste contient notamment :<\/p>\n
- \n
- exoplatform\/ci:jdk6-maven30<\/li>\n
- exoplatform\/ci:jdk7-maven30<\/li>\n
- exoplatform\/ci:jdk7-maven32<\/li>\n
- exoplatform\/ci:jdk8-maven32<\/li>\n
- exoplatform\/ci:jdk8-maven33<\/li>\n
- exoplatform\/ci:jdk8-gradle2<\/li>\n
- \u2026<\/li>\n<\/ul>\n
Comme vous pouvez l’imaginer, il n’y a pas beaucoup de diff\u00e9rences entre toutes ces images. Nous avons donc cr\u00e9\u00e9 des images de base CI \u00e0 plusieurs niveaux afin d’\u00e9viter autant que possible la duplication du code.<\/p>\n
Le sch\u00e9ma ci-dessous montre comment ces images sont organis\u00e9es :<\/p>\n
![\"Image](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Image-de-base-CI-sur-docker-avec-h\u00e9ritage-pour-\u00e9viter-la-duplication-de-code.png\")
<\/a>Ci-dessous, il s’agit d’un extrait du Dockerfile pour l’image exoplatform\/ci:jdk8-maven33<\/i><\/strong> et vous pouvez voir qu’il n’y a que des instructions Docker li\u00e9es \u00e0 l’installation Maven car toutes les autres configurations ont \u00e9t\u00e9 effectu\u00e9es dans les images h\u00e9rit\u00e9es (d\u00e9finir les param\u00e8tres r\u00e9gionaux, cr\u00e9er un utilisateur CI …).<\/p>\nFROM exoplatform\/ci:jdk8\n\n# CI Tools version\nENV MAVEN_VERSION 3.3.9\n# Install Maven\nRUN mkdir -p \/usr\/share\/maven \\\n&& curl -fsSL http:\/\/archive.apache.org\/dist\/maven\/maven-3\/$MAVEN_VERSION\/binaries\/apache-maven-$MAVEN_VERSION-bin.tar.gz \\\n| tar xzf - -C \/usr\/share\/maven --strip-components=1 \\\n&& ln -s \/usr\/share\/maven\/bin\/mvn \/usr\/bin\/mvn\n\n\u2026\n\n# Custom configuration for Maven\nENV M2_HOME=\/usr\/share\/maven\nENV MAVEN_OPTS=\"-Dmaven.repo.local=${HOME}\/.m2\/repository -XX:+UseConcMarkSweepGC -Xms1G -Xmx2G -XX:MaxMetaspaceSize=1G -Dcom.sun.media.jai.disableMediaLib=true -Djava.io.tmpdir=${EXO_CI_TMP_DIR} -Dmaven.artifact.threads=10 -Djava.awt.headless=true\"\nENV PATH=$JAVA_HOME\/bin:$M2_HOME\/bin:$PATH\n\n...\n\n# Workaround to be able to execute others command than \"mvn\" as entrypoint\nENTRYPOINT [\"\/usr\/bin\/docker-entrypoint\"]\n\nCMD [\"mvn\", \"--help\"]<\/pre>\nComme expliqu\u00e9 pr\u00e9c\u00e9demment dans cet article, nous avons combin\u00e9 les instructions Docker ENTRYPOINT et CMD pour pouvoir ex\u00e9cuter toutes les commandes Maven dans ce conteneur facilement:<\/p>\n
docker run ... -e ******** exoplatform\/ci:jdk8-maven33 clean package<\/pre>\n
Et nous ajoutons \u00e9galement un script personnalis\u00e9, pour pouvoir ex\u00e9cuter la commande cat et d’autres commandes que Maven en donnant le chemin d\u2019acc\u00e8s absolu \u00e0 la commande:<\/p>\n
docker run exoplatform\/ci:jdk8-maven33 \/bin\/echo hello<\/pre>\n
Enfin, vous avez peut-\u00eatre remarqu\u00e9 que nous avons d\u00e9clar\u00e9 les variables d’environnement M2_REPO<\/strong> et MAVEN_OPTS<\/strong> sous forme d\u2019instructions Docker ENV<\/strong> avec des valeurs par d\u00e9faut pour tous les param\u00e8tres importants. Elles peuvent \u00eatre surcharg\u00e9es via l’option -e<\/i> dans la commande de d\u00e9marrage de docker.<\/p>\n
Tester ses Images Docker<\/h4>\n
Comme pour tout autre type de code source, il est possible de cr\u00e9er des suites de tests pour ses images Docker et Dockerfiles. Pour les images Docker eXo CI, nous utilisons Goss<\/a><\/strong> \u00e0 travers son wrapper dgoss<\/a><\/strong>.<\/p>\n
- \n
- Goss<\/strong> est un outil, bas\u00e9 sur YAML, pour valider la configuration d’un serveur<\/li>\n
- dgoss<\/strong> est une enveloppe autour de Goss qui vise \u00e0 apporter la simplicit\u00e9 de Goss aux conteneurs Docker.<\/li>\n<\/ul>\n
La premi\u00e8re \u00e9tape consiste \u00e0 cr\u00e9er un fichier YAML pour d\u00e9crire ce que vous souhaitez tester dans votre conteneur Docker. Il existe des exemples en ligne<\/a> <\/strong>qui peuvent aider \u00e0 cr\u00e9er ce fichier de configuration, mais cela peut \u00e9galement \u00eatre g\u00e9n\u00e9r\u00e9 par la ligne de commande de goss.<\/p>\n
Par exemple, nous voulons v\u00e9rifier que certains fichiers de configuration Maven existent dans le conteneur. Nous voulons \u00e9galement \u00eatre s\u00fbr que la commande mvn –version<\/i><\/strong> est conforme aux versions Maven et JDK install\u00e9es dans le container.<\/p>\n
goss.yaml<\/i><\/p>\n
file:\n\/home\/ciagent\/.m2\/repository:\ntitle: Validating the presence Maven repository folder\nexists: true\n\/home\/ciagent\/.m2\/settings.xml:\ntitle: Validating the absence of eXo USER settings file\nexists: false\n\/usr\/share\/maven\/conf\/settings.xml:\ntitle: Validating the presence of eXo GLOBAL settings file\nexists: true\npackage:\ngit:\ninstalled: true\ntitle: Check that git is installed\ncommand:\nmvn --version:\nexit-status: 0\nstdout:\n- 3.3.9\n- 1.8.0\n- \"Default locale: en_US, platform encoding: UTF-8\"\nstderr: []\ntimeout: 0<\/pre>\n
Ensuite, pour ex\u00e9cuter ces tests, il suffit simplement d’ex\u00e9cuter une ligne de commande via dgoss<\/strong>:<\/p>\n
dgoss run -it exoplatform\/ci:jdk8-maven33 cat<\/pre>\n
<\/p>\n
![\"Code\"](\"https:\/\/www.exoplatform.com\/blog\/wp-content\/uploads\/2017\/05\/Code.png\")
<\/a>Conclusion<\/h3>\nSi vous \u00eates int\u00e9ress\u00e9s pour tester ou utiliser ces images Docker:<\/p>\n
- \n
- tous les Dockerfiles<\/strong> sont disponibles dans le projet GitHub d\u00e9di\u00e9 exo-docker\/exo-ci<\/a><\/strong><\/li>\n
- les images Docker<\/strong> peuvent \u00eatre t\u00e9l\u00e9charg\u00e9es \u00e0 partir de l\u2019organisation eXo sur le DockerHub<\/a><\/strong><\/li>\n<\/ul>\n
N’h\u00e9sitez pas \u00e0 nous faire part de vos commentaires ou \u00e0 proposer vos id\u00e9es.<\/p>\n
Prochaine \u00e9tape<\/h3>\n
Maintenant que nous avons cr\u00e9\u00e9 nos propres Images Docker pour toutes nos environnements de build de l’int\u00e9gration continue, nous vous expliquerons dans le prochain article (Partie 2), comment utiliser ces images dans un environnement de d\u00e9veloppement local quel que soit votre syst\u00e8me d’exploitation.
\nD\u00e9couvrez comment eXo Platform peut vous aider \u00e0 transformer votre entreprise!<\/a><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"Part1: Cr\u00e9er ses propres images Docker pour Jenkins Il y a un an, chez eXo, nous avons pris la d\u00e9cision de construire tous nos projets dans des conteneurs Docker.","protected":false},"author":69,"featured_media":13012,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"image","meta":[],"categories":[],"tags":[606,850],"lang":"fr","translations":{"fr":12998},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts\/12998"}],"collection":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/users\/69"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/comments?post=12998"}],"version-history":[{"count":0,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/posts\/12998\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/media\/13012"}],"wp:attachment":[{"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/media?parent=12998"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/categories?post=12998"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exoplatform.com\/blog\/wp-json\/wp\/v2\/tags?post=12998"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} - les images Docker<\/strong> peuvent \u00eatre t\u00e9l\u00e9charg\u00e9es \u00e0 partir de l\u2019organisation eXo sur le DockerHub<\/a><\/strong><\/li>\n<\/ul>\n
- dgoss<\/strong> est une enveloppe autour de Goss qui vise \u00e0 apporter la simplicit\u00e9 de Goss aux conteneurs Docker.<\/li>\n<\/ul>\n
- Goss<\/strong> est un outil, bas\u00e9 sur YAML, pour valider la configuration d’un serveur<\/li>\n
- feature\/xxx<\/strong> : branches d\u00e9di\u00e9es aux nouvelles fonctionnalit\u00e9s majeures (de nombreux commits), “xxx” correspond au nom de la fonctionnalit\u00e9.<\/li>\n
- develop<\/strong> : branche qui contient les derniers d\u00e9veloppements valid\u00e9s<\/li>\n
- 25+ composants \u00e0 construire\n