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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

4. Les contraintes pour le MVP
   ● Aller vite
   ● Coûter peu cher en hébergement
   ● Attirer les investisseurs (B* words)
   

   View Slide

5. Les solutions trouvées
   Les offres de cloud startup x k€ offerts les n premières années
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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é
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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"
    }
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

18. Reste à faire
    ● Arrêter d’en avoir besoin
    ● Intégrer dans la CI
    ● Gérer plus finement les multiples statefiles
    

    View Slide

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
    

    View Slide