1. Introduction

In June 2024, I joined the Lee Jae-hoon professor's Network Research Lab at Dongguk University, focusing on AI-enabled networking technologies.
As part of the lab activities, I worked extensively with ONOS (Open Network Operating System) to understand and apply Software-Defined Networking (SDN) concepts through hands-on labs.

This blog post summarizes my journey. detailed version also exists in korean.

ONOS Practice - Connecting virtual networks using Mininet with ONOS 2.7.0 on Ubuntu 22.04

ONOS Practice - Setting flow rules in ONOS to control VLAN-tagged packets

ONOS Practice - Visualizing real-time switch port traffic statistics from ONOS using open-source tools

2. Setting up ONOS and Mininet

To start, I set up the ONOS 2.7.0 controller on Ubuntu 22.04 and connected it with Mininet, a popular network emulator for SDN.
I practiced creating virtual networks consisting of multiple switches and hosts, and then linked them to ONOS to control the flow of network traffic.

Key tools:

• Ubuntu 22.04
• Mininet
• ONOS 2.7.0

3. Connecting Virtual Networks

I created virtual topologies in Mininet (such as linear and tree structures) and verified that ONOS correctly discovered all devices and links.
I also explored how ONOS automatically installs default flow rules to manage packet forwarding in the network.

I built flow rules by two ways. one in reactive mode, where the SDN controller makes decision, and the other in proactive mode, where the user defines the rules manually.

4. Installing Open vSwitch on Raspberry Pi

Taking a step further, I installed Open vSwitch (OVS) on Raspberry Pi 3 devices to build a real-world SDN testbed.
After configuring the OVS bridges and ports, I connected the Raspberry Pi switches to ONOS as external network elements.

5. Controlling VLAN Packets with ONOS

Using ONOS’s Flow Rule functionality, I wrote flow rules to control VLAN-tagged packets.
This included filtering specific VLAN IDs and forwarding traffic based on VLAN properties, allowing me to manage network segmentation dynamically.

6. Visualizing Switch Traffic in Real Time

To monitor network performance, I visualized real-time switch port traffic data using ONOS metrics combined with open-source visualization tools.
This helped me gain insights into traffic patterns, detect bottlenecks, and understand SDN monitoring strategies.

7. Key Takeaways and Reflections

Through these hands-on experiences, I learned:

• How SDN controllers like ONOS manage and orchestrate network flows.
• Practical skills in setting up and controlling virtual and physical network devices.
• The importance of real-time network visualization for operational insights.

This project sparked my interest in developing custom ONOS applications and exploring deeper into SDN-enabled smart networking.

I look forward to continuing this journey by building my first ONOS application and contributing to open-source networking initiatives!

Resources

• ONOS Project Official Website
• ONOS Wiki: Setting up Your First App

Thank you for reading! 🚀

이 문제는 에라토스테네스의 체 알고리즘을 이용하여 풀 수 있다. 먼저, vector<bool> isPrime(N+1,true)를 생성하여 모든 수를 소수로 가정한다. 그리고 2부터 N까지 배수를 제거하여 소수만 남기는 구조이다. 코드는 아래에 적어두었다.

ios::sync_with_stdio(false);와 cin.tie(nullptr);는 c++에서 입출력 성능을 최적화 하기 위한 코드이다. 1️⃣ios::sync_with_stdio(false);

• c++의 표준 입출력인 cin,cout과 c의 표준 입출력인 scanf,printf의 동기화를 해제하는 역할을 한다.
• 기존적으로 c++의 cin,cout은 c의 scanf,printf와 동기화되어 같이 사용될 때 정상적으로 동작하도록 보장된다.
• 하지만 동기화과정이 불필요한 경우 성능을 향상시킬 수 있다.
• 즉, sacnf,printf를 사용해야한다면 이 옵션은 쓰면 안된다. 2️⃣cin.tie(nullptr);
• 기본적으로 cin과 cout은 연결(tie)되어있다.
• 즉, cin이 사용될 때마다 자동으로 cout이 flush(출력 버퍼 비움)이 되어 즉시 출력된다. 이를 해제(nullptr로 설정)하려면 불필요한 flush를 방지하여 입출력 속도를 높일 수 있다.

#include<iostream>
#include<vector>

using namespace std;

void sieve(int M, int N) {
    vector<bool> isPrime(N+1, true);
    isPrime[0] = isPrime[1] = false;

    //에라토스테네스의 체 알고리즘
    for(int i = 2; i*i <=N; i++){
        if(isPrime[i]){
            for(int j = i * i; j<= N; j+=i){
                isPrime[j] = false;
            }
        }
    }

    //결과 출력
    for(int i = M; i<=N; i++){
        if(isPrime[i]){
            cout<<i<<'\n';
        }
    }
}

int main(){
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    int M, N;
    cin >> M >> N;
    sieve(M, N);

    return 0;
}

이번에는 위 사진의 순서대로 실습을 진행해볼 것이다. 실습의 편의성을 위해 모든 오픈소스 소프트웨어는 모두 하나의 PC에 설치된다.

1️⃣ ONOS + Mininet 구성

Mininet으로 가상 네트워크를 생성하여 SDN 제어기인 ONOS에 연결을 구성하는 방식이다.

ONOS 2.7.0, Ubuntu 22.04이용해 mininet 가상 네트워크 연결 링크된 포스트와 동일하게 진행하면 된다.

위 포스팅대로 진행을 완료하면, 현재 ONOS와 연결된 Mininet기반 가상 네트워크 구조를 조회하면 다음과 같은 결과가 출력된다. dpid가 '0000000000000001'인 OVS스위치(s1) 1대에 1번 포트(s1-eth1)과 2번 포트(s1-eth2)에 각각 호스트가 하나씩 연결된 것을 알 수 있다.

구성정보를 표현한 그림이다.

2️⃣ Celery 구성

Celery로 OVS 포트 별 실시간 송/수신 트래픽 처리량 계산

💡 Celery란 무엇인가? Celery는 분산 작업 큐(distributed task queue)이다. python으로 작성되었으며, 비동기 작업 및 스케줄링에 널리 사용된다. 즉, 시간이 오래걸리는 작업을 백그라운드에서 실행할 수 있도록 도와주는 도구이다. 이는 웹 애플리케이션의 응답 속도를 높이기 위해 많이 사용된다.

Celery를 설치하는 가장 간단한 방법은 python라이브러리 설치패키지 매니저인 pip을 통해 설치하는 방법이다. 이를 위해 python3와 python3를 지원하는 pip을 pc에 설치해준다. pip 설치가 완료되면 pip3를 이용하여 Celery를 설치해준다. pip3를 통해 설치된 python모듈을 조회하면 나는 5.4.0 버전이 조회된다.

Celery설치를 완료했다면, 이제 Celery 기본 Broker인 RabbitMQ를 아래와같이 설치해준다.

비유를 들어 설명하자면,

• Celery는 "심부름 명령을 내리는 사람"이다. 심부름이 많을 때 효율적으로 각 심부름꾼(worker)에게 지시한다.
• RabbitMQ는 "심부름 메모를 전달하는 게시판"이다. 모든 심부름꾼은 게시판에서 심부름 내용을 확인하고 수행한다.

설치가 다 되었다면 실행해준다. 이제는 Broker(RabbitMQ)를 통해 Worker에 분배 될 Celery Task를 생성하면 된다. 하지만, 그 전에 먼저 Celery Task에 반영해주기 위한, OVS 스위치 포트 별 트래픽 정보를 가지고 트래픽처리량을 계산하는 과정을 알아보아야 한다.

그래서 일단 REST API를 통해서 ONOS와 연결된 스위치 별 포트정보를 조회해서, 어떤 정보가 수집되는지 확인해볼 필요가 있다. 이를 위해 우선 cURL, jq를 설치해주자.

• cURL: HTTP 요청을 전송하는 도구
• jq: JSON 데이터를 읽기 쉽게 포맷하여 출력하는 도구 그런 다음 다음과같이 ONOS의 REST API를 이용해 Mininet으로 구성한 OVS 스위치 s1의 포트 별 트래픽 정보를 조회하는 스크립트 파일을 만들어준다. ONOS_IP는 본인의 IP로 바꾸어주어야 한다.

이 스크립트를 실행하면, ONOS와 연결된 스위치 별 포트 정보를 알 수 있다. 여기서는 OVS 스위치 s1의 1번포트와 2번포트에 대한 정보를 확인할 수 있다. 각 포트 별 bytesReceived, bytesSent, durationSec 값을 이용하면 스위치 포트 별 수신(RX), 송신(TX)패킷에 대한 트래픽처리량 계산이 가능하다.

• bytesReceived() : 포트를 통해 수신받은 패킷의 누적 사이즈(단위: bytes)

• byteSent() : 포트를 통해 송신된 패킷의 누적 사이즈(단위:bytes)
• durationSec() : 포트가 활성화된 시간(sec)

여기까지 완료되었다면, 이제는 위의 송/수신 트래픽처리량(TX/RX Throughput)에 대한 공식을 가지고, 매 단위시간마다 트래픽 처리량 정보를 계산하는 Celery Task를 생성하겠다. Celery Task를 통하여 ONOS의 REST API를 호출하기 위하여, Python requests 모듈을 설치한다.

처음 계산되는 송/수신 트래픽 처리량 값을 임시로 저장하기 위한 data디렉토리를 생성하고, 읽고 쓰기 권한을 아래와같이 변경해준다. (권한 변경 시 sudo 붙여주는 것을 잊지말자 ㅎㅎ)

다음으로, 아래와같이 task.py라는 파일을 생성하여 ONOS_CELERY_TASK라는 celery task함수를 하나 작성한다. 해당 task는 ONOS의 REST API를 통해 ONOS와 연결된 모든 스위치의 활서화된 포트 별 bytesSent,bytesReceived,durationSec값을 조회하고, 앞에서 도출한 공식 두 가지를 통해서 송수신 트래픽에 대한 처리량(TX/RX Throughput)을 계산한다.

from celery import Celery
import json
import requests
import os

# Broker(RabbitMQ) 설정
app = Celery('ONOS_TASK', broker='pyamqp://guest@localhost//')

# celeryconfig.py에 정의한 Celery Task 환경설정 정보 가져오기
app.config_from_object('celeryconfig')

# 파일 저장 및 읽기 함수 정의
def FILE_WRITE(file_dir, data):
    with open(file_dir, 'w') as f:
        f.write(data)

def FILE_READ(file_dir):
    with open(file_dir, 'r') as f:
        return f.readline()

# Celery Task 함수 정의
@app.task
def ONOS_CELERY_TASK(CTRL_IP, CTRL_PORT, CTRL_ID, CTRL_PW):
    try:
        # ONOS REST API를 통해 스위치 정보 조회
        ONOS_URI = f"http://{CTRL_IP}:{CTRL_PORT}/onos/v1/devices"
        result = requests.get(ONOS_URI, auth=(CTRL_ID, CTRL_PW))
        DEVICE_INFO = result.json().get("devices", [])

        for device in DEVICE_INFO:
            SW_DPID = device["id"]
            print(f"Processing SW_DPID: {SW_DPID}")
            ONOS_URI_PORTS = f"http://{CTRL_IP}:{CTRL_PORT}/onos/v1/statistics/ports"
            result_ports = requests.get(ONOS_URI_PORTS, auth=(CTRL_ID, CTRL_PW))
            SW_STATE_INFO = result_ports.json().get("statistics", [])

            for state_info in SW_STATE_INFO:
                if state_info["device"] == SW_DPID:
                    for port in state_info["ports"]:
                        MATCH_PORT = port["port"]
                        RX_BYTE_COUNT = port["bytesReceived"]
                        TX_BYTE_COUNT = port["bytesSent"]
                        DURATION_TIME = port["durationSec"]

                        FILE_NAME = f"dpid_{SW_DPID.replace(':', '')}_port_{MATCH_PORT}"
                        FILE_DIR = f"./data/{FILE_NAME}.log"

                        # 파일이 없으면 새로 생성
                        if not os.path.exists(FILE_DIR):
                            data = f"{TX_BYTE_COUNT}_{RX_BYTE_COUNT}_{DURATION_TIME}"
                            FILE_WRITE(FILE_DIR, data)
                        else:
                            # 파일이 있으면 데이터 읽기
                            DATA = FILE_READ(FILE_DIR).split("_")
                            PREVIOUS_TX_BYTE_COUNT = float(DATA[0])
                            PREVIOUS_RX_BYTE_COUNT = float(DATA[1])
                            PREVIOUS_DURATION_TIME = float(DATA[2])

                            CURRENT_TX_BYTE_COUNT = float(TX_BYTE_COUNT)
                            CURRENT_RX_BYTE_COUNT = float(RX_BYTE_COUNT)
                            CURRENT_DURATION_TIME = float(DURATION_TIME)

                            data = f"{TX_BYTE_COUNT}_{RX_BYTE_COUNT}_{DURATION_TIME}"
                            FILE_WRITE(FILE_DIR, data)

                            # Duration Time이 0일 경우 로그 출력
                            if CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME == 0:
                                print(f"Duration time is 0 for Port No. {MATCH_PORT}. The SDN controller has not updated.")
                            else:
                                # Throughput 계산
                                TX_THROUGHPUT = (CURRENT_TX_BYTE_COUNT - PREVIOUS_TX_BYTE_COUNT) * 8 / (CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME)
                                RX_THROUGHPUT = (CURRENT_RX_BYTE_COUNT - PREVIOUS_RX_BYTE_COUNT) * 8 / (CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME)

                                TX_THROUGHPUT = round(TX_THROUGHPUT, 4)
                                RX_THROUGHPUT = round(RX_THROUGHPUT, 4)

                                print(f"Port No. : {MATCH_PORT}")
                                print(f"TX_THROUGHPUT = {TX_THROUGHPUT} bps")
                                print(f"RX_THROUGHPUT = {RX_THROUGHPUT} bps")

    except Exception as error:
        print(f"Error: {error}")

CTRL: Controller의 준말 DPID: (Device Port Identifier) OpenFlow 프로토콜에서 각 스위치를 식별하기 위해 사용되는 64비트 길이의 식별자

이어서, 앞에 작성한 task.py의 Celery Task함수 "ONOS_CELERY_TASK"가 매 3초마다 호출되도록 "celeryconfig.py"파일을 생성해, 스케줄링 내용을 아래와 같이 작성한다. 참고로, celery는 celery Beat이라는 스케줄러를 통해 Task들의 실행 순서를 결정할 수 있는데, 여기서 작성하는 "celeryconfig.py"파일 내용을 가지고 Celery Beat을 통해 Task가 매 3초간 수행되게 된다.

from datetime import timedelta

# ONOS의 IP/Port/ID/PW 정의
CTRL_IP = "192.168.224.128"
CTRL_PORT = "8101"
CTRL_ID = "karaf"
CTRL_PW = "karaf"

# task.ONOS_CELERY_TASK(task.py 파일에 정의된 ONOS_CELERY_TASK)의 스케줄링 정보 정의
beat_schedule = {
    'add-every-3-seconds': {
        'task': 'task.ONOS_CELERY_TASK',
        'schedule': timedelta(seconds=3),
        'args': (CTRL_IP, CTRL_PORT, CTRL_ID, CTRL_PW)
    }
}

# 타임존 설정
timezone = 'UTC'

broker_connection_retry_on_startup = True

💣트러블 슈팅(1) - broker_connection_retry_on_startup = True

• 이 옵션이 필요한 이유는 Celery워커 또는 비트 프로세스가 브로커(RabbitMQ, Redis 등)에 연결할 수 없을 때 자동으로 재시도하도록 설정하기 위함이다.
• 브로커 서비스가 아직 시작하지 않았거나, 일시적으로 응답하지 않을 수 있다. 위 옵션을 설정하면, 연결 실패 시 바로 종료되지 않고 일정 시간 동안 재시도를 시도한다.
• 🔍초기값이 False인 이유? 초기 재시도 시 무한 루프처럼 실행되는 것을 방지하기 위해서이다.

해당 Task를 CeleryBeat를 통해 3초 단위로 실행할 것이므로 -B 옵션을 포함하여 아래와같은 명령어를 실행한다.

Celery Beat: 주기적으로 작업을 스케줄링하여 실행할 수 있도록 해주는 Celery의 확장 패키지

성공적으로 Celery가 실행되면 아래와같이 Celery서버의 로그화면이 출력되면서 "task.py"에서 작성했던 Celery Task함수 "ONOS_CELERY_TASK"가 호출되는 것을 확인할 수 있다.

그리고 매 3초마다 DPID가 of:0000000000000001인 OVS 스위치 s1의 현재 활성화된 포트 1번, 2번의 송/수신 트래픽 처리량(TX/RX Troughput)이 계산되어 출력되는 것을 알 수 있다.

💣트러블슈팅(2)

1. celerybeat-schedule 파일 문제 celerybeat-schedule파일은 Celery Beat가 작업 일정을 관리하기 위해 사용하는 데이터베이스 파일이다. 이 파일은 일정이 저장되어 있으므로, 비정상적인 종료나 파일 손상이 발생하면 Beat 프로세스가 해당 파일을 읽을 수 없어 오류를 발생시킨다.

