You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
…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.
The text was updated successfully, but these errors were encountered:
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.
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:
backend|zmd
/prod|beta
)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:
Les betas multiples
J'ai aussi dans ce dépôt un PoC de plusieurs beta. L'idée est la suivante:
nom de beta
->ID d'image scaleway
[clé].zestedesavoir.com
avec les IPs des instancesLes 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:
plan
et auto-appliquer au merge de la PRLes questions qui restent à résoudre en vrac:
Je me permet de ping @Situphen et @artragis, puisque c'est susceptible de vous intéresser.
The text was updated successfully, but these errors were encountered: