Образы контейнеров FROM scratch стоит ли так делать? 🤔

Довольно часто можно встретить практику, когда статически слинкованный бинарник на Go просто кладут в образ, собранный FROM scratch. Но у такого подхода есть ряд подводных камней:

- нет rootfs-лейаута

- отсутствуют CA-сертификаты

- нет базы данных часовых поясов

Решение? Использовать distroless-базу вместо этого

Подробнее о проблеме и одном из возможных решений:
🔹Building Container Images FROM Scratch: 6 Pitfalls That Are Often Overlooked
🔹What's Inside Distroless Container Images: Taking a Closer Look

👉 DevOps Portal

Мы все знаем, что у AWS недавно случился даунтайм. Давайте разберём, что именно произошло.

Регион US-EAST-1 — один из крупнейших и наиболее критичных дата-центров AWS, где размещена инфраструктура тысяч крупных сайтов и приложений. Когда у DynamoDB, ключевого сервисa баз данных, начали расти ошибки, это вызвало эффект домино по взаимосвязанным системам AWS. Сбои стали массовыми, потому что многие приложения полагаются на DynamoDB для операций хранения и выборки данных.

DynamoDB глубоко интегрирован в архитектуру control plane AWS. Многие сервисы AWS используют его внутри для хранения метаданных, информации о состоянии и конфигураций сервисов. Поэтому, когда API-эндпоинт DynamoDB стал недоступен через DNS, зависящие от него сервисы потеряли доступ к критически важным операционным данным. Сбой одновременно затронул более 36 сервисов AWS.

Когда упала DNS-резолюция, клиенты просто перестали находить нужные эндпоинты DynamoDB. Это запустило фидбек-луп, похожий на тот, что произошёл во время даунтайма DynamoDB в сентябре 2015 года: каждый повторный запрос потреблял больше ресурсов, вызывал новые таймауты, которые, в свою очередь, генерировали ещё больше ретраев - и так по кругу, пока система не ушла в штопор.

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

Основное исправление заключалось в стабилизации инфраструктуры DNS-резолвинга для эндпоинта DynamoDB. Команды инженеров AWS, вероятно:

🔹переконфигурировали или перезапустили DNS-резолверы, обслуживающие DynamoDB

🔹временно перевели трафик на альтернативные пути DNS-резолвинга

🔹применили аварийные настройки DNS-кэширования

Этот инцидент отражает взаимозависимость и хрупкость крупномасштабных облачных экосистем, где даже единственная точка отказа в базовом сервисе способна за минуты вызвать каскад проблем в десятках систем.

P.S. Это лишь часть деталей и предположений, которые я нашёл в интернете и сформировал на основе собственного понимания. Точные и подробные данные AWS ещё не раскрыл.

👉 DevOps Portal