Pull to refresh

Comments 26

Это всё классно и прикольно, но почему бы не выложить вашу роль/плейбук и показать не части кода, а полноценный и то, как это работает?
Думаю не только мне будет интересно посмотреть…
Да, будет время — выложу куда-нибудь.
Предположу, потому что это решение привязано к их DNS провайдеру.
Мы юзаем AWS Route53. Подойдёт любой провайдер с API.
Уточните пожалуйста, как?
Например у меня Google DNS или PowerDNS, как ваша роль взлетит с ними?
В нашем случае DNS живёт в Route53, и для управления им используется эта штука:
docs.ansible.com/ansible/latest/modules/route53_module.html

Если бы DNS жил в Гугле, то использовалась бы эта штука:
docs.ansible.com/ansible/latest/modules/gcdns_record_module.html

А для PowerDNS есть масса вариантов.
Где дока живет я знаю :) Но я сказал, что ваше решение привязано к вашему провайдеру. Ссылки выше означают, что ваше решение нужно переписывать. Имено переписывать, т.к. у меня есть решение для нескольких облаков,(AWS,GCP,Aliyun) которое родилось из чужой роли для Route53. Взять что-то готовое и просто указать другого провайдера — не получится.
Что только не придумаешь лишь бы не поднять Caddy

Что люди только не делают чтобы не использовать Nginx/HAproxy.

а чем бы тут помог caddy?

Генерацией сертификатов без костылей?

из статьи:


А давайте использовать wildcard сертификаты? Давайте! Let’s Encrypt их уже выдаёт. Правда, придётся настроить подтверждение владения доменом через DNS. А DNS у нас живёт в AWS Route53. И придётся разложить реквизиты доступа в AWS по всем серверам.

и


Также появились сервера вообще без HTTP. Скажем, с почтой. Или с базами данных. Или с каким-нибудь LDAP. Или ещё с чем-нибудь странным. Туда также приходилось копировать сертификаты вручную.

caddy точно покрыл бы эти случаи?


P.S. на мой взгляд получение сертификатов LE в веб-сервере — весьма сомнительное решение с точки зрения изящности архитектуры.
P.P.S. странно, что ещё не догадался на веб-сервере держать и зоны dns.

edo1h точно отметил. У нас сертификаты используются в разных местах. В том числе таких, где нет никакого HTTP.
А почему когда вам не понравился api.service.skyeng.ru, вы решили сразу переносить всё в папки, а не добавили тире? Например вот так: service-api.skyeng.ru? Красиво и поменять быстро.
Да, для новых сервисов так и делаем. А старые остались с именами разных уровней.

А вы как-нибудь проверяете полученные сертификаты на валидность? Что бы вдруг не распространить пустой файл или просроченный сертификат на серверы?

Интересная идея, не думал об этом.

С одной стороны, это просто сделать. С другой стороны, за год эксплуатации у нас не было ничего подобного. Тогда зачем исправлять проблему, которая никогда не возникнет?

Когда у себя решали этот же вопрос, накидали отдельный сервис с API поверх certboot и все складываем в Hashicorp Vault, откуда уже каждая команда забирает сертификат для своих сервисов.


У вас в качестве хранилища что используется?

У нас всё просто на файловой системе. Так же, как делает certbot.

Vault тоже юзаем. Можно было бы и там хранить.
Там ничего секретного нет. Будет время — выложу куда-нибудь.

один в один проходили подобную ситуацию на проекте. разве что не было извращений с субдоменами 4 уровня :)
в итоге, было принято решение купить пять wildcard ssl и отказаться от мазохизма с LE, хоть он и приятен админам.
220 баксов в год (цена SSL) - не те деньги, ради которых надо страдать и превозмогать, так как есть куда более интересные извращения :)

Сервера были поделены на 5 серверных групп, каждой назначен свой домен.
Стало проще по части группировки данных в статистике и глядя на субдомен сервера уже сразу можно было сказать что от сервера можно ожидать.

Раз в год получаются новые SSL, размещаются на корневом сервере, далее скрипт, где обычный rsync разносит серты по серверам + релоадит веб-сервера.

Сообственно и все.

220 баксов в год (цена SSL) — не те деньги, ради которых надо страдать и превозмогать, так как есть куда более интересные извращения :)

а превозмогание чего именно вы исключили?

Sign up to leave a comment.