☰

제로 다운 타임 배포 Node.js Docker

tag-icon • tag-icon docker kubernetes docker-compose docker-swarm
제로 다운 타임 배포 Node.js Docker

docker-compose를 사용하여 단일 서버에서 실행되는 React/Node.js 애플리케이션이 있습니다. 내 반응 앱에 대해 가동 중지 시간이 0인 배포를 달성하려고 합니다. 현재 프로세스는 webpack 빌드(내 dist 폴더의 파일 대체)를 수행한 다음 docker down 및 docker up을 수행합니다. 이 전체 과정은 약 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;
}
}

답변1

더 좋은 방법은 이를 위해 오케스트레이터를 사용하는 것이라고 생각합니다. 모두 롤링 업데이트를 지원하며 표준 업데이트 흐름을 사용할 수 있습니다.

그러나 당신이 쓴 내용을 정확히 원한다면 (하지만 그것은 올바른 방법이 아니다조금도), 예를 들어 컨테이너에서 스크립트를 실행하면 애플리케이션의 새 버전을 체크아웃하고 이를 빌드한 후 이전 버전에서 새 버전으로 심볼릭 링크를 전환할 수 있습니다. 이 작업은 다음과 같이 원자적으로 수행할 수 있습니다 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/appNginx가 사용하는 현재 버전의 애플리케이션을 전환하는 명령을 실행할 수 있습니다.

답변2

이를 위해 간단한 단일 노드 떼를 적극 권장합니다. 업데이트 중에 다운타임이 없어야 하지만 다중 노드 고가용성이 필요하지 않거나 필요하지 않은 경우에 완벽한 솔루션입니다. 실제로 오버헤드나 더 많은 관리 부담을 추가하지 않으며 동일한 작성 파일을 사용합니다.

네, 실제로 이 서버에 제공하려는 모든 커밋에서 코드를 사용하여 이미지의 새 버전을 구축해야 합니다. 도구는 이러한 유형의 워크플로를 기대하므로 해당 워크플로를 채택하면 더 쉽게 작업할 수 있습니다. Docker Hub는 GitHub 및 BitBucket의 분기(오픈 소스인 경우 무료, 단일 개인 저장소의 경우 무료)에 대한 모든 커밋에서 이 작업을 지원합니다. Docker Hub에서 매번 새 이미지를 빌드한다고 가정하면 단일 노드 떼에서 작동하는 방법은 다음과 같습니다.

  1. 최근 안정적인 도커 버전(이 게시물 현재 17.12)을 사용한다고 가정합니다.
  2. docker swarm init이제 단일 노드 떼가 생겼습니다. 그게 다야. (도커를 배포할 서버가 하나만 있을 수 있는 경우나는 항상 좋은 이유 목록 때문에 docker-compose가 아닌 단일 노드 스웜을 사용합니다..
  3. 몇 가지 사항을 변경하면 Compose 파일을 스택 파일로 사용할 수 있습니다.docker stack deploy -c compose-file.yml stackname
  4. 다운타임 없는 배포를 보장하려면 다음을 수행해야 합니다.상태 확인 추가노드/nginx 컨테이너에 연결하여 앱이 실제로 "연결 준비"가 된 시기를 알 수 있습니다. Swarm은 서비스 업데이트 중에도 이를 사용하므로 이것이 핵심입니다.
  5. Swarm이 먼저 새 컨테이너를 추가하도록 하려면 기존 컨테이너를 제거하기 order: start-first전에https://docs.docker.com/compose/compose-file/#update_config.
  6. 그런 다음 구성 파일에서 이미지 태그를 변경하고 동일한 스택 배포 명령을 다시 실행하면 Swarm이 차이점을 감지하고 (컨테이너를 교체하여) 서비스를 새 이미지로 업데이트합니다 myuser/myrepo:1.0.myuser/myrepo:2.0

이를 테스트하려면 httping을 사용하여 업데이트 프로세스 중에 원격으로 계속 사용할 수 있는지 확인하세요.

관련 정보