Plop la ML, J'aimerai avoir des retours d'utilisation de Terraform. Si vous avez déjà travaillé avec cet outil quels sont vos retours/points positifs/négatifs ? L'idée c'est que je vais avoir une future application à déployer en multi DC/multi cloud-provider/multi region. Évidemment le but n'est pas de tout faire à la mano pour chaque déploiement. Le but est de se rapprocher du modèle IAC (infra as code) et de faire jouer les stories pour faire poper/provisionner nos modèles d'archi chez les différents providers. Donc dans l'esprit, on terraform pour le deploy et on ansible pour le paramétrage. Faîtes-vous différemment si oui pourquoi ? Merci pour votre temps :-) (je prends tout, docs, vidéos, avis) Bonne semaine à tous ! F00b4rch
Bonjour, Je suis en train de pratiquer un benchmark pour déployer des infrastructures immuables et bien entendu les outils d'hashicorp sont dans le scope. Terraform est un orchestrateur dont l'idée est de faire de l'IAC de façon déclarative. Il faut retenir qu'il prend son intérêt en l'associant avec d'autres outils comme packer et consul, c'est pourquoi la société hashicorp à pivoté et intégré sa solution entreprise s'appelant "Atlas" qui est en fait redevenu terraform de nom. Mais l'idée est de grouper ces services avec quelques fonctionnalités intéressantes qui prennent du temps à si l'on souhaite les établir avec la version open-source. Pour les points négatifs je dirais que la compatibilité n'est pas vraiment ascendante car le projet est encore récent et plein de bonnes idées à développer. Il faut donc bien faire attention à préfixer ses versions pour les plugins et versionner l'ensemble. Le concept tourne autour du stockage d'une configuration locale qu'il devient vite important de déplacer sur un backend, pour cela terraform fournit des backends comme S3 ou consul (cas d'un cloud hybride) A mon avis je ne vois pas vraiment l'intérêt de basculer sur terraform si c'est pour ensuite travailler avec ansible qui peut également faire le travail lui même. Ces outils me semblent intéressant pour de l'infrastructure immuable, entre autre tu peux partir du principe que tu ne souhaites plus accéder à tes instances lorsqu'elles sont déployées. Ce qui simplifies la sécurité dans les VPC et oblige à travailler avec une bonne rigueur du côté de l'IAC. Je travaille également sur une alternative avec kubernetes qui peut sembler plus pérenne mais la contrepartie est l'utilisation de containers et des problématiques de sécurité qui y sont liées. Une VM dans les cloud les plus connus à tout de même un temps de démarrage considérable et c'est souvent également un problème à prendre en compte. Souvent la solution est de démarrer l'instance et de reconnecter les data une fois que cette dernière est prête. J'ai également noté quelques ratages lors de certains déploiements (AWS et compatible Outscale) ce qui oblige à rajouter une couche de contrôle pour déployer à nouveau suivant le type d'erreur. Cordialement, Guillaume Tristani Le 13 février 2018 à 12:31, F00b 4rch <f00b4rch@gmail.com> a écrit :
Plop la ML,
J'aimerai avoir des retours d'utilisation de Terraform. Si vous avez déjà travaillé avec cet outil quels sont vos retours/points positifs/négatifs ?
L'idée c'est que je vais avoir une future application à déployer en multi DC/multi cloud-provider/multi region. Évidemment le but n'est pas de tout faire à la mano pour chaque déploiement.
Le but est de se rapprocher du modèle IAC (infra as code) et de faire jouer les stories pour faire poper/provisionner nos modèles d'archi chez les différents providers.
Donc dans l'esprit, on terraform pour le deploy et on ansible pour le paramétrage.
Faîtes-vous différemment si oui pourquoi ?
Merci pour votre temps :-) (je prends tout, docs, vidéos, avis)
Bonne semaine à tous !
F00b4rch
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello, En complément des réponses de Guillaume, j'ajouterai un retour indirect de mon précédent client qui s'est jeté là dedans à fond la forme. Ce que je retiens, à distance, n'étant pas moi même utilisateur direct : - pour GCP / OVH / AWS / Azure, c'est super cool - pour Azure, c'est limite indispensable tellement la console d'admin est moche / lente / mal faite / pas complète / ..... - le vrai truc chiant c'est la gestion des tfstate que tu peux mettre sur un bucket S3 ou autre. Mais il faut inventer une méthode de travail collaboratif. Terraform ne fait de verrou ..... Dans la même idée, - il faut être rigoureux dans la gestion de tes stacks. Si tu en fait évoluer une en live, ton terraform plan ne verra rien et pourra tout te désinguer si tu ne reportes pas les modifs dans ton code (allez au hasard t'ajoutes des tags parce que tu trouves ça cool, bah terraform te créeras une nouvelle stack. - ça a été dit, attention aux compatibilité binaire / conf : si un mec modifie ta stack avec une version plus récente du client, tu ne pourras peut-être / sûrement pas la reprendre depuis un vieux client terraform (vieux = 15 jours). La aussi, faut être un peu rigoureux et imposer une version de prod, et se garder les versions ultérieures pour les tests avant généralisation - le code de tes stacks doit bien sûr être versionné - il n'y a rien de prévu dans la gestion des identités / tokens tout çà, à toi d'inventer un truc pour sécuriser ton modèle, voire à passer sur du terraform enterprise qui fourni alors une GUI et une IAM. - le code est ouvert, tu peux facilement développer tes plugins pour Foreman, ton logiciel de ticketting préféré ou autre truc du genre : c'est du go, help yourself. Quant à l'infra immutable, il y avait deux conf à ce sujet au cfgmgmtcamp : Une pour dire que c'était trop cool et que LinuxKit ça allait te révolutionner la vie : http://cfgmgmtcamp.eu/schedule/main/MakingImmutableInfrastructuresimplerwith... (mais il me reste encore plein de questions sur ce que fait VRAIMENT linuxkit), suivie d'une autre http://cfgmgmtcamp.eu/schedule/main/ImmutableIsNOTTheAnswerp.html ou Sam nous explique que dans la vraie vie, on fait juste comme on peut : https://twitter.com/gianluca_r/status/960836629702299649 Il y avait une track terraform également : http://cfgmgmtcamp.eu/schedule/index.html Pour ma part, je suis allé voire une prés. de tarraboard. Bah pour résumer, ça met en graphique les json de terraform. C'est joli, mais en vrai, je ne suis pas encore convaincu d'en avoir besoin : https://github.com/camptocamp/terraboard Saine lecture : https://www.amazon.fr/Terraform-Running-Writing-Infrastructure-Code/dp/14919... Bonne soirée, Le mar. 13 févr. 2018 à 16:03, Guillaume <guibdx@gmail.com> a écrit :
Bonjour,
Je suis en train de pratiquer un benchmark pour déployer des infrastructures immuables et bien entendu les outils d'hashicorp sont dans le scope. Terraform est un orchestrateur dont l'idée est de faire de l'IAC de façon déclarative.
Il faut retenir qu'il prend son intérêt en l'associant avec d'autres outils comme packer et consul, c'est pourquoi la société hashicorp à pivoté et intégré sa solution entreprise s'appelant "Atlas" qui est en fait redevenu terraform de nom. Mais l'idée est de grouper ces services avec quelques fonctionnalités intéressantes qui prennent du temps à si l'on souhaite les établir avec la version open-source.
Pour les points négatifs je dirais que la compatibilité n'est pas vraiment ascendante car le projet est encore récent et plein de bonnes idées à développer. Il faut donc bien faire attention à préfixer ses versions pour les plugins et versionner l'ensemble.
Le concept tourne autour du stockage d'une configuration locale qu'il devient vite important de déplacer sur un backend, pour cela terraform fournit des backends comme S3 ou consul (cas d'un cloud hybride)
A mon avis je ne vois pas vraiment l'intérêt de basculer sur terraform si c'est pour ensuite travailler avec ansible qui peut également faire le travail lui même. Ces outils me semblent intéressant pour de l'infrastructure immuable, entre autre tu peux partir du principe que tu ne souhaites plus accéder à tes instances lorsqu'elles sont déployées. Ce qui simplifies la sécurité dans les VPC et oblige à travailler avec une bonne rigueur du côté de l'IAC.
Je travaille également sur une alternative avec kubernetes qui peut sembler plus pérenne mais la contrepartie est l'utilisation de containers et des problématiques de sécurité qui y sont liées.
Une VM dans les cloud les plus connus à tout de même un temps de démarrage considérable et c'est souvent également un problème à prendre en compte. Souvent la solution est de démarrer l'instance et de reconnecter les data une fois que cette dernière est prête.
J'ai également noté quelques ratages lors de certains déploiements (AWS et compatible Outscale) ce qui oblige à rajouter une couche de contrôle pour déployer à nouveau suivant le type d'erreur.
Cordialement, Guillaume Tristani
Le 13 février 2018 à 12:31, F00b 4rch <f00b4rch@gmail.com> a écrit :
Plop la ML,
J'aimerai avoir des retours d'utilisation de Terraform. Si vous avez déjà travaillé avec cet outil quels sont vos retours/points positifs/négatifs ?
L'idée c'est que je vais avoir une future application à déployer en multi DC/multi cloud-provider/multi region. Évidemment le but n'est pas de tout faire à la mano pour chaque déploiement.
Le but est de se rapprocher du modèle IAC (infra as code) et de faire jouer les stories pour faire poper/provisionner nos modèles d'archi chez les différents providers.
Donc dans l'esprit, on terraform pour le deploy et on ansible pour le paramétrage.
Faîtes-vous différemment si oui pourquoi ?
Merci pour votre temps :-) (je prends tout, docs, vidéos, avis)
Bonne semaine à tous !
F00b4rch
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Oliver Duquesne aka DaffyDuke http://www.coincoin.fr.eu.org Excusez les éventuelles erreurs, ce message a été envoyé depuis un mobile.
J'utilise terraform pour déployer chez AWS et OVH, et même si la courbe d'apprentissage est un peu rude au début, c'est un vrai plaisir de l'utiliser au quotidien. Rien que l'abandon de Cloud Formation (pour AWS) et la garantie que la totalité de la stack est redéployable à l'identique en 5 minutes, buckets S3 et services en tout genre d'AWS compris, vaut le coup. À condition que tout le monde joue le jeu et ne passe plus par les consoles pour modifier des paramètres en douce. Mon conseil : faire tourner la validation, la simulation et l'application des stacks depuis la CI / CD du dépôt git sur lequel la configuration est commitée. Ça permet une vraie agilité pour déployer. Chez nous, la simulation est lancée automatiquement, mais l'application de la configuration est faite depuis un bouton de la CI, mais manuellement. On Feb 13, 2018 16:04, "Guillaume" <guibdx@gmail.com> wrote: A mon avis je ne vois pas vraiment l'intérêt de basculer sur terraform si c'est pour ensuite travailler avec ansible qui peut également faire le travail lui même. Ansible a des modules pour faire du provisionning, mais il est loin derrière terraform. Notamment pour les services autres que EC2. Je les trouve plutôt complémentaires : terraform pour les ressources de l'infra, puis ansible (ou puppet) pour les dépendances systèmes à l'intérieur des instances. Bonne journée à tous, Théophile Helleboid
Bonjour, Aujourd'hui j'ai participé à une conf de Redhat sur Ansible et son partie cloud, j'avais posé la même question. Il se peut que la réponse est que aucune différence existe entre ansible et terraform mais en plus on peut instancier terraform via ansible et vice versa. Est-ce que quelqu'un pourrait confirmer le contraire par exemple? Ou genre, ou exactement ou devrait utiliser terraform a la place de cloudinit ou cloudform et on ne peut pas utiliser Ansible à la place? L'objectif est d'autant de diminuer cette multitude interminable d'outillage au sein d'un SI. Cordialement, 2018-02-14 9:52 GMT+01:00 Théophile Helleboid <chtitux@gmail.com>:
J'utilise terraform pour déployer chez AWS et OVH, et même si la courbe d'apprentissage est un peu rude au début, c'est un vrai plaisir de l'utiliser au quotidien.
Rien que l'abandon de Cloud Formation (pour AWS) et la garantie que la totalité de la stack est redéployable à l'identique en 5 minutes, buckets S3 et services en tout genre d'AWS compris, vaut le coup. À condition que tout le monde joue le jeu et ne passe plus par les consoles pour modifier des paramètres en douce.
Mon conseil : faire tourner la validation, la simulation et l'application des stacks depuis la CI / CD du dépôt git sur lequel la configuration est commitée. Ça permet une vraie agilité pour déployer. Chez nous, la simulation est lancée automatiquement, mais l'application de la configuration est faite depuis un bouton de la CI, mais manuellement.
On Feb 13, 2018 16:04, "Guillaume" <guibdx@gmail.com> wrote:
A mon avis je ne vois pas vraiment l'intérêt de basculer sur terraform si c'est pour ensuite travailler avec ansible qui peut également faire le travail lui même.
Ansible a des modules pour faire du provisionning, mais il est loin derrière terraform. Notamment pour les services autres que EC2. Je les trouve plutôt complémentaires : terraform pour les ressources de l'infra, puis ansible (ou puppet) pour les dépendances systèmes à l'intérieur des instances.
Bonne journée à tous,
Théophile Helleboid
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Boukari Sabri Cloud DevOps Specialist *Failure is the Great Teacher*
Bonjour à tous, Merci pour tous les retours, c'est très sympa et surtout très intéressant pour moi (et pour la communauté) :-) Je vais mettre en place un POC et commencer à monter tout ça. Très bonne fin de semaine à vous tous ! F00b4rch Le 14 février 2018 à 15:18, Sabri Boukari <sabriicone@gmail.com> a écrit :
Bonjour,
Aujourd'hui j'ai participé à une conf de Redhat sur Ansible et son partie cloud, j'avais posé la même question. Il se peut que la réponse est que aucune différence existe entre ansible et terraform mais en plus on peut instancier terraform via ansible et vice versa.
Est-ce que quelqu'un pourrait confirmer le contraire par exemple? Ou genre, ou exactement ou devrait utiliser terraform a la place de cloudinit ou cloudform et on ne peut pas utiliser Ansible à la place?
L'objectif est d'autant de diminuer cette multitude interminable d'outillage au sein d'un SI.
Cordialement,
2018-02-14 9:52 GMT+01:00 Théophile Helleboid <chtitux@gmail.com>:
J'utilise terraform pour déployer chez AWS et OVH, et même si la courbe d'apprentissage est un peu rude au début, c'est un vrai plaisir de l'utiliser au quotidien.
Rien que l'abandon de Cloud Formation (pour AWS) et la garantie que la totalité de la stack est redéployable à l'identique en 5 minutes, buckets S3 et services en tout genre d'AWS compris, vaut le coup. À condition que tout le monde joue le jeu et ne passe plus par les consoles pour modifier des paramètres en douce.
Mon conseil : faire tourner la validation, la simulation et l'application des stacks depuis la CI / CD du dépôt git sur lequel la configuration est commitée. Ça permet une vraie agilité pour déployer. Chez nous, la simulation est lancée automatiquement, mais l'application de la configuration est faite depuis un bouton de la CI, mais manuellement.
On Feb 13, 2018 16:04, "Guillaume" <guibdx@gmail.com> wrote:
A mon avis je ne vois pas vraiment l'intérêt de basculer sur terraform si c'est pour ensuite travailler avec ansible qui peut également faire le travail lui même.
Ansible a des modules pour faire du provisionning, mais il est loin derrière terraform. Notamment pour les services autres que EC2. Je les trouve plutôt complémentaires : terraform pour les ressources de l'infra, puis ansible (ou puppet) pour les dépendances systèmes à l'intérieur des instances.
Bonne journée à tous,
Théophile Helleboid
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Boukari Sabri
Cloud DevOps Specialist *Failure is the Great Teacher*
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Est-ce que quelqu'un pourrait confirmer le contraire par exemple? Ou genre, ou exactement ou devrait utiliser terraform a la place de cloudinit ou cloudform et on ne peut pas utiliser Ansible à la place? La philosophie Unix, 1 outil (simple) pour 1 tâche (simple) permet de diminuer la complexité des outils tout en gardant un maximum de flexibilité. Si on veut faire des choses "compliquées" chez AWS, par exemple créer des domaines autorisés sur SES, leur solution d'envoi d'email, puis créer les enregistrements DNS nécessaires pour valider la propriété des domaines sur Route 53,De même, ça peut se faire dans terraform. Mais pas dans ansible. Terraform n'est par contre pas capable d'exécuter des commandes ou modifier des fichiers de configuration une fois que l'instance est déjà démarrée. Ansible et puppet sont spécialisés dans ça. Cloud init permet d'exécuter des commandes au démarrage de l'instance. Un setup complet serait : - terraform pour instancier les ressources chez le provider (instances, vpc, buckets, policy) - ansible ou puppet pour la configuration des instances - Cloud init pour, au démarrage de l'instance, configurer puppet et lancer le premier run Si votre besoin est simple, ansible étant capable de faire du provisionnement, vous pouvez tout faire avec (ansible + Cloud init). Mais dès que la stack se complexifie, il faudra faire le choix entre terraform ou complexifier énormément les recettes ansible. L'objectif est d'autant de diminuer cette multitude interminable d'outillage au sein d'un SI. Plus les outils savent faire de choses, moins ils sont spécialisés. L'équilibre est toujours précaire. Théophile Helleboid
Bonjour, Merci beaucoup pour cette réponse extrêmement précise! 2018-02-15 10:07 GMT+01:00 Théophile Helleboid <chtitux@gmail.com>:
Est-ce que quelqu'un pourrait confirmer le contraire par exemple? Ou genre, ou exactement ou devrait utiliser terraform a la place de cloudinit ou cloudform et on ne peut pas utiliser Ansible à la place?
La philosophie Unix, 1 outil (simple) pour 1 tâche (simple) permet de diminuer la complexité des outils tout en gardant un maximum de flexibilité.
Si on veut faire des choses "compliquées" chez AWS, par exemple créer des domaines autorisés sur SES, leur solution d'envoi d'email, puis créer les enregistrements DNS nécessaires pour valider la propriété des domaines sur Route 53,De même, ça peut se faire dans terraform. Mais pas dans ansible.
Terraform n'est par contre pas capable d'exécuter des commandes ou modifier des fichiers de configuration une fois que l'instance est déjà démarrée. Ansible et puppet sont spécialisés dans ça.
Cloud init permet d'exécuter des commandes au démarrage de l'instance.
Un setup complet serait : - terraform pour instancier les ressources chez le provider (instances, vpc, buckets, policy) - ansible ou puppet pour la configuration des instances - Cloud init pour, au démarrage de l'instance, configurer puppet et lancer le premier run
Si votre besoin est simple, ansible étant capable de faire du provisionnement, vous pouvez tout faire avec (ansible + Cloud init). Mais dès que la stack se complexifie, il faudra faire le choix entre terraform ou complexifier énormément les recettes ansible.
L'objectif est d'autant de diminuer cette multitude interminable d'outillage au sein d'un SI.
Plus les outils savent faire de choses, moins ils sont spécialisés. L'équilibre est toujours précaire.
Théophile Helleboid
-- Boukari Sabri Cloud DevOps Specialist *Failure is the Great Teacher*
participants (5)
-
F00b 4rch -
Guillaume -
Olivier Duquesne (DaffyDuke) -
Sabri Boukari -
Théophile Helleboid