Cloudflare users unable to deploy

[pallebone]

Hi there,

When updating to 0.18.4 caddy gives an error:

+] Building 6.7s (7/8)
=> [proxy internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [proxy internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 202B 0.0s => [proxy internal] load metadata for docker.io/library/caddy:latest 0.2s => [proxy internal] load metadata for docker.io/library/caddy:builder 0.2s => CACHED [proxy builder 1/2] FROM docker.io/library/caddy:builder@sha256:f93573a72179f8f660127d9ae09a2a188b9194320f6fc1dbf562ca1bc7b38386 0.0s => CACHED [proxy stage-1 1/2] FROM docker.io/library/caddy:latest@sha256:89213bb94f8a60ebf0554ffe4a45c1af65321140246d34a689e641dae233b063 0.0s => ERROR [proxy builder 2/2] RUN xcaddy build --with github.com/caddy-dns/cloudflare 6.3s

---

5.765 2023/08/08 18:18:05 [INFO] exec (timeout=-2562047h47m16.854775808s): /usr/local/go/bin/go get -d -v github.com/caddy-dns/cloudflare github.com/caddyserver/caddy/v2@v2.7.2 5.926 go: downloading github.com/caddy-dns/cloudflare v0.0.0-20230807034102-74f004e1c1ab 6.015 go: github.com/caddy-dns/cloudflare@upgrade (v0.0.0-20230807034102-74f004e1c1ab) requires github.com/caddyserver/caddy/v2@v2.7.3, not github.com/caddyserver/caddy/v2@v2.7.2 6.017 2023/08/08 18:18:05 [FATAL] exit status 1

Luckily I could just start up the docker containers afterwards without an issue but the deploy script gives this error when running it.

Pete

[ubergeek77]

Hmm, it seems like the latest Caddy image has still not been published:

https://www.github.com/caddyserver/caddy-docker/issues/307

https://www.github.com/caddy-dns/cloudflare/issues/55

I'll push an update in a little bit that locks everything to 2.7.2. In the future I'll think about a way to determine the safest Caddy/plugin version pairs without needing to push LED updates every time.

For anyone coming in: please do not go and comment on either of those discussions on my behalf. Just react to any comments if you really want to participate.

[pallebone]

No problem all good. Will wait for them to resolve :) happy to retest also if you need me to.

[ubergeek77]

@pallebone Please try LED 1.3.0, I have updated the Caddy build files to avoid this.

[pallebone]

Ok will try in a couple of hours! Thanks for the effort. Hopefully they can do what you suggested and make tags.

[ubergeek77]

I am very doubtful they'll be receptive of that due to how immediately defensive their response was, but here's hoping.

[pallebone]

Hi there,

Just ran the git pull, ./deploy -y, ./deploy -f and it has managed to run the update without any issue whatsoever this time.

I see you changed the tag to caddy272 - does this mean you will monitor it from now on and change the tag for caddy if there is an update when you update the script from time to time? Just wondering what to expect.

Anyway all seems good, so many thanks again :)

One other thing I have noticed is that after the installation the docker names have somewhat changed slightly. So for example the old names were containing _ but the new ones contain -.

For example: => => naming to docker.io/library/lemmy-easy-deploy-proxy 0.0s [+] Running 6/6
✔ Container lemmy-easy-deploy_lemmy-ui_1 Removed 0.0s ✔ Container lemmy-easy-deploy_postgres_1 Removed 0.0s ✔ Container lemmy-easy-deploy_proxy_1 Removed 0.0s ✔ Container lemmy-easy-deploy_lemmy_1 Removed 0.0s ✔ Container lemmy-easy-deploy_pictrs_1 Removed 0.0s ✔ Network lemmy-easy-deploy_default Removed 0.3s [+] Running 6/6 ✔ Network lemmy-easy-deploy_default Created 0.1s ✔ Container lemmy-easy-deploy-postgres-1 Started 0.8s ✔ Container lemmy-easy-deploy-pictrs-1 Started 0.8s ✔ Container lemmy-easy-deploy-lemmy-1 Started 1.2s ✔ Container lemmy-easy-deploy-lemmy-ui-1 Started 1.5s ✔ Container lemmy-easy-deploy-proxy-1 Started

This means when I run this command below:

docker-compose -f /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml -p "lemmy-easy-deploy" up -d && docker-compose -f /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml -p "lemmy-easy-deploy" logs -f | grep -C7 -e ERROR -e WARN

It has to recreate the docker volumes as the names are brought back to lemmy-easy-deploy_proxy_1 instead of lemmy-easy-deploy-proxy-1 for example.

The script still states:

If you must manage your deployment manually, it is critical to supply the stack name: docker compose -p "lemmy-easy-deploy" [up/down/etc]

So some small change has occurred recently to bring in this minor inconsistency. I would note this seems to have no ill effect on the deployment thus far.

Kind regards Peter

[ubergeek77]

I see you changed the tag to caddy272 - does this mean you will monitor it from now on and change the tag for caddy if there is an update when you update the script from time to time? Just wondering what to expect.

Essentially yes, and the way I go about it will depends on how they respond to my feature request. But something tells me I won't have to worry about them publishing new versions "too fast."

One other thing I have noticed is that after the installation the docker names have somewhat changed slightly. So for example the old names were containing _ but the new ones contain -.

This might be yet another strange behavior of Docker Compose v1. Maybe Debian pushed an update to v1 and there was a behavior change. But since v1 has been deprecated, I still do recommend you update to v2 using Docker's official upgrade guide.

But make sure you aren't running two deployments now:

docker container ls

If you see duplicates, you might have a problem. If you don't then you should be good. I don't think your new stack would actually be running if there was an issue, so if Lemmy is working, then I think everything is fine.

[pallebone]

I am running a later version after you moaned at me:

root@lemmy01:/lemmy/Lemmy-Easy-Deploy# docker compose version Docker Compose version v2.19.1

I think it might be something that changed recently as it never used to do this.

Also it does not do this if I dont use the -f option on the script I noticed (from limited testing). Unsure if this is a difference?

Will continue to monitor it.

Pete

[ubergeek77]

Maybe it's due to your upgrade from v1 to v2?

Checking my own stack, mine has always used hyphens, i.e.:

lemmy-easy-deploy-lemmy-ui-1

I wouldn't worry about it too much though, because I don't try to access these containers by absolute name, and the volume names are still predictable in either case. And even if this is some weird behavior in Docker Compose, the fact that your stack is running suggests that it's deleting the old containers as needed and basically sorting itself out.

Thanks for pointing this out though, it's a good reminder to be careful about these names. I didn't know it did this.

[pallebone]

Interesting. Mine always had the underscores even of you check old issues where I posted information many days ago. I assumed that they were just the normal way. I never realised we were different either.

I dont believe it matters either as they map to the correct volume locations either way so find the data they need.

Will just keep monitoring it.

[pallebone]

Relevant information:

https://stackoverflow.com/questions/66514436/difference-between-docker-compose-and-docker-compose

Changed command I use from docker-compose to docker compose (with a space) eg: docker compose -f /lemmy/Lemmy-Easy-Deploy/live/docker-compose.yml -p "lemmy-easy-deploy" up -d

And now I get - instead of _

relevant comment:

Another notable difference between the two is how the docker image tags are generated. For both commands, the image tag is concatenation of COMPOSE_PROJECT_NAME env var (project dir name if env var is not set) and name value from the compose file. For older docker-compose command the name is appended to COMPOSE_PROJECT_NAME with an underscore, but the newer docker compose command appends the two with a hyphen/dash -