📻 RDO #3 - Comment bien débuter l'infrastructure as code?

:thinking: Vous voulez vous mettre à l’Infrastructure as Code mais vous ne savez pas par où commencer ?

:radio: Nous en parlons justement dans #RadioDevOps numéro 3 avec @les-podcasteurs.

Vous pratiquez déjà l’#InfraAsCode ?

2 J'aime

Content que tout le monde fasse du Ansible :stuck_out_tongue:

Pour avoir fait du Ansible (de manière intensive) et du Puppet, clairement Ansible >>>>>>> Puppet.
Déjà, je trouve Puppet beaucoup plus complexe, difficile à mettre en place, et on parle souvent de problèmes de perfs avec Ansible mais un puppet centralisé c’est pas forcément mieux :smiley:
Et surtout, Ansible permet beaucoup plus de choses. Puppet, on sait que son infras convergera après X minutes, mais Puppet n’a aucune capacité d’orchestration.

Par exemple, avec Ansible je faisais du rolling restart de clusters Elasticsearch (exclure un noeud du cluster, attente d’avoir un cluster green, redémarrage du noeud etc…), ce genre de trucs est impossible à faire avec du Puppet.
Il peut être éventuellement intéressant de mixer les deux aussi si besoin.

Par contre, je crois que je n’ai jamais repris un rôle d’Ansible Galaxy (alors que j’ai dû écrire plusieurs centaines de rôles à une époque). Beaucoup de rôles galaxy sont de mauvaise qualité, ne respectent aucune bonne pratique, sont très spécifiques ou bien essayent de tout faire… Donc je réécris systématiquement mes rôles.
Ansible demande une énorme rigueur pour sortir des trucs propres, les bonnes pratiques s’apprennent sur le tas.

Concernant Ansible vs Terraform pour de l’infra, je préfère Terraform mais Ansible permet plus de trucs. Comme dit précédemment, Ansible est aussi intéressant pour faire de l’orchestration, là où parfois bidouiller le lifecycle etc… de Terraform peut être lourd. Donc pour certaines tâches, Ansible peut avoir du sens.

Pour un Terraform “universel”, je n’y crois pas actuellement car les Cloud sont trop différents entre eux. Une VM c’est une VM, un réseau c’est un réseau, mais il y a toujours des différences d’implémentation qui se ressentent sur les API. Et comme ça a été dit, certains produits sont complètement différents entre Cloud.

Je suis aussi un gros fan de Packer sinon, j’avais écris un article et fait un talk sur le sujet (avec des use cases assez poussés).
D’ailleurs, si je devais refaire une infra aujourd’hui, je pense que je packagerais probablement directement mes applications dans des images via Packer, et le déploiement/le scaling serait juste déployer des vms :stuck_out_tongue:

2 J'aime

Perso, je ne comprends pas comment on peut ĂŞtre fan de terraform:

  • c’est assez illisible et tu ne sais pas dans quel ordre sera rĂ©alisĂ© un “dĂ©ploiement”. Un mix entre tout en parallèle et de la dĂ©pendance +/- explicite
  • dès que tu n’est pas dans un provider, tu fais beaucoup de choses avec des provisionners ou du null_resource
  • d’un point de vue sĂ©mantique, bof
  • les modules communautaires sont de qualitĂ© très inĂ©gales
  • impossible nativement de rĂ©cupĂ©rer un fichier sur le host cible pour le ramener en local

J’ai donc l’impression qu’en dehors des providers officiels, c’est pas trop la peine. Et même là parfois on a des choses étranges.

Alors oui terraform est arrivé au bon moment et à réussi à s’imposer mais je suis assez déçu.

Je viens de porter un déploiement d’un cluster kubernetes via kubespray sur des machines GCE et sur lequel on déploit le produit de mon client pour avoir du terraform partout. J’en ai bien chié et d’ailleurs comme le destroy déconne, j’ai fini par garder le script python qui fait le ménage chez GCE pour les VM / VPC / DNS. Pour une raison que j’ignore, terraform perd un contexte k8s et donc le destroy échoue alors qu’il marche très bien au déploiement…

ansible n’est pas parfait non plus mais je le trouve bien plus lisible et même si on perd en parallélisme des actions. C’est sur que si tu veux un destroy, faut le rédiger toi même mais à la limite, je préfère.

