Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap, aka le Masterplan. #11

Open
sandhose opened this issue Jan 6, 2019 · 1 comment
Open

Roadmap, aka le Masterplan. #11

sandhose opened this issue Jan 6, 2019 · 1 comment

Comments

@sandhose
Copy link
Contributor

sandhose commented Jan 6, 2019

Voici en vrac ce que j'aimerais à terme pour l'infra de Zeste de Savoir.

L'objectif est 1. d'avoir une infra la plus déclarative, reproductible et automatisée possible, et 2. pouvoir déployer dynamiquement plusieurs environnements de beta.

Dans infra, j'entends:

  • les machines qu'on a (1 VPS chez Gandi pour la prod, 1 VPS chez Scaleway pour la beta)
  • les deux noms de domaines avec la zone associé (c'est Gandi notre registrar et DNS)
  • les secrets de login social (clé d'API Facebook et Google)
  • plusieurs projets avec DSN associé dans Sentry (backend|zmd / prod|beta)
  • un projet Google Cloud avec les services accounts ayant accès à Google Analytics
  • divers clés/certificats genre compte LetsEncrypt, clé DKIM pour les mails…

Là dedans, les seuls trucs qui sont pas gérable via une API sont les clés d'API de login sociaux (y'a une issue chez Google pour ça), et les VPS chez Gandi ('fin, l'API est très vieille et manque d'un vrai SDK)


J'ai pas mal expérimenté avec Terraform, qui est un outil permettant de décrire et déployer une infra via des fichiers de config.

Mes expérimentations pour Zeste de Savoir se trouvent sur sandhose/terraform-zestedesavoir.

Ce qu'il y a dans ces fichiers de config:

L'idée, c'est qu'ensuite, on peut faire générer un certain nombre de sorties à Terraform, qu'on pourrait ensuite utiliser dans le playbook Ansible.

Ce qui serait aussi possible de gérer via Terraform:

  • le service account pour les credentials d'API Google Analytics
  • les "projets" Sentry pour récupérer ensuite les différents DSN
  • les différents records DNS genre SPF, DMARC…

Les betas multiples

J'ai aussi dans ce dépôt un PoC de plusieurs beta. L'idée est la suivante:

  • on construit avec l'outil Packer des images pour Scaleway à partir du playbook Ansible (j'ai le fichier de conf. Packer fonctionnel en local)
  • on stocke dans un stockage clé-valeur quelconque (dans mes tests, Consul) une association nom de beta -> ID d'image scaleway
  • Terraform déploie autant d'instances chez Scaleway qu'il faut…
  • …puis ajoute les records DNS [clé].zestedesavoir.com avec les IPs des instances

Les exécutions de Terraform et de Packer peuvent se faire en CI. Pour déployer une nouvelle beta, il suffirait d'ajouter l'entrée dans le stockage clé-valeur et trigger la CI ; pour en enlever une, il suffirait de supprimer la clé correspondante.


Autres infos en vrac:

  • l'état de Terraform doit être partagé d'une manière ou d'une autre. Le stocker dans Consul est envisageable
  • le fait de gérer le certificat ACME dans terraform permet de générer un certificat wildcard réutilisable (pas besoin de faire un nouveau compte + certificat pour chaque instance), et évite de laisser traîner les credentials Gandi sur le serveur
  • l'ajout d'une nouvelle instance dans le clé-valeur peut très bien se faire automatiquement en CI, et on peut faire remonter l'info à GitHub pour l'afficher dans les PR. On peut aussi trigger des pipelines Travis entre plusieurs dépôts via leur API
  • je suis tombé sur Atlantis pour lancer Terraform à chaque PR, afficher le plan et auto-appliquer au merge de la PR

Les questions qui restent à résoudre en vrac:

  • je ne sais pas comment enregistrer auprès du munin de @vhf les nouvelles instances. De ce que je sais, c'est compliqué de faire de l'ajout dynamique d'hôte sur munin.
  • je ne sais pas comment on va faire pour restaurer les données sur une nouvelle beta. J'ai un script presque fonctionnel pour ça, mais il doit être exécuté depuis mon serveur
  • quid de la rétention des images Scaleway ? On build à chaque commit ? Chaque tag ? Manuellement ?

Je me permet de ping @Situphen et @artragis, puisque c'est susceptible de vous intéresser.

@AmauryCarrade
Copy link
Member

AmauryCarrade commented Feb 16, 2021

Salut @sandhose ! Est-ce que tu penses que tout cela est toujours d'actualité ?

J'envisage (un jour) jouer un peu avec l'API de déploiements de GitHub pour déployer sur la bêta depuis une PR à la demande (avec un nano-bot GitHub pour créer une demande de déploiement via un commentaire dans une PR le mentionnant, et un workflow GitHub Actions exécuté lors de la création d'un déploiement qui appellerait Ansible et éventuellement la synchronisation des données). Ce serait un peu une version light de cela : déploiement à la demande sans intervention humaine, mais avec un seul unique environnement.

Cela dit, si un travail est concrètement en cours là dessus, il serait dommage de se marcher dessus. Mais d'un autre côté, ce que je décris peut servir de base à ta vision, à terme (via le bot pour créer un déploiement, et GitHub Actions pour construire mais suivant ta logique).

À noter que ce ne sont que des idées pour le moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants