Docker Community Forums

Share and learn in the Docker community.

Alternatives to labels?

General Discussions
#1

I’m working on a web interface to manage docker containers:
Yacht (Essentially trying to make a clean interface that utilizes a tempting system to enable people to host their own container “App Stores”)

I’m trying to think of a good way for someone to add a description for ports of various containers so that when someone is deploying a container there’s an easy way for them to tell what a port is used for and then be able to reference that when they go to a detailed view of a running container.

From the documentation I’ve seen it looks like labels should be used for this so that I can easily pull the information from the docker socket and provide it to the user. I was just wanting to check and make sure this is a valid way to use labels and see if there isn’t a better way to store/retrieve that information.

#2

With Docker labels are the only way I can see, if you realy want to store the details within the container engine itself. Though be aware that labels for docker containers and swarm services are at different locations in docker-compose.ymls and of course if requested from the api, on different api endpoints.

#3

I’m using docker-py to grab the information so hopefully it’ll stay in the same place there. Thanks for the information!

#4

Unless a container is replaced, it will be at the same place.

Though, swarm services will create a new task (which itself will create the container) everytime a replica of a service is started (think of system reboots, restarts on failure). If you update a tag for images in a docker-compose deployment, it will replace the container as well. So on a second though, maybe labels are not the most reliable way to store the details.

In Kuberentes you often encounter that people store information within the cluster using configmaps (which would translate to docker configs) and secrets, since you instrument the api, you potentialy could do the same. In your usecase, its irrelevant if deployed containers - other than yours that uses the api to access them - can access them :slight_smile: Though, you would need to keep them consistent with the current deployment state. Does that make sense?

#5

I would like to not have to manage detecting new containers not deployed by my app in order to pull information from them if I can help it. Currently I’m just getting all the information from the docker socket which allows for detection of all running containers regardless of if they were deployed by my app or not which is how I would like to keep it. The less I have to keep track of the better as I’ve got enough I have to keep up with as it is :sweat_smile:.

#6

:rofl: I am not sure what to make from your response.
Though, it seems like you have sorted out a way and want to keep it that way :slight_smile: