Как Elasticsearch поломал сборки и «обнулил» звёзды в Github
Казалось бы, майская история с Docker hub должна была научить всех нас уделять больше времени на обеспечение целостности артефактов проекта, но на то мы и люди, чтобы учиться на своих (и чужих) ошибках не с первого раза. В этой статье я поведаю про настоящую историю, которая в этот раз не связана с образами, но связана с библиотеками.
Обыкновенный вторник второй половины октября, через час запланирован релиз в продакшн, ничего не предвещало, а ожидаемые заказчиком фичи уже протестированы вдоль и поперёк, ожидая своего часа.
В какой-то момент от коллег поступает информация о том, что официальная библиотека elasticsearch-php в момент сборки через composer install
перестала устанавливаться.
Состояние Github репозитория elasticsearch-php
Ринувшись разбираться в вопросе, выясняем, что Github репозиторий удален и теперь там красивая ошибка 404.
Как же так? Что произошло? Вот так просто удалить без какого-либо анонса? Что-то здесь неладное…
Работать нужно, но работать не дают, начинаем гуглить и искать интересующую нас информацию по сообщениям в чатах Telegram. Находим ссылку в дискуссиях на официальном ресурсе компании, где представитель команды сообщил, что часть публичных репозиториев временно недоступны, там же прикреплена ссылка на страницу с логами по инциденту.
Фрагмент логов, проясняющих ситуацию:
As part of an internal change task, some of our public git repositories hosted under Elastic’s GitHub organisation were marked as private. As a result, when attempting to access these repositories an error may be seen. Our teams are working to restore these with urgency.
Перевод: В рамках внутренней задачи по изменению некоторые из наших публичных репозиториев git, размещенных в организации Elastic GitHub, были помечены как приватные. В результате при попытке доступа к этим репозиториям может возникнуть ошибка. Наши команды работают над их срочным восстановлением.
Первое о чем я подумал, вспоминая свой предыдущий опыт смены видимости репозитория с Public на Private: «кажется, сейчас elastic потерял заработанные годами звёзды» (механизм смены видимости репозитория в Github работает по методу удаления и создания заново со сбросом числовых значений в шапке).
Релиз на носу, а с поиском что-то нужно делать, любой ценой катим фичи. Учитывая, что поиск на проекте это не основной функционал, а вспомогательный, принимается решение удалить зависимость с бэкенда и визуально скрыть форму поиска для пользователей — composer remove
в помощь. Управились быстро, релиз спасён, основные фичи поехали в продакшн без задержек по времени.
Уже вечером, после работы, с чашечкой чая, мне стало интересно, а что еще из популярного у Elastic было затронуто, начинаю изучать их репозитории. Подведя итоги, сравнив количество звёзд в Яндекс кэше, получаю следующий результат (актуально на момент написания статьи 30.10.24):
Пример на репозитории elasticsearch: факт и кэш Яндекс
Как выглядит репозиторий elasticsearch сейчас (30.10.2024)
Как выглядит репозиторий elasticsearch в кэше Яндекса (кэш от 28.10.2024)
Вам очень повезло, если процесс сборки на вашем проекте настроен по всем канонам безопасности, вы — молодцы! Возможно, вы просто не заметили данное событие, но это тоже хорошо.
На момент написания данного текста все известные мне (официальные) репозитории Elastic были восстановлены.
Под конец статьи хочу сказать следующее: берегите то дело, ради которого мы тратим столько сил и энергии, берегите ваши проекты и ваших заказчиков. Относитесь серьезно к процессу сборки и созданию резервных копий.
Это моя первая статья на данной площадке, в будущем постараюсь снабжать вас интересным контентом и новостями из мира IT.
Спасибо за внимание, Хабр!