etalab-ia / albert-api

MIT License
9 stars 3 forks source link

Création d'un environnement de staging pour Albert API #81

Open leoguillaume opened 2 weeks ago

leoguillaume commented 2 weeks ago

@cyrillay update : 18/11/2024 @cyrillay update : 19/11/2024

Context

Actuellement Albert API est composé de 2 environnements :

Ces environnements ne sont pas sur Terraform.

Objectifs

Spécifications techniques

Vision cible

Voici la vision cible pour l'environnement de staging de Albert API. Il ne s'agit pas ici de créer la vision cible ici. tf drawio (1)

Vision attendue

Création d'un state de staging :

Sur l'exemple du state de dev, outscale_eu-west-2_albert-dev présent sur la branche main du repo administration (voir : https://gitlab.com/etalab-datalab/infrastructure/administration/-/terraform).

Création de 2 VM :

Région  Name Type Tags Storage Storage type Security group
eu-west-2a OUT-APP-STA-001 tinav5.c2r8p2 {"Env": "STAGING", "Project": "API"} 120 gp2 albert-app
eu-west-2a OUT-BDD-STA-002 tinav6.c8r32p1 {"Env": "STAGING", "Project": "API"} 720 gp2 albert-bdd

cloud-config

cloud_config_modules:

users:

hostname:


Spéfication de l'environnement de staging voir https://grist.numerique.gouv.fr/o/albert/25SBdE5Sqqhg/Infrastructure/p/15

Création de 2 entrées DNS sur OVH (voir avec @leoguillaume pour la procédure) : 
- albert.api.staging.etalab.gouv.fr
- albert.bdd.staging.etalab.gouv.fr

- Création d'un documentation (fr) sur la nomenclature des services Outscale dans le dossier /docs

### Plus optionnel

- utilisation de templating terraform
- création d'un net pour l'environnement et d'un sous réseau par VM (cf schéma) avec considération des accès internets (internet gateway)

Configuration fail2ban dans cloud-init

echo "info: enabling and starting fail2ban" sudo systemctl enable fail2ban sudo systemctl start fail2ban



# Taches liées

- #62
- #63

# Ressources 

- Documentation API outscale : https://docs.outscale.com/api.html
- Documentation Terraform outscale : https://registry.terraform.io/providers/outscale/outscale/latest/docs
- Contact support Outscale : david.anis@outscale.com
- Documentation Outscale cloud init : https://docs.outscale.com/fr/userguide/Introduction-%C3%A0-cloud-init.html

* Nomenclature noms des VM : 

| Datacenter | Type | Env | Number |
| -- | -- | -- | -- | 
| OUT | APP | DEV | 001 |
| | BDD | STA | 002 |
| | SVC | PRO | … |
| | GPU |   | | 
cyrillay commented 1 week ago

@leoguillaume pour confirmer :

Aussi, concernant le templating, je pense que c'est plutôt les (modules)[https://developer.hashicorp.com/terraform/language/modules] qu'il faut utiliser pour ce usecase (instantier plusieurs fois une même stack sur 3 environnements). A ce stade, je ne suis pas sur d'avoir besoin du templating. D'accord avec ça ?

cyrillay commented 1 week ago

Concernant le subnet, et mettre les VMs dans un sous réseau, c'est faisable, mais nous ne pourrions plus y accéder sans un VPN ou un Bastion. Je serais plutôt en faveur du VPN. Est-ce qu'il y a déjà un projet en cours ? Sinon, je peux le démarrer en voyant avec outscale ce qu'il peuvent nous fournir : doc.