Quand à la gestion des états, se dire que l’état de terraform est un mix entre l’api du provider, son “state” et ce qui est décrit, c’est une hérésie je trouve. Surtout qu’il ne faut pas perdre ce fichu fichier de state pour ne pas tout perdre. :man_facepalming:

Là encore, je préfère l’approche ansible est l’état décrit dans le fichier et donc il y a juste réconciliation avec la source distante.

Pulumi, je sais pas pourquoi, je pensais que cela n’était pas OSS donc j’avais écarté. Mais je m’étais trompé. Mais il me semble aussi qu’il y a un fichier “state” de la même manière que terraform…

Dans les outils, il y a mgmt que je surveille de temps à autre mais je ne sais pas s’il aboutira ou pas…

1 J'aime

Salut,

Pour moi Terraform/Pulumi sont totalement différents d’outils comme Ansible/Saltstack/Puppet/Chef, qui sont à la base des outils de provisioning système (et non infra).

La différence entre Terraform et Pulumi est principalement liée à l’utilisation d’un DSL pour l’un et d’un langage de programmation pour l’autre, y’a des avantages et inconvénients aux deux approches, sinon les deux outils se rejoignent sur le fait d’avoir un fichier state.

J’ai longtemps utilisé Saltstack avant de basculer sous Ansible car plus répandu et plus simple de prise en main.

Aujourd’hui j’utilise principalement le couple Terraform/Ansible, Terraform depuis la 0.12 permet d’avoir des modules plus flexibles et plus génériques. Ansible fonctionne assez bien même si j’ai relevé certains bugs bien emmerdant et toujours pas fixés.

Mon principal problème en terme de Infrastructure As Code est la gestion des secrets, ces outils ne fournissent aucune solution viable out of the box.

Lorsqu’on bosse sur du public cloud comme Azure ou AWS, on peut s’en sortir à l’aide de certains de leurs services mais sur du on-premise cela devient assez vite un casse tête à gérer.

Tu as ansible-vault quand même par défaut et je présume que terraform a aussi son intégration vault :wink:

Sinon, oui je fais bien le distingo entre les deux types d’outils (TF/Pullumi vs Ansible and co) mais mon client voulait tout piloter via terraform…

ansible-vault n’est pas une solution viable à mon sens :

  • ImpossibilitĂ© d’avoir plusieurs passphrases (donc secret Ă  partager entre plusieurs utilisateurs).
  • ImpossibilitĂ© d’auto-gĂ©nĂ©rer les secrets.

Sous Terraform ce n’est pas mieux, les secrets se retrouvent dans les fichiers states, il faut donc recourir un backend de type S3 avec chiffrement coté serveur d’activé… ou sinon passer par leur offre SaaS.

Pulumi possède une option à la ansible-vault permettant de chiffrer les secrets contenus dans les fichiers states à l’aide d’une passphrase.

1 J'aime

Concernant Ansible vault je considère que c’est juste le minimum qu’un outil peut fournir. Avec AWX ou Tower c’est par contre plus facile a gérer. Il y a moyen d’avoir une granularité sur les droits d’accès aux mots de passe par équipes, par users etc. N’hésitez pas à le tester cela peut répondre à certains besoins quand on travail avec plusieurs équipes.

Cet épisode d’électro monkey parle de Pulumi: https://electro-monkeys.fr/?p=531
Pour être honnête, je suis resté sur ma faim techniquement parlant.

Comme le logiciel a pu Ă©voluer beaucoup depuis les derniers messages. Est ce que qq peut faire un REX (forces/faiblesses) sur Pulumi ?

J’ai testé Pulumi et je t’avoue ne pas trop savoir quoi en penser :

  • Son avantage est aussi son inconvĂ©nient : permettre d’utiliser un vrai langage de programmation offre beaucoup de flexibilitĂ© mais c’est aussi la porte ouverte aux mauvaises implĂ©mentations, de plus, il y a plus d’un langage supportĂ© donc selon la boite ou l’entreprise, il faudra s’adapter.
  • Depuis les dernières versions de Terraform, HCL a bien Ă©voluĂ© et offre beaucoup plus de flexibilitĂ© que dans les versions prĂ©cĂ©dentes.

La seule feature pour l’instant de Pulumi que j’aurais aimé retrouver sur Terraform est le support natif du chiffrement des fichiers states.