What about secrets for local development using the Docker Compose command line. We've been talking about
Swarm up until now.
But I'm back on my machine, and I've got Docker Compose installed which I did not have in my swarm,
right?
Because again, Compose is not a production tool.
It's designed for development.
I'm in the same secret sample directory we had before.
You can see that I have the two password files, and the Docker Compose file that we had in the swarm. Just
to prove that I'm not in a swarm,
I can do a docker node
ls, and it will actually tell me this is not a swarm manager.
I'm not in a swarm, so I don't have access to the Swarm database or the ability to put secrets in it.
So, how do we deal with this in local development?
Ideally, we can still use the same Compose file.
We can still use the same objects like the environment variables for postgres.
Docker had to come up with a way to make this work in test and dev.
If we do a docker compose up -d,
and then we did a docker compose exec psql. Then did a cat on run secrets
psql user, how did our secret get in there, right?
Because we don't have the database.
Well, it turns out there's a little bit of magic here.
Well it's not magic. It's just hiding behind the scenes, that what's actually happening with Compose is
not secure, but it does work.
It basically bind mounts at runtime that actual file on my hard drive into the container.
It's really just doing a -v with that particular file in the background.
Again, this is totally not secure and it's not supposed to be.
It's just a way to get around this problem and allow us to develop with the same process and the same
environment variable secret information that we would have in production, only now we can do it locally
too. Which is great because now that means we can develop using the same launch scripts and the same
way we get environment variables into our container just like we would in Swarm.
And that's what we really want.
We want to match our production environment as much as we possibly can locally.
You need the latest version of Docker Compose to do this.
I believe it only works in Docker Compose 11.
I hope you think that's pretty cool because I thought that was a good compromise for them to make
in order to let us use the Secret commands.
Now I will point out this only works with file-based secrets.
It will not work with the external that we talked about.
If we look at the Compose file real quick, I would have to use file-based ones for my local development.
Maybe if you're using external in your production, you just might have to have a different Compose
file for development that would have the file attribute here and specify sample, dummy files in the
same directory or somewhere else you might store them, that are just using simple password for development.