DevOps от первого лица

💾 Создание настройка и мониторинг RAID1 Вот и я добрался до использования RAID1. RAID1 - избыточное хранение данных, зеркалирование. ⚡️ Ставим N дисков, а используем как 1 ⚡️ Кажется нерационально, но не хочется в случае поломки диска ломать голову как восстановить данные. В процессе создания ничего сложного: - чистим диски и создаем таблицу разделов - создаем RAID1 массив на выделенных разделах - создаем файловую систему и помещаем в автозагрузку 📚 Консольные средства мониторинга тоже рассмотрим. https://byurrer.ru/storage-raid1 #article #raid

🎢 Gitlab CI & sourcemaps in Sentry Внедряя Sentry в проекты, столкнулись с необходимостью пробрасывать sourcemaps для javascript между разными этапами нашего конвейера. Использовали для этого привычный нам sentry-cli: 1) билдим проект 2) помечаем .min.js и .map меткой debugId чтобы в Sentry у нас был читаемый код и нормальный стектрейс 3) заливаем помеченные файлы в Sentry 🤯 Почему 3 разных этапа: после каждого этапа полученный результат может быть использован, например загружен в объектное хранилище для дальнейшего использования. Объединить мы их не можем, потому что этапы подготовки (1 и 2) происходят до момент деплоя, а таких подготовительных моментов до деплоя может быть с десяток и создавать десяток пустых релизов в Sentry, крайне не хочется. 🗃 Если шарить данные между этапами, то на ум сразу приходит cache. Удобно и надежно. Неоднократно это позволяло ускорить конвейер и откинуть этап инсталяции пакетов composer или npm. Админ задал резонный вопрос: как и когда очищается этот кэш? В документации по ссылке выше, можно найти раздел про очистку cache, вручную. Не пойдет ... 🧐 Недолгие поиски наводят на issue по поводу expired в cache также как у артефактов. Судя по всему за 4 года, с момента создания issue ситуация не сдвинулась с места. Поискав сам кэш на сервере gitlab-runner он был найден, а все файлы запакованы в zip. К слову все кэши лежали в одном docker volume, потому что у нас executor docker. 🐳 Теперь идем в документацию по docker executor и видим рекомендацию использовать clear-docker-cache в кроне для очистки неиспользуемых томов и контейнеров. Видимо так и поступим) ❓А вы что используете для шэринга данных между этапами конвейера не заполняя место этим шэрингом до отказа?) #sentry #gitlab

💾 Диски, RAID1 и другие новости кратко Пришли все диски и большую часть выходных я провел за их установкой в домашний сервер: - 2 SSD по 256гб под систему - 2 NMVE по 1тб под данные для сервера 👉 По 2 для того чтобы объединить их в RAID1 массив, на случай если один выйдет из строя то второй будет работать, а мне нужно будет оперативно заменить сломанный диск. Да, избыточно, но не хочется в случае поломки диска ломать голову как восстановить данные. Тем более что исследования google (из книги "Unix и Linux руководство системного администратора") показали что: - технология памяти не имеет отношения к надежности - даже среди самых надежных моделей SSD у 20% наблюдалась 1 неисправимая ошибка чтения, у менее надежных 63%. ❗️ И несмотря на меньший уровень отказов среди SSD по сравнению с HDD это не отменяет возможных рисков. 😔 ProxMox 8 удалось поставить только через установку Debian, потому что установщик образа ProxMox не поддерживает ручное формирование RAID1 массива. А с сетью пришлось повозиться (и нет, по ссылке не заработало), к слову почти после каждой новой инсталяции ProxMox я сталкиваюсь с проблемами в сети. 🧐 Инсталировать grub на второй диск получилось только через копирование /boot/efi на выделенный EFI раздел второго диска, однако при этом если первый диск убирать из массива и пытаться загрузитсья со второго, то слетают настройки BIOS, нужно повторно руками выставлять и все загружается. 🗃 По ходу дела обнаружился еще прикол: fstab потому что монтирует /boot/efi с первого (вынутого диска), опция nofail помогает. Со старого ProxMox бэкапами вынес виртуалки на новый - завелись почти без проблем. 🥳 Прикольно вставлять и вынимать произвольные диски наблюдая как система продолжает бесперебойно работать) За время работы собралось много материалов, постепенно буду оформлять в статьи на блог. 🎉 Заказал последнюю часть апгрейда своего сервера: XEON E5 2470 v2 (10 ядер, 20 потоков) 2шт по 1000р с Авито. На выходных буду ставить и заменять стоковые куллеры на башенные (купил их изначально, но потом захотел попробовать стоковые).

