Docker - how does it start?

ℹ️ Support
,
1

Nextcloud AIO v12.7.0 on Ubuntu 20.04

I have a nooby question that I cannot find an answer to elsewhere.

When AIO (or any other docker image) is installed and starts, as I understand it:

  • The image is downloaded
  • It runs, using a Dockerfile to configure networking, ports etc
  • It runs some kind of startup shell that does more configuration
  • it would normally have a volume that holds data that needs to persist, such as database or website content

If you reboot the server, what happens when containers start again? Do they

  • Re-run the Dockerfile every time?
  • Re-run the startup commands again?
  • Or, does the container just pick up from its saved state (perhaps a ‘commit’ is run at shutdown.)

And, where does docker composer fit into all this?

If anyone can explain this to be I would be grateful.

Thanks

Adrian

2

Yes, it does

3

See how it works: GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. · GitHub

4

Thanks.

I’ve seen that but it doesn’t quite give me the answer. The closest it comes is the description on how to reset your instance, but I don’t want to reset , just understand how it starts.

When the server boots, where is the Linux command that starts the containers - in init.d? A cron job? Some kind of startup script? Once I have an starting point, I can probably trace it from there.

Thanks

Adrian

5

We utilize the docker restart feature and configure it for all containers. If the server restarts, the docker daemon will take care of starting the containers automatically.

6

Is there a specific reason for this question, a specific problem you want to solve, or a goal you want to achieve?

If you’re just asking out of general interest, I’d suggest reading up on how Docker works, because what you’re asking isn’t specific to Nextcloud AIO. Maybe start with the official documentation: Docker Engine | Docker Docs.

Here is a link specifically to the section about automatically starting containers: Start containers automatically | Docker Docs

1 Like
7

Thanks chaps.

If I’ve read one article on how docker works, I’ve read… well, several.

Its just curiosity - but i would like to know so that I can deal with problems. Fr’example, I have an AIO on which the conatiners wont start. So I’m trying to trace things through from when the server starts. One learns helluva lot from troubleshooting real problems.

So, my thinking is: When a server boots, its services automatically start - like ssh and including docker.

I’m used to services in Linux having a .conf file or similar that specifies what the service is going to do - what port its listening on, for example.

I imagine that the docker service has some conf file that has the ‘docker run ’ commands listed in it. So when the docker service starts, it reads the config file, and the containers start. (Then the containers might have an entrypoint ‘start.sh’ that works internally in the container).

This is the missing peice of the jigsaw to me. Some articles refer to a ‘config.json’ but I cant find one in the AIO deployment.

Thanks

Adrian

8

I can’t explain every technical detail of how it works internally. However, in general, things like restart or start policies for containers are configured at the application level, not at the system service level. In practice, this means they are defined when you start a container (for example with docker run ...) or inside a compose.yaml file when using Docker Compose.

Manging the containers themselves is not done via system services. They are managed by the Docker Engine, which is started by the Docker daemon (dockerd). The daemon itself runs as a system service (usually via systemd on Linux). Its configuration can be adjusted through files such as /etc/docker/daemon.json or similar locations depending on the distribution, but this configuration generally affects the Docker engine as a whole, not individual containers. In normal setups there are only a few options configured there, and it typically does not include anything related to managing specific containers.

Docker stores internal container metadata under directories such as /var/lib/docker/containers. However, you generally should not modify anything directly in those directories, as they are managed automatically by Docker. If you want to change how a container behaves, for example its restart policy, the correct approach is to stop and remove the container and then recreate it with the desired configuration. For example, if a container was originally started with --restart always and you want to change that behaviour to --restart unless-stopped, you would stop and remove the container and start it again with the new option.

In the case of Nextcloud AIO, there is an additional layer involved. In the standard setup via docker run command you only directly start and configure the master container via docker commands, which then manages the other required containers internally. This is done through a Docker socket proxy, allowing the master container to control the rest of the stack.

If you want more control over the AIO stack, it is also possible to deploy it manually using Docker Compose. However, even in that case you generally should not modify things unless you clearly understand the implications and have a specific reason to do so. The manual setup instructions can be found here: https://github.com/nextcloud/all-in-one/tree/main/manual-install

1 Like
9

Addition:

From that line of thinking, you could loosely comparecompose.ymal files to configuration files, while docker run would be somewhat comparable to manually starting binaries with certain parameters.

However, the comparison isn’t entirely accurate. A better way to think about Docker is as something similar to a hypervisor but for application containers.

The configuration of containers is of course stored somewhere internally by Docker, but you generally do not interact directly with those configurations. Instead, you interact with Docker through the interfaces it provides, mainly the Docker CLI (docker run) or Docker Compose. These act as frontends that define and control container behaviour, while the Docker engine itself handles storing and applying the resulting configuration internally.

1 Like
10

Hi bb77,

Thanks taking the time to understand what I’m on about and make a detailed reply, which contained some useful insights.

I think I may be chasing something that can’t easily be seen and perhaps I don’t need to see it and should accept that it ‘just happens’ - like I accept VMs in Hyper-v are always appear in Hyper-V manager - I’ve never trawled through the registry to find where Hyper-V manager gets its settings from. Whats easier to see in Hyper-V are the VM config files and disk images - and I’m sure its similar in Docker.

Your replies have some useful info that has furthered my knowledge, so thanks.

Adrian

11

@adrianBromley When I read your question it seems to me that you’re mixing up Dockerfile and Docker Compose — they serve very different purposes.

A Dockerfile tells docker build how to build an image. Think of it as the “install the app” step. It only runs once, during the build process. After that, the image is a fixed snapshot — it never re-runs the Dockerfile.

These images are typically pushed to a registry like Docker Hub, which acts as a central repository for container images. When you install something like Nextcloud AIO, you’re pulling a pre-built image from such a registry — you don’t build it yourself. The Dockerfile was already used by the developers to build the image before publishing it. That’s why you never see or interact with a Dockerfile when you simply run a container.

docker run takes that image and creates a container from it — a running instance of that image. The process that starts inside the container is defined by the ENTRYPOINT (or CMD) in the Dockerfile. For example, in an Nginx image, that’s where the Nginx server gets started.

When you run docker run, the Docker daemon also stores the container’s configuration (in files like config.v2.json) so it knows how to handle that container after a reboot. On restart, Docker simply restarts the container process from the image — it does not re-run the Dockerfile or rebuild anything. Any data written inside the container (but outside a volume) is preserved in the container’s writable layer.

Volumes are used for data that must survive even if the container is deleted and recreated — things like databases or uploaded files.

Now, Docker Compose is a convenience tool. Instead of typing long docker run commands with all their parameters on the command line, you define everything in a YAML file and run docker compose up. It bundles multiple containers, networks, and volumes into a single, reproducible configuration.

What might confuse you about Nextcloud AIO specifically: the AIO container itself acts as a kind of “Docker Compose with a web GUI”. It configures and starts the actual Nextcloud containers (database, web server, etc.) on your behalf. So you’re not writing a docker-compose.yml yourself — the AIO container manages that for you.

2 Likes
12

@Reiner_Nippes

Thank you so much for that explanation. It is just what I needed. Why it is not in the docker documention or youtube training videos (and believe me, I’ve looked at loads) I do not know.

The explanation of the AIO mastercontainer is especially welcome - I’d begun to suspect it was somehow in control of things, so its great to understand how.

Thanks again,

Adrian