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/