Сценарий 2. Добавить микросервис в существующий проект

Добавляется одна запись, существующее не трогается
Добавляется одна запись, существующее не трогается

Это самый частый сценарий и самый спокойный. Вы дописываете одну запись в список services и мержите.

services:
  - name: api           # уже был
    tier: backend
    stack: python
    datastores: [postgres]

  - name: notifications # добавили
    tier: backend
    stack: python
    datastores: [postgres]
    worker: true

#Почему это безопасно

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

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

#Что стоит указать, а что нет

worker: true добавляет второй процесс от того же образа — очередь, планировщик, что-то, что работает не по запросу. Ставьте, если такой процесс правда есть. В примере выше он есть, потому что в репозитории лежит конфигурация celery и она запускается в docker-compose. Не ставьте «на будущее»: пустой воркер выглядит работающим и ничего не делает.

datastores перечисляет, чем сервис пользуется. Каждый упомянутый postgres даёт сервису схему, названную по нему.

hostnames только если сервис должен быть доступен снаружи. Внутренние сервисы имён хостов не получают, и это нормальное, а не урезанное состояние.

Порт снова не указывайте, если он не особенный. Новый бэкенд получит следующий номер в своей группе.

#Что произойдёт с сервисом, который вы уберёте

Ничего не удалится.

Убранный из описания сервис объявляется осиротевшим и продолжает работать. Служба напишет про него на странице состояния и не тронет.

Это выглядит как недоделка, а сделано намеренно. Выключить работающий сервис — решение с последствиями для людей, которые им пользуются, и его принимает человек, а не таймер, сработавший через пять минут после мержа. Если сервис действительно надо погасить, это отдельная осознанная работа.

#Если репозитория для сервиса ещё нет

Служба скажет, что репозиторий не переехал, и не станет его создавать.

Причина та же по духу: созданный на пустом месте репозиторий стоял бы рядом с живым проектом, никем не собирался и никем не читался, но выглядел бы настоящим. Пустое место, про которое сказано вслух, честнее.

#Проверка после мержа

Загляните на страницу состояния через несколько минут. Полезно смотреть не только на «сделано», но и на то, что служба делать отказалась: там будет причина, если что-то из ожидаемого не появилось.