Damien/infra-scripts
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Le mode update doit aussi mettre à jour l'OS, pas seulement le binaire applicatif #15

New Issue
Closed
opened 2026-07-30 09:00:01 +00:00 by Damien · 0 comments
Damien commented 2026-07-30 09:00:01 +00:00
Owner
Copy Link
Copy Source

Contexte

Sur un conteneur déjà provisionné, relancer le script doit rafraîchir à la fois les paquets de l'OS et le binaire applicatif. Ce n'est pas homogène aujourd'hui :

  • openbao : ✅ update_lxc() (host) fait apk update && apk upgrade avant de déléguer à exec_in_lxc --update, et update_inside_lxc() refait apk update && apk upgrade avant install_or_upgrade_bao.
  • gitea-runner : ❌ deux problèmes cumulés :
    1. Pas de mise à jour OS du tout — update_runner() (inside LXC) télécharge juste la nouvelle release act_runner, sans jamais faire apk update/apk upgrade.
    2. Pas de détection de conteneur existant côté host — contrairement à openbao (find_existing_lxc + update_lxc), gitea-runner n'a pas cette logique : dans main(), si on relance le script depuis l'hôte Proxmox, il appelle directement create_lxc à chaque fois, sans jamais vérifier si une LXC gitea-runner existe déjà. Relancer le script depuis le host ne met donc jamais à jour un conteneur existant — il tente d'en recréer un.

Règle à appliquer

Pour tout script créateur de LXC :

  • Le mode update (déclenché depuis l'hôte sur un conteneur existant, ou lancé directement depuis l'intérieur de la LXC) doit systématiquement :
    1. Rafraîchir les paquets de l'OS (apk update && apk upgrade / apt-get update && apt-get upgrade).
    2. Mettre à jour le binaire/l'application elle-même.
  • C'est à l'utilisateur de valider que l'outil fonctionne toujours correctement après une montée de version d'OS (pas de garantie automatique de compatibilité) — le script ne doit pas masquer ce risque, mais ne doit pas non plus l'empêcher.
  • Le host doit toujours être capable de détecter un conteneur existant (par tag/hostname, comme find_existing_lxc dans openbao) et basculer en update plutôt que de recréer.

Proposition

  1. Ajouter find_existing_lxc() + update_lxc() (host-side) à gitea-runner/install.sh, sur le modèle d'openbao.
  2. Ajouter apk update && apk upgrade dans update_runner() de gitea-runner, avant le téléchargement du binaire.
  3. Documenter ce comportement dans les deux README (« une mise à jour rafraîchit aussi l'OS de la LXC »).
  4. Envisager de factoriser ce flux dans le helper partagé (lib/common.sh, voir #12 et #14) puisque la logique host-side (find + refresh OS + delegate) est quasi identique entre openbao et ce que gitea-runner devrait avoir.
## Contexte Sur un conteneur déjà provisionné, relancer le script doit rafraîchir **à la fois** les paquets de l'OS et le binaire applicatif. Ce n'est pas homogène aujourd'hui : - `openbao` : ✅ `update_lxc()` (host) fait `apk update && apk upgrade` avant de déléguer à `exec_in_lxc --update`, et `update_inside_lxc()` refait `apk update && apk upgrade` avant `install_or_upgrade_bao`. - `gitea-runner` : ❌ deux problèmes cumulés : 1. **Pas de mise à jour OS du tout** — `update_runner()` (inside LXC) télécharge juste la nouvelle release `act_runner`, sans jamais faire `apk update`/`apk upgrade`. 2. **Pas de détection de conteneur existant côté host** — contrairement à `openbao` (`find_existing_lxc` + `update_lxc`), `gitea-runner` n'a pas cette logique : dans `main()`, si on relance le script depuis l'hôte Proxmox, il appelle directement `create_lxc` à chaque fois, sans jamais vérifier si une LXC `gitea-runner` existe déjà. Relancer le script depuis le host ne met donc *jamais* à jour un conteneur existant — il tente d'en recréer un. ## Règle à appliquer Pour tout script créateur de LXC : - Le mode update (déclenché depuis l'hôte sur un conteneur existant, ou lancé directement depuis l'intérieur de la LXC) doit systématiquement : 1. Rafraîchir les paquets de l'OS (`apk update && apk upgrade` / `apt-get update && apt-get upgrade`). 2. Mettre à jour le binaire/l'application elle-même. - C'est à l'utilisateur de valider que l'outil fonctionne toujours correctement après une montée de version d'OS (pas de garantie automatique de compatibilité) — le script ne doit pas masquer ce risque, mais ne doit pas non plus l'empêcher. - Le host doit toujours être capable de détecter un conteneur existant (par tag/hostname, comme `find_existing_lxc` dans `openbao`) et basculer en update plutôt que de recréer. ## Proposition 1. Ajouter `find_existing_lxc()` + `update_lxc()` (host-side) à `gitea-runner/install.sh`, sur le modèle d'`openbao`. 2. Ajouter `apk update && apk upgrade` dans `update_runner()` de `gitea-runner`, avant le téléchargement du binaire. 3. Documenter ce comportement dans les deux README (« une mise à jour rafraîchit aussi l'OS de la LXC »). 4. Envisager de factoriser ce flux dans le helper partagé (`lib/common.sh`, voir #12 et #14) puisque la logique host-side (find + refresh OS + delegate) est quasi identique entre `openbao` et ce que `gitea-runner` devrait avoir.
Damien added reference chore/standardize-lxc-scripts 2026-07-30 11:04:30 +00:00
Sign in to join this conversation.
chore/standardize-lxc-scripts
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Damien (Damien Arnodo)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Damien/infra-scripts#15