$30 off During Our Annual Pro Sale. View Details »

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

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

Gaëtan

November 19, 2019
Tweet

Other Decks in Technology

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