Quand provisionner dans Packer vs Terraform?
Je suis assis avec une situation où j'ai besoin de provisionner des instances EC2 avec des packages au démarrage. Il existe quelques contraintes (entreprise/entreprise):
- J'ai besoin de provisionner au-dessus d'une AMI spécifique, qui ajoute des éléments d'entreprise tels que l'accès LDAP/AD, etc.
- Ces modifications sont destinées à être utilisées pour toutes les machines de développement internes
En raison principalement de la deuxième contrainte, je me demandais quel était le meilleur endroit pour placer l'approvisionnement. C'est ce que j'ai trouvé
Provision dans Terraform
Comme il est indiqué, je prévois simplement en terraform les cas nécessaires. Si je regroupe ces ressources dans des modules, le provisionnement ne "s'échappera" pas. Les désavantages
- Je ne pourrai pas ajouter un ensemble différent d'étapes de provisioning au-dessus du module?
- Un changement dans l'approvisionnement entraînera probablement la destruction d'instances lors de l'application?
- Le provisionnement prend beaucoup de temps en raison des packages qu'il essaie d'installer
Provisioning dans Packer
Ceci est basé sur le hypothèse que Packer vous permet de provisionner au-dessus des AMI afin que les AMI puissent être "étendues". En outre, cela ne sera utilisé que dans AWS, il n'utilisera donc pas nécessairement d'autres constructeurs. L'approvisionnement dans Packer rend le code Terraform beaucoup plus simple et l'application de terraform deviendra plus rapide car ce n'est qu'une AMI que vous lancez.
Pour moi, ces deux méthodes ont leur place. Mais ce que je veux vraiment savoir, c'est quand choisissez-vous Packer Provisioning plutôt que Terraform Provisioning?
L'utilisation de Packer pour créer des images finies (ou presque terminées) raccourcit considérablement le temps nécessaire au déploiement de nouvelles instances et vous permet également d'utiliser des groupes de mise à l'échelle automatique.
Si Terraform exécute un provisionneur tel que Chef ou Ansible à chaque création d'instance EC2, vous ajoutez un laps de temps pour que le provisionneur s'exécute au moment où vous devez déployer de nouvelles instances. À mon avis, il est préférable de faire la configuration à l'avance et à l'avance à l'aide de Packer pour cuire autant que possible dans l'AMI, puis utiliser des scripts/outils de données utilisateur comme Consul-Template pour fournir un environnement spécifique différences.
Packer peut certainement s'appuyer sur des images et nécessite en fait un source_AMI à préciser. Je recommande fortement de baliser vos AMI d'une manière qui vous permette d'utiliser source_AMI_filter dans Packer et Terraform aws_AMI source de données donc lorsque vous apportez des modifications à votre AMI Packer, Terraform les récupérera automatiquement pour les construire ou les déployer à la prochaine opportunité.
Personnellement, je prépare une AMI "de base" raisonnablement légère qui effectue un durcissement de base et configure la surveillance et la journalisation que je veux pour toutes les instances qui sont déployées et s'assure également que Packer chiffre le volume racine de l'AMI. Toutes les autres images sont ensuite construites à partir de la dernière AMI "de base" et n'ont pas à se soucier de s'assurer que ces choses sont installées/configurées ou de chiffrer le volume racine.
En intégrant votre configuration dans l'AMI, vous pouvez également évoluer vers le modèle d'infrastructure immuable qui présente des avantages majeurs dans la mesure où vous savez que vous pouvez toujours supprimer une instance qui rencontre des problèmes et la remplacer très rapidement par une nouvelle. Selon votre niveau de maturité, vous pouvez même supprimer l'accès aux instances afin qu'il ne soit plus possible de modifier quoi que ce soit sur l'instance une fois qu'elle a été déployée, ce qui, selon mon expérience, est un facteur majeur des problèmes opérationnels.
Très occasionnellement, vous pouvez rencontrer quelque chose qui rend très difficile la création d'une AMI et dans ces cas, vous pouvez choisir d'exécuter vos scripts de provisioning dans un provisionneur Terraform lors de sa création. Parfois, il est tout simplement plus facile de déplacer un processus existant vers l'utilisation de provisioners avec Terraform que de créer les AMI, mais je pousserais à déplacer les choses vers Packer si possible.
J'ai rencontré la même situation. Selon ma compréhension
- Si vous faites apparaître vos instances EC2 très fréquemment, dites 2 à 3 fois par jour, puis créez une AMI personnalisée avec packer, puis appelez l'AMI via terraform.
- Si votre image de base (AMI créée par packer) change fréquemment en fonction de vos besoins, alors c'est bien d'aller avec packer. Mais pour moi, exécuter des scripts de packer prend beaucoup de temps.
- Vous pouvez également faire la même chose avec packer. Vous pouvez écrire vos besoins dans un script et l'appeler en terraform. En intégrant tout dans un script terraform, cela réduirait le temps
Enfin, c'est votre décision et votre fréquence de lancement des instances EC2.