온달의 해피클라우드(Happy@Cloud)

DMAP 빌더: 코드 없이 멀티에이전트 플러그인 만들기

Happy@Cloud — Tue, 10 Feb 2026 18:09:58 +0900

DMAP 빌더: 코드 없이 멀티에이전트 플러그인 만들기

선언형 멀티에이전트 플러그인의 세계로 초대합니다

멀티에이전트 개발, 지금 뭐가 불편한가요?

오케스트라를 상상해보세요. 지휘자가 악보 없이 수십 명의 연주자에게 "알아서 잘 맞춰봐"라고 한다면 어떨까요? 아마 끔찍한 소음이 나겠죠. AI 에이전트도 마찬가지입니다.

에이전트 1개일 때는 괜찮습니다. 하지만 여러 에이전트가 협업해야 하는 순간, 복잡도가 폭발적으로 늘어나요. 기존 방식은 Python SDK로 직접 코딩하거나, LangChain, CrewAI, AutoGen 같은 프레임워크를 배워야 합니다. 프레임워크마다 문법이 다르고, 특정 런타임에 종속되어 버리죠.

진입장벽은 높고, 유지보수는 어렵고, 다른 환경으로 옮기려면 처음부터 다시 만들어야 합니다. 저는 그래서 근본적인 질문부터 해봤습니다.

"에이전트를 정의하는 데 꼭 코드가 필요할까?"

DMAP 빌더란?

레고를 떠올려보세요. 설명서만 보고 블록을 조립하면 멋진 작품이 완성되잖아요?

DMAP 빌더도 같은 원리입니다. 코드 한 줄 없이, Markdown과 YAML 파일만 작성하면 멀티에이전트 플러그인이 뚝딱 만들어집니다.

DMAP는 Declarative Multi-Agent Plugin의 약자입니다. "선언형"이라는 말이 어렵게 느껴질 수 있는데, 쉽게 말하면 "어떻게(HOW)" 대신 "무엇을(WHAT)"만 적는 방식이에요.

택시 기사에게 경로를 일일이 지시하는 대신, "강남역이요"라고 목적지만 말하는 것처럼요.

DMAP의 핵심 가치

· 선언형 명세 — 코드 대신 문서로 에이전트를 정의합니다

· 런타임 중립 — Claude Code, Codex CLI 등 어디서든 동작해요

· 관심사 분리 — 역할별로 깔끔하게 나뉘어 유지보수가 쉽습니다

· 비개발자 접근성 — 마크다운만 쓸 줄 알면 누구나 만들 수 있어요

· 도메인 범용 — 어떤 업무 영역이든 적용 가능합니다

구분	기존 프레임워크	DMAP
명세 방식	Python/TypeScript 코드	Markdown + YAML
런타임	프레임워크 전용 엔진	Claude Code, Codex CLI 등
진입장벽	코딩 필수	마크다운 작성 가능하면 OK
도구/모델 교체	코드 수정 필요	YAML 한 줄 변경

현재 버전 안내 (2026.2월): v1.0.0
현재 DMAP 빌더는 Claude Code 전용으로 제공됨.
DMAP 표준 자체는 런타임 중립적으로 설계되었으며, 향후 Codex CLI, Gemini CLI 등
멀티 런타임 지원으로 확장 예정임.

핵심 개념: 회사에 비유하면

DMAP의 구조를 회사 조직에 비유하면 이해하기 쉬워요. 회사에는 부서장, 전문가, 통역사가 있잖아요? DMAP도 비슷한 구조입니다.

Skills = 부서장

스킬은 일을 배분하는 부서장 같은 역할이에요. 사용자의 요청을 받아서 어떤 에이전트에게 어떤 일을 시킬지 결정합니다. SKILL.md 파일 하나로 워크플로우 전체를 선언하죠.

Agents = 전문가

에이전트는 실제 일을 하는 전문가입니다. 각 에이전트는 AGENT.md(역할 정의), agentcard.yaml(메타데이터), tools.yaml(사용 가능한 도구) 3개 파일로 구성돼요.

Gateway = 통역사

게이트웨이는 추상적인 선언을 구체적인 실행 환경으로 번역하는 통역사입니다. 에이전트가 "파일 검색 도구"라고 선언하면, 게이트웨이가 실제 런타임에서 어떤 도구를 쓸지 매핑해줘요.

리소스 마켓플레이스 = 사내 공유 드라이브

가이드, 템플릿, 샘플, 도구를 모아둔 공유 저장소입니다. 여러 플러그인이 함께 사용할 수 있는 공용 자원이에요.

이 컴포넌트들은 Clean Architecture 원칙을 따릅니다.

Skills → Agents → Gateway 순서로 단방향 의존하기 때문에, 각 부분을 독립적으로 수정하거나 교체할 수 있어요.

TIP: 선언형이란? "어떻게(HOW)" 대신 "무엇을(WHAT)"만 적으면 됩니다!
SQL처럼 원하는 결과만 말하면, 실행은 엔진이 알아서 해줘요.

DMAP 아키텍처 — Clean Architecture 기반 컴포넌트 구성

동작 원리: 어떻게 돌아갈까요?

프롬프트 조립 — 여행 가이드북 만들기

해외여행을 갈 때 가이드북을 만든다고 생각해보세요. 기본 정보(공통 규칙)에 목적지별 정보(에이전트 역할)를 합치고, 마지막에 오늘의 일정(작업 지시)을 추가하면 완성되죠?

DMAP도 같은 방식으로 프롬프트를 조립합니다. 먼저 Gateway의 runtime-mapping으로 공통 설정을 로드하고, 에이전트 패키지 3개 파일(AGENT.md, agentcard.yaml, tools.yaml)을 합친 뒤, 마지막으로 스킬이 전달하는 동적 작업 지시를 붙여서 최종 프롬프트를 완성합니다.

프롬프트 조립 과정 — 3단계 레이어 구성

4-Tier 매핑 — 택시 vs 버스 vs KTX

모든 일에 택시를 탈 필요는 없잖아요? 가까운 곳은 버스로, 먼 곳은 KTX로 가면 비용도 절약되고 효율적이죠. DMAP의 4-Tier 매핑도 같은 원리입니다.

작업의 복잡도에 따라 HEAVY, HIGH, MEDIUM, LOW 4단계로 나누고, 각 단계에 적합한 AI 모델을 배정해요. 간단한 파일 검색은 가벼운 모델(Haiku)이, 복잡한 아키텍처 설계는 강력한 모델(Opus)이 담당합니다. 작업 중 난이도가 올라가면 자동으로 상위 모델로 에스컬레이션되기도 해요.

4-Tier 모델 매핑 — 복잡도별 최적 모델 배정

스킬 활성화 — 114 안내교환대

예전 114 안내교환대를 기억하시나요? "피자집 전화번호 알려주세요"라고 하면 알아서 연결해주었죠. DMAP의 스킬 활성화도 비슷합니다.

두 가지 경로가 있어요.

첫째, 슬래시 명령어로 직접 호출하는 방법 — 정확히 어떤 스킬이 필요한지 알 때 사용합니다. 둘째, Core 스킬을 경유하는 방법 — 모호한 요청이 들어오면 Core가 의도를 분석해서 적절한 스킬로 라우팅해줘요. 런타임은 skills/ 디렉토리를 자동 스캔해서 사용 가능한 스킬을 발견합니다.

스킬 활성화 경로 — 직접 호출과 Core 경유

플러그인 개발 방법: 요리 레시피 따라하기

요리를 할 때 레시피를 따라하면 누구나 맛있는 음식을 만들 수 있잖아요? DMAP 플러그인 개발도 마찬가지입니다. 4단계 레시피만 따라가면 플러그인이 완성돼요.

Phase	단계	비유
1	요구사항 수집	어떤 요리를 만들지 정하기
2	설계 및 계획	레시피 작성하기
3	플러그인 개발	실제 요리하기
4	검증 및 완료	시식하고 플레이팅

각 Phase가 끝날 때마다 사용자의 확인을 받습니다. "이 요리 맞죠?"라고 중간중간 물어보는 셈이에요. 덕분에 엉뚱한 결과물이 나오는 걸 미리 방지할 수 있습니다.

실전 예제: abra 플러그인

백문이 불여일견! 실제로 DMAP으로 만든 플러그인을 살펴볼게요.

"abra"는 Dify 워크플로우 DSL 자동화 플러그인입니다. Dify라는 AI 워크플로우 플랫폼에서 사용하는 DSL(Domain Specific Language)을 자동으로 생성하고, 프로토타이핑까지 해주는 똑똑한 플러그인이에요.

Abra는 아브라카타브라(Abracadabra: 원하는 것이 모두 이루어지는 마법의 주문)에서 착안한 이름

에이전트 5명의 전문가 팀

· scenario-analyst — 요구사항을 분석하고 시나리오를 만드는 기획자

· dsl-architect — Dify DSL 코드를 설계하는 아키텍트

· plan-writer — 개발계획서를 작성하는 PM

· prototype-runner — Dify에서 프로토타이핑을 실행하는 테스터

· agent-developer — 최종 Agent 코드를 개발하는 개발자

스킬 8개 — 부서장들의 업무 지시서

setup, core, dify-setup, scenario, dsl-generate, prototype, dev-plan, develop — 각 스킬이 워크플로우의 한 단계를 담당합니다.

사용자 입장에서는 시나리오 생성 → DSL 생성 → 프로토타이핑 → 개발계획 → Agent 개발 순서로 자연스럽게 진행돼요. 복잡한 내부 구조를 몰라도 됩니다!

abra 플러그인 구조 — 5개 에이전트와 8개 스킬의 협업

앞으로의 로드맵

DMAP는 계속 진화하고 있습니다. 앞으로 어떤 모습이 될지 살짝 엿볼게요.

현재

· Claude Code 런타임 기반으로 안정적으로 동작 중

단기 계획

· 다중 런타임 지원 — Codex CLI, Gemini CLI 등 다양한 환경에서 실행

중기 계획

· 플러그인 마켓플레이스 — 만든 플러그인을 공유하고 다운로드하는 생태계 구축

· 커뮤니티 생태계 — 개발자들이 함께 성장하는 오픈소스 커뮤니티

장기 비전

· 비개발자용 시각적 플러그인 빌더 — 드래그 앤 드롭으로 플러그인을 만드는 노코드 UI

지금 바로 시작하기

어렵게 느껴지셨나요? 걱정 마세요. 4단계면 시작할 수 있습니다!

· Step 1: DMAP 표준 문서를 읽고 전체 구조를 파악

· Step 2: 플로그인 요구사항 명세서 작성

· Step 3: /dmap:develop-plugin 명령으로 플러그인 개발 시작

· Step 4: 플러그인 설치 및 테스트(플러그인의 README.md 참조)

코드 한 줄 없이 멀티에이전트 플러그인을 만들 수 있다는 걸 직접 경험해보세요.

지금 바로 시작해보세요!

TIP: DMAP 표준 문서와 샘플은 GitHub에서 확인하세요:
- 표준문서: https://github.com/cna-bootcamp/gen-dmap/blob/main/standards/plugin-standard.md
- 요구사항 샘플: https://github.com/cna-bootcamp/abra/blob/main/output/requirement.md

HAProxy 서버 설치

Happy@Cloud — Sun, 6 Oct 2024 02:22:34 +0900

이 가이드는 Ubuntu 기준으로 작성되어 있습니다.

CentOS 기반의 가이드는 여기를 참조하세요.

1. 설치
apt-get install -y haproxy

2. 설정

아래 예제를 참조하여 작성하십시오.
sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
vi /etc/haproxy/haproxy.cfg

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
        ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
        ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
        ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http
	maxconn                 3000

listen stats
    bind :9000
    mode http
    stats enable
    stats uri /
    monitor-uri /healthz

frontend api-server
    bind *:6443
    default_backend api-server
    mode tcp
    option tcplog

backend api-server
    balance source
    mode tcp
    server controlplane controlplane.msa.edutdc.com:6443 check

frontend http-in
    bind *:80
    mode tcp
    option tcplog
    default_backend http-backend

frontend https-in
    bind *:443
    mode tcp
    option tcplog
    default_backend https-backend

backend http-backend
    mode tcp
    server worker1 worker1.msa.edutdc.com:30080
    server worker2 worker2.msa.edutdc.com:30080

backend https-backend
    mode tcp
    server worker1 worker1.msa.edutdc.com:30443
    server worker2 worker2.msa.edutdc.com:30443

ingress-nginx contrller 서비스 객체를 Node port로 오픈해야 합니다.

3. 적용
systemctl restart haproxy

Pod에서 haproxy서버 통해 outbound 시 Troubleshooting

Pod내에서 외부 사이트(예: github.com)를 접속할 때 haproxy서버가 설치된 VM을 통해 나가게 됩니다.

http통신이라면 문제가 없지만, https 통신시에는 문제가 됩니다.

예를 들어, https://github.com으로 통신을 시도하면 github.com의 주소가 실제 외부 IP가 아닌 haproxy 서버의 IP로 해석이 됩니다.

SSL통신을 할 때는 먼저 SSL Handshake라고 해서 대상 서버에서 인증서를 다운로드 하고 그 인증서의 유효성을 체크합니다.

그런데 실제 github.com이 아닌 haproxy서버로 접속하게 되고, haproxy서버로 부터 인증서를 다운로드 하려 합니다.

당연히 haproxy서버에는 github.com의 SSL인증서가 없습니다.

haproxy서버는 이 요청을 ingress 컨트롤러로 proxying하게 됩니다.

그리고 ingress 컨트롤러는 kubernetes의 SSL 인증서를 리턴하게 됩니다.

결과적으로 github.com의 SSL 인증서가 아니라 kubernetes의 SSL 인증서가 다운로드 되므로 SSL Handshake는 실패하게 됩니다.

테스트를 위해 Git Pod를 하나 생성합니다.

kubectl run gitpod -it --image bitnami/git -- sh

생성된 파드 안에서 아래 명령으로 실제 주소로 연결되는지 haproxy서버로 연결되는지 테스트 합니다.

curl -v github.com

또는 실제로 git repository를 다운로드 해 봅니다.

git clone https://github.com/hiondal/subride-front.git

만약 아래와 같은 에러가 난다면 솔루션에 따라 조치 합니다.

# git clone https://github.com/hiondal/subride-config.git
Cloning into 'subride-config'...
fatal: unable to access 'https://github.com/hiondal/subride-config.git/': SSL certificate problem: self-signed certificate

솔루션은 github.com의 실제 주소로 연결하도록 DNS에 github.com의 IP를 등록해 주면 됩니다.

Kubernetes Pod의 DNS는 coredns입니다.

coredns 파드는 ConfigMap 'coredns'에서 정보를 주입 받습니다.

따라서 ocredns 컨피그맵에 github.com의 실제 주소를 지정하고, coredns 파드를 재시작하면 됩니다.

kubectl edit cm coredns -n kube-system

아래 'ready' 하단에 있는 'hosts' 섹션과 같이 실제 IP를 추가합니다.

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health {
           lameduck 5s
        }
        ready
        hosts {
            20.205.243.166 github.com
            fallthrough
        }
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf {
           max_concurrent 1000
        }
        cache 30
        loop
        reload
        loadbalance
    }
kind: ConfigMap
metadata:
  creationTimestamp: "2024-09-25T08:31:52Z"
  name: coredns
  namespace: kube-system
  resourceVersion: "4050036"
  uid: c8f8d48b-627b-49f0-8deb-f8ca626b6d65

coredns Pod를 재시작합니다.

kubectl rollout restart deploy coredns -n kube-system

이제 테스트 Git Pod를 삭제하고 재생성한 후 Git clone을 테스트 해 봅니다.

DNS 서버 설치

Happy@Cloud — Sun, 6 Oct 2024 02:20:43 +0900

이 가이드는 Ubuntu 기준으로 작성되어 있습니다.

CentOS 기반의 가이드는 여기를 참조하세요.

1. DNS설치

apt-get install -y bind9-utils bind9

2. DNS설정
설정파일 예시를 참고하여 작성하십시오.

1) /etc/bind/named.conf.options 
options {
	directory "/var/cache/bind";
	
	recursion yes;               // 내부 네트워크에만 재귀 쿼리 허용
	allow-recursion { any; };    // 모든 사용자를 허용하려면 { any; }로 설정
	listen-on { any; };          // 모든 인터페이스에서 DNS 쿼리를 수신
	allow-transfer { none; };    // 기본적으로 존 전송을 허용하지 않음

	dnssec-validation auto;

	listen-on-v6 { any; };
};

2) /etc/bind/named.conf.local

zone "msa.edutdc.com" {
    type master;
    file "/etc/bind/zones/db.msa.edutdc.com";  // 영역 파일의 경로
};

zone "110.10.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.10.110";  // 역방향 영역 파일의 경로
};

3) /etc/bind/zones/db.msa.edutdc.com
$TTL    604800
@       IN      SOA     ns1.msa.edutdc.com. admin.msa.edutdc.com. (
                        3         ; Serial
                        604800    ; Refresh
                        86400     ; Retry
                        2419200   ; Expire
                        604800 )  ; Negative Cache TTL

@       IN      NS      ns1.msa.edutdc.com.
ns1     IN      A       10.110.50.111   ; Primary DNS 서버를 실제 DNS 서버가 설치된 VM의 IP로 설정

bastion       IN      A       10.110.10.124
controlplane  IN      A       10.110.20.65
worker1       IN      A       10.110.30.77
worker2       IN      A       10.110.40.91
infra         IN      A       10.110.50.111
apigw         IN      A       10.110.60.106
cicd          IN      A       10.110.70.239
telemetry     IN      A       10.110.80.10

; Public IP 매핑 (선택 사항)
infra-public     IN      A       18.141.104.160
bastion-public   IN      A       13.215.90.232

4) /etc/bind/zones/db.10.110
$TTL    604800
@       IN      SOA     ns1.msa.edutdc.com. admin.msa.edutdc.com. (
                            3         ; Serial
                            604800    ; Refresh
                            86400     ; Retry
                            2419200   ; Expire
                            604800 )  ; Negative Cache TTL

@       IN      NS      ns1.msa.edutdc.com.
ns1     IN      A       10.110.50.111

; 세 번째와 네 번째 옥텟을 사용하여 PTR 레코드 작성
124.10     IN      PTR     bastion.msa.edutdc.com.
65.20      IN      PTR     controlplane.msa.edutdc.com.
77.30      IN      PTR     worker1.msa.edutdc.com.
91.40      IN      PTR     worker2.msa.edutdc.com.
111.50     IN      PTR     infra.msa.edutdc.com.
106.60     IN      PTR     apigw.msa.edutdc.com.
239.70     IN      PTR     cicd.msa.edutdc.com.
10.80      IN      PTR     telemetry.msa.edutdc.com.

3. DNS서버 재시작
systemctl restart bind9

4. DNS설정 수정
1) /etc/systemd/resolved.conf
[Resolve]
DNS=10.110.50.111
Domains=msa.edutdc.com

2) 적용
systemctl restart systemd-resolved

5. 테스트
1) 정방향 탐색
nslookup {host}
ex) nslookup bastion.msa.edutdc.com

2) 역뱡향 탐색
dig -x 10.110.10.124
또는
nslookup 10.110.10.124

Fluent Bit 설치

Happy@Cloud — Sun, 6 Oct 2024 01:55:52 +0900

이 가이드는 k8s 1.30이상에 Elasticsearch 8.x를 설치한 경우 Fluent bit를 설치하는 방법을 안내합니다.

Elasticsearch 8.x 설치 가이드는 아래 글을 참조하세요.

https://happycloud-lee.tistory.com/294

엘라스틱 서치 헬름 저장소 추가

아래와 같이 엘라스틱 서치 헬름 차트 저장소를 추가 하고 차트 리스트를 업데이트 합니다.

[root@osboxes ~]# helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories
[root@osboxes ~]# helm repo update

Fluent bit의 헬름 차트명과 버전을 찾습니다.

ubuntu@bastion:~/install/efk$ helm search repo fluent-bit
NAME              	CHART VERSION	APP VERSION	DESCRIPTION                                       
bitnami/fluent-bit	2.3.21       	3.1.9      	Fluent Bit is a Fast and Lightweight Log Proces..

설치 Config파일 작성

작업 디렉토리를 만들고 이동 합니다.

[root@osboxes ~]# mkdir -p ~/install/efk && cd ~/install/efk

설치를 위한 환경설정 파일을 만듭니다. fluentbit.yaml이라는 이름을 만들었다고 가정하고 설명하겠습니다.

Elasticsearch의 Service 주소과 password는 변경 하셔야 합니다.

SSL키를 갖고 있는 Secret이 정확한 지 확인하십시오. 위 Elasticsearch 가이드대로 설치했으면 맞을 겁니다.

daemonset:
  enabled: true

config:
  outputs: |
    [OUTPUT]
        Name           es
        Match          *
        Host           elasticsearch-master-hl.efk.svc.cluster.local
        Port           9200
        Logstash_Format On
        Logstash_Prefix fluent-bit
        Suppress_Type_Name On
        Retry_Limit    False
        tls            On
        tls.verify     On
        tls.ca_file    /opt/bitnami/fluent-bit/certs/ca.crt
        HTTP_User      elastic
        HTTP_Passwd    P@ssw0rd$

existingSecret:
  - name: elasticsearch-master-crt
    keys: 
      tls.crt: tls.crt
      tls.key: tls.key
      ca.crt: ca.crt

extraVolumeMounts:
  - name: elasticsearch-certs
    mountPath: /opt/bitnami/fluent-bit/certs
    readOnly: true

extraVolumes:
  - name: elasticsearch-certs
    secret:
      secretName: elasticsearch-master-crt

이 설정에서 중요한 부분은 Elasticsearch 연결 정보를 셋팅하는 아래 부분입니다.

- Host: Elasticsearch의 service객체 주소로서, SSL통신을 하므로 인증서의 SAN(Subject Alternative Name)과 반드시 일치해야 함

- HTTP_Passwd: elastic 서버 인증 암호. Secret 'elasticsearch-master-credentials'에서 구함

CA, Cert, Key는 Secret 'elasticsearch-master-crt'에서 마운트 함

아래는 SSL인증서(tls.crt)의 SAN값을 확인하는 방법입니다.

kubectl get secret elasticsearch-master-crt -o jsonpath="{.data['tls\.crt']}" | base64 --decode > elastic-tls.crt

openssl x509 -in elastic-tls.crt -text -noout

아래와 같이 SAN을 확인할 수 있습니다.

...

            X509v3 Subject Alternative Name: 
                DNS:*.elasticsearch-master-hl.efk.svc.cluster.local, DNS:elasticsearch-master-hl.efk.svc.cluster.local, DNS:elasticsearch-master, DNS:127.0.0.1, DNS:localhost


...

설치하기

namespace를 만들고 이동합니다.

k create ns efk
kubens efk

helm 명령으로 설치합니다.

helm upgrade fluentbit -i -f fluentbit.yaml bitnami/fluent-bit

Pod가 실행될때까지 기다립니다. 아래와 같이 모든 Pod가 실행되어야 합니다.

파드는 DaemonSet으로 설치되므로 각 노드 당 1개씩 생성됩니다.

ubuntu@bastion:~/install/efk$ k get po
NAME                                     READY   STATUS    RESTARTS   AGE
elasticsearch-coordinating-0             1/1     Running   0          6h54m
elasticsearch-data-0                     1/1     Running   0          6h54m
elasticsearch-ingest-0                   1/1     Running   0          6h54m
elasticsearch-kibana-6486cc7b88-vq9fd    1/1     Running   0          6h54m
elasticsearch-master-0                   1/1     Running   0          6h54m
elasticsearch-metrics-85c74dfbdf-hb69p   1/1     Running   0          6h54m
fluentbit-fluent-bit-fcsp6               1/1     Running   0          9m17s
fluentbit-fluent-bit-qs4xg               1/1     Running   0          9m17s
fluentbit-fluent-bit-rkgh2               1/1     Running   0          9m17s
fluentbit-fluent-bit-v8gtg               1/1     Running   0          9m17s

Fluentd설치(k8s 1.30이상에서 Elasticsearch 8.x 연동)

Happy@Cloud — Thu, 3 Oct 2024 19:07:47 +0900

아래 가이드는 제대로 설치 안되어 보다 경량화된 Fluentd인 Fluentbit를 설치할 것을 권고합니다.

https://happycloud-lee.tistory.com/296

이 가이드는 k8s 1.30이상에 Elasticsearch 8.x를 설치한 경우 Fluentd를 설치하는 방법을 안내합니다.

Elasticsearch 8.x 설치 가이드는 아래 글을 참조하세요.

https://happycloud-lee.tistory.com/294

k8s 1.30이상에서 Elasticsearch 8.x 설치

k8s 1.30으로 업그레이드 되면서 elastic에서 제공하는 helm chart도 많은 변화가 있습니다.이 가이드에서는 최신 버전의 elastic helm chart를 k8s 1.30 클러스터에 설치하는 방법을 다룹니다. 엘라스틱 서치

happycloud-lee.tistory.com

엘라스틱 서치 헬름 저장소 추가

아래와 같이 엘라스틱 서치 헬름 차트 저장소를 추가 하고 차트 리스트를 업데이트 합니다.

[root@osboxes ~]# helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories
[root@osboxes ~]# helm repo update

Fluentd의 헬름 차트명과 버전을 찾습니다.

ubuntu@bastion:~/install/efk$ helm search repo fluentd
NAME                        	CHART VERSION	APP VERSION	DESCRIPTION                                       
bitnami/fluentd             	6.5.13       	1.17.1     	Fluentd collects events from various data sourc...

설치 Config파일 작성

작업 디렉토리를 만들고 이동 합니다.

[root@osboxes ~]# mkdir -p ~/install/efk && cd ~/install/efk

설치를 위한 환경설정 파일을 만듭니다. fluentd.yaml이라는 이름을 만들었다고 가정하고 설명하겠습니다.

Forwarder는 각 노드에 Daemon으로 설치되어 로그를 수집하여 Aggregator로 보냅니다.

Aggregator는 수집된 로그를 연결된 Elasticsearch로 보냅니다.

## Forwarder parameters
forwarder:
  enabled: true
  configMapFiles:
    fluentd.conf: |
      # Ignore fluentd own events
      <match fluent.**>
        @type null
      </match>

      @include fluentd-inputs.conf
      @include fluentd-output.conf

    fluentd-inputs.conf: |
      # HTTP input for the liveness and readiness probes
      <source>
        @type http
        port 9880
      </source>
      # Get the logs from the containers running in the node
      <source>
        @type tail
        path /var/log/containers/*.log
        # exclude Fluentd logs
        exclude_path /var/log/containers/*fluentd*.log
        pos_file /opt/bitnami/fluentd/logs/buffers/fluentd-docker.pos
        tag kubernetes.*
        read_from_head true
        <parse>
          @type json
          time_key time
          time_format %Y-%m-%dT%H:%M:%S.%NZ
        </parse>
      </source>
      # enrich with kubernetes metadata
      <filter kubernetes.**>
        @type kubernetes_metadata
      </filter>

    fluentd-output.conf: |
      # Forward all logs to the aggregators
      <match **>
        @type forward
        <server>
          host fluentd-aggregator
          port 24224
        </server>
      </match>

## Aggregator parameters
aggregator:
  enabled: true
  replicaCount: 1

  configMapFiles:
    fluentd.conf: |
      # Ignore fluentd own events
      <match fluent.**>
        @type null
      </match>

      @include fluentd-inputs.conf
      @include fluentd-output.conf

    fluentd-inputs.conf: |
      # HTTP input for the liveness and readiness probes
      <source>
        @type http
        port 9880
      </source>
      # Receive logs from forwarders
      <source>
        @type forward
        port 24224
      </source>

    fluentd-output.conf: |
      # Send the logs to Elasticsearch
      <match **>
        @type elasticsearch
        host "elasticsearch-master-hl.efk.svc.cluster.local"
        port 9200
        user "elastic"
        password "P@ssw0rd$"
        scheme https
        ssl_verify true
        ssl_version TLSv1_2
        ca_file /opt/bitnami/fluentd/certs/elasticsearch/ca.crt
        client_cert /opt/bitnami/fluentd/certs/elasticsearch/tls.crt
        client_key /opt/bitnami/fluentd/certs/elasticsearch/tls.key
        index_name fluentd
        type_name fluentd
        logstash_format true
        logstash_prefix fluentd
        reconnect_on_error true
        reload_on_failure true
        <buffer>
          flush_thread_count 8
          flush_interval 5s
          chunk_limit_size 2M
          queue_limit_length 32
          retry_max_interval 30
          retry_forever true
        </buffer>
      </match>

  # SSL인증서 mount
  extraVolumes:
    - name: elasticsearch-certs
      secret:
        secretName: elasticsearch-master-crt
  extraVolumeMounts:
    - name: elasticsearch-certs
      mountPath: /opt/bitnami/fluentd/certs/elasticsearch
      readOnly: true

# Disable TLS
tls:
  enabled: false

# Disable metrics for simplicity
metrics:
  enabled: false

이 설정에서 중요한 부분은 Elasticsearch 연결 정보를 셋팅하는 아래 부분입니다.

- host: Elasticsearch의 service객체 주소로서, SSL통신을 하므로 인증서의 SAN(Subject Alternative Name)과 반드시 일치해야 함

- scheme: 반드시 SSL통신을 해야 함

- password: elastic 서버 인증 암호. Secret 'elasticsearch-master-credentials'에서 구함

- ca_file: SSL인증서를 서명한 CA(Certificate Authority)의 인증서 경로

- client_cert: SSL 인증서 경로

- client_key: SSL 인증서의 개인 키 경로

CA, Cert, Key는 Secret 'elasticsearch-master-crt'에서 마운트 함

  aggregator:
    ... 
    fluentd-output.conf: |
      # Send the logs to Elasticsearch
      <match **>
        @type elasticsearch
        host "elasticsearch-master-hl.efk.svc.cluster.local"
        port 9200
        user "elastic"
        password "P@ssw0rd$"
        scheme https
        ssl_verify true
        ssl_version TLSv1_2
        ca_file /opt/bitnami/fluentd/certs/elasticsearch/ca.crt
        client_cert /opt/bitnami/fluentd/certs/elasticsearch/tls.crt
        client_key /opt/bitnami/fluentd/certs/elasticsearch/tls.key

아래는 인증서들을 Secret 'elasticsearch-master-crt'에서 마운트 하기 위한 설정입니다.

aggregator:
...
  # SSL인증서 mount
  extraVolumes:
    - name: elasticsearch-certs
      secret:
        secretName: elasticsearch-master-crt
  extraVolumeMounts:
    - name: elasticsearch-certs
      mountPath: /opt/bitnami/fluentd/certs/elasticsearch
      readOnly: true

아래는 SSL인증서(tls.crt)의 SAN값을 확인하는 방법입니다.

kubectl get secret elasticsearch-master-crt -o jsonpath="{.data['tls\.crt']}" | base64 --decode > elastic-tls.crt

openssl x509 -in elastic-tls.crt -text -noout

아래와 같이 SAN을 확인할 수 있습니다.

...

            X509v3 Subject Alternative Name: 
                DNS:*.elasticsearch-master-hl.efk.svc.cluster.local, DNS:elasticsearch-master-hl.efk.svc.cluster.local, DNS:elasticsearch-master, DNS:127.0.0.1, DNS:localhost


...

설치하기

namespace를 만들고 이동합니다.

k create ns efk
kubens efk

helm 명령으로 설치합니다.

helm upgrade fluentd -i -f fluentd.yaml bitnami/fluentd

Pod가 실행될때까지 기다립니다. 아래와 같이 모든 Pod가 실행되어야 합니다.

fluentd-0, fluentd-1이 Aggregator이고, fluentd-xxx 파드들이 Forwarder입니다.

Forwarder파드는 DaemonSet으로 설치되므로 각 노드 당 1개씩 생성됩니다.

$ k get po
NAME                     READY   STATUS    RESTARTS      AGE
elasticsearch-master-0   1/1     Running   0             158m
fluentd-0                1/1     Running   0             58m
fluentd-1                1/1     Running   0             57m
fluentd-j8xkr            1/1     Running   1 (57m ago)   58m
fluentd-jv4qq            1/1     Running   1 (58m ago)   58m
fluentd-klh8p            1/1     Running   2 (55m ago)   58m
fluentd-pnj8b            1/1     Running   4 (56m ago)   58m
fluentd-pnk4b            1/1     Running   1 (58m ago)   58m

k8s 1.30이상에서 Elasticsearch과 Kibana 8.x 설치

Happy@Cloud — Thu, 3 Oct 2024 15:58:44 +0900

k8s 1.30으로 업그레이드 되면서 elastic에서 제공하는 helm chart도 많은 변화가 있습니다.

이 가이드에서는 최신 버전(2024.10월 현재 8.15.3)의 Elasticsearch와 Kibana를

bitnami helm chart를 이용하여 k8s 1.30 클러스터에 설치하는 방법을 다룹니다.

엘라스틱 서치 헬름 저장소 추가

아래와 같이 Bitnami 헬름 차트 저장소를 추가 하고 차트 리스트를 업데이트 합니다.

[root@osboxes ~]# helm repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories
[root@osboxes ~]# helm repo update

엘라스틱 서치의 헬름 차트명과 버전을 찾습니다.

ubuntu@bastion:~$ helm search repo elasticsearch
NAME                                              	CHART VERSION	APP VERSION	DESCRIPTION                                       
bitnami/elasticsearch                             	21.3.20      	8.15.2     	Elasticsearch is a distributed search and analy...

설치 Config파일 작성

작업 디렉토리를 만들고 이동 합니다.

[root@osboxes ~]# mkdir -p ~/install/efk && cd ~/install/efk

설치를 위한 환경설정 파일을 만듭니다. elasticsearch.yaml이라는 이름으로 만들었다고 가정하고 설명하겠습니다.

아래 sample을 이용하여 본인의 상황에 맞게 적절히 변경하십시오.

최대한 자세한 주석을 달았으니 참고하십시오.

아래는 반드시 변경해야 할 설정입니다.

- storageClass: k get sc 명령어로 확인

- security.elasticPassword: elastic 유저의 암호를 지정. 이 암호로 초기 암호가 생성됨

- ingress.hostname: 본인이 원하는 Elasticsearch Host. IP는 지정 불가능함

- 환경변수 'KIBANA_SERVER_PUBLICBASEURL': 본인이 원하는 Kibana Host. IP는 지정 불가능

- kibana.elasticsearch.security.auth.kibanaPassword: kibana_system 유저의 암호. 이후 과정에서 이 암호로 지정해야 함

- kibana.ingress.hostname: 본인이 원하는 Kibana Host로서 위 환경변수 'KIBANA_SERVER_PUBLICBASEURL'와 동일하게 지정해야 함

# Elasticsearch 클러스터 이름 설정
clusterName: "elastic"

# 전역 설정
global:
  # Kibana 활성화 여부
  kibanaEnabled: true

# 마스터 노드 설정
master:
  # 마스터 노드 복제본 수
  replicaCount: 1
  # 마스터 노드의 힙 크기 (메모리)
  heapSize: 1048m
  # 마스터 노드의 리소스 요청 및 제한
  resources:
    requests:
      cpu: 1  # CPU 요청량
      memory: 1Gi  # 메모리 요청량
    limits:
      cpu: 2  # CPU 제한량
      memory: 2Gi  # 메모리 제한량
  # 마스터 노드의 영구 저장소 설정
  persistence:
    enabled: true  # 영구 저장소 활성화
    storageClass: "nfs-retain"  # 사용할 스토리지 클래스
    accessModes:
      - ReadWriteOnce  # 접근 모드
    size: 5Gi  # 저장소 크기
  # 마스터 노드를 배치할 노드 선택기
  nodeSelector:
    role: telemetry

# 데이터 노드 설정
  # 데이터 노드의 역할:
  # - 실제 데이터를 저장하고 관리
  # - 인덱싱, 검색, 집계 등의 데이터 관련 작업 수행
  # - 클러스터의 주요 워크로드를 처리
  # 주의: 데이터 노드는 클러스터의 성능과 안정성에 직접적인 영향을 미치므로,
  # 리소스 설정과 복제본 수를 신중히 고려해야 함
data:
  # 데이터 노드 복제본 수
  replicaCount: 1
  # 데이터 노드의 힙 크기 (메모리)
  heapSize: 1024m
  # 데이터 노드의 리소스 요청 및 제한
  resources:
    requests:
      cpu: 1000m
      memory: 2Gi
    limits:
      cpu: 2000m
      memory: 4Gi
  # 데이터 노드의 영구 저장소 설정
  persistence:
    enabled: true
    storageClass: "nfs-retain"
    accessModes:
      - ReadWriteOnce
    size: 10Gi


# 코디네이팅 노드 설정
  # 코디네이팅 노드의 역할:
  # - 클라이언트 요청을 받아 적절한 데이터 노드로 라우팅
  # - 검색 결과의 집계 및 정렬 수행
  # - 클러스터의 부하를 분산시키고 전체적인 성능 향상에 기여
  # 주의: 코디네이팅 노드는 데이터를 저장하지 않으므로 영구 저장소 설정이 불필요함
coordinating:
  # 코디네이팅 노드 복제본 수
  replicaCount: 1
  # 코디네이팅 노드의 힙 크기 (메모리)
  heapSize: 512m
  # 코디네이팅 노드의 리소스 요청 및 제한
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 1000m
      memory: 2Gi

# 인제스트 노드 설정
 # 인제스트 노드의 역할:
  # - 데이터 인덱싱 전 전처리 작업 수행 (예: 데이터 변환, 보강)
  # - 복잡한 데이터 처리 파이프라인 실행
  # - 데이터 품질 향상 및 일관성 유지에 기여
  # 주의: 인제스트 노드는 대량의 데이터 처리 시 중요한 역할을 하므로,
  # 데이터 처리량에 따라 리소스와 복제본 수를 적절히 조정해야 함
ingest:
  # 인제스트 노드 활성화 여부
  enabled: true
  # 인제스트 노드 복제본 수
  replicaCount: 1
  # 인제스트 노드의 힙 크기 (메모리)
  heapSize: 512m
  # 인제스트 노드의 리소스 요청 및 제한
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 1000m
      memory: 2Gi
  # 인제스트 노드의 영구 저장소 설정
  persistence:
    enabled: true
    storageClass: "nfs-retain"
    accessModes:
      - ReadWriteOnce
    size: 5Gi

# 시스템 설정을 위한 이미지 설정
sysctlImage:
  enabled: true
  # vm.max_map_count 값을 설정하는 명령어
  command: ["sysctl", "-w", "vm.max_map_count=262144"]

# 메트릭스 설정
metrics:
  # 메트릭스 수집 활성화
  enabled: true
  serviceMonitor:
    # ServiceMonitor 비활성화 (Prometheus Operator가 없는 경우)
    enabled: false

# 공통 서비스 설정
service:
  type: ClusterIP

# Elasticsearch Ingress 설정
ingress:
  enabled: true
  hostname: es.msa.edutdc.com
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    # Ingress에서 백엔드로의 통신 프로토콜을 HTTPS로 지정
    # 이는 Ingress 컨트롤러가 Kibana와 통신할 때 HTTPS를 사용하도록 함
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
  tls: true

# 보안 설정
security:
  # 보안 기능 활성화
  enabled: true
  # Elastic 사용자의 비밀번호
  elasticPassword: "P@ssw0rd$"
  tls:
    # TLS 인증서 자동 생성
    autoGenerated: true
    # REST API에 대한 암호화 활성화
    restEncryption: true

# Kibana 설정
kibana:
  # Kibana에 추가할 환경 변수
  extraEnvVars:
    - name: KIBANA_SERVER_PUBLICBASEURL
      value: "https://kibana.msa.edutdc.com"
  
  # Elasticsearch 연결 설정

  elasticsearch:
    # 주의: hosts에는 http(s) 프로토콜과 포트 번호를 제외한 마스터 노드의 서비스 주소만 입력
    # 예: "elasticsearch-master" (서비스 이름)
    # 프로토콜과 포트는 별도로 지정되므로 여기서는 생략해야 함
    hosts:
      - "elasticsearch"
    port: "9200"
    security:
      auth:
        enabled: true
        # kibana_system 사용자의 비밀번호
        # kibana_system 사용자의 비밀번호
        # 주의: 이 비밀번호는 Elasticsearch에서 생성한 실제 kibana_system 사용자의 비밀번호와 일치해야 합니다.
        # 비밀번호 설정 방법:
        # 1. Elasticsearch 클러스터가 실행 중이고 보안이 활성화된 상태에서 다음 명령을 실행합니다:
        #    kubectl exec -it elasticsearch-master-0 -- elasticsearch-setup-passwords interactive -Expack.security.http.ssl.verification_mode=certificate
        # 2. 프롬프트에 따라 각 기본 사용자(elastic, kibana_system 등)의 비밀번호를 설정합니다.
        # 3. kibana_system 사용자의 비밀번호를 메모하고, 아래 kibanaPassword 값으로 사용합니다.
        # 4. 이 값을 변경한 후, Kibana deployment를 재시작하여 새 비밀번호를 적용합니다.
        kibanaPassword: "P@ssw0rd$"
      tls:
        enabled: true
        verificationMode: certificate
        # 기존 TLS 인증서 시크릿 사용
        existingSecret: elasticsearch-master-crt
        usePemCerts: true
  # Kibana Ingress 설정
  ingress:
    enabled: true
    hostname: kibana.msa.edutdc.com
    annotations:
      kubernetes.io/ingress.class: nginx
      cert-manager.io/cluster-issuer: "letsencrypt-prod"
      # Ingress에서 백엔드로의 통신 프로토콜을 HTTPS로 지정
      # 이는 Ingress 컨트롤러가 Kibana와 통신할 때 HTTPS를 사용하도록 함
      nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    tls: true
  # Kibana를 배치할 노드 선택기
  nodeSelector:
    role: telemetry
  # Kibana의 리소스 요청 및 제한
  resources:
    requests:
      cpu: "300m"
      memory: "512Mi"
    limits:
      cpu: "500m"
      memory: "1Gi"
  # Kibana 보안 설정
  security:
    enabled: true
  # Kibana TLS 설정
  tls:
    enabled: true
    verificationMode: certificate
    existingSecret: elasticsearch-master-crt
    usePemCerts: true

특정 노드에 각 Elasticsearch 노드를 설치하려면 nodeSelector를 지정합니다.

node label은 아래와 같이 지정하면 됩니다.

# label 추가 
kubectl label nodes node1 role=telemetry
kubectl get nodes --show-label

# label 삭제
kubectl label nodes node1 role-

설치하기

namespace를 만들고 이동합니다.

k create ns efk
kubens efk

helm 명령으로 설치합니다.

helm upgrade elasticsearch -i -f elastic.yaml elastic/elasticsearch

Pod가 실행될때까지 기다립니다.

ubuntu@bastion:~$ k get po
NAME                                     READY   STATUS     RESTARTS       AGE
elasticsearch-coordinating-0             1/1     Running    0              43m
elasticsearch-data-0                     1/1     Running    0              43m
elasticsearch-ingest-0                   1/1     Running    0              43m
elasticsearch-kibana-596f8fdcbc-87bl4    1/1     Running    0              42m
elasticsearch-master-0                   1/1     Running    0              43m
elasticsearch-metrics-85c74dfbdf-mxcr7   1/1     Running    0              95m

kibana_system 유저 암호 지정

아래 명령으로 Elasticsearch의 기본 유저들의 암호를 지정합니다.

특히 kibana_system의 암호는 elasticsearch.yaml에 지정한 kibanaPassword와 반드시 동일해야 합니다.

* 일일이 치지 말고 암호를 클립보드에 복사한 후 붙여넣기 하면 편합니다.

ubuntu@bastion:~$ kubectl exec -it elasticsearch-master-0 -- elasticsearch-setup-passwords interactive -Expack.security.http.ssl.verification_mode=certificate
...
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]y

Enter password for [elastic]: 
Reenter password for [elastic]: 
Enter password for [apm_system]: 
Reenter password for [apm_system]: 
Enter password for [kibana_system]: 
Reenter password for [kibana_system]: 
Enter password for [logstash_system]: 
Reenter password for [logstash_system]: 
Enter password for [beats_system]: 
Reenter password for [beats_system]: 
Enter password for [remote_monitoring_user]: 
Reenter password for [remote_monitoring_user]: 
Changed password for user [apm_system]
Changed password for user [kibana_system]
Changed password for user [kibana]
Changed password for user [logstash_system]
Changed password for user [beats_system]
Changed password for user [remote_monitoring_user]
Changed password for user [elastic]

테스트

ingress 주소로 Elasticsearch를 로그인 합니다.

id는 elastic이고 암호는 위 elasticsearch.yaml에 지정한 값입니다.

Kibana를 로그인 합니다. ID/PW는 위 Elastic 로그인 id/pw와 동일합니다.

Kibana 기본 환경 설정

1. Index Pattern 작성

Fluent bit가 수집하여 Elasticsearch DB에 저장한 데이터의 index pattern을 생성합니다.

로그인 후 좌측 상단 햄버거 메뉴에서 Management > Stack Management를 클릭하고,

Kibana > Data Views를 선택합니다. 그리고 [Create data view]를 누릅니다.

Name은 적절히 지정하시고, Index Patten은 우측에 있는 Index sources리스트에 있는 것중 입력합니다.

좌측 전체 메뉴에서 'Discover'를 누르면 수집된 로그를 검색하는 화면이 표시됩니다.

2. 로그 보관 정책과 기간 설정
index의 보관 정책 및 기간을 설정합니다.
엘라스틱 서치의 index Lifecycle은 아래와 같이 4단계로 나눌 수 있으며, Hot과 Delete단계는 필수로 지정해야 합니다.
- Hot: 빈번하게 검색 해야할 최신 로그
- Warm: Hot보다 덜 찾는 로그
- Cold: 간헐적으로 찾는 로그
- Delete: 더 이상 필요 없어 삭제할 로그

<주의>
Index 보관 주기를 바꾸지 않으면 기본 설정대로 90일 후에나 로그가 삭제되므로 저장공간이 모자랄 수 있습니다.
</>

❶ Data > Index Lifecycle Policies을 클릭하고 ❷ kibana-reporting을 선택 합니다.

Hot/Warm/Cold/Delete Phase별로 로그 정책과 보관 기간을 설정 합니다.

로그 조회 및 검색 실습

헬스체크때 배포한 ‘probe-httpreq’파드를 이용하여 로그를 조회해 보겠습니다.

아래와 같이 ‘probe-httpreq’ 파드를 재시작 하십시오.

[root@osboxes efk]# kubens ott
Context "kubernetes-admin@kubernetes" modified.
Active namespace is "ott".
[root@osboxes efk]# k rollout restart sts probe-httpreq
statefulset.apps/probe-httpreq restarted

이 파드는 ‘member’서비스를 시작하면서 여러분이 NFS 서버의 ‘/ data/ott/members.properties’파일에 만든 데이터를 콘솔에 표시 합니다.

[root@osboxes efk]# k logs -f probe-httpreq-0
… ondal=온달,남자,hiondal@gmail.com
… user1=유저1,여자,user1@gmail.com
… user2=유저2,여자,user2@gmail.com

이 로그가 플루언트디에 의해 수집되어 엘라스틱 서치 DB에 저장될 것이고 키바나에서 검색할 수 있습니다.
키바나의 좌측 상단 햄버거 메뉴를 누르고 ‘Discover’를 클릭 하십시오.

아래와 같이 거의 실시간으로 로그가 수집되는걸 볼 수 있습니다.

상단의 검색 박스에 ‘kubernetes.pod_name : probe-httpreq and user1’이라고 입력하여 검색해 보십시오.
❶ 아래와 같이 수집된 로그에서 검색하여 결과를 하단에 보여 줍니다.
또한 ❷ 자주 사용하는 검색식을 저장하여 나중에 빠르게 로그를 볼 수 있습니다.

ArgoCD 설치

Happy@Cloud — Wed, 7 Aug 2024 03:18:04 +0900

Helm chart로 손쉽게 ArgoCD를 설치하는 방법입니다.

1. Helm chart repository 추가

helm repo add argo https://argoproj.github.io/argo-helm

2. 사용자 정의 설정 파일 만들기

아래 내용으로 argocd.yaml파일을 만듭니다.

global.domain은 ingress host로 사용됩니다. 적절하게 변경하세요.

## Globally shared configuration
global:
  # -- Default domain used by all components
  ## Used for ingresses, certificates, SSO, notifications, etc.
  ## IP는 외부에서 접근할 수 있는 ks8 node의 Public IP 또는 
  ## ingress-nginx-controller 서비스의 External IP이여야 함
  domain: argo.43.200.12.214.nip.io
  
  # -- 특정 노드에 배포시 지정
  #nodeSelector:
    #agentpool: argocd

server:
  ingress:
    enabled: true
    https: true
    annotations:
      kubernetes.io/ingress.class: nginx
    tls:
      - secretName: argocd-tls-secret
  extraArgs:
    - --insecure  # ArgoCD 서버가 TLS 종료를 Ingress에 위임

configs:
  params:
    server.insecure: true  # Ingress에서 TLS를 처리하므로 ArgoCD 서버는 HTTP로 통신
certificate:
  enabled: false  # 자체 서명 인증서 사용 비활성화 (외부 인증서 사용 시)

3. namespace 생성

ArgoCD를 배포할 네임스페이스를 만들고 이동합니다.

kubectl create ns argocd
kubens argocd

4. argocd-tls-secret 생성

ArgoCD는 ssl로 통신하므로 SSL키가 있어야 하고, 이 키를 이용하여 Secret을 만들어야 합니다.

SSL키는 실제 운영시에는 공인인증 기관으로 부터 구매하시면 됩니다.

여기서는 테스트 키를 만들어 사용합니다.

아래와 같이 테스트 키를 만들고 Secret까지 작성합니다.

테스트 키를 만들때 CN에는 위에서 지정한 global.domain과 동일한 값을 지정해야 합니다.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=argo.43.200.12.214.nip.io"

kubectl create secret tls argocd-tls-secret \
  --namespace argocd \
  --key tls.key \
  --cert tls.crt

5. ArgoCD 설치

helm chart로 설치합니다.

helm install argocd -f argocd.yaml argo/argo-cd

6. 로그인

username은 'admin'이고 최초 비밀번호는 argocd-initial-admin-secret에서 아래와 같이 구합니다.

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

비밀번호는 로그인 후 'User Info'에서 변경할 수 있습니다.

7. Manifest repisotory 작성

사전에 manifest repository를 만들어야 합니다.

아래는 두개 서비스의 manifest를 디렉토리별로 관리하는 repository의 예시입니다.

8. Project 생성

먼저 Project를 추가해야 합니다.

ArgoCD의 애플리케이션들을 논리적으로 그룹핑한 개념으로 Project 단위로 소스, 권한, Git과의 Sync방법등을

관리할 수 있습니다.

이름과 Manifest 파일이 있는 관리할 Repository 주소를 지정합니다.

배포 대상 k8s 환경을 지정합니다.

private repository인 경우 Settings > Repositories에서 인증 정보를 입력하여야 합니다.

Password는 로그인 암호가 아니라 Access Token을 입력해야 합니다.

10. Application 생성

그리고 Application을 생성합니다.

아래는 ArgoCD Project 생성 시 옵션에 대한 설명입니다.

## ArgoCD New Application 
- Application name: 동기화할 application 명 
- Project name: ArgoCD의 애플리케이션들을 논리적으로 그룹핑한 개념으로 Project 단위로 
  소스, 권한, Git과의 Sync방법등을 관리할 수 있음
- Sync Policy:  Manual / Automatic
  - Automatic > prune resources: Git에 정의되어 있지 않은 k8s 오브젝틑는 삭제 
  - Automatic > self heal: Git에 정의된 값으로 k8s 오브젝트의 상태를 
    강제 동기화 시킴(예: Pod 수 일치)
  - set Deletion Finalizer: k8s 오브젝트 삭제 시 관련된 다른 object들을 
    먼저 삭제하는 finalizer를 자동으로 추가할 지 여부. 
    불필요한 오브젝트가 남는 걸 막기 위해 체크하는 것이 좋음

- Sync options
  - Skip Schema Validation: Kubernetes 매니페스트의 스키마 유효성 검사를 건너뜀
  - Prune Last: 마지막 동기화에서 생성되었지만 더 이상 Git 저장소에 없는 오브젝트를 제거
  - Respect Ignore Differences: ArgoCD 애플리케이션 리소스에 지정된 무시할 차이점을 고려. 
    Git 리소스 정의 시 spec.ignoreDifferences 필드에 정의한 필드값의 차이는 무시하는 옵션임
  - Auto-Create Namespace: 애플리케이션 배포 시 지정된 네임스페이스가 없으면 자동으로 생성
  - Apply Out of Sync Only: Git 저장소와 클러스터 간에 차이가 있는 경우에만 변경 사항을 적용
  - Server-Side Apply: 쿠버네티스 서버 사이드 적용 기능을 사용하여 리소스를 적용. 
    여러 도구로 동일한 리소스를 관리할 때 필드 수준의 병합을 하여 충돌을 방지할 수 있음
- Prune Propagation Policy
  - foreground: 종속 오브젝트부터 먼저 삭제하고 대상 오브젝트 생성. 일반적으로 권고하는 옵션
  - background: 대상 오브젝트 먼저 삭제하고 종속 오브젝트는 백그라운드에서 삭제. 
    고아 오브젝트가 남을 수 있음
  - orphan: 종속 오브젝트를 삭제하지 않음 

- Replace/Retry: 
  - Replace: 변경된 필드만 부분적으로 변경하는 것이 아닌 기존 오브젝트를 통째로 
    Git에 정의한대로 바꿈
  - Retry: 동기화 실패 시 재 시도함
    - limit: 재시도 최대 횟수
    - durations: 동기화 실패 시 다음 동기화까지의 대기 시간
    - max duration: 동기화 재 시도의 총 수행시간 최대값
    - factor: 다음 동기화까지의 대기 시간을 늘리는 승수
      (예: durations가 5초이고 factor가 2이면 첫 재시도는 5초, 
       2nd 재시도는 10초, 3rd 재시도는 20초후에 수행됨)
- Source(Git)
  - Repository URL: manifest가 있는 Git repository 주소
  - Revision: Branch나 Tag. 'HEAD'는 기본 브랜치에서 가져오는 것을 의미
  - Path: 레포지토리에서 manifest가 있는 디렉토리 경로 
- Source(Helm)
  - Repository URL: HTTP로 접근할 수 있는 helm chart가 있는 주소. 
    예) https://raw.githubusercontent.com/cna-bootcamp/helm-charts/main/stable
  - Charts: 확장자가 tgz인 helm chart 파일의 이름. 
    예) subride-front-1.1.0.tgz이면 subride-front
  - Version: 차트 버전. 예) subride-front-1.1.0.tgz이면 1.1.0
- Destination
  - Cluster URL: API Server 파드를 접근할 수 있는 Service object 주소. 
    예) https://kubernetes.default.svc
  - Namespace: 배포할 namespace명 

- Directory
  - Directory Recurse: 하위 디렉토리 recursive하게 탐색하여 manifest파일을 찾을지 여부
  - Top-level Arguments: 매니페스트 파일 설정을 overriding함. 
    예) spec.template.spec.containers[0].image=docker.io/hiondal/springboot-gradle:1.0.0
  - External Variables: 매니페스트 파일 설정을 외부 환경변수값으로 replace함
    아래 예와 같이 yaml을 만들고 External Varialbes에 IMAGE_TAG=1.0.0으로 입력 
    ```
	apiVersion: apps/v1
	kind: Deployment
	metadata:
	  name: myapp
	spec:
	  template:
	    spec:
	      containers:
	      - name: myapp
	        image: myapp:{{env.IMAGE_TAG}}
    ```
  - Include: 포함할 특정 파일이나 디렉토리
  - Exclude: 제외할 특정 파일이나 디렉토리

아래는 예시입니다.

Project에 지정한 repository 중 하나여야 합니다.

Project에서 정의한 대상 환경과 일치해야 합니다.

manifest repository가 디렉토리 별로 manifest를 관리하는 구조일 때 Directory Recurse를 체크 합니다.

11. Rollback

클라우드 네이티브 애플리케이션 부트캠프 알림

Happy@Cloud — Sat, 25 May 2024 22:56:43 +0900

안녕하세요 ?

이번에 러닝스푼즈와 손 잡고 클라우드 네이티브 애플리케이션 부트캠프를 기획했습니다.

관심있는 분들의 많은 참석 바래요^^

한국 IBM 출신 아키텍트에게 배우는 클라우드 네이티브 애플리케이션 개발 (learningspoons.com)

한국 IBM 출신 아키텍트에게 배우는 클라우드 네이티브 애플리케이션 개발

국내 유일, 클라우드 환경 기반 서비스 [기획-설계-개발-배포-제품 검증]까지 모두 경험하는 클라우드 네이티브 애플리케이션 개발 강의!

learningspoons.com

[마이크로서비스패턴 쉽게 개발하기] 전자책 출간

Happy@Cloud — Sun, 28 Jan 2024 10:52:10 +0900

안녕하세요? 온달입니다.
그동안 몇 번 시도하다 포기했던 책내기에 드디어 성공 했습니다.

책 제목은 '마이크로서비스패턴 쉽게 개발하기'입니다.
2024년 2월 19일 부터 교보문고, Yes24, 알라딘 등 대형서점을 통해 출간 예정입니다.

3줄 요약

이론 보다 동작하는 코드로 마이크로서비스 패턴 익히기
자연스럽게 배우는 SpringBoot
비개발자도 따라할 수 있는 자세한 설명

판매서점
- 교보문고: https://ebook-product.kyobobook.co.kr/dig/epd/ebook/E000006541466
- Yes24: https://www.yes24.com/Product/Goods/125032617
- 알라딘: http://aladin.kr/p/TQyim
- 리디북스: https://ridibooks.com/books/1745006808

마이크로서비스패턴에 대한 관심은 많지만 실제 개발을 안내하는 자료는 온/오프라인에 거의 없더군요.
그래서 이번에 Axon Framework을 이용하여 Saga, Event Sourcing, CQRS, API Composition패턴을 어떻게 개발하는지
자세한 예제와 함께 책으로 엮어 봤습니다.
원래 블로그에 다 올리려 했는데 이왕 하는 거 '책내기'라는 버킷리스트도 실현하자는 맘으로 책을 내게 됐습니다.
마이크로서비스패턴을 직접 개발해 보고 싶은 개발자나 차별적 역량을 갖고 싶은 취준생분들에게 도움이 되리라 생각합니다.
관심있는 분들의 구매를 살짝 기대하며 주변에도 많은 홍보 부탁 드립니다.
감사합니다.

[마이크로서비스 패턴 쉽게 개발 4] Axon Framework(7): Event Replay로 조회DB 데이터 복구

Happy@Cloud — Fri, 19 Jan 2024 15:47:04 +0900

지금까지 Axon Framework의 CommandGateway & Event Sourcing, EventGateway, QueryGateway, Snapshot, State Stored Aggregate에 대해서 '코끼리 냉장고 넣기'서비스를 개발하면서 배워 봤습니다.

이제 마지막으로 Event Replay를 이용하여 조회DB 데이터를 복구 하는 방법을 실습해 보겠습니다.

Event Replay Controller 추가

package 'org.axon.controller'에 'ReplayEventsController' class를 추가 합니다.

두개의 API가 추가 됩니다.

ReplayEventsController: 지정한 Event Handler에 대해 특정 일시 이후의 Event만 Replay함
replayEventsAll: Event Replay가 활성화된 모든 Event Handler에 대해 Event Replay를 함

package org.axon.controller;
/*
- 목적: Event를 replay하여 최종 상태를 DB에 저장함
*/
import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.Parameter;
import io.swagger.v3.oas.annotations.Parameters;
import io.swagger.v3.oas.annotations.enums.ParameterIn;
import io.swagger.v3.oas.annotations.tags.Tag;
import lombok.extern.slf4j.Slf4j;
import org.axonframework.config.Configuration;
import org.axonframework.eventhandling.StreamingEventProcessor;
import org.axonframework.eventhandling.TrackingEventProcessorConfiguration;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.time.Instant;
import java.util.List;

@Tag(name = "Replay Events API")
@Slf4j
@RestController
@RequestMapping("/api/admin")
class ReplayEventsController {
    private final Configuration configuration;

    public ReplayEventsController(Configuration configuration) {
        this.configuration = configuration;
    }

    //-- 특정 EventHandler class에 대해 특정 날짜 이후의 Event Replay하여 최종 상태 저장
    @GetMapping("/replay/{processingGroup}/{startDateTime}")
    @Operation(summary = "지정한 Processing Group의 Event Handler를 지정한 시간 이후 Event만 Replay하면서 수행함")
    @Parameters({
            @Parameter(name = "processingGroup", in= ParameterIn.PATH, description = "Processing Groupname",
                    required = true, example="elephant"),
            @Parameter(name = "startDateTime", in= ParameterIn.PATH, description = "시작일시(생략 시 모든 Event Replay)",
                    allowEmptyValue = true, example = "2024-01-01T00:00:00.00Z")
    })
    String replayEventFor(
            @PathVariable(name = "processingGroup") String processingGroupName,
            @PathVariable(name = "startDateTime") String startDateTime) {

        String startAt = ("".equals(startDateTime) ? "2000-01-01T00:00:00.00Z" : startDateTime);
        log.info("Executing replayEventsFor({}) from {}", processingGroupName, startAt);

        TrackingEventProcessorConfiguration tepConfig = TrackingEventProcessorConfiguration
                .forSingleThreadedProcessing()
                .andInitialTrackingToken(streamableMessageSource ->
                        streamableMessageSource.createTokenAt(Instant.parse(startAt)));

        configuration.eventProcessingConfiguration()
                .eventProcessorByProcessingGroup(processingGroupName, StreamingEventProcessor.class)
                .ifPresentOrElse(streamingEventProcessor ->
                {
                    if(streamingEventProcessor.supportsReset()) {
                        streamingEventProcessor.shutDown();
                        //streamingEventProcessor.resetTokens();    //모든 Event replay 시
                        streamingEventProcessor.resetTokens(tepConfig.getInitialTrackingToken());
                        streamingEventProcessor.start();
                        log.info("===== Start replay events for <{}> from {}", processingGroupName, startAt);
                    } else {
                        log.info("Find <{}>. But, It's not support replay", processingGroupName);
                    }
                }, () -> log.info("Can't find <{}>", processingGroupName));

        return "Replay Events is processed";
    }

    //-- Event Replay를 허용하는 모든 Event Handler에 대해 전체 Event를 Replay하여 최종 상태 저장
    @GetMapping("/replayAll")
    @Operation(summary = "Replay가 가능한 모든 Event Handler를 찾아 Event를 처음부터 Replay하도록 함")
    String replayEventsAll() {
        log.info("Executing replayEventsAll");
        List<StreamingEventProcessor> streamingEventProcessors = configuration.eventProcessingConfiguration()
                .eventProcessors().values().stream()
                .filter(StreamingEventProcessor.class::isInstance)
                .map(StreamingEventProcessor.class::cast)
                .toList();

        streamingEventProcessors.forEach(streamingEventProcessor -> {
            if(streamingEventProcessor.supportsReset()) {
                log.info("Trigger ResetTriggeredEvent for streamingEventProcessor <{}>", streamingEventProcessor);
                streamingEventProcessor.shutDown();
                streamingEventProcessor.resetTokens();
                streamingEventProcessor.start();
            }
        });

        return "Replay Events All is Processed";
    }
}

EventHandler class에 Event Replay 활성화 및 @ResetHandler 추가

ElephantEventHandler class에 Event Replay를 활성화하는 어노테이션 '@ AllowReplay'를 추가 합니다.

또한 @ProcessingGroup 어노테이션으로 Process Group명도 추가 합니다.

위에서 만든 'ReplayEventsController' API에서 Process Group명을 입력하는데 이 이름을 사용하면 됩니다.

@Slf4j
@Component
@ProcessingGroup("elephant")    //전체 Event Replay시 대상 class를 구별하기 위해 부여
@AllowReplay                    //Event Replay를 활성화 함. 비활성화할 EventHandler에는 @DisallowReplay를 지정
public class ElephantEventHandler {
    @Autowired
...
}

참고) Event Replay를 허용하지 않을 Event Handler 메소드는 @DisallowReplay 어노테이션을 붙이십시오.

Event Replay를 시작 하기 전에 조회DB의 기존 데이터를 모두 삭제하는 Reset Handler를 맨 아래 추가 하십시오.

enter_count 테이블의 모든 데이터도 삭제해야 합니다.

    //===================== 전체 이벤트 Replay하여 DB에 최종 상태 저장 ===========
    @ResetHandler
    private void replayAll() {
        log.info("[@ResetHandler] Executing replayAll");
        elephantRepository.deleteAll();
        enterCountRepository.deleteAll();
    }

EnterCountRepository를 만들어서 에러를 없앱니다.

package 'org.axon.repository' 하위에 작성 합니다.

import org.axon.entity.EnterCount;
import org.springframework.data.jpa.repository.JpaRepository;

public interface EnterCountRepository extends JpaRepository<EnterCount, String> {

}

ElephantEventHandler class에 EnterCountRepository의 객체를 생성하는 수행을 추가 합니다.

public class ElephantEventHandler {
	...
    @Autowired
    private EnterCountRepository enterCountRepository;
    ...
}

TIP) 특정 일시부터 현재까지 발생한 Event만 이용하여 데이터 생성이 가능함

두번째 API를 응용하여 정기적으로 다른 조회 DB에 Event Replay를 하여 데이터를 생성할 수 있습니다.

예를 들어 매월 말에 그 달에 발생한 데이터만 생성하여 월간보고 등에 이용할 수 있습니다.

테스트

어플리케이션을 재시작하고 Swagger 페이지를 열어 보십시오.

이제 Event Replay 요청 API가 하단에 표시될겁니다.

- '/api/admin/replayAll' 실행

API 실행 후 콘솔의 두번째 줄을 보면 'elephant'라는 Processing group을 찾아서 Event Replay를 실행한 걸 확인할 수 있습니다.

  Executing replayEventsAll
   Trigger ResetTriggeredEvent for streamingEventProcessor <elephant>
   Shutdown state set for Processor 'elephant'.
   Processor 'elephant' awaiting termination...
   Released claim
   Worker for segment Segment[0/0] stopped.
   [@ResetHandler] Executing replayAll
   Worker assigned to segment Segment[0/0] for processing
   Using current Thread for last segment worker: TrackingSegmentWorker{processor=elephant, segment=Segment[0/0]}
   Fetched token: ReplayToken{currentToken=ReplayToken{currentToken=null, tokenAtReset=IndexTrackingToken{globalIndex=2}, context=null}, tokenAtReset=IndexTrackingToken{globalIndex=2}, context=null} for segment: Segment[0/0]
   [@EventHandler] CreatedElephantEvent for Id: 664
   [@EventHandler] CreatedElephantEvent for Id: 046
   [@CommandHandler] CreateEnterCountCommand for Id: 664
   [@CommandHandler] CreateEnterCountCommand for Id: 046
   [@EventHandler] CreatedElephantEvent for Id: 143
   [@CommandHandler] CreateEnterCountCommand for Id: 143

DBeaver에서 데이터를 확인해 보면 모두 지우고 Event Replay를 한 후 Data가 다시 복원된 걸 확인할 수 있습니다.

두번째 API를 테스트 해 봅니다.

특정 날짜 이후의 Event만 Replay할 수 있습니다. 실행을 하고 DBeaver에서 확인해 보면 데이터가 그대로 복원되었을 겁니다.

이번에는 시작 일시를 오늘 날짜 이후로 지정하고 실행해 보십시오.

데이터가 복원되지 않습니다.

다시 시작일시를 어제 날짜로 지정하고 실행해 봅니다.

이번에는 데이터가 복원되었을 겁니다.

원본 데이터는 Event Store에 저장되어 있기 때문에 복원이 되는 것입니다.

이상으로 총 7개 편으로 나누어 Axon Framework에 대해 실습을 통해 이해 하였습니다.

Axon Framework은 지금까지 설명한 기능 외에 Saga 패턴을 쉽게 구현할 수 있는 방법도 제공 합니다.

마이크로서비스 패턴 쉽게 개발하기 목차

아래 주제들은 '마이크로서비스패턴 쉽게 개발하기'라는 제 책에서 만나실 수 있습니다.

멀티 모듈 프로젝트 작성
신규 주문 정상처리 프로세스 구현
배송 상태 변경 및 재고 증감 처리
신규 주문 보상처리 프로세스 구현
주문 수정 정상처리 프로세스 구현
주문 수정 보상처리 프로세스 구현
주문 삭제 정상처리 프로세스 구현
주문 삭제 보상처리 프로세스 구현
API Composition 패턴과 CQRS 패턴

책 한번 내겠다는 평소의 꿈을 실현하기 위해 이번에 전자책을 내게 되었습니다.

제 꿈을 응원하신다는 마음으로 전체 내용을 공유하지 않는것을 양해해 주시고

구매까지 해 주시면 더욱 감사하겠습니다.

https://happycloud-lee.tistory.com/notice/291

[마이크로서비스패턴 쉽게 개발하기] 전자책 출간

안녕하세요? 온달입니다. 그동안 몇 번 시도하다 포기했던 책내기에 드디어 성공 했습니다. 책 제목은 '마이크로서비스패턴 쉽게 개발하기'입니다. 2024년 2월 19일 부터 교보문고, Yes24, 알라딘 등

happycloud-lee.tistory.com