Added Caddy as reverse proxy.

[atakane]

By using a reverse proxy like Caddy, docker users may automatically publish their system on 443 without dealing with SSL certificates and all. Thanks to Caddy's auto integration with Letsencrypt. Click here for more info on their auto-ssl

[robotdan]

Thanks for your contribution @atakane.

@mooreds do you think this belongs here, or https://github.com/FusionAuth/fusionauth-contrib?

[mooreds]

I'm no caddy expert, but from a glance at the website it doesn't appear to be container only, so I'd suggest fusionauth-contrib. (Because you could run caddy outside of docker and use the config file, it looks like.)
@atakane, would you mind opening a PR against that repo?

[drpebcak]

Correct, caddy is not container-specific. There's tons of ways to get TLS working with proxies in front of fusionauth, so I don't think it makes sense to try to maintain something specific here.

[atakane]

Hi @mooreds and @robotdan

Docker configs are better when they're together in a docker-compose file. Think this like implementing "elasticsearch" as a new docker container addition into your compose file. To support this, I'm sharing Hasura's docker repo. Since FusionAuth is meant to be open to the public as the central Identity management server of the organisation, the docker distribution should Include a reverse proxy either Nginx or Caddy. I prefer Caddy over Nginx for their no-hassle SSL support.

For fusionauth-contrib repo, yes there should be a stand-alone Caddyfile like Nginx, Apache, and others. I'll create a separate PR for it.

[robotdan]

Thanks for the addition info @atakane that is helpful.

My hesitation with accepting this PR in this repo is that I am not familiar with Caddy (yet) and any changes to the the docker-compose.yml will affect fast path install, fast path install doc, fusionauth.io/download/ and perhaps a few other sections.

So, that is just to say I want to become more familiar with this tool, and then ensure there are no side effects for those currently using our fast path docker install, and see how it may affect our documented procedures.

I think @atakane is correct though, if using a reverse proxy and accessing FusionAuth over 80 or 443 is best practice - then we should probably add this type of configuration to our example docker-compose.yml.

I do like the idea of native integration with Let's Encrypt, but Nginx is probably more widely used and understood.

I'll take some time and test this out and look into Caddy and see if I can identify how this would affect our doc, and fast path installation guides, etc and report back.

Another option may be to make a docker-override.yml version of some sort for "production" and leave the existing one as a "development" version. TBD.

[atakane]

Hi all,

Both sides of the aisle have legit arguments. Making an docker-override.yml version may be the solution here once you decided on the reverse-proxy. If Nginx has an auto-SSL-deploy feature, it works here too. (I don't remember though. I always used certbot while dealing with Nginx sites, and I had to modify the config file manually which is time-consuming)

To me, creating SSL certificates is always a burden, for especially people who want to get on board as soon as possible with the tools like FusionAuth without dealing much with server configs and all. It should be as easy as how Cloudflare manages them. Just turn a switch on, and voila, whole sites publish via TLS.

I've created a version for our site at https://github.com/circleboom/docker-circleboom-fusionauth which sets and loads reverse-proxy listen-address from environment variables defined in .env

.env file becomes

POSTGRES_SERVER=your-postgres-db-server-ip
POSTGRES_SERVER_PORT=5432
POSTGRES_USER=postgres
POSTGRES_PASSWORD=your-secure-db-password

DATABASE_USERNAME=fusionauth
DATABASE_PASSWORD=your-secure-fusionauth-db-password

ES_JAVA_OPTS=-Xms512m -Xmx512m

FUSIONAUTH_APP_MEMORY=512M
FUSIONAUTH_APP_RUNTIME_MODE=development

# replace :80 with your domain-name like login.mydomain.com
CADDY_SITE_ADDRESS=:80

and Caddyfile becomes pretty straightforward

{$CADDY_SITE_ADDRESS} {
  reverse_proxy fusionauth:9011
}

to set the environment variable in docker-compose, we add environment: before mounting volumes

  caddy:
      image: caddy:2.2.1
      depends_on:
      - fusionauth
      restart: always
      environment:
      - "CADDY_SITE_ADDRESS=${CADDY_SITE_ADDRESS}"      
      ports:
      - "80:80"
      - "443:443"
      volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
      networks:
      - search

Best

[robotdan]

@mooreds Since I'm sure you're not busy... :-) if you had any time to look at this, or test it that would be great. Otherwise it is still on my radar...