59
What's the advantages/disadvantages to hosting Nextcloud with Docker vs the Package Center on a Synology? (europe.pub)
submitted 10 months ago by to c/selfhosted@lemmy.world
22 comments fedilink hide all child comments
 

Most of the threads I've found on other sites (both Reddit and the Synology forums) have basically said "go with Docker". But what do you actually gain from this?

People suggest it's more up-to-date, and maybe for some packages that's true? But for Nextcloud specifically it looks pretty good. 32.0.3 came out 1 day ago and isn't yet supported, but the version immediately preceding that, from 3 weeks ago, is.

I've never done Nextcloud before, but I would assume installing it via the Package Center would be way easier to install and to keep up-to-date than Docker. So what's the reason everyone recommends Docker? Is it easier to extend?

Screenshot of Nextcloud in the Synology Package Center
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 10 months ago (6 children)

How isolated could it really be as a docker container vs a separate machine or proxmox?

You can get much better isolation with separate machines but that gets very expensive very fast.

It's not that it provides complete isolation - but it provides enough isolation very cheaply. You still compete with other applications for compute resources but you run in your own little filesystem jail and can run that janky python version that your application needs and not worry about breaking yum. Or you can bundle that old out-of-support version of libaio that your application requires. All of your dependencies are bundled with your application so you don't affect the rest of the system.

And since containers are standardized it allows you to move between physical computers without any modification or server setup other than installing docker or podman. You can run on Amazon Linux, RedHat, Ubuntu, etc. If it can run containers it can run your application. Containers can also be multi-platform so you can run on both ARM64 and AMD64 seamlessly.

And given that isolation you can run on a kubernetes cluster, or Amazon ECS with FARGATE instances, etc.

But that starts to get very enterprisey. For the home-gamer there is still a ton of benefit to just having file-system isolation and an easy way to run an application regardless of the local system version and installed packages. It's a bit of an "experience" thing to truly appreciate it I suppose. Like I said - if you've tried running a lot of services on a system in the past without containers it gets kinda complicated rather fast. Especially if they all need databases (with containers you can spin up one db for each application easily).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 10 months ago* (5 children)

    I still feel like I'm missing something. Flatpaks help you sidestep dependency hell, so what is docker for? What advantages does further containerization give you if you aren't going as far as proxmox vms.?

    I guess I've only tried running one service at a time that needed a database, so I get it if a Docker container can include a database and a flatpak cannot.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 10 months ago (1 child)

    Flatpaks are similar, but more aimed at desktop applications. Docker containers are made for services and give more isolation on the network.

    Docker containers get their own IP addresses, they can discover each other internally, you get port forwarding, etc. Additionally you get volume mounts for persistent storage and other features.

    Docker compose allows you to bring up multiple dependent containers as a group and manage connections between them, with persistent volumes. It'll handle lifecycle issues (restarting crashed containers) and health checks.

    An example - say you want a Nextcloud service and an immich service running on the same host. You can create two docker-compose files that launch both of them, each with its own supporting database, and give each db and application persistent volumes for storage. Your applications can be exposed to the network and the databases only internally to other containers. You don't need to worry about port conflicts internally since each container is getting its own IP address. So those two MySQL DBs won't conflict with each other. All you need to do is ensure that publicly available services have a unique port forwarded to them. So less to keep track of.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •