Especificar container em execução na página de backup a partir de variáveis de ambiente no arquivo yml

[neounix (Dark Matter)]

Plugin Proposto: discourse-container-names.git

O que você gostaria que fosse feito?

Gostaria de um plugin simples que exiba o(s) nome(s) do(s) container(s) na página de backups, conforme o exemplo a seguir:

O nome do container deve ser obtido a partir de variáveis de ambiente no arquivo yml, conforme mostrado abaixo:

Observações sobre a aplicação:

1. O nome do container deve ser obtido das variáveis de ambiente, conforme mostrado na imagem acima (e não, por exemplo, a partir de docker ps).

2. No caso em que há um container de dados e um container de aplicação, seria interessante exibir também o nome do container de dados:

• Container: app #exemplo básico de nome único
• Containers: socket-only, data #exemplo básico de configuração com dois containers

3. O motivo para isso é que executamos múltiplos containers de aplicação, e quero saber sempre qual container está em execução ao acessar as páginas de administração, em particular a página de backups (conforme a primeira imagem).

Quando você precisa que seja feito?

A qualquer momento. Sem pressa. Parece um plugin muito simples para especialistas em plugins do Discourse. É apenas um “desejável” para a página de backups de administração, e não tenho motivação para escrevê-lo eu mesmo, então estou feliz em pagar uma taxa razoável a alguém para fazê-lo!

Qual é o seu orçamento, em dólares americanos (USD), que você pode oferecer para esta tarefa?

Sinta-se à vontade para me enviar uma mensagem privada (PM).

O plugin deve ser disponibilizado gratuitamente para toda a comunidade do Discourse, caso haja outros administradores de sistemas do Discourse que executem múltiplos containers e queiram ver o nome do container em execução atual na página de backups do painel administrativo; ou para qualquer pessoa que queira ver o nome do seu container em execução (mesmo que em modo standalone) na página de backups.

[RGJ (Richard - Communiteq)]

Ótima ideia, que tal adicionar também o ID real do container?

Ele pode ser consultado de dentro do container assim:
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

Obrigado, mas ter um utilitário de linha de comando dependente da plataforma no plugin para obter as informações não funciona (como necessário) para mim (obter o ID do Docker a partir do comando abaixo não funciona na nossa configuração Ubuntu 18.04):

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

#. (sem resultados)

Até mesmo isso não produz resultados:

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

#  (sem resultados)

FYI (de 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

Isso significa que as informações (a string que especifica o nome do container em execução) devem ser derivadas de uma variável de ambiente no arquivo yml. Isso garante que as informações sejam neutras em relação à plataforma e funcionem mesmo quando vários containers estão em execução.

Por exemplo, executamos múltiplos aplicativos Discourse e outros containers simultaneamente, portanto, usar comandos do docker-cli não fornecerá as informações exatas de que precisamos (o nome do container em execução na web “no momento”, que é determinado pela configuração do proxy reverso, não pelo Docker).

Selecionamos qual container exibir alterando o nome do socket Unix (ou a porta exposta do container) na configuração do proxy reverso, permitindo trocar de containers em menos de um segundo com tempo de inatividade zero. Isso significa que o nome do container deve (obrigatoriamente) vir de uma variável de ambiente no arquivo yml para ser 100% confiável e preciso.

Portanto, minha exigência é que a string (nome do container, ID do container, etc.) venha apenas de variáveis de ambiente no arquivo yml.

Para quem prefere o ID do container, pode adicioná-lo à sua variável de ambiente assim (por exemplo):

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

ou até mesmo:

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

e, conforme meu post original (a forma como queremos usar):

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

Qual identificador de string (token) (nome, ID do container ou ambos) usar dependerá dos requisitos do administrador do sistema (ou da empresa).

É por isso que fui específico ao exigir que as informações sejam codificadas no arquivo yml principal do aplicativo como uma variável de ambiente (não a partir de comandos de CLI como docker ps ou outros comandos do sistema operacional dependentes da plataforma).

Espero que isso tenha tornado minha exigência mais clara.

Quero que isso seja neutro em relação à plataforma e à configuração, sem depender de comandos de CLI ou comandos do sistema. Executamos o Docker para muitos outros aplicativos e não apenas o Discourse em nossos servidores (incluindo Discourse, aplicativos LAMP Dockerizados, registros privados do Docker e muito mais, como você pode ver na saída de exemplo do docker ps acima.).

[RGJ (Richard - Communiteq)]

@neounix

utilitário de linha de comando dependente da plataforma

Você está completamente certo!

[neounix (Dark Matter)]

@RGJ

Você está completamente certo!

Olá @RGJ,

Apenas mais uma reflexão complementar:

O caso limite em que a codificação rígida dos identificadores de contêiner (seja ID, nome ou ambos) como variáveis de ambiente no YAML pode não funcionar ocorre com Docker Swarm ou Kubernetes (como exemplos); pois, quando os contêineres são dinâmicos com base na carga e/ou falhas, codificar variáveis de ambiente no YAML não funcionará (assumo, mas ainda não implementei isso para falar com autoridade sobre o assunto); no entanto, estou disposto a seguir com a “abordagem simples” por enquanto (variáveis de ambiente no YAML).

De qualquer forma, ainda não implementei o Discourse com Swarm ou Kubernetes, então meu plano é resolver esse problema quando ele surgir mais tarde

Refleti bastante sobre isso e, por isso, decidi que a melhor rota neste momento é utilizar as variáveis de ambiente do Discourse codificadas rigidamente no(s) arquivo(s) YAML.

Deveria ser uma tarefa relativamente simples pegar essas variáveis de ambiente, tratá-las como configurações do site e exibi-las na página de backups do administrador, conforme meu rápido esboço: