The Doppler Quarterly (FRANÇAIS) L'automne 2017 | Page 48

plus et plus souvent à la recherche d’OPC (code d’autres personnes), ce qui rend leur
travail beaucoup plus productif. Toutefois, cela crée un défi en termes de cycle de
vie du conteneur, dans la mesure où le nombre de dépendances dont vous effectuez
le suivi est limité.
Et il s’agit ici clairement d’un problème à résoudre. Si, à une étape donnée, le dével-
oppeur a besoin de rechercher et d’exploiter des images de conteneurs préassem-
blées, il doit savoir où les stocker et comment y accéder afi n de simplifi er le travail
de suivi qui s’impose.
Pour stocker une copie de l’image de base en cours d’exploitation, ainsi que vos
extensions de cette image, vous pouvez faire appel à un référentiel privé. L’avantage
est que vous pouvez alors conserver un exemplaire original de l’image dont votre
version personnalisée est dérivée. De plus, vous pouvez enregistrer cette dernière
dans ce même référentiel privé.
Sachez toutefois que si cette méthode vous protège contre les modifi cations de
l’image publique dont vous dépendez désormais (lesquelles pourraient rendre
inopérante l’application que vous développez à l’aide de conteneurs), vous ne pou-
vez plus bénéfi cier des mises à jour et des correctifs de bugs dans l’image
d’origine.
La solution consiste alors à utiliser un système de gestion des confi gurations
prenant en charge les conteneurs. Bien qu’il soit possible d’adapter les outils tradi-
tionnels à la gestion des images de conteneurs, ceux-ci pâtissent de certaines lim-
ites. Pour l’heure, la meilleure pratique consiste à collaborer avec votre actuel
prestataire de gestion de la confi guration, afi n de comprendre comment exploiter
gérer vos applications à base de conteneurs à l’aide des outils existants. Mais d’ici
un an ou deux, tenez-vous prêt à vous mettre en quête de meilleurs outils que ceux
de votre pool de fournisseurs DevOps existants.
Test de conteneurs
Il existe de nombreuses approches pour pratiquer des tests sur les conteneurs.
Dans tous les cas, il importe de se souvenir que l’automatisation de vos batteries de
tests constitue la clé de voûte de cette activité.
Avec les conteneurs, vous pouvez décider de positionner l’automatisation des tests
à l’intérieur ou à l’extérieur du processus. Pour cela, il convient de mettre en place
des environnements de test reproductibles dans lesquels le même test pourra être
exécuté au moyen des mêmes outils de test d’automatisation. Le test doit donc être
envisagé comme faisant entièrement partie des outils d’intégration en continu, de
transfert et de déploiement. De cette manière, les tests sont systémiques entre le
moment où un développeur est prêt à les lancer et la phase de passage en
production.
L’approche qui consiste à tester la partie interne des conteneurs implique que les
outils de test fassent partie intégrante de l’image. Dans ce cas, leur confi guration a
lieu automatiquement.
Avec l’approche externe, en revanche, vous pouvez créer des conteneurs de test
d’intégration spéciaux qui contiendront uniquement des outils et des artefacts de
mise à l’essai, tels que les scripts, données et paramètres de confi guration de l’en-
vironnement de test. Bien qu’il s’agisse par essence de conteneurs, ils ne feront pas
partie intégrante de l’image du conteneur en production, ce qui fait qu’ils n’auront
aucune incidence sur la taille ou les performances de cette image. En revanche, ils
ne sont pas autoconfi gurés, et doivent donc être paramétrés en fonction des tâches
46 | THE DOPPLER | AUTOMNE 2017