Почему после ребрендинга я оставил старое имя Docker Compose — иначе поднялась бы пустая база

Значимый прорыв формирует отрасль ИИ: crymans 12 минут назад Почему после ребрендинга я оставил старое имя Docker Compose — иначе поднялась бы пустая база Средний 7 мин 369 Веб-разработка * DevOps * Кейс Новое имя. Снаружи проект уже называется по-новому. Домены, логотип, тексты, почта — всё переехало.

Но на сервере до сих пор живёт строка:name: legacy-prod И контейнер базы по-прежнему называется примерно так:legacy-prod-db-1 Это не забытый пункт ребрендинга. Я оставил старое имя специально. Когда начал готовить переезд, первой мыслью было заменить старое название по всему репозиторию.

Технические детали

Обычный поиск находил его в Compose, названиях баз, OAuth-клиентах, переменных окружения, миграциях и путях. Выглядело как механическая работа на вечер. Но строка в заголовке Compose — не подпись под логотипом.

Это namespace для инфраструктуры. Если «красиво» переименовать её вместе с сайтом, Docker не перенесёт данные. Он создаст новый набор ресурсов и запустит на них полностью исправное приложение.

Именно полностью исправное. С зелёными healthcheck и пустой базой. Почему name: влияет на данныеВ production Compose-файле база подключена к логическому тому postgres_data:name: silvercode-prod services: db: image: postgres:17-alpine volumes: - postgres_data:/var/lib/postgresql/data volumes: postgres_data:Но в Docker Engine том получает не просто имя postgres_data.

Отраслевые последствия

Compose добавляет namespace проекта:silvercode-prod_postgres_dataЕсли поменять одну строку:- name: silvercode-prod + name: iconcode-prodследующий docker compose up -d запросит уже другой том:iconcode-prod_postgres_dataТакого тома нет, поэтому Compose создаст его. Postgres увидит пустой каталог, штатно выполнит инициализацию, создаст базы из init-скрипта и станет healthy. Смена project name создаёт другой набор volumesСтарый том никуда не исчезает.

Данные физически остаются на диске. Но приложение больше к ним не подключено, поэтому снаружи картина почти не отличается от потери данных:список пользователей пуст;контент исчез;заказы исчезли;миграции стартуют на чистой схеме;администратор снова видит первоначальную установку. На этом месте легко сделать ситуацию хуже.

Увидеть пустую базу, решить, что старый stack больше не нужен, и запустить docker compose down -v. Вот тогда временная ошибка маршрутизации тома превращается в настоящее удаление. Я стараюсь вообще не использовать -v в процедурах обновления.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.