Comments 10
Интересный кейс. Упёршись в лимит Летсэнкрипта, лично я бы, наверное, в первую очередь начал смотреть в сторону сертификатов, содержащих несколько доменов. Когда их там штук по 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 и 100к доменов: автоматический SSL при одностраничном конфиге