3 ms·

> docker image, upgrades are a breeze. Maybe this has been improved, but I remember thinking that and then it biting me because updating to the latest image (l

> docker image, upgrades are a breeze. Maybe this has been improved, but I remember thinking that and then it biting me because updating to the latest image (linuxserver/nextcloud) wasn't actually updating nextcloud itself, just the environment (php, etc.) When I realized this, I had to go through several major nextcloud upgrades, incrementally going from one major version to the next. Then it bit me again a few months later where nextcloud updated their maximum supported php version, and the docker image I was on quickly bumped the bundled php version to the new maximum, so the older version of nextcloud suddenly refused to start - even to run the updater. I ended up finding the max version check in nextcloud's php code and commenting it out, after that I was able to run the nextcloud update manually. After being bit twice, I finally automated the full process so that the nextcloud software is updated in addition to the environment.

jax_the_dog 3y ago
Having just dealt with this… can you share that automation?
- nfriedly 3y ago
  So, the script I have is just this: sudo -u abc php /data/www/nextcloud/updater/updater.phar --no-interaction Although, it looks like I need to add this also: occ db:add-missing-indices And, I thought I had it in my crontab, but now I don't see the job there. I haven't touched it in months, and I'm on the latest version of nextcloud, so presumably it's still working. But I honestly can't remember how I set it up.
bityard 3y ago
I just use the regular "official" docker hub image, not the linuxserver one. Not sure what the differences may be. The "major versions incremental upgrades" is a fundamental nextcloud thing, to do with their database migrations I expect. I was way behind and had to do three of them in a row when I containerized my Nextcloud instance, but they all worked fine, thankfully.
dzikimarian 3y ago
Don't use linuxserver images. My feeling is they were done by someone who doesn't understand docker very well. Frequent use of supervisor, lack of logs on stdout, weird automagic config approach. It may feel convenient if someone did homelab without docker, but will bite you in the long run.
- jjeaff 3y ago
  hmm, are you sure about that? the whole reason I use the linuxserver offerings is that they all follow the same pattern of not using root privileges in the container and also factoring the uid and group id out as compose variables so you can match them to other containers if needed.
  - radlad 3y ago
    I think both are true - LinuxServer images are usually well maintained, and they all use a common format, so once you know how to configure one, it's easy to configure the rest. But they make a lot of decisions that are not "best practices" in Docker - such as running multiple processes per container, under a supervisor. IMO, they are great for single-machine home deployments.
  - dzikimarian 3y ago
    Yes their images are standardized, which helps if you want "linuxserver experience" and don't care about actual image. Try to understand what actually happens on container startup and you're stuck in three layers of base images that they use as framework, with hooks on each layer. Wanna inherit some image and eg. copy something into config dir? Nope. Config dir is overwritten by symlink, by script on some layer. Actual config dir is moved somewhere to fit their internal convention. Their framework allows them to quickly add new applications and keep them updated. But it's pain to work with. I guess if you're willing to learn it and you're 100% sure, you're not going to modify image or configure application beyond of what they exposed - you might be okay using it. Otherwise just get official image.
- chatmasta 3y ago
  They work great for stateless services that you don't modify for your use case. I've had a wireguard server and client container, both based on linuxserver/wireguard, in a fairly weird setup within Nomad, running in production for over a year with no issues. The trick was to isolate the weirdness in the wgconf files, the permissions of the containers, and their shared netns (a nomad group, in this case, with its netns configs tweaked by a startup script). The Dockerfile is simply FROM linuxserver/wireguard:latest. (It's wrapped in a Dockerfile so its rebuilds are limited to when we rebuild our images (every commit), but AFAIU the linuxservers setup, it can also pull in wireguard updates at runtime.)

jax_the_dog 3y ago

Having just dealt with this… can you share that automation?

nfriedly 3y ago
So, the script I have is just this: sudo -u abc php /data/www/nextcloud/updater/updater.phar --no-interaction Although, it looks like I need to add this also: occ db:add-missing-indices And, I thought I had it in my crontab, but now I don't see the job there. I haven't touched it in months, and I'm on the latest version of nextcloud, so presumably it's still working. But I honestly can't remember how I set it up.

bityard 3y ago

I just use the regular "official" docker hub image, not the linuxserver one. Not sure what the differences may be. The "major versions incremental upgrades" is a fundamental nextcloud thing, to do with their database migrations I expect. I was way behind and had to do three of them in a row when I containerized my Nextcloud instance, but they all worked fine, thankfully.

dzikimarian 3y ago

Don't use linuxserver images. My feeling is they were done by someone who doesn't understand docker very well. Frequent use of supervisor, lack of logs on stdout, weird automagic config approach. It may feel convenient if someone did homelab without docker, but will bite you in the long run.

jjeaff 3y ago
hmm, are you sure about that? the whole reason I use the linuxserver offerings is that they all follow the same pattern of not using root privileges in the container and also factoring the uid and group id out as compose variables so you can match them to other containers if needed.
- radlad 3y ago
  I think both are true - LinuxServer images are usually well maintained, and they all use a common format, so once you know how to configure one, it's easy to configure the rest. But they make a lot of decisions that are not "best practices" in Docker - such as running multiple processes per container, under a supervisor. IMO, they are great for single-machine home deployments.
- dzikimarian 3y ago
  Yes their images are standardized, which helps if you want "linuxserver experience" and don't care about actual image. Try to understand what actually happens on container startup and you're stuck in three layers of base images that they use as framework, with hooks on each layer. Wanna inherit some image and eg. copy something into config dir? Nope. Config dir is overwritten by symlink, by script on some layer. Actual config dir is moved somewhere to fit their internal convention. Their framework allows them to quickly add new applications and keep them updated. But it's pain to work with. I guess if you're willing to learn it and you're 100% sure, you're not going to modify image or configure application beyond of what they exposed - you might be okay using it. Otherwise just get official image.
chatmasta 3y ago
They work great for stateless services that you don't modify for your use case. I've had a wireguard server and client container, both based on linuxserver/wireguard, in a fairly weird setup within Nomad, running in production for over a year with no issues. The trick was to isolate the weirdness in the wgconf files, the permissions of the containers, and their shared netns (a nomad group, in this case, with its netns configs tweaked by a startup script). The Dockerfile is simply FROM linuxserver/wireguard:latest. (It's wrapped in a Dockerfile so its rebuilds are limited to when we rebuild our images (every commit), but AFAIU the linuxservers setup, it can also pull in wireguard updates at runtime.)