WE LIVE IN THE CLOUD

#03 Nginx Reverse Proxy(프록시) 서버 구축

admin_cloud — Fri, 4 Oct 2024 13:01:41 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 Nginx Reverse Proxy(프록시) 서버 구축을 목표로 합니다 .

Nginx Reverse Proxy(프록시) 서버 구축을 통해 어떻게 동작되는지, 어떻게 활용되는지 확인해 보겠습니다!

"#01 Proxy(프록시) 서버란?" & "#02 Squid Forward Proxy(프록시) 서버 구축" 이어지는 내용으로 참고해주세요!

#01 Proxy(프록시) 서버란?

안녕하세요. TAK 입니다:) 이번 포스팅은 Proxy(프록시) 서버란 무엇인지 알아보겠습니다. Proxy(프록시) 서버라는 단어는 네트워크 관련 주제에서 빠지지 않고 등장하는 용어인데, 낱낱이 살

with-cloud.tistory.com

#02 Squid Forward Proxy(프록시) 서버 구축

안녕하세요. TAK 입니다:) 이번 포스팅은 Squid Forward Proxy(프록시) 서버 구축을 목표로 합니다. Squid Forward Proxy(프록시) 서버 구축을 통해 어떻게 동작되는지, 어떻게 활용되는지 확인해 보

with-cloud.tistory.com

그럼 시작하겠습니다!

Contents

1. Reverse Proxy

https://cf-assets.www.cloudflare.com/slt3lc6tev37/3msJRtqxDysQslvrKvEf8x/f7f54c9a2cad3e4586f58e8e0e305389/reverse_proxy_flow.png

Reverse Proxy는 서버 쪽에 위치하여 클라이언트 요청을 받아 실제 서버로 전달하고, 서버의 응답을 클라이언트에게 반환하는 역할을 합니다.

그림에서는 origin server 는 내부 네트워크에 위한 서버를 의미하며, Proxy Server는 내부 혹은 DMZ 네트워크에 위치합니다.

이는 내부 서버를 보호하고, 로드 밸런싱, SSL 암호화, 캐싱 등의 기능을 제공하기 위해 사용됩니다.

1-1. Nginx Reverse Proxy

실제 구축 실습은 Nginx Reverse Proxy를 사용합니다.

Nginx Reverse Proxy는 위에 설명한 일반적인 Reverse Proxy의 클라이언트(사용자)와 웹 서버 간 중개자 역할을 하는 서버입니다. 이러한 일반적인 기능 이외 웹 서버로 향하는 요청에 대한 부하를 분산시키고, 내부 서버의 IP가 노출되지 않도록 보호하는 등 다양한 기능을 수행할 수 있습니다.

주요 특징은 다음과 같습니다.

트래픽 분산 (Traffic Distribution)
- 로드 밸런싱 (Load Balancing)
  - Nginx는 여러 백엔드 서버 사이에서 트래픽을 분산하여 로드를 균등하게 나누어 처리합니다.
  - 로드 밸런싱 알고리즘으로는 라운드 로빈, 최소 연결, IP 해시 등을 지원합니다.
  - 이를 통해 서버의 성능을 향상하고 응답 시간을 줄일 수 있습니다.
- 서버 상태 모니터링
  - Nginx는 백엔드 서버의 상태를 모니터링하여, 응답이 느리거나 실패한 서버로의 요청을 자동으로 조정합니다.
콘텐츠 캐싱 (Content Caching)
- 정적 및 동적 콘텐츠 캐싱 (Caching)
  - Nginx는 정적 파일 및 동적 콘텐츠의 캐싱을 지원합니다.
  - 자주 요청되는 콘텐츠를 캐시 하고, 서버의 부하를 줄이며, 클라이언트(사용자)의 요청에 대한 응답 속도를 향상합니다.
SSL/TLS 암호화 종료 (SSL/TLS Termination):
- Nginx는 SSL/TLS 암호화 및 복호화를 처리할 수 있으며, 이를 통해 백엔드 서버는 암호화되지 않은 트래픽만 처리할 수 있습니다.
- 이는 서버의 성능을 향상하고, SSL/TLS 인증서 관리를 중앙화할 수 있게 해 줍니다.
URL 재작성 및 리다이렉션 (URL Rewriting and Redirection):
- Nginx는 요청 URL을 재작성하거나 리다이렉션 할 수 있는 기능을 제공합니다.
- 이를 통해 URL 구조를 변경하거나, 특정 URL 패턴을 다른 URL로 전달할 수 있습니다.
보안 (Security):
- Nginx는 IP 주소 차단, 인증, 접근 제어 등을 통해 보안을 강화할 수 있습니다.
- 또한, 웹 애플리케이션 방화벽(WAF) 기능과 같은 보안 기능을 통해 악성 트래픽을 차단할 수 있습니다.
압축 (Compression):
- Nginx는 HTTP 응답을 압축하여 대역폭을 절약하고 응답 속도를 향상할 수 있습니다.
- Gzip 압축을 사용하여 콘텐츠를 압축하고 전송합니다.
고가용성 (High Availability):
- Nginx는 고가용성 아키텍처를 지원하여 시스템의 안정성을 높일 수 있습니다.
- 여러 Nginx 인스턴스를 클러스터링 하여 장애 발생 시 서비스가 계속 유지되도록 할 수 있습니다.
정적 콘텐츠 제공 (Static Content Serving):
- Nginx는 정적 파일(예: 이미지, CSS, JavaScript 등)을 매우 효율적으로 제공할 수 있습니다.
- 정적 콘텐츠 제공을 통해 백엔드 서버의 부하를 줄일 수 있습니다.
모니터링 및 로깅 (Monitoring and Logging):
- Nginx는 상세한 액세스 로그와 오류 로그를 기록하여 모니터링과 문제 해결에 도움을 줍니다.
- 다양한 로그 포맷과 로그 분석 도구를 지원합니다.

1-2. 구성도

이번 Reverse Proxy 실습은 Azure 환경에서 진행합니다.

위 그림과 같이 클라이언트(사용자)가 인터넷을 통해 Target 서버인 Server X, Y에 요청을 할 때,

Nginx Reverse Proxy를 통해 전달될 수 있도록 하는 구성(중계)하며, 응답도 마찬가지로 해당 Proxy 서버를 통해서 전달됩니다.

이 과정에서 Target 서버인 Server X, Y의 정보(ex. IP)의 노출 없이 진행됩니다.

각 서버의 상세 내역은 다음과 같습니다.

VM 정보(상세 Spec은 테스트이기에 가장 저렴하게 맞추시면 됩니다.)
- Client(User) : 외부 인터넷을 통한 요청이기 때문에 로컬 호스트, 즉 대부분이 사용하는 윈도우 환경
- Reverse Proxy(Nginx) : Linux(Ubuntu 24.04)
- Server X : Linux(Ubuntu 24.04), API 및 정적 콘텐츠 서버
- Server Y : Linux(Ubuntu 24.04), DB(MySQL) 서버
[내부 네트워크]라고 함은 "인증 및 인가되지 않은 액세스는 불가하며, 외부 통신을 제한한다"라는 가정이 전제됩니다.
Forward Proxy는 DMZ 구간으로 배포된 서버이며, 내/외부 네트워크 중간에 위치하여 제약 사항이 존재합니다.

1-2-1. 네트워크 구성

위 구성도를 보면, Proxy 와 서버 간 네트워크 대역이 다름을 확인할 수 있습니다.

정확히 Proxy는 DMZ(혹은 Hub) 구간에 배포되어 중계 역할을 하는 서비이기에, Target 서버와 서로 다른 네트워크 대역으로 구분하였습니다.

다만, Proxy와 Target 서버 간 통신을 위해 VNET Peering 을 통해 서로 다른 대역의 가상 네트워크를 연결을 진행합니다. 또한, ACL 역할을 하는 NSG(Network Security Group) 규칙을 통해 IP, Port 에 대해 보다 상세히 제어해 보도록 하겠습니다.

1-3. Nginx Reverse Proxy 구축

1-3-1. Nginx 설치

Nginx Reverse Proxy라는 것은 결국 Nginx 가 역방향 프록시 기능과 역할을 수행할 수 있음을 의미합니다.

따라서, 설치 자체는 일반적인 Nginx를 설치하는 것과 동일합니다.

이후, 역방향 프록시 기능과 역할을 수행할 수 있도록 서버의 구성을 설정하면 되는 구조입니다.

apt를 통한 Nginx 설치

sudo apt update
sudo apt install nginx -y

설치 확인(System 등록 및 curl 명령어)

**Target 서버 구성

이번 실습은 Nginx Reverse Proxy 대해 초점이 맞춰있습니다.

따라서, Target 서버 구성에 대해 자세히 다루지 않습니다.

간략히 정리하자면 다음과 같습니다.

- API 서버 : Flask 사용하여 API 요청에 대한 값 응답 구성(메시지, 정적 파일)

- DB 서버 : MySQL 설치하였고, DBA가 Tools(DBeaver 등)을 사용하여, 데이터 조회 혹은 활용(Join)을 하기 위한 간단한 데이터베이스, 테이블, 데이터 생성

1-3-2. Nginx Reverse Proxy 구성

Nginx의 전역 설정 파일은 /etc/nginx/nginx.conf 입니다. 이는 서버 전체의 기본 설정을 정의하는 곳으로 워커 프로세스 수, 로그 파일 위치, 기본 사용자 및 그룹, 타임아웃 등 성능과 보안 관련 전역 옵션이 포함됩니다.

또한, 전역적으로 사용할 HTTP 프로토콜 관련 설정을 정의합니다. 여기서 정의된 값들은 모든 서버 블록에 적용될 수 있으며, 서버별로 별도로 설정한 값이 없다면 기본적으로 사용됩니다.

해당 HTTP 블록에서 포함(include)시키는 부분인 /etc/nginx/sites-enabled/* 을 통해 개별 서버 설정 파일을 포함하는데, 이는 디렉터리 내의 파일들은 서버별 세부 설정을 관리합니다. 여기에는 각 도메인에 대한 포트, SSL 인증서, 리버스 프록시 설정 등이 포함됩니다.

즉, 사이트별 설정은 sites-available 디렉토리에 위치한 개별 설정 파일에서 관리되는 구조이며, 해당 설정(/etc/nginx/sites-enabled/*)에서 이번에 구성하고자 하는 Reverse Proxy 설정 및 관리가 이뤄집니다.

기본 값인 default 파일 구성은 다음과 같습니다.

# /etc/nginx/sites-available/default

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        #
        # listen 443 ssl default_server;
        # listen [::]:443 ssl default_server;
        #
        # Note: You should disable gzip for SSL traffic.
        # See: https://bugs.debian.org/773332
        #
        # Read up on ssl_ciphers to ensure a secure configuration.
        # See: https://bugs.debian.org/765782
        #
        # Self signed certs generated by the ssl-cert package
        # Don't use them in a production server!
        #
        # include snippets/snakeoil.conf;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name _;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

        # pass PHP scripts to FastCGI server
        #
        #location ~ \.php$ {
        #       include snippets/fastcgi-php.conf;
        #
        #       # With php-fpm (or other unix sockets):
        #       fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        #       # With php-cgi (or other tcp sockets):
        #       fastcgi_pass 127.0.0.1:9000;
        #}

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #       deny all;
        #}
}


# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#       listen 80;
#       listen [::]:80;
#
#       server_name example.com;
#
#       root /var/www/example.com;
#       index index.html;
#
#       location / {
#               try_files $uri $uri/ =404;
#       }
#}

해당 구성은 HTTP 요청에 대해 일반적으로 80 포트 기반, 클라이언트의 요청을 처리하는 방법을 정의하고 있습니다.

여기서, 추가 및 수정하고자 하는 부분은 다음과 같습니다.

- HTTPS(443) 설정 및 리디렉션

- Target 서버인 API(정적 콘텐츠)에 대한 Reverse Proxy 설정 > location 추가

- HTTP(S) 이외 다른 프로토콜(MySQL Admin 접근용) 처리 > Stream 정의(nginx.conf의 전역 설정)

위 항목에 대해 구성 파일별로 정의하겠습니다.

하지만, 그전에 Nginx의 모듈의 개념을 잠시 살펴보겠습니다.

**NGINX Moduels

a) HTTP 모듈
역할: HTTP 및 HTTPS 프로토콜을 처리하는 모듈입니다.

용도: 주로 웹 트래픽을 처리하며, 웹서버 기능을 제공하거나, 리버스 프록시(Reverse Proxy) 역할을 수행합니다. 정적/동적 콘텐츠를 제공하거나, 프록시 서버로서 백엔드 서버에 요청을 전달합니다.

구성 파일: /etc/nginx/sites-enabled/default와 같은 파일을 사용하여 HTTP 요청을 처리하는 설정을 합니다.

b) Server 모듈
역할: Nginx의 기본 단위로, HTTP, HTTPS, TCP/UDP 프로토콜을 사용하는 서비스를 정의할 수 있습니다.

용도: 각 프로토콜에 대한 서버 블록을 정의하며, listen 지시어를 사용해 해당 서버가 어떤 포트를 통해 요청을 수신할지 결정합니다. HTTP와 Stream 모듈에서 Server 블록은 각각의 프로토콜에 맞게 설정됩니다.

여기서 a) HTTP 모듈과 b) Server 모듈의 차이점을 정리해 보면 다음과 같습니다.

구분	HTTP 모듈	Server 모듈
역할	HTTP/HTTPS 트래픽을 처리하는 전체적인 설정을 관리함.	하나의 포트와 도메인에 대한 특정 설정을 정의함.
위치	http {} 블록 안에서 정의됨.	http {} 또는 stream {} 블록 안에서 정의됨.
기능	웹 트래픽, 로그 설정, 압축, 캐싱 등 다양한 기능을 지원함.	각 도메인 또는 IP에 대한 트래픽을 처리함. 포트, SSL 설정 등을 포함함.
구조	여러 개의 server {} 블록을 포함할 수 있음.	각 server {} 블록은 하나의 포트와 도메인을 담당함.

c) Stream 모듈
역할: TCP와 UDP 프로토콜을 처리하는 모듈입니다. HTTP가 아닌 다른 프로토콜(예: MySQL, Redis, SMTP 등)을 프록시하거나, 라우팅 할 때 사용됩니다.

용도: MySQL, Redis, SSH, SMTP 같은 TCP/UDP 기반 서비스의 트래픽을 프록시할 때 사용됩니다.

구성 파일: 이 모듈은 nginx.conf 파일의 최상위 레벨에 설정해야 합니다. HTTP 모듈과 별개로 처리되므로, HTTP 모듈을 사용하는 sites-enabled/default 같은 파일에서는 이 설정을 사용할 수 없습니다.

결과적으로 HTTP 모듈과 Stream 모듈은 서로 다른 트래픽을 처리하므로, 각각의 특성에 맞는 설정을 해야 합니다.

1-3-3. /etc/nginx/sites-enabled/*

해당 경로의 파일은 앞서 설명한 것처럼 HTTP(S) 관련 사이트 설정이 포함된 디렉토리로, HTTP 모듈과 관련된 설정만 포함됩니다. 즉, /etc/nginx/sites-enabled/* 디렉토리에서 사용하는 설정 파일들은 HTTP/HTTPS 트래픽을 처리하는 HTTP 모듈을 기반으로 동작합니다. Nginx의 HTTP 모듈은 기본적으로 웹 트래픽(HTTP, HTTPS)을 처리하도록 설계되어 있으며, 이를 통해 TCP/UDP 기반 트래픽을 직접 처리할 수는 없습니다.

웹 서비스와 같은 HTTP 기반 트래픽을 처리하며, 일반적으로 server 블록을 사용해 HTTP 요청을 다루며, 정적 파일 제공이나 리버스 프록시 설정을 수행합니다. 각 프로토콜에 대한 서버 블록을 정의하며, listen 지시어를 사용해 해당 서버가 어떤 포트를 통해 요청을 수신할지 결정합니다. HTTP와 Stream 모듈에서 Server 블록은 각각의 프로토콜에 맞게 설정됩니다. 즉, 각 server {} 블록은 하나의 도메인이나 서비스에 대한 설정을 정의합니다. 주로 특정 포트와 도메인에 대한 트래픽을 처리합니다.

이를 다음과 같이 설정할 수 있습니다.

크게 두 부분으로 나눠 설정하자면,

[# HTTP에서 HTTPS 리디렉션] 은 먼저 HTTP 요청을 80 포트에서 수신하여, 클라이언트가 HTTP 프로토콜을 통해 요청을 보낼 때, 이 서버 블록이 활성화됩니다. 이 설정에서는 모든 HTTP 요청을 HTTPS로 리디렉션 합니다.

이후,

[# HTTPS 프록시 설정] 에서는 HTTPS 요청을 처리합니다.

실제 Target 서버 프록시 전, SSL을 사용을 위한 인증 설정을 정의합니다. 이후, 각 서버의 구성에 맞춰 프록시 설정을 합니다.

실제 Target 서버인 API 서버로 프록시 하기 위해, location 설정에 따른 경로별 요청의 헤더 정보를 설정하여 원본 클라이언트의 IP 주소 및 요청 정보를 API 서버에 전달합니다. 이 설정을 통해 API 서버는 클라이언트 요청을 올바르게 인식하고 처리할 수 있습니다.

1-3-4. /etc/nginx/nginx.conf

MySQL 액세스를 위해서는 별도로 TCP/UDP 트래픽을 처리하기 위한 stream 모듈에서 처리해야 합니다.

stream 모듈은 Nginx의 기본 설정 파일에서 설정합니다. 해당 설정은 전체 Nginx 서버의 동작을 정의하며, stream 설정을 통해 TCP/UDP 트래픽을 처리합니다.

stream 모듈은 은 HTTP 요청이 아닌 TCP/UDP 프로토콜을 기반으로 하는 트래픽을 다루기 때문에, 이를 사용하여 Nginx를 TCP/UDP 프록시로 구성할 수 있습니다. 예를 들어, MySQL, Redis, PostgreSQL 등 TCP 기반 프로토콜을 프록싱할 수 있습니다.

즉, 데이터베이스와 같은 TCP 서비스는 반드시 stream 모듈을 통해 설정해야 하며, HTTP 모듈을 통해서는 설정할 수 없습니다.

stream 블록 내 TCP 및 UDP 트래픽을 처리할 수 있는 범위를 정의합니다.

여기서 upstream db_servers 블록을 통해 DB 서버의 IP와 포트를 정의합니다. 이는 클라이언트의 요청이 해당 정보로 전달되도록 합니다. 이후, Server 블록을 통해 클라이언트가 연결할 포트를 설정합니다. 여기서는 listen 3306;을 통해 클라이언트가 MySQL에 접속할 포트를 지정합니다. 클라이언트는 이 포트로 요청을 보내고, Nginx는 이를 수신합니다.

proxy_pass 지시어를 통해, 클라이언트의 요청을 실제 데이터베이스 서버로 전달하기 위해 proxy_pass db_servers;를 사용합니다. 이 지시어는 앞서 정의한 upstream 블록으로 설정한 서버로 요청을 포워딩합니다.

이렇게 Target 서버 중계를 위한 Proxy 서버의 설정을 마쳤습니다.

위 변경사항을 저장하고 Nginx가 올바르게 작동하는지 확인 후, 재시작합니다.

sudo nginx -t

sudo systemctl restart nginx

마음이 편안해지는 초록색~

(만약, nginx -t 명령어 실행 시, 에러가 발생한다면 Nginx의 에러 로그(/var/log/nginx/error.log)를 살펴보세요!)

마지막으로 위 구성을 통해, 정상적으로 Proxy 서버가 잘 동작하는지 테스트를 진행하겠습니다.

1-4. Proxy 테스트

Reverse Proxy를 구성한 이유는 Target 서버를 노출시키지 않고, 클라이언트(사용자)에 대한 요청을 Proxy 서버가 중계하여 응답을 반환하는 통신을 하기 위함입니다.

따라서, 인터넷을 통한 클라이언트의 요청을 Nginx Reverse Proxy에게 전달합니다.

우선, 기본 Nginx가 서비스하는 페이지를 확인해 보겠습니다.

http://<Nginx-Reverse-Proxy의 IP 혹은 DNS>

Server 블록에 정의한, 리디렉션 설정에 따라 동작
- 다만, 자체 서명 인증서 발급으로 인해, 신뢰할 수 없는 [인증서가 올바르지 않음]으로 표기
- [고급] 클릭 후, 보이는 링크로 이

기본 Nginx 페이지 확인

1-4-1. API 서버 Proxy

/etc/nginx/sites-enabled/default 의 Server 블록에서 정의한, URL 경로 구성에 따라 API 서버에 구성 요청이 중계가 잘 되는지 확인해 보겠습니다.

메시지(GET) : /api/

정적 파일 : /static/

위 그림들처럼, 클라이언트(사용자)가 인터넷을 통해 HTTP(S) 요청을 보내면, Nginx는 클라이언트로부터 온 요청을 받고, 그 요청을 백엔드 API 서버로 전달하기 위한 프록시 역할을 합니다. 위에서 정의한 설정 파일에 따라 클라이언트의 요청을 처리합니다.

즉, 해당 요청이 Nginx reverse proxy에 도달하고, Nginx가 그 요청을 백엔드의 API 서버로 전달한 뒤 응답을 다시 클라이언트로 반환하는 과정입니다.

이제 Nginx Reverse Proxy 서버의 로그를 살펴보겠습니다.

/var/log/nginx/access.log

위 순서대로 각 URL의 access 로그를 확인해 보면,

클라이언트(사용자)의 정보와 함께 정의된 경로로 요청 정보, 그리고 HTTP 상태 코드(200)가 확인되면서

API 서버가 중계된 요청에 대한 응답(데이터)을 반환하며 Proxy 역할이 잘 수행됨을 확인할 수 있습니다.

1-4-2. DB 서버 Proxy

/etc/nginx/nginx.conf 의 stream 블록에 정의한 설정에 따라 DB 서버에 접근할 수 있는지 확인해 보겠습니다.

해당 구성은 인터넷을 통해 DB Tool(DBeaver)을 통해 DBA가 접근하여 데이터를 조회하기 위한 가정으로 진행하였습니다.

DB의 경우, 서버 내 MySQL을 설치하고 데이터베이스, 테이블, 데이터를 생성한 상태입니다.

또한, 사용자를 추가하고, DB 접근을 위한 적절한 권한을 설정하였습니다.

중계의 흐름은 클라이언트가 Nginx에 연결하면, Nginx는 요청을 받아 정의된 upstream 블록을 통해 DB 서버에 전달합니다. 이때 Nginx는 클라이언트의 연결을 DB 서버와 연결하는 중개자 역할을 합니다. 이후, DB 서버는 Nginx로부터 받은 요청을 처리한 후, 결과를 Nginx로 반환합니다. 이 과정에서 DB 서버는 클라이언트의 IP 주소를 모르고 Nginx의 IP 주소만 알고 있습니다.

Nginx는 DB 서버로부터 받은 응답을 클라이언트에게 다시 전달합니다. 이때 클라이언트는 마치 DB 서버와 직접 연결된 것처럼 응답을 받을 수 있습니다.

DBeaver 연결

아래 3가지 항목 입력 후, [Test Connection] 을 통해 연결 여부를 확인하고 [완료] 클릭

- Server Host : Nginx Proxy 서버의 IP 혹은 DNS 입력

- Database : Database 이름

- Authentication : 로그인 정보

여기서, "Public Key Retrieval is not allowed" 에러 확인 시, [Driver properties] 탭에서 아래 항목을 "True" 변경하면 연결 문제를 해결할 수 있습니다.

연결 성공

데이터 조회

Join 쿼리문 실행
- 위 조회에 실행한 2 테이블 기반, 사용자의 이름과 그들이 주문한 제품 조회

다만, 위 구성은 access.log에 기록지 않습니다.

그 이유는 access.log는 기본적으로 HTTP 요청을 기록하도록 설계되어 있습니다. 이 로그 파일은 웹 트래픽을 기록하는 데 초점을 맞추고 있으며, 여기에는 URL, 브라우저 정보, HTTP 상태 코드 등의 HTTP 전용 정보가 포함됩니다.

따라서 stream 블록에서 logging을 위한 별도의 구성이 필요합니다. 즉, stream 모듈에 대해서는 별도의 로그 포맷과 로그 파일을 지정해야 합니다.

그렇다면, 구성 파일을 아래와 같이 수정합니다.

이후, 재연결을 시도하면 다음과 같이 DB 서버에 대한 연결 요청 시에 200 응답 코드를 확인할 수 있습니다.

여기서, 쿼리 실행 시 로그가 남지 않는 이유는 Nginx의 stream 모듈이 TCP 연결 자체에 대한 정보를 기록하고, TCP 세션 내부에서 주고받는 쿼리와 같은 애플리케이션 레벨의 데이터는 기본적으로 로그에 포함하지 않기 때문입니다.

Nginx의 stream 모듈은 주로 L4 (전송 계층)에서 동작하므로, HTTP처럼 요청과 응답을 각각 기록하는 방식이 아니라, TCP 연결의 시작과 종료만 기록하는 구조입니다.

만약, 쿼리 로그가 필요하다면, MySQL 로그 설정 혹은 DBeaver에서 쿼리 로그를 활성화하여 확인할 수 있습니다.

이상으로 "#03 Nginx Reverse Proxy(프록시) 서버 구축" 포스팅을 마치겠습니다!

제가 #02 Squid Forward Proxy 구축에서 빠른 시일 내 찾아뵙겠다고 말씀드렸지만, 굉장히;; 늦어졌습니다

다음에도 포스팅도 함께 나눌 수 있는 주제로 돌아오겠습니다!!

#02 Squid Forward Proxy(프록시) 서버 구축

admin_cloud — Thu, 8 Aug 2024 16:33:47 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 Squid Forward Proxy(프록시) 서버 구축을 목표로 합니다.

Squid Forward Proxy(프록시) 서버 구축을 통해 어떻게 동작되는지, 어떻게 활용되는지 확인해 보겠습니다!

현 구축 실습은 "#01 Proxy(프록시) 서버란?" 포스팅과 이어지기에 이해하시는데 도움이 될 거예요!

#01 Proxy(프록시) 서버란?

with-cloud.tistory.com

Contents

1. Forward Proxy

https://cf-assets.www.cloudflare.com/slt3lc6tev37/2MZmHGnCdYbQBIsZ4V11C6/25b48def8b56b63f7527d6ad65829676/forward_proxy_flow.png

구성에 앞서 다시 한번 설명하자면, Forward Proxy는 클라이언트와 인터넷 사이에 위치하여 클라이언트의 요청을 대신 처리해 주는 서버입니다.

그림에서는 use's device가 클라이언트입니다.

또한, 해당 클라이언트는 내부 네트워크에 위치하며, Proxy Server는 내부 혹은 DMZ 네트워크에 위치합니다.

클라이언트가 Forward Proxy에 요청을 보내면, Proxy 서버가 이를 인터넷으로 전달하고, 응답을 받아 클라이언트에게 반환합니다.

이를 통해 클라이언트의 IP 주소를 숨기거나, 콘텐츠 필터링, 캐싱, 보안 등을 제공할 수 있습니다.

1-1. Squid Proxy란?

실제 구축 실습은 Squid Proxy라는 오픈소스 Proxy를 사용합니다.

Squid Proxy 는 일반적인 개념 설명을 기준으로는 Cache & Web Proxy Server에 가깝지만, 일반적인 Proxy Server 가 가지는 특성을 가지고 있으며 클라이언트의 요청을 전달(Forward)하는 Forward Proxy와 같은 방향성을 가집니다.

주로 HTTP와 HTTPS 트래픽을 처리하며, 캐싱을 통해 네트워크 성능을 향상시키고, 네트워크 대역폭을 절약하는 데 도움을 줍니다. Squid는 또한 웹 필터링, 액세스 제어, 로깅 등의 기능을 제공합니다.

nginx, apache 등과 달리 Squid의 경우, Proxy로 사용하기 위한 별도의 설정 없이 자체가 Proxy를 위한 오픈소스이기 구축이 쉽고, 패키지 형태로 설치 가능하기에 Config 설정만 구성한다면 변경 등 관리적 측면에서 비교적 수월할 수 있습니다.

그 외 장점은 다음과 같습니다.

고급 캐싱 기능: HTTP, HTTPS, FTP 등 다양한 프로토콜을 지원하며, 매우 세밀한 캐싱 제어를 제공합니다.
네트워크 최적화: 대역폭 절약과 응답 시간 단축을 위해 고도로 최적화되어 있습니다.
액세스 제어 및 필터링: 강력한 ACL(Access Control List)을 통해 상세한 접근 제어와 웹 필터링을 할 수 있습니다.
로깅 및 모니터링: 상세한 로그와 모니터링 기능을 제공합니다.

1-2. 구성도

이번 Forward Proxy 실습은 Azure 환경에서 진행합니다.

위 그림과 같이 [내부 내부네트워크] 표시가 있는 클라이언트에서 Server X, Y에게 요청을 할 때,

10.11.0.0/24 대역에 배포된 Squid Proxy 를 통해서 요청이 전달될 수 있도록 하는 구성(중계 요청)으로 진행하겠습니다.

구성도에 대한 상세 사항은 다음과 같습니다.

VM 정보(상세 Spec은 테스트이기에 가장 저렴하게 맞추시면 됩니다.)
- Client A : Windows 10, Client B : Windows Server 2019
- Forward Proxy(Squid) : Linux(Ubuntu 24.04)
- Server X, Server Y : Linux(Rocky 9)
[내부 네트워크]라고 함은 "인증 및 인가되지 않은 액세스는 불가하며, 외부 통신을 제한한다"라는 가정이 전제됩니다.
Forward Proxy는 DMZ 구간으로 배포된 서버이며, 내/외부 네트워크 중간에 위치하여 제약 사항이 존재합니다.

1-3. 네트워크 구성

내부 네트워크와 Proxy Server 가 배포된 네트워크의 대역이 다릅니다.

이는 두 네트워크 내 배포된 서버 간 통신을 위해서 추가 작업이 필요하다는 의미입니다.

예를 들어, 다음과 같은 방법이 있습니다.

- 경로 테이블(UDR) 생성하여 Client 단의 트래픽을 Proxy Server 로 통하게 전파하는 방식으로 라우팅을 설정

- NSG(Network Security Group) 혹은 방화벽을 통한 접근 제어 방식

- VNET 간 Peering 을 구성하여 네트워크 연결

- VPN, 기타 등등

이 중 VNET 간 Peering 을 통해 사설 네트워크 간 통신 가능하도록 구성하고, ACL 역할을 하는 NSG(Network Security Group) 규칙을 통해 IP, Port 에 대해 보다 상세히 제어해 보도록 하겠습니다.

NSG의 기본 규칙 중 "가상 네트워크 간 통신은 모두 허용한다" 라는 것이 있습니다.

다만, NSG 는 우선순위 기반이기에 그 보다 더 높은 우선순위를 부여하여 출발지와 목적지를 특정할 수 있습니다.

1-3. Squid Proxy 구축

1-3-1. Squid Proxy 설치

apt 패키지 방식으로 설치 및 서비스 상태 확인

sudo apt update && sudo apt install squid

1-4. Squid Proxy 구성

config 파일 확인

sudo nano /etc/squid/squid.conf

Squid 가 리스닝 하는 Default 포트 정보 확인

well-known 포트이기에 실제 사용 목적이라면 변경합니다. 해당 실습에서는 기본 포트 사용합니다.

1-4-1. 인증

Squid Proxy Server에 Samab, LDAP 등 여러 가지 인증을 구성하는 방법이 있습니다.

가장 일반적인 방법 중 하나는 HTTP 기본 인증(Basic Authentication)을 사용하는 것입니다. 이를 위해서 "htpasswd" 유틸리티를 사용하여 사용자 계정을 생성합니다.

말 그대로 HTTP 기본 인증(Basic Authentication)은 서버에 액세스 할 수 있는 사용자를 식별하는 데 사용되며, 서버 보호에 이점이 있습니다.

하지만 전송되는 데이터의 경우, 암호화되지 않은 상태로 전달하기에 보안 상 취약합니다.

그래서!!

HTTPS를 통해 Squid와 클라이언트 간의 트래픽을 암호화하는 것이 좋기에...

이왕 하는 거 조금 더 번거롭지만? OpenSSL을 사용해서 자체 서명 인증서를 생성하여 TLS/SSL 인증서를 Squid Proxy 에 사용할 수 있도록 해보겠습니다!!

사용자 계정 생성
- 이후, 암호 생성 요청에 따라 신규 암호 생성

sudo apt-get install apache2-utils
sudo htpasswd -c /etc/squid/passwords <account_name>

인증서 및 키 생성

인증서와 키를 저장할 디렉터리 생성(.conf 파일과 동일한 경로)

sudo mkdir -p /etc/squid/ssl_cert

OpenSSL 사용해서 인증서와 키를 생성

원래는 key와 crt를 각각 생성하여 구분하는 것이 좋습니다만...

sudo openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout /etc/squid/ssl_cert/<CA_name>.pem -out /etc/squid/ssl_cert/<CA_name>.pem

생성 시, 국가 이름, 조직 이름 등과 같은 여러 가지 정보를 입력하게 되는데, 테스트이기에 임의로 하시면 됩니다.

인증서 및 키 생성 확인

1-4-2. ACL 및 인증 구성 적용

sudo nano /etc/squid/squid.conf

우선 용이한 작업을 위해 conf 파일을 복사하여 백업본을 생성한 후, 진행하겠습니다.

(.conf 파일을 들여다보면 주석 처리된 내용이 많기에, 수정하는데 번거로울 수 있습니다.)

주석 삭제 및 줄 공백 삭제 명령어

sudo sed -i '/^#/ d' /etc/squid/squid.conf
sudo sed -i '/^$/ d' /etc/squid/squid.conf

간략해진 .conf 파일을 보면 마음이 안정이 되는데요..

사실 Squid에서 요점은 간단합니다.

기본적으로 Deny 정책을 가져가되, localhost 의 액세스는 허용하고

특정 조건에 따라 적용될 ACL에 반영할 값을 정의 후, 접근 규칙에 반영 구조입니다.

요건은 다음과 같습니다.

- 내부 클라이언트에서 naver.com 접근 시 차단 / 그 외 허용

- 내부 클라이언트에서 외부 서버(4.217.253.107)에 80,443 접근 시 허용 / 그 외 IP 및 포트 접근 시 차단

따라서, 이번 실습에서 추가 및 변경할 부분은 다음과 같습니다. (이외 항목은 기본값 유지)

정의 규칙
- ACL 포트 정의 규칙
- ACL 특정 출발지 및 목적지 네트워크 & 도메인 정의 규칙
접근 제어 규칙
- 도메인 허용/차단 규칙
- 내부 네트워크에서 목적지 서버로의 접근 규칙
인증
- HTTPS 포트 설정
- 기본 인증(Basic Authentication)
- 인증된 사용자 ACL

위 사항들이 반영된 .conf 파일은 다음과 같습니다.

# ACL 요청을 필터링하는 데 사용되는 규칙
# 로컬 네트워크 범위 정의(Default 유지)
acl localnet src 0.0.0.1-0.255.255.255  # RFC 1122 "this" network (LAN)
acl localnet src 10.0.0.0/8             # RFC 1918 local private network (LAN)
acl localnet src 100.64.0.0/10          # RFC 6598 shared address space (CGN)
acl localnet src 169.254.0.0/16         # RFC 3927 link-local (directly plugged) machines
acl localnet src 172.16.0.0/12          # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16         # RFC 1918 local private network (LAN)
acl localnet src fc00::/7               # RFC 4193 local private network range
acl localnet src fe80::/10              # RFC 4291 link-local (directly plugged) machines

# ACL 포트 정의 규칙(불필요한 포트 정보 삭제)
acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 443         # https

# ACL 특정 출발지 및 목적지 네트워크 & 도메인 정의 규칙
acl internal_network src 172.16.10.0/24
acl destination_network dst 4.217.253.107
acl naver dstdomain .naver.com


# 접근 제어 규칙
# ACL을 기반으로 특정 요청을 허용 혹은 거부
# 포트 허용 규칙(안전하지 않은 포트와 관리 인터페이스에 대한 접근을 제어)
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localhost
http_access deny to_localhost
http_access deny to_linklocal

# 도메인 허용/차단 규칙(google, naver)
http_access deny naver
http_access allow !naver

# 내부 네트워크에서 목적지 서버로의 접근 규칙
http_access allow internal_network destination_network
http_access deny internal_network destination_network !Safe_ports

# 추가 설정 파일을 포함(Default 유지)
include /etc/squid/conf.d/*.conf

# 기본적으로 모든 접근을 차단
http_access deny all

# http 포트 정의(Default 유지)
http_port 3128

# https 포트 정의(인정서와 키 파일)
https_port 3129 tls-cert=/etc/squid/ssl_cert/<CA_name>.pem tls-key=/etc/squid/ssl_cert/<CA_name>.pem

# 기본 인증(Basic Authentication)
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on

# 인증된 사용자 ACL
acl authenticated proxy_auth REQUIRED
http_access allow authenticated

# 코어 덤프를 저장할 디렉터리 지정(Default 유지)
coredump_dir /var/spool/squid

# 다양한 유형의 캐싱 정책 설정(Default 유지)
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern .               0       20%     4320

1-5. Client 구성

Client는 Windows 10로 브라우저(Firefox) 단에서 프록시 설정을 진행해 보겠습니다.

검색바에서 프록시 검색

[수동 프록시 설정] 에서 Squid Proxy Server의 IP와 기본 포트(HTTP) 3128 그리고 HTTPS 옵션도 함께 선택

클라이언트에서 아운바운드 IP 확인
- IP를 확인해 보면, Squid Proxy Server 의 공용 IP가 확인됨.

1-6. Proxy 테스트

이제 클라이언트 단에서 Squid Proxy Server 테스트를 진행해 보겠습니다.

1-6-1. 도메인 제어 테스트

naver.com 액세스 시도 > 차단
Squid Proxy 의 (/var/log/squid/)access.log 확인 시, 403 응답 확인
with-cloud.tistory.com 연결 시도 > 허용
Squid Proxy 의 (/var/log/squid/)access.log 확인 시, 200 응답 확인

1-6-2. 목적지 IP 및 포트 제어 테스트

클라이언트 단에서 요청 시, 프록시가 중계 역할을 하기 때문에 Squid Proxy Server 의 IP와 Port를 지정하여, 외부 서버에 연결된 Azure NSG 규칙을 추가하여 액세스를 제한합니다.

목적지인 외부 서버와 80으로 서비스 중인 Nginx 액세스 시도 > 허용

access.log에 확인되는 응답 결과는 TCP_MISS/200인데, 이는 캐시에 저장된 정보가 없어 원격 서버로부터 데이터를 가져왔으며, 성공적으로 요청에 대해 응답했음을 의미합니다.

응답 코드 304의 경우, 서버에게 동일한 요청을 보낼 때 별다른 문제나 변화가 없으면 확인될 수 있으며 이는 변경 사항이 없으므로 캐시 되어 있는 자원으로 리디렉션 하겠다는 의미를 갖습니다.

목적지인 외부 서버와 8080으로 서비스 중인 Tomcat 액세스 시도 > 차단
- Squid Proxy Server에서 요청에 대한 거절의 메시지 내용이 있는 HTML 파일을 보여줌.

access.log 에서 해당 요청에 대한 응답 코드로 403을 반환

이상으로 "#02 Squid Forward Proxy(프록시) 서버 구축" 포스팅을 마치겠습니다!

원래 해당 포스팅에서 Reverse Proxy에 대한 실습 내용도 함께 작성하려고 했는데, 개인적인 이유로 시간적 여유가 부족해 별로 작성할 예정입니다. ~~(양해를 바라며...)~~

그럼 빠른 시일 내 Reverse Proxy 실습으로 다시 찾아오겠습니다!

함께 해주셔서 감사합니다

#01 Proxy(프록시) 서버란?

admin_cloud — Wed, 31 Jul 2024 15:19:47 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 Proxy(프록시) 서버란 무엇인지 알아보겠습니다.

Proxy(프록시) 서버라는 단어는 네트워크 관련 주제에서 빠지지 않고 등장하는 용어인데, 낱낱이 살펴보겠습니다!

1. Proxy(프록시) Server란?

1-1. Proxy(프록시) 의미

Proxy 라는 단어의 뜻을 먼저 살펴보면, "대리∙신(권)" 또는 "대리∙신의"이라는 의미인 것을 알 수 있습니다.

즉, 개념적인 용어로 특정 기능을 수행하는 역할이라고 표현할 수 있습니다.

이러한 일반적인 개념을 IT Network 영역에 적용하여

"클라이언트 요청을 다른 서버로 전달하고 그 결과를 클라이언트에게 반환하는 중계 역할" 하는 것을 "Proxy Server" 라고 합니다.

1-2. Proxy(프록시) 서버

좌 : https://www.fortinet.com/content/dam/fortinet/images/cyberglossary/proxy-server-1.jpeg 우 : https://data-flair.training/blogs/wp-content/uploads/sites/2/2022/01/mechanism-of-proxy-server.webp

위에 정의한 것을 다시 설명하자면, 클라이언트가 Proxy Server를 통해 다른 네트워크의 서비스에 간접적으로 액세스 할 수 있도록 해주는 컴퓨터 시스템이나 응용 프로그램을 말합니다.

즉, 클라이언와 서버 간 중계기로써 대리로 통신을 수행하는 것을 지칭하며 Proxy Server 이므로 물리적 혹은 가상 서버입니다.

Proxy Server 는 다양한 용도로 사용될 수 있습니다.

전에 포스팅한 CDN 과 비슷하게 캐시를 이용하여 클라이언트의 요청에 빠른 응답을 가능케 하고 이는 웹 브라우징의 속도를 향상합니다. 또한, 보안을 위한 방화벽 기능, 서버의 IP 주소를 숨기기 위한 익명화 등 다양한 네트워크 및 보안 기능을 제공합니다.

1-3. Proxy(프록시) 서버 특징

Proxy Server는 다음과 같은 특징을 가집니다. 아래 항목들은 Proxy Server의 종류에 따라 달라질 수 있습니다.

특징
- 중계 역할 :클라이언트의 요청을 대신하여 서버에 전달하고, 서버의 응답을 클라이언트로 전달합니다.
  다만, 서버를 관리하고 설정하는 과정이 복잡할 수 있으며, 상용 프로그램 사용 시에 추가 비용이 발생할 수 있습니다.
- 캐싱 기능 : 자주 요청되는 웹 페이지나 데이터를 캐시에 저장하여 같은 요청이 있을 때 더 빠르게 응답할 수 있습니다. 이를 통해 네트워크 대역폭을 절약하고 응답 시간을 단축시킵니다.
- 보안 강화 : 클라이언트의 IP를 숨겨 익명성을 제공하고, 악성 사이트에 대한 접근을 차단할 수 있습니다. 또한, HTTPS 프록시는 암호화된 트래픽을 검사하여 보안을 강화할 수 있습니다.
- 콘텐츠 필터링 : 특정 웹 사이트나 콘텐츠에 대한 접근을 차단하거나 제한할 수 있습니다. 이는 기업이나 학교에서 사용자가 부적절한 사이트에 접속하는 막는 데 사용될 수 있습니다.
  다만, 일부 웹 사이트나 서비스는 Proxy Server를 통한 접근을 차단할 수도 있습니다. 이는 익명화 Proxy나 지역 제한 우회를 위한 Proxy 사용 시 발생할 수 있습니다.
- 로깅 및 모니터링 : 사용자의 웹 활동을 기록하고 모니터링할 수 있습니다. 이를 통해 네트워크 사용 패턴을 분석하고 보안 위협을 감지할 수 있습니다.
  다만, 운영자가 사용자 트래픽을 모니터링할 수 있기에 프라이버시 침해의 우려가 있을 수 있습니다.
- 속도 저하 가능성 : 모든 트래픽이 Proxy Server를 거친다면, 서버의 성능에 따라 전체 네트워크 속도가 저하될 가능성이 있습니다.

1-4. Proxy(프록시) 서버 종류

Proxy Server는 다양한 유형으로 나뉘며, 각 유형은 목적에 따른 동작 방식을 통해 작동합니다.

즉, 네트워크 상 어디에 위치하는지 또는 네트워크 흐름이 어느 방향으로 데이터는 제공(혹은 요청) 하는지에 따라 달라집니다.

이는 Forward Proxy 와 Reverse Proxy 가 일반적이고 대표적으로 구분됩니다.

아래 항목들을 통해, 다양한 Proxy Server 유형과 간단한 다이어그램을 살펴보겠습니다.

웹 프록시(Web Proxy)
- 주로 HTTP, HTTPS 트래픽을 처리하는 Proxy Server 입니다.
- 클라이언트의 웹 요청을 받아 원격 서버에 전달하고, 응답을 클라이언트에서 반환합니다.
- 웹 사이트 접근 시, 보안과 익명성을 제공하고 특정 웹 사이트를 차단하거나 허용하는 데 사용합니다.
- 브라우저(Firefox, Chrome) 에서 웹 프록시를 사용할 수 있습니다.

캐싱 프록시 (Caching Proxy)
- 클라이언트 요청에 대한 응답 데이터를 캐시에 저장하여 동일한 요청에 다시 들어오면 캐시에 직접 데이터를 제공합니다.
- 이는 네트워크 대역폭을 절약하고 응답 시간을 단축합니다.
- 주로 자주 요청되는 데이터를 효율적으로 제공하기 위해 사용됩니다.

포워드(정방향) 프록시 (Forward Proxy)
- 클라이언트와 인터넷 사이에 위치하여 클라이언트의 요청을 대신 처리하고, 원격 서버의 응답을 클라이언트에게 전달합니다.
- 위 그림과 같이 내부 네트워크의 클라이언트의 요청으로 외부 서버의 데이터는 가져와 응답하는 형식으로 일반적으로 Proxy Server라는 것을 포워드(정방향) 프록시라고 부릅니다.
- 주로 내부 네트워크 사용자가 외부 인터넷에 접근할 때 사용되며, 사용자의 신원을 숨기고 익명성을 보장합니다.
- 보안, 캐싱, 콘텐츠 필터링 등의 기능을 제공합니다.

리버스(역방향) 프록시 (Reverse Proxy)
- 원격 서버(목적지) 앞단에 위치하여 외부 클라이언트의 요청을 받아 적절한 내부 서버로 전달합니다.
- 서버(목적지)를 외부 트래픽으로부터 보호하여 보안을 강화합니다.
- 앞단에 위치하고, 외부 트래픽으로 보호한다는 것은 해당 Proxy Server 가 실제 내부 네트워크에 위치한 서버와는 다른 네트워크 환경에 위치함을 시사합니다.
- 즉, 리버스(역방향) 프록시의 경우, 흔히 얘기하는 DMZ 하는 내/외부 네트워크 사이에 위치함으로써 내부 서버와네트워크 상 구분되어 있으며 이는 보안 이슈를 최소화하고자 함입니다.
- 여러 서버에 트래픽을 분산시키는 로드 밸런싱을 통해 각 서버의 부하를 줄임으로써 성능 최적화 합니다.

오픈(공개) 프록시 (Open Proxy)
- 누구나 접근할 수 있는 공개 Proxy Server 입니다.
- 즉, 인터넷상 모든 사용자가 접근할 수 있으며, 이를 통해 자신의 IP 주소를 남기지 않고 익명으로 활동할 수 있습니다.
- 다만, 이러한 서버는 크래킹, 악성 코드 또는 바이러스 유포 등 불법 행위에 악용되기 쉽습니다.

투명 프록시 (Transparent Proxy)
- "투명"이라는 말 그대로 클라이언트가 Proxy Server 를 사용하고 있다는 것을 인식하지 못합니다.
- 모든 트래픽이 자동으로 투명 프록시 서버를 통해 라우팅 됩니다.
- 이는 네트워크 레벨에서의 설정으로 네트워크 관리자에 의해 라우터나 스위치에서 설정됩니다.
- 서버(목적지)를 외부 트래픽으로부터 보호하여 보안을 강화합니다.

익명 프록시(Anonymous Proxy)
- 클라이언트의 실제 IP 주소를 숨기고 프록시 서버의 IP 주소로 대체하여 원격 서버(목적지)에 요청을 보냅니다.
- 이를 통해 사용자의 신원을 숨기고, 익명성을 유지하여 프라이버시 보호에 사용될 수 있습니다.

소켓 프록시(SOCKS Proxy)
- HTTP/HTTPS 이외에도 FTP, SMTP 등 다양한 프로토콜을 지원합니다. 이는 소켓 레벨에서 작동하기 때문에 특정 프르토콜에 종속되지 않습니다.
- 또한, 기본적인 인증 메커니즘을 지원하여 사용자 인증을 통해 보안을 강화할 수 있습니다. 즉, 허가된 사용자만 프록시 서버를 사용할 수 있게 합니다.
- 이를 통해 클라이언트와 서버 사이의 모든 데이터를 중계합니다.
- 다양한 프로토콜이 지원되므로 여러 프로토콜에 대해 네트워크 연결 테스트를 할 수 있으며, 방화벽 규칙을 적용하여 특정 네트워크에 액세스 하는 데 사용될 수 있습니다.

지금까지 "#01 Proxy(프록시) 서버란?" 을 통해 Proxy Server의 개념과 유형 등을 알아보았습니다.

다음 편에는 "#02 Proxy(프록시) 서버 구축"으로 돌아오겠습니다 (!!많관부!!)

자유로운 의견을 남겨주세요!

CDN(Content Delivery Network)란?

admin_cloud — Mon, 1 Jul 2024 14:48:38 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 CDN(Content Delivery Network)란 무엇인지 알아보겠습니다.

익숙하지만 추상적으로 알고 있는 CDN이라는 개념과 작동 방식을 함께 정리하면 좋을 것 같아 준비했습니다!

1. CDN(Content Deliver Network)란?

(좌)https://www.cloudflare.com/ko-kr/learning/cdn/what-is-a-cdn/ (우)https://blog.scaleflex.com/content/images/2022/12/how-does-a-cdn-work.png

CDN은 웹 콘텐츠를 사용자에게 효율적으로 전달할 수 있는 분산 서버 네트워크입니다.

말 그대로, CDN은 콘텐츠를 소비하는 사용자에게 필수적인 서비스로, 대기 시간을 최소화하며 최종 사용자에게 콘텐츠를 전달하는 역할을 합니다.

쉽게 표현하자면, 웹 페이지의 이미지, 동영상 등의 콘텐츠를 사용자(User)의 실제 위치(지리적 위치)와 가까운 서버에 캐싱하여, 콘텐츠를 기다릴 필요 없이 쇼핑, 영화 감상, 콘텐츠 다운로드, SNS 게시 등 작업을 원활히 수행할 수 있게 해 줍니다.

CDN은 이를 위해 PoP(Point of Presence) 위치에 캐시 된 콘텐츠(데이터 센터에 파일 사본을 임시로 저장하는 ‘캐싱’이라는 프로세스)를 Edge 서버에 저장합니다. 이를 통해 최종 사용자와 가까운 서버에서 콘텐츠를 제공하여 빠르고 효율적인 서비스가 가능해집니다.

1-1. 용어 설명

위에서 언급한 주요 용어에 대해서 살펴보겠습니다.

1-1-1. 캐싱(Caching)

캐싱은 파일의 사본을 임시로 저장하는 프로세스를 의미합니다.(즉, 임시로 저장한 테이터 요청 시간을 단축시키는 기술) CDN은 보통 글로벌 서비스를 제공하는데, 원본 서버에서 제공하는 콘텐츠를 전 세계 데이터 센터에 파일을 캐싱하여, 사용자가 가까운 서버에서 인터넷 콘텐츠에 접속할 수 있도록 합니다. 이를 통해 데이터 전송 시간을 단축하고 서버 부하를 줄입니다.

속도 향상: 사용자가 요청한 콘텐츠를 가까운 개시 서버에서 제공하여 대기 시간을 줄이고 빠르게 전달
서버 부하 감소: 원본 서버에 대한 요청을 줄여 서버 부하를 분산
대역폭 비용 절감: 원본 서버와 사용자 간의 직접 통신을 줄여 네트워크 대역폭 사용을 최적화
가용성 증가: 원본 서버 문제 시에도 캐시 서버에 저장된 콘텐츠를 통해서 서비스 지속 가능

**캐싱 방식

: CDN에서 캐싱은 크게 정적(Static) 캐싱과 동적(Dynamic) 캐싱으로 나눌 수 있습니다.

두 가지 방식은 각각의 콘텐츠 유형과 특성에 맞추어 최적화된 방법으로 캐시를 관리합니다.

*정적(Static) 캐싱

: 정적 캐싱은 자주 변하지 않는 콘텐츠를 캐시에 저장하는 방식입니다. 정적 콘텐츠는 일반적으로 변경 빈도가 낮고, 여러 사용자에게 동일한 형태로 제공되는 파일들입니다.(ex. 이미지, HTML, CSS 등)

- 변경 빈도가 낮음: 콘텐츠가 자주 변경되지 않아, 한 번 캐시에 저장되면 오랜 기간 동안 유효하게 사용할 수 있습니다.
- TTL 설정: Cache-Control 헤더를 통해 TTL(Time To Live)을 길게 설정하여, 캐시된 콘텐츠가 오랜 시간 동안 유지되도록 합니다.
- 고정된 URL: 정적 파일의 URL이 변경되지 않으므로, 캐시 히트를 통해 빠르게 제공됩니다.

- 속도 향상: 자주 요청되는 콘텐츠를 캐시에서 즉시 제공하여 로딩 시간 감소

- 서버 부하 감소: 원본 서버로의 요청이 줄어들어 서버 부하를 감소

- 일관성 유지: 동일한 콘텐츠가 여러 사용자에게 일관되게 제공

*동적(Dynamic) 캐싱

: 동적 캐싱은 자주 변경되는 콘텐츠를 캐시에 저장하는 방식입니다. 동적 콘텐츠는 사용자의 요청에 따라 실시간으로 생성되거나 변경되며, 사용자별로 다를 수 있는 데이터입니다. (ex. 실시간 뉴스, 주식, 쇼핑몰 추천 목록 등 )

- 변경 빈도가 높음: 콘텐츠가 자주 변경되어 캐시의 유효 기간을 짧게 설정하거나, 조건부 요청을 통해 최신 상태를 유지합니다.
- 조건부 요청 사용: ETag 또는 Last-Modified 헤더를 사용하여, 콘텐츠가 변경된 경우에만 캐시를 갱신합니다.
- 사용자별로 다름: 개인화된 콘텐츠의 경우, 사용자별로 다른 캐시를 관리해야 할 수 있습니다.

- 성능 최적화: 자주 변경되는 콘텐츠도 일정 기간 캐시를 통해 빠르게 제공할 수 있어 성능이 최적화 가능
- 최신 상태 유지: 조건부 요청을 통해 항상 최신 콘텐츠를 제공
- 서버 부하 감소: 동적 콘텐츠도 캐시를 통해 서버 부하를 줄일 수 있음.

1-1-2. PoP(Point of Presence)

PoP는 CDN의 네트워크 인프라의 일부로, 지리적으로 분산된 데이터 센터를 의미합니다. 각 PoP는 여러 캐시 서버를 포함하며, 사용자와 가까운 위치에서 콘텐츠를 제공하여 네트워크 지연 시간을 최소화합니다.

지연 시간 감소: 사용자와 가까운 PoP에서 콘텐츠를 제공하여 네트워크 지연 시간을 최소화
트래픽 분산: 전 세계에 분산된 PoP를 통해 트래픽을 분산시켜 네트워크 혼잡을 완화
지역 최적화: 각 지역의 네트워크 조건과 사용자 요구에 맞춰 최적화된 서비스를 제공
확장성: PoP를 추가하여 네트워크 용량을 확장하고, 급증하는 트래픽을 효율적으로 처리 가

1-1-3. Edge 서버

Edge 서버는 CDN에서 사용자와 가까운 위치에 배치되어 콘텐츠를 제공하는 서버입니다. PoP 내에 위치하거나 PoP 자체를 지칭하기도 하며, 사용자 요청을 처리하는 첫 번째 지점입니다. Edge 서버는 캐시된 콘텐츠를 통해 빠르게 사용자에게 데이터를 전달합니다.

콘텐츠 캐싱: 자주 요청되는 콘텐츠를 캐싱하여 빠르게 제공.
지연 시간 감소: 사용자와 지리적으로 가까운 위치에 배치되어 데이터 전송 거리 최소화
트래픽 분산: 트래픽을 분산시켜 네트워크 혼잡을 완화하고, 서버 과부하를 방지
지역 최적화: 특정 지역의 네트워크 조건과 사용자 요구에 맞춘 최적화
보안 강화: DDoS 공격 방어, SSL 암호화 등 보안 기능을 수행하여 원본 서버를 보호하고 사용자 데이터를 안전하게 전송

2. 작동 방식

(좌)https://www.hostinger.com/tutorials/wp-content/uploads/sites/2/2019/01/how-does-a-CDN-work-1-1024x886.webp (우)https://www.akamai.com/site/en/images/article/2023/what-is-a-cdn.png

CDN은 위에서 언급한 것처럼, 결과적으로는 사용자에게 빠르고 효율적으로 콘텐츠를 전달하기 위해 서비스입니다.

이를 위한 CDN 동작 방식을 예시와 함께 알아보겠습니다.

예를 들어, A 사용자가 한국에서 미국에 있는 웹 사이트(taknhyen.com)에 접속하여 고화질 동영상을 스트리밍 하려고 합니다.

a. 사용자 요청 (User Request)

- 사용자 A는 브라우저를 열고 taknhyen.com에 접속하여 고화질 동영상을 스트리밍 하기 위해 클릭합니다.

b. DNS 요청 (DNS Request)

- 사용자 A의 브라우저는 taknhyen.com의 IP 주소를 찾기 위해 DNS 서버에 요청을 보냅니다.

- DNS 서버는 taknhyen.com의 IP 주소를 확인하고, 가장 가까운 PoP(Point of Presence)를 찾기 위해 CDN의 DNS 서버로 요청을 전달합니다.

c. 가장 가까운 PoP 선택 (Selecting the Closest PoP)

- CDN의 DNS 서버는 사용자 A의 위치를 기반으로 가장 가까운 PoP를 선택합니다. 사용자 A는 한국 서울에 있으므로, 서울에 있는 PoP가 선택됩니다.

- DNS 서버는 사용자 A의 브라우저에 서울 PoP의 IP 주소를 반환합니다.

d. PoP의 Edge 서버에서 캐시 확인 (Cache Checking at PoP's Edge Server)

- 사용자 A의 브라우저는 서울 PoP의 Edge 서버에 콘텐츠 요청을 보냅니다.

- 서울 PoP의 Edge 서버는 요청된 고화질 동영상이 캐시에 있는지 확인합니다.

e. (상황 1) 캐시 적중 (Cache Hit) : 만약 고화질 동영상이 서울 PoP의 Edge 서버에 이미 캐시 되어 있다면, Edge 서버는 즉시 동영상을 사용자 A에게 스트리밍 합니다.

- 사용자 A는 서울 PoP의 Edge 서버로부터 고화질 동영상을 빠르게 스트리밍 할 수 있습니다.

e. (상황 2) 캐시 미스 (Cache Miss) : 만약 고화질 동영상이 서울 PoP의 Edge 서버에 없다면, Edge 서버는 미국에 있는 원본 서버(Origin Server)로부터 동영상을 가져와야 합니다.

- 서울 PoP의 Edge 서버는 미국의 원본 서버에 요청을 보내 고화질 동영상을 다운로드합니다.

- 원본 서버는 요청된 동영상을 서울 PoP의 Edge 서버로 전송합니다.

f. 콘텐츠 전달 (Content Delivery)

- 서울 PoP의 Edge 서버는 원본 서버로부터 받은 동영상을 캐시에 저장합니다.

- 저장된 동영상을 사용자 A에게 스트리밍 합니다.

- 사용자 A는 원본 서버에서 가져온 동영상을 서울 PoP의 Edge 서버를 통해 스트리밍 하게 됩니다.

g. 추가 요청 처리 (Handling Subsequent Requests)

- 이후 다른 사용자들이 같은 고화질 동영상을 요청하면, 서울 PoP의 Edge 서버에 캐시 된 동영상을 빠르게 제공할 수 있습니다.

- 이를 통해 대기 시간이 줄어들고, 서버 부하가 분산됩니다.

위와 같은 단계를 통해 CDN 서비스를 제공합니다.

지금까지 CDN의 개념과 작동 방식에 대해 함께 살펴보았습니다.

다음 포스팅에서는 "CDN 활용편"으로 찾아뵐게요!

의견을 자유롭게 댓글로 남겨주세요. 감사합니다:)

#2 Docker 그리고 Docker Network

admin_cloud — Mon, 24 Jun 2024 15:20:52 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 Docker Network에 알아보겠습니다!

아래 #1 Dcoker의 개념과 구조에 대한 글을 읽으시면, 이번 주제를 팔로우하는 데 도움이 되실 거예요.

#1 Docker 그리고 Docker Network

안녕하세요. TAK 입니다:) 날이 점점 더워지고 있는 요즘입니다 이번 포스팅의 주제로 Docker 그리고 Docker Network를 준비하였습니다 (아무래도 Docker 개념을 선행하는 것이 Network 영역을 이

with-cloud.tistory.com

그럼 바로 시작하겠습니다!

Contents

1. Docker Network

1-1. Docker Network 란?

: Docker Network는 Container 간, 그리고 컨테이너 외부 네트워크 간의 통신을 가능케 하여 이를 관리하고 격리하기 위한 기능 제공합니다. 이를 통해 다양한 네트워크 환경에서 컨테이너화된 애플리케이션을 효과적으로 배포하고 관리할 수 있습니다. Docker는 네트워크 구성을 쉽게 관리할 수 있도록 다양한 네트워크 드라이버와 옵션을 제공합니다.

1-2. Docker Network Drivers의 종류

: 아래 네트워크 드라이버의 경우, Native Driver 입니다. (Remote Driver는 3rd Patry Driver를 의미합니다.)

https://media.licdn.com/dms/image/D4D12AQEtEBjpPLradw/article-cover_image-shrink_600_2000/0/1656643165785?e=2147483647&v=beta&t=9Sp6nUvVgoxsdNfthGN8eLslgpKmUkNCCMm07a4RGFs

https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WKiEgPXO8XXppoqgr7ZVQA.png

Bridge Network
: Bridge Network는 Docker가 기본적으로 사용하는 네트워크 드라이버입니다. 이는 Docker 호스트 내에서 격리된 네트워크를 형성하며, 주로 단일 호스트에서 여러 컨테이너를 연결하는 데 사용됩니다.
- 'docker0'라는 가상 브리지 인터페이스를 사용하여 컨테이너를 연결합니다. 동일한 브리지 네트워크에 있는 컨테이너는 서로 통신할 수 있습니다.
- 단일 서버에서 여러 컨테이너로 구성된 애플리케이션을 실행할 때 유용합니다.
- 컨테이너의 포트를 호스트의 포트에 매핑하여 외부 통신이 가능합니다.
```
# 새로운 드라이버(Bridge) 생성
docker network create --driver bridge my_bridge_network

#container1(nginx)과 container2(redis)가 같은 Bridge 네트워크를 통해 서로 통신 가능
docker run -d --name container1 --network my_bridge_network nginx
docker run -d --name container2 --network my_bridge_network redis
```

Host Network
: Host Network는 컨테이너가 Docker 호스트의 네트워크 스택을 직접 사용하도록 합니다. 이 경우, 컨테이너는 별도의 네트워크 네임스페이스를 가지지 않고, 호스트와 동일한 네트워크 인터페이스를 공유합니다.
- 컨테이너가 호스트 네트워크 스택을 사용하므로, 네트워크 성능이 향상되지만 네트워크 격리가 줄어듭니다.
- 성능이 중요한 경우나, 호스트 네트워크와 완전한 통합이 필요한 경우에 사용됩니다.
```
# nginx 컨테이너가 호스트 네트워크 스택을 직접 사용 
docker run -d --network host nginx
```

None Network
: None Network는 네트워크가 전혀 연결되지 않은 상태로 컨테이너를 실행하는 네트워크 모드입니다.
- 네트워크 인터페이스가 없으며, 외부와의 통신이 불가능합니다.
- 네트워크가 필요 없는 작업(예: 로컬 파일 작업이나 CPU 집약적인 작업)을 수행할 때 유용합니다.
```
docker run -d --name isolated_container --network none nginx
```

Overlay Network
: Overlay Network는 여러 Docker 호스트에서 실행되는 컨테이너를 연결하는 데 사용됩니다. 이는 Docker Swarm이나 Kubernetes 같은 오케스트레이션 도구와 함께 사용됩니다.
- 여러 Docker 데몬(호스트)에서 실행되는 컨테이너를 연결할 수 있습니다.
- VXLAN(Virtual Extensible LAN)을 사용하여 네트워크 패킷을 터널링 합니다.
  (이는 물리적 네트워크 상에 논리적 네트워크를 구축하여, 여러 호스트에 걸친 네트워크를 형성합니다.)
- 각 호스트가 외부 네트워크와 통신할 수 있으며, 오버레이 네트워크를 통해 다른 호스트의 컨테이너와도 통신할 수 있습니다. 이는 다중 호스트 환경에서 마이크로서비스 아키텍처를 구축할 때 사용됩니다.
```
docker network create -d overlay my_overlay_network
docker service create --name my_service --network my_overlay_network nginx
```

1-3. 구조 및 내역

좌 : Default Network(docker0)

Docker Network는 위 그림과 같은 구조를 가집니다.

각각의 요소들은 호스트(192.168.0)와 컨테이너(172.17.0) 사이의 네트워킹을 관리하는 요소로 연결 및 통신을 위한 역할은 다음과 같습니다.

(Host) eth0
: Host Ethernet Interface는 쉽게 표현하면 (물리적) 랜카드입니다. eth0의 0은 Interface의 인덱스(번호)를 나타내며, 기본적으로 eth0에서 순차적으로 증가합니다. 이는 컴퓨터의 네트워크 연결을 나타내며, 호스트 시스템의 네트워크 스택과 직접 상호 작용합니다.

호스트 eth0은 호스트 시스템에서 수신된 모든 네트워크 패킷을 처리하고, 이를 컨테이너로 전달하거나 컨테이너에서 수신된 패킷을 호스트 시스템으로 라우팅 합니다.
Bridge
: 앞서 설명한 호스트와 컨테이너 간의 통신을 중개하는 역할을 합니다. 즉, 브리지는 네트워크의 물리적인 및 가상적인 부분을 연결하는 네트워크 장치입니다. 도커에서는 도커 엔진이 자동으로 생성하는 가상 스위치로 사용됩니다.

도커 브리지는 호스트의 네트워크와 컨테이너 간의 통신을 중개합니다. 브리지는 물리적 네트워크와 가상 이더넷 인터페이스인 veth 쌍을 연결하여 통신을 관리합니다.
veth
: Virtual Ethernet Interface로 일종의 가상 랜카드 역할을 수행합니다. veth는 컨테이너와 브리지 사이의 가상 이더넷(Container eth0) 연결입니다. veth 쌍은 컨테이너 내부와 호스트의 네트워크 네임스페이스 사이에 생성됩니다.

각 컨테이너가 생성될 때, Bridge(docker0)와 바인딩 - Container 내부 eth0라는 이름으로 veth인터페이스와 연결됩니다. 즉, veth 쌍 중 하나는 컨테이너 내부의 네트워크 네임스페이스에 연결되고, 다른 하나는 브리지에 연결됩니다. 이를 통해 컨테이너와 호스트 네트워크 사이에 패킷이 전달되어 컨테이너는 외부와 통신할 수 있습니다.
(이는 일반적인 NI와 달리, 패킷을 전달받으면 자신에게 연결된 다른 NI로 패킷을 보내는 식으로 동작하기에 항상 쌍으로 생성해줘야 합니다.)
(Container) eth0
: 컨테이너 eth0은 컨테이너 내부의 네트워크 인터페이스를 나타냅니다. 컨테이너 내에서 실행되는 응용 프로그램은 이 인터페이스를 사용하여 네트워크 통신을 합니다.

컨테이너 eth0은 해당 컨테이너의 네트워크 스택과 연결되어 있으며, 컨테이너 내부의 IP 주소 및 네트워크 설정을 관리합니다.

우측에는 my_bridge라는 새로운 Bridge를 만들었으며, Defaut 대역이 아닌 10.0.~ 대역을 사용하고 있습니다.

이는 docker0 Bridge와는 서로 다른 대역을 가지고 있으며,

1-4. Sample

: 앞서 설명한 내용들을 바탕으로 실제 Docker Network 의 구성 사항들을 살펴보고, 몇 가지 구조 기반 테스트를 해보겠습니다.

Host 정보 확인
: Host 시스템의 NIC(네트워크 인터페이스) 정보를 확인해 보겠습니다.

아래 Host의 네트워크 인터페이스를 나타내는 eth0 경우,
Azure VNet(192.168.11.0/24)의 서브넷 192.168.11.0/28(192.168.11.0 - 192.168.11.15) 대역을 사용하고 있으며, 해당 VM은 Private IP(192.168.11.4) 를 할당받은 상태입니다.

Docker 설치 시, Default 네트워크인 Bridge(docker0)의 경우, 172.17.0.0/24 대역을 사용하고 있음을 확인할 수 있습니다.

Docker Network 확인
: Docker 엔진에서 사용 가능한 모든 네트워크 설정을 확인해 보겠습니다.

이후, 아래 명령어는 통해 bridge의 상제 네트워크 정보를 확인해 보겠습니다.
```
docker network inspect <network_name_or_id>
```
Default 네트워크 드라이버이기에 별 다른 설정 없이 컨테이너를 생성한다면, 해당 Bridge(docker0)를 사용합니다. 또한, 서브넷 대역(172.17.0.0/16) 의 IP를 실행되는 컨테이너에 순차적으로 할당합니다.

이전 배포된 컨테이너의 네트워크 확인
: #1에서 마지막에 배포한 컨테이너의 네트워크 정보를 확인해 보겠습니다.

# 현재 컨테이너 실행 중인지 확인
docker ps 

# 만약, 아무것도 나오지 않는다면, 현재 실행중인 상태가 아니므로
# 아래 명령어를 통해 전체 컨테이너 목록 확인
docker ps -a

# status가 'exited'라면, 아래 명령어 사용하며 (재)실행
docker (re)start <container_id_or_name>

우선, 아래 명령어를 통해서 네트워크 설정을 확인해 보면 다음과 같습니다.

# 출력값 중, NetworkSettings 만 확인
docker inspect <container_id_or_name>

실제 실행 중인 컨테이너 내부에서 확인한다면 다음과 같습니다.

# container 접속
docker exec -it <container_id_or_name> /bin/bash

# ip addr or ifconfig 명령어 사용하여 확인
# 172.17.0.1인 GW IP로 172.17.0.2부터 순차적으로 컨테이너에 IP 할당

이렇게, Default 네트워크인 Bridge(docker0) 드라이버를 사용하는 네트워크 구성을 살펴보았습니다.

이어서 TEST 1 & TEST 2 를 통해서 네트워크 구성을 다각화해 보겠습니다.

**TEST 1

: 이번 테스트는 서로 다른 네트워크를 사용하여 격리된 컨테이너 간의 네트워크 테스트를 진행하고(Step1), Bridge에 veth 연결을 통해 격리된 컨테이너 간 네트워크 연결을 통해 통신이 가능(Step2)하도록 진행해 보겠습니다.

my_bridge라는 새로운 Bridge 네트워크 드라이버를 생성하고, "10.0.0.0/24" 대역에서 "10.0.0.254" IP를 db 컨테이너에 할당해 보겠습니다. 이후, 해당 Bridge 에 web 컨테이너를 연결하는 과정입니다.

좌 : Step1 우 : Step2

네트워크 드라이버 생성
: 아래 명령어를 통해 my_bridge라는 네트워크 드라이버를 생성합니다.

docker network create \
  --driver=bridge \
  --subnet=10.0.0.0/24 \
  --gateway=10.0.0.1 \
 my_bridge

이후. db 컨테이너(mariadb 이미지)를 실행하여 네트워크 통신 테스트를 진행해 보겠습니다.

db 컨테이너(mariadb 이미지)를 생성 및 실행

# 네트워크(my_bridge)와 IP(10.0.0.254) 지정
# 'MYSQL_ROOT_PASSWORD' 지정하지 않으면, 배포 및 실행 불가
docker run -d --name db --network=my_bridge --ip=10.0.0.254 -e MYSQL_ROOT_PASSWORD=tak_password mariadb

db 컨테이너 네트워크 정보 확인

web 컨테이너(앞서 구성한 Flask 앱)의 통신 테스트
: 해당 컨테이너에 할당된 IP는 172.17.0.2 이며, 서로 다른 네트워크로 격리된 컨테이너 간에 통신이 불가합니다.

이제 Step2 로 넘어가 my_bridge라는 네트워크 드라이버에 web 컨테이너를 연결해 보도록 하겠습니다.
(Bridge 네트워크 드라이버는 여러 컨테이너와 연결이 가능함을 앞서 설명드렸습니다. 이는 실행 중인 컨테이너도 연결이 가능합니다.)

네트워크 드라이버와 컨테이너 연결

docker network connect <docker network ID or Name> <container ID or Name>

web 컨테이너의 네트워크 정보 확인
: my_bridge 네트워크 드라이버에 설정한 네트워크 대역(10.0.0.0/24) 에서 순차적으로 IP를 할당받음을 확인(GW IP 10.0.0.1 제외)

네트워크 통신 확인
: (db 컨테이너 > web 컨테이너) 172.17.0.2와 같은 특정 IP을 지정하지 않고, 컨테이너 자체로 ping 테스트

Test 1을 통해서, 서로 다른 네트워크 환경을 구성하고 컨테이너의 격리와 연결 여부를 테스트하였습니다.

**TEST 2

: 이번에는 하나의 네트워크 드라이브에서 2-Tier 애플리케이션을 구성하여 동작 과정 테스트 해보겠습니다.

신규 Bridge 생성
: 특정 네트워크 대역을 위해 생성합니다. 만약, 특정값이 필요하지 않다면, docker-compose.yml 의 네트워크 이름과 driver 종류를 입력하면 임의값으로 생성됩니다.

docker network create \
  --driver=bridge \
  --subnet=10.11.12.0/24 \
  --gateway=10.11.12.1 \
 3tier_bridge

디렉터리 구조
: 애플리케이션 배포를 위해 스크립트를 포함한 필요한 디렉터리 구조아 소스 코드 구성을 다음과 같습니다.

이번 포스팅에서는 소스 코드에 대한 내용보다는 Docker 관련 파일 내용에 집중합니다.

상세 소스 코드는 제 Github에 확인하실 수 있습니다!!

docker-compose.yml
: docker-compose.yml 파일은 여러 도커 컨테이너를 정의하고 관리하는 데 사용되는 YAML 형식의 파일입니다. 이 파일을 사용하면 여러 컨테이너를 손쉽게 설정하고 동시에 시작할 수 있습니다.

Sample

# Compose 파일의 버전 지정
# 더 이상 docker-compose 파일에 버전을 명시할 필요가 없음.
# 만약 명시하다면, 'version' is obsolete 라는 경고 문구 확인 됨.(배포는 정상적으로 진행)
version: '3.*'  

services:  # 관리할 서비스(컨테이너) 정의
  service_name:  # 서비스 이름
    image: image_name:tag  # 사용할 Docker 이미지
    build:  # 빌드 옵션 (이미지를 직접 빌드할 때 사용)
      context: .  # Dockerfile의 경로
      dockerfile: Dockerfile  # 사용할 Dockerfile의 이름
    ports:  # 호스트와 컨테이너 간의 포트 매핑
      - "host_port:container_port"
    volumes:  # 호스트와 컨테이너 간의 볼륨 매핑
      - host_path:container_path
    environment:  # 환경 변수 설정
      - ENV_VAR_NAME=value
    depends_on:  # 이 서비스가 의존하는 다른 서비스
      - other_service_name
    networks:  # 이 서비스가 연결될 네트워크
      - network_name

networks:  # 네트워크 정의
  network_name:
    driver: bridge  # 네트워크 드라이버 (예: bridge, overlay 등)

volumes:  # 볼륨 정의
  volume_name:
    driver: local  # 볼륨 드라이버 (예: local)

실제 적용한 .yml 파일
: Flask와 MySQL 를 포함하는 2개 이상의 컨테이너는 배포 시, 유용하게 사용 가능.

services:
  app:
    container_name: my-flask-app
    build:
      context: ./flask
      dockerfile: Dockerfile
    ports: # 호스트의 5000번 포트를 컨테이너의 5000번 포트에 매핑
      - "5000:5000"
    environment: # .evn라는 환경변수 파일에서 값을 가져옴.
      MYSQL_HOST: ${MYSQL_HOST}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - ./flask/app:/app/app
    depends_on:
      - db
    networks:
      - 2tier_bridge

  db:
    container_name: my-flask-app-db
    build:
      context: ./db
      dockerfile: Dockerfile
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    expose: # 포트를 외부에 공개하지 않고 다른 컨테이너에 노출
      - "3306"
    volumes:
      - ./db/init_db.sql:/docker-entrypoint-initdb.d/init_db.sql
    networks:
      - 2tier_bridge

networks:
  2tier_bridge:
    driver: bridge

Dockerfile
: Dockerfile은 Docker 이미지를 정의하는 파일입니다. Dockerfile을 통해 특정 소프트웨어 환경을 구성하는데 필요한 모든 지침을 Docker에게 제공할 수 있습니다.

Sample

# 베이스 이미지
FROM base_image:tag

# 작성자 정보
LABEL maintainer="your_name@example.com"

# 환경 변수 설정
ENV ENV_VAR_NAME=value

# 작업 디렉터리 설정
WORKDIR /path/to/workdir

# 파일 or 디렉터리 복사
COPY src /dest
# URL에서 파일을 다운로드하거나 압축 파일 해제
ADD src /dest

# 패키지 설치(이미지 빌드 시, 실행할 명령어 지정)
RUN command

# 포트 노출(컨테이너가 수신 대기할 포트 지정)
EXPOSE port_number

# 기본 실행 명령어 설정(컨테이너가 시작될 때 실행할 기본 명령어 지정)
CMD ["executable","param1","param2"]

# 컨테이너 실행 시 실행할 명령어(컨테이너가 시작될 때 항상 실행되도록 지정)
ENTRYPOINT ["executable","param1","param2"]

*CMD와 ENTRYPOINT의 차이점
: 'CMD'와 'ENTRYPOINT' 두 지시어 모두, 컨테이너가 시작할 때 실행되는 명령어를 설정하는 사용됩니다.
다만, ' ENTRYPOINT'의 경우, 항상 실행되기에 추가 인자로 덮어 쓸 수 없습니다.
'CMD'의 경우, docker run 명령어를 통해 추가 인자를 사용하여 덮어 쓸 수 있습니다.

flask

FROM python:3.9

WORKDIR /app

COPY ./requirements.txt /app/
COPY ./app /app/app

RUN pip install --no-cache-dir -r requirements.txt

CMD ["flask", "run", "--host=0.0.0.0"]

FROM mysql:8.0

# 환경 변수(.env) 설정
ENV MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
ENV MYSQL_DATABASE=${MYSQL_DATABASE}
ENV MYSQL_USER=${MYSQL_USER}
ENV MYSQL_PASSWORD=${MYSQL_PASSWORD}

# 초기화 SQL 파일 추가
COPY init_db.sql /docker-entrypoint-initdb.d/init_db.sql

Docker 실행

docker compose up -d --build

정상적으로 컨테이너 (현재) 실행 여부 확인

네트워크 확인

애플리케이션 정상 구동 확인
: 외부 오픈(노출) 포트 5000 접속, Azure의 NSG 인바운드 정책에 5000포트에 대한 인터넷 액세스 추가 필수!

DB 연동 확인
: 게시판에 글 작성 후, MySQL 컨테이너 내부에 데이터 기록(저장)되는지 확인

데이터 기입 후, [Submit] 클릭

MySQL DB 컨테이너 접속

데이터 확인

이상으로 "Docker" & "Docker Network" 에 대해 알아보았습니다.

여러분들이 생각하는 의견을 자유롭게 댓글로 남겨주세요:)

다음에도 도움이 되는 자료로 찾아뵙겠습니다!

#1 Docker 그리고 Docker Network

admin_cloud — Wed, 29 May 2024 17:19:05 +0900

안녕하세요. TAK 입니다:)

날이 점점 더워지고 있는 요즘입니다

이번 포스팅의 주제로 Docker 그리고 Docker Network를 준비하였습니다

(아무래도 Docker 개념을 선행하는 것이 Network 영역을 이해하는데 도움이 되겠죠?!)

그럼 바로 시작하겠습니다!

Contents

1. Docker

1-1. Docker 란?

https://www.docker.com/wp-content/uploads/2023/05/symbol_blue-docker-logo.png

: Docker는 2013년 Docker사에서 Go 언어로 개발한 오픈소스 플랫폼입니다.

이는 Docker Engine 혹은 관련된 모든 프로젝트를 포함한 것을 의미하여, Docker Engine을 사용하여 *리눅스 컨테이너(Linux Container)를 제어하고, 다양한 기능을 사용하여 더 편리하고 쉽게 관리할 수 있습니다.

Docker라는 플랫폼은 컨테이너라는 격리된 환경에서 애플리케이션을 패키징하고 실행하는 기능을 제공합니다.

격리 및 보안을 통해 특정 호스트에서 동시에 많은 컨테이너를 실행할 수 있습니다.

컨테이너는 가볍고 애플리케이션을 실행하는 데 필요한 모든 것을 포함하고 있으며, 이식성이라는 특징이 있어, 이는 개발환경, 테스트 환경, 서비스 환경을 모두 동일(Onprem, Cloud 또는 Hybird 환경 등에서도 실행 가능)하게 사용할 수 있기 때문입니다.

*리눅스 컨테이너란?

https://www.weave.works/blog/a-practical-guide-to-choosing-between-docker-containers-and-vms

: 리눅스 컨테이너는 컨테이너 가상화 기술을 사용합니다. 리눅스 컨테이너에는 애플리케이션이나 이에 필요한 라이브러리 및 설정 파일 등이 포함되어 있습니다.

리눅스 컨테이너를 설명할 때 빠지지 않는 것이 바로 가상 머신과의 비교입니다.

리눅스 컨테이너는 가상 머신과 다르게 가상화 계층이 없고 커널이 별로 존재하지 않기 때문에 가상 머신에 비해 가볍고 실행 속도 또한 빠르다는 특징을 가지고 있습니다.

즉, 도커는 리눅스 컨테이너를 다루는 도구이며, 컨테이너 런타임이라고 합니다.

(위 그림의 Container Engine --> Docker Engine)

리눅스 컨테이너를 사용할 때 가장 핵심 기술 두 가지는 cgroup과 namespace 입니다.

cgroup
: control group의 약자로, Process 또는 Thread를 그룹화하여 관리하는 기능과 시스템 리소스(CPU, 메모리, 디스크 입출력 등)의 사용을 제한하는 기술입니다. 리눅스 컨테이너는 호스트의 리소스를 공유하여 사용하는데, 이때 cgroup을 사용하여 컨테이너가 사용하는 리소스의 양을 제한할 수 있습니다. 또한 같은 호스트에서 동작하는 서로 다른 컨터이너에 영향을 주지 않도록 막아주는 역할을 합니다.
namespace
: namespace는 직역하면 이름공간으로, 이 공간에 다수의 Object를 격리할 수 있습니다. 예를 들어 동일한 호스트에서 동일한 PID를 가칠 수 없지만 서로 다른 namespace에서는 동일한 PID를 가질 수 있습니다.

1-2. Docker 구조

https://docs.docker.com/get-started/images/docker-architecture.webp

Docker 클라이언트(docker)
: 클라이언트는 docker 커맨드를 통해 한 개 이상의 데몬과 통신할 수 있으며 사용자가 Docker와 상호작용할 수 있는 가장 우선적인 방법입니다.
Docker 데몬(dockerd)
: 다른 Docker 데몬과 통신하거나 Docker API 요청을 기다리고 이미지, 컨테이너, 네트워크, 볼륨 등을 관리하는 역할을 합니다.
Docker 레지스트리
: Docker 이미지 저장소. 기본적으로 Docker Hub라는 퍼블릭 레지스트리로 설정되어 있고 프라이빗 레지스트리도 생성할 수 있으며, Docker Datacenter(DDC)를 사용하는 경우, Docker Trusted Registy(DTR)로부터 pull, push 할 수 있습니다.

위 용어를 통해 그림의 흐름을 간략히 설명하면 다음과 같습니다.

- Clinet에서 Docker Command 실행

- Docker Host의 Daemon을 통해 동작하는데, Reigstry에 있는 images를 가져와 Container에게 전달(배포)

1-3. Docker 개념 및 용어 정리

Container(컨테이너)
: 위에서도 언급한 것처럼, 컨테이너는 앱의 각 구성 요소에 대해 격리된 프로세스입니다.
- 각 컨테이너에는 호스트 시스템에 사전 설치된 종속성에 의존하지 않고, 작동하는 데 필요한 모든 요소가 포함되어 있습니다.
- 컨테이너는 격리되어 실행되므로 호스트 및 기타 컨테이너에 미치는 영향이 최소화되어 애플리케이션의 보안이 향상됩니다.
- 각 컨테이너는 독립적으로 관리됩니다. 하나의 컨테이너를 삭제해도 다른 컨테이너에는 영향을 미치지 않습니다.
- 컨테이너는 어디에서나 실행될 수 있습니다. 실행되는 컨테이너는 On-Premise, Cloud 등 인프라 환경에 상관없이 동일한 방식으로 작동합니다.
Image(이미지)
: 컨테이너 이미지는 컨테이너를 실행하는 데 필요한 모든 파일, Binary, Library 및 구성을 포함하는 표준화된 패키지입니다. 다만, 이미지는 다음과 같은 특징이 있습니다.
- 이미지는 이미지 생성 후, 변경(수정)할 수 없습니다. 새 이미지를 만들거나 그 위에 변경 사항을 추가하는 것만 가능합니다. 즉, 기존 이미지를 기반으로 새로운 이미지를 생성하는 것을 의미합니다.
- 컨테이너 이미지는 레이어로 구성됩니다. 각 계층은 파일을 추가, 제거 또는 수정하는 일련의 파일 시스템 변경 사항을 나타냅니다.
  
  이 두 가지 특징을 기반으로 기존 이미지를 추가하거나 확장할 수 있습니다. 쉽게 표현하자면, Nginx 같은 기본 이미지(version 1.0)를 시작하고 추가 레이어를 추가하여 코드를 추가하여 새로운 이미지(version 2.0)를 만들 수 있습니다.
Registry(레지스트리)
: 말 그대로, 이미지를 저장하는 장소를 Registry라 말합니다. 저장소라는 용어와 구분하여 설명하자면 저장소는 레지스트리 내 관련 이미지의 모음이며, 레지스트리는 이미지를 저장하고 관리하는 상위 개념입니다.

개발을 위한 소스코드를 저장하고, 다른 사람들과 공유할 수 있는 Github와 같이 이미지를 저장하고 공유할 수 있는 Docker Hub 공용 레지스트리가 있으며, CSP 사에서 제공하는 Azure Container Registry, Amazon Elastic Container Registy 같은 Private 레지스트리 혹은 Harbor, JFrog Artifactory, GitLab 컨테이너 레지스트리 등이 있습니다.
Docker Compose
: Docker사의 권장 사항으로 각 컨테이너가 한 가지 작업을 수행하는 것입니다. 다만, 하나의 컨테이너에 여러 작업을 실행할 수 있는데, 바로 Docker Compose를 수행하는 방법입니다. 즉, 앱을 구성하는 서비스를 docker-compose.yml에 정의하여 격리된 환경에서 함께 실행할 수 있습니다.
Dockerfile
: Dockerfile은 컨테이너 이미지를 빌드하기 위한 지침을 제공합니다. 즉, 사용자가 이미지를 생성하는데, 해당 이미지를 통해 실행될 애플리케이션의 필요한 종속성을 포함합니다. 이는 단일 이미지를 빌드하기 위한 명세서이며, 나열된 명령어(텍스트)가 차례대로 수행되는데, 베이직 이미지, 환경 변수, 수행 명령어 등 이미지를 빌드하기 위한 명령어가 포함되어 있습니다.
```
FROM python:3.12
WORKDIR /usr/local/app

# Install the application dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# Copy in the source code
COPY src ./src
EXPOSE 5000

# Setup an app user so the container doesn't run as the root user
RUN useradd app
USER app

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8080"]
```
각 요소는 다음을 의미합니다.
- FROM <image> : 빌드가 확장될 기본 이미지를 지정합니다.
- WORKDIR <path> : 이 명령은 "작업 디렉터리" 또는 파일이 복사되고 명령이 실행될 이미지의 경로를 지정합니다.
- COPY <host-path> <image-path> : 이 명령은 빌더에게 호스트에서 파일을 복사하여 컨테이너 이미지에 넣으라고 지시합니다.
- RUN <command> : 이 명령은 빌더에게 지정된 명령을 실행하도록 지시합니다.
- ENV <name> <value> : 이 명령은 실행 중인 컨테이너가 사용할 환경 변수를 설정합니다.
- EXPOSE <port-number> : 이 명령은 이미지가 노출하려는 포트를 나타내는 이미지 구성을 설정합니다.
- USER <user-or-uid> : 이 명령은 모든 후속 명령에 대한 기본 사용자를 설정합니다.
- CMD ["<command>", "<arg1>"] : 이 지침은 이 이미지를 사용하는 컨테이너가 실행할 기본 명령을 설정합니다.

1-4. Docker 설치 및 구성 확인

: Azure VM(Ubuntu 22.04)에서 테스트 진행하였습니다.

다음 2부에서 자세히 설명하겠지만, Docker의 경우, 기본적으로 172.17.0.0/16 으로 설정(!변경 가능!)되어 있습니다.

실습에서(Default Network를 변경하지 않을 예정), 해당 대역과 중첩하게 된다면 컨테이너 통신이 되지 않기 때문에 유의하시기 바랍니다.

관련하여 보다 자세한 내용은 2편에서 진행할 예정입니다.

1-4-1. Docker Command

Docker에서 주로 사용되는 기본 명령어를 다음과 같이 정리하였습니다.

(보다 자세한 명령어는 공식 문서를 참고해 주세요!)

Docker Image	이미지 검색(From Docker Hub)	docker search {이미지 이름}
	이미지 다운로드	docker image pull {이미지명:태그}
	(다운로드 된) 이미지 조회	docker images
	이미지 빌드(Dockerfile)	docker build -t {이미지명:태그명} {dockerfile의 경로}
	이미지 삭제	docker image rm {이미지 ID or 이름}
	이미지 업로드	docker image push {이미지명:태그}
Docker Container	실행중인 컨테이너 목록 조회	docker ps
	컨테이너 생성 후, 실행	docker run -it --name {컨테이너 이름} -p {Host 포트} : {컨테이너 포트} {이미지 Repository}
	컨네이너 실행	docker start {이미지 이름:태그}
	컨테이너 중지	docker stop {컨테이너 ID or 이름}
	컨테이터 삭제	docker rm {컨테이너 ID or 이름}
	컨테이너 내부 접속	docker exec -it {컨테이너 ID 또는 이름} /bin/bash
Docker Compose	빌드	docker-compose build
	빌드 후, 실행	docker-compose up
	조회	docker-compose ps
	삭제	docker-compose down

1-4-2. Docker 설치

설치를 위한 apt 레포지토리 설정

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

패키지 설치

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

설치 확인
: 서비스 등록되어 Status(Active) 확

테스트 이미지 실행

이미지 목록 확인(조회)

1-4-3. Image Pull (다운로드) - Run

: 일반적으로 이미지를 Push/Pull 하는 단계에서 Docker Hub의 이미지를 사용하기 위해서넌 Login이 필요합니다.

다만, Push의 경우, Commit 을 위한 Docker Hub의 User ID와 저장소인 Repository 를 명령어에 사용하기 때문에 반드시 필요합니다. Pull의 경우, 이미지를 다운로드할 때 Docker Hub Login 없이 가능하지만, 기능의 일부 제약이 존재합니다.

앞서 설명한 것처럼, Docker Hub는 Public 합니다. 따라서 공개된 이미지나 Pull 가능하며, Push 가능합니다. 다만, 보안 위험 등 존재할 수 있는 사고를 줄이고자 공식 이미지(Official Imgae), 인증된 게시자(Verified Publisher) 이미지 혹은 자신이 만든 이미지를 사용하는 것을 권장합니다.

Trusted content

https://hub.docker.com/explore

명령어로 이미지 검색 시, 확인되는 OFFICIAL CHECK

Nginx 공식 이미지 다운로드
: 태그(tag)의 경우, 별도 지정하지 않는다면, 자동적으로 latest 기본값으로 사용됩니다.

Container 생성 및 실행
: Conatiner 생성 및 실행을 위해서는 docker run 명령어를 실행합니다. 해당 명령어는 이미지에서 새 컨테이너를 생성 및 실행하는 명령어입니다.
자주 사용되는 옵션과 예시는 다음과 같으며, 보다 자세한 옵션과 설명은 공식 문서를 참고해 주세요.
```
docker (container) run [OPTIONS] IMAGE [COMMAND] [ARG...]
```
- -d( --detach) : 컨테이너를 백그라운드에서 실행
- -p(--publish) : 호스트 포트와 컨테이너 포트 연결
- --name : 컨테이너 이름 지정
- -it(--interatice & --tty) : 컨테이너와 상호 작용하는 대화형 모드로 컨테이너 안에서 터미널을 사용하는 것처럼 명령어를 입력하고 출력을 확인 가능. 주로 컨테이너 내부에서 Shell에 접근하기 위해 사용
- -v(--volume) : 호스트의 디렉터리를 컨테이너의 디렉터리로 마운트
- -e(--env) : 환경 변수 설정
- --network : 특정 네트워크에 컨테이너 연결

# nginx 라는 이미지를 
# nginx_svr 라는 컨테이너 이름으로 백그라운드 실행
# 호스트 포트(8000)와 컨테이터 포트(80) 연결

sudo docker run -d --name=nginx_svr -p 8000:80 nginx

정상 실행 시, 컨테이터 ID 출력

현재 실행중인지 확인(Status : Up)

curl 명령어로 확인

인터넷에서 액세스 확인

*Azure VM에서 실행 중이므로 외부에서 해당 웹 페이지를 액세스 하기 위해서는 NSG의 인바운드 정책을 추가하여야 합니다.

1-4-4. Image Push (업로드)

: 이미지를 Docker Hub와 같은 레지스트리에 Push(업로드) 합니다.

위 단계에서 Pull(다운로드)한 nginx 이미지를 기반으로 Content를 일부 수정 후, 새로운 이미지를 생성하여 Docker Hub의 레지스트리에 Push 하는 과정입니다.

기존 이미지 수정
: HTML 파일 수정을 위해, 실행 중인 컨테이너 내부에 접근하여 Nginx가 바라보는 HTML 파일이 저장된 경로를 파악합니다.

sudo docker exec -it nginx_svr /bin/bash

# 이미지는 삽입하기 위해 컨테이너 내부에 디렉터리 생성
sudo docker exec nginx_svr mkdir -p /usr/share/nginx/html/images

# 이미지 파일을 컨테이너 내부로 복사
sudo docker cp ./IMG_4559.JPG\?type\=w773 nginx_svr:/usr/share/nginx/html/images/
> Successfully copied 29.2kB to nginx_svr:/usr/share/nginx/html/images/

컨테이너 내부 확인

NGINX에서 정적 파일을 제공할 때, 쿼리 문자열을 무시하고 파일 이름만 사용하기에 이미지를 제대로 서빙하기 위해서 파일 이름 변경

# 해당 이미지가 저장된 경로(./images/)에서 변경
mv 'IMG_4559.JPG?type=w773' IMG_4559.JPG

마지막으로 HTML 파일을 수정합니다.

# index.html 파일 수정
echo "<h1>Hello, Tak's World</h1><img src='images/IMG_4559.JPG?type=w773' alt='My Image'>" > /usr/share/nginx/html/index.html

새로운 이미지 정의하여 Docker Hub에 Push
: 위 단계까지 변경 작업한 사항을 반영하여 새로운 이미지를 생성하여 이미지를 Push 합니다. 레지스트리에 이미지를 Push 하기 위해서는 Docker Hub 로그인이 필수입니다.

수정한 내용을 새로운 Docker 이미지로 Commit 합니다.

변경 사항을 Docker Hub에 Push 하기 위해 login 합니다.

계정 정보를 기입하여 로그인을 시도합니다. warning이 표시되는 이유는 로그인 정보다 해당 호스트(서버)에 남기에 주의하라는 내용이며, 해당 테스트에서는 개인용 VM을 사용하기에 무시합니다.

이제, 해당 이미지를 본인의 저장소(레포지토리)에 Push 합니다.

명령어를 통해 레포지토리에 이미지를 Push 하기 위해서는 Docker hub에 레지스트리를 생성하여야 합니다.

로그인 후, [Repositories] - [Create repository] 를 선택합니다.

Namespace는 본인의 Account를 의미하며, 그 안에 포함되는 레포지토리 이름을 정의하여 생성합니다.

마지막으로 이미지를 Push 합니다.

# 이미지 식별 등 버전 관리를 위한 tag 명령어 사용
# 호스트(로컬)에 있는 'nginx_svr:modified001' 이미지를 Docker hub에 생성한 레포지토리 'tak2da/taks-blog:v1' 태그 설정

docker tag nginx_svr:modified001 tak2da/taks-blog:v1

**docker login을 통해 login 여부를 확인합니다.

# tag가 설정된 이미지를 Docker hub에 Push

docker push tak2da/taks-blog:v1

업로드 확인

해당 이미지를 통해 Pull을 시도하여 새로운 Container를 생성 및 실행할 수 있습니다.

1-4-5. Dockerfile - Build

: 이번에는 Docker Hub에서 만들어진 이미지 같은 표준화된 이미지나 빠른 배포를 위해 사용하는 Pull-Run 방식이 아닌, Dockerfile을 작성하여 커스터마이징 된 이미지를 빌드하고 실행하는 테스트를 해보겠습니다.

Python 애플리케이션인 Flask 를 Docker 컨테이너로 생성 및 실행하는 과정입니다.

(Python 및 Flask 설치의 경우, 해당 과정에서는 생략합니다. 간단하고 기본적인 Flask만 구성하시면 됩니다!)

의존성 파일 작성
: 설치한 Flask의 버전을 확인하여, 의존성을 명시한 requirement.txt 파일에 기입합니다.

Dockerfile 생성

# 베이스 이미지로 Python 3.9 사용
FROM python:3.9-slim

# 작업 디렉토리 설정
WORKDIR /usr/src/app

# 의존성 파일 복사 및 설치
COPY docker-flask/requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 파일 복사
COPY docker-flask/. .

# Flask 애플리케이션 실행
CMD ["python", "app.py"]

이미지 Build

# 이미지 빌드 시, tag(1.0) 적용
# docker-flask 는 이미지의 이름이고, .(마침표)는 Dockerfile이 있는 현재 디렉토리를 의미

docker build -t docker-flask:1.0 .

Docker 컨테이너 생성 및 실행

# docker-flask:1.0 라는 이미지를 
# flaks_svr 라는 컨테이너 이름으로 백그라운드 실행
# 호스트 포트(8080)와 컨테이터 포트(5000) 연결

sudo docker run -d --name=flaks_svr -p 8080:5000 docker-flask:1.0

*위 Nginx와 마찬가지로 외부(인터넷)에서 액세스 하기 위해서는 NSG 인바운드 정책에 8080 포트를 Open 해야 합니다.

지금까지 " #1 Docker 그리고 Docker Network 중 Docker" 에 대해 알아보았습니다.

다음 편에는 " #02 Docker Network "으로 돌아오겠습니다 (!!많관부!!)

여러분의 생각하는 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

Azure Route Table (Private Endpoint VS VNet Integration)

H-Y-E-N — Mon, 13 May 2024 14:49:07 +0900

안녕하세요. HYEN입니다.

Azure Route Table 공부하기 시리즈가 끝이 났으나, 마지막에 한 가지 제대로 마무리하지 않은 게 있어 오늘은 간단하게 그 부분에 대해 다뤄보고자 합니다.

지난 글 : https://with-cloud.tistory.com/52

Azure Route Table 공부하기 (5)

안녕하세요. HYEN입니다.시나리오 세 번째 글이자 이번 Route Table 공부하기의 마지막 글입니다~~~ 물론 마지막 시나리오의 내용 중 추가적으로 다룰 부분은 새로운 글로 적을 예정이지만!

with-cloud.tistory.com

Contents

지난 글에서 Spoke 대역 간 통신 시 Azure Firewall을 거쳐 가도록 구성해 보았습니다.

그중 Spoke 가상 머신 → Azure Firewall → Private Endpoint → Azure Database for PostgreSQL Flexible Server로 흐르는 트래픽 플로우와 Spoke 가상 머신 → Azure Firewall → Azure Database for PostgreSQL Flexible Server(VNet Integration)로 흐르는 트래픽 플로우 사이에 차이가 있다는 것을 발견하였습니다.

Private Endpoint와 연결된 PostgreSQL 서버의 경우

Azure Route Table에 경로 추가 (Destionation을 Private Endpoint subnet으로 하며, 다음 홉이 Azure Firewall인 경로 추가)
Azure Firewall에 VM이 배포된 subnet과 Private Endpoint용 subnet 간 통신이 가능하도록 Network 규칙 추가

이 두 가지 과정을 수행해 주면 접근이 되었습니다.

그러나 VNet Integration 된 PostgreSQL 서버의 경우 위의 두 과정을 거쳐도 접근이 되지 않았는데요.

그 이유는 하기와 같습니다.

Private Endpoint와 연결된 PostgreSQL 서버는 PaaS이기 때문에 가상 네트워크에 포함되지 않습니다.

또한 이러한 PostgreSQL 서버는 Microsoft 내 구독에 안전하게 배포되어 서비스됩니다.

Spoke 가상 머신에서 Azure Firewall을 거쳐 Private Endpoint를 통해서 PostgreSQL 서버에 접근하면 그 트래픽은 PostgreSQL 서버에서 Spoke 가상 머신으로 직접 전달되게 됩니다.

그렇기 때문에 Azure Route Table에 Spoke 가상 머신이 배포된 subnet을 destination으로 하는 경로를 추가해 주지 않아도 되는 것이죠.

반면 VNet Integration된 PostgreSQL 서버는 제 VNet 내에 배포되어 있기 때문에 사용자가 직접 모든 경로를 구성해 주어야 합니다.

따라서 Spoke 가상 머신에서 Azure Firewall을 거쳐 PostgreSQL에 접근하는 경로를 생성해 주었다면 PostgreSQL에서 Azure Firewall을 거쳐 Spoke 가상 머신으로 향하는 경로도 생성해 주어야 합니다.

지금부터 PostgreSQL 서버의 입장에서 Spoke 가상 머신으로 가기 위한 경로를 생성해 보도록 하겠습니다.

Spoke 경로 테이블에서 경로를 추가해야 합니다.

[경로 테이블] > [설정] 블레이드 > [경로] 탭 > [+ 추가]

그런 다음 다시 한번 접근을 시도해 봅니다.

경로를 추가해 주고 난 뒤에는 정상적으로 PostgreSQL 서버에 접근이 가능한 것을 확인할 수 있습니다.

이렇게 찜찜한 부분까지 싹 없애보았습니다!!

다음에는 더더욱 유익한 글로 돌아오도록 하겠습니다 ~~~

Azure Route Table 공부하기 (5)

H-Y-E-N — Fri, 10 May 2024 15:37:39 +0900

안녕하세요. HYEN입니다.

시나리오 세 번째 글이자 이번 Route Table 공부하기의 마지막 글입니다~~~

물론 마지막 시나리오의 내용 중 추가적으로 다룰 부분은 새로운 글로 적을 예정이지만!

드디어 마무리라니... 감회가 새롭습니다.

이전 글 : https://with-cloud.tistory.com/51

Azure Route Table 공부하기 (4)

안녕하세요. HYEN입니다. 시나리오 두 번째 글로 찾아왔습니다! 연휴와 개인 사정이 겹쳐 이전 글과 다소 시간 차가 있지만 양해 부탁드리며, 두 개의 시나리오에 대해 다뤄보았습니다. 이전 글

with-cloud.tistory.com

Contents

3. 시나리오

3.5 Spoke VM → Spoke 대역의 PostgreSQL

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

현재 Spoke 가상 네트워크 내에서의 통신은 Azure Firewall을 거치지 않고 있습니다.

경로 테이블의 유효 경로를 확인해 보겠습니다.

Spoke 가상 머신이 배포된 서브넷의 유효 경로는 상기 스크린샷과 같습니다.

다음 홉이 가상 네트워크인 경로가 활성화되어 있습니다.

즉, Spoke 가상 네트워크 내에서는 Azure Firewall을 거치지 않고 가상 네트워크 내에서 각 서브넷으로 라우팅이 되게 되는 것이죠.

가상 머신의 [연결 문제 해결] 탭에서도 다음 홉 형식을 확인할 수 있습니다.

Spoke 가상 머신에서 VNet Integration된 Azure Database for PostgreSQL Flexible Server로 향하는 트래픽에 대한 다음 홉을 테스트해 보았습니다.

상기 스크린샷과 같이 사용자 지정 경로를 따르는 것이 아니라 default로 정의된 시스템 경로를 따르는 것을 알 수 있습니다.

그렇다면 Private Endpoint와 연결된 Azure Database for PostgreSQL Flexible Server는 어떨까요?

경로 테이블의 유효 경로에는 하기와 같이 InterfaceEndpoint 즉 Private Endpoint를 다음 홉으로 하는 시스템 경로가 존재하는 것을 알 수 있습니다.

가상 머신의 [연결 문제 해결] 탭에서도 Private Endpoint의 Private IP를 목적지로 설정하여 다음 홉에 대한 진단을 실행하면 하기와 같이 트래픽이 다음 홉이 PrivateEndpoint인 시스템 경로를 따르는 것을 알 수 있습니다.

Hub와 통신할 때에는 Azure Firewall을 거치고 Spoke 내에서는 각 서브넷끼리 직접 통신할 수 있도록 구성이 잘 되어 있음을 알 수 있습니다.

3.6 Spoke VM → Azure Firewall → Spoke 대역의 PostgreSQL

그렇다면, Spoke 내에서의 통신도 Azure Firewall을 거쳐가게 할 수 있을까요?

답은 YES입니다.

앞서 Azure의 경로 테이블은 Longest Prefix Match 알고리즘을 따른다고 했는데요.

현재 Spoke 내에서의 통신에 대한 경로는 다음과 같습니다.

이보다 더 대역이 작은 사용자 지정 경로를 지정하여 다음 홉 유형을 가상 어플라이언스로 지정해 준다면 Spoke 대역 내에서의 통신도 Azure Firewall을 거치게 될 것입니다.

먼저, Spoke 가상 머신에서 Azure Firewall을 거쳐, Private Endpoint와 연결된 Azure Database for PostgreSQL Flexible Server에 접근하도록 테스트해보겠습니다.

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

이를 위해 Spoke 경로 테이블에 서브넷 단위의 사용자 지정 경로를 추가해 줍니다.

[경로 테이블] > [설정] 블레이드 > [경로] 탭 > [+ 추가]

위의 경로를 생성하면, 해당 경로 테이블과 연결된 서브넷들 중 대상 IP 주소로 가려고 하는 트래픽이 있을 경우 이 트래픽은 Azure Firewall로 보내지게 됩니다.

그렇게 되면 Azure Firewall과 연결된 방화벽 정책에 연결된 규칙에 기반하여 트래픽이 라우팅 되게 됩니다.

따라서 Azure Firewall로 보내진 트래픽이 목적지를 찾아갈 수 있도록 이번에는 방화벽 정책에 Network 규칙을 생성해 주겠습니다.

먼저 기존 규칙 컬렉션 (Hub-Spoke 간 통신 관련)과 다른 새로운 규칙 컬렉션을 생성합니다. ([설정] 블레이드 > [규칙 컬렉션] 탭 > [+ Add] > [Rule Collection])

설정이 완료되었으니 가상 머신의 [연결 문제 해결] 탭에서 연결 진단을 통해 다음 홉에 대해 확인해 보겠습니다.

진단 결과 다음 홉 유형이 가상 어플라이언스(Azure Firewall)로 트래픽이 시스템 경로가 아닌 방금 전 지정해 준 사용자 지정 경로를 따라 흐르는 것을 알 수 있습니다.

Spoke 가상 머신에서도 PostgreSQL 서버에 접근해 보겠습니다.

잘 접근되는 것을 알 수 있습니다.

다음은 Spoke 가상 머신에서 Azure Firewall을 거쳐, VNet Integration 된 Azure Database for PostgreSQL Flexible Server에 접근하도록 테스트해보겠습니다.

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

이를 위해 Spoke 경로 테이블에 서브넷 단위의 사용자 지정 경로를 추가해 줍니다.

[경로 테이블] > [설정] 블레이드 > [경로] 탭 > [+ 추가]

다음으로 Azure Firewall에 가상 머신 ↔ Azure Database for PostgreSQL Flexible Server (VNet Integration) 간 통신에 필요한 Network 규칙을 추가해 줍니다.

설정이 완료되었으니 가상 머신의 [연결 문제 해결] 탭에서 연결 진단을 통해 다음 홉에 대해 확인해 보겠습니다.

Spoke 가상 머신에서도 PostgreSQL 서버에 접근해 보겠습니다.

Private Endpoint와 연결된 PostgreSQL 서버와는 다르게 접근이 안 되는 것을 알 수 있습니다.

이 이유에 대해서는 다음 글에서 다루도록 하겠습니다!

긴 글 읽어주셔서 감사합니다!

Azure Route Table 공부하기 (4)

H-Y-E-N — Thu, 9 May 2024 14:36:47 +0900

안녕하세요. HYEN입니다.

시나리오 두 번째 글로 찾아왔습니다!

연휴와 개인 사정이 겹쳐 이전 글과 다소 시간 차가 있지만 양해 부탁드리며, 두 개의 시나리오에 대해 다뤄보았습니다.

이전 글 : https://with-cloud.tistory.com/50

Azure Route Table 공부하기 (3)

안녕하세요. HYEN입니다. 드디어 시나리오 별 UDR을 구성하는 테스트에 대한 글을 쓰게 되었습니다. 물론, 이 글도 길어져서 시나리오를 두, 세 개씩 쪼개어 시리즈 물로 작성될 예정입니다.

with-cloud.tistory.com

Contents

3. 시나리오

3.3 Hub VM → Azure Firewall → PostgreSQL (VNet Integration)

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

이를 위해 3.2 에서 수행했던 과정을 동일하게 진행합니다.

그 전에 Azure Database for PostgreSQL Flexible Server에 대한 Private DNS Zone에 Hub 대역의 가상 네트워크를 연결해 주어야 합니다.

privatelink.postgres.database.azure.com이라는 이름의 Private DNS Zone을 찾아 [설정] 블레이드의 [가상 네트워크 링크] 탭을 클릭합니다. [+ 추가] 버튼을 클릭하여 가상 네트워크 링크를 진행합니다.

링크 이름과 연결할 가상 네트워크(Hub VNet)를 선택한 후 [확인] 버튼을 클릭하여 링크 생성을 마무리합니다.

그 다음, 각 대역의 사용자 지정 경로에 서브넷을 연결하고 경로를 추가합니다.

[Hub 대역의 경로 테이블]

Hub 가상 머신이 배포되어 있는 서브넷은 이미 Hub 대역의 경로 테이블과 연결되어 있기 때문에 서브넷 연결 과정은 진행하지 않아도 됩니다.

경로 역시 이미 0.0.0.0/0, 즉 모든 트래픽에 대해 Azure Firewall로 라우팅되도록 구성되어 있기 때문에 해당 과정은 진행하지 않아도 됩니다.

[Spoke 대역의 경로 테이블]

[설정] 블레이드 > [서브넷] 탭 > [+ 연결]

Spoke 대역에서 Hub 가상 머신으로 가기 위한 경로는 이미 구성되어 있기 때문에 경로는 추가로 생성하지 않아도 됩니다.

경로를 추가한 후 방화벽 정책으로 이동하여 Network 규칙을 생성합니다.

[설정] 블레이드 > [규칙 컬렉션] 탭에서 Network 규칙 컬렉션을 선택합니다. (규칙을 한번에 추가하기 위함입니다.)

Hub ↔ Postgre01(VNet Integration) 연결을 위해 Network 규칙을 생성해 줍니다.

From-Hub-to-Postgre01 규칙만 추가하면 Hub 가상 머신에서 Azure Firewall을 거쳐 Postgre01까지 가는 트래픽만 허용됩니다. 따라서, From-Postgre01-to-Hub 규칙을 추가해서 Postgre01에서 Azure Firewall을 거쳐 Hub 가상 머신으로 가는 트래픽이 허용될 수 있도록 해야 합니다.

규칙 생성이 완료된 후, Hub 가상 머신에서 Postgre01에 접근해 보겠습니다.

접근하기 위한 명령어는 Azure Database for PostgreSQL Flexible Server의 [설정] 블레이드 > [연결] 탭의 "브라우저에서 또는 로컬에서 연결" 섹션을 확인하면 됩니다.

(아키텍처 상에는 VNet Integration된 Azure Database for PostgreSQL Flexible Server 명이 postgre-hyein-01로 되어 있으나 실제 리소스 생성 명은 postgre-hyein-02인 점 양해 부탁드립니다. )

명령어를 복사하여 Hub 가상 머신에서 실행합니다.

접근이 잘 되는 것을 확인할 수 있습니다.

가상 머신의 [도움말] > [연결 문제 해결] 탭에서 다음 홉을 확인하여 트래픽이 예상한 대로 흐르는지 확인해 보도록 하겠습니다.

이를 확인하기 위해서는 먼저 IP 주소 확인이 필요한데요.

privatelink.postgres.database.azure.com이라는 이름의 Private DNS Zone으로 이동하여 레코드를 확인합니다.

해당 IP 주소를 복사해 둡니다.

다시 [연결 문제 해결] 탭으로 이동하여 대상 주소 섹션 중 "URI, FQDN 또는 IP 주소" 칸에 복사해 둔 IP 주소를 입력합니다.

진단 테스트 결과 현재 다음 홉이 VirtualNetworkPeering으로 지정되어 있는 것을 확인할 수 있습니다.

이는 테스트 시나리오대로 트래픽이 흐르고 있지 않은 것을 의미합니다.

무엇이 문제일까요?

답은 경로에 있습니다.

Azure는 Longest Prefix Match 알고리즘을 따르기 때문에 접두사가 더 긴, 즉 주소 대역이 더 작은 경로를 따르게 됩니다.

현재 udr-hub-hyein이라는 경로 테이블의 유효 경로 테이블은 하기와 같습니다.

0.0.0.0/0 즉 모든 트래픽에 대한 다음 홉이 Azure Firewall로 지정되어 있지만 그 보다 더 작은 범위인 10.100.0.0/24 즉, Spoke 대역의 가상 네트워크에 대한 다음 홉이 VNet 피어링으로 지정되어 있기 때문에 트래픽은 Azure Firewall이 아니라 VNet Peering이 다음 홉인 경로를 따라가고 있음을 알 수 있습니다.

따라서, 경로 테이블에 Spoke 가상 네트워크 대역보다 작거나 동일한 크기의 대역에 대한 경로를 명시해 주어야 합니다.

[경로 테이블] > [설정] 블레이드 > [경로] 탭에서 경로를 추가해 줍니다.

경로를 추가한 후 다시 연결 진단을 실행하면 이번에는 트래픽이 하기와 같이 다음 홉 유형이 Azure Firewall인 경로를 따라 흐르는 것을 확인할 수 있습니다.

3.4 Hub VM → Azure Firewall → PostgreSQL (Private Endpoint)

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

경로 테이블을 구성하기에 앞서 먼저 서브넷의 "프라이빗 엔드포인트에 대한 네트워크 정책"을 활성화 시켜야 합니다.

이 정책은 Private Endpoint에 대해 사용자 정의 경로 및 네트워크 보안 그룹과 같은 네트워크 정책을 사용하고자 할 경우 활성화 시켜야 하는 정책입니다.

단, 해당 설정은 서브넷의 Private Endpoint에만 적용되며 서브넷의 모든 Private Endpoint에 영향을 줍니다.

[가상 네트워크] > [설정] 블레이드 > [서브넷] 탭에서 해당 정책을 활성화할 서브넷을 선택합니다.

그 후, 가장 하단에 있는 프라이빗 엔드포인트에 대한 네트워크 정책 탭에서 [경로 테이블]을 선택합니다.

[Hub 대역의 경로 테이블]

Hub 가상 머신이 배포되어 있는 서브넷은 이미 Hub 대역의 경로 테이블과 연결되어 있기 때문에 서브넷 연결 과정은 진행하지 않아도 됩니다.

경로 역시 이미 0.0.0.0/0, 즉 모든 트래픽에 대해 Azure Firewall로 라우팅되도록 구성되어 있기 때문에 해당 과정은 진행하지 않아도 됩니다.

[Spoke 대역의 경로 테이블]

[설정] 블레이드 > [서브넷] 탭 > [+ 연결]

Spoke 대역에서 Hub 가상 머신으로 가기 위한 경로는 이미 구성되어 있기 때문에 경로는 추가로 생성하지 않아도 됩니다.

경로를 추가한 후 방화벽 정책으로 이동하여 Network 규칙을 생성합니다.

[설정] 블레이드 > [규칙 컬렉션] 탭에서 Network 규칙 컬렉션을 선택합니다. (규칙을 한번에 추가하기 위함입니다.)

From-Hub-to-Postgre02 규칙의 대상에는 Postgre02와 연결된 Private Endpoint가 배포되어 있는 서브넷의 대역을 입력해 주면 됩니다.

3.3 과정과 동일하게 Postgre02에 접근해 보겠습니다.

접근이 잘 되는 것을 확인할 수 있습니다.

다음으로 가상 머신 쪽에서 연결 진단을 실행해 보겠습니다.

다음 홉이 Azure Firewall인 경로로 트래픽이 잘 흐르는 것을 확인할 수 있습니다.

이렇게 Hub 가상 머신에서 Spoke 대역으로 접근하는 부분에 대한 테스트를 마무리하였습니다.

다음 글에서는 Spoke 대역 간의 통신에 대해 다뤄보도록 하겠습니다.

Azure Route Table 공부하기 (3)

H-Y-E-N — Thu, 2 May 2024 15:50:19 +0900

안녕하세요. HYEN입니다.

드디어 시나리오 별 UDR을 구성하는 테스트에 대한 글을 쓰게 되었습니다.

물론, 이 글도 길어져서 시나리오를 두, 세 개씩 쪼개어 시리즈 물로 작성할 예정입니다.

지난 글 : https://with-cloud.tistory.com/49

Azure Route Table 공부하기 (2)

안녕하세요. HYEN입니다. 지난 글에서는 Azure Route Table의 개념과 동작 로직에 대해 알아보았습니다. 지난 글 : https://with-cloud.tistory.com/47 Azure Route Table 공부하기 (1)안녕하세요. HYEN입니다.어제,

with-cloud.tistory.com

Contents

3. 시나리오

테스트할 시나리오는 총 6개로 하기와 같습니다.

Local PC → Azure Firewall → Hub VM (DNAT Rule)
Hub VM → Azure Firewall → Spoke VM
Hub VM → Azure Firewall → PostgreSQL (VNet Integration)
Hub VM → Azure Firewall → PostgreSQL (Private Endpoint)
Spoke VM → Azure Firewall → Spoke 대역의 PostgreSQL
Spoke VM → Spoke 대역의 PostgreSQL

3.1 Local PC → Azure Firewall → Hub VM (DNAT Rule)

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

이를 위해서는 Azure Firewall에서 DNAT 규칙을 생성해 주어야 합니다.

즉, Local PC에서 Hub VM에 접근하기 위해 Azure Firewall의 공인 IP 주소를 입력하면 해당 주소가 Hub 가상 머신의 사설 IP로 DNAT 될 수 있도록 규칙을 생성해야 하는 것이죠.

먼저, 가상 머신과 공인 IP를 분리합니다.

[가상 머신] > [네트워킹] 블레이드 > [네트워크 설정] 탭에서 네트워크 인터페이스를 클릭합니다.

그 후 [IP 구성] 탭에서 IP 구성 편집을 위해 ipconfig1을 클릭합니다.

하기와 같이 [공용 IP 주소 설정] 섹션의 "공용 IP 주소 연결" 항목의 체크 박스를 해제하거나, 해제가 되어 있는지 확인합니다.

이 과정이 완료되면 가상 머신의 [개요] 탭에서 공용 IP 주소에 대한 값이 "-"인 것을 확인할 수 있습니다.

다음으로, Azure Firewall과 연결된 방화벽 정책으로 이동하여 DNAT 규칙을 생성합니다.

규칙 컬렉션이 없다면 규칙 컬렉션을 먼저 생성해 주어야 합니다.

상기 스크린샷과 같이 규칙 컬렉션과 규칙을 생성합니다.

원본 : Local PC의 공인 IP 주소
대상 포트 : 22 (원하는 포트를 지정해 줘도 됩니다.)
대상 (방화벽 IP 주소) : Azure Firewall의 공인 IP 주소
변환된 주소 또는 FQDN : Hub 가상 머신의 사설 IP 주소
번역된 포트 : 실제로 해당 서버에 접근하기 위해 열려 있는 포트

실제로 접근이 되는지 테스트해 보겠습니다. (ssh hyein@{Azure Firewall의 공인 IP 주소})

상기 스크린샷과 같이 방화벽의 공인 IP 주소를 사용하여 Hub 가상 머신에 접속할 수 있는 것을 알 수 있습니다.

3.2 Hub VM → Azure Firewall → Spoke VM

시나리오 아키텍처 및 구성하고자 하는 트래픽 플로우는 다음과 같습니다.

다음은 Hub 가상 머신에서 Azure Firewall을 지나 Spoke 가상 머신에 접근하는 테스트를 해보겠습니다.

현재 Hub 가상 네트워크와 Spoke 가상 네트워크에는 VNet Peering이 구성되어 있습니다.

그렇기 때문에 Hub 가상 머신과 Spoke 가상 머신이 배포되어 있는 각 서브넷의 경로 테이블에는 상대 서브넷에 대해, 다음 홉이 VNet Peering인 경로를 가지고 있습니다.

따라서 가상 네트워크 간 직접 통신이 아닌, Azure Firewall 쪽으로 트래픽이 꺾이는 사용자 지정 경로를 구성해야 합니다.

지금부터는 사용자 지정 경로를 구성해 보겠습니다.

[Hub 대역의 경로 테이블]

[설정] 블레이드 > [서브넷] 탭 > [+ 연결]

Hub 가상 머신이 배포되어 있는 서브넷을 선택하여 경로 테이블과 연결합니다.

[설정] 블레이드 > [경로] 탭 > [+ 추가]

Hub 가상 머신이 Spoke 가상 머신으로 가기 위한 경로를 생성해 줍니다.

대상 주소는 Spoke 가상 머신이 배포되어 있는 서브넷 대역을 입력해 주면 됩니다.

다음 홉 형식을 [가상 어플라이언스]로 지정하고 다음 홉 주소에는 Azure Firewall의 사설 IP 주소를 입력합니다.

[Spoke 대역의 경로 테이블]

[설정] 블레이드 > [서브넷] 탭 > [+ 연결]

Spoke 가상 머신이 배포되어 있는 서브넷을 선택하여 경로 테이블과 연결합니다.

[설정] 블레이드 > [경로] 탭 > [+ 추가]

Spoke 가상 머신이 Hub 가상 머신으로 가기 위한 경로를 생성해 줍니다.

대상 주소는 Hub 가상 머신이 배포되어 있는 서브넷 대역을 입력해 주면 됩니다.

다음 홉 형식을 [가상 어플라이언스]로 지정하고 다음 홉 주소에는 Azure Firewall의 사설 IP 주소를 입력합니다.

또한 Spoke 가상 네트워크 대역을 대상 주소로 가지는 경로를 하나 더 추가해 줍니다.

이 경로 또한 다음 홉 형식을 "가상 어플라이언스"로 선택하고 다음 홉 주소를 Azure Firewall의 사설 IP로 지정해 줍니다.

이 역시 Longest Prefix Match 알고리즘을 따르는 Azure 경로 테이블의 동작 방식으로 인해 추가가 필요합니다.

경로를 추가하였으니 접근이 제대로 되는지 확인해 보겠습니다. (Hub 가상 머신 → Spoke 가상 머신)

Hub 가상 머신에서 ssh hyein@10.100.0.4를 입력하여 Spoke 가상 머신에 접근합니다.

그 결과, 하기와 같이 접근이 불가한 것을 알 수 있습니다.

왜 그런 걸까요?

현재 Hub 가상 머신은 Spoke 가상 머신에 도달하기 위해 Azure Firewall로 이동합니다.

이때 Azure Firewall은 Spoke 가상 머신에 해당 트래픽을 보낼 수 있을까요?

답은 NO입니다.

그 이유는 아직 Azure Firewall에 해당 트래픽에 대한 네트워크 규칙이 생성되어 있지 않기 때문입니다.

트래픽이 Azure Firewall까지 도착했지만 Spoke 가상 머신으로 트래픽이 도달하기 위한 규칙이 현재 Azure Firewall에는 없습니다.

지금부터는 방화벽 정책에서 네트워크 규칙을 생성해 보도록 하겠습니다.

상기 스크린샷과 같이 규칙 컬렉션과 규칙을 생성합니다.

Hub 대역을 원본(Source)으로 하는 규칙과 Spoke 대역을 원본(Source)으로 하는 규칙, 이렇게 두 가지의 규칙을 생성합니다.

(이렇게 해야 Spoke 가상 머신에서 Hub 가상 머신으로도 접근이 가능하기 때문입니다.)

규칙 생성이 완료된 후, 다시 한번 Hub 가상 머신에서 Spoke 가상 머신에 접속해 보겠습니다.

이전과 다르게 Spoke 가상 머신에 접근이 가능한 것을 확인할 수 있습니다.

[경로 테이블] > [도움말] > [유효 경로] 탭에서도 하기 스크린샷과 같이 사용자 지정 경로가 생성된 것을 확인할 수 있습니다.

나머지 시나리오에 대한 테스트 글도 후다닥 정리해서 돌아오겠습니다.

Azure Route Table 공부하기 (2)

H-Y-E-N — Tue, 30 Apr 2024 16:27:28 +0900

안녕하세요. HYEN입니다.

지난 글에서는 Azure Route Table의 개념과 동작 로직에 대해 알아보았습니다.

지난 글 : https://with-cloud.tistory.com/47

Azure Route Table 공부하기 (1)

안녕하세요. HYEN입니다.어제, Azure Route Table을 사용하여 경로를 라우팅하는 테스트를 진행해 보았는데요. 네트워크도 어려운데 Route Table에 UDR을 정의해서 원하는 대로 통신이 되게 하려고 하

with-cloud.tistory.com

이번 글에서는 시나리오 별 트래픽을 라우팅하는 방법에 대한 테스트를 진행할 환경을 구성하는 과정에 대해 다뤄보도록 하겠습니다. (다음 글부터 시나리오 별 테스트를 진행해 보도록 하겠습니다.)

Contents

2. 환경 구성

본 테스트를 위해 구성해야 하는 환경은 하기와 같습니다.

Hub, Spoke 가상 네트워크 생성
Hub, Spoke 간 가상 네트워크 피어링 구성
Azure Firewall 배포
경로 테이블 (Hub, Spoke에 각각 하나씩) 배포
가상 머신 (Hub, Spoke에 각각 하나씩) 배포
Azure Database for PostgreSQL Flexible Server (VNet Integration / Private Endpoint) 배포

차례대로 구성해 보도록 하겠습니다.

2.1 Hub, Spoke 가상 네트워크 생성

※ Hub용 리소스 / Spoke용 리소스 리스트를 보다 쉽게 확인하기 위해 리소스 그룹을 분리하여 생성하겠습니다.※

첫 번째로 Hub, Spoke 가상 네트워크를 생성합니다.

[Hub 대역]

[기본 사항] 탭

[보안] 탭
- [보안] 탭에서 Azure Firewall을 생성할 수 있지만 별도로 배포를 진행할 예정이기 때문에 해당 과정은 생략합니다.

[IP 주소] 탭

Hub 가상 네트워크에서 필요한 서브넷은 상기 스크린샷에서 볼 수 있듯이 2개입니다. (VM용, Azure Firewall용)

Azure Firewall용 서브넷을 생성하는 방법은 하기와 같습니다.

서브넷 용도 중 [Azure Firewall]을 선택합니다.

/26만큼의 주소 범위가 필요하므로 적당한 시작 주소를 입력합니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [가상 네트워크] 생성을 마무리합니다.

[Spoke 대역]

[기본 사항] 탭

[IP 주소] 탭

Spoke 가상 네트워크에서 필요한 서브넷은 상기 스크린샷에서 볼 수 있듯이 3개입니다. (VM용, Private Endpoint용, Azure Database for PostgreSQL에 대한 위임된 서브넷 용)

해당 탭에서 snet-postgre-dedicated 서브넷을 Azure Database for PostgreSQL에 위임할 수 있으나 해당 리소스를 생성할 때 구성하도록 하겠습니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [가상 네트워크] 생성을 마무리합니다.

2.2 Hub, Spoke 간 가상 네트워크 피어링 구성

생성한 두 가상 네트워크 간 가상 네트워크 피어링을 구성합니다.

[가상 네트워크] > [설정] > [피어링] 탭 > [+ 추가]

[피어링 추가] 페이지

피어링 이름과, 피어링 할 네트워크를 선택한 후 [추가] 버튼을 클릭하여 피어링 구성을 완료합니다.

상기 스크린샷과 같이 피어링 상태가 "연결됨"일 경우 구성이 제대로 된 것입니다.

2.3 Azure Firewall 배포

Hub 대역에 Azure Firewall을 배포합니다.

[기본 사항] 탭

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [Azure Firewall] 배포를 마무리합니다.

2.4 경로 테이블 배포

사용자 지정 경로를 구성하기 위해 우선 Route Tables를 배포합니다.

Hub, Spoke 각 대역에 한 개씩 배포합니다.

[Hub 대역]

[기본] 탭

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [경로 테이블] 생성을 마무리합니다.

[Spoke 대역]

[기본] 탭

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [경로 테이블] 생성을 마무리합니다.

여기서, "게이트웨이 경로 전파"에 대해 좀 더 알아보겠습니다.

게이트웨이 경로 전파란?

VPN이나 ExpressRoute를 통해 들어온 트래픽이 Azure 내 리소스와 통신할 때 사용합니다.
해당 설정이 활성화되어 있으면 라우트 테이블을 자동으로 전달해 주기 때문에 VPN이나 ExpressRoute를 통해 Azure의 네트워크로 갈 때, 이 경로에 대해서 별도의 구성을 하지 않아도 됩니다.
해당 설정이 비활성화되어 있을 경우, 도달해야 하는 목적지에 대한 정보가 자동으로 제공되지 않기 때문에 직접 경로에 대한 구성을 해 주어야 합니다.

2.5 가상 머신 배포

가상 머신을 배포한 후에 Azure Database for PostgreSQL에 접근할 수 있도록 psql (PostgreSQL과 상호 작용하기 위한 명령줄 도구)를 설치합니다.

※ 가상 머신 배포 과정은 Hub용, Spoke용 모두 동일합니다. (리소스 그룹 명, 가상 네트워크/서브넷 대역만 다르게 지정)
본 테스트는 Hub 기준으로 작성하도록 하겠습니다.※

[기본 사항] 탭

[네트워킹] 탭

공용 IP의 경우 psql 설치를 위해 Hub용 가상 머신에만 잠시 attach 합니다. (추후, Azure Firewall 규칙 및 UDR 구성 시 공용 IP는 필요하지 않습니다.)

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [가상 머신] 생성을 마무리합니다.

위와 같은 방식으로 Spoke용 가상 머신도 생성합니다. (공용 IP는 붙이지 않습니다.)

가상 머신 배포가 완료된 후에는 psql 설치를 진행합니다. (Hub, Spoke용 가상 머신 모두에 설치합니다.)

psql 설치를 위해 Hub용 가상 머신에 접근합니다. (ssh hyein@{hub용 가상 머신 공용 IP})

https://www.postgresql.org/download/ 페이지로 이동하여 Linux > Ubuntu를 선택한 후 해당 페이지의 install 과정을 따라 psql 설치를 진행합니다.

Spoke용 가상 머신에 접근하여 상기 과정을 진행합니다. (ssh hyein@10.100.0.4)

2.6 Azure Database for PostgreSQL Flexibel Server 배포

환경 구성의 마지막 단계로 Azure Database for PostgreSQL Flexibel Server를 배포합니다.

네트워킹 옵션이 각각 VNet Integration, Private Endpoint인 Azure Database for PostgreSQL Flexibel Server를 배포해 보겠습니다.

Private Endpoint와 VNet Integration에 대한 설명은 하기 글을 참고해 주세요!

https://with-cloud.tistory.com/48

프라이빗 엔드포인트 VS VNET 통합 (프라이빗 액세스)

안녕하세요. HYEN입니다.라우팅 테스트를 하는 중 Azure Database for PostgreSQL Flexible Server를 생성할 때 선택할 수 있는 네트워킹 옵션에 대해 정리해 봐야겠다는 생각이 들어 이번 글을 작성하게 되었

with-cloud.tistory.com

[Private Endpoint]

[기본] 탭

[네트워킹] 탭

[공용 액세스] 섹션에서 "공용 IP 주소를 사용하여 인터넷을 통해 이 리소스에 공용 액세스 허용"에 대한 체크 박스를 해제합니다.

그다음 하단의 [프라이빗 엔드포인트] 섹션에서 [+ 프라이빗 엔드포인트]를 클릭하여 프라이빗 엔드포인트 생성을 진행합니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [Azure Database for PostgreSQL Flexible Server] 생성을 마무리합니다.

[만들기] 버튼을 클릭하면 하기와 같은 창이 뜹니다. [방화벽 규칙 없이 서버 만들기] 버튼을 클릭하여 생성을 진행합니다. (이 부분은 구성할 필요가 없습니다.)

다음은 VNet Integration 된 Azure Database for PostgreSQL Flexible Server를 배포해 보겠습니다.

[VNet Integration (Private Access)]

[기본] 탭

[네트워킹] 탭

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [Azure Database for PostgreSQL Flexible Server] 생성을 마무리합니다.

이상으로 이번 글을 마무리 하도록 하겠습니다!

다음에는 시나리오별 테스트하는 글로 만나요 !

프라이빗 엔드포인트 VS VNET 통합 (프라이빗 액세스)

H-Y-E-N — Tue, 30 Apr 2024 15:49:16 +0900

안녕하세요. HYEN입니다.

라우팅 테스트를 하는 중 Azure Database for PostgreSQL Flexible Server를 생성할 때 선택할 수 있는 네트워킹 옵션에 대해 정리해 봐야겠다는 생각이 들어 이번 글을 작성하게 되었습니다.

가상 네트워크에 배포할 수 있는 Azure 서비스는 다양하며 리소스마다 VNET 통합도 성격이 조금씩 다르기 때문에 하기 링크를 참고하시어 각 리소스에 대한 자세한 설명을 확인하시기 바랍니다.

참고 링크 : https://learn.microsoft.com/ko-kr/azure/virtual-network/virtual-network-for-azure-services#services-that-can-be-deployed-into-a-virtual-network

Azure 서비스에 대한 가상 네트워크

전용 Azure 서비스를 가상 네트워크에 배포하는 방법과 해당 배포에서 제공하는 기능을 알아봅니다.

learn.microsoft.com

※ 본 글은 Azure Database for PostgreSQL Flexible Server의 네트워킹 옵션에 대해 다루고 있습니다.※

Contents

1. 프라이빗 엔드포인트 (Private Endpoint)

배포
- PaaS 서비스를 위해 가상 네트워크에 NIC를 생성합니다.
- 여러 가상 네트워크에 하나의 PaaS 서비스를 위한 프라이빗 엔드포인트를 생성할 수 있습니다.

특징
- PaaS 서비스에 대한 인바운드 연결만 지원합니다. 따라서 PaaS 서비스는 가상 네트워크의 리소스에 액세스 할 수 없습니다.
- 프라이빗 엔드포인트 사용 시 가상 네트워크, 피어링된 가상 네트워크, VPN 또는 ExpressRoute를 사용하는 온프레미스 환경 등에서 PaaS 리소스에 연결이 가능합니다.
- Azure 서비스에 프라이빗하게 액세스할 수 있는 IP 주소를 제공하지만 프라이빗 엔드포인트를 구성한다고 공용 네트워크 액세스가 반드시 제한되는 것은 아닙니다. 각 리소스의 [네트워킹] 탭에서 "공용 액세스" 사용을 비활성화하는 작업이 추가로 필요할 수 있습니다.
- 프라이빗 엔드포인트가 배포되어 있는 서브넷에 대해 [프라이빗 엔드포인트에 대한 네트워크 정책]을 활성화할 경우, NSG(네트워크 보안 그룹), UDR(사용자 정의 경로), ASG(애플리케이션 보안 그룹)를 지원합니다.

네트워크 플로우

주황색 선의 경우 온프레미스에서 VPN이나 ExpressRoute를 통해 Azure 대역으로 들어가서 프라이빗 엔드포인트를 거쳐 PaaS 서비스에 진입하는 트래픽을 나타 냅니다.
파란색 선의 경우 Azure의 가상 네트워크 내에 배포된 가상 머신에서 프라이빗 엔드포인트를 거쳐 PaaS 서비스에 진입하는 트래픽을 나타 냅니다. (이 경우 가상 머신이 배포된 가상 네트워크와 PaaS 서비스가 존재하는 가상 네트워크 간 피어링이 구성되어 있어야 합니다.)
검은색 선의 경우 인터넷을 통해 PaaS 서비스에 접근하는 트래픽을 나타냅니다. 프라이빗 엔드포인트를 생성한다고 해서 인터넷을 통해 액세스할 수 있는 퍼블릭 엔드포인트가 사라지는 것은 아니며 PaaS 서비스의 방화벽 정책에서 해당 부분을 허용/차단함에 따라 액세스가 가능/불가능합니다.

2. VNET 통합 (VNET Integration), 프라이빗 액세스 (Private Access)

배포
- 위임된 서브넷의 주소를 사용하는 가상 인터페이스를 생성하여 작동합니다. (사용되는 가상 인터페이스는 사용자가 직접 액세스할 수 없습니다.)
- 하나의 PaaS 서비스는 하나의 가상 네트워크에만 통합할 수 있습니다.

특징
- PaaS 서비스와 가상 네트워크의 리소스는 개인 IP 주소를 통해 프라이빗하게 서로 통신할 수 있습니다.
- 프라이빗 엔드포인트를 구성할 필요 없이 피어링 된 가상 네트워크나 가상 네트워크 내 존재하는 Azure 리소스들에서 PaaS 서비스로 연결이 가능합니다.
- 온프레미스 리소스는 VPN 또는 ExpressRoute를 통해 개인 IP 주소를 사용하여 가상 네트워크의 리소스에 액세스 할 수 있습니다.
- PaaS 서비스 인스턴스는 가상 네트워크의 서브넷에 배포되기 때문에 서브넷에 대한 인바운드 및 아웃바운드 네트워크 액세스를 별도로 설정해 주어야 합니다.
- 인터넷을 통해 액세스 할 수 있는 퍼블릭 엔드포인트가 존재하지 않습니다.

네트워크 트래픽

주황색 선의 경우 온프레미스에서 VPN이나 ExpressRoute를 통해 Azure 대역으로 들어가서 서브넷 내에 있는 PaaS 서비스에 접근하는 트래픽을 나타냅니다.
파란색 선의 경우 Azure의 가상 네트워크 내에 배포된 가상 머신에서 서브넷 내에 있는 PaaS 서비스에 진입하는 트래픽을 나타 냅니다. (이 경우 가상 머신이 배포된 가상 네트워크와 PaaS 서비스가 존재하는 가상 네트워크 간 피어링이 구성되어 있어야 합니다.)
검은색 선의 경우 인터넷을 통해 PaaS 서비스에 접근하는 트래픽을 나타냅니다. VNet 통합 옵션 사용 시, PaaS 서비스에 인터넷을 통해 액세스 할 수 있는 퍼블릭 엔드포인트가 존재하지 않게 됩니다.

이상으로 이번 글을 마치도록 하겠습니다.

다음에는 Routing 테스트 관련 환경 구성 글로 돌아오겠습니다!

Azure Route Table 공부하기 (1)

H-Y-E-N — Fri, 26 Apr 2024 16:56:57 +0900

안녕하세요. HYEN입니다.

어제, Azure Route Table을 사용하여 경로를 라우팅하는 테스트를 진행해 보았는데요.

네트워크도 어려운데 Route Table에 UDR을 정의해서 원하는 대로 통신이 되게 하려고 하다보니 이래저래 시행착오를 많이 겪었습니다.

그래서 까먹지 않도록 정리해 보고자 합니다.

테스트 내용을 정리하기 전 먼저 Azure Route Table에 대한 개념과 Azure의 라우팅 로직에 대해 알아보도록 하겠습니다.

Contents

1. Azure의 가상 네트워크 트래픽 라우팅 로직

1.1 기본 경로

먼저 Azure에서 Azure, 온프레미스, 인터넷 등으로 트래픽을 라우팅하는 로직에 대해 알아보겠습니다.

Azure는 기본적으로 가상 네트워크 내 각 서브넷에 대한 경로 테이블을 자동으로 생성하고 생성한 경로 테이블에 시스템 기본 경로를 자동으로 추가합니다.

시스템 기본 경로를 추가로 만들거나 시스템 경로를 제거할 수는 없기 때문에 시스템 경로를 재정의 하기 위해서는 사용자 지정 경로 (UDR; User-defined Routes)을 사용해야 합니다.

가상 네트워크가 생성될 때마다 각 서브넷에 대해 하기와 같은 기본 시스템 경로가 자동으로 생성됩니다.

위 테이블 중 다음 홉 유형(Next hop type)에 대해 좀 더 알아보겠습니다.

Vitual network (가상 네트워크)
- 가상 네트워크의 주소 공간에 대한 트래픽을 라우팅 하기 위한 기본 경로입니다.
- 가상 네트워크가 여러 개 있다면 여러 개의 가상 네트워크에 대한 개별 경로가 생성됩니다.
- Azure는 서브넷 주소 범위에 대한 기본 경로는 생성하지 않습니다.
- 한 가상 네트워크 내에 있는 서브넷 간의 트래픽은 자동으로 라우팅 됩니다.
- 서브넷 중 일부만 경로 테이블과 연결되어도 기본 시스템 경로의 주소 접두사(Address prefixes)는 가상 네트워크의 대역으로 지정됩니다.

실제로 UDR과 snet-vm(10.100.0.0/29)과 snet-pe(10.100.0.8/29)라는 이름의 서브넷을 연결한 후 유효 경로를 확인해 보겠습니다.

([경로 테이블] > [도움말] > [유효 경로] 탭에서 확인이 가능합니다.)

상기 테이블과 같이 서브넷이 2개가 있지만 실제 경로 테이블에는 가상 네트워크의 대역인 (10.100.0.0/28)만 확인되는 것을 알 수 있습니다.

인터넷
- 주소 접두사로 지정된 트래픽을 인터넷으로 라우팅 합니다.
- 시스템 기본 경로에는 0.0.0.0/0이 지정되어 있습니다. 따라서 Azure의 기본 경로를 재정의하지 않는 한, 가상 네트워크 주소 범위에 지정되지 않은 주소에 대한 트래픽은 인터넷으로 라우팅 됩니다.
- 만약, 대상 주소가 Azure 서비스 중 하나라면 Azure는 트래픽을 인터넷으로 라우팅 하지 않고 Azure의 백본 네트워크를 통해 트래픽을 해당 서비스로 직접 라우팅 하게 됩니다.
- 따라서 Azure 서비스 간 트래픽은 인터넷을 거치지 않습니다.

없음
- 다음 홉이 "없음"인 트래픽의 경우 서브넷 밖으로 라우팅 되지 않고 삭제됩니다.
- Azure에서는 하기 주소 접두사에 대한 기본 경로를 자동으로 생성합니다.
  - 10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16: RFC 1918에서 프라이빗용으로 예약되어 있습니다.
  - 100.64.0.0/10: RFC 6598에서 예약되어 있습니다.
- 만약, 상기 주소 범위 중 하나를 할당하면 Azure는 자동으로 다음 홉 유형을 "없음"에서 "가상 네트워크"로 변경합니다.

예를 들어, 10.0.0.0/8라는 주소에 대해서 Azure는 자동으로 시스템 기본 경로를 생성하고 다음 홉 유형을 "없음"으로 생성합니다.

이때, 사용자가 10.100.0.0/28라는 가상 네트워크를 생성하게 되면 Azure는 이 주소 대역에 대해서는 다음 홉 유형을 "가상 네트워크"로 변경합니다.

상기 스크린샷에서 보실 수 있듯이 10.100.0.0/28은 10.0.0.0/8에 속합니다.

그러나 해당 가상 네트워크의 서브넷이 [경로 테이블]에 연결되어 있기 때문에 10.100.0.0/28 대역에 대해서는 다음 홉 유형이 "없음"이 아닌 "가상 네트워크"가 되게 됩니다.

1.2 선택적 기본 경로

다음은 선택적 기본 경로에 대해 알아보겠습니다.

Azure는 1.1에서 언급한 기본 경로 외에 특정 기능을 사용할 때만 추가되는 선택적 기본 경로를 제공하고 있습니다.

선택적 기본 경로에서도 위의 테이블 중 다음 홉 유형(Next hop type)에 대해 좀 더 알아보도록 하겠습니다.

VNet 피어링
- 두 가상 네트워크 간 가상 네트워크 피어링이 구성되어 있는 경우 해당 경로가 추가됩니다.

실제로 vnet-hyein-01(10.50.0.0/28)이라는 이름의 가상 네트워크와 vnet-hyein-02(10.100.0.0/28)라는 이름의 가상 네트워크 간 가상 네트워크 피어링을 구성해 보겠습니다.

그 후 경로 테이블에서 [유효 경로]를 다시 확인합니다.

이전과는 다르게 다음 홉 유형을 VNet 피어링으로 가지는 경로가 추가되었습니다.

주소 접두사는 vnet-hyein-01이라는 이름의 가상 네트워크의 주소 대역인 10.50.0.0/28로 지정되어 있음을 알 수 있습니다.

가상 네트워크 게이트웨이
- 가상 네트워크 게이트웨이가 가상 네트워크에 추가되면 생성되는 경로입니다.
- 온프레미스에 대해 BGP로 광고된 대역이나 로컬 네트워크 게이트웨이에 구성된 접두사에 대한 경로가 주소 접두사로 지정됩니다.
- 온프레미스 대역에 대해 가장 큰 주소 범위로 온프레미스에 대한 경로를 구성하는 것이 권장됩니다. (Azure 가상 네트워크 게이트웨이에 전파할 수 있는 경로의 수에 제한이 있기 때문)

VirtualNetworkServiceEndpoint
- 특정 Azure 서비스에 대한 서비스 엔드포인트를 활성화할 경우 Azure는 특정 서비스에 대한 공용 IP 주소를 경로 테이블에 추가하게 됩니다.
- 서비스 엔드포인트는 가상 네트워크 내의 개별 서브넷에서 사용하기 때문에 서비스 엔드포인트가 활성화된 서브넷에 대한 주소 접두사가 경로로 지정됩니다.
- Azure 서비스의 공용 IP 주소는 주기적으로 변경되지만 Azure가 이러한 주소를 관리하기 때문에 주소가 변경될 경우 경로 테이블의 주소도 자동으로 업데이트됩니다.

1.3 사용자 정의 경로

앞서 Azure의 시스템 기본 경로는 추가나 삭제가 불가하다는 것을 말씀드렸는데요.

사용자 정의 경로를 통해 기본 시스템 경로를 재정의하거나 경로를 추가하는 것이 가능합니다.

하나의 경로 테이블에는 여러 개의 서브넷을 연결할 수 있습니다.

그러나 하나의 서브넷에는 여러 개의 경로 테이블을 연결할 수는 없습니다.

만약 서브넷의 기본 경로와 사용자 정의 경로가 충돌하는 경우 사용자 정의 경로가 우선순위를 가집니다.

지금부터는 사용자 정의 경로를 생성할 때 지정할 수 있는 다음 홉 유형에 대해 확인해 보겠습니다.

하기 스크린샷에서 볼 수 있듯이 사용자 정의 경로에 대한 다음 홉으로 지정할 수 있는 형식은 총 5개입니다.

가상 어플라이언스
- 방화벽 같은 네트워크 애플리케이션을 실행하는 가상 머신이나, Azure Firewall을 다음 홉으로 지정하고자 할 경우 사용할 수 있는 옵션입니다.
- 해당 옵션의 경우 IP 주소를 지정해 주어야 하며 IP 주소는 다음과 같습니다.
  - 가상 머신의 private ip 주소 (NIC에 대한 IP 전달 사용 옵션 활성화 필요)
  - Azure Internal Load Balancer의 private ip 주소
  - Azure Firewall의 private ip 주소
- 주소 접두사를 0.0.0.0/0으로 지정한 후 가상 어플라이언스를 다음 홉으로 지정할 경우 모든 트래픽에 대해 가상 어플라이언스에서 allow/deny를 결정할 수 있도록 할 수 있습니다. ← 다음 글에서 할 테스트 중 일부입니다.

가상 네트워크 게이트웨이
- 가상 네트워크 게이트웨이로 라우팅 되는 특정 주소 접두사로 향하는 트래픽을 원할 때 해당 옵션을 사용합니다.
- 가상 네트워크 게이트웨이 타입은 반드시 VPN으로 지정되어야 합니다. (ExpressRoute로 지정할 경우 사용자 지정 경로에 BGP를 반드시 사용해야 하기 때문입니다.)

없음
- 지정된 주소 접두사로 향하는 트래픽을 삭제하기 위해 사용하는 옵션입니다.

가상 네트워크
- 가상 네트워크 내 시스템 기본 경로를 재정의하고자 할 경우 해당 옵션을 사용합니다.

인터넷
- 지정된 주소 접두사로 향하는 트래픽을 명시적으로 인터넷으로 라우팅 하기 위해 사용합니다.
- 공용 IP를 가지고 있는 Azure의 서비스로 향하는 트래픽을 Azure 백본 네트워크 내에 유지하려는 경우에도 사용합니다.

추가적으로 사용자 정의 경로 생성 시 선택할 수 있는 대상 유형은 다음과 같습니다.

IP 주소
서비스 태그

이렇게 오늘은 Azure의 라우팅 로직에 대해 세 가지로 나누어 알아보았는데요.

다음 글은 이러한 이해를 바탕으로 실제로 여러 가지 상황을 가정하여 테스트를 해보도록 하겠습니다!!

Azure Container Login 시 발생할 수 있는 에러 해결하기

H-Y-E-N — Fri, 26 Apr 2024 10:11:35 +0900

안녕하세요. HYEN입니다.

이번 글은 Azure Container Registry 이름에 대문자를 포함할 경우 발생할 수 있는 에러에 대해 다뤄 보았습니다.

간단하게 해결이 되긴 했지만 처음 해당 이슈를 접했을 때에는 왜 안 되는지 모르겠었기 때문에 나중에 이런 일이 발생했을 때에는 놀라지 않도록 기록해 보겠습니다.

Contents

1. 환경 구성

두 개의 Azure Container Registry를 생성합니다.
ACR에 접근할 가상 머신을 생성합니다.

1.1 Azure Container Registry 생성

먼저, 소문자만 포함하는 ACR을 생성합니다.

[기본 사항] 탭

Pricing plan은 "표준"을 선택합니다.

프라이빗 액세스를 구성하고자 할 경우에는 "프리미엄" plan을 선택해야 합니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [Azure Container Registry]를 생성합니다.

이름에 대문자를 포함하는 Azure Container Registry도 상기 과정과 동일하게 생성하면 됩니다.

[기본 사항] 탭

참고로, 컨테이너 레지스트리는 Azure 전역에서 고유한 이름이어야 합니다. (대소문자 구분 없음)

ex) acrhyein이라는 ACR이 존재할 경우 acrHyein이라는 이름으로는 ACR을 생성할 수 없습니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [Azure Container Registry]를 생성합니다.

1.2 가상 머신 생성 및 세부 구성

Local PC에서도 접근이 가능하지만 가상 머신을 생성하여 이미지를 생성하고 Push를 진행해 보도록 하겠습니다.

[기본 사항] 탭

본 테스트에서는 Ubuntu 20.04 이미지를 사용하였습니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기]를 클릭하여 [가상 머신]을 생성합니다.

가상 머신 생성이 완료되었으면 공인 IP로 접근합니다. (ssh hyein@{vm 공인 ip})

가상 머신에서 하기 과정을 진행해야 합니다. (설치 과정은 링크로 갈음합니다.)

az cli를 설치합니다.
Docker를 설치합니다.

Azure CLI 설치
- https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=apt#install-azure-cli

Install the Azure CLI on Linux

Learn how to install and run the Azure CLI on Linux manually. You can install the Azure CLI on Linux computers with one command or a step-by-step process.

learn.microsoft.com

Docker 설치
- https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository

Install Docker Engine on Ubuntu

Jumpstart your client-side server applications with Docker Engine on Ubuntu. This guide details prerequisites and multiple methods to install Docker Engine on Ubuntu.

docs.docker.com

2. 대문자를 포함하지 않은 ACR에 컨테이너 이미지 push 하기

먼저 대문자를 포함하지 않은 ACR에 컨테이너 이미지를 push해 보겠습니다.

Docker image를 Docker Hub에서 Pull 해옵니다. ( docker pull alpine )

이미지를 Azure Container Registry에 push하기 위해 먼저 az login을 진행합니다.
(멀티 테넌트를 소유하고 있는 경우 -t 옵션으로 tenantID를 입력해 주어야 합니다.)

멀티 구독인 경우 az account -s "구독 명"을 입력하여 Azure Container Registry가 존재하는 구독으로 활성 구독을 변경해 줍니다.

acrhyein이라는 ACR에 로그인합니다. ( az acr login -n acrhyein )

ACR에 push할 컨테이너 이미지에 대한 tag를 지정합니다. ( docker tag alpine:latest acrhyein.azurecr.io/hyein )

docker images 명령어를 통해 tag를 확인합니다.

docker push acrhyein.azurecr.io/hyein 명령어로 ACR에 push를 진행합니다.

Azure Portal 상에서 ACR에 이미지가 정상적으로 push 된 것을 확인할 수 있습니다.

상기 내용과 같이 소문자로 이루어진 ACR의 경우 어떠한 문제도 발생하지 않는 것을 확인할 수 있습니다.

3. 대문자를 포함한 ACR에 컨테이너 이미지 Push 하기

이번에는 대문자를 포함한 이름을 가지고 있는 ACR에 컨테이너 이미지를 push 해 보도록 하겠습니다.

acrHyein이라는 ACR에 로그인합니다. ( az acr login -n acrHyein01 )

경고 문구

Uppercase characters are detected in the registry name.
When using its server url in docker commands, to avoid authentication errors, use all lowercase.

ACR 이름에 대문자가 있을 경우, docker command에서 server url을 사용할 때 authentication error를 피하기 위해서는 모두 대문자로 사용해라 라는 내용입니다.

실제로 ACR에 로그인 시 서버 명을 모두 소문자로 한 후 로그인을 시도하면 하기와 같이 Login Succeeded라는 문구만 출력되는 것을 확인할 수 있습니다.

우선, 대문자가 포함되어 있는 서버명으로 하기 과정을 진행해 보겠습니다.

가상 머신에 빌드 되어 있는 alpine이라는 이미지에 대해 태그를 생성합니다. ( docker tag alpine:latest acrHyein01.azurecr.io/hyein )

docker push acrHyein01.azurecr.io/hyein 명령어로 ACR에 push를 진행합니다.

상기 스크린샷과 같이 unauthorized로 시작하는 에러가 발생한 것을 확인할 수 있습니다.

에러 문구

Using default tag: latest
The push refers to repository [acrHyein01.azurecr.io/hyein]
d4fc045c9e3a: Preparing
unauthorized: {"errors": {"code":"UNAUTHORIZED","message":"authentication required, visit https://aka.ms/acr/authorization for more information."}]}

이를 방지하기 위해서는 server url을 모두 lowercase로 변경하여야 합니다.

ACR의 서버 명에 있는 대문자를 모두 소문자로 바꾼 후 태그를 재 생성합니다. ( docker tag alpine:latest acrhyein01.azurecr.io/hyein )

docker push acrhyein01.azurecr.io/hyein 명령어로 ACR에 push를 진행합니다.

아까와는 다르게 push가 정상적으로 진행되는 것을 확인할 수 있습니다.

마지막으로, Azure Portal 상에서 ACR에 이미지가 정상적으로 push 되었는지 확인합니다.

acrHyein01이라는 이름의 ACR에 컨테이너 이미지가 제대로 push된 것을 알 수 있습니다.

추가적으로,

이러한 내용은 Microsoft Azure 공식 문서의 FAQ에도 적혀 있으니 참고하실 분들은 참고 부탁 드립니다.

https://learn.microsoft.com/ko-kr/azure/container-registry/container-registry-faq#az-acr-login------------------------------docker--------

Azure Container Registry

Azure Container Registry 서비스와 관련된 질문과 대답입니다.

learn.microsoft.com

#01 REST API - 개념과 보안

admin_cloud — Tue, 23 Apr 2024 15:54:36 +0900

안녕하세요. TAK 입니다:)

이번 포스팅은 관련 업무를 하면서 REST API 에 대해 정리할 필요성을 느꼈기에 작성하게 되었습니다

아래처럼 2편으로 나눠서 포스팅할 예정입니다!

#01 REST API - 개념과 보안

#02 REST API - 활용

엄청난 내용을 다루진 않지만, 그래도 From ? To ! 가 될 수 있는 내용이 될 수 있지 않을까 하는 생각과 함께

시작합니다!

Contents

1. API 란?

1-1. 정의

1-1-1. 개념

: API는 Application Programming Interface의 약자로, 소프트웨어 응용 프로그램들이 서로 통신할 수 있도록 만들어진 인터페이스를 말합니다.

이를 쉽게 표현하자면, "애플리케이션 간 상호 작용할 수 있는 중간 다리 역할을 한다"라고 이해하시면 좋을 것 같네요.
(아래 출처에서 가져온 이미지로는 "중간 다리 역할 = 점원" 으로 표현하고 있네요 )

이러한 역할을 하는 API는 서로 통신할 수 있는 방법을 제공하며, 데이터 및 서비스에 접근하고 사용할 수 있게 하는 매개체입니다.

출처 : https://blog.wishket.com/wp-content/uploads/2019/10/API-%EC%89%BD%EA%B2%8C-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0.png

1-1-2. API 유형

Private APIs	Partner APIs	Open(Public or External) APIs
말 그대로 Prviate API는 내부에서 사용되는 API입니다. 기업 내부에서 개발자나 사용이 허용되는 일부 사용자가 기업의 IT 시스템이나 애플리케이션을 통합, 구축 등의 목적으로 사용됩니다. 즉, 외부(제3자)에게는 노출되지 않습니다.	Partner API의 경우, 기업 간 계약을 통해 허용된 비즈니스 파트너가 사용가능한 API 입니다. 공통으로 앱을 개발하거나, 모니터링 및 성능 개선의 목적으로 타사의 솔루션을 사용할 때, 제공되는 API라고 할 수 있습니다.	Open API는 무료(개방형)와 상용 2가지 유형이 있습니다. 무료(개방형)의 경우, 대부분의 기능이 공개되어 있으며, 별도의 제약 및 승인 없이 공개된 API를 사용하여 애플리케이션을 생성하고 테스트할 수 있습니다. 상용 API의 경우, 구독료 혹은 사용한 만큼 지불하는 Pay As You Go 방식을 통해 제공합니다.

1-1-3. API 방식

위 그림에서 보이는 것과 같이, 프로그램 - 프로그램 관계를 클라이언트 - 서버 관계로 아래의 그림처럼 표현할 수 있습니다.

예를 들어, 사용자가 웹 브라우저에서 네이버에 접속했을 때

네이버는 다양한 카테고리를 통해 정보를 확인하고 조작할 수 있도록 구성을 해두었습니다.

네이버의 뉴스 카테코리를 클릭했을 때, 뉴스라는 API를 호출(Request)하고 해당 요청에 대해 API라는 요청을 처리하는 규칙을 통해서 Web Server는 요청을 해석하고 데이터가 저장된 Database에 여러 섹션(정치, 문화, 스포츠 등) 다양한 데이터(정보)를 가져와 사용자에서 보여주는 응답(Reposne)하는 과정이라고 할 수 있습니다.

출처 : https://www.altexsoft.com/media/2019/06/1.png

1-2. REST API 란?

1-2-1. REST API 개념 및 특징

: 그렇다면 REST API는 무엇일까요? 앞서 설명한 API는 여러 형태가 있을 수 있습니다.

가장 흔한 형태는 웹(HTTP) API로, HTTP 프로토콜을 사용하며 네트워크를 통해 상호 작용 하도록 설계되어 있습니다.

일반적으로 테스트 형식의 코드로 작성하면서 만드는 API가 웹 API에 해당합니다.

이는 각 사용자들이 자기만의 API를 만드는 것은 다른 사람과 공통으로 적용할 수 없는 자기만의 규칙을 만든 다는 것으로 볼 수 있습니다. 즉, 기업에서 담당자가 변경되거나, 다른 파트너와의 API를 공유할 때 타인이 이해하기 어렵다는 문제점이 발생할 수 있습니다.

여기서에서 이러한 문제점을 개선하고자 그리고 API를 보다 잘 활용해 보고자 "REST(Representational State Transfer) API"가 등장하게 됩니다.

REST(Representational State Transfer) API 는 네트워크 아키텍처의 한 형태로, 자원을 URI로 표현하고 해당 자원에 대한 행위를 HTTP METHOD(GET, POST, PUT, DELETE 등)를 통해 수행합니다.

즉, 블로그 서비를 REST API로 구현하고자 한다면 아래와 같이 표현할 수 있습니다.

1. 자원을 URL로 표현

블로그의 모든 글: GET /posts
특정 글: GET /posts/{post_id}
새로운 글 생성: POST /posts
글 업데이트: PUT /posts/{post_id}
글 삭제: DELETE /posts/{post_id}

2. 자원의 행위는 HTTP METHOD로 표현

GET: 자원을 읽기 위해 사용됩니다.
POST: 새로운 자원을 생성하기 위해 사용됩니다.
PUT: 자원을 업데이트하기 위해 사용됩니다.
DELETE: 자원을 삭제하기 위해 사용됩니다.

3. 예시

블로그 API를 사용하여 특정 ID를 가진 글을 읽고자 한다면
```
GET /posts/123
```
새로운 글을 작성하려면
```
POST /posts
```

이처럼 Represent 라는 의미에 맞게, 요청하는 내용만 보고 무엇을 요청하는 것인지 직관적으로 이해할 수 있어야 합니다.

위의 표현은 METHOD에 충실히 표현한 것이므로, HTTP 프로토콜을 사용하기에 정확히 표현하자면 아래처럼 표현할 수 있습니다.

*예시
GET http(s)://with-cloud.tistory.com/posts/123

또한, REST API는 크게 4가지로 이루어져 있습니다. ①권한 인증 등에 활용되는 header, ②위치를 나타내는 path, ③쿼리문을 활용한 query string, ④requsest 요청에 포함되는 body로 이루어져 있습니다. 일반적으로 ③query string은 GET 방식 ④body는 POST 방식에 활용됩니다.

앞으로 진행할 보안 인증(Authorization) 테스트에서 인증을 위한 값들은 Header의 매개변수로써 사용되게 됩니다.

1-2-2. REST API 설계 규칙

URI는 명사를 사용한다.(리소스명은 동사가 아닌 명사를 사용해야한다.)
슬래시(/)로 계층 관계를 표현한다.
URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
밑줄(_)을 사용하지 않고, 하이픈(-)을 사용한다.
URI는 소문자로만 구성한다.
HTTP 응답 상태 코드 사용 - 클라이언트는 해당 요청에 대한 실패, 처리 완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다.
파일 확장자는 URI에 포함하지 않는다.

2. API 보안 방식

: 그렇다면, 이러한 REST API는 어떻게 보호해야 하는 걸까요?

대부분의 서비스의 구현은 API를 기반으로 통신합니다. 앞서 설명한 것처럼 클라이언트 - 서버 간 대부분의 통신이 API 방식으로 이뤄지게 되는데, 이는 데이터 및 시스템을 보호하고 여러 위협으로 보호하기 위해 필수적인 영역입니다.

인증 및 권한 부여: 사용자가 인증되지 않은 경우 API에 액세스 할 수 없도록 보장해야 합니다. 또한, 권한이 없는 사용자가 보호되는 자원에 액세스하지 못하도록 권한을 제어해야 합니다.
데이터 무결성: API를 통해 전송되는 데이터는 무결성을 유지해야 합니다. 즉, 데이터가 중간에서 변경되거나 손상되는 것을 방지해야 합니다.
기밀성: 민감한 정보가 포함된 데이터는 인가된 사용자만 액세스할 수 있어야 합니다. 이러한 정보가 노출되면 비즈니스나 개인에게 심각한 피해를 줄 수 있습니다.
DDoS 및 악의적인 공격 방지: REST API는 인터넷을 통해 공개되므로 DDoS(분산 서비스 거부) 및 다양한 악의적인 공격에 취약합니다. 적절한 방어 메커니즘이 필요합니다.
데이터 검증 및 처리: API에 입력되는 데이터는 검증되어야 합니다. 이는 유효성 검사를 통해 잘못된 요청이나 악의적인 데이터를 방지하는 것을 의미합니다.
로그 및 감사: API에 대한 액세스 및 활동에 대한 로그를 유지하고 감사해야 합니다. 이를 통해 보안 사고가 발생했을 때 추적하고 대응할 수 있습니다.

이러한 REST API의 보안을 위한 중요한 메커니즘인 인증(Authentication)과 인가(Authorization) 개념에 대해서 살펴보겠습니다.

2-1. Authentication(인증)

: 인증이란? API의 보호된 리소스에 대한 액세스를 허용하기 위해 확인하는 절차로 사용자가 자신이 주장하는 신원(예: 사용자 이름과 비밀번호)을 확인하는 과정입니다.

사용자가 시스템에 로그인할 때 인증이 이루어집니다.
대부분의 경우, 인증은 사용자 이름과 비밀번호를 사용하여 이루어지지만, 보다 안전한 방법으로는 토큰 기반 인증(JSON Web Token 등)이나 OAuth와 같은 프로토콜을 사용할 수 있습니다.
인증이 성공하면 사용자는 시스템에 대한 액세스 권한을 부여받습니다.

2-2. Authorization(인가)

: 인가란? 인증된 사용자가 특정 자원이나 기능에 액세스 할 수 있는 권한을 가지고 있는지 확인하는 과정입니다.

인가는 인증 이후에 이루어지며, 사용자의 역할이나 권한에 따라 자원에 대한 접근을 제어합니다.
예를 들어, 사용자가 관리자로 인증되었지만 특정 리소스에 대한 관리자 권한이 없는 경우, 해당 리소스에 대한 액세스가 거부됩니다.
인가는 일반적으로 역할 기반 접근 제어(Role-Based Access Control, RBAC)나 규칙 기반 접근 제어(Rule-Based Access Control)와 같은 방법을 사용하여 구현됩니다.

이외에도, 네트워크 레벨 암호화, 메시지 무결성 보장, 메시지 본문 암호화 등이 있습니다.

3. REST API 인증 방법

: REST API인증 테스트를 위해, Python(Flask) 활용하였습니다.

사용된 샘플 코드는 다음과 같습니다!

from flask import Flask, request, jsonify

app = Flask(__name__)

# GET 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['GET'])
def get_data():
    # GET 요청의 쿼리 파라미터 가져오기
    param = request.args.get('param')

    if not param:
        return jsonify({'error': 'Parameter is missing'}), 400

    return jsonify({'message': f'GET 요청이 성공적으로 처리되었습니다. Parameter: {param}'})

# POST 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['POST'])
def post_data():
    # POST 요청의 JSON 데이터 가져오기
    data = request.get_json()

    if not data:
        return jsonify({'error': 'JSON data is missing'}), 400

    return jsonify({'message': f'POST 요청이 성공적으로 처리되었습니다. Data: {data}'})

if __name__ == '__main__':
    app.run(host="0.0.0.0 or Private IP", Port="5000" ,debug=True)

우선 인증이 이뤄지지 않은 상태의 값을 확인해 보겠습니다.

(GET) 파라미터값 입력 X

(GET) 파라미터값 입력 O

(POST)
- Request Content-Type 제약으로, 만약 body 에 대해 Json 형식으로 값을 전달하지 않으면 415 Unsupported Media Type 에러가 뜨게 됩니다.

이처럼 외부에서 별도의 제약 없이 API를 호출하는 것은 보안 이슈와 데이터 보호에 취약합니다. 따라서 아래 4가지 인증 방법에 대해서 살펴보겠습니다.

3-1. Basic Authentication

출처 : https://voyager.postman.com/illustration/http-basic-auth-diagram-postman.svg

가장 간단한 형태의 인증으로, 사용자 이름과 비밀번호를 인코딩(Base64)하여 HTTP 요청 헤더에 포함시키는 방식입니다.
- 아래 샘플 코드의 내용처럼 "사용자이름:비밀번호 = admintak:pwdforapitest"라는 문자열을 인코딩
보안적으로 취약할 수 있으므로 HTTPS(클라이언트 인증서, 신원 확인을 위한 검증)와 함께 사용하는 것이 좋습니다.

*Basic Authentication TEST

: 위 샘플코드를 기반으로 Basic Auth 를 구현해 보겠습니다.

라이브러리 설치

pip install Flask-BasicAuth

Basic Auth 적용 샘플 코드
- 각 METHOD에 Basic Auth 데코레이터 추가

from flask import Flask, request, jsonify
from flask_basicauth import BasicAuth

app = Flask(__name__)
app.config['BASIC_AUTH_USERNAME'] = 'admintak'
app.config['BASIC_AUTH_PASSWORD'] = 'pwdforapitest'

basic_auth = BasicAuth(app)

# GET 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['GET'])
@basic_auth.required
def get_data():
    # GET 요청의 쿼리 파라미터 가져오기
    param = request.args.get('param')

    if not param:
        return jsonify({'error': 'Parameter is missing'}), 400

    return jsonify({'message': f'GET 요청이 성공적으로 처리되었습니다. Parameter: {param}'})

# POST 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['POST'])
@basic_auth.required
def post_data():
    # POST 요청의 JSON 데이터 가져오기
    data = request.get_json()

    if not data:
        return jsonify({'error': 'JSON data is missing'}), 400

    return jsonify({'message': f'POST 요청이 성공적으로 처리되었습니다. Data: {data}'})

if __name__ == '__main__':
    app.run(host="0.0.0.0 or Private IP", Port="5000" ,debug=True)

Authorization(인증) 없이 호출할 경우, Status : 401 Unauthorized

Authorization(인증) : Basic Auth 적용
- 아래처럼 세팅하면, Postman에서 해당 값에 대해 인코딩(Base64)을 자동으로 지원해 주기 때문에 가능합니다.
- 따라서, 실제로는 인코딩(or 디코딩) 사이트에서 값을 확인해야 합니다.

직접 인코딩 값을 HTTP 헤더 값으로 넣는 경우

Authorization: Basic YWRtaW50YWs6cHdkZm9yYXBpdGVzdA==

3-2. API Key Authentication

출처 :  https://voyager.postman.com/illustration/api-key-auth-diagram-postman.svg

API 키 인증은 보통 정적인 문자열로 구성되며, 클라이언트가 서버에 요청을 보낼 때 이 키를 함께 전송합니다.
API 키는 주로 서비스나 애플리케이션을 식별하고 인증하는 데 사용됩니다. 이는 API를 사용하는 클라이언트가 서비스에 등록되어 있는지 여부를 확인하는 데에 주로 사용됩니다.
말 그대로 API Key 를 사용하는 고유한 식별자이, 각 클라이언트에게 부여되어 API 요청에 포함됩니다.
API를 사용하고자 할 때, API Key를 발급받아 메시지 안에 넣어 호출합니다.
클라이언트 간 동일한 API Key를 공유하기 때문에, 보안상 취약점이 존재하며 높은 보안 인증이 필요할 때는 적합하지 않습니다.

*API Key Authentication TEST

: 위 샘플코드를 기반으로 API Key Auth 를 구현해 보겠습니다.

API Key 생성
- 일반적으로 API Key의 경우, "대소문자 + 숫자" 조합한 32글자로 이뤄져 있습니다.

import secrets
import string

def generate_api_key(length=32):
    alphabet = string.ascii_uppercase + string.ascii_letters + string.digits
    api_key = ''.join(secrets.choice(alphabet) for i in range(length))
    return api_key

# 32자 길이의 무작위 API 키 생성
api_key = generate_api_key()

print(api_key)

API Key Auth 적용 샘플 코드
- 각 METHOD에 API Key Auth 데이레이터 추가

from flask import Flask, request, jsonify
from functools import wraps

app = Flask(__name__)

API_KEY = '[위 key 생성 스크립트에서 생성한 key 값 입력]'

# API 키를 검증하는 함수
def verify_api_key(api_key):
    return api_key == API_KEY

# API 키 검증을 수행하는 데코레이터
def require_api_key(view_function):
    @wraps(view_function)
    def decorated_function(*args, **kwargs):
        api_key = request.headers.get('X-API-KEY')
        if not api_key or not verify_api_key(api_key):
            return jsonify({'error': 'Unauthorized access'}), 401
        return view_function(*args, **kwargs)
    return decorated_function

# GET 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['GET'])
@require_api_key
def get_data():
    param = request.args.get('apitest')
    if not param:
        return jsonify({'error': 'Parameter is missing'}), 400
    return jsonify({'message': f'GET 요청이 성공적으로 처리되었습니다. Parameter: {param}'})

# POST 요청을 처리하는 엔드포인트
@app.route('/api/data', methods=['POST'])
@require_api_key
def post_data():
    data = request.get_json()
    if not data:
        return jsonify({'error': 'JSON data is missing'}), 400
    return jsonify({'message': f'POST 요청이 성공적으로 처리되었습니다. Data: {data}'})

if __name__ == '__main__':
    app.run(host="0.0.0.0 or Private IP", Port="5000" ,debug=True)

Key 값 없이 호출할 경우, Status : 401 Unauthorized

Basic Auth와 마찬가지로 Postman에서 지원하는 Authorization에서 인증 Type 설절하여 Key:Vaule 사용하여 인증
- Key : 위 스크립트에서 "request.headers.get('X-API-KEY')" 을 확인해 보면 헤더 값에 Key Name을 X-API-KEY 사용하라고 표기되어 있으므로 해당 값 입력
- Value : '[위 key 생성 스크립트에서 생성한 key 값 입력]' 해당 값 입력

Authorization(인증) : API Key 적용

마찬가지로 Postman의 Authorization 사용 없이, Headers 값에 직접 Key:Vaule를 입력하여 인증할 수 있다.

3-3. Token Authentication

출처 : https://voyager.postman.com/illustration/jwt-auth-diagram-postman.svg

사용자가 로그인할 때 서버에서 발급된 토큰을 클라이언트에게 제공하고, 클라이언트는 이 토큰을 이후의 요청에 함께 전송하여 인증합니다.
즉, 로그인 정보(username, password 등)를 통해 사용자를 인증하고 발급된 API 토큰으로 사용자를 인증하는 방식입니다.
JWT(JSON Web Token) 방식이 일반적으로 많이 사용됩니다.
- Json 객체를 사용하는 Key:Vaule 구조
Token 인증 과정을 설명하자면 다음과 같습니다.
1. 사용자의 로그인(username, password) > POST /user/login with username:password
2. 서브는 요청을 확인하고 Secret Key를 통해 Access Token 발급
3. 사용자가 API를 통해 인증을 요청할 때, Header 값에 Authorization(인증):Acceess Token을 담아서 전달(요청)
4. 서버는 JWT Signature를 확인하고, Playload로부터 사용자 정보를 확인하고 응답(자원을 Return)

*Token(JWT) Authentication TEST

: 위 샘플코드를 기반으로 Token(JWT) Auth 를 구현해 보겠습니다.

DB에 저장된 사용자가 로그인할 때 서버에서 발급된 토큰을 제공해야 하기 때문에 우선 DB와 사용자를 생성하겠습니다.

테스트용이기 때문에 가볍고, 별도의 서버가 필요 없는 SQLite DB(Python 기본 라이브러리에 포함)를 사용하였습니다.

import sqlite3

# SQLite 데이터베이스 파일 경로
DB_FILE = 'users.db'

# 사용자 테이블 생성 함수
def create_user_table():
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS users (
            id INTEGER PRIMARY KEY AUTOINCREMENT,
            username TEXT UNIQUE NOT NULL,
            password TEXT NOT NULL
        )
    ''')
    conn.commit()
    conn.close()

# 사용자 추가 함수
def add_user(username, password):
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('INSERT INTO users (username, password) VALUES (?, ?)', (username, password))
    conn.commit()
    conn.close()

# 사용자 추가 함수 실행
def add_users():
    add_user('admintak01', 'pwdforapitest01')
    add_user('admintak02', 'pwdforapitest02')

# 사용자 조회 함수
def get_user(username):
    conn = sqlite3.connect(DB_FILE)
    cursor = conn.cursor()
    cursor.execute('SELECT * FROM users WHERE username = ?', (username,))
    user = cursor.fetchone()
    conn.close()
    return user

# 실행 코드
if __name__ == '__main__':
    create_user_table()  # 사용자 테이블 생성
    add_users()          # 사용자 추가

DB(users.db) 데이터 확인

Login API 생성
: Python(Flask)에서 JWT를 통한 인증 구현하기 위해서 Flask-JWT-Extended 라이브러리 사용하겠습니다.
```
pip install flask-jwt-extended
```
Login API 테스트

from flask import Flask, jsonify, request
from flask_jwt_extended import *
from token_users_db import get_user

app = Flask(__name__)
app.config['JWT_SECRET_KEY'] = 'super-secret'  # JWT를 생성 및 확인하는 데 사용되는 시크릿 키
jwt = JWTManager(app)

# 로그인 테스트용 엔드포인트
@app.route('/login', methods=['POST'])
def login_test():
    username = request.json.get('username', None)
    password = request.json.get('password', None)
    if not username or not password:
        return jsonify({"msg": "Missing username or password"}), 400

    user = get_user(username)
    if user and user[2] == password:  # user[2]는 password 필드를 가리킵니다.
		    access_token = create_access_token(identity=user)  # 사용자 정보를 식별자로 설정
        # 접근 토큰과 함께 로그인 성공 메시지 반환
        return jsonify({"msg": "Login successful", "access_token": access_token}), 200
    else:
        return jsonify({"msg": "Bad username or password"}), 401

if __name__ == '__main__':
    app.run(host="0.0.0.0 or Private IP", Port="5000" ,debug=True)

Body 값에 사용자 로그인 정보 입력하여 POST METHOD 사용하면, 해당 계정에 대한 Token 발급

GET, POST METHOD 사용
- 위에서 로그인할 때, 발급된 Token 값을 METHOD 사용 시, Headers 값에 Key:Vaule 기입합니다.
- Key:Vaule = Authorization: Bearer access_token
- "Bearer"는 HTTP 요청에서 사용되는 인증 방식 중 하나입니다. 클라이언트가 서버에 요청을 보낼 때, 인증 정보를 함께 전달하는데, "Bearer" 방식은 이를 위한 표준 형식 중 하나입니다.

from flask import Flask, jsonify, request
from flask_jwt_extended import *
from token_users_db import get_user

app = Flask(__name__)
app.config['JWT_SECRET_KEY'] = 'super-secret'  # JWT를 생성 및 확인하는 데 사용되는 시크릿 키
jwt = JWTManager(app)

# 로그인 엔드포인트
@app.route('/login', methods=['POST'])
def login():
    username = request.json.get('username', None)
    password = request.json.get('password', None)
    if not username or not password:
        return jsonify({"msg": "Missing username or password"}), 400

    user = get_user(username)
    if user and user[2] == password:  # user[2]는 password 필드를 가리킵니다.
        access_token = create_access_token(identity=username)
        return jsonify(access_token=access_token), 200
    else:
        return jsonify({"msg": "Bad username or password"}), 401

# 토큰 인증이 필요한 보호된 엔드포인트 (GET 메서드)
@app.route('/api/data', methods=['GET'])
@jwt_required()
def protected_get():
    current_user = get_jwt_identity()
    return jsonify(logged_in_as=current_user), 200

# 토큰 인증이 필요한 보호된 엔드포인트 (POST 메서드)
@app.route('/api/data', methods=['POST'])
@jwt_required()
def protected_post():
    current_user = get_jwt_identity()
    return jsonify(logged_in_as=current_user), 200

if __name__ == '__main__':
    app.run(host="0.0.0.0 or Private IP", Port="5000" ,debug=True)

3-4. OAuth Authentication

출처 : https://voyager.postman.com/illustration/oauth-diagram-postman.svg

3rd Party 애플리케이션에 대한 사용자 인증 및 권한 부여를 위한 프로토콜입니다.
클라이언트는 사용자의 인증을 위해 OAuth 서버에 요청하고, 성공하면 액세스 토큰을 받아 API에 접근할 수 있습니다.
OAuth는 다양한 시나리오에 대응하기 위해 다양한 인증 흐름을 제공합니다.
OAuth 인증 과정을 설명하자면 다음과 같습니다.
1. 사용자는 특정 Application을 통해 OAuth 인증을 요청합니다.(Authorization Code 요청)
2. OAuth 서비스는 Redirect URL을 통해 사용자에게 Authorization Code 부여합니다.
3. 사용자는 2 단계에서 전달받은 Authorization Code를 Authorization Server에게 전달하여 Access Token을 요청합니다.
4. Authorization Server는 사용자가 Resource Server에 있는 정보를 액세스 할 수 있는 Access Token을 생성하고 전달합니다.
5. 사용자는 리소스에 대한 액세스를 요청하기 위해 Resource Server에 4단계에서 받은 Access Token을 전달합니다.
6. Resource Server는 Authorization Server를 통해 Access Token의 유효성을 확인 후, 유효하다면 사용자에게 리소스에 대한 액세스 권한을 부여합니다.

→ OAuth 인증에 대해서는 Microsoft Entra ID를 사용하여 보다 자세하게 다룰 예정입니다. 다음 편을 기대해 주세요!

지금까지 " #01 REST API - 개념과 보안" 에 대해 알아보았습니다.

다음 편에는 " #02 REST API - 활용"으로 돌아오겠습니다 (!!많관부!!)

여러분의 생각하는 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

Azure Private Subnet에 명시적으로 아웃바운드 연결하기

H-Y-E-N — Tue, 23 Apr 2024 15:25:24 +0900

안녕하세요. HYEN입니다.

테스트 글까지 하루에 적을 수 있을까 했는데 무사히 작성을 완료하였습니다.

Azure Private Subnet을 배포하고 NAT Gateway를 통해 아웃바운드 연결을 명시해 주는 테스트를 진행해 보았는데요.

관련된 개념 정리 글은 아래 링크를 확인해 주세요!

https://with-cloud.tistory.com/43

Azure Private Subnet과 Azure NAT Gateway란?

안녕하세요. HYEN입니다. 오늘은 Azure Private Subnet과 Azure NAT Gateway에 대해 알아보도록 하겠습니다. Azure Private Subnet이 Public Preview 형태로 제공되고 있어 기존의 subnet과 어떤 차이가 있는지 알고 싶어

with-cloud.tistory.com

그렇다면 바로 본론으로 들어가 보도록 하겠습니다.

Contents

1. 시나리오 확인

이번 글의 시나리오는 다음과 같습니다.

가상 네트워크 내 Private Subnet 생성
가상 머신 두 대 생성 (한 대에만 Public IP attach)
가상 머신 접속 후 인터넷 접근 가능 여부 확인
Azure NAT Gateway 생성
Subnet과 Azure NAT Gateway 연결
Public IP가 attach 되지 않은 가상 머신에서 인터넷 접근 가능 여부 확인

이를 위해 지금부터 테스트 환경을 구성해 보도록 하겠습니다.

2. 테스트 환경 구성

2.1 가상 네트워크 내 Private Subnet 생성하기

Private Subnet을 포함하는 가상 네트워크를 생성합니다.

※ 참고 사항 ※

현재 Private Subnet의 경우 Public Preview 상태이기 때문에 Subnet을 생성하는 단계에서만
"프라이빗 서브넷 사용(기본 아웃바운드 액세스 없음)" 옵션을 사용하여 Private Subnet을 배포할 수 있습니다.
(배포 이후에는 변경이 불가하며, 기존 Subnet도 Private으로 변경할 수 없습니다.)

[기본 사항] 탭

[IP 주소] 탭
- "프라이빗 서브넷 사용(기본 아웃바운드 액세스 없음)" 옵션을 반드시 활성화해야 합니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기] 버튼을 클릭하여 [가상 네트워크] 생성을 완료합니다.

2.2 가상 머신 생성하기

가상 머신은 두 대를 생성하여 하나는 공인 IP를 attach 하고 하나는 공인 IP를 attach 하지 않습니다.

이렇게 두 대의 가상 머신을 생성하는 이유는 다음을 확인하기 위해서입니다.

공인 IP가 attach 된다면 가상 머신에 명시적인 아웃바운드 연결이 생성이 된 것이기 때문에 Private Subnet 내에 있는 가상 머신이라고 하더라도 인터넷 통신이 가능합니다.
공인 IP가 없어 명시적인 아웃바운드 연결이 없는, Private Subnet 내에 있는 가상 머신은 인터넷 통신이 불가합니다.

지금부터는 가상 머신을 생성해 보도록 하겠습니다.

[기본 사항] 탭
- 첫 번째 가상 머신을 생성한 후 가상 머신의 이름만 변경해서 두 번째 가상 머신을 생성합니다.
  (ex. vm-test-hyein-02)

[네트워킹] 탭
- vm-test-hyein-01의 경우 공인 IP를 생성해야 하며, vm-test-hyein-02의 경우 공인 IP를 생성하지 않도록 "없음"을 선택합니다.

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기] 버튼을 클릭하여 [가상 머신] 생성을 완료합니다.

2.3 가상 머신 → 인터넷 접근 가능 여부 확인하기

먼저, 공인 IP가 attach 된 가상 머신에 접근합니다.

그 후 Microsoft Edge를 실행하여 "Azure"를 검색합니다.

위와 같이 인터넷 접근이 가능한 것을 확인할 수 있습니다.

다음은 해당 가상 머신 (vm-test-hyein-01)에서 공인 IP가 attach 되지 않은 가상 머신 (vm-test-hyein-02)에 접근해 보도록 하겠습니다.

그 후 동일하게 Microsoft Edge에서 "Azure"를 검색해 보겠습니다.

아까와는 다르게 인터넷 접근이 불가한 것을 확인할 수 있습니다.

Private Subnet 내에 존재하는 가상 머신이기 때문에 아웃바운드에 대해 명시적으로 구성을 해주지 않는다면 인터넷으로의 접근이 불가한 것을 알 수 있습니다.

2.4 Azure NAT Gateway 생성하기

공인 IP가 없는 가상 머신 (vm-test-hyein-02)에 대해서 인터넷 접근이 가능하도록 Azure NAT Gateway를 생성해 주도록 하겠습니다.

[기본 사항] 탭

[아웃바운드 IP] 탭
- 본 테스트에서는 [공용 IP 접두사]는 생성하지 않도록 하겠습니다.

[서브넷] 탭
- 가상 머신들이 배포되어 있는 Subnet을 선택합니다. (pri-snet-vm)

[검토 + 만들기] 탭에서 유효성 검사 후 [만들기] 버튼을 클릭하여 [NAT Gateway] 생성을 완료합니다.

2.5 Public IP가 attach 되지 않은 가상 머신에서 인터넷 접근하기

다시 가상 머신 (vm-test-hyein-02)에 접속하여 다시 한번 "Azure"를 검색합니다.

상기 스크린 샷과 같이 이번에는 정상적으로 인터넷에 접근이 가능한 것을 확인할 수 있습니다.

또한 검색 창에 My Ip Address를 검색하여 공인 IP를 확인해 보면,

52.231로 시작하는 공인 IP가 출력되는 것을 확인할 수 있습니다.

Azure Portal 상에서 [NAT Gateway] > [설정] > [아웃바운드 IP] 탭을 클릭하면 해당 IP는 NAT Gateway의 아웃바운드 IP 임을 알 수 있습니다.

참고로, 공인 IP가 붙은 가상 머신의 경우

NAT Gateway와 연결되지 않을 경우 My IP Address는 해당 가상 머신의 공인 IP가 되지만,

NAT Gateway와 연결된 경우 My IP Address는 NAT Gateway의 공인 IP가 됩니다.

(NAT Gateway가 Subnet과 연결되었기 때문에 공인 IP가 붙은 가상 머신도 영향을 받게 됩니다.)

이상으로 Azure Private Subnet + Azure NAT Gateway에 대한 테스트를 마치도록 하겠습니다.

다음에 더 재밌고 유익한 글로 돌아오겠습니다!

Azure Private Subnet과 Azure NAT Gateway란?

H-Y-E-N — Tue, 23 Apr 2024 11:20:05 +0900

안녕하세요. HYEN입니다.

오늘은 Azure Private Subnet과 Azure NAT Gateway에 대해 알아보도록 하겠습니다.

Azure Private Subnet이 Public Preview 형태로 제공되고 있어 기존의 subnet과 어떤 차이가 있는지 알고 싶어 시작하게 되었는데 이론과 테스트로 글이 나뉘게 되어 뭔가 일이 커졌다는 느낌이 들지만....

그래도 Azure NAT Gateway도 한번쯤은 사용해 보고자 이번 글을 작성하였음을 알리며

개념 정리부터 시작해 보겠습니다.

Contents

1. Azure Private Subnet이란?

Azure는 그동안 명시적인 아웃바운드 연결이 없어도 가상 네트워크 상에 가상 머신을 만들 때 기본적으로 아웃바운드 공용 IP 주소를 할당해 주었습니다. 이를 통해 아웃바운드를 명시하지 않아도 암시적으로 외부와 연결이 되었는데요.

이러한 암시적 IP는 변경될 수 있고, 사용자의 구독 내에 존재하는 것도 아니며, Azure의 기본적인 보안 모델을 따르지 않는다는 문제점이 있었습니다.

그래서 Microsoft Azure는 Azure Private Subnet이라는 기능을 현재 Public Preview 형태로 제공하고 있습니다.

Azure Private Subnet은 "기본 아웃바운드 액세스"를 false로 설정하여 암시적인 연결을 방지하는 리소스입니다.

배포 시 Azure Private Subnet 기능을 활성화한 후, 해당 subnet 내에 있는 가상 머신에 대해 명시적인 아웃바운드를 정의해 주면 됩니다.

참고로, 2025년 9월 30일 이후로 새로 생성하는 리소스에 대해서 기본 아웃바운드 액세스가 사용 중지되기 때문에 해당 날짜 이후에는 인터넷 액세스가 필요한 가상 머신의 경우 Azure NAT Gateway, Azure Load Balancer 아웃바운드 규칙, Public IP Address Attach 등 명시적인 아웃바운드 연결을 사용해야 합니다.

Default outbound access for VMs in Azure will be retired— transition to a new method of internet access | Azure 업데이트 |

Default outbound access connectivity for virtual machines will be retired in September 2025

azure.microsoft.com

2. Azure NAT Gateway란?

이번 글에서는 명시적인 아웃바운드 연결 방법 중, Azure NAT Gateway에 대해 다뤄보겠습니다.

먼저, NAT(Network Address Translation)란 무엇일까요?

네트워크 주소 변환이라는 의미의 NAT는 사설 IP를 공인 IP로 변경할 때 사용하는 서비스로
대부분 라우터 등의 장비를 사용하여 여러 사설 IP를 하나의 공인 IP로 변환할 때 사용됩니다.
또한, 한정적인 IP 주소를 절약하기 위해서도 사용되는 기술입니다.
이를 통해 인터넷이라는 퍼블릭한 망과 연결되는 사용자들의 고유한 사설 IP를 보호할 수 있습니다.

Azure에서는 이러한 NAT에 대한 서비스를 Azure NAT Gateway라고 부릅니다.

Azure NAT Gateway는 Azure 가상 네트워크의 subnet 내에 있는 프라이빗한 인스턴스에 대한 SNAT를 제공합니다.

subet에 NAT Gateway가 구성된 경우 subnet 내의 사설 IP는 NAT Gateway의 고정 공인 IP로 SNAT 되어 인터넷에 아운바운드로 연결됩니다.

인터넷에서의 인바운드 연결은 NAT Gateway를 통해 허용되지 않으며 아웃바운드 연결에 대한 응답만 DNAT 되어 NAT Gateway를 통과할 수 있습니다.

2.1 Azure NAT Gateway 특징

Azure NAT Gateway의 특징에 대해 좀 더 알아보겠습니다.

Azure NAT Gateway는 가상 네트워크에서 인터넷으로 나가는 트래픽, 즉 아웃바운드 트래픽에 대한 연결을 제공하는 리소스로 인터넷에서 들어오는 인바운드 트래픽은 NAT Gateway를 통과할 수 없습니다.
NAT Gateway가 가상 네트워크 내의 subnet에 연결된 경우 인터넷으로 전송되는 모든 아웃바운드 트래픽에 대해 subnet의 next hop이 됩니다. (이에 대한 추가 라우팅 구성은 필요하지 않습니다.)
하나의 Azure NAT Gateway 서비스를 사용하여 동일한 가상 네트워크 내 두 개 이상의 subnet을 다룰 수는 있으나, 하나가 아닌 여러 개의 가상 네트워크에 단일 Azure NAT Gateway를 연결할 수는 없습니다.

3. 가상 머신에 대한 명시적 아웃바운드 연결 예시

추가적으로, 가상 머신에 대한 명시적 아웃바운드 연결 예시는 하기와 같습니다.

NAT Gateway에 연결된 subnet 내의 가상 머신
아웃바운드 규칙이 정의된 표준 Load Balancer의 백엔드 풀로 연결된 가상 머신
기본 공용 부하 분산 장치의 백 엔드 풀로 연결된 가상 머신
공용 IP 주소가 attach 된 가상 머신

(참고 링크 : https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access)

Default outbound access in Azure - Azure Virtual Network

Learn about default outbound access in Azure.

learn.microsoft.com

이어서 다음 글의 주제는 "Azure Private Subnet에 명시적으로 아웃바운드 연결하기"입니다.

클라우드 네이티브란?

H-Y-E-N — Mon, 22 Apr 2024 11:20:22 +0900

안녕하세요. HYEN입니다.

오늘은 제 머릿속에 사혼의 구슬처럼 흩어져 있던 클라우드 네이티브와 클라우드 네이티브를 이루는 핵심 요소들에 대해 정리해 보았습니다.

CD에 대해서는 Delivery랑 Deployment의 차이가 무엇일까 왜 나눠서 사용할까? 하는 의문이 들었고

DevOps를 생각할 때는 그래서 DevOps랑 CI/CD의 차이가 뭔데?라는 생각이 많이 들었습니다.

클라우드 네이티브에 대해 알아볼 뿐만 아니라 각각의 개념에 대해서도 좀 더 제 것으로 만들 수 있는 기회가 되었으면 하여 이 글을 작성하였습니다!

Contents

1. 클라우드 네이티브란?

클라우드 네이티브란 소프트웨어 애플리케이션을 클라우드 환경을 기반으로 설계하고 구축하는 방식을 의미합니다.

클라우드 네이티브 앱은 클라우드 서비스의 특성을 활용하여 확장성, 탄력성, 안정성, 비용 효율성 등을 갖출 수 있으며 이를 위해 Microservices, CI/CD, DevOps, Containers 등의 기술과 방법론을 사용합니다.

2. 클라우드 네이티브 아키텍처

2.1 마이크로서비스

마이크로서비스에 대해서는 아래 글에 정리해 두었습니다.

마이크로서비스 아키텍처란? (https://with-cloud.tistory.com/38)

마이크로서비스 아키텍처(MSA)란?

안녕하세요. HYEN입니다. 개념적인 내용도 다루고 넘어가면 좋을 것 같아 오늘은 간단하게 마이크로서비스 아키텍처가 무엇인지에 대해 알아보도록 하겠습니다. 쿠버네티스를 공부하면서 많이

with-cloud.tistory.com

2.2 CI/CD

CI/CD는 Continuous Integration (지속적인 통합) / Continuous Delivery (지속적인 서비스 제공) 또는 Continuous Deployment (지속적인 배포)를 의미합니다.

먼저, CI는

1) 소스 코드를 공유 레포지토리에 push할 때

2) 이러한 변경 사항에 대해 자동으로 빌드 및 테스트가 진행되고

3) 공유 레포지토리에 소스 코드가 병합되는

과정을 나타냅니다.

커밋할 때마다 빌드와 테스트가 자동으로 이루어지기 때문에 해당 변경으로 문제가 생기는 부분이 없도록 보장할 수 있게 됩니다. 이를 통해 개발자가 구현한 코드를 기존 코드와 병합했을 때 코드가 올바르게 동작하고 빌드되는지 검증할 수 있고 문제가 있다면 수정을 하고 다시 병합을 진행하거나 문제가 없다면 배포를 진행하게 됩니다.

CD는 두 가지 의미로 분리할 수 있을 것 같습니다.

첫 번째, CD(Continuous Delivery)의 경우,

1) CI 파이프라인을 통해 main branch에 저장된 완성된 코드가 GitHub와 같은 레포지토리(Delivery)에 자동으로 업로드되는 것을 뜻합니다.

두 번째, CD(Continuous Deployment)의 경우,

1) 개발자가 변경한 사항을 레포지토리에 업로드하는 것을 넘어

2) 고객이 사용할 수 있는 프로덕션 환경까지 자동으로 릴리즈하는 것을 의미합니다.

이 둘 개념 간 차이에 대해서는 하기 그림을 보시는 것이 이해에 도움이 될 것 같습니다.

출처 : https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

즉, 프로덕션 환경으로의 릴리즈가 수동으로 이루어지는가, 자동으로 이루어지는가가 Continuous Delivery / Continuous Deployment의 차이라고 보시면 될 것 같습니다.

Continuous integration vs. delivery vs. deployment

Learn the difference between continuous integration, continuous delivery, and continuous deployment in modern software development and DevOps.

www.atlassian.com

CI/CD Pipeline의 경우 빌드하고 테스트하는 과정을 자동화하는 것이기 때문에 코드 개발 자체에 좀 더 집중할 수 있게 됩니다.

또한 반복적으로 수행해야 하는 과정을 자동화하기 때문에 시간을 절약할 수 있다는 장점이 있습니다.

2.3 DevOps

DevOps는 소프트웨어 개발과 운영을 통합하여 효율성, 협력, 안정성 등을 높이는 방법론입니다.

소프트웨어 개발부터 배포, 운영, 모니터링까지 전체 생명주기를 관리하고, 개발과 운영 간의 협업을 강화하여 릴리즈 주기를 단축하고 문제를 신속하게 해결할 수 있도록 하는 것이 바로 DevOps입니다.

그렇다면, DevOps와 CI/CD의 차이점은 무엇일까요?

DevOps는 개발과 운영 간의 커뮤니케이션과 협업을 강조하는 문화 또는 사고방식을 나타냅니다.

조직이 지속적으로 신속하게 애플리케이션을 배포할 수 있도록 소프트웨어나 팀을 구축하도록 지원하는 방법론이 바로 DevOps입니다.

이러한 DevOps를 성공적으로 구현하기 위해서는 자동화가 매우 중요합니다.

DevOps 문화를 가지고 있는 팀은 CI와 CD를 팀의 프로세스테 통합하여 CI/CD Pipeline을 원활하게 운영할 수 있습니다. 여기서 CI/CD는 자동화된 테스트 도구를 사용하는 DevOps의 전략이라고 볼 수 있습니다.

즉, CI/CD는 소프트웨어 전체의 생명 주기에 중점을 두기 때문에 자동화와 관련된 도구를 강조하며, DevOps는 이러한 것들이 가능하게 하는 문화에 대해 강조하는 개념이라고 정리할 수 있습니다.

2.4 컨테이너

클라우드 네이티브 애플리케이션은 컨테이너 기술을 활용하여 개발됩니다.
클라우드 네이티브 애플리케이션의 코드는 컨테이너로 패키지화되고 실행 환경이 격리됩니다.
개발 환경과 운영 환경 간의 일관성을 유지할 수 있으며 운영 중단 없이 애플리케이션을 업그레이드하거나 효율적으로 확장할 수 있습니다.
다양한 환경 간에 쉽게 이식할 수 있습니다.
컨테이너화를 통해 마이크로서비스를 기반이 되는 OS 및 H/W와 독립적으로 실행될 수 있습니다.

정리하자면,

클라우드 네이티브 아키텍처란 클라우드 컴퓨팅 시스템의 장점을 최대로 활용하도록 하는 애플리케이션 구축 방법이며 상기 설명한 4가지 핵심 요소를 통해 이를 달성할 수 있습니다.

간단하게 클라우드 네이티브가 무엇인지, 이것을 이루는 핵심 요소에는 무엇이 있는지 알아보았습니다.

그럼 다음에 또 좋은 글로 찾아오도록 하겠습니다.

Streamlit으로 웹 애플리케이션 만들어보기

H-Y-E-N — Fri, 19 Apr 2024 15:31:02 +0900

안녕하세요. HYEN입니다.

이전 글에 이어 Streamlit으로 실제 데이터 웹 애플리케이션을 만들어 보는 테스트에 대해 다뤄보겠습니다.

이전 글 : https://with-cloud.tistory.com/40

Streamlit이란?

안녕하세요. HYEN입니다. 오늘은 기존에 다루던 부분과 조금은 다른 분야의 내용을 다뤄보고자 합니다. 바로 Python 기반의 웹 개발 프레임워크인 Streamlit입니다! 우연한 기회에 접하게 되었는데 웹

with-cloud.tistory.com

Contents

1. 환경 구성

먼저 Streamlit으로 데이터 웹 애플리케이션을 만들기 전 사전에 구성하거나 설치해야 하는 것들에 대해 알아보도록 하겠습니다.

※ 본 테스트는 Local PC가 아닌 가상 머신에서 진행되었습니다.※

1.1 Visual Studio Code 설치

Download Visual Studio Code - Mac, Linux, Windows로 이동하여 테스트 환경 OS에 맞는 Visual Studio Code 설치 파일을 다운로드 합니다.

Download Visual Studio Code - Mac, Linux, Windows

Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows. Download Visual Studio Code to experience a redefined code editor, optimized for building and debugging modern web and cloud applications.

code.visualstudio.com

저는 Windows11 가상 머신을 사용하기 때문에 Windows용 System Installer x64를 다운로드 받습니다.

하기와 같이 "I accept the agreement"로 옵션을 변경하는 것 외 기본 설정을 유지하고 [Next >]를 클릭합니다.

마지막으로 [Install] 버튼을 클릭하여 Visual Studio Code 설치를 완료합니다.

마지막으로, Streamlit이라는 이름의 folder를 하나 생성합니다.

1.2 python 설치

Download Python | Python.org로 이동하여 테스트 환경 OS에 맞는 python 설치 파일을 다운로드 합니다.

Download Python

The official home of the Python Programming Language

www.python.org

저는 Visual Studio Code 설치 시와 마찬가지로 Windows용 파일을 다운로드 받습니다.

설치 파일을 실행한 후 [Install Now] 버튼을 클릭하여 설치를 진행합니다.

하단의 "Use admin privileges when installing py.exe"와 "Add python.exe to PATH" 체크박스를 클릭해 줍니다.

Visual Studio Code를 재실행한 후에 [Ctrl + Shift + `]를 눌러 터미널을 실행합니다.

터미널 창에 python을 입력했을 때 상기 스크린샷처럼 출력된다면 python 설치가 정상적으로 진행된 것입니다.

1.3 Streamlit 설치

Streamlit을 설치하기 위해 로 이동하여 [Get started] > [Installation] > [Use command line]을 클릭합니다.

python -m venv .venv 명령어로 가상 환경을 만들어도 되지만 저는 Streamlit을 그냥 VM 환경에 설치해 보겠습니다.

pip install streamlit 명령어를 입력하여 Streamlit을 설치합니다.
streamlit hello를 입력하여 Hello는 example app을 실행합니다.
Email 입력의 경우 그냥 [Enter]를 눌러도 됩니다.

명령어가 실행되면 네트워크 허용에 대한 메시지 창이 뜹니다. [Allow]를 클릭하면 하기 스크린샷과 같은 Sample Web page가 생성된 것을 확인할 수 있습니다.

2. 웹 페이지 생성해 보기

2.1 "Hello World" app 생성하기

https://docs.streamlit.io/get-started/installation/command-line#create-a-hello-world-app-and-run-it의 가이드를 따라서 Hello World app을 생성한 후 실행해 보겠습니다.

Streamlit Docs

Join the community Streamlit is more than just a way to make data apps, it's also a community of creators that share their apps and ideas and help each other make their work better. Please come join us on the community forum. We love to hear your questions

docs.streamlit.io

먼저 Streamlit이라는 폴더 내에 helloworld라는 이름의 폴더를 하나 더 생성한 후 cd helloworld 명령어를 입력하여 working directory를 변경합니다.

(이어서 테스트할 다른 app들과 환경을 분리하기 위함입니다.)

test.py라는 파일을 helloworld 폴더 하위에 생성합니다.

test.py 파일을 열고 하기 코드를 입력합니다.

import streamlit as st

st.write("Hello world")

작성을 완료한 후 저장을 눌러 변경 사항을 저장합니다.

streamlit run test.py 명령어를 실행합니다.

자동으로 하기 페이지가 로딩되며 "Hello world"라는 문구가 출력되어 있는 것을 확인할 수 있습니다.

다소 심플한 감이 있어 Docs의 API Reference 탭의 sample 코드를 가지고 To Do List를 만들어 보겠습니다.

https://docs.streamlit.io/develop/api-reference로 이동하여 "Input widgets"를 클릭합니다.

Streamlit Docs

docs.streamlit.io

"Checkbox"를 클릭합니다.

코드를 복사해서 앞서 생성한 test.py 파일에 붙여 넣습니다.

그냥 붙여 넣어도 되지만 To Do List이기 때문에 하기 코드와 같이 항목을 두 개 더 추가하고 체크박스가 모두 체크되면 "You did EVERYTHING! "이 출력되도록 하였습니다.

또한 To Do List라는 제목을 가장 상단에 표시되도록 하고 색은 무지개 색으로 보이도록 코드를 추가해 주었습니다.

import streamlit as st

st.title(':rainbow[To Do List] :rainbow:')

work = st.checkbox('Work')
gym = st.checkbox('Go to gym')
book = st.checkbox('Read a book')

if work and gym and book:
    st.write('You did EVERYTHING! :thumbsup:')

코드를 작성한 후 [Ctrl + s] 버튼을 눌러 변경 사항을 저장합니다.

그 후 streamlit run test.py 명령어를 실행합니다.

웹 페이지가 실행되면서 하기 스크린샷과 같은 페이지가 보입니다.

체크 박스를 다 누르면 "You did EVERYTHING! "이라는 문구가 출력되는 것을 확인할 수 있습니다.

참고로 Streamlit에서 지원하는 emoji의 shortcode들에 대한 정보는 하기 링크에서 확인하실 수 있습니다.

https://streamlit-emoji-shortcodes-streamlit-app-gwckff.streamlit.app/

A faster way to build and share data apps

App showing all the emoji shortcodes supported by Streamlit

streamlit-emoji-shortcodes-streamlit-app-gwckff.streamlit.app

2.2 LangChain을 사용하여 LLM app 생성하기

다음은 LangChain을 사용하여 LLM app을 생성하는 테스트를 진행해 보도록 하겠습니다.

LangChain❓ LLM❓이 무엇일까요?

우선 이 두 가지 개념에 대해서 간단히 설명하고 넘어가도록 하겠습니다.

LangChain이란?

LangChain은 대규모 언어 모델(LLM)을 기반으로 한 애플리케이션을 개발하기 위한 오픈 소스 프레임워크입니다.
개발자들이 기존의 언어 모델을 쉽게 연동하고 확장할 수 있도록 다양한 도구와 인터페이스를 제공합니다.
따라서 LangChain은 특히 대화형 AI 시스템을 구축하는 데 많이 사용되고 있습니다.

LLM이란?

LLM(Large Language Models)은 대규모 언어 모델을 의미하며, 대량의 데이터셋을 학습하여 자연어 이해 및 생성 능력을 갖춘 모델입니다.
딥러닝 방식으로 패턴을 분석하고 의미를 추출하여 인간의 방식으로 답을 생성하도록 훈련되었습니다.
OpenAI의 ChatGPT, 메타(구 페이스북)의 LLaMA와 같은 모델이 대표적인 LLM 모델입니다.

주요 개념에 대해서 알아 보았으니 지금부터 LangChain을 사용하는 LLM app을 생성해 보도록 하겠습니다.

Streamlit Docs 중 "Build an LLM app using LangChain" 문서를 참고하여 생성합니다.

https://docs.streamlit.io/develop/tutorials/llms/llm-quickstart

Streamlit Docs

docs.streamlit.io

먼저, llmapp이라는 폴더를 새로 생성합니다.

이후 터미널에서 cd ../llmapp 명령어를 입력하여 working directory를 변경합니다.

그리고 해당 위치에 app.py라는 이름의 파일을 하나 생성합니다.

여기까지 했다면 2.1 과정과는 다르게 추가적으로 해주어야 하는 것이 있습니다.

바로 OpenAI key를 생성하는 것입니다.

참고로 API Key를 사용하기 위해서는 Paid User여야 합니다. (최소 $5의 비용이 발생합니다.)

여기로 이동하여 로그인을 합니다. (계정이 있어야 합니다. 없다면 생성해야 합니다.)

하기와 같은 페이지가 뜨면 [+ Create new secret key]를 클릭하여 새로운 API Key를 생성합니다.

API Key의 이름을 입력한 후 [Create secret key] 버튼을 클릭합니다.

하기 스크린샷과 같이 API Key가 출력되면 [Copy] 버튼을 클릭하여 해당 Key를 복사합니다.

(해당 키는 해당 창을 나가면 다시 볼 수 없기 때문에 꼭 메모장과 같은 곳에 저장해 두어야 합니다.)

정상적으로 생성이 되면 하기와 같이 Project API keys 리스트에 방금 생성한 API Key가 출력되게 됩니다.

다시 Visual Studio Code로 돌아와 pip install openai langchain 명령어를 입력하여 필요한 Python 라이브러리를 설치합니다. (Streamlit은 이미 설치했기 때문에 생략합니다.)

그 다음 현재 폴더에 requirements.txt라는 파일을 생성합니다.

그리고 streamlit openai langchain를 해당 파일에 적어 줍니다.

app.py 파일에 하기 코드를 입력해 줍니다.

import streamlit as st
from langchain.llms import OpenAI

st.title('  Quickstart App')

openai_api_key = st.sidebar.text_input('OpenAI API Key', type='password')

def generate_response(input_text):
    llm = OpenAI(temperature=0.7, openai_api_key=openai_api_key)
    st.info(llm(input_text))

with st.form('my_form'):
    text = st.text_area('Enter text:', 'What are the three key pieces of advice for learning how to code?')
    submitted = st.form_submit_button('Submit')
    if not openai_api_key.startswith('sk-'):
        st.warning('Please enter your OpenAI API key!', icon='⚠')
    if submitted and openai_api_key.startswith('sk-'):
        generate_response(text)

코드에 대해 간략하게 설명을 해보자면 다음과 같습니다.

Line 1, 2를 통해 필요한 Python 라이브러리를 import 합니다.
Line 4를 통해 페이지의 제목을 적어줍니다.
Line 6을 통해 OpenAI API Key를 입력할 수 있는 input text box를 생성합니다.
Line 8-10을 통해 OpenAI API Key를 가지고 Open AI에 인증하고, prompt를 보내고 AI가 생성한 응답을 받을 수 있도록 하는 함수를 정의합니다. 이 함수는 user의 요청을 받아 AI가 생성한 응답을 st.info를 사용하여 파란색 박스에 출력하도록 하는 함수입니다.
마지막으로 Line 12-18에서 st.form()을 사용하여 사용자 입력을 위한 text box를 생성합니다. st.text_area()를 사용자가 Submit이라는 버튼을 클릭하면, 사용자의 입력을 인수로 사용하는 generate-response()라는 함수가 호출됩니다.

파일을 저장한 후 streamlit run app.py 명령어를 실행합니다.

웹 페이지가 실행되면서 하기와 같은 화면이 출력됩니다.

앞서 생성한 OpenAI API Key를 좌측 상단의 [OpenAI API Key] 박스에 입력한 후 질문을 입력합니다.

"What is a dog?"라는 질문에 대한 대답이 하기 스크린샷과 같이 파란색 박스 안에 출력되는 것을 알 수 있습니다.

2.3 간단한 app 만들어 보기

마지막으로 문장을 입력하면 image를 생성해 주는 app에 대한 GitHub 소스 코드를 clone 해서 애플리케이션을 build 해 보겠습니다.

본 테스트는 Youtube의 AI Image Generation Streamlit App이라는 영상의 소스 코드를 사용하였습니다.

git clone https://github.com/AIAnytime/AI-Image-Generation-Streamlit-App ai-image-generator 명령어를 사용하여 git clone을 진행합니다.

cd ai-image-generator를 입력하여 working directory를 이동합니다.

코드는 수정하지 않고 필요한 라이브러리와 환경 변수만 추가로 설치해 줍니다.

먼저 라이브러리를 설치하기 위해 하기 명령어를 입력합니다.

pip install --upgrade diffusers[torch]
pip install sentencepiece
pip install --upgrade diffusers transformers accelerate
pip install transformers

설치가 완료되면 하기 스크린샷에 있는 "OPENAI_API_KEY"라는 변수에 대한 값을 입력해 주기 위해 현재 폴더 내에 .env라는 파일을 하나 생성합니다.

그리고 .env 파일에 다음과 같이 작성합니다.

Key 값은 2.2 과정에서 사용했던 OpenAI API Key를 입력해 주면 됩니다.

파일을 저장한 후에 터미널에서 streamlit run app.py 명령어를 실행합니다.

만약 웹 페이지 실행 시 하기와 같은 에러가 발생할 경우,

OSError: [WinError 126] The specified module could not be found. Error loading "C:\Users\hyein\AppData\Local\Programs\Python\Python312\Lib\site-packages\torch\lib\c10.dll" or one of its dependencies.

VS2019 redist를 설치하면 됩니다. (설치 링크 : https://aka.ms/vs/16/release/vc_redist.x64.exe)

웹 페이지가 정상적으로 보이면 좌측의 드롭다운 버튼을 클릭하여 "DALL-E"를 선택합니다.

원하는 문장을 입력합니다.

저는 예시로 "Cats are playing badminton in the jungle. cartoon style."이라는 문장을 입력해 보았습니다.

그 후 [Generate Image] 버튼을 누르면 이미지를 생성해 줍니다.

실제로 생성해 준 그림은 하기와 같습니다.

계속 보니 의미는 모르겠지만 귀여운 것 같습니다.

물론 제일 왼쪽에 있는 고양이랑 배드민턴은 뭔지 모르겠지만...

이렇게 Streamlit 테스트를 완료해 보았습니다.

직접 해 보니까 확실히 Streamlit은 빠르게 애플리케이션을 생성하기에 굉장히 강력한 도구라는 생각이 듭니다.

운영을 목적으로는 사용해 보지 않았지만 해당 부분은 다소 한계가 있을 거 같다는 생각도 듭니다.

그래도 여전히 쉽게 AI와 관련된 애플리케이션을 생성해 보기에 아주 좋은 도구라는 점에서 관심 있으신 분들은 사용해 보시는 것을 추천 드립니다.

Streamlit이란?

H-Y-E-N — Wed, 17 Apr 2024 13:53:12 +0900

안녕하세요. HYEN입니다.

오늘은 기존에 다루던 부분과 조금은 다른 분야의 내용을 다뤄보고자 합니다.

바로 Python 기반의 웹 개발 프레임워크인 Streamlit입니다!

우연한 기회에 접하게 되었는데 웹 개발에 대한 지식이 많이 없는 저도 쉽게 데모 환경을 구성할 수 있더라구요!

이번 글에서는 간단하게 Streamlit이 무엇인지에 대해 알아보고 다음 글에서 실제 구성한 데모 환경에 대해 다뤄보도록 하겠습니다. ️

Contents

1. Streamlit이란?

공식 문서에 따르면 Streamlit의 정의는 다음과 같습니다. (https://docs.streamlit.io/)

Streamlit is an open-source Python framework for data scientists and AI/ML engineers to deliver dynamic data apps with only a few lines of code. Build and deploy powerful data apps in minutes.

Streamlit Docs

docs.streamlit.io

Data Scientist나 AI/ML 엔지니어들이 간단한 코드만 작성하면 동적인 데이터 분석 애플리케이션을 제공할 수 있는 오픈 소스 Python 프레임워크가 바로 오늘의 주제인 Streamlit입니다.

애플리케이션을 개발하려고 한다면 HTML, CSS, Javascript 뿐만 아니라 웹 프레임워크를 모두 고려해야 합니다. 이런 지식이 충분하지 않다면 개발에 어려움을 겪을 수밖에 없는데요.

Streamlit은 Python 코드만 작성하면 데이터 분석 애플리케이션을 생성할 수 있습니다.

즉, 사전 배경 지식을 상대적으로 많이 요하지 않는다는 점에서 단기간에 개발이 가능하다는 점이 Streamlit의 특징이라고 할 수 있습니다.

2. Streamlit의 특징

Simple and Pythonic
- 간단하고 읽기 쉬운 코드로 구성되어 있습니다.
- 복잡한 배경 지식이 없어도 애플리케이션을 빠르게 생성할 수 있습니다.
- Streamlit cloud를 사용할 경우 GitHub 레포지토리에 소스 코드를 업로드하여 웹 상에 본인의 서비스를 배포할 수 있습니다.

Fast, interactive prototyping
- 원하는 대로 애플리케이션의 모양과 기능을 변경할 수 있어 빠르고 상호 작용적인 프로토타입을 생성할 수 있습니다.
- 웹 서비스 형태의 데모를 제작하는데 최적화 되어 있습니다.

Live editing
- 코드를 편집하면 그 즉시 애플리케이션이 자동으로 업데이트 됩니다.

Open-source and free
Data Integration
- Python 코드 기반이기 때문에 Python의 주요 데이터 분석 및 시각화 라이브러리와의 통합이 용이합니다.

3. 한계점

간단한 데모 애플리케이션 생성에는 굉장히 유용한 프레임워크이지만 복잡한 애플리케이션일 경우 프레임워크 디자인에 제한이 있습니다.
많은 부분을 추상화하여 제공하기 때문에 레이아웃이나 위젯과 같이 디자인 측면의 자유도가 낮습니다.
사용자와 상호작용할 때마다 전체 스크립트가 다시 실행되는 Streamlit의 로직 특성 상 dataset의 크기가 크거나 복잡한 계산이 필요한 경우 성능이 저하될 수 있습니다.

이렇게 Streamlit의 개념 그리고 특징과 한계점에 대해 알아보았습니다.

빠른 시일 내에 Streamlit 테스트 글로 돌아오도록 하겠습니다~

Service Mesh란?

H-Y-E-N — Mon, 15 Apr 2024 11:05:37 +0900

안녕하세요. HYEN입니다.

오늘은 Service Mesh에 대해 알아보도록 하겠습니다.

Contents

1. Service Mesh란?

https://istio.io/latest/about/service-mesh/

Service Mesh는 마이크로서비스 간 통신이 매시 형태인 것에서 착안된, 마이크로서비스 간의 통신을 나타내는 개념입니다. 이는 여러 서비스 간의 통신을 관리하는 것을 도와줍니다.

소프트웨어를 작은 단위로 나누어 개발하는 방식인 마이크로서비스에서는 각각의 서비스들이 서로 통신하여 기능을 수행하기 때문에 이러한 분산된 통신을 관리해 줄 도구가 필요해집니다.

Service Mesh는 서로 다른 기능 간의 통신이 원활할 수 있도록 통신을 관리해 주고, 데이터를 안전하게 전송하고 저장할 수 있도록 해줍니다. 또한 서비스들의 동작을 계속해서 모니터링하여 이슈가 발생할 경우 알려줍니다.

일반적으로, Service Mesh는 Kubernetes와 같은 컨테이너 오케스트레이션 환경 내에서 사이드카 형태의 프록시를 배치합니다. 그리고 이러한 프록시를 통해 트래픽 모니터링이나 트래픽 컨트롤을 수행합니다.

사이드카 형태의 프록시를 통해서 Service Mesh는 기존의 애플리케이션 코드를 수정하지 않고도 서비스 간 통신을 모니터링할 수 있고, 필요한 경우 로깅하여 시스템의 상태를 파악하고 문제를 진단할 수 있게 됩니다.

이러한 Service Mesh를 구현하는 오픈 소스 소프트웨어로는 이스티오(Istio), 링커드(Linkerd), Kuma 등이 있습니다. 그중 이스티오를 사용하여 이러한 Service Mesh를 구현하는 경우가 가장 많으며 아래에서 좀 더 자세히 설명하도록 하겠습니다.

추가적으로 사이드카 형태에 대해 간단히 알아보고 넘어가겠습니다.

사이드카 형태란?

https://kubebyexample.com/learning-paths/istio/intro

애플리케이션 컨테이너와 독립적으로 동작하는 또 하나의 컨테이너를 붙이는 패턴을 의미합니다. 즉, 메인 컨테이너 외 보조적인 기능을 추가하는 서브 컨테이너를 포함하는 패턴이 바로 사이드카 형태입니다.
애플리케이션 컨테이너(메인 컨테이너)와 독립적으로 동작하므로 사이드카 컨테이너에 장애가 발생하더라도 애플리케이션 컨테이너는 영향을 받지 않습니다.
또한 사이드카 컨테이너를 생성하고, 업데이트하고, 제거해야 하는 경우에도 기존 애플리케이션 컨테이너에 대한 코드는 수정을 할 필요가 없습니다.

Service Mesh를 구성하는 개별 프록시들은 마이크로서비스 내에서 실행되는 것이 아니라 마이크로서비스의 옆에서, 즉 사이드카 형태로 함께 실행됩니다.

2. Service Mesh를 사용하는 이유는?

마이크로 서비스는 여러 작은 서비스들로 구성되어 있기 때문에 서비스 간의 통신이 복잡합니다. 따라서 각 서비스 간의 통신을 추상화하여 더 쉽게 관리할 수 있도록 하기 위해 Service Mesh를 사용합니다.

통신을 추상화한다는 것이 정확히 무슨 뜻일까요?

추상화라는 의미 자체는 복잡한 세부 사항들 중 핵심적인 개념 또는 기능을 간추려 내는 것을 의미합니다.

마이크로 서비스는 Service Mesh를 이용하여 각 서비스 간 통신을 추상화 함으로써 개별 서비스 내에 통신 관련 로직을 직접 구현하지 않게 됩니다. 또한 같은 맥락으로 서비스는 다른 서비스의 구체적인 세부 정보를 알 필요가 없어집니다. Service Mesh를 통해 통신하기 때문에 다른 서비스를 신경 쓰지 않고 자신의 로직에만 집중할 수 있게 됩니다.

이 외에도 통신 보안이나 모니터링과 같은 기능을 Service Mesh가 제공하기 때문에 개발자가 이에 대해 직접 구현할 필요가 없어집니다.

또한 Service Mesh는 서비스들의 수가 증가하더라도 쉽게 확장할 수 있도록 구성되어 있습니다. (ex. 사이드카 패턴) 이뿐만 아니라 로드 밸런싱, 트래픽 제어, 오류 처리 등의 기능도 함께 제공하기 때문에 서비스들의 성능과 안정성을 향상하는 역할도 합니다.

서비스 간 통신의 모든 부분을 모니터링할 수 있기 때문에 문제를 손쉽게 인식하고 진단할 수 있으며 장애가 발생한 서비스에 대한 요청을 다시 라우팅 할 수 있도록 해주기 때문에 애플리케이션 복구 능력 역시 향상됩니다.

Service Mesh를 사용하지 않을 경우 서비스 간의 통신을 직접 구현하거나 관리해야 하기 때문에 복잡성이 증가할 수 있습니다. 각 서비스마다 다른 방식으로 통신을 관리하게 되면 유지 보수와 디버깅, 그리고 병목 현상과 같은 네트워크 이슈에 대한 트러블 슈팅이 어려워지게 됩니다.

따라서, Service Mesh는 복잡한 마이크로 서비스 아키텍처에서 필수적인 도구라고 할 수 있습니다.

3. Istio란?

Istio란 (https://istio.io/latest/about/service-mesh/)

The Istio service mesh

Service mesh.

istio.io

Istio는 기존 분산 애플리케이션에 투명하게 layering 되는 오픈 소스 Service Mesh입니다.
마이크로 서비스들을 보호하고, 연결하고, 모니터링하는 균일하고 효율적인 방법을 제공합니다.
서비스 코드에 대한 최소한의 변경을 통해 또는 서비스 코드 변경 없이 로드 밸런싱, 서비스 간 인증 및 모니터링을 위한 경로(path)가 됩니다.

Istio는 Control Plane과 Data Plane 이 두 가지 요소로 구성되어 있습니다.

먼저 Istio의 Control Plane은 TLS 암호화, ID 기반 인증 및 권한 부여를 통해 클러스터에서 서비스 간 통신을 보호합니다.

또한 HTTP, gRPC, WebSocket 및 TCP 트래픽에 대한 로드 밸런싱을 제공하고 다양한 라우팅 규칙, 재시도(retries), 장애조치(failover) 등을 통해 트래픽을 세밀하게 제어합니다.

클러스터의 ingress 및 egress를 포함한 클러스터 내의 모든 트래픽에 대해 자동화된 메트릭, 로그 및 추적 기능도 제공합니다.

Data Plane은 서비스 간 통신 자체를 나타냅니다.

Service Mesh는 전송되는 트래픽의 유형, 출처를 확인하기 위해 프록시를 사용하여 모든 네트워크 트래픽을 확인합니다.

정리하자면,

Data Palne은 각 프록시들로 이루어져 config에 따라 트래픽을 관리하는 부분을 의미합니다.

이 경우 서비스가 증가하게 되면 프록시 수도 증가하게 됩니다. 프록시가 증가하게 되면 당연히 관리 포인트도 증가하기 때문에 이 부분을 중앙에서 관리할 필요성이 생깁니다.

config 값들을 저장하고 각 프록시들에게 이에 대해 전달하는 것이 Control Plane의 역할입니다.

Istio는 Envoy 프록시를 사용합니다.

https://www.cncf.io/projects/

Envoy 프록시는 Lyft사에서 개발한 프록시로 MSA 내 각 서비스를 위해 설계된 고성능 분산 프록시입니다.

기존 L3, L4 기반의 프록시들로는 다양한 요건들을 처리하기 힘들기 때문에 MSA 환경에서는 L7 기능을 갖춘 프록시의 필요성이 대두되었습니다.

Envoy 프록시는 L7 기반의 프록시로 HTTP, TCP, gRPC까지 다양한 프로토콜을 지원합니다.

앞서 말한 Istio가 Service Mesh로서 제공하는 기능이 모두 Istio의 메인 프록시인 Envoy를 통해 제공된다고 보시면 됩니다.

이상으로 이번 글을 마무리하겠습니다.

마이크로서비스 아키텍처(MSA)란?

H-Y-E-N — Thu, 11 Apr 2024 18:12:59 +0900

안녕하세요. HYEN입니다.

개념적인 내용도 다루고 넘어가면 좋을 것 같아 오늘은 간단하게 마이크로서비스 아키텍처가 무엇인지에 대해 알아보도록 하겠습니다.

쿠버네티스를 공부하면서 많이 들어본 개념인데 이 개념을 탄탄하게 정리한 적은 없는 거 같아 늘 마음에 걸렸기 때문에...

Contents

1. 마이크로서비스 아키텍처(MSA)란?

출처 : https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

마이크로서비스 아키텍처(MSA)는 시스템의 개별 기능을 서비스 단위로 잘라 서비스끼리 gRPC나 RESTful API 등으로 연계하여 시스템 전체를 구성하는 느슨한 결합(loose coupling) 아키텍처입니다.

전체 시스템을 여러 개의 작고 독립적인 부분으로 나누는 방식으로, 각 부분들은 특정한 업무나 기능을 담당하고 서로 통신하여 전체 시스템을 이루게 됩니다. 이러한 작고 독립적인 부분을 마이크로서비스라고 부르며, 이들은 독립적으로 배포하고 확장시키고 유지 보수 할 수 있습니다.

이를 통해 더 유연하고 확장성이 높은 시스템을 구성할 수 있으며 장애 발생 시 전체 시스템에 미치는 영향을 줄일 수 있습니다.

참고로, 마이크로서비스 아키텍처와 반대되는 개념은, 시스템 전체를 하나의 서비스로 구성한 모놀리식(monolithic) 아키텍처입니다.

2. 마이크로서비스 아키텍처(MSA)의 장점과 단점

장점은 다음과 같습니다.

각 서비스마다 프로그래밍 언어나 프레임워크 등의 기술을 자유롭게 선정할 수 있습니다. 각 서비스가 독립적으로 개발되는 마이크로서비스 아키텍처에서는 서비스별로 다른 기술 스택을 사용하는 것을 용이하게 합니다.
서비스별로 개발 규모나 성능을 확장시킬 수 있고 사용되는 코드가 상대적으로 적기 때문에 유연성이 높아지고 변경 사항을 롤백하는 것도 쉬워집니다.
특정 기능을 업데이트하거나 수정할 때, 해당 기능만 빠르게 배포할 수 있기 때문에 전체 시스템의 불필요한 재배포를 최소화할 수 있고 더 빠르게 개발할 수 있습니다. 즉, 서비스별로 독립적인 업데이트가 가능하여 릴리즈 사이클을 단축시킬 수 있으며 장애 영향 범위도 해당 서비스에 한정시킬 수 있게 됩니다.

쿠버네티스는 이러한 마이크로서비스 아키텍처와 잘 맞습니다.

마이크로서비스 아키텍처를 따르는 시스템을 쿠버네티스에 배포하게 되면, 한 개의 마이크로서비스를 한 개의 이미지로 개발하고 이를 한 개의 Deployment로 배포할 수 있습니다.

각 서비스 당 각기 다른 이미지 및 Deployment를 사용하기 때문에 독립적으로 개발할 수 있으며 더 유연하게 확장할 수 있게 됩니다.

단점은 다음과 같습니다.

여러 개의 독립적인 마이크로서비스를 구축하고 배포하고 처리하는 것은 복잡도가 높고 구현하기도 어렵습니다. 각 서비스가 어떻게 작동하는지, 다른 서비스들과 어떻게 통신하고 조화를 이루어야 하는지 이해하는 과정이 필요할 수 있습니다.
여러 프로그래밍 언어나 프레임워크를 사용하기 때문에 다른 마이크로서비스에서 사용했던 코드를 재사용하는 것이 어려울 수 있습니다.
전체 시스템 측면에서 볼 때, 네트워크 트래픽이 증가한다는 단점이 있을 수 있습니다. 각 서비스가 모두 독립적이기 때문에 서로 네트워크를 통해 통신해야 하는데, 이는 트래픽을 증가시키고 불필요한 레이턴시를 발생하게 할 수 있습니다.
하나의 시스템을 여러 마이크로서비스로 적절하게 분리하기 어려울 수도 있습니다.
시스템 전체에 대한 모니터링이 어렵습니다. 여러 마이크로서비스가 하나의 시스템을 구성하고 있기 때문에 각 서비스들의 의존성을 확인하거나 서비스 간 트래픽 레이턴시 등을 확인하기 어렵습니다.

따라서 작은 규모의 프로젝트거나, 하나의 기술 스택을 사용하여 개발이 가능한 경우 마이크로서비스 아키텍처를 도입하는 것은 오히려 추가적인 복잡성을 초래할 수 있기 때문에 도입 시 신중한 고려가 필요합니다.

또한 서비스 간 통신이 많이 발생하는 서비스일 경우 성능에 문제가 발생할 수 있기 때문에 마이크로서비스가 적절하지 않을 수 있습니다.

참고로, 상기 언급한 단점들 중 시스템 전체에 대한 모니터링이 어려운 점을 '서비스 매시'로 해결할 수 있습니다. 이에 대해서는 다음 글에서 다뤄보도록 하겠습니다.

Jenkins - GitHub Private하게 연결하기 (2)

H-Y-E-N — Wed, 10 Apr 2024 16:52:21 +0900

안녕하세요. HYEN입니다.

호다닥 이어서 테스트 내용을 정리해 보겠습니다.

이전 글 : https://with-cloud.tistory.com/36

Jenkins - GitHub Private하게 연결하기 (1)

안녕하세요. HYEN입니다. 오늘은 지난 글 (Windows에 Jenkins 설치하기)에 이어 Jenkins와 GitHub를 Private하게 연결하고 Build Pipeline을 구성하는 과정을 알아보도록 하겠습니다. Windows에 Jenkins 설치하기 안

with-cloud.tistory.com

Contents

3. GitHub Webhook Trigger 생성

이제, GitHub로 이동하여 Webhook Trigger를 생성해 보도록 하겠습니다.

상단의 [⚙️ Settings] > [Webhooks] > [Add webhook] 버튼을 클릭합니다.

Payload URL에 Jenkins Admin page의 주소를 입력한 후 그 뒤에 /github-webhook/을 추가해 줍니다.

[Add Webhook]을 클릭하여 Webhook 설정을 마무리합니다.

과연 정상적으로 Webhook 설정이 완료 되었을까요?

답은 NO입니다. 그렇다면, 이유는 뭘까요?

Webhook을 날리는 주체는 GitHub입니다.

따라서, GitHub는 자신이 Webhook을 날릴 대상이 누구인지를 알고 있어야 합니다.

그렇기 때문에 Payload URL에 가상 머신의 private ip를 입력해 줄 경우 GitHub는 대상을 못 찾게 되는 것이죠.

그래서 지금부터 GitHub가 무사히 Jenkins Admin page를 찾을 수 있도록 Azure Load Balancer를 구성해 보도록 하겠습니다.

Azure Load Balancer가 갑자기 왜 튀어나오는지 의문을 가질 수도 있으실 텐데요.

여기서 Azure Load Balancer는 SNAT를 해주는 역할이라고 보시면 됩니다.

GitHub가 Load Balancer로 트래픽을 보내면 Load Balancer는 Source ip(GitHub의 ip)를 Load Balancer의 public ip로 변환합니다.

이를 통해, GitHub는 Jenkins Server의 private ip 주소를 몰라도 webhook을 트리거할 수 있게 됩니다.

3.1 Load Balancer 생성

[기본 사항] 탭
- 형식은 [공개]로 변경해 줍니다.

[프런트 엔드 IP 구성] 탭

[백 엔드 풀] 탭
- 가상 네트워크를 선택하고 [+ 추가] 버튼을 클릭하여 Jenkins Server의 nic를 선택합니다.

[인바운드 규칙] 탭
- 인바운드 NAT 규칙을 추가합니다.
- 이를 통해, Azure Load Balancer의 프런트 엔드 IP:8080으로 들어오는 트래픽은 포트 8080을 통해 백 엔드 풀로 전달되게 됩니다.

여기서 인바운드 규칙에 대해 간단하게 설명하고 넘어가겠습니다.

인바운드 NAT 규칙이란?

선택한 IP 주소 및 포트 조합으로 전송된 인바운드 트래픽을 특정 가상 머신에 전달하는 규칙을 말합니다.

사실 인바운드 NAT까지만 추가를 해주면 될 줄 알았으나, 하기와 같은 에러가 발생했습니다.

Failed to connect to repository : Command "git.exe ls-remote -h -- https://github.com/{account name}/test.git HEAD" returned status code 128: stdout:
stderr: fatal: unable to access 'https://github.com/{account name}/test.git/': Failed to connect to github.com port 443 after 21185 ms: Couldn't connect to server

곰곰히 생각해 보니, 지금 구성으로는 Jenkins에서 GitHub로 트래픽이 나갈 수 없었습니다.

그렇기에 상기 에러가 발생하는 것이었습니다.

따라서, Jenkins가 해당 URL과 통신을 할 수 있도록 아웃바운드 규칙도 생성해 주도록 하겠습니다.

그렇다면, 아웃바운드 규칙은 또 무엇일까요?

아웃바운드 규칙이란?

가상 머신에서 외부로 향하는 트래픽을 관리하는 데 사용되는 규칙입니다.
가상 머신에서 생성된 트래픽을 관리하고 이를 외부로 라우팅하는 데 도움을 주는 역할을 합니다.

Jenkins가 설치된 가상 머신에서 GitHub 레포지토리로 트래픽을 보내야 하는데 아웃바운드 규칙이 없을 경우 이러한 트래픽이 GitHub까지 도달하지 못하게 됩니다.

그래서 하기 과정을 통해 아웃바운드 규칙을 생성합니다.

[아웃바운드 규칙] 탭

[검토 + 만들기] 탭을 클릭하여 유효성 검사 후 Load Balancer 생성을 진행합니다.

3.2 Windows 가상 머신 방화벽 규칙 생성

Local PC에서 Load Balancer의 public ip 그리고 포트 8080을 사용해 Jenkins의 Admin page에 접근하면 해당 트래픽은 가상 머신의 private ip 그리고 포트 8080으로 전달됩니다.

여기서 Load Balancer는 내부 네트워크로 트래픽을 전달하게 되는 것이기 때문에, 이 트래픽은 가상 머신 입장에서는 외부에서 들어온 것으로 인식되게 됩니다.

따라서 가상 머신의 서버 방화벽에서 해당 포트에 대한 접근을 허용하는 규칙을 생성해 주어야 합니다.

가상 머신에서 Windows 로고 키를 클릭한 후 firewall을 검색합니다. Windows Defender Firewall with Advanced Security를 클릭합니다.

[Inbound Rules]를 클릭한 후 우측의 [New Rule] 버튼을 클릭하여 새로운 Inbound Rule을 생성합니다.

Rule Type은 “Port”를 선택합니다. (Jenkins가 돌아가는 8080 포트를 열어줘야 하기 때문입니다.)

Specific local ports를 선택한 후 8080을 입력합니다.

나머지는 Default 값을 유지한 후 이름을 지정해 줍니다.

Finish 버튼을 클릭하여 Inbound Rule 생성을 완료합니다.

Load Balancer의 public ip:8080으로 접근하면 하기 스크린샷과 같이 Jenkins Admin Page가 정상적으로 뜨는 것을 확인할 수 있습니다.

3.3 GitHub Webhook Trigger 생성

이제 Payload URL을 변경하러 GitHub로 이동합니다.

기 생성한 Webhook에 대해 [Edit] 버튼을 클릭합니다.

Payload URL에서 가상 머신의 private ip를 Load Balancer의 public ip로 변경한 후 [Update webhook]을 클릭하여 변경 사항을 저장합니다.

그 후 webhook을 클릭하여 Recent Deliveries 탭에서 [Redeliver] 버튼을 클릭합니다.

하기와 같이 ✅ 표시가 출력되면 webhook이 정상적으로 추가된 것입니다.

4. Jenkins Pipeline 실행하기

모든 구성이 끝났으니 지금부터는 Jenkins Pipeline을 실행해 보도록 하겠습니다.

4.1 소스 코드 구성 확인

각 Pipeline의 Jenkinsfile은 앞서 확인을 했으니 본 테스트의 Flow를 간단하게 정리한 후 소스 코드에 대해 확인해 보겠습니다.

1️⃣ 첫 번째 Build Pipeline
test라는 레포지토리의 Source Code를 clone 해 옴 (저장 위치 확인 목적) → 두 번째 Build Pipeline 트리거

2️⃣ 두 번째 Build Pipeline
result라는 레포지토리의 README.md 파일에 첫 번째 Build Pipeline의 BUILD_NUMBER를 저장 → Git Push를 통해 GitHub에 소스 코드 업로드

사실 위와 같은 Flow는 굉장히 간단하고 Pipeline으로서의 의미는 크게 없긴 하지만,

하나의 Build Pipeline에서 다른 Pipeline을 트리거하고, built-in 변수를 사용하여 GitHub에 소스 코드를 업로드 하는 과정을 테스트하고자 작성하였음을 말씀 드립니다.

현재 result 레포지토리의 README.md 파일은 하기와 같습니다.

4.2 Jenkins Pipeline Build

Local PC에서 test 레포지토리의 소스 코드 중 일부를 변경한 후 git push를 진행합니다.

첫 번째 Pipeline이 자동으로 트리거 됨을 확인합니다.

"Trigger Second Pipeline" stage가 실행되면서 두 번째 Pipeline이 트리거 됩니다.

result 레포지토리를 확인한 결과 README.md 파일에 하기 스크린샷과 같이 Build Number에 대한 값이 반영된 것을 확인할 수 있습니다.

추가적인 테스트를 위해 첫 번째 Build Pipeline을 수행했다가 강제 중지한 후 다시 Build를 진행해 보도록 하겠습니다.

이 경우, 두 번째 Pipeline은 실행되지 않을 것이기 때문에 Build Number는 2가 되겠지만, 첫 번째 Pipeline은 Build Number가 3이 되기 때문에 Build number from first pipeline : 3이 result 레포지토리에 반영될 것입니다.

다시 Local PC에서 코드 일부를 변경한 후 Commit을 진행합니다.

첫 번째 Pipeline이 동작하면 중간에 중지합니다.

다시 Local PC에서 코드를 수정한 후 Commit을 진행합니다.

첫 번째 Pipeline이 자동으로 트리거되고 두 번째 Pipeline도 성공적으로 트리거가 되는 것을 확인합니다.

두 번째 Pipeline도 성공적으로 완료된 것을 확인합니다.

GitHub의 result 레포지토리에서 README.md 파일에 저장된 값을 확인합니다.
저장된 값이 Build number from first pipeline: 3임을 확인할 수 있습니다.

4.3 초기 Working Directory 확인

Jenkins Pipeline이 돌면서 Git Clone 해오는 소스 코드는 어디에 저장이 될까요?

확인하고자 하는 Jenkins Project를 클릭한 후 Build 내역 중 하나를 클릭하면 하기 스크린샷과 같이 [Workspaces]라는 탭이 보이게 됩니다.

[Workspaces] 탭에서 초기 Working Directory를 확인할 수 있습니다.

실제 Windows 가상 머신에서 저 경로로 이동하면 다음과 같이 소스 코드가 저장되어 있는 것을 확인할 수 있습니다.

그렇다면 이러한 Working Directory를 변경할 수 있을까요?

답은 YES입니다.

먼저 Jenkins의 Home Directory(C:\ProgramData\Jenkins\.jenkins)로 이동한 후 config.xml 이라는 이름의 파일을 엽니다.

Home Directory는 [Manage Jenkins] > [System]에서 확인할 수 있습니다.

코드에서 workspaceDir이라는 부분을 찾습니다. 본 테스트에서는 workspace directory 하위에 hyeintest라는 이름의 새로운 directory를 생성한 후 그 안에 코드를 저장해 보도록 하겠습니다.

※ 상기 과정을 진행한 후에는 Jenkins Server를 재기동해야 합니다.※

두 번째 Pipeline의 Jenkinsfile에 WORKSPACE라는 built-in 변수 값을 README.md 파일에 적는 부분을 추가해 줍니다.

첫 번째 Pipeline이 실행되도록 test 레포지토리의 내용을 수정한 후 commit을 진행합니다.

자동으로 첫 번째 Pipeline이 실행되고 이어서 두 번째 Pipeline이 트리거됩니다.

Build 번호를 클릭한 후 Workspaces를 클릭합니다.

하기 스크린샷과 같이 Working Directory의 경로가 변경된 것을 확인할 수 있습니다.

실제 파일 탐색기에서 해당 경로로 이동할 시 하기와 같이 지정해준 Working Directory에 소스코드가 저장되어 있는 것을 확인할 수 있습니다.

result 레포지토리의 README.md 파일에도 첫 번째 Pipeline의 Build Number와 현재 Working Directory에 대한 절대 경로가 제대로 출력된 것을 확인할 수 있습니다.

이렇게 하여 드디어 Windows VM에 Jenkins를 설치하고 Jenkins와 GitHub를 private하게 연결한 후 Build Pipeline까지 돌려 보는 대장정을 마무리하였습니다!

다음에는 개념적인 내용으로 찾아오도록 하겠습니다.

Jenkins - GitHub Private하게 연결하기 (1)

H-Y-E-N — Wed, 10 Apr 2024 12:47:40 +0900

안녕하세요. HYEN입니다.

오늘은 지난 글 (Windows에 Jenkins 설치하기)에 이어 Jenkins와 GitHub를 Private하게 연결하고 Build Pipeline을 구성하는 과정을 알아보도록 하겠습니다.

Windows에 Jenkins 설치하기

안녕하세요. HYEN입니다. 오늘은 Windows에 Jenkins를 설치하는 방법에 대해 알아보겠습니다. 문득 Jenkins는 Linux에만 설치를 해봤다는 생각이 들어서 이번 글을 적게 되었습니다. 이번 글에서는 Jenkins

with-cloud.tistory.com

Windows는 어떤 디렉토리를 초기 working directory로 바라보는지
private ip만 붙어 있는 가상 머신의 경우 어떻게 GitHub와 통신하는지

이 두 가지 궁금함으로 이번 테스트를 시작하게 되었는데요.

이렇게 오래 걸릴 테스트가 아니었음에도 불구하고 Jenkinsfile을 무한 루프 돌게 만들어 버리는 바람에 시간이 다소 걸렸습니다.

Contents

1. Spoke 가상 머신에 Git 설치하기

가장 먼저 Spoke 가상 머신에 Git을 설치해 줍니다.

그렇지 않으면 아래에서 설명할 에러가 발생할 수 있습니다.

https://git-scm.com/download/win로 이동하여 Windows용 Git을 다운로드 합니다.

(default 값을 사용하여 설치를 진행하면 됩니다.)

Git - Downloading Package

Download for Windows Click here to download the latest (2.44.0) 32-bit version of Git for Windows. This is the most recent maintained build. It was released about 2 months ago, on 2024-02-23. Other Git for Windows downloads Standalone Installer 32-bit Git

git-scm.com

2. Jenkins Pipeline 생성

2.1 Jenkins Pipeline 생성 - 첫 번째 Pipeline

먼저 테스트용 Jenkins Pipeline을 생성합니다.

이번 테스트에서 Build Pipeline은 두 개를 생성할 예정입니다.

(원하는 결과값을 내기 위해서는 두 개로 Pipeline을 분리하는 게 최선이었는데 혹시 좋은 팁 있으면 알려주시면 감사하겠습니다.)

첫 번째 파이프라인은 두 번째 파이프라인의 트리거 용으로 사용합니다.

Build가 잘 되는지만 확인하기 위해서는 이렇게 구성할 필요가 없으나 BUILD_NUMBER라는 Jenkins의 built-in 변수를 사용해 보고자 두 개의 Pipeline으로 구성하였습니다.

Jenkins 관리 페이지에서 좌측 상단의 [+ New Item]을 클릭합니다.

Project 이름을 입력하고 Project 타입은 [Pipeline]을 선택합니다.

Configure의 General 탭에서 Build Triggers 옵션 중 "GitHub hook trigger for GITScm polling"을 선택합니다.

다음 step으로 넘어가기 전 GitHub hook trigger for GITScm polling 옵션이 무엇인지 알아보도록 하겠습니다.

GitHub hook trigger for GITScm polling이란?

GitHub는 이벤트가 발생할 때 webhook을 트리거합니다.
webhook은 이벤트 발생시 지정된 URL로 HTTP POST 요청을 보내는 기능을 말합니다.
Jenkins는 이러한 webhook을 통해 GitHub의 변경 사항을 감지합니다.
Jenkins는 변경 사항이 없어도 주기적으로 저장소를 확인하고 변경 사항이 있는지 여부를 확인하게 되는데 이때 GITScm polling을 사용하게 됩니다.
이것이 바로 변경 사항이 발생하지 않아도 Jenkins가 build를 트리거할 수 있는 이유입니다.

Configure의 Pipeline 탭에서 Definition을 “Pipeline script from SCM”으로 변경합니다.
그 후, SCM에 대해 “Git”을 선택합니다.

Repository에 GitHub의 URL 주소를 입력합니다. (본 테스트의 경우 기존에 작성해 둔 Terraform 코드와 관련된 Repository를 사용합니다.)
- GitHub로 이동해 [< > Code] 버튼을 클릭하여 HTTPS 형식의 GitHub URL 주소를 복사해 옵니다.

다시 Jenkins로 돌아와 복사한 Repository URL을 붙여 넣은 후 GitHub 계정 이름과 PAT를 사용하여 Credentials을 생성합니다.
- PAT 발급 관련 설명은 https://with-cloud.tistory.com/19#2._GitHub_-_Jenkins_연결를 참고해 주세요.

마지막으로 Configure의 Pipeline 탭에서 Script Path를 확인합니다.
GitHub Repository 내 Jenkinsfile의 위치를 확인합니다. GitHub Repository의 가장 상단에 Jenkinsfile이 존재할 경우 default 경로를 변경할 필요는 없습니다.

Project 설정이 완료되었으면 [Save] 버튼을 클릭하여 변경 사항을 저장합니다.

2.2 Jenkins Pipeline 생성 - 두 번째 Pipeline

Project 이름을 입력하고 Project 타입은 [Pipeline]을 선택합니다.

첫 번째 Pipeline에 의해 트리거 되어야 하기 때문에 다른 설정은 하지 않고 Pipeline 부분만 설정을 진행해 줍니다.
Repository URL은 결과값이 저장될 GitHub 레포지토리를 지정해 줍니다. (Credentials의 경우 이전에 설정한 것을 사용해도 무방합니다.)

2.3 Jenkinsfile 구성 확인

첫 번째 Jenkins Pipeline의 Jenkinsfile은 하기와 같습니다.
- test라는 이름의 GitHub 레포지토리를 clone해 오는 stage와 두 번째 Pipeline을 트리거하는 stage로 이루어져 있습니다.
- BUILD_NUMBER라는 built-in 변수를 parameters를 사용하여 두 번째 Pipeline에 전달하게 됩니다.

두 번째 Jenkins Pipeline의 Jenkinsfile은 하기와 같습니다.
- environment block에서 첫 번째 Pipeline의 Build 번호를 FIRST_PIPELINE_BUILD_NUMBER라는 변수에 저장합니다.
- Build stage에서 README.md 파일에 현재 Pipeline의 Build 번호를 추가하고 Commit and Push stage에서 이를 result라는 이름의 GitHub 레포지토리에 push합니다.

2.4 Jenkinsfile 구성 확인

앞서 말씀 드렸듯이, Pipeline 구성 시 Pipeline 탭의 Repository URL 입력 부분에서 하기와 같은 이슈가 발생할 수 있습니다.

Failed to connect to repository : Error performing git command: git.exe ls-remote -h https://github.com/{계정 이름}/test.git HEAD

이와 같은 에러가 발생하는 이유는 서버에 Git이 설치 되어 있지 않기 때문에 발생하는 문제이므로 1번 과정과 같이 Git을 서버에 설치한 후 Jenkins를 다시 시작해 주면 됩니다.

Jenkins를 다시 시작하는 방법은 아래와 같습니다. (Windows 기준)

윈도우 로고 키를 마우스 우클릭한 후 Task Manager를 클릭합니다.

Services 탭으로 이동하여 Jenkins를 검색합니다.

Jenkins Service를 마우스 우클릭한 후 [Restart]를 눌러 Jenkins를 다시 실행합니다.

이렇게 Pipeline을 생성하는 부분까지 알아보았는데요.

다음 글에서는 GitHub Webhook Trigger를 생성하고 Jenkins Pipeline을 실행하는 과정에 대해 다뤄보겠습니다.

Azure Cloud Shell에 Private하게 접근하기 (2)

H-Y-E-N — Wed, 3 Apr 2024 15:45:40 +0900

안녕하세요. HYEN입니다.

오늘은 지난 글에 이어 Azure Relay를 사용하여 Azure Cloud Shell을 가상 네트워크에 배포하는 방법에 대해 알아보겠습니다.

지난 글 : https://with-cloud.tistory.com/31

Azure Cloud Shell에 Private하게 접근하기 (1)

안녕하세요. HYEN입니다. 오늘은 Azure Cloud Shell에 Private하게 접근하는 방법에 대해 알아보겠습니다. 결과부터 말하자면, Local PC에서 Cloud Shell에 접근하는 것 자체를 제어하는 것은 하기에 적은

with-cloud.tistory.com

Contents

3. 가상 네트워크에서 Cloud Shell 사용하기 - Azure Relay

※ 3번에서 진행되는 리소스는 Southeast Asia에 배포합니다. Korea Central로 region 지정 시 오류가 발생합니다. ※

3.1 Azure Relay란?

먼저 Azure Relay가 무엇인지부터 확인하고 넘어가도록 하겠습니다.

Azure Relay는 클라우드와 온프레미스 서비스가 서로 연결될 수 있는 지점을 제공하는 Azure의 서비스입니다.
만약, 온프레미스에 있는 서비스가 클라우드 구성 요소와 통신해야 하지만 VPN 또는 ExpressRoute와 같이 온프레미스와 클라우드 간 사설 네트워크 망을 구축하거나, 방화벽을 통해 특정 포트를 여는 방식을 사용하고자 하지 않을 경우 Azure Relay를 사용할 수 있습니다.

3.2 사전 리소스 생성

템플릿을 사용하여 가상 네트워크에 Cloud Shell을 배포하기 전에 사전에 생성해야 하는 리소스를 배포하고 필요한 데이터를 확인해야 합니다.

[체크리스트]

✅ 가상 네트워크 생성
✅ Azure Container Instance OID 확인
✅ Azure Relay 네임스페이스 생성
✅ NSG 생성

먼저, 가상 네트워크를 생성합니다.

서브넷의 경우 컨테이너 서브넷, 릴레이 서브넷, 스토리지 서브넷이 필요합니다.

[기본 사항] 탭

[IP 주소] 탭 (optional)
- 각 서브넷의 이름과 대역을 메모해 둡니다. (ARM Template에서 생성해 줘도 됩니다.)

[검토 + 만들기] 탭을 클릭하여 유효성 검사 후 가상 네트워크 생성을 진행합니다.

다음으로, Azure Container Instance OID를 확인합니다.

[Microsoft Entra ID] > [개요] > “azure container instance service” 검색

[개체 ID]를 복사한 후 메모해 둡니다.

Azure Relay 네임스페이스를 생성합니다.

[기본 사항] 탭

[검토 + 만들기] 탭을 클릭하여 유효성 검사 후 Relay 생성을 진행합니다.

NSG를 생성합니다.

[기본 사항] 탭

[검토 + 만들기] 탭을 클릭하여 유효성 검사 후 NSG 생성을 진행합니다.

3.3 템플릿을 사용하여 가상 네트워크에 Cloud Shell 배포

ARM Template을 사용하여 가상 네트워크에서 Cloud Shell 리소스를 생성합니다.

(https://learn.microsoft.com/ko-kr/samples/azure/azure-quickstart-templates/cloud-shell-vnet/)

하기 스크린샷과 같이 [Deploy to Azure] 버튼을 클릭하여 템플릿 페이지로 이동합니다.

하기 스크린샷과 같이 배포에 필요한 정보를 입력합니다.

[검토 + 만들기] 탭을 클릭하여 ARM Template을 통한 배포를 진행합니다.

3.4 템플릿을 사용하여 가상 네트워크 내에 Storage Account 생성

ARM Template을 사용하여 가상 네트워크에서 Cloud Shell 리소스를 생성합니다.

(https://learn.microsoft.com/ko-kr/samples/azure/azure-quickstart-templates/cloud-shell-vnet-storage/)

하기 스크린샷과 같이 [Deploy to Azure] 버튼을 클릭하여 템플릿 페이지로 이동합니다.

하기 스크린샷과 같이 배포에 필요한 정보를 입력합니다.

[검토 + 만들기] 탭을 클릭하여 ARM Template을 통한 배포를 진행합니다.

3.5 가상 네트워크를 사용하도록 Cloud Shell 구성 - Local PC

배포가 완료된 후 사용자 별 Private Cloud Shell 인스턴스를 사용하도록 구성을 변경해야 합니다.

Cloud Shell을 실행한 후 ⚙️ 버튼을 클릭하여 [사용자 설정 다시 설정] 버튼을 클릭합니다.

사용자 설정 다시 설정 창이 표시되면 [초기화]를 클릭합니다.

Azure Cloud Shell 시작 창이 표시되면 [Bash]를 클릭합니다.

스토리지와의 연결을 위해 하기 스크린샷과 같이 VNET 격리 설정을 진행합니다.

하기 스크린샷과 같이 Virtual Network에 있는 Cloud Shell에 요청을 보낸 후 Cloud Shell에 연결되는 것을 확인할 수 있습니다.

만약, Cloud Shell에서 ifconfig를 날리면 어떻게 될까요?

하기와 같은 ip가 출력됩니다.

이는 vnet-cs-hyein이라는 이름의 가상 네트워크 내 존재하는 snet-con이라는 이름의 서브넷에 속해 있는 ip입니다.

따라서 Cloud Shell이 가상 네트워크 내에 잘 격리되어 있는 것을 확인할 수 있습니다.

이번에는 Azure Relay를 확인해 보겠습니다.

[Azure Relay] > [엔터티] > [하이브리드 연결]로 이동하면 연결이 1개 생성되어 있는 것을 확인할 수 있습니다.

그렇다면 하이브리드 연결은 무엇일까요?

하이브리드 연결은 웹 소켓 또는 HTTP(S)를 통해 요청을 보내고 응답을 받을 수 있도록 하는 연결 기능입니다.
쉽게 말하자면 요청을 보내고 받는 각각의 애플리케이션 또는 당사자들이 각자의 네트워크 내에서 도달할 수 있는 Azure 영역에 랑데부, 즉 서로가 만날 수 있는 지점를 만드는 것을 하이브리드 연결이라고 할 수 있습니다.
그래서 각자의 네트워크가 서로 연결되어 있지 않아도 직접 연결된 것처럼 릴레이를 통해 요청 및 응답을 교환할 수 있게 됩니다.

이 외에도 Azure Relay에서는 WCF 연결도 지원하고 있지만 이 부분은 이번 글에서는 다루지 않도록 하겠습니다.

그렇다면, Cloud Shell을 통해 private ip만 attach된 Linux 가상 머신에 접근할 수 있을까요?

이를 확인해 보기 위해 vnet-cs-hyein이라는 이름의 가상 네트워크에 snet-vm이라는 이름의 서브넷을 생성합니다.

snet-vm이라는 이름의 서브넷을 생성하고 ip 대역은 172.19.3.0/24로 할당합니다.

Linux 가상 머신을 생성합니다. (자세한 내용은 생략합니다.)

먼저 Cloud Shell에서 Linux 가상 머신의 private ip로 ping을 날려 보겠습니다.

Cloud Shell을 가상 네트워크에 배포하지 않은 환경에서 가상 머신의 private ip로 ping을 날리면 하기와 같이 packet loss가 발생합니다.

이 두 환경의 차이를 통해서 Cloud Shell이 가상 네트워크 내에 잘 구성되었다는 것을 알 수 있습니다.

그렇다면 SSH 접근은 가능할까요?

답은 YES입니다.

가상 네트워크 내에서 동작하는 것이기 때문에 가상 머신의 NSG에 별도의 인바운드 규칙 추가 없이 접근이 가능합니다.

만약 테스트하려는 가상 머신이 배포되어 있는 가상 네트워크와 Cloud Shell을 격리한 가상 네트워크가 서로 다르다면 VNet Peering만 해주면 됩니다.

3.6 가상 네트워크를 사용하도록 Cloud Shell 구성 - Virtual Machine

이번에는 가상 머신에서 Cloud Shell을 실행했을 때 Local PC에서 접근하는 것과 어떤 차이가 있는지 알아보도록 하겠습니다.

이를 위해 먼저 Windows 가상 머신을 생성합니다. (자세한 내용은 생략합니다.)

RDP를 통해 Windows 가상 머신에 접근합니다.

Azure Portal로 이동하여 Cloud Shell을 실행합니다.
하기 스크린샷과 같이 별도의 설정 없이 바로 Cloud Shell을 사용할 수 있는 것을 확인할 수 있습니다.

이렇게 Azure Relay를 사용하여 Local PC에서 가상 네트워크에 격리된 Cloud Shell을 사용하는 방법, 그리고 가상 머신에서 가상 네트워크에 격리된 Cloud Shell을 사용하는 방법에 대해 알아보았습니다.

저번 글에서도 말씀 드렸듯이, Cloud Shell에 대한 완전한 접근 차단을 위해서는 별도의 도메인을 방화벽 등에서 차단해야 한다는 점 참고해 주시면 감사하겠습니다.

다음 글은 Jenkins와 GitHub를 Private하게 연결하는 법에 대해 다뤄보겠습니다.

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #04 Always On 가용성 그룹 구성

admin_cloud — Tue, 2 Apr 2024 17:06:36 +0900

안녕하세요. TAK 입니다:)

해당 포스팅을 마지막 으로 시리즈의 막을 내리며,

이번에는 SQL Server 고가용성을 위한 "#04 Always On 가용성 그룹"에 관한 내용을 다룹니다.

#01 ~ 03 진행한 구성은 계속되는 과정에서 필수적인 환경으로 아래 링크를 참고하여 함께 팔로잉 해주세요!

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #01 용어 정리 및 구성도 공유 그리고 AD 구축

안녕하세요. TAK 입니다:) 봄이 부쩍 가까워진 3월에 다시 인사드립니다(^꾸_벅^) 회사 업무로 Azure VM 기반 MSSQL FCI 구성한 적이 있는데.. 이후에 Always ON 가용성 그룹 구성이 자꾸 아른?..거려

with-cloud.tistory.com

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #02 Failover Cluster 구성

안녕하세요. TAK 입니다:) 일교차가 큰 요즘.. 다들 잘 지내고 계신가요? 감기 조심하세요! 이어지는 포스팅인 만큼 흐름을 이어가고자 빠르게? 다시 찾아왔습니다 (저만의 초기 감기 꿀팁을

with-cloud.tistory.com

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #03 SQL Server 구성

안녕하세요. TAK 입니다:) 벚꽃이 개화하면서, 봄이 가까워졌음을 알리는 요즘 인사드립니다 (아직까지 일교차가 크기에 건강 유의하셔요 ) 이번에는 실제 SQL Server 설치과 구성을 위한 단계

with-cloud.tistory.com

그럼 오늘도 힘차게 출발하겠습니다

Contents

1. 가용성 그룹 생성 전, 구성 사항

1-1. Enable Always On 가용성 그룹

: 사전 단계에서 SQL Server 정상 설치되어 있으며, SSMS를 통해 접근하게 됩니다.

이때, Always On High Availability 클릭하게 된다면, SQL Server Configuration Manager를 통해서 사용가능한 상태로 설정하는 에러와 함께 가이드하기 때문에 Enable 하는 사전 작업을 진행합니다.

SQL Server Configuration Manager 실행

SQL Server Servies > SQL Server(MSSQLSERVER) > 오른쪽 마우스 클릭 후, Properties(속성)

Enable Always On Availability Groups

구성 사항을 서비스에 적용하기 위해, Restart

→ 상기 작업은 각 SQL Server(복제본 서버)에서도 동일하게 Enable 적용하여야 합니다.

1-2. 데이터베이스 백업

: 가용성 그룹 생성 전, 요구 사항(가용성 데이터베이스)으로 실제 가용성 그룹 생성 후에 데이터베이스를 추가하기 위해서는 전체 데이터베이스 백업을 하나 이상 소유하여야 합니다.

이는 다음과 같은 이유로 필요로 하게 됩니다.

- 가용성 그룹의 초기 데이터 동기화: 가용성 그룹을 구성할 때, 가용성 그룹에 속하는 모든 데이터베이스의 초기 동기화를 위해 백업이 사용됩니다. 이러한 초기 백업은 주요 데이터베이스의 백업을 사용하여 데이터베이스의 상태를 가용성 그룹의 다른 노드로 전송합니다. 이는 가용성 그룹의 복제된 데이터베이스들이 동일한 출발점에서 시작할 수 있도록 보장합니다.

- 가용성 그룹의 가동성 보장: 가용성 그룹을 구성하면 데이터베이스의 가용성과 장애 조치 기능을 향상시키는 것이 목적입니다. 초기 백업을 설정함으로써 데이터 손실을 방지하고 장애 발생 시 데이터베이스를 복구하는 데 필요한 준비를 합니다.

- 복구 지점의 설정: 초기 백업은 가용성 그룹의 복구 지점을 설정하는 데 사용됩니다. 복구 지점은 장애 발생 시 데이터베이스를 복구할 때 사용되는 시점을 나타냅니다. 초기 백업을 설정하면 이러한 복구 지점을 명확하게 정의할 수 있습니다.

- 성능 및 안정성: 초기 백업을 사용하여 가용성 그룹을 생성하면 데이터 전송 속도를 최적화하고 데이터 동기화 프로세스를 안정화할 수 있습니다. 또한 가용성 그룹을 생성하는 동안 발생할 수 있는 네트워크 문제 또는 장애에 대비하여 데이터의 안정성을 높일 수 있습니다.

공유 백업 포함하여 구선 전 고려해야 할 사항들은 아래 Docs를 참고해 주세요.

가용성 그룹: 필수 구성 요소, 제한 사항 및 권장 사항 - SQL Server Always On

SQL Server에 Always On 가용성 그룹을 배포하기 위한 필수 조건, 제한 사항 및 권장 사항에 대한 설명입니다.

learn.microsoft.com

1-2-1. 공유 폴더 생성

SQL Server의 Server Manager > Computer Management

Shared Folders > Shares > New Share

공유 폴더 Permission > 관리자 계정 선

공유 폴더 구성 및 생성 완료 확인

1-2-2. SQL Server의 (Sample)DB의 백업 설정

사전에 생성한 SampleDB에 대한 Back Up 진행

2. 가용성 그룹

2-1. 가용성 그룹 만들기

Always On High Availability > New Availability Group Wizard

가용성 그룹 이름 입력

가용성 그룹에 포함할 데이터베이스 선택
- 사전에 백업을 진행하였기에 조건에 충족한다는 멘트를 확인할 수 있습니다.

2-2. 가용성 그룹 생성(+ Add Replica)

: 위 단계와 이어지는 단계로 해당 작업은 SQL-01, 즉 Primary(주) 서버에서 진행한 단계로 가용성 그룹에 추가로 Secondary(보조) 서버를 추가하는 과정입니다.

우선 주(Primary) 서버와 보조 혹은 복제(Secondary) 서버의 네트워크 설정을 진행합니다.

2-2-1. SQL Server 간 네트워크 통신을 위한 설정

: 각 SQL Server들이 가용성 그룹으로 묶고, 네트워크 통신을 하기 위한 작업입니다. (모든 SQL Server에서 동일하게 진행)

SQL Server Configuration Manager

SQL Server Network Configuration > Protocols for MSSQLSERVER > TCP/IP Enable

SQL Server Serives 재시작

2-2-2. 보조 혹은 복제(Replica) 서버 가용성 그룹에 추가

Specify Replicas > Add Replica...

SQL-02, SQL-03 서버 연결

정상적으로 등록됨을 확

Endpoints 확인

Listener 설정
- 추후 Azure Load Balancer의 IP로 Cluster의 Listener 설정할 예정으로 현 단계에서 Do not create 선택

위 단계에서 구성한 공유 폴더를 [Full database and log backup] 파일 저장 경로로 지정

구성 적용 전 유효성 확인

가용성 그룹 최종 Summary 확

2-2-3. 가용성 그룹 확인

: 지금까지 구성한 값들이 정상적으로 적용되어 생성되었는지 확인합니다.

3. Listener(수신기)

: 장애 조치(failover) 클러스터에서 가용성 그룹 Listener(수신기)를 생성합니다. Listener(수신기)는 DB의 V(Virtual)IP로 해당 IP로 Failover 시, Cluster의 Master 혹은 Slave의 Role이 바뀌어도 해당 IP를 그대로 사용하기 위해 사용되며, 해당 IP 주소는 사용하지 않는 IP를 입력하여합니다.

(**Azure의 경우, 브로드캐스트 하지 못해 Internal Load Balancer를 연결해야 합니다.)

3-1. Azure Load Balancer 생성 및 Clienc Access Point 설정

Internal Load Balancer 구성
- 해당 과정에서는 LB 배포하는 과정은 생략되어 있음을 참고해 주세요.
- Internal Load Balancer의 경우, 프라이빗 형식으로 서브넷 내 배포되며, 서브넷 대역의 사설 IP를 할당받습니다.

생성한 Internal Load Balancer의 IP(172.168.1.59)의 값을 수신기 IP로 등록
- 가용성 그룹 선택 > 클라이언트 액세스 지점 확인

* Fail over Cluster의 Network 정보 확인

클라이언트 액세스 포인트 지정

구성 값 반영 여부 확인

Dependency Report 확인
- 위 단계에서 구성한 값들을 바탕으로 Fail over 조치가 이뤄질 있도록 종속성이 올바르게 연결되었는지 확인

3-2. Listener Online(Up) 구성

: 해당 작업을 통해 수신기 상태를 온라인으로 전환합니다.

PowerShell 명령어를 통해 클러스터 매게 변수 설정되며, 옵션은 다음과 같습니다.

해당 옵션값은 사용자 환경에 맞게 변수를 업데이트하여 사용합니다.

- $ClusterNetworkName은 네트워크를 선택하여 장애 조치(failover) 클러스터 관리자에서 이름을 찾습니다. 네트워크를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다. $ClusterNetworkName은 일반 탭의 이름 아래에 있습니다.

- $IPResourceName은 장애 조치(failover) 클러스터 관리자의 IP 주소 리소스에 지정된 이름입니다. 이 이름은 역할을 선택하여 장애 조치(failover) 클러스터 관리자에서 찾을 수 있습니다. SQL Server AG 또는 FCI 이름을 선택하고, 서버 이름 아래에서 리소스 탭을 선택하고, IP 주소 리소스를 마우스 오른쪽 단추로 클릭하고, 속성을 선택합니다. 올바른 값은 일반 탭의 이름 아래에 있습니다.

- $ListenerILBIP는 가용성 그룹 수신기에 대해 Azure 부하 분산 장치에서 만든 IP 주소입니다. SQL Server AG/FCI 수신기 리소스 이름과 동일한 속성 페이지의 장애 조치(failover) 클러스터 관리자에서 $ListenerILBIP를 찾습니다.

- $ListenerProbePort는 가용성 그룹 수신기에 대해 Azure 부하 분산 장치에서 구성한 포트(예: 59999)입니다. 사용하지 않는 모든 TCP 포트는 유효합니다.

명령어 실행

$ClusterNetworkName = "Cluster Network 1" # The cluster network name. Use Get-ClusterNetwork on Windows Server 2012 or later to find the name.
$IPResourceName = "IP Address 172.168.1.59" # The IP address resource name.
$ListenerILBIP = "172.168.1.59" # The IP address of the internal load balancer. This is the static IP address for the load balancer that you configured in the Azure portal.
[int]$ListenerProbePort = 59999

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ListenerILBIP";"ProbePort"=$ListenerProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}

설정 이후, [Start Role] 클릭하여 온라인 상태로 전환

가용성 그룹의 수신기(Listener) 정보 확인

MSSQL Always On 가용성 그룹을 위한 Azure의 NSG 설정값 정보
- SQL Server: 기본 인스턴스에 대해 1433
- 데이터베이스 미러링 엔드포인트: 5022 또는 사용 가능한 모든 포트
- 가용성 그룹에 대한 부하 분산 장치 IP 주소 상태 프로브: 59999 또는 사용 가능한 포트
- 클러스터 코어에 대한 부하 분산 장치 IP 주소 상태 프로브: 58888 또는 사용 가능한 포트

지금까지 "SQL Server Always On 가용성 그룹 on Azure" 중 Always On 가용성 그룹 구성 단계를 알아보았습니다. 이번 과정을 마지막으로 시리즈의 막을 내리겠습니다!

이번 포스팅을 준비하면서 여러 구성과 설정 등 고려해야 할 점들 파악하면서 많은 것들을 배울 수 있는 시간이었습니다!

(함께 따라오시는 분들도 그렇길 바라면서...ㅎㅎ)

(!!많관부!!) 다음에도 유익한 주제로 찾아뵙겠습니다

여러분의 생각하는 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

Windows에 Jenkins 설치하기

H-Y-E-N — Tue, 2 Apr 2024 15:22:13 +0900

안녕하세요. HYEN입니다.

오늘은 Windows에 Jenkins를 설치하는 방법에 대해 알아보겠습니다.

문득 Jenkins는 Linux에만 설치를 해봤다는 생각이 들어서 이번 글을 적게 되었습니다.

이번 글에서는 Jenkins를 설치할 가상 머신을 생성하는 과정과 Jenkins를 Windows VM에 설치하는 방법에 대해 다뤄보고,

다음 글에서는 Jenkins Pipeline가 동작하며, GitHub와 같은 소스 코드 레포지토리의 소스 코드가 Windows VM의 어떤 Directory로 떨어지는지 확인해 보고자 합니다.

Contents

1. 테스트 환경 생성

[시나리오]

RDP(3389) 포트를 통해 외부에서 접근할 수 있는 Windows 가상 머신을 한 대 생성합니다.
해당 가상 머신에서 접근 가능한, Public IP가 없는 Window 가상 머신을 한 대 생성합니다.
두 가상 머신은 다른 가상 네트워크에 존재하며, VNet Peering을 통해 연결되어 있습니다.

※ 리소스 그룹 한 개에 모든 리소스를 전부 다 배포할 예정입니다.※

1.1 리소스 그룹 생성

[기본] 탭

[검토 + 만들기] 버튼을 클릭하여 리소스 그룹 생성을 완료합니다.

1.2 가상 네트워크 생성 - Hub

[기본 사항] 탭

[IP 주소] 탭

[검토 + 만들기] 버튼을 클릭하여 Hub 가상 네트워크 생성을 완료합니다.

1.3 가상 네트워크 생성 - Spoke

[기본 사항] 탭

[IP 주소] 탭

[검토 + 만들기] 버튼을 클릭하여 Spoke 가상 네트워크 생성을 완료합니다.

1.4 VNet Peering 구성

[가상 네트워크] > [설정] > [피어링] > [+ 추가] 버튼을 클릭하여 피어링 구성을 진행합니다.

피어링 링크 이름 및 원격 가상 네트워크를 선택한 후 [추가] 버튼을 클릭하여 피어링 구성을 완료합니다.

1.5 가상 머신 생성 (Public IP O)

[기본 사항] 탭

[네트워킹] 탭

[검토 + 만들기] 버튼을 클릭하여 가상 머신 생성을 완료합니다.

1.6 가상 머신 생성 (Public IP X)

[기본 사항] 탭

[네트워킹] 탭

[검토 + 만들기] 버튼을 클릭하여 가상 머신 생성을 완료합니다.

2. Jenkins 설치 - Spoke 가상 머신

2.1 Spoke 가상 머신에 접근

Local PC에서 Hub 가상 머신에 붙은 Public IP를 통해 Hub 가상 머신에 접근한 후, 가상 머신 내에서 Remote Desktop Connection을 통해 Spoke 가상 머신에 접근합니다.

2.2 Java 설치

Jenkins를 설치하기 전에, 먼저 Spoke 가상 머신에 Java를 설치해야 합니다.

그러나 Oracle 페이지로 이동해서 Java를 다운로드 받기 위한 버튼을 누르면 Oracle에 로그인하는 페이지로 리다이렉트 됩니다.

만약 계정이 없을 경우, https://www.jenkins.io/doc/book/installing/windows/에서 Open JDK를 다운로드 받을 수 있습니다.

해당 페이지로 이동해 하기 과정을 진행합니다.

[java SE 21]을 클릭한 후 msi 파일을 다운로드 합니다.

다운 받은 파일을 압축 해제한 후 압축 해제된 폴더의 경로를 복사합니다.

시스템 환경 변수에 해당 경로를 등록하기 위해 로고 키를 눌러 시스템 환경 변수 편집 (Edit the system environment variables)를 클릭합니다.

[환경 변수 (Environment Variables)] > [새로 만들기 (New)] 버튼을 클릭합니다.

변수 이름 (Variable name)에 JAVA_HOME을, 변수 값 (Variable value)에 복사해 둔 경로를 입력합니다.

Path라는 변수에 등록한 환경 변수에 대한 bin 경로를 추가해 줍니다.

cmd 창에서 java -version 명령어를 입력하여 Java 버전이 정상적으로 조회되는지 확인합니다.

2.3 Jenkins 설치

https://www.jenkins.io/download/#downloading-jenkins로 이동하여 Windows용 LTS 버전을 다운로드 받습니다.

자동으로 다운로드 되는 jenkins.msi 파일을 실행하여 설치를 진행합니다.
- Service Logon Credentials 창이 나올 때까지 Next를 누른 후 [Run service as a local or domain user :] 옵션을 사용합니다.
  (단, 해당 옵션에서 사용되는 Account는 미리 해당 가상 머신에 생성되어 있어야 합니다. [Settings] > [Accounts] > [Add account]에서 생성 가능)

[Troubleshooting]

만약 account가 있음에도 하기와 같은 에러가 발생할 경우,

This account either does not have the privilege to logon as a service or the account was unable to be verified.

[로컬 보안 정책 (Local Security Policy)] > [로컬 정책 (Local Policies)] > [사용자 권한 할당 (User Rights Assignment)] > [서비스로 로그온 (Log on as a service)]으로 이동합니다.

[Add User or Group] 버튼을 클릭한 후 해당 account를 추가해 줍니다. 그 후 [Apply] 버튼을 클릭하여 변경 사항을 저장합니다.

Port Selection 창이 나올 때까지 Next를 누른 후 사용할 Port를 입력하고 Test 합니다.

Java Home Directory에 대해 default 경로를 실제 Java가 설치된 경로로 변경해 줍니다.

모든 설정이 완료되면 [Install] 버튼을 클릭하여 설치를 완료합니다.

2.4 Jenkins 초기 설정

인터넷 창에서 가상 머신 private ip:8080을 입력하여 Jenkins Admin 페이지에 접근합니다.
초기 비밀번호를 확인하기 위해 해당 페이지에 출력된 경로를 복사하여 해당 파일을 엽니다.

복사한 비밀번호를 Jenkins Admin 페이지에 입력하여 접속합니다.

필요한 Plugin은 추후에 설치하면 되기 때문에 [Install suggested plugins]를 클릭합니다.

Create First Admin User 페이지는 필요한 경우 새로 생성하거나, [Skip and continue as admin] 버튼을 클릭하여 건너뜁니다.

Jenkins URL은 default 값이 맞는지 확인하고 Save and Finish를 클릭하여 Jenkins를 시작합니다.

모든 과정이 제대로 진행되었다면 Jenkins 설치가 완료된 것입니다 !

이렇게 Windows VM에 Jenkins를 설치하는 과정에 대해 알아보았습니다.

Linux VM보다 Java에 대한 부분에서 좀 더 신경을 써야 하기 때문에 다음에는 그냥 Ubuntu VM에 올리자 라는 생각을 하게 만는 테스트 였습니다.

다음 글은 Jenkins와 GitHub를 연결하는 부분과, Jenkins Pipeline의 결과물(?)이 어떤 directory에 떨어지는지 확인하는 과정에 대해 다뤄보겠습니다!

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #03 SQL Server 구성

admin_cloud — Mon, 1 Apr 2024 15:05:36 +0900

안녕하세요. TAK 입니다:)

벚꽃이 개화하면서, 봄이 가까워졌음을 알리는 요즘 인사드립니다

(아직까지 일교차가 크기에 건강 유의하셔요 )

이번에는 실제 SQL Server 설치과 구성을 위한 단계인 "#03 SQL Server 구성"에 관한 내용을 다룹니다.

#01 ~ 02 진행한 초기 구성은 계속되는 과정에서 필수적인 환경으로 아래 링크를 참고하여 함께 팔로잉 해주세요!

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #01 용어 정리 및 구성도 공유 그리고 AD 구축

with-cloud.tistory.com

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #02 Failover Cluster 구성

with-cloud.tistory.com

그럼 시작하겠습니다!

Contents

1. SQL Server

1-1. SQL Server 설치

: 해당 과정에서는 SQL Server 2022 및 개발자 버전을 설치하였습니다.

SQL Server 2022 다운로드
- [개발자] 선택
  https://www.microsoft.com/ko-kr/sql-server/sql-server-downloads

SQL Server 2022 에 대한 세부 사항 Docs
https://learn.microsoft.com/ko-kr/sql/sql-server/editions-and-components-of-sql-server-2022?view=sql-server-ver16

SQL Server 2022의 버전 및 지원하는 기능 - SQL Server

SQL Server 2022의 버전 및 지원하는 기능

learn.microsoft.com

SQL Server에서 다운로드 파일 실행 후
- [Download Media] 선택

언어 및 설치 패키지(ISO) 선택

다운로드 후, ISO 이미지 파일 MOUNT

파일 탐색기 내, 정상적으로 마운트 여부 확인
- 이후, setup 실행 파일을 [관리자 권한으로 실행]

1-2. SQL Server 설치 Configuration

: SQL Sever 설치 시, Installation Center를 통해 세부 사항을 설정하여 설치합니다.

신규 SQL Server 설치 관련 선택

Free Edition 선택
- 위 단계에서 다운로드를 개발자(Developer) 선택

라이센스 조건에 대한 동의

Microsoft Update(선택 사항)

Install Rules (default 선택 및 Next)

Feature Selection
- [Database Engine Services] 선택

Instance Configuration
- [Default instance] 선택

Server Configuration(Service Accounts)
- <<Browe..>> 선택하여 [SQL Server Agent & SQL Server Database Engine]의 Account Name을 AD 서버의 도메인 관리자 값(tak2on\admintak)으로 설정 후, Password 입력

Server Configuration(Collation)
: 기본 서버 데이터 정렬은 SQL Server 설치 중에 결정되며, 시스템 데이터베이스 및 모든 사용자 데이터베이스의 기본 데이터 정렬이 됩니다.
- 세부 사항은 아래 공식 Docs 참고

데이터 정렬 및 유니코드 지원 - SQL Server

SQL Server의 데이터 정렬 및 유니코드 지원에 대해 알아봅니다.

learn.microsoft.com

Database Engine Configuration
- Server Configuration
  : Mixed Mode 사용하여, AD 도메인 관리자를 SQL Server 시스템 관리자로 함께 등록하여 함께 사용합니다.
  (해당 과정은 테스트이므로 다음과 같이 구성하였지만, 별도의 SQL Server 시스템 관리자를 구성하는 것을 권장드립니다.)
- Data Directories
  : 실제 사용자가 사용하는 Database의 데이터들에 대한 저장 경로 지정하는 단계입니다. 앞서 설명한 것처럼, Always on의 경우, Database 수준으로 이뤄지는 고가용성 서비스이므로 각 VM에 Attach 한 Data Disk 경로를 지정합니다. (백업 등 디스크 사용이 용이)
- TempDB
  : 위와 같은 경로로 재정의 합니다.
이후, 기타 옵션은 Default 값 설정 후, 지금까지 구성 사항을 트리형식으로 확인 후, [Install]

정상적으로 설치된 것을 확인

2. SSMS

: SSMS란, Microsoft SQL Server Management Studio의 줄임말로 SQL 인프라를 관리하기 위한 통합 환경입니다. 쉽게 말해, SQL에 접근하여 Database의 데이터를 다룰 수 있는 툴이라고 생각할 수 있습니다.(ex, Heidisql, Dbeaver 등)

다운로드 및 설치
SSMS(SQL Server Management Studio) 다운로드 - SQL Server Management Studio (SSMS)

SSMS(SQL Server Management Studio) 다운로드 - SQL Server Management Studio (SSMS)

SQL Server 및 Azure SQL 인스턴스를 관리하고 구성하기 위한 최신 버전의 SSMS(SQL Server Management Studio)를 다운로드합니다.

learn.microsoft.com

언어 설정(Korean) 제외하고 나머지 Default 값으로 구성

접근 확인 및 테스트

SQL-01 Server에서 위 단계에서 지정한 Account 정보를 입력하여 로그인합니다.

샘플 DB 및 테이블(데이터 포함) 생성

-- 샘플 데이터베이스 생성
CREATE DATABASE SampleDB;

-- 생성된 데이터베이스로 이동
USE SampleDB;

-- 샘플 Employees 테이블 생성
CREATE TABLE Employees (
    EmployeeID INT PRIMARY KEY,
    FirstName NVARCHAR(50),
    LastName NVARCHAR(50),
    Department NVARCHAR(50),
    Salary DECIMAL(10, 2)
);

-- 데이터 삽입
INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary)
VALUES (1, 'John', 'Doe', 'HR', 55000.00);

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary)
VALUES (2, 'Jane', 'Smith', 'IT', 60000.00);

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary)
VALUES (3, 'Bob', 'Johnson', 'Finance', 62000.00);

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary)
VALUES (4, 'Alice', 'Williams', 'Marketing', 50000.00);

INSERT INTO Employees (EmployeeID, FirstName, LastName, Department, Salary)
VALUES (5, 'Eve', 'Davis', 'IT', 65000.00);

Select 문 사용하여 데이터 조회

지금까지 "SQL Server Always On 가용성 그룹 on Azure" 중 SQL Server 설치와 구성 단계에 대해서 알아보았습니다!

다음 포스팅에서는 대망의 마지막 단계인 SQL Server의 Always On 가용성 그룹 구성에 대해 살펴보고 시리즈를 마무리하려 합니다. (!! 많관부!!)

이번 포스팅에서 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

Azure Cloud Shell에 Private하게 접근하기 (1)

H-Y-E-N — Mon, 1 Apr 2024 14:48:20 +0900

안녕하세요. HYEN입니다.

오늘은 Azure Cloud Shell에 Private하게 접근하는 방법에 대해 알아보겠습니다.

결과부터 말하자면,

Local PC에서 Cloud Shell에 접근하는 것 자체를 제어하는 것은 하기에 적은 테스트 방법으로는 불가합니다.

Microsoft의 공식 문서에 따르면, Cloud Shell에 대한 접근 제어는 ux.console.azure.com 이라는 도메인에 대한 액세스를 제어함으로서 가능하다고 합니다. (https://learn.microsoft.com/ko-kr/azure/cloud-shell/faq-troubleshooting#block-cloud-shell-in-a-locked-down-network-environment)

저는 가상 네트워크 즉, 허용된 가상 네트워크 대역에서만 Cloud Shell을 실행할 수 있도록, Local PC에서는 Cloud Shell에 접근이 되어도 정상적으로 Command를 날리지 못하게 하도록 하는 방법을 찾기 위해 이번 테스트를 수행해 보았습니다.

Azure Cloud Shell FAQ(질문과 대답)

이 문서에서는 일반적인 질문에 답변하고 Cloud Shell 문제를 해결하는 방법을 설명합니다.

learn.microsoft.com

하기 테스트는 가상 네트워크 내에 Cloud Shell을 배포하는 방법에 대한 내용을 다루고 있음을 말씀드리며 이번 글을 시작해 보겠습니다 !

Contents

1. Azure Cloud Shell이란?

먼저 Azure Cloud Shell이 무엇인지에 대해 알아보고 가겠습니다.

Azure Cloud Shell은 Azure의 클라우드 기반 Command Line 환경입니다.
Azure 리소스를 관리하기 위해 브라우저에서 액세스할 수 있는 인증된 대화형 터미널로 Bash, Powershell 두 가지 환경이 제공됩니다.
이를 통해 로컬 환경에서 Azure CLI를 설치하거나 환경을 구성하지 않고도 Azure를 관리할 수 있습니다.

Azure Portal (https://portal.azure.com/)에 접근하면 하기 스크린샷과 같은 아이콘이 우측 상단에 보입니다.

이게 바로 Azure Cloud Shell로, Azure 환경에 대한 관리를 웹 상에서 간단하게 할 수 있는 Command Line 도구입니다.

2. 가상 네트워크에서 Cloud Shell 사용하기 - Private Endpoint

첫 번째로 Cloud Shell이 사용하는 Storage Account의 Files에 대해 private endpoint를 생성하면 Local PC에서 접근이 어렵지 않을까 하는 생각에 테스트를 진행해 보았습니다.

2.1 Azure Cloud Shell 용 Storage Account 생성하기

앞서 설명 드린 것과 같이 Azure Portal의 우측 상단에서 Cloud Shell을 실행합니다.

Cloud Shell을 사용하기 위해서는 새로운 Storage Account를 생성해야 합니다.

위와 같이 [새로 만들기] 옵션을 클릭하여 Storage Account와 리소스 그룹을 생성합니다.

2.2 가상 네트워크 생성하기

Private Endpoint를 생성하기 위해서 가상 네트워크를 먼저 생성합니다.

[기본 사항] 탭

[IP 주소] 탭

[검토 + 만들기] 탭을 클릭하여 유효성을 검사한 후 가상 네트워크를 생성합니다.

2.3 Storage Account에 Private Endpoint 연결하기

Cloud Shell 실행 시 생성한 Storage Account의 [공용 네트워크 액세스] 상태는 기본적으로 "모든 네트워크에서 사용"
입니다.

공용 네트워크 액세스를 차단하기 위해 [공용 네트워크 액세스] 상태를 "사용 안 함"으로 변경해야 합니다.

Azure Portal로 이동하여 [Storage Account] > [보안 + 네트워킹] > [네트워킹] 탭 > [방화벽 및 가상 네트워크]에서 공용 네트워크 액세스에 대한 옵션을 [사용 안 함]으로 변경합니다.

[저장] 버튼을 클릭하여 해당 내용을 저장합니다.

다음으로 [프라이빗 엔드포인트] 연결 탭을 클릭하여 Storage Account에 대한 Private Endpoint를 생성합니다.

[기본 사항] 탭

[리소스] 탭

[가상 네트워크] 탭

[DNS] 탭

위와 같은 설정을 마무리한 후 [검토 + 만들기] 탭으로 이동하여 Private Endpoint 생성을 완료합니다.

2.4 Local PC에서 Cloud Shell 접근하기

Cloud Shell을 실행한 후 ⚙️ 버튼을 클릭하여 [사용자 설정 다시 설정] 버튼을 클릭합니다.

사용자 설정 다시 설정 창이 표시되면 [초기화]를 클릭합니다.

Azure Cloud Shell 시작 창이 표시되면 [Bash]를 클릭합니다.

다시 한번, 스토리지와의 연결을 위해 하기와 같은 설정을 진행합니다.

이번에는 [새로 만들기] 옵션이 아닌 [기존 항목 사용] 옵션을 사용해야 합니다.

과연! 결과는 어떨까요?

접근은 가능하지만 Azure file share에 접근이 되지 않아 cloud drive를 이용할 수 없다는 Error Message가 출력됩니다.

이 경우 Azure CLI 명령어는 사용할 수 있으나 git clone을 통해 가져온 파일의 경우는 Azure file share에 영구히 저장되지 않게 됩니다.

실제로 테스트를 한번 진행해 보겠습니다.

az group list -o table 명령어를 통해 현재 구독에 존재하는 리소스 그룹의 리스트를 테이블 형식으로 확인해 보겠습니다.

명령어가 정상적으로 실행되는 것을 확인할 수 있습니다.

다음은 git clone 명령어를 통해 GitHub에 있는 소스 코드를 Cloud Shell로 가지고 와 보겠습니다.

git clone https://github.com/carlosalexei/aks-workshop.git 명령어를 사용하여 Cloud Shell에 소스 코드를 가지고 옵니다. 그후 ls를 입력하여 aks-workshop이라는 directory가 생성된 것을 확인합니다.

clone 해 온 소스 코드가 Cloud Shell을 다시 시작해도 여전히 남아 있는지 확인하기 위해 하기 스크린샷처럼 전원 버튼을 클릭합니다.

[다시 시작] 버튼을 클릭하여 Cloud Shell을 다시 시작합니다.

ls -al 명령어를 사용하여 확인해 보면 동일한 위치임에도 불구하고 aks-workshop이라는 directory가 보이지 않는 것을 확인할 수 있습니다.

이를 통해, 상기 테스트한 방법으로는 Local PC에서 Cloud Shell을 사용하여 Azure 인프라를 관리하는 것을 막지 못한다는 것을 알 수 있습니다. 단순히 Cloud Shell이 재실행되거나 다시 연결될 때 Cloud Shell에 업로드한 폴더나 파일에 대한 부분이 휘발되는 것일 뿐, 접근 제어와 command 실행 제어와는 Private Endpoint가 관련이 없다는 것을 확인하였습니다.

다음 글에서는 Azure Relay를 사용하여 Cloud Shell을 가상 네트워크 내에 배포하는 방법에 대해 알아보도록 하겠습니다.

다음 글 : https://with-cloud.tistory.com/35

Azure Cloud Shell에 Private하게 접근하기 (2)

안녕하세요. HYEN입니다. 오늘은 지난 글에 이어 Azure Relay를 사용하여 Azure Cloud Shell을 가상 네트워크에 배포하는 방법에 대해 알아보겠습니다. 지난 글 : https://with-cloud.tistory.com/31 Azure Cloud Shel

with-cloud.tistory.com

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #02 Failover Cluster 구성

admin_cloud — Thu, 21 Mar 2024 16:29:11 +0900

안녕하세요. TAK 입니다:)

일교차가 큰 요즘.. 다들 잘 지내고 계신가요? 감기 조심하세요!

이어지는 포스팅인 만큼 흐름을 이어가고자 빠르게? 다시 찾아왔습니다

(저만의 초기 감기 꿀팁을 드리자면,,

저는 약국 판콜 + 비타민 C + 홍삼꿀물 + 약간의 유산소 + 수면

으로 초기 감기를 이겨내곤 한합니다... 하루 정도 나의 건강을 위해 빠르게 회복하는 방법이니 참고..해주세용 )

이번에는 본격적으로 고가용성을 위한 기본 전제조건인 "#02 Failover Cluster 구성"에 관한 내용을 다룹니다.

#01에서 진행한 초기 구성은 계속되는 구축 과정에서 필수적인 환경으로 아래 링크를 참고하여 함께 팔로잉 해주세요!

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #01 용어 정리 및 구성도 공유 그리고 AD 구축

with-cloud.tistory.com

!!그럼 힘차게 시작하겠습니다!!

Contents

1. Failover Cluster 환경 및 생성 작업

현 구성의 총 3대의 SQL Server 전체 대상으로 1-2 Failover Cluster 설치 단계까지 동일하게 진행하면 됩니다!

1-1. 방화벽 설정

: SQL Server 와 고가용성을 위한 구성에서 통신을 위해 다음과 같이 방화벽 Port를 Open 합니다.

- SQL Server: 기본 인스턴스의 경우 1433
- 데이터베이스 미러 엔드포인트: 5022 또는 사용 가능한 모든 포트
- 가용성 그룹에 대한 부하 분산 장치 IP 주소 상태 프로브: 59999 또는 사용 가능한 모든 포트
- 클러스터 코어에 대한 부하 분산 장치 IP 주소 상태 프로브: 58888 또는 사용 가능한 포트

Windows Defender Firewall with Advanced Security(Inbound Rules)

마우스 오른쪽 버튼 클릭 후, [New Rule…] 선택

위 단계에서 지정한 값(Inbound Rule)에 대한 명명

1-2. Failover Cluster 설치

Add roles and features

feaures 값만 설정하면 되기에, 앞 과정은 모두 기본값으로 설정

설치 완료 후, 재부팅
- 다음 명령어 통해서 Failver Cluster Manager 확인

1-2-1. Validate Configuration

Failver Cluster Manager 확인 후, [Validate Configuration] 작업
- 실제 클러스터 구성 전, 확인 작업을 위하여 진행

Domain(tak2on.com) Join 된 SQL Server(Computer) 목록 찾기

클러스터 구성 테스트 실행

유효 확인(Vaildated) 작업 완료

1-2-2. Create Cluster

1-2-1 과정과 동일하게 Domain(tak2on.com)에 Join 된 SQL Server 선택

클러스터 이름 지정
- 네이밍 룰(15 characters limit) 확인

클러스터링 정상 확인
- 선택한 SQL Server가 Nodes 목록에 정상 등록 및 Status(Up) 확인

2. Quorum

: Quorum(쿼럼) 이란, HA(고가용성) 을 위해 사용되는 장치로 분산 시스템에서 일관된 동작과 안정성을 유지하기 위해 사용되는 개념입니다. 다수결(일반적으로 투표라 하며 다수결에 의해 Active Node를 결정)을 통해 시스템의 상태를 결정하고 조정함으로써 분산 시스템의 안정성을 보장합니다.

출처 : https://learn.microsoft.com/en-us/windows-server/failover-clustering/media/deploy-a-cloud-witness-for-a-failover-cluster/cloudwitness_2.png

즉, 다음과 같은 이유로 구성이 필수적입니다.

- 고가용성과 장애 복구 : 분산 시스템에서 노드 간의 통신이 중단되는 경우, 시스템이 계속해서 정상적으로 작동하려면 여전히 다수의 노드가 동작해야 합니다. 쿼럼은 이러한 상황에서도 시스템이 올바르게 작동할 수 있도록 보장합니다.

- 일관성 유지 : 분산 시스템에서 여러 노드가 데이터를 공유하고 처리할 때, 일관된 상태를 유지하기 위해 쿼럼이 사용됩니다. 데이터의 일관성을 보장하기 위해서는 다수의 노드가 동일한 상태를 동의해야 합니다.

- 스플릿 브레인(Split-brain) 문제 방지(해결) : 스플릿 브레인은 네트워크 분할로 인해 클러스터가 두 그룹으로 분리되는 상황을 말합니다. 이때 쿼럼을 사용하면 두 그룹 중 하나만이 시스템을 제어하도록 하여 데이터의 일관성과 안정성을 유지할 수 있습니다.

현 구성은 Single Quorum 으로 비교적 작은 규모의 환경에서 사용되는 경우에 적합합니다. (의존성이 높음.)

2-1. Quorum 설정

[클러스터 명] - [More Actions] - [Configure Cluster Quorum Settings]

Quorum Witness 옵션 중, Azure Storage Account(Blob)을 Quorum으로 사용하기 위해 [Cloud witness] 선택
- 현 구성에서는 Private Link - Private Endpoint 구성을 통해 Private 구성된 상태

2-2. Quorum 구성 확인

연결한 Azure Storage Account(blob) - Container에서 정상 연결되었다면, [msft-cloud-witness] 컨테이너를 확인할 수 있습니다.

이후, 보다 원활한 사용과 통신을 위해 IE 보안 강화 구성 해제
- 모든 서버 대상

마지막으로 여기서!!!!!

작업 단계를 정리하자면, 다음과 같습니다.

- 현 구성에서는 총 3대의 SQL Server가 있으므로 대상 서버 모두 Failover Cluster 설치 단계까지 동일하게 진행
- Clustering 구성은 1대의 서버에서만 정상적으로 구성이 되었다면, 1-2-1 과정 이후에 대해 반복하여 진행할 필요 없으며, 각 서버의 Failover Cluster Manager에서 확인 가능

지금까지 "SQL Server Always On 가용성 그룹 on Azure"에서 고가용성을 위해 중요한 Failover Cluster 구성에 대해서 알아보았습니다!

다음 포스팅에서는 SQL Server의 SQL구성 그리고 Always On 가용성 그룹 구성까지 알아보겠습니다.(!!많관부!!)

이번 포스팅에서 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

[경영정보시각화능력] 자격증 소개

admin_cloud — Wed, 20 Mar 2024 17:16:42 +0900

안녕하세요. TAK 입니다:)

!!오늘은 따뜬한 자격증 정보를 들고 왔습니다!!

3월 어느날..

데이터자격검정센터에서 메일이 와 확인해보니 신설 국가기술자격 경영정보시각화능력 안내를 하더랩죠...

조금 더 자세히 살펴보니, 대한상공회의소에서 시행하는 시험이더라구요.

2024년 신설되어 처음으로 시행하는 일정은 다시 한번 살펴보면 올해 필기는 2번, 실기는 1번으로 진행되네요.

첫 시험이다 보니, 수험자들의 이해를 돕기 위해 필기수험가이드북과 필기/실기 모의문제집을 무료로 배포하고 있다고 합니다.

보다 시험 관련 자세한 내용은 아래 공식 홈페이지에서 확인하면 좋을것 같아요:)

https://license.korcham.net/co/examguide.do?mm=28&cd=0108

종목소개 시험안내

경영정보시각화능력 종목소개 4차 산업혁명, 디지털 전환 등으로 인해 데이터에서 의미있는 정보를 도출하는 능력이 무엇보다 중요해지고 있습니다. <경영정보시각화능력(Business Intelligence Specia

license.korcham.net

이미 제 소개글에서 Data의 다양한 분야에 관심이 있다고 언급한 적이 있는데요.

뭔가 실무스러운 느낌이라.. 흥미가 생겼고.. 국가기술자격증이라고 하니.. 더욱..

그래서 2024년 첫 자격증으로 신설된 [경영정보시각화능력] 취득에 도전하려고 합니다!

그런데...

마침 수험 기본서 이벤트를 진행하는 굿 타이밍이라 이렇게 많은 분들과 공유하고 포스팅하게 되었습니다! (~ 03.24)

이벤트 참여 링크 : https://form.naver.com/response/Lp7MDk8m5eanQk2P0ZDQfg

관심있으신 분들은 이벤트도 참여하시고, 함께 도전해 보시는게 어떨까요?

포스팅의 모든 그림(이미지) 출처는 대한상공회의소(자격평가사업단) 입니다.

[MSSQL Server Always ON 가용성 그룹 구성 on Azure VMs] #01 용어 정리 및 구성도 공유 그리고 AD 구축

admin_cloud — Mon, 18 Mar 2024 15:08:05 +0900

안녕하세요. TAK 입니다:)

봄이 부쩍 가까워진 3월에 다시 인사드립니다(^꾸_벅^)

회사 업무로 Azure VM 기반 MSSQL FCI 구성한 적이 있는데.. 이후에 Always ON 가용성 그룹 구성이 자꾸 아른?..거려서 작성하게 되었다는 그런 이상한 출발점으로 이번 포스팅을 준비했습니다!

그럼 "Azure 인프라 내에서 MSSQL과 Failover를 위한 Always ON 가용성 그룹 구성"에 대해 찐~하게 살펴보겠습니다!

찐~한만큼 구성의 단계별로 나눠서 포스팅할 예정입니다.

(설정에 따라 구성이 많이 달라질 수 있는 점 참고해 주세요.)

자, 그럼 본격으로 1부 시작하겠습니다!

"실제 테스트 구축 전, 우리가 함께 구성할 서비스에 대한 개념 정리 먼저 해보겠습니다."

Contents

1. MSSQL 이란?

https://www.commvault.com/wp-content/uploads/2019/08/sql-server_logo.jpg?quality=80&w=930

: MSSQL이란, Microsoft SQL Server의 줄임말로 대표적인 RDBMS(Relational DataBase Management System) 중 하나입니다. 관계형 데이터베이스(RDB)는 테이블, 행(레코드 또는 튜플), 열(속성)의 정보를 구조화하는 방식입니다. RDB에는 테이블을 조인하여 정보 간 관계 또는 링크를 설정할 수 있는 기능이 있어, 여러 데이터 포인트 간의 관계를 쉽게 이해하고 정보를 얻을 수 있습니다. 즉, RDBMS는 RDB를 생성, 관리, 업데이트 등에 사용되는 프로그램으로 볼 수 있습니다.

특징은 다음과 같습니다.

- MySQL과 달리 오픈소스가 아님으로 라이센스 구매 필요한 Microsoft의 상용 제품

- Transact-SQL 또는 T-SQL 사용(표준 SQL + 추가 기능)

- 위와 같은 이유로 주기적인 업데이트를 통해 데이터 암호화, 접근제어, 감사 로깅 등 보안에 강점

- 많이 사용되는 DB 제품으로 관련 정보를 쉽게 찾을 수 있으며, 트러블슈팅 등 다양한 지원에도 유리

- MSSQL은 중앙 집중식 데이터베이스 제어로 고가용성 솔루션이 있으며, 백업 및 복구 기능 제공

- 주로 Windows OS를 통해 실행되며, 높은 호환성

- SSMS(SQL Server Management Studio) 혹은 Azure Data Studio와 같은 Tool을 통해 액세스 및 사용 가능

- RDBMS는 DBMS의 한 유형(ex. MySQL, MariaDB, Oracle 등)

1-1. 고가용성(High Availability) 솔루션

: 고가용성(HA, High Availability)이란, 오랜 기간 동안 지속적으로 정상 운영 가능한 상태를 말합니다.

MSSQL에서는 대표적으로 아래 두 가지 고가용성 솔루션을 제공하고 있습니다.

아래 두 고가용성의 설명은 MSSQL on Azure를 가정합니다.

1-1-1. FCI(Failover Cluster Instances)

https://i0.wp.com/www.omegamadlab.com/wp-content/uploads/2020/07/S2DFCI-1.png?w=741&ssl=1

FCI는 기존의 Windows 클러스터링 기술을 사용하여 SQL Server를 실행하는 인스턴스
- 클러스터 내에서 하나의 노드에 장애가 발생하면 다른 노드로 자동으로 이동하여 서비스 지속 가능
여러 대의 서버(노드)에 SQL Server를 설치하고, 클러스터를 형성하여 단일 데이터베이스 인스턴스를 공유
- 위 그림과 같이, 스토리지 구성에서 공유 필요
FCI는 주로 단일 데이터베이스 인스턴스의 고가용성을 제공하는 데 사용
- 즉, 고가용성(Protection)의 주체는 데이터베이스 인스턴스

1-1-2. Always On Availability Group Cluster

https://i2.wp.com/www.omegamadlab.com/wp-content/uploads/2020/07/AG.png?w=745&ssl=1

Always On 가용성 그룹은 데이터베이스 수준의 고가용성을 제공
- 여러 대의 서버(노드)에 데이터베이스의 복제본을 만들어 공유, 즉 Node에 연결된 개별 스토리지 필요(No Shared)
복제본은 읽기 가능 또는 읽기 전용일 수 있으며, 여러 가용성 그룹을 구성하여 다양한 목적에 맞게 데이터베이스를 배포 가능
- 장애가 발생하면 해당 가용성 그룹의 복제본 중 하나로 자동으로 이동하여 서비스 지속 가능
Always On 가용성 그룹은 데이터베이스 단위로 고가용성을 제공하므로 다중 데이터베이스 솔루션에 적합

1-1-2. FCI(Failover Cluster Instances) VS Always On Availability Group Cluster

Feature	FCIs	AGs
Licenses*	Single license required	Single license required for HA mode, additional licenses required for actively used secondary replicas
Storage Configuration	Shared storage, eg SAN, Storage Spaces Direct, etc.	No shared storage needed, each replica has its own
Storage Requirements	No additional store space required for user databases	Each replica stores its own copy of the database
Protection	Instance-level	Database-level
Typical configuration	HA, with DR capabilities if combined with other technologies	HA or DR
RPO: Potential data loss	Typically no data loss during failover	Typically no data loss during failover for synchronous-commit; potential data loss for asynchronous-commit
RTO: Time to failover	Potentially noticeable for large and active systems	Typically fast and may be unnoticeable on many systems
Administration	Once configured, manage the instance. Use SQL Server Setup program to add/remove nodes	Once configured, additional care must be taken for instance-level objects such as logins and jobs.
Patching & maintenance	Reduces downtime to failover time	Reduces downtime to failover time

출처 : https://theserogroup.com/sql-server/whats-the-difference-in-sql-server-fcis-and-ags/

2. 구성도 및 인프라 세부 사항

2-1. 구성도

: 이번 포스팅에서는 Always On 가용성 그룹 방법으로 진행됩니다!

2-2. 인프라 세부 사항

: 한국 중부 리전의 가용성 영역(1,2,3) 구분하여 배포

- Azure Load Balancer (1ea) for Cluster Listener

- Storage Account - Blob (1ea) for Quorom

- Data Disk (3ea) for SQL Server Database Replication

- Virtual Machine Configuration

구성	AD-01	AD-02	SQL-01	SQL-02	SQL-03
OS	Windows Server 2019 R2
HOSTNAME	tak-ad-01	tak-ad-02	tak-sql-01	tak-sql-02	tak-sql-03
SKU	Standard B2s (2개 vcpu, 4GiB 메모리)		Standard B4als v2 (4개 vcpu, 8GiB 메모리)
IP	172.168.0.4	172.168.0.4	172.168.1.4	172.168.1.5	172.168.1.6
DNS	tak2on.com(172.168.0.4, 172.168.0.5)

3. AD 서버 구성

: AD 서버는 MSSQL의 고가용성 구성을 위해 필수적인 리소스입니다.

해당 구성에서는 주 서비스인 AD DC(Actice Directory Domain Services)는 윈도우 서버 운영체제의 기능을 사용합니다.

즉, 다음과 같은 이유로 사용됩니다.

- AD 사용자 및 그룹을 만들어 권한 할당 및 인증에 사용

- 관리자 및 클라이언트에서 MSSQL Server에 액세스 할 때, AD를 통해서 인증에 사용

- Window 기능 중 Failover를 위한 클러스터링 구성에서 모든 노드가 AD DC의 도메인에 속해야 하며, 이는 클러스터링 서비스, 관리 도구 과 통합되어 노드 Failover 시에 인증과 통신 등에 사용(+ 서비스로 등록)

→ 위와 같은 이유로 AD 서버의 고가용성을 고려하여 2대의 AD 서버를 구성합니다.

3-1. AD 서버 설정

: 2대의 AD 서버 동일하게 설정합니다. 우선 1대의 AD 서버(tak-ad-01) 설정을 진행하겠습니다.

Add roles and freatures 선택

AD 서버 선택

AD DS (Active Directory Domain Services)

[Features] 단계에서 Defaults 옵션 유지하여, Next

설치 완료 후, “Promote This server to a domain controller” 문구가 클릭 후, Domain Controller 구성

새로운 구성으로, Add a new forest 클릭 후, Root domain name 입력

정상적으로 설치 완료되었다면, 구성 사항 반영을 위해 Restart

3-2. AD 서버 접근 및 AD DS 확인

AD 서버에 액세스 시, 위 단계에서 구성한 AD DS에 등록된 Domain Controllers 정보로 로그인합니다.
→ 정상적으로 Domain에 등록되었는지 확인을 위해

AD DS 및 DNS 구성 확인

AD DS(Domain) 구성 확인

→ 다른 1대의 AD 서버(tak-ad-02)도 위 단계와 동일하게 구성하시면 됩니다.

위 단계 일부 다른점은 AD DS 구성 설정 시,
새로운 도메인 추가가 아닌 기존 도메인에 Domain Controller를 추가하는 것

인증 방법은 도메인 전체 혹은 도메인의 NetBOIS를 입력하는 2가지 방법 중 편하신 방법을 선택하여 인증

→ 이후 과정은 동일합니다.

AD 서버 2대 모두 정상적으로 설치 및 구성하였다면, 다음과 같이 확인 가능합니다.
- 정상적으로 도메인(tak2on.com) 의 Domain Controllers 등록

4. Azure Virtaul Network DNS 서버 설정

: 지금까지 구성한 AD DS의 경우, 앞서 설명한 SQL Server의 고가용성을 위한 역할로 사용됩니다.

따라서, 구성된 네트워크의 DNS 정보를 SQL Server가 AD 서버를 바라볼 수 있도록 DNS 서버 값을 지정합니다.

5. SQL Server에 대한 AD Join

: SQL Server의 고가용성을 위한 AD 서버의 목적으로 사용할 수 있도록 전체 SQL Server를 대상으로 위에서 생성한 도메인에 Member(Computer)로 등록합니다.

위에서 설정한 DNS 서버의 값들이 적용되고 있는 확인
- 각 SQL Sever 내 DNS 서버 정보 확인(모든 SQL Server에서 확인)

각 SQL Server에서 Domain Join 작업 실행

설정 이후, Domaion Join을 위한 인증
→ AD 서버의 도메인 관리자 계정으로 인증해야 하며, 이는 VM이 생성될 때 설정한 사용자가 됩니다.

재시작 후, 관리자 계정으로 로그인
- 사용자 확인

→ 모든 SQL 서버 대상으로 위 단계의 AD Join 작업 진행

→ AD 서버 관리 페이지에 Computers 항목에 AD Join이 정상적으로 되어 편입되었는지 확인

지금까지 "SQL Server Always On 가용성 그룹 on Azure"를 위한 개념과 테스트를 위한 환경 및 구성도 그리고 AD 서버의 구축 단계까지 진행하였습니다.

다음 포스팅에서는 SQL Server의 Failover Cluster 구성, SQL구성 그리고 Always On 가용성 그룹 구성까지 알아보겠습니다.(!! 많관부!!)

이번 포스팅에서 부족한 점, 궁금한 점 등 자유로운 의견을 남겨주세요!

Encrypting Secret Data at Rest in ETCD

H-Y-E-N — Tue, 12 Mar 2024 13:38:49 +0900

안녕하세요. HYEN입니다.

이번 글은 Encrypting Secret Data at Rest in ETCD에 대한 내용인데요.

개인적으로 한번은 꼭 해보고 싶었던 테스트라 VM으로 Kubernetes Cluster를 구성한 김에 진행해 보았습니다.

Contents

1. ETCD란?

ETCD Encryption at Rest 테스트를 진행하기에 앞서 먼저 ETCD가 무엇인지 간단하게 알아보도록 하겠습니다.

ETCD란?

ETCD는 Kubernetes Cluster의 모든 데이터를 담는 Kubernetes의 Key-Value 형태의 저장소입니다.

우리가 kubectl 명령어를 입력해서 받는 여러 Kubernetes Objects에 대한 정보는 모두 ETCD에 저장된 데이터에서 가져오는 정보죠.

따라서 Secret 데이터도 ETCD에 저장되게 됩니다.

그렇다면 Secret 데이터가 ETCD에 저장될 때 암호화되어 저장이 될까요?

답은 No입니다.

기본적으로 ETCD에 저장되는 Secret 데이터는 평문으로 저장이 됩니다.

그러나 Kubernetes는 ETCD에 저장되는 Secret 데이터를 암호화하는 방법을 제공하고 있습니다.

그렇다면 ETCD를 암호화하는 이유는 뭘까요?

그 이유는 Control Plane에 root 권한을 가진 사람은 ETCD에 접근해서 Secret 데이터를 볼 수 있기 때문입니다.

이것이 바로 이번 글에서 다룰 Encrypting Secret Data at Rest in ETCD 입니다.

그 전에 한 가지 설명하고자 하는 것은 ETCD pod의 형태입니다.

ETCD뿐만 아니라 Control Plane의 Component는 사용자가 배포하는 Pod와는 조금 다른 성질을 가지고 있습니다.

바로, ETCD나, API Server, Scheduler와 같은 Component는 Static Pod의 형태로 kube-system Namespace에 배포된 다는 것인데요.

Static Pod는 또 무엇일까요?

일반적으로 kubectl create 또는 kubectl apply 명령어로 pod를 생성할 때에는 kube-apiserver가 그 요청을 받아서 kubelet에게 알려주고 그 다음 각 Node에 있는 kubelet이 이를 처리하게 됩니다.

그러나 Control Plane의 /etc/kubernetes/manifests/ 디렉토리(default 경로) 하위에 있는 yaml file을 기반으로 kubelet은 자동으로 생성하고 관리하는 pod들이 있는데요.

이것이 바로 Static Pod입니다.

Control Plane의 Component를 Static Pod로 생성하면 kubelet이 해당 디렉토리를 지속적으로 관리하고 감시하여서 manifest file에 정의된 대로 각 pod의 상태를 유지하고자 합니다.

실제로 Control Plane 서버에서 ls /etc/kubernetes/manifests/ 명령어를 실행해 보면 하기 스크린샷과 같이 각 Control Plane Component에 대한 yaml file이 존재하는 것을 알 수 있습니다.

이 외에도 Static Pod로 생성하고 싶은 pod의 manifest file을 해당 디렉토리에 위치시키면 kubelet이 자동으로 pod를 생성하고 관리하게 됩니다.

이렇게 ETCD pod의 성질을 간단히 알아 보았는데요.

다시 본 주제로 돌아와서 ETCD에 저장된 Secret 값을 암호화하는 테스트를 진행해 보겠습니다.

2. ETCDCTL 설치

Encrypting Secret Data at Rest in ETCD 테스트를 진행하기 전 현재 ETCD에 저장된 데이터가 실제 평문으로 저장되어 있는지를 확인해 봅니다.

이전 글에서 kubeadm으로 Kubernetes Cluster를 생성하였기 때문에 ETCD를 위한 별도의 설치는 필요하지 않습니다.

그러나 ETCD와 상호작용하기 위해서 etcdctl이라는 Command Line Tool을 설치해야 합니다.

공식 문서 (https://etcd.io/docs/v3.4/install/)를 참고하여 etcdctl을 설치합니다.

ETCD repo를 다운로드하기 위해 git clone -b v3.4.28 https://github.com/etcd-io/etcd.git 명령어를 입력합니다.

cd etcd/ 명령어로 디렉토리를 이동한 다음 ./build 명령어를 통해 build script를 실행합니다.
만약 ./build 명령어 실행 시 하기와 같은 에러가 발생한다면 Go를 설치해 주어야 합니다.

Go 설치 (공식 문서 링크 : https://go.dev/doc/install)
- 이전에 Go를 설치했을 수도 있기 때문에 해당 디렉토리를 삭제하고 새로 설치합니다.
  rm -rf /usr/local/go && tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
- 상기 명령어가 제대로 작동하지 않을 경우에는 wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz 명령어를 입력한 후 tar Cxzvf /usr/local go1.22.1.linux-amd64.tar.gz를 실행하여 tar 파일을 /usr/local 디렉토리에 압축해제 합니다.
- ls /usr/local 명령어를 입력하여 Go가 정상적으로 설치된 것을 확인합니다.
- vi ~/.bashrc 명령어를 입력한 후 파일 가장 하단에 PATH=$PATH:/usr/local/go/bin를 추가하여 /usr/local/go/bin 디렉토리를 PATH에 영구히 추가합니다.
- source ~/.bashrc 명령어를 입력하여 변경 사항을 반영합니다.
- go version 명령어를 입력하여 설치를 다시 한번 확인합니다.

다시 cd etcd && ./build 명령어를 수행하면 이전과는 다르게 제대로 설치가 되는 것을 확인할 수 있습니다.

vi ~/.bashrc 명령어를 입력한 후 앞서 추가했던 PATH 뒤에 :/root/etcd/bin를 입력하여 /root/etcd/bin 디렉토리를 PATH에 영구히 추가합니다.

source ~/.bashrc 명령어를 입력하여 변경 사항을 반영합니다.

etcd --version 명령어를 입력하여 etcdctl이 제대로 설치되었는지 확인합니다.

ETCDCTL도 설치가 완료되었으니 이제 정말로 Encrypting Secret Data at Rest in ETCD를 테스트해 보겠습니다.

3. ETCD에 저장된 Secret 값 확인

ETCD에 저장되는 Secret 값은 기본적으로 평문으로 저장된다고 앞서 말씀 드렸는데요.

실제로 그런지 알아보도록 하겠습니다.

먼저 테스트용 Secret을 생성하겠습니다.

kubectl create secret generic secret-hyein --from-literal key=hyeintest 명령어를 입력하여 secret을 생성합니다.
kubectl get secret secret-hyein -o yaml 명령어를 입력해서 확인해 보면 base64로 인코딩된 형태로 데이터가 저장되어 있는 것을 알 수 있습니다.

echo "aHllaW50ZXN0" | base64 -d 명령어를 입력하여 디코딩하면 쉽게 value 값을 확인할 수 있습니다.

그렇다면 ETCD에 저장된 Secret도 똑같은지 확인해 보겠습니다.

ETCD Server에 연결하기 위해서는 --cacert, --cert, --key 값이 필요한데요.

이런 값은 어디서 확인해야 할까요?

앞서 설명 드렸던 Static Pod들이 저장된 디렉토리의 etcd.yaml 파일을 확인해 보면 알 수 있습니다.

cat /etc/kubernetes/manifest/etcd.yaml 명령어를 입력하여 필요한 값들에 대한 정보를 확인합니다.

하기와 같은 명령어를 입력해서 ETCD에 저장된 Secret 데이터를 확인합니다.

ETCDCTL_API=3 etcdctl\
   --cacert=/etc/kubernetes/pki/etcd/ca.crt \
   --cert=/etc/kubernetes/pki/etcd/server.crt \
   --key=/etc/kubernetes/pki/etcd/server.key \
   get /registry/secrets/default/secret-hyein | hexdump -C

스크린샷의 오른쪽 하단을 보면 key의 값이 hyeintest인 것을 볼 수 있습니다.

kubectl get secret secret-hyein -o yaml 명령어를 입력했을 때에는 적어도 base64로 인코딩된 형태로 존재했지만 ETCD에 저장된 데이터는 평문 그대로 저장된 것을 확인할 수 있습니다.

이 경우, 만약 누군가가 Control Plane 서버에 접근해서 --cacert, --cert, --key 값만 알 수 있다면 Cluster에 존재하는 Secret 데이터가 유출 될 수 있는 것입니다.

이를 방지하기 위해, 지금부터 ETCD에 저장되는 데이터에 대한 암호화를 구성해 보도록 하겠습니다.

4. Encrypting Secret Data at Rest in ETCD

(참고 링크 : https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)

ETCD Encryption을 진행하기 위해서는 두 가지 과정이 필요합니다.

1️⃣ EncryptionConfiguration Object 생성
2️⃣ kube-apiserver 설정 변경

1번부터 진행해 보도록 하겠습니다.

4.1 EncryptionConfiguration Object 생성

EncryptionConfiguration Object는 Kubernetes Cluster의 구성 중 하나로 ETCD의 데이터를 암호화하는 데 사용됩니다.

EncryptionConfiguration를 설정하면 EncryptionConfiguration manifest 파일에 지정한 리소스(ex. secrets, configmaps)의 데이터는 모두 암호화됩니다.

암호화를 위해서는 보안 키가 필요하며 이 키는 EncryptionConfiguration의 manifest 파일에 지정됩니다.

(key 값은 base64로 인코딩하여 기재해야 합니다.)

manifest file을 생성하기에 앞서 먼저 key로 사용할 값을 인코딩 해 보겠습니다.

32바이트의 랜덤한 키를 생성하기 위해 head -c 32 /dev/urandom | base64 명령어를 입력합니다. (출력 내용 저장 필요)
- AES-CBC 암호화를 사용하는 키는 128비트, 192비트, 256비트의 길이를 가져야 합니다. (16자, 24자, 32자)
  그렇지 않을 경우, 에러가 발생할 수 있습니다.

/etc/kubernetes/enc/ 디렉토리에 enc.yaml이라는 이름으로 EncryptionConfiguration manifest 파일을 생성합니다.
해당 디렉토리가 없을 경우 mkdir /etc/kubernetes/enc/ 명령어로 디렉토리를 먼저 생성합니다.
(폴더는 어디든 상관 없습니다.)

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: 3WJOfWFj2SNy2Jj2+EUVUSzEMoRZh13hQ5t4ZWfUhcE=
      - identity: {}

manifest file 설명
- resources field에는 어떤 종류의 리소스(Object)를 암호화할 것인지를 지정합니다.
  본 테스트에서는 Secrets만 지정해 주었습니다.
- providers field에는 어떤 암호화 provider를 사용할 것인지를 지정합니다.
  provider field는 첫 번째로 정의된 provider가 우선이 되기 때문에 순서가 중요합니다.
  ex. identity provider가 가장 첫 번째에 위치하면 모든 Secret 데이터는 평문으로 저장됩니다.
  
  [암호화 방식]
  - aescbc
    - AES-CBC 암호화를 사용하는 프로바이더로 keys field에 지정한 key1이라는 이름의 키를 사용하여 암호화를 수행합니다.
    - secret field에는 실제 사용될 보안 키가 base64로 인코딩되어 있습니다.
  - identity
    - 별도의 암호화를 수행하지 않은 채로 데이터를 평문으로 제공하는 provider로 default 값입니다.

파일 작성이 완료되면 저장한 후 cat /etc/kubernetes/enc/enc.yaml 명령어를 입력하여 파일이 제대로 작성되었는지 확인합니다.

4.2 kube-apiserver 설정 변경

kube-apiserver도 Static Pod이기 때문에 kube-apiserver 관련 manifest 파일은 Control Plane의 /etc/kubernetes/manifest/ 디렉토리에 존재합니다.

vi /etc/kubernetes/manifests/kube-apiserver.yaml 명령어를 입력하여 해당 파일을 편집합니다.
(문제가 발생했을 때 rollback을 빠르게 하기 위해 backup 파일을 생성한 후 해당 파일을 변경하는 것이 권장됩니다.)

spec.containers.command 하위의 flag들이 모여있는 곳에 --encryption-provider-config flag를 추가합니다.
경로는 4.1에서 생성한 manifest file이 저장된 경로(ex. /etc/kubernetes/enc/enc.yaml)를 입력해 주면 됩니다.

volumes과 volumeMounts field에도 관련된 내용을 추가해 줍니다. (실제 존재하는 경로를 입력해 주어야 합니다.)
- volumeMounts field
  - volumes field

변경 사항을 한번 더 확인하고 저장하면 kubelet이 변경 사항을 자동으로 감지하여 kube-apiserver를 자동으로 재생성합니다. (재생성에는 시간이 소요되기 때문에 잠시 기다려야 합니다.)

kubectl get po -n kube-system 명령어를 입력하였을 때 하기와 같이 pod가 정상적으로 조회가 되어야 합니다.

4.3 Secret 데이터 암호화 확인

모든 설정이 완료되었으므로 실제로 변경 사항이 적용되었는지 테스트 해 보겠습니다.

먼저 새로운 Secret을 생성하여 Secret 데이터가 암호화되어 저장되는지 확인해 보겠습니다.

kubectl create secret generic secret-hyein-new --from-literal key=hyeintest-new 명령어를 입력하여 secret을 생성합니다.

그 다음 하기 명령어를 입력하여 ETCD에 저장된 Secret 데이터가 암호화 되었는지 확인합니다.

ETCDCTL_API=3 etcdctl\
   --cacert=/etc/kubernetes/pki/etcd/ca.crt \
   --cert=/etc/kubernetes/pki/etcd/server.crt \
   --key=/etc/kubernetes/pki/etcd/server.key \
   get /registry/secrets/default/secret-hyein-new | hexdump -C

하기 스크린샷의 첫 번째 빨간 박스를 보면 provider가 Secret 데이터를 암호화했음을 보여주는 k8s:enc:aescbc:v1: 이라는 문구가 Secret 이름 뒤에 붙어 있음을 알 수 있습니다.
또한 두 번째 빨간 박스를 보면 이전과는 다르게 Secret 데이터가 평문으로 보이지 않는 것을 알 수 있습니다.

그렇다면 기존 Secret의 데이터도 암호화 되었을까요?

기존 Secret의 데이터를 조회해 보면 하기와 같이 아직까지 암호화가 되어 있지 않은 것을 확인할 수 있습니다.

따라서, kubectl get secrets -A -o json | kubectl replace -f - 명령어를 통해 기존의 모든 Secret 데이터를 암호화하여 ETCD에 저장하여야 합니다.

명령어를 적용하면 하기 스크린샷과 같이 Cluster 내의 모든 Secret이 업데이트되는 것을 확인할 수 있습니다.

다시 한번 기존의 Secret의 데이터를 조회해 보겠습니다.

아까와는 다르게 Secret 데이터가 평문이 아닌 암호화된 형태로 보이는 것을 확인할 수 있습니다.

이렇게 ETCD에 저장되는 데이터에 대한 암호화를 진행해 보았는데요.

이제부터 ETCD에 데이터를 저장할 때에는 암호화가 적용되어서 평문이 아닌 암호화된 형태로 보여지겠 지만

여전히 API Server를 통해서 Secret 값을 가져올 때에는,

즉, kubectl get secrets secret-hyein -o yaml 명령어로 Secret에 저장된 데이터를 조회할 때에는

그대로 Secret 데이터가 노출된다는 문제가 남아 있습니다.

따라서 이 부분까지도 암호화를 하고자 할 경우에는 KMS 플러그인 등을 사용해야 합니다.

이렇게 해서 ETCD에 저장되는 Confidential한 데이터를 암호화하여 저장하는 방법에 대해 알아보았습니다.

완전한 암호화를 위해서는 여전히 고려해야 할 부분이 남아 있지만 CKA를 준비할 때부터 한번쯤은 해보고 싶은 테스트를 무사히 끝냈다는 점에서 굉장히 만족스러운 글이었습니다.

다음에도 좀 더 유익하고 재밌는 글로 돌아오겠습니다!

Virtual Machine으로 Kubernetes Cluster 구성하기 (2)

H-Y-E-N — Mon, 11 Mar 2024 10:43:18 +0900

안녕하세요. HYEN입니다.

지난 글에 이어서 Virtual Machine으로 Kubernetes Cluster를 구성하는 테스트를 다뤄보도록 하겠습니다.

(지난 글 : https://with-cloud.tistory.com/25)

Virtual Machine으로 Kubernetes Cluster 구성하기 (1)

안녕하세요. HYEN입니다. 드디어 미뤄두고 미뤄뒀던 Kubernetes Cluster on Virtual Machine 구성 테스트를 완료하였습니다. VMWare로 한번, Azure Virtual Machine으로 한 번, 총 두 번 테스트를 했던 적이 있

with-cloud.tistory.com

Contents

3. Control Plane 구성

3.1 kubeadm init

Kubernetes Cluster용 [가상 머신] 모두에게 설치해야 할 것들을 모두 설치하였습니다.

지금부터는 Control Plane에서 kubeadm init 명령어를 사용하여 본격적으로 Kubernetes Cluster를 구성해 보도록 하겠습니다.

※ kubeadm init 명령어는 반드시 Control Plane에서만 설치하여야 합니다.※

kubeadm init 명령어를 실행합니다.
- 만약 pod cidr 대역이 기본값과 다르다면 (default : 192.168.0.0/16) --pod-network-cidr flag를 사용하여 사용할 pod의 cidr 대역을 직접 명시해 주어야 합니다.
- (본 테스트에서는 default cidr 대역을 그대로 사용하기 때문에 kubeadm init 명령어만 사용하였습니다.)

테스트 중 발생했던 Preflight Error에 대한 Trouble Shooting 내역을 정리해 보았습니다.

저는 하기와 같은 에러가 발생했는데요. ☠️

4개의 에러를 해결해야 kubeadm init이 정상적으로 실행되게 됩니다.

socket not found in system path라는 문구가 출력되어 있으므로 socket을 설치합니다.
해당 문구는 Warning이기 때문에 설치하지 않으셔도 무방합니다.
- sudo apt-get update && sudo apt-get install -y socat

conntrack not found in system path라는 문구가 출력되어 있으므로 conntrack을 설치합니다.
- sudo apt-get update && sudo apt-get install -y conntrack

/proc/sys/net/bridge/bridge-nf-call-iptables does not exist라는 문구가 출력되어 있으므로 echo 명령어를 사용하여 1을 해당 파일에 넣어 줍니다.
- echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
- 만약 상기 명령어를 입력했을 때 에러가 발생한다면 modprobe br_netfilter 라는 명령어를 실행합니다.
  해당 명령어는 CNI 플러그인이 작동하기 위한 요구사항인 modprobe br_netfilter 모듈을 설치하는 명령어입니다.
- 이 모듈은 Bridge를 통과하는 네트워크 패킷을 필터링하는 역할을 하는데요.
  Kubernetes Cluster에서 Network Policy를 구현하고 트래픽을 관리하는데 도움이 되는 커널 모듈이라고 보시면 됩니다.
- modprobe br_netfilter 명령어를 실행한 후 다시 echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables 명령어를 입력하면 됩니다.

/proc/sys/net/ipv4/ip_forward contents are not set to 1이라는 문구가 출력되어 있으므로 echo 명령어를 사용하여 1을 해당 파일에 넣어 줍니다.
- echo 1 > /proc/sys/net/ipv4/ip_forward

모든 preflight error를 해결하고 난 후 kubeadm init 명령어를 다시 실행하면 정상적으로 초기화가 진행됩니다.

명령어가 성공적으로 실행되면 2가지를 수행해야 합니다.

첫 번째로 하기 명령어를 모든 가상 머신에서 실행하는 것입니다.
- 만약 Node Server에서 상기 명령어가 제대로 작동하지 않을 경우 Control Plane에서 해당 명령어를 먼저 실행한 후 scp 명령어를 통해 해당 파일을 $HOME/.kube (없으면 mkdir -p $HOME/.kube 명령어로 먼저 생성)에 붙여 넣습니다.

두 번째로 kubeadm join으로 시작하는 명령어를 Nodes에서 각각 실행합니다. (root 계정으로 실행해야 합니다.)
- node-hyein-01에서 상기 명령어 수행 결과
- node-hyein-02에서 상기 명령어 수행 결과

join 작업이 완료된 후 Control Plane에서 kubectl get nodes 명령어를 입력하면 하기와 같이 Kubernetes Cluster를 이루는 3 대의 가상 머신이 보이게 됩니다.

3.2 Conatiner Network Interface(CNI) 설치

Kubernetes Cluster 내 pod 통신을 위해서는 CNI(Container Network Interface)가 필요합니다.

CNI는 또 무엇일까요??

Container Network Interface인 CNI는 container 기술에서 network interface를 정의하는 표준 스펙으로, 이를 통해 container가 호스트 및 다른 container, 외부 시스템과 통신할 수 있도록 지원합니다.

CNI는 다양한 network plugin을 통해 구현될 수 있으며 이러한 plugin은 Kubernetes와 같은 orchestration tool에서 사용됩니다.

좀 더 쉽게 정의하자면,

CNI는 container 간 네트워킹에 필요한 plugin에 대한 표준이라고 생각하시면 될 것 같습니다.

이러한 CNI plugin에는 Calico, Weave, Flannel 등 여러 가지 종류의 3rd party plugin이 존재하는데요.

여러 CNI 중 이번 테스트에서는 Calico를 사용해 보도록 하겠습니다.

※ CNI는 반드시 Control Plane에서만 설치하여야 합니다.※

하기 공식 문서를 참고하여 Calico를 설치하면 됩니다. (Manifest 사용)

(https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises)

Kubernetes API datastore에 Calico Networking manifest를 다운로드합니다.
curl <https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/calico.yaml> -O

pod cidr를 변경하였다면 yaml file에서 해당 부분을 변경해 주어야 하지만 본 테스트에서는 기본값을 사용하기 때문에 생략하겠습니다.

manifest를 적용하기 위해 kubectl apply -f calico.yaml 명령어를 입력합니다.
생성을 완료한 후 kubectl get nodes를 해보면 하기 스크린샷과 같이 STATUS가 Ready로 변경되어 있는 것을 확인할 수 있습니다.

3.3 Node Labeling (Optional)

kubectl get nodes를 했을 때 ROLES 부분에 Control Plane은 control-plane이라고 되어 있지만 Node들은 <none>이라고 표기가 되어 있는데요.

저는 이 부분이 마음에 들지 않기 때문에 Labeling을 통해서 각 Node에 node라는 역할을 부여해 보도록 하겠습니다.

kubectl label nodes node-hyein-01 node-role.kubernetes.io/node= 명령어를 실행합니다.
- node-hyein-01 Node의 ROLES column에 node라는 역할이 제대로 부여된 것을 확인할 수 있습니다.

이어서 node-hyein-02 Node도 동일하게 진행해 줍니다.

이렇게 VM 상에 Kubernetes Cluster를 구성하는 과정을 마쳐 보았습니다.

다음 글에서는 지금까지 구성한 Kubernetes Cluster의 ETCD에 저장되는 Secret Data에 대한 암호화에 대해 다뤄보겠습니다.

Virtual Machine으로 Kubernetes Cluster 구성하기 (1)

H-Y-E-N — Thu, 7 Mar 2024 13:50:12 +0900

안녕하세요. HYEN입니다.

드디어 미뤄두고 미뤄뒀던 Kubernetes Cluster on Virtual Machine 구성 테스트를 완료하였습니다.

VMWare로 한번, Azure Virtual Machine으로 한 번, 총 두 번 테스트를 했던 적이 있어 우선 순위에서 밀렸던 것도 사실이긴합니다.

하지만 반복하지 않으면 까먹기 때문에 여유가 생긴 지금! 테스트 내용을 정리해 보고자 합니다.

Contents

1. Virtual Machine 배포

Azure 환경에 [가상 머신]을 세 대 배포하여, 1대는 control plane, 2대는 node로 사용합니다.

1.1 Virtual Machine 배포

1.1.1 [리소스 그룹] 생성

구독 : # 사용할 구독 선택
리소스 그룹 : rg-k8s-test # 리소스 명 입력
영역 : Korea Central # 가상 머신이 배포될 Azure Region 선택

1.1.2 [가상 머신] 생성

세 대 모두 배포 방법은 모두 동일합니다.

본 테스트에서는 이름만 변경하였으나 필요에 따라 control plane의 역할을 하는 [가상 머신]의 SKU를 더 크게 지정할 수 있습니다.

[기본 사항]
- 노란색으로 하이라이트한 부분에 대해 설정을 완료한 후 [다음 : 디스크 >] 버튼을 클릭하여 다음 탭으로 이동합니다.

[디스크] 탭
- OS 디스크 크기 및 OS 디스크 유형을 지정한 후 [다음 : 네트워킹 >] 버튼을 클릭하여 넘어갑니다.
  (본 테스트에서는 default 값을 유지하였습니다.)

[네트워킹] 탭
- [가상 네트워크] 생성
  - 이름, 가상 네트워크의 주소 범위, 서브넷 이름, 서브넷 주소 범위 등에 대해 지정한 후 [확인]을 클릭하여 [가상 네트워크] 생성을 완료합니다.
- [공용 IP] 제거
  - [공용 IP]는 [없음]을 선택합니다.
  - private한 cluster를 구성해야 하기 때문에 [공용 IP]를 붙이지 않습니다.
  - 추후 2번 과정에서 Bastion용 가상 머신과의 VNet Peering을 진행합니다.
- 하기 스크린샷과 같이 설정이 필요한 부분을 확인한 후 [다음 : 관리 >] 버튼을 클릭하여 넘어갑니다.

[검토 + 만들기] 탭
- [검토 + 만들기] 탭을 클릭하여 유효성 검사 후 [가상 머신] 생성을 진행합니다.

위와 같은 방식으로 Node용 [가상 머신]을 두 대 더 생성합니다. (이름은 변경해야 합니다.)

본 테스트에서는 Node용 [가상 머신]의 이름을 node-hyein-01과 node-hyein-02로 지정하였습니다.

1.2 VNet Peering 구성

Kubernetes Cluster를 이루는 가상 머신의 경우 [공용 IP]를 붙이지 않고 private하게 구성하였기 때문에 Local에서 직접 접근할 수 없습니다.

따라서 Bastion용 가상 머신을 생성해야 합니다.

Bastion용 가상 머신은 Kubernetes Cluster를 이루는 가상 머신이 배포된 [가상 네트워크]와 다른 대역에 배포한 후 [VNet Peering]을 진행합니다.

Bastion용 [가상 머신]의 OS 종류는 중요하지 않으며 배포 과정은 이번 글에서는 생략하겠습니다.

(Ubuntu의 경우 상기 2번 과정과 동일합니다.)

연결할 [가상 네트워크] 중 하나를 Azure Portal 상에서 선택한 후 [설정] > [피어링] 탭 > [+ 추가]
[피어링] 정보를 입력합니다.
- 노란색으로 하이라이트한 부분에 대해 설정을 완료한 후 [추가] 버튼을 클릭하여 [피어링]을 진행합니다.

1.3 Virtual Machine 접근

Bastion VM에 접속한 후 각 [가상 머신]에 접근합니다.

VNet Peering을 맺은 상태이기 때문에, Bastion VM에서 각 [가상 머신]으로 정상적으로 접근이 되어야 합니다.

Local Machine > Bastion VM 접근 : ssh hyein@{public ip}
Bastion VM > 각 [가상 머신] 접근
- Control Plane : ssh hyein@10.0.0.4
- Node 01 : ssh hyein@10.0.0.5
- Node 02 : ssh hyein@10.0.0.6

2. Kubernetes Cluster 구성

지금부터는 가상 머신 상에 Kubernetes Cluster를 구축해 볼텐데요.

모든 가상 머신에 동일하게 적용해야 하는 부분에 대해 먼저 다뤄보겠습니다.

2.1 Containerd 설치

Docker를 따로 사용하지 않을 것이기 때문에 Docker를 설치하지 않고 Containerd만 설치를 하도록 하겠습니다.

설치에 앞서 먼저 Containerd가 무엇인지부터 짚고 넘어가 보겠습니다.

Containerd란?

Containerd가 무엇인지에 앞서 먼저 Container Runtime이라는 개념을 알고 넘어가야 하는데요.

Container Runtime이란 container 실행을 담당하는 software이며, 이러한 Container Runtime을 호출할 수 있는 표준화된 인터페이스는 CRI, 즉 Container Runtime Interface라고 합니다.

Kubernetes는 container를 관리하기 위한 Orchestration tool로, 다양한 Container Runtime과 통신하여 container를 관리합니다. 그리고 이 때 이러한 통신을 담당하는 것이 바로 CRI입니다.

CRI가 Kubernetes와 Containerd 간의 표준화된 API를 정의하기 때문에 사용자는 CRI 포맷을 지원하는 Container Runtime을 Kubernetes에서 모두 사용할 수 있습니다.

Docker가 바로 가장 널리 사용되는 Container Runtime 중 하나입니다.
Docker는 CRI 개발 이전부터 널리 쓰이던 Container Runtime이기 때문에 CRI를 준수하지 않습니다.
그렇기 때문에 Docker는 kubelet과 Dockerd 사이에 docker-shim을 사용하여 이를 대신해 왔는데요.

하드코딩된 docker-shim을 유지 보수하는 것이 점점 어려워지고 Docker라는 Container Runtime을 위해서만 이러한 어댑터를 유지하는 것이 표준화와는 거리가 멀기에 Kubernetes는 docker-shim에 대한 지원을 v1.24에서 중단하게 되었습니다.

이러한 CRI를 준수하는 Container Runtime으로는 Containerd와 CRI-O가 있습니다.
그 중 Containerd를 사용하여 이번 테스트를 진행하고자 합니다.

Containerd는 Docker에서도 사용된 Container Runtime 기술로 컨테이너화된 application을 실행, 관리하고 관련된 작업들을 수행하는데 사용되는 Container Runtime이라고 볼 수 있습니다.

Kubernetes v1.24부터는 Kubernetes Cluster를 위해 Docker를 설치하지 않아도 되며, Containerd만 설치해 주면 됩니다.

설명이 굉장히 길어졌습니다..

지금부터 Containerd를 각 [가상 머신]에 설치해 보도록 하겠습니다.

Official Binary를 사용하여 Containerd를 설치하기 위해 하기 링크를 통해 GitHub로 이동합니다.
https://github.com/containerd/containerd/blob/main/docs/getting-started.md

Step 1: Installing containerd 부분에서 tar file을 다운로드 받기 위해 https://github.com/containerd/containerd/releases로 이동합니다.

원하는 버전을 선택한 후 마우스를 우클릭하여 [링크 주소 복사] 버튼을 통해 링크를 복사합니다.
wget {복사한 링크 주소} 명령어를 통해 tar 파일을 각 [가상 머신]에 다운로드 합니다.

tar 파일을 /usr/local 디렉토리에 압축해제 합니다.
- tar Cxzvf /usr/local containerd-1.7.13-linux-amd64.tar.gz
- /usr/local 디렉토리는 보통 사용자가 직접 설치한 소프트웨어를 저장하는 디렉토리이며 여기에 저장된 프로그램은 시스템 전체에서 사용 가능하기 때문에 해당 디렉토리에 tar 파일을 압축 해제 하겠습니다.
- C는 디렉토리 변경 옵션으로 특정 디렉토리에 파일을 압축 해제하기 위해 사용합니다.

systemd를 통해 Containerd service를 관리할 수 있도록 systemd service 파일을 다운로드 한 후 해당 서비스를 /usr/lib/systemd/system/ 디렉토리로 이동시킵니다.
- wget <https://raw.githubusercontent.com/containerd/containerd/main/containerd.service>
- sudo mv containerd.service /usr/lib/systemd/system/

하기 명령어를 사용하여 Containerd service를 시작합니다.
- sudo systemctl daemon-reload
- sudo systemctl enable --now containerd

sudo systemctl status containerd 명령어를 사용하여 Containerd의 상태를 확인합니다.

Step 2: Installing runc에서 runc binary를 설치하기 위해 https://github.com/opencontainers/runc/releases로 이동합니다.

runc.amd64를 선택한 후 마우스를 우클릭하여 [링크 주소 복사] 버튼을 통해 링크를 복사합니다.
wget {복사한 링크 주소} 명령어를 입력하여 runc.amd64를 각 [가상 머신]에 다운로드 합니다.

install -m 755 runc.amd64 /usr/local/sbin/runc 명령어를 입력하여 runc.amd64를 /usr/local/sbin/runc 디렉토리에 설치합니다.

Step 3의 지침을 따르기에 앞서 mkdir -p /opt/cni/bin 명령어를 통해 /opt/cni/bin이라는 디렉토리를 생성합니다.

Step 3: Installing CNI plugins에서 cni plugin을 설치하기 위해 https://github.com/containernetworking/plugins/releases로 이동합니다.

원하는 버전을 선택한 후 마우스를 우클릭하여 [링크 주소 복사] 버튼을 통해 링크를 복사합니다.

wget {복사한 링크 주소} 명령어를 입력하여 cni plugin을 각 [가상 머신]에 다운로드한 후 tar Cxzvf /opt/cni/bin/ cni-plugins-linux-amd64-v1.4.0.tgz 명령어를 입력하여 tar 파일을 /opt/cni/bin/ 디렉토리에 압축 해제 합니다.

Containerd에 대한 설정 파일을 생성하고 변경하기 위해 우선 설정 파일을 저장할 디렉토리를 생성합니다. (mkdir -p /etc/containerd)

Containerd에서 제공하는 config 명령어를 사용하여 default config 정보를 얻고 그것을 config.toml라는 파일에 저장합니다. (containerd config default > /etc/containerd/config.toml)

2. 2 Swap Off

공식 문서를 보면 Kubernetes v1.28에서는 swap memory를 사용할 수 있도록 beta support를 지원한다고 되어 있으나 beta support이므로 일단 swap off를 진행하도록 하겠습니다.

(참고 링크 : https://kubernetes.io/blog/2023/08/24/swap-linux-beta/)

swap off를 진행하기에 앞서, 잠시 swap이 무엇인지 간단하게 확인하고 넘어가겠습니다.

swap은 컴퓨터의 물리적인 RAM이 부족할 때 사용되는 보조 저장소입니다.
OS가 메모리를 효율적으로 관리하기 위해 보통 사용되는데요.

시스템에 메모리가 부족한 경우 OS는 현재 사용되지 않는 메모리를 swap 영역으로 이동시켜 물리적인 메모리 공간을 확보하게 됩니다.

사실 Azure의 [가상 머신]은 기본적으로 swap이 비활성화되어 있기 때문에 해당 부분은 확인만 하고 넘어가시면 될 것 같습니다.

sudo swapon --show 명령어를 입력하였을 때 아무것도 출력되지 않거나, free -h 명령어를 입력하였을 때 하기와 같이 Swap 부분의 total이 0B로 출력되는지 확인합니다.

2. 3 kubeadm, kubelet, kubectl 설치

마지막으로 모든 [가상 머신]에 kubeadm, kubelet, kubectl을 설치해 보겠습니다.

kubeadm은 Kubernetes Cluster를 구성하는데 사용되며 Control Plane과 Node들을 설정하고 필수 구성 요소를 설치하여 Kubernetes Cluster를 준비하는 작업들을 지원합니다.

하기 링크를 참고하여 모든 [가상 머신]에 kubeadm, kubelet, kubectl을 설치합니다.

(참고 링크 : https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)

패키지 매니저를 사용하지 않는 경우를 선택해야 합니다.

CNI plugin의 경우 위에서 이미 설치했기 때문에 해당 내용은 생략합니다.

DOWNLOAD_DIR="/usr/local/bin”의 경우 하기 명령어에서 사용하기 때문에 변수를 선언해 줍니다.

crictl을 설치합니다.

kubeadm, kubelet, kubectl 설치 및 kubelet systemd 서비스를 추가합니다.

kubelet을 활성화하고 시작합니다.

kubectl을 입력하였을 때 하기와 같이 출력되면 세 도구가 정상적으로 설치된 것입니다.
kubelet이나 kubeadm을 입력해서 확인해도 됩니다.

이렇게 Kubernetes Cluster를 이루는 가상 머신을 배포하고 Containerd를 설치하는 등 공통적으로 적용해야 할 부분에 대해 다뤄보았습니다.

다음 글에서는 이를 바탕으로 Control Plane을 초기화하고 Kubernetes Cluster로서 각 가상 머신들이 join하는 방법, 그리고 Node에 대한 Roles을 Labeling하는 방법에 대해 알아보겠습니다.

CKAD 시험 후기

H-Y-E-N — Mon, 4 Mar 2024 18:03:16 +0900

안녕하세요. HYEN입니다.

오랜만에 블로그에 글을 적는 것 같은데요.

그동안 CKAD 시험을 준비하느라 블로그를 쓸 시간이 없었다는 핑계를 대며,, 시험 후기를 적어 보도록 하겠습니다.

Contents

1. CKAD (Certified Kubernetes Application Developer)란?

사실 CKAD가 무엇인지에 대해서는 이미 많은 블로그에서 정리를 잘 해 놓았기 때문에 굳이 정리하지 않으려고 하다가 그래도 해야 하지 않나 싶어서 정리해 보았습니다. (●'◡'●)

Linux Foundation 홈페이지에는 CKAD에 대해 다음과 같의 설명하고 있습니다.

The Certified Kubernetes Application Developer (CKAD) exam certifies that candidates can design, build and deploy cloud-native applications for Kubernetes.

즉, CKAD는 Kubernetes를 위한 클라우드 네이티브 application을 설계하고 빌드하고 배포할 수 있는 능력이 있는지에 대해 검증하는 시험이라고 볼 수 있습니다.

현재 자격증의 유효 기간은 취득 후 36개월이지만 2024년 4월 1일부터 24개월로 변경되기 때문에, 혹시라도 시험 계획이 있으신 분들은 4월 1일 이전에 시험을 보시는 것을 권장드립니다.

자세한 내용은 링크 참고 부탁드립니다. (https://training.linuxfoundation.org/certification-policy-change-2024/)

2. CKAD 시험 결제 및 예약 + Killer shell

사실 작년에 CKA를 이미 취득한 상태라 시험 결제 및 예약에 큰 문제는 없었으나, 그래도 혹시나 하는 마음에 정리를 해 보았습니다.

CKAD는 $395, 한화로 53만 5700원(글 작성일 기준)이라는 많은 비용이 드는 시험입니다.

2번의 기회를 주기는 하지만 그래도 여전히 큰 돈이죠.

저는 작년 11월 경 50% 할인 쿠폰을 사용해서 미리 결제를 해 두었기 때문에 $197.50에 결제하였지만 그래도 여전히 비싸긴 합니다. ㅠ

매년 11월 Cyber Monday에 CKA나 CKAD 같은 시험에 대한 할인 voucher가 제공되고 결제 후 1년 이내에만 시험을 보면 되기 때문에 이때를 노리시는 것도 그나마 싸게 결제할 수 있는 방법입니다.

물론 이때 말고도 거의 상시 25~30% voucher는 존재하기 때문에 구글링을 통해서 voucher를 확인하시길 바랍니다.

결제를 하고 난 후, My Portal에 접속하시면 하기와 같은 화면이 나오는데요,

저는 이미 시험을 본 상태라 [View Certificate]이라고 표시되지만, 오른쪽의 파란색 버튼을 클릭하면 시험을 응시하기 위한 단계를 안내하는 페이지로 리다이렉트 됩니다.

각 단계별로 초록색 버튼이 될 수 있도록 안내되는 사항을 준수하시어 설정 또는 스케줄링을 완료하시면 시험 예약은 끝입니다.

Killer Shell은 CKAD 시험을 결제하게 되면 주는 시험입니다.

이름부터 지독해 보이는데요.

시험과 똑같은 환경을 미리 체험할 수 있는, 시험보다 난이도가 있는 모의시험이라고 생각하시면 됩니다.

3. CKAD 시험 준비

시험 준비는 모두의 바이블이죠.

Udemy에 있는 "Kubernetes Certified Application Developer (CKAD) with Tests" 를 완강했습니다.

CKA도 "Certified Kubernetes Administrator (CKA) with Practice Tests" ← 이 강의를 다 듣고 시험을 응시했습니다.

Section 별로 명확하게 분리되어 있고 내용이 매우 알차기 때문에, 저는 단순히 시험 응시를 목적으로 이 강의를 수강했다기보다 Kubernetes에 대해 기초적인 지식을 전체적으로 정리하기 위한 목적으로 수강했습니다.

CKA와 겹치는 부분도 있기는 하지만 기본적으로 다루고 있는 범위가 완전히 겹치지는 않기 때문에 CKAD 강의도 다시 한번 수강했습니다.

CKA가 Kubernetes의 전반적인 부분을 다루고 있다면 CKAD는 그보다 좀 더 딥하게 일부를 본다는 느낌이 강했습니다.

또한 Application Developer가 갖춰야 하는 지식을 검증하는 시험답게 Docker나 Helm에 대해서도 다루고 있어서 저는 CKA보다 좀 더 어렵다는 생각이 들었습니다. (그렇다고 CKA보다 CKAD가 더 어렵냐? 하면 또 그것은 아닙니다.)

정리하자면,

CKA는 Kubernetes의 전반적인 요소들을 다루고 있어서 공부해야 할 범위가 넓어 어렵고, CKAD는 범위는 CKA보다 좁으나 Docker나 Helm 등 Kubernetes와 떼려야 뗄 수 없는 다른 tool까지 시험 범위에 포함되어 어렵습니다. (˘･_･˘)

Udemy 강의 + Section별 Kode Kloud 문제 풀이 + Mock Exam까지 끝낸 후 저는 시험 하루, 이틀 전에 Killer Shell의 문제를 활성화하여 마지막으로 시험에 대한 감을 잡을 수 있도록 했습니다.

CKAD 시험 결제 후 제공되는 Killer Shell 문제는 2개의 Session이 제공되며 각각 36시간 동안 활성화 되어 있습니다.

Session은 2개가 제공되지만 문제는 동일합니다.

36시간 동안은 몇 번이고 시험을 응시할 수 있으며, 해당 환경은 시험과 동일합니다.

저는 CKA 시험을 응시했을 때 한 Session을 활성화하지 않아서 아직도 Not Activated 상태로 하나가 존재하는데요.

(CKAD는 시간 계산을 잘못해서 두 개의 Session을 활성화 했습니다. 36시간은 1일하고 12시간인데 3일로 생각해서.. )

활성화 되지 않은 simulator을 클릭하면 하단에 Activate Session이라는 빨간 박스가 있고, 그걸 누르게 되면 그때부터 36시간 동안 Session이 활성화 됩니다.

시험과 환경이 동일하기 때문에 Killer Shell을 통해 해당 환경에 적응할 수 있도록 연습하는 것을 권장드립니다.

사실 Killer Shell의 문제는 반만 맞아도 시험에 합격하는데 전혀 문제가 없다고 할 정도로 난이도가 높습니다.

따라서 편한 마음으로 주어진 문제 중 반만 맞추겠다라는 마음으로 응시하셔도 된다고 생각합니다.

단, 해설이 제공되기 때문에 시험을 본 후에 꼭 오답을 체크하시길 바라며,

저는 못 풀었던 문제까지 다 풀 수 있을 만큼 Killer Shell Session을 활용한 후에 시험에 응시하였습니다.

마지막으로,

노트북의 경우 저는 Surface Laptop으로 응시해서 화면이 매우 작았습니다.

노트북 화면은 거거익선입니다! 무조건 큰 노트북으로 응시하시길 바랍니다.

4. CKAD 시험 응시 중 주의 사항

저는 CKA나 CKAD 모두 시험 보다는 시험을 보기 전 체크인 과정이 더 힘들고 진이 빠졌던 것 같습니다.

시험 전 시험 환경 체크 과정이 굉장히 빡빡하게 진행되기 때문에 체크인 시간이 되면 바로 접속하시는 것을 추천드립니다. (저도 이 30분을 다 쓸 줄 몰랐으나, CKA, CKAD 모두 거의 30분을 다 사용했습니다.)

처음에 네트워크 및 마이크 등에 대한 환경 체크를 진행하게 되는데요, 저는 회사 와이파이를 썼음에도 네트워크 품질이 시험을 볼 정도로 좋지 않다는 결과를 받아서 ☠️ x 100000000 결국 핫스팟으로 진행했습니다.

체크인 과정과 시험 감독을 한 proctor가 진행하며 proctor와는 대화가 아닌 채팅으로 의사소통하게 됩니다.

생각보다 요구하는 사항들이 많기 때문에 최대한 책상에 아무것도 없고, private 한 공간에서 시험을 응시하는 것이 좋습니다.

저 같은 경우, 천장을 보여달라고 해서 보여줬더니 비상구 사인을 다시 보여달라고 하면서 뭐냐고 물어보기도 하고,

시험을 보는 회의실에 있던 TV 모니터가 계속 꺼져 있다는 것을 증명하라고 해서 TV 모니터의 코드를 뽑기까지 했습니다.

음료는 투명한 컵에 담긴 무색의 액체만 반입 가능하며 그 외에는 예외 없이 금지입니다.

카메라를 통해 책상 위, 아래, 천장 등 모든 곳을 보여주어야 하기 때문에 다시 한번 넉넉하게 체크인을 진행하시기를 권장드립니다.

여권으로 본인 인증을 했는데, 본인 인증을 하는 과정에서 여권 사진을 업로드해야 합니다.

저는 처음에 핸드폰으로 여권 사진을 찍어서 본인 인증을 하기 위해 제공되는 QR 코드를 찍어서 여권 사진을 찍었는데요.

뭐가 문제인지 업로드가 너무 오래 걸려서 그냥 노트북으로 사진 찍기를 눌러서 본인 인증을 진행했습니다.

이렇게 체크인 과정이 끝이 나면 바로 시험이 진행됩니다.

사실 체크인 과정에서 너무 진이 빠지다보니 저는 두 번의 시험 모두 시험 중에는 그렇게 떨리지 않았던 것 같습니다.

5. CKAD 시험 출제 내용

사실 저는 Custom Resource Definition이나 Admission Controller가 출제 범위에 포함되어 있어 상당히 걱정을 많이 했었습니다.

Udemy 강의를 들을 때에도 해당 부분은 처음 접하는 내용이라 집중해서 듣고 Kode Kloud 문제도 여러 번 풀었으나 아무래도 익숙치 않은 내용이라 나오지 않기만을 바랐는데,, 사실 후기를 찾아보니 아직까지 해당 부분과 관련된 문제가 나온 적은 없는 것 같습니다.

기억 나는 대로 시험 출제 내용을 적어보자면 총 16문제가 나왔고 문제는 하기와 같습니다.

Nginx ENV 등록하고 port expose
Docker image build하고 OCI format으로 export하기 (tar 파일로)
Canary Deployment
Persistent Volume, Persistent Volume Claim 생성하여 Bound 확인
배포되어 있는 Network Policy 수정하지 않고 주어진 pod간만 통신하도록 Service랑 Deployment yaml file 수정
Deployement와 연결된 Service Name 수정하는 거
container 수준에서 Security Context 추가
Namespace limit 확인하여 Namespace에 할당된 memory limit의 반을 Deployment 내 pod별 limit으로 지정 + memory request 지정
CronJob 생성
Deprecated된 거 버전 변경
Secret 생성한 후 Environment Variables 형태로 pod 내 container 단에 정의
Readiness Probe 생성
rolling update 관련 설정 변경 및 image 버전 변경한 후 이전 버전으로 rollback 진행
Logging 관련 문제

시험이 끝난 후에 생각나는 것을 적었다 보니 두 문제 정도는 기억이 잘 나지 않는데 시험 합/불에 영향을 줄 만한 어려운 문제는 아니었던 것으로 기억합니다.

2, 3이 사실 저는 제일 까다로웠고 이 외에는 크게 문제가 없었습니다.

2는 정말 보자마자 멘붕이었는데요.

image build까지는 크게 문제가 없었으나 OCI Format? tar file? 이라는 생각이 들면서 일단 flag를 걸어두고 다음 문제를 풀러 갔던 기억이 납니다. 시험을 본 후에 명령어를 찾아보니 docker save -o {tar file 이름} image:tag를 했어야 했던 것 같습니다.

3은 Canary Deployment 자체를 어떻게 하는 것인지 이론적으로만 생각하고 있다가 직접 하라고 하니까 당황했었는데요. 그렇기 때문에 이 부분도 빠짐 없이 꼼꼼하게 공부하고 가시길 바랍니다.

한 가지 주의할 점은, 제가 Killer Shell 문제를 풀 때엔 제공되는 yaml file을 백업 없이 수정하면 오류가 났을 때 rollback하기 어려울 것 같아 문제 번호.yaml 과 같은 식으로 백업 파일을 생성한 후에 그 백업 파일을 수정하는 방식을 택했습니다. 수정한 백업 파일로 apply가 잘 되면 그 후에 cp 명령어로 제공되는 파일을 덮어쓰기 하는 식이었는데요. 그러다 보니까, apply가 성공하면 신나서 다음 문제로 넘어가서 cp 명령어를 하지 않을 때도 있었습니다.

처음에 문제를 풀었을 때 생각보다 점수가 낮게 나와 놀랐는데 이 이유가 모두 위에 적은 방식으로 문제를 풀었기 때문이었습니다. 그래서 시험 중에는 백업 파일을 만들고, 제공된 yaml 파일을 수정하였습니다.

어찌보면 당연한 내용이기는 하지만, 맞은 문제도 이 때문에 틀리게 채점이 될 수 있기 때문에 혹시나 하는 마음에 적어 보았습니다.

저는 최종적으로 100점 만점에 91점으로 시험에 합격하였습니다.

여러 일이 겹쳐서 걱정이 많았던 시험이지만 그래도 결과가 좋아서 다행이라는 생각을 하며, 이번 글을 마무리 하도록 하겠습니다.

2부 : Prometheus(+ Node Exporter, AlertManager) + Grafana 구성하기

admin_cloud — Tue, 20 Feb 2024 10:59:45 +0900

안녕하세요. TAK 입니다:)

지난 1부에 이어서 2부 "Grafana 대시보드화 구성과 AlertManager 를 통한 알림 서비스 연동" 으로 돌아왔습니다!

1부와 이어지는 내용이기에 아래 링크를 통해서 확인 후에, 이번 포스팅을 팔로우 하시면 이해하는 데 편하실거에요:)

1부 : Prometheus(+ Node Exporter, AlertManager) + Grafana 구성하기

안녕하세요. TAK 입니다:) 요번 Monitoring & Alert 를 위해 많이 사용되는 "Prometheus(+ Node Exporter) + Grafana" 주제를 준비했습니다! (별도의 Category 를 만들까 했지만, 제가 처음으로 포스팅한 내용처럼 조

with-cloud.tistory.com

그럼 시작하겠습니다!

Contents

2-1. Grafana 구성

2-1-1. Grafana 설치

구성도에서 처럼 Promethues Server가 아닌, 별도의 Grafana Server(Ubuntu 22.04)에서 구성하겠습니다.

자세한 사항은 Offical Docs 를 참고해 주세요!

(가이드 등 세부 내역이 상세히 잘 되어 있는 느낌..!)

Download Grafana | Grafana Labs

Overview of how to download and install different versions of Grafana on different operating systems.

grafana.com

Grafana Packages Repository 추가

sudo apt-get install -y apt-transport-https software-properties-common wget

# GPG key
sudo mkdir -p /etc/apt/keyrings/
wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

# To add a repository for stable releases
echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list

# Updates the list of available packages
sudo apt-get update

# Installs the latest OSS release:
sudo apt-get install grafana

Systemd Service 시작

sudo systemctl daemon-reload

sudo systemctl enable grafana-server.service
sudo systemctl start grafana-server.service
sudo systemctl status grafana-server.service

NSG 확인
- Azure Ubuntu의 경우, 방화벽의 Default 값은 Inactive 이므로, NSG(Netwokr Security Group)에서 제어합니다.
- Grafana의 Default Port : 3000

2-1-2. Grafana 설정

액세스 확인 및 초기 Login 정보
- 초기 Login 정보 > ID : admin / PW : admin
- 최초 접속 이후에, PW 변경 지시에 따라 변경 권장

Data Source 설정하기
- 실제 시각화할 데이터의 원본을 설정하는 단계입니다.

Prometheus Server 추가

Promethues Server의 URL 추가
- 연결을 위한 아래 빨간 네모 박스 설정 이외에 인증, 보안 등 여러 설정이 있지만, 해당 과정에서는 Defualt 값으로 진행합니다.
- 또한, UI 상에서 Prometheus, Grafana 사용을 위해 VM의 연결된 Public IP를 사용했지만, 모든 연결 설정은 Private IP 사용합니다.

→ 빨간 네모 박스 안, Prometheus Server URL의 경우
1부에서 구성한 /etc/prometheus/prometheus.yml 파일의 "localhost:9090" 입니다.

다만, 위 값에는 VM에 할당된 Private IP를 기입하여 "http://<Private IP>:9090" 입력합니다.

(여기서, Priavte 환경에서는 VM의 Private IP를 적지만, 우선 Public IP도 함께 사용 중이므로 localhost 값을 유지하였습니다.)

연결 확인

2-2. Grafana 대시보드

2-2-1. Self 테스트 구성

초기 빈(Empty) 구성의 Custom Panel 생성

대시보드를 위한 구성
- 1,2번 항목 : 대시보드화할 Metics 종류와 Filter 선택
- 3번 항목 : 1,2번 항목에서 선택 값이 구체화되는지 확인
- 4번 항목 : 대시보드에 해당 값을 저장

Visualizations(Chart종류) 및 Panel의 이름

대시보드 확인
- 위 단계를 반복하며 원하는 Metrics과 Filter 선택하여 목적에 맞게 대시보드 구성

구성 대시보드 저장

2-2-2. Template 사용 구성

Grafana 에서 제공하는(타 사용자들이 공유) Template을 활용한 대시보드를 구성합니다.

Import

대시보드 적용 Sample 확인
- 아래 사이트에서 대시보드에 적용할 샘플을 업로드합니다.
- 해당과정에서는 Copy ID (URL 혹은 ID) 방식을 사용합니다.
  
  Dashboards | Grafana Labs
  
  Thank you! Your message has been received!
  
  grafana.com

Copy ID 적용 후, Import dashboard를 위한 Options 설정

2-3. 멋진 최종 DashBoard 확인

Import 기능을 사용하여 제공되는 여러 Template을 기반으로 일반적인 Metrics 활용한 멋진 대시보드 완성!
제공되는 여러 옵션을 선택하여 다양한 시각화를 제공합니다.

2-4. Alertmanager 구성

2-4-1. Alertmanager 설치

Alermanager도 위 단계에서 사용한 Grafana VM에서 설치하여 사용합니다.

Binary 파일 다운로드

Download | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

prometheus.io
```
wget https://github.com/prometheus/alertmanager/releases/download/v0.26.0/alertmanager-0.26.0.linux-amd64.tar.gz
```
Alermanager 시스템 그룹 및 사용자 할당(+ 디렉터리 생성)

sudo groupadd --system alertmanager
sudo useradd -s /sbin/nologin --system -g alertmanager alertmanager

sudo mkdir -p /etc/alertmanager/templates
sudo mkdir /var/lib/alertmanager
sudo chown alertmanager:alertmanager /etc/alertmanager
sudo chown alertmanager:alertmanager /var/lib/alertmanager

압축 풀고, 디렉터리 이동

tar -xvf alertmanager-0.26.0.linux-amd64.tar.gz
cd alertmanager-0.26.0.linux-amd64.tar.gz

Binary 파일 (로컬) 이동 및 소유자 설정

sudo mv alertmanager /usr/local/bin
sudo mv amtool /usr/local/bin
sudo chown alertmanager:alertmanager /usr/local/bin/alertmanager
sudo chown alertmanager:alertmanager /usr/local/bin/amtool

구성 파일 이동 및 소유자 변경

sudo mv alertmanager.yml /etc/alertmanager/alertmanager.yml
sudo chown alertmanager:alertmanager /etc/alertmanager/alertmanager.yml

Alertmanager Systemd Service 만들기

sudo nano /etc/systemd/system/alertmanager.service


[Unit]
Description=AlertManager
Wants=network-online.target
After=network-online.target

[Service]
User=alertmanager
Group=alertmanager
Type=simple
ExecStart=/usr/local/bin/alertmanager \
        --config.file /etc/alertmanager/alertmanager.yml \
        --storage.path /var/lib/alertmanager/ \
        --cluster.advertise-address="<Private IP>:9093"
        
[Install]
WantedBy=multi-user.target

** (Alertmanager의 HA mode) The cluster.advertise-address flag is required if the instance doesn't have an IP address that is part of RFC 6890 with a default route.

GitHub - prometheus/alertmanager: Prometheus Alertmanager

Prometheus Alertmanager. Contribute to prometheus/alertmanager development by creating an account on GitHub.

github.com

구성 사항 반영을 위해 Reload Systemd

sudo systemctl daemon-reload

2-4-2. Alertmanager Service 시작

sudo systemctl enable alertmanager
sudo systemctl start alertmanager

sudo systemctl status alertmanager

방화벽 허용(Azure NSG 허용 정책)
- Azure의 VM의 경우, 방화벽 설정이 Default 값으로 Inactive(비활성화) 입니다.
- 따라서, 해당 과정에서는 NSG 정책으로 In/Out Bound 제어합니다.
  - InBound 정책 추가 : Default Port 9093

Prometheus 정상 액세스 확인
- 내부 확인 : curl -X GET http://localhost:9093

2-4-3. Prometheus Server연동

다음과 같은 목적을 기반으로 작업 수행을 위해 Prometheus Server를 구성합니다.

- Prometheus Server에서 Sraping 한 메트릭 데이터를 기반으로 Alertmanager에서 Alert을 보낼 수 있도록

- Grafana에서 Alertmanager에 대한 영역을 모니터링할 수 있도록

Config 변경(추가)
- Alertmanager를 Grafana VM에서 구성했기에, 해당 VM의 <Private IP>:9093 를 Target으로 입력합니다.
- 별도의 NSG 정책을 추가하지 않는다면, Azure에서는 기본 정책으로 VNET 내 Private IP 기반 통신의 경우, Source/Destination 및 Port의 제한이 없습니다.

sudo nano /etc/prometheus/prometheus.yaml

서비스 재시작하여 변경값 적용

sudo systemctl restart prometheus

Prometheus Target 정상 UP 확인
- 위 Config 값에 구성한 값이 정상 반영된 것을 확인할 수 있습니다.

2-5. Alertmanager 경고 규칙 만들기

Prometheus Server 에서 정의한 경고 규칙에 따라, Alertmanager 가 정해진 구성값(ex. Slack, Email)을 기반으로 알림(Alert)를 보내기 위한 단계입니다.

Prometheus Server 에서 Rule 생성
- 규칙의 경우, Sample 제공하는 사이트의 자료를 참고하였습니다.
- 총 5개의 규칙을 위한 조건을 정의하였습니다.
  - InstanceDown
  - HostHighCpuLoad
  - HostOutOfMemory
  - HostMemoryUnderMemoryPressure
  - HostOutOfDiskSpace

sudo nano/etc/prometheus/alert_rules.yml


groups:
- name: alert_rules
  rules:
  # instance(Host VM) is down on {{ $labels.instance }}
  - alert: InstanceDown
    expr: up == 0
    for: 0m
    labels:
      severity: "critical"
    annotations:
      summary: "Endpoint {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."
 
  # CPU load is > 80%
  - alert: HostHighCpuLoad
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 80
    for: 0m
    labels:
      severity: warning
    annotations:
      summary: "Host high CPU load (instance {{ $labels.instance }})"
      description: "CPU load is > 80%\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"      

  # Node memory is filling up (< 10% left)	
  - alert: HostOutOfMemory
    expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Host out of memory (instance {{ $labels.instance }})"
      description: "Node memory is filling up (< 10% left)\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"

  #The node is under heavy memory pressure. High rate of major page faults
  - alert: HostMemoryUnderMemoryPressure
    expr: rate(node_vmstat_pgmajfault[1m]) > 1000
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Host memory under memory pressure (instance {{ $labels.instance }})"
      description: "The node is under heavy memory pressure. High rate of major page faults\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"
 
  # Disk is almost full (< 10% left) 
  - alert: HostOutOfDiskSpace
    expr: (node_filesystem_avail_bytes * 100) / node_filesystem_size_bytes < 10 and ON (instance, device, mountpoint) node_filesystem_readonly == 0
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Host out of disk space (instance {{ $labels.instance }})"
      description: "Disk is almost full (< 10% left)\n  VALUE = {{ $value }}\n  LABELS: {{ $labels }}"

Rules 적용
- 위 작성한 Rule에 대한 스크립트를 Promethues Config에 반영합니다.

sudo /ect/prometheus/prometheus.yml

Prometheus Server 서비스 재기동

sudo systemctl restart prometheus.services

Rules 반영 확인
- Prometheus Server 접속 > Status > Rules
- Prometheus Server > Alerts

2-6. Alertmanager 통한 Slack 알림 보내기

자, 이제 마지막 단계입니다.

최종적으로 수집된 메트릭 데이터를 기반으로 규칙을 반영하여 Slack에 알림 보내겠습니다!

(메일 알림의 경우, 타 자료가 많은 관계로 생략하였습니다_._)

Alermanager Config 설정
- slack_api_url의 값에 Slack에서 생성한 Incoming Webhook 앱의 URL 값을 입력합니다.
  (이번 포스팅에서는 발급 과정에 대해서는 생략합니다.)
- 보다 자세한 사항(옵션값의 대한 정의 등)은 공식 Docs를 참조
  
  Configuration | Prometheus
  
  An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.
  
  prometheus.io

실제 알림을 위해 Node 중 1대의 VM을 OFF
- Alertmanager 확인(InstanceDown)
- Premetheus 확인
- Slack 알림 확인

지금까지 2부 "Grafana 대시보드화 구성과 AlertManager 를 통한 알림 서비스 연동" 알아보았습니다.

이것으로 1,2부 동안 진행한 "Prometheus(+ Node Exporter, AlertManager) + Grafana 구성" 포스팅을 마치겠습니다.

궁금한 점이나 이번 포스팅에서 부족한 점 등 자유로운 의견을 남겨주세요!

(!많관부!) 다음에도 함께 공유할 수 있는 주제를 가지고 찾아뵙겠습니다. (!많관부!)

1부 : Prometheus(+ Node Exporter, AlertManager) + Grafana 구성하기

admin_cloud — Thu, 15 Feb 2024 17:16:36 +0900

안녕하세요. TAK 입니다:)

요번 Monitoring & Alert 를 위해 많이 사용되는 "Prometheus(+ Node Exporter) + Grafana" 주제를 준비했습니다!

(별도의 Category 를 만들까 했지만, 제가 처음으로 포스팅한 내용처럼 조금 더 포괄적인 영역인 DATA 분야에 포스팅하게 되었습니다.)

조금 더 자세한 전달을 위해 1부 & 2부로 나눠서 포스팅할 예정입니다.

1부에서는 개념과 테스트 환경의 설명, Prometheus 및 Node Exporter 설치와 구성
2부에서는 Grafana 대시보드화 구성과 AlertManager 를 통한 알림 서비스 연동

자, 그럼 본격으로 1부 시작하겠습니다!

Contents

1-1. Prometheus 란?

: Promethus 란, 시스템 모니터링 및 경고를 위해 SoundCloud 에서 구축된 오픈소스 ToolKit 입니다.

현재는 독립된 오픈소스 프로젝트로 Kubernetes와 같이 거버넌스에 종속되지 않는 Cloud Native Computing Foundations에 합류했다고 합니다.

주된 목적은 모니터링으로 서비스 운영 중 발생할 수 있는 이슈 및 장애 대비를 위해 사용되며, 시계열 데이터를 수집하고 기록하며, 이를 구체화(수치화, 시각화)하는 것이라고 표현할 수 있습니다.

Timestamp와 함께 측정항목의 이름과 Key-Vaule 쌍으로 기록되며, 시계열이라 함은 시간에 따른 변화를 기록하는 것을 의미합니다. 이러한 다차원 데이터 모델을 활용하기 위한 별도의 PromQL이라는 쿼리언어가 존재합니다.

모니터링에는 2가지 매커니즘이 존재합니다.

1. pull-based monitoring system
2. push-based monitoring system

Prometheus 에서는 아래 보이는 것과 같이 대상(Targets)으로부터 메트릭 값을 Pull

즉, 가져오는(받아오는) 방식을 사용하고 있습니다. 예를 들어, Node Exporter 라는 Agent가 설치된 대상(Tagets) 서버의 메트릭을 수집하면, 중앙 시스템(Prometheus Server)가 데이터를 Scraping 하는 방식입니다.

이러한 Pull - Push 방식은 사용자의 관점이나 환경에 따라 장단점이 존재합니다.

Pull의 경우만 살펴보자면,

중앙 시스템(Prometheus Server)는 직접(수동) 접근하여 데이터를 수집하기에 신뢰성이 높으며, Health Check에서도 연결 구성이 비교적 단순하기에 Trobleshooting이 수월한 점 등이 있습니다.

출처 : https://prometheus.io/assets/architecture.png

위 그림처럼 Prometheus 생태계는 여러 구성 요소들로 이뤄질 수 있습니다.

(대부분의 Prometheus 구성 요소는 Go 언어로 개발되었으며, 정적 바이너리로 쉽게 구축하고 배포할 수 있습니다.)

생태계 구성 요소와 각 기능을 설명하자면 다음과 같습니다.

데이터 수집
: 중앙 시스템 역할을 하는 Prometheus Server 의 요소 중 하나인 Retrieval에서는 Service discovery에 정의되어 있는 Target을 식별합니다. Target이 정의되면 Retrieval에서 Target에 존재하는 Exporter를 통해 메트릭을 스크래핑 합니다.

Service discovery는 Kubernetes Cluster 과 같은 Auto-Scale Target 에 대해 메트릭을 수집 대상을 동적으로 설정 가능하도록 yaml 형태로 정의한 파일로 저장되어 있습니다.

또한, Pushgateway 는 말 그대로 데이터를 push 받아주는 서버(From Exporter) 입니다.
이는 역할은 단일(임시) 또는 배치 작업과 같은 수명이 짧은 서비스에 대한 메트릭을 가져오기위해 사용 합니다.
데이터 저장
: Prometheus Server 구성 요소를 살펴보면, Pull Metrics 방식으로 데이터를 수집하는 역할을 하는 Retrieval,
이러한 데이터가 저장되는 Local Storage인 TSDB(Time Series Database), 그리고 이러한 데이터를 API와 PromQL등 사용하여 대시보드화 등 활용가능케 하는 HTTP Server로 구성되어 있습니다.

*데이터 저장소는 Remote Storage(Disk, Volume) 사용 가능.

데이터 시각화, 알림
: Prometheus Server 의 HTTP Server 는 수집한 메트릭 데이터를 HTTP 엔드포인트를 통해 활용될 수 있습니다. Grafana와 같은 대시보드를 위한 애플리케이션을 사용하여 PromQL 쿼리하여 데이터를 시각화할 수 있습니다.

또한, API 방식으로 Alertmanager를 통해 수집한 메트릭 데이터 정보를 바탕으로 임계값을 조건에 맞춰 생성하고, 이데 따른 알림 및 경고를 E-mail, Slack 등 다양한 채널로 최종 사용자에게 전송하는 역할을 합니다.

1-2. 테스트 환경

출처 : https://training.promlabs.com/static/node-exporter-architecture-570e9857c08bbb0008022f76606fa749.svg

위 예시처럼 Linux 서버에 Node Exporter를 사용하여 중앙 시스템(Prometheus Server)에서 메트릭 데이터를 Scraping 하는 구성도는 다음과 같습니다.

이러한 구조는 Azure 환경에서 주로 사용되는 Hub-Spoke 구조에 적합?하여, Hub 영역에 Promethues Server를 배치하고, 메트릭 데이터를 수집하는 위 구성도를 반영하였습니다.

우선, 서로 다른 네트워크(대역)을 VNET(Virtual Network) Peering을 통해 통신 가능한 상태로 구현하였습니다.

(VPN은 비용상 문제가 있어서... 양해를..)

Target VM을 서로 다른 Linux 계열을 사용하였으며, Subnet으로 구분한 이유는 NSG(Network Security Group)에 따른 In/Out Bound 정책을 제어하고자 하는 목적이 있습니다.

현재 구성에 대한 세부 사항은 아래 접은글을 참고해주세요!

사용된 리눅스 계열(정보) 참조

- Ubuntu 22.04

- Rocky 8

- RHEL 8.7

Peering 연결 설정 그리고 간단한 통신 테스트 내용 참조

VNET Peering
- Peering 대상 : tak-PG-vnet (172.168.10.0/24) - tak-prometheus-vnet(10.0.30.0/24)
- 각 대상 VNET 선택 > 설정 > [피어링] 추가

연결 및 통신 확인
- Target VM 중 Ubuntu VM 정상 연결 확인(Ping, Telnet)

1-3. Prometheus Server 설치

이번 포스팅에서는 Binary 설치 방식을 사용하였습니다.

(Docker 를 통한 설치는 추후 Kubernetes 환경에서 모니터링 포스팅에서 다룰 예정이랍니다!)

1-3-1. 설치를 위한 기본 설정

Package Update

sudo apt update

Prometheus 시스템 그룹 및 사용자 할당

sudo groupadd --system prometheus
sudo useradd -s /sbin/nologin --system -g prometheus prometheus

Prometheus 용 디렉터리 생성 및 권한 설정

sudo mkdir /etc/prometheus
sudo mkdir /var/lib/prometheus

sudo chown -R prometheus:prometheus /var/lib/prometheus

1-3-2. 설치를 위한 Binary 파일 구성

아래 링크에서 원하는 버전 선택하여 진행
- 현재 글은 최신 버전으로 구성

Download | Prometheus

An open-source monitoring system with a dimensional data model, flexible query language, efficient time series database and modern alerting approach.

prometheus.io

wget https://github.com/prometheus/prometheus/releases/download/v2.43.0/prometheus-2.43.0.linux-amd64.tar.gz

압축 풀고, 디렉터리 이동

tar vxf prometheus*.tar.gz

cd prometheus*/

Binary 파일 (로컬)이동 및 소유자 설정

sudo mv prometheus /usr/local/bin
sudo mv promtool /usr/local/bin
sudo chown prometheus:prometheus /usr/local/bin/prometheus
sudo chown prometheus:prometheus /usr/local/bin/promtool

구성 파일 이동 및 소유자 변경

sudo mv consoles /etc/prometheus
sudo mv console_libraries /etc/prometheus
sudo mv prometheus.yml /etc/prometheus

sudo chown prometheus:prometheus /etc/prometheus
sudo chown -R prometheus:prometheus /etc/prometheus/consoles
sudo chown -R prometheus:prometheus /etc/prometheus/console_libraries
sudo chown -R prometheus:prometheus /var/lib/prometheus

Prometheus Config 파일 수정
- 지금 단계에서는 변경 사항없이 Default 값에 대한 정보만 확인합니다.

sudo nano /etc/prometheus/prometheus.yml

Prometheus Systemd Service 만들기

sudo nano /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \\
    --config.file /etc/prometheus/prometheus.yml \\
    --storage.tsdb.path /var/lib/prometheus/ \\
    --web.console.templates=/etc/prometheus/consoles \\
    --web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

구성 사항 반영을 위해 Reload Systemd

sudo systemctl daemon-reload

1-4. Prometheus Serivce 시작

sudo systemctl enable prometheus
sudo systemctl start prometheus

sudo systemctl status prometheus

방화벽 허용(Azure NSG 허용 정책)
- Azure의 VM의 경우, 방화벽 설정이 Default 값으로 Inactive(비활성화) 입니다.
- 따라서, 해당 과정에서는 NSG 정책으로 In/Out Bound 제어 합니다.
  - InBound 정책 추가 : Default Port 9090

Prometheus 정상 액세스 확인

1-5. Target VM < Node Exporter 설치

이제는 Prometheus Server에서 Pull 방식으로 Scraping 할 수집 대상(Target) VM에 Node Exporter 설치 과정을 진행하겠습니다!

Node Exporter을 통해서 각기 다른 Linux 계열 서버들을 대상으로 메트릭을 수집합니다.

이는 시스템 서비스로 실행되며, 구성을 위한 전체적인 단계는 동일합니다.

따라서, 이러한 공통 사항 반영하여 모든 VM에서 실행할 수 있도록 Shell Scripts 방식으로 배포하였습니다.

(일부 명령어 사용에 있어 Linux 계열에 따라 구성에 달라질 수 있습니다.)

1-5-1. (공통) Shell Scripts

vi node-exporter-install.sh

# System User생성
sudo useradd -rs /sbin/nologin node_exporter

# Node Exporter Binary Install
wget <https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz>
tar -xvf node_exporter-1.7.0.linux-amd64.tar.gz

sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/

# Systmed Service 생성
sudo tee </dev/null /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target
StartLimitIntervalSec=500
StartLimitBurst=5
[Service]
User=node_exporter
Group=node_exporter
Type=simple
Restart=on-failure
RestartSec=5s
ExecStart=/bin/sh -c '/usr/local/bin/node_exporter' \
    --collector.logind
[Install]
WantedBy=multi-user.target
EOF

# 디렉터리 권한 변경
chmod 775 /root/node-exporter-install.sh

# 스크립트 실행
/root/node-exporter-install.sh

*Rocky의 경우, 파일 다운로드를 위해 wget 설치 필요

(얘가 손이 많이 가서... ExecStart 값에서 다른 Linux는 실행 파일의 Path만 입력하면 됐는데.. 굳이 실행 명령어까지 필요한 너...)

sudo yum install wget

*RHEL경우, 7버전 이후부터는 firewalld 가 기본 방화벽 관리 도구로 사용되므로, Node Exporter의 Port(9100)를 추가

# 9100 리스닝 확인
netstat -nlp | greo 9100

# 방화벽 상태 확인
sudo firewall-cmd --state

# 방화벽 현재 구성 확인
sudo firewall-cmd --list-all

# 방화벽 정책 추가
sudo firewall-cmd --add-port=9100/tcp --permanent

firewall-cmd --reload

1-5-2. Systemd Serivce 확인

위 단계의 스크립트 실행 후, 진행

sudo systemctl daemon-reload

sudo systemctl enable node_exporter
sudo systemctl start node_exporter

# activce 상태 확인
sudo systemctl status node_exporter

아래와 같이 Active 상태인 것을 확인

프로세스(Daemon) 확인

1-6. Prometheus Server에서 Target 정보(Node Exporter) 추가

이번 단계에서는 위 Prometheus Server 설치 단계에서 확인한 Config 파일에 아래와 같이 해당 내용을 반영합니다.

Prometheus Config 파일 수정
- scrape_configs > job_name > static_configs > targets

sudo nano /etc/prometheus/prometheus.yml

서비스 재시작하여 변경값 적용

sudo systemctl restart prometheus

서비스 상태 확인

1-7. Prometheus Server Target 구성 확인

이제 마지막으로 Prometheus Server에 들어가서 지금까지의 구성이 정상적으로 적용되었는지를 확인해 보겠습니다.

Target 확인

쿼리(PromQL) 테스트

(예시) 운영체제 확인
```
node_os_info
```

(예시) CPU 확인

100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

이상으로 Prometheus(+ Node Exporter, AlertManager) + Grafana 구성하기 중 "1부 : 개념과 테스트 환경의 설명, Prometheus 및 Node Exporter 설치와 구성" 마치겠습니다.

조만간 "2부 : AlertManager 를 통한 알림 서비스 연동 그리고 Grafana 대시보드화 구성" 로 돌아오겠습니다.(!많관부!)

Jenkins, ArgoCD로 CI/CD Pipeline 구성하기 (3)

H-Y-E-N — Mon, 5 Feb 2024 13:43:19 +0900

안녕하세요. HYEN입니다.

지난 글에서는 Jenkins에서 Jenkinsfile을 사용하여 Job을 구성하는 과정에 대해 알아보았는데요.

지난 글 바로 가기 : https://with-cloud.tistory.com/20

Jenkins, ArgoCD로 CI/CD Pipeline 구성하기 (2)

안녕하세요. HYEN입니다. 지난 글에서는 CI/CD Pipeline에 대한 전체 Flow와 Pipeline을 구성하기 전에 필요한 설정들에 대해 다뤄보았습니다. 지난 글 바로 가기 : https://with-cloud.tistory.com/19. Jenkins, ArgoCD

with-cloud.tistory.com

이번 글에서는 CI/CD Pipeline 구성의 마지막 부분인 Github와 ArgoCD 간 연결, 그리고 전체 CI/CD Pipeline을 자동화 하는 부분에 대해 다뤄보겠습니다.

Contents

※ Jenkins와 ArgoCD 등 CI/CD Pipeline 구성에 필요한 모든 리소스는 사전에 배포해 두었습니다.※

6. GitHub와 ArgoCD 연결

두 번째 Job에 의해 Github Repository의 deploy.yaml이 업데이트 되면 해당 Repository를 주기적으로 체크하는 ArgoCD에 의해 해당 변경 사항이 감지되도록 GitHub와 ArgoCD를 연결해 보도록 하겠습니다.

6.1 ArgoCD에 GitHub Repository 등록

ArgoCD 로그인 > 좌측 상단의 [Settings] 탭 > [Repositories]

[+ Content Repo] 버튼을 클릭합니다.

Connection을 위한 세부 정보를 입력합니다.
- HTTPS를 사용하여 연결하기 위해 [VIA HTTPS] 옵션을 선택합니다.
- Repository URL을 입력합니다.
- Username에는 Github의 User 명을 입력하고 Password에는 발급해 놓은 PAT를 입력합니다.
- 상단의 [Connect] 버튼을 클릭하여 연결을 완료합니다.

연결 상태를 확인한 결과 Successful이 뜨는 것을 알 수 있습니다.

6.2 ArgoCD에서 Application 생성

6.1에서 연결한 Repository에 대한 정보를 확인할 수 있는 페이지에서 우측의 점 세 개를 클릭한 후, [Create application]을 선택하여 Application을 생성할 수 있습니다.

[General] 탭
- Sync Policy를 설정합니다. (현재는 테스트를 위해 Manual로 구성하였으나 뒤에서 Automatic으로 변경할 예정입니다.)

[Source] 탭
- GitHub Repository에 대해 설정합니다.
  - Repository URL을 입력합니다.
  - Path : 해당 Repository에서 manifest file이 위치하고 있는 경로를 입력합니다. (가장 상위일 경우 .를 입력합니다.)

[Destination] 탭
- Azure Kubernetes Service(AKS) 내 Application이 배포될 위치에 대해 설정합니다.
  - Namespace : Application이 배포될 namespace를 입력합니다.

상단의 [Create] 버튼을 클릭하여 Application 생성을 완료합니다.

7. ArgoCD와 Azure Kubernetes Service(AKS) Sync

ArgoCD는 연결된 AKS 내 Deployment의 현재 상태와 Github Repository의 deploy.yaml의 상태를 확인하고 Sync하는 작업을 수행합니다.

7.1 생성된 Application 확인

[Applications] 탭에서 생성된 Application을 확인할 수 있습니다.
Status 부분을 보면 해당 Application의 상태가 OutOfSync 임을 알 수 있습니다.

생성된 Application을 클릭한 후 Out of Sync가 떠 있는 Deployment를 클릭합니다.

세부 정보 창 하단의 [DIFF] 탭을 클릭하여 Out of Sync인 부분을 확인할 수 있습니다.
- 현재 AKS 상에 배포된 Deployment가 바라보는 Image의 tag와 Github 상에 업데이트된 deploy.yaml file에 정의된 Image의 tag가 일치하지 않기 때문임을 알 수 있음

현재 Web Page는 하기와 같습니다.

상단의 Sync 버튼을 클릭하여 Sync를 수행합니다.
- Out of Sync 상태인 모든 Object에 대해 Synchronize를 수행합니다.

Sync 수행 시 ArgoCD에서 GUI를 통해 Sync가 진행되는 과정을 확인할 수 있습니다.

kubectl get po 명령어를 사용하여 Sync가 진행되는 과정을 확인할 수 있습니다.

변경 사항이 적용된 Web Page는 하기와 같습니다.

8. 전체 CI/CD Pipeline 자동화

지금까지는 Jenkins에서의 Job들도, GitHub에 변경 사항이 생겼을 때 ArgoCD가 Sync를 하는 것도 모두 따로따로 진행되도록 구성을 하였습니다.

테스트를 할 때 불필요하게 모든 과정이 반복되는 것을 막기 위함이었는데요.

각각의 단계에 대해 테스트를 성공적으로 마무리 하였기 때문에 마지막으로 전체 CI/CD Pipeline을 자동화 해 보도록 하겠습니다.

그 전에 간단하게 전체 CI/CD Pipeline에 대해 Flow를 정리해 보도록 하겠습니다.

1️⃣ 첫 번째 GitHub Repository, 즉, Web Page를 위한 image에 대한 코드가 존재하는 Repository에 변경 사항이 발생할 경우 첫 번째 Jenkins Job에 의해 변경 사항이 반영된 새로운 이미지가 build되고 ACR로 push됩니다.

2️⃣ 첫 번째 Jenkins Job의 마지막 stage에서 두 번째 Jenkins Job을 트리거합니다.

3️⃣ 두 번째 Jenkins Job은 변경 사항이 적용된 이미지를 두 번째 GitHub Repository, 즉, manifest file이 업로드 되어 있는Repository에 대해 이미지 버전을 변경합니다. (deploy.yaml file의 이미지 버전을 변경)

4️⃣ 두 번째 GitHub Repository를 바라보고 있는 ArgoCD는 이러한 변경 사항을 감지한 후 자동으로 GitHub Repository에 정의된 deploy.yaml file과 실제로 AKS 내에 배포되어 있는 Deployment Object 간 Sync를 수행합니다.

여기서 두 번째 step과 네 번째 step에 대해 추가적인 구성이 필요해집니다.

구성은 어렵지 않습니다.

먼저 첫 번째 Job과 두 번째 Job을 연결해 보도록 하겠습니다.

8.1 첫 번째 Job 완료 후 두 번째 Job을 Trigger하도록 구성

첫 번째 Job의 Jenkinsfile에 Stage를 추가해야 합니다.

pipeline {
    agent any

    environment {
        BUILD_NUMBER = "v6"
        WEB_IMAGE_NAME = "${ACR_LOGINSERVER}/{respository 명}:${BUILD_NUMBER}"
    }

    stages {        
        stage('Login to ACR') {
            steps {
                script {
                    sh "az login -i"
                    echo "Login to Azure Success"
                    sh "az acr login --name ${ACR_LOGINSERVER}"
                    echo "Login to Azure Container Registry Success"
                }
            }
        }
        
        stage('Build Docker Image') {
            steps {
                script {
                    echo "Start to Build the Image"
                    sh "docker build -t ${ACR_LOGINSERVER}/sundls:${BUILD_NUMBER} ."
                    echo "Build Success"
                }
            }
        }

        stage('Push Image to ACR') {
            steps {
                script {
                    // Docker 이미지를 ACR에 푸시
                    echo "Push to ACR"
                    sh "docker push ${ACR_LOGINSERVER}/{respository 명}:${BUILD_NUMBER}"
                    echo "Push Success"
                }
            }
        }
	stage('Trigger 2nd Job') {
            steps {
                echo 'Trigger 2nd Job...'
                build job: 'pipeline-for-manifest', wait: true
            }
        }
    }
}

'Trigger 2nd Job' stage를 제외한 stage들과 environment block은 이전 글에서 설명하였으므로 추가적으로 설명하지는 않겠습니다.
'Tigger 2nd Job' stage
- 이 stage에서는 다음 Job을 명시해 주기만 하면 됩니다.
- build job: 이라는 항목에 대해 두 번째 Job의 project 이름만 기입해 주면 됩니다 .

위와 같이 기존 Jenkinsfile에 stage 하나만 더 추가하면 두 Job을 연결할 수가 있습니다.

단, Jenkinsfile을 업데이트 해도 GitHub Repository에서는 이를 Jenkins로 Trigger하기 때문에 이 점 참고하시어 CI를 수행하시길 바랍니다.

8.2 이미지 관련 코드 수정 후 Git push를 통해 첫 번째 Job Trigger

두 Job을 연결하였으니 이번에는 이미지 관련 코드를 수정할 때 자동으로 deply.yaml file까지 변경되는지 확인해 보겠습니다.

먼저 코드를 수정한 후 git push 명령어를 통해 GitHub Repository를 업데이트합니다.

GitHub Update가 완료되면 첫 번째 Job이 자동으로 trigger되고 첫 번째 Job의 마지막 stage에서 두 번째 Job이 자동으로 trigger 됩니다.

두 번째 Jenkins Project를 클릭하면 별도의 사용자 개입 없이 두 번째 Job이 자동으로 trigger 되는 것을 확인할 수 있습니다.

와! 성공적으로 연결된 것을 확인할 수가 있습니다.

다음은 ArgoCD로 가보겠습니다.

현재는 ArgoCD의 Sync Policy가 manual이기 때문에 자동으로 Kubernetes에 배포된 Deployment의 Image의 tag가 v6에서 v7로 변경되지 않습니다.

아직까지는 상단의 [Sync] 버튼을 클릭하여야 수정 사항이 반영됩니다.

기존 Web Page는 하기와 같습니다.

변경 사항이 적용된 Web Page는 하기와 같습니다.

8.3 ArgoCD의 Sync Policy 수정 (Manual → Auto)

ArgoCD 상단의 [Details] 버튼을 클릭한 후 하단의 [Sync Policy] 탭에서 [Enable Auto-Sync]를 클릭합니다.

Auto-Sync 세부 정보는 하기와 같습니다.

Prune Resources
- 이를 활성화 할 경우 연결된 Github Repository에서 manifest file이 삭제될 경우 Kubernetes Cluster에서도 해당 리소스가 삭제됩니다.
- Github Repository와 Kubernetes Cluster를 완전히 동기화 할 수 있어 둘 간의 상태 불일치를 방지할 수 있으나 예기치 않은 리소스가 삭제될 수 있음에 유의해야 합니다.
Self Heal
- Kubernetes Cluster의 상태를 지속적으로 Github Repository와 비교하고 둘 간에 Out of Sync가 발생할 경우 Cluster의 상태를 Github Repository의 상태로 자동으로 복구하는 기능입니다.

8.4 CI/CD Pipeline 전체 자동화 테스트

ArgoCD의 Sync Policy까지 Automatic으로 변경하였으니 정말 마지막으로 CI/CD Pipeline 전체를 자동화하는 테스트를 진행해 보도록 하겠습니다.

코드를 수정한 후 git push 명령어를 통해 GitHub Repository에 변경 사항을 적용합니다.

Github Update가 완료되면 첫 번째 Job이 자동으로 Trigger되고 첫 번째 Job의 마지막 Stage에서 두 번째 Job이 자동으로 Trigger 됩니다.

두 번째 Job이 자동으로 trigger 되는 것을 확인할 수 있습니다.

ArgoCD에서 자동으로 Sync가 이루어집니다. (deploy.yaml file의 image tag가 v7에서 v8로 변경됩니다.)

변경된 Web Page는 하기와 같습니다.

이렇게 긴 시간에 걸쳐 CI/CD Pipeline을 구성하는 과정에 대해 테스트하고 글로 기록해 보았습니다.

다음에는 또 다른 재밌고 유익한 글로 돌아오도록 하겠습니다 :)

Jenkins, ArgoCD로 CI/CD Pipeline 구성하기 (2)

H-Y-E-N — Thu, 1 Feb 2024 14:22:39 +0900

안녕하세요. HYEN입니다.

지난 글에서는 CI/CD Pipeline에 대한 전체 Flow와 Pipeline을 구성하기 전에 필요한 설정들에 대해 다뤄보았습니다.

지난 글 바로 가기 : https://with-cloud.tistory.com/19.

Jenkins, ArgoCD로 CI/CD Pipeline 구성하기 (1)

안녕하세요. HYEN입니다. 드디어 길고 길었던 CI/CD Pipeline 구성이 끝이 났습니다. 개인적으로, CI/CD Pipeline은 구성할 때마다 어렵다 이거 언제 다 연결하지? 라는 마음이 드는데요. 막상

with-cloud.tistory.com

이어서 이번 글에서는 본격적으로 Jenkinsfile을 사용하여 Jenkins 내에서 Job을 생성하고 테스트 하는 과정에 대해 적어보도록 하겠습니다.

Contents

※ Jenkins와 ArgoCD 등 CI/CD Pipeline 구성에 필요한 모든 리소스는 사전에 배포해 두었습니다.※

4. Jenkins에서 Job 생성 (1) Push the image to ACR

4.1 Project 생성

[+ New Item] > [Pipeline] 선택 > [Ok] 클릭

4.2 Project Configuration - General

Build Triggers 중 [GitHub hook trigger for GITScm polling] 옵션을 선택합니다.
- 이를 통해 GitHub Repository에 코드 변경 사항이 push될 때마다 Jenkins Job이 자동으로 트리거 됩니다.

4.3 Project Configuration - Pipeline

Jenkinsfile을 작성하기에 앞서 Jenkinsfile에 대해 간략하게 알아보겠습니다.

Jenkinsfile이란?

Jenkins Pipeline의 정의를 포함하는 텍스트파일로 Jenkinsfile을 사용하면 CI/CD Pipeline의 구성, 실행, 관리를 코드 형식으로 수행할 수 있습니다.
선언형 파이프라인과 스크립트형 파이프라인의 두 가지 방식으로 정의될 수 있습니다.
- 선언형 파이프라인 : 파이프라인 block으로 시작하여 stages, steps, environment 등의 지시어를 포함하는 방식으로 구조가 명확하고, 각 단계를 쉽게 이해할 수 있게 해줍니다. ← 이번 글에서 사용한 방식입니다.
- 스크립트형 파이프라인 : Groovy 기반의 구문을 사용하며, node block 내 로직을 작성하여 더 복잡한 파이프라인을 구현할 수 있습니다. 선언형 파이프라인보다 더 고급 기능과 더 많은 제어 구조를 제공하지만 작성하거나 이해하기가 보다 어려운 방식입니다.

앞서 말씀 드렸듯이, 이번 글에서는 선언형 파이프라인을 사용하여 Jenkinsfile을 작성하였습니다.

Jenkinsfile 작성 내용은 하기와 같습니다.

pipeline {
    agent any

    environment {
        BUILD_NUMBER = "v5"
        WEB_IMAGE_NAME = "${ACR_LOGINSERVER}/{respository 명}:${BUILD_NUMBER}"
    }

    stages {        
        stage('Login to ACR') {
            steps {
                script {
                    sh "az login -i"
                    echo "Login to Azure Success"
                    sh "az acr login --name ${ACR_LOGINSERVER}"
                    echo "Login to Azure Container Registry Success"
                }
            }
        }
        
        stage('Build Docker Image') {
            steps {
                script {
                    echo "Start to Build the Image"
                    sh "docker build -t ${ACR_LOGINSERVER}/{respository 명}:${BUILD_NUMBER} ."
                    echo "Build Success"
                }
            }
        }

        stage('Push Image to ACR') {
            steps {
                script {
                    // Docker 이미지를 ACR에 푸시
                    echo "Push to ACR"
                    sh "docker push ${ACR_LOGINSERVER}/{respository 명}:${BUILD_NUMBER}"
                    echo "Push Success"
                }
            }
        }
    }
}

environment block
- BUILD_NUMBER : Tag에 대한 변수로 GitHub에 변경 사항이 반영될 때마다 바꿔주어야 합니다.
- WEB_IMAGE_NAME : image를 build할 때 사용할 이름으로 이미지와 태그를 지정해 주는 변수입니다.
'Login to ACR' stage
- script block : Managed Identity를 사용하여 Azure에 로그인하고 ACR에 로그인 합니다.
'Build Docker Image' stage
- Github Repository에 있는 Dockerfile을 사용하여 변수로 지정한 이름:태그로 이미지를 build 합니다.
'Push Image to ACR' stage
- build가 완료된 후 docker push 명령어를 사용하여 이미지를 ACR로 push 합니다.

Jenkinsfile 어렵지 않으시죠?

다음은 Jenkins에서 Pipeline 정의하는 부분에 대해 알아보겠습니다.

Definition의 경우 [Pipeline script from SCM]을 선택합니다.
Repository URL에 GitHub Repository의 URL을 입력합니다.
Credentials
- GitHub Repository가 Private Repository일 경우 [+ Add] 버튼을 클릭하여 User name과 PAT(Personal Access Token)에 대한 값이 저장된 Credentials을 생성해야 합니다.

Script Path를 Jenkinsfile로 지정합니다. (default)
- GitHub Repository에서 Jenkinsfile이 있는 위치를 명시해 주어야 합니다.
- Repository 가장 상위에 존재할 경우 위와 같이 Jenkinsfile이라고 명시해 주면 되고 특정 directory 내 존재한다면 directory명/Jenkins로 명시해 주면 됩니다.

4.3 GitHub 코드 수정 후 Job이 자동으로 trigger 되는지 확인

Local에서 코드를 수정한 후 GitHub에 변경 사항을 push 해 보았습니다.

이후 Jenkins에서 Build가 자동으로 Trigger 되는 것을 확인할 수 있습니다. (하기 이미지 참조)

이렇게 첫 번째 job을 생성해 보았는데요.

첫 번째 job의 flow를 간단하게 정리하고 넘어가 보도록 하겠습니다.

➡️ 코드를 수정한 후 GitHub에 변경 사항을 push하면 Jenkins는 GitHub webhook에 의해 변경 사항이 발생했다는 것을 감지합니다. 그 후, Jenkins는 자동으로 job을 실행하여 ACR에 변경 사항이 적용된 이미지를 push합니다.

5. Jenkins에서 Job 생성 (2) Update the manifest file

5.1 Project 생성

[+ New Item] > [Pipeline] 선택 > [Ok] 클릭

5.2 Project Configuration - General

두 번째 job은 첫 번째 job이 성공적으로 완료된 이후 자동으로 trigger 되어야 합니다.

이 부분은 첫 번재 job에서 추후 구성할 예정이기 때문에 해당 job에서는 별도로 구성해 주어야 할 것이 없습니다.

5.3 Project Configuration - Pipeline

첫 번째 job과 마찬가지로 두 번째 job에서 사용될 Jenkinsfile도 선언형 파이프라인 방식을 사용하였습니다.

Jenkinsfile 작성 내용은 하기와 같습니다.

pipeline {
    agent any
    environment {
        IMAGE_TAG = 'initial'
    }
    stages {
        stage('Clone repository') {
            steps {
              checkout scm
            }
        }
        stage('Update deploy.yaml') {
            steps {
                script {
                    IMAGE_TAG=sh(script: "az acr repository show-tags --name {acr명} --repository {repository명} --orderby time_desc --top 1 --output tsv", returnStdout: true).trim()
                    echo "Image Tag: ${IMAGE_TAG}"
                    sh "sed -i 's|image: .*|image: {acr server 주소}/{respository}:${IMAGE_TAG}|' deploy.yaml"
                    }
            }
        }
        stage('Commit and Push') {
            steps {
                script {
                    withCredentials([string(credentialsId: 'sundls', variable: 'GIT_CREDENTIALS_ID')]){
                        sh 'git config user.email "user email 입력"'
                        sh 'git config user.name "user name 입력"'
                        sh 'git add .'
                        sh 'git commit -m "Update image tag in deploy.yaml"'
                        sh 'git push https://${GIT_CREDENTIALS_ID}@github.com/{user name 입력}/Manifest.git HEAD:main'
                    }
                }
            }
        }
    }
}

environment block
- IMAGE_TAG의 경우, 초기 값을 지정해 줍니다.
- 이후 하기 ‘Update deploy.yaml’ stage에서 변수 값을 update 하게 됩니다.
'Clone repository' stage
- Jenkins Project 내 Pipeline 정의 탭에서 설정할 SCM(이 경우 GitHub Repository)으로부터 소스 코드를 체크아웃하는 단계를 의미합니다.
- 해당 pipeline은 project 내 정의된 GitHub Repository를 바라보고 있습니다.
'Update deploy.yaml' stage
- IMAGE_TAG라는 변수에 ACR에 push된 image 중 가장 최신 버전인 값이 할당되도록 합니다.
  - orderby라는 매개변수의 값을 time_desc으로 하여 가장 최근에 push된 image의 값부터 출력되도록 정렬합니다.
  - top이라는 매개변수의 값을 1로 하여 정렬한 값들 중 가장 첫 번째 값만 출력되도록 합니다.
  - returnStdout는 Jenkins 파이프라인 스크립트에서 사용되는 특정 옵션입니다. 일반적으로 script block 내에서 쉘 명령어를 실행할 경우 명령어의 출력값은 문자열 형태로 터미널 또는 콘솔에 직접 출력됩니다. 하지만 returnStdout:true 옵션을 사용하면 Jenkins가 이 출력을 캡처하여 Jenkins script 내의 변수에 저장하게 됩니다.
  - trim() 함수를 통해 문자열의 앞뒤 공백을 제거합니다. (혹시 모를 오인식을 방지하기 위함입니다.)
'Commit and Push' stage
- withCredentials
  - Jenkins Credentials에 정의한 GitHub PAT와 관련된 값을 사용하기 위한 선언을 하는 field입니다.
  - credentialsId 값에 Credentials ID 값을 입력하고 variable 값에는 하기 명령어에서 사용할 변수 값을 입력합니다. ← Credentials 값이 variable에 선언한 값에 저장됩니다.
- git 명령어
  - git 명령어들을 통해 변경된 값을 GitHub repository에 push 합니다.

다음은 Jenkins에서 Pipeline 정의하는 부분에 대해 알아보겠습니다.

첫 번째 job과 동일한 방식으로 정의해 주시면 됩니다!

5.4 Job이 trigger 되었을 때 이미지 값이 자동으로 변경되는지 확인

현재 이미지 값을 확인합니다. (tag가 v5 임을 확인할 수 있습니다.)

Pipeline Project에서 [Build Now]를 클릭합니다.

Job이 정상적으로 종료된 것을 Jenkins에서 확인할 수 있습니다.

Github에서 버전 값이 변경되었는지 확인합니다. (tag 값이 v5에서 v6으로 변경된 것을 확인할 수 있습니다.)

이렇게 Jenkins에서 job을 2개 생성하고 각각의 job들이 목적에 맞게 잘 돌아가는지 확인해 보았습니다.

아직까지는 두 개의 job을 연결하는 부분을 추가해 주지 않았기 때문에 두 개의 job이 연결되어 돌아가지는 않는다는 점 다시 한번 말씀드리며, 이번 글을 마무리하도록 하겠습니다.

job들이 시나리오 대로 잘 돌아가는 것을 확인했으니

다음 글에서는 ① 두 번째 job에 의해 update 될 deploy.yaml file이 있는 GitHub Repository와 AKS 간 sync를 위해 ArgoCD에서 어떤 구성을 해 주어야 하는지 알아보고 ② CI/CD Pipeline 전 과정을 자동화 해 보도록 하겠습니다.

Jenkins, ArgoCD로 CI/CD Pipeline 구성하기 (1)

H-Y-E-N — Wed, 31 Jan 2024 14:46:37 +0900

안녕하세요. HYEN입니다.

드디어 길고 길었던 CI/CD Pipeline 구성이 끝이 났습니다.

개인적으로, CI/CD Pipeline은 구성할 때마다 어렵다 이거 언제 다 연결하지? 라는 마음이 드는데요.

막상 구성해 놓고 보면 자동으로 척척 빌드되고 배포되는 게 멋있고 뿌듯하더라구요.

하지만 할 때마다 어려워 할 수는 없으니! 이번 기회에 쭈욱 정리해 보고자 합니다.

Contents

※ Jenkins와 ArgoCD 등 CI/CD Pipeline 구성에 필요한 모든 리소스는 사전에 배포해 두었습니다.※

1. CI/CD Flow

개발자가 코드를 수정한 후 'Toy-Project-Web' Repository에 변경 사항을 push합니다.
(Toy-Project-Web이라는 GitHub Repository에는 Dockerfile과 웹 어플리케이션 소스 코드가 포함되어 있습니다.)
GitHub에 설정된 Webhook이 push 이벤트를 감지하고 Jenkins의 job을 트리거합니다.
Jenkins는 트리거를 받아 구성된 job을 실행하여 새로운 코드 변경 사항을 기반으로 이미지를 build하고 이를 Azure Container Registry에 push 합니다.
Jenkins의 첫 번째 job의 마지막 stage에서 두 번째 job을 트리거합니다.
Jenkins에서 두 번째 job이 실행되고, 이에 따라 'Manifest' Repository의 deploy.yaml file 내의 image version이 업데이트 됩니다.
ArgoCD는 주기적으로 'Manifest' Repository를 체크하다가 변경 사항을 감지하면 AKS의 현재 상태와 GitHub에 정의된 desired state 간 Sync를 진행합니다.
AKS 내 배포된 Deployment에 대한 새로운 변경 사항을 rollout합니다.

2. GitHub - Jenkins 연결

2.1 Personal Access Token 발급

✅ GitHub Private Repository와 Jenkins를 연결하기 위해 Personal Access Token를 발급해야 합니다.
✅ GitHub의 Personal Access Token(PAT)는 API를 통해 GitHub에 인증하여 접근할 수 있는 방법 중 하나입니다.

GitHub Log in > Profile 아이콘 클릭 > [Settings] > [Developer settings] > [Tokens (classic)] > [Generate new token]

token 이름과 권한 범위를 선택합니다.
- repo, admin:org, admin:repo_hook 권한을 부여합니다.

하단의 [Generate token] 버튼을 클릭하여 token을 생성합니다.
발급된 PAT를 복사한 후 보관합니다.
- 해당 키는 다시 볼 수 없기 때문에 메모장 등에 따로 보관해 두어야 합니다.

2.2 Jenkins에 GitHub의 Personal Access Token을 Credentials로 등록

✅ GitHub의 PAT를 Jenkins Server에 Credentials로 등록 합니다.

[Dashboard] > [Manage Jenkins] > [System] > [GitHub] > [Add GitHub Server]

Credentials 추가를 위해 [+ Add] > [Jenkins]로 이동합니다.
- Kind : Secret text 선택
- Secret : 복사해 둔 Personal Access Token 입력
- ID : 해당 credential 식별에 사용할 ID 입력

생성한 Credentials 선택한 후 [Test Connection] 버튼을 클릭하여 연결을 확인합니다.

하단의 [Save] 버튼을 클릭하여 변경 사항을 저장합니다.

2.3 GitHub Webhook 설정

✅ GitHub Repository에 변경 사항이 발생할 경우 GitHub는 Webhook을 통해 Jenkins에게 Event에 대한 트리거를 보냅니다.
❌ Jenkins Server가 Private IP 주소만 가지고 있을 경우 이 ip 주소를 Payload URL로 사용할 수 없습니다.
➡️ 이 경우, Azure Firewall로 트래픽을 라우팅 하여 Azure Firewall의 Public IP 주소로 Webhook의 Payload URL을 지정하도록 구성해야 합니다.

구성 방법은 그렇게 어렵지 않습니다! 아래를 봐주세요.

GitHub Webhook의 Payload URL을 Azure Firewall의 Public IP로 지정하기 위해서 Azure Firewall에 DNAT Rule을 추가합니다.
- 원본 : GitHub Webhook IP 주소 (참고 링크 : https://api.github.com/meta)
- 대상 포트 : 8080 # 원하는 port 지정
- 대상 : Azure Firewall의 Public IP 주소
- 변환된 주소 : Jenkins Server의 Private IP 주소
- 번역된 포트 : 8080 # Jenkins가 LISTEN하고 있는 port 입력 필요

이렇게만 해주면 됩니다!

규칙 추가가 끝났다면 본론으로 돌아와 다시 Webhook 설정을 진행해 보도록 하겠습니다.

Repository > [Settings] > [Webhooks] > [Add webhook]

Webhook 추가
- Payload URL : Azure Firewall의 Public IP 주소 뒤에 /github-webhook/를 추가해 줍니다.

[Add Webhook]을 클릭하여 Webhook을 생성합니다.

Webhook이 정상적으로 연결되면 하기와 같이 ✅ 마크가 Payload URL 앞에 표시됩니다.

3. Azure Container Registry - Jenkins 연결

code를 수정한 후 GitHub에 변경 사항을 push 할 때, 이러한 push event를 알려줄 GitHub Webhook에 대한 구성을 완료했습니다.

그럼 그 다음에 해야할 일은 무엇일까요? 바로, Jenkins에 첫 번째 job을 생성하는 것인데요.

하지만 ❗❗❗

job을 생성하기 전에 해야 할 일이 있습니다.

ACR과 Jenkins를 연결하기 위한 Environment Variables와 Managed Identity에 대한 Credentials을 먼저 생성해 주어야 하는 것이 선행되어야 합니다.

그럼 먼저 Azure Container Registry용 Environment Variables를 생성해 보겠습니다.

3.1 Azure Container Registry용 Environment Variables 생성

[Dashboard] > [Manage Jenkins] > [System] > [Global properties] > [Environment variables] > [Add]
- Name : 변수 명
- Value : Azure Container Registry 로그인 서버 이름 입력
- 하단의 [Save] 버튼을 클릭하여 저장

3.2 Managed Identity에 대한 Credentials 생성

✅ 먼저 Azure Credentials Plugins을 설치해 주어야 합니다.
✅ Managed Identity를 사용해서 Jenkins에서 ACR에 접근하기 위함입니다.

[Dashboard] > [Manage Jenkins] > [Plugins] > [Available plugins] > [Azure Credentials] 설치

Azure Credentials Plugin이 설치되었으니 Credentials을 등록해 보겠습니다.

[Dashboard] > [Manage Jenkins] > [Credentials] > [System] > [Global credentials (unrestricted)] > [+ Add Credentials]

Azure Container Registry에 기여자 역할이 할당된 Managed Identity에 대한 정보를 입력 합니다.
- Kind : Azure Managed Identity (Azure Credentials Plugins 사전 설치 필요)
- Subscription ID : Azure Container Registry가 있는 구독 ID 입력
- ID : 연결하고자 하는 Managed Identity의 이름 입력

하단의 [Create] 버튼을 클릭하여 Credentials을 생성합니다.

Credentials이 생성되었다면 다음엔

생성한 Credentials에 대한 Verification을 수행해야 합니다.

위에서 생성한 Credentials(mi-aks-boc)을 클릭합니다.

좌측의 [Update] 버튼을 클릭합니다.

우측 하단의 [Verify Configuration] 버튼을 클릭하여 유효성을 검사합니다.

만약, 하기와 같은 문구가 출력되었다면 유효성 검증은 정상적으로 진행된 것입니다.

그러나 에러가 발생하기도 하는데요, 특히 Managed Identity에 대한 내용은 구글링으로도 찾기가 어려워 저도 처음에는 많이 헤맸습니다.

3.3 Managed Identity에 대한 Credentials 생성 시 에러가 발생하는 경우

결과부터 적어보자면,

[Verify Configuration] 버튼을 클릭했을 때 하기와 같은 메시지가 출력될 경우에는 Managed Identity와 Virtual Machine을 연결해 주어야 합니다.

⚠️The provided credentials are not valid: managed identity authentication is not available.

제가 생각하기에는 Jenkins Server가 구동되는 Spoke VM에 Managed Identity에 대한 권한 또는 연결점이 없어서 이러한 에러가 발생하는 것 같습니다. (아니라면 알려주세요!)

그래서 가상 머신과 Managed Identity를 연결하는 과정을 추가적으로 진행해 주었습니다.

[가상 머신] > [설정] > [ID] > [사용자 할당 항목] > [+ 추가]

VM에서 Managed Identity를 사용하여 Azure Login을 진행합니다.

[Verify Configuration]을 다시 클릭하여 유효성 검사를 재수행합니다.

이렇게 하면 정상적으로 유효성 검사가 진행되는 것을 확인하실 수 있습니다.

이번 글에서는 본격적으로 Jenkins, ArgoCD를 통해 CI/CD Pipeline을 구성하기에 앞서 필요한 사전 준비에 대해 다뤄보았습니다.

다음 글부터는 실제 Jenkins에서 Job을 생성하는 과정에 대해 다뤄보겠습니다.

Kubernetes Network Policy 공부하기 (2)

H-Y-E-N — Fri, 12 Jan 2024 21:40:44 +0900

안녕하세요. HYEN입니다.

이전 글에서 Network Policy에 대해서 공부해 보았는데요.

이번에는 실제로 Network Policy에 대해 테스트한 내용에 대해 다뤄보도록 하겠습니다.

Network Policy에 대한 이론을 정리한 글은 아래 링크를 참고해 주세요!

https://with-cloud.tistory.com/17

Contents

1. Namespace 생성 및 Label 지정

테스트에 사용할 namespace를 생성합니다.
- kubectl create ns ns-01
- kubectl create ns ns-02

생성된 namespace 확인하기 위해 하기 명령어를 입력합니다.
- kubectl get ns | awk ‘NR==1 || /ns-/' ← 이 명령어는 첫 번째 행 또는 ns-라는 문자열이 포함된 행을 출력하라는 의미입니다.
  - kubectl 명령어 외 파이프라인 뒤 명령어의 경우 하기 내용을 확인해 주세요!
    - awk 명령어는 사용자로부터 직접 입력을 받거나, 파일을 지정하여 데이터를 가공하고 처리하는 명령어입니다.
    - NR은 현재 레코드의 번호를 의미합니다. 예를 들어, NR==1은 첫 번째 행을 의미하죠.
    - / /은 정규식 패턴을 의미합니다. 예를 들어, /ns-/는 ns-라는 문자열과 일치하는 것이 있는지 확인하기 위한 패턴입니다.

namespace에 label을 지정해 줍니다.
- kubectl label namespace ns-01 ns=ns-01

지정된 label을 확인하기 위해 하기와 같은 명령어를 입력합니다.
- kubectl get ns ns-01 --show-labels

2. Deployment 생성

ns-01 namespace에 Deployment를 생성합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: amsy810/echo-nginx:v2.0
        ports:
        - containerPort: 80

kubectl apply -f deploy.yaml

image는 “쿠버네티스 완벽 가이드” 책의 image를 참고하였습니다. (curl 등 network 통신 테스트가 목적이기 때문입니다.)

pod ip를 조회합니다. (AKS를 종료한 후 재시작 할 경우, pod의 ip는 변경된다는 점, 잊지 마세요!)
- kubectl get po -o wide

해당 ip 중 하나로 curl 명령어를 날립니다. (AKS에 접근할 수 있는 Spoke 대역의 VM에서 명령어를 입력해야 합니다.)

정상적으로 nginx의 default page가 보이는 것을 확인할 수 있습니다.

ns-02 namespace에 Deployment를 생성합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-test
  namespace: ns-02
  labels:
    app: test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: test
        image: amsy810/echo-nginx:v2.0
        ports:
        - containerPort: 80

kubectl apply -f deploy1.yaml

pod ip를 조회합니다.(AKS를 종료한 후 재시작 할 경우, pod의 ip는 변경된다는 점, 잊지 마세요!)
- kubectl get po -o wide -n ns-02

3. Network Policy 생성 1 - podSelector

3.1 Test Architecture

※ pod는 Deployment를 통해 배포되었지만, pod 간 트래픽 흐름을 나타내기 위해 Deployment 표기는 생략한 점 참고 부탁드립니다.

Public IP가 붙은 Hub 대역의 VM에서 Spoke 대역의 VM에 접근합니다. (Spoke 대역의 VM에는 Public IP를 붙이지 않았기 때문입니다.)
ns-01의 모든 pod들에 대해 ingress/egress 트래픽을 차단하는 Network Policy를 생성합니다.
테스트 시나리오는 다음과 같습니다.
- Kubernetes Cluster 외부
  - Spoke VM에서 ns-01의 pod로 curl 명령어를 날립니다.
- Kubernetes Cluster 내부
  - ns-01의 임의의 pod에서 ns-02의 임의의 pod로 curl 명령어 실행
  - ns-02의 임의의 pod에서 ns-01의 임의의 pod로 curl 명령어 실행

3.2 Test

ns-01 namespace 내 모든 pod들에 대해 ingress/egress 트래픽을 모두 차단하는 Network Policy를 생성합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-deny-all
  namespace: ns-01
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Network Policy를 생성하기 위해 하기와 같은 명령어를 입력합니다.
- kubectl apply -f np.yaml

Kubernetes Cluster 외부에서 들어오는 트래픽에 대한 테스트를 하기 위해 curl 명령어를 사용합니다.
- Network Policy를 적용한 후에는 aks와 같은 VNet 대역에 있는 VM에서 curl 명령어를 해당 pod의 ip로 날려도 통신이 되지 않는 것을 확인할 수 있습니다.

Kubernetes Cluster 내부에서의 pod 간 통신을 테스트하기 위해 pod 내 container에 접근하여 curl 명령어를 날립니다.
- Network Policy의 적용을 받은 pod 중 하나를 실행하여 namespace 2의 pod에게 curl 명령어를 날립니다.
  ➡️ egress가 차단 되어 curl: (28) Connection timed out after 5001 milliseconds라는 메시지가 출력되는 것을 확인할 수 있습니다.
  - kubectl exec -it nginx-deployment-799744886-4nvls -- curl --connect-timeout 5 10.10.144.28
- namespace 2에 pod를 하나 생성하여 Network Policy의 적용을 받은 pod 중 하나로 curl 명령어를 날립니다.
  ➡️ ingress가 차단되어 curl: (28) Connection timed out after 5001 milliseconds라는 메시지가 출력되는 것을 확인할 수 있습니다.
  - kubectl exec -it deployment-test-f8dbf68bd-9vr78 -- curl --connect-timeout 5 10.10.144.23

4. Network Policy 생성 2 - namespaceSelector

4.1 Test Architecture

※ pod는 Deployment를 통해 배포되었지만, pod 간 트래픽 흐름을 나타내기 위해 Deployment 표기는 생략한 점 참고 부탁드립니다.

Public IP가 붙은 Hub 대역의 VM에서 Spoke 대역의 VM에 접근합니다.
ns-01에 생성했던 network policy를 제거합니다.
ns-01 namespace에 ns: ns-01이라는 Label이 붙어 있는 것을 다시 확인합니다.
ns-02의 모든 pod들에 대해 ingress/egress 트래픽을 차단하는 Network Policy를 생성합니다.
ns-02의 배포된 pod들 중 app: test Label을 가지는 pod들에 대해 egress 트래픽을 허용하는 Network Policy를 생성합니다.
테스트 시나리오는 다음과 같습니다.
- Kubernetes Cluster 내부
  - ns-02에 배포된 pod들 중 app: test Label을 가지는 pod에서 ns-01의 임의의 pod로 curl 명령어 실행
  - ns-02에 배포된 pod들 중 app: hyein Label을 가지는 pod에서 ns-01의 임의의 pod로 curl 명령어 실행

4.2 Test

namespace 2의 모든 pod들에 대한 ingress/egress를 차단하기 위한 network policy를 생성합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-deny-all
  namespace: ns-02
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

namespace 2의 pod 중 app: test라는 Label을 가진 pod에 대해서만 namespace 1에 있는 모든 pod로 Egress 트래픽을 보내는 것을 허용하기 위해 namespaceSelector 옵션을 사용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-deny-egress-to-ns-01
  namespace: ns-02
spec:
  podSelector:
    matchLabels:
      app: test
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          ns: ns-01
    ports:
    - protocol: TCP
      port: 80

Network Policy를 생성하기 위해 하기와 같은 명령어를 실행합니다.
- kubectl apply -f np4.yaml
- kubectl apply -f np2.yaml

ns-02 namespace에 있는 Deployment 및 Label를 조회하기 위한 명령어는 하기와 같습니다.
- kubectl get deploy -n ns-02 --show-labels

➡️ deployment-test에서 ns-01 namespace로 보내는 egress 트래픽은 차단단되어야 하고
deployment-hyein에서 ns-01 namespace로 보내는 egress 트래픽은 허용되어야 합니다.

그렇다면 테스트 결과를 확인해 보겠습니다!
- deployment-test의 pod에서 ns-01에 있는 pod 중 임의의 pod로 curl 명령어 날립니다.
  - kubectl exec -it deployment-test-f8dbf68bd-9vr78 -- curl --connect-timeout 5 10.10.144.5
- deployment-hyein의 pod에서 ns-01에 있는 pod 중 임의의 pod로 curl 명령어를 날립니다.
  - kubectl exec -it deployment-hyein-87b66c554-2dsdb -- curl --connect-timeout 5 10.10.144.5

5. Network Policy 생성 3 - ipBlock

5.1 Test Architecture

※ pod는 Deployment를 통해 배포되었지만, pod 간 트래픽 흐름을 나타내기 위해 Deployment 표기는 생략한 점 참고 부탁드립니다.

※ ns-02의 Deployment 및 Network Policy는 5. Network Policy 생성 3 - ipBlock에서 사용하지 않아 표기를 생략한 점 참고 부탁드립니다.

Public IP가 붙은 Hub 대역의 VM에서 Spoke 대역의 VM에 접근합니다.
- 2개의 Spoke VM에 각각 접근합니다.
ns-01에 ingres/egress를 모두 차단하는 network policy를 생성합니다.
app: test Label을 가지는 pod들에 대해 특정 ip 대역에서 들어오는 ingress 트래픽을 허용하는 Network Policy를 생성합니다.
테스트 시나리오는 다음과 같습니다.
- Kubernetes Cluster 외부
  - 10.10.128.4의 ip 주소를 가지는 Spoke VM에서 curl 명령어 실행
  - 10.10.128.5의 ip 주소를 가지는 Spoke VM에서 curl 명령어 실행

5.2 Test - spoke-vm 대역에서 pod로 직접 통신

ns-01 namespace 내 app: nginx라는 Label Selector을 가지고 있는 pod들에 대해 snet-vm(10.10.128.0/27) 대역에서 들어오는 ingress 트래픽을 허용하되, except field를 사용하여 10.10.128.5 ip 주소를 가지는 source에서 들어오는 ingress 트래픽은 차단하는 Network Policy를 생성합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-with-ipblock
  namespace: ns-01
spec:
  podSelector:
    matchLabels:
      app: nginx
  policyTypes:
    - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.10.128.0/27
        except:
        - 10.10.128.5/32
    ports:
    - protocol: TCP
      port: 80

Network Policy를 생성하기 위해 하기 명령어를 실행합니다.
- kubectl apply -f np1.yaml

✅ 현재 ns-01 namespace에는 모든 ingress/egress 트래픽을 차단하는 np-deny-all이라는 network policy와 특정 subnet 대역에서 들어오는 트래픽만 허용하는 np-with-ipblock 이라는 network policy가 배포되어 있습니다.

✅ Network Policy는 합집합입니다.

➡️ 특정 subnet 대역에서 Service의 External IP로 접속을 시도해도 통신이 불가합니다.

snet-vm 대역에 생성한 2개의 VM에 접속하여 테스트를 진행합니다.
- vm-01 (10.10.128.4)
  - pod 중 하나로 curl 명령어를 실행하면 하기 빨간 박스와 같이 통신이 가능한 것을 확인할 수 있습니다.
- vm-02 (10.10.128.5)
  - pod 중 하나로 curl 명령어를 실행하면 하기 빨간 박스와 같이 통신이 불가한 것을 확인할 수 있습니다.

6. Network Policy 생성 4 - ipBlock

6.1 Test Architecture

※ pod는 Deployment를 통해 배포되었지만, pod 간 트래픽 흐름을 나타내기 위해 Deployment 표기는 생략한 점 참고 부탁드립니다.

※ ns-02의 Deployment 및 Network Policy는 6. Network Policy 생성 4 - ipBlock에서 사용하지 않아 표기를 생략한 점 참고 부탁드립니다.

Public IP가 붙은 Hub 대역의 VM에서 테스트 수행합니다.
ns-01에 ingres/egress를 모두 차단하는 network policy를 생성합니다.
Node ip 대역에서 들어오는 ingress 트래픽을 허용하는 network policy를 생성합니다.
테스트 시나리오는 다음과 같습니다.
- Kubernetes Cluster 외부
  - Hub 대역의 VM에서 Internal Load Balancer의 ip를 통해 Application에 접근할 수 있는지 확인합니다.

6.2 Test - Hub VM - Service - Deployment - Pod로의 Ingerss 통신 제어

ns-01 namespace 내 nginx-deployment 앞단에 LoadBalancer Type의 Service를 배포합니다.

apiVersion: v1
kind: Service
metadata:
  name: svc-deploy-nginx
  namespace: ns-01
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "snet-lb"
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

Service를 배포하기 위해 하기 명령어를 실행합니다.
- kubectl apply -f svc1.yaml

Service의 External IP를 확인하기 위해 하기 명령어를 실행합니다.
- kubectl get svc

Internal Load Balancer의 External IP를 통해 Appilcation에 접근해 봅니다.
- 접근이 불가한 것을 확인할 수 있습니다.

왜 접근이 불가능할까요❓

✅ 현재 ns-01 namespace에는 모든 ingress/egress 트래픽을 차단하는 np-deny-all이라는 network policy와 특정 subnet 대역에서 들어오는 트래픽만 허용하는 np-with-ipblock 이라는 network policy가 배포되어 있습니다.
✅ Network Policy는 합집합입니다.

➡️ Hub VM에서 Service의 External IP로 접속을 시도해도 통신이 불가합니다.

Load Balancer를 타고 들어온 트래픽이 Node를 거쳐 pod로 흐를 수 있도록 node들의 ip를 허용해 주는 network policy를 생성해야 합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-with-ipblock-for-node
  namespace: ns-01
spec:
  podSelector:
  policyTypes:
    - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.10.144.0/20
    ports:
    - protocol: TCP
      port: 80

AKS의 node들이 배포되어 있는 subnet 대역을 cidr로 지정해 줍니다.
Network Policy를 생성하기 위해 하기와 같은 명령어를 입력합니다.
- kubectl apply -f np5.yaml

ns-01에 배포된 Network Policy를 조회하기 위해 하기와 같은 명령어를 입력합니다.
- kubectl get netpol

Internal Load Balancer의 External IP를 통해 Appilcation에 다시 한번 접근해 봅니다.

와! 이번에는 접속이 가능하군요!

ClientIP에 10.10.144.11 (node ip 중 하나)가 찍힌 것을 통해 정상적으로 network policy가 적용된 것을 확인할 수 있습니다.

이상으로 Network Policy에 대한 테스트를 마치도록 하겠습니다.

감사합니다!

Kubernetes Network Policy 공부하기 (1)

H-Y-E-N — Wed, 10 Jan 2024 17:01:59 +0900

안녕하세요. HYEN입니다.

이번에는 Kubernetes Network Policy에 대해서 공부해 보았습니다.

먼저 이론적으로 Network Policy에 대해서 알아본 후 다음 글에서 실제 테스트한 내용을 다뤄보도록 하겠습니다.

Contents

1. Network Policy란?

Kubernetes Cluster 내부에서 pod 간 통신 시 트래픽 규칙을 규정하는 역할을 하는 object입니다.
기본적으로 Network Policy를 사용하지 않는 경우 Kubernetes Cluster 내부의 모든 pod는 서로 통신 가능하지만 Network Policy 사용 시 pod 간 통신을 제어할 수 있습니다.
Kubernetes Cluster가 Network Policy를 지원하는 네트워크 플러그인(CNI Plug-in)을 사용해야 Network Policy를 활성화할 수 있습니다.

✅ 물론, Kubernetes Cluster가 사용하는 CNI가 Network Policy를 지원하지 않더라도 Network Policy object 자체는 생성할 수 있습니다.
❌ 그러나 동작은 하지 않는 점! 주의하시길 바랍니다.

Network Policy는 Namespace Scoped 리소스로 Namespace 별로 생성해야 합니다.
Azure Kubernetes Service의 경우 Network Policy를 구현하는 두 가지 방법을 제공하고 있습니다.

Azure Network Policy Manager : Azure에서 자체적으로 구현한 정책
Calico Network Policy : Tigera에서 만든 오픈 소스 네트워크 및 네트워크 보안 솔루션

두 Policy 간 차이점은 하기 링크를 참고해 주세요 :)
https://learn.microsoft.com/ko-kr/azure/aks/use-network-policies#differences-between-azure-network-policy-manager-and-calico-network-policy-and-their-capabilities

네트워크 정책을 사용하여 Pod 트래픽 보안 - Azure Kubernetes Service

AKS(Azure Kubernetes Service)에서 Kubernetes 네트워크 정책을 사용하여 pod 안팎으로 흐르는 트래픽을 보호하는 방법 알아보기

learn.microsoft.com

[AKS] > [설정] > [네트워킹] 탭에서 [네트워크 정책]을 확인할 수 있습니다.

2. Network Policy를 통한 Kubernetes Cluster 내 pod 간 트래픽 제어 방식

✅ Ingress 트래픽 제어와 Egress 트래픽 제어는 독립적으로 선언됩니다.
Ingress 트래픽과 Egress 트래픽 둘 다를 제어하고자 한다면 각각 규칙을 선언해 줘야 합니다.

✅ Network Policy는 충돌 되지 않으며 합산 되어 적용됩니다.
특정 방향에 대해 여러 개의 Policy가 존재할 경우에는 해당 Policy 모두가 적용됩니다.

3. Network Policy 종류

✅ podSelector와 namespaceSelector는 Kubernetes Cluster 내부의 통신 제어 시 사용하는 것이 권장되고
ipBlock의 경우 Kubernetes Cluster 외부 네트워크 제어에 사용하는 것이 권장됩니다.
cf) pod ip는 임시적이고 예측할 수 없어 pod의 ip로 network를 통제하는 것이 비효율적이기 때문입니다.

✅ podSelector와 namespaceSelector는 ingress/egress rule에서 두 종류를 함께 지정하여 사용할 수 있습니다.

Network Policy의 종류에 대해 좀 더 알아보도록 하겠습니다.

3.1 podSelector

특정 pod에서 들어오는(Ingress), 특정 pod로 나가는(Egress) 통신을 제어하는 정책으로 Selector를 사용하여 Selector와 일치하는 pod에 대한 ingress/egress rule을 지정합니다.

3.2 namespaceSelector

특정 Namespace 상에 있는 pod에서 들어오는(Ingress), 특정 Namespace 상에 있는 pod로 나가는(Egress) 통신을 제어하는 정책으로 Selector를 사용하여 Selector와 일치하는 pod에 대한 ingress/egress rule을 지정합니다.

3.3 ipBlock

특정 IP Block(CIDR 범위)에서 들어오는(Ingress), 특정 IP Block(CIDR 범위)로 나가는(Egress) 통신을 제어하는 정책입니다.

4. Network Policy 예제

4.1 Kubernetes 공식 문서 예제

(출처 : https://kubernetes.io/docs/concepts/services-networking/network-policies/)

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector: # Network Policy를 적용할 pod 명시 
    matchLabels:
      role: db # Label Selector를 사용하기 때문에 여러 pod를 대상으로 할 수 있음 
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              project: myproject # Namespace에 Label 먼저 지정해 줘야 함 
        - podSelector: 
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/24
      ports:
        - protocol: TCP
          port: 5978
          endPort: 6000

spec section 하위 ingress / egress는 규칙들의 집합입니다.
- ingress의 경우 from field를 사용하고 egress의 경우 to field를 사용합니다.

policyTypes
- 선택한 pod에 대한 Policy를 적용할 것인지 그 여부를 나타내는 field입니다.
- policyTypes가 명시되지 않은 경우 기본적으로 Ingress와 관련된 정책으로 인식하게 되며, Egress는 명시해 주어야 합니다.
- cf) ingress와 egress를 모두 차단하고자 할 경우 policyTypes에 ingress와 egress를 모두 명시해 주어야 합니다.
endPort field를 사용하여 단일 포트 대신 포트 범위를 대상으로 지정할 수 있습니다.
- 이 field를 지원하는 CNI Plug-in에서만 사용할 수 있으며, 만약 endPort field를 지원하지 않는 Plug-in인 경우 endPort field를 사용하여도 port field만 적용됩니다.

4.2 Ingress나 Egress를 모두 허용하고자 할 경우

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-allow-all
  namespace: default
spec:
  podSelector: {}
  egress:
  - {}
  ingress:
  - {}
  policyTypes:
  - Ingress
  - Egress

{}는 모두 포함한다는 의미입니다. (빈칸으로 놔두는 셈이죠.)
지정한 Namespace에 배포된 모든 pod에 대해 egress/ingress를 허용하겠다라는 의미입니다.

4.3 Ingress나 Egress를 모두 차단하고자 할 경우

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: np-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

spec section 하위에 ingress/egress 규칙을 지정한 field 없이 policyTypes를 Ingress/Egress로 지정할 경우 허용되는 규칙이 없기 때문에 모든 트래픽이 차단되게 됩니다.

이렇게 Network Policy의 이론적인 내용에 대해 다뤄 보았는데요.

다음에는 실제로 Azure Kubernetes Service 내에서 Network Policy를 통해서 pod 간의 트래픽을 제어하는 방식에 대해 테스트한 내용으로 돌아 오겠습니다.

Application Gateway에 SSL 인증서를 적용하여 HTTPS로 Application 접근하기

H-Y-E-N — Sun, 7 Jan 2024 22:12:40 +0900

안녕하세요. HYEN입니다.

이번에는 Application Gateway에 SSL 인증서를 적용하여 백 엔드 Application에 HTTPS로 접근하도록 테스트해 보았습니다.

SSL/TLS 관련 정리는 아래 링크를 참조해 주세요!

https://with-cloud.tistory.com/15

SSL/TLS 알아 보기

안녕하세요. HYEN입니다. 이번에는 Application Gateway SSL 인증서를 적용하여 저와 동기가 만든 Web Server를 https를 이용해서 접근해 보려고 하던 도중, 대체 SSL이 무엇인가! 하는 궁금증이 생겨 공부해

with-cloud.tistory.com

Contents

1. Application Gateway의 암호화

먼저 Application Gateway의 암호화에 대해 정리해 보았습니다.

Application Gateway Flow (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)

Application Gateway는 전송 중 데이터 암호화를 위해 인증 기관에서 인증서를 구매하여 서버로 들어오고 나가는 메시지를 암호화할 수 있습니다. 이러한 암호화를 통해 전송 중인 메시지를 권한 없는 사용자가 가로채서 그 안에 있는 정보를 볼 수 없게 됩니다.
Application Gateway는 HTTP 트래픽 로드 밸런싱, WAF 방화벽 및 데이터의 SSL 암호화 지원과 같은 기능을 제공합니다. 또한 사용자와 Application Gateway 간의 트래픽, Application Server와 Application Gateway 간의 트래픽 암호화를 지원합니다.
- 기본적으로 SSL Termination 수행 시 사용자와 Application Gateway 간의 트래픽은 HTTPS로 암호화되고 Application Gateway와 Backend Server 간의 트래픽은 HTTP로 통신이 이루어집니다.
- 만일, Application Gateway에서 Backend Server로 가는 트래픽 역시 HTTPS로 암호화하여 구성하고 싶을 경우 Application Gateway에서 지원하는 End-to-End TLS 암호화를 구성하면 됩니다.
  End-to-End TLS Encryption 설명 (https://learn.microsoft.com/en-us/azure/application-gateway/ssl-overview#end-to-end-tls-encryption)
Application Gateway에서 SSL Termination을 수행할 경우 서버에 인증서를 설치하고 SSL을 구성할 필요가 없어집니다.

2. Application Gateway를 통한 트래픽 암호화 로직

Application Gateway를 통한 트래픽이 암호화 되는 방식에 대해 좀 더 알아보겠습니다.

Application Gateway 구성 요소 (https://learn.microsoft.com/ko-kr/training/modules/end-to-end-encryption-with-app-gateway/2-application-gateway-and-encryption)

트래픽은 Frontend의 포트를 통해 들어오고 수신기를 거쳐 규칙에 맞게 수신 요청을 Backend Pool에 전달합니다.
수신기 (Listener)
- 특정 호스트, 특정 IP 주소의 특정 포트를 수신 대기하도록 설정된 리소스로 SSL 인증서를 사용하여 Application Gateway로 들어오는 트래픽을 암호 해독 할 수 있습니다.
- 수신기가 지원하는 포트 (여러 포트 open 가능)는 다음과 같습니다.

SKU	Supported Port Range	Exceptions
V2	1 ~ 64999	22
V1	1 ~ 65502	3389

3. Application Gateway의 TLS Termination

그렇다면 TLS Termination 구성의 장점은 무엇일까요?

(https://learn.microsoft.com/ko-kr/azure/application-gateway/ssl-overview#tls-termination에 대해서 읽어보시는 것을 권장 드립니다.)

TLS 암호 해독 시 성능에 가장 부하를 주는 것은 초기 Handshake이기 때문에 Application Gateway에서 TLS Termination을 수행할 경우, Client의 모든 요청에 대해 캐시된 값을 사용할 수 있습니다.
cf) Backend Server에서 TLS Termination 수행할 경우, Client의 요청이 다른 Server로 갈 때마다 Client가 다시 인증을 해야 하는 번거로움이 발생합니다.
SSL/TLS 통신 시 CPU 사용률이 높으며 SSL/TLS 통신 시 사용하는 키의 크기가 커짐에 따라 이 사용률은 더 증가하고 있습니다. 그렇기 때문에 Backend Server에서 이 작업을 하지 않을 경우 Server는 데이터를 가장 효율적으로 전달할 수 있는 방식에 대해서만 집중할 수 있게 됩니다.
Application Gateway가 트래픽의 암호를 해독할 때 헤더, URI 등에 액세스 할 수 있기 때문에 이를 활용하여 요청을 지능적으로 라우팅할 수 있습니다.
Application Gateway에만 Certificate를 설치하면 되기 때문에 시간과 비용을 절약할 수 있습니다.

✅ TLS Termination을 구성하기 위해서는 TLS/SSL Certificate가 반드시 수신기에 구성되어 있어야 합니다.
✅ Application Gateway에 제공된 인증서는 개인키와 공개키를 모두 포함하는 PFX(개인 정보 교환) 형식이어야 합니다.
❌ Application Gateway는 새 인증서를 만들거나 인증 기관에 인증서 요청을 보내는 기능을 제공하지 않습니다.

이를 통해 Application Gateway는 들어오는 트래픽을 해독하고 Client에 대한 response 트래픽을 암호화할 수 있습니다.

3.1 Backend Server TLS 암호화

※ 이번 포스팅에서는 이 부분에 대한 테스트를 다루고 있지는 않습니다.

Backend Server로 전달되는 트래픽을 암호화하여 보내고자 할 경우 Application Gateway의 End-to-End TLS 암호화 기능을 사용하면 됩니다.
End-to-End TLS는 백 엔드 설정에서 백 엔드 프로토콜을 HTTPS로 변경하여 사용 가능합니다.

4. Application Gateway의 TLS Termination 구성

4.1 SSL Certificate 만들기

4.1.1 회원 가입

SSL Certificate를 무료로 발급할 수 있는 사이트(ex. https://www.sslforfree.com/) 접속한 후 회원 가입을 진행합니다.

Certificate 관련 메일이 수신되기 때문에 사용하는 메일을 이용해야 합니다.

4.1.2 Certificate 생성

[New Certificate] 클릭
Certificate를 발급 받고자 하는 도메인을 입력합니다.
[90-Day Certificate]를 선택합니다.

4.1.3 도메인 인증

실제로 도메인을 소유하고 있는지 여부를 확인하기 위한 단계로 제공하는 3가지 방법 (Email Verification, DNS(CNAME), HTTP File Upload) 중 가능한 방법으로 인증하면 됩니다.

※ 본 테스트에서는 DNS(CNAME)을 사용하였습니다.

Name, Point To, TTL을 각각 복사하여 DNS Provider에 CNAME Record를 추가합니다.

가비아에서 구매한 도메인에 대해 Azure DNS의 Name Server를 사용하도록 설정해 두었기 때문에 Azure Portal에 접속하여 해당 DNS Zone에 Record를 등록해야 합니다.

4.1.4 Certificate Download

[Download Certificate (.zip)] 버튼을 클릭합니다.
zip 파일을 압축 해제 합니다.

4.1.5 SSL Certificate 포맷 변환 (.crt → .pfx)

Win64 OpenSSL Command Prompt 실행한 후 다운로드 받은 폴더로 Directory를 변경합니다.
pfx 파일로 변환하기 위해 하기와 같은 명령어를 입력합니다.
- pkcs12 -export -out hyein-certificate.pfx -inkey private.key -in certificate.crt -certfile ca_bundle.crt
- 상기 명령어 실행 시 “Enter Export Password” 문구가 출력되면 Certificate의 암호로 사용할 password를 입력합니다.
변환된 Certificate를 확인합니다.

4.2 Application Gateway에 Certificate 업로드

4.2.1 수신기 생성 및 Certificate 업로드

프로토콜 : HTTPS

포트 : 443 # 기존에 수신기가 이미 존재할 경우, 그 수신기와 겹치지 않는 포트 기입 필요

PFX 인증서 파일 : # pfx 파일로 변환한 Certificate 업로드

암호 : # pfx 형식의 Certificate 생성 시 입력한 암호 입력

4.2.2 규칙 생성

[수신기] 선택
[백 엔드 대상] 선택

4.3 HTTPS를 사용하여 Application 접근

https://hyein.<domain name>을 입력하면 아래와 같이 정상적으로 Application에 접근이 가능한 것을 확인할 수 있습니다.

하기와 같이 주소창 옆 [사이트 정보 보기] 버튼을 클릭한 후 "이 연결은 안전합니다."라는 항목을 클릭할 시, 아래와 같이 인증서와 관련된 정보를 확인할 수 있습니다.
\

이상으로, Application Gateway에 SSL Certificate를 업로드하여 Application에 HTTPS로 접근하는 방법에 대해 알아보았습니다.

SSL/TLS 알아 보기

H-Y-E-N — Fri, 5 Jan 2024 13:44:42 +0900

안녕하세요. HYEN입니다.

이번에는 Application Gateway SSL 인증서를 적용하여 저와 동기가 만든 Web Server를 https를 이용해서 접근해 보려고 하던 도중, 대체 SSL이 무엇인가! 하는 궁금증이 생겨 공부해 보았습니다.

Contents

1. SSL와 TLS란?

SSL(Secure Socket Layer; 보안 전송 계층)
- 암호화 기반 인터넷 보안 프로토콜로 웹사이트와 브라우저 사이 또는 두 서버 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술입니다.
- OSI 계층 모델 중 응용 계층과 전송 계층 사이에서 동작하여 애플리케이션 데이터를 보호하고 이를 전송 계층으로 보내는 역할을 합니다.

TLS(Transport Layer Security; 전송 계층 보안)
- SSL의 업데이트 버전 (cf. TLS 1.0은 SSL 3.0을 계승함)

➡️ 따라서 SSL과 TLS는 같은 역할을 하는 프로토콜이라고 볼 수 있습니다.

TLS 및 SSL 프로토콜을 사용할 경우 클라이언트 및 서버 애플리케이션에서는 메시지 변조, 메시지 가로채기, 메시지 위조 등의 보안 위험을 감지할 수 있습니다.

그렇다면, 대체 SSL/TLS 프로토콜은 이러한 보안 위험을 어떻게 감지하는 걸까요?

바로 SSL/TLS 프로토콜은 암호화, 해시화, 디지털 인증서라는 3가지 기술을 조합하여 사용하여 보안 위험을 감지하는데요. 여기서 해시화에 대해 잠깐 알아보고 가도록 하겠습니다.

해시화란?
- 애플리케이션 데이터를 고정된 크기의 고유한 값으로 변환하는 기술로 데이터에 작은 변경이 발생해도 결과 해시 값이 크게 변하도록 설계되어 있어 제 3자가 데이터를 바꾸어 쓰는 변조를 감지할 수 있습니다.
- 해시값은 데이터를 요약한 것이기 때문에 해시값이 유출 되더라도 보안 상 문제는 없습니다.

이와 같은 기술들을 통해 SSL/TLS 프로토콜이 제공하는 보안 요소는 다음과 같습니다.

Confidentiality (기밀성)
- 인가된 사람들에게만 데이터를 공개하는 것
- Client와 Server가 서로 주고 받는 데이터는 오직 Client와 Server만 볼 수 있어야 한다는 것을 의미합니다.
Integrity (무결성)
- 네트워크 상 송, 수신되는 데이터가 임의로 수정되거나 위, 변조되지 않아야 하는 것을 의미합니다.
- 정보는 변경이 허락된 주체에 의해 인가된 방법을 통해서만 변경되어야 하기 때문이죠.
Authentication (인증)
- 주체의 자격이나 내용을 검증하는 것으로 데이터에 접근할 수 있는 객체인지, 정당한 객체인지 확인되어야 합니다.

2. TLS 및 SSL Protocol Stack

TLS 및 SSL 프로토콜은 두 가지 계층으로 나뉘어 집니다.

https://commons.wikimedia.org/wiki/File:TLS_protocol_stack.svg

2.1 상위 계층

2.1.1 Handshake Protocol

Client와 Server가 서로 암호화 통신을 시작할 수 있도록 서로 확인하고 필요한 정보를 서로 주고 받는 과정을 의미합니다.
어떤 TLS 버전을 사용할 것인지, 어떤 암호화 알고리즘을 사용할 것인지 협상하고, Server와 Client의 인증서를 통해 인증하고, 공개키를 공유 (보통 RSA 암호화 알고리즘 사용)합니다.

지금부터는 Handshake 프로토콜의 Flow를 좀 더 자세하게 알아보겠습니다. (RSA 암호화 알고리즘을 기준으로 작성하였습니다.)

Security Deployment in TR-069 CPE WAN Management Protocol - Scientific Figure on ResearchGate

Client Hello
- Client는 Server에 접속하여 자신이 사용할 SSL/TLS 버전, Cipher Suite List(Client가 지원하는 암호화 방식), 세션 ID, 초기 랜덤 넘버(추후 대칭키 생성에 사용됨)를 포함한 Client Hello라는 패킷을 Server에게 보냅니다.
Server Hello
- Server에서 사용하는 SSL/TLS 버전, Client가 보낸 암호화 방식 중 Server가 사용할 수 있는 암호화 방식을 선택(Selected Suite)하여 보냅니다. → 협상
- Server에서 생성한 랜덤 넘버 (추후 대칭키 생성에 사용됨) 및 세션 ID도 함께 보냅니다.
- Client Hello와 거의 동일함
Server Certificate
- Server의 Certificate을 Client에게 보냅니다.
  - 인증서 내부에는 Server가 발행한 공개키가 들어 있습니다.
  - Client는 Server가 보낸, CA(Certificate Authority)의 개인 키로 암호화된 Certificate을, CA의 공개키를 사용하여 복호화 합니다. → 복호화 여부를 통해 Certificate 진위 여부를 검증할 수 있습니다.
- Client는 Server의 Certificate에 대한 무결성을 검증한 후 검증이 되었다면 데이터 암호화에 사용할 대칭키를 생성하게 됩니다.
Server Key Exchange
- Server의 공개키가 Certificate 내부에 없는 경우, Server가 직접 공개키를 전달하게 됩니다.
- 만약 공개키가 Certificate 내부에 있을 경우 이 과정은 생략된다고 보시면 됩니다.
  - Certificate 내부에 공개키가 있다면 3번의 CA의 공개키를 사용하여 Certificate를 복호화 하는 과정에서 이미 Server의 공개키를 확보하였을 것이기 때문이죠.
Server Hello Done
- Server의 Hello 절차가 완료되었음을 Client에게 전송하기 위한 메시지입니다.
Client Certificate (optional)
- Client의 인증서를 Server에 전송하는 과정입니다.
Client Key Exchange
- Client는 3번 과정에서 생성한 대칭키를 Server가 보낸 Certificate 내부에 들어 있던 공개키로 암호화 하여 Server에게 전송합니다.
- 대칭키는 데이터를 실제로 암호화하는 키를 의미합니다.
  - 이 키를 통해 Client와 Server는 교환하고자 하는 데이터를 암호화 할 수 있습니다.
Change Cipher Spec
- 이 이후로 전송되는 모든 메시지에 대해서 정해진 암호화 알고리즘과 키를 사용하여 암호화 하겠다고 알리는 패킷입니다.
- Client와 Server가 서로에게 날리는 패킷으로 교환할 정보를 모두 교환한 후 통신 준비 완료를 알리는 역할을 하죠.
Finished
- SSL/TLS Handshake가 성공적으로 끝나서 이를 종료한다는 의미를 담은 패킷입니다.

2.1.2 Change Cipher Spec Protocol

Handshake 과정 중 Client와 Server 간의 통신에서 암호화된 부분을 나타내는 신호 역할을 합니다.
Handshake 프로토콜의 일부로 간주되며 이 메시지 이후 Client와 Server 간의 통신은 새로운 암호화 및 보안 매개변수를 사용하게 됩니다.

2.1.3 Alert Protocol

SSL/TLS 통신 과정에서 발생하는 오류 및 경고 상황을 알리고 대응하기 위한 프로토콜로, Client와 Server 간 오류 및 경고 메시지를 교환하는데 사용됩니다.
Alert Level에는 Fatal(치명적)과 Warning(경고) 총 두 가지 Level이 존재 합니다.
- Fatal
  - 이 경우 connection이 즉시 끊어집니다.
  - ex. 인증에 실패했을 때, 프로토콜 버전이 호환되지 않을 때 등
- Warning
  - 일반적인 경고 메시지입니다.
  - ex. 암호화 키의 유효 기간이 다가왔을 때, 암호화 알고리즘의 안전하지 않은 사용 등

2.2 하위 계층

2.2.1 Record Protocol

데이터의 기밀성, 무결성 및 인증을 위한 프로토콜로, SSL/TLS 세션에서 데이터의 보호를 담당하며 Handshake 프로토콜에서 협상된 보안 매개변수에 따라 데이터의 암복호화, 인증 및 압축을 수행합니다.
- 암호화 : Handshake 과정에서 협상된 대칭키를 사용하여 데이터를 암호화합니다.
- 무결성 : MAC(Message Authentication Code)을 사용하여 데이터의 무결성을 보장합니다.
- 압축 : 선택적으로 데이터를 압축하여 전송할 수 있습니다.
이 프로토콜에 의해 암호화 및 인증 처리된 데이터는 TCP와 같은 전송 계층(L4) 프로토콜에 의해 전송됩니다.

여기서 MAC은 또 뭘 의미하는 걸까요? 빠르게 알아보도록 하겠습니다.

MAC(Message Authentication Code)
- 해시 함수와 유사하나 더 많은 보안 기능을 제공하는, 메시지의 무결성과 인증을 확인하기 위한 코드입니다.
- 주로 대칭키 암호화에서 사용되며, 특히 데이터 전송 중 메시지 변조를 탐지하는 데 활용됩니다.

주로 HMAC(Hash-based Message Authentication Code)가 흔히 사용되는데요. HMAC의 특징은 다음과 같습니다.

해시 함수를 기반으로 하면서 키를 사용하여 보안 수준을 높임
대칭키 암호화 방식 사용
메시지에 대한 내부 해시를 계산하고, 외부에서 추가된 키를 사용하여 한 번 더 해시를 수행함

3. SSL Temination이란?

https://commons.wikimedia.org/wiki/File:SSL_termination_proxy.svg#/media/File:SSL_termination_proxy.svg

부하 분산 장치의 옵션 기능의 하나로 Server에서 수행하던 SSL 처리를 부하 분산 장치에서 수행하는 기능을 의미하며, 암호화, 복호화에 필요한 작업을 부하 분산 장치에 위임하는 것으로 SSL Offloading이라고도 합니다.
Client가 HTTPS로 request하면 그 request를 받은 부하 분산 장치에서 SSL 처리를 하고 부하 분산 대상 Server에는 HTTP로 전달하게 됩니다.
- 부하 분산 장치는 Client로부터 받은 암호화된 트래픽을 해독하고, clear text 데이터로 변환합니다.
- 부하 분산 장치는 해독된 clear text를 Server로 전송합니다. (이 구간의 통신은 암호화 X)
부하 분산 장치에서 SSL Offloading이 이루어지므로 부하 분산 장치가 SSL/TLS 암호화 및 복호화를 처리할 수 있는 기능을 가지고 있어야 합니다.
Server가 SSL 처리를 하지 않아도 되기 때문에 처리 부하가 감소한다는 장점이 있습니다.

이상으로, 간단하게 SSL/TLS에 대해 알아보았습니다.

다음에는 실제로 Azure Application Gateway에 SSL 인증서를 적용하는 과정에 대해 알아보도록 하겠습니다.

Kubernetes Namespace 간 Ingress 트래픽 라우팅 하기

H-Y-E-N — Wed, 3 Jan 2024 21:49:10 +0900

안녕하세요. HYEN입니다.

이번에는 Kubernetes Namespace 간 Ingress 트래픽을 라우팅하는 방법에 대해 알아보도록 하겠습니다.

Contents

1. 궁금증의 시작

저는 최근 Terraform으로 Azure Infra를 구성하는 테스트를 진행하고 있습니다.
모듈화는 처음이라 굉장히 고난을 겪었지만 멋진 동기 덕분에 무사히 테스트를 완료하였습니다.

그 다음 목표는 배포된 Azure Kubernetes Service 내부에 세부 구성을 진행하는 것이었는데요.
도커 이미지를 Build해서 Azure Container Registry로 Push하고 Azure Kubernetes Service에서 그 이미지를 가지고 Web용 Deployment를 배포하기로 했습니다.

동기가 만든 Deployment와 제가 만든 Deployment를 경로에 따라 분기하기 위해서 Nginx Ingress를 생성하는 작업을 진행하던 도중 궁금증이 생겼습니다.

Deployment가 서로 다른 namespace에 있을 때,
어떤 namespace에 Ingress 리소스를 지정해 줘야 하는 걸까?

이 궁금증을 해결하기에 앞서, 먼저 Ingress 리소스에 대해 알아보도록 하겠습니다.

2. Ingress란?

L7 로드 밸런싱을 제공하는 리소스로 Service들을 묶는 Service의 상위 Object입니다.
- TLS/SSL 인증서 처리, 도메인 기반 가상 호스팅 제공, 특정 HTTP 경로의 라우팅 등의 규칙을 정의합니다.
- 외부에서 Kubernetes 내부로 들어오는 네트워크 요청을 어떻게 처리할 지 결정하는 역할을 합니다.

Ingress는 namespace scope의 object입니다. → 사실상 이것이 문제!
- 따라서 백엔드로 연결할 Service는 Ingress Object와 동일한 namespace에 있어야 Ingress가 해당 백엔드를 찾아갈 수 있습니다.
  (공식 문서 : https://kubernetes.io/docs/concepts/services-networking/ingress/#resource-backend)

추가적으로, Ingress Controller는 Ingress가 어떻게 동작하는 지를 결정하는 Controller이며 이번 테스트에서는 Nginx Ingress Controller를 사용하였습니다.
그러나 Azure의 Application Gateway의 AGIC 기능을 활성화 하여 Ingress Controller로 사용할 수 있습니다.

정리해 보면,

Ingress Object와 같은 Namespace에 있는 Service의 경우 Ingress가 해당 Service를 잘 찾아갈 수 있지만
Ingress Object와 다른 Namespace에 있는 Service는 Ingress가 인지할 수 없다는 것을 알 수 있습니다.

이때 사용할 수 있는 방법은 바로 ExternalName Type의 Service를 추가로 배포하는 것입니다.

그렇다면 ExternalName Type의 Service는 뭘까요?

3. ExternalName

ExternalName type의 Service는 Selector를 기반으로 하는 것이 아니라 DNS 이름으로 매핑하여 외부의 특정 FQDN에 대한 CNAME 매핑을 제공합니다.

즉, Cluster IP 주소와 같은 ip 주소를 기반으로 액세스하는 것이 아니라 Service를 생성할 때 manifest file의 externalName field에 정의된 값을 포함하는 CNAME 레코드를 반환하게 됩니다.

4. 아키텍처

최종 테스트 아키텍처는 다음과 같습니다.

Ingress를 namespace-1에 배포하고 namespace-1에 있는 Service를 백엔드로 지정
namespace-1에 ExternalName type의 Service 배포 - namespace-2에 있는 Service를 찾아가기 위한 bridge 역할
해당 Service에 externalName: service-2. namespace-2(Service Name.Namespace Name) 지정

5. 테스트 내용

5.1 hyein-ns

1. Load Balancer type의 Service 생성 및 Deployment 생성

1) lb.yaml

apiVersion: v1
kind: Service
metadata:
  name: first-svc
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "snet-lb"
spec:
  selector:
    app: hyein
  ports:
    - protocol: TCP
      port: 80
  type: LoadBalancer

internal LB로 생성하기 위해 annotation을 추가하였습니다. (service.beta.kubernetes.io/azure-load-balancer-internal: "true")
실제로 생성을 한 후에 kubectl get svc first-svc -o wide 명령어를 입력하여 확인해 보면 하기와 같이 External IP가 Private IP인 것을 확인할 수 있습니다.

또한 lb가 생성될 subnet을 지정하기 위해 annotation을 추가하였습니다. (service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "snet-lb")
Azure Portal 상에서 Load Balancer가 존재하는 VNet을 선택하면 [설정] 블레이드의 [연결된 디바이스] 탭에서 kubernetes-internal이라는 이름의 Load Balancer가 snet-lb라는 subnet 대역에 배포되어 있는 것을 확인할 수 있습니다.

2) deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: first-deploy
  labels:
    app: hyein
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hyein
  template:
    metadata:
      labels:
        app: hyein
    spec:
      containers:
      - name: first-container
        image: # Azure Container Registry Server/Repository/Image:Tag
        ports:
        - containerPort: 5000

Azure Container Registry에 있는 image를 참조하기 위해 image field에 대한 값에 registry 주소/repository/Image:version 값을 기입하였습니다.

2. ExternalName type의 Service 생성

apiVersion: v1
kind: Service
metadata:
  name: lily-svc-bridge
  namespace: hyein-ns
spec:
  type: ExternalName
  externalName: lily-svc.lily-ns

lily-svc-bridge라는 이름은 pod에서 DNS를 호출하는 이름으로 사용됩니다.
externalName 값은 lily-svc.lily-ns로 지정합니다. 이는 lily-ns에 있는 lily-svc를 가리킵니다. 또한 이는 pod에서 lily-svc-bridge를 호출하면 실제로 변경되는 external 주소입니다.
ExternalName type의 Service는 클러스터 내부에서 클러스터 외부의 특정 서비스에 접속하기 위해 DNS CNAME을 설정하는 방식이라는 것 ! 잊지 않으셨죠?
실제로 ExternalName type의 Service를 생성해 보았습니다. 하기와 같이 External IP Field에 ip가 아닌 lily-ns에 배포된 lily-svc를 가리키는 도메인이 지정된 것을 확인할 수 있습니다.

3. Ingress 생성

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hyein-ingress
  namespace: hyein-ns
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: “false”
spec:
  ingressClassName: nginx
  rules:
  - host: hyein.example.com # domain address 01 
    http:
      paths:
      - path: /
        backend:
          service:
            name: first-svc
            port:
              number: 80
        pathType: Prefix
  - host: lily.example.com # domain address 02
    http:
      paths:
      - path: /
        backend:
          service:
            name: lily-svc-bridge
            port:
              number: 80
        pathType: Prefix

기본적으로 Ingress Controller는 해당 ingress에 대해 TLS 설정이 되어 있는 경우 HTTPS로 강제 redirection 합니다.
이를 비활성화 하기 위해서는 nginx.ingress.kubernetes.io/ssl-redirect: "false" 이라는 annotation을 사용해야 합니다.
규칙에 2개의 host를 추가해 보았습니다. 각 host별 각기 다른 backend가 지정됩니다. 규칙에 정의한 내용 대로 traffic이 분기된다고 보시면 됩니다.

주의할 점은,
Ingress Object와 같은 namespace에 있는 Service의 경우, 그대로 Service를 backend로 지정하면 되지만
Ingress Object와 다른 namespace에 있는 Service의 경우, Ingress가 ExternalName type의 Service를 참조하여
해당 Service를 찾아갈 수 있도록 backend로 ExternalName type의 Service를 지정해 주어야 합니다.

상기 Yaml file로 Ingress Object를 생성해 보았습니다.
- Helm을 통해 Ingress Controller를 생성하였을 때 --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true 라는 파라미터를 통해 Azure Internal Load Balancer를 사용하도록 지정하였습니다. 따라서 Address가 Private IP인 것을 확인할 수 있습니다.

5.2 lily-ns

Load Balancer type의 Service 생성 및 Deployment 생성

5.3 Azure Application Gateway 설정 및 DNS Zone 등록

지금부터는 Azure Portal로 이동하여 Azure Application Gateway에 대해 몇 가지 설정을 진행하고 DNS Zone에 Record를 등록해 보겠습니다.

1. 백 엔드 풀에 Ingress Object의 External IP 등록

Azure Application Gateway의 백 엔드 풀 대상으로 Ingress의 Address를 입력해 줍니다.
이로서 Azure Application Gateway의 뒷단에 Ingress가 연결되게 되고 이러한 Ingress는 Service의 상위 Object로서 각 Service로의 Traffic 분기를 담당하게 됩니다.

2. 상태 프로브 생성

프로브는 하나 이상의 HTTP 설정과 연결된 경우에만 백엔드 상태를 모니터링하며,
프로브가 연결된 HTTP 설정과 연결과 backend pool의 백엔드 리소스를 모니터링합니다.
또한 프로브 요청은 <protocol>://<hostName>:<port>/(urlPath)로 전송됩니다.
ex. http://10.10.144.93:80/healthz

호스트 : Ingress Object의 External IP를 입력합니다.
경로 : helm으로 nginx ingress controller 생성 시 지정해 준 경로 입력
ex.) --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

3. 백 엔드 설정 수정

Terraform으로 생성한 백 엔드 설정 중 일부를 Azure Portal 상에서 수정했습니다.
- 백 엔드 경로 재정의 : 재정의할 필요가 없기 때문에 공란으로 둡니다.
- 사용자 지정 프로브 사용 : [예] 선택 후 2번에서 생성한 상태 프로브를 선택합니다.

4. 규칙 및 수신기 설정

Azure Application Gateway는 Frontend IP 주소로 traffic이 들어오면 Azure Application Gateway 내 구성된 규칙을 확인하여 지정된 백 엔드 대상으로 트래픽을 전송합니다.
리스너는 지정된 포트(ex. 80), 프로토콜, 호스트, IP 주소 등을 사용하여 들어오는 연결 요청을 확인하는 역할을 합니다.

규칙 - [수신기] 탭

규칙 - [백 엔드 대상] 탭

5. DNS Zone에 Record 등록

Ingress Object 생성 시 지정한 host 이름(도메인)과 일치하도록 Record를 등록합니다.
예를 들어 hyein.example.com이 Ingress의 Manifest file에 정의되어 있다면 example.com이라는 Azure DNS Zone을 배포한 후 hyein이라는 A 레코드를 등록해 주어야 합니다.
또한 Azure Application Gateway의 Frontend IP 주소를 각 레코드와 매핑해 주어야 합니다.

5.4 접속 테스트

실제로 생성한 페이지에 접근해 보겠습니다. (도메인은 테스트용으로 실제 사용하고 있어 블러 처리 하였습니다.)

hyein-ns에 생성한 Deployment

lily-ns에 생성한 Deployment

이상으로 Kubernetes Namespace 간 Ingress 트래픽을 라우팅하는 방법에 대해 알아 보았습니다!

[Terraform] 전체 코드 중 특정 resource/module만 apply하기

H-Y-E-N — Fri, 15 Dec 2023 18:00:42 +0900

안녕하세요. HYEN입니다.

이번에는 Terraform 공부 중 알게된 전체 코드 중 특정 리소스만 apply하는 방법에 대해 알아보도록 하겠습니다.

Contents

1. terraform state list

1-1 terraform state list [options] [address...] 명령어 설명

address가 있는 경우, 주어진 조건과 일치하는 상태 파일의 모든 리소스를 나열합니다.
address가 없다면 상태 파일의 모든 리소스가 나열됩니다.
모듈 depth에 따라 알파벳 순으로 정렬됩니다.
코드가 복잡한 경우 수천 개의 결과가 출력될 수 있기 때문에 하나 이상의 pattern을 사용하는 것을 권장합니다.
resource address 형식은 다음과 같습니다.
- module
  - [module path][resource spec]
  - module.module_name[module index]
- resource
  - resource_type.resource_name[instance index]

1-2 terraform state list 명령어 실행 결과

해당 명령어를 입력할 경우 전체 resource address list가 출력됩니다.

1-3 terraform state list module.fw 명령어 실행 결과

2. terraform apply -target [resource address]

2-1 terraform apply -target [resource address] 명령어 설명

[resource address]에 해당하는 target에 대해서만 apply 명령어를 실행할 수 있습니다.

2-2 terraform apply -target [resource address] 명령어 실행 결과

예시로 terraform apply -target module.fw.azurerm_firewall_policy_rule_collection_group.rule-collection-group 명령어 실행를 실행해 보았습니다. (Azure Firewall 정책 중 NAT Rule의 Source IP 변경)

"Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols ... Terraform will perform the following actions ~"에서 알 수 있듯이 해당 명령어를 입력하면 -target flag 뒤에 명시한 resource address에 대해서만 apply가 실행됩니다.
해당 명령어는 Warning 문구를 확인하여 예외적인 경우에만 사용할 것을 권장하고 있으며 경고 문구 상세는 하기와 같습니다.

Warning: Resource targeting is in effect
You are creating a plan with the -target option, which means that the result of this plan may not represent all of the changes requested by the current configuration.

The -target option is not for routine use, and is provided only for exceptional situations such as recovering from errors or mistakes, or when Terraform specifically suggests to use it as part of an error message.

이상으로 Terraform 코드 중 일부 resource에 대해서만 apply하는 방법에 대해 아주 간단히 알아보았습니다!

PaaS형 DNS 서버 Azure Private Resolver 알아보자!

admin_cloud — Fri, 15 Dec 2023 13:38:31 +0900

안녕하세요.

"PaaS형 DNS 서버 역할을 수행하는 Azure Private Resolver 알아보기!" 포스팅으로 돌아온 TAK 입니다.

지난 번 "AWS-Azure VPN S2S(Site-to-Site) 연결과 DNS 서버 구성" 이라는 주제로 글을 작성했습니다.

1부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

안녕하세요. 새로운 포스팅으로 돌아온 TAK 입니다. 이번 주제는 "AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 입니다. 이는 VPN S2S 연결을 통해 Multi Cloud 간 통신 그리고 Azure PaaS 리소스인 Azure Storage Account(

with-cloud.tistory.com

2부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

안녕하세요. "2부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 포스팅으로 돌아온 TAK 입니다. 이번 포스팅의 내용에서는 일부 일반적인 리소스 배포에 대한 내용은 생략되어 있습니다. 다만, 필요한 구

with-cloud.tistory.com

이번에는 조금 더 확장하여 Azure에서 제공하는 PaaS형 DNS 서버 역할을 수행하는 Azure Private Resolver에 대한 내용을 이야기 해보려 합니다!

1. 정의

Azure Private Resolver를 정의하자면 다음과 같습니다.

VM 기반 DNS 서버를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 새로운 서비스

즉, 이전 포스팅에서 구성한 DNS 서버 구성할 필요 없이 Cloud 내부에서 인프라 구성 시에 보다 효율적으로 사용 가능한 리소스 입니다.

Azure의 모든(혹은 대부분)의 PaaS형 리소스들은 DNS 기반으로 동작합니다.

이에 온-프레미스 혹은 다른 CSP 환경에서 Private 구성(Private Endpoint - Private Link)된 Azure PaaS 리소스들을 쿼리할 때, DNS서버 혹은 hosts 파일에 정보를 등록하여 액세스 및 사용 가능합니다.

이 때 보다 많은 PaaS형 리소스 사용 혹은 Cloud Native 환경이라면 활용하기 좋은 리소스라고 생각됩니다.

2. 작동 방식

https://learn.microsoft.com/ko-kr/azure/dns/media/dns-resolver-overview/resolver-architecture.png

쿼리 프로세스를 요약하자면 다음과 같습니다.

(예시에서는 Express Route를 사용했지만, VPN 연결로 이해하셔도 무방합니다.)

가상 네트워크 환경의 Client 에서 DNS 쿼리를 실행합니다.
Client 환경의 가상 네트워크에 대한 DNS 서버가 Azure로 향하는 구성(즉, (조건부) 전달자)이 되어 있다는 가정으로, 쿼리를 지정된 IP 주소로 전달합니다.
전달 받은 정보를 기반으로, Azure DNS 서버(Default )가 VNet에 구성되어 있으며, 동일한 VNet에 연결된 Private DNS Zone이 있는 경우에는 해당 영역을 참조합니다.
만약 쿼리가 VNet에 연결된 Private DNS Zone과 일치하지 않는다면, DNS 전달 규칙 집합에 대한 가상 네트워크 링크를 참조합니다.
규칙 집합 링크가 없는 경우, Azure DNS를 사용하여 쿼리를 확인합니다.
규칙 집합 링크가 있는 경우, DNS 전달 규칙을 평가합니다.
접미사가 일치하는 경우, 쿼리를 지정된 주소로 전달합니다.
여러 항목이 일치하는 경우 가장 긴 접미사를 사용합니다.
일치하는 항목이 없는 경우 DNS 전달을 수행하지 않고 Azure DNS를 사용하여 쿼리를 확인합니다.

3. 구성

아래 구성은 이전 포스팅한 구성을 기반으로 한 정리임을 알려드립니다.
2023.11.29 - [TOPIC/Cloud] - 1부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

위 아키텍처의 구성처럼 Azure Private Resolver의 경우, 동작을 위한 별도의 Virtual Network를 구성하여야 합니다.
또한, DNS 확인자 역할을 하는 InBound / OutBoud 엔드포인트를 배포하는 Subnet의 경우에도 Microsoft.Network/dnsResolvers에만 위임하기 때문에 다른 리소스(서비스)를 사용이 불가합니다.

3-1. 배포를 위한 기본 및 제약 사항 확인

3-2. 인/아웃 바운드 엔드포인트 추가

인바운드 엔드포인트
- DNS 질의 시, 도메인 이름 확인 요청 받을 수 있는 인바운드 엔드포인트 구성
- AWS DNS 서버의 조건부 전달자 설정에 대한 IP 주소
- Static 사설 IP 할당

위와 같은 방식으로 아웃바운드 엔드포인트 추가

3-3. Ruleset

현 구성은 AWS Client > Azure Storage Account 에 대한 질의로,

아웃바운드 엔드포인트 기준으로 DNS 트래픽에 대한 조건부 전달 규칙은 필요하지 않습니다.

→ Azure Private Resolver를 사용함으로

Azure에 DNS 서버 구성과 Forwarder 구성 할 필요 없이, DNS Private Resolver를 통해 전달 가능합니다.

4. 최종 구성 및 테스트

AWS DNS 서버 조건부 전달자 구성의 IP 주소를 인바운드 엔드포인트 정적 IP 주소를 추가합니다.
- 기존 Azure의 DNS 서버의 사설 IP 주소를 그대로 둔다면, 해당 서버 OFF 상태이어야 합니다.
- 또한, 명령어(ipconfig /flushdns) 를 사용하여 DNS 서버의 캐시값을 초기화 한 후에 클라이언트에서 질의해야 해당 구성의 목적에 맞게 정상적인 테스트 할 수 있습니다. (혹은 인바운드 엔드포인트 IP만 등록)

결과

"AWS-Azure VPN S2S(Site-to-Site) 연결과 DNS 서버 구성" 글의 확장으로 시작한 이번 포스팅을 마치겠습니다.

감사합니다:)

2부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

admin_cloud — Wed, 6 Dec 2023 11:03:20 +0900

안녕하세요.

"2부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 포스팅으로 돌아온 TAK 입니다.

이번 포스팅의 내용에서는 일부 일반적인 리소스 배포에 대한 내용은 생략되어 있습니다.
다만, 필요한 구성에 대한 정보는 포함되어 있음을 알려드립니다.

1부 내용은 아래 링크를 참고해주세요:)

1부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

with-cloud.tistory.com

Contents

4. DNS 서버 구성

4-1. Windows Server DNS 서버 설치

AWS, Azure 모두 IaaS형 Windows Server에 대한 DNS 서버 설치 방법은 동일합니다.

4-1-1. 서버 관리자 OR PowerShell을 통한 DNS 서버 설치

(1) [서버 관리자] - [역할 및 기능 추가] - [DNS 서버] 선택을 후 설치

(2) 관리자 권한으로 PowerShell 실행

DNS 역할 설치를 위한 명령어 실행

Install-WindowsFeature -Name DNS

설치 확인

[서버 매니저]를 통해 반영 확인

4-2. DNS 서버 구성

4-2-1. (AWS) DNS 조건부 전달자 구성

[서버 매니저] - [Tools] - [DNS]

blob.core.windows.net / Azure DNS 서버 PIP
- 클라이언트에서 FQDN 쿼리 시, DNS 서버를 통해 대상 리소스 IP 찾을 수 있도록 구성
- 조건부 전달자 이므로 조건에 맞는 DNS 쿼리 시, 동작

사용될 Blob 도메인

<Storage Account Name>.blob.core.windows.net

Azure DNS Server의 Private IP 입력

4-2-2. (Azure) DNS Forwarders 구성

Azure VM - NIC(Network Interface) 에 연결된 Private IP 정적으로 설정
- 기본값 : 동적 → 정적(Static) 변경

Azure DNS 서버
- 해당 DNS 서버의 Forwarders에서 Azure DNS 가상 서버 IP(168.63.129.16) 를 바라보게 되는 구성
- 이는 Azure 플랫폼 리소스에 대한 통신 채널을 원할하게 설정하는 데 사용되는 가상 공용 IP 주소
- 또한, 내부 Azure 플랫폼만이 통신 간 메시지 원본을 제공할 수 있으므로, 안전함.

→ 즉, Forwarders 값으로 AWS DNS 서버로부터 수신되면, Azure DNS 로 전달되게끔 구성하는 과정입니다.

4-3. AWS Client 구성

DNS 정보를 AWS의 Default 값이 아닌, AWS에 구성한 DNS 서버를 바라보기 위한 설정
각 인스턴스에 적용되는 보안 규칙에서 대해서 AWS DNS 서버의 보안 규칙 중 인바운드에 대한 부분을 허용
(DNS - 53, UDP + TCP)

daemon 형식으로 실행중인 Amazon Linux의 DNS Resolve 구성 확인
- systemd-resolved

nslookup 명령어를 통해 구글 도메인(google.com) 조회하면, 도메인 정보 조회에서 0.200.0.2 서버(DNS)가 사용되었음을 알 수 있습니다.
- 이는 EC2의 기본 DNS 정보이며, AWS에서 구성한 VPC의 대역(10.200.0.0/16) 내 포함되어 있는 내부 IP 입니다.

→ 하지만, 현재 구성에서는 기존 DNS 값이 아닌, 다른 서브넷에 구성한 별도의 DNS 서버를 바라보아야 하며

특정 DNS가 포함된 FQDN 조회 시 정상적으로 결과값을 반환(조건부 전달자 구성 했기 때문)해야 합니다.

**참고 사항

: AWS는 동일 네트워크 구성이더라도 보안 그룹의 인/아웃바운드에 대한 별도 설정 필요합니다.
(Azure의 경우, 기본값으로 가상 네트워크 내 모든 통신 허용)

만약 별도의 구성 없이 *기본값(기본 DNS 정보이며, AWS에서 구성한 VPC의 대역(10.200.0.0/16) 내 포함되어 있는 내부 IP)으로 진행한다면, 아래와 같이 클라이언트 단에서 변경한 DNS의 정보값이 반영되지 않습니다.
- telnet 명령어를 통해 DNS port 53 Open 여부 확인 → 액세스 불가 확인

재부팅 중에 유지되는 고정 DNS 서버를 EC2 인스턴스에 할당

아래 경로에서 파일 내용 중 DNS 편집

sudo vi /etc/systemd/resolved.conf

변경 사항 반영을 위한 서비스 재시작 및 상태 확인

sudo systemctl restart systemd-resolved.service

로컬 호스트 리졸버를 바라보며, nameserver 정보 반영 여부 확인

sudo vi /etc/resolv.conf

기본 DNS 정보 주석 처리

확인

→ DNS 질의 시, 기본 DNS 만 사용되며, 해당 값을 주석 처리하게 되면, 질의 불가(무응답) 합니다.

이러한 이유는,
AWS에 배포된 DNS 서버의 보안그룹 규칙에서 상기 작업에 대한 인바운드 Rule 이 존재하지 않기 때문입니다.

따라서, 다음과 같은 조치가 필요합니다.

AWS의 배포된 DNS 서버의 보안그룹 규칙에 DNS port 53 대해 인바운드 규칙을 추가합니다.
- DNS(UDR) 추가 → 해당 VPN 대역
- telnet 등 연결 확인을 위한 DNS(TCP) 추가

설정 후, 재질의 시 수정된 DNS 정보가 반영되었음을 확인할 수 있습니다.

→ 이는 클라이언트에서 DNS 서버를 통해 Azure 인프라에 배포된 Storage 서비스에 대한 정보를 찾기 위한 과정으로, 클라이언트 단에서 AWS DNS 서버로 질의 하는 과정이 선행되어야 합니다.

결과

위 모든 작업을 통해
Client는 AWS DNS 서버를 바라보고 있으며
이를 통해 Azure의 DNS 서버의 Forwarder를 통해 Azure DNS 서버(168.63.129.16) 와 통신할 수 있습니다.
따라서, Azure 가상 네트워크에 연결된 PaaS 리소스인 Storage Account(Blob)에 할당된 Private IP 확인 가능합니다.

AWS 내 Client 에서 질의

이상으로 "AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 포스팅을 마치겠습니다.

관련하여 추가 포스팅으로 Azure의 PaaS 리소스인 [Azure DNS Private Resolver]으로 찾아뵙겠습니다:)

1부 : AWS-Azure VPN S2S 연결 및 DNS 서버 구성

admin_cloud — Wed, 29 Nov 2023 21:08:54 +0900

안녕하세요.

새로운 포스팅으로 돌아온 TAK 입니다.

이번 주제는 "AWS-Azure VPN S2S 연결 및 DNS 서버 구성" 입니다.

이는 VPN S2S 연결을 통해 Multi Cloud 간 통신 그리고 Azure PaaS 리소스인 Azure Storage Account(Blob) 액세스를 위한 DNS 서버 구성입니다.

최근 기업 간 여러 CSP의 인프라와 서비스를 사용하며 운영하는 Multi Cloud 수요가 증가함에 따라 주제를 선정하여 준비하게 되었습니다.

이번 포스팅의 내용에서는 일부 일반적인 리소스 배포에 대한 내용은 생략되어 있습니다.
다만, 필요한 구성에 대한 정보는 포함되어 있음을 알려드립니다.

**Multi Cloud 란?

정의의 개념은 비슷하지만, 세부적인 사항은 각 CSP 별로 다를 수 있습니다.

본격적인 내용에 앞서, 3가지 배경지식이 될 내용을 살펴보겠습니다.

첫째, AWS와 Azure의 리소스 용어

General	AWS	Azure	비고
Virtual Network	VPC (Virtaul Private Cloud)	VNET (Virtual Network)
Virtual Machine	EC2 (Elastic Compute Cloud)	VM (Virtual Machine)
Endpoint (In Cloud)	Virtual Private Gateway	Virtual Network Gateway	For VPN Connection
Gateway (On the other side)	Customer Gateway	Local Network Gateway	For VPN Connection
Storage	S3 (Simple Storage Services)	Blob of Storage Account

둘째, VPN S2S 연결

AWS와 Azure에서는 VPN S2S(Site to Site) 연결을 아래 그림과 같이 표현하고 있습니다.

- AWS

이미지 출처 : https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/images/vpn-how-it-works-vgw.png

- Azure

이미지 출처 : https://learn.microsoft.com/ko-kr/azure/vpn-gateway/media/tutorial-site-to-site-portal/diagram.png

표현의 방식이 다를 뿐, 서로 동일한 역할과 기능을 하는 것을 알 수 있습니다.

해당 구성에서는 일반적으로 S2S(Site to Site) 연결에서 사용되는 IPSec 방식을 사용하였습니다.

쉽게 표현하면, Network to Network의 개념으로 사설망과 사설망을 연결하고자 할 때 IPSec 방식이 사용됩니다.

위 용어를 빌려 표현하자면,

이는 Multi 클라우드 간 보안 연결이며, 데이터가 Gateway 리소스로부터 전달되어 AWS - Azure 간 주고 받는 암화된 링크 입니다.

실제 아래 리소스들은 위 이미지와 같이 온-프레미스 즉, 각 클라우드 입장에서 반대편에서 S2S(Site to Site) 연결을 위해 설치된 물리적 디바이스 혹은 SW 애플리케이션의 정보를 담고,

Gateway
(On the other side)

Customer Gateway

Local Network Gateway

For VPN Connection

암호화된 터널링을 통해, 각 Virtual Network의 Endpoint를 통해 연결 및 통신 가능함을 나타냅니다.

관련하여 VPN 학습에서 큰 도움이 된 블로그를 공유합니다.

VPN 쉽게 이해하기

1960년대 미국과 소련이 한창 냉전으로 신경전을 벌이던 시절, 미국 국방부는 소련의 핵공격에 초토화되어도 작동하는 '통신이 가능한 군사용 네트워크' 개발에 착수했습니다. 국방부와 같은 정

aws-hyoh.tistory.com

셋째, DNS 통신 방식

이미지 출처 : https://www.wisewiredbooks.com/csbooks/ch3-network-internet/img/dns-recursive.jpg

일반적으로 DNS의 기본 동작은 다음과 같다.

위 그림과 관련된 설명은 아래 2가지를 가정한다.

- Cache가 남아 있지 않다는 가정

- Local, Root, TLD DNS 에서 최초 질의한 FQDN을 알지 못한다는 가정

1.웹 브라우저(클라이언트)에서 www.google.com 질의

2. Computer는 우선 Local DNS 해당 Hostname에 대한 IP 주소를 질의

- Iterated query (반복적)

- Recursive query (재귀적)

3. Local DNS에 해당 정보가 없다면, Root DNS 질의

- 정보가 없다면, com DNS(TLD 네임 서버)의 IP 주소를 Local DNS에게 전달

4. TLD DNS에 질의

- 정보가 없다면, google.com DNS(google.com 네임 서버)의 IP주소를 Local DNS에게 전달

5. google.com의 네임 서버에 질의

- 해당 네임 서버에 등록된 ns에 따라서 질의한 FQDN의 주소를 응답

6. 획득한 IP 주소를 Local DNS가 브라우저에게 전달

하지만, 현재 AWS - Azure 클라우드 간 DNS 전달자를 사용하여 통신하는 구성은 Azure 클라우드의 리소스를 사용함으로써 보다 자세한 설명이 필요하기에 2부에서 자세히 다룰 예정입니다.

(많관부~)

이로써 간략한 설명을 마치고, 본격적으로 실제 구성을 진행하겠습니다.

Contents

Architecture

Network

Azure

VNet : 10.100.0.0/16
- subnet01 : 10.000.0.0/24
- subnet02 : 10.100.1.0/24
- subnet-pe : 10.100.30.0/24
- GatewaySubnet : 10.100.255.0/24

AWS

VPC : 10.200.0.0/16
- tak-aws-subnet-public1-2a : 10.200.0.0/20
- tak-aws-subnet-private1-2a : 10.200.128.0/20
- tak-aws-subnet-public2-2b : 10.200.16.0/20
- tak-aws-subnet-private2-2b : 10.200.144.0/20

1. Azure 인프라 - 네트워크

1-1. 구성 목록

Azure Virtual Network(VNet)
- 상기 정보 기준으로 구성

Azure VM
- Windows (Windows Server 2019 Datacenter)
- Standard B2s(2개 vcpu, 4GiB 메모리)

Azure Virtual Network Gateway
- Azure의 VPN은 VNet 내 전용 Gateway Subnet 배포
  → 구독 및 VNet Region(Korea Central)으로 한정
- 사용량을 고려하여 적절한 SKU 선택하여 배포
  → 현재 구성의 SKU : VpnGw2AZ

Azure Storage Account
- PaaS 리소스로 그 중 Blob을 하위 리소스로 선택하여 Private Endpoint 연결.
- 이를 통해, 외부에 접근을 차단하고, 가상 네트워크 내에서만 액세스 가능

→ Private Endpoint 할당되고, 배포된 서브넷 대역 기준으로 사설 IP 할당

2. AWS 인프라 - 네트워크

2-1. VPC & EC2 생성

VPC

Auzre 대역과 중첩되지 않게 네트워크 구성
Client 서버 | DNS 서버 별도의 보안 그룹 적용

EC2

Client 서버
- Amazon Linux 3 (t2.medium)

DNS 서버
- Windows Server 2019 Base (t3.medium)

2-2. VPN 연결을 위한 구성

2-2-1. Custom GW 생성

IP 주소 : 디바이스의 외부 인터페이스에 대한 인터넷 라우팅 가능 IP 주소
- 즉, 연결할 대상(Azure VPN)의 공용 IP

2-2-2. Virtual Private GW 생성

2-2-3. VP GW - VPC 연결

VP GW를 통해 연결할 대상 네트워크인 VPC 선택

사용 가능한(대상) VPC 선택하여 연결

2-2-4. 라우팅 테이블

라우팅 전파 편집

** EC2 배포된 서브넷과 연결된 라우팅 테이블 설정 필요

3. AWS - Azure VPN 연결

3-1. (AWS) Site-to-Site VPN Connections

CGW 이름 변경(tak-custom-gw-01 → tak-cgw-01)

Config

대상 게이트웨이 유형 : 가상 프라이빗 게이트웨이
가상 프라이빗 게이트웨이 : 기존 생성한 VPGW
고객 게이트웨이 ID : 기존 생성한 CGW
라우팅 옵션 : 정적
- 연결할 대상(Azure Virtural Network)의 Private CIDR 형식 기입

로컬 IPv4 네트워크 CIDR : 기본값(0.0.0.0/0)
- PN 터널을 통해 통신할 수 있는 고객 게이트웨이(온프레미스) 측의 IPv4 CIDR 범위

원격 IPv4 네트워크 CIDR : 기본값(0.0.0.0/0)
- VPN 터널을 통해 통신할 수 있는 AWS 측의 IPv4 CIDR 범위

**Pre-Shared Key for Tunnel 1

AWS의 VPN 연결 생성 시, 기본적으로 2개의 터널이 생성됨.
- 2개 중 1개를 선택하여, 연결할 대상(Azure Local Network Gateway)의 [IP 구성] 설정에 기입
- 이는 VPN S2S 통신에서 사용되는 공용 IP 임

이때, 사전 공유 키의 별도 값을 입력하지 않는다면, Amazon에서 자동으로 생성됨.
이는 기본 인증 옵션이며, 연결할 대상(Azure Local Network Gateway)에서 입력하여 디바이스 간 보안 연결을 설정
대상 VPN 연결을 선택 후, [작업] - [VPN 터널 옵션 수정]

Tunnel 1 의 공용 IP주소를 선택하여, 사전 공유 키를 확인

3-2. (Azure) Site-to-Site VPN Connections

생성된 Azure Local Network Gateway의 [구성] 설정

AWS의 Tunnel 1의 공용 IP
AWS VPC의 네트워크 대역

Azure의 VPN 연결
- 연결 형식, GW 리소스 선택 등 연결을 추가

생성한 해당 연결을 선택하여 [인증 유형]의 공유 키(PSK) 값에 앞서 확인한 AWS의 Tunnel 1의 Pre-Shared Key 값을 입력

3-3. AWS - Azure 연결 확인

AWS Tunnel 1 : UP

Azure 연결 상태 : 연결됨

AWS의 라우팅 테이블 설정 확인
- AWS EC2 가 위치한 서브넷에 연결된 라우팅 테이블에
  → Azure의 네트워크 대역을 대상(Destination)
  → 트래픽이 생성한 VPN을 통해서 라우팅될 수 있도록 대상(Target) 설정

3-4. AWS - Azure 연결 테스트

AWS

공용 IP
- 실패, 이유는 Azure VM의 인바운드 설정에서 공용 IP 접근 시, ICMP 허용하지 않았기 때문

사설 IP
- 성공, Azure의 기본 네트워크 보안 그룹 규칙에서는 가상 네트워크 내 모든 프로토콜을 허용

Azure

공용 IP
- 실패, 소스 IP로 Azure의 사설 네트워크 대역으로 설정

사설 IP
- 성공

이번 포스팅에서는 VPN S2S(Site to Site) 구성하는 과정까지를 담았습니다.

이어지는 2부에서는 DNS 구성 관련한 포스팅으로 찾아오겠습니다!!!

제가 놓친 부분이 있다면, 자유롭게 댓글로 의견 남겨주세요:)