-> 따라서, 파일이 손상된 경우에는 rm 명령어로 해당 파일을 지우고, 다시 Beat 프로세스를 실행해야한다. 2. -n 옵션을 통해 워커 이름을 실행 때마다 변경해주어야 한다. Celery 워커는 이름을 기준으로 프로세스를 구분한다. 기본적으로 여러 개의 동일한 이름을 가진 워커가 동시에 실행되면, 충돌이 발생한다. 즉, PID가 겹치고 메시지 큐 관리에서 문제가 생기는 것이다. 같은 이름의 워커가 이미 실행 중이면 Address already in use 또는 Another worker with the same name exists 등의 오류가 발생할 수 있다. -> 즉, -n옵션을 사용해 각 워커가 고유한 이름을 가지도록 설정해야한다.

3️⃣ InfluxDB 구성

InfluxDB는 시계열 데이터를 저장하고 관리하는 오픈소스 데이터베이스이다. 주로 온도, 시간, 속도 등 시간별 수치로 측정될 수 있는 시계열 데이터에 특화되어있다. 그래서 이번엔 해당 InfluxDB에다가 앞서 Celery를 통해 매 3초마다 계산되는 송/수신 트래픽처리량(TX/RX Throughput) 정보를 주기적으로 한 번 저장해볼 것이다.

influxdb와 influxdb-client 패키지를 아래와 같이 설치한다.

• sudo service influxdb start: InfluxDB 실행
• influx: influxDB CLI환경으로 접속됨. 버전 확인도 가능
• 트래픽처리량을 저장하기위한 sdn이라는 DB 생성, 확인, influxDB CLI종료

그리고, 생성한 데이터베이스 sdn에 매 3초간 Celery Task로 계산되는 송/수신 트래픽처리량을 저장하기 위해 먼저 InfluxDB의 Python패키지를 아래와같이 설치한다.

그리고, task.py파일을 열어서, 최상단에는 InfluxDBClient라는 파이썬 모듈을 가져와 InfluxDB에 데이터를 저장해주기 위한 함수 InfluxDB_InsertData()를 아래와같이 저장해주고, 송/수신 트래픽처리량을 계산하는 소스코드 아래에 계산된 트래픽처리량을 InfluxDB에 저장할 수 있도록 위쪽과 들여쓰기를 맞추어서 InfluxDB_InsertData()를 호출하는 코드를 추가해준다.

from celery import Celery
import json
import requests
import os
from influxdb import InfluxDBClient  # InfluxDB 라이브러리 import

# Broker(RabbitMQ) 설정
app = Celery('ONOS_TASK', broker='pyamqp://guest@localhost//')

# celeryconfig.py에 정의한 Celery Task 환경설정 정보 가져오기
app.config_from_object('celeryconfig')

# InfluxDB에 데이터 저장 함수 정의
def InfluxDB_InsertData(dpid, port_no, tx_throughput, rx_throughput):
    DB_HOST = "192.168.224.128"  # InfluxDB 호스트 IP
    DB_PORT = "8086"         # InfluxDB 포트
    DB_USER = "root"         # InfluxDB 사용자 ID
    DB_PSWD = "root"         # InfluxDB 비밀번호
    DB_NAME = "sdn"          # InfluxDB 데이터베이스 이름

    json_body = [{
        "measurement": dpid,
        "tags": {
            "port": port_no
        },
        "fields": {
            "tx_throughput": tx_throughput,
            "rx_throughput": rx_throughput
        }
    }]

    client = InfluxDBClient(DB_HOST, DB_PORT, DB_USER, DB_PSWD, DB_NAME)
    print(f"Write points: {json_body}")
    client.write_points(json_body)

# ONOS REST API를 통해 조회된 정보를 파일로 저장하기 위한 함수 정의
def FILE_WRITE(file_dir, data):
    with open(file_dir, 'w') as f:
        f.write(data)

# 파일로 저장된, ONOS REST API를 통해 조회된 정보를 읽어오기 위한 함수 정의
def FILE_READ(file_dir):
    with open(file_dir, 'r') as f:
        data = f.readline()
    return data

# Celery를 통해 실행시켜줄 ONOS TASK "ONOS_CELERY_TASK" 함수 정의
@app.task
def ONOS_CELERY_TASK(CTRL_IP, CTRL_PORT, CTRL_ID, CTRL_PW):
    try:
        ONOS_URI = f"http://{CTRL_IP}:{CTRL_PORT}/onos/v1/devices"
        result = requests.get(ONOS_URI, auth=(CTRL_ID, CTRL_PW))
        DEVICE_INFO = result.json()["devices"]

        # ONOS REST API를 통해 스위치별 Port 상태 조회
        for device in DEVICE_INFO:
            SW_DPID = device["id"]
            print(f"SW_DPID: {SW_DPID}")
            ONOS_URI = f"http://{CTRL_IP}:{CTRL_PORT}/onos/v1/statistics/ports"
            result = requests.get(ONOS_URI, auth=(CTRL_ID, CTRL_PW))
            SW_STATE_INFO = result.json()["statistics"]

            for state in SW_STATE_INFO:
                if state["device"] == SW_DPID:
                    for port in state["ports"]:
                        MATCH_PORT = port["port"]
                        RX_BYTE_COUNT = port["bytesReceived"]
                        TX_BYTE_COUNT = port["bytesSent"]
                        DURATION_TIME = port["durationSec"]
                        FILE_NAME = f"dpid_{SW_DPID.replace(':', '')}_port_{MATCH_PORT}"
                        FILE_DIR = f"./data/{FILE_NAME}.log"

                        if not os.path.exists(FILE_DIR):
                            data = f"{TX_BYTE_COUNT}_{RX_BYTE_COUNT}_{DURATION_TIME}"
                            FILE_WRITE(FILE_DIR, data)
                        else:
                            DATA = FILE_READ(FILE_DIR).split("_")
                            PREVIOUS_TX_BYTE_COUNT = float(DATA[0])
                            PREVIOUS_RX_BYTE_COUNT = float(DATA[1])
                            PREVIOUS_DURATION_TIME = float(DATA[2])

                            CURRENT_TX_BYTE_COUNT = float(TX_BYTE_COUNT)
                            CURRENT_RX_BYTE_COUNT = float(RX_BYTE_COUNT)
                            CURRENT_DURATION_TIME = float(DURATION_TIME)

                            data = f"{TX_BYTE_COUNT}_{RX_BYTE_COUNT}_{DURATION_TIME}"
                            FILE_WRITE(FILE_DIR, data)

                            if CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME == 0:
                                print(f"The SDN controller has not updated The Port No. {MATCH_PORT} State!!")
                            else:
                                TX_THROUGHPUT = (CURRENT_TX_BYTE_COUNT - PREVIOUS_TX_BYTE_COUNT) * 8 / (
                                    CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME)
                                RX_THROUGHPUT = (CURRENT_RX_BYTE_COUNT - PREVIOUS_RX_BYTE_COUNT) * 8 / (
                                    CURRENT_DURATION_TIME - PREVIOUS_DURATION_TIME)

                                TX_THROUGHPUT = round(TX_THROUGHPUT, 4)
                                RX_THROUGHPUT = round(RX_THROUGHPUT, 4)

                                print(f"Port No. : {MATCH_PORT}")
                                print(f"TX_THROUGHPUT = {TX_THROUGHPUT} bps")
                                print(f"RX_THROUGHPUT = {RX_THROUGHPUT} bps")

                                # InfluxDB에 트래픽 처리량 저장
                                InfluxDB_InsertData(SW_DPID, MATCH_PORT, TX_THROUGHPUT, RX_THROUGHPUT)

    except Exception as error:
        print("Error:", error)

이렇게 수정한 task.py파일이 정상적으로 동작하는지 Celery서버를 실행한다. 아래 사진과같이 정상적으로 실행되었다면, 로그 화면에서 influxDB에 저장되는 데이터 정보를 확인할 수 있다. 로그 내용을 살펴보면 DPID가 of:0000000000000001인 OVS스위치의 현재 활성화된 1번,2번 포트의 송수신 트래픽 처리량 값이 계산되어 JSON형식으로 influxDB에 전달되는 것을 알 수 있다.

이제는 InfluxDB에 실제로 데이터가 저장되었는지 확인해보자. InfluxDB CLI에 접속하여 앞서 생성했던 "sdn" DB를 선택한다. 그리고 select문을 통해 저장된 데이터를 조회해보면, 시간대별로 Celery Task가 실행되면서 저장된 스위치 포트별 송/수신 트래픽 처리량 데이터 정보를 확인할 수 있다.

4️⃣ Grafana 구성

지금까지 Celery Task를 통해 송수신 트래픽처리량도 계산했고, 이를 InfluxDB라는 시계열 데이터베이스에 저장도 했다.

이번에는 Grafana라는 데이터 시각화 도구를 통해 InfluxDB에 저장된 트래픽처리량 데이터를 실시간 그래프로 출력하는 과정이다.

먼저, grafana를 다운받아야한다. 위 사진의 url로 접근하여, Ubuntu and Debien에서 grafana 다운로드 부분을 복사한다. 복사해온 명령어를 실행시켜주면 된다. 위의 wget은 설치파일을 받아오는 것이다. 이제 받은 파일을 가지고 Grafana를 PC에 설치해준다.

grafana를 실행한 뒤 Grafana UI(192.168.224.128:3000)에 접속하자. 위 사진처럼 로그인 화면이 뜨면 성공이다.

다음으로는 Grafana와 InfluxDB를 연동해야한다. 로그인화면에서는 초기아이디,패스워드인 admin/admin을 입력하고 로그인한다. influxDB로 data source를 만들어주면 된다.

save&test 버튼을 누른다.

Mininet CLI로 접속해서 h1에서 h2로 ping메시지를 보낸다.

💣 트러블슈팅(3)

1. Mininet은 ~(root)에서 접속해야만한다. 예를들어, onos디렉토리 안에서는 접근하려하면 오류가 발생한다.
2. 실행했던 Mininet에서 exit하면, 꼭 sudo mn --clear 명령어를 통해 지워주어야한다. 지워주지 않으면 다시 Mininet CLI로 접속이 되지 않는다.

그리고, 다른 터미널에서 ping 정보를 DB에 저장해주어야 grafana에 그래프로 반영이 된다. 기존에 만들어두었던 것을 실행해주면 된다. 그래프 설정을 아래 사진을 쭉 따라하면 된다. 대시보드와 그래프의 이름은 원하는 것으로 바꾸어도 좋다.

Grafana의 Dashboard를 확인해보면, 현재 가상 호스트 h1에서 h2로 트래픽이 흐르면서 가상 호스트와 연결된 OVS 스위치 1번 포트의 수신 트래픽처리량(RX Throughput)은 약 1.3kbps, 송신 트래픽처리량(TX Throughput)은 약 0.7kbps인 것을 확인할 수 있다.

이 실습은 ununtu 22.04버전, ONOS 2.7.0 버전이 필요하다. vmware와 Ubuntu설치는 검색해보면 자세히 정리된 블로그들이 많다. onos 설치과정은 아래 블로그에 적혀있으니 그대로 따라하면 된다. ONOS 2.7.0, Ubuntu 22.04이용해 mininet 가상 네트워크 연결

위의 포스팅에서는 Mininet기반의 가상 네트워크 환경을 구축하여 Host간 통신이 되도록 flow rule을 reactive, proactive 방식으로 각각 설정해보았다. 이번에는 가상으로만 패킷제어를 해보는 방식이 아닌, 물리적 장치인 라즈베리파이3를 추가하여 진행한다. 라즈베리파이3에 OVS를 설치하여 하나의 SDN스위치를 만들고 여기에 연결된 단말 장치 간 VLAN패킷을 주고받을 수 있도록 ONOS로 flow rule을 설정해보는 것이다.

자 이제 실습을 시작해보자!!

준비물

참고로, 나는 라즈베리파이의 usb 단자와 노트북을 연결하기 위해 usb 이더넷 어댑터를 산 것이다. 사진에는 두 개 라고 나와있지만, 이번 실습에서는 하나는 물리적으로, 하나는 가상으로 구성하여 실습을 진행할 것이다. 최근 노트북은 대부분 c타입으로 연결하기 때문에 usb to c 선 1개 가 있으면 될 것 같다!

1️⃣ ONOS 환경 구축

먼저, 실습을 진행할 컴퓨터를 준비한다. 아래 조건을 만족해야한다.

나의 경우 컴퓨터와 유무선공유기 사이에 인터넷 선을 연결하여 인터넷에 연결했다. pc의 IP주소는 아래 사진처럼 확인할 수 있다.

선행 post부터 쭉 따라했다면, ONOS가 잘 설치되어있을 것이다. 확인한 pc주소를 넣어 명령어를 실행하면 ONOS CLI 접속이 잘 될 것이다. 초기 비밀번호는 karaf이다. 다시 기본 터미널로 나오고싶다면, ctrl+D버튼을 누르면 된다.

SDN의 openflow프로토콜을 지원하는 ONOS의 애플리케이션인 org.onosproject.openflow를 활성화시킨다.

💣 트러블슈팅

명령어를 올바르게 작성했는데 이런 오류가 나온다면, SSH 호스트 키가 변경되어 발생하는 문제이다. 이를 해결하기 위해 known_hosts파일에 저장된 이전 키를 삭제해야한다.

ssh-keygen -f "/home/hyeonseo/.ssh/known_hosts" -R "[192.168.224.128]:8101"

이 명령어를 통해 키를 제거한 후 다시 SSH 연결을 시도하면 잘 된다.

2️⃣ 라즈베리파이 연결

이제 라즈베리파이에 ubuntu를 설치해주어야 하는데, 이 과정에서는 micro sd카드와 micro sd카드 리더기가 필요하다.

raspberry pi imager를 다운로드 한다. raspberry pi imager를 설치한 후 실행해 다음과같이 선택해준다.

저장소는 micro sd카드를 micro sd card 리더기에 연결하여 pc 본체에 연결해주면 저장소 선택이 된다. 운영체제는 기존 컴퓨터에 설치된 버전과 맞춰주면 된다. 나는 22.04버전이 기존 컴퓨터에 설치되어있어서 동일하게 22.04버전으로 선택했다.

세부 설정을 이렇게 바꾸어주어야한다.

그런 후, 완료되었다고 나오면, sd카드를 raspberrypi에 연결해준다. 연결 후 전원 케이블을 뺏다 꽂아주면 초록 불이 깜빡거리며 바로 설치가 된다.

내부 네트워크설정으로 들어가 스크롤을 내려보면, 이렇게 자동할당 되어있는 raspberrypi의 ip주소를 확인할 수 있다.

그리고 putty를 설치해야한다. 동일하게 "putty"를 검색하여 최상단에 나오는 것을 다운로드 받은 후 실행하면 된다. 참고로, sd카드를 라즈베리파이에 삽입한 후 putty에 접속되기까지는 1-2분의 시간이 소요된다! hostname 부분에 아까 확인한 raspberrypi의 ip주소를 넣어준 후, open한다. accept를 하고, imager의 추가 설정에서 설정했던대로 로그인 해주면 된다. ubuntu로 로그인이 잘 되었다.

3️⃣ 물리 연결 Host에 VLAN 설정하기

이번에는 아래와 같이 라즈베리파이에 연결된 usb이더넷 어댑터에 연결되어있는 Host의 vlan을 설정해줄 것이다.

이를 위해서는 호스트에 vmware를 설치하고 ubuntu 22.04LTS 버전을 실행시켜주어야 한다. ubuntu 설치가 완료되었다면, Host1(노트북)의 ubuntu에 접근하여 라즈베리파이와 연결된 이더넷 장치를 확인한 후 vlan 설정을 해줄 것이다. 먼저 vlan을 설치하고, 802.1q모듈을 커널에 올린다. 먼저, 연결된 이더넷의 이름을 확인하기 위해 ip a 명령어를 이용한다. 여기에선 3번에 이더넷이 보인다. 그리곤, vlan을 생성해준다. 다시 ip a를 해보면 vlan이 확인된다.

물리 연결 Host의 인터페이스 vlan10을 조회해보면 아래와같이 ip주소가 20.0.0.1/24로 할당된 것을 확인할 수 있다. 라우팅 테이블을 확인해보았을 때도 20.0.0.0/24대역의 패킷을 보낼 때 vlan10 인터페이스를 이용하는 것을 확인할 수 있다.

4️⃣ 라즈베리파이 OVS 네트워크 구성하기

일단 라즈베리파이에 Open vSwitch(이하 OVS)를 설치해준다. 설치가 성공적으로 완료되었다면 아래와같이 OVS 설치버전이 조회된다.

br-int라는 브릿지를 하나 생성하자.

내가 사용하는 ONOS 2.7.0버전은 OpenFlow 1.0 및 1.3을 지원한다고 한다. 따라서, 해당 버전을 사용하도록 설정해준다. 이 설정을 하지 않을 경우 ONOS가 지원하는 OpenFlow버전과 일치하지 않아, OVS 브릿지 'br-int'가 ONOS와 연결 수립이 되지 않을 수 있다.

이렇게 생성됭 OVS 브릿지 br-int의 상태를 조회해보면 아래와 같이 br-int란 브릿지에 br-int라는 포트가 현재 생성된 상태임을 알 수 있다.

