Je suis assez nouveau sur Docker et les outils de gestion de configuration.
Au début, j'ai commencé à écrire des scripts bash pour provisionner mes boîtes Vagrant pour mes machines de développement, mais maintenant je suis passé à l'utilisation de Chef pour cela afin de pouvoir utiliser la même source pour provisionner les environnements de développement et de production pour essayer de les obtenir comme similaires que possible.
Depuis que j'ai commencé à utiliser Chef, j'apprécie l'aspect SECHE de ne pas avoir à copier et coller des lignes de script shell d'un projet à l'autre, la possibilité de provisionner des machines exécutant une variété de distributions Linux en utilisant une seule source consolidée et la commodité d'utiliser des livres de cuisine fournis par la communauté.
Maintenant que j'utilise Chef pour provisionner mes vm, j'ai l'impression de faire un pas en arrière lorsque j'ajoute des commandes RUN suivies de commandes shell à un Dockerfile pour réaliser ce qui pourrait être réalisé en exécutant simplement une recette Chef.
J'ai googlé et je n'ai rien trouvé (mais peut-être que je l'ai raté), mais il ne semble pas qu'il existe un moyen facile d'utiliser des recettes Chef pour créer des conteneurs Docker. Pourquoi donc?
Je comprends que les conteneurs sont censés être immuables et que les outils de gestion de la configuration sont couramment utilisés pour reconfigurer les machines pendant toute leur durée de vie, mais n'offriraient-ils pas encore de nombreux avantages s'ils étaient utilisés lors de la construction initiale du conteneur?
la source
Réponses:
L'outil dont vous avez besoin est Packer utilisant Docker comme "constructeur" et Chef comme "approvisionneur". Ensuite, vous pouvez ajouter l'image résultante à votre référentiel et la réutiliser sans avoir à emballer à nouveau, jusqu'à ce que vos recettes changent.
la source
Ces stratégies n'ont rien à voir les unes avec les autres.
Les conteneurs (comme Docker) sont une méthodologie pour déployer et isoler des applications. Les conteneurs sont très appréciés car ils sont transportables. Ils peuvent être développés et prévisualisés localement dans la plupart des cas, il est donc logique d'y mettre des applications.
Quant à savoir pourquoi Docker utilise les scripts shell : une image Docker est littéralement une image de conteneur Linux. C'est un système d'exploitation Linux et le but de ce conteneur est d'être aussi léger et efficace que possible. Si vous avez commencé à ajouter Chef, Ruby, Erlang et toutes les autres bibliothèques requises pour avoir Chef en tant que provisionneur sur un Dockerfile, vous élimineriez le point d'utiliser des conteneurs.
La gestion de la configuration permet de provisionner un nœud de calcul. Votre état final de configuration est généralement reflété dans le code et dispose d'un serveur central pour maintenir l'état. Des outils comme vagrant vous permettent d'utiliser chef pour configurer les machines Vagrant, en grande partie par commodité pour les développeurs. Bien que vous puissiez utiliser la plupart de ces outils en mode local uniquement , leur maintenance devient assez lourde. Ces serveurs centraux servent à des choses comme le tri automatique des versions et la gestion des dépendances.
Bash n'est pas intrinsèquement un pas en arrière. Par exemple, de nombreuses organisations construisant des pipelines d'images entièrement immuables construisent leurs images à l'aide de Bash. Cela garantit la stabilité et la prévisibilité ainsi qu'un langage commun parmi les ingénieurs (de nombreux ingénieurs peuvent provenir de différents horizons de gestion de configuration).
Gestion immuable vs config . L'infrastructure immuable ne change pas et doit être entièrement remplacée pour être mise à jour. La gestion de la configuration implique que l'état d'une machine est maintenu par un agent ou une connexion étrangère (comme avec Ansible).
Les conteneurs Docker sont intrinsèquement immuables. Vous ne persistez pas les données sur eux et ils doivent être roulés pour être mis à jour.
la source