--- # Les machines du SITE — les MEMES qu'au site de Chezlepro, sous les memes noms (decision de # Daniel, 2026-10-12) : un exploitant qui connait l'un connait l'autre, et une reprise ne # demande d'apprendre aucun nom. # # Ici l'adressage est DECLARE (un site est le terrain, il n'a pas de seed dont le deriver). # La regle reste celle de Chezlepro : 10..., et # le meme VMID. `reseau:` nomme un reseau de `underlay.yml`, qui fournit pont, VLAN, masque et # passerelle. # # UN SEUL NOEUD : toutes sur `maurice`. Somme : 9 VM, 17 vCPU, 23 Go de RAM, 816 Go de disque # provisionne — a l'aise dans 2 x 128 Go. Disques : 416 Go sur `nvme`, 400 Go # (`site-backup-01`) sur `miroir`. serveurs: site-ops-01: etat: actif reseau: site-pilotage ip: 10.31.31.11 noeud: maurice gabarit: { vcpu: 2, memoire: 4096, disque: 40G } vmid: 9001 variables: # LES DEUX LOCATAIRES : ce site est la reprise de l'un ET de l'autre. Le runner doit # pouvoir redeployer chacun depuis son propre depot. serveur_ops_depots: - { depot: "set-ops-public", dest: "Set-OPS-public", role: "moteur" } - { depot: "site-technolibre", dest: "SITE-Technolibre", role: "hebergeur" } - { depot: "set-ops-modeles", dest: "Set-OPS-Modeles", role: "modeles", branche: "master" } - { depot: "ops-chezlepro", dest: "OPS-Chezlepro", role: "tenant" } - { depot: "ops-technolibre", dest: "OPS-Technolibre", role: "tenant", branche: "master" } serveur_ops_instance: "" serveur_ops_gui_auth: locale serveur_ops_underlay: "SITE-Technolibre" serveur_ops_site_depot: "SITE-Technolibre" serveur_ops_site_voute_source: >- {{ (playbook_dir ~ '/../../underlay.yml') | realpath | dirname }}/underlay.vault.yml serveur_ops_site_cle_deposer: true serveur_ops_site_cle_source: "~/.config/setops-vault-site-technolibre" site-cache-01: etat: actif reseau: site-genome ip: 10.31.33.21 noeud: maurice gabarit: { vcpu: 2, memoire: 2048, disque: 120G } vmid: 9002 site-forge-01: etat: actif reseau: site-genome ip: 10.31.33.11 noeud: maurice gabarit: { vcpu: 2, memoire: 4096, disque: 80G } vmid: 9003 integrations: [client_backup] variables: serveur_forgejo_bd: sqlite serveur_forgejo_tls: true serveur_forgejo_http_port: 443 client_pki_cle_groupe: git client_pki_cle_mode: "0640" client_pki_reload_services: - forgejo site-pki-01: etat: actif reseau: site-autorite ip: 10.31.32.11 noeud: maurice gabarit: { vcpu: 2, memoire: 2048, disque: 32G } vmid: 9004 integrations: [client_backup] site-dns-01: etat: actif reseau: site-service ip: 10.31.34.11 noeud: maurice gabarit: { vcpu: 2, memoire: 2048, disque: 40G } vmid: 9005 variables: serveur_powerdns_publier_expositions: true site-backup-01: etat: actif reseau: site-sauvegarde ip: 10.31.35.11 noeud: maurice gabarit: { vcpu: 2, memoire: 2048, disque: 400G } vmid: 9010 # SUR LE MIROIR, pas sur le NVMe : ses 400 Go ne tiendraient pas a cote des huit autres, # et c'est la machine dont le disque doit survivre a la perte d'un disque. stockage: miroir site-mon-01: etat: actif reseau: site-supervision ip: 10.31.36.11 noeud: maurice gabarit: { vcpu: 2, memoire: 4096, disque: 64G } vmid: 9011 integrations: [client_backup] site-edge-01: etat: actif reseau: site-publication ip: 10.31.37.11 noeud: maurice gabarit: { vcpu: 2, memoire: 2048, disque: 20G } vmid: 9012 variables: client_pki_reload_services: - nginx # LE SECOND SERVEUR DE NOMS PUBLIC des deux ecosystemes (2026-09-29) : il tourne ICI, et le # relais (VPS) ne fait que lui faire suivre les requetes par le tunnel du site. site-dnspub-01: etat: actif reseau: site-publication ip: 10.31.37.21 noeud: maurice gabarit: { vcpu: 1, memoire: 1024, disque: 20G } vmid: 9013