0.8.4 improvment request

[pallebone]

Hi There, it is me again.

Currently for lemmy easy deploy the tags are hard coded for: Caddy, Pictrs, Postgres

This means we cant select our own tag if we need to for various reasons. I have personally experienced this limitation once in the past. Can it be implemented that selecting a tag can be customizable if required?

Kind regards Peter

[ubergeek77]

I'm not sure what is being asked of here. Do you mean the prefix that shows on the log output for the stack?

This is just how Docker Compose works. If you want to filter just the logs for a given service, you can do that, and you can also show those logs without any prefix at all:

https://stackoverflow.com/questions/50360674/how-can-i-remove-prefix-with-service-name-from-logs/68855292#68855292

Do you want a custom prefix because you want to clearly see the logs for different services? Because if so, you can just show them by service name as shown in that discussion.

[pallebone]

My apologies, please let me clarify. I should have been more clear.

In the docker compose file it will have something like:

image:caddy:latest

and

image:asonix/pictrs:0.4.0

These tags cannot be changed so I cant deploy a different version of pictrs or a version of caddy that is a specific build in the example above.

Kind regards Peter

[ubergeek77]

Ah I see. Sorry, I don't plan to support that. At that point, you're basically just going a roundabout way of specifying your own Docker Compose deployment.

You can still specify a custom Docker Compose template if you want, with those things customized, but having custom images for each service would vastly increase the scope of this project, and likely increase the amount of issues I receive due to people using unsupported images. I also cannot guarantee that images with different tags, especially Lemmy, has the versions required for a successful deployment. I can guarantee them for my own images because I've ensured they are always built, usually a few hours before the official ones.

[pallebone]

Interesting, this does make it difficult as certain features come out for each of the components quite rapidly. In addition if you use the latest tag for caddy (which you do) its not clear how you are ensuring everyone uses the identical version of caddy since depending when they deploy it a situation can occur (is possible) where if caddy upload a new version, a different version is being deployed of it for one person using lemmy easy deploy to another.

[pallebone]

What did you think about this?

[ubergeek77]

I think that level of meticulously tracking every version of every service is out of scope for this project, as this is not professional software.

For caddy, the latest tag is sufficient as it is a very stable image with little to no changes across pushes. I can't recall Caddy ever having a breaking change.

For Lemmy, I'm tracking those changes.

For pictrs and everything else, the deployment files for this script are updated when upstream's deployment files change.

You are still free to specify a custom Docker Compose template with different tags if you like.

[pallebone]

Alright can you tell me how I specify a custom docker compose template that is not overwritten when I update with the script? Im not clear how to complete this.

[ubergeek77]

Anything in the custom folder will never be overwritten on updates. When you update this script, things in that folder take precedence, so it is the responsibility of the user to ensure their custom modifications are updated to address any potential breaking changes. This is rare but it could happen if the Lemmy team makes any weird changes to their deployment. The last time it happened was when pictrs 0.4 was released.

You can check the documentation in the repo and copy the official template into that directory with the correct name, then edit it how you like.

[pallebone]

Ok so this seems doable so if I just make a copy of docker-compose.yml and put the copy exactly here: ./custom/docker-compose.yml.template

Then it will just use this from then on? This doesnt seem too bad as an option. I can try that if this is the solution? I assume this still conforms to your specification if I do it that way?

P

[ubergeek77]

That's correct. It will always refer to that file instead of the one I supply.

It "conforms" to my specification, but if you have any issues as a result of this deployment, I won't really be able to help as the deployment will now be non-standard (with the exception being if I've made a mistake in how custom files are being interpreted)

[pallebone]

Alrighty it seems okay. May I also ask how the cloudflare template works as I would like to implement cloudflare for ddos. I didnt realise I had to make lemmy easy deploy aware of cloudflare. What exactly does the cloudflare template do or tell lemmy to do?

[ubergeek77]

If you specify a Cloudflare API token that has permission to modify your Zone's DNS records, that Cloudflare snippet will be added to the beginning of the Caddyfile, and the Lemmy block will include that snippet as part of it's configuration.

This will make Caddy use the DNS ACME challenge to request a certificate, instead of the HTTP challenge, because the Cloudflare proxy causes some issues with the HTTP challenge.

In short, it just uses the DNS challenge to request certificates.

Note: this requires Caddy to be compiled with the Cloudflare DNS plugin. This is how plugins in Caddy work. The Cloudflare DNS plugin was created by the author of Caddy, and this script will perform that build for you automatically.

However, if you override the Caddy tag template inside of the compose file, you won't use the built image, thus your Caddy image will not have the required plugin, and your configuration will break.

Your options at that point will be either to revert your change and allow the script to manage Caddy as it normally would, or specify a Caddy tag that has the requisite plugin installed.

You seem motivated in keeping things stable, so I should point out that both caddy:latest and the version of Caddy that is built via xcaddy (as this script does for the DNS plugin) always refer to the latest stable version, not main or untested commits.

[pallebone]

Ok thank you. Your expertise in this is very much valued. It makes sense what you are saying. I am going to need to do this for cloudflare so I may have to ask for some assistance next week when I set it up to check its working as it makes sense that if I enable the proxy for ddos it would interfere with letsencrypt getting the cert renewal.

Regards stability yes this is my main motivation so of your advice here is that its ok then will still stick with what you have specified unless Im am forced to change for some reason (hopefully this wont happen). So far I think I am only using 2 custom files - one for extra pictrs variables for object storage and one for the postgres performance improvements so Im pretty sure I still conform 100%. This is why I have a lot of questions surrounding changes instead of just doing whatever without first asking.

Thanks again. I noticed I am also using the debian images you create now as you built for amd64 so it seems I am pretty much as stable as possible through your script.

Appreciate you taking the time to talk to me. P