Comments 18
Интересный кейс. Упёршись в лимит Летсэнкрипта, лично я бы, наверное, в первую очередь начал смотреть в сторону сертификатов, содержащих несколько доменов. Когда их там штук по 50 в каждом (а для паркинга, по идее, это норм) - сразу другой rps получается.
Let's Encrypt поддерживает до 100 доменов в одном сертификате, и для паркинга это было бы нормально.
Для этого бы пришлось писать свой код, в немалом обьеме, и очень тщательно его тестировать, а потом поддерживать.
У caddy политика разработчиков 1 сертификат 1 домен. Даже на www и сам домен отдельные сертификаты.
У них на этом прям пунктик, они считают такой подход сильно минимизурующим проблемы.
Я спрашивал девов на форуме, они кстати живенько и по делу отвечают.
Когда система работала на nginx, то у нас был свой модуль которые выпускал серты, просто домен + www, и продлевал. Работал модуль очень так себе, после того как написали выяснилось что можно уперется в лимиты и нужна умная система отслеживания что продлили что нет, с вписыванием очереди продления в окно рейтлимита Let's Encrypt.
А при переходе на caddy от этого модуля просто избавились.
Когда есть вариант сделать свое решение, и использовать что то живое опенсорсное, активно развивающееся и массово использование, то опенсорс лучше дешевле и надежнее.
Ну и вначале я делал ресерч по лимитам, и выяснил что даже 3 ноды решают бизнес задачу, а в дальнейшем на паккинге только рост нод, и "пропускная способность" по новым сертам будет только рости.
Можно использовать один е-мейл адрес ставив в суффикс адресата +чего-то. Если валидация у CA в такое не умеет, то все письма будут на один ящик падать.
Хорошая статья. Осталось добавить, что для сборки есть докер от разработчиков:
FROM caddy:<version>-builder AS builder
RUN xcaddy build \
--with github.com/caddyserver/nginx-adapter \
--with github.com/hairyhenderson/caddy-teapot-module@v0.0.3-0
FROM caddy:<version>
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
Спасибо за статью! Caddy для меня действительно стал избавлением. Особенно те сборки, которые нафаршированы по последнему слову моддеров, умеющие в генерацию конфига на лету из labels в docker-compose.yml, типа такой: https://github.com/homeall/caddy-reverse-proxy-cloudflare. То есть в простых и средних случаях даже Caddyfile не нужен - он сам создастся, как только появятся контейнеры в сети Caddy. Умеет во всё + даже TCP-трафик заворачивает, то бишь можно проксировать на FRP это всё.
Хочется больше подробностей. А что за проект такой, где 120к пользовательских доменов при том, что 3к в час может добавляться?
Что ещё помимо кедди рассматривали? Traefik например? Почему именно кедди? Почему не взял envoy + какой-нибудь контроллер для выпуска сертификатов?
Думаю ручек по работе с трафиком у кедди может быть явно меньше чем у нгингх, не потеряли ли в другом фунционале?
Маркетплейс доменов saw.com, начинающий конкурент sedo.com, afternic.com
Кроме caddy ничего не рассматривал, главный админ ресерч делал и мне уже выдал задачу в формате "попробуй запустить на caddy, потестим что выйдет с удобством и производительностью". Потестли, прижилось.
То есть большинство доменов хостят только лендинг о продаже этого домена, никакого веб-трафика на них нет, и требований к производительности веб-сервера тоже нет?
В Caddy вроде как можно настраивать несколько разных issuer и матчить нужные домены в нужные аккаунты
https://caddyserver.com/docs/json/apps/tls/automation/policies/
LE никак не валидирует имейлы эти.
Мне кажется можно сделать так, что для каждого домена будет сертификат с аккаунтом в этом же домене, просто после проверки on_demand_tls дергаем ещё какой нибудь скрипт на хосте, который рендерит нам новый json конфиг для Caddy и релоадид сам кедди, а потом уже выпускаем серт на этот домен.
"tls": {
"automation": {
"policies": [
{
"subjects": ["*.foo-bar.com", "foo-bar.com"],
"issuers": [{
"module": "acme",
"email": "admin@foo-bar.com",
"ca": "https://acme-v02.api.letsencrypt.org/directory"
}]
},
{
"subjects": ["*.bar-foo.org", "bar-foo.org"],
"issuers": [{
"module": "acme",
"email": "admin@bar-foo.org",
"ca": "https://acme-v02.api.letsencrypt.org/directory"
}]
}
]
}
},но это конечно просто моя теория, можете проверить ))
Конфиг у caddy можно править в памяти, без релоада. По встроенному API.
То есть тот конфиг что на винте лежит не изменится, а работать станет по новому.
Я так и меняю почты своим питоновским скриптом, ссылка на гитхаб в статье есть.
Если бы было такое требование, то да можно было бы менять почту под домен, LE не проверяет.
Ну и в нашем кейсе одновременно может генерится десяток сертификатов новых доменов. Если добавили например 5000 доменов, то максимально быстро будут серты генерится пока не исчерпается 3х часовой лимит LE, новые домены у нас паркинг простукивает в кадди в 10 потоков.
Для шаред хостинга где домены редко добавляются, и клиентам приятнее видеть свой емейл в сертификате, смысл мог бы быть.
Подскажите, а по какой причине выбрали бороться с рейт лимитами Let's Encrypt? Почему просто не используете ZeroSSL? Вроде бы они на сайте пишут, что у них нет рейт лимитов.
Первый тест на 2к доменов, на 1й ноде Caddy, показал что какие то лимит на ZeroSSL все же есть, как минимум для новых сертов. Caddy быстро выгреб 3х часовой лимит Let's Encrypt, это всего 150 доменов тк 2 серта на домен для www и без.
Потом часть доменов получили серты от ZeroSSL, и часть повисли без сертов.
Какой именно лимит, какое окно, я не пытался выяснить.
300 сертификатов за 3 часа с одного аккаунта
Один раз переводя сервис на другой хостинг мы как-то умудрились натолкнуться на rate-limits от LE. Там была ошибка в конфигурации (или DNS почему-то не обновился, или банально ошибку допустили в нём, не помню), и кадди пытался выпустить энное количестве неверных сертификатов подряд.
И мне показалось, что там лимит сильно меньше чем 300 за 3 часа. Но, возможно, это относится только к неуспешным попыткам выпуска сертификата.
Но возможно это стоит тоже явно как-то отразить.
Ага, что то такое было в документации, что при ошибках другие рейтлимиты.
Ну так ошибка есть ошибка, хз как это можно учитывать при проектировании системы.
Тут если у вас 100500 доменов, то каскад рисуется просто.
Почему-то отваливается N доменов, они по КД пытаются обновиться, и если ранее чем это КД истечёт новые домены добавятся (или старые не починятся), то начнётся каскад и аккаунт "навсегда" уйдёт в бан.
Но, наверное если у вас 100500 доменов, надо самому управлять обновлением.
Обновления сертов caddy делает сам.
Но он проверяет в нашем API, валиден ли домен в системе.
А система по кругу проверяет по rdap жив ли домен, и что у него наши NS.
Получается, если эта часть системы у нас сломается, всегда например будет выдавать ОК для доменов которые проекспариилсь или были перенесены, у нас тут возникнет проблема.
Caddy и 100к доменов: автоматический SSL при одностраничном конфиге