⚡️ На хабре вышла наша первая статья по установке и настройке Sentry (наконец-то). Ура! 👨‍💻 Статья писалась более месяца, снабжалась уместными схемами и мемами. На протяжении нескольких месяцев мы с вами разбирались с Sentry: ✔️ как транспортировать события для Sentry через fluentd (и еще), а здесь тестовый стенд ✔️ подключали ldap и обновлялись ✔️ переделывали транспортировку для фронта, а здесь тестовый стенд ✔️ собирали логи от Sentry ✔️ расследовали потерю событий и все-таки решили ✔️ делали свой sentry клиент для php (были на то веские причины) ✔️ учились мониторить Sentry с точки зрения обслуживания Как вы могли заметить по названию это только первая часть из серии статей о Sentry. Надеюсь получится довести серию до финала. В следующей статье поговорим про Sentry с точки зрения использования в разработке, оказывается здесь тоже много приколов. 🤝 Спасибо моим коллегам поддержавшим меня в этом начинании ) #article #sentry

🧪 Модификация BIOS для поддержки NVME через PCI Захотелось поставить NVME накопитель на свою плату Supermicro X9DBL-I через PCI-E. Как хранилище NVME работает без проблем из под ОС, но загружать ОС с него не получается - BIOS не поддерживал NVME. ❗️ Нельзя вот так просто взять и загрузить ОС c NVME на старых материнских платах. 🧐 Обновление прошивки BIOS не помогло, драйвер NVME не завезли. 👉 На просторах интернета удалось собрать информацию как добавить в BIOS поддержку NVME дисков ... и оно работает, но не без приколов. По ходу дела: - познакомимся с бифуркацией PCI-E - заденем UEFI - раскопаем форумы в поисках истины - провернем рискованную замену модифицированного BIOS материнской платы - в конце поговорим о проблемах https://byurrer.ru/modify-bios-nvme #article

Недавно обновил прошивку BIOS на своей плате X9DBL-I, а сейчас писал статью про модификацию прошивки BIOS для поддержки загрузки ОС с NVME диска через PCI-E. Собирал материалы и заглянул в раздел BIOS Hardware Health Configuration и внезапно теперь есть показания температуры плашек ОЗУ (DIMM на скрине) 😱 ❓ Вопрос получения температуры плашек ОЗУ некоторое время был насущным, пока я не нашел костыльный вариант в виде внешних термометров. А теперь вспомним что на этой плате нет IPMI, значит: ✔️ плашки имеют датчики показаний температуры и их можно опросить из ОС ✔️ для предыдущего пункта не нужен IPMI, есть иные механизмы Но быстрый тест sensors не дал результатов. Полагаю, можно сдуть пыль с записок по исследованию вопроса получения температуры плашек ОЗУ и снова этим заняться 🕵️‍♂️