다음으로 생성한 br-int 브릿지에 포트를 생성해 라즈베리파이의 이더넷 포트(enxc84d4420046d)를 연결해준다.

이더넷 포트의 이름은 ip a명령어를 통해 확인했다.(2번에 이더넷 포트가 쓰여있다.)

5️⃣ OVS 브릿지에 ONOS 연결하기

ONOS가 OVS 브릿지 br-int에 연결되기 위해서는 ONOS와 OVS 브릿지 br-int가 동일한 네트워크 대역으로 묶여 서로 통신을 할 수 있어야 한다. 이를 위해 라즈베리파이에 접속하여 /etc/netplan 내부의 파일을 확인한다. 나는 50-cloud-init.yaml파일이 존재했다. 이는 다를 수 있으니 직접 확인해보아야 한다. 그리고, 이 파일을 다음과같이 수정해주어야 한다. 이 또한 라즈베리파이의 ip주소에 따라 다르니, 본인의 상황에 맞는 ip주소,대역 설정을 해주어야 한다.

network:
  version: 2
  renderer: networkd
  wifis:
    wlan0:
      dhcp4: no
      addresses:
        - 192.168.0.137/24  # 실제 무선 네트워크 IP
      gateway4: 192.168.0.1  # 공유기/라우터의 게이트웨이 IP
      nameservers:
        addresses:
          - 8.8.8.8  # Google DNS
      access-points:
        'Wi-Fi SSID':  
          password: "네트워크 비밀번호"

  bridges:
    br-int:
      interfaces:
        - wlan0  # 무선 네트워크 인터페이스를 브릿지에 연결
      dhcp4: no
      addresses:
        - 192.168.0.200/24  # 브릿지용 고정 IP (무선 네트워크와 같은 대역)
      gateway4: 192.168.0.1  # 공유기/라우터의 게이트웨이
      nameservers:
        addresses:
          - 8.8.8.8

• 브릿지용 고정 IP는 처음에 확인했듯이 사용중인 IP주소 정보를 보고, 사용하지 않는 IP로 해주어야 한다. 나의 경우 200은 사용중이지 않다.
• 공유기/라우터의 게이트 웨이 IP를 확인하는 방법은 다음과 같다. default에 쓰여있는 것이 게이트웨이 ip이다.

이렇게 netplan내부의 파일을 수정한 후 적용해준다.

지난번에 설치했던 onos를 실행해줄 것이다. 먼저, bazel을 이용해 onos를 실행해주어야 한다. 시간이 조금 걸리니, 마음을 편히 먹고 기다리자. 이렇게하면, 8101포트가 활성화된다. 다른 터미널을 열어서 다음과같이 확인할 수 있다. 접속이 되었다.

이후, ONOS GUI에 접근한다. 접근 주소는 다음과 같다.

http://{ONOS 설치 IP주소}:8181/onos/ui/index.html

6️⃣ 가상 HOST 설정하기

미니넷을 설치하여 접속한다. sudo mn --controller=remote,ip=192.168.224.128,port=6653 --switch=ovs,protocols=OpenFlow13 이 명령어를 통해 Mininet CLI로 접근할 수 있다. 참고로, 이 CLI에서 나오려면 exit을 치면 된다. 이번 실습에서는 host 하나만 필요하지만, 미니넷에서는 호스트 하나만 만드는게 불가하다. 컨트롤러와 스위치도 함께 만들어진다.

이제는 물리연결 HOST와의 ping을 위해 미니넷 호스트를 설정해야하는데, sudo ovs-vsctl set port h1-eth0 tag=10으로 한다.

7️⃣ Flow Rule 설정하기

현재 상태를 보면 라즈베리파이에서 br-int 브릿지가 있고, Mininet에 가상 스위치 s1과 가상 호스트 h1(10.0.0.1) 및 h2(10.0.0.2)가 생성된 상태이다. 또한 br-int에 실제 물리 네트워크 인터페이스가 연결되어 있다.

이제 호스트 간 ping 테스트를 위한 플로우 엔트리 설정을 위해 ONOS에 JSON 파일을 작성하여 플로우 규칙을 추가해야 한다. flow_h1_to_host2.json

{
  "flows": [
    {
      "priority": 40000,
      "timeout": 0,
      "isPermanent": true,
      "deviceId": "of:0000000000000001",
      "treatment": {
        "instructions": [
          {
            "type": "L2MODIFICATION",
            "subtype": "VLAN_PUSH",
            "vlanId": 10
          },
          {
            "type": "OUTPUT",
            "port": "enxc84d4420046d"
          }
        ]
      },
      "selector": {
        "criteria": [
          {
            "type": "ETH_TYPE",
            "ethType": "0x0800"
          },
          {
            "type": "VLAN_VID",
            "vlanId": 10
          },
          {
            "type": "IPV4_SRC",
            "ip": "10.0.0.1/32"
          },
          {
            "type": "IPV4_DST",
            "ip": "20.0.0.1/32"
          }
        ]
      }
    },
    {
      "priority": 40000,
      "timeout": 0,
      "isPermanent": true,
      "deviceId": "of:0000000000000001",
      "treatment": {
        "instructions": [
          {
            "type": "OUTPUT",
            "port": "s1-eth1"
          }
        ]
      },
      "selector": {
        "criteria": [
          {
            "type": "ETH_TYPE",
            "ethType": "0x0800"
          },
          {
            "type": "VLAN_VID",
            "vlanId": 10
          },
          {
            "type": "IPV4_SRC",
            "ip": "20.0.0.1/32"
          },
          {
            "type": "IPV4_DST",
            "ip": "10.0.0.1/32"
          }
        ]
      }
    }
  ]
}

deviceId: br-int 브릿지의 OpenFlow ID (onos> devices 명령어로 확인 가능). port: h1 -> br-int → Host2: 물리 포트(enxc8...)로 출력. Host2 -> br-int → h1: 가상 포트(s1-eth1 등)로 출력.

그리고 위에 작성한 json파일을 적용하는 명령어이다. onos에서 flows를 쳤을 때, br-int OpenFlowId부분을 확인해보면, priorty, deviceId, selector 등의 정보가 등록된 것을 확인할 수 있다.

❓ VLAN을 사용하는 이유?

VLAN(Virtual Local Area Network) 하나의 물리적 네트워크를 여러개의 가상 네트워크로 나누는 기술이다. 장비에 VLAN태그를 추가하여 특정 네트워크 트래픽을 격리하거나 구분함. VLAN태그를 통해 같은 네트워크 스위치를 이용하지만, 서로 다른 VLAN에 속한 장치들은 기본적으로 서로 통신할 수 없다.

현재 구성에서 VLAN을 사용한 이유는 가상 HOST에서 br-int(OVS)를 거쳐 물리 연결 HOST로 패킷이 이동할 때, 네트워크 환경을 VLAN 10으로 구분한다. 즉, VLAN 10 태그가 없는 트래핏은 해당 포트를 통과하지 못하는 것이다.

만일 호스트 간 패킷이 VLAN 태그 없이 전송되면, 다른 VLAN트래픽과 충돌하거나 의도치 않게 외부로 노출될 수 있다. 또한, OVS나 ONOS 플로우 설정에서 VLAN 태그를 필터링하지 않으면, 모든 패킷이 해당 경로로 전송될 수 있어 보안 및 네트워크 정책이 무너질 수 있다.

8️⃣ 실습 실패의 원인

flow rule까지 등록을 다 했는데, 결론은 ping테스트가 성공하지 못했다.

mininet으로 만든 가상 스위치인 s1과 라즈베리파이에서 만든 ovs인 br-int의 컨트롤러가 각각 존재했기 때문에 ONOS를 통한 패킷제어가 애초에 불가능했다.

기존의 블로그에서는 HOST 두 개와 라즈베리파이, ONOS를 설치한 컴퓨터 전부를 유선으로 연결하여 같은 대역에서 패킷제어를 시도했기 때문에 가능했던 것이었다.

나의 경우 라즈베리파이의 유선연결이 되지 않아, 무선연결로 수행했고, 준비했던 두 개의 Host 중 하나의 Host가 오래된 노트북이었어서 이더넷 선 연결을 인식하지 못하여 Host를 하나밖에 연결하지 못했다.

그럼에도 불구하고, 이번 실습을 통해 ONOS의 패킷 라우팅 구조와 원리에 대해 깊이있게 이해할 수 있게 되었다는 점에 있어서 큰 의의가 있었던 실습이라고 생각한다.

window 사용자 기준 Ubuntu를 실행하기 위한 가상머신이 필요합니다! 저는 vmware을 설치하여 사용했습니다.

그리고, Ununtu 22.04버전 이미지를 다운로드받아서, vmware에서 실행시켜주면 됩니다.

ONOS 설치 블로그 위 블로그를 참고하여 ONOS를 설치했습니다. 그대로 쭉 따라하시면 잘 설치 될겁니다! 저는 이렇게 설치가 잘 되었습니다.

ONOS CLI를 실행하는데, 먼저 컴퓨터의 IP주소를 알아야 해요!

ip route | grep default 

위 명령어를 통해 공유기의 IP주소를 확인했습니다. 저는 192.168.224.2 인 것으로 확인했습니다.

그 다음으로는 pc의 주소인데,

ip addr show 

위 명령어를 통해 192.168.224.128인 것을 확인했습니다.

그러면 이렇게 본인의 IP주소를 넣어 ONOS에 접속할 수 있습니다. 초기 비밀번호는 karaf입니다. -p 옵션은 포트번호를 지정합니다. 로컬인 클라이언트가 ONOS 컨트롤러로 SSH 연결을 시도할 때 서버의 8101포트를 통해서 SSH 요청을 보내도록 지정하는 것입니다. 즉, 나가는 포트는 랜덤한 동적 포트로 설정되지만, ONOS컨트롤러는 고정된 포트(여기서는 8101) 포트로 SSH 연결을 수신합니다.

이제는 가상 네트워크를 구성해서 OpenFlow 프로토콜을 기반으로 ONOS와 연결해볼 것입니다.

여기에서 OpenFlow는 SDN에서 사용하는 프로토콜입니다!

OpenFlow를 사용하기 위해서는 ONOS CLI로 접속하여 OpenFlow프로토콜을 지원하는 ONOS 애플리케이션인 'org.onosproject.openflow'를 활성화 해주어야 합니다. 다음과 같이 진행합니다. 두 번째로 친 명령어는 현재 실행중인 앱을 조회하는 명령어입니다. openflow 관련 애플리케이션들이 실행되는 것을 확인할 수 있습니다.

그리곤, 다른 터미널을 열어 apt-get을 이용해 mininet을 설치해주어야 합니다.

sudo apt-get install mininet

오픈소스 SW인 OpenFlow 기반의 가상 스위치를 제공해주는 Open vswitch(이하 OVS)도 패키지 관리도구인 apt-get으로 설치해줍니다.

sudo apt-get install openvswitch-switch

설치가 완료되면, mininet으로 1개의 OVS 스위치(s1)에 두 개의 가상 Host(h1,h2)와 ONOS 제어기(c0)가 연결되도록 가상네트워크를 구성하기 위해서

아까 확인했던 pc의 ip주소를 넣어 명령어를 실행시켜 주면 됩니다. 명령어의 옵션은 위와 같습니다.

명령어 실행 후, ONOS CLI에서 현재 ONOS와 연결된 스위치 정보를 조회해보면 OVS 스위치 1대가 ONOS와 연결이 되었음을 확인할 수 있습니다.

mininet cli에서 ping테스트를 해보면, 아직 flow rule을 설정하지 않아 서로 메시지를 주고받을 순 없다고 나옵니다.

Mininet으로 가상 네트워크 구조 파악하기

nodes 명령어를 통해 확인해보면, c0,h1,h2,s1 이렇게 4개의 Node가 생긴 것을 확인할 수 있습니다.

이러한 상황입니다. 여기에서 각 Node들의 interface정보들을 확인해보면,

• h1은 h1-eth0인터페이스에 IP주소 10.0.0.1 할당
• h2는 h2-eth0인터페이스에 IP주소 10.0.0.2 할당
• OVS 스위치 s1에는 eth1,eth2인터페이스 생성
• onos에 해당하는 node인 c0는 ip주소/포트 192.168.224.128/6653 dump와 net 명령어를 통해 더 자세히 확인할 수 있습니다. dump는 인터페이스 ip주소를 보여주고, net은 각 node들의 네트워크 인터페이스 별 연결정보를 알려줍니다. h1의 h1-eth0 인터페이스는 OVS 스위치 s1의 s1-eth1 인터페이스와 연결되고, 호스트 h2의 h2-eth0 인터페이스는 OVS 스위치 s1의 s1-eth2인터페이스와 연결되어있는 것을 확인할 수 있습니다. ONOS인 c0는 당연하게 OVS 스위치 s1과 local로 연결되므로, Mininet으로 살펴본 가상 네트워크 구성은 이러합니다.

ONOS가 바라본 가상 네트워크 구조 파악하기

ONOS가 바라보는 가상 네트워크 구조는 앞서 Mininet으로 파악한 가상 네트워크 구조와 동일하지만, ONOS는 직접 Flow Rule을 설정해주어야 하기 때문에 각 장치별 요소를 구분하기 위한 값이 Mininet을 통해 파악한 것과는 조금 다릅니다.

먼저 ONOS CLI로 접속하여 현재 연결된 OVS 스위치 정보를 조회해보면, Mininet에서는 s1이라는 노드로 표현되었지만, 여기서는 of:0000000000000001라는 고유의 장치 ID 값을 가집니다.

이번에는 hosts명령어를 통해 확인한 것입니다. locations=[of:0000000000000001/2]는 호스트 of:0000000000000001가 스위치의 2번포트에 연결되어있음을 의미합니다.

이 사진이 최종 연결구조입니다.

h1이 연결된 OVS 스위치(s1)의 s1-eth1 인터페이스는 1번 포트이고, h2가 연결된 s1-eth2는 2번 포트로 인식됨을 확인할 수 있습니다.

이제 이렇게 최종 확인된 가상 네트워크 구조를 가지고, ONOS의 Flow Rule 설정을 통해 두 Host 간 통신이 되도록 해볼 것입니다.

Flow Rule 설정하기 - reactive mode

Openflow 프로토콜에서는 flow rule 설정 방식이 두 가지 있습니다. 하나는 flow rule이 정의되지 않은 미지의 패킷이 SDN 스위치로 유입되었을 때, SDN 제어기에 의해 flow rule이 결정되는 reactive 모드이고, 다른 하나는 네트워크 관리자에 의하여 SDN 스위치에 미리 flow rule을 등록하는 proactive 모드입니다.

reactive모드를 실행하기 위해서는 ONOS CLI에서 org.onosproject.fwd애플리케이션을 실행시켜야 합니다. 이 애플리케이션은 packet-in메시지를 SDN 제어기인 ONOS로 보내도록 flow rule을 설정하여 ONOS가 reactive모드로 동작하도록 합니다. 명령어가 잘 실행되었습니다. mininet cli에서 다시 ping을 보내보면, 기존에는 안되던 h1과 h2의 ping이 성공적으로 잘 수행된 것을 확인할 수 있습니다. ONOS를 통해 직접 flow rule이 OVS 스위치 s1에 설정된 것입니다. ONOS CLI에서 flows 명령어를 통해 flow rule을 조회해보면 ADDED상태로 추가된 rule을 확인할 수 있습니다.

Flow Rule 설정하기 - Proactive 모드

이제부터는 ONOS에서 제공하는 REST API를 활용해서 Proactive모드로써 직접 Flow Rule을 설정해볼 것입니다. 일단 ONOS CLI에 접속하여 Reactive 모드를 테스트하기 위해 앞서 실행했던 org.onosproject.fwd를 비활성화해줍니다.

그리고 flow_rule_post.sh라는 스크립트 파일을 만들 것입니다. 이 스크립트 파일은 ONOS REST API를 이용해서 JSON파일로 정의된 Flow Rule을 해당 OVS 스위치에 설정하는 역할을 수행합니다. flow_rule_post.sh에는 아래 내용을 넣어주면 됩니다. 역시 IP주소는 바꾸어 넣어야 합니다.

ONOS_IP=192.168.224.128
ONOS_PORT=8181

curl -X POST --header "Content-Type: application/json" --header "Accept: application/json" -d @$1 "http://$ONOS_IP:$ONOS_PORT/onos/v1/flows/" --user karaf:karaf

이제 flow rule을 정의해볼 것입니다. h1에서 h2로 데이터를 보낼 수 있도록 OVS스위치 s1의 1번포트로 패킷이 들어오면 2번포트로 내보내라는 flow rule을 정의해볼 것입니다. 이를 위해 OVS 스위치 s1의 입력포트(IN_PORT)는 1번, 출력포트(OUTPUT)는 2번으로 지정된 flow rule을 5000이라는 우선순위를 적용하여 flow_h1_to_h2.json라는 JSON포맷 파일로 생성합니다.

