Convention de nommage
Cette convention s'applique à tout ce qu'on nomme dans l'infrastructure Spektrum : conteneurs, bases de données, utilisateurs SQL, volumes, hostnames, mots de passe. L'objectif est qu'on puisse deviner à quoi sert une ressource juste à partir de son nom, sans devoir ouvrir un wiki ou demander à un collègue.
Règle d'or
Si tu hésites entre deux noms, choisis celui qu'un nouveau collaborateur comprendrait sans contexte.
Skin - clef client
Chaque projet ou client est identifié par un skin : un identifiant court, unique, réutilisé partout (conteneurs, DB, volumes, secrets, dossiers).
Règles
| Règle | Détail |
|---|---|
| Longueur | 3 à 15 caractères |
| Casse | Minuscules uniquement |
| Caractères autorisés | a-z et 0-9 |
| Interdits | Espaces, accents, tirets, underscores, caractères spéciaux |
| Unicité | Doit être unique dans l'infrastructure |
Comment le construire
- Nom raccourci :
coteminceur=>cotemin - Acronyme existant : Association des Communes de Crans-Montana (ACCM) =>
accm - Marque courte déjà :
psymed=>psymed
Exemples utilisés en production
| Skin | Client |
|---|---|
cotemin | Côté Minceur |
accm | Association des Communes de Crans-Montana |
fctvs | Fête Cantonal de Tir du Valais |
apol | Association Police Lavaux |
Le skin est immuable
Une fois choisi, le skin se retrouve dans des dizaines d'endroits (DNS, secrets, volumes, backups, IAM). Ne le change jamais une fois en prod - crée plutôt un alias si nécessaire.
Environnements
Les cinq environnements standard, du plus volatile au plus critique :
| Code | Usage |
|---|---|
dev | Poste développeur, jetable |
test | Tests automatisés, CI |
staging | Recette interne, démo client |
preprod | Iso-prod, dernier filet avant mise en ligne |
prod | Production |
Pas tous les projets ont les 5
La plupart des sites tournent avec staging + prod uniquement. preprod n'est ajouté que sur les projets sensibles (e-commerce, intégrations critiques).
Conteneurs Docker
Format général :
<type>_<skin>_<env>Types standards
| Type | Stack / rôle |
|---|---|
umb | Umbraco (CMS .NET) |
nop | nopCommerce (e-commerce .NET) |
app | Application custom (.NET, Node, autre) |
worker | Background worker, traitement asynchrone |
cron | Tâches planifiées |
proxy | Reverse proxy applicatif (NGINX, Traefik) propre au site |
db | Base de données embarquée au stack |
cache | Cache (Redis, Memcached) |
queue | Broker de messages (RabbitMQ) |
search | Moteur de recherche (ElasticSearch, Meilisearch) |
Exemples
umb_cotemin_prod
umb_cotemin_staging
nop_apol_prod
app_accm_staging
worker_apol_prod
proxy_cotemin_prodTri alphabétique gratuit
Le <type> en premier permet de regrouper visuellement les conteneurs par rôle dans docker ps ou Portainer. C'est pour ça que le pattern n'est pas <skin>_<type>_<env>.
Bases de données
Même format que les conteneurs :
<type>_<skin>_<env>Types standards
| Type | Usage |
|---|---|
umb | Base Umbraco |
nop | Base nopCommerce |
app | Base applicative custom |
log | Logs, monitoring, audit |
cache | Données temporaires, sessions |
search | Index de recherche persisté |
Exemples
umb_cotemin_prod
umb_cotemin_staging
nop_apol_prod
log_apol_prodUtilisateurs SQL
Un utilisateur SQL par stack applicatif, jamais d'utilisateur partagé entre projets :
<type>user-<skin>| Exemple | Donne accès à |
|---|---|
umbracouser-apol | Bases umb_apol_* |
nopuser-apol | Bases nop_apol_* |
appuser-accm | Bases app_accm_* |
Pas de compte SQL multi-environnements
Chaque environnement a son propre compte. Un dump prod restauré en staging ne doit pas pouvoir se reconnecter avec les credentials staging par accident.
Hostnames / FQDN
Format général pour les services exposés :
<service>.<env>.spektrum-suisse.chPour les sites clients en production, le FQDN est dicté par le client (www.exemple.ch). Pour tout ce qui est interne ou outillage, on suit la convention.
Exemples
| Hostname | Usage |
|---|---|
ftp.staging.spektrum-suisse.ch | Serveur FTPS staging |
ftp.prod.spektrum-suisse.ch | Serveur FTPS production |
<skin>.staging.spektrum-suisse.ch | Site client en recette |
Volumes et disques
Les volumes Infomaniak sont identifiés par un label ext4 court (max 16 caractères). On utilise une forme abrégée du skin pour rester dans la limite :
<skin-court>-<usage>-<env>Exemples
| Label | Volume |
|---|---|
tsc-ftp-prod | Volume FTP de The Swiss Collector (prod) |
hvs-ftp-prod | Volume FTP de l'Hôpital Valais (prod) |
apol-data-prod | Volume de données Apol (prod) |
Limite ext4 = 16 caractères
Le label ext4 est tronqué à 16 caractères. Si ton skin fait déjà 8 caractères, il ne te reste que 7 pour <usage>-<env>. Privilégie une forme abrégée du skin (tsc plutôt que theswisscollector) uniquement pour les labels de volumes.
Mots de passe (services cloud)
Pour tout ce qui touche à un service cloud (panel admin, API key longue durée, console infra) :
Suisse-<Internal|Prod|Sysadmin>-<Service>| Exemple | Usage |
|---|---|
Suisse-Internal-Homarr | Compte admin Homarr du sous-réseau internal |
Suisse-Prod-NGINX | Accès au reverse proxy NGINX en prod |
Suisse-Sysadmin-Guardian | Compte admin du gestionnaire de secrets |
Récap - antipatterns à éviter
| Symptôme | Cause | Fix |
|---|---|---|
umb-cotemin-prod (avec tirets) | Mélange tirets/underscores | Underscores partout dans les noms Docker/DB |
UMB_Cotemin_PROD | Casse non respectée | Tout en minuscules |
app_côté-minceur_prod | Accents et caractères spéciaux | Refaire le skin sans accents (cotemin) |
Label volume cotemin-data-prod rejeté | Dépasse 16 caractères | Skin abrégé pour les labels (cmin-data-prod) |
Compte SQL appuser partagé | Pas de skin dans le nom | Un compte par projet : appuser-<skin> |

