I run the Caddy cluster in Kubernetes, so I use Redis as the cluster lock.
In addition:
https://caddyserver.com/account/register-package
unable to scan modules in package github.com/ss098/certmagic-s3
Please include this error ID if reporting: 465bb9d7-0e3d-4b51-8570-df06a2bbbbbfNeat! FYI @matt, error ^
@cenegd what would the benefits of this s3 driver be over GitHub - gamalan/caddy-tlsredis: Redis Storage using for Caddy TLS Data if you still need Redis for locks?
S3 storage like a file system and is easier to manage than Redis.
Certmagic requires locks in the cluster, using S3 as a lock is not safe.
Thanks for the error ID! The error is:
unexpected argument to RegisterModule(): &ast.UnaryExpr{OpPos:19268762, Op:17, X:(*ast.CompositeLit)(0xc0043372c0)} - expect either composite literal or new()
Huh, so I guess &S3{} won’t do, you’ll have to use new(S3) instead.
I can look into fixing that but it’s not a high priority.
Regarding locking, there is an existing S3 storage implementation that unfortunately does not have the atomicity required to use successfully in a cluster (or at least at any degree of scale, like more than couple or few instances and certificates). Using redis is a fair workaround, but now it requires S3 + redis, which is unfortunate. I think most people who use AWS with CertMagic have simply decided to use DynamoDB as their storage backend which provides some atomicity.
The package has been registered, thank you.
I don’t use AWS, using Redis as a lock is relatively simple, and using Redis as a lock does not require persistence.
If someone in the community needs it, I may use Etcd and DynamoDB as the driver in the future.
In addition:
Is it possible for the file_server module to support the Certmagic Storage interface? If this is combined with S3, Caddy can have unlimited storage.
Currently, I use rclone mount and it works well.
I’m a bit nervous about this – make sure that all instances which are configured to use the same storage also share the same locks, even if some instances are shut down and others are started.
What do you mean by this? The file_server module is just a static file server (it doesn’t change files).
I know it is read-only.
The current file_server module uses os.Open and only supports file systems. If it supports Certmagic Storage Interface, it will be able to load files from anywhere else (Example S3).
Hmm, that’s a good question. I think file_server could be made pluggable by supporting a roughly os compatible interface. If you’d like to open an issue on GitHub for further discussion, I think that could be interesting.
I’m not sure if the CertMagic storage interface is enough though, it might be too basic, because file_server does a bit more complicated stuff than it. It might require a fresh abstraction (or maybe there’s an existing lib that makes this kind of abstraction already?)
That said, you could reimplement the file_server handler yourself to support s3 (basically just copy the whole module as a plugin, swapping out the os stuff with the s3 API) but I think that’s more boring 
I don’t think it’s possible because we need a stream (io.Reader, specifically io.ReadSeeker I think), but certmagic’s Storage interface is not designed as a file system abstraction per-se, it is only meant for basic data storage abstractions. It’d have to load the whole file into memory which is simply a no-go.
I have heard there’s some new work by the Go team on a standard file system abstraction. We should probably wait for that to mature before trying anything ourselves.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.