Caddy configuration to Play Framework app

Help
1
  • I am trying to configure caddy to proxy to another container on the same network (Running a play framework app). Here are the configs I have tried.

docker-compose.yml:

version: '3.7'

services:

  play-demo:
    container_name: play-demo
    hostname: play-demo
    restart: unless-stopped
    image: openjdk:8-jre
    volumes:
      - /var/www/play-demo/artifacts/server-0.1.0-SNAPSHOT:/var/www/demo.***.com
    networks:
      - play
    working_dir: /var/www/demo.***.com
    expose:
      - 9443
      - 9000
    command: /var/www/demo.***.com/bin/server -Dhttps.port=9443 -Dplay.crypto.secret='***'

  caddy:
    container_name: caddy
    hostname: caddy
    restart: unless-stopped
    image: abiosoft/caddy:1.0.0
    depends_on:
      - play-demo
    volumes:
      - /var/www/play-demo/caddy/Caddyfile:/etc/Caddyfile
      - /var/www/play-demo/artifacts/caddy/.caddy:/root/.caddy
      - /var/www/play-demo/artifacts/caddy/logs:/var/log/caddy
      - /var/www/play-demo/artifacts/server-0.1.0-SNAPSHOT:/var/www/demo.***.com
    environment:
      ACME_AGREE: 'true'
    networks:
      - play
    ports:
      - 80:80
      - 443:443

networks:

  play:

Caddyfile:

demo.***.com {
    root /var/www/demo.***.com
    proxy / play-demo:9443 {
        transparent
    }
    log /var/log/caddy/demo.***.com-access.log
    errors /var/log/caddy/demo.***.com-error.log
}

Errors and Access logs:
demo.***.com-access.log

*** - - [16/Jul/2019:10:53:57 +0000] "GET / HTTP/2.0" 499 5
*** - - [16/Jul/2019:10:54:00 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:03 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:03 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:17 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:18 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:26 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:27 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:29 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:30 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:36 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:54:37 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:55:11 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:55:11 +0000] "GET /favicon.ico HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:55:36 +0000] "GET / HTTP/2.0" 502 16
*** - - [16/Jul/2019:10:55:37 +0000] "GET /favicon.ico HTTP/2.0" 502 16

16/Jul/2019:10:53:57 +0000 [ERROR 499 /] context canceled
16/Jul/2019:10:54:00 +0000 [ERROR 502 /] read tcp 172.18.0.3:49554->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:03 +0000 [ERROR 502 /] read tcp 172.18.0.3:49556->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:03 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49558->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:17 +0000 [ERROR 502 /] read tcp 172.18.0.3:49562->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:18 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49564->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:26 +0000 [ERROR 502 /] read tcp 172.18.0.3:49566->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:27 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49568->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:29 +0000 [ERROR 502 /] read tcp 172.18.0.3:49570->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:30 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49572->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:36 +0000 [ERROR 502 /] read tcp 172.18.0.3:49574->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:54:37 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49576->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:55:11 +0000 [ERROR 502 /] read tcp 172.18.0.3:49578->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:55:11 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49580->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:55:36 +0000 [ERROR 502 /] read tcp 172.18.0.3:49586->172.18.0.2:9443: read: connection reset by peer
16/Jul/2019:10:55:37 +0000 [ERROR 502 /favicon.ico] read tcp 172.18.0.3:49588->172.18.0.2:9443: read: connection reset by peer

Please let me know if I can help with any more resources. I expected to maybe have some css and favicon.ico not accessible upon the first connection attempt, but this isn’t working at all. I am very new to Caddy and usually I find the example confs very useful, but there is not one for the Play framework.

2

G’day @dnk8n, welcome to the Caddy community.

Looks like Caddy’s running alright, and it’s resolved play-demo:9443 to 172.18.0.2:9443 just fine (so Docker DNS is working fine). It’s then trying to connect, and the “peer” (which is your app) is resetting the connection, which is a nice way to say it’s shutting the door in Caddy’s face. Caddy then issues the 502 to it’s client, because there’s not much it can do about that.

So I’d be troubleshooting your play framework app here.

3

I will update with the final conf that worked in the end. But my problem was that I accidentally set -Dhttps.port=9443 instead of -Dhttp.port=9000

The play framework was having a hard time doing unnecessary https stuff.

On that note, is it fine to use http instead of https internally? Is there added advantage to passing through the https stuff play does to caddy?

4

The main two benefits of HTTPS are encryption and validation.

Encryption makes it hard for people listening in to figure out what’s being communicated. Validation helps you ensure you’re talking to the right person.

Encryption doesn’t matter as much when you’re talking over a Docker network that you’ve only got two services on (the two that are communicating). And validation is not really possible without a more extensive solution because you can’t get a publicly trusted certificate for the hostname play-demo, not to mention less necessary (again because the only two hosts on the network are the only two who want to talk to each other).

So, basically, yeah - it’s fine to use HTTP unless you’ve got incredibly stringent (overzealous?) security requirements.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.