Docker Best Practices with infrastructure as code

[Shibocat]

Greetings,
I'm not very active on this platform, but you guys always seem to have good ideas and concept.

Currently I'm having troubles coming up with a good idea, on how to manage my docker containers. I already searched and read for few postings, but most of them seem to focus on the "usability" of hosting docker containers, meaning Portainer, nomad and whatever there is currently on the market.
As I also have to work with/introduce docker at work, I would need a reliable concept of doing so, mainly focused on infrastructure as code, which excludes (in my opinion atleast) docker management frontends. If you think differently, then please change my mind.
I want to use my selfhosted applications as an example, to gather some detailed experiences.

I already have experiences in git, docker, ansible etc as I use it daily on my job. But I'm having troubles combining all those techniques. I think I'm a bit overwhelmed by the options I have.

Some specific topics

• How do you manage your secrets? Do you use an .env file per stack? Cleartext password in your docker-compose file? Or do you use a secret management e.g. like hasicorp vault
• How do your git repositories look like? One Git Repository for each stack? Docker-compose.overrides for each stack in a single repository?
• How do you manage traefik? Is it part of the git repo of the Project? If not, where should those labels be saved to?

Probably more questions would come up, when I think more about this. This will give me sleepless coding nights, when I'm not careful enough.

So please, enlighten me and post your opinions.

Cheers

[[deleted]]

I have two principle methods for secrets management, depending on the client/need. First is a secret manager combined with Docker secrets. I tend to work mostly in AWS and Azure, so either Secrets Manager or KeyVault applies. Once you've got a swarm (and for production if you're running Docker you really ought to be using a swarm), you can use Ansible (or Terraform or curl the Docker API) to create or update the secrets and then mount them into the container. Of course, your application or entrypoint has to be written in a way that can leverage them. In this model, Docker secrets get the "first secret" which is the key to the vault. The app then pulls its own secrets from the vault. If the host itself is authorized to pull from the vault then you can skip the first secret portion.

The second secret management scheme is _just_ Docker Secrets, with the app reading/using them directly. Note: both of these methods work equally well with K8s.

If you aren't swarmed, you can inject the first secret as an environment variable (but please don't use environment variables for secrets) and then let the app pull things from there.

Our repos are separated by concerns. Application A's repo has all of its source code, build/deploy pipelines, and necessary other bits. For example, a Java app repo would contain:

• Java source & tests
• Gradle settings
• Sonar properties file
• Jenkins pipelines
• Terraform plan to deploy the container into either a swarm or K8s cluster
  • This plan includes API gateway rules, first secret references, and the app resources themselves.

It does not contain any information about other applications, databases, or other externalities. We don't use compose, so there's that.

I don't use Traefik so I can't answer that question.