Specify Running Container on Backup Page from Env Vars in yml file

[neounix (Dark Matter)]

Proposed Plugin: discourse-container-names.git

What would you like done?

I would like a simple plugin which displays the container name(s) on the backups page, as follows (example):

The name of the container should come from environmental variable(s) in the yml file, as follows:

Application Notes:

1. The name of the container must come from the environmental variable(s) as shown in the image above (not from docker ps, for example)

2. In the case where there is a data container and a application container, it would be nice to have the name of the data container as well:

• Container: app basic standalone name example
• Containers: socket-only, data basic two container setup example

3. The reason for this is that we run multiple app containers, and I want to always know which container is running when looking at the admin pages, and in particular the backup page (per the first image).

When do you need it done?

Anytime. No hurry. Seems like a very simple plugin for Discourse plugins experts. It’s just a “nice to have” for the admin backup page and I’m not motivated to write it myself, so happy to pay someone a reasonable fee to do it!

What is your budget, in $ USD that you can offer for this task?

Feel free to PM me.

The plugin should be made freely available to the Discourse community at large in case there are other Discourse sys admins who run multiple containers and wish to see the name of the current running container in the backup page of the admin panel; or for anyone who wants to see the name of their running container (even if in standalone mode) on the backups page.

[RGJ (Richard - Communiteq)]

A great idea, how about adding the actual container ID as well?

It can be looked up from within the container like this:
cat /proc/self/cgroup|grep "systemd:/docker"| awk -F/ '{print $3}'|cut -c1-12

[neounix (Dark Matter)]

Thanks but having a platform dependent command line utility in the plugin to get the information does not work (as required) for me (getting the docker id from the command below, does not work on our Ubuntu 18.04 setup):

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

#. (no results)

even this yields no fruit:

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

#  (no results)

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

This means that the info (the string which specifies the running container name) should derive from an environmental var in the yml file. to insure the information is platform neutral and can work when many containers are running.

For example, we run multiple Discourse app and other containers at the same time and so using docker-cli commands will not provide the exact info we need (the name of the running container on the web “at the time” which is determined by the reverse proxy configuration, not docker)

We select which container to display by changing the name of the unix socket (or the exposed container port) in the reverse proxy configuration, so we change containers in less than a second with zero downtime. This means the name of the container should (must) come from an env var in the yml file to be 100% reliable and accurate.

Hence, my requirement for the string (name of container, container id, etc.) to only come from environmental variables in the yml file.

For anyone who prefers the container id , they could add that to their env var like this (for example):

DISCOURSE_APP_CONTAINER_NAME = 'socket-only (63c52bc571b5)'

or even:

DISCOURSE_APP_CONTAINER_NAME = '63c52bc571b5'
DISCOURSE_DATA_CONTAINER_NAME = 'ca7b55fc5a0c'

and per my original post (the way we want to use it):

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

Which string (token) identifier (name, container id, or both) to use would be based on the requirements of the sys admin (or business).

This is why I was specific to specify that the information must be hardcoded into the main app yml file as an env var (not from CLI commands like docker ps or other OS (platform) dependent commands).

Hope that makes my requirement more clear.

I want to this to be platform and configuration neutral and not dependent on CLI commands or system commands. We run Docker for many other apps and not only Discourse on our servers (including Discourse, Dockerized LAMP apps, Docker private registries and more, as you can see from a sample docker ps output above.).

[RGJ (Richard - Communiteq)]

@neounix

platform dependent command line utility

You are completely right!

[neounix (Dark Matter)]

@RGJ

You are completely right!

Hi @RGJ,

Just one follow-up thought:

The corner case, where hard coding the container identifiers (be it container id, name or both) as yml env vars may not work, is with Docker Swarm or Kubernetes (examples); because when containers are dynamic based on load and / or fault, hard-coding env vars in yml will not work (I assume, but have not yet done it to speak with authority on the subject); but I’m willing to go with the “simple approach” for now (env vars in yml).

Anyway, I have not yet deployed Discourse with Swarm or Kuber, so my plan was to cross that bridge when I come to it later

I have given a lot of thought to this, and that is why I have decided the best route at this point in time is to go with Discourse environmental vars hard-coded into the yml file(s).

It should be a relative easy task to take these env vars, as site settings, and display them on the admin backups page per my quick little mockup: