Memorandom

Cela fait plusieurs mois (années ?) que je me dis qu’utiliser DinD (Docker in Docker) pour builder des images ce n’est vraiment pas idéal. Mais cela fait aussi un moment que je n’ai pas eu l’occasion de (re)construire une CI. Couplé à une flemmingite aiguë en ce qui concerne la reprise des projets persos…
Mais il est temps ! Ajourd’hui jetons un coup d’oeil sur buildah et construisons une pipeline Gitlab-CI simple pour s’affranchir de la dépendance à Docker dans nos jobs.

Dans le cadre d’une structure utilisant Terraform se pose toujours à un moment donné la question du contrôle de l’infrastructure. Est-ce que celle-ci est sécurisée ? Est-ce qu’elle est conforme aux réglementations applicables ? Suit-elle les bonnes pratique en vigueur ?

Ces questions deviennent de plus en plus pertinentes quand l’utilisation de Terraform tend à se généraliser et que ce n’est plus une équipe restreinte et particulièrement sensible à ces problématiques qui gère l’infrastructure. Comment s’assurer qu’un panel plus large d’utilisateurs, souvent moins expérimentés, puisse participer à l’évolution de l’infrastructure sans en compromettre la sécurité mais tout en gardant leur autonomie ?

C’est ici qu’un outil de Policy as Code peut s’avérer utile. Et nous abordons dans cet article Open Policy Agent en ce sens.

Abordons dans cet article un moyen d’automatiser le déploiement de son code Terraform : les outils de CI/CD intégrés à Gitlab (et les runners associés).
Nous détaillerons une pipeline constituée de 3 jobs pour l’initialisation, la planification et l’application d’un manifeste Terraform. Avec une validation manuelle avant la création effective des ressources. En bonus nous verrons comment planifier la destruction de l’infrastructure pour limiter les coûts dans le cadre d’un POC.

Dans cet article je suppose que vous connaissez déjà Terraform et que vous en avez déjà eu une utilisation au moins basique. Plan et Apply vous sont connus, tout comme les variables et les states par exemple.

Le but de cet article est de répondre à la question qui m’es venue après la compréhension des principes de base de l’outil : comment organiser mon code proprement pour qu’il reste lisible et exploitable.

Comme d’habitude je ne prétends pas détenir La réponse, il existe d’ailleurs plusieurs approches pour traiter les problématiques abordées. Je présente ici l’état, à ce jour, de ma réflexion sur ce sujet. Libre à vous de vous en inspirer ou de me partager vous retours d’expériences et conseils =).