Not containers and data, but the images. The point would be reproducability in case a remote registry does not contain a certain image anymore. Do you do that and how?
Not containers and data, but the images. The point would be reproducability in case a remote registry does not contain a certain image anymore. Do you do that and how?
Nope. Data directories and compose files only.
This is how i do it. I can delete everything, repull and redeploy like nothing ever happened.
I have one exception and thats my calibre-web container. I have all my books backed up separately and I’ll be nuking that whole set up eventually.
Curious, have you tested rebuilding using this approach?
It makes sense to me, if the compose files are up-to-date, it should just work.
I’d only be concerned about ensuring I capture changes made to the container that happened after initial build.
That’s the secret. I never change the container.
If you absolutely must do some config on the container, then have a container creation script that creates a new container with the right settings and use that.
#pipelines
I feel like if that’s something you’re doing, you’re using containers wrong. At least docker ones. I expect a container to have no state from run to run except what is written to mounted volumes. I should always be able to blow away my containers and images, and rebuild them from scratch. Afaik docker compose always implicitly runs with
--rmfor this reason.