­Déboguer un conteneur « nu »

Spécialité(s)


Résumé
L’une des difficultés associées au conteneur Docker en production est la difficulté d’analyse des incidents. En effet, déterminer la cause d’un incident requiert l’utilisation de nombreux outils qui sont rarement installés sur des images Docker puisque l’on tend à vouloir conserver une taille d'image aussi minimale que possible. Néanmoins, comme nous allons l’illustrer dans cet article, ceci n’est pas une fatalité ! Il est tout à fait possible d’analyser un conteneur défaillant sans pour autant devoir installer les outils nécessaires sur ce dernier.


Avec l’arrivée des conteneurs Docker, l’industrie s'est à nouveau tournée vers l'option qu'elle avait délaissée au fil des années, celle de déployer des instances... au profit d'images standards, complètes, multifonctions. Mais aujourd’hui, de manière générale, les bonnes pratiques de l’industrie, comme les technologies à base de conteneurs, vont toutes dans cette direction visant à réduire au strict minimum la taille du système déployé.

Un parfait exemple de cette tendance est certainement l’effort fait, dans le monde Java, pour réduire la taille de sa machine virtuelle. L’objectif avoué ici est d’offrir une meilleure intégration avec le monde Docker, très friand de conteneurs légers. Quelques autres technologies, telles le langage Go [1], vont encore un cran plus loin en se passant même de la fameuse glibc et en ne nécessitant rien d’autre que le binaire lui-même !

Néanmoins, une fois l’image déployée en production, on peut se retrouver...

Cet article est réservé aux abonnés. Il vous reste 96% à découvrir.
S'abonner à Connect
  • Accédez à tous les contenus de Connect en illimité
  • Découvrez des listes de lecture et des contenus Premium
  • Consultez les nouveaux articles en avant-première
Je m'abonne


Article rédigé par

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous