Pyidros

공공데이터 OpenAPI 사용법

Pyidros — Tue, 26 Mar 2024 22:41:17 +0900

● API(Application Programming Interface)란,

애플리케이션 소프트웨어나 데이터베이스, 컴퓨터 하드웨어 간의 상호작용을 가능하게 하는 인터페이다. 즉, 서로 다른 소프트웨어 시스템이 서로 통신하고 데이터를 교환할 수 있도록 돕는 도구와 규약의 집합이다. API는 '계약'처럼 작동하여, 한 시스템이 다른 시스템에게 요청할 수 있는 작업들과 그에 대한 형식, 규칙을 정의한다.

● 공공데이터 포털에서 한국환경공단_에어코리아_대기오염정보 API 신청

● 공공데이터 API를 사용하기 위해 주의 깊게 서비스 정보에 대해서 파악 해야한다.

데이터명: API가 제공하는 데이터의 종류와 형태를 나타낸다. JSON과 XML 형식으로 제공되는 경우가 많으며, 사용하는 시스템이 어떤 형식을 지원하는지에 따라 적절한 형식을 선택해야 한다.
서비스 유형: 이 API가 REST 방식으로 제공되는지, SOAP 방식인지 등의 웹 서비스 유형을 나타낸다. REST는 가장 일반적인 API 유형 중 하나로, HTTP 요청을 사용하여 데이터를 쉽게 교환할 수 있다.
활용기한: API를 사용할 수 있는 기간으로, 이 기간이 지나면 API 사용에 제약이 생긴다.
엔드포인트(End Point): API를 요청할 때 사용해야 하는 주소(URL)다. 이 주소로 API 요청을 보내서 필요한 데이터를 받아올 수 있다.
인코딩/디코딩 방식: API를 사용할 때 요청과 응답 데이터의 인코딩(암호화)과 디코딩(복호화) 방식을 명시하고 있다. 이는 데이터의 안전한 전송을 보장하기 위한 중요한 정보다.
첨부문서: API 사용법, 데이터 구조, 예제 코드 등을 담고 있는 문서가 제공된다. 이 문서를 통해 API의 정확한 사용 방법을 숙지할 수 있으며, 개발 과정에서 참조해야 할 중요한 자료이다.

이미지에 나타난 내용들은 API를 효율적으로 활용하고, 개발 과정에서 발생할 수 있는 문제를 예방하는 데 도움을 줄 수 있는 핵심 정보이다. 따라서 API를 사용하기 전에 해당 정보들을 꼼꼼히 확인하고 이해하는 것이 중요하다.

● 다음은 자바에서 인증키와 End Point를 이용해 API의 데이터를 가져오는 예시이다.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.HttpURLConnection;
import java.net.URL;
import java.net.URLEncoder;
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;

public class SimpleAirKoreaApiCaller {

    // API URL 및 파라미터 설정
    private static final String API_URL = "여기에 End Point 즉, 주소를 기입";
    private static final String SERVICE_KEY = "여기에 서비스키를 기입"; 

    public static void main(String[] args) {
        try {
            // API 요청 URL 생성
            String encodedCityName = URLEncoder.encode("서울특별시", "UTF-8");
            StringBuilder urlBuilder = new StringBuilder(API_URL);
            urlBuilder.append("?serviceKey=").append(SERVICE_KEY);
            urlBuilder.append("&returnType=json");
            urlBuilder.append("&stationName=").append(encodedCityName);
            urlBuilder.append("&dataTerm=DAILY");
            urlBuilder.append("&ver=1.3");

            // HTTP 연결 설정 및 요청 수행
            URL url = new URL(urlBuilder.toString());
            HttpURLConnection conn = (HttpURLConnection) url.openConnection();
            conn.setRequestMethod("GET");
            conn.setRequestProperty("Accept", "application/json");

            // 응답 받기
            BufferedReader rd;
            if (conn.getResponseCode() == HttpURLConnection.HTTP_OK) {
                rd = new BufferedReader(new InputStreamReader(conn.getInputStream()));
                ObjectMapper mapper = new ObjectMapper();
                JsonNode rootNode = mapper.readTree(rd);
                rd.close();

                // JSON 데이터에서 필요한 부분 가져오기
                JsonNode itemsNode = rootNode.path("response").path("body").path("items");
                System.out.println(itemsNode);

            } else {
                System.err.println("API 호출 실패: " + conn.getResponseCode());
            }
            conn.disconnect();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Go 프로그래밍 언어란?

Pyidros — Thu, 14 Mar 2024 17:47:38 +0900

Go 프로그래밍 언어는 Google에서 개발한 오픈 소스 프로그래밍 언어로, 종종 Golang으로도 불린다. 이 언어는 간결함, 효율성, 그리고 특히 동시성을 다루는 능력에 중점을 두고 설계된 현대적인 프로그래밍 언어이다.

Go의 만들어진 과정

2007년 Robert Griesemer, Rob Pike, 그리고 Ken Thompson에 의해 Go 언어의 개발이 시작되었다. 이들은 개발자들이 대규모 시스템을 효과적으로 관리할 수 있도록 도와주는 새로운 언어의 필요성을 느꼈다. 기존 언어들이 제공하는 도구와 라이브러리가 복잡한 동시성 문제와 대규모 데이터 처리 요구를 충분히 해결하지 못한다고 보았기 때문이다. 2009년에 공식적으로 공개된 Go는 이러한 요구를 충족시키는 데 중점을 두고 설계되었다.

Go의 주요 특징

간결성: Go는 간결하고 명확한 문법을 가지고 있어 코드의 이해와 작성이 쉽다.
동시성: 고루틴(Goroutines)과 채널(Channels)을 이용한 효율적인 동시성 지원을 제공한다. 이를 통해 동시에 실행되는 작업을 쉽게 관리할 수 있다.
표준 라이브러리: 네트워킹, 문자열 처리, 그리고 암호화와 같은 다양한 작업을 손쉽게 처리할 수 있도록 광범위한 표준 라이브러리를 포함하고 있다.
정적 타입: 컴파일 시간에 타입 체크를 수행하는 정적 타입 언어로, 프로그램의 안정성과 성능을 향상시킨다.
컴파일 언어: 빠른 컴파일 속도를 제공하며, 이는 개발자의 생산성 향상에 기여한다.
크로스 컴파일: 다양한 운영 체제와 아키텍처를 위한 쉬운 크로스 컴파일을 지원한다.

Go와 자바 및 C언어와의 차이점 및 장점

자바와의 차이점
- 컴파일 및 실행 속도: Go는 JVM(Java Virtual Machine) 위에서 실행되는 자바보다 컴파일과 실행 속도가 빠르다.
- 동시성: 스레드와 락을 사용하여 동시성을 관리하는 자바와 달리, Go는 고루틴과 채널을 사용하여 더 간결하고 효율적으로 동시성을 처리한다.
- 가비지 컬렉션: 두 언어 모두 가비지 컬렉션을 제공하지만, Go는 가능한 한 최소한의 지연을 목표로 한다.
C언어와의 차이점
- 메모리 관리: 개발자가 직접 메모리 할당과 해제를 관리해야 하는 C언어와 달리, Go는 자동 가비지 컬렉션을 제공한다.
- 동시성: C언어는 표준으로 동시성을 지원하지 않으며, 외부 라이브러리나 OS 기능에 의존한다. 반면, Go는 언어 차원에서 강력한 동시성 지원을 제공한다.
- 문법과 안전성: Go는 C언어보다 더 간결하고 안전한 문법을 제공한다. 예를 들어, Go는 포인터 연산을 허용하지 않아 메모리 접근 관련 오류를 줄인다.

현대적인 프로그래밍 요구를 충족시키기 위해 설계된 Go는 특히 동시성을 다루는 애플리케이션 개발에 있어 그 장점이 부각된다. 간결한 문법, 빠른 실행 속도, 그리고 강력한 표준 라이브러리 덕분에 많은 개발자들에게 선호되고 있다.

유니온 마운트(Union mount)_OverlayFS, BTRFS

Pyidros — Thu, 14 Mar 2024 11:02:43 +0900

보통 하나의 디렉토리 파일 위치에서 파일 시스템을 마운트하면 최근 마운트 내용이 보이게 됩니다.

이렇게 여러 개의 파일 시스템을 하나처럼 병합하여 사용하는 기술을 유니온 마운트라 할 수 있습니다.

컨테이너 파일 시스템의 레이어드 구조

이 그림은 컨테이너 파일 시스템의 레이어드 구조를 나타냅니다. 이 구조는 다음과 같은 주요 개념과 특징을 가지고 있습니다:

Image Layering (이미지 레이어링):
- 각 레이어는 파일 시스템의 일부분을 담당합니다.
- 레이어 1, 레이어 2, 레이어 3은 'Read Only (R)'로 설정되어, 이들 레이어의 파일은 읽을 수만 있고 변경할 수 없습니다.
- 최상위 레이어인 'Container (RW)'는 읽기와 쓰기가 모두 가능한 'Read-Write' 레이어로, 여기에서 파일 변경 작업이 발생합니다.
Copy-on-Write (CoW):
- 하단 'Read Only' 레이어의 파일에 변경이 필요한 경우, 해당 파일은 최상위 'Container (RW)' 레이어로 복사되어 변경됩니다.
- 이 메커니즘은 공간 효율성을 높이고, 성능을 개선하며, 이미지의 불필요한 중복을 피합니다.
File System Support:
- 이러한 특징을 지원하는 파일 시스템에는 AUFS, OverlayFS, BTRFS 등이 있습니다.
- 이들 파일 시스템은 특히 컨테이너화된 환경에서 데이터 관리와 속도 향상을 위해 설계되었습니다.

이렇게 레이어드 파일 시스템 구조는 효율적인 리소스 사용을 가능하게 하며, 컨테이너 기반의 가상화 환경에서 중요한 역할을 합니다.

직접 서버에서 명령어로 확인해 보겠습니다.

1.sudo mount -t tmpfs tmpfs /home/ubuntu/

' ubuntu ' 디렉토리에 'tmpfs' 타입의 임시 파일 시스템을 마운트합니다. 'tmpfs'는 메모리에 저장되며, 데이터는 시스템이 재부팅될 때 사라집니다. 'sudo'는 관리자 권한으로 명령어를 실행하라는 것을 의미합니다.

2. mount | grep tmpfs

현재 마운트된 모든 파일 시스템 중에서 'tmpfs'로 마운트된 항목들만 필터링해서 보여줍니다. 여기서 /home/ubuntu/경로에 'tmpfs'가 마운트된 것을 확인할 수 있습니다.

3. ls -l

이 명령어는 현재 디렉토리의 파일과 디렉토리의 목록을 간략하게 보여줍니다. 마운트된 후에 'linux_campus' 디렉토리를 확인해보면 아무것도 보이지 않는데, 이는 'tmpfs' 마운트로 인해 원래 디렉토리가 숨겨져 있기 때문입니다.

4. ls -l ubuntu /

마운트된 ' ubuntu ' 디렉토리 내부를 확인합니다. 결과로는 아무것도 나타나지 않으며, 이는 'tmpfs'가 비어 있는 새로운 파일 시스템으로 마운트되었기 때문입니다.

5. sudo umount /home/ubuntu

마운트된 'tmpfs' 파일 시스템을 ' ubuntu ' 디렉토리에서 언마운트합니다.

6. ls -l ubuntu /

' ubuntu ' 디렉토리의 내용을 다시 확인합니다. 이번에는 'tmpfs'가 언마운트되었기 때문에 원래의 디렉토리와 파일들이 다시 나타납니다.

이러한 일련의 명령어를 통해 사용자는 특정 파일 위치에서 마운트할 경우 가장 최근에 마운트한 파일을 보여주는것을 확인할 수 있습니다.

OverlayFS와 BTRFS의 특징

OverlayFS

OverlayFS는 두 개의 다른 파일 시스템 레이어를 하나로 통합해 사용자에게 하나의 파일 시스템처럼 보이게 하는 기술입니다. 구조적 특징은 다음과 같습니다:

상단 레이어(Upperdir): 여기에 파일의 변경 사항이 저장됩니다. 쓰기 작업이 일어날 때마다 새로운 데이터가 이 레이어에 기록됩니다. ( 만약, 파일이 추가된다면 upperdir에 바로 추가됩니다. 이미지를 참고해서 설명하자면, file5가 새로 upperdir에 생성되게 됩니다.)
하단 레이어(Lowerdir): 읽기 전용 레이어로, 실제 파일의 원본 데이터를 포함합니다. 변경할 수 없으며, 기본 데이터로 사용됩니다. ( 여러 층의 이미지 레이어가 생성될수 있습니다.)
통합 레이어(Merged): 상단 레이어와 하단 레이어를 통합하여 사용자에게 하나의 파일 시스템처럼 보여주는 가상의 뷰입니다.
호환성: Red Hat Linux에서는 XFS 파일 시스템을 하단 레이어로 사용하는 것이 지원되지만, 다른 리눅스 배포판에서는 다양한 파일 시스템을 하단 레이어로 사용할 수 있습니다.

OverlayFS는 주로 컨테이너의 데이터 레이어를 관리하는 데 사용되며, 컨테이너가 수행하는 파일 시스템의 변경 사항을 효율적으로 다루기 위해 설계되었습니다.

BTRFS

BTRFS(B-Tree File System)는 Copy-on-Write (CoW)를 기반으로 하는 현대적인 파일 시스템으로, 복잡한 스토리지 요구 사항을 해결하기 위해 만들어졌습니다. 주요 기능은 다음과 같습니다:

스냅샷(Snapshots): 파일 시스템의 특정 시점을 기록하여 필요할 때 그 시점으로 되돌릴 수 있습니다. 이는 데이터 백업 및 복구에 매우 유용합니다.
스냅샷 기준으로 이미지 레이어를 생성하고, 먼저 쌓았던 스냅샷은 변경 불가능 하빈다. 그리고 최근 스냅샷은 컨테이너 레이어로서 RW 기능을 즉, 읽기와 저장기능을 가지고 있습니다.
RAID 지원: 여러 디스크에 걸쳐 데이터를 분산하여 저장하고, 디스크가 실패했을 때도 데이터를 복구할 수 있는 기능을 내장하고 있습니다.
Self-Healing: 데이터의 손상을 자동으로 감지하고 복구하는 기능을 지원합니다.
증분 백업(Incremental Backup): 스냅샷을 사용하여 데이터의 변경사항만을 기록합니다. 이는 저장 공간을 효율적으로 사용하고, 백업 시간을 단축합니다.

BTRFS는 데이터 무결성과 복구에 중점을 두어 설계된 파일 시스템으로, 서버와 스토리지 시스템에서 안정적인 데이터 관리를 가능하게 합니다. 또한, BTRFS는 파일 시스템의 유연성과 확장성을 향상시키기 위해 다양한 고급 기능을 제공합니다.

OverlayFS 사용하여 파일 시스템 마운트 하고, 파일을 생성 및 관리하는 과정(예)

1. 디렉토리 생성

명령어 : mkdir /tmp/{lower1,lower2,upper,merged,work}

/tmp 디렉토리 아래에 lower1, lower2, upper, merged, work라는 5개의 디렉토리를 생성합니다.
lower1, lower2는 하단 레이어로 사용될 디렉토리입니다.
upper는 변경사항(쓰기 작업)이 저장될 상단 레이어 디렉토리입니다.
merged는 상단과 하단 레이어가 합쳐져 보여질 마운트 포인트입니다.
work는 OverlayFS의 내부 작업을 위한 작업 디렉토리입니다.

2. 파일 생성

명령어 : echo "lower1 a" > /tmp/lower1/a.txt
명령어 : echo "lower1 b" > /tmp/lower1/b.txt
명령어 : echo "lower2 a" > /tmp/lower2/a.txt
명령어 : echo "lower2 c" > /tmp/lower2/c.txt

lower1 디렉토리에 a.txt, b.txt 파일을 생성하고, 각각 "lower1 a", "lower1 b" 문자열을 저장합니다.
lower2 디렉토리에 a.txt, c.txt 파일을 생성하고, 각각 "lower2 a", "lower2 c" 문자열을 저장합니다.

3. -1 OverlayFS 마운트 (읽기 전용 시도)

명령어 : sudo mount -t overlay overlay -o lowerdir=/tmp/lower1:/tmp/lower2 /tmp/merged

lower1과 lower2를 하단 레이어로 사용하여, merged 디렉토리에 OverlayFS를 마운트합니다. 여기서 upperdir와 workdir 옵션이 누락되어 있어 읽기 전용으로 마운트됩니다.

3. -2 OverlayFS 마운트 (읽기-쓰기)

명령어 : sudo mount -t overlay overlay -o lowerdir=/tmp/lower1:/tmp/lower2,upperdir=/tmp/upper,workdir=/tmp/work /tmp/merged

이번에는 lowerdir, upperdir, workdir를 모두 지정하여 merged에 마운트합니다. 이로써 merged 디렉토리가 읽기-쓰기 가능한 상태가 됩니다.

4. 파일 생성 및 확인

명령어 : echo "Hello World" > /tmp/merged/hello.txt

merged 디렉토리에 hello.txt 파일을 생성하고 "Hello World" 문자열을 저장합니다. 이 파일은 upper 디렉토리에 실제로 저장됩니다.

5. 최종 파일 상태 확인

ls -l /tmp/merged/ 명령을 통해 merged 디렉토리의 내용을 확인합니다. 여기서 a.txt, b.txt, c.txt, hello.txt 파일이 보입니다.
ls -l /tmp/upper 명령을 통해 upper 디렉토리의 내용을 확인합니다. hello.txt 파일만 존재하는 것을 확인할 수 있습니다. 이는 merged 디렉토리에 새로 생성되거나 변경된 파일들이 upper 디렉토리에 저장됨을 의미합니다.

이 과정은 OverlayFS를 사용하여 파일 시스템의 여러 레이어를 관리하고, 파일을 생성 및 수정하는 방법을 보여줍니다.

요약

유니온 마운트(Union Mount)는 여러 개의 파일 시스템을 하나처럼 병합하여 사용하는 기술로, 두 개 이상의 디렉토리 트리를 오버레이 방식으로 겹쳐서 하나의 디렉토리처럼 보이게 만듭니다. 이 때 각 레이어는 수정이 불가능한 읽기 전용(Read-Only)과 수정이 가능한 읽기-쓰기(Read-Write) 레이어로 구분되어 있을 수 있습니다. 이러한 구조는 파일의 가상 뷰를 제공하면서 실제 파일 시스템에는 변화를 주지 않는 방식으로 작동합니다.

OverlayFS는 유니온 마운트를 구현한 리눅스 파일 시스템의 한 예입니다. OverlayFS는 두 개의 디렉토리(하위 디렉토리와 상위 디렉토리)를 통합하여 단일 디렉토리처럼 사용할 수 있게 해주는데, 이는 유니온 마운트의 개념을 실제로 적용한 것입니다. OverlayFS의 주요 사용 사례 중 하나는 Docker 컨테이너에서 이미지와 컨테이너 레이어를 관리하는 것입니다.

BTRFS는 유니온 마운트 방식이 아니라 전혀 다른 접근을 사용하는 현대적인 파일 시스템입니다. BTRFS의 주요 기능 중 하나인 스냅샷은 유니온 마운트의 레이어 개념과는 다르게 작동합니다. 스냅샷은 특정 시점의 파일 시스템 상태를 기록하고, 필요한 경우 그 시점으로 롤백할 수 있는 기능을 제공합니다. BTRFS의 이러한 특징은 특히 데이터 무결성과 시스템 복원력을 중시하는 환경에서 중요합니다.

결론적으로, OverlayFS와 BTRFS는 각기 다른 목적과 사용 사례를 위해 설계된 파일 시스템으로, 유니온 마운트라는 개념을 실제 파일 시스템 관리에 적용하는 다양한 방식을 제공합니다. OverlayFS는 유니온 마운트의 직접적인 구현체로 볼 수 있으며, BTRFS는 유니온 마운트와는 별개로 다른 기능적 이점을 제공하는 파일 시스템입니다.

네트워크 네임스페이스(Network Namespace)는

Pyidros — Wed, 13 Mar 2024 15:48:16 +0900

네트워크 네임스페이스(Network Namespace)는 리눅스 커널의 기능 중 하나로, 네트워크 리소스(인터페이스, IP 주소, 라우트 테이블 등)를 분리하여 각각 독립적으로 관리할 수 있게 해줍니다. 이 기능은 가상 네트워킹, 컨테이너화, 네트워크 실험 등 다양한 시나리오에서 유용하게 사용됩니다. 여기서 제공된 명령어들을 통해 실제로 네트워크 네임스페이스를 생성하고, 간단한 가상 네트워크를 설정하는 방법을 살펴보겠습니다.

이 이미지는 리눅스에서 네트워크 네임스페이스와 브릿지, 그리고 가상 이더넷(veth) 페어를 사용하여 구성한 가상 네트워크의 구조를 나타내고 있습니다. 여기서 각 요소의 관계와 역할을 설명하겠습니다:

네트워크 네임스페이스(Network Namespace): '네임스페이스1'과 '네임스페이스2'는 독립된 네트워킹 환경을 제공합니다. 각각의 네임스페이스는 자신만의 인터페이스, IP 주소, 라우팅 테이블 등을 가집니다. 'lo'는 각 네임스페이스에 있는 로컬(loopback) 인터페이스를 나타냅니다.
가상 이더넷(veth) 페어: 'veth0'과 'veth1'은 가상 이더넷 페어를 나타냅니다. 이들은 서로 연결된 가상 네트워크 인터페이스로, 한쪽에서 패킷이 들어오면 다른 한쪽으로 전달됩니다. 여기서 'veth0'은 '네임스페이스1'에 연결되어 있는 'Ceth0'와 쌍을 이루고, 'veth1'은 '네임스페이스2'에 연결되어 있는 'Ceth1'와 쌍을 이룹니다.
브릿지(Br0): 'Br0'는 브릿지 인터페이스로, 여러 네트워크 인터페이스를 하나의 브릿지로 결합하여 레이어 2(데이터 링크 계층)에서 패킷을 전달합니다. 이 경우에는 'veth0'과 'veth1'을 브릿지로 결합하여 두 네임스페이스가 서로 통신할 수 있게 합니다.
물리적 인터페이스(eth0): 'eth0'은 호스트 시스템의 물리적 네트워크 인터페이스를 나타냅니다. 'Br0'와 연결될 수 있으며, 이를 통해 네임스페이스에 있는 인터페이스들이 물리 네트워크로 트래픽을 전송하거나 받을 수 있습니다.

이 구성을 사용하여, 두 개의 네트워크 네임스페이스는 독립적으로 관리되면서도 서로 또는 외부 네트워크와 안전하게 통신할 수 있습니다. 예를 들어, 네임스페이스 간 격리가 필요한 멀티테넌시 환경이나 네트워크 실험, 컨테이너 환경 등에서 유용하게 사용됩니다.

네트워크 네임스페이스 생성 및 관리

루트 권한 획득: 네트워크 네임스페이스를 생성하고 관리하기 위해서는 루트 권한이 필요합니다.
sudo su
네트워크 네임스페이스 생성: ip netns add 명령어를 사용하여 네트워크 네임스페이스를 생성합니다.
ip netns add ns0
ip netns add ns1
생성된 네임스페이스 확인: ip netns list 명령어로 생성된 네임스페이스를 확인할 수 있습니다.
네임스페이스 내 인터페이스 정보 확인 및 설정: 네임스페이스 내의 네트워크 인터페이스 정보를 확인하고, 로컬(loopback) 인터페이스를 활성화합니다.
ip netns exec ns0 ip link
ip netns exec ns0 ip link set lo up

가상 브릿지 및 veth 페어 생성

브릿지 인터페이스 생성: ip link add 명령어를 사용하여 호스트에 브릿지 네트워크 인터페이스를 생성하고 활성화합니다.
ip link add br0 type bridge
ip link set br0 up
브릿지 네트워크에 IP 설정: 브릿지에 IP 주소를 할당합니다.
ip addr add 192.168.2.1/24 dev br0
veth 페어 생성: 가상 이더넷(veth) 페어는 한 쌍의 가상 인터페이스로, 패킷이 한 인터페이스로 들어오면 다른 한쪽으로 나갑니다. 이를 생성하여 하나는 브릿지에 연결하고, 다른 하나는 네임스페이스에 할당합니다.
ip link add veth0 type veth peer name ceth0
- * ip link add 명령어를 사용하여 veth 페어를 생성합니다. 이때, 두 인터페이스의 이름을 지정합니다. 예를 들어, veth0과 ceth0이라는 이름의 페어를 생성합니다.
- veth0은 브릿지에 연결될 인터페이스이고, ceth0은 특정 네트워크 네임스페이스에 할당될 인터페이스입니다.
  생성된 veth0 인터페이스를 브릿지에 연결합니다. 이 과정을 통해 veth0이 브릿지의 일부가 되며, 브릿지 네트워크에 포함된 다른 장치와 통신할 수 있게 됩니다.
ip link set veth0 master br0
ip link set veth0 up
- master br0는 veth0을 브릿지 br0에 연결하라는 의미입니다.
- ip link set veth0 up 명령은 veth0 인터페이스를 활성화합니다.
ip link set ceth0 netns ns0
- 명령은 ceth0을 네임스페이스 ns0로 이동시킵니다.

네임스페이스 내부 네트워킹 설정

네임스페이스에 IP 할당: 각 네임스페이스에 있는 ceth 인터페이스에 IP 주소를 할당합니다.
ip netns exec ns0 ip addr add 192.168.2.2/24 dev ceth0
ip netns exec ns1 ip addr add 192.168.2.3/24 dev ceth1
네임스페이스 간 통신 테스트: 한 네임스페이스에서 다른 네임스페이스로의 연결을 테스트합니다
ip netns exec ns0 ping -c 2 192.168.2.3

요약

네트워크 네임스페이스를 사용하면 가상의 독립된 네트워크 환경을 생성할 수 있습니다. 이는 컨테이너 또는 가상 네트워크 실험에 매우 유용합니다.
ip netns 명령어를 통해 네임스페이스를 생성, 관리할 수 있으며, 네임스페이스 내에서 네트워크 인터페이스를 관리하기 위해 ip netns exec 명령어를 사용합니다.
가상 이더넷 페어(veth)를 활용하여 네임스페이스를 물리 네트워크 또는 다른 네임스페이스와 연결할 수 있습니다.
네트워크 네임스페이스는 리눅스 기반 시스템에서 네트워크 관리 및 분리에 있어 강력한 도구입니다.

PID 네임스페이스

Pyidros — Mon, 11 Mar 2024 18:17:53 +0900

PID 네임스페이스와 Mount 네임스페이스의 차이점

PID 네임스페이스는 프로세스 식별 번호(PID)의 격리에 초점을 맞춥니다. 각각의 네임스페이스에서는 PID가 1부터 시작하여 독립적인 프로세스 ID 공간을 가집니다. 이를 통해 여러 개의 격리된 프로세스 그룹을 운영할 수 있으며, 컨테이너와 같은 기술에서 중요하게 사용됩니다.
Mount 네임스페이스는 파일 시스템 마운트 포인트의 격리에 초점을 맞춥니다. 이를 통해 각 네임스페이스는 독립적인 파일 시스템 뷰를 가질 수 있으며, 마운트 및 언마운트 작업이 다른 네임스페이스에 영향을 주지 않습니다.

장점과 단점

PID 네임스페이스의 장점:
- 프로세스 격리: 각 컨테이너 또는 격리된 환경에서 독립적인 프로세스 관리가 가능합니다.
- 보안 강화: 공격자가 시스템의 다른 부분에 영향을 미치기 어렵게 만듭니다.
- 자원 관리: 특정 네임스페이스 내에서 프로세스를 관리하고 제어할 수 있습니다.
PID 네임스페이스의 단점:
- 복잡성 증가: 네임스페이스를 관리하고 구성하는 것은 복잡할 수 있으며, 시스템의 이해도를 요구합니다.
- 호환성 문제: 일부 기존 애플리케이션은 PID 네임스페이스 격리 환경에서 예상대로 작동하지 않을 수 있습니다.

설정과 생성 과정

unshare -pmif

unshare -pmif 명령어에 사용된 각 옵션의 의미는 다음과 같습니다:

-p: PID (Process ID) 네임스페이스를 생성합니다. 이 옵션을 사용하면 새로운 프로세스 ID 네임스페이스가 만들어지며,
이 네임스페이스 안에서 생성된 프로세스들은 고유한 PID 공간을 가집니다. 따라서 같은 PID를 가지는 프로세스가 다른 네임스페이스에서 동시에 존재할 수 있습니다.

-m: 마운트(Mount) 네임스페이스를 생성합니다. 이를 통해 파일 시스템 마운트 포인트의 격리가 가능해지며, 네임스페이스
내부에서 수행된 마운트 작업은 다른 네임스페이스에 영향을 미치지 않습니다.

-i: IPC (Inter-Process Communication) 네임스페이스를 생성합니다. IPC 네임스페이스는 프로세스 간 통신
리소스(예: 메시지 큐, 세마포어, 공유 메모리 등)를 격리합니다.

-f: unshare 명령어 실행 후 새로운 프로세스(일반적으로 쉘)를 fork 합니다. 이 옵션이 없으면 unshare는 새 네임스페이스를
생성한 후에도 현재 프로세스(unshare 명령어를 실행한 쉘 또는 스크립트) 내에서 계속 실행됩니다. -f 옵션을 사용하면,
새 네임스페이스 내에서 새로운 프로세스가 시작되고, 이 프로세스가 새 네임스페이스의 "root" 프로세스가 됩니다.

결론적으로, unshare -pmif 명령어는 새 PID 네임스페이스, 마운트 네임스페이스, IPC 네임스페이스를 동시에 생성하고,
이 세 가지 네임스페이스가 적용된 새로운 프로세스(보통 새 쉘)를 fork하여 실행하는 것을 의미합니다.
이를 통해 격리된 환경에서 프로세스를 실행할 수 있으며, 컨테이너와 같은 기술의 기반 기능 중 하나로 사용됩니다.

그리고 나서

PID가 1로 주어진것을 확인 할 수 있습니다.

'unshare'로 인해 생성된 새로운 PID 네임스페이스에서 이 PID는 다를 수 있습니다.

ps aux | head -n5

시스템에서 실행 중인 프로세스 목록의 상위 5개를 출력합니다. 새로운 네임스페이스에서는 볼 수 있는 프로세스가 제한될 수 있습니다.

ls /proc

/proc 디렉토리의 내용을 나열합니다. /proc은 시스템 정보와 실행 중인 프로세스에 대한 정보를 포함하는 가상 파일 시스템입니다.

mount -t proc none /proc

새로운 네임스페이스에 맞게 /proc 파일 시스템을 새롭게 마운트합니다. 이렇게 함으로써 새로운 PID 네임스페이스에서 실행 중인 프로세스만 /proc을 통해 볼 수 있습니다.

ps aux | head -n5 (후속 단계)

/proc을 새롭게 마운트한 후에 실행 중인 프로세스 목록의 상위 5개를 다시 출력합니다. 이제 이 목록은 새로운 PID 네임스페이스 내의 프로세스만 보여줍니다.

이 과정을 통해, 사용자는 리눅스의 네임스페이스 기능을 이용해 시스템의 나머지 부분과 독립적으로 동작하는 격리된 환경을 만들고, 이 환경 내에서 실험하거나 특정 작업을 수행할 수 있습니다. 이는 컨테이너와 같은 가상화 기술의 기반 메커니즘 중 하나입니다.

Mount 네임스페이스

Pyidros — Mon, 11 Mar 2024 11:15:05 +0900

Mount?? -

컴퓨팅에서 "마운트(Mount)"란 파일 시스템이 운영 체제에 의해 액세스가능하도록 만드는 과정을 말합니다. 이 용어는 주로 운영 체제가 저장 매체(하드 드라이브, SSD, CD-ROM 등) 또는 파일 시스템을 검색하여 사용할 준비를 할 때 사용됩니다. 마운트 과정을 통해 운영 체제는 해당 저장 매체의 파일과 디렉토리를 파일 시스템 트리의 특정 지점에 연결하게 되고, 이후에는 사용자와 다른 프로그램들이 파일 경로를 통해 저장 매체에 접근할 수 있게 됩니다.

예를 들어, 리눅스와 유닉스 계열 시스템에서 USB 드라이브를 컴퓨터에 연결하면 운영 체제는 이를 파일 시스템 트리의 특정 지점에 마운트해야 합니다. 일반적으로 이 과정은 자동으로 이루어지며, 마운트 후에는 사용자가 /media/usbdrive와 같은 경로를 통해 드라이브의 내용을 볼 수 있습니다.

마운트의 반대 과정은 "언마운트(Unmount)"이며, 이는 파일 시스템을 안전하게 제거하여 더 이상 액세스할 수 없게 만드는 것을 말합니다. 이는 데이터 손실을 방지하기 위해 저장 매체를 제거하기 전에 일반적으로 수행됩니다.

Mount 네임스페이스는 - 리눅스 커널의 기능 중 하나로, 프로세스 그룹이 파일 시스템 마운트를 별도로 관리할 수 있게 하는 기능입니다. 간단히 말해, mount 네임스페이스는 특정 프로세스나 프로세스 그룹이 시스템의 나머지 부분과 독립적으로 파일 시스템 마운트를 볼 수 있게 합니다.

이는 주로 컨테이너와 같은 가상화 기술에서 중요한 역할을 하며, 다양한 컨테이너가 각기 다른 파일 시스템 뷰를 가질 수 있도록 해줍니다. 컨테이너 A는 특정한 파일이나 디렉토리를 마운트할 수 있고, 컨테이너 B는 완전히 다른 것을 마운트할 수 있습니다. 이들 각각의 마운트는 다른 컨테이너나 호스트 시스템에는 보이지 않습니다.

Mount 네임스페이스는 리눅스의 다른 네임스페이스 기능들과 함께 시스템의 격리와 보안을 강화하는 데 사용됩니다. 예를 들어, PID 네임스페이스는 프로세스 ID를 격리시키고, Network 네임스페이스는 네트워크 인터페이스를 격리시키는 등의 작업을 수행합니다.

1. unshare 명령어 사용하기

unshare 명령어는 실행하는 쉘 또는 프로세스에 대해 새로운 네임스페이스를 생성하여 격리된 환경을 만듭니다.

먼저 unshare --help를 실행하여 사용 가능한 옵션들을 확인합니다. -m 옵션은 새로운 mount 네임스페이스를 생성하는 데 사용됩니다.

2. 새로운 mount 네임스페이스 생성

현재 쉘의 PID(프로세스 ID)를 확인합니다: echo $$
unshare -m /bin/bash 명령어를 사용해 새로운 쉘을 시작하고, 이 쉘에 대해 새로운 mount 네임스페이스를 생성합니다.
다시 echo $$를 사용해 새 쉘의 PID를 확인합니다. 이 PID는 이전과 동일할 것입니다. 네임스페이스 격리는 PID 네임스페이스가 아니므로, PID는 변경되지 않습니다.

3. tmpfs 마운트

새로운 mount 네임스페이스 내에서 mount -t tmpfs tmpfs /mnt를 실행하여 tmpfs(임시 파일 시스템)를 /mnt에 마운트합니다.
mount | grep /mnt를 실행하여 /mnt에 마운트된 파일 시스템을 확인합니다.

4. 테스트 파일 생성 및 확인

/mnt/hello.txt 파일을 생성하고 "Hello"를 내용으로 씁니다: echo "Hello" > /mnt/hello.txt
cat /mnt/hello.txt를 사용해 파일의 내용을 확인합니다.

5. 다른 터미널에서 파일 확인 시도

새로운 터미널을 열고 cat /mnt/hello.txt를 실행하여 파일 내용을 확인합니다. 파일이 보이지 않거나 다른 내용이 표시되는 경우, 이는 해당 터미널이 원본 mount 네임스페이스에 있기 때문입니다.

6. nsenter 명령어 사용하기

man nsenter를 통해 nsenter 명령어 사용법을 확인합니다. nsenter는 특정 PID의 네임스페이스로 진입하여 커맨드를 실행할 수 있게 해줍니다.
nsenter -t $TARGET_PID -a를 실행하여 타겟 PID의 모든 네임스페이스(여기서는 mount 네임스페이스)로 진입한 후 커맨드를 실행할 수 있습니다. $TARGET_PID는 앞서 unshare로 생성한 쉘의 PID입니다.

7. mount 네임스페이스 종료

exit 명령어를 사용하여 unshare로 생성한 쉘을 종료합니다. 이로써 새로운 mount 네임스페이스에서 작업한 내용은 종료되며, 원래의 네임스페이스로 돌아갑니다.

팁

네임스페이스를 사용할 때는 현재 작업 중인 네임스페이스를 항상 인식하고 있어야 합니다. 실수로 잘못된 네임스페이스에서 작업할 경우 예상치 못한 결과가 발생할 수 있습니다.
unshare와 nsenter는 리눅스 컨테이너를 다루거나 격리된 환경에서 테스트를 실행하는 등 다양한 시나리오에서 유용하게 사용될 수 있습니다.

컨테이너를 구성하는 3가지 리눅스 기술

Pyidros — Thu, 7 Mar 2024 13:52:54 +0900

1. 컨트롤 그룹 (Control Groups, cgroups)

컨트롤 그룹 (Control Groups, cgroups): 컨트롤 그룹은 리눅스 커널의 기능으로, 프로세스 그룹의 자원 사용량(메모리, CPU, 네트워크, 디바이스, 디스크 I/O, Block I/O 등)을 제한하고 격리하며 관리합니다. cgroups는 시스템 자원을 세밀하게 관리하고, 한 컨테이너가 호스트의 모든 자원을 독점하는 것을 방지하여 시스템의 안정성을 유지하도록 돕습니다.

특징:

이는 리소스 사용량을 제한하고, 프로세스를 격리하며, 여러 프로세스를 관리하는 Linux 커널 기능입니다.
서브시스템에는 blkio, cpu, cpuacct, cpuset, devices, freezer, memory, net_cls, ns 등이 있습니다.

cpu:
- 특정 cgroup에 할당된 프로세스가 사용할 수 있는 CPU 자원의 양을 제한(스케줄러를 이용해)할 수 있습니다. 예를 들어, CPU 사용을 10%로 제한하는 등의 설정이 가능합니다.
- 이 기능을 통해 시스템의 CPU 자원을 공정하게 분배하고, 시스템 오버로드를 방지할 수 있습니다.
memory:
- cgroup에 할당된 메모리 사용량을 제한합니다. 메모리 사용량을 128MB로 설정하면, 해당 그룹은 그 이상의 메모리를 사용할 수 없습니다. 만약 메모리 사용량이 한계치에 도달하면, OOM(out-of-memory) 관리자가 작동할 수 있으며, 필요하다면 프로세스를 종료시키는 등의 조치를 취할 수 있습니다.
freezer:
- cgroup의 프로세스를 일시 정지하거나 다시 시작할 수 있습니다. 이를 통해 도커와 같은 컨테이너 관리 도구에서 컨테이너를 일시 중지(docker pause)하거나 상태를 관리하는 데 사용됩니다.
blkio:
- cgroup에 할당된 프로세스가 디스크 I/O에 접근하는 방법을 제어하고, I/O 대역폭을 제한할 수 있습니다. 이는 I/O 자원의 공정한 사용을 보장하고, 시스템 성능에 미치는 영향을 최소화하는 데 도움이 됩니다.
net_cls:
- 이 서브시스템은 Linux 트래픽 컨트롤러(TC)와 함께 작동하여 트래픽을 cgroup에 따라 분류합니다. 네트워크 트래픽의 classid를 설정하여 네트워크 패킷에 대한 처리 우선순위를 조정할 수 있습니다.
cpuset:
- 프로세스가 실행될 수 있는 특정 CPU 코어나 메모리 노드를 지정합니다. 이를 통해 시스템의 특정 리소스를 고정시켜 사용할 수 있으며, 멀티 프로세싱 환경에서 성능 최적화에 도움이 됩니다.
devices:
- cgroup의 프로세스가 특정 디바이스에 접근할 수 있는 권한을 제어합니다. 필요한 디바이스만 사용할 수 있도록 제한함으로써 보안을 강화하고 시스템의 안정성을 높일 수 있습니다.
ns (namespace):
- 프로세스에 대한 격리를 제공하는 네임스페이스 기능으로, 시스템의 다른 부분으로부터 프로세스를 독립적으로 분리할 수 있습니다. 이는 프로세스 간의 리소스 충돌을 방지하고, 시스템의 여러 환경을 동시에 실행하는 데 사용됩니다.

이러한 cgroups와 네임스페이스 기능은 컨테이너 기술의 기반이 되며, 리눅스 시스템에서 강력한 리소스 관리와 격리를 가능하게 합니다. 컨테이너가 각기 독립적인 환경에서 실행되면서도 리소스를 효율적으로 사용할 수 있도록 지원합니다.

cgroups버전:

cgroupsv1은 개별 리소스 유형에 따라 별도의 계층적 관리를 제공합니다. 이는 각 리소스 유형에 대한 세밀한 제어를 가능하게 하지만, 관리의 복잡성을 증가시킵니다.
cgroupsv2는 단일 계층 구조를 가지고 있어 사용자가 시스템 리소스를 더 쉽게 관리할 수 있게 해줍니다. 또한, v2는 v1보다 향상된 기능과 효율성을 제공합니다.

장점:

시스템 리소스를 공정하게 분배하고 오버커밋(overcommit)을 방지합니다.
특정 애플리케이션의 리소스 사용을 제한하여 시스템의 안정성과 예측성을 향상시킵니다.

단점:

cgroups의 세부 설정은 복잡할 수 있고, 잘못 구성하면 성능에 부정적 영향을 줄 수 있습니다.

활용 사례:

1. runc

runc는 Open Container Initiative (OCI) 표준에 따른 컨테이너 런타임으로, Docker 및 다른 컨테이너화 플랫폼에서 널리 사용됩니다.
runc는 cgroups를 사용하여 각 컨테이너 프로세스에 필요한 리소스(예: CPU, 메모리)를 할당하고 제한합니다.
이를 통해 개별 컨테이너가 시스템의 리소스를 과도하게 사용하는 것을 방지하여 시스템의 안정성을 유지합니다.

2. YARN (Hadoop)

YARN은 Hadoop 데이터 처리를 위한 클러스터 리소스 관리 시스템입니다.
cgroups를 활용하여 각 작업(job)에 대한 리소스 사용량을 제한하고 관리합니다. 특히, 대규모 데이터 처리에 필요한 CPU와 메모리 자원을 효율적으로 분배합니다.
작업의 성능을 보장하면서도 다른 작업과 자원을 공정하게 공유할 수 있도록 합니다.

3. Android

Android는 애플리케이션의 Foreground 및 Background 작업 관리를 위해 cgroups를 사용합니다.
사용자 인터페이스와 상호 작용하는 애플리케이션에 대해 자원 사용에 제한을 거의 두지 않으며, 이를 통해 사용자 경험을 최적화합니다.
Background 에서 실행되는 애플리케이션의 경우, 네트워크 사용, 스토리지 액세스 및 CPU 사용량에 제한을 두어 배터리 수명을 연장하고 시스템 성능을 유지합니다.

차이점:

네임스페이스가 격리를 제공한다면, cgroups는 이 격리된 환경에서의 리소스 사용을 관리합니다.

2. 네임스페이스 (Namespaces)

네임스페이스 (Namespaces): 네임스페이스는 리눅스 시스템 내에서 프로세스 그룹을 격리하여 각 그룹이 서로의 시스템 자원을 볼 수 없게 만드는 기술입니다. 네임스페이스는 파일 시스템, 네트워크, 사용자 ID 등 여러 시스템 자원을 격리하여 프로세스가 독립적인 환경에서 실행되는 것처럼 느낄 수 있게 합니다. 이를 통해 하나의 시스템에서 여러 개의 독립적인 컨테이너를 실행할 수 있습니다.

특징:

시스템 리소스를 프로세스 그룹 단위로 격리합니다.
PID, 네트워크, IPC, 마운트, 호스트 이름 등 다양한 유형의 네임스페이스가 있습니다.

장점:

각 컨테이너에 대해 독립적인 시스템 환경을 제공합니다.
한 컨테이너의 변경이 다른 컨테이너에 영향을 주지 않습니다.

단점:

근본적인 호스트 OS의 취약점에는 영향을 받을 수 있습니다.
네임스페이스를 너무 많이 만들 경우 관리가 복잡해질 수 있습니다.

활용 사례:

Docker, Podman과 같은 컨테이너화 플랫폼에서 각 컨테이너에게 별도의 호스트 이름, 네트워크 스택을 제공합니다.

차이점:

cgroups가 리소스 할당과 제한에 중점을 두는 반면, 네임스페이스는 프로세스 레벨의 격리에 중점을 둡니다.

3. 유니언 파일 시스템 (Union File Systems)

유니언 파일 시스템 (Union File Systems): 유니언 파일 시스템은 여러 파일 시스템 계층을 오버레이(overlay) 방식으로 합쳐서 하나의 파일 시스템으로 표현하는 기술입니다. 이를 통해 읽기 전용의 기반 이미지를 유지하면서도, 변경 사항을 쓰기 가능한 최상위 계층에 저장할 수 있습니다. 이 방식은 컨테이너의 스토리지 효율성을 높이고, 이미지 계층을 공유하여 다양한 컨테이너 이미지 사이의 중복을 줄일 수 있습니다.

특징:

여러 파일 시스템을 하나로 병합하여 단일 파일 시스템처럼 관리할 수 있게 합니다.
읽기 전용과 쓰기 가능 계층을 분리하여 효율적인 파일 시스템 관리를 가능하게 합니다.

장점:

컨테이너의 기본 이미지를 변경하지 않고도 수정 사항을 저장할 수 있습니다.
이미지 계층을 통해 중복을 줄이고 스토리지 효율성을 향상시킵니다.

단점:

유니언 파일 시스템의 성능은 사용하는 특정 구현에 따라 다를 수 있으며, 때로는 기본 파일 시스템보다 느릴 수 있습니다.

활용 사례:

Docker에서 컨테이너의 파일 시스템 계층을 관리하고, 공유 이미지를 통해 여러 컨테이너 간의 재사용성을 높입니다.

차이점:

네임스페이스나 cgroups와는 달리, 유니언 파일 시스템은 파일 레벨에서 격리와 리소스 관리를 수행합니다.

이 세 가지 기술은 함께 사용될 때 리눅스 기반 컨테이너의 강력한 격리, 리소스 관리 및 파일 시스템 효율성을 제공합니다.

SSH (Secure Shell)란?

Pyidros — Mon, 4 Mar 2024 12:51:49 +0900

SSH (Secure Shell)는 네트워크를 통해 다른 컴퓨터에 안전하게 로그인하고, 원격 시스템에서 명령을 실행하며, 파일을 복사할 수 있게 해주는 프로토콜입니다. 기존의 rsh, rlogin, telnet 등을 대체하기 위해 설계되었으며, 통신 중인 데이터를 암호화하여 보안을 강화했습니다.

여기 rsh, rlogin, telnet, 그리고 ssh의 각각에 대한 간단한 설명과 장단점을 정리해드리겠습니다.

rsh (Remote Shell):

특징: 사용자가 원격 호스트에서 명령을 실행할 수 있게 해줍니다.
장점: 간단하고 사용하기 쉽습니다.
단점: 암호화되지 않은 텍스트로 데이터를 전송하기 때문에 보안에 취약합니다.

rlogin (Remote Login):

특징: 원격 시스템에 로그인하여 인터랙티브 셸 세션을 사용할 수 있습니다.
장점: 사용자가 원격으로 시스템에 로그인하고 작업할 수 있게 해줍니다.
단점: rsh와 마찬가지로 데이터 전송이 암호화되지 않아 보안에 취약합니다.

telnet:

특징: 원격 시스템에 대한 텍스트 기반의 인터페이스를 제공합니다.
장점: 널리 사용되며 많은 시스템과 호환됩니다.
단점: 모든 통신이 암호화되지 않아 중간자 공격에 취약합니다. 현대의 네트워크 환경에서는 거의 사용되지 않습니다.

ssh (Secure Shell):

특징: 암호화된 채널을 통해 안전한 텍스트 기반 통신을 제공합니다.
장점: 강력한 인증 및 암호화를 통해 보안을 제공합니다. 이는 데이터 무결성 및 기밀성을 보장하며, 사용자가 원격 시스템에서 안전하게 명령을 실행하고 파일을 전송할 수 있게 해줍니다.
단점: 더 복잡한 구성과 관리가 필요하며, 오래된 시스템이나 장비에서는 지원되지 않을 수 있습니다.

SSH는 rsh, rlogin, telnet에 비해 데이터를 암호화하여 안전한 원격 작업 환경을 제공한다는 큰 장점이 있습니다. 이러한 이유로 현재 대부분의 원격 접속과 파일 전송에는 SSH가 사용됩니다.

Telnet과 달리 SSH는 암호화 기능을 통해 데이터를 안전하게 보호합니다. 사용자 인증을 위한 공개 키 인증 방식을 지원하며, 이를 통해 비밀번호 없이도 안전하게 로그인할 수 있는 방법을 제공합니다. 또한, SSH는 포트 포워딩을 통해 로컬 및 원격 포트를 연결하고, 안전하지 않은 트래픽을 암호화된 채널을 통해 전송할 수 있는 기능을 제공하여, 더욱 강력한 네트워크 보안 환경을 구축할 수 있습니다.

SSH의 이러한 보안 기능 때문에, 많은 조직과 시스템 관리자들은 민감한 데이터를 처리하거나 중요한 시스템을 관리할 때 SSH를 선호합니다. 이는 네트워크를 통한 관리 작업의 안전성을 크게 향상시키며, 원격 시스템에 대한 신뢰성 있는 접근을 가능하게 합니다.

Telnet과 같은 이전 프로토콜들은 여전히 일부 구식 시스템이나 특정 환경에서 사용되기는 하지만, 보안이 중요한 대부분의 현대적인 환경에서는 SSH가 그 자리를 대체하고 있습니다. Telnet은 간단한 테스트나, 보안이 크게 중요하지 않은 내부 네트워크에서의 사용에 한정되어 사용됩니다.

SSH는 어떻게 작동되는가??

SSH (Secure Shell)는 클라이언트-서버 모델을 기반으로 작동합니다. 여기에는 클라이언트(SSH 클라이언트 프로그램을 실행하는 사용자의 컴퓨터)와 서버(SSH 서버 프로그램을 실행하는 원격 컴퓨터)가 포함됩니다.

작동 과정을 단계별로 설명하면 다음과 같습니다:

연결 설정:
- 클라이언트가 서버에 연결을 시도하며, 서버는 자신의 신원(공개 키)을 클라이언트에게 전송합니다.
- 클라이언트는 이 공개 키를 확인하고 신뢰할 수 있는지 결정합니다. 이전에 연결한 적이 있으면 클라이언트는 known_hosts 파일에서 키를 확인합니다.
인증:
- 클라이언트가 서버의 신원을 확인한 후, 사용자는 서버에 로그인해야 합니다. 이때 사용자 이름과 비밀번호, 공개 키 인증, 또는 다른 인증 방법을 사용할 수 있습니다.
- 공개 키 인증을 사용하는 경우, 클라이언트는 개인 키를 사용하여 인증 요청에 서명하고, 서버는 해당 사용자의 공개 키로 서명을 검증합니다.
암호화된 세션:
- 인증이 성공하면, 클라이언트와 서버는 대칭 키를 사용하여 세션 데이터를 암호화하기 위한 안전한 채널을 협상합니다. 이 대칭 키는 세션 동안만 유효하며, 일반적으로 매 세션마다 새로 생성됩니다.
- 이후 모든 통신은 이 대칭 키를 사용하여 암호화되어 전송됩니다.
데이터 전송:
- 세션 암호화가 설정되면, 클라이언트는 명령어를 서버로 전송할 수 있고, 서버는 그 결과를 클라이언트로 반환합니다.
- 파일 전송은 SFTP(SSH File Transfer Protocol) 또는 SCP(Secure Copy Protocol)를 통해 암호화된 형태로 이루어집니다.

이러한 과정은 사용자와 서버 간의 모든 데이터가 노출 없이 안전하게 전송될 수 있도록 보장합니다.

예를들어 코딩으로 예시를 든다면 다음과 같다

---------------------------------------------------------------------------

클라이언트 -> 서버: 연결 요청
서버 -> 클라이언트: 공개 키 전송

if 클라이언트가 서버 키를 신뢰한다면
    클라이언트 -> 서버: 인증 정보 전송(비밀번호 또는 개인 키 서명)
    if 서버가 인증을 승인한다면
        양쪽은 대칭 키를 생성하여 세션 암호화
        클라이언트와 서버 간에 암호화된 데이터 통신이 시작됨
    else
        연결 실패
else
    연결 실패

---------------------------------------------------------------------------

VirtualBox으로 리눅스 네트워크 구성

Pyidros — Thu, 29 Feb 2024 18:05:16 +0900

VirtualBox에서 리눅스와 같은 가상 환경을 실행할 때 네트워크 구성을 위한 여러 가지 옵션이 있습니다. 각각의 네트워크 구성 옵션은 다음과 같은 특징과 장점을 가지고 있습니다:

NAT (Network Address Translation)

NAT (Network Address Translation):

특징: NAT 모드는 VirtualBox가 가상 머신의 네트워크 인터페이스를 호스트 시스템의 NAT 엔진에 연결하여 인터넷에 액세스할 수 있도록 합니다. 가상 머신은 프라이빗 내부 네트워크에서 동작하고, 호스트 시스템을 통해 외부 네트워크와 통신합니다.
장점: 쉽게 설정할 수 있고, 추가적인 네트워크 구성 없이 가상 머신에 인터넷 액세스를 제공할 수 있습니다. 또한, 가상 머신이 호스트 네트워크에 직접 노출되지 않아 보안 측면에서 이점을 가집니다.

NAT Network

NAT Network:

특징: NAT 네트워크는 여러 가상 머신이 동일한 내부 네트워크에 속하게 하여 서로 통신할 수 있도록 해주며, 동시에 인터넷에도 접속할 수 있게 합니다.
장점: NAT 모드의 모든 장점을 가지면서, 가상 머신 간 네트워크 통신을 가능하게 합니다.

Bridged Adapter

Bridged Adapter:

특징: 브리지 모드는 가상 머신을 호스트의 네트워크에 마치 실제 컴퓨터처럼 연결합니다. 가상 머신은 호스트 머신과 동일한 물리적 네트워크 내에서 고유한 IP 주소를 가집니다.
장점: 가상 머신이 호스트 네트워크의 일부로서 다른 네트워크 디바이스와 직접 통신할 수 있으며, 네트워크 상의 다른 기기들에게 보이게 할 수 있습니다.

Host-only Adapter

Host-only Adapter:

특징: 호스트-온리 어댑터는 가상 머신이 호스트와만 통신할 수 있도록 하는 사설 네트워크를 생성합니다. 외부 네트워크와는 격리되어 있습니다.
장점: 가상 머신과 호스트 간의 네트워크 트래픽이 필요할 때 사용하며, 가상 머신을 외부 네트워크로부터 분리하여 보안을 강화할 수 있습니다.

Internal Network

Internal Network:

특징: 내부 네트워크는 가상 머신들 사이에서만 통신할 수 있는 완전히 격리된 네트워크를 만듭니다. 호스트 머신 또는 인터넷과는 연결되지 않습니다.
장점: 테스트 환경에서 여러 가상 머신들 간의 네트워크를 구성하고 싶을 때 유용합니다.

각각의 네트워크 모드는 상황에 따라 적합한 사용 사례가 있으므로, 사용자의 요구사항에 맞게 적절한 옵션을 선택해야 합니다. 예를 들어, 개발 환경에서는 Host-only나 Internal Network를 사용하여 외부 네트워크로부각각의 네트워크 설정은 사용자의 특정 요구에 따라 다른 환경에서 활용될 수 있습니다. 개발 환경에서는 호스트와만 통신이 필요할 경우 호스트-온리 어댑터를, 외부 인터넷 연결이 필요하지 않은 내부 테스트 네트워크 구성이 필요할 때 내부 네트워크를 사용할 수 있습니다. 가상 머신을 마치 실제 네트워크의 일부인 것처럼 사용해야 할 때는 브리지 어댑터를 사용하고, 간단히 인터넷 연결만 필요할 때는 NAT를 사용합니다. NAT 네트워크는 여러 가상 머신이 서로 통신하면서도 인터넷에 연결되어야 할 때 유용합니다.

이러한 각각의 설정은 가상화 환경에서의 네트워킹 요구사항을 충족하기 위해 고안되었으며, 상황에 맞게 선택하여 사용하면 됩니다.

OCI와CRI의 개념 그리고 차이

Pyidros — Tue, 27 Feb 2024 23:31:37 +0900

OCI(Open Container Initiative)와 CRI(Container Runtime Interface)는 컨테이너 기술에서 중요한 역할을 하는 두 가지 다른 표준입니다.

OCI (Open Container Initiative)

OCI는 컨테이너 형식과 런타임의 표준화를 목표로 하는 개방형 프로젝트입니다. 이 표준은 컨테이너가 다양한 환경에서 일관되게 동작할 수 있도록 보장하는 것을 목적으로 하며, 컨테이너 이미지 형식과 컨테이너 실행을 위한 런타임 사양 두 가지 주요 구성 요소로 이루어져 있습니다.

Image Specification: 컨테이너 이미지가 어떻게 구성되어야 하는지에 대한 사양을 제공합니다. 이를 통해 이미지가 다양한 환경과 호환될 수 있습니다.
Runtime Specification: 컨테이너를 실행하기 위한 환경(런타임)이 준수해야 하는 기술 사양을 정의합니다. 이는 컨테이너가 실제로 어떻게 생성되고 관리되어야 하는지에 대한 세부사항을 포함합니다.

OCI의 목표는 컨테이너 기술의 표준화를 통해 개발자들이 벤더에 종속되지 않고 컨테이너를 사용할 수 있게 하는 것입니다. 즉, OCI 표준을 준수하는 컨테이너는 어떤 호스트 시스템에서든 동일하게 작동해야 합니다.

CRI (Container Runtime Interface)

CRI는 특히 Kubernetes에서 컨테이너 런타임을 플러그 가능하게 하기 위해 도입된 인터페이스입니다. CRI는 Kubernetes가 다양한 컨테이너 런타임과 상호 작용할 수 있도록 표준화된 방식을 제공합니다. 예를 들어, Docker는 CRI를 통해 Kubernetes와 통신할 수 있고, 이는 Kubernetes가 Docker 외에 다른 CRI를 구현한 런타임(예: containerd, CRI-O 등)과도 호환될 수 있도록 합니다.

CRI는 주로 두 가지 API로 구성됩니다: 이미지와 컨테이너 관리입니다. 이를 통해 Kubernetes 오케스트레이터는 컨테이너의 생명 주기를 관리할 수 있으며, 이미지를 가져오고, 컨테이너를 시작하고, 정지시키는 등의 작업을 수행할 수 있습니다.

차이점 및 특징

범위: OCI는 컨테이너 이미지와 런타임의 보편적인 표준을 정의하는 반면, CRI는 Kubernetes와 컨테이너 런타임 간의 인터페이스에 초점을 맞춥니다.
목적: OCI는 컨테이너의 휴대성과 호환성을 보장하는 반면, CRI는 Kubernetes 내부의 컨테이너 런타임 통합을 목적으로 합니다.
사용 사례: OCI는 모든 컨테이너 환경에 적용 가능한 반면, CRI는 Kubernetes 클러스터 내에서 사용됩니다.

OCI와 CRI 모두 컨테이너 기술의 표준화를 추진하는 중요한 역할을 하지만, 각각의 범위와 적용 분야가 다릅니다. OCI는 컨테이너 기술 전반에 걸쳐 표준을 제공하는 반면, CRI는 Kubernetes가 다양한 컨테이너 런타임과 상호 작용하는 방식을 표준화하는데 중점을 둡니다.

# 인터페이스란 : 인터페이스는 서로 다른 두 시스템이나 프로그램이 상호 작용하는 방식을 정의합니다

# 플러그 가능이란 : 특정 컴포넌트를 시스템에 추가하거나 제거할 수 있는 기능을 의미합니다.