Создание версии докера - PullRequest
0 голосов
/ 31 октября 2018

Я обычно использую простую композицию производственных образов для управления производственными развертываниями, поэтому исключительно полагаюсь на docker-compose.

Я не использую Kubernetes или другие инструменты, поскольку хочу, чтобы в моих простых приложениях было проще (я не развертываюсь на нескольких хостах, не управляю балансировкой нагрузки или не выполняю CD / CI)

Вот как может выглядеть мой производственный состав:

version: '3'

services:
    php:
        image: ${CONTAINER_REGISTRY_BASE}/php:${VERSION}
        depends_on:
          - db
        env_file:
          - ./api.env

    api:
        image: ${CONTAINER_REGISTRY_BASE}/api:${VERSION}
        depends_on:
          - php
          - db

    db:
        image: mariadb:10.2

    client:
        image: ${CONTAINER_REGISTRY_BASE}/client-prod:${VERSION}
        env_file:
          - ./client.env

    admin:
        image: ${CONTAINER_REGISTRY_BASE}/admin-prod:${VERSION}
        env_file:
          - ./admin.env

Сохранение одной глобальной версии для стека приложений в файле .env, когда я обновляю эту версию, мне просто нужно сделать следующее:

docker-compose build
docker-compose push

А на рабочем сервере (после обновления версии)

docker-compose up -d

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

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

Я вижу это неправильно? Разве я не должен использовать docker-compose в производстве? В каком случае, что я должен использовать?

Может кто-нибудь предложить мне простой способ развертывания, основанный на реестре докеров?

1 Ответ

0 голосов
/ 31 октября 2018

Краткий ответ: На самом деле у вас должны быть отдельные сервисы для каждого, и я бы порекомендовал перейти с обычного сервера Docker для вашего производства на Swarm.

Длинный ответ: Если вы перейдете в Docker Swarm, вы можете использовать тот же самый файл compose с несколькими изменениями, чтобы превратить его в файл стека. Это создает ряд сервисов, индивидуально поддерживаемых Swarm.

Во время процесса сборки я бы рекомендовал назначать каждой новой сборке определенный номер версии, а затем специально отмечать его как последний или dev. Нажмите последнюю версию или версию разработчика в хранилище.

Причина этого двоякая:

  1. Когда вы обновляете свой стековый файл, вам нужно будет указать дискретную версию образа для использования. IE 1.2.3 или что-то новое для службы, которую вы только что изменили. Это потому, что если вы попытаетесь использовать «последний», есть хорошее изменение, Swarm даже не попытается получить образ из-за развертывания. Я всегда считал, что лучше избегать двусмысленности в смысле производства.
    1. Для разработчиков, когда бы они ни начинали работать или когда они работали в своей локальной среде, они всегда могут нацеливаться на dev или последнее изображение с помощью переопределений composer (в основном вызывая два файла compose в последовательности, первый из которых имеет определения ядра, второй с изменениями или дополнениями и т. д.)

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

Примечание: Я никогда не находил подходящего варианта использования баз данных, существующих в Docker, из-за (1) нехватки ресурсов или (2) интеграционного тестирования.

...