Simple is Beautiful.

0. 앞선 글

Docker 이미지의 태그들 중에서 -alpine이라는 태그가 달려있는 이미지들을 자주 볼 수 있습니다. 이 글에선 alpine이 무엇인지, 왜 사용하는지에 대해서 알아봅니다.

이 글은 The 3 Biggest Wins When Using Alpine as a Base Docker Image을 번역 한 글입니다.

1. Alpine?

Alpine은 다음과 같이 설명됩니다.

Small. Simple. Secure. Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
- 가볍고 단순하며 안전합니다. 알파인 리눅스는 musl libc와 busybox를 기반으로 한 보안지향의 경량 리눅스 배포판입니다.

2. 가장 큰 이점은 컨테이너의 용량이 작아진다는 것입니다.

세탁과 같은 상황에서 줄어든다는 것은 나쁜 상황이겠지만 Docker의 세계에서는 Docker 이미지가 더 작아진다는 의미이므로 기대할만한 상황이 됩니다.

Alpine 3.6의 Dockerized 버전의 무게는 3.98MB입니다.

비교를 위해 Alpine을 다른 인기 Linux 배포판과 비교해 보자면 그 크기는 다음 표와 같습니다: 

크기 차이 좀 보세요. 알파인은 데비안보다 약 30배 작습니다.

Docker Hub는 수많은 풀을 처리합니다. API를 조사해 보면 이 글이 작성되는 시점(2017년도 기준)에 Debian에 35,555,107개의 pull이, Alpine은 135,136,475개의 pull이 있었음을 알 수 있습니다.

이러한 pull로 인해 모든 바이트가 전송될까요? 아마도 그렇지 않을 것입니다. 그러나 당신이 한 예상은 제가 한 것처럼 좋을 것입니다. 최소한 상황을 보는 관점은 되어줍니다.

S3를 통해 Debian과 Alpine을 최대 3,500만 번 전송하는 데 드는 예상 비용:

S3의 가격 계산기 비용으로 Debian과 Alpine을 최대 3,500만 번 전송하는 데 거의 $400,000 USD의 차이가 발생하게 됩니다..

아마도 여러분이 그 정도의 규모로 운영하고 있지 않을 것이라는 건 압니다. 그러나 모든 규모 수준에서 클라우드의 전송 비용에 있어서는 실질적인 절감 효과가 있습니다.

이미지 크기를 100MB 이상 줄일 수 있다는 것은 큰 일입니다.

많은 패키지가 설치된 실제 웹 애플리케이션에서 Alpine을 사용하면 최종 이미지 크기가 2배 또는 3배 정도 절약되므로 마이크로 벤치마크에만 유용한 것은 아닙니다. 최대 100MB 절약은 이미지에 무엇이 내장되어 있는지에 관계없이 고정되어 있는 이점입니다.

3. 알파인은 빠릅니다.

더 작은 Docker 이미지를 처리할 때 비용만이 유일한 장점은 아닙니다.

Docker 이미지를 다운로드하고  CURL을 설치하고 싶다고 가정해 보겠습니다. Debian과 Alpine의 경우 시간이 얼마나 걸릴까요?

여기서는 2가지 테스트를 수행하겠습니다.

첫 번째 테스트는 30MB 가정용 케이블 연결을 사용하여 기본 Docker 이미지를 시스템에 다운로드하고 CURL을 설치할 것이며 시스템에 이미지가 다운로드되어있지 않은 환경입니다.

두 번째 테스트는 CURL을 설치하기 전에 시스템에 이미 기본 Docker 이미지가 있다는 점을 제외하면 위와 동일합니다.

테스트 1의 결과:

## Debian
time docker run --rm debian sh -c "apt-get update && apt-get install curl"
real 0m 27.928s
user 0m 0.019s
sys 0m 0.077s

Debian을 모두 다운로드하고 apt-get 업데이트를 실행한 다음 CURL을 설치하는 데 실제 시간은 약 28초입니다.

## Alpine
time docker run --rm alpine sh -c "apk update && apk add curl"
real 0m 5.698s
user 0m 0.008s
sys 0m 0.037s

반면에 Alpine을 사용하면 약 5배 더 빠르게 완료되었습니다. 28초와 5초를 기다리는 것을 비교하는 건 가벼운 게 아닙니다. 상당한 시간입니다.

프로그래밍 테스트가 30초 또는 5초 안에 완료될 때까지 기다리는 것이 얼마나 짜증 나는 일인지 생각해 보십시오.

테스트 2의 결과:

## Debian
time docker run --rm debian sh -c "apt-get update && apt-get install curl"
real 0m 9.170s
user 0m 0.000s
sys 0m 0.031s

분명히 30MB 케이블이 병목 현상을 일으키고 있어 apt-get update를 실행하고 컬을 설치하는 데에는 9초 이상이 걸렸습니다.

##Alpine

time docker run --rm alpine sh -c "apk update && apk add curl"
real 0m 3.040s
user 0m 0.017s
sys 0m 0.008s

반면 알파인은 단 3초 만에 완료했습니다. 약 3배 정도 개선된 셈입니다.

새 Docker 이미지를 새로운 서버로 다운로드할 때 Alpine에서 초기 풀링 속도가 상당히 빨라질 것으로 예상할 수 있습니다. 네트워크 속도가 느릴수록 그 차이는 더 커집니다.

자동 확장 기능이 있고 많은 서버를 가동하는 경우라면 이는 매우 큰 문제입니다. 이는 서버가 더 빠른 속도로 트래픽을 수용할 준비가 되었음을 의미합니다.

서버를 많이 가동하지 않으면 속도 이점이 크게 떨어지지만 데이터 전송 및 저장 비용은 여전히 100MB 이상 절약됩니다.

4. 알파인은 안전합니다.

크기가 훨씬 작은 또 다른 장점은 공격을 받는 표면적이 훨씬 적다는 것입니다.

시스템에 패키지와 라이브러리가 많지 않으면 잘못될 수 있는 일이 거의 없습니다.

몇 년 전에 "ShellShock"이라는 이름으로 공격해 해커가 피해를 입은 경우 컴퓨터에 대한 제어권을 얻을 수 있는 불쾌한 Bash 공격이 있었습니다.

알파인에는 Bash는 기본적으로 설치되지 않기 때문에 해당 공격에서 무사했습니다..

또한 대부분의 배포판은 기본적으로 수많은 서비스를 실행합니다. 최신 Debian 또는 Ubuntu 시스템의 ps aux 출력 길이는 1마일이나 됩니다. 이는 Docker가 아닌 설정에서는 합리적일 수 있지만 Dockerized 애플리케이션에는 기본적으로 시작되는 대부분의 작업이 필요하지 않을 가능성이 있습니다.

알파인은 훨씬 다른 접근 방식을 취합니다. 기본적으로 너무 많이 시작하지 않으며 필요한 것만 시작하기를 기대합니다. 이는 Dockerized 애플리케이션에 적합합니다.

작업에 가장 적합한 도구를 사용하세요

알파인은 보안 전반에 대해서도 강력한 입장을 취했습니다. 개발팀은 특정 패키지를 보다 안전한 버전으로 교체하는 것을 두려워하지 않습니다. 예를 들어 OpenSSL을 LibreSSL로 대체했습니다.

위에 링크된 페이지에서 이 인용문이 정말 마음에 듭니다.

While OpenSSL is trying to fix the broken code, libressl has simply removed it.

 - OpenSSL이 손상된 코드를 수정하려고 시도하는 동안 libressl은 이를 제거했습니다.

제 생각엔 이것이 바로 알파인의 특징이라고 생각합니다. 작고 안전한 Linux 배포판이 되겠다는 약속을 실제로 실천하고 있습니다. 기본 Docker 이미지로 사용될 때 Docker와 함께 사용하기에 완벽한 콤보입니다.

RabbitMQ를 Docker Container로 실행하는 방법에 대해 알아봅니다.

0. 준비사항

해당 포스트는 Docker 및 docker-compose를 이용해 RabbitMQ를 실행합니다. Docker와 docker compose를 미리 준비합니다.

1. docker-compose.yml

다음과 같이 docker-compose.yml 파일을 작성합니다.

version: '3'
services:
  rabbitmq:
    image: rabbitmq:3.12.4-management-alpine
    container_name: smoh-rabbitmq
    volumes:
      - ./rabbitmq-data/etc/:/etc/rabbitmq/
      - ./rabbitmq-data/data/:/var/lib/rabbitmq/
      - ./rabbitmq-data/logs/:/var/log/rabbitmq/
    ports:
      - "5672:5672"
      - "15672:15672"
    environment:
      RABBITMQ_ERLANG_COOKIE: "RabbitMQ-Cookies"
      RABBITMQ_DEFAULT_USER: "smoh"
      RABBITMQ_DEFAULT_PASS: "password"

2. 컨테이너 실행 및 rabbit management 활성화

다음 명령어를 실행해 컨테이너를 실행합니다.

docker-compose up -d

컨테이너가 실행되면 다음 명령어를 통해 bash로 진입합니다.

docker exec -it ##### /bin/bash

bash에서 다음 명령어를 수행해 rabitmq-management를 활성화시켜 줍니다.

rabbitmq-plugins enable rabbitmq_management

3. 접속 테스트

docker-compose에 작성한 WebUI 포트로 접속해 계정 및 암호를 입력한 뒤 Management 페이지를 확인합니다.

정상적으로 동작하는 것을 확인할 수 있습니다.

Ubuntu Jenkins에서 docker build시 Docker permission denied 문제를 수정하는 방법에 대해 알아봅니다.

1. 문제

Ubunto 20.04에 설치된 Jenkins 2.317 버전에서 docker build시 다음 에러 메시지와 함께 permission denied 에러가 발생합니다.

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=my-app%3Alatest&target=&ulimits=null&version=1": dial unix /var/run/docker.sock: connect: permission denied

2. 원인 및 수정

jenkins 유저가 docker에 접근할 권한을 설정해야 합니다. 다음 명령을 통해 docker에 권한을 부여합니다

> sudo usermod -aG docker jenkins

이후 Jenkins 서비스를 재시작 합니다.

> sudo service jenkins restart

이후 다시 빌드를 수행해보면 정상적으로 빌드가 진행되는 것을 확인할 수 있습니다.

[MyApp] $ /bin/sh -xe /tmp/jenkins10435575314027477160.sh
+ docker build --tag my-app:latest --file Dockerfile .
Sending build context to Docker daemon 249.9MB
Step 1/5 : FROM mcr.microsoft.com/dotnet/aspnet:5.0
...

jenkins 서비스 재시작을 잊지 마세요.

Docker, Express, NGINX, AWS ELB를 복합적으로 사용해 고가용성을 위한 애플리케이션 환경을 구축해 봅니다.

로드 밸런싱이 무엇인가요?

로드 밸런싱은 들어오는 네트워크 트래픽을 서버 그룹에 분산하는 데 사용되는 기술 혹은 알고리즘입니다. 모든 공용 사용자에게 서버에서 호스팅 하는 서비스에 대한 단일 진입점을 제공합니다.

프로덕션 서버는 일반적으로 로드 밸런서 뒤에서 실행됩니다. 서버 전체에서 들어오는 부하를 "균등"하게 나워 서버 과부하를 방지할 수 있기 때문입니다.

또한 로드 밸런서는 트래픽을 라우팅 하는 서버에 보조 기능을 제공합니다. 로드 밸런서는 역방향 프락시 역할을 합니다. 역방향 프락시는 서버 그룹과 사용자 간의 중개자와 같습니다. 역방향 프락시가 처리하는 모든 요청은 요청 조건에 따라 적절한 서버로 전달됩니다. 이런 방식으로 역방향 프락시는 구성파일, 토큰, 암호와 같은 민감한 데이터가 저장되는 주 서버에 대한 액세스를 방지하면서 서버의 ID를 익명으로 유지합니다.

로드 밸런서로서의 NGINX와 AWS ELB

NGINX는 역방향 프락시의 역할도 할 수 있는 빠른 무료 오픈소스 로드 밸런서입니다.

반면에 ELB는 아마존 AWS에서 제공하는 로드 밸런싱 서비스입니다. ELB는 ALB, CLB, NLB의 세 가지 유형이 있습니다. 게이트웨이 로드 밸런서라고 하는 새로운 로드 밸런서도 AWS가 제공하는 클라우드 서비스 제품군에 추가되었습니다.

이 튜토리얼의 아이디어는 다중 포트에서 실행되는 고 가용성 Node.js 서버를 제공할 수 있는 계단식의 다중 로드 밸런서 구조를 만드는 것입니다.

* 참고사항

Docker 애플리케이션을 위해 AWS의 자체 ECS, ECR 환경을 활용하는 방법을 포함해 AWS에서 Node.js 애플리케이션을 위한 인프라를 구축하는 방법에는 여러 가지 방법이 있습니다. 하지만 이 자습서에서는 이에 초점을 맞추지 않고 EC2 인스턴스, 로드 밸런서의 메커니즘, 로드밸런싱, 프락시 포트를 통해 Docker와 상호작용 하는 방법을 더 잘 이해하는 것을 목표로 합니다.

아키텍처 개요

이것이 우리가 목표로 하는 아키텍처입니다. AWS와 NGINX에서 관리하는 다중 로드 밸런서는 node 앱을 위한 EC2 인스턴스에서 여러 포트를 관리하는데 도움이 됩니다. 이 아키텍처의 장점은 두 인스턴스가 AZ1과 AZ2의 서로 다른 가용 영역을 가진다는 것입니다. 이로 인해 한 영역이 다운되더라도 다른 영역은 계속 동작할 것이며 두 애플리케이션은 충돌하지 않게 됩니다.

Node.js 앱

단순하게 하기 위해 다음과 같은 표준 스타터 express node 앱을 사용합니다:

const express = require("express");
const app = express();
const PORT = process.env.PORT;
const SERVER_ID = process.env.SERVER_ID;

app.get("/", (req, res)=>{
  res.send({server: SERVER_ID, port: PORT});
});

app.listen(PORT, ()=>{
  console.log(`Server ${SERVER_ID} is running at ${PORT}.`);
});

 포트는 환경변수의 PORT를 사용해 express 앱에 제공됩니다. Docker를 통해 이 포트 값을 제공할 것입니다. docker-compose를 이용하면 간단한 작업입니다. 또 다른 환경 변수인 SERVER_ID가 있지만 데모용일 뿐이므로 걱정하지 마세요.

전체 설정이 준비되면 SERVER_ID는 로드 밸런서가 응답을 가져오는 서버를 알려주는 데 사용됩니다. 이를 통해 다중 로드 밸런서 / 역방향 프락시를 사용하는 인프라 구성이 올바른 방식으로 실행되고 있는지 확인하는데 도움이 됩니다.

이러한 유형의 구성은 프로덕션 파이프라인에서 일반적인 구성입니다. 일반적으로 이 경우 기본 앱 서버는 VPC에 배치됩니다. 

한 가지 알아둘 점은 레벨 1 로드 밸런서가 실제 클라이언트의 요청을 처리하기 때문에 공용으로 분류되는 반면 레벨 2 로드 밸런서는 소스 간의 요청을 라우팅 하는 역할을 하는 내부의 로드 밸런서라는 것입니다.

EC2 서버 실행하기.

AWS 계정에 로그인하고 EC2 대시보드로 이동합니다. 다음 단계에 따라 새 서버를 설정하고 Docker를 사용할 준비를 합니다.

1. 대시보드에서 인스턴스 시작을 클릭합니다.

2. 빠른 시작 섹션에서 Amazon Linux 2 AMI를 선택합니다.

3. 인스턴스 유형에서 t2.micro를 선택합니다. 이 대신 원하는 다른 유형을 선택할 수도 있습니다.

4. 이 데모에서 두 인스턴스를 서로 다른 가용 영역에서 동작하길 원하므로 두 인스턴스를 별도로 시작해야 합니다. 이 글에서 리전은 ap-northeast-2 이므로 서브넷은 ap-northeast-2a를 선택했습니다.

5. 사용자 데이터 섹션 아래에 이 스크립트 코드를 붙여 넣어 node.js Docker 앱을 실행하기 위한 필수 소프트웨어를 설치하게 합니다.

#!/bin/bash
sudo amazon-linux-extras install -y docker
sudo service docker start
sudo usermod -a -G docker ec2-user
sudo chkconfig docker on
sudo curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
sudo yum install -y gcc-c++ make
curl -sL https://rpm.nodesource.com/setup_14.x | sudo -E bash -
sudo yum install -y nodejs git

6. 스토리지 추가와 태그 추가 섹션은 기본값을 유지한 채 건너뜁니다.

7. 보안 그룹 우성의 경우 포트 22(SSH)와 80(HTTP)이 열려있는 새 보안 그룹을 생성합니다.

IP 범위의 경우 Anywhere  또는 MyIP*8을 선택할 수 있습니다. 테스트 용이므로 아무거나 선택해도 됩니다. 전 Anywhere인 0.0.0.0을 선택하였습니다.

8. 검토 및 시작 버튼을 클릭해 실행시킵니다.

9. 인스턴스에 SSH를 위한 새 키 페어를 생성합니다. 나중에 앱이나 내부 로드 밸런서에 대한 Docker 이미지를 빌드하는데 필요합니다.

이제 두 개의 인스턴스 중 첫 번째 인스턴스가 시작되었습니다. 동일한 단계를 거쳐 다음 인스턴스를 시작하고 서브넷 값을 앞서 생성한 값이 아닌 다른 값으로 변경하고 방금 생성한 SSH 키 페어를 사용해 두 번째 인스턴스를 생성합시다.

앱 컨테이너화와 NGINX 구성.

여기서는 앱을 위해 다음 저장소를 사용합니다: load_balanced_nodejs_app

이를 통해 프로세스 속도를 높일 수 있습니다. 저장소의 계층을 보자면 다음과 같습니다.

앱 폴더에는 Dockerfile과 함께 노드 서버 소스 코드가 포함되어 있습니다. nginx 폴더에는 업스트림 서버 포트 구성을 정의하는 구성 파일인 nginx.conf가 있으며 다음과 같습니다:

http{    
    upstream lb {        
        server 172.17.0.1:1000 weight=1;        
        server 172.17.0.1:2000 weight=1;        
        server 172.17.0.1:3000 weight=1;    
    }     
    server {        
        listen 80;        
        location / {            
            proxy_pass http://lb;        
        }    
    }
}

이 구성 파일은 메인 NGINX 서버가 포트 80번에서 동작한다고 지정하고 루트 위치 "/"은 lb라는 이 구성 파일에 정의된 업스트림으로 요청(프락시 패스)을 릴레이 합니다. lb는 서버 수를 지정하는 업스트림 객체이며 이 객체는 포함될 서버의 수와 이러한 서버가 내부적으로 실행될 포트를 지정합니다. 여기서 포함될 서버란 docker-compose를 통해 마운트 되는 서버이며 이는 이후 섹션에서 좀 더 자세히 다룹니다. 프락시는 80번 포트의 트래픽 부하를 분산시키게 됩니다. 

우리의 경우 업스트림 프락시는 트래픽을 1000번, 2000번, 3000번 포트로 보냅니다. 이 포트 번호는 docmer-compose YAML 파일에서 작성되는 env 변수로 익스프레스 서버 인스턴스에 전송되는 내부 PORT 값과 일치해야 합니다. 

각각의 시작되는 인스턴스에 대해 다음 작업을 수행해 줍니다.

1. 생성했던 키 페어를 이용해 인스턴스에 SSG로 연결합니다.

2. 다음 터미널 명령을 수행해 dockerfile로 앱 이미지를 빌드합니다.

git clone https://github.com/sowmenappd/load_balanced_nodejs_app.git
cd load_balanced_nodejs_app/app
docker build -t app .

3. 다음으로 NGINX 서버 이미지를 빌드합니다.

cd ../nginx
docker build -t nginx-s .

4. docker images 명령어를 실행 해 다음과 같은 내용이 표시되는지 확인합니다.

5. 두 번째 서버는 docker-compose.yml 파일을 수정해야 합니다. env 변수중 SERVER_ID는 모든 앱인 app1, app2, app3에 대해 2로 변경해야 합니다.

걱정하지 마세요 프로덕션 서버에서는 이런 일을 할 필요가 없습니다. 이는 데모 목적만을 위한 것입니다.

6. 마지막으로 다음 명령어를 실행합니다.

cd ..
docker-compose up -d

격리된 서버는 이제 백그라운드에서 세 개의 express 앱을 실행하게 됩니다. 이제 필요한 것은 AWS가 제공하는 로드 밸런서인 AWS ALB를 사용하여 이 시스템을 마운트 하는 것입니다.

AWS ALB에 시스템 마운트 하기.

이제 두 인스턴스 모두 마운트 할 준비가 되었습니다. 다음 단계를 따라 AWS에 애플리케이션 로드 밸런서를 설정하도록 합시다.

1. EC2 대시보드의 대상 그룹으로 이동해 대상 그룹을 만듭니다.

2. 대상 유형은 인스턴스를 선택 한 뒤 대상 그룹 이름을 작성하고 다음을 클릭하세요.

3. 실행 중인 두 인스턴스를 선택하고 선택한 인스턴스를 위한 포트를 80으로 설정한 뒤 아래에 보류 중인 것으로 포함 버튼을 클릭합니다.

4. 보류 중인 항목에 추가된 인스턴스를 확인한 뒤 대상 그룹을 생성합니다.

5. 이제 로드 밸런서로 이동해 로드 밸런서 생성 버튼을 클릭한 뒤 Application Load Balancer 생성을 클릭합니다.

6. 앞서 인스턴스를 생성할 때 선택한 가용 영역을 고른 뒤 계속합니다.

7. 보안 그룹 구성으로 이동해 모든 IP에 대해 80번 포트가 열려있는 새 보안 그룹을 만들고 다음을 클릭합니다.

8. 라우팅 구성에서 앞서 기존 대상 그룹을 고른 뒤 앞서 생성한 대상 그룹을 선택합니다.

9. 설정을 검토 한 뒤 로드 밸런서를 생성합니다. 로드 밸런서는 생성 후 상태 확인을 실행 한 뒤 몇 분 내로 실행되어야 합니다.

이제 EC2 대시보드의 로드 밸런서에서 방금 생성한 로드 밸런서의 DNS이름을 복사합니다. 

이 DNS 주소를 브라우저에 붙여 넣고 엔터를 누르세요. 브라우저를 새로 고칠 때마다 SERVER_ID와 PORT가 다른 값을 전송하는 것을 볼 수 있습니다.

이는 기본적으로 NGINX와 AWS 로드 밸런서가 로드 밸런싱을 위해 기본적으로 라운드 로빈 알고리즘을 사용하기 때문입니다.

맺는 글.

이렇게 배포된 시스템은 다중 로드 밸런서의 구성을 통해 높은 가용성을 보장하고 오랜 기간 동작하는 동안 많은 양의 트래픽을 견딜 수 있게 되었습니다. 이 자습서를 뒤이어 소스 제어와 통합 배포 파이프라인을 관리하고 GitHub 저장소에 커밋할 때 변경사항을 서버에 배포하는 방법을 보여주는 또 다른 기사를 게시할 예정입니다.

해당 글은 다음 글을 참고해 번역한 글입니다: Build a highly available Node.js application using Docker, NGINX and AWS ELB

Jenkins를 이용해 docker 이미지를 빌드하는 방법에 대해 알아봅니다.

0. Jenkins 및 docker 설치.

들어가기 앞서 jenkins와 docker를 미리 준비합니다.

• 2019.05.23 - [Programming/Linux] - [Ubuntu] Docker 설치하기
• 2020.01.17 - [Programming/Linux] - [Ubuntu] CI/CD를 위한 Jenkins 설치

1. Github 저장소 생성

가장 먼저 jenkins에서 빌드할 Github 저장소를 생성해 줍니다. 저장소에는 도커 이미지로 빌드할 때 사용될 dockerfile이 포함되어야 합니다.

Github 저장소는 다음을 참고해 주시기 바랍니다: JenkinsDockerPipeline

dockerfile은 설명할 내용이 없으며 Jenkinsfile은 뒤에서 설명하도록 하겠습니다.

2. 빌드 환경 구성.

Jenkins에서 Docker 이미지를 빌드하기 위해선 별도의 플러그인이 필요합니다. Jenkins 플러그인 설치 페이지로 이동 후 "Docker Pipeline" 플러그인을 설치합니다.

다음으론 Docker Registry의 인증 정보를 등록해 줄 차례입니다. Global Credential 페이지로 이동 후 Add Credentials를 클릭해 인증 정보를 등록합니다.

전 이전에 생성한 Harbor의 인증정보를 입력했습니다.

다음은 git을 이용하기 위한 설정입니다. 먼저 Jenkins가 설치된 서버에 git이 없다면 설치합니다.

$ sudo apt-get install git

그 후 git exe 경로를 확인합니다.

$ gut --exec-path

Jenkins의 Global tool configuration 페이지로 이동해 Git 항목을 확인한 경로로 수정해 줍니다.

다음은 도커 사용 권한입니다. 기본적으로 Jenkins에서 바로 docker.sock를 사용할 순 없습니다. 다음 명령어로 권한을 부여해 주세요.

$ sudo chmod 666 /var/run/docker.sock

3. Jenkins 아이템 생성

이제 Jenkins Pipeline을 사용해 실제 빌드를 진행해 보도록 하겠습니다. "새로운 Item"을 클릭해 "Pipeline"을 선택하고 새로운 아이템을 만듭니다.

저장소를 확인해 보셨다면 내부에 ${env.BUILD_NUMBER}를 확인할 수 있습니다. 이 값을 태그로 이용할 것이며 해당 값은 빌드할 때 함께 넘겨줍니다. 이를 위해 매개변수를 정의합니다.

다음은 파이프 라인 관련 설정입니다. 파이프라인 설정은 다음과 같이 설정하시면 됩니다.

"Pipeline script from SCM"을 선택한 뒤 SCM은 git을 고르고 리포지토리 주소를 입력하면 됩니다. 해당 리포지토리 내의 "Jenkinsfile"을 파이프라인 스크립트로 사용하겠다는 의미를 가집니다.

"Build with parameter"를 클릭해 BUILD_NUMBER를 입력한 뒤 빌드하면 파이프라인을 통해 빌드되는 것을 확인할 수 있습니다.

이제 Jenkinsfile을 확인해 봅시다.

node {
  stage('========== Clone repository ==========') {
    checkout scm
  }
  stage('========== Build image ==========') {
    app = docker.build("jenkins-docker-pipeline/my-image")
  }
  stage('========== Push image ==========') {
    docker.withRegistry('YOUR_REGISTRY', 'YOUR_CREDENTIAL') {
      app.push("${env.BUILD_NUMBER}")
      app.push("latest")
    }
  }
}

업로드된 Jenkinsfile은 Scripted pipeline을 위한 스크립트입니다. 다른 방식으로 Declarative pipeline을 위한 방식도 있으나 이 글에선 설명하지 않도록 하겠습니다.

파이프라인은 세 스테이지로 동작합니다.

1. SCM에서 소스코드를 체크아웃받습니다.

2. dockerfile을 이용해 "jenkins-docker-pipeline/my-image"라는 이름으로 이미지를 빌드합니다. 

   Jenkinsfile에서 push 할 때 이미지 태그를 설정하므로 여기선 이미지 이름만 설정합니다.

3. DockerRegistry에 Credential을 이용해 이미지를 push 합니다. 

   여기서 앞서 정의한 BUILD_NUMBER가 사용되며 자동으로 latest 태그의 이미지도 함께 push 됩니다.

예를 들어 BUILD_NUMBER에 0.0.1을 입력하고 빌드하면 jenkins-docker-pipeline/my-image:0.0.1과 jenkins-docker-pipeline/my-image:latest가 push 됩니다.

중앙 로그 수집을 위해 Eleastcsearch, Fluentd, Kibana를 이용해 EFK 스택을 구축해보도록 합니다.

1. 앞선 글

중앙 로그 수집을 위해 로그 수집기를 알아봤습니다: 2020.10.28 - [Programming] - LogStash vs Fluentd - 어떤 것을 선택해야 할까

Fluentd를 사용해보고자 했지만 미뤄졌던 일이 이제야 사용해 볼만한 기회가 찾아와 좀 더 자세히 포스팅하기로 했습니다.

EFK 스택은 기존 ELK 스택의 변형입니다. 기존 로그 수집 미들웨어인 Logstash 대신 Fluentd를 사용한 스택입니다. Elasticsearch, Logstash, Fluentd, Kibana에 대한 설명은 이 글에서 다루지 않도록 하겠습니다.

이 글의 예시는 Visual Studio의 dotNet5.0을 이용해 예시 프로젝트를 만들고 그 프로젝트의 로그를 fluentd를 통해 elasticsearch로 보낸 뒤 kibana에서 확인하는 과정으로 진행하도록 하겠습니다.

해당 내용은 다음 git 저장소에서 확인할 수 있습니다: FluentdTester

2. 테스트용 프로젝트 생성.

VisualStuio를 열고 dotNet 5.0을 사용해 WebAPI 프로젝트를 생성합니다. 프로젝트는 HTTPS를 지원하지 않도록 설정하였으며 Docker 지원은 체크해 생성합니다.

로그를 남기기 위해 Serilog를 사용하도록 합니다. NuGet 패키지 관리자를 열어 Serilog, Serilog.Sinks.File, Serilog.Formatting.Elasticsearch 패키지를 설치합니다.