🚦 НЕДОСТАТОК БАЗОВОЙ УСТАНОВКИ REDIS SENTINEL Мы ведем подготовку высокодоступного Redis Sentinel, я уже затрагивал эту тему. На стейдже мы развернули базовую установку: размещение Sentinel только на 3-х узлах Redis. ⚡️ Сегодня при деплое тесты доступности инфраструктуры упали на Redis'е: - приложение запросило у доступного узла Sentinel (redis1) мастера (redis3) - Sentinel, будучи в кластере в спокойном состоянии отдал валидную с точки зрения кластера конфигурацию redis3, потому что для всех узлов Sentinel он был доступен - клиент попытался обратится к redis3 и не смог 🚧 Связь между узлом приложения и redis2 и redis3 была недоступна. Можно списать на специфичную сетевую инфраструктуру, но мы столкнулись с недоступностью высокодоступного Redis, значит он не высокодоступный. 👉 Это недостаток базовой установки Redis Sentinel, нужно разместить Sentinel на узлах с приложениями и чем больше узлов сочтут redis-master недоступным, тем быстрее они изберут доступного мастера. #infrastructure #redis

💾 Прошивка BIOS архивных плат Supermicro через DOS Теперь и я добрался до обновления прошивки BIOS. Как оказалось ничего сложного: ✔️ качаем новую прошивку ✔️ создаем загрузочную флешку с DOS ✔️ закачиваем туда прошивку ✔️ идем на сервер и загружаем liveCD DOS ✔️ запускаем bat'ник прошивки Для моей архивной платы X9DBL-I нашел новую прошивку на странице описания. А другие архивные платы можно найти здесь. На данный момент все архивные платы Supermicro можно прошить указанным в статье способом, но для более новых есть возможность прошивки через UEFI built-in shell. https://byurrer.ru/update-bios-archive-supermicro #article

Продолжаю делать desktop gui на golang с библиотекой fyne. Fyne - это open-source проект позволяющий строить кроссплатформенный gui по мотивам Material Design. ⚡️ Внутри своя реализация компонентов с рендером на openGL ⚡️ Есть демо и примеры, а здесь среда рабочего стола для Linux. Документация скупая, на youtube нашел плейлист про fyne на русском языке 👨‍💻 Сегодня мне довелось посмотреть на кросс-платформенность в golang и fyne. Оказалось не так уж и сложно. Но для начала ссылки. - Тут про кросс-компиляцию в golang - И здесь тоже - Еще с форума - Здесь issue в репе fyne - А здесь конкретно про кросс-компиляцию в fyne На Ubuntu компиляция выглядит так: - установка mingw чтобы можно было под Windows компилировать: apt install mingw-w64 - команда для запуска компиляции: CGO_ENABLED=1 CXX=x86_64-w64-mingw32-g++ CC=x86_64-w64-mingw32-gcc GOOS=windows GOARCH=amd64 go build -ldflags "-s -w" А если говорить про fyne то там есть fyne-cross, он работает через docker, вывод такой же. #golang #gui

🧨 КАК НАС ЗАБАНИЛ НАШ ПРОВАЙДЕР DDOS Недавно я рассказывал про наш сервис на ISP и приключения с сертификатами. На днях сайты на сервере стали долго открываться, а потом просто падать. 🤯 Мы начали смотреть и разбирать в чем проблема, до нас долго не могло дойти в чем проблема: то ли php-fpm не работает, то ли проблема в коде ... Мы предположили много разных вариантов, но спустя время пришил к выводу - какая-то операция в скриптах зависает. Сначала подозрение пало на tarantool, уж больно нестабильная штука в кластере, доставляет головную боль. Но когда мы переключились на резервный сервер, а с ним проблем не было, и начали во внутренней сети дебажить var_dump'ами, то поняли в чем проблема: ⚡️ Наш провайдер защитник от DDoS добавил в черный список ip нашего сервера ISP, который обращался к другому нашему сервису. Оба были на обслуживании у этого провайдера. ⚡️ Конечно, такие дела нужно проворачивать через внутреннюю сеть, да и вообще добавлять в белый список свои сервера. Обсуждения у нас идут до сих пор, первые меры уже приняты. Однако, в этом инциденте я убедился еще раз: мониторить нужно все что возможно, даже количество коннектов nginx и php-fpm. Это ускорило бы обнаружения вектора сбоя и позволило бы сразу проводить расследование в нужно направлении. ✔️ Немного погуглив удалось найти получения статусной страницы в php-fpm и даже есть функция для получения этих данных в коде. ✔️ Для nginx тоже можно получить статусную страницу, а еще у них есть специальное API по коммерческой подписке, где информация о текущем состоянии значительно обширнее комьюнити версии. Но можно обойтись весьма лаконичным вариантом. 💡 Ретроспективно размышлять об инцидентах проще, чем перспективно предугадывать проблемы. #incident #infrastructure

🧨 ТЕСТ ВЫСОКОДОСТУПНОГО REDIS Ранее мы уже рассматривали тестовый стенд с высокодоступным Redis, а на прошлой неделе устроили стресс тест. На нашем stage стенде получился такой интересный состав: - 3 redis-server с репликацией master-slave - 3 redis-sentinel с минимальным кворумом из двух участников, которые принимают решение о смене мастера - 1 клиент, который постоянно что-то пишет в мастер и читает желательно тоже из мастера 👉 Наша основная цель: минимальное время задержки при переключении мастера, измеряемое несколькими секундами. 🤯 То есть, вся эта толпа из 7 участников должна договориться что мастер упал, переизбрать нового мастера и чтобы клиент об этом узнал сразу же. Ладно, начнем с небольшой справки. 📚 Redis Sentinel выступаем поставщиком конфигурации текущего мастера для клиента. То есть клиент запрашивает первый доступный узел Sentinel о мастере, и подключается к нему. А вообще Sentinel это просто режим работы Redis, так что он есть из коробки. 🥷 Этапы смены мастера: 1) По истечении времени недоступности мастера (down-after-milliseconds) Sentinel'ы считаю его субьективно упавшим (s_down) 2) Sentinel'ы организуют кворум и согласуют друг с другом и если участники кворума соглашаются что мастер s_down то Sentinel'ы переводят состояние текущего мастера в объективно упал (o_down) 3) Далее выбирается один узел Sentinel, который совершает смену мастера. Меняется эпоха, точнее инкрементируется config_epoch, по которому можно сказать сколько раз менялся мастер (после тестов у нас это число было больше 1000). Тестировали путем отключения узлов (и завершением службы и отключением сети). Подкрутили параметр down-after-milliseconds до 3-х секунд, и в итоге: инфраструктурная часть переключается за 3-4 секунды. ⚡️ Но в этой цепи взаимодействия присутствует клиент, который играет важную роль в задержках переключения. Мы использовали predis, это слабодетерминированная библиотека, не исключающая двусмысленное толкование кода. Так вот, в этой библиотеке по дефолту были недопустимые для нас инструкции, а именно частые попытки соединения с недоступным узлом sentinel. Есть страница с параметрами подключения. Ответ который наводит на верное решение есть в этом обсуждении. Нас интересовали следующие конфиги: - timeout (таймаут первого соединения), по дефолту 5сек - read_write_timeout (таймаут чтения/записи), дока говорит что дефолт зависит от платформы, и может быть ~60сек, ну а мы по опыту знаем что таймауты иногда могут просто не сработать Выяснив что остался последний тормоз в виде клиента, изменили конфиги: как для Redis Server так и для Redis Sentinel устанавливаем свои значения для timeout 0,5сек, а для read_write_timeout 1сек. И теперь клиент переключается на нового мастера за 2-3 секунды. 🎉 Итоговое демократическое переключение мастера для всех участников составляет 5-7 секунд 🥳 ❗️ Не забываем что для переключения мастера нам нужен кворум, а если наш кластер не сможет собрать нужное количество голосующих, то переизбрания просто не состоится, эту ситуацию мы смогли смоделировать оставив включенным один redis-server в режиме slave и один узел redis-sentinel. Читать можно, а вот записывать не получиться. #infrastructure #redis

