Исправление vbr, (текущая версия) :
Ну если вкратце.
Есть такая штука как кластер кубернетес.
Его сервисам иногда нужен валидный сертификат. Обычно не нужен, можно общаться внутри кластера через http, но иногда нужен. Так вот они написаны.
Этот кластер я разворачиваю определенными скриптами. То бишь у хостера есть опенстак, там ничего нет. Я пишу terraform apply . и через полчаса у хостера создаются виртуалки, балансировщики нагрузки, диски там всякие, устанавливается развернутый кластер, где запущены все сервисы. Я пишу terraform destroy . и этот кластер удаляется.
Кроме того эти скрипты работают инкрементально, т.е. можно, к примеру, добавить туда новый сервис или изменить версию или настройки текущего и при запуске они приведут кластер в нужное состояние. Ну в теории.
Это удобно в основном для тестирования. У меня есть продуктовый кластер, который, конечно, никто не удаляет и есть какое-то нетривиальное изменение. На продуктовом кластере его тестировать некомильфо. Поэтому я разворачиваю тестовый кластер с этим изменением и убеждаюсь, что оно работают. А потом удаляю, ибо я живу в бедной стране и работаю в бедной компании, держать постоянно запущенным тестовый кластер денег нет. Ну и вообще удобно, в принципе можно это всё и на локалхосте развернуть, пока такой нужды не было, но доработок там будет немного.
В процессе разворачивания эти самые злополучные сертификаты получаются от letsencrypt как часть процесса инсталляции. Просто создается ингресс и cert-manager выпускает на него сертификат.
Иногда бывает так, что я что-то меняю и оно перестаёт работать. Т.е. я развернул, а оно криво развернулось. А сертификат уже выпустился. Я исправляю и прогоняю всё с нуля, чтобы убедиться, что всё работает. И когда что-то сильно и часто меняется, то такая ситуация можно произойти чаще, чем 5 раз в неделю.
У letsencrypt есть некоторые ограничения. В основном они все разумные. Но есть одно, которое мне мешает.
Сертификат обычно выпускается для одного домена. Но в общем случае в нём можно перечислить несколько доменов. letsencrypt для каждого домена просит доказать его владение и выпускает такой сертификат.
И вот для множества (domain1, domain2, …, domainN) существует ограничение в 5 сертификатов в неделю. Т.е. я могу выпустить 5 сертификатов на s1.mysite.com, а 6 уже не смогу. Но я могу поменять список доменов на (s1.mysite.com, s1-temp1.mysite.com) и выпустить ещё 5. Потом выпустить ещё 5 на (s1.mysite.com, s1-temp2.mysite.com). И так далее. В конце концов я упрусь в какой-то следующий лимит, наверное, но это мне не важно, там уже лимиты большие. Мне важно то, что этот лимит на 5 в неделю - он абсолютно глупый, он легко обходится (но не легко для меня, т.к. у меня конфиги статические и приходится руками добавлять эти мусорные домены) и он мне мешает. Собственно я так и делал, когда упирался в этот лимит - добавлял руками мусорные домены. В принципе если хорошо заморочиться, можно и генерировать этот мусорный домен, но блин, это же полная лажа.
Ну а zerossl можно использовать вместо letsencrypt путём нехитрых манипуляций (надо зарегистрироваться у них на сайте, получить api ключ и прописать его в настройках cert-manager) и по их обещаниям никаких лимитов нет. Поэтому прописав для тестового кластера этот самый zerossl я всю проблему снял малой кровью на мой взгляд. Попутно узнав, что не одним letsencrypt-ом живёт мир бесплатных сертификатов (и с сожалением узнав. что для ru доменов, похоже, одним, но у меня домен не ru, поэтому для меня это ограничение не такое уж критичное, хотя я всё же в проде оставлю letsencrypt).
Чтобы использовать невалидные сертификаты (самоподписанные или выпущенные через letsencrypt-staging), мне придется ощутимо перерабатывать многие скрипты, создавать свои образы вместо использования готовых. То бишь сейчас я использую какой-нибудь hashicorp/terraform, который собирают эти самые хашкорпы, а мне надо будет создавать новый репозиторий, писать докерфайл, в котором прописывать добавление staging root сертификата в этот образ, настраивать CI, чтобы он мониторил появление новых версий от хашкорпа и ребилдил этот доморощенный образ, прописывать в тестовую конфигурацию этот изменённый образ. И делать это для более, чем одного сервиса. Рискуя, между прочим, тем, что кто-нибудь перепутает эти сервисы и на прод задеплоит образ с тестовыми сертификатами в доверенных. А это как бы нехорошо, не могу сформулировать точно, почему, но вот чувствую, что нехорошо. Ну и вообще куча работы. А я как бы не девопс какой, у меня других дел хватает, чем заниматься какой-то левой работой, от которой только вред потенциальный.
А ваилдкард выпускать вместо отдельных на поддомены - в данной ситуации ничего не изменит. Вообще ваилдкард обычно нужен, если у тебя сервис, где выделяется поддомен на юзера или что-то похожее. Типа abcd-1234.ngrok.io. Вот тут точно упрёшься во все лимиты, если захочешь выпустить тысячу сертификатов, по одному на юзера. Тут уместен wildcard.
Исходная версия vbr, :
Ну если вкратце.
Есть такая штука как кластер кубернетес.
Его сервисам иногда нужен валидный сертификат. Обычно не нужен, можно общаться внутри кластера через http, но иногда нужен. Так вот они написаны.
Этот кластер я разворачиваю определенными скриптами. То бишь у хостера есть опенстак, там ничего нет. Я пишу terraform apply . и через полчаса у хостера создаются виртуалки, балансировщики нагрузки, диски там всякие, устанавливается развернутый кластер, где запущены все сервисы. Я пишу terraform destroy . и этот кластер удаляется.
Кроме того эти скрипты работают инкрементально, т.е. можно, к примеру, добавить туда новый сервис или изменить версию или настройки текущего и при запуске они приведут кластер в нужное состояние. Ну в теории.
Это удобно в основном для тестирования. У меня есть продуктовый кластер, который, конечно, никто не удаляет и есть какое-то нетривиальное изменение. На продуктовом кластере его тестировать некомильфо. Поэтому я разворачиваю тестовый кластер с этим изменением и убеждаюсь, что оно работают. А потом удаляю, ибо я живу в бедной стране и работаю в бедной компании, держать постоянно запущенным тестовый кластер денег нет. Ну и вообще удобно, в принципе можно это всё и на локалхосте развернуть, пока такой нужды не было, но доработок там будет немного.
В процессе разворачивания эти самые злополучные сертификаты получаются от letsencrypt как часть процесса инсталляции. Просто создается ингресс и cert-manager выпускает на него сертификат.
Иногда бывает так, что я что-то меняю и оно перестаёт работать. Т.е. я развернул, а оно криво развернулось. А сертификат уже выпустился. Я исправляю и прогоняю всё с нуля, чтобы убедиться, что всё работает. И когда что-то сильно и часто меняется, то такая ситуация можно произойти чаще, чем 5 раз в неделю.
У letsencrypt есть некоторые ограничения. В основном они все разумные. Но есть одно, которое мне мешает.
Сертификат обычно выпускается для одного домена. Но в общем случае в нём можно перечислить несколько доменов. letsencrypt для каждого домена просит доказать его владение и выпускает такой сертификат.
И вот для множества (domain1, domain2, …, domainN) существует ограничение в 5 сертификатов в неделю. Т.е. я могу выпустить 5 сертификатов на s1.mysite.com, а 6 уже не смогу. Но я могу поменять список доменов на (s1.mysite.com, s1-temp1.mysite.com) и выпустить ещё 5. Потом выпустить ещё 5 на (s1.mysite.com, s1-temp2.mysite.com). И так далее. В конце концов я упрусь в какой-то следующий лимит, наверное, но это мне не важно, там уже лимиты большие. Мне важно то, что этот лимит на 5 в неделю - он абсолютно глупый, он легко обходится (но не легко для меня, т.к. у меня конфиги статические и приходится руками добавлять эти мусорные домены) и он мне мешает. Собственно я так и делал, когда упирался в этот лимит - добавлял руками мусорные домены. В принципе если хорошо заморочиться, можно и генерировать этот мусорный домен, но блин, это же полная лажа.
Ну а zerossl можно использовать вместо letsencrypt путём нехитрых манипуляций (надо зарегистрироваться у них на сайте, получить api ключ и прописать его в настройках cert-manager) и по их обещаниям никаких лимитов нет. Поэтому прописав для тестового кластера этот самый zerossl я всю проблему снял малой кровью на мой взгляд. Попутно узнав, что не одним letsencrypt-ом живёт мир бесплатных сертификатов (и с сожалением узнав. что для ru доменов, похоже, одним, но у меня домен не ru, поэтому для меня это ограничение не такое уж критичное, хотя я всё же в проде оставлю letsencrypt).
Чтобы использовать невалидные сертификаты (самоподписанные или выпущенные через letsencrypt-staging), мне придется ощутимо перерабатывать многие скрипты, создавать свои образы вместо использования готовых. То бишь сейчас я использую какой-нибудь hashicorp/terraform, который собирают эти самые хашкорпы, а мне надо будет создавать новый репозиторий, писать докерфайл, в котором прописывать добавление staging root сертификата в этот образ, настраивать CI, чтобы он мониторил появление новых версий от хашкорпа и ребилдил этот доморощенный образ, прописывать в тестовую конфигурацию этот изменённый образ. И делать это для более, чем одного сервиса. Рискуя, между прочим, тем, что кто-нибудь перепутает эти сервисы и на прод задеплоит образ с тестовыми сертификатами в доверенных. А это как бы нехорошо, не могу сформулировать точно, почему, но вот чувствую, что нехорошо. Ну и вообще куча работы. А я как бы не девопс какой, у меня других дел хватает, чем заниматься какой-то левой работой, от которой только вред потенциальный.