Что может скрываться за словами «крупнейшая онлайн-школа Европы»? С одной стороны, это 1 тысяча уроков в час, 10 тысяч учителей, 100 тысяч учеников.
А для меня, инфраструктурного инженера, это еще и 200+ серверов, сотни сервисов (микро и не очень), доменные имена со 2-го по 6-й уровень.
Везде нужен SSL и соответственно сертификат для него.
По большей части мы используем сертификаты Let’s Encrypt. Их преимущества в том, что они бесплатны и получение полностью автоматизировано.
С другой стороны, у них есть особенность: небольшой срок действия – всего три месяца.
Соответственно, их приходится часто обновлять.
Мы пытались это как-то автоматизировать, но ручной работы все равно оставалось много, и постоянно что-то ломалось.
Год назад мы придумали простой и надежный способ обновления этой кучи сертификатов и с тех пор забыли об этой проблеме.
От одного сертификата на одном сервере до сотен в нескольких дата-центрах
Когда-то был только один сервер.И на нем жил certbot, который работал из-под короны.
Потом один сервер уже не справлялся с нагрузкой, поэтому появился другой сервер.
А потом еще и еще.
У каждого из них были свои сертификаты со своим уникальным набором имен, и везде нужно было настраивать их продление.
Где-то при расширении были скопированы существующие сертификаты, а об обновлении забыли.
Чтобы получить сертификат Let's Encrypt, вам необходимо подтвердить право собственности на доменное имя, указанное в сертификате.
Обычно это делается с помощью обратного HTTP-запроса.
Вот несколько распространенных проблем, с которыми мы столкнулись по мере своего роста:
- Не все новые серверы были доступны извне: некоторые были скрыты за балансировщиком входящего трафика и стали недоступны из Интернета.
Сертификаты пришлось копировать вручную.
- Также появились серверы вообще без HTTP. Допустим, с почтой.
Или с базами данных.
Или с каким-нибудь LDAP. Или еще что-то странное.
Нам также пришлось копировать туда сертификаты вручную.
Чтобы браузер не сообщал постоянно о «подозрительном сайте», вам достаточно добавить наш корневой сертификат в список доверенных, и все готово.
Но позже и здесь возникли трудности.
Беда в том, что в BrowserStack, которым пользуются тестировщики, невозможно добавить сертификат в список доверенных сертификатов, по крайней мере для iPad, Mac, iPhone. Так что тестировщикам пришлось мириться с постоянно выскакивающими предупреждениями об опасных сайтах.
Ищем решение
Конечно, в первую очередь нужно делать мониторинг, чтобы узнавать об истекающих сертификатах не тогда, когда они уже истекли, а немного раньше.Хорошо, тогда.
Мониторинг идет, мы теперь знаем, что сертификаты тут и там скоро закончатся.
и что теперь делать? 
Big Ear — старый бот, который сертификат не испортит. Давайте использовать подстановочные сертификаты? Давайте! Let's Encrypt уже предоставляет их.
Однако вам придется настроить подтверждение владения доменом через DNS. А наш DNS находится в AWS Route53. И вам придется распределить учетные данные доступа к AWS по всем серверам.
А когда появятся новые сервера, копировать всё это оборудование и туда.
Хорошо, имена уровня 3 подстановочные.
Что делать с именами 4 уровня и выше? У нас много команд, которые разрабатывают различные сервисы.
Сейчас принято разделять фронтенд и бэкенд. И если интерфейс получит имя третьего уровня, например service.skyeng.ru , затем они стремятся дать бэкэнду имя api.service.skyeng.ru .
Хм, может, стоит запретить им делать это в будущем? Отличная идея! Что делать с десятками, которые уже существуют? Можно ли железной рукой объединить их всех в одно доменное имя? Давайте заменим все эти имена разного уровня на URL типа skyeng.ru/service .
Технически это вариант, но сколько времени это займет? И как бизнес может обосновать необходимость таких действий? У нас 30+ команд разработчиков, если уговорить каждую, то это займет минимум полгода.
Мы также создаем единую точку отказа.
Как ни крути, это спорное решение.
Какие еще идеи у вас есть?.
Может быть, мы сможем сделать один сертификат, в который можно будет включить все, все, все? И мы установим его на все сервера.
Это могло бы стать решением наших проблем, но Let’s Encrypt позволяет иметь в сертификате только 100 имен, а различных микросервисов у нас уже больше.
Что делать с тестировщиками? Они никогда ничего не придумали и постоянно жалуются.
Все ерунда, кроме пчел.
Пчелы тоже фигня, но их очень много.
Каждому разработчику или тестировщику предоставляется тестовый сервер — мы называем их тестированием.
Тесты не пчелы, но их уже куда больше сотни.
И все проекты развернуты на каждом.
На самом деле все.
А если для продаж нужно N сертификатов, то на каждое тестирование их столько же.
На данный момент они самоподписанные.
Было бы здорово заменить их на настоящие.
Две пьесы и один источник истины
Лебедь, рак и щука телегу никуда не привезут. Нам нужен единый центр управления полетными серверами.В нашем случае это Ansible. Certbot на каждом сервере — зло.
Храните все сертификаты в одном месте.
Если где-то кому-то нужен сертификат, то зайдите сюда и возьмите с полки последнюю версию.
А мы позаботимся о том, чтобы сертификаты в этом хранилище всегда были актуальными.
Учетные данные для входа в AWS также присутствуют только в этом одном месте.
Соответственно, у нас отпадают вопросы типа настройки AWS CLI на новом сервере, у которого есть доступ к Route53 и тому подобное.
Все необходимые сертификаты описаны в одном файле Ansible в формате YAML:
Периодически запускается один плейбук, который проходит через этот список и выполняет свою тяжелую работу - по сути, все, что делает certbot:certificates: - common_name: skyeng.ru alt_names: - *.skyeng.ru - common_name: olympiad.skyeng.ru alt_names: - *.
olympiad.skyeng.ru - api.content.olympiad.skyeng.ru - games.skyeng.ru - common_name: skyeng.tech alt_names: - *.
skyeng.tech .
.
.
- создает учетную запись в центре сертификации Let’s Encrypt
- генерирует закрытый ключ
- генерирует (еще не подписанный) сертификат — так называемый запрос на подпись сертификата
- отправляет запрос на подпись
- получает DNS-запрос
- размещает полученные записи в DNS
- отправляет запрос на подпись еще раз
- и, наконец получив подписанный сертификат, помещает его в хранилище.
Если ему по какой-то причине не удалось обновить некоторые сертификаты — будь то проблемы с сетью или какие-то ошибки на стороне Let’s Encrypt — это не проблема.
Обновлю в следующий раз.
Теперь, когда на каком-то сервисном хосте нужен SSL, вы можете прийти в это хранилище и взять оттуда несколько файлов - самая простая операция, которую выполняет второй плейбук.
Какие сертификаты нужны на данном хосте, описано в параметрах этого хозяин, в инвентаризации/host_vars/server.yml : certificates:
- common_name: skyeng.ru
handler: reload nginx
- common_name: crm.skyeng.ru
.
.
.
Если файлы изменились, то Ansible тянет крючок — обычно это перезапуск Nginx (в нашем случае это действие по умолчанию).
И таким же образом вы можете получать сертификаты от других ЦС, работающих по протоколу ACME.
Общий
- У нас было много разных конфигураций.
Постоянно что-то ломалось.
Часто мне приходилось лазить по серверам и разбираться, что же там снова отвалилось.
- Теперь у нас есть две плейбука и все записано в одном месте.
Все работает как часы.
Жизнь стала скучнее.
Тестирование
Да, а как насчет тестировщиков и их тестирования? Каждому разработчику или тестировщику предоставляется персональный тестовый сервер — тестирование.На данный момент их около 200. У них есть такие имена, как test-y123.skyeng.link , Где 123 — это номер тестирования.
Создание и удаление тестирования автоматизировано.
Одной из составляющих действия является установка на него SSL-сертификата.
SSL-сертификат генерируется заранее с именами по шаблону: ssl_cert_pattern:
- *
- *.
auth - *.
bill .
.
.
Всего около 30 имён.
Таким образом, готовый сертификат включает имена test-y123.skyeng.link
*.
test-y123.skyeng.link *.
auth.test-y123.skyeng.link *.
bill.test-y123.skyeng.link
и так далее.
После увольнения разработчика или тестировщика их тестирование удаляется.
Сертификат остается готовым к использованию.
Вы знаете, где все это хранится, и знаете, как оно распределяется по хостам.
P.S.
Репозиторий кода .Возможно, вам также будет интересно почитать на эту тему: Как переполнение стека перешло на HTTPS :
- Сотни доменов разного уровня
- Вебсокеты
- Множество HTTP API (проблемы с прокси)
- Делайте все, не жертвуя производительностью
Теги: #ИТ-инфраструктура #Системное администрирование #DevOps #ansible #Администрирование доменных имен #SSL-сертификаты #Certbot #обновление SSL-сертификатов
-
Дети Виртуальной Улицы
19 Oct, 24 -
Мультиклет Стал Еще Доступнее
19 Oct, 24 -
Страйкбол: Немного Обо Всем
19 Oct, 24