🐳 Рецензия: Docker на практике. Второе издание Дочитал этого мастодонта и очень доволен, получил много новой информации + обновил свой взгляд на Docker. Я взялся за прочтение книги имея некоторый опыт работы Docker, Docker Compose и даже с Docker Swarm. Читая книгу много было знакомо, но вторая половина книги была кратким полетом над множеством возможностей, которые я не использовал. В книге рассматриваются различные аспекты использования Docker: 👨‍💻 начиная от потребностей разработки 😴 проходя через сонные админские будни 🔥 затем вливаясь в пайплайны доставки до горящего продакшена 🛠 учитывая оркестрацию, конфигурирование и отладку 🛡 а в конце говорим про безопасность. https://byurrer.ru/docker-in-practice-2 #article

Давно не было постов и новостей, не хватало времени написать, теперь исправляю ситуацию этим блиц-постом: 🕵️‍♂️ начал готовить серию статей о том как мы внедряли Sentry, чтобы получился цельный материал, не просто же так я писал сюда короткие заметки с тегом #sentry 📚 продолжаю участие в марафоне привычек, я выбрал привычку чтение професиональной литературы, дочитал книгу "Docker на практике", готовлю рецензию, начал читать "UNIX И LINUX - руководство системного администратора" 🫢 вышел из одного совместного проекта, здесь писал про его ответвлении, решение было крайне тяжелым, но я сделал это, очень рад что решился 🥕 на работе внедряем отказоустойчивый и высокодоступный Redis, здесь есть тестовый стенд 🥷 на работе в свободное от основных дел время пишу UI на golang + fyne для Cloak client, библиотека fyne понравилась, есть документация и примеры использования По мере готовности вышеописанного буду оформлять в цельные полезные посты сюда или даже в инструкции на блог.

🗳 ВЫСОКОДОСТУПНЫЙ REDIS, ТЕСТОВЫЙ СТЕНД ⚡️ Мы начали рассматривать высокодоступный Redis, и для исследований завели тестовый стенд, который теперь доступен в нашем репозитории. Недавно был пост про новые docker образы для старого ПО, там как раз шла финальная подготовка тестового стенда. 🗃 Так сложилось что Redis мы рассматриваем исключительно как быстрый кэш. Однако, Redis шагнул достаточно далеко, там завезли ACL, Redis Streams (это что-то типа брокера сообщений, чем-то напоминает Kafka), новый протокол RESP3, lua скрипты, и много чего еще (почитать можно здесь про v6, а здесь про v7). Что мы хотим: - иметь глобальный кэш состоящий из нескольких узлов, это реализуется при помощи реплицируемого Redis - в каждый из которых можно писать, и из каждого можно читать, это реализуется при помощи Sentinel (это что-то типа прокси, который будет направлять все запросы в master сервер) 👉 В репозитории есть README с необходимыми инструкциями для тестирования основной логики высокодоступности. ⚡️ Все наши наработки можно посмотреть в профиле компании на github. #repository #infrastructure

🚃 SENTRY + HAPROXY + TDAGENT ⚡️ Настало время доставлять ошибки с frontend в Sentry. Специально для исследований мы подготовили тестовый стенд в репозитории. Недавно мы тестировали и внедряли транспортировку событий в Sentry через td-agent, но делали мы это исключительно для backend в частной сети. Но frontend доступен миру снаружи, мир жесток значит нам нужно оставить минимум. ✔️ Мы выяснили что нам нужен только envelope endpoint, но вдруг захочется store endpoint? Сделаем оба. ✔️ Также не забываем что у нас есть блокировщики рекламы, которые тоже надо обходить и доставлять события. На ум приходит идея сделать внешний прокси и напрямую соединить его с сервером Sentry. Однако: 🧨 Если наш сервер Sentry лежит значит мы потеряем события. 🐞 А если в этом endpoint есть какая-то уязвимость, которая выдаст наружу что-то нежелательное? Доставляем события через надежную сеть td-agent'ов. ⚡️ Все наши наработки можно посмотреть в профиле компании на github. #sentry #infrastructure #repository

