la premiere heure : adresses et comptes, dans l ordre
Proxmox et OPNsense sont deja installes chez TechnoLibre. Ce qui manque avant tout deploiement, ce sont les bonnes adresses et les comptes par lesquels Set-OPS agit. L ORDRE N EST PAS INDIFFERENT : la frontiere porte la passerelle de chaque zone. Posee apres le noeud, celui-ci aurait des adresses qui ne menent nulle part, et le diagnostic parlerait de reseau alors qu il s agirait d une patte manquante. Le document donne les huit pattes de la frontiere avec l invariant du dernier octet, les trois adresses du noeud, les deux comptes d API avec leurs commandes exactes, la cle publique de la flotte a poser, la restauration du gabarit depuis la cle USB, et la mesure d espace a faire AVANT de materialiser. Il dit aussi franchement pourquoi le jeton Proxmox part en Administrator, et que le resserrer ensuite est un geste a faire, pas une intention. Au passage : `cle_ssh` designait `~/.ssh/technolibre`, qui n existe pas. La vraie cle est `~/.ssh/id_ed25519_ansible_technolibre` — un nom plausible ne designe rien. Controle : les onze adresses du document sont celles que la carte declare, aucune inventee. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
This commit is contained in:
parent
7db59ebfe9
commit
ca68ef46b6
2 changed files with 184 additions and 1 deletions
181
PREMIERE-HEURE.md
Normal file
181
PREMIERE-HEURE.md
Normal file
|
|
@ -0,0 +1,181 @@
|
|||
# La première heure — adresses et comptes
|
||||
|
||||
> **Pour qui :** l'**exploitant**, devant le matériel de TechnoLibre, avant tout déploiement.
|
||||
|
||||
Proxmox et OPNsense sont déjà installés. Ce document ne fait qu'une chose : leur donner les
|
||||
**bonnes adresses** et les **comptes** dont Set-OPS a besoin pour agir. Rien n'est déployé
|
||||
ici ; on rend seulement les deux machines joignables et pilotables.
|
||||
|
||||
**L'ordre n'est pas indifférent.** La frontière porte la passerelle de chaque zone : si elle
|
||||
n'est pas posée, le nœud aura des adresses qui ne mènent nulle part, et le diagnostic
|
||||
parlera de réseau alors qu'il s'agira d'une patte manquante.
|
||||
|
||||
---
|
||||
|
||||
## 0 · Se poser sur son réseau d'administration
|
||||
|
||||
Avant tout, donner au poste une adresse secondaire — c'est de là que tout se fait.
|
||||
|
||||
```
|
||||
sudo ip addr add 10.31.0.17/24 dev <ta-carte>
|
||||
```
|
||||
|
||||
De cette adresse tu atteindras la frontière (`.1`), le nœud (`.41`) et, plus tard, le
|
||||
rebond vers les machines du site. C'est exactement ce que tu fais déjà chez toi avec
|
||||
`10.17.0.17` et `10.37.0.17`.
|
||||
|
||||
> À relever avant : l'adresse **actuelle** des deux machines, pour pouvoir y revenir si
|
||||
> une manœuvre coupe l'accès.
|
||||
|
||||
---
|
||||
|
||||
## 1 · La frontière — `portail`
|
||||
|
||||
### 1.1 Les huit pattes
|
||||
|
||||
Une par zone, plus le plan d'administration et le transit. **Le dernier octet est toujours
|
||||
`.1`** : c'est l'invariant dont le devis dérive les règles.
|
||||
|
||||
| Interface | VLAN | Adresse | Ce qu'elle sert |
|
||||
|---|---|---|---|
|
||||
| administration | — | `10.31.0.1/24` | le poste de l'exploitant, le rebond |
|
||||
| transit | 40 | `10.0.4.1/24` | la sortie des locataires |
|
||||
| pilotage | 31 | `10.31.31.1/24` | le runner du site |
|
||||
| autorité | 32 | `10.31.32.1/24` | l'autorité de certification |
|
||||
| génome | 33 | `10.31.33.1/24` | la forge et le cache |
|
||||
| service | 34 | `10.31.34.1/24` | les noms |
|
||||
| sauvegarde | 35 | `10.31.35.1/24` | le dépôt |
|
||||
| supervision | 36 | `10.31.36.1/24` | le témoin |
|
||||
|
||||
### 1.2 Relever les noms d'interface — le piège du jour
|
||||
|
||||
Dans **Interfaces → Assignments**, noter le nom `optN` attribué à **chacune** des huit,
|
||||
transit compris.
|
||||
|
||||
> Le devis raisonne en **arrivée** : une règle posée sur la mauvaise patte ne correspond
|
||||
> jamais, et rien ne le signale. Ces neuf noms vont dans `opnsense.yml`, et ils doivent
|
||||
> être exacts.
|
||||
|
||||
### 1.3 Le compte d'API
|
||||
|
||||
**System → Access → Users** → nouvel utilisateur `ansible`, puis **api keys** → créer.
|
||||
Le fichier téléchargé contient la clé et le secret.
|
||||
|
||||
Ils vont dans la voûte, **jamais** dans un fichier de plan :
|
||||
|
||||
```
|
||||
cd ../Set-OPS-public
|
||||
ANSIBLE_VAULT_IDENTITY_LIST="$(python3 scripts/voutes.py identites)" \
|
||||
ansible-vault edit ../SITE-Technolibre/underlay.vault.yml
|
||||
```
|
||||
|
||||
→ `vault_opnsense_api_key` et `vault_opnsense_api_secret`, déjà déclarés vides.
|
||||
|
||||
### 1.4 L'accès SSH
|
||||
|
||||
Le rebond vers les machines du site passe par la frontière. Créer l'utilisateur `ansible`
|
||||
avec accès shell, et y poser cette clé publique :
|
||||
|
||||
```
|
||||
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICf8ecGQ555LuTDaFaqzc3SG+wy0Y8ECqmsIRxemc0dM Cle ansible pour le royaume technolibre
|
||||
```
|
||||
|
||||
Vérifier ensuite, depuis le poste :
|
||||
|
||||
```
|
||||
ssh ansible@10.31.0.1 'echo ok; sudo -n true && echo "sudo ok"'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2 · Le nœud — `atelier`
|
||||
|
||||
### 2.1 Le nom d'hôte
|
||||
|
||||
`atelier` — c'est ce que le plan déclare, et l'API l'utilise comme identifiant dans ses
|
||||
chemins. Un autre nom oblige à corriger `proxmox-hebergeur.yml`.
|
||||
|
||||
### 2.2 Les adresses
|
||||
|
||||
Un seul pont, **VLAN-aware**, portant tout :
|
||||
|
||||
| Réseau | VLAN | Adresse |
|
||||
|---|---|---|
|
||||
| administration | — | `10.31.0.41/24` — passerelle `10.31.0.1` |
|
||||
| transit | 40 | `10.0.4.41/24` |
|
||||
| transport VXLAN | 50 | `10.31.50.41/24` |
|
||||
|
||||
> `vmbr0` doit être **VLAN aware** : sans cela les VLAN des zones ne traverseront pas, et
|
||||
> les VM naîtront sur un réseau muet.
|
||||
|
||||
### 2.3 Le compte d'API
|
||||
|
||||
```
|
||||
pveum user add ansible@pve
|
||||
pveum aclmod / -user ansible@pve -role Administrator
|
||||
pveum user token add ansible@pve set-ops --privsep 0
|
||||
```
|
||||
|
||||
Le **secret n'est affiché qu'une fois**. Il va dans la voûte, sous
|
||||
`proxmox_api_token_id` et `proxmox_api_token_secret`.
|
||||
|
||||
> **Sur `Administrator`, autant le dire franchement.** Le minimum est `VM.Allocate`,
|
||||
> `VM.Clone`, `VM.Config.*`, `Datastore.AllocateSpace` et les droits SDN. Mais l'outil crée
|
||||
> aussi des objets réseau et détruit des VM : partir large le premier jour évite de courir
|
||||
> après des `403` pendant le déploiement. Le resserrer ensuite est un rôle sur mesure, dix
|
||||
> minutes — et c'est un geste à faire, pas une intention.
|
||||
|
||||
### 2.4 Le gabarit doré
|
||||
|
||||
Depuis la clé USB, dossier `gabarits/` :
|
||||
|
||||
```
|
||||
qmrestore vzdump-qemu-9006-*.vma.zst 9006 --storage local-lvm
|
||||
qm template 9006
|
||||
qm config 9006 | grep -E '^(name|machine|bios|template)'
|
||||
```
|
||||
|
||||
Attendu : `name=modeleSetOPS-minimal`, `machine=q35`, `bios=ovmf`, `template=1`.
|
||||
|
||||
> `--storage` est **obligatoire** : le disque vient d'un Ceph qui n'existe pas ici.
|
||||
> Et `qm template` est ce qui rend la VM clonable — sans lui, le clonage refusera.
|
||||
|
||||
### 2.5 Mesurer avant de matérialiser
|
||||
|
||||
```
|
||||
vgs ; df -h
|
||||
```
|
||||
|
||||
Quinze clones **complets** demandent environ 600 Go. C'est la seule décision de ce document
|
||||
qui peut encore changer, et elle se prend avec un chiffre sous les yeux.
|
||||
|
||||
---
|
||||
|
||||
## 3 · Renseigner ce qu'on a relevé
|
||||
|
||||
Dans `opnsense.yml` — les neuf noms d'interface et les deux adresses de la frontière.
|
||||
Dans la voûte — les quatre jetons.
|
||||
|
||||
Puis, depuis `Set-OPS-public` avec le lien `underlay.yml` pointant sur ce site :
|
||||
|
||||
```
|
||||
make site-intrants # ce que le site exposera à ses locataires
|
||||
python3 scripts/devis_reseau.py # ce qu'il faut poser sur le commutateur
|
||||
python3 scripts/devis_sdn.py --verifier
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ce qui est déjà décidé, et qu'il suffit de confirmer
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| Index du site | `31` |
|
||||
| Domaine | `socle.internal` |
|
||||
| Routage des locataires | `sdn` — EVPN sur le nœud, ASN `65031`, contrôleur `EVPN0031` |
|
||||
| Pont | `vmbr0`, VLAN-aware |
|
||||
| Stockage | `local-lvm` |
|
||||
| Gabarit | `9006` — `99998` est son précédent, jamais cloné |
|
||||
|
||||
Dix des quatorze secrets du site sont déjà engendrés. Les quatre restants sont les jetons
|
||||
ci-dessus.
|
||||
|
|
@ -10,7 +10,9 @@ organisation: TechnoLibre
|
|||
# Par où l'administration entre. Chez Chezlepro c'est la patte LAN de la frontière ;
|
||||
# ici ce sera la patte de gestion de l'OPNsense (10.23.0.1) ou un accès direct.
|
||||
rebond: ansible@10.31.0.1
|
||||
cle_ssh: ~/.ssh/technolibre
|
||||
# LE NOM REEL DE LA CLE, pas un nom plausible. Celle-ci existe sur le poste et sert
|
||||
# deja a la flotte de TechnoLibre ; `~/.ssh/technolibre` ne designait rien.
|
||||
cle_ssh: ~/.ssh/id_ed25519_ansible_technolibre
|
||||
|
||||
integrations_exemptes: {}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue