Support a more efficient config-sharing method than environment variables

[jalada]

In an environment where there are 10s of domains, it takes a long time to verify each domain, and the app restarts once per validation (causing downtime). It also interferes with your release numbers.

If we could offer multiple configuration sharing methods we could make the gem perform better for these larger scale deployments, e.g. using an available Redis installation.

[vitamino]

Absolutely +1

I don't know if @jalada refers to the same thing, but the use of ENV on Heroku restarts the server, so in a multi domain app the server will be restarted every 5/10 seconds for N times. That's not acceptable in a production environment.

PS: it's a great gem!

[jalada]

Thanks @vitamino. That's exactly what I am referring to. We're currently thinking about adding support for Redis as the shared-memory layer. What do you think?

[davidlibrera]

@jalada it's a problem that I noticed too. The use of ENV is a great idea, is the only way to mantain data between dynos. Install redis or force to use active record with a database (for those application that has no database) could be very introusive. But I think that we can store a serialized hash

ENV["ACME_CHALLENGES"] = { challenge_filename1 => challenge_file_content1, challenge_filename2 => challenge_file_content2, .... }

or something else similiar.

In this way task rake will:

1) Creates challenges for each domain 2) Store all challenges in ENV (reboot) 3) Verify one by one all challenges 4) Generate and upload the new certificate 5) Clear ENV (reboot)

[jalada]

@davidlibrera serialised ENV variables is a cool idea. Definitely worth a try, thanks.

[vitamino]

@jalada: redis or memcached seem good options. On Heroku are immediate via (free) addons.

But the solution proposed by @davidlibrera is nice too! Perhaps the final clear is not strictly required. One reboot is a fair price for a simplest structure without dependencies.

A little OT note about config "storage": I tested the gem only a couple of times and didn't study the code, but I suppose it doesn't save the account and recreates it at every renew. Although it is perfectly legit from Letsencrypt side, I read somewhere that they have an "accounts limit" for a single email and a lot of certs rebuild could hit it. So could be nice storing the account somewhere and reuse it.

[jalada]

@vitamino do you have a source re: account email limit? Not disputing you, it's just something that's playing on my mind too and if there's a limit for sure we need to fix that ASAP!

[vitamino]

@jalada the offical Rate Limits page (https://letsencrypt.org/docs/rate-limits/) doesn't talk about that; I remember to have read this some time ago in a comment by a Letsencrypt rappresentative/developer, I will try to find the source! However perhaps will be safer ask for an updated and official response.

[jalada]

@vitamino thanks, I've asked on their community support forum: https://community.letsencrypt.org/t/maximum-accounts-per-email-address/29908

[jalada]

Tracking the account key issue here: https://github.com/pixielabs/letsencrypt-rails-heroku/issues/50