Сейчас я DevOps/Cloud архитектор, и когда делюсь опытом, одна из первых тем - “никогда не используйте :latest в production”. Эта история рассказывает мой случай “почему”.
Немного контекста
Работали мы в Azure Kubernetes, команда логгинг/мониторинг. Собирали кастомный OpenSearch, пайплайн билдил образ, вешал версию и переставлял тэг :latest.
После каждого билда мы руками меняли версию в Helm чарте для деплоя. И вот сидим с коллегой, смотрим на очередной перезапуск StatefulSet и думаем: “А зачем? Давай просто :latest используем? Мы же все равно сразу деплоим?”
Поменяли. PullPolicy был Always, вроде норм.
В чем косяк
Хватило на два деплоя в dev. Потом вылезли нюансы:
- Откатить версию просто так нельзя
- Протестировать образ отдельно перед деплоем нельзя - он сразу катится
- И главное: dev для разработчиков был dev, а для нас - вполне себе прод. Логи-то им все равно нужны)))
Быстро пофиксили, вернули версии. Рабочий момент.
Свежий пример
Месяц назад помогал команде с падением MongoDB в dev:
image: mongo # без тэга, а значит используется latest
Ноду на maintenance убрали, под переехал и образ перекачался. А 16 дней назад вышла Mongo v8, тэг :latest переехал на нее. Под поднялся с новой версией, а в storage лежала база от старой - несовместимая. Dev не работал несколько часов.
Разработчики были скорее удивлены чем расстроены - они ж в docker compose работают локально, так что для них это просто “хм, интересно, не знали что так бывает”.
Сейчас я всегда использую явные версии в манифестах. :latest только в локальной разработке, и то не всегда.
Когда хочу подушнить, или объясняю нюансы, то упоминаю что: тэг :latest - это не “последняя стабильная”, это “что там сейчас под этим тэгом лежит”. Погуглите “:latest problems” - тонны историй “10 способов выстрелить себе в ногу”.
Расскажете свою историю с :latest?