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

3ec76a46081a09c9b0248a6609440e21?s=47 Gaëtan
November 19, 2019

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

3ec76a46081a09c9b0248a6609440e21?s=128

Gaëtan

November 19, 2019
Tweet

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