Назад | Перейти на главную страницу

Нулевое время развертывания Docker для Node.js

У меня есть приложение React / Node.js, работающее на одном сервере с использованием docker-compose. Я пытаюсь добиться нулевого времени простоя для моего приложения для реагирования. Прямо сейчас процесс выполняет сборку веб-пакета (заменяет файлы в моей папке dist), а затем докер вниз и докер вверх. Весь этот процесс занимает около 2-3 минут. Я понял, что с помощью docker-compose я могу масштабировать свой контейнер вверх / вниз, но я не уверен, как подтолкнуть свой код только к одному из них и перестроить веб-пакет. Я действительно не хочу использовать Kubernetes / Swarm или Openshift, потому что это немного излишне. Мне интересно, добился ли кто-нибудь еще чего-то подобного.

Мой docker-compose выглядит так:

node:
    build:
        context: ./env/docker/node
        args:
            - PROJECT_ROOT=/var/www/app
    image: react_app:rapp_node
    command: "npm run prod"
    expose:
        - "3333"
    networks:
        - react-net
    volumes_from:
        - volumes_source
    tty: false

nginx:
    env_file:
        - ".env"
    build:
        context: ./env/docker/nginx
    volumes_from:
        - volumes_source
    volumes:
        - ./env/data/logs/nginx/:/var/log/nginx
        - ./env/docker/nginx/sites/node.template:/etc/nginx/node.template
    networks:
        - react-net
        - nginx-proxy
    environment:
        NGINX_HOST: ${NGINX_HOST}
        VIRTUAL_HOST: ${NGINX_VIRTUAL_HOST}
        LETSENCRYPT_HOST: ${NGINX_VIRTUAL_HOST}
        ESC: $$
    links:
        - node:node
    command: /bin/sh -c "envsubst < /etc/nginx/node.template > /etc/nginx/sites-available/node.conf && nginx -g 'daemon off;'"

volumes_source:
    image: tianon/true
    volumes:
        - ./app:/var/www/app

А мой nginx выглядит примерно так:

server {
server_name www.${NGINX_HOST};
return 301 ${ESC}scheme://${NGINX_HOST}${ESC}request_uri;
}

server {
listen 80;
server_name ${NGINX_HOST};

root /var/www/app;

location / {
proxy_pass http://node:3333;
proxy_http_version 1.1;
proxy_set_header Upgrade ${ESC}http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host ${ESC}host;
proxy_cache_bypass ${ESC}http_upgrade;
}
}

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

Да, вам действительно следует создавать новую версию своего изображения с вашим кодом при каждом коммите, который вы планируете отправить на этот сервер. Инструменты рассчитаны на этот тип рабочего процесса, поэтому вам будет легче, если вы воспользуетесь этим рабочим процессом. Docker Hub поддерживает выполнение этого за вас при каждой фиксации в ветке (бесплатно, если с открытым исходным кодом, и все еще бесплатно для одного частного репо) GitHub и BitBucket. Вот как это будет работать в рое с одним узлом, если вы каждый раз создаете новые образы в Docker Hub:

Предполагая, что вы используете последнюю стабильную версию докера (17.12 на момент публикации)
docker swarm init и теперь у вас есть рой с одним узлом. Вот и все. (Если бы у меня был только один сервер для развертывания докеров на Я всегда использую single-node-swarm, а не docker-compose по списку веских причин..
С небольшими изменениями ваш файл композиции можно использовать в качестве файла стека для docker stack deploy -c compose-file.yml stackname
Чтобы обеспечить нулевое время простоя при развертывании, вам нужно: добавить проверки работоспособности в ваши контейнеры node / nginx, чтобы они знали, когда приложение действительно «готово к подключению». Swarm также использует это при обновлении сервисов, так что это ключ.
Если вы хотите, чтобы Swarm сначала добавил новый контейнер, перед удалением старого контейнера добавьте order: start-first к https://docs.docker.com/compose/compose-file/#update_config.
Затем просто измените теги изображений в файле создания, возможно myuser/myrepo:1.0 к myuser/myrepo:2.0 а затем снова запустите ту же команду развертывания стека, и Swarm обнаружит различия и обновит службу новым образом (путем замены контейнера).

Чтобы проверить это, используйте httping, чтобы убедиться, что он все еще доступен удаленно во время процесса обновления.

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

Но, если вы хотите именно то, что написали (но это неверный путь вообще), вы можете, например, запустить сценарий в контейнере, который будет проверять новую версию вашего приложения, строить ее и переключать символическую ссылку со старой версии на новую, что вы можете сделать атомарно следующим образом: ln -s new current_tmp && mv -Tf current_tmp current.

Итак, структура каталогов будет такой: /var/www/app - symlink to your current version /var/www/app_v1 - directory with current version, which symlinked to "/var/www/app" /var/www/app_v2 - directory with new version

Итак, теперь вы можете запустить команду ln -s /var/www/app_v2 /var/www/app_v2_sym && mv -Tf /var/www/app_v2_sym /var/www/app для переключения текущей версии приложения, которое использует Nginx.