🐳 НОВЫЕ DOCKER ОБРАЗЫ ДЛЯ СТАРОГО ПО В прошлый раз говорили про runtime docker контейнеров, а сегодня поговорим про еще один интересный случай. Понадобилось поднимать новый Redis 7.2 (шибко не задумываясь взял базовый bookworm) и как обычно: ✔️ локально на Ubuntu 22.04 + Docker 23 работает ✖️ в эксплуатации на Debian 10 + Docker 19 нет

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Fatal: Can't initialize Background Jobs. Error message: Operation not permitted

Warning поправил как здесь, есесно ошибка не решилась. Нагуглил это обсуждение, там есть ссылка на PR #12333 но ничего интересного. 💡 Продолжая искать наткнулся на соседнее обсуждение где предлагают дайнгрейдить образ, а здесь предлагают апгредить систему. Апгрейдить систему точно не будем ... попробовал понизить версию до 7.0.10 на bullseye - заработало ... но хочется иметь свежую версию Redis причем из официального образа Потом пришла мысль выдернуть Dockerfile из репозитория. 🧩 Продолжая искать решение проблемы была найдена интересная статья "является ли Redis однопоточным?" где есть разбор исходников, среди которых вывод той самой ошибки. В статье все на китайском кроме исходников, но через переводчик можно читать) ⚡️ А потом я просто решил попробовать 7.2-alpine и заработало, к тому же образ стал весить на ~100мб меньше. 👉 Вывод: если на старом ПО не заводится Docker контейнер, необязательно сразу даунгрейдить, можно посмотреть другие базовые образы.

🔐 МОНИТОРИНГ СЕРТИФИКАТОВ ISP Пришла задача: надо решить проблемы с сертификатами на сервере с ISP. 😬 Ситуация усугублялась большим количеством неприпаркованных доменов (тысячи), которые не могли получить let's enctypr сертификат с нашего acme аккаунта. 🧨 Точкой кипения стал инцидент учиненный техподдержкой ISP, которая запустила нам перевыпуск сертификатов по всем доменам - мы уперлись в лимиты и начали получать жалобы от клиентов. В конечном итоге: ✔️ героически почистили авгиевы конюшни сервер ISP от лишних сайтов (в прошлом посте софт для обнаружения проблем) ✔️ почувствовали горечь лимитов let's encrypt, но терпеливо переждали бурю ✔️ настроили мониторинг через БД самого ISP и стали мудрее сделали много графиков 👉 Подробнее по ссылке: https://byurrer.ru/isp-ssl-monitoring

🔍 МАССОВАЯ ПРОВЕРКА ДОМЕНОВ 👨‍💻 По работе появилась задача: проверить A записи доменов и валидность сертификатов, доменов несколько тысяч. Сначала на скорую руку накидал php скрипт, было жутко медленно, 40-60 минут. Теперь переписал на многопоточный golang. Вот репозиторий. Что нам нужно: ✔️ убедиться что домен припаркован именно к нашему серверу ✔️ убедиться в валидность сертификата ✔️ скорость, потому что мы проводили стресс-тест на отключение основных серверов и тестировали резервы, нам важно было как можно скорее понять как обстоят дела (все хорошо 😇) ⚡️ Если приложение найдет проблемы то мы должны с ними разобраться. 🗓 Использовать просто, сначала компилируем, а потом:

./domain_checker -n 10 -a "127.0.0.1" "ip,cert" domains.txt