Serilog는 로그를 남기기 위함이며 Serilog.Sink.File은 로그를 파일에 쓰기 위함이고 Serilog.Formatting.Elasticsearch는 로그 형식을 Elasticseach에 맞게 남겨주는 데 사용합니다.

새 컨트롤러를 생성해 Get요청이 오면 로그를 남기도록 코드를 작성합니다.

using Microsoft.AspNetCore.Mvc;
using Serilog;
using Serilog.Core;
using Serilog.Formatting.Elasticsearch;

namespace FluentdTester
{
    [Route("api/[controller]")]
    [ApiController]
    public class LogController : ControllerBase
    {
        private readonly Logger logger;
        public LogController()
        {
            logger = new LoggerConfiguration()
                .MinimumLevel.Debug()
                .Enrich.FromLogContext()
                .Enrich.WithProperty("Service", "LogTester")
                .WriteTo.File(new ElasticsearchJsonFormatter(), "logs/fluentd-test.log", rollingInterval: RollingInterval.Day)
                .CreateLogger();
        }
        // GET: api/log/test
        [HttpGet("test")]
        public IActionResult Get()
        {
            logger.Debug(string.Format("This is sample log."));
            return Ok();
        }
    }
}

다음은 편의를 위한 코드 수정입니다. Production 환경에서도 swagger에 접속할 수 있도록  Startup.cs 파일을 수정합니다.

// Startup.cs
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseDeveloperExceptionPage();
    app.UseSwagger();
    app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "FluentdLogTester v1"));
    app.UseHttpsRedirection();
    app.UseRouting();
    app.UseAuthorization();
    app.UseEndpoints(endpoints => { endpoints.MapControllers(); });
}

이제 도커 이미지로 빌드해 봅시다. 자동으로 생성된 Dockerfile을 우클릭 해 Docker 이미지 빌드를 클릭합니다.

정상적으로 빌드되는지 확인합니다. 해당 방식으로 이미지를 빌드하면 자동으로 latest 태그가 설정되어 빌드가 됩니다.

3. fluentd 추가하기.

앞서 작성한 프로그램이 로그를 남기면 fluentd는 그 로그파일을 읽어 Elasticsearch로 로그를 전송하는 역할을 담당하게 될 겁니다. 이렇게 로그 파일을 추적해 로그를 전송하는 방식은 fluentd의 "tail" Input Plugin을 사용합니다. 자세한 내용은 공식 홈페이지를 참고해 주시기 바랍니다: Fluentd - tail

로그를 읽어 들이는 Input Plugin이 있으면 반대로 읽은 로그를 Elasticsearch로 전송하는 기능도 있습니다. 다행히도 별도의 구현을 할 필요 없이 바로 Elasticsearch로 로그를 보낼 수 있도록 Elasticsearch Output Plugin을 제공해주고 있습니다. 자세한 내용은 공식 홈페이지를 참고해 주시기 바랍니다: Fluentd - elasticsearch

이제 tail과 elasticsearch를 사용할 수 있도록 fluentd의 설정 파일을 작성하도록 하겠습니다.

