Error using php_fastcgi directive: two Caddy blocks are created

[gremo]

Pretty minimal configuration to get PHP up and running:

services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:2.8
    container_name: ${COMPOSE_PROJECT_NAME}-caddy
    ports:
      - ${HTTP_PORT:-80}:80
      - ${HTTPS_PORT:-443}:443
    volumes:
      - ./public:/var/www/html/public
      - /var/run/docker.sock:/var/run/docker.sock
      - caddy_data:/data
    restart: unless-stopped
    labels:
      caddy.debug:

  php:
    image: php:8.2-fpm
    container_name: ${COMPOSE_PROJECT_NAME}-php
    volumes:
      - ./:/var/www/html
    depends_on:
      - caddy
    labels:
      caddy: localhost
      caddy.root: "* /var/www/html/public"
      caddy.php_fastcgi: "{{ upstreams 9000 }}"
      caddy.encode: zstd gzip
      caddy.file_server:

volumes:
  caddy_data:

With the above the generated Caddyfile looks wrong to me:

{
    debug
}
localhost {
    encode zstd gzip
    file_server
    php_fastcgi 192.168.16.3:9000
    root * /var/www/html/public
}
localhost:80 {
    encode zstd gzip
    file_server
    php_fastcgi
    root * /var/www/html/public
}

Is this a bug, my fault... or something not yet implemented?

EDIT: using a real host like api.example.com:

{
    debug
}
api.example.com {
    encode zstd gzip
    file_server
    php_fastcgi 192.168.16.3:9000
    root * /var/www/html/public
}
localhost:80 {
    encode zstd gzip
    file_server
    php_fastcgi
    root * /var/www/html/public
}

[francislavoie]

Weird. Are you sure you don't have another container running for some reason that causes CDP to grab invalid config?

[gremo]

@francislavoie yes, I've deleted the container and the caddy volume too. Double checked the image version and it's 2.8.

The only way to prevent the creation of localhost:80 block is to specify caddy: localhost:80 in my Compose file.

[gremo]

I can confirm that, no matter what, the caddy file show "old settings" (i.e. th debug option). Deleted all containers, with this new compose.yaml:

services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:2.8
    container_name: ${COMPOSE_PROJECT_NAME}-caddy
    ports:
      - ${HTTP_PORT:-80}:80
      - ${HTTPS_PORT:-443}:443
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - caddy_data:/data
    restart: unless-stopped

  whoami:
    image: containous/whoami
    container_name: ${COMPOSE_PROJECT_NAME}-whoami
    labels:
      caddy: ${DOMAIN:-localhost}
      caddy.reverse_proxy: "{{upstreams 8080}}"

volumes:
  caddy_data:

[francislavoie]

How did you "delete" the containers? Did you do docker compose down? There must be somekind of state still kept somewhere in Docker. I don't see how this could be a problem with Caddy or CDP.

[gremo]

@francislavoie I stopped and removed the container using Docker Desktop. Then I removed the associated volumes using the GUI. To be sure I've also run docker builder prune.

I don't know what to do. I've restarted Docker and also my machine.

Are we sure there isn't some bug related to Docker labels and this (awesome) project?

[francislavoie]

docker builder prune only prunes the build cache.

You probably want docker system prune -f after shutting everything down. Make sure there's no Docker networks still sitting around.

[gremo]

Screencast from 2023-11-20 16-42-42.webm

@francislavoie here is a video showing a fresh start (no container exists) ad the resulting Caddyfile given:

services:
  caddy:
    image: lucaslorentz/caddy-docker-proxy:2.8
    ports:
      - ${HTTP_PORT:-80}:80
      - ${HTTPS_PORT:-443}:443
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - caddy_data:/data
    restart: unless-stopped

  whoami:
    image: containous/whoami
    labels:
      caddy: ${DOMAIN:-localhost}
      caddy.reverse_proxy: "{{upstreams 8080}}"

volumes:
  caddy_data:

Result Caddyfile. As you can see, debug, file_serve, encode, php_fastcgi comes out of... nothing:

{
    debug
}
localhost {
    reverse_proxy 172.30.0.2:8080
}
localhost:80 {
    encode zstd gzip
    file_server
    php_fastcgi
    root * /var/www/html/public
}

[francislavoie]

Sure. But please actually start from a clean slate. Wipe out all Docker networks, containers, and volumes.

[gremo]

Thank you @francislavoie . For some obscure reasons, only docker system prune -f solved my problem.

It would be nice to know why this actually happened... and if it can occour again.

[francislavoie]

I don't trust Docker Desktop. It doesn't necessarily clean everything up properly. Docker in CLI will always show you the truth.