Y a-t-il une raison d'utiliser Puppet avec Docker?


16

J'ai essayé Ops partie de DevOps il y a quelque temps et c'était assez amusant, mais je n'ai pas le temps et la raison de l'essayer dans aucun projet. Mais la semaine dernière, j'ai commencé un nouveau travail, où le patron m'a demandé si je pouvais configurer le serveur pour créer quelque chose comme un environnement de transfert pour les projets de l'entreprise. Parallèlement à cela, j'ai commencé à penser au projet de migration pour être plus DevOps plutôt que seulement dev.

Je suis sorti avec Docker qui est génial et super facile pour moi. Mais il y a quelque temps, j'essayais Puppet, alors la question m'est venue à l'esprit: "Y a-t-il une raison d'utiliser Puppet avec Docker?". Docker semble faire tout ce que Puppet ferait, mais de manière plus simple.

PS Il y a quelque temps sur Hacker News, il y avait Consul qui est une belle configuration et découverte de service, donc même la configuration peut être résolue (et je pense à l'implémenter aussi).

Réponses:


18

Puppet et docker peuvent faire plusieurs des mêmes choses, mais ils les abordent différemment.

Puppet gère les fichiers + packages + services. (Appelé le trifecta). Docker encapsule les fichiers binaires et les fichiers de configuration à l'intérieur d'un conteneur.

Au moment d'écrire ces lignes, le docker est toujours instable et ne devrait pas être utilisé en production. De nombreuses API sont susceptibles d'être modifiées jusqu'à la sortie de la version 1.0.

Même lorsque Docker devient stable, il sera très difficile de convertir chaque processus et fichier de configuration en conteneurs Docker.

La marionnette par contre est un produit stable et est livré avec tout un écosystème d'outils (heira, mcollective, facter, razor). Ces outils peuvent être mis en œuvre rapidement et sans souci de rupture.

Je suggère fortement les ressources suivantes.

Une vidéo expliquant comment gérer les piles d'applications avec une marionnette
https://www.youtube.com/watch?v=KSo_mcJxFIA

Un podcast sur la façon dont docker et marionnette peuvent travailler ensemble
http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html

Un article de blog de marionnettes sur la façon de s'intégrer à Docker
http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker

Un autre article de blog sur les marionnettes et les dockers coexistant
http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist

Un module marionnette pour interagir avec docker
http://docs.docker.io/use/puppet/

Une correction mineure sur la terminologie des devops. Devops est plus une méthodologie de développement logiciel où les développeurs et les opérations coopèrent que n'importe quel outil spécifique.

Mise à jour

Actuellement, mon entreprise utilise à la fois des marionnettes et des dockers. Voici une excellente présentation donnée lors de la conférence de marionnettes 2014 sur les raisons pour lesquelles vous utiliseriez puppet vs docker. Donné par James Turnbull, un ancien employeur de puppetlabs et l'auteur du livre docker.

https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter

Aussi un bon court tutoriel vidéo sur docker donné par sysadmincasts.com

https://sysadmincasts.com/episodes/31-introduction-to-docker

Docker Pros:

  • Peut tourner rapidement l'instance
  • Plus facile à apprendre que la marionnette
  • Facile à faire 0 temps d'arrêt

Docker Inconvénients:

  • Les conteneurs ont une limite de 10 Go lors de l'utilisation du backend devicemapper
  • Les petites modifications de configuration prennent beaucoup de temps pour reconstruire le conteneur
  • Coûte de l'argent pour utiliser un registre docker comme hub.docker.com, quay.io (Le registre docker auto-hébergé est extrêmement bogué et n'a pas de GUI)
  • Aucun système d'initialisation approprié. Certaines applications ne fonctionnent pas bien.
  • Pas de contrôle fin sur le réseau
  • Les applications qui nécessitent des sous-coques (en regardant votre RVM + rubis) sont très difficiles à faire fonctionner correctement
  • Impossible de gérer les hôtes Windows, pas de SLES ou d'autres systèmes d'exploitation moins populaires
  • Actuellement, l'orchestration des dockers est très jeune.
  • Impossible actuellement de définir votre /etc/resolv.conf au moment de la construction
  • Divers bogues que nous devons monter / etc / localtime et / dev / urandom pour mapper aux répertoires localtime et urandom de l'hôte.
  • Les performances ne sont pas aussi rapides (malgré toutes les affirmations selon lesquelles le docker devrait être 99% plus rapide que le métal nu, il est parfois 30% plus lent que les autres machines).
  • Les petits conteneurs ont encore des centaines de mégaoctets de surcharge. Nos conteneurs sont tous de plusieurs gigaoctets.

Puppet Pros:

  • Facile à évoluer
  • Fonctionne avec les serveurs existants (windows, linux, sles)
  • Rapide pour faire de petits changements
  • Forte communauté d'autres utilisateurs et modules de marionnettes
  • API standardisée pour l'installation de packages sur toutes les plateformes

Inconvénients des marionnettes:

  • Les grandes infrastructures deviennent très complexes
  • Les dépendances de module conditionnelles créent du code spagetti
  • Poids plus lourd

Actuellement, nous utilisons des marionnettes pour approvisionner nos conteneurs de docker. Les conteneurs Docker sont utilisés pour les builds jenkins et sont détruits après chaque build. Cela fonctionne bien et nous donne un environnement cohérent. Cela signifie que nous ne devons écrire le code qu'une seule fois, puis reconstruire les machines ubuntu, sles et centos. La reconstruction des conteneurs prend environ 15 à 30 minutes et est toujours un processus manuel. Docker est idéal pour faire tourner des vm de test rapide,

Bref, la marionnette est excellente pour gérer votre infrastructure existante. Docker est bon si vous avez un greenfield 100% linux avec une pile technologique qui peut être enfermée dans de petites instances éphémères. Bien que certaines fonctionnalités se chevauchent, elles ne s'excluent pas mutuellement.


5
J'ai trouvé cette réponse subjective et spéculative. Je ne crois pas que cela réponde vraiment à la raison pour laquelle on pourrait continuer à utiliser Puppet avec / conjointement avec Docker, alors que Docker apparaît, à un niveau élevé, comme un outil plus simple dans le même but.
8bitjunkie

1
@ 7SpecialGems Mis à jour avec plus de faits.
spuder

1
ce serait formidable de voir une revue de cette réponse dans le monde 2015 et comment les choses ont changé
Oliver Bayes-Shelton

La question / réponse est-elle toujours relative en 2019? Qu'est-ce qui aurait pu changer?
Md. Abu Taher

2

Docker vous aide à approvisionner et à configurer initialement les conteneurs, mais il exécute des commandes uniques lors de l'initialisation du conteneur.

Puppet est plus puissant lorsque vous l'exécutez en tant que démon, il garantit que votre configuration reste telle que vous la spécifiez, donc par exemple si votre service s'arrête, il le redémarrera.

L'une des meilleures choses à propos des manifestes de configuration de marionnettes (correctement conçus) est qu'ils sont idempotents ; il est censé décrire l'état dans lequel vous voulez être et pas nécessairement les étapes pour y arriver.

Il vous permet également d'abstraire et de paramétrer des configurations et vous pouvez exporter des paramètres créés sur un serveur ou un conteneur et les utiliser dans un autre (par exemple en collectant une liste de noms d'hôte de nœuds pour une application de surveillance).

Je dirais qu'ils servent certainement des objectifs différents mais liés. J'essaie actuellement d'utiliser des manifestes de marionnettes existants pour commencer à configurer des conteneurs afin que les environnements de développement ressemblent davantage aux environnements de production.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.