#/fluentd/conf/fluent.conf
<source>
  @type tail
  path /app/logs/fluentd-tester/*.log
  pos_file /app/logs/td-agent/logtest.log.pos
  tag logtest
  <parse>
    @type json
  </parse>
</source>
<match *.**>
  @type copy
  <store>
    @type elasticsearch
    host elasticsearch
    port 9200
    logstash_format true
    logstash_prefix fluentd
    logstash_dateformat %Y%m%d
    include_tag_key true
    type_name access_log
    tag_key @log_name
    flush_interval 1s
  </store>
  <store>
    @type stdout
  </store>
</match>

앞서 작성한 프로그램의 로그를 읽어 elasticsearch로 전송하는 설정 파일입니다. 다음으로는 이 설정 파일과 elasticsearch 플러그인을 사용할 수 있도록 fluentd 이미지를 빌드하는 dockerfile을 작성합니다.

# /fluentd/dockerfile
FROM fluentd:v1.9.1-debian-1.0
COPY /conf/* /fluentd/etc/
USER root
RUN ["gem", "install", "fluent-plugin-elasticsearch", "--no-document", "--version", "4.3.3"]
USER fluent

이제 이 dockerfile을 사용해 fluentd 이미지를 빌드해 줍니다.

$ docker build . -t my-fluentd:0.0.1

** 여기서는 conf 파일을 포함하는 이미지를 미리 빌드해서 사용합니다. 

** 만약 docker-compose에서 새로 빌드하고자 한다면 dockerfile의 "COPY /conf/* /etc/"를 사용할 수 없으므로 별도로 conf 파일을 옮겨주는 작업이 필요합니다. 

4. 배포를 위한 docker-compose 작성.

이 글은 간단한 테스트를 위한 글이므로 테스트 프로그램, fluentd, Elasticsearch, Kibana 모두 한 docker-compose 파일 내에 작성해 배포하도록 진행하겠습니다.

version: '3.9'

volumes:
  test-logs:

services:
  fluentd-tester:
    image:  fluentdtester:latest
    volumes:
        - test-logs:/app/logs
    depends_on:
        - "fluentd"
    expose:
        - "8080"
    ports:
        - "8080:80"

  fluentd:
    image: my-fluentd:0.0.1
    user: root
    volumes:
      - test-logs:/app/logs/fluentd-tester
    depends_on:
      - "elasticsearch"
    ports:
      - "24224:24224"
      - "24224:24224/udp"

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2
    environment:
      - "discovery.type=single-node"
    expose:
      - "9200"
    ports:
      - "9200:9200"

  kibana:
    image: kibana:7.10.1
    depends_on:
      - "elasticsearch"
    ports:
      - "5601:5601"

내용은 간단합니다. 앞서 빌드한 이미지인 fluentdtester:latest와 my-fluentd:0.0.1 그리고 elasticsearch와 kibana를 실행시킵니다. fluentd-tester와 fluentd 서비스는 test-logs라는 이름의 볼륨을 이용해 데이터를 공유하도록 해주었습니다.

이를 통해 fluentd-service에서 작성한 로그파일에 fluentd가 접근해 tail로 로그파일을 elasticsearch로 전송합니다.

다음 명령어를 통해 docker-compose를 실행시켜봅시다.

$ docker-copmpose up -d

정상적으로 컨테이너들이 실행된 것을 확인할 수 있습니다.

5. 동작 확인.

컨테이너가 정상적으로 실행되었다면 이제 테스트 로그를 남겨봅시다. 다음 주소로 이동해 swagger를 사용해 로그를 남깁시다.

http://localhost:8080/swagger/index.html

정상적으로 로그가 남았음을 확인하고 싶다면 컨테이너에 접속해 /app/logs 폴더에 들어가 확인해보시면 됩니다.

이제 키바나에 접속해 인덱스 패턴을 생성해야 합니다. 다음 주소로 접속해 인덱스 패턴을 생성합니다.

http://localhost:5601/app/management/kibana/indexPatterns

Create index 화면에서 "fluentd-*" 패턴을 생성해줍니다.

Time Field는 @timestamp를 선택합니다.

이제 discover로 이동합니다.

http://localhost:5601/app/discover/

앞서 남긴 로그를 확인할 수 있습니다.

docker-compose를 이용해 간단히 MongoDB ReplicaSet을 구성하는 방법에 대해 알아보도록 합니다.

참고 소스는 다음 git 저장소에서 확인할 수 있습니다: MongoDBReplicaSetTest

0. Docker Desktop 설치

Docker Container로 배포를 위해선 개발 환경에 docker가 설치되어 있어야 합니다. 공식 홈페이지로 이동해 Docker Desktop을 설치합니다: www.docker.com/products/docker-desktop

1. Replica set 구성을 위한 js 파일 작성.

MongoDB에서 ReplicaSet을 설정하기 위한 js 파일을 작성합니다.

// init/
config = {
  _id : "replication",
  members: [
    {_id:0,host : "mongo1:27017"},
    {_id:1,host : "mongo2:27017"},
    {_id:2,host : "mongo3:27017"},
  ]
}
rs.initiate(config);
rs.conf();

members를 보면 알 수 있듯이 mongo1, mongo2, mongo3의 세 개의 MongoDB를 사용할 예정입니다. 이번 예시에서는 mongo1 서버에서 해당 스크립트를 수행하도록 진행할 것입니다.

2. 쉘 스크립트 작성.

MongoDB 컨테이너가 올라오면 앞서 작성한 스크립트 파일을 수행 해 Replica set을 구성하도록 하는 쉘 스크립트를 작성합니다.

#init/setup.sh
sleep 5 | echo "Waiting for the servers to start..."
mongo mongodb://localhost:27017 /usr/src/configs/init/setReplication.js

3. dockerfile 작성

앞서 스크립트를 작성하면서 설명했듯이 mongo1 컨테이너에서는 우리가 작성한 스크립트가 실행되어야 합니다. 이를 위해 MongoDB 이미지를 가져와 컨테이너 실행 시 우리의 코드가 실행되는 새로운 이미지를 만들어 보도록 하겠습니다.

# dockerfile

FROM mongo

WORKDIR /usr/src
RUN mkdir configs
WORKDIR /usr/src/configs

COPY init/* init/

RUN chmod +x init/setup.sh

CMD ["/usr/src/configs/init/setup.sh"]

수행하는 내용은 간단합니다. mongo 이미지를 가져와 /usr/src/config 폴더를 만들고 그 안에 init 폴더를 그대로 복사합니다. 그리고 앞서 작성한 setup.sh 파일에 권한을 부여한 후 setup.sh를 실행시키는 게 전부입니다. 

4. docker-compose.yml 작성

이제 거의 다 끝나갑니다. 마지막으로 여러 mongodb 컨테이너를 동시에 실행시키고 ReplicaSet을 구성하기 위한 docker-compose.yml 파일을 작성합시다.

version: '3'
services:
  mongo1:
    image: mongo-rep:0.0.1
    build:
      context: .
      dockerfile: dockerfile
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo1:/data/db
    ports:
      - "27021:27017"
    networks:
      - mongo-networks
    command: mongod --replSet replication

  mongo2:
    image: "mongo"
    ports:
      - "27022:27017"
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo2:/data/db
    networks:
      - mongo-networks
    command: mongod --replSet replication
    depends_on:
      - mongo1

  mongo3:
    image: "mongo"
    ports:
      - "27023:27017"
    volumes:
      - {SOMEWHERE_YOUR_VOLUME}/mongoRepl/mongo3:/data/db
    networks:
      - mongo-networks
    command: mongod --replSet replication
    depends_on:
      - mongo2

networks:
  mongo-networks:
    driver: bridge

mongo2와 mongo3은 mongo 이미지를 그대로 가져와 사용합니다. 볼륨은 각각 자신이 설정한 볼륨 경로 내의 "mongoRepl/mongo2"와 "mongoRepl/mongo3"에 컨테이너 내부의 mongodb 데이터가 저장됩니다.

세 컨테이너는 depends_on으로 연결되어 있으며 bridge 네트워크를 사용해 서로 서비스 이름을 통해 통신할 수 있습니다. 추가적으로 mongo2와 mongo3은 replSet 명령어로 "replication"이라는 이름으로 ReplicaSet을 생성합니다. 이 이름은 앞서 작성한 js의 _id에 입력한 값과 동일해야 합니다.

mongo1은 다른 두 서비스와 달리 mongo 이미지를 그대로 사용하지 않고 앞서 작성한 dockerfile을 이용해 새로운 이미지를 빌드합니다. 이 서비스가 실행되면 다른 두 mongodb 서비스와 같이 ReplicaSet을 구성하게 됩니다.

이제 다음 명령어를 통해 docker-compose를 실행시켜 봅시다

$ docker-compose up -d

이제 ReplicaSet이 정상적으로 동작하는지 확인하기 위해 컨테이너에 접속해 봅시다. 먼저 컨테이너의 ID를 확인합니다.

$ docker ps -a

컨테이너 ID를 확인 후 아무 데나 접속해 봅니다.

$ docker exec -u 0 -it 51 mongo

위와 같이 "replication:PRIMARY" 혹은 "replication:SECONDARY"라고 표시되면 정상적으로 ReplicaSet이 구성된 겁니다.

.Net 5.0을 사용해 React 프로젝트에서 Docker Container를 사용해 프로젝트를 배포하는 방법에 대해 알아봅니다.

0. Docker Desktop 설치.

Docker Container로 배포를 위해선 개발 환경에 docker가 설치되어 있어야 합니다. 공식 홈페이지로 이동해 Docker Desktop을 설치합니다: www.docker.com/products/docker-desktop

1. 프로젝트 생성

Visual studio를 켜고 React.js 프로젝트를 생성합니다.

프로젝트 이름은 적당히 짓고 대상 프레임워크는 .Net 5.0을 선택합니다.

* IDE는 Visual studio 2019 CE를 사용하였습니다.

2. Docker 지원 추가.

Visual studio 2019의 다른 여러가지 Web 프로젝트는 대부분 기본적으로 Docker Container 배포를 지원합니다. 하지만 안타깝게도 포스팅을 올리는 현재 Visual studio 2019에서 React.js 프로젝트는 Docker Container 배포를 기본적으론 지원하지 않습니다. 앞서 프로젝트를 만들 때 docker 지원을 보지 못하셨을 겁니다.

React.js 프로젝트에 수동으로 docker 지원을 추가해 봅시다. 먼저 프로젝트를 우클릭한 뒤 추가 -> Docker 지원을 클릭합니다.

대부분의 경우는 Linux container일겁니다. 자신이 원하는 대상 OS를 선택합니다.

이제 IDE가 자동으로 "Dockerfile"을 생성해 .Net5.0에 맞는 dockerfile을 작성해 줍니다. "Dockerfile"을 우클릭 해 "Docker 이미지 빌드"를 클릭해 도커 이미지를 생성해 봅시다.

빌드가 잘 되시나요? 아마 다음과 같은 오류와 함께 빌드가 실패했을 것입니다.

이제 빌드 출력창을 한번 뒤져봅시다. 아마 다음과 같은 에러 메시지를 마주 할 수 있을 겁니다.

1>#16 2.809 /bin/sh: 2: /tmp/tmp1d7d426dff82428db5f0845ee787658f.exec.cmd: npm: not found
1>#16 2.814 /src/DockerDeployExample/DockerDeployExample.csproj(37,5): error MSB3073: The command "npm install" exited with code 127.
1>#16 ERROR: executor failed running [/bin/sh -c dotnet publish "DockerDeployExample.csproj" -c Release -o /app/publish]: exit code: 1

누가 봐도 어디서 문제가 생긴건지 찾으실 수 있을 겁니다 npm: not found 우리 이미지엔 npm이 없었습니다.

3. .Net5.0 이미지에 nodejs 추가하기.

사실 MSDN을 애용하는 개발자라면 이런 문제를 마주치지 않을 수도 있었을 겁니다. MSDN의 다음 글을 확인해 주세요: Quickstart: Use Docker with a React Single-page App in Visual Studio

리눅스 컨테이너 항목을 보면 수동으로 nodejs를 설치해야 하는 것을 알 수 있습니다. 이제 우리 "Dockerfile"에 다음과 같은 명령어를 추가해 주도록 합니다.

RUN curl -sL https://deb.nodesource.com/setup_15.x | bash -
RUN apt-get install -y nodejs

* 현재 포스팅 일자 기준으로 nodejs의 최신 버전은 15.x 버전이며 LTS는 14.x 버전입니다.

MSDN페이지에선 base와 build 모두에 설치했지만 .Net5.0에선 base 이미지에 nodejs를 설치하면 에러가 발생하며 build 이미지에만 nodejs를 설치해 줘도 정상적으로 빌드가 됩니다.

수정한 Dockerfile은 다음과 같습니다.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
RUN curl -sL https://deb.nodesource.com/setup_15.x | bash -
RUN apt-get install -y nodejs
WORKDIR /src
COPY ["DockerDeployExample/DockerDeployExample.csproj", "DockerDeployExample/"]
RUN dotnet restore "DockerDeployExample/DockerDeployExample.csproj"
COPY . .
WORKDIR "/src/DockerDeployExample"
RUN dotnet build "DockerDeployExample.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "DockerDeployExample.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DockerDeployExample.dll"]

이제 다시 "Dockerfile"을 우클릭 해 "Docker 이미지 빌드"를 클릭해 도커 이미지를 생성해보면 정상적으로 이미지가 생성되는 것을 확인할 수 있습니다.

4. Docker image push

이제 빌드한 이미지를 "게시" 기능을 이용해 Docker Registry에 Push까지 해봅시다. Docker Registry는 DockerHub를 사용하거나 PrivateRegistry를 구축해 사용하시면 됩니다.

• 2020.02.26 - [Programming/Linux] - [Docker] Harbor를 이용한 Private Registry 구축
• 2020.06.04 - [Programming/Linux] - [Docker] Harbor 2.0 업그레이드

프로젝트를 우클릭 해 "게시"를 클릭합니다.

게시 대상을 선택합니다. "Docker 컨테이너 레지스트리"를 선택합니다.

원하는 컨테이너 레지스트리를 선택합니다. 저는 이전에 구축한 Harbor에 게시해 보도록 하겠습니다.

자격증명과 레지스트리 경로를 입력합니다.

"호스팅" 항목의 "..."을 클릭하면 "이미지 태그 편집"을 사용할 수 있습니다. 기본값은 latest인데 이 값을 0.0.1로 바꿔 게시해 보도록 하겠습니다.

잠시 기다리면 게시가 완료되었다는 메시지를 확인할 수 있습니다.

실제로 Harbor에 접속해보면 이미지가 정상적으로 push 되었음을 확인할 수 있습니다.

Harbor에 이미지를 push 할 때 Unauthorized 에러가 발생하는 원인과 해결 방법에 대해 알아봅니다.

1. 현상

Harbor에 이미지를 push 하면 preparing과 waiting메시지가 보이다가 unauthorized에러가 발생하며 push가 취소됩니다.

2. 로그인 문제

해당 에러가 발생하면 가장 먼저 체크해봐야 할게 Private registry로의 로그인입니다. 다음 명령어로 다시 로그인을 시도해 봅시다.

> docker logout
> docker login your.host.com:port -u username -p password

그리고 다시 push를 해봅니다. 사실 이 방법으로 해결되면 이 글을 읽고 있지 않을 겁니다. 다른 원인에 대해 생각해 봅시다.

3. Nginx 문제

제 경우에 해당하는 원인이었습니다. 전 Harbor를 Private registy로 사용하고 있으며 해당 서버에 Nginx를 이용해 proxy_pass를 설정해 둔 상태입니다. 

또한 push명령을 직접 치기 귀찮아서 Harbor의 Repository에서 알려주는 Push Command를 복사해서 사용했습니다. 문제는 여기서 발생했습니다.

예를 들어 Harbor의 HTTPS 기본 포트를 변경해 사용하고 있다고 가정합시다. 443에서 1443으로 변경한 뒤 prepare를 통해 harbor.yml을 생성하게 되면 docker-compose.yml은 자동적으로 포트를 1443:8443으로 설정하게 됩니다. 또한 이런 식으로 설치된 Harbor는 Push command에 default port가 변경되었으므로 자동으로 1443 포트를 추가하게 됩니다. 

docker push your.host.com:1443/repo-name/image:tag

위와 같이 된다는 뜻입니다. 하지만 우리는 nginx를 통해 HTTPS연결을 잡아둔 상태이므로 1443 포트가 포함된 명령어를 그대로 사용할 수 없습니다. 

docker push your.host.com/repo-name/image:tag

위처럼 포트를 지우고 명령을 내리면 push작업이 진행되는 걸 확인할 수 있습니다.

만약 위와 같이 수정 후에 push명령중 413에러가 발생한다면 다음 글을 참고해 주시기 바랍니다:

2020/12/04 - [Programming/Linux] - [Nginx] 413 Request Entity Too Large

앞선 글에서 Express를 이용해 클러스터를 구성해 여러 워커를 가진 서버를 띄워보았습니다. 이번에는 제작한 웹 서버를 이용해 이중화 구성을 한 뒤 nginx를 이용해 로드밸런서를 만들어 그럴듯한 운영 환경을 구성해 보도록 하겠습니다.

0. 사전 준비.

이 글에서는 앞선 글에서 작성한 웹 서버를 사용합니다. 이전 글을 참고해 웹 서버를 준비해 주세요.

Nginx를 사용할 예정이니 미리 서버를 다운로드하여 주셔도 좋습니다. 단, Docker를 이용하실 분은 별도의 Nginx를 준비하지 않으셔도 됩니다.

모든 결과물을 한번에 배포하기 위해 docker-compose를 사용할 예정입니다. docker-compose를 준비해 주세요.

• 2020/06/18 - [JavaScript] - Express를 이용한 서버 클러스터 구성.
• 2020/01/14 - [Linux] - [Ubuntu] Docker-compose 설치하기

1. Nginx를 이용한 이중화 구성.

이제 우리가 만든 서버는 여러 개의 워커를 갖고 도커 위에서 동작합니다. 이제 안정성을 위해 두 개의 서버를 올려두고 그 앞에 Nginx를 둬서 로드밸런서의 역할을 하도록 합시다.

우리가 할 일은 단지 nginx의 config파일을 추가하는것 뿐 입니다. 아무런 추가 작업을 진행하지 않은 채 설정 파일을 추가해 주는 것만으로도 로드밸런서를 구성할 수 있습니다.

새로운 폴더인 my-nginx를 생성하고 그 안에 nginx 폴더를 만들어줍니다. 그리고 그 안에 nginx.conf 파일을 작성합니다.

#./nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

사실 위의 설정파일은 nginx를 설치하면 가장 기본으로 들어가 있는 값입니다. 스킵하셔도 무방합니다만 나중에 수정된 값을 사용할 수 있으므로 넣어주었습니다.

설정 파일을 살펴봅시다. nginx.conf의 맨 아래 include를 보세요. 이 include가 의미하는 바는 /etc/nginx/conf.d폴더 내의 모든 conf파일을 가져와 http 아래에 두겠다는 뜻입니다.

따라서 우리가 다음에 작성할 설정 파일이 바로 아래 추가될 것이란 의미가 됩니다. 이 외에도 nginx의 default 페이지가 담긴 default.conf도 추가될 것입니다. 

그다음으로nginx 안에 conf.d 폴더를 생성 한 뒤 my-react-lb.conf파일을 작성합니다.

# ./nginx/conf.d/my-react-lb.conf

upstream my-react {
    #least_conn;
    #ip_hash;
    server localhost:3000 weight=10 max_fails=3 fail_timeout=10s;
    server localhost:3001 weight=10 max_fails=3 fail_timeout=10s;
}    
server {
    listen                8080;
    server_name  localhost;
    location / {
        proxy_pass http://my-react;
    }
}

이 파일의 폴더 경로도 실제 리눅스 시스템에서 nginx가 위치하는 폴더의 경로를 맞추기 위함이므로 임의의 폴더에 작성하셔도 됩니다.

server항목을 먼저 봅시다. 이 서버는 8080 포트에서 동작하고 리버스 프록시로 동직 합니다. 즉, localhost:8080으로 들어오면 내부적으로 my-react로 연결시킨다는 뜻입니다. 이때 연결하는 my-react가 위에서 정의한 upstream입니다.

upstream 내부에 두 개의 서버가 정의되어 있습니다. 유저가 들어올 때마다 번갈아 가면서 3000, 3001 포트에 올라간 서버가 접속을 수용할 겁니다. 정리하자면 localhost:8080으로 접속하게 되면 내부적으로 로드밸런싱을 거쳐 localhost:3000, locahost:3001로 이동하게 된다는 겁니다.

주석 처리한 least_conn은 번갈아 가면서 수용하는 게 아닌 현재 접속이 가장 적은 곳에 우선 접속할 수 있도록 하는 기능이며 ip_hash는 접속한 사용자의 ip를 해싱해서 같은 사용자는 같은 서버로 접속할 수 있게 해 세션 문제 등을 해결할 수 있도록 하는 기능입니다.

따라서 메인 서버에 위의 설정 파일을 갖는 nginx를 설치한 뒤 Docker로 3000, 3001 포트에 앞서 작성한 웹 서버를 두대 올려 둔 후 localhost:8080으로 접속하면 정상적으로 로드밸런싱이 동작할 겁니다. 

2. Docker compose를 이용해 한번에 배포하기.

사실 위와 같이 배포하기 위해서는 서버에 nginx를 직접 설치해야 하며 그 서버에서 Docker가 동작 해 웹서버가 돌아야 합니다. 즉, nginx가 돌아가는 localhost에 웹서버가 동작해야 한다는 뜻입니다.

서버에 접속해 nginx를 설치하고 conf 파일을 수정해준 뒤 그 서버에 docker를 설치하고 docker 명령어로 두 개의 웹서버를 실행시키는 과정이 필요하게 됩니다. 이것만 해도 귀찮아지기 시작합니다. 게다가 수작업이 들어가는 만큼 오류의 가능성도 높아집니다.

이제 좀 더 편하게 위 과정을 다음과 같이 변경할 겁니다.

1. Nginx를 직접 설치하지 않고 Docker Image로 빌드 해 Docker 명령어로 배포한다
2. 명령어를 미리 작성해 둬 한번에 여러 이미지를 배포한다.

그러기 위해선 docker-compose와 nginx를 docker image로 빌드하는 작업이 필요합니다. 우선 nginx를 docker image로 빌드하기 위해 Dockerfile을 작성합니다.

# ./Dockerfile

FROM nginx:stable

COPY ./nginx/nginx.conf /etc/nginx/nginx.conf
COPY ./nginx/conf.d/my-react-lb.conf /etc/nginx/conf.d/my-react-lb.conf

CMD ["nginx", "-g", "daemon off;"]

매우 간단합니다. nginx 안정화 버전을 받아 우리가 작성한 conf파일을 복사 한 뒤 실행합니다. 이제 다음 명령어로 docker image를 빌드합니다.

$ docker build . -t my-nginx:0.0.1

그리고 빌드한 이미지를 실행해 봅시다. 

$ docker run -itd -p 3000:3000 my-react:0.0.1

$ docker run -itd -p 3001:3000 my-react:0.0.1

$ docker run -itd -p 8080:8080 my-nginx:0.0.1

localhost:8080으로 이동하면 어떻게 될까요?

에러가 보이는 이유에 대해 생각해 봅시다. 우리는 nginx를 도커로 돌렸으며 my-react-lb.conf의 upstream에 server로 localhost:3000와 localhost:3001을 등록했습니다. 과연 nginx 컨테이너 내에서 이 두 서버에 접속할 수 있을까요?

궁금하신 분은 다음 명령어로 한번 테스트해보시기 바랍니다.

$ docker exec -u 0 -it (my-nginx 컨테이너 ID) bash

$ apt-get update

$ apt-get intall telnet

$ telnet localhost 3000

당연히 독립된 네트워크 이므로 접속을 할 수 없습니다.

그러므로 우리는 Docker compose를 이용해야 합니다. Docker compose는 같이 배포되는 컨테이너끼리 미리 정의된 이름으로 접속이 가능합니다. 마치 도메인 네임처럼 말입니다.

최상위 폴더로 이동해 docker-compose.yml 파일을 생성합니다 저 같은 경우엔 my-react와 my-nginx를 포함하고 있는 폴더에 작성하였습니다.

그리고 docker-compose.yml을 다음과 같이 작성해 줍니다.

# docker-compose.yml

version: "3"
services:
    my-react-A:
        image: my-react:0.0.1
        ports:
            - "3000:3000"
    my-react-B:
        image: my-react:0.0.1
        ports:
            - "3001:3000"
    nginx:
        image: my-nginx:0.0.1
        ports:
            - "8080:8080"

여기서 서비스 항목을 봅시다. 우리는 my-react-A, my-react-B, nginx 이렇게 총 세 개의 컨테이너를 생성하도록 작성하였습니다. 당연히 이름은 변경해도 됩니다. 서비스 내의 image는 도커 이미지를 의미합니다. ports는 docker run의 -p 옵션과 동일합니다. 

이런 식으로 docker-compose를 구성하게 되면 위의 세 컨테이너 간에는 서비스에 작성한 이름으로 서로 접근이 가능해집니다. 따라서 우리의 my-react-lb.conf가 바뀌어야 함을 의미하죠.

# ./nginx/conf.d/my-react-lb.conf

upstream my-react {
    #least_conn;
    #ip_hash;
    server my-react-A:3000 weight=10 max_fails=3 fail_timeout=10s;
    server my-react-B:3000 weight=10 max_fails=3 fail_timeout=10s;
}    
server {
    listen                8080;
    server_name  localhost;
    location / {
        proxy_pass http://my-react;
    }
}

그리고 다시 도커 이미지를 빌드해 줍니다.

$ docker build ./my-nginx -t my-nginx:0.0.2

잊지 마세요. 태그에 버전을 0.0.2로 변경하였으므로 당연히 docker-compose를 변경해야 합니다. 이제 docker-compose를 통해 컨테이너를 올려보겠습니다.

$ docker-compoase up -d

우리가 작성한 docker-compomse파일 대로 컨테이너가 실행되었습니다. 이제 localhost:8080으로 이동해 보세요. react페이지가 보이시나요? 

그렇다면 우리가 어떤 서버로 접속했는지 알아보기 위해 localhost:8080/where로 이동해 봅시다.

위와 같이 접속할 때마다 서버 정보가 변경되는 것을 확인할 수 있습니다. 실제 운영환경에선 이렇게 하면 서버가 바뀌며 세션정보가 유실되므로 앞서 설명한 ip_hash와 least_conn옵션을 켜고 서버를 배포해야 합니다.