{
  "flows": [
    {
      "priority": "50000",
      "timeout": 0,
      "isPermanent": true,
      "deviceId": "of:0000000000000001",
      "treatment": {
        "instructions": [
          {
            "type": "OUTPUT",
            "port": "2"
          }
        ]
      },
      "selector": {
        "criteria": [
          {
            "type": "IN_PORT",
            "port": "1"
          }
        ]
      }
    }
  ]
}

이번에는 반대로 h2에서 h1으로 데이터를 보낼 수 있도록 OVS스위치 s1의 2번 포트로 패킷이 들어오면 1번 포트로 내보내라는 Flow Rule을 정의해볼 것입니다. 이를 위해 OVS 스위치 s1 (of:0000000000000001) 의 입력포트 (IN_PORT) 는 2번, 출력포트 (OUTPUT) 는 1번으로 지정된 Flow Rule을 5000이라는 우선순위 (Priority) 를 적용해 'flow_h2_to_h1.json' 라는 JSON 포맷 파일로 생성합니다.

{
  "flows": [
    {
      "priority": "50000",
      "timeout": 0,
      "isPermanent": true,
      "deviceId": "of:0000000000000001",
      "treatment": {
        "instructions": [
          {
            "type": "OUTPUT",
            "port": "1"
          }
        ]
      },
      "selector": {
        "criteria": [
          {
            "type": "IN_PORT",
            "port": "2"
          }
        ]
      }
    }
  ]
}

편의를 위해 생성한 파일의 권한까지 변경해준 모습입니다.

JSON 파일로 정의한 Flow Rule 파일 (flow_h2_to_h1.json, flow_h2_to_h1.json) 들을 먼저 앞에서 작성한 flow_rule_post.sh 스크립트 파일을 이용하여, ONOS를 통해 OVS 스위치 s1 (of:0000000000000001) 로 Flow Rule 정보를 등록해줍니다. Flow Rule이 정상적으로 내려갔다면 스위치 s1의 Device ID와 등록한 Flow Rule의 ID 값이 출력됩니다.

./flow_rule_post.sh flow_h1_to_h2.json flow_h2_to_h1.json

./flow_rule_post.sh flow_h2_to_h1.json

ONOS CLI로 접근하여 실제 등록된 FlowRule정보를 확인해보면, 성공적으로 등록된 것을 확인할 수 있습니다. 이제 네트워크 구조를 도식화해보면 다음과 같습니다. 이 사진 역시 블로그에서 가져온 것이라 세부적 flow Id, c0 address, MAC address는 다릅니다. flow rule이 등록된 상태에서 mininet CLI를 통해 h1과 h2의 ping테스트를 해보면 성공적으로 수행되는 것을 확인할 수 있습니다.

먼저 h1에서 h2로 Ping 메시지를 보낼 경우, h1은 h2의 MAC 주소를 알아내기 위해 ARP 요청 메시지를 보내고, 해당 메시지는 OVS 스위치 s1의 1번포트로 전달됩니다. 이때 OVS 스위치 s1은 메시지의 처리를 위해 자신의 Flow Table에 등록된 Flow Rule을 찾아봅니다. Flow Table에서 입력포트 (IN_PORT) 가 1번인 Match Field가 일치하여, 해당 ARP 요청 메시지는 출력포트 (OUTPUT) 인 OVS 스위치 s1의 2번포트를 통해서 h2로 전달됩니다.

h1로부터 ARP 요청 메시지를 받은 h2는 자신의 MAC 주소를 포함한 ARP 응답 메시지를 보내고, 해당 메시지는 OVS 브릿지 s1의 2번포트로 전달됩니다. 이때 OVS 스위치 s1은 메시지의 처리를 위해 자신의 Flow Table에서 Flow Rule을 찾아봅니다. Flow Table에서 입력포트 (IN_PORT) 가 2번인 Match Field가 일치하여, 해당 ARP 응답 메시지는 출력포트 (OUTPUT) 인 OVS 스위치 s1의 1번포트를 통해서 h1로 전달됩니다.

h2로부터 ARP 응답 메시지를 전달받은 h1은 해당 메시지에 포함된 h2의 MAC 주소를 파악하고 해당 MAC 주소를 이용하여 ICMP 요청 메시지를 h2에 전달합니다. 이때 해당 메시지는 OVS 스위치 s1의 1번 포트로 제일 먼저 전달되며, OVS 스위치 s1은 메시지의 처리를 위해 자신의 Flow Table에 등록된 Flow Rule을 찾아봅니다. Flow Table에서 입력포트 (IN_PORT) 가 1번인 Match Field가 일치하여, 해당 ICMP 요청 메시지는 출력포트 (OUTPUT) 인 OVS 스위치 s1의 2번포트를 통해서 h2로 전달됩니다.

h1로부터 ICMP 요청 메시지(echo request)를 받은 h2는 이에 대한 응답으로 ICMP 응답 메시지(echo reply)를 생성해 h1으로 전달합니다. 이때 해당 메시지는 OVS 브릿지 s1의 2번포트로 먼저 전달됩니다. 그리고 OVS 스위치 s1은 메시지의 처리를 위해 자신의 Flow Table에서 Flow Rule을 찾아봅니다. Flow Table에서 입력포트 (IN_PORT) 가 2번인 Match Field가 일치하여, 해당 ARP 응답 메시지는 출력포트 (OUTPUT) 인 OVS 스위치 s1의 1번포트를 통해서 h1으로 전달됩니다.

여기까지 h1에서 h2로 Ping 메시지를 보내는 동안 OVS 스위치 s1에 등록된 Flow Rule이 어떻게 적용되어 데이터를 전달하는지 살펴보았습니다. h2에서 h1으로 Ping 메시지를 보내는 경우에도 마찬가지로 동일한 방식으로 Flow Rule이 적용되어 통신이 이루어집니다.

mininet이란

가상 네트워크를 통해 SDN이나 Openflow와 같은 네트워크 환경을 시뮬레이션 할 수 있는 오픈 소스 프로그램입니다. Mininet은 가상 스위치, 호스트를 사용해 네트워크를 시뮬레이션하는 소프트웨어로 SDN 및 Openflow와 같은 네트워크 프로토콜을 시험하고 개발하는 데 사용된다고 합니다. Mininet은 python기반으로 작성되었으며, 가상화 기술을 사용해 다중 사용자를 지원하고, 빠르고 쉽게 네트워크를 생성, 시험할 수 있습니다.

Mininet은 학술연구, 프로토타입 및 시스템 테스트, 교육 및 교육용 목적으로 사용됩니다. Mininet은 또한 Openflow 교육 및 SDN 프로토타입 개발 등의 목적으로도 사용됩니다.

mininet 사용해 네트워크 토폴로지 생성해보기.

mininet 설치

from mininet.net import Mininet
from mininet.cli import CLI
from mininet.node import Host
from mininet.node import OVSKernelSwitch
from mininet.log import setLogLevel, info

Mininet: 네트워크를 시뮬레이션하는 객체. CLI: Mininet의 명령어 인터페이스로 사용자가 명령을 입력할 수 있게 함. Host: 가상 호스트를 생성. OVSKernelSwitch: Open vSwitch 기반 스위치를 생성. setLogLevel: 로그 출력 레벨을 설정.

def myTopo():
    net = Mininet( topo=None, autoSetMacs=True, build=False, ipBase='10.0.1.0/24' )

net: Mininet 객체를 생성합니다. topo=None: 사용자 정의 토폴로지를 사용할 것을 의미합니다. autoSetMacs=True: 자동으로 MAC 주소를 설정합니다. build=False: 네트워크는 명시적으로 build() 메서드를 호출할 때까지 빌드되지 않습니다. ipBase='10.0.1.0/24': 호스트들이 사용할 기본 IP 주소 대역입니다.

h1 = net.addHost( 'h1', cls=Host, defaultRoute=None )
h2 = net.addHost( 'h2', cls=Host, defaultRoute=None )
h3 = net.addHost( 'h3', cls=Host, defaultRoute=None )
s1 = net.addSwitch( 's1', cls=OVSKernelSwitch, failMode='standalone' )

net.addHost: 네트워크에 호스트를 추가합니다. h1, h2, h3라는 이름의 호스트를 추가. net.addSwitch: 네트워크에 스위치를 추가합니다. s1이라는 이름의 스위치를 생성. failMode='standalone': 스위치가 컨트롤러 없이 독립적으로 동작합니다.

net.addLink(h1, s1)
net.addLink(h2, s1)
net.addLink(h3, s1)

호스트 h1, h2, h3를 스위치 s1과 연결합니다.

h1.setIP(intf="h1-eth0", ip='10.0.1.2/24')
h2.setIP(intf="h2-eth0", ip='10.0.1.3/24')
h3.setIP(intf="h3-eth0", ip='10.0.1.4/24')

각 호스트의 네트워크 인터페이스에 IP 주소를 설정합니다. 인터페이스 이름: h1-eth0, h2-eth0, h3-eth0. IP 주소:

• h1: 10.0.1.2/24
• h2: 10.0.1.3/24
• h3: 10.0.1.4/24

  net.build()
  net.start()

  build(): 네트워크를 빌드합니다. start(): 네트워크를 시작합니다.

  CLI(net)
  net.stop()

  CLI(net): Mininet 명령어 인터페이스를 시작합니다. 사용자가 명령을 입력해 네트워크 상태를 확인하거나 테스트할 수 있습니다. net.stop(): 네트워크를 종료합니다.

  if __name__ == '__main__':
    setLogLevel("info")
    myTopo()

  setLogLevel("info"): 로그 출력 레벨을 "info"로 설정. myTopo(): 위에서 정의한 네트워크 토폴로지 함수 실행.

pingall명령어를 통해 잘 연결되는 것을 확인할 수 있다.

1. EC2 생성
2. RDS 생성
3. Dockerfile 작성
4. github secrets에 환경변수 선언
5. github-actions.yml 코드 작성

EC2 생성과 RDS 생성은 자료들이 많을 것이라고 생성한다. 주의할 점은 같은 VPC 안에서 생성되어야하기 때문에 RDS 생성 시 기존에 생성해두었던 EC2를 지정해주어야 한다. 같은 VPC안에 있어야 서버에서 RDS를 찾아 생성할 수 있다.

1. EC2 생성

2. RDS 생성

3. DockerFile 작성

프로젝트의 루트 디렉토리 내에 생성하면 된다.

# 베이스 이미지: Java 17 (필요에 따라 Java 버전 변경 가능)
FROM openjdk:17-jdk-slim

# 컨테이너 내부의 작업 디렉토리 설정
WORKDIR /app

