Migrationg Caddyfile from 0.10 version to 2.2 version

[luzfcb (Fabio C. Barrionuevo)]

Hello, I’m trying to migrate a project made with Caddy 0.10.3 to 2.2.1.

I’ve never worked with Caddy before and I’m having a bit of a hard time finding exactly what changes have occurred in the Caddyfile specification between the 0.10.x, 1.x, and 2.x specification to be able to rewrite the Caddyfile to be compatible with 2.x

Below, I include the original Caddyfile, and the new Caddyfile with my migration attempt.

I also don’t know if my new version of Caddyfile makes any sense since I know that there may not be a 1 to 1 migration path.

I appreciate any help.

1. Caddy version (caddy version):

2.2.1

2. How I run Caddy:

a. System environment:

docker

b. Command:

paste command here

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

My original Caddyfile works fine on 0.10.3

www.mydomain.org {
    redir https://mydomain.org
}

mydomain.org {
    proxy / django-a:5000 django-b:5000 {
        health_check /health_check/
        health_check_interval 1s
        health_check_timeout 5s
        fail_timeout 5s
        policy round_robin
        header_upstream Host {host}
        header_upstream X-Real-IP {remote}
        header_upstream X-Forwarded-Proto {scheme}
    }
    log stdout
    errors stdout
    gzip
}

mydomain.org/static {
    root /data/static
    header / Cache-Control "max-age=2592000"
    gzip
}

mydomain.org/media {
    root /data/media
    header / Cache-Control "max-age=2592000"
    gzip
}

My attempt to rewrite parts of Caddyfile

www.mydomain.org {
    redir https://mydomain.org
}

mydomain.org {
    reverse_proxy django-a:5000 django-b:5000 { # proxy was simply renamed to reverse_proxy or other hard changes were made?
        health_path /health_check/
        health_interval 1s
        health_timeout 5s
        fail_timeout 5s # this attribute has been renamed or removed?
        lb_policy round_robin
        header_up Host {host}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-Proto {scheme}
    }
    log {
        output stdout
    }
    errors stdout  # this attribute has been renamed or removed?

    encode gzip
}

mydomain.org/static {
    root * /data/static
    header Cache-Control "max-age=2592000"
    encode gzip
}

mydomain.org/media {
    root * /data/media
    header Cache-Control "max-age=2592000"
    encode gzip
}

3. The problem I’m having:

4. Error messages and/or full log output:

5. What I already tried:

6. Links to relevant resources:

[francislavoie]

Use the upgrade guide

Upgrading to Caddy 2 - Caddy Documentation

I think this is basically what you want:

www.mydomain.org {
    redir https://mydomain.org{uri}
}

mydomain.org {
	encode gzip
	log

	handle_path /static* {
		root * /data/static
		header Cache-Control "max-age=2592000"
		file_server
	}

	handle_path /media* {
		root * /data/media
		header Cache-Control "max-age=2592000"
		file_server
	}

	handle {
		reverse_proxy django-a:5000 django-b:5000 {
			health_path /health_check/
			health_interval 1s
			health_timeout 5s
			fail_duration 5s
			lb_policy round_robin
			header_up X-Real-IP {remote}
		}
	}
}

• handle and handle_path are used to make mutually exclusive routing blocks instead of separate sites. handle_path also strips the path before handling, which is important here, otherwise the file_server would be looking for files in /data/static/static/foo for example.
• fail_timeout is fail_duration for passive health checks, pretty sure.
• You don’t need to set Host and X-Forwarded-Proto, those are handled automatically reverse_proxy (Caddyfile directive) — Caddy Documentation
• Added {uri} to the www redirect so that the path is preserved
• errors does not exist anymore, all logs go to stdout by default
• Simply using log will enable access logs to stdout
• Note the * on the /static* path matcher, this is important because in Caddy v2 path matching is exact, meaning /static would only match exactly /static and nothing else.

Also big disclaimer about the docker image Docker Hub (please read the docs there), it uses /data for certificate storage. I strongly recommend using a different path, like /srv, for your site assets instead.