Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Horizontal Scaling #42

Closed
RyanHoldren opened this issue Jul 10, 2020 · 3 comments
Closed

Horizontal Scaling #42

RyanHoldren opened this issue Jul 10, 2020 · 3 comments
Labels
closed: question The issue is a question

Comments

@RyanHoldren
Copy link

We are currently using Certbot to create/update certificates whenever a new server is added to the cluster with the configuration shared between all the servers via an NFS. Because Certbot uses file locks, this architecture mostly works, though we've had some problems making sure edge cases are handled correctly.

How will micronaut-acme behave if it is horizontally scaled?

@RyanHoldren
Copy link
Author

Perhaps the certificates⁠—and private keys, for that matter⁠—could be stored in AWS Systems Manager Parameter Store or whatever the equivalent service is for Azure/Google Cloud.

@alvarosanchez alvarosanchez added the closed: question The issue is a question label Jul 27, 2020
@alvarosanchez
Copy link
Member

Please post questions in StackOverflow.

You can also try with asking in Gitter.

@zendern
Copy link
Collaborator

zendern commented Jul 29, 2020

@RyanHoldren I missed this originally sorry about that..... the way it works right now is each server would end up requesting a new certificate which should work with in theory with no issues. Assuming you are using Lets Encrypt you can see previous responses here about doing so but main issues with this approach are 2 things. 1. would be rate limiting and 2. would be the authorizations process. (https://community.letsencrypt.org/t/aws-distributing-current-certbot-certificates-amongst-server-which-are-spun-up-with-autoscale/35739/2). So in theory you could randomize the acme.renew-within property to have them renew on different intervals to skirt the ratelimiting if you have that many servers.

But to the issue of the authorization step that would have issues if you selected http/tls since those would need to get directed to whichever server actually made the call since there is a token involved at the time of order. There is a chance it could work but unlikely due to you more than likely having a load balancer in place.

That leaves you with DNS being you only option but ATM DNS option requires manual intervention until #3 #4 #5 (or whatever DNS provider you are using that might have an API) are done and it just happens automatically.

And maybe there are other routing options or fanciness you could do to get the authorizations to work out.... id be curious to hear more about how you have certbot running on multiple servers requesting renewals or maybe you dont and you just have a "master certbot server" that does all the magic and then NFS to share the cert.

Also as far as storing the certificate in AWS Systems Manager Parameter Store or whatever the equivalent service is for Azure/Google Cloud. Not sure it solves the issue. The biggest hangup i think is the authorization process. But maybe again you just have 1 node do it, share to a storage provider and then all the other nodes check for changes on an interval. ¯_(ツ)_/¯ #spitballin. But now you're down to 1 node and no redundancy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed: question The issue is a question
Projects
None yet
Development

No branches or pull requests

3 participants