Specifica il contenitore in esecuzione nella pagina di backup tramite variabili d'ambiente nel file yml

[neounix (Dark Matter)]

Plugin proposto: discourse-container-names.git

Cosa vorresti che venisse fatto?

Vorrei un plugin semplice che mostri il/i nome/i del container nella pagina dei backup, come segue (esempio):

Il nome del container deve provenire dalle variabili d’ambiente presenti nel file yml, come mostrato di seguito:

Note sull’applicazione:

1. Il nome del container deve provenire dalle variabili d’ambiente come mostrato nell’immagine sopra (non da docker ps, ad esempio).

2. Nel caso in cui ci sia un container dati e un container applicazione, sarebbe utile avere anche il nome del container dati:

• Container: app # esempio base con nome singolo
• Containers: socket-only, data # esempio base con configurazione a due container

3. Il motivo è che eseguiamo più container applicazione e voglio sempre sapere quale container è in esecuzione quando visualizzo le pagine di amministrazione, in particolare la pagina dei backup (come mostrato nella prima immagine).

Quando hai bisogno che sia fatto?

In qualsiasi momento. Nessuna fretta. Sembra un plugin molto semplice per gli esperti di plugin Discourse. È solo un “nice to have” per la pagina dei backup dell’amministratore e non ho la motivazione per scriverlo da solo, quindi sono felice di pagare una tariffa ragionevole a qualcuno per farlo!

Qual è il tuo budget, in $ USD, che puoi offrire per questo compito?

Sentiti libero di inviarmi un messaggio privato.

Il plugin dovrebbe essere reso liberamente disponibile all’intera comunità Discourse, nel caso ci siano altri amministratori di sistema Discourse che eseguono più container e desiderano vedere il nome del container attualmente in esecuzione nella pagina dei backup del pannello di amministrazione; oppure per chiunque voglia vedere il nome del proprio container in esecuzione (anche in modalità standalone) nella pagina dei backup.

[RGJ (Richard - Communiteq)]

Ottima idea, che ne dici di aggiungere anche l’ID effettivo del contenitore?

Può essere recuperato dall’interno del contenitore in questo modo:
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

Grazie, ma l’utilizzo di uno strumento da riga di comando dipendente dalla piattaforma all’interno del plugin per ottenere le informazioni non funziona (come richiesto) per me (l’ottenimento dell’ID Docker dal comando sottostante non funziona nella nostra configurazione Ubuntu 18.04):

# cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

#. (nessun risultato)

nemmeno questo dà frutti:

# cat /proc/self/cgroup|grep "systemd:/docker"

#  (nessun risultato)

FYI (da docker ps):

CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS                  PORTS                               NAMES
63c52bc571b5        local_discourse/socket-only     "/sbin/boot"             28 minutes ago      Up 28 minutes                                               socket-only
631fbabedda9        local_discourse/socket-only2    "/sbin/boot"             26 hours ago        Up 26 hours                                                 socket-only2
123743e12208        mysql/mysql-server              "/entrypoint.sh mysq…"   2 days ago          Up 20 hours (healthy)   33060/tcp, 0.0.0.0:6603->3306/tcp   mysql-man
7a145366268c        registry.unix.com/unix:condor   "/run.sh"                6 days ago          Up 20 hours             3306/tcp, 0.0.0.0:8999->80/tcp      unix
3cc0c90c3e3a        registry:2                      "/entrypoint.sh /etc…"   7 days ago          Up 7 days               0.0.0.0:5000->5000/tcp              hubby
ca7b55fc5a0c        local_discourse/data            "/sbin/boot"             2 weeks ago         Up 8 days                                                   data

Ciò significa che le informazioni (la stringa che specifica il nome del contenitore in esecuzione) dovrebbero essere derivate da una variabile d’ambiente nel file yml. Questo per garantire che le informazioni siano indipendenti dalla piattaforma e funzionino anche quando molti contenitori sono in esecuzione.

Ad esempio, eseguiamo contemporaneamente più applicazioni Discourse e altri contenitori, quindi l’uso di comandi docker-cli non fornirà le informazioni esatte di cui abbiamo bisogno (il nome del contenitore in esecuzione sul web “al momento”, che è determinato dalla configurazione del reverse proxy, non da Docker).

Selezioniamo quale contenitore visualizzare modificando il nome del socket Unix (o della porta esposta del contenitore) nella configurazione del reverse proxy, in modo da cambiare contenitore in meno di un secondo con zero tempi di inattività. Ciò significa che il nome del contenitore deve provenire da una variabile d’ambiente nel file yml per essere al 100% affidabile e accurato.

Di conseguenza, la mia richiesta è che la stringa (nome del contenitore, ID contenitore, ecc.) provenga esclusivamente dalle variabili d’ambiente nel file yml.

Per chiunque preferisca l’ID del contenitore, potrebbe aggiungerlo alla propria variabile d’ambiente in questo modo (ad esempio):

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

o anche:

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

e come nel mio post originale (il modo in cui vogliamo utilizzarlo):

DISCOURSE_APP_CONTAINER_NAME = 'socket-only'
DISCOURSE_DATA_CONTAINER_NAME = 'data'

Quale identificatore (token) utilizzare (nome, ID contenitore o entrambi) dipenderà dai requisiti dell’amministratore di sistema (o dell’azienda).

Per questo motivo ho specificato che le informazioni devono essere hardcoded nel file yml principale dell’app come variabile d’ambiente (non da comandi CLI come docker ps o altri comandi OS dipendenti dalla piattaforma).

Spero che questo renda più chiara la mia richiesta.

Voglio che questo sia indipendente dalla piattaforma e dalla configurazione e non dipenda da comandi CLI o di sistema. Eseguiamo Docker per molte altre applicazioni e non solo per Discourse sui nostri server (inclusi Discourse, applicazioni LAMP containerizzate, registri privati Docker e altro, come si può vedere dall’esempio di output docker ps sopra).

[RGJ (Richard - Communiteq)]

@neounix

utility da riga di comando dipendente dalla piattaforma

Hai assolutamente ragione!

[neounix (Dark Matter)]

@RGJ

Hai assolutamente ragione!

Ciao @RGJ,

Solo un ulteriore pensiero:

Il caso limite in cui hardcodare gli identificatori dei container (sia esso l’ID del container, il nome o entrambi) come variabili d’ambiente in YAML potrebbe non funzionare si presenta con Docker Swarm o Kubernetes (ad esempio); poiché quando i container sono dinamici in base al carico e/o ai guasti, hardcodare le variabili d’ambiente in YAML non funzionerà (lo suppongo, ma non l’ho ancora fatto per poter parlare con autorità sull’argomento); ma sono disposto ad adottare l’“approccio semplice” per ora (variabili d’ambiente in YAML).

Comunque, non ho ancora distribuito Discourse con Swarm o Kubernetes, quindi il mio piano era di affrontare quel problema quando ci sarei arrivato

Ci ho riflettuto molto e per questo ho deciso che la strada migliore al momento è quella di hardcodare le variabili d’ambiente di Discourse nei file YAML.

Dovrebbe essere un compito relativamente semplice prendere queste variabili d’ambiente, trattarle come impostazioni del sito e visualizzarle nella pagina dei backup dell’amministratore, come mostrato nel mio rapido mockup: