So che non è un compito facile. Tuttavia, lo scopo dei container è garantire uno stato coerente e portatile. Quindi, se i container vengono utilizzati come dovrebbero e funzionano per te, c’è un’alta probabilità che funzionino per chiunque utilizzi quel container.
Se il processo di bootstrap venisse spostato all’interno del container, invece di essere eseguito sull’host, si farebbe già un grande passo avanti verso la portabilità. Posso darci un’occhiata dopo aver terminato altri progetti. Nemmeno io sono un esperto di container, ma ne ho costruiti alcuni. Lo svantaggio, però, è che non esiste documentazione di installazione, giusto? È semplicemente: “Eccolo, esegui questo script”. Potrei provare a replicare ciò che fa lo script, ma questo non lascia molto spazio a suggerimenti di miglioramento.
Quindi, se la comunità, in particolare le persone coinvolte da vicino e che hanno informazioni interne su come dovrebbe funzionare l’installazione, sono disposte a dare consigli o aiuto, allora sono disposto a lanciare questa iniziativa. Altrimenti, la qualità non sarà quella che ci si aspetta.
Gli obiettivi sarebbero più o meno i seguenti:
- Un Dockerfile che preveda una build atomica dell’ambiente (nessun bootstrap locale esterno al container)
- Nessuna necessità di eseguire il container come root; l’ideale è utilizzare fakeroot e aggiungere capabilities (questi sono argomenti da riga di comando; gli utenti possono comunque scegliere di avviare un container come root…)
- Creare uno script di entrypoint influenzabile da variabili d’ambiente, che devono essere chiaramente documentate
- Utilizzare
podman-generate-systemdo qualcosa di simile per creare un’unità systemd per (ri)avviare un container o avviarne uno all’avvio del sistema (funzionalità di Podman; forse Docker ha qualcosa di simile, ma è più orientato all’integrazione)
Questo sarebbe per l’installazione di base. Per una soluzione scalabile, è necessaria una soluzione docker-compose e Kubernetes. Onestamente, non ritengo che sia responsabilità della comunità Discourse trovare una soluzione universale, poiché questi aspetti possono essere adattati con grande precisione, specialmente su Kubernetes. Quindi, immagino che una soluzione compose di base sia sufficiente per permettere alle persone di prendere confidenza.
Questo fornirebbe una soluzione portatile e più sicura, aumentando l’adozione e la qualità complessiva. Nel frattempo, verificherò se Discourse è davvero ciò di cui ho bisogno per la mia comunità. Se lo è, per ora utilizzerò un sistema Ubuntu LTS. Quando avrò più tempo, investirò nello sviluppo di un tale ambiente.