Nginx를 이용한 배포 설정, Jenkins, Docker

Nginx를 이용한 배포 설정

Nginx는 웹 서버 및 리버스 프록시 서버로 널리 사용되는 소프트웨어로, 특히 고성능 웹 서버로서 많은 인기를 끌고 있습니다.

Nginx를 사용하여 웹 애플리케이션을 배포할 때, 몇 가지 중요한 설정과 에러 페이지 구성에 대해 알아보겠습니다.

 

프록시(Proxy)란?

프록시는 '대리인'이라는 뜻입니다. 컴퓨터 네트워크에서 프록시는 사용자의 요청을 받아 대신 처리해주는 서버를 의미합니다. 쉽게 말해,  어떤 웹사이트에 접속하고 싶을 때 프록시 서버가 그 웹사이트에 접속한 후, 그 내용을 전달해주는 역할을 합니다. 이렇게 하면 직접 웹사이트에 접속하지 않더라도 웹사이트의 정보를 볼 수 있습니다.

 

1. Nginx 설정 파일 (nginx.conf)

Nginx 설정 파일인 nginx.conf는 Nginx의 동작을 정의하는 핵심 파일입니다.

이 파일을 통해 서버 블록을 정의하고, 요청을 처리하는 방식을 설정할 수 있습니다.

 

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

    # 로그 설정
    access_log  /var/log/nginx/access.log;
    error_log   /var/log/nginx/error.log;

    sendfile        on;
    keepalive_timeout  65;

    # 서버 블록
    server {
        listen       80;
        server_name  example.com;

        # 루트 디렉토리 설정
        root /usr/share/nginx/html;
        index index.html index.htm;

        # 에러 페이지 설정
        error_page  404              /404.html;
        error_page  500 502 503 504  /50x.html;

        location / {
            try_files $uri $uri/ =404;
        }

        location = /404.html {
            internal;
        }

        location = /50x.html {
            internal;
        }
    }
}

 

2. 404 및 기타 에러 페이지 설정

웹 애플리케이션을 운영하다 보면 다양한 에러 페이지를 사용자에게 제공해야 할 상황이 발생합니다.

Nginx를 사용하여 다음과 같은 에러 페이지를 설정할 수 있습니다.

 

404 에러 페이지 설정

404 에러는 요청한 페이지를 찾을 수 없을 때 발생합니다.

이를 처리하기 위해 Nginx 설정 파일에 다음과 같이 정의합니다:

error_page 404 /404.html;
location = /404.html {
    internal;
}

위 설정은 404 에러가 발생했을 때 /404.html 페이지를 사용자에게 보여주도록 합니다.

internal 디렉티브는 이 페이지가 내부적으로만 접근 가능하도록 설정합니다.

 

500, 502, 503, 504 에러 페이지 설정

500번대 에러는 서버 내부에서 발생하는 오류입니다.

각 에러에 대해 개별적으로 처리할 수도 있고, 하나의 페이지로 통합하여 처리할 수도 있습니다.

error_page 500 502 503 504 /50x.html;
location = /50x.html {
    internal;
}

 

위 설정은 500, 502, 503, 504 에러가 발생했을 때 /50x.html 페이지를 사용자에게 보여줍니다.

 

3. 배포 시 고려사항

Nginx를 사용하여 웹 애플리케이션을 배포할 때는 다음 사항을 고려해야 합니다:

• 도메인 및 SSL 설정: 도메인 이름을 설정하고 SSL 인증서를 적용하여 HTTPS를 활성화합니다.
• 로드 밸런싱: 여러 서버에 트래픽을 분산시키기 위해 로드 밸런싱 설정을 고려합니다.
• 압축 및 캐싱: 성능 향상을 위해 gzip 압축을 활성화하고 캐싱 전략을 설정합니다.
• 보안 설정: 보안을 강화하기 위해 HTTP 헤더 설정, 접근 제어 목록(ACL), 방화벽 설정 등을 구성합니다.

SSL 인증서란?

SSL 인증서는 'Secure Sockets Layer'의 약자로, 웹사이트와 사용자의 브라우저 사이에 오가는 데이터를 암호화하는 역할을 합니다. 이를 통해 인터넷 상에서 데이터가 안전하게 전송될 수 있도록 합니다. 예를 들어, 여러분이 쇼핑몰에서 물건을 사기 위해 신용카드 정보를 입력할 때, 이 정보가 암호화되어 안전하게 전달되도록 해주는 것이 SSL 인증서입니다.

로드밸런싱이란?

로드밸런싱은 '부하 분산'이라는 뜻입니다. 여러 대의 서버가 동일한 작업을 처리할 때, 각각의 서버가 고르게 일을 나눠서 처리하도록 하는 것을 말합니다. 예를 들어, 아이스크림 가게에 손님이 많이 몰리면 가게 주인은 여러 명의 직원에게 손님을 나눠서 맡기겠죠? 로드밸런싱도 이와 비슷하게 서버에 몰리는 요청을 여러 서버에 고르게 분산시키는 역할을 합니다.

트래픽 분산 이유?

트래픽 분산의 이유는 서버의 과부하를 방지하고, 웹사이트의 성능을 높이기 위해서입니다. 한 서버에 요청이 너무 많이 몰리면 서버가 느려지거나 다운될 수 있습니다. 이를 방지하기 위해 여러 서버로 트래픽을 나눠서 처리하면, 서버의 부담을 줄이고, 사용자들에게 빠르고 안정적인 서비스를 제공할 수 있습니다.

 

 

예시: HTTPS 및 로드 밸런싱 설정