-n - количество потоков -a - список разрешенных IP в A записи, через запятую "ip,cert" - список проверок через запятую, пока доступны две, можно указать одну domains.txt - файл со списком доменов разделенных новой строкой 🏎 Тестировали на 10 потоках, по скорости ~1000 сайтов в минуту. #repository

👉 МЫ ЭТО ПРИВЫЧКИ "Твои деньги в банке это не ты сам", говорил Тайлер Дернен, а Ренат утверждает что ты это твои привычки. 🎭 Привычки это шаблонные действия повторяемые автоматически из раза в раз. ❓ А вам не кажется что эти привычки похожи на те самые паттерны объектно-ориентированного программирования, которые мы применяем ежедневно в своей работе? А что если эти паттерны можно внедрить в свою жизнь и поведение? Ренат мой бывший коллега и настоящий друг. Я наблюдаю за его метаморфозами уже на протяжении года. Чуть ли не каждый день я слышу от него какой-то научный аспект касательно привычек. 👉 А теперь он готов поделиться своими накопленными знаниями и исследованиями научных кругов со всеми желающими в своем марафоне "легкие привычки"! ➡️ Пишите ему в личку он расскажет что будет на этом марафоне и ответит на любые вопросы. Сам тоже планирую поучаствовать, есть позитивный эффект от его разговоров 😁

🔐 ИНЦИДЕНТ С СЕРТИФИКАТАМИ НА ISP Недавно поступила задача разобраться с хаосом сертификатов на сервере с ISP Manager где у нас несколько тысяч сайтов от разных клиентов, валидность которых под вопросом. ⛏ Вопрос целесообразности ISP не поднимается, нужно просто решить проблему. Из-за высокого уровня энтропии, в основном проблемы уровня "невозможно подтвердить владение домена", но есть также проблема невозможности засунуть серт в nginx (например вот и вот):

nginx SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

👨‍💻 В поисках решения проблем гуглил и вел переговоры с ТП ISP. В пятницу ТП решили нам помочь и перевыпустить все сертификаты ... а у нас там тысячи доменов среди которых чуть меньше половины невалидны. 😱 В понедельник начали сыпаться жалобы от клиентов: мы уперлись в лимиты* и больше не могли выпускать новые сертификаты, а новые сайты продолжали регистрироваться на нашем ISP. ТП ISP не помогли урегулировать пожар в который подлили масло. * лимиты на авторизацию доменов для выпуска нового сертификата, это не относится к продлению Спустя 2 дня ситуация не изменилась: мы по прежнему сидим в лимитах и не можем выпускать новые сертификаты. Но появилось время погрузиться в решение проблемы. Читаем спецификацию acme, и статьи от ISP как они с этим работали вот и вот. Гуглим. ⚡️ Оказалось что в такой ситуации мы не одиноки, есть даже проекты на эту тему например вот, вот и вот, а этот вообще веб (ссылка на реп). Но большая часть этих проектов работает по старому протоколу v01, а у нас уже v02. Да и не имеет это смысла, потому что в логах у нас нет enpoint authz с нашими нужными доменами. Возможно потому что наш certbot версии 0.33. У нас назрели 2 пути решения проблемы: 👉 запрос авторизации идемпотентен, а значит мы можем запросить авторизацию снова и получить ключ для отмены уже созданной авторизации - скриптуем процесс и выходим из лимитов 👉 деактивируем текущий acme аккаунт тем самым сбрасывая все авторизации доменов и создаем новый, последствия неизвестны 🥳 Однако, вероятность выхода из лимитов увеличивается с каждым днем и на третий день мы вышли из лимитов. Переписка с ТП ISP по этому инциденту не дала результатов, баг не признают, в планах этого нет. Но зато они подсказали что можно отправить фичреквест. Я опубликовал фичреквест и он был принят в бэклог. Мы плотно взялись за чистку ISP и мониторинг, ибо порядок значительно снижает риск рецидива. А вопрос отмены авторизации оставили разработчикам продукта. #incident #infrastructure