Сбой в ЦОД Canonical: 20+ сервисов Ubuntu, включая Launchpad и keyserver

Что случилось

11 ноября около 21:00 по московскому времени Canonical предупредила пользователей: часть сервисов и сайтов проекта Ubuntu работает с перебоями или недоступна. Причина — сбой в одном из дата-центров, обслуживающих инфраструктуру проекта. Актуальное состояние компания предлагала смотреть на странице status.canonical.com.

Детали

Список пострадавшего оказался широким — больше двадцати имён:

• сайты ubuntu.com, canonical.com, launchpad.net, snapcraft.io, blog.ubuntu.com, developer.ubuntu.com, academy.canonical.com, portal.canonical.com, assets.ubuntu.com, maas.io, jaas.ai и gopkg.in;
• почтовые и DNS-серверы проекта;
• сервисы разработки и сборки: ppa.launchpad.net, cloud-images.ubuntu.com, images.maas.io, streams.canonical.com, ubuntu-archive-team.ubuntu.com;
• инфраструктура доверия и доступа: keyserver.ubuntu.com вместе с портом 11371, login.ubuntu.com, Ubuntu Security API, API Livepatch, contracts.canonical.com, Landscape и lists.ubuntu.com.

Доступ к самому репозиторию пакетов сохранился: apt-обновления на машинах, настроенных на штатные зеркала, продолжали ставиться.

Что это значит

На практике сбой ударил по трём сценариям. Первый — сборка и образы: без cloud-images.ubuntu.com и images.maas.io не скачать свежие облачные образы, без streams.canonical.com не обновляются их метаданные, без ppa.launchpad.net не собрать пакеты из личных архивов. Второй — доверие к ключам: keyserver.ubuntu.com нужен при добавлении репозиториев и проверке подписей, и на время сбоя его нет. Третий — эксплуатация: недоступными были API Livepatch и Landscape, то есть проверка статуса патчей ядра и управление парком машин.

Отдельно стоит отметить DNS и почту домена: пока лежат авторитативные серверы зоны, проблемы начинаются не только у сайтов, но и у доставки писем и у разрешения имён поддоменов.

Практические выводы для своего парка:

• держать локальное зеркало или кеш пакетов, чтобы сервисы вендора не были единственной точкой отказа;
• хранить нужные GPG-ключи локально и не рассчитывать на онлайн-keyserver в момент установки;
• кешировать образы и метаданные на своих ресурсах, а не тянуть их при каждом развёртывании;
• не путать доступность репозитория с доступностью остальных сервисов: apt работал, а привычные вспомогательные страницы — нет.

Порядок действий в момент такого сбоя простой. Сначала проверить, не завязаны ли сборочные конвейеры на внешние адреса вендора: CI, который тянет образы напрямую с cloud-images.ubuntu.com, встанет целиком, а сборка из локального зеркала пройдёт. Затем — убедиться, что внутренние репозитории и прокси разрешаются своим DNS, а не ждут ответа от серверов проекта. И только потом разбираться с второстепенным: страницы документации и порталы успеют вернуться сами.

Canonical не раскрывала технических подробностей сбоя и не называла площадку. Но случай показателен сам по себе: сайт, сборка, ключи и управление патчами у проекта оказались в одном дата-центре — и упали вместе.