Развертывание с нулевым временем простоя Node.js/NGINX Docker

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

Я понял, что с помощью docker-compose я могу масштабировать свой контейнер вверх/вниз, но я не уверен, как отправить свой код только в 1 из них, перестроить веб-пакет и перезапустить его npm, а затем убить другие контейнеры. Я действительно не хочу использовать 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;
}
}

person Hirad Roshandel    schedule 13.03.2018    source источник
comment
почему вы делаете down, вы можете просто build изображения, а затем docker-compose up -d, и это создаст только эти новые объекты   -  person Mazel Tov    schedule 13.03.2018
comment
@MazelTov, потому что мне нужно в основном убить работающий сервер узла и снова запустить npm. если вы посмотрите на мой контейнер узла, он запускает скрипт, который обрабатывает это. Я не вношу никаких изменений в свой образ Node.js, поэтому его не нужно перестраивать. Мы просто вносим реагирующие изменения   -  person Hirad Roshandel    schedule 13.03.2018
comment
тогда вы можете сделать только docker-compose restart node, но если вы сделаете down, он удалит сеть, остановит все контейнеры и т. д.   -  person Mazel Tov    schedule 13.03.2018
comment
мое мнение таково, что вы должны создать свой образ с кодом внутри, а не монтировать папку с кодом в тот же контейнер.   -  person Mazel Tov    schedule 13.03.2018
comment
@MazelTov Я попробую перезапустить узел и дам вам знать. Что вы подразумеваете под созданием изображения с кодом внутри? Означает ли это, что я не должен использовать громкость?   -  person Hirad Roshandel    schedule 13.03.2018
comment
я предпочитаю, чтобы мой рабочий образ был протестирован перед развертыванием, а когда он был развернут, чтобы он был максимально безопасным. Вот почему я создаю свои образы в gitlab-ci, затем тестирую образ, а затем развертываю его, и код всегда находится в образе, а не смонтирован... возможно, этот подход тоже будет излишним для вас.   -  person Mazel Tov    schedule 13.03.2018
comment
технически вы можете перезапускать каждый масштабируемый контейнер отдельно, потому что они называются foldername_container_1, но ваш nginx всегда случайным образом выбирает один из этих контейнеров с именем node, поэтому, если вы получите доступ к узлу во время перезапуска, он выдаст ошибку, я думаю   -  person Mazel Tov    schedule 13.03.2018
comment
@MazelTov Спасибо за объяснение. Ваше решение сработало. Вы хотите написать это как ответ, чтобы я мог принять его?   -  person Hirad Roshandel    schedule 14.03.2018


Ответы (1)


более быстрый способ обновления контейнера

docker-compose restart node

потому что, если вы сделаете docker-compose down, это приведет к отключению всех служб, удалению настроенных сетей.

Если у вас масштабированная служба, вы можете попробовать перезапустить ее с помощью

docker restart foldername_node_2

и у вас может быть 0 простоев, но конфигурации nginx недостаточно, потому что он случайным образом выберет node машину, поэтому вам придется реализовать какой-то сервер резервного копирования

person Mazel Tov    schedule 14.03.2018
comment
кроме того, вы хотели бы установить значение -t при перезапуске, иначе он будет использовать 10 секунд по умолчанию, поэтому вы можете использовать что-то вроде docker restart -t1 node, чтобы уменьшить это до 1 секунды. (Возможно, вам понадобится небольшая задержка, поэтому точная сумма зависит от вашей ситуации.) - person ldg; 15.03.2018