Think of container as a running VM. Image is the file system of the VM. The image itself is static, so when restarted alll file system changes get tossed out (you can map certain paths inside the container to other storage). A Dockerfile is a file that describes how to build the image (For example : Use an ubuntu base image, run these commands, copy this file in to this path, expose this network port, and when running the container, start this file when it boots up).
When running a container you specify which image it should run, network ports to expose to the host network, environment variables that should be set inside the container, if it has access to a gpu, mapping paths to storage and so on. You can even change the startup command.
A docker compose file is a config file that can define all those things, and define it for multiple containers, binding them together in one stack. So you could for example have a static web server, an api server, a database server, redis, and so on defined and configured via environment variables. And you could just do “docker compose up” to bring up all the parts in their own docker namespace and virtual network.
Yes, but the benefit of an official image would be that I wouldn’t have to recreate it when a new version was released, it would update itself when I reload the container.
You can do whatever you want inside the container. If you wanted to update inside it, you can, but it’s probably not worth the effort. The downtime depending on the app can be just a few seconds when you rebuild the container.
is that why it doesn’t quite make sense to me?
Can you make a container from the compose file?
Think of container as a running VM. Image is the file system of the VM. The image itself is static, so when restarted alll file system changes get tossed out (you can map certain paths inside the container to other storage). A Dockerfile is a file that describes how to build the image (For example : Use an ubuntu base image, run these commands, copy this file in to this path, expose this network port, and when running the container, start this file when it boots up).
When running a container you specify which image it should run, network ports to expose to the host network, environment variables that should be set inside the container, if it has access to a gpu, mapping paths to storage and so on. You can even change the startup command.
A docker compose file is a config file that can define all those things, and define it for multiple containers, binding them together in one stack. So you could for example have a static web server, an api server, a database server, redis, and so on defined and configured via environment variables. And you could just do “docker compose up” to bring up all the parts in their own docker namespace and virtual network.
Yes, but the benefit of an official image would be that I wouldn’t have to recreate it when a new version was released, it would update itself when I reload the container.
Do you need to recreate the container? Can you update the applications in the container?
I mean, I know I don’t have to recreate it when I use a normal container, but I’m not clear when using compose
Hopefully someone with knowledge can weigh in.
You can do whatever you want inside the container. If you wanted to update inside it, you can, but it’s probably not worth the effort. The downtime depending on the app can be just a few seconds when you rebuild the container.
That makes sense