http {
    # gzip 압축 활성화
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    # 로드 밸런싱 설정
    upstream myapp {
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        listen 80;
        server_name example.com;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        server_name example.com;

        ssl_certificate /etc/ssl/certs/example.com.crt;
        ssl_certificate_key /etc/ssl/private/example.com.key;

        location / {
            proxy_pass http://myapp;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

 

위 설정은 HTTP 요청을 HTTPS로 리디렉션하고, 로드 밸런서를 사용하여 백엔드 서버에 트래픽을 분산시키며, SSL 인증서를 적용하여 보안을 강화합니다.

 

이처럼 Nginx 설정을 통해 웹 애플리케이션의 성능과 보안을 최적화할 수 있습니다.

Nginx 설정 파일을 적절히 수정하여 배포 시 필요한 기능을 구현해 보세요.

 

 

Nginx를 활용한 흐름도

Nginx는 웹서버, 프록시 서버, 로드 밸런서 등 다양한 역할을 할 수 있는 소프트웨어입니다.

아래는 Nginx를 활용한 웹 요청 처리 흐름도입니다.

이 흐름도는 Nginx가 클라이언트의 요청을 받아 백엔드 서버로 전달하고, 다시 클라이언트로 응답을 보내는 과정을 보여줍니다. Nginx는 이 과정에서 로드밸런싱, 프록시 역할을 수행하며, SSL 인증서를 통해 데이터를 암호화합니다.

 

1. 클라이언트 요청: 사용자가 브라우저를 통해 웹사이트에 접속을 시도합니다.
2. DNS 조회: 사용자의 브라우저가 도메인 이름을 IP 주소로 변환하기 위해 DNS 서버에 조회합니다.
3. Nginx 서버: DNS 조회를 통해 얻은 IP 주소를 통해 Nginx 서버에 요청을 보냅니다.
4. 프록시 역할: Nginx 서버는 프록시 역할을 하여 사용자의 요청을 백엔드 서버(실제 데이터를 처리하는 서버)로 전달합니다.
5. 로드밸런싱: Nginx 서버가 여러 백엔드 서버 중 하나를 선택하여 요청을 전달합니다. 로드밸런싱 기능을 통해 여러 서버에 요청을 고르게 분산시킵니다.
6. 백엔드 서버 응답: 백엔드 서버가 요청을 처리하고, 결과를 Nginx 서버로 다시 보냅니다.
7. Nginx 서버 응답: Nginx 서버가 백엔드 서버로부터 받은 응답을 사용자에게 전달합니다.
8. 클라이언트 응답: 사용자의 브라우저가 Nginx 서버로부터 응답을 받아 웹 페이지를 표시합니다.

 

 

구성 요소의 역할과 흐름을 설명해 드리겠습니다.

1. Client (클라이언트):
   • 웹 브라우저나 다른 HTTP 클라이언트를 의미합니다.
   • 사용자가 웹 페이지를 요청하면 클라이언트에서 HTTP 요청을 보냅니다.
2. Nginx (Proxy):
   • 클라이언트의 요청을 받아 프론트엔드와 백엔드 서버로 분배하는 역할을 합니다.
   • 기본 포트 80에서 동작합니다.
   • 두 개의 위치(location) 설정이 있습니다:
     • /: 프론트엔드 서버로의 요청을 처리합니다.
     • /api: 백엔드 서버로의 API 요청을 처리합니다.
3. Front (프론트엔드 서버):
   • Nginx가 프론트엔드의 정적 파일 (JS, HTML, CSS)을 서빙합니다.
   • 프론트엔드 서버는 포트 3000에서 동작합니다.
4. Server (백엔드 서버):
   • 프론트엔드에서의 API 요청을 처리하는 서버입니다.
   • 포트 5000에서 동작합니다.
   • 데이터베이스와의 통신도 담당합니다.
5. MySQL (데이터베이스 서버):
   • 백엔드 서버와 연결된 데이터베이스 서버입니다.
   • 포트 3063에서 동작합니다.

흐름 설명

1. 클라이언트 요청:
   • 클라이언트가 HTTP 요청을 Nginx 프록시 서버로 보냅니다.
2. Nginx 프록시 서버:
   • Nginx는 요청의 경로에 따라 요청을 프론트엔드 또는 백엔드 서버로 분배합니다.
     • / 경로로 오는 요청은 프론트엔드 서버 (포트 3000)로 전달됩니다.
     • /api 경로로 오는 요청은 백엔드 서버 (포트 5000)로 전달됩니다.
3. 프론트엔드 서버:
   • Nginx가 프론트엔드 서버에서 정적 파일을 서빙합니다.
   • 사용자에게 JS, HTML, CSS 파일을 제공합니다.
4. 백엔드 서버:
   • Nginx가 API 요청을 백엔드 서버로 전달합니다.
   • 백엔드 서버는 비즈니스 로직을 처리하고 데이터베이스와 통신합니다.
5. MySQL 데이터베이스:
   • 백엔드 서버는 필요한 데이터를 MySQL 데이터베이스에서 조회하거나 저장합니다.
6. 응답:
   • 백엔드 서버는 처리 결과를 Nginx를 통해 클라이언트에 응답합니다.
   • 프론트엔드 서버도 정적 파일을 Nginx를 통해 클라이언트에 응답합니다.

---

 

젠킨스와 도커: 개념 및 관련성

젠킨스 (Jenkins)

• 젠킨스(Jenkins)는 오픈 소스 자동화 서버로서, 주로 소프트웨어 개발 프로젝트에서 CI/CD(Continuous Integration/Continuous Delivery)를 구현하는 데 사용됩니다.
• Continuous Integration (CI): 여러 개발자가 코드를 병합할 때마다 자동으로 빌드하고 테스트하여 통합의 문제를 빠르게 발견할 수 있도록 합니다.
• Continuous Delivery (CD): CI를 통해 검증된 코드를 자동으로 배포하여 사용자가 지속적으로 업데이트된 소프트웨어를 사용할 수 있도록 합니다.
• 젠킨스는 다양한 플러그인과 연동하여 소프트웨어 개발, 테스트, 배포 파이프라인을 자동화할 수 있습니다.

 

도커 (Docker)

• 도커(Docker)는 소프트웨어를 컨테이너(Container)라는 독립적인 환경에서 실행할 수 있도록 도와주는 플랫폼입니다.
• 컨테이너(Container): 애플리케이션과 그 실행 환경을 패키지화하여 어디서나 동일하게 실행될 수 있도록 하는 기술입니다. 이를 통해 개발, 테스트, 배포 과정이 일관되게 유지됩니다.
• 도커를 사용하면 애플리케이션의 의존성, 설정 등을 컨테이너 이미지에 포함시켜, 어떤 환경에서도 일관되게 동작하도록 할 수 있습니다.

 

젠킨스와 도커의 관련성

1. CI/CD 파이프라인 구축:
   • 젠킨스를 통해 코드를 빌드하고, 테스트하며, 배포하는 과정을 자동화할 때 도커를 활용하면, 일관된 환경에서 안정적으로 이 과정을 수행할 수 있습니다.
   • 젠킨스에서 도커를 사용하면, 빌드 환경, 테스트 환경, 배포 환경을 각각 컨테이너로 분리하여 관리할 수 있습니다.
2. 컨테이너화된 빌드 및 테스트:
   • 젠킨스는 도커 컨테이너 안에서 빌드 및 테스트 작업을 수행할 수 있습니다. 이를 통해 환경 간의 차이로 인한 문제를 줄이고, 빌드 및 테스트의 일관성을 보장할 수 있습니다.
   • 예를 들어, 젠킨스 작업(Jenkins Job)을 설정할 때 도커 이미지를 지정하여 그 이미지 내에서 빌드 및 테스트를 수행하도록 할 수 있습니다.
3. 배포 자동화:
   • 젠킨스는 빌드된 도커 이미지를 도커 레지스트리(Docker Registry)에 푸시하고, 배포 환경에서 이를 가져와 실행하도록 자동화할 수 있습니다.
   • 젠킨스를 사용하여 애플리케이션이 업데이트될 때마다 자동으로 도커 이미지를 생성하고, 이를 프로덕션 환경에 배포할 수 있습니다.

 

Nginx와의 관련성

1. 프록시 및 로드 밸런싱:
   • Nginx는 웹 서버, 프록시 서버, 로드 밸런서로서 다양한 역할을 할 수 있습니다. 도커 컨테이너로 실행되는 애플리케이션들을 Nginx가 프록시하여 외부 트래픽을 분산시킬 수 있습니다.
   • 예를 들어, 여러 도커 컨테이너에 배포된 웹 애플리케이션들을 Nginx가 앞단에서 프록시하여 로드 밸런싱을 수행할 수 있습니다.
2. 젠킨스를 통한 Nginx 설정 배포:
   • 젠킨스를 이용하여 Nginx 설정 파일을 관리하고, 설정이 변경될 때마다 자동으로 Nginx를 재시작하거나 리로드하여 새로운 설정을 적용할 수 있습니다.
   • 이는 Nginx를 사용하는 웹 애플리케이션의 배포 및 관리에 있어서 효율적이고 자동화된 운영을 가능하게 합니다.

 

전체 흐름도

1. 코드 커밋:
   • 개발자가 코드 저장소(예: Git)에 코드를 커밋합니다.
2. 젠킨스 트리거:
   • 젠킨스가 코드 커밋을 감지하고, 빌드 및 테스트 작업을 시작합니다.
3. 도커 빌드:
   • 젠킨스는 도커 이미지를 빌드합니다. 이 이미지는 애플리케이션과 그 실행 환경을 포함합니다.
4. 도커 테스트:
   • 젠킨스는 빌드된 도커 이미지를 테스트합니다. 이 과정은 컨테이너 내에서 수행되므로 일관된 테스트 환경을 보장합니다.
5. 이미지 푸시:
   • 테스트가 성공하면, 젠킨스는 도커 이미지를 도커 레지스트리(Docker Registry)에 푸시합니다.
6. 배포 및 Nginx 업데이트:
   • 젠킨스는 도커 이미지를 배포 환경에 배포하고, Nginx 설정 파일을 업데이트하여 새로운 컨테이너를 프록시하도록 설정합니다.
7. Nginx 리로드:
   • Nginx를 리로드하여 새로운 설정을 적용하고, 트래픽을 새로운 컨테이너로 분산시킵니다.

이 과정을 통해 젠킨스와 도커, Nginx가 협력하여 일관되고 자동화된 애플리케이션 빌드, 테스트, 배포 파이프라인을 구축할 수 있습니다.