Docker Nextcloud using example from here but connecting via http?

Help
1

I run Caddy as my reverse proxy. I recently(last night) installed Nextcloud via docker and caddy according to the example here. Nextcloud is up and running but I immediately notice two things:

  1. The install/initialization of Nextcloud(like setting up initial apps, etc) was unbelievably slow. This surprised me as I thought the fpm image was supposed to be faster. For contrast, I’ve set up nextcloud via docker without a reverse proxy and it’s much faster.
  2. The second thing I noticed is that I’m not connected via https.

Right now I’m just testing this out so I’m connecting directly to it via 192.168.1.210:9980. Once I get it set up to my liking, if I’m going to keep it, I will switch it over to nextcloud.mydomain.com. Anyway, here is my docker compose:

version: '2'
volumes:
  caddy_data:
  caddy_config:  
  nextcloud:
  db:
services:
  jellyfin:
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=002
      - TZ=America/New_York      
    ports:
      - 8096:8096
    volumes:
      - /home/mike/docker/jellyfin:/config
      - /pool-1/nasmedia/data/media:/data
    image: hotio/jellyfin
    depends_on:
      - caddy
    restart: unless-stopped 
  caddy:
    container_name: caddy
    ports:
      - 80:80  
      - 443:443
      - 9980:80  
    volumes:
      - caddy_data:/data
      - caddy_config:/config  
      - ./Caddyfile:/etc/caddy/Caddyfile  
    volumes_from:
      - app
    image: caddy
    restart: always
  db:
    image: mariadb
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    restart: always
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=<hidden>
      - MYSQL_PASSWORD=<hidden>
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud:fpm
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    restart: always

Can I solve my http/https problem by simply changing my caddy port from “9980:80” to “9980:443”?

And here is my Caddyfile:

jellyfin.mydomain.net {
reverse_proxy 192.168.1.210:8096
}
ombi.mydomain.net {
reverse_proxy 192.168.1.205:9020
}
:80 {

        root    * /var/www/html
        file_server

        php_fastcgi app:9000
        header {
                # enable HSTS
                # Strict-Transport-Security max-age=31536000;
        }

        redir /.well-known/carddav /remote.php/dav 301
        redir /.well-known/caldav /remote.php/dav 301

        # .htaccess / data / config / ... shouldn't be accessible from outside
        @forbidden {
                path    /.htaccess
                path    /data/*
                path    /config/*
                path    /db_structure
                path    /.xml
                path    /README
                path    /3rdparty/*
                path    /lib/*
                path    /templates/*
                path    /occ
                path    /console.php
        }

        respond @forbidden 404

}

Oh Caddy Jedi Masters, what would you have me do?

2

That is interesting. Caddy, in this case, is a drop-in replacement for Nginx used in the Docker Hub example. What might be worth doing is to try with Nginx instead and if it’s just as slow, the issue may be with the FPM image. However, if it’s noticeably faster, the issue may be with the Caddy web server configuration.

Multi-container applications are always going to be slower than their native, non-container counterparts. I find Docker great for mock-ups of multi-container applications, but production systems I’ll build natively as they are noticeably faster. If you do decide to stick with the containerised version of Nextcloud, whether it be the Docker Hub base version (Apache webserver included) or the FPM version (BYO webserver), you might want to include a Redis (object cache) container in the mix as it may provide noticeable improvements in response time. The Nextcloud thread HowTo: Ubuntu + Docker + Nextcloud + Talk + Collabora howto includes some useful clues, if you decide to pursue this.

Well, you haven’t actually placed the unsecured Nextcloud application behind the reverse proxy yet. As per the Docker Hub notes, both the Base and FPM versions provide no ssl encryption and are intended to run behind a reverse proxy. Something like this should work:

cloud.mydomain.net {
  reverse_proxy 192.168.1.210:9980
}

Note that the Caddy webserver just serves the Nextcloud PHP files. The Caddy reverse proxy provides the encryption services.

3

@basil I think it’s unnecessary to recommend running two Caddy instances (if I’m understanding what you’re saying here), it simply adds unnecessary overhead.

But yeah I agree with the rest. You just need to specify a domain as your site address and Caddy will manage TLS for you (as long as your DNS points to your server and your ports are publicly accessible).

4

Thanks for the response! You know, it’s funny because the reason I run everything (and I really do run all my apps) containerized, is because I view bare metal installations as sort of “cluttering my file system”. I’m sure that’s ridiculous by my level of fastidiousness is mind-boggling.

Part of my problem is that I don’t really and truly understand caddy (or web servers). That’s obvious because I didn’t even realize I had to add what you suggested to my Caddyfile to put nextcloud behind the reverse proxy. I thought it was already done since I added the bit to my Caddyfile regarding port 80. hahaha.

I’m going to reconsider installing nextcloud to my file system. Also, thank you for the recommendation on redis, I will look into that as well.

@francislavoie I don’t think I’m running two instances of caddy - am I?

5

No, I 100% agree with that, it’s why I like Docker as well. I don’t like cluttering my host machine and dealing with interdependencies that may conflict. Docker is storage heavy in comparison, but storage is cheap. The performance overhead is really not that much.

You don’t need to do that actually, what you had was fine, you just needed to specify a domain instead of :80 for it to be served by Caddy with Automatic HTTPS:

@basil has a setup where they have one Caddy instance that does the communication between Caddy and PHP-FPM, but then runs another instance of Caddy in front of that which terminates TLS then proxies to the Caddy + FPM instance. This isn’t necessary, it’s just a infrastructural choice that they made.

I don’t know why performance would be slower for you here, that doesn’t seem right to me. But I think all you had to do was change :80 to a domain and you should be good to go… I hope?

6

Makes perfect sense. Jails under FreeBSD (and its derivatives like FreeNAS) help declutter the file system and in that sense act like containers.

FreeBSD jails provide OS-level virtualisation, so the issue of conflicting interdependencies doesn’t arise. Where performance is the primary criteria, I’ll build natively and this tends to happen with multi-container applications like Nextcloud and WordPress. For everything else, I am likely to reach for Docker and this is especially true for applications that haven’t been ported to FreeBSD.

Handy to know and yes, this makes sense where Caddy is a component part of the application build.

Why do I use a separate reverse proxy? There are two really useful functions the Caddy reverse proxy instance performs. The first is automatic HTTPS for applications that are being served to the internet. Where Caddy is not part of the application build, it makes sense to proxy to a separate Caddy instance. A second, equally as useful function, is for applications that I might not necessarily serve out to the internet (so automatic HTTPS isn’t a primary consideration), but have hard to remember port numbers e.g. Resilio Sync, which has a default port number 8888. By placing it behind a reverse proxy, I no longer have to remember the IP:port as I now have an easy to remember domain name e.g.

sync.mydomain.com {
  reverse_proxy 192.168.1.210:8888
}

Btw, I would ordinarily serve Resilio Sync out to the internet. I’m just using it as an example here.

7

This topic was automatically closed after 30 days. New replies are no longer allowed.