What is Docker Compose on NAS? After I changed from point-by-point installation to Compose, the containers were no longer messed up.
There are nine containers running on my Feiniu, including Jellyfin, qBittorrent, and Immich. The first eight are all installed by me in the Feiniu Docker interface.: Click New Container, fill in one name, one image, one port mapping, one more directory mounting, and two more environment variables. Click all the way down, and after installing one, write down the parameters in the memo. When I was dressing up for the ninth time, I couldn't help but think about it.: I repeated this set of actions eight times, and the parameter memorandum was already three pages long. One day Feiniu upgraded the interface and revised it, and I couldn’t even match what I filled in at that time.
What really made me decide to change my mind was the power outage last year. After the call came in, all the containers were up, but Immich's web page kept spinning. After checking it all night, I found that the postgres database container it relied on had started up late. Immich ran before the database and got stuck there. At that time, I restarted each container one by one to save it. The next day, I started to change all containers to Compose management. This article explains exactly what Compose solves, how to write yml so that it is not easy to overturn, and how to move when changing machines. It is written clearly in the order of my pitfalls.
Speak humanly first: Compose is to write a configuration sheet for the container
Docker Compose is not a new container. It writes the parameters you click on every time in the interface into a file called compose.yml in the text file. Port mapping, directory mounting, environment variables, and restart policies are all written in the file. You hand this file to Docker, and it pulls up the container according to the order.
What is the biggest difference between these two words? For manually installed containers, the parameters only exist in Docker's own mind. You can glimpse part of it at a glance at the interface, but if you want to move the whole thing or go through it again, you have to go through it one by one. The parameters of the container installed in Compose are in the yml file. I opened the file and saw which port each of the nine containers uses and which directory it is hung in. It took one minute to read it all. This file itself is a backup. I copied the entire docker directory to the mobile hard disk, and the configuration will not be lost if the machine crashes.
If you are still confused about the terms port mapping and directory mounting in Docker, read it first This article is an introduction to Feiniu Docker , Compose just changed the way these actions are written, and the concept has not changed. Which containers should use which network mode? What is the difference between bridge and host? The article about installing Home Assistant It has been removed in Compose and can be used in Compose.
mine compose.yml What does it look like? Don’t copy the wrong three places.
Create a new project (Compose) in Feiniu's Docker management and just paste the yml into it. Synology is a project in Container Manager, which means the same thing. I took my running Immich and cut a skeleton for you. It looks like this:
services: immich-server: image: ghcr.io/immich-app/immich-server:release container_name: immich-server restart: unless-stopped ports: - "2283:2283" volumes: - /vol1/1000/docker/immich/library:/usr/src/app/library environment: - DB_PASSWORD=改成你自己的 depends_on: - immich-db Three places where mistakes are most likely to be copied. The first is the host path to the left of the colon when the directory is mounted. Use the absolute path to write the entire path. Don’t write ./library This kind of relative path, the relative path on Feiniu follows the location created at that time. If the directory is moved or the project is rebuilt, the photo library will be hung in another directory. There is no other way to save this kind of error except re-hanging. The second is restart: unless-stopped Don't worry about this. If the container crashes, Docker will pull it up by itself, and it will boot up after the power is turned off and restarted. Three is depends_on , this is the root cause of my last power outage. If I write it, Immich will wait for the database container to get up first before starting it. This set of accounts is the same as the memory article. Nine containers only consume 2G in steady state. What really crushes the machine is the peak value. If you are interested, read it. Container memory account .
There is also a little habit of writing yml: Do not write the password directly into the file. Compose supports putting passwords in the same directory .env In the file, only the variable name is written in yml. I tried to save trouble by writing the first three containers in plain text. Later, when I wanted to synchronize this directory to the backup machine at my mother's house, I broke out in a sweat - the plain text password was synchronized with it. Change to .env In the future, just exclude this file during synchronization.
When it comes to updating containers, Compose saves half the steps compared to doing it manually.
If you want to update a manually installed container, you must first stop the container, delete the container, pull a new image, and then fill in the parameters according to the memo. If you miss one of them, it will be an accident. When I updated Jellyfin, I forgot to reinstall the transcoding directory. When I went into the settings, it was all grayed out. It took me an hour to retrieve it. Compose is updated in three steps: Pull the new image, rebuild the container, and done.
docker compose pull docker compose up -dThe second command means "put all the containers that should be run in running state according to the yml". When the image is updated, it will delete the old container and rebuild it with the new image and the same configuration, because your data is in the mounted host directory and not in the container. After the reconstruction, the data, accounts, and settings are all there. This is why the directory mounting item must be written correctly from the first day - the container itself is disposable, and the yml plus the mounting directory is your real wealth. Which details need to be monitored manually when upgrading containers? I’m here How to upgrade containers There is a more detailed list in that article.
By the way, I have installed and uninstalled watchtower, which automatically updates containers. Automatically upgrading all containers in the middle of the night sounds great, but for a database service like Immich, once the new version changes the table structure, the automatic upgrade will overturn while you are sleeping, and the photo library will no longer be open in the morning. For containers on home NAS, my principle is to update important services myself, and only leave unimportant ones to automation.
The container cannot start after restarting. First check whether it is a sequence problem or a path problem.
After changing to Compose, I cut off the power and restarted it twice. Once nothing happened, and once it overturned, I just collected both types of pitfalls. The first category is the startup sequence: depends_on It only guarantees "who starts it first", not "who is really ready to wait". The database container is up but is still being initialized, and the containers that rely on it will still be unable to connect and get stuck. Immich, the database in the official compose file has a health check. It is most stable to copy the official one. Writing the yml of a simple service by yourself is not so particular. At most, you can manually restart the stuck one after turning on the computer, which is much better than when I clicked it one by one eight times.
The second category is path problems: The mounted host directory is on a USB external disk. The disk has not been mounted when booting. When the container starts up, it is found that the directory is empty. At least an error is reported, and at most, the configuration is initialized. In this case, either move the docker directory to the internal disk, or wait in the system for the external disk to be mounted. Here are the three pitfalls of using a USB disk as a warehouse disk Use mobile hard disk as warehouse disk I wrote in that article that friends who rely on external disks to run containers must take a look. The complete troubleshooting sequence for containers that cannot be started after restarting is also provided with a three-step checklist. This article .
The night I replaced my NAS, I really felt that Compose was worth it.: Moved nine containers in one night
Last month I moved the containers from an old machine to the new N100. I never dared to think about it before. It takes at least a weekend to adjust the parameters of each of the nine containers. The process after using Compose is like this: Install Feiniu on the new machine, create the same docker directory structure, and put the entire docker directory (including the contents of each container compose.yml and data) rsync from the old machine, and then run it in each project directory docker compose up -d , the image is automatically pulled, the container is automatically built, and all the data is in the mounting directory. I started working on it at eight o'clock in the evening, and at 11:30 all nine containers were running on the new machine, and I even had a meal in the meantime.
There are two things that Compose cannot move and have to be repaired manually. The first is the image tag seen in the container list. If you used it by swiping at that time, latest , the new version pulled by the new machine may behave differently from the old version. I later changed the important services to pinned version numbers, such as release Change to a specific version. The second is .env The password in the file, if you exclude it from synchronization like me, remember to copy it separately. After the migration is completed, open the web pages of each container to confirm. Things such as Jellyfin's transcoding settings and Immich's face index are stored in the database and will generally not be lost if you follow the data directory. Comparison of several paths and speeds for transferring files between two machines. I have measured them and recorded them in This article .
Who should switch to Compose and who should stay put?
My advice is per capita. If you have more than three containers, have been updated at least once, or have experienced a power outage and are in a hurry to restart, it is worth spending an evening to switch to Compose. The reward will be peace of mind every time you update and move in the future. There are only one or two containers that have not been touched since they are filled, so don’t mess with them, they are enough. Pure newbies should first understand the three basic words of Docker before proceeding. Don’t skip the level. I have an important photo library on my hands, so I took a snapshot or backup on the day I changed Compose. The yml was pasted with the wrong mounting path. Immich thought it was a new installation when I started it for the first time and used the empty directory as the photo library. Although the old data was still in the original directory, I was scared at the time.
Finally, give a practical summary: Compose doesn't let you run an extra container, nor does it make the machine faster. It just collects your configurations scattered in interface clicks and memos into a text file that can be read, saved, and copied. NAS is a thing that lasts for several years, and there will definitely be power outages, upgrades, and machine replacements along the way. The earlier you put the configuration into the file, the earlier you will be able to calm down during those days.