# 빌드된 JAR 파일을 컨테이너로 복사
COPY ./build/libs/*.jar app.jar

# 컨테이너에서 열릴 포트
EXPOSE 8080

# 애플리케이션 실행 명령어
ENTRYPOINT ["java", "-jar", "app.jar"]

4. github secrets 환경변수 선언

github actions를 이용할건데, github에 개인정보는 올리면 안되니까 환경변수를 이용한다. 아래의 github-actions.yml 코드 내부에 이용되는 것들을 환경변수로 미리 선언하는 것이다.

YML

YML
spring:
  application:
    name: forest
  profiles:
    group:
      dev: dev, local
      deploy: deploy
    active: dev

YML_DEV

spring:
  datasource:
    url: jdbc:mysql://<엔드포인트>:<포트번호>/<DB인스턴스식별자이름>
    username: <rds 생성 시 지정한 마스터사용자 이름>
    password: <rds 생성 시 지정한 마스터암호>
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: update
logging:
  level:
    org.hibernate.SQL: debug

hibernate: ddl-auto: update 데이터베이스 내부에 자동으로 테이블이 만들어지도록 하는 명령어이다. 이 코드를 써주지 않으면 actions파일을 실행시켰을 때 오류가 나므로 꼭 포함시켜주어야한다.

USERNAME

ubuntu

DOCKER_USERNAME

docker 가입할 때 지정한 사용자 이름

DOCKER_PASSWORD

docker 가입할 때 지정한 비밀번호

HOST_DEV

EC2로 할당받은 public IPv4 주소

PRIVATE KEY

ppk파일을 다운로드 했다면, 이를 cat명령어를 이용해 확인한 후, 키 부분을 떼어 위와같이 작성한 후 PRIVATE KEY 환경변수로 등록해준다.

5. github-actions.yml 코드 작성

먼저 루트 디렉토리 내부의 .github 패키지 내부에 workflows 패키지를 만들고, 그 안에 github-actions.yml 파일을 만든다. 나의 경우에는 dev를 실행하도록 코드를 작성했다.

# github repository actions 페이지에 나타날 이름
name: CI/CD using github actions & docker

# event trigger
# main브랜치에 push가 되었을 때 실행
on:
  push:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  CI-CD:
    runs-on: ubuntu-latest
    steps:

      # JDK setting - github actions에서 사용할 JDK 설정 (프로젝트나 AWS의 java 버전과 달라도 무방)
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      # gradle caching - 빌드 시간 향상
      - name: Gradle Caching
        uses: actions/cache@v3
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
          restore-keys: |
            ${{ runner.os }}-gradle-
      # 권한 부여
      - name: Add execution permissions to Gradle Wrapper
        run: chmod +x ./gradlew

      # 환경별 yml 파일 생성(1) - application.yml
      - name: make application.yml
        if: |
          contains(github.ref, 'main')
        run: |
          mkdir ./src/main/resources # resources 폴더 생성
          cd ./src/main/resources # resources 폴더로 이동
          touch ./application.yml # application.yml 생성
          echo "${{ secrets.YML }}" > ./application.yml # github actions에서 설정한 값을 application.yml 파일에 쓰기
        shell: bash

      # 환경별 yml 파일 생성(2) - dev
      - name: make application-dev.yml
        run: |
          cd ./src/main/resources
          touch ./application-dev.yml
          echo "${{ secrets.YML_DEV }}" > ./application-dev.yml
        shell: bash




      # gradle build
      - name: Build with Gradle
        run: ./gradlew build -x test


      # docker build & push to develop
      - name: Docker build & push to dev
        run: |
          docker login -u ${{ secrets.DOCKER_USERNAME }} -p ${{ secrets.DOCKER_PASSWORD }}
          docker build -f Dockerfile-dev -t ${{ secrets.DOCKER_USERNAME }}/docker-test-dev .
          docker push ${{ secrets.DOCKER_USERNAME }}/docker-test-dev



      ## deploy to develop
      - name: Deploy to dev
        uses: appleboy/ssh-action@master
        id: deploy-dev
        with:
          host: ${{ secrets.HOST_DEV }} # EC2 퍼블릭 IPv4 DNS
          username: ${{ secrets.USERNAME }} # ubuntu
          password: ${{ secrets.PASSWORD }}
          port: 22
          key: ${{ secrets.PRIVATE_KEY }}
          script: |
            port=8080
            echo "Checking for containers using port $port..."

            # Find the container ID using the specified port
            container_id=$(docker ps --filter "publish=$port" --format "{{.ID}}")

            if [ -n "$container_id" ]; then
              echo "Found container with ID: $container_id. Stopping it..."
              docker stop "$container_id"
              docker rm "$container_id"
              echo "Container stopped successfully."
            else
              echo "No container is using port $port."
            fi
            sudo docker ps
            sudo docker pull ${{ secrets.DOCKER_USERNAME }}/docker-test-dev
            sudo docker run --name team-18 -d -p 8080:8080 ${{ secrets.DOCKER_USERNAME }}/docker-test-dev

application.yml코드 작성

spring:
  application:
    name: <애플리케아션 이름>
  profiles:
    group:
      dev: dev, local
      deploy: deploy
    active: dev

💻 코드 설명

• spring.application
  • name Spring Boot 애플리케이션의 이름을 지정하는데 사용된다. 지정된 이름은 주로 로그 출력, Spring Cloud 환경에서 서비스 식별, 그리고 애플리케이션 상태 모니터링 등 여러 곳에서 활용된다. 로깅에 표시되는 예시는 다음과같다. 예를들어 애플리케이션 이름을 "hyeondooori"로 했다면 2024-11-22 12:00:00.000 INFO 12345 --- [ main] hyeondooori.Application : Started Application in 5.123 seconds (JVM running for 5.678)
• spring.profiles
  • group 프로파일 그룹을 정의한다. dev그룹은 dev와 local프로파일이 함께 활성화되고, deploy그룹은 deploy 프로파일만 활성화된다. 이를통해 여러 프로파일일을 하나의 그룹으로 묶어서 사용할 수 있다.
  • active 현재 활성화된 프로파일을 지정한다. 여기서는 dev프로파일이 활성화된 상태이다.

💻동작 방식

1. spring.profiles.active에 따라 프로파일 로드

• active: dev 설정에 따라 application-dev.yml 또는 dev 관련 설정이 로드된다.

2. 그룹 활성화

• dev 프로파일이 활성화되면, 그룹 설정에 따라 dev와 local 두 프로파일의 설정이 모두 적용된다.

3. 우선순위

• 기본설정(application.yml) -> 활성화된 프로파일(application-dev.yml 또는 application-deploy.yml) 순서로 설정이 병합된다.
• 동일한 키가 중복되면, 활성화된 프로파일의 설정이 우선된다.

  개발 환경에 따라 application.yml 내부의 spring.profiles.active를 변경하여 활성되는 프로파일을 변경할 수 있다. 로컬환경에서 작업할 때는 active를 local로 하고, 개발환경에서는 dev로 하는 방식!

❓AWS 서버에서의 Docker Desktop

로컬에서 Docker컨테이너를 실행하려면 Docker Desktop이 실행중이어야만 했다. 이는 Windows나 Mac과 같은 운영체제에서 Docker engine을 실행하는데 필요하다.

하지만, AWS에서 실행되는 Docker는 해당 서버(AWS 인스턴스)에 설치된 Docker engine 위에서 동작한다. 이 Docker engine은 AWS 서버 자체에서 관리되며, 로컬 Docker Desktop과는 전혀 관계가 없다.

AWS에서 퍼블릭IP를 할당받은 인스턴스(AWS EC2 등)에서 Docker컨테이너를 실행했다면:

• docker 컨테이너는 AWS 인스턴스 내에서 자체적으로 동작한다.
• 퍼블릭 IP를 통해 외부에서 접근할 수 있다.

컨테이너 실행 유지 조건

1. AWS EC2 인스턴스가 계속 실행 중이어야 한다. EC2가 중지되면, Docker 컨테이너도 중단된다.
2. Docker 컨테이너가 백그라운드에서 실행중이어야한다. 컨테이너를 실행할 때 -d(detached mode)옵션을 사용하여 컨테이너를 백그라운드에 유지한다. docker run -d -p 3306:3306 --name mysql-container -e MYSQL_ROOT_PASSWORD=<password> mysql

1. 실행 설정 (Run Configuration 확인)

• IntelliJ IDEA의 Run Configuration에 정의된 설정을 기반으로 애플리케이션을 실행합니다.
• 기본적으로 Spring Boot 프로젝트에서는 다음을 설정할 수 있습니다:
  • 실행할 클래스: 예를 들어 @SpringBootApplication이 포함된 메인 클래스.
  • 활성화할 프로파일: spring.profiles.active 값을 설정 가능.
  • JVM 옵션 및 환경 변수 설정 가능.

Run Configuration 설정 확인 방법

• IntelliJ 메뉴에서 Run > Edit Configurations를 클릭.
• 실행하려는 Run Configuration을 선택하여 실행 환경을 확인하고 수정할 수 있습니다.

2. Maven/Gradle 빌드 과정

Spring Boot 프로젝트에서는 실행 전에 Maven 또는 Gradle 빌드 작업이 수행됩니다.

1. 프로젝트 컴파일:

   • 소스 코드(Java/Kotlin)를 컴파일하여 .class 파일을 생성.
   • 컴파일된 파일은 기본적으로 /target/classes(Maven) 또는 /build/classes/java/main(Gradle) 디렉토리에 저장.

2. 의존성 확인 및 다운로드:

   • Maven 또는 Gradle이 pom.xml 또는 build.gradle 파일을 읽어 프로젝트에 필요한 라이브러리 의존성을 확인.
   • 누락된 라이브러리가 있다면, 원격 저장소에서 자동으로 다운로드.

3. Spring Boot 애플리케이션 실행 파일 생성:

   • Gradle/Maven에 의해 빌드된 .jar 또는 .war 파일이 생성됩니다(필요한 경우).

3. JVM 실행

빌드가 완료된 후, IntelliJ는 Java Virtual Machine(JVM)을 실행하여 애플리케이션을 시작합니다.

1. 메인 클래스 실행:

   • Spring Boot 애플리케이션에서는 기본적으로 @SpringBootApplication이 정의된 클래스(보통 Application.java)가 실행됩니다.
   • 이 클래스는 내부적으로 SpringApplication.run() 메서드를 호출하여 애플리케이션을 부트스트랩(초기화)합니다.

   예:

   @SpringBootApplication
   public class Application {
       public static void main(String[] args) {
           SpringApplication.run(Application.class, args);
       }
   }

2. JVM 옵션 적용:

   • Run Configuration에서 설정된 JVM 옵션이 적용됩니다. 예: -Xmx1024m 같은 메모리 관련 설정.

3. 환경 변수 적용:

   • Run Configuration에서 정의한 환경 변수도 JVM에 전달됩니다.
   • 예: spring.profiles.active=dev

4. Spring Boot 애플리케이션 초기화

Spring Boot 애플리케이션이 JVM 위에서 실행되며 초기화 과정을 거칩니다:

1. Spring 컨텍스트 초기화:

   • ApplicationContext가 생성되고, 모든 빈(Bean)이 초기화됩니다.
   • @Component, @Service, @Repository 등의 애너테이션으로 정의된 클래스가 빈으로 등록됩니다.

2. 외부 설정 로드:

   • application.yml, application.properties, 또는 환경 변수에서 설정 값을 읽어옵니다.
   • 활성화된 프로파일(spring.profiles.active)에 따라 추가 설정을 병합합니다.

3. 내장 웹 서버 실행:

   • Spring Boot 프로젝트는 기본적으로 내장형 웹 서버(Tomcat, Jetty 등)를 사용합니다.
   • 내장 웹 서버가 지정된 포트(기본값: 8080)에서 시작됩니다.

4. 애플리케이션 실행 준비 완료:

   • 초기화가 완료되면 로그에 Started Application in [time] seconds 메시지가 표시됩니다.
   • 이 시점에서 애플리케이션이 요청을 받을 준비가 됩니다.

5. IntelliJ에서 로그 출력

IntelliJ IDEA의 Run 창에 애플리케이션 로그가 출력됩니다:

• Spring Boot 로고와 버전 정보.
• 로드된 설정 파일(application.yml 또는 application.properties).
• 초기화된 빈(Bean) 목록.
• 내장 웹 서버가 시작된 포트 정보.

예:

2024-11-22 10:00:00.000  INFO 12345 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port(s): 8080 (http)
2024-11-22 10:00:00.000  INFO 12345 --- [           main] com.example.Application                  : Started Application in 5.123 seconds (JVM running for 5.678)

6. 애플리케이션 실행 중 동작

• 애플리케이션이 실행되면서 HTTP 요청을 수신하고, Controller, Service, Repository 계층이 동작.
• 로컬에서 실행 중인 애플리케이션에 접근하려면 브라우저나 Postman 등을 사용하여 다음 URL에 접근:

  http://localhost:8080

7. 정리

IntelliJ IDEA에서 Run 버튼을 누르면 아래 과정이 실행됩니다:

1. Run Configuration을 기반으로 애플리케이션 실행 설정 확인.
2. Maven/Gradle 빌드로 소스 코드 컴파일 및 의존성 다운로드.
3. JVM 실행 및 main() 메서드 실행.
4. Spring Boot 초기화:
   • 빈 등록, 설정 파일 로드, 내장 웹 서버 시작.
5. 애플리케이션 시작 및 로그 출력.

이 과정을 통해 로컬에서 Spring Boot 애플리케이션이 실행되고, 브라우저를 통해 접근할 수 있는 상태가 됩니다.

스프링의 요청 처리 과정

Spring이 요청에 대한 처리를 어떤 흐름으로 진행하는지에 대한 그림이다.

1. 클라이언트의 요청을 디스패처 서블릿이 받음.
2. 요청 정보를 통해 요청을 위임할 컨트롤러 찾음
3. 요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아 전달함.
4. 핸들러어댑터가 컨트롤러로 요청을 위임함.
5. 비즈니스 로직을 처리함.
6. 컨트롤러가 반환값을 처리함.
7. 핸들러어댑터가 반환값을 처리함.
8. 서버의 응답을 클라이언트로 반환함.

• Dispatcher-Servlet 디스패처 서블릿의 dispatch는 "보내다"라는 뜻을 가지고 있다. 그리고 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(front Controller)라고 정의할 수 있다. 클라이언트로부터 어떤 요청이 오면 톰캣(Tomcat)과 같은 서블릿 컨테이너가 요청을 받게된다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게된다. 그러면 디스패처 서블릿은 공통작업을 먼저 처리한 후 해당 요청을 처리해야하는 컨트롤러를 찾아 작업을 위임한다. 여기서 프런트 컨트롤러(front controller)라는 용어가 사용되는데, Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아 처리해주는 컨트롤러로서, MVC 구조에서 함께 사용되는 디자인 패턴이다. 과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했지만, dispatcher-servlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링해주고 공통 작업을 처리면서 상당히 편리하게 이용할 수 있게 되었습니다. 우리는 컨트롤러를 구현해두기만 하면 디스패처 서블릿가 알아서 적합한 컨트롤러로 위임을 해주는 구조가 되었습니다.

❓ 만약 Controller에서 로직을 처리하던 중 예상치못한 에러가 발생한다면 어떻게될까?

스프링의 기본적인 예외 처리 방법

이와같은 컨트롤러의 getProduct에서 NoSuchElementFoundException 예외가 발생했다면 우리는 접속한 환경에 따라 다른 에러처리를 받게 된다. 만약 웹페이지로 접속했다면 Whitelabel Error Page를 반환받게된다.

Spring은 만들어질 때부터 에러처리를 위한 BasicErrorController를 구현해두었고, 스프링 부트는 예외가 발생하면 기본적으로 /error로 에러 요청을 다시 전달하도록 WAS 설정을 해두었다.

WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로서 웹 서버 단독으로는 처리할 수 없는 데이터베이스의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다. 대표적인 WAS 종류: Tomcat WAS에 대한 더욱 자세한 설명은! ->CLICK!!

그래서 별도의 설정이 없다면 예외 발생 시에 BasicErrorController로 에러 처리 요청이 전달된다. 참고로 이는 스프링 부트의 WebMvcAutoConfiguration을 통해 자동 설정이 되는 WAS의 설정이다. 여기서 요청이 /error로 다시 전달된다는 부분에 주목해야한다. 일반적인 요청 흐름은 다음과 같이 진행된다. WAS(톰캣) -> 필터 -> 서블릿(디스패처 서블릿) -> 인터셉터 -> 컨트롤러 그리고 컨트롤러 하위에서 예외가 발생했을 때, 별도의 예외 처리를 하지 않으면 WAS까지 에러가 전달된다. 그러면 WAS는 애플리케이션에서 처리를 못하는 예외라 exception이 올라왔다고 판단을 하고 대응 작업을 진행한다. 컨트롤러(예외발생) -> 인터셉터 -> 서블릿(디스패처 서블릿) -> 필터 -> WAS(톰캣)

WAS는 스프링 부트가 등록한 에러 설정(/error)에 맞게 요청을 전달하는데, 이러한 흐름을 총 정리하면 다음과 같다. WAS(톰캣) -> 필터 -> 서블릿(디스패처 서블릿) -> 인터셉터 -> 컨트롤러 -> 컨트롤러(예외발생) -> 인터셉터 -> 서블릿(디스패처 서블릿) -> 필터 -> WAS(톰캣) -> WAS(톰캣) -> 필터 -> 서블릿(디스패처 서블릿) -> 인터셉터 -> 컨트롤러(BasicErrorController)

기본적인 에러 처리 방식은 결국 에러 컨트롤러를 한 번 더 호출하는 것이다. 그러므로 필터나 인터셉터가 다시 호출될 수 있는데, 이를 제어하기 위해서는 별도의 설정이 필요하다.

서블릿은 dispatcherType으로 요청의 종류를 구분하는데, 일반적인 요청은 REQUEST이며 에러 처리 요청은 ERROR이다. 필터는 서블릿 기술이므로 필터등록(FilterRegistrationBean) 시에 호출될 dispatcherType 타입을 설정할 수 있고, 별도의 설정이 없다면 REQUEST일 경우에만 필터가 호출된다. 하지만, 인터셉터는 스프링 기술이므로 dispatcherType을 설정할 수 없어 URI 패턴으로 처리가 필요하다. 스프링 부트에서는 WAS까지 직접 제어하게 되면서 이러한 WAS의 에러 설정까지 가능해졌다. 또한 이는 요청이 2번 생기는 것은 아니고, 1번의 요청이 2번 전달되는 것이다. 그러므로 클라이언트는 이러한 에러 처리 작업이 진행되었는지 알 수 없다.

BasicErrorController

BasicErrorController는 accept헤더에 따라 에러 페이지를 반환하거나 에러 메시지를 반환한다. 에러 경로는 기본적으로 /error로 정의되어있으며 properties에서 server.error.path로 변경할 수 있다.

errorHtml()과 errer()는 모두 getAttributeOptions를 호출해 반환할 에러 속성을 얻는데, 기본적으로 DefaultErrorAttributes로부터 반환할 정보를 가져온다. DefaultErrorAttributes는 전체 항목들에서 설정에 맞게 불필요한 속성들을 제거한다.

• timestamp: 에러가 발생한 시간
• status: 에러의 http상태
• error: 에러코드
• path: 에러가 발생한 uri
• exception: 최상위 예외 클래스의 이름(설정 필요)
• message: 에러에 대한 내용(설정 필요)
• errors: BindingException에 의해 생긴 에러 목록(설정 필요)
• trace: 에러 스택 트레이스(설정 필요)

위는 기본 설정으로 받는 에러 응답이다. 나름 잘 갖추어져 있지만 클라이언트 입장에서 유용하지 못하다. 클라이언트는 "Item with id 5000 not found"라는 메시지와 함께 404 status로 에러 응답을 받으면 훨씬 유용할 것이다. 다음과 같이 properties를 통해 에러 응답을 조정할 수 있다. 물론 운영 환경에서 구현이 노출되는 trace는 제공하지 않는 것이 좋다.

참고로 SpringBoot 2.3 이전에는 message를 기본적으로 제공했었지만, SpringBoot 2.3부터는 클라이언트에게 너무 많은 정보가 노출되는 것을 방지하기 위해 기본적으로 제공하지 않게 되었다.

스프링이 제공하는 다양한 예외 처리 방법

JAVA에서는 예외 처리를 위해 try-catch를 사용해야 하지만 try-catch를 모든 코드에 붙이는 것은 비효율적이다. Spring은 에러 처리라는 공통 관심사(cross-cutting concerns)를 메인 로직으로부터 분리하는 다양한 예외 처리 방식을 고안했고, 예외 처리 전략을 추상화한 HandlerExceptionResolver 인터페이스를 만들었다. (전략 패턴이 사용된 것이다.)

대부분의 HandlerExceptionResolver는 발생한 Exception을 catch하고 HTTP상태나 응답메시지 등을 설정한다. 그래서 WAS입장에서는 해당 요청이 정상적인 응답인 것으로 인식되며, 위에서 설명한 복잡한 WAS의 에러 전달이 진행되지 않는다.

위의 Object 타입인 handler는 예외가 발생한 컨트롤러 객체이다. 예외가 던져지면 디스패처 서블릿까지 전달되는데, 적합한 예외처리를 위해 HandlerExceptionResolver구현체들을 빈으로 등록해서 관리한다. 그리고 적용 가능한 구현체를 찾아 예외를 처리하는데, 우선순위대로 아래의** 4가지 구현체**들이 빈으로 등록되어있다.

• DefaultErrorAttributes: 에러 속성을 저장하며 직접 예외를 처리하지 않는다.
• ExceptionHandlerExceptionResolver: 에러 응답을 위한 Controller나 ControllerAdvice에 있는 ExceptionHandler를 처리한다.
• ResponseStatusExceptionResolver: Http상태코드를 지정하는 @ResponseStatus 또는 ResponseStatusException을 처리한다.
• DefaultHandlerExceptionResolver: 스프링 내부의 기본 예외들을 처리한다.

Spring에서 ExceptionResolver를 동작시켜 에러를 처리할 때 사용하는 도구들을 살펴보자. ExceptionHandler, RestControllerAdvice의 두 개가 있다. ResponseStatusException의 한계점들을 보완해준 방식들이라 이것들을 사용한다.

ResponseStatusException의 한계점

• 직접 예외처리를 프로그래밍하므로 일관된 예외처리가 어려움
• 예외처리 코드가 중복될 수 있음
• Spring 내부의 예외를 처리하는 것이 어려움
• 예외가 WAS까지 전달되고, WAS의 에러 요청 전달이 진행됨

@ExceptionHandler

• 매우 유연한 에러처리 제공
• 에러 응답(payload)자유롭게 다룰 수 있음.
• 컨트롤러의 메소드에 해당 어노테이션을 적용할 수 있는데, 이는 전역적으로 사용할 수 없다. 전역적인 사용을 위해서는 @RestControllerAdvice 또는 @ControllerAdvice 애노테이션을 사용해야 한다.

@RestControllerAdvice

• Spring 4.3부터 제공하는 애노테이션
• @ExceptionHandler를 전역적으로 사용할 수 있도록 도와줌
• @ControllerAdvice와의 차이점은 에러응답을 JSON으로 내려준다는 것이다.
• 사용방법: 애노테이션을 적용해 전역적으로 에러를 핸들링하는 class를 만들어 사용한다.(에러처리 위임)

출처: https://mangkyu.tistory.com/18 [MangKyu's Diary:티스토리] 출처: https://mangkyu.tistory.com/204 [MangKyu's Diary:티스토리]

먼저,

Node.js 앱이란?

Node.js 앱은 Node.js 런타임 환경에서 실행되는 애플리케이션이다. Node.js는 자바스크립트(JavaScript)코드를 서버 측에서도 실행할 수 있게 만들어주며, 주로 웹 서버, API서버, 또는 백엔드 애플리케이션을 개발하는 데 사용된다.

일반적으로 Node.js앱은 자바스크립트코드, 패키지관리(package.json), 주요 프레임워크(Express.js)로 구성된다.

1. JavaScript 코드 Node.js는 자바스크립트를 사용하여 서버 기능을 구현할 수 있다. 기본적인 웹 서버나 데이터베이스 연결, 파일 시스템 제어 등을 모두 자바스크립트로 작성할 수 있다.
2. 패키지 관리 Node.js앱에서는 npm(Node Package Manager)을 통해 다양한 라이브러리와 모듈을 설치하고 관리한다. package.json파일에 의존성 정보가 저장되어 있어 필요한 라이브러리들을 손쉽게 설치하고 관리할 수 있다.
3. 주요 프레임워크 Node.js 앱에서 가장 널리 사용되는 웹 프레임워크는 Express.js이다. Express는 웹 서비스나 RESTful API를 쉽게 구축할 수 있도록 해준다. 예를 들어, Express를 사용하면 클라이언트의 요청을 처리하고 응답을 반환하는 웹 서버를 간단하게 만들 수 있다.

Node.js 앱을 만드는데 필요한 두 가지 파일

1. package.json 프로젝트의 정보와 프로젝트에서 사용 중인 패키지의 의존성을 관리하는 곳이다. npm init 명령어를 사용해 만들 수 있다. (Node.js와 WSL설치가 되어있어야한다!) dependencies의 express부분을 추가한 이유는 Node.js를 더욱 쉽고 유용하게 사용할 수 있도록 하기 위함이다. Javascript와 jQuery의 관계처럼 Node.js의 API를 단순화하고 새로운 기능을 추가해준다.

2. server.js Node.js에서 진입점이 되는 파일이다. const express = require('express'); : express 모듈 불러온다. const PORT = 8080; : express 서버를 위한 포트 설정 const app = express(); : 새로운 express어플 생성 app.get('/',(req,res)=>{ res.send("Hello World") }); : "/" 이 경로로 요청이 오면 Hello World를 결과값으로 전달 app.listen(PORT);: 해당 포트에서 HTTP서버를 시작

이렇게 두 파일을 이용해 기본적인 Node.js애플리케이션을 완성했다. 이제 이 Node.js 앱을 도커 환경에서 실행하기 위해서 도커와 관련된 부분을 만들어야한다.

Dockerfile 작성하기

Node.js앱을 도커 환경에서 실행하려면 먼저 이미지를 생성하고 그 이미지를 이용해서 컨테이너를 실행한 후 그 컨테이너 안에서 Nodejs앱을 실행해야한다. 그래서 그 이미지를 먼저 생성하려면 Dockerfile을 먼저 작성해야한다. FROM,RUN,CMD에 명시한 것 각각이 무엇인지는 밑에서 차차 설명할 예정이다.

alpine 베이스 이미지 대신 node이미지 사용하는 이유?

alpine으로 하면 npm not found 오류가 나는 것을 확인할 수 있다. 그 이유는 alpine이미지는 가장 최소한의 경량화된 파일들이 들어있기에 npm을 위한 파일이 들어있지 않아서 RUN부분에 npm install을 할 수가 없다. 알파인 이미지의 사이즈는 5MB정도밖에 안된다. 그래서 이미지 사이즈가 더 큰 node를 사용해야 오류가 발생하지 않는다.

npm install?

• npm은 Node.js로 만들어진 모듈을 웹에서 받아서 설치하고 관리해주는 프로그램이다.
• npm install은 package.json에 적혀있는 종속성들을 웹에서 자동으로 다운받아 설치해주는 명령어이다.
  • 그러니까, package.json내부의 dependencies를 설치해주는 역할!
• 결론적으로는 현재 Node.js앱을 만들 때 필요한 모듈들을 다운받아 설치하는 역할을 한다.

CMD 안의 "node","sever. js"?

• 노드 웹 서버를 작동시키려면 "node"와 "엔트리 파일 이름"을 입력해야 한다.

이제, 만들어둔 Dockerfile을 docker build .으로 실행시켜보면 오류가 나는 것을 확인할 수 있다.

오류 화면을 보면, RUN npm install 부분에서 오류가 발생한다. 원인이 무엇일까?

이미지를 빌드할 때 package.json 파일이 없다고 나오는 이유

지금 우리는 docker의 이미지를 만들고 있다. 이미지를 만들 때에는 Node 베이스 이미지를 통해 임시 컨테이너를 만든 다음에 임시 컨테이너로 실제 사용할 이미지를 만드는 것이다. 베이스 이미지에는 파일 스냅샷이 존재한다. 그래서 그것을 하드디스크에 넣어주고, RUN에 있는 npm install을 하게 된다. RUN은 추가적으로 필요한 파일들을 다운로드 받는 역할을 한다. RUN에 쓴 npm install은 package.json파일에 명시된 모든 패키지를 설치하는 역할을 수행한다. Node.js 프로젝트에서는 package.json 파일에 의존성 정보가 포함되어 있으며, npm install을 실행하면 해당 의존성들이 node_modules 폴더에 설치됩니다.

그러나, package.json이 컨테이너의 밖에 존재하여 파일을 보고 설치하는 것이 불가능하다.

그 이유는 Node 베이스 이미지의 스냅샷이 임시 컨테이너의 하드디스크로 들어오게 되는데, Node 베이스 이미지의 스냅샷에는 두 파일이 없기 때문이다.

아래의 사진을 보면 이 말을 더욱 잘 이해할 수 있다.

그렇다면, 이 문제를 어떻게 해결해야할까?

COPY를 이용해 Package.json을 컨테이너 안으로 넣어주기

Dockerfile내부에 COPY를 적은 뒤, docker build -t <docker account>/<앱 이름>을 통해 실행시켜보았다. 빌드가 잘 되는 것을 확인할 수 있다.

이제 run을 시켜볼건데, 잘 되는지 확인해보기 위해 이렇게 콘솔 로그를 server.js에 넣어주었다. 그리고 다시 빌드시킨 후 run해보면, 이렇게 잘 실행되는 것을 확인할 수 있다.

하지만, localhost:8080주소로 가보면, 실행이 되지 않은 것을 확인할 수 있다.

생성한 이미지로 애플리케이션 실행 시 접근이 안 되는 이유(포트 매핑)

위에서 컨테이너를 실행하기 위해 사용한 명령어는 다음과 같다.

여기에서 추가해야할 부분이 있다.

이미지를 만들 때 로컬에 있던 파일(package.json)등을 컨테이너에 복사해주어야했다. 그것과 유사하게 네트워크도 로컬 네트워크에 있던 것을 컨테이너 내부에 있는 네트워크에 연결을 시켜주어야한다.

브라우저에서 5001번 포트로 접속하고, 컨테이너 내부에서 컨테이너 속 8080포트로 접근하는 방식이다.

이제 hello world가 잘 보이는 것을 확인할 수 있다!

WORKING DIRECTORY 명시해주기

도커 파일에 WORKDIR이라는 부분을 추가해주어야 한다.

이미지 안에서 애플리케이션 소스 코드를 가지고 있을 디렉터리를 생성하는 것이다. 그리고 이 디렉터리가 애플리케이션에 working directory가 된다.

그런데, 왜 따로 working directory가 있어야할까? 현재 만들어놓은 이미지의 Root 디렉토리를 살펴보기 위해 docker run -it <이미지이름> sh 명령어를 사용했고, 그 터미널 안에서 ls 명령어를 입력했다. 여기 파일 중에서 COPY를 해서 컨테이너 안으로 들어온 것들은 다음과 같다.

• Dockerfile
• package.json
• package-lock.json
• node_module 이렇게 workdir을 지정하지 않고 그냥 COPY할 때 생기는 문제점

1. 원래 이미지에 있던 파일과 이름이 같다면? 예를 들어, 베이스 이미지에 이미 home이라는 폴더가 있고 COPY를 함으로써 새로 추가되는 폴더 중에 home이라는 폴더가 있다면 중복이 되므로 원래 있던 폴더가 덮어씌워져버린다.
2. 모든 파일이 한 디렉토리 내부에 들어가게 되어 정돈이 되어있지 않아 식별이 어렵다.

그래서 모든 어플리케이션을 위한 소스들은 WORK 디렉토리를 따로 만들어서 보관한다.

Dockerfile에 WORKDIR을 추가시켰다.

처음 ls를 실행한 결과에 COPY된 것들만 존재한다. 그 이유는 WORKDIR을 지정하면 root가 아니라 WORKDIR로 가게 되기 때문이다. 따라서 처음 ls실행환경이 WORKDIR로 지정했던 /usr/src/app인 것이다. 그 후, cd /를 통해 root로 가서 ls를 치면, 원래 존재하는 다른 디렉토리들이 있는 것을 확인할 수 있다.

애플리케이션 소스 변경 시 재빌드 문제점

어플리케이션을 만들다보면 소스 코드를 계속 변경시켜주어야하며 그에따라 변경된 부분을 확인하면서 개발을 해나가야한다. 그래서 도커를 이용해 어떻게 실시간으로 소스가 반영되게 하는지 알아본다.

현재까지 만든 어플을 소스 변경 시 변경된 소스를 반영시켜주기 위해서는 현재까지 도커 컨테이너로 어플을 실행한 순서를 보면

그러면, 이러한 비효율적인 부분을 어떻게 해결할까?

애플리케이션 소스 변경으로 재 빌드 시 효율적으로 하는 법

위의 도표를 보면, 완성본 Dockerfile에는 RUN 위에 COPY package.json ./이 하나가 추가되고 원래의 COPY가 RUN 아래로 내려갔다.

그 이유는 무엇일까? npm install할 때 불필요한 다운로드를 피하기 위해서이다. 코드 변경이 있을 때 문제점) COPY ./ ./ 명령어로 모든 파일을 복사하게 되면, 작은 소스 코드 변경이 있어도 Docker는 npm install 단계 이전의 모든 캐시를 무효화하고, 모듈을 다시 다운로드하게 된다.

그래서 npm install 단계 전에는 의존성파일(package.json)만 COPY해서 필요한 모듈만 설치하고, 그 이후에 다른 파일들을 다시 COPY해서 Docker이미지가 효율적으로 빌드되도록 한다.

이렇게 함으로써 코드 수정 시 npm install 이전 단계를 다시 실행하지 않아도 되며, 불필요한 다운로드를 방지할 수 있다.

Docker Volume

이제는 npm install 전에 package.json만 따로 COPY 해주어서 모든 캐시를 무효화하고 모듈을 다시 다운로드 하는 일을 없앴다.

하지만 아직도 소스를 변경할 때마다 변경된 소스 부분은 COPY한 후 이미지를 다시 빌드를 해주고 컨테이너를 다시 실행해주어야지 변경된 소스가 화면에 반영이 된다.

이러한 작업은 너무나 시간 소요가 크며 이미지도 너무나 많이 빌드하게 된다.

이러한 문제점을 해결하기 위해!!! Volume을 사용한다.

💻 Docker Volume? 지금까지는 컨테이너에 소스 코드를 COPY로 넣어주었다. COPY는 호스트 디렉터리에 있는 파일을 도커 컨테이너네 복사하는 것이고, 볼륨은 도커 컨테이너에서 호스트 디렉터리에 있는 파일들을 매핑해서 사용한다.

Volume을 사용하여 어플리케이션을 실행해보려면, docker run -p 5000:8080 -v /usr/src/app/node_modules -v $(pwd):/usr/src/app <이미지 아이디>

• -p 5000:8080: 호스트의 5000번 포트를 컨테이너의 8080포트에 매핑한다.
• -v /usr/src/app/node_modules: node_modules 폴더를 호스트에 공유하지 않고, 컨테이너 내부에만 유지시킨다.
  • 호스트 시스템에는 node_modules폴더를 포함하지 않는 이유는 컨테이너 내부에서만 필요한 의존성 파일을 관리하려는 것이다. 이는 호환성 문제를 줄이고, Docker의 독립적 환경 내에서 의존성을 유지할 수 있도록 도와준다.
• -v $(pwd):/usr/src/app: 현재 작업 디렉토리($(pwd))를 /usr/src/app경로에 매핑하여 소스 코드 파일이 컨테이너와 동기화되도록 한다.

일단, "Hello World" 출력하는 것에서 "안녕하세요."로 소스코드를 변경했다. 재빌드 하지 않고 볼륨도 사용하지 않고 서버 실행시키면, 이렇게 기존대로 실행이 된다.

재빌드 없이, 도커 볼륨을 이용해서 실행해보았다. 변경한 코드가 반영된 것을 확인할 수 있다!!

1. 직접 생성해서도 사용할 수 있고
2. 도커 허브에 올려서 공유할 수도 있다.

간단한 도커 이미지 복습

1. 도커 이미지는 컨테이너를 만들기 위해 필요한 설정이나 종속성들을 갖고있는 소프트웨어 패키지이다.
2. 지금까지 해왔듯이 도커 이미지는 Dockerhub에 이미 다른 사람들이 만들어놓은 것을 이용할 수도 있으며, 직접 도커 이미지를 만들어서 사용할 수도 있고 직접 만든 것을 Dockerhub에 업로드할 수도 있다.

도커 이미지를 이용해 도커 컨테이너 생성 docker create <이미지이름>

도커 이미지 생성 순서

Dockerfile 만드는 법

도커파일(Docker file)이란? 도커 이미지를 만들기 위한 설정 파일 컨테이너가 어떻게 행동해야하는지에 대한 설정들을 정의해주는 곳이다.

도커 이미지를 만들기 위한 설정 파일이므로, 도커 이미지가 필요한 것이 무엇인지를 생각해야한다. 도커 이미지는 시작 시 실행 될 명령어와 파일 스냅샷으로 구성되어있으므로, 이 두 가지를 만들어야 한다.

도커 파일 만드는 순서

1. 베이스 이미지 명시(파일 스냅샷에 해당)
2. 추가적으로 필요한 파일을 다운 받기 위한 몇 가지 명령어를 명시(파일 스냅샷에 해당)
3. 컨테이너 시작 시 실행 될 명령어를 명시해준다. (시작시 실행 될 명령어에 해당)

베이스 이미지는 무엇인가?

도커 이미지는 여러 개의 레이어들로 되어있다. 그 중에서 베이스 이미지는 이 이미지의 기반이 되는 부분이다.

실습 - Hello문구 출력

Dockerfile작성

1. 도커 파일을 만들 폴더 하나 만들기 ex) dockerfile-folder
2. 방금 생성한 도커 파일 폴더를 에디터를 이용해서 실행(Visual Studio Code 추천)
3. 파일 하나를 생성, 이름은 dockerfile
4. 그 안에 먼저 어떻게 진행해 나갈지 기본적 토대 명시

FROM RUN CMD 등은 도커 서버에게 무엇을 하라고 알려주는 것이다.

FROM 이미지 생성 시 기반이 되는 이미지 레이어 <이미지이름>:<태그> 형식으로 작성 태그를 안 붙이면 자동적으로 가장 최신 것으로 다운 받음 ex) ubuntu:14.04

RUN 도커 이미지가 생성되기 전에 수행할 쉘 명령어

CMD 컨테이너가 시작되었을 때 실행할 실행 파일 또는 셸 스크립트이다. 해당 명령어는 DockerFile 내 1회만 쓸 수 있다.

5. 이제 베이스 이미지부터 실제 값으로 추가해주기.
6. 베이스 이미지는 ubuntu를 써도 되고 centos등을 써도 되지만 hello를 출력하는 기능은 굳이 사이즈가 큰 베이스 이미지를 쓸 필요가 없기에 사이즈가 작은 alpine베이스 이미지를 사용한다.
7. hello문자를 출력해주기 위해 echo를 사용해야하는데 이미 apline안에 echo를 사용하게 할 수 있는 파일이 있기에 RUN부분은 생략함.
8. 마지막으로 컨테이너 시작 시 실행될 명령어 echo hello를 적어준다.

도커 클라이언트, 도커 서버, 이미지 생성

도커 파일에 입력된 것들이 도커 클라이언트에 전달되어서 도커 서버가 인식하게 해야한다. 그렇게 하기 위해서 docker build ./ 또는 docker build .

build명령어는

• 해당 디렉토리 내에서 dockerfile이라는 파일을 찾아서 도커 클라이언트에 전달시켜준다.
• docker build 뒤에 ./와 .는 둘 다 현재 디렉토리를 가리킨다.

그래서 docker build .을 해보면

build 과정 설명

이미지를 빌드할 때 Docker는 Dockerfile을 읽고 각 명령어에 따라 레이어(layer)를 쌓아 이미지를 생성한다. 위 사진의 빌드 로그에 나타난 주요 단계는 다음과 같다.

1. load build definition from Dockerfile Docker가 현재 디렉터리에서 Dockerfile을 찾고, 이를 읽어서 빌드를 시작한다.
2. transferring Dockerfile Dockerfile의 내용을 Docker데몬에 전송하여 빌드를 준비한다. 여기서 264B는 Dockerfile의 크기이다.
3. load metadata for docker.io/library/alpine FROM alpine 명령에 따라, alpine이미지를 기반으로 사용한다. 여기서는 Docker가 최신 버전(apline:latest)의 메타데이터를 가져온다.
4. load .dockerignore Docker는 .dockerignore 파일을 로드하여 빌드 과정에서 제외할 파일이나 폴더를 확인한다. .dockerignore파일에 지정된 내용은 빌드 시 제외된다.
5. transferring context 현재 디렉터리의 모든 내용을 Docker 데몬에 전송한다. 이때 전송된 데이터의 크기는 2B로 매우 작다. 컨텍스트(context)는 Docker가 빌드할 때 필요로하는 파일 및 폴더의 집합이다.
6. CACHED[1/1]FROM docker.io/library/alpine 캐시된 alpine이미지를 사용하여 빌드를 빠르게 처리한다. 캐시된 레이어가 있으면 이를 재사용하여 빌드 시간을 단축!
7. exporting to image 모든 명령을 처리한 후, 최종 이미지를 생성하여 저장
8. exporting layers / writing image 빌드가 완료된 이미지를 저장하고, 이미지의 해시 값을 출력한다. 이 해시값은 이미지의 고유ID이다.

결과적으로 이 빌드과정은 alpine기반 이미지 위에 CMD["echo","hello"]명령을 추가하여 최종 Docker이미지를 생성하는 과정을 나타낸다.

원래는 이런식으로 빌드 과정에서 각 레이어와 컨테이너 ID가 터미널에 표시되었었다. 그런데, 최근 Docker버전에서는 빌드 과정의 출력을 간소화하면서 세부적인 레이어 ID와 컨테이너 ID 대신 요약된 정보를 출력하도록 변경되었다.

ID를 확인하고싶다면, docker images 명령어를 통해서 확인할 수 있다.

결론적으로

• 베이스 이미지에서 다른 종속성이나 새로운 커맨드를 추가할 때는 임시 컨테이너를 만든 후 그 컨테이너를 토대로 새로운 이미지를 만든다. 그리고 그 임시 컨테이너는 지워준다.

만든 도커 이미지를 실행하려면, docker images 명령어를 통해 확인한 이미지ID를 이용해야 한다. ex. docker run b7a652f17135 IP Address가 기억하기 힘들기에 Domain이름을 새로 만들어서 이용하는 것과 비슷하게 우리가 만드는 도커 이미지에 이름을 줄 수 있다.

이를 위해 도커 이미지에 이름을 주면, 그 이름으로 실행시킬 수 있다.

도커 이미지에 이름 주는 방법

도커 이미지를 사실 아무렇게나 주어도 상관없다. 그런데, 사람들이 통상적으로 사용하는 규칙이 아래의 주황색 박스로 표현되어있다.

실제로 명령어를 사용해 보았을 때, 로그의 마지막에 naming to~ 로 이름설정이 잘 적용되었음을 확인할 수 있다.

설정한 이름을 기반으로 실행한 화면이다. 의도했던 대로 hello가 잘 출력된 것을 확인할 수 있다.

현재 레디스 클라이언트와 서버 상황

레디스 클라이언트가 레디스 서버가 있는 컨테이너 밖에서 실행을 하려 하니 레디스 서버에 접근을 할 수가 없기에 레디스 클라이언트를 작동하려 할 때 에러가 발생한다.

답은 레디스 클라이언트도 컨테이너 안에서 실행을 시켜야 한다.

1. 먼저 이전과 똑같이 첫 번째 터미널을 킨 후, 레디스 서버를 작동시키자.
2. 이미 실행중인 컨테이너에 명령어를 전달할 때 exec을 쓴다. 그러니 redis 서버가 실행 중인 컨테이너에 exec을 이용하여 redis 클라이언트도 실행해보아야 한다. docker exec -it <컨테이너 아이디> redis-cli 여기에서 -it를 붙여줘야 명령어를 실행한 후 계속 명령어를 적을 수 있다.

• -i interactive 상호적인
• -t terminal -i + -t = -it

만약, -it가 없다면, 그냥 redis-cli를 켜기만 하고 밖으로 다시 나와버린다.

이 사진에서 보이다싶이, 윗 명령어(-it가 없는 명령어)에서는 바로 나와지는데, 밑에서는 클라이언트로 들어가진 상태가 유지되어 추가적인 명령어를 더 입력할 수 있는 것을 볼 수 있다.

컨테이너에 쉘 환경으로 접근

지금까지 실행 중인 컨테이너에 명령어를 전달할 때에는 docker exec -it <컨테이너 아이디> <명령어> 이런식으로 명령어 하나마다, 이 코드가 필요했다.

이러한 문제점을 해결해주기 위해 컨테이너 안에 쉘이나 터미널 환경으로 접속을 해줄 수가 있다. ➡ 마지막 명령어를 sh로 해주면 된다.

1. 첫 번째 터미널을 실행한 후, alpine 이미지를 이용해 컨테이너를 실행한다. docker run apline ping localhost
2. 그 후 exec을 이용하고 마지막 명령어 부분에 sh를 입력 후 컨테이너 안에서 터미널 환경을 구축한다. docker exec -it <컨테이너 아이디> sh
3. 그 안에서 여러 가지 터미널에서 원래 할 수 있는 작동들을 해본다. ex.

• ls - 컨테이너 디렉토리에 있는 내용(디렉토리, 파일 확인)
• touch new file - 파일 생성
• export hello=hi echo $hello -변수 생성 출력

📌 이 터미널 환경에서 나오려면 Control+D !!

1. 먼저 터미널 2개를 실행한다.
2. 첫 번째 터미널에서 컨테이너 하나를 실행한다. (docker alpine ping localhost)
3. 두 번째 터미널에서 컨테이너가 잘 작동하고 있는지 확인하고 다른 명령어를 전달한다. ex) docker exec <컨테이너 아이디> ls

똑같은 결과를 내주는 것 : docker run <이미지이름>

• docker run은 새로 컨테이너를 만들어서 실행
• docker exec은 이미 실행 중인 컨테이너에서 명령어를 전달 여기에서도 두 개의 터미널을 띄워서 한 터미널에 실행을 시킨다. 그 실행 정보를 다른 터미널에서 보고, exec 실행여부를 확인해보았다. 디렉토리 정보가 잘 출력되는 것을 확인할 수 있다.

생성, 시작, 실행

지금까지는 docker run<이미지 이름>으로 컨테이너 생성,실행을 했는데, 이것을 docker create와 docker start로 쪼개서 볼 수 있다.

docker run는 파일 스냅숏을 하드디스크로 옮기고, 시작 시 실행할 명령어를 컨테이너에서 실행시켜주는 두 역할을 모두 수행한다. 하지만, docker create는 파일 스냅샷만 하드디스크로 옮겨주고, docker start는 시작 시 실행할 명령어만 컨테이너 내에서 실행시켜준다.

중지

docker stop과 docker kill로 중지할 수 있다.

stop과 kill은 둘 다 실행중인 컨테이너를 중지시키는 역할을 수행한다. 하지만,

1. Stop은 Gracefully하게 중지시킨다. 자비롭게 그동안 하던 작업들을 완료하고 컨테이너를 중지시킨다. 예를 들어, 메시지를 보내고 있었다면, 보내던 메시지는 다 보내고 컨테이너를 중지시킨다.
2. Kill은 Stop과 달리 어떠한 것도 기다리지 않고 바로 컨테이너를 중지시킨다.

kill은 SIGTERM이 없다.

먼저 실행시킨 뒤, docker ps로 아이디나 이름을 알아내어 docker stop <NAMES>명령어를 쳤다. 바로 중지되지 않고, 특정 시간이 지난 후에 종료된다. kill은 명령어가 입력되는 순간 바로 종료된다.

삭제

docker rm <중지할 컨테이너 아이디/이름> 삭제된 것을 확인할 수 있다.

• 실행중인 컨테이너는 먼저 중지한 후에 삭제가 가능하다.

모든 컨테이너를 삭제하고싶다면?

docker rm \`docker ps -a -q\`

윈도우의 powerShell에서는 백틱을 지원하지 않아서 $()로 수행했다.

이미지를 삭제하고 싶다면? docker rmi <이미지 id>

한 번에 사용하지 않는 컨테이너, 이미지, 네트워크 모두 삭제하고 싶다면? docker system prune

도커를 쓰지 않을 때 모두 정리하고싶다면, 위의 docker system prune 명령어를 사용하면 된다. 하지만 이것도 실행 중인 컨테이너에는 영향을 주지 않음!

ps: process status

실습

1. 2개의 Terminal을 작동시킨다.
2. 첫 번째 Terminal에서 container 하나를 실행 (하지만 이때 컨테이너를 켰다가 바로 끄면 3번을 할 때 이미 프로세스가 꺼져있기 때문에 리스트에서 볼 수 없음.)
3. 두 번째 Terminal에서 docker ps로 확인.
4. 그러면 꺼져있는 container도 확인하고 싶다면?

1. CONTAINER ID : 컨테이너의 고유한 아이디 해시값 실제로는 더욱 길지만, 일부분만 출력
2. IMAGE : 컨테이너 생성 시 사용한 도커 이미지
3. COMMAND : 컨테이너 시작 시 실행될 명령어
4. CREATED : 컨테이너가 생성된 시간
5. STATUS : 컨테이너의 상태 실행중은 UP, 종료는 Excited, 일시정지 Pause
6. PORTS : 컨테이너가 개방한 포트와 호스트에 연결한 포트 특별한 설정을 하지 않은 경우 출력되지 않음
7. NAMES : 컨테이너의 고유한 이름 컨테이너 생성 시 --name 옵션으로 이름 설정하지 않으면 도커 엔진이 임의로 형용사와 명사를 조합해 설정한다. id와 마찬가지로 중복이 안되고 docker rename 명령어로 이름 변경 가능. ex. docker rename original-name changed-name

원하는 항목만 보려면?

이것 또한, 실행되고 있는 것만이 출력된다.

실행되고있지 않은 컨테이너도 모두 나열하고싶다면?

docker ps -a -a가 all을 의미한다. 이 명령어를 치면, 실행되고있지 않은 것이라도 출력된다.

docker run hello-world

• ls가 쓰여있는 자리는 원래 이미지가 가지고 있는 시작 명령어를 무시하고, 여기에 있는 커맨드를 실행하도록 하는 것이다.
• ls커맨드는 현재 디렉터리의 파일 리스트를 표출한다.

작동 순서

1. 도커 클라이언트에 명령어 입력 후 도커 서버로 보냄.
2. 도커 서버에서 컨테이너를 위한 이미지가 이미 캐시되어있는지 확인
3. 없으면 도커 허브에서 다운받아옴. 있다면 그 이미 가지고있는 이미지로 컨테이너 생성

이 예시를 보면, 파일 리스트를 보여준 것을 확인할 수 있다. 로컬에는 alpine이라는 것이 없어서 도커 허브에서 Pull 해온 것을 확인할 수 있다.

설명

1. Alpine 이미지를 이용해 컨테이너 생성
2. 생성할 때 Alpine 이미지 안에 들어있던 파일 스냅샷들(bin,dev,etc 등등 ..)이 컨테이너 안에 있는 하드디스크로 다운로드됨.
3. 이미지 이름 뒤에 다른 명령어를 더 붙여서 원래 이미지 안에 들어있는 기본 커맨드는 무시되고, ls 명령어가 실행됨.

하지만, 어떻게 Alpine 이미지를 이용해 ls명령어를 실행시킬 수 있는거지?

Alpine 이미지 파일 스냅샷 내부에 이미 ls를 사용 가능하게 하는 파일이 있다!

hello-world 이미지로는 ls 명령어를 사용할 수 없다. 설명을 보면, executable file not found.(실행할 수 있는 파일을 못찾음)

하이퍼바이저(Hipervisor)는 가상머신을 생성하고 관리하는 소프트웨어이다. VM을 통해 다양한 운영체제를 실행할 수 있다. 이때 호스트는 OS 하이퍼바이저를 통해 VM들이 CPU, 메모리, 저장장치같은 하드웨어 자원을 사용할 수 있도록 지원한다.

예시

• 호스트 OS: Windows, macOS, Linux 등
• 하이퍼바이저: VMware, VirtualBox, Hiper-V, KVM 등
• 게스트 OS: 호스트 OS 위의 하이퍼바이저에서 구동되는 VM에 설치된 OS로, Windows, Linux, macOS 등 다양할 수 있음.

게스트 OS는 호스트OS에서 생성된 가상머신에 설치된 운영체제이다. 실제 물리적 하드웨어가 아니라 가상화된 하드웨어 자원을 활용한다.

• 네이티브 하이퍼 바이저 하이퍼바이저가 하드웨어를 직접 제어하기 때문에 자원을 효율적으로 사용하며, 별도의 호스트 os가 없으므로 오버헤드가 적다. 하지만 여러 하드웨어 드라이버를 세팅해야하므로 설치가 어렵다.

• 호스트형 하이퍼바이저 일반적인 소프트웨어처럼 호스트 os 위에서 실행되며, 하드웨어 자원을 VM 내부의 게스트 os에 에뮬레이트 하는 방식으로 오버헤드가 크다. 하지만 게스트 os 종류에 대한 제약이 없고 구현이 다소 쉽다. 이것이 일반적으로 많이 이용하는 방법이다.

에뮬레이트(emulate)란, 특정 하드웨어나 소프트웨어 환경을 다른 환경에서 똑같이 모방하거나 흉내내는 과정을 말한다.

하이퍼바이저 기반의 VM 구조

• 하이퍼바이저에 의해 구동되는 VM은 각 VM마다 독립된 가상 하드웨어 자원을 할당받는다.
• 논리적으로 분리 되어 있어서 한 VM에 오류가 발생하도 다른 VM으로 퍼지지 않는다는 장점이 있다.

이러한 가상화 기술에서 나온 컨테이너 가상화 기술

• VM과 비교했을 때 컨테이너는 하이퍼바이저와 게스트 OS가 필요하지 않으므로 더 가볍다.
• 애플리케이션을 실행할 때는 컨테이너 방식에서는 호스트 os 위에 애플리케이션의 실행 패키지인 이미지를 배포하기만 하면 되는데, VM은 애플리케이션을 실행하기 위해서 VM을 띄우고 자원을 할당한 다음, 게스트 OS를 부팅하여 애플리케이션을 실행시켜야해서 훨씬 복잡하고 무겁게 실행해야 한다.

공통점

도커 컨테이너와 가상머신은 기본 하드웨어에서 격리된 환경 내에 애플리케이션을 배치하는 방법이다.

차이점

가장 큰 차이점은 격리된 환경을 얼마나 격리를 시키는지의 차이이다.

• 도커 컨테이너에서 돌아가는 애플리케이션은 격리된 환경에서 실행되지만, 호스트 시스템의 커널을 공유한다.
• 가상머신은 독립적인 운영체제를 완전히 시뮬레이션 하는 방식으로 동작한다. 컨테이너보다 무겁고 성능이 느릴 수 있지만, 완전히 독립된 환경에서 다양한 운영 체제를 동시에 실행할 수 있다는 장점이 있다.

도커 컨테이너 격리 방법

먼저 리눅스에서 쓰이는 Cgroup(control groups)과 네임스페이스(namespaces)에 대해 알아야한다.

이것들은 컨테이너와 호스트에서 실행되는 다른 프로세스 사이에 벽을 만드는 리눅스 커널 기능들이다.

• C Group CPU, 메모리, Network bandwidth, 입출력 등 프로세스 그룹의 시스템 리소스 사용량을 관리한다. 예를 들어, A 어플의 사용량이 너무 많다면, A 어플을 C Group에 집어넣어서 CPU와 메모리의 사용을 제한할 수 있다.
• namespaces 하나의 시스템에서 프로세스를 격리시킬 수 있는 가상화 기술 별개의 독립된 공간을 사용하는 것처럼 격리된 환경을 제공하는 경량 프로세스 가상화 기술이다.

여기에서 보면, 커널은 공유되고있고, 하드디스크와 CPU,메모리가 격리되어 있는 것을 확인할 수 있다. cpu와 메모리는 C Group에 의해 격리된다. 각 컨테이너가 격리되는 것은 namespace를 이용한 것이다.

나는 현재 윈도우를 사용 중인데, 어떻게 리눅스의 기능인 C Group과 namespace를 사용할 수 있는것일까?

터미널에서 docker version을 입력하면 Server 내부의 OS/Arch를 보면 linux/amd64라고 쓰여있는 것을 확인할 수 있다.

Mac과 window 모두 리눅스 커널, 리눅스 VM에서 비롯된 것이므로 리눅스 명령어를 사용할 수 있는 것이다.

🚨 Docker 자체는 하이퍼바이저를 사용하지 않고 컨테이너를 구동한다. 하지만 Windows에서 Docker Desktop은 리눅스 커널 기능을 제공하기 위해 WSL 2 기반의 리눅스 VM을 사용한다. 이 VM은 Windows와 리눅스 컨테이너 간의 호환성을 높여주며 리눅스의 CGroup과 Namespace기능을 사용할 수 있게 해준다.

도커는 컨테이너를 사용하여 응용프로그램을 더 쉽게 만들고 배포하고 실행할 수 있도록 설계된 도구이며, 컨테이너 기반의 오픈소스 가상화 플랫폼이자 생태계이다.

컨테이너?

도커 이미지와 도커 컨테이너 정의

컨테이너는 코드와 모든 종속성을 패키지화하여 응용 프로그램이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위이다.

➡ 현재까지 여러 가지 방향으로 컨테이너를 정의할 때 간단하고 편리하게 프로그램을 실행시켜주는 것으로 정의를 내리고 있다.

컨테이너 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정과 같은 응용 프로그램을 실행하는데 필요한 모든 것을 포함하는 가볍고 독립적이며 실행 가능한 소프트웨어 패키지이다. 또한, 컨테이너 이미지는 런타임에 컨테이너가 되고 도커 컨테이너의 경우 도커 엔진에서 실행될 때 이미지가 컨테이너가 된다. 리눅스와 윈도우 기반 애플리케이션 모두에서 사용할 수 있는 컨테이너화 된 소프트웨어는 인프라에 관계 없이 항상 동일하게 실행된다.

컨테이너는 소프트웨어를 환경으로부터 격리시키고 개발과 스테이징의 차이에도 불구하고 균일하게 작동하도록 보장한다.

도커 이미지는 프로그램을 실행하는데 필요한 설정이나 종속성을 가지고 있으며 도커 이미지를 이용해 컨테이너를 생성하며 도커 컨테이너를 이용해 프로그램을 실행한다.

도커를 쓰는 이유는 무엇인가?

어떤 프로그램을 다운로드 하는 과정을 굉장히 간단하게 만들기 위해서 사용한다.

도커 없이 프로그램을 받을 때는 installer 내려받고, 그걸 실행하면 된다. 그런데, 갖고있는 서버, 패키지 버전, 운영체제 등등에 따라 프로그램을 설치하는 과정에서 많은 에러가 발생한다. 그것만이 아니라 설치 과정이 다소 복잡하다.

실제 redis 다운로드 과정으로 예시를 들어보면, 도커 없이 다운로드를 받기 위해서는 이런 과정을 거쳐야한다. 하지만 wget 명령어를 사용하기 위해서는 또 설치과정이 필요하여 오류가 발생하고 복잡하다. 즉, 특정 프로그램을 받을 때 거기에 맞는 부수적인 것들도 계속 받으며 설치하는 과정이 복잡해지고 에러도 많이 생긴다.

반면! 도커로 Redis를 받으려고 하면, docker run -it redis만 치면 다운로드가 완료된다.

즉, 도커를 이용해 프로그램을 설치하면 예상치 못한 에러도 덜 발생하며, 설치하는 과정도 훨씬 간단해지기 때문에 도커를 사용한다.

이미지로 컨테이너 생성하는 방법

그렇다면, 어떻게해서 컨테이너를 생성하는 것일까?

이미지는 응용 프로그램을 실행하는데 필요한 모든 것을 포함하고 있다.

필요한 모든 것

1. 컨테이너가 시작될 때 실행되는 명령어
2. 파일 스냅샷 ex. 컨테이너에서 카카오톡을 실행하고싶다면, 카카오톡 파일(카카오톡을 실행하는데 필요한 파일) 스냅샷

파일 스냅샷은 디렉토리나 파일을 카피한 것이다.

이미지로 컨테이너 만드는 순서

1. Docker 클라이언트에 docker run<이미지> 입력해준다.
2. 도커 이미지에 있는 파일 스냅샷을 컨테이너 하드 디스크에 옮겨준다.
3. 이미지에서 가지고 있는 명령어(컨테이너가 실행될 때 사용될 명령어)를 이용해서 카카오톡을 실행시켜준다.

모니터링은 잘 대응하는 것이 중요하다. 서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생하도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것이다.

세상에는 수 많은 모니터링 툴이 있고, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용할 수 있다.

그라파나 대시보드 핀포인트 이런 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다. (실제로는 라이브러리 등을 통해서 자동화되는 경우가 많다.)

모니터링 툴에 지표 전달 예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달한다고 가정해보자. 그러면 각각의 정보를 JMX 모니터링 툴이 정한 포멧에 맞추어 측정하고 전달해야 한다.

모니터링 툴 변경 그런데 중간에 사용하는 모니터링 툴을 변경하면 어떻게 될까? 기존에 측정했던 코드를 모두 변경한 툴에 맞도록 다시 변경해야 한다. 개발자 입장에서는 단순히 툴 하나를 변경했을 뿐인데, 측정하는 코드까지 모두 변경해야 하는 문제가 발생한다. 이런 문제를 해결하는 것이 바로 마이크로미터(Micrometer)라는 라이브러리이다.

마이크로미터 추상화 마이크로미터 전체 그림

• 마이크로미터는 애플리케이션 메트릭 파사드라고 불리는데, 애플리케이션의 메트릭(측정 지표)를 마이크로미터가 정한 표준 방법으로 모아서 제공해준다.
• 쉽게 이야기해서 마이크로미터가 추상화를 통해 구현체를 쉽게 갈아끼울 수 있도록 해두었다.
• 보통은 스프링이 이런 추상화를 직접 만들어서 제공하지만, 마이크로미터라는 이미 잘 만들어진 추상화가 있기 때문에 스프링은 이것을 활용한다. 스프링 부트 액츄에이터는 마이크로미터를 기본으로 내장해서 사용한다.
  • 로그를 추상화하는 SLF4J를 떠올려보면 쉽게 이해가 될 것이다.
• 개발자는 마이크로미터가 정한 표준 방법으로 메트릭(측정 지표)를 전달하면 된다. 그리고 사용하는 모니터링 툴에 맞는 구현체를 선택하면 된다. 이후에 모니터링 툴이 변경되어도 해당 구현체만 변경하면 된다. 애플리케이션 코드는 모니터링 툴이 변경되어도 그대로 유지할 수 있다.

마이크로미터가 지원하는 모니터링 툴은 다음과 같다. AppOptics Atlas CloudWatch Datadog Dynatrace Elastic Ganglia Graphite Humio Influx Instana JMX KairosDB New Relic Prometheus SignalFx Stackdriver StatsD Wavefront

메트릭 확인하기

CPU, JVM, 커넥션 사용 등등 수 많은 지표들을 어떻게 수집해야 할까? 개발자가 각각의 지표를 직접 수집해서 그것을 마이크로미터가 제공하는 표준 방법에 따라 등록하면 된다. 다행히도 마이크로미터는 다양한 지표 수집 기능을 이미 만들어서 제공한다. 그리고 스프링 부트 액츄에이터는 마이크로미터가 제공하는 지표 수집을 @AutoConfiguration을 통해 자동으로 등록해준다.

쉽게 이야기해서 스프링 부트 액츄에이터를 사용하면 수 많은 메트릭(지표)를 편리하게 사용할 수 있다. 이제 기본으로 제공하는 메트릭들을 확인해보자. 아직 모니터링 툴을 연결한 것은 아니고, 등록된 메트릭들을 확인해보는 단계이다.

matrics 엔드포인트 matrics 엔드포인트를 사용하면 기본으로 제공되는 메트릭들을 확인할 수 있다.

• 액츄에이터가 마이크로미터를 통해 등록한 기본 메트릭들을 확인할 수 있다.
• 내용이 너무 많아 일부만 남겨두었다.

metrics 엔드포인트는 다음과 같은 패턴을 사용해서 더 자세히 확인할 수 있다. http://localhost:8080/actuator/metrics/{name}

JVM 메모리 사용량을 확인해보자.

• 현재 메모리 사용량을 확인할 수 있다.

Tag필터 availableTags를 보면 다음과 같은 항목을 확인할 수 있다.

• tag:area, values[heap, nonheap]
• tag:id, values[G1 Survivor Space, ...] 해당 Tag를 기반으로 정보를 필터링해서 확인할 수 있다. tag=KEY:VALUE와 같은 형식을 사용해야 한다.

다음과 같이 실행해보자.

• http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap
• http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:nonheap tag 를 사용해서 힙 메모리, 힙이 아닌 메모리로 분류해서 데이터를 확인할 수 있다.

또 다른 예시는 다음과 같다.

다양한 메트릭

마이크로미터와 액츄에이터가 기본으로 제공하는 다양한 메트릭을 확인해보자.

• JVM 메트릭
• 시스템 메트릭
• 애플리케이션 시작 메트릭
• 스프링 MVC 메트릭
• 톰캣 메트릭
• 데이터 소스 메트릭
• 로그 메트릭 기타 수 많은 메트릭이 있다. 사용자가 메트릭을 직접 정의하는 것도 가능하다. 뒤에서 예제로 만들어본다.

JVM 메트릭

JVM 관련 메트릭을 제공한다. jvm.으로 시작한다.

• 메모리 및 버퍼 풀 세부 정보
• 가비지 수집 관련 통계
• 스레드 활용
• 로드 및 언로드된 클래스 수
• JVM 버전 정보
• JIT 컴파일 시간

시스템 메트릭

시스템 메트릭을 제공한다. system. , process. , disk. 으로 시작한다.

• CPU 지표
• 파일 디스크립터 메트릭
• 가동 시간 메트릭
• 사용 가능한 디스크 공간

애플리케이션 시작 메트릭

애플리케이션 시작 메트릭을 제공한다.

• application.started.time: 애플리케이션을 시작하는데 걸리는 시간 (ApplicationStartedEvent로 측정)
• application.ready.time: 애플리케이션이 요청을 처리할 준비가 되는데 걸리는 시간(ApplicationReadyEvent로 측정)

스프링은 내부에 여러 초기화단계가 있고 각 단계별로 내부에서 애플리케이션 이벤트를 발행한다.

• ApplicationStartEvent: 스프링 컨테이너가 완전히 실행된 상태이다. 이후에 커맨드 라인 러너가 호출된다.
• ApplicationReadyEvent: 커맨드 라인 러너가 실행된 이후에 호출된다.

스프링 MVC 메트릭

스프링 MVC 컨트롤러가 처리하는 모든 요청을 다룬다. 메트릭 이름: http.server.requests

TAG 를 사용해서 다음 정보를 분류해서 확인할 수 있다.

• uri : 요청 URI
• method : GET , POST 같은 HTTP 메서드
• status : 200 , 400 , 500 같은 HTTP Status 코드
• exception : 예외
• outcome : 상태코드를 그룹으로 모아서 확인 1xx:INFORMATIONAL , 2xx:SUCCESS , 3xx:REDIRECTION , 4xx:CLIENT_ERROR , 5xx:SERVER_ERROR

자바에서 클래스나 메서드를 정의할 때, 특정 데이터 타입에 의존하지 않고 다양한 타입을 처리할 수 있도록 만드는 방법이다. 제네릭을 사용하면 데이터 타입을 일반화시켜 코드의 재사용성과 타입 안전성을 높일 수 있다. 제네릭을 통해 컴파일 시점에 타입을 확정하고, 그로인해 잘못된 타입 사용을 방지할 수 있다.

제네릭은 클래스나 메서드를 정의할 때 사용되며, 그 안에서 다룰 데이터 타입을 나중에 지정할 수 있도록 해준다. 예를 들어 특정 클래스가 Integer,String과 같은 다양한 데이터 타입을 처리해야하는 경우, 제네릭을 사용하면 같은 코드를 중복 작성하지 않고 한 번에 다양한 데이터 타입을 처리할 수 있다.

제네릭 타입의 문법

class 클래스이름<T> {
    // 클래스 내용
}

여기서 T는 제네릭 타입 매개변수로 Type을 나타내는 약어이다. T 외에도 E, K, V 등 다양한 문자를 사용할 수 있다. 하지만 일반적으로는 T를 많이 사용한다.

사용 예시

public class Box<T> {
    private T item;

    // 아이템 저장
    public void setItem(T item) {
        this.item = item;
    }

    // 아이템 반환
    public T getItem() {
        return item;
    }

    public static void main(String[] args) {
        // String 타입의 Box
        Box<String> stringBox = new Box<>();
        stringBox.setItem("Hello");
        System.out.println(stringBox.getItem());  // 출력: Hello

        // Integer 타입의 Box
        Box<Integer> intBox = new Box<>();
        intBox.setItem(123);
        System.out.println(intBox.getItem());  // 출력: 123
    }
}

제네릭 메서드 예시

• 클래스 뿐만 아니라 메서드에도 적용할 수 있다. 제네릭 메서드는 메서드 정의에서 제네릭 타입을 사용하는 것이다.

  public class GenericMethodExample {
  
    // 제네릭 메서드
    public static <T> void printArray(T[] array) {
        for (T element : array) {
            System.out.println(element);
        }
    }
  
    public static void main(String[] args) {
        // Integer 배열 출력
        Integer[] intArray = {1, 2, 3, 4, 5};
        printArray(intArray);
  
        // String 배열 출력
        String[] strArray = {"A", "B", "C", "D"};
        printArray(strArray);
    }
  }

제네릭의 장점

1. 타입 안전성(Type Safety)

• 제네릭을 사용하면 컴파일 시점에서 타입 검사를 하기 때문에 잘못된 타입을 사용하는 오류를 방지할 수 있다. 예를 들어, 제네릭을 사용하지 않고 Object 타입을 사용할 경우, 각 데이터를 처리할 때마다 타입 변환(casting)을 해야하고, 잘못된 변환 시 런타임 오류가 발생할 수 있다.
• 제네릭 사용 시 미리 타입을 지정하고 잘못된 타입의 데이터가 들어가는 것을 방지할 수 있다.

2. 코드 재사용성

• 제네릭을 사용하면 하나의 클래스나 메서드로 다양한 데이터 타입을 처리할 수 있으므로, 중복 코드를 줄이고 코드 재사용성을 높일 수 있다.

3. 캐스팅을 줄임

• 제네릭을 사용하지 않으면 Object로 데이터를 처리하게 되므로 데이터 타입에 맞게 형변환(casting)을 해야한다. 제네릭을 사용하면 이 과정이 생략되어 코드가 더욱 간결해진다.

제네릭을 사용하지 않았을 때의 문제점

제네릭이 없다면 모든 객체를 Object로 처리해야하며, 이로인해 불필요한 형변환이 필요하게 된다.

public class NonGenericBox {
    private Object item;

    public void setItem(Object item) {
        this.item = item;
    }

    public Object getItem() {
        return item;
    }

    public static void main(String[] args) {
        NonGenericBox box = new NonGenericBox();
        box.setItem("Hello");

        // 형 변환 필요
        String item = (String) box.getItem(); 
        System.out.println(item);

        // 형 변환 오류 가능성
        box.setItem(123);
        String wrongType = (String) box.getItem();  // 실행 시 ClassCastException 발생
    }
}

• setItem() 메서드는 매개변수로 Object 타입을 받기 때문에 어떤 객체든 저장할 수 있다. 예를 들어, String 객체도 저장할 수 있고, Integer 객체도 저장할 수 있다.
• getItem() 메서드는 저장된 객체를 반환하는데, 반환 타입이 Object이다. 이 반환된 객체를 사용할 때, 해당 객체를 구체적인 타입(예: String)으로 형 변환(casting) 해야한다.
• 처음에 setItem("Hello")로 String 객체를 저장했고, 이를 String으로 형 변환하여 문제없이 사용했다. 하지만 두 번째로 setItem(123)로 Integer 객체를 저장하고 나서 이를 String으로 잘못 형 변환하려고 하므로, ClassCastException이 발생하게 된다.

오류의 원인

• setItem()을 통해 어떤 타입의 객체든 저장할 수 있지만, getItem으로 객체를 꺼내올 때 그 객체가 원래 어떤 타입이었는지 알 수 없기 때문에 잘못된 타입으로 형 변환을 시도할 경우 런타임 오류가 발생한다.
• Integer객체는 String으로 직접 형변환을 할 수 없다.
  • 형변환은 일반적으로 두 클래스가 상속관계에 있을 때만 가능하다.
  • 예를 들어, Integer는 Object를 상속받기 때문에 Object로 형 변환이 가능하다. 그러나 Integer와 String은 전혀 상관없는 클래스이므로 직접 형변환을 시도하면 ClassCastException이 발생한다.

Integer를 String으로 변환 방법

• String.valueOf()메서드를 사용해야 한다. 이 메서드는 int나 Integer 값을 문자열로 반환해준다.

  Integer intObj = 123;
  String str = String.valueOf(intObj);
  System.out.println(str);  // 출력: "123"

• Integer.toString()메서드를 통해 Integer 객체의 값을 문자열로 변환할 수 있다.

  Integer intObj = 123;
  String str = intObj.toString();
  System.out.println(str);  // 출력: "123"

• 문자열 결합 연산자(+) 사용 숫자를 문자열과 더하면 자동으로 문자열로 변환된다.

  Integer intObj = 123;
  String str = intObj + "";  // 문자열 결합
  System.out.println(str);  // 출력: "123"

String을 Integer로 변환하는 방법

• Integer.parseInt() 사용 int형으로 변환해준다.

  String str = "123";
  int number = Integer.parseInt(str);
  System.out.println(number);  // 출력: 123

• Integer.valueOf() 사용 객체형(Integer)로 변환해줌.

  String str = "123";
  Integer number = Integer.valueOf(str);
  System.out.println(number);  // 출력: 123