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
[–] 2 points 10 months ago (6 children)

You will still have to make sure that port numbers don't conflict

I'm sure I read you're comment wrong, but you are aware that each docker container has its own tcp stack, right?

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

    I don't really understand what a TCP stack is, but my question is if your IP address is 192.168.1.2, and you want to run two different services that both have a web interface. You still have to configure both of them to use different port numbers.

    If you don't think of doing that and they both default to 8000 for example and you try to run them both at the same time, I imagine you would get a conflict when you try to go to 192.168.1.2:8000 or even localhost:8000.

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

    @non_burglar@lemmy.world is correct, but is perhaps not explaining it perfectly for the practical questions you seem to be asking.

    If you have, say, two Docker containers for two different web servers (maybe one's for your Wiki, and the other is for your portfolio site), you can have both listening on ports 80 and 443 of their container, but a third Docker container running a reverse proxy which has access to your machine's ports 80 and 443. It then looks at the incoming request and decides which container to route the request to (e.g., http://192.168.1.2/wiki/%s requests go to the Wiki container, and all other requests go to portfolio site).

    Now, reverse proxies can be run without Docker, but the isolation Docker adds makes it all a lot easier to manage, in part because you don't need to configure loads of different ports.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 10 months ago (2 children)

    Sorry, that was presumptuous of me. 'TCP stack' just means each container can have its own IP and services. Each docker, and in fact each Linux host can have as many interfaces as you like.

    I imagine you would get a conflict when you try to go to 192.168.1.2:8000 or even localhost:8000.

    You're free to run a service on port 8000 on one IP and still run the same port 8000 on another ip on the same subnet. However, two services can't listen on the port at the same ip address.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •