mingming

Jenkins Helm Chart 기동 구조 분석

mingming_96 — Sun, 22 Mar 2026 23:21:09 +0900

Jenkins를 Helm으로 배포하고 운영하다 보면 한 번쯤 이런 의문이 생깁니다. Pod가 재시작될 때 플러그인은 어디서 오는 걸까? ConfigMap은 어떻게 Jenkins에 반영되는 걸까?

이 글에서는 jenkinsci/jenkins Helm Chart를 기반으로 Jenkins Pod가 기동될 때의 전체 흐름을 단계별로 분석합니다.

1. 전체 Pod 구성

Jenkins Helm Chart는 하나의 Pod 안에 아래와 같은 컨테이너 구조로 구성됩니다.

Pod: jenkins-0 (StatefulSet)
├── initContainer: copy-default-config   ← 기동 전 준비 작업
├── container:     jenkins               ← 메인 Jenkins 프로세스
└── container:     config-reload (선택)  ← JCasC 자동 리로드 사이드카

StatefulSet으로 배포되기 때문에 Pod 이름은 항상 <release>-0으로 고정됩니다. initContainer가 완료되어야만 메인 컨테이너가 기동됩니다.

2. 생성되는 Kubernetes 리소스

helm install 시 생성되는 주요 리소스 목록입니다.

리소스	이름	용도
StatefulSet	`<release>`	Jenkins Controller Pod 관리
ConfigMap	`<release>`	apply_config.sh, plugins.txt, jvm-options 등
ConfigMap	`<release>-jenkins-jcasc-config`	JCasC 기본 보안/권한 설정
ConfigMap	`<release>-jenkins-config-<key>`	configScripts 항목별 JCasC yaml
Secret	`<release>`	admin 계정 username / password
ServiceAccount	`<release>`	Jenkins RBAC 권한
PVC	`<release>`	jenkins_home 영구 저장소
Service	`<release>`	8080 (UI), 50000 (Agent 연결)

3. 볼륨 구성

initContainer와 메인 컨테이너가 공유하는 볼륨 구조입니다. 어떤 볼륨이 재시작 후에도 살아남는지 파악하는 것이 중요합니다.

볼륨명	타입	initContainer 마운트	메인 컨테이너 마운트	데이터 유지
`jenkins-home`	PVC	`/var/jenkins_home`	`/var/jenkins_home`	✅ 영구
`jenkins-config`	ConfigMap (읽기전용)	`/var/jenkins_config`	—	✅ ConfigMap 기준
`plugin-dir`	emptyDir	`/var/jenkins_plugins`	`/usr/share/jenkins/ref/plugins`	❌ 재시작 시 초기화
`secrets-dir`	emptyDir	`/usr/share/jenkins/ref/secrets`	`/usr/share/jenkins/ref/secrets`	❌ 재시작 시 초기화
`sc-config-volume`	emptyDir	—	`/var/jenkins_home/casc_configs`	❌ 재시작 시 초기화

plugin-dir은 emptyDir입니다. Pod가 재시작될 때마다 비워지기 때문에 매 기동 시 initContainer가 plugins.txt를 다시 읽어 플러그인을 전부 새로 설치합니다.

4. initContainer 상세 분석

4.1 기본 정보

initContainer는 메인 컨테이너와 동일한 이미지를 사용하며, ConfigMap에 저장된 쉘 스크립트를 실행합니다.

name:    copy-default-config
image:   jenkins/jenkins:lts
command: ["sh", "/var/jenkins_config/apply_config.sh"]

4.2 주입되는 환경 변수

env:
  # Secret에서 주입
  - name: ADMIN_PASSWORD
    valueFrom:
      secretKeyRef:
        name: <release>
        key:  jenkins-admin-password

  - name: ADMIN_USER
    valueFrom:
      secretKeyRef:
        name: <release>
        key:  jenkins-admin-user

  # values.yaml에서 주입
  - name: JENKINS_VERSION   # Setup Wizard 비활성화에 사용
    value: "2.x.x"

  - name: JAVA_OPTS         # controller.javaOpts
    value: "-Xmx512m ..."

  - name: JENKINS_OPTS      # controller.jenkinsOpts
    value: "..."

4.3 apply_config.sh 실행 흐름

Step 1 — Setup Wizard 비활성화

JCasC 환경에서 최초 기동 시 나타나는 Setup Wizard를 건너뛰기 위해 버전 파일을 미리 생성합니다.

echo $JENKINS_VERSION > /var/jenkins_home/jenkins.install.UpgradeWizard.state
echo $JENKINS_VERSION > /var/jenkins_home/jenkins.install.InstallUtil.lastExecVersion

Step 2 — plugins.txt 복사 (ConfigMap → PVC)

ConfigMap에 있는 plugins.txt를 PVC로 복사합니다. 이전 실행에서 남은 .lock 파일도 함께 제거합니다.

cp /var/jenkins_config/plugins.txt /var/jenkins_home
rm -rf /usr/share/jenkins/ref/plugins/*.lock

Step 3 — 플러그인 설치 (jenkins-plugin-cli)

jenkins-plugin-cli 버전에 따라 두 가지 방식으로 분기합니다.

# jenkins-plugin-cli v2.1.1 이상 (신버전)
jenkins-plugin-cli \
  --war "/usr/share/jenkins/jenkins.war" \
  --plugin-file "/var/jenkins_home/plugins.txt" \
  --latest true

# v2.1.1 미만 (구버전 폴백)
/usr/local/bin/install-plugins.sh $(cat /var/jenkins_home/plugins.txt)

Update Center를 참조하여 의존성을 재귀적으로 해결하며, 버전 충돌 시 높은 버전으로 자동 대체됩니다.

Step 4 — plugin-dir(emptyDir)로 플러그인 복사

설치된 플러그인을 메인 컨테이너가 읽을 수 있는 공유 볼륨으로 복사합니다.

yes n | cp -i /usr/share/jenkins/ref/plugins/* /var/jenkins_plugins/

5. 메인 컨테이너 기동 순서

initContainer가 exit 0으로 종료된 후 메인 Jenkins 컨테이너가 기동됩니다.

순서	작업	비고
1	JVM 기동	JAVA_OPTS, JENKINS_OPTS 적용
2	플러그인 로드	`/usr/share/jenkins/ref/plugins/`
3	JCasC 설정 적용	`/var/jenkins_home/casc_configs/` 내 yaml 전체 읽기
4	Probe 통과	HTTP GET /login → 200 OK 확인 후 트래픽 허용

플러그인 의존성 충돌은 2번 단계에서 Jenkins가 죽습니다. kubectl logs <pod> -c jenkins에서 오류를 확인하세요.

6. JCasC(Jenkins Configuration as Code) 적용 구조

6.1 ConfigMap 생성 구조

values.yaml의 controller.JCasC.configScripts 항목들은 각각 독립적인 ConfigMap으로 생성됩니다.

controller:
  JCasC:
    configScripts:
      welcome-message: |
        jenkins:
          systemMessage: "Hello Jenkins"
      credentials: |
        credentials:
          system: ...

6.2 Pod 내 마운트 경로

/var/jenkins_home/casc_configs/
  ├── welcome-message.yaml      ← ConfigMap에서 마운트
  ├── credentials.yaml          ← ConfigMap에서 마운트
  └── jcasc-default-config.yaml ← 기본 보안/권한 설정

6.3 configAutoReload 사이드카

controller.sidecars.configAutoReload.enabled: true로 설정하면 사이드카 컨테이너가 추가됩니다.

사이드카는 ConfigMap 변경을 감지하면 yaml을 casc_configs/에 복사하고 리로드를 요청합니다. Jenkins 재기동 없이 설정 변경이 반영됩니다.

7. Secret 및 Credential 주입 구조

7.1 Admin 계정 Secret

controller:
  adminUser:     "admin"
  adminPassword: "password"

7.2 추가 Secret 마운트

controller:
  additionalSecrets:
    - name:  github-token
      value: "ghp_xxx"

  additionalExistingSecrets:
    - name:    my-k8s-secret
      keyName: db-password

Pod의 /run/secrets/ 경로에 마운트되며, JCasC에서 ${github-token} 형식으로 참조할 수 있습니다.

8. 기동 실패 주요 원인

원인	증상	확인 방법
플러그인 의존성 충돌	initContainer CrashLoopBackOff	`kubectl logs <pod> -c copy-default-config`
PVC 마운트 실패	Pod Pending 상태 지속	`kubectl describe pod <pod>` Events 확인
Update Center 연결 실패	플러그인 다운로드 타임아웃	initContainer 로그에서 connection refused 확인
JCasC yaml 문법 오류	Jenkins 기동 후 즉시 재시작	`kubectl logs <pod> -c jenkins`
Secret 누락	initContainer Error 즉시 종료	`kubectl describe pod` Events 확인

주요 확인 명령어

# initContainer 로그
kubectl logs <pod> -c copy-default-config -n <namespace>

# 메인 컨테이너 로그
kubectl logs <pod> -c jenkins -n <namespace>

# 사이드카 로그
kubectl logs <pod> -c config-reload -n <namespace>

# Pod 전체 이벤트
kubectl describe pod <pod> -n <namespace>

# rollout 상태 확인
kubectl rollout status statefulset/jenkins -n <namespace>

9. 전체 기동 흐름 요약

지금까지 살펴본 내용을 단계별로 정리하면 다음과 같습니다.

Phase 1 — 리소스 준비

단계	내용
Helm install/upgrade	Chart 렌더링 후 K8s 리소스 apply
ConfigMap 생성/업데이트	apply_config.sh, plugins.txt, JCasC yaml
Secret 생성/업데이트	admin 계정, 추가 credentials
PVC 바인딩	jenkins_home 영구 볼륨 확보

Phase 2 — initContainer (copy-default-config)

순서	작업	관련 볼륨
1	Setup Wizard 비활성화 파일 생성	jenkins-home (PVC)
2	ConfigMap → PVC로 plugins.txt 복사	jenkins-config, jenkins-home
3	jenkins-plugin-cli로 플러그인 다운로드	Update Center 네트워크 통신
4	설치된 플러그인을 plugin-dir에 복사	plugin-dir (emptyDir)

Phase 3 — 메인 컨테이너 (jenkins)

순서	작업	관련 볼륨
5	JVM 기동 (JAVA_OPTS, JENKINS_OPTS 적용)	—
6	plugin-dir에서 플러그인 로드	plugin-dir (emptyDir)
7	casc_configs/ 읽어 JCasC 설정 적용	sc-config-volume (emptyDir)
8	Liveness / Readiness Probe 통과	—

Phase 4 — 사이드카 (config-reload, 선택)

순서	작업
9	Kubernetes Watch API로 ConfigMap 변경 감시 시작
10	변경 감지 시 yaml을 casc_configs/에 복사 후 Jenkins에 리로드 요청

Windows Server KMS 호스트 등록

mingming_96 — Sun, 1 Feb 2026 02:03:40 +0900

Windows 라이선스는 종류와 인증 방식에 따라 적용 방법이 크게 달라지며, 이를 충분히 이해하지 못한 상태에서 KMS를 구성할 경우 인증 오류나 운영상의 제약이 발생할 수 있습니다. 이에 따라 본 문서에서는 다음과 같은 순서로 내용을 정리하였습니다.

Windows 라이선스 종류
Microsoft 라이선스 인증 채널 유형
KMS 인증 구조
KMS 호스트 등록 절차
제약사항 및 한계
slmgr 명령어 사용 예시
KMS 호스트 버전별 지원 범위
KMS 인증 시 자주 발생하는 오류 코드 및 해결법

1. Windows 라이선스 종류

Windows Server 및 Windows Client 라이선스는 크게 다음과 같은 유형으로 구분됩니다.

1.1 Retail (FPP, Full Packaged Product)

개인 또는 소규모 환경을 대상으로 제공되는 라이선스입니다.
제품 키를 입력하여 Microsoft 인증 서버와 직접 통신하는 방식으로 활성화됩니다.
일정 조건을 충족할 경우 다른 장비로 이전이 가능합니다.
KMS 및 MAK 인증 방식은 사용할 수 없습니다.

1.2 OEM (Original Equipment Manufacturer)

서버 또는 PC 구매 시 하드웨어와 함께 제공되는 라이선스입니다.
BIOS/UEFI에 제품 키가 내장되어 있습니다.
하드웨어에 종속되며 다른 장비로 이전할 수 없습니다.
KMS 인증 방식은 사용할 수 없습니다.

1.3 Volume License (볼륨 라이선스)

기업 및 공공기관 환경을 대상으로 제공되는 라이선스입니다.
다수의 서버 및 클라이언트를 효율적으로 관리하기 위한 목적의 라이선스입니다.
KMS 또는 MAK 인증 방식을 사용할 수 있습니다.

KMS 호스트는 반드시 Volume License 환경에서만 구성 가능합니다.

2. Microsoft 라이선스 인증 채널 유형

Windows 라이선스는 라이선스 종류와 별도로 인증 채널(Activation Channel) 에 따라 활성화 방식이 구분됩니다. 주요 인증 채널은 Retail, MAK, KMS 세 가지입니다.

2.1 Retail 인증 채널

Retail(FPP) 라이선스에서 사용하는 인증 채널입니다.
제품 키를 입력하면 Microsoft 인증 서버와 직접 통신하여 활성화됩니다.
장비 1대당 1개의 라이선스가 적용됩니다.
기업 환경에서의 중앙 집중식 라이선스 관리는 제공되지 않습니다.

특징

인터넷 연결 필수
개별 장비 단위 인증
KMS 또는 MAK 전환 불가

2.2 MAK (Multiple Activation Key)

볼륨 라이선스 환경에서 사용하는 인증 채널입니다.
각 시스템이 Microsoft 인증 서버와 직접 통신하여 활성화합니다.
활성화 횟수에 제한이 존재합니다.
운영체제 재설치 시 인증 횟수가 추가로 차감될 수 있습니다.

적합한 환경

서버 또는 클라이언트 수량이 많지 않은 환경
중앙 집중식 라이선스 관리가 필요하지 않은 환경

2.3 KMS (Key Management Service)

볼륨 라이선스 환경에서 사용하는 인증 채널입니다.
내부 네트워크에 KMS 호스트 서버를 구성하여 인증을 수행합니다.
클라이언트는 KMS 호스트를 통해 라이선스를 인증받습니다.
일정 주기마다 자동으로 재인증이 수행됩니다.

적합한 환경

다수의 Windows Server 및 Client를 운영하는 환경
내부망 기반의 중앙 집중형 라이선스 관리가 필요한 환경

3. KMS 인증 구조

KMS 환경은 다음과 같은 구성 요소로 동작합니다.

3.1 KMS 호스트

Microsoft에서 발급한 KMS Host Key를 설치합니다.
내부 클라이언트의 인증 요청을 처리합니다.
최초 1회 Microsoft 인증 서버와의 통신이 필요합니다.

3.2 KMS 클라이언트

GVLK(Generic Volume License Key)를 사용하여 인증을 수행합니다.
DNS를 통해 KMS 호스트를 검색한 후 인증을 진행합니다.
일정 주기마다 KMS 호스트에 재인증을 요청합니다.

KMS 인증은 최소 활성화 수(Minimum Activation Threshold) 조건을 충족해야 정상적으로 수행됩니다.

4. KMS 호스트 등록 절차

4.1 사전 준비 사항

Microsoft Volume License 계약 체결
VLSC(Volume Licensing Service Center) 계정 보유
KMS Host Key 확보
KMS 호스트 역할을 수행할 Windows Server

4.2 KMS Host Key 설치

KMS 호스트로 사용할 Windows Server에서 관리자 권한 명령 프롬프트를 실행한 후 아래 명령어를 입력합니다.

slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

4.3 KMS 호스트 활성화

slmgr /ato

KMS 호스트 자체를 Microsoft 서버에 활성화합니다.
최초 1회 인터넷 연결이 필요합니다.

4.4 KMS 상태 확인

slmgr /dlv

아래 항목을 중심으로 상태를 확인합니다.

License Status
KMS 활성화 여부
Current Count (현재 인증 요청 수)

4.5 DNS 설정 확인

KMS 인증은 기본적으로 DNS SRV 레코드를 통해 KMS 호스트를 자동으로 검색합니다. 따라서 DNS 설정이 정상적으로 구성되어 있지 않으면 KMS 인증이 실패할 수 있습니다.

4.5.1 DNS SRV 레코드 개요

레코드 이름: _vlmcs._tcp
프로토콜: TCP
포트: 1688
대상 호스트: KMS 호스트 서버

KMS 호스트가 정상적으로 활성화되면, DNS 서버에 SRV 레코드가 자동으로 등록됩니다.

4.5.2 DNS SRV 레코드 확인 방법

DNS 서버에서 다음 명령어를 통해 SRV 레코드 존재 여부를 확인할 수 있습니다.

nslookup -type=SRV _vlmcs._tcp.example.com

정상적인 경우 KMS 호스트 정보와 포트 1688이 조회됩니다.

4.5.3 DNS 자동 등록이 되지 않는 경우

다음과 같은 환경에서는 SRV 레코드가 자동으로 등록되지 않을 수 있습니다.

KMS 호스트가 도메인에 가입되어 있지 않은 경우
DNS 동적 업데이트가 제한된 경우
보안 정책에 의해 SRV 레코드 등록이 차단된 경우

이 경우 DNS 관리자 콘솔에서 SRV 레코드를 수동으로 등록해야 합니다.

SRV 레코드 수동 등록 예시

서비스: _vlmcs
프로토콜: _tcp
포트 번호: 1688
호스트 이름: kms01.example.com

4.5.4 DNS를 사용하지 않는 경우

DNS 기반 자동 탐색을 사용할 수 없는 환경에서는 클라이언트에 KMS 서버를 수동으로 지정할 수 있습니다.

slmgr /skms kms01.example.com:1688

이 방식은 임시 조치 또는 테스트 환경에서만 사용하는 것이 권장됩니다.

5. KMS 클라이언트 설정

KMS 클라이언트는 GVLK를 사용하여 인증을 수행합니다.

slmgr /ipk <GVLK_KEY>
slmgr /ato

DNS SRV 레코드 _vlmcs._tcp를 통해 KMS 호스트를 자동으로 탐색합니다.
필요 시 KMS 서버를 수동으로 지정할 수 있습니다.

6. KMS 제약사항 및 한계

6.1 최소 활성화 수 제한

구분	최소 수량
Windows Client	25대
Windows Server	5대

최소 활성화 수를 충족하지 못할 경우 KMS 인증이 완료되지 않습니다.

6.2 인증 유효 기간

KMS 인증의 유효 기간은 180일입니다.
클라이언트는 7일 주기로 재인증을 시도합니다.
180일 동안 재인증에 실패할 경우 라이선스 만료 상태로 전환됩니다.

6.3 네트워크 및 DNS 의존성

TCP 1688 포트 통신이 필요합니다.
DNS SRV 레코드가 정상적으로 등록되어 있어야 합니다.
방화벽 또는 DNS 장애 발생 시 인증이 실패할 수 있습니다.

6.4 KMS 호스트 장애 영향

KMS 호스트 장애 발생 시 신규 인증이 불가능합니다.
기존 인증은 유효 기간 동안 유지됩니다.
필요에 따라 다중 KMS 호스트 구성이 가능합니다.

7. slmgr 명령어

라이선스 정보 요약 확인

slmgr /dli

라이선스 상세 정보 확인

slmgr /dlv

제품 키 제거

slmgr /upk

KMS 서버 수동 지정

slmgr /skms kms01.example.com:1688

KMS 서버 설정 초기화

slmgr /ckms

8. Windows Server 버전별 KMS 호환성

KMS 호스트는 설치된 Windows Server 버전에 따라 인증 가능한 Windows Server 및 Client 버전이 제한됩니다. 따라서 KMS 호스트 구축 시 호환성을 반드시 고려해야 합니다.

8.1 KMS 호스트와 클라이언트 호환성 개요

상위 버전의 Windows Server KMS 호스트는 하위 버전 Windows를 인증할 수 있습니다.
하위 버전 KMS 호스트는 상위 버전 Windows를 인증할 수 없습니다.

예를 들어, Windows Server 2022 KMS 호스트는 Windows Server 2019/2016 및 Windows 10, 11을 인증할 수 있지만, Windows Server 2016 KMS 호스트는 Windows Server 2022를 인증할 수 없습니다.

8.2 Windows Server KMS 호스트 버전별 지원 범위

아래 표는 Microsoft 공식 문서(KMS 정품 인증 계획) 기준으로 정리한 KMS 호스트와 클라이언트 간 호환성 개요입니다.

핵심 기준: KMS 호스트는 해당 Windows Server 버전을 인식할 수 있는 KMS Host Key를 보유해야 인증이 가능합니다.

KMS 호스트	KMS Host Key	인증 가능 Windows Server	비고
Windows Server 2025	Server 2025 KMS Host Key	2025 / 2022 / 2019 / 2016	최신 호스트, 하위 버전 호환
Windows Server 2022	Server 2022 KMS Host Key	2022 / 2019 / 2016	Server 2025 인증 불가
Windows Server 2019	Server 2019 KMS Host Key	2019 / 2016	상위 버전 인증 불가
Windows Server 2016	Server 2016 KMS Host Key	2016	최소 호환 범위

※ Windows Server 2025는 KMS 클라이언트 OS로는 지원 대상에 포함되지만, 이를 인증하려면 Server 2025를 인식할 수 있는 KMS Host Key 및 호스트 환경이 필요합니다.

https://learn.microsoft.com/ko-kr/windows-server/get-started/kms-activation-planning?tabs=server25

Windows Server에 대한 KMS(키 관리 서비스) 정품 인증 계획

Windows Server에서 KMS(키 관리 서비스) 정품 인증을 계획하는 방법을 알아봅니다.

learn.microsoft.com

9. KMS 인증 시 자주 발생하는 오류 코드 및 해결법

KMS 구성 후 정품 인증 시 발생하는 오류 코드

1. 0xC004F038 (수량 부족)

의미: "인증 서버의 카운트가 부족합니다."
원인: KMS 호스트에 연결된 클라이언트 수가 최소 기준(서버 5대 / 클라이언트 25대)을 넘지 못했습니다.
해결: 더 많은 클라이언트를 연결하여 카운트를 채워야 합니다. (카운트 확인: slmgr /dlv)

2. 0x80070005 (권한 부족)

의미: "액세스가 거부되었습니다."
원인: 명령 프롬프트(CMD)를 '관리자 권한'으로 실행하지 않아 인증 정보를 시스템에 기록하지 못한 경우입니다.
해결: 반드시 CMD를 관리자 권한으로 실행한 뒤 명령어를 입력하세요.

3. 0xC004F074 (연결 실패/시간 초과)

의미: "KMS 호스트를 찾을 수 없거나 연결할 수 없습니다."
원인: 네트워크 문제, 방화벽(1688 포트) 차단, 또는 DNS SRV 레코드가 잘못 설정되어 호스트를 찾지 못하는 경우입니다.
해결: telnet <KMS서버IP> 1688 명령으로 포트 확인 및 DNS의 _vlmcs 레코드를 점검하세요.

4. 0xC004F015 (잘못된 키/버전 미지원)

의미: "라이선스를 활성화할 수 없습니다."
원인: 호스트 버전보다 높은 버전의 클라이언트가 인증을 요청했거나(예: 2012 호스트에 2025 클라이언트), 잘못된 키가 입력된 경우입니다.
해결: KMS 호스트 서버를 최신 버전(Windows Server 2025 등)으로 교체하거나 적절한 호스트 키를 재설치하세요.

5. 0x800705B4 (타임아웃)

의미: "작업 시간이 초과되었습니다."
원인: 인증 서비스(sppsvc)의 응답이 너무 늦어 시스템이 기다려주지 못하고 연결을 끊어버린 경우입니다.
해결: 레지스트리에서 ServicesPipeTimeout 시간을 늘려주거나 서비스를 재시작 후 즉시 시도하세요.

Linux 부팅 실패 후 dracut 모드로 진입했을 때의 복구 과정

mingming_96 — Sun, 18 Jan 2026 05:02:59 +0900

Linux 부팅 실패 후 dracut 모드 진입: initramfs 재생성

서버 재부팅 후 Root Volume을 찾을수 없다는 에러와 함께 dracut 모드로 진입했습니다.
dracut 모드에서 현재 상태 진단 및 복구하는 과정을 공유해보려 합니다.

1. 장애 상황 개요

Netbackup의 WORM 인스턴스 다운 및 재기동 실패
Netbackup 재부팅 후 정상 부팅 실패
부팅 과정에서 dracut emergency mode 진입
루트 파일시스템을 찾지 못했다는 메시지 출력

이 시점에서 가장 큰 혼란은 명확한 원인을 찾지 못한다는 것이었습니다.

2. 장애 발생 환경

2.1 dracut 모드 진입

Entering emergency mode.
dracu:/#

2.2 `/dev/mapper` 상태

ls /dev/mapper

control만 존재
루트 볼륨으로 사용 중이던 Logical Volume이 보이지 않음

➡️ dm_mod는 올라왔지만, LVM을 통해 루트 볼륨을 활성화 하지 못함.

2.3 LVM 명령어 상태

dracut:/# lvs
command not found


dracut:/# pvs
command not found

dracut:/# lvm pvscan
segmentation fault

lvs, pvs, vgs 명령어 자체가 없음
lvm pvscan 실행 시 segmentation fault 발생

이 때문에 처음에는 다음과 같은 가설을 세웠다.

LVM 메타데이터 손상?
디스크 자체 장애?

하지만 이후 분석 결과, 이 가설은 모두 결과에 대한 오해였다.

3. segmentation fault

pvscan 실행 시 발생한 segmentation fault는 매우 위협적으로 보였다.

일반적으로 segmentation fault는 다음과 같은 오류를 의미한다.

잘못된 메모리 접근
손상된 바이너리 또는 라이브러리
불완전한 실행 환경

이번 케이스에서는 LVM 바이너리가 initramfs 내에서 필요한 라이브러리를 정상적으로 로딩하지 못한 상태였고,
그 결과 pvscan이 정상 실행되지 못하며 segmentation fault가 발생한 것이다.

4. 리눅스 부팅 단계에서 무슨 일이 벌어졌나

리눅스 부팅 과정은 크게 다음과 같다.

BIOS/UEFI
→ GRUB
→ Kernel
→ initramfs (dracut)
    ├─ 스토리지 드라이버 로드
    ├─ 디스크 장치 생성 (/dev/sdX, /dev/nvmeX)
    ├─ device-mapper 로드 (dm_mod)
    ├─ LVM 유저스페이스 실행
    │     ├─ pvscan
    │     ├─ VG 활성화
    │     └─ LV 생성
    ├─ root LV 마운트 (/sysroot)
→ systemd

이번 장애는 initramfs 생성 단계의 LVM 유저스페이스 실행 단계에서 실패했다.

initramfs 안에 LVM 관련 바이너리, 필요한 라이브러리 등이 완전하게 포함되지 않은 상태였다.

그 결과 커널은 정상은 로드되었지만 LVM을 통해 루트 볼륨을 활성화하지 못하였다.

5. 근본 원인 분석

이번 장애의 근본 원인은 LVM이나 디스크 자체의 문제가 아니라, initramfs(dracut) 환경이 단독으로 손상되거나 불완전하게 생성된 것이었다.
중요한 점은 커널 업데이트는 전혀 없었다는 사실이다. 그럼에도 불구하고 dracut 단계에서 부팅이 멈춘 이유는, 리눅스 부팅 구조상 커널과 initramfs가 서로 독립적으로 관리되기 때문이다.

5.1 무엇이 깨졌나

커널은 정상적으로 로딩됨
device-mapper 커널 모듈(dm_mod)도 로드됨
initramfs 내부에 있어야 할 LVM 사용자 공간 바이너리 관련 shared library udev rule 일부 가 누락되거나 정상적으로 포함되지 않은 상태

그 결과, 커널은 디스크를 인식했지만 LVM을 통해 루트 Logical Volume을 활성화할 수 없었고, 부팅은 dracut 단계에서 중단되었다.

5.2 왜 이런 일이 발생했나

가능성이 높은 원인은 다음과 같다.

/boot 파티션 공간 부족 상태에서 dracut가 실행됨
lvm2, dracut, systemd 등 관련 패키지 업데이트 중 initramfs 자동 재생성 실패
initramfs 생성 과정 중 전원 차단 또는 강제 재부팅
일시적인 I/O 오류로 인한 initramfs 이미지 손상

이 중 어떤 경우든 공통점은 하나다.

"부팅에 필요한 모든 구성 요소가 포함되지 않은 initramfs가 생성되었다"

이 상태에서는 LVM 명령어가 없거나, 실행되더라도 필요한 라이브러리를 찾지 못해 segmentation fault와 같은 비정상 동작이 발생할 수 있다.

6. 해결 방법 (복구 절차)

6.1 Rescue 모드 진입

OS 설치 ISO로 부팅
Rescue mode 선택
기존 시스템을 /mnt/sysimage에 마운트
/mnt/sysimage 하위에 가상파일시스템 연결

mkdir -p /mnt/sysimage

# root LV 마운트
mount /dev/mapper/root-vol /mnt/sysimage

# mount pseudo-filesystems inside chroot
for i in proc sys dev; do mount -rbind /$i /mnt/sysimage/$i; done

6.2 chroot 진입

chroot /mnt/sysimage /bin/bash

6.3 initramfs 강제 재생성

현재 커널의 initramfs 재생성

dracut -f -v

또는 특정 커널 지정:

dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

➡️ LVM, device-mapper, 필수 라이브러리를 initramfs에 다시 포함

6.4 GRUB 설정 재생성 (안전 확인)

BIOS 환경

grub2-mkconfig -o /boot/grub2/grub.cfg

UEFI 환경

grub2-mkconfig -o /boot/efi/EFI/*/grub.cfg

6.5 재부팅 및 확인

재부팅 후 체크리스트

dracut emergency shell로 떨어지지 않고 정상 부팅되는지
/dev/mapper/root-vol 이 정상적으로 마운트되는지
lsblk, mount, df -h 명령으로 root filesystem 상태 확인
systemctl status를 통해 주요 서비스 정상 기동 여부 확인

7. 정리하며

7.1 디스크도 LVM도 정상인데, 왜 부팅이 되지 않았을까

이번 장애를 겪으면서 가장 혼란스러웠던 점은 디스크와 LVM이 모두 정상임에도 불구하고 OS가 부팅되지 않았다는 사실이었다. 복구 모드에서는 root volume이 정상적으로 보였고, 파일시스템 역시 문제없이 마운트되었다. 그렇다 보니 자연스럽게 “이게 왜 안 올라오지?”라는 의문이 들 수밖에 없었다.

7.2 initramfs의 역할

initramfs는 단순히 부팅에 필요한 파일 묶음이 아니라, 커널이 부팅 초기에 root filesystem에 도달하기 위해 필요한 드라이버와 도구들을 담고 있는 일종의 설계도에 가깝다.

이번 경우에는 이 설계도 안에서 root LVM을 자동으로 활성화하는 과정이 정상적으로 수행되지 않았다. 그 결과 /dev/mapper에는 control 디바이스만 남았고, 커널은 root filesystem을 찾지 못한 채 dracut 단계에서 멈춰 서게 되었다.

7.3 장애의 본질

중요한 점은 이것이 디스크 손상이나 LVM 메타데이터 문제 때문이 아니라, initramfs가 생성되던 시점의 시스템 상태와 실제 재부팅 시점의 상태가 어긋나면서 발생했다는 것이다. 운영자가 의도적으로 작업을 하지 않았더라도, dracut 자동 실행 실패나 시스템 환경 변화로 인해 이러한 불일치는 충분히 발생할 수 있다.

결국 이번 장애의 본질은 “디스크가 없어서”가 아니라, 부팅 단계에서 그 디스크에 도달하지 못했다는 점이었다.

이번 경험을 통해, dracut 모드에서 발생하는 부팅 장애는 단순히 스토리지 가시성만으로 판단해서는 안 되며, initramfs가 부팅 과정에서 어떤 역할을 수행하는지부터 차분히 되짚어보는 것이 가장 빠른 해결로 이어진다는 점을 다시 한 번 확인할 수 있었다.

Windows 메모리 구조

mingming_96 — Sat, 22 Nov 2025 18:12:14 +0900

Windows 메모리 구조

Committed, Working Set, Shared Memory, 반환 가능한 메모리까지

Windows 서버나 VM에서 메모리를 분석하다 보면
Committed, Working Set, Private, Shared 같은 용어들이 헷갈릴 때가 많습니다.
특히 아래와 같은 의문이 자주 생깁니다.

Working Set이 왜 Committed보다 더 클까?
프로세스가 실제로 운영체제에 돌려줄 수 있는 메모리는 어떻게 확인할까?
Committed / Working Set / Private Memory의 관계는 어떻게 되나?

이 글에서는 Windows 메모리 구조를 기반으로
실제 운영 환경에서 메모리를 해석하는 방법을 정리했습니다.

1. Windows 메모리 구조 기본 이해

Windows는 프로세스 메모리를 크게 두 가지로 나눕니다.

✔ Virtual Memory (가상 메모리)

프로세스가 논리적으로 확보한 주소 공간.

✔ Physical Memory (물리 메모리)

RAM에 실제 올라가 있는 페이지.

이 둘을 구분해서 관리하기 때문에 각종 메모리 지표가 따로 존재합니다.

2. Committed Memory란?

Committed Memory = 프로세스가 OS로부터 ‘보장받은 메모리’

반드시 확보되어야 하는 Private 메모리
페이지파일 포함
OS가 마음대로 회수할 수 없는 영역
프로세스 단위 “필수 메모리”

즉, “이건 꼭 필요하니 보장해줘”라고 OS에 요청한 양입니다.

3. Working Set(작업 집합)이란?

Working Set = 실제 RAM에 올라와 있는 물리 메모리 전체

다음 요소들이 모두 포함됩니다.

Private Working Set
Shared Working Set
File-backed pages
Prefetch / Cache pages

즉, 프로세스가 지금 당장 RAM에서 사용 중인 모든 페이지입니다.

4. 왜 Working Set이 Committed보다 클까?

많은 관리자들이 여기서 의문을 가집니다.

✔ Resource Monitor에서 WS > Commit이 나오는 이유

Commit에는 Private 메모리만 포함되지만,
Working Set에는 Shared + File-backed + Private 모두 포함되기 때문입니다.

예시)

Committed	Working Set
1,668 KB	117,040 KB
5,120 KB	18,864 KB
215,324 KB	222,228 KB

이처럼 Working Set이 더 크게 보이는 것은
Shared 메모리가 Process의 WS로 잡혀서 그런 것이며 완전히 정상입니다.

5. Private / Shared / File-backed / Stanby Cache 메모리 차이

구분	설명	회수 가능 여부
Private	프로세스 고유 메모리	△ 가능하지만 제한적
Shared	DLL 등 다른 프로세스와 공유	⭕ 가능
File-backed	파일 매핑 기반	⭕ 가능
Standby Cache	캐시 페이지	⭕ 가능

→ “회수 가능”한 것들이 WS에 포함되므로 WS가 커질 수 있음.

6. 반환 가능한 메모리(Reclaimable Memory)란?

운영체제가 상황에 따라 언제든지 회수(trim)할 수 있는 메모리입니다.

포함되는 영역:

Shared Working Set
File-backed Working Set
Standby list
Modified pages(디스크에 쓰면 회수 가능)

즉, Working Set의 상당 부분은 언제든지 회수 가능한 메모리라는 뜻입니다.

7. 반환 가능한 메모리 확인 방법

❗ Resource Monitor로는 정확한 확인 불가

Resource Monitor는 Private Working Set 표시가 없음
→ 반환 가능한 메모리 계산 자체가 불가능.

정확한 확인은 아래 두 가지 방법으로만 가능합니다.

✔ 방법 1) Process Explorer (가장 정확)

Sysinternals Process Explorer 실행
프로세스를 더블 클릭
아래 항목 확인
- Working Set
- Private Working Set
- Shared Working Set

반환 가능 메모리 = Working Set - Private Working Set

Working Set = 120MB
Private WS = 20MB

→ 반환 가능 메모리 = 100MB

즉, OS가 필요하면 100MB는 바로 회수할 수 있습니다.

✔ 방법 2) Perfmon Counter 사용 (운영 수준)

Process → Working Set
Process → Working Set – Private
Memory → Standby Cache
Memory → Modified Page List

이 조합을 통해 프로세스의 “실제 필요한 메모리”와
“회수 가능한 메모리”를 정확히 구분할 수 있습니다.

8. 메모리 누수 판단 기준

Commit 증가 → Private Memory 증가 → 누수 가능성 높음
Working Set 증가만으로는 누수 판단 불가 (캐시 포함)
Shared WS는 누수와 무관

진짜 위험한 것은 Commit이 끝없이 증가하는 경우입니다.

9. 최종 정리

항목	의미
Committed	프로세스가 예약한 Private 메모리 (반환 불가)
Working Set	현재 RAM에 올라온 전체 메모리
Private Working Set	프로세스가 반드시 필요한 최소 메모리
WS - Private WS	OS가 회수 가능한 메모리

IPSec VPN Phase 1 & Phase 2

mingming_96 — Sun, 12 Oct 2025 04:38:34 +0900

Phase 1: IKE SA 협상 (보안 채널 설정)

1. 목적

Phase 1은 VPN 장비가 서로를 인증하고, 안전한 IKE SA(보안 채널)를 생성하는 단계입니다.
이 IKE SA는 Phase 2에서 실제 데이터 트래픽 보호를 위한 IPSec SA의 기반이 됩니다.

2. 배경 지식

IPSec: Layer3 에서 데이터 암호화 및 인증을 통해 안전한 통신 제공
IKE (Internet Key Exchange): 안전한 키 교환과 SA 생성 프로토콜
HMAC (Hash-based Message Authentication Code): 메시지 무결성 검증용 해시 기반 인증 코드
Diffie-Hellman (DH): 안전한 공유 비밀 키 생성용 공개키 교환 알고리즘

3. 구성 요소

항목	설명	예시
인증 방식	VPN 장치 인증 수단	PSK, Digital Certificate
암호화 알고리즘	데이터 보호	AES-128/192/256, 3DES
해시/무결성	메시지 무결성	SHA-1, SHA-256, MD5
DH 그룹	키 교환 안전 수준	2, 5, 14, 19, 20
IKE Version	프로토콜 버전	IKEv1, IKEv2
LifeTime	SA 유효 기간

4. Phase 1 – IKE SA 협상 과정

4.1 단계 1: Initiation

Initiator → Responder: SA Proposal 전달
포함 정보: 암호화/해시/인증 방식, DH 그룹, LifeTime
Responder → Initiator: 지원 가능한 옵션 선택

4.2 단계 2: DH 키 교환

Initiator와 Responder 상호 공개키 교환 → 공유 비밀 키 생성
Nonce(Ni, Nr) + DH 공개값으로 세션 키 파생
- SK_d: Phase2 데이터 키
- SK_ai/SK_ar: HMAC 키
- SK_ei/SK_er: 암호화 키

4.3 단계 3: 인증

Initiator → Responder
- SK_ei로 암호화, SK_ai로 HMAC 생성
- IDi + AUTH 전송
Responder 처리
- SK_ei 복호화, SK_ai HMAC 검증
Responder → Initiator
- SK_er로 암호화, SK_ar HMAC 생성
- IDr + AUTH 전송
Initiator 처리
- SK_er 복호화, SK_ar HMAC 검증
결과: 상호 인증 완료 → IKE SA 확립

5. Phase 1 메시지 흐름 (IKEv1 Main Mode)

단계	메시지	역할
1	Initiator → Responder: SA 제안	암호화/해시/인증 방식 제시
2	Responder → Initiator: SA 수락	제안 수락, 협상 완료
3	DH + Nonce 상호 교환	공유 비밀 키 계산, SK_* 파생
4	Initiator → Responder: 인증 메시지	ID + AUTH 암호화 전송
5	Responder → Initiator: 인증 메시지	ID + AUTH 암호화 전송
6	Phase 1 완료	IKE SA 확립, Phase 2 준비

Phase 2: IPSec SA 협상 (데이터 보호 채널)

1. 목적

Phase 2는 실제 데이터 트래픽을 암호화하기 위한 IPSec SA를 설정하는 단계입니다.

2. 배경 지식

SPI: 각 SA를 식별하는 고유 번호
Transform Set: 사용할 암호화/인증/PFS 방식 결정
PFS(Perfect Forward Secrecy): DH 재교환으로 이전 키 노출에도 안전한 통신 제공

3. Phase 2 – IPSec SA 협상 과정

3.1 IPSec SA 제안 (Initiator → Responder)

제안 항목: 프로토콜(AH/ESP), 암호화/해시 알고리즘, Lifetime
Phase 1 IKE SA를 이용해 메시지 암호화 + HMAC 무결성 검증

3.2 SA 수락 및 응답 (Responder → Initiator)

제안 중 허용 가능한 옵션 선택
PFS 사용 시 DH 교환 및 Nonce 사용
Phase 1 키(SK_ei, SK_ai 등)로 암호화/무결성 검증

3.3 인증 및 SA 확립

Initiator → Responder
- SK_ei로 암호화, SK_ai로 HMAC 생성
- 이전 단계 교환값(Ni, Nr) 기반 IPSec 세션 키 계산, HASH 전송
Responder 처리
- SK_ei 복호화, SK_ai HMAC 검증
- HASH 확인 → IPSec SA 생성
Responder → Initiator
- SK_er 암호화, SK_ar HMAC 생성
- IDr + 인증 데이터 전송
Initiator 처리
- SK_er 복호화, SK_ar HMAC 검증 → IPSec SA 확립 완료

4. Phase 2 메시지 흐름 (Quick Mode)

단계	메시지	역할
1	Initiator → Responder: IPSec SA 제안	프로토콜(AH/ESP), 암호화/해시 알고리즘, Lifetime 등 제안. Phase 1에서 확립된 IKE SA를 이용해 암호화(HMAC 포함)
2	Responder → Initiator: SA 수락	협상된 IPSec SA 선택, 제안 수락
3	(Optional) DH 교환	PFS 적용 시, 새로운 공유 키 계산
5	Phase 2 완료	상호 인증 완료 및 IPSec SA 확립 → 실제 데이터 트래픽 암호화 가능

요약

Phase 1: IKE SA 생성 → 안전한 제어 채널 확보
Phase 2: IPSec SA 생성 → 실제 데이터 트래픽 암호화
양 단계 모두 암호화, HMAC, Nonce, DH 키를 이용하여 인증, 무결성, 기밀성 확보

Linux 부팅 커널 변경 및 커널 자동 업데이트 방지 설정

mingming_96 — Sun, 5 Oct 2025 22:00:26 +0900

Linux 부팅 커널 변경 및 커널 자동 업데이트 방지 설정

운영 중인 리눅스 서버에서 커널이 자동으로 업데이트되면 예상치 못한 커널 버전 차이로 부팅 장애나 드라이버 호환성 문제가 발생할 수 있습니다.
이 글에서는 다음을 다룹니다.

현재 부팅 커널 확인
부팅 시 사용할 커널 변경
yum update 실행 시 커널 자동 설치 방지

1. 현재 커널 버전 확인

uname -r
5.14.0-570.42.2.el9_6.x86_64

현재 실행 중인 커널 버전을 확인할 수 있습니다.

2. 설치된 커널 목록 확인

rpm -qa | grep kernel

rpm -qa --last | grep kernel
kernel-5.14.0-570.42.2.el9_6.x86_64 Fri 04 Oct 2025 09:14:36 PM KST kernel-5.14.0-362.24.1.el9_3.x86_64 Mon 17 Jun 2024 10:10:55 AM KST

3. 부팅 시 사용할 커널 버전 변경

리눅스는 여러 커널이 설치되어 있을 때, GRUB 부트로더를 통해 어느 커널로 부팅할지 결정합니다.

▶ 현재 부팅 순서 확인

sudo grub2-editenv list
saved_entry=2

▶ 사용 가능한 부팅 커널 목록 확인

CentOS

sudo awk -F\' '/menuentry / {print $2}' /etc/grub2.cfg
Rocky Linux (5.14.0-570.42.2.el9_6.x86_64) Rocky Linux (5.14.0-362.24.1.el9_3.x86_64)

Rocky Linux(RHEL 8이상)

grep '^title' /boot/loader/entries/*.conf | awk -F'title ' '{print $2}'

▶ 기본 부팅 커널 변경

예를 들어, 두 번째 커널(5.14.0-362.24.1)로 부팅하고 싶다면:

sudo grub2-set-default 1 sudo grub2-editenv list
→ saved_entry=1 로 변경되면 성공

이후 재부팅 시 지정된 커널로 부팅됩니다.

4. yum update 시 커널 자동 설치 원리

yum update(또는 dnf update)는 시스템의 모든 패키지 중 최신 버전이 있는 항목을 전부 갱신합니다.
커널(kernel, kernel-core, kernel-modules)도 RPM 패키지이기 때문에 기본적으로 포함됩니다.

sudo yum update -y
실행 시 자동으로 새로운 커널이 설치됩니다.

업데이트 로그 확인
grep -i kernel /var/log/yum.log or /var/log/dnf.log

5. yum update 시 커널 제외 설정

커널 업데이트를 자동으로 포함하지 않게 하려면,
/etc/dnf/dnf.conf 파일을 하기와 같이 수정합니다. (RHEL 8 이상은 dnf가 yum을 대체합니다)

sudo vi /etc/dnf/dnf.conf
exclude=kernel*

yum update 실행 시 커널은 제외됩니다.

일시적으로만 커널 제외하고 싶다면

전역 설정을 바꾸지 않고, 특정 명령에서만 제외할 수도 있습니다.

sudo yum update --exclude=kernel*

6. 추가 팁: 오래된 커널 자동 정리

기본적으로 DNF는 최신 커널 3개만 유지합니다.
이 갯수를 조정하려면 /etc/dnf/dnf.conf 의 아래 항목을 수정합니다.

installonly_limit=3

7. 정리 요약

현재 커널 확인	uname -r	실행 중 커널 버전
설치된 커널 확인	`rpm -qa --last	grep kernel`
부팅 커널 변경	grub2-set-default N	기본 부팅 커널 변경
yum update 시 커널 제외	/etc/dnf/dnf.conf → exclude=kernel*	자동 설치 방지
일시적 제외	yum update --exclude=kernel*	1회성 제외
자동 업데이트 중지	systemctl disable dnf-automatic.timer	자동 커널 업데이트 차단
오래된 커널 정리	installonly_limit=3	커널 유지 개수 제한

Netbackup AWS Integration

mingming_96 — Sat, 27 Sep 2025 20:36:44 +0900

NetBackup Snapshot Manager AWS Cross-Account Integration

AWS에서 서비스를 운영하다 보면, 계정을 하나만 쓰지 않고 여러 개로 나눠 쓰는 경우가 많습니다.
예를 들어, 운영 계정에는 실제 서비스가 돌고, 별도의 보안/백업 계정에서는 모니터링과 로그만 관리하는 식이죠.

바로 Cross-Account Integration을 설정해서, Snapshot Manager가 다른 계정 리소스까지 백업하도록 만드는 방법이 있습니다.

Cross-Account 구조 이해하기

간단히 말해,

Source Account → NetBackup Snapshot Manager가 설치된 계정
Target Account → 실제 보호할 워크로드(EC2, EBS, RDS)가 있는 계정

이 두 계정을 이어주는 게 IAM Role + AssumeRole 입니다.

즉, Source Account의 Snapshot Manager가 Target Account 안에 있는 Role을 “빌려 쓰는” 방식으로 접근하는 거죠.

단계별 설정 방법

1) Target Account에 IAM Role 만들기

먼저 보호 대상 계정에 Role을 하나 만듭니다. 이름은 편하게 NBU_SnapshotRole 정도로 두면 관리하기 좋습니다.

그리고 신뢰 정책(Trust Policy)에 Source Account ID를 넣어줘야 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::PRIMARY_ACCOUNT_ID:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

이렇게 하면 Source Account에서 이 Role을 AssumeRole 할 수 있게 됩니다.

2) Role에 권한 붙이기

Snapshot Manager가 할 수 있는 일이 꽤 많습니다. EC2 스냅샷도 만들고, RDS 백업도 하고, 암호화된 볼륨은 KMS까지 접근해야 하죠.
그래서 Role에 다음과 같은 권한을 붙입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "KMSAccess",
      "Effect": "Allow",
      "Action": [
        "kms:ListKeys",
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyWithoutPlaintext",
        "kms:CreateGrant",
        "kms:ReEncryptTo",
        "kms:ReEncryptFrom",
        "kms:DescribeKey",
        "kms:ListAliases"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RDSBackupRestore",
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBSnapshots",
        "rds:DescribeDBClusters",
        "rds:DescribeDBClusterSnapshots",
        "rds:DeleteDBSnapshot",
        "rds:CreateDBSnapshot",
        "rds:CreateDBClusterSnapshot",
        "rds:ModifyDBSnapshotAttribute",
        "rds:DescribeDBSubnetGroups",
        "rds:DescribeDBInstances",
        "rds:CopyDBSnapshot",
        "rds:CopyDBClusterSnapshot",
        "rds:DescribeDBSnapshotAttributes",
        "rds:DeleteDBClusterSnapshot",
        "rds:ListTagsForResource",
        "rds:AddTagsToResource",
        "rds:ModifyDBInstance",
        "rds:ModifyDBClusterSnapshotAttribute",
        "rds:RestoreDBInstanceFromDBSnapshot",
        "rds:ModifyDBCluster",
        "rds:RestoreDBClusterFromSnapshot",
        "rds:CreateDBInstance",
        "rds:RestoreDBClusterToPointInTime",
        "rds:CreateDBSecurityGroup",
        "rds:CreateDBCluster",
        "rds:RestoreDBInstanceToPointInTime",
        "rds:DescribeDBClusterParameterGroups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "STSAccess",
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EC2SnapshotAndRestore",
      "Effect": "Allow",
      "Action": [
        "ec2:CreateSnapshot",
        "ec2:CreateSnapshots",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus",
        "ec2:ModifySnapshotAttribute",
        "ec2:CopySnapshot",
        "ec2:DescribeSnapshots",
        "ec2:DescribeVolumeStatus",
        "ec2:DescribeVolumes",
        "ec2:RegisterImage",
        "ec2:DeregisterImage",
        "ec2:DescribeVolumeAttribute",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeInstanceAttribute",
        "ec2:DeleteSnapshot",
        "ec2:DescribeRegions",
        "ec2:DescribeAvailabilityZones",
        "ec2:ResetSnapshotAttribute",
        "ec2:DescribeHosts",
        "ec2:DescribeImages",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeNetworkInterfaces",
        "ec2:RunInstances",
        "ec2:AttachNetworkInterface",
        "ec2:DetachVolume",
        "ec2:AttachVolume",
        "ec2:DeleteTags",
        "ec2:CreateTags",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:CreateVolume",
        "ec2:DeleteVolume",
        "ec2:DescribeIamInstanceProfileAssociations",
        "ec2:AssociateIamInstanceProfile",
        "ec2:AssociateAddress",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeInstanceTypeOfferings",
        "ec2:GetEbsEncryptionByDefault",
        "ec2:AuthorizeSecurityGroupEgress",
        "ec2:AuthorizeSecurityGroupIngress"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EBSBackupAndRestore",
      "Effect": "Allow",
      "Action": [
        "ebs:ListSnapshotBlocks",
        "ebs:GetSnapshotBlock",
        "ebs:ListChangedBlocks",
        "ebs:CompleteSnapshot",
        "ebs:PutSnapshotBlock",
        "ebs:StartSnapshot"
      ],
      "Resource": "*"
    },
    {
      "Sid": "IAMInspection",
      "Effect": "Allow",
      "Action": [
        "iam:ListAccountAliases",
        "iam:SimulatePrincipalPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DynamoDBBackupRestore",
      "Effect": "Allow",
      "Action": [
        "dynamodb:ListTables",
        "dynamodb:DescribeTable",
        "dynamodb:CreateTable",
        "dynamodb:BatchWriteItem",
        "dynamodb:DescribeContinuousBackups",
        "dynamodb:ExportTableToPointInTime",
        "dynamodb:DescribeExport",
        "dynamodb:DeleteTable",
        "dynamodb:UpdateTable",
        "dynamodb:UpdateContinuousBackups"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftBackupRestore",
      "Effect": "Allow",
      "Action": [
        "redshift:ListDatabases",
        "redshift:GetClusterCredentialsWithIAM",
        "redshift-data:ExecuteStatement",
        "redshift-data:ListDatabases",
        "redshift-data:GetStatementResult",
        "redshift:DescribeClusters",
        "redshift-data:CancelStatement",
        "redshift:GetClusterCredentials",
        "redshift-data:DescribeStatement"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3AccessForBackup",
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:ListBucket",
        "s3:GetObjectAcl",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:PutObject",
        "s3:PutObjectRetention"
      ],
      "Resource": "*"
    },
    {
      "Sid": "SSMApplicationConsistentSnapshot",
      "Effect": "Allow",
      "Action": [
        "ssm:SendCommand",
        "ssm:DescribeDocument",
        "ssm:DescribeInstanceInformation",
        "ssm:UpdateDocumentDefaultVersion",
        "ssm:UpdateDocument",
        "ssm:CreateDocument",
        "ssm:GetCommandInvocation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EKSClusterOperations",
      "Effect": "Allow",
      "Action": [
        "eks:DescribeNodegroup",
        "eks:DescribeUpdate",
        "eks:UpdateNodegroupConfig",
        "eks:ListClusters",
        "eks:DescribeCluster"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AutoScalingAndSNS",
      "Effect": "Allow",
      "Action": [
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:AttachInstances",
        "autoscaling:DescribeScalingActivities",
        "autoscaling:TerminateInstanceInAutoScalingGroup",
        "sns:Publish",
        "sns:GetTopicAttributes"
      ],
      "Resource": "*"
    }
  ]
}

테스트 단계에서는 Resource: "*" 로 두고, 운영에선 꼭 필요한 리소스 ARN만 넣는 게 더 안전합니다.

3) Source Account에 AssumeRole 권한 주기

이제 NetBackup이 돌아가는 계정에 “저쪽 Role을 AssumeRole 할 수 있다”라는 권한을 줘야 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::TARGET_ACCOUNT_ID:role/ROLE_NAME"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

4) Snapshot Manager에 Cross-Account 등록

이제 NetBackup 콘솔로 가서 Snapshot Manager 설정 메뉴에서

Target Account ID
Role 이름

을 입력해주면 끝입니다.

Assume Role 검증하기

구성이 제대로 됐는지 확인하려면, CLI에서 직접 AssumeRole을 해볼 수 있습니다.

aws sts assume-role \ --role-arn arn:aws:iam::<TARGET_ACCOUNT_ID>:role/NBU_SnapshotRole \ --role-session-name TestNetBackup

정상적으로 AccessKey, SecretKey, SessionToken이 나오면 설정이 성공한 겁니다.

마무리

NetBackup Snapshot Manager로 여러 AWS 계정을 하나의 창구에서 관리하려면,
결국 핵심은 IAM Role과 AssumeRole 설정입니다.

한 번만 제대로 설정해두면, 계정이 여러 개로 쪼개져 있어도 Snapshot Manager가 알아서 스냅샷을 생성하고 관리할 수 있습니다.
복잡해 보이지만 실제로는

Target Account에 Role 만들기
Source Account에서 AssumeRole 허용
Snapshot Manager에 등록

NetBackup Kubernetes 백업

mingming_96 — Sat, 27 Sep 2025 05:52:13 +0900

1) 사전 준비

NetBackup 버전 호환성 확인(Operator 지원 버전). (Veritas 다운로드 포털 / 문서 확인)
kubectl과 helm 사용 가능, 클러스터 Admin 권한 보유
컨테이너 레지스트리 (이미지 Push 권한)
네트워크: Kubernetes 노드 → NetBackup Primary / Media 서버간 통신 (기본 PBX 1556 등 포트 열기). NetBackup은 클라이언트 → 서버 방향으로 PBX(기본 1556) 포트 통신을 사용합니다. (MSDP 등 추가 포트는 기능에 따라 필요).
스토리지: PV를 스냅샷으로 만들 수 있는 StorageClass / VolumeSnapshotClass(CSI) 필요(복구 시 필수).

2) 패키지/이미지 준비

Veritas NetBackup Kubernetes 패키지(예: netbackupkops-<ver>.tar.gz)와 datamover 이미지 파일을 다운로드. Helm 차트 및 이미지가 포함되어 있습니다.
(로컬에서) 이미지를 레지스트리에 등록

# 예시: tar에서 이미지 로드 -> 태깅 -> push
docker load -i veritasnetbackup-datamover-10.3.tar
docker tag veritasnetbackup-datamover:10.3 my-registry.example.com/veritas/datamover:10.3
docker push my-registry.example.com/veritas/datamover:10.3

Helm 차트 위치(예: netbackupkops-helm-chart)를 작업 디렉토리에 준비. values.yaml을 편집할 준비.

(참고: 레지스트리가 사설이면 imagePullSecret 생성 필요.)

Netbackup Helm 차트 구조

netbackupkops-helm-chart/
├── charts
├── Chart.yaml
├── templates
│   ├── deployment.yaml
│   └── _helpers.tpl
└── values.yaml

3) Kubernetes 전제 작업 (네임스페이스/이미지풀시크릿/서비스어카운트/RBAC)

네임스페이스 생성

kubectl create namespace netbackup

이미지 풀 시크릿 (사설 레지스트리용)

kubectl create secret docker-registry nb-regcred \
  --docker-server=my-registry.example.com \
  --docker-username=myuser --docker-password='mypassword' \
  -n netbackup

4) NetBackup (Primary Server)에서 토큰/인증키 생성 & 시크릿 생성

NetBackup Web UI 또는 CLI에서 Kubernetes용 인증 토큰(API key) 을 생성합니다. NetBackup Operator는 이 토큰(또는 API key)과 Primary 서버의 인증서 지문(fingerprint)을 사용해 안전하게 통신합니다.
Kubernetes에 넣을 시크릿 예시:

apiVersion: v1
kind: Secret
metadata:
  name: netbackup-nb-config-deploy-secret
  namespace: netbackup
type: Opaque
stringData:
  apikey: "생성한-API-키-값"
  k8scacert: |

kubectl apply -f nb-config-deploy-secret.yaml -n netbackup

주의: NetBackup 가이드에 따라 토큰은 Base64 인코딩 / fingerprint 포함 등 요구사항이 있으니, 문서의 예시를 그대로 따라야 합니다. (토큰/지문 생성 및 사용 절차는 관리자 가이드를 참고하세요).

5) Volume Snapshot Contorller 설치

1. CRD 배포

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/refs/heads/release-8.2/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/refs/heads/release-8.2/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/refs/heads/release-8.2/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

2. Volume Snapshot Controller 배포

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/refs/heads/release-8.2/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/refs/heads/release-8.2/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml

3. Volume Snapshot Class 배포

# vsc.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete

kubectl apply -f vsc.yaml

6) Helm values.yaml 설정

netbackupkops-helm-chart/values.yaml 주요 항목

netbackupkops:
  containers:
    manager:
      image: "netbackupkopsimage:10.5.1"
      resources:
        limits:
          cpu: 150m
          memory: 600Mi
        requests:
          cpu: 100m
          memory: 500Mi
  kopsPvcStorageClass:
  kopsPvcSize: 10Gi
  pvMountPath: /usr/openv
  imagePullSecrets: []
  # Example to add imagePullSecrets
  # imagePullSecrets:
  # - name: netbackupkops-docker-cred
  fipsMode: DISABLE
  acceleratorTracklogPvcStorageClass: None
  minSizeForAcceleratorTracklogPvc: 50Mi
  hostAliases:
    - hostnames:
      - netbackup-master.local.com
      ip: 10.70.1.151

nbsetup:
  replicas: 1
  containers:
    netbackup_config_pod:
      nbprimaryserver: netbackup-master.local.com
      nbsha256fingerprint: "netbackup-fingerprint"
      k8sCluster: "k8scluster-url"
      k8sPort: 443
      datamoverimage: "datamoverimage:10.5.0.1"
      logLevel: INFO
      storageclassblock: gp3
      volumesnapshotclassblock: csi-aws-vsc
      storageclassfilesystem:
      volumesnapshotclassfilesystem:
  storageMap:
    gp3:
      snapshotClass: csi-aws-vsc
      storageClassForBackupDataMovement: gp3
      storageClassForRestoreFromBackup: gp3

(버전에 따라 netbackupKops 또는 netbackupConfig 등 키명 차이가 있을 수 있으니 values.yaml 기본 파일을 확인해서 복사·수정하세요.)

7) Helm으로 설치

# 로컬 차트 경로로 설치 예시
helm install nb-kops ./netbackupkops-helm-chart -n netbackup --values ./my-values.yaml

# 상태 확인
helm status nb-kops -n netbackup
kubectl get pods -n netbackup
kubectl describe pod <pod-name> -n netbackup
kubectl logs <pod-name> -n netbackup

설치 중 chart가 operator pod, config pod, datamover pod 등을 생성합니다. 배포가 완료되면 NetBackup Web UI에서 “클러스터 추가(Add Cluster)” 절차를 밟아 클러스터를 등록합니다. 등록할 때 operator가 제공하는 토큰/지문 정보를 이용합니다.

8) 설치 검증(핵심 체크포인트)

kubectl get pods -n netbackup — 모든 관련 Pod가 Running 상태인지 확인
kubectl logs <operator-pod> -n netbackup — 에러/예외 로그 확인
NetBackup Web UI: 클러스터가 ‘연결(Connected)’ 상태인지, 자동 자원탐지(autodiscovery)가 정상 동작하는지 확인
샘플 백업 실행(예: NetBackup에서 생성한 K8s 용 Policy로 테스트 백업) 및 복구(restore) 시나리오 테스트
PV snapshot 생성/복구가 제대로 동작하는지 확인 — 이는 스토리지 드라이버(CSI)와 밀접하므로 미리 확인해야 합니다.

9) 자주 발생하는 문제 & 해결 팁

이미지 Pull 실패: imagePullSecrets 누락 또는 레지스트리 인증 오류 → kubectl describe pod / 이벤트 확인
RBAC 권한 오류: Operator가 CRD 또는 VolumeSnapshot 접근 권한이 없을 때 발생 → 필요한 권한 추가(ClusterRole 수정)
토큰/인증서 관련 에러: 토큰 값의 포맷(Base64 등) 또는 Primary 서버의 인증서 지문(fingerprint) 불일치 → 시계(Clock skew)도 확인 필요(토큰/증명서 유효성에 영향).
NetBackup과 통신 불가: 방화벽(1556) 차단, DNS 불일치, 호스트명 해석 문제 → bpclntcmd(클라이언트 유틸)로 NetBackup 관점의 네트워크 상태 확인.

10) (참고) 전통적인 NetBackup 클라이언트 에이전트 설치 — Linux / Windows (간단 요약)

Kubernetes 외에 개별 노드(예: VM/베어메탈)의 NetBackup 클라이언트를 설치할 때는 NetBackup 설치 이미지(ESD/DVD)를 내려받아 로컬 설치 또는 Master에서 push 방식으로 설치할 수 있습니다. UNIX/Linux는 ./install 스크립트 기반 설치, Windows는 Browser.exe 또는 설치 마법사/무인 설치 방식이 제공됩니다. 설치 후 NetBackup 서비스 시작/정지 명령(bpup, nbstop 등)과 bpclntcmd로 연결 상태를 확인합니다.

빠른 명령 모음

# 네임스페이스
kubectl create ns netbackup

# registry credential (사설 레지스트리)
kubectl create secret docker-registry nb-regcred --docker-server=... --docker-username=... --docker-password=... -n netbackup

# API token secret (예시)
kubectl create secret generic nb-config-deploy-secret --from-literal=apikey='PASTE_API_KEY' -n netbackup

# Helm 설치
helm install nb-kops ./netbackupkops-helm-chart -n netbackup --values ./my-values.yaml

# 상태 확인
kubectl get pods -n netbackup
helm status nb-kops -n netbackup
kubectl logs -n netbackup <operator-pod>

참고(주요 근거 문서)

NetBackup Kubernetes Installation and Configuration Guide.
NetBackup for Kubernetes Administrator's Guide (토큰/secret, 업그레이드 지침).
Installing NetBackup using Helm charts (Helm/차트 관련 지침).
NetBackup Network Ports Reference Guide (포트/방화벽).
About NetBackup client installation on UNIX and Linux (클라이언트 설치 방법 요약).

Windows MMC와 CPL

mingming_96 — Sun, 21 Sep 2025 15:13:15 +0900

Windows MMC와 CPL: 관리 도구의 이해 및 자주 쓰는 종류

Windows 환경에서 시스템 관리를 하다 보면 자주 마주치는 두 가지 개념이 있습니다. 바로 MMC와 CPL입니다. 이번 글에서는 이 두 도구가 무엇인지, 각각의 특징과 자주 쓰이는 종류, 차이점을 쉽게 정리해보겠습니다.

1. MMC (Microsoft Management Console)

MMC는 Windows에서 다양한 관리 도구를 통합하여 실행할 수 있는 프레임워크입니다.

개념: 여러 관리 도구를 하나의 콘솔 창에서 실행하도록 해주는 컨테이너
주요 기능:
- Snap-in 기반 구조: 각 관리 도구를 Snap-in 형태로 추가
- 사용자 정의 콘솔 생성 가능: 관리자가 원하는 도구만 모아서 실행 가능
- 정책 관리, 장치 관리, 이벤트 뷰어 등 다양한 관리 기능 제공
사용 예시:
- Event Viewer, Device Manager, Group Policy Management 등을 MMC로 통합
- 예: mmc.exe 실행 후 원하는 Snap-in 추가

1-1. 자주 쓰이는 MMC 종류 (.msc)

Event Viewer (eventvwr.msc) – 시스템/응용 프로그램 로그 확인
Device Manager (devmgmt.msc) – 하드웨어 장치 관리
Group Policy Editor (gpedit.msc) – 로컬 그룹 정책 관리
Computer Management (compmgmt.msc) – 디스크 관리, 서비스, 사용자 계정 통합 관리
Services (services.msc) – 서비스 상태 확인 및 관리
Task Scheduler (taskschd.msc) – 예약 작업 관리

정리: MMC는 Windows 관리 도구를 통합하고 사용자 맞춤형 관리 콘솔을 만드는 프레임워크입니다.

2. CPL (Control Panel Item)

CPL은 Control Panel에서 실행되는 개별 관리 항목 파일입니다. 대부분 .cpl 확장자를 가집니다.

개념: 제어판에서 실행되는 개별 설정 항목
주요 기능:
- 제어판에서 네트워크 설정, 사용자 계정, 전원 옵션 등 개별 설정 항목 관리
- CPL 파일은 실행 시 자체 GUI를 제공
사용 예시:
- control.exe로 제어판 실행 후 CPL 호출 가능
- 예: inetcpl.cpl (인터넷 옵션), ncpa.cpl (네트워크 연결)

2-1. 자주 쓰이는 CPL 종류 (.cpl)

인터넷 옵션 – inetcpl.cpl
네트워크 연결 – ncpa.cpl
전원 옵션 – powercfg.cpl
시스템 속성 – sysdm.cpl
프로그램 추가/제거 – appwiz.cpl
사용자 계정 – nusrmgr.cpl (Windows 10 이전) / 계정 설정은 Control Panel GUI에서 접근 가능
마우스 설정 – main.cpl
디스플레이 설정 – desk.cpl

정리: CPL은 제어판에서 실행되는 개별 관리 설정 파일로, 특정 기능만 담당합니다.

3. MMC와 CPL의 차이

구분	MMC	CPL
개념	관리 도구 통합 콘솔 프레임워크	제어판에서 실행되는 개별 설정 항목
확장자	.msc (Management Console)	.cpl
기능	여러 관리 도구를 통합하여 사용자 정의 콘솔 생성 가능	특정 설정 항목에 대한 GUI 제공
사용 예시	Event Viewer, Device Manager, Group Policy Management	인터넷 옵션, 네트워크 연결, 전원 옵션
사용 방식	Snap-in 추가/삭제로 맞춤형 콘솔 생성	Control Panel이나 명령어로 단독 실행

4. 마무리

Windows에서 시스템 관리 시 MMC와 CPL의 역할을 이해하면 도구 선택이 훨씬 쉬워집니다.

MMC: 여러 도구를 통합하여 관리할 때 사용
CPL: 특정 제어판 설정을 빠르게 실행할 때 사용

즉, MMC는 관리 도구 통합 콘솔이고, CPL은 제어판 개별 항목이라고 생각하면 이해가 쉽습니다.

REST API와 SOAP

mingming_96 — Sat, 20 Sep 2025 21:14:39 +0900

REST API와 SOAP: 역사, 개념, 특징, 그리고 차이점

API는 오늘날 소프트웨어 개발에서 빠질 수 없는 핵심 요소입니다. 그중에서도 가장 많이 비교되는 두 가지 방식이 바로 SOAP과 REST입니다. 이번 글에서는 두 방식의 역사와 개념, 특징을 살펴보고 어떤 차이가 있는지 정리해 보겠습니다.

1. API 역사 속 SOAP과 REST의 등장

SOAP의 등장

SOAP(Simple Object Access Protocol)은 1998년 Microsoft와 IBM을 중심으로 등장했습니다.
당시에는 기업 시스템 간 연동이 중요한 시대였고, 서로 다른 플랫폼(Java, .NET, C++ 등)을 사용하는 환경에서도 안정적이고 신뢰성 있는 통신 방식이 필요했습니다.

SOAP은 이러한 요구를 충족하기 위해 만들어졌으며, 보안(WS-Security), 트랜잭션 보장 같은 기능이 내장되어 있어 은행·정부·대기업의 엔터프라이즈 시스템에서 널리 사용되었습니다.

REST의 등장

REST(Representational State Transfer)는 2000년 Roy Fielding(HTTP 프로토콜 공동 설계자)의 박사 논문에서 처음 제시되었습니다.
SOAP의 복잡성과 무거움을 극복하기 위해, 웹 친화적이고 단순한 아키텍처 스타일을 제안한 것입니다.

REST는 이후 웹 2.0 시대와 모바일 서비스 확산과 함께 급속히 자리잡았고, JSON 기반 응답을 활용하며 현재는 인터넷 서비스의 표준 API로 자리매김했습니다.

2. SOAP API 개념과 특징

SOAP은 XML 기반 메시징 프로토콜로, 엄격한 표준화를 통해 다양한 환경에서 일관된 통신을 제공합니다.

데이터 포맷: XML 고정
API 정의: WSDL(Web Services Description Language)로 인터페이스 정의
프로토콜 지원: HTTP뿐 아니라 SMTP, TCP 등 다양한 프로토콜 사용 가능
특징:
- WS-Security, 트랜잭션 보장 등 고급 기능 내장
- 엔터프라이즈 환경에서 안정성과 보안성이 뛰어남
- 무거운 이유:
  - XML 기반 메시지는 구조가 복잡하고, 네임스페이스·태그가 많아 데이터 크기가 커짐
  - SOAP 헤더, WS-Security, 트랜잭션 관련 정보가 포함되어 요청/응답 메시지가 커짐
  - 여러 프로토콜과 기능을 지원하다 보니 처리 로직이 복잡하고 서버 부담 증가

SOAP 요청/응답 예시

<!-- SOAP 요청 -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:usr="http://example.com/user">
   <soapenv:Header/>
   <soapenv:Body>
      <usr:GetUser>
         <usr:UserId>123</usr:UserId>
      </usr:GetUser>
   </soapenv:Body>
</soapenv:Envelope>

<!-- SOAP 응답 -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <GetUserResponse>
         <User>
            <Id>123</Id>
            <Name>홍길동</Name>
            <Email>hong@example.com</Email>
         </User>
      </GetUserResponse>
   </soapenv:Body>
</soapenv:Envelope>

3. REST API 개념과 특징

REST는 웹의 설계 원칙을 따른 아키텍처 스타일로, 가볍고 단순한 접근 방식을 제공합니다.

데이터 포맷: JSON, XML, YAML 등 자유롭게 선택 가능 (JSON이 주류)
리소스 표현: URL로 리소스 식별 (/users/1)
HTTP 메서드 활용: GET, POST, PUT, DELETE 등 표준 메서드 사용
특징:
- Stateless 구조 (서버가 클라이언트 상태를 기억하지 않음)
- 단순하고 빠르며, 웹·모바일 환경에 최적화
- 경량화된 이유:
  - JSON 사용으로 데이터 구조가 간단하고 용량이 작음
  - 불필요한 헤더와 기능이 없고, 트랜잭션/보안 관련 정보는 최소화
  - HTTP 표준만 활용해 메시지 처리 로직이 단순

REST 요청/응답 예시

# REST 요청 (GET)
GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

// REST 응답 (JSON)
{
  "id": 123,
  "name": "홍길동",
  "email": "hong@example.com"
}

4. SOAP vs REST 비교

구분	SOAP	REST
등장 시기	1998년 (MS, IBM 주도)	2000년 (Roy Fielding 논문)
데이터 포맷	XML 고정	JSON, XML, YAML 등 자유
프로토콜	HTTP, SMTP, TCP 등	HTTP 기반
복잡성	복잡하고 무겁다	단순하고 가볍다
보안/트랜잭션	WS-Security, 트랜잭션 지원	별도 구현 필요
주 사용처	금융, 정부, 대기업 엔터프라이즈	웹/모바일, 오픈 API
상태 관리	Stateful 가능	Stateless 기본 원칙

5. 마무리

SOAP과 REST는 등장 배경부터 철학이 다릅니다.

SOAP은 안정성과 보안을 중시하는 엔터프라이즈 환경에서 출발했으며, 오늘날에도 금융·정부 시스템에서는 여전히 사용됩니다.
REST는 단순함과 웹 친화성을 무기로 웹·모바일 API 표준으로 자리 잡았고, 현재 대부분의 서비스에서 활용됩니다.

결국 어떤 API를 선택할지는 서비스 환경과 요구사항(보안, 성능, 확장성)에 달려 있습니다.

mingming

Jenkins Helm Chart 기동 구조 분석

1. 전체 Pod 구성

2. 생성되는 Kubernetes 리소스

3. 볼륨 구성

4. initContainer 상세 분석

4.1 기본 정보

4.2 주입되는 환경 변수

4.3 apply_config.sh 실행 흐름

Step 1 — Setup Wizard 비활성화

Step 2 — plugins.txt 복사 (ConfigMap → PVC)

Step 3 — 플러그인 설치 (jenkins-plugin-cli)

Step 4 — plugin-dir(emptyDir)로 플러그인 복사

5. 메인 컨테이너 기동 순서

6. JCasC(Jenkins Configuration as Code) 적용 구조

6.1 ConfigMap 생성 구조

6.2 Pod 내 마운트 경로

6.3 configAutoReload 사이드카

7. Secret 및 Credential 주입 구조

7.1 Admin 계정 Secret

7.2 추가 Secret 마운트

8. 기동 실패 주요 원인

주요 확인 명령어

9. 전체 기동 흐름 요약

Windows Server KMS 호스트 등록

1. Windows 라이선스 종류

1.1 Retail (FPP, Full Packaged Product)

1.2 OEM (Original Equipment Manufacturer)

1.3 Volume License (볼륨 라이선스)

2. Microsoft 라이선스 인증 채널 유형

2.1 Retail 인증 채널

2.2 MAK (Multiple Activation Key)

2.3 KMS (Key Management Service)

3. KMS 인증 구조

3.1 KMS 호스트

3.2 KMS 클라이언트

4. KMS 호스트 등록 절차

4.1 사전 준비 사항

4.2 KMS Host Key 설치

4.3 KMS 호스트 활성화

4.4 KMS 상태 확인

4.5 DNS 설정 확인

4.5.1 DNS SRV 레코드 개요

4.5.2 DNS SRV 레코드 확인 방법

4.5.3 DNS 자동 등록이 되지 않는 경우

4.5.4 DNS를 사용하지 않는 경우

5. KMS 클라이언트 설정

6. KMS 제약사항 및 한계

6.1 최소 활성화 수 제한

6.2 인증 유효 기간

6.3 네트워크 및 DNS 의존성

6.4 KMS 호스트 장애 영향

7. slmgr 명령어

8. Windows Server 버전별 KMS 호환성

8.1 KMS 호스트와 클라이언트 호환성 개요

8.2 Windows Server KMS 호스트 버전별 지원 범위

9. KMS 인증 시 자주 발생하는 오류 코드 및 해결법

Linux 부팅 실패 후 dracut 모드로 진입했을 때의 복구 과정

Linux 부팅 실패 후 dracut 모드 진입: initramfs 재생성

1. 장애 상황 개요

2. 장애 발생 환경

2.1 dracut 모드 진입

2.2 /dev/mapper 상태

2.3 LVM 명령어 상태

3. segmentation fault

4. 리눅스 부팅 단계에서 무슨 일이 벌어졌나

5. 근본 원인 분석

5.1 무엇이 깨졌나

5.2 왜 이런 일이 발생했나

6. 해결 방법 (복구 절차)

6.1 Rescue 모드 진입

6.2 chroot 진입

6.3 initramfs 강제 재생성

6.4 GRUB 설정 재생성 (안전 확인)

6.5 재부팅 및 확인

7. 정리하며

7.1 디스크도 LVM도 정상인데, 왜 부팅이 되지 않았을까

7.2 initramfs의 역할

7.3 장애의 본질

Windows 메모리 구조

2.2 `/dev/mapper` 상태