Docker configuration

[vorezal]

I've seen a few requests to run Dockcheck within Docker. This could use a lot more testing than I was able to do with only my use cases, but here is what it should provide:

• Dockerfile for image building. Anyone can use this to build one themselves, and we can also publish it in Dockerhub. I think it would make the most sense to do this under the mag37/dockcheck namespace, but I would be happy to do it under vorezal/dockcheck and maintain it if that's easier.
• Example compose.yaml file which can be modified for individual use cases.
• Manages schedules and command line arguments as environment variables passed to the container.
• Documentation not yet written. I'd like feedback and testing to confirm it is fully functional, then I'll write up documentation.
• I think the container can even update itself, but it could short circuit an execution and I still need to test that case.

Limitations I can think of at present:

• DSM notification won't work if running on DSM as a container
• The files snooze.list and updates_available.txt won't live beyond the container unless added to a volume. This may be fine as is, or may need additional documentation and examples.
• Apprise limited to curl configuration unless we add the package to the container image, which would increase its size.
• Rootless docker installation not supported and this container runs as root to access docker.sock. I think this is ok since privilege escalation is pretty trivial for anything that can run arbitrary containers.
• Compose projects path must exactly match host system path and every compose file must be added to a volume to be discovered.

As always, open to thoughts and improvements!

[mag37]

Impressive work @vorezal - as always!

I'm quite overwhelmed with other things currently and can't find time to properly review and feedback this, so it'll be a couple of weeks most likely before this would hit the main branch and a proper release. I'll try to squeeze in a read-through and hopefully run some tests so I can give some feedback!

Just a thought about the limitation

Compose projects path must exactly match host system path and every compose file must be added to a volume to be discovered.

Isn't it enough to bind the "root" of the docker project - just exactly to what it is outside of the container?
So if I keep all my docker projects in this structure:

/opt/projects/containers/
├── apache
│   ├── data
│   └── docker-compose.yml
├── homer
│   ├── data
│   └── compose.yml
└── whoogle
     └── docker-compose.yml

Wouldn't this suffice as a bind mount? - /opt/projects/containers:/opt/projects/containers:ro
Or are you required to individually add every compose?

And about namespace - I'm fine with either! If you'd like proper credits and host it under your name, or if you think it's more sensible to use mag37/dockcheck. Though might need to name it mag37/dockcheck-docker if so to keep it apart and/or change current label-setup as that might conflict.

[yoyoma2]

I've also seen multiple requests for this so some users will be very happy. 👍 I have DSM and some rootless setups so it's not for me personally.

[vorezal]

Yes, sorry my statement about adding compose files was a little unclear. If you only have one root, you only need to add that folder as a volume. I was trying to cover the case where someone could have compose files under multiple different folders for some reason. What I was trying to say is that all compose files for containers you want to manage must be available to the Docker container at the same path as on the host file system, however many volumes you have to add to do it. You could include every single docker file individually, one primary root (if you only have one), or each root if you have more than one.

I don't think the Docker namespaces will conflict with Github project names, so we should be able to use mag37/dockcheck for the image without a problem. As for mag37 vs vorezal, I think it makes the most sense to keep it the same as the Github project for discovery and consistency. People will know it is official that way. The issue there is you would have to build and publish a new Docker image with each release or bake the build/publish into the Github project itself using Github actions and GHCR. Adding the build would be nice, but it only takes a few seconds to build and publish the image manually.

[mag37]

Ah then I get what you mean! So let's say I've got this layout (for some reason):

/opt/projects/containers/prod
├── container_one
│   ├── data
│   └── docker-compose.yml
└── container_two
     └── docker-compose.yml


/home/user_bob/containers/test
├── container_t1
│   ├── data
│   └── docker-compose.yml
└── container_t2
     └── docker-compose.yml

I'd need to bind both of them with:

    volumes:
      - /home/user_bob/containers/test:/home/user_bob/containers/test:ro
      - /opt/projects/containers/prod:/opt/projects/containers/prod:ro

Or as you state, bind more granular with individual containers etc.

---

namespace

I'd be fine running it under mag37/dockcheck as long as you think it's fair/sensible. I'll probably stay away from using Github actions for now and rather build+publish manually on new releases.

(I'm considering if a migration to Codeberg is sensible in the future - though that's a later discussion/project when time allows)

[vorezal]

Yes that volume structure looks correct! And sounds good on the docker image publishing. I think keeping mag37/dockcheck is quite sensible and the level of effort is pretty minimal.