I. Analyse syntaxique du format JSON avec Bash▲
Une fois qu'une application est liée à un conteneur, ce dernier a accès aux données de connexion du service au format JSON. Il suffit de les analyser. De nombreuses images Docker existantes utilisent des variables d'environnement pour se lier à des services externes, comme des bases de données. Un excellent exemple de cela est l'image officielle WordPress de Docker. L'image WordPress lit un ensemble spécifique de variables d'environnement pour établir une connexion à une base de données MySQL. L'image WordPress ne sait pas du tout ce que sont les VCAP_SERVICES, nous devons donc trouver un moyen propre d'analyser le VCAP_SERVICE JSON et exporter des informations d'identification en tant que variables d'environnement que WordPress peut comprendre. Si votre conteneur possède un langage de script comme Node.js ou Python, vous pouvez écrire des scripts à l'aide de bibliothèques d'analyse JSON préexistantes et exporter les données analysées. Cependant, nous voulons une solution qui puisse fonctionner même avec les images les plus légères, avec peu ou pas de dépendances. Ainsi, nous pouvons réutiliser ce modèle sur chaque image. Pour cette raison, nous le ferons tout en utilisant les commandes Bash et les scripts shell. L'analyse JSON avec Bash n'étant pas facile, nous utiliserons un script appelé JSON.sh. Ce script prend une chaîne JSON en entrée et l'ajoute à un format beaucoup plus facile à analyser à l'aide de grep.
Voici un exemple de ce que JSON.sh peut faire :
Compte tenu des VCAP_SERVICES suivants :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
{
"cleardb": [
{
"credentials": {
"username": "b079b14027e178",
"name": "ad_72f5612734efca1",
"hostname": "us-cdbr-iron-east-02.cleardb.net",
"password": "6550057f",
"port": "3306"
},
"plan": "spark",
"name": "ClearDB MySQL Database-sj",
"label": "cleardb"
}
]
}
Nous pouvons charger la variable $VCAP_SERVICES avec un pipe dans le script JSON.sh comme suit (l'indicateur -b ne montre que les nœuds feuilles (leaf nodes)) :
2.
3.
4.
5.
6.
7.
8.
9.
~ echo $VCAP_SERVICES | JSON.sh -b
["cleardb",0,"credentials","username"] "b079b14027e178"
["cleardb",0,"credentials","name"] "ad_72f5612734efca1"
["cleardb",0,"credentials","hostname"] "us-cdbr-iron-east-02.cleardb.net"
["cleardb",0,"credentials","password"] "6550057f"
["cleardb",0,"credentials","port"] "3306"
["cleardb",0,"plan"] "spark"
["cleardb",0,"name"] "ClearDB MySQL Database-sj"
["cleardb",0,"label"] "cleardb"
Dans ce format, obtenir les données souhaitées est facile avec une commande grep. Supposons que nous voulions obtenir les informations relatives au nom ClearDB. Nous exécutons la commande grep comme ceci :
2.
~ echo $VCAP_SERVICES | JSON.sh -b | grep cleardb\",0,\"credentials\",\"name
["cleardb",0,"credentials","name"] "ad_72f5612734efca1"
Nous utilisons ensuite sed pour supprimer l'entête du fichier JSON.sh :
2.
~ echo $VCAP_SERVICES | JSON.sh -b | grep cleardb\",0,\"credentials\",\"name | sed "s/^\[.*\].//"
"ad_72f5612734efca1"
Il suffit enfin de vous débarrasser de ces guillemets en utilisant tr :
2.
~ echo $VCAP_SERVICES | JSON.sh -b | grep cleardb\",0,\"credentials\",\"name | sed "s/^\[.*\].//" | tr -d '"'
ad_72f5612734efca1
Pour rendre tout ce processus beaucoup plus simple, j'ai écrit un petit script (vcap_parse.sh) qui intègre le «chemin» à la variable souhaitée comme entrée et retourne la valeur de la variable. Vous pouvez trouver le code ici
2.
adapterSH ./vcap_parse.sh cleardb 0 credentials name
ad_72f5612734efca1
Notez la façon dont nous avons atteint cette valeur à cleardb[0].credentials.name.
./vcap_parse.sh cleardb 0 credentials name.II. Export des données analysées▲
En utilisant ce script et votre connaissance de la structure des VCAP_SERVICES, vous pouvez analyser rapidement celles que vous voulez. Maintenant, il ne reste plus qu'à les exporter en tant que variables d'environnement afin que l'image Docker puisse les voir et les utiliser.
Dans l'exemple WordPress, nous devons exporter les valeurs suivantes :
- WORDPRESS_DB_HOST ;
- WORDPRESS_DB_USER ;
- WORDPRESS_DB_PASSWORD ;
- WORDPRESS_DB_NAME.
Nous avons toutes les valeurs nécessaires dans le VCAP_SERVICES JSON vu plus haut, et avec le script vcap_parse.sh, l'exportation sera triviale.
L'exportation des informations d'identification de la base de données, dans l'exemple de WordPress, se fait dans un script appelé vcap_export.sh. vcap_export.sh appelle vcap_parse.sh quatre fois et exporte chaque résultat comme une variable d'environnement spécifiée par l'image WordPress . Si vous voulez configurer une connexion pour quelque chose d'autre, comme un conteneur Drupal, vous devez remplacer les noms des variables d'export par les noms spécifiés dans les documents de l'image Drupal.
Voici le contenu de vcap_export.sh :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
#!/bin/bash
# exporte les informations d'authentification de la base de données comme variables d'environnement
export WORDPRESS_DB_USER=$(/vcap_parse.sh cleardb 0 credentials username)
export WORDPRESS_DB_PASSWORD=$(/vcap_parse.sh cleardb 0 credentials password)
export WORDPRESS_DB_HOST=$(/vcap_parse.sh cleardb 0 credentials hostname):3306
export WORDPRESS_DB_NAME=$(/vcap_parse.sh cleardb 0 credentials name)
# répare le point d'entree que nous avons remplacé plus tôt (de la fin de wordpress:latest)
/entrypoint.sh
apache2-foreground
(Remarque : la ligne de la variable sur l'hôte se termine par le numéro du port « : 3306 », comme requis par l'image WordPress.)
J'expliquerai plus en détail ce que font les deux dernières lignes de vcap_export.sh à la fin de la prochaine section. Pour l'instant, sachez que toutes les variables sont définies et WordPress peut communiquer avec l'instance clearDB (si vous souhaitez utiliser une base de données MySQL autre que clearDB, vous devrez modifier vcap_export.sh pour analyser les informations d'authentification correctes, cet exemple utilisant des variables spécifiques à clearDB).
III. Mettre le tout ensemble▲
Nous savons maintenant comment analyser et exporter, il suffit d'ajouter ce flux de travail dans le fichier Docker de notre image afin que les services soient analysés et exportés avant que notre image ne démarre. Au lieu de charger et modifier l'image de base existante, nous pouvons utiliser la commande Dockerfile FROM pour ajouter ce processus d'analyse et d'export comme une couche au-dessus de l'image originale de WordPress non modifiée.
Voici le Dockerfile que j'ai créé pour l'exemple de WordPress :
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
FROM wordpress:latest
# Utilitaire d'analyse JSON (shell) - écrit dans /usr/local/bin/JSON.sh
ADD https://raw.githubusercontent.com/dominictarr/JSON.sh/master/JSON.sh /usr/local/bin/JSON.sh
RUN chmod u+x /usr/local/bin/JSON.sh
# Utiliser JSON.sh pour analyser et retourner VCAP_SERVICES
COPY vcap_parse.sh /vcap_parse.sh
RUN chmod u+x /vcap_parse.sh
# Utiliser vcap_parse.sh pour exporter les données d'identification de la base dedonnées
COPY vcap_export.sh /vcap_export.sh
RUN chmod u+x /vcap_export.sh
# Remplacer le Entrypoint de Wordpress:latest
ENTRYPOINT ["/vcap_export.sh"]
Expliquons ce code. La commande FROM indique le processus de construction qui débute avec l'image wordpress:lastest et l'ajoute à partir de là. La ligne suivante télécharge le script JSON.sh de github et l'enregistre dans /usr/local/bin/JSON.sh à l'aide de la commande ADD. JSON.sh a besoin d'un chmod u + x pour être exécuté, alors c'est ce que fait la troisième ligne. Les deux lignes suivantes copient le script vcap_parse.sh et l'enregistrent dans la racine du conteneur, suivi d'un autre chmod u + x. Les deux lignes suivantes font exactement la même chose, mais pour le script vcap_export.sh.
La dernière ligne remplace le ENTRYPOINT défini par l'image WordPress pour utiliser /vcap_export.sh comme nouveau ENTRYPOINT. Nous devons le faire de sorte que l'exportation des données d'identification de la base de données se produise avant que WordPress ne démarre. Nous devrons finalement appeler le point d'entrée que nous avons outrepassé. Cela se fait à la fin de vcap_export.sh. C'est ce que font ces lignes :
2.
3.
# Réparez le point d'entrée que nous avons remplacé plus tôt (à la fin de wordpress:lastest)
/entrypoint.sh
apache2-foreground
Ceci n'est pas nécessaire pour chaque image, mais vous devrez probablement remplacer un endpoint pour la plupart des images. Maintenant, l'image WordPress sera exécutée comme si rien ne changeait et pourra obtenir des données de connexion à partir des variables d'environnement provenant de la liaison d'une application à votre conteneur. N'oubliez pas de toujours appeler les points d'entrée que vous avez remplacés, ils peuvent être trouvés à la fin de votre image de base.
IV. Résumé des étapes▲
- Créer Dockerfile avec un
FROM<nom de l′image souhaitée>. - Ajouter le script JSON.sh et lancer chmod u + x sur celui-ci.
- Copier vcap_parse.sh et vcap_export.sh pour root et exécuter chmod u + x sur les deux.
- Remplacer le <Nom de l'image souhaité> ENTRYPOINT pour appeler vcap_export.sh.
- Suivre le modèle dans vcap_export.sh pour exporter les variables que l'image requiert.
- S'assurer d'appeler le ENTRYPOINT que vous avez remplacé et les commandes qui se trouvent à sa suite.
Une fois que vous avez tout configuré à l'aide de ce modèle, vous pouvez construire l'image, l'étiqueter, la mettre dans votre registre Bluemix et la déployer à partir de Bluemix. Assurez-vous de lier une application qui possède les services nécessaires à votre image de conteneur, sinon l'exportation échouera.
Rappelez-vous que nous avons utilisé un exemple pour connecter ClearDB à WordPress, mais cette technique peut être modifiée et utilisée pour lier n'importe quel service Bluemix (pas seulement DB) à n'importe quelle image Docker qui lit dans les variables via des variables d'environnement.
Les codes sources utilisés pour cette image sont disponibles. Et l'image exemple du WordPress est hébergée sur dockerhub.
Vous pouvez tester, dès à présent, ces fonctionnalités en commençant par créer un compte gratuitement sur Bluemix.