171–180 of 212 posts
I don't see how this is anything like compose. With quadlets you have to create a file for each container and deal with creating volumes and so on. Whereas with Docker it's one file, one command and you're done, you don't have to deal with anything else.
Yeah, I see Docker Compose as a development environment setup aid. This seems like a way to set up a system.
Earlier quoted context omitted.
Do you have a link to your NixOS router config? Been thinking of doing this for a while but never got round to it.
Here's a redacted version: https://gist.github.com/dbrgn/137da9e9ad342d536d1e452fba3e9d... Maybe it's useful as reference. It includes multiple network interfaces, a firewall, VLANs, DNS and ad blocking (plus two network services). (This version of the config does not yet make use of podman, I'm still in the process of setting everything up.) I'm also using nix flakes, to keep the setup reproducible. If you want to g…
Quadlets are very much a welcomed integration but last time I tried to create an users Quadlet in .config/containers/systemd/ with a linuxserver.io image I ended up with all sort of files owned by strange UID & GID. So I had to add --userns keep-id to my container unit what caused all sort of problem because of podman apparently. So you always end up with the kind of investigation & fiddling that shouldn't be necessa…
I believe this is due to the linuxserver.io images actually being customized specifically for usage with docker. For images intended for rootless deployments e.g. podman, take a look at the onedr0p container images, https://github.com/onedr0p/containers
I have been trusting the plan but I notice that after 10 years of container industry standard etc. we have to search for podman friendly images to enjoy integration with the common Linux service manager...
Now if container-based Linux distributions are the future I'm starting to wonder if we are not gonna soon see RedHat & co. packaging docker images in RPMs to make sure guarantee things work together & people don't badly mess up the security...
Earlier quoted context omitted.
Updating your custom registry with new upstream dep versions after testing in CI with the all services you care about is fine. But the OP seems to just blindly pull the newest wordpress images from upstream or am I missing something? How is this meant to work reliably? I guess given wordpress's security record taking breaking your site from time to time is preferable to your site being broken into from time to time.
I think you're mixing up some things. If you run the image "docker.io/wordpress:6.3.1", then the container will be updated when the image with that tag (6.3.1) is being re-built (which is a best practice, because that's the only way how you get security updates for the libraries in the base image). The tag is just a pointer to the latest image hash. Many Docker images also provide "semantic version tags". Wordpress d…
But it's basically similar to running a "update" of you distros package manager automatically on the fly. (okay it's better due it having a smaller surface and somewhat better per package update schema controls)
And some people argue that you must not do so as it might unexpected subtle break your system.
And other say you must because (especially security) updates must be done.
And the truth is probably in between. (Like auto updates with self test and rollback, which in complex systems isn't trivial at all.)
Anyway especially for using local user space toolings on my computer I 100% will enable it. I mean iff it stops working I can fix it but if not (the normal case) it's low maintenance. Perfect.
I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.) Quadlets seems not exactly a replacement for the function docker-compose was supposed to perform though, or am I wrong? It seems like its target audience is administrators who are supposed to run contain…
When putting multiple containers together docker-compose will handle setting up the networking and hostname lookup so that the services can communicate with static names and ports. Among other things.
Earlier quoted context omitted.
And so does Python. But Python is unnecessary for this task. So, having to choose between two evils, I'd choose the necessary one.
Idk what python you're talking about with docker compose
Earlier quoted context omitted.
For anything other than a hello world type project a compose file will fall over kinda quick. I would much prefer to (ahem) compose smaller things together and systemd is great for that.
For my home server, I have a flat 2507 line docker-compose file that automatically configures and boots all of my 85 containers. I still have some complexity: .env files in /opt/ /, a systemd process that automatically runs docker-compose -f / /docker-compose.yaml -d on boot, and it's only a little irritating to have use absolute paths for everything instead of relative. But, after having to update all of my services…
Earlier quoted context omitted.
I think you're mixing up some things. If you run the image "docker.io/wordpress:6.3.1", then the container will be updated when the image with that tag (6.3.1) is being re-built (which is a best practice, because that's the only way how you get security updates for the libraries in the base image). The tag is just a pointer to the latest image hash. Many Docker images also provide "semantic version tags". Wordpress d…
I think they know about that. But it's basically similar to running a "update" of you distros package manager automatically on the fly. (okay it's better due it having a smaller surface and somewhat better per package update schema controls) And some people argue that you must not do so as it might unexpected subtle break your system. And other say you must because (especially security) updates must be done. And the…
Which is a thing now. My openSUSE MicroOS/Aeon machines default to running transactional-update every day, and updates take effect on the next reboot. Given that MicroOS is allegedly to SUSE as CoreOS is to Red Hat, I suspect the latter has similar defaults.
Earlier quoted context omitted.
> 2507 line docker-compose file mother_of_god.gif
Yeah, she's a big girl, but having one flat file and one systemd process is infinitely better than juggling 85 of each. I have the systemd process start after docker.service, and most of my containers have a "depends_on" argument so they don't all try to boot at once. All of the containers also push logging to a Splunk instance, which adds 9 lines per container , which increases the file by 765 lines.
If those 9 lines are identical you can probably simplify quite a bit with extension fields and yaml anchors. [0]
You would put
logging: *default-logging
[0] https://docs.docker.com/compose/compose-file/compose-file-v3...