Du cloud click-click à l'infrastructure as code sans tout casser (ou presque)

Beaucoup de startup font le choix de commencer leur activité sur des clouds publics en bénéficiant ds crédits offerts. Cela se traduit par le lancement de multiples services difficiles à suivre. Cette présentation présente un chemin pour reprendre la main sur ces infrastructures et les intégrer à une gestion moderne comme infrastructure as code

Transcript

1. Du cloud en click-click à infrastructure as code sans tout casser (ou presque)* Gaëtan Duchaussois - Fretlink * #DevOups #TypoTeam
2. Avis de dégagement de responsabilité La situation présentée en point de départ n’est pas celle de mon employeur actuel ou d’un employeur passé mais plutôt une synthèse de situations vues et entendues
3. Contexte : Lançons une startup • On a une idée • Elle nécessite d’avoir des sous • Donc il faut convaincre • Faisons un MVP/POC
4. Les contraintes pour le MVP • Aller vite • Coûter peu cher en hébergement • Attirer les investisseurs (B* words)
5. Les solutions trouvées Les offres de cloud startup x k€ offerts les n premières années
6. Les conséquences • Abondance de services lancés • Peu de visibilité sur ce qui est là (firewalling, droits, services managés) • Facturation potentiellement élevée cachée par les crédits offerts • Le MVP est devenu une prod
7. Our lord and savior terraform • Gestion dans des fichiers textes (à mettre dans un SCM) • Gestion des accès concurrents (système de lock et SCM) • Suivi des modifications • Reviews
8. Import des ressources • Scripts maisons pour SaaS simples ◦ Création du fichier terraform ◦ Exécution des terraform import idoines • Outils disponibles en ligne, par exemple la gem terraforming https://github.com/dtan4/terraforming
9. Et maintenant que fait-on ? • On fait des make plan • On fait le ménage le plus évident • On introduit des variables • On renomme des ressources ⚠ On touche au state • On partage le statefile sur un espace de stockage partagé
10. De nouveaux problèmes • On ne respecte pas vraiment les best practices d’organisation du code • Duplicate code everywhere • Les modifications du state sont pas évidentes en équipe
11. Migrations • Inspiré de ce qui se fait en SQL • En dehors de la codebase terraform • Le state porte un numéro de version • Scripts bash pour passer d’une version à une autre • Script pour vérifier la correspondance et appliquer les migrations
12. Comment ça marche ? migrations/ ├── 001 │ ├── down.sh │ └── up.sh ├── 002 │ ├── down.sh │ └── up.sh ├── 003 │ ├── down.sh │ └── up.sh ├── 004 │ ├── down.sh │ └── up.sh ├── 005 │ └── up.sh ├── 006 │ ├── down.sh │ └── up.sh └── migrate.sh ├── version ← 6 └── version.tf data local_file version { filename = "${path.module}/version" }
13. Comment ça marche ? #!/bin/bash state_version="local_file.version" [...] function get_current_version { version=$(terraform state show "$state_version" 2>/dev/null | grep -E '^content\s+=' | cut -d '=' -f 2) if [ "$version" == "" ]; then version=0 fi; return $version } function get_target_version { target=$(head -n 1 "$terraform_dir/version") } function migrate { # run the correct script } get_current_version get_target_version # Run migrate for the versions # Refresh set the version from file in state terraform refresh -target=data.local_file.version
14. Usage : renommer une ressource up.sh: terraform state mv aws_internet_gateway.igw-649df804 aws_internet_gateway.production down.sh: terraform state mv aws_internet_gateway.production aws_internet_gateway.igw-649df804
15. Passer de n ressources à une ressource avec count up.sh terraform state mv aws_instance.reverse-proxy-bc2ga8f33061 aws_instance.reverse-proxy[0] terraform state mv aws_instance.reverse-proxy-ef2ga8e93087 aws_instance.reverse-proxy[1] down.sh terraform state mv aws_instance.reverse-proxy[0] aws_instance.reverse-proxy-bc2ga8f33061 terraform state mv aws_instance.reverse-proxy[1] aws_instance.reverse-proxy-ef2ga8e93087
16. On s’améliore en terraform, on fait des modules up.sh terraform state mv aws_instance.app_integ module.app-integ.aws_instance.ansible-base down.sh terraform state mv module.app-integ.aws_instance.ansible-base aws_instance.app_integ
17. On réorganise les statefiles #!/usr/bin/env bash set -e # Add existing resources to the new hetzner/production statefile cd providers/hetzner/production || exit 1 terraform import hcloud_server.slack_bot 1567246 cd - || exit 0 # Remove resources from the Root statefile terraform state rm hcloud_server.slack_bot
18. Reste à faire • Arrêter d’en avoir besoin • Intégrer dans la CI • Gérer plus finement les multiples statefiles
19. Conclusion • C’est mieux de pas commencer en cliquant partout • Ce n’est pas une fatalité • L’usage de scripts intermédiaires permet de se faciliter la vie • La review et le suivi des modifications, c’est la vie • Ça reste moins propre que de remonter depuis zéro une infrastructure