sunny.log

WireGuard VPN 세팅

Wed, 08 Jul 2026 07:45:18 GMT

Proxmox LXC에 WireGuard VPN 구성하기

1. 구성 목적

회사에서 특정 IP만 접속 허용하는 환경이 있을 때, 집 공인 IP를 회사에 등록해두면 집에서는 정상적으로 접속할 수 있다.

하지만 카페, 외부 장소, 다른 집에서 노트북을 사용하면 접속 출발지 IP가 바뀌기 때문에 회사 시스템에 접속할 수 없다.

이 문제를 해결하기 위해 집에 VPN 서버를 구성하고, 외부에서는 VPN을 통해 집 네트워크를 경유하도록 만들었다.

최종 목표는 다음과 같다.

외부 노트북 / 휴대폰
  ↓ WireGuard VPN
집 Proxmox 서버
  ↓
집 공인 IP
  ↓
회사 시스템 접속

즉, 외부에서 접속하더라도 회사 입장에서는 항상 집 공인 IP에서 접속한 것처럼 보이게 하는 구조다.

2. 최종 구성도

이번에 구성한 환경은 다음과 같다.

인터넷
  ↓
Proxmox Host
  - vmbr0: 공인망
    IP: 49.172.xxx.xxx/27
    GW: 49.172.xxx.1

  - vmbr1: 내부망
    IP: 10.10.10.1/24

  - LXC 102: wg-vpn
    IP: 10.10.10.20/24
    GW: 10.10.10.1
    WireGuard Port: UDP 51820

WireGuard VPN 내부 대역은 별도로 아래처럼 구성했다.

WireGuard Server: 10.8.0.1/24
WireGuard Client: 10.8.0.2/32

최종 트래픽 흐름은 다음과 같다.

휴대폰 LTE / 외부 노트북
  ↓
WireGuard Client
  ↓
Proxmox 공인 IP:51820/udp
  ↓
Proxmox iptables DNAT
  ↓
LXC wg-vpn:10.10.10.20:51820
  ↓
WireGuard wg0
  ↓
집 공인 IP로 외부 인터넷 접속

3. 사전 확인

먼저 Proxmox 호스트에서 네트워크 상태를 확인했다.

ip -4 addr show vmbr0
ip -4 addr show vmbr1
ip route
curl -4 ifconfig.me

확인 결과는 다음과 같았다.

vmbr0: 49.172.xxx.xxx/27
vmbr1: 10.10.10.1/24
default gateway: 49.172.xxx.1
curl ifconfig.me: 49.172.xxx.xxx

여기서 중요한 점은 vmbr0의 IP와 curl ifconfig.me 결과가 동일했다는 것이다.

즉, Proxmox 호스트가 사설 IP 뒤에 있는 것이 아니라 공인 IP를 직접 가지고 있는 상태였다.

또한 내부망 NAT가 이미 설정되어 있었다.

iptables -t nat -S

기존 NAT 룰은 다음과 같은 형태였다.

-A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

IP Forward 상태도 확인했다.

sysctl net.ipv4.ip_forward

결과:

net.ipv4.ip_forward = 1

이 값이 1이어야 내부망 또는 VPN 클라이언트의 트래픽을 외부로 라우팅할 수 있다.

만약 0이라면 아래처럼 활성화한다.

echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-ipforward.conf
sysctl -p /etc/sysctl.d/99-ipforward.conf

4. Debian 12 LXC 생성

WireGuard는 매우 가볍기 때문에 별도의 VM보다 LXC로 구성했다.

Proxmox GUI에서 Create CT를 선택하고 다음과 같이 생성했다.

CT ID: 102
Hostname: wg-vpn
Template: Debian 12
Unprivileged container: 체크
Disk: 5GB
CPU: 1 Core
Memory: 512MB
Swap: 512MB
Bridge: vmbr1
IPv4: 10.10.10.20/24
Gateway: 10.10.10.1
DNS: 1.1.1.1

DNS 설정 시 search domain은 비워두었다.

5. LXC TUN 장치 허용

WireGuard는 /dev/net/tun 장치를 사용한다. LXC에서 WireGuard를 사용하기 위해 Proxmox 호스트에서 다음 설정을 추가했다.

CT ID는 102 기준이다.

pct stop 102
pct set 102 -features nesting=1

mkdir -p /dev/net
[ -c /dev/net/tun ] || mknod /dev/net/tun c 10 200
chmod 666 /dev/net/tun

grep -q "c 10:200" /etc/pve/lxc/102.conf || echo "lxc.cgroup2.devices.allow: c 10:200 rwm" >> /etc/pve/lxc/102.conf

grep -q "/dev/net" /etc/pve/lxc/102.conf || echo "lxc.mount.entry: /dev/net dev/net none bind,create=dir" >> /etc/pve/lxc/102.conf

pct start 102

이후 LXC에 접속했다.

pct enter 102

네트워크 확인:

ip a
ip route
ping -c 3 1.1.1.1
apt update

정상적으로 아래와 같이 확인되었다.

eth0: 10.10.10.20/24
default via 10.10.10.1
ping 1.1.1.1 성공
apt update 성공

6. WireGuard 설치

LXC 내부에서 WireGuard를 설치했다.

apt install -y wireguard wireguard-tools iptables curl

설치 확인:

wg --version

7. LXC 내부 IP Forward 활성화

LXC 내부에서도 VPN 클라이언트 트래픽을 전달해야 하므로 IP Forward를 활성화했다.

cat > /etc/sysctl.d/99-wireguard.conf << 'EOF'
net.ipv4.ip_forward=1
EOF

sysctl -p /etc/sysctl.d/99-wireguard.conf

정상 결과:

net.ipv4.ip_forward = 1

8. WireGuard 키 생성

LXC 내부에서 서버 키와 클라이언트 키를 생성했다.

mkdir -p /etc/wireguard
cd /etc/wireguard
umask 077

wg genkey | tee server_private.key | wg pubkey > server_public.key
wg genkey | tee client_laptop_private.key | wg pubkey > client_laptop_public.key

파일 확인:

ls -l /etc/wireguard

생성된 파일은 다음과 같다.

server_private.key
server_public.key
client_laptop_private.key
client_laptop_public.key

주의할 점은 private.key 파일은 절대 외부에 공개하면 안 된다.

9. WireGuard 서버 설정

LXC 내부에서 /etc/wireguard/wg0.conf 파일을 생성했다.

SERVER_PRIVATE_KEY=$(cat /etc/wireguard/server_private.key)
CLIENT_PUBLIC_KEY=$(cat /etc/wireguard/client_laptop_public.key)

cat > /etc/wireguard/wg0.conf << EOF
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = ${SERVER_PRIVATE_KEY}

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = ${CLIENT_PUBLIC_KEY}
AllowedIPs = 10.8.0.2/32
EOF

권한 설정:

chmod 600 /etc/wireguard/wg0.conf

여기서 중요한 부분은 다음이다.

Address = 10.8.0.1/24
ListenPort = 51820

WireGuard 서버는 10.8.0.1을 사용하고, UDP 51820 포트에서 대기한다.

클라이언트는 다음 IP를 사용한다.

AllowedIPs = 10.8.0.2/32

10. WireGuard 서비스 시작

WireGuard를 시작하고 자동 시작 설정을 추가했다.

systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0

상태 확인:

systemctl status wg-quick@wg0 --no-pager

정상 상태:

active (exited)
enabled

WireGuard 상태 확인:

wg

정상적으로 아래와 같은 정보가 확인된다.

interface: wg0
  listening port: 51820

peer:
  allowed ips: 10.8.0.2/32

11. Proxmox 호스트에서 포트포워딩 설정

LXC는 내부망인 10.10.10.20에 있기 때문에, 외부에서 Proxmox 공인 IP의 UDP 51820 포트로 들어온 트래픽을 LXC로 전달해야 한다.

LXC에서 나와 Proxmox 호스트에서 작업한다.

exit

Proxmox 호스트에서 아래 명령을 실행했다.

iptables -t nat -A PREROUTING -i vmbr0 -p udp --dport 51820 -j DNAT --to-destination 10.10.10.20:51820

iptables -A FORWARD -i vmbr0 -o vmbr1 -p udp -d 10.10.10.20 --dport 51820 -j ACCEPT

iptables -A FORWARD -i vmbr1 -o vmbr0 -s 10.10.10.20 -j ACCEPT

확인:

iptables -t nat -S | grep 51820
iptables -S FORWARD | grep 10.10.10.20

정상적으로 다음과 같이 확인된다.

-A PREROUTING -i vmbr0 -p udp -m udp --dport 51820 -j DNAT --to-destination 10.10.10.20:51820

-A FORWARD -d 10.10.10.20/32 -i vmbr0 -o vmbr1 -p udp -m udp --dport 51820 -j ACCEPT
-A FORWARD -s 10.10.10.20/32 -i vmbr1 -o vmbr0 -j ACCEPT

12. 클라이언트 설정 파일 생성

다시 LXC에 접속한다.

pct enter 102

클라이언트 설정 파일을 생성한다.

PUBLIC_IP=$(curl -4 -s ifconfig.me)
SERVER_PUBLIC_KEY=$(cat /etc/wireguard/server_public.key)
CLIENT_PRIVATE_KEY=$(cat /etc/wireguard/client_laptop_private.key)

cat > /root/client-laptop.conf << EOF
[Interface]
PrivateKey = ${CLIENT_PRIVATE_KEY}
Address = 10.8.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = ${SERVER_PUBLIC_KEY}
Endpoint = ${PUBLIC_IP}:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
EOF

확인:

cat /root/client-laptop.conf

설정 파일 형태는 다음과 같다.

[Interface]
PrivateKey = 클라이언트_개인키
Address = 10.8.0.2/32
DNS = 1.1.1.1

[Peer]
PublicKey = 서버_공개키
Endpoint = 49.172.xxx.xxx:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

여기서 AllowedIPs = 0.0.0.0/0의 의미는 클라이언트의 모든 IPv4 트래픽을 WireGuard VPN으로 보내겠다는 뜻이다.

즉 외부에서 VPN을 켜면 인터넷 접속도 집 Proxmox 서버를 경유하게 된다.

13. 휴대폰으로 테스트

처음에는 외부 노트북으로 바로 테스트하기 어려워서 휴대폰 LTE로 테스트했다.

휴대폰에 WireGuard 앱을 설치한 뒤, client-laptop.conf 내용을 등록했다. (QR 버전으로 등록 완료)

QR 코드로 conf 등록하는 방법은 다음과 같다.

apt install -y qrencode

qrencode -t ansiutf8 < /root/client-laptop.conf
# 터미널에서 QR코드가 나옴

WireGuard 앱에서 +
→ Create from QR code
→ 화면의 QR 코드 스캔

테스트 조건은 다음과 같다.

휴대폰 Wi-Fi OFF
LTE 상태
WireGuard ON

브라우저에서 아래 사이트에 접속했다.

https://ifconfig.me

결과가 집 공인 IP로 확인되었다.

IP Address: 49.172.xxx.xxx

WireGuard를 Off하게되면 휴대폰 LTE IP로 변경되는 것을 확인했다.

즉, 휴대폰 LTE 상태에서도 VPN을 통해 집 공인 IP로 나가는 것을 확인했다.

서버에서도 확인했다.

wg

정상 연결 시 아래 항목이 보인다.

latest handshake: 몇 초 전
transfer: xx KiB received, xx KiB sent

14. 중복 iptables 룰 정리

작업 중 같은 iptables 룰이 중복으로 들어간 경우가 있었다.

전체 NAT 룰 확인:

iptables -t nat -S

FORWARD 룰 확인:

iptables -S FORWARD

중복된 NAT MASQUERADE 룰은 다음 명령으로 하나 제거했다.

iptables -t nat -D POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

중복된 DNAT 룰은 다음 명령으로 하나 제거했다.

iptables -t nat -D PREROUTING -i vmbr0 -p udp --dport 51820 -j DNAT --to-destination 10.10.10.20:51820

중복된 FORWARD 룰은 다음 명령으로 하나씩 제거했다.

iptables -D FORWARD -d 10.10.10.20/32 -i vmbr0 -o vmbr1 -p udp --dport 51820 -j ACCEPT

iptables -D FORWARD -s 10.10.10.20/32 -i vmbr1 -o vmbr0 -j ACCEPT

최종적으로 남겨야 할 핵심 룰은 다음과 같다.

nat 테이블

-A PREROUTING -i vmbr0 -p udp -m udp --dport 51820 -j DNAT --to-destination 10.10.10.20:51820
-A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE

filter 테이블

-A FORWARD -d 10.10.10.20/32 -i vmbr0 -o vmbr1 -p udp -m udp --dport 51820 -j ACCEPT
-A FORWARD -s 10.10.10.20/32 -i vmbr1 -o vmbr0 -j ACCEPT

정리 후 휴대폰 LTE에서 다시 WireGuard를 켜고 ifconfig.me로 확인했으며, 정상적으로 집 공인 IP가 나왔다.

15. Proxmox 저장소 이슈 해결

iptables 영구화를 위해 apt update를 실행했는데 다음과 같은 에러가 발생했다.

401 Unauthorized
https://enterprise.proxmox.com/debian/pve
https://enterprise.proxmox.com/debian/ceph-squid

원인은 Proxmox 유료 구독용 Enterprise Repository가 활성화되어 있었기 때문이다.

구독을 사용하지 않는 홈랩 환경에서는 Enterprise 저장소를 비활성화하고 No-Subscription 저장소를 사용하면 된다.

현재 환경에서는 다음 저장소를 사용했다.

deb http://download.proxmox.com/debian/pve trixie pve-no-subscription

GUI에서는 다음 경로에서 설정할 수 있다.

pve 노드 선택
→ Updates
→ Repositories
→ Enterprise Repository 비활성화
→ No-Subscription Repository 추가

이후 다시 apt update를 실행하니 정상적으로 완료되었다.

16. iptables 영구화

iptables 룰은 기본적으로 재부팅하면 사라질 수 있다.

따라서 iptables-persistent를 설치해 영구화했다.

apt update
apt install -y iptables-persistent

설치 중 질문은 다음과 같이 선택했다.

Save current IPv4 rules? → Yes
Save current IPv6 rules? → No

설치 후 현재 룰을 저장했다.

netfilter-persistent save

저장 파일 확인:

cat /etc/iptables/rules.v4 | grep 51820
cat /etc/iptables/rules.v4 | grep "10.10.10.0/24"
cat /etc/iptables/rules.v4 | grep "10.10.10.20"

정상적으로 다음과 같은 룰이 저장되어 있어야 한다.

-A PREROUTING -i vmbr0 -p udp -m udp --dport 51820 -j DNAT --to-destination 10.10.10.20:51820
-A POSTROUTING -s 10.10.10.0/24 -o vmbr0 -j MASQUERADE
-A FORWARD -d 10.10.10.20/32 -i vmbr0 -o vmbr1 -p udp -m udp --dport 51820 -j ACCEPT
-A FORWARD -s 10.10.10.20/32 -i vmbr1 -o vmbr0 -j ACCEPT

서비스 활성화 확인:

systemctl is-enabled netfilter-persistent

정상 결과:

enabled

17. LXC 자동 시작 설정

Proxmox 서버가 재부팅되었을 때 VPN LXC도 자동으로 시작되도록 설정했다.

pct set 102 -onboot 1

확인:

pct config 102 | grep onboot

정상 결과:

onboot: 1

또는 GUI에서 다음 경로로 설정할 수 있다.

CT 102(wg-vpn)
→ Options
→ Start at boot
→ Yes

LXC 내부 WireGuard 서비스도 자동 시작 상태인지 확인했다.

pct enter 102
systemctl is-enabled wg-quick@wg0

정상 결과:

enabled

18. 최종 점검 명령어

Proxmox 호스트에서 확인할 명령어:

iptables -t nat -S | grep 51820
iptables -t nat -S | grep "10.10.10.0/24"
iptables -S FORWARD | grep "10.10.10.20"
systemctl is-enabled netfilter-persistent
pct config 102 | grep onboot

LXC 내부에서 확인할 명령어:

systemctl status wg-quick@wg0 --no-pager
wg

클라이언트에서 확인할 것:

WireGuard ON
https://ifconfig.me 접속
집 공인 IP로 보이는지 확인

19. 최종 결과

최종적으로 다음 상태가 되었다.

Proxmox Host
  - 공인 IP: 49.172.xxx.xxx
  - vmbr0: 공인망
  - vmbr1: 내부망 10.10.10.1/24
  - iptables-persistent 활성화

WireGuard LXC
  - CT ID: 102
  - Hostname: wg-vpn
  - IP: 10.10.10.20/24
  - WireGuard Server IP: 10.8.0.1/24
  - Listen Port: UDP 51820
  - Start at boot: enabled

Client
  - VPN IP: 10.8.0.2/32
  - AllowedIPs: 0.0.0.0/0

휴대폰 LTE 환경에서 WireGuard를 켰을 때 ifconfig.me 결과가 집 공인 IP로 확인되었으므로, VPN 구성은 정상적으로 완료되었다.

20. 주의사항

첫 번째, client-laptop.conf 파일에는 클라이언트 개인키가 들어 있다. 블로그나 외부 문서에 절대 그대로 올리면 안 된다.

PrivateKey = 절대_공개_금지

두 번째, 같은 클라이언트 설정을 휴대폰과 노트북에서 동시에 사용하면 안 된다.

예를 들어 휴대폰과 노트북이 둘 다 아래 설정을 동시에 사용하면 충돌이 발생할 수 있다.

같은 PrivateKey
같은 Address = 10.8.0.2/32

테스트 후 휴대폰에서 터널을 삭제하고 노트북에서 같은 설정을 사용하는 것은 괜찮다. 하지만 운영용으로는 기기별로 Peer를 분리하는 것이 좋다.

노트북: 10.8.0.2/32
휴대폰: 10.8.0.3/32

세 번째, 가정용 인터넷의 공인 IP는 유동 IP일 수 있다. 집 공인 IP가 바뀌면 회사에 등록된 허용 IP도 다시 변경해야 한다.

네 번째, Proxmox 호스트와 LXC를 재부팅해도 VPN이 자동 복구되려면 아래 세 가지가 모두 되어 있어야 한다.

1. netfilter-persistent enabled
2. CT 102 onboot enabled
3. wg-quick@wg0 enabled

마무리

이번 구성으로 외부에서도 WireGuard VPN을 통해 집 Proxmox 서버를 경유할 수 있게 되었다.

결과적으로 카페나 외부 장소에서 노트북을 사용하더라도 회사 시스템에는 항상 집 공인 IP로 접속하는 구조가 완성되었다.

외부 노트북
  → WireGuard
  → 집 Proxmox
  → 집 공인 IP
  → 회사 시스템

리소스도 매우 적게 사용한다.

WireGuard LXC
CPU: 1 Core
Memory: 512MB
Disk: 5GB

따라서 작은 홈서버나 Proxmox 환경에서도 부담 없이 운영할 수 있는 구성이라고 볼 수 있다.

Proxmox 세팅

Wed, 24 Jun 2026 04:22:28 GMT

Proxmox 란?

하나의 물리 서버를 통해 다수의 가상 머신(VM) 및 컨테이너를 생성하고 관리할 수 있는 오픈소스 가상화 플랫폼

설치

1. 설치 전 준비

설치할 PC 또는 서버 준비
설치 대상 디스크 확인
기존 데이터 백업
BIOS/UEFI 진입
가상화 옵션 활성화 Intel: VT-x AMD: SVM Secure Boot는 문제가 생기면 비활성화

2. Proxmox VE ISO 다운로드

Proxmox 공식 사이트에서 Proxmox VE ISO 다운로드 https://www.proxmox.com/en/downloads/proxmox-virtual-environment/iso

3. 부팅 USB 생성

Rufus 또는 Ventoy 사용
USB에 Proxmox ISO 적용
설치할 장비에 USB 연결

4. USB로 부팅

부팅 메뉴 진입
USB 선택
Proxmox VE Installer 실행
참고: 그래픽 화면에서 멈추거나 검은 화면이 나오면 부팅 옵션에 nomodeset을 추가*
```
옵션 설정 순서
```

Proxmox 설치 USB로 부팅 Proxmox 부팅 메뉴에서 Install Proxmox VE 선택 위치로 이동 바로 Enter 누르지 말고 키보드에서 e 입력 부팅 옵션 편집 화면이 열림 linux 또는 linuxefi로 시작하는 줄을 찾기 해당 줄 끝부분에 nomodeset 추가


#### 5. Proxmox 설치 시작
- Install Proxmox VE 선택
- 라이선스 동의
- 설치 대상 디스크 선택
- 여기서 선택한 디스크는 초기화되므로 반드시 확인
![](https://velog.velcdn.com/images/sunny-10/post/f12f7d00-3b67-4f4e-8601-dbf179ce9cef/image.jpg)


#### 6. 디스크 구성 선택
- 단일 디스크 테스트용이면 기본값으로 진행 가능
- 운영 또는 홈랩 장기 사용이면 ZFS, RAID 구성 여부 검토

#### 7. 국가/시간대/키보드 설정
- Country: Korea
- Time zone: Asia/Seoul
- Keyboard: 보통 English 또는 사용하는 키보드에 맞게 선택

#### 8. 관리자 계정 설정
- root 비밀번호 입력
- 관리자 이메일 입력
- 로그인 계정은 기본적으로 root@pam

#### 9. 네트워크 설정
- Management Interface 선택
- Hostname 설정 예시: pve.local
- IP 주소 설정
- Gateway 설정
- DNS 설정

#### 10. 설치 진행 및 재부팅
- 설정 확인 후 Install
- 설치 완료 후 USB 제거
- Reboot

#### 11. 웹 콘솔 접속
- 같은 네트워크의 PC에서 브라우저 접속
  https://Proxmox_IP:8006
- 인증서 경고는 자체 서명 인증서라서 처음에는 정상적으로 보일 수 있음
- 로그인 계정: root@pam
![](https://velog.velcdn.com/images/sunny-10/post/d2242fc5-8953-4fa6-ac0e-0ae358173001/image.png)


#### 12. 설치 후 기본 설정
- 업데이트 저장소 확인
- 구독이 없는 테스트/홈랩 환경이면 no-subscription 저장소를 사용할 수 있음
- 공식 문서상 no-subscription 저장소는 구독키 없이 사용할 수 있지만, 테스트/비운영 용도에 가깝고 운영용으로는 Enterprise Repository가 권장

#### 13. 업데이트 실행
- Proxmox 웹 콘솔 또는 Shell에서 업데이트
```apt update
apt full-upgrade -y

기본 확인
노드 상태 확인
스토리지 확인
네트워크 브리지 확인 보통 기본 브리지는 vmbr0
CPU, 메모리, 디스크 인식 확인

14. VM 생성 준비

ISO 업로드
VM 생성
CPU, Memory, Disk 설정
Windows VM이면 VirtIO ISO도 함께 준비
Linux VM이면 일반 ISO만으로도 설치 가능

본 구성에서는 Windows VM 세팅

Windows VM 설치가 안될 경우, Options > Boot Order 에 진입하여 Boot 순서 확인 virtio가 1순위일 경우 부팅이 제대로 되지 않음

화면 배율 설정 방법 Windows 배경화면에서 디스플레이 설정 시 해상도 설정이 안될 경우

Boot Device 화면 진입 EFI Firmware Setup > Device Manager > OVMF Platform Configuration > Preferred Resolution 을 통해 원하는 해상도 설정(1920 x 1080) 이후 재시작

CloudForet SCP Provider 및 Custom Collector 구성 핵심 정리

Tue, 16 Jun 2026 06:25:02 GMT

1. 전체 목표

CloudForet에서 기본 지원하지 않는 Samsung Cloud Platform(SCP)의 Virtual Server 정보를 수집하기 위해 Custom Provider, Secret Schema, Plugin, Service Account, Collector를 구성하고, SCP OpenAPI를 호출하는 Custom Inventory Collector를 제작하였다.

최종 목표는 SCP OpenAPI에서 조회한 VM 정보를 CloudForet의 inventory.CloudService 리소스로 변환하여 CloudForet 콘솔에서 SCP 서버 목록을 확인하는 것이다.

2. CloudForet 수집 구조의 핵심 구성요소

CloudForet에서 외부 CSP 리소스를 수집하려면 다음 구성요소가 필요하다.

Provider

Provider는 CloudForet에서 CSP 또는 외부 플랫폼을 구분하는 기준이다.

이번 실습에서는 scp Provider를 생성하여 Samsung Cloud Platform을 CloudForet 내 독립 Provider로 인식하게 했다.

핵심 값:

provider: scp
name: Samsung Cloud Platform

Provider가 없으면 Service Account, Secret, Collector가 어느 CSP에 속하는지 구분할 수 없다.

Secret Schema

Secret Schema는 해당 Provider에 접속하기 위해 어떤 인증 정보가 필요한지 정의하는 구조다.

이번 SCP Collector에서는 SCP OpenAPI 호출을 위해 다음 값이 필요했다.

access_key
access_secret_key
project_id
client_type
language
resource_type
base_endpoint
region_code
ssl_verify

핵심은 access_key, access_secret_key, project_id가 필수 인증값이라는 점이다.

Secret Schema는 UI 입력 폼과 Secret 저장 구조의 기준이 된다.

Repository Plugin

Repository Plugin은 CloudForet가 실제로 실행할 Collector Plugin 이미지 정보를 정의한다.

이번 실습에서는 Docker Hub에 Custom Collector 이미지를 push하고 CloudForet Plugin으로 등록했다.

핵심 값:

plugin_id: scp-vm-collector
provider: scp
service_type: inventory.Collector
image: ypjs09/scp-vm-collector
registry_type: DOCKER_HUB
version: 0.1.9

중요한 점은 Docker Hub에 이미지를 push하는 것과 CloudForet Repository에 Plugin 버전이 등록되는 것은 별개라는 것이다.

CloudForet가 모르는 버전으로 Collector를 생성하면 다음과 같은 오류가 발생한다.

version does not exist

Service Account

Service Account는 특정 Provider의 계정 또는 프로젝트 단위를 CloudForet에 등록하는 객체다.

이번 실습에서는 SCP 프로젝트를 하나의 Service Account로 등록했다.

핵심 값:

provider: scp
service_account_id: sa-d88be3973e9a
scope: PROJECT
project_id: project-2bcfd61ce098

Service Account는 “어떤 SCP 프로젝트를 수집할 것인가”를 나타낸다.

Secret

Secret은 Service Account에 연결되는 실제 인증 정보다.

이번 실습에서 중요한 트러블슈팅 포인트는 Service Account는 있었지만 Secret이 없어서 Collector JobTask가 생성되지 않았던 점이다.

즉, CloudForet 수집 흐름에서는 다음 연결이 반드시 필요하다.

Provider
  → Service Account
    → Secret
      → Collector

Secret이 없으면 Collector가 어떤 인증 정보로 수집해야 하는지 알 수 없다.

Collector

Collector는 특정 Plugin을 이용해서 실제 수집 작업을 수행하는 객체다.

이번 실습의 최종 Collector는 다음과 같다.

collector_id: collector-71452b876d46
name: SCP VM Collector 019
provider: scp
plugin_id: scp-vm-collector
version: 0.1.9
secret_filter:
  service_accounts:
    - sa-d88be3973e9a

Collector의 핵심은 plugin_info와 secret_filter다.

plugin_info는 어떤 Collector Plugin 이미지를 실행할지 결정하고, secret_filter는 어떤 Service Account/Secret을 대상으로 수집할지 결정한다.

3. 구성 순서

이번 실습에서 성공한 전체 순서는 다음과 같다.

1. SCP Provider 생성
2. SCP Secret Schema 생성
3. Docker Hub에 Custom Collector 이미지 push
4. Repository Plugin 등록
5. SCP Service Account 생성
6. SCP Secret 생성
7. Collector 생성
8. Collect Data 실행
9. Job / JobTask 확인
10. CloudService 수집 결과 확인

이 순서 중 하나라도 빠지면 수집이 실패한다.

특히 중요한 순서는 다음이다.

Service Account 생성 후 반드시 Secret을 생성해야 함
Collector 생성 시 Secret Filter에 Service Account를 연결해야 함
Collector Plugin 버전은 CloudForet가 인식하는 버전이어야 함

4. Custom Collector 코드에서 가장 중요했던 부분

CloudForet Inventory Collector는 단순히 데이터를 반환하는 것이 아니라, CloudForet가 이해할 수 있는 응답 구조로 반환해야 한다.

이번 실습에서 Collector가 반환해야 했던 핵심 구조는 다음이다.

{
    "resource_type": "inventory.CloudService",
    "resource": resource,
    "match_rules": {
        "1": ["reference.resource_id"]
    }
}

CloudServiceType은 다음 기준으로 매칭했다.

{
    "resource_type": "inventory.CloudServiceType",
    "resource": resource,
    "match_rules": {
        "1": ["name", "provider", "group"]
    }
}

핵심 포인트는 다음이다.

resource_type은 최상위에 있어야 함
resource 내부에만 resource_type이 있으면 인식하지 못함
match_rules가 없으면 ERROR_MATCH_RULE 발생
match_rules는 list가 아니라 dict 형태여야 함

5. 주요 트러블슈팅 정리

1) Job은 생성되지만 JobTask가 생성되지 않음

원인:

SCP Service Account는 있었지만 연결된 Secret이 없었음

해결:

secret.Secret 생성
schema: scp_openapi
service_account_id: SCP Service Account ID
project_id: CloudForet Project ID

2) resource_type None 오류

에러:

collector can not find resource_type: None

원인:

Collector 응답에서 resource_type이 최상위가 아니라 resource 내부에만 존재했음

해결:

to_primitive()에서 resource_type을 최상위 필드로 이동

3) ERROR_MATCH_RULE

에러:

No match rule

원인:

CloudForet가 리소스를 생성/업데이트할 기준을 찾지 못함

해결:

match_rules = {
    "1": ["reference.resource_id"]
}

CloudServiceType의 경우:

match_rules = {
    "1": ["name", "provider", "group"]
}

4) match_rules 파싱 오류

에러:

Failed to parse match_rules field
Struct must be in a dict

원인:

match_rules = [["reference.resource_id"]]

처럼 list 형태로 반환했기 때문이다.

해결:

match_rules = {
    "1": ["reference.resource_id"]
}

처럼 dict 형태로 수정했다.

5) Collector Plugin 버전 변경이 안 됨

문제:

기존 Collector를 update해도 plugin_info.version이 0.1.8에서 0.1.9로 바뀌지 않음

원인:

inventory.Collector update API는 plugin_info 변경을 지원하지 않음

해결:

기존 Collector를 수정하는 대신 새 Collector를 생성

6) version does not exist 오류

에러:

version:0.1.10 of scp-vm-collector does not exist

원인:

Docker Hub에는 0.1.10 이미지를 push했지만 CloudForet Repository Plugin 버전으로는 등록되지 않았음

해결:

CloudForet가 이미 알고 있는 0.1.9 태그를 재빌드/재푸시하여 사용

7) ERROR_GRPC_CONNECTION

에러:

Channel is not ready
Server is unavailable

원인:

동적 Collector Pod가 Ready 되기 전에 Job이 수집을 시도하거나,
Service는 존재하지만 Endpoints가 비어 있었음

해결:

Service selector에 맞는 수동 Deployment를 생성하여 Endpoint를 강제로 유지

확인 포인트:

kubectl get endpoints -n spaceone-plugin scp-vm-collector-wjdnuksxfqujxcoe -o wide

정상 예시:

10.42.0.45:50051

6. 운영 관점에서 배운 핵심

이번 실습의 핵심은 Collector 코드보다 CloudForet 내부 수집 흐름을 이해한 것이다.

CloudForet Inventory 수집은 다음 순서로 동작한다.

Collector 실행
→ 연결된 Service Account 조회
→ 연결된 Secret 조회
→ Plugin Pod 실행
→ gRPC로 Collector Plugin 호출
→ collect() 결과 수신
→ resource_type 확인
→ match_rules 기준으로 기존 리소스 매칭
→ CloudService 생성 또는 업데이트

따라서 장애를 볼 때는 다음 순서로 확인해야 한다.

1. Collector가 올바른 plugin version을 보고 있는가
2. Service Account가 연결되어 있는가
3. Secret이 존재하는가
4. Plugin Pod가 뜨는가
5. Service Endpoint가 있는가
6. gRPC 연결이 되는가
7. collect 응답에 resource_type이 있는가
8. match_rules가 올바른 dict 구조인가
9. CloudService 필드 구조가 CloudForet 스키마와 맞는가

7. 최종 성과

최종적으로 SCP OpenAPI를 통해 조회한 Virtual Server 정보를 CloudForet Inventory 리소스로 변환하여 수집에 성공했다.

수집 대상은 SCP Virtual Server이며, CloudForet에서는 다음 구조로 표현된다.

Provider: scp
Cloud Service Group: VirtualServer
Cloud Service Type: VM
Resource Type: inventory.CloudService

이번 작업을 통해 CloudForet에서 기본 지원하지 않는 CSP도 Custom Provider와 Custom Collector를 통해 확장할 수 있음을 검증했다.

CloudForet Custom Collector 개발의 핵심은 API 호출 자체보다, CloudForet Inventory Worker가 해석할 수 있는 resource_type, resource, match_rules 구조를 정확히 맞추는 것이다.

CloudForet 활용(심화)

Fri, 12 Jun 2026 06:14:15 GMT

앞서 최소사양으로 CloudForet을 구성 및 AWS와 연동 다만, 멀티 클라우드 관리에 대한 확인을 하고 싶어 심화 과정 시작

구성

현재 AWS는 연동되어 있는 상태 SCP를 추가적으로 연동하여 멀티 클라우드 관리 진행

SCP Plugin이 없으므로 아래와 같이 진행하기로 결정

1단계: SCP API로 VM 목록 조회하는 Python 스크립트 성공
2단계: 조회 결과를 CloudForet Inventory CloudService 포맷으로 변환
3단계: SpaceONE Collector Plugin 구조로 패키징
4단계: Docker 이미지 빌드
5단계: CloudForet에 Plugin 등록
6단계: Collector 생성 후 SCP Service Account 연결
7단계: Cloud Service 화면에 SCP VM 표시 확인

1단계

SCP API로 VM 목록 조회하는 Python 스크립트 성공

===============================================================================
🔍 SCP Virtual Server 목록 조회 시작
================================================================================
스크립트 위치: c:\Users\user\Desktop\MZC\Z-mzc\OpenAPI 작업
인증정보 파일: c:\Users\user\Desktop\MZC\Z-mzc\OpenAPI 작업\scp_credentials.json
결과 저장 파일: c:\Users\user\Desktop\MZC\Z-mzc\OpenAPI 작업\scp_vm_list.parsed.json

================================================================================
⚙️ 설정 요약
================================================================================
OpenAPI Endpoint: https://openapi.samsungsdscloud.com
Project ID: PROJECT-
Client Type: OpenApi
Resource Type: PROJECT
Language: en-US
SSL Verify: False
Access Key: sBAM****

📄 페이지 조회 중: page=0, size=100
   HTTP Status Code: 200
   전체 VM 개수: 5
   현재까지 조회된 VM 수: 5

================================================================================
✅ SCP VM 조회 완료: 5개
================================================================================
[1] name=bastion-001, id=INSTANCE-H0n--iGlIgfhed, state=STOPPED, private_ip=192.168, image_id=IMAGE-TYn75EWMtgcTM7qZBaL7-a, service=Virtual Server, created_at=2026-05-28T11:23:17.263794+09:00
[2] name=backup-02-001, id=INSTANCE-TsS62YOMYpJVTyd, state=STOPPED, private_ip=192.168, image_id=IMAGE-k4Vwue-usTcVS9tp0chgGa, service=Virtual Server, created_at=2026-05-28T11:21:47.861308+09:00
[3] name=backup-01-001, id=INSTANCE-_L-p8BkBiZSgZuYCm, state=STOPPED, private_ip=192.168, image_id=IMAGE-TYn75EWMtgcTM7qZBaL7-a, service=Virtual Server, created_at=2026-05-28T11:19:48.349298+09:00
[4] name=vm-pms-test, id=INSTANCE-4rNcjYmNs7dji4Amd, state=RUNNING, private_ip=192.168, image_id=IMAGE-25Z0imVfs2mMGxiBMnKmop, service=Virtual Server, created_at=2026-04-20T14:51:47.746695+09:00
[5] name=test-001, id=INSTANCE-7W1BHSAZtvfH15gj, state=STOPPED, private_ip=192.168, image_id=IMAGE-25Z0imVfs2mMGxiBMnKmop, service=Virtual Server, created_at=2026-03-06T13:45:30.489579+09:00

================================================================================
💾 파일 저장 완료
================================================================================
파일 경로: c:\Users\user\Desktop\MZC\Z-mzc\OpenAPI 작업\scp_vm_list.parsed.json
파일 크기: 5,399 bytes

================================================================================
✅ 작업 완료
================================================================================
PS C:\Users\user\Desktop\MZC\Z-mzc\OpenAPI 작업>

2단계

SCP Collector Plugin 생성

예상 구조

scp-vm-inven-collector/
├── Dockerfile
├── requirements.txt
├── setup.py
└── src/
  └── spaceone/
      └── inventory/
          └── plugin/
              └── collector/
                  ├── service.py
                  ├── connector/
                  │   └── scp_connector.py
                  └── manager/
                      └── vm_manager.py

현재 구조

src/spaceone/inventory/conf/global_conf.py
src/spaceone/inventory/conf/__init__.py
src/spaceone/inventory/connector/__init__.py
src/spaceone/inventory/connector/__pycache__/__init__.cpython-311.pyc
src/spaceone/inventory/connector/__pycache__/scp_connector.cpython-311.pyc
src/spaceone/inventory/connector/scp_connector.py
src/spaceone/inventory/__init__.py
src/spaceone/inventory/interface/grpc/collector.py
src/spaceone/inventory/interface/grpc/__init__.py
src/spaceone/inventory/interface/grpc/__pycache__/collector.cpython-311.pyc
src/spaceone/inventory/interface/grpc/__pycache__/__init__.cpython-311.pyc
src/spaceone/inventory/interface/__init__.py
src/spaceone/inventory/manager/__init__.py
src/spaceone/inventory/manager/__pycache__/vm_manager.cpython-311.pyc
src/spaceone/inventory/manager/vm_manager.py
src/spaceone/inventory/__pycache__/__init__.cpython-311.pyc
src/spaceone/inventory/service/collector_service.py
src/spaceone/inventory/service/__init__.py
src/spaceone/inventory/service/__pycache__/collector_service.cpython-311.pyc
src/spaceone/inventory/service/__pycache__/__init__.cpython-311.pyc

3단계

spacectl를 이용한 SCP Provider 등록

사전에 SCP Provider에서 사용할 Service Account 생성 필요

Trouble Shooting

콘솔에서 SCP용 Service Account 생성 시 Add 버튼 비활성으로 SA 생성 실패 → spacectl을 이용하여 생성

kubectl exec -i -n spaceone spacectl -- sh -c 'cat > /tmp/scp_service_account.yaml' <


콘솔에서 SCP용 Collector 생성 시
Collector 생성 실패 → spacectl을 이용하여 생성
kubectl exec -i -n spaceone spacectl -- sh -c 'cat > /tmp/scp_collector.yaml' <<'EOF'
---
name: SCP VM Collector
provider: scp
plugin_info:
  plugin_id: scp-vm-collector
  version: "0.1.8"
  upgrade_mode: MANUAL
schedule:
  state: DISABLED
secret_filter:
  state: ENABLED
  service_accounts:
    - sa-d88be3973e9a
tags:
  description: SCP VM Collector created by CLI
EOF

kubectl exec -n spaceone spacectl -- \
  spacectl exec create inventory.Collector -f /tmp/scp_collector.yaml

결과
기존에 없던 삼성클라우드플랫폼(SCP) Provider 생성 후
AWS와 SCP의 멀티클라우드 관리 가능 확인


자세한 과정은 다음 게시글에서 핵심 정리



CloudForet 활용 (최소 사양)
Mon, 08 Jun 2026 08:16:37 GMT
CloudForet 란
CloudForet는 한마디로 말하면 오픈소스 멀티클라우드 관리 플랫폼(CMP, Cloud Management Platform)
예전에는 SpaceONE이라는 이름으로 시작되었고, 현재는 CloudForet라는 이름으로 발전했으며, Linux Foundation 프로젝트로 운영됨
AWS, Azure, GCP, OpenStack, Kubernetes 등 여러 클라우드 환경을 하나의 화면에서 통합 관리할 수 있도록 해줌
전체 구성
현재 서버는 아래와 같이 구성

1core / 2Memory / 100GB / Rocky 8.10 / 1대
최소 구동 확인용으로 시작

다만, 1C / 2GB는 공식 최소 사양보다 낮기 때문에 “CloudForet 콘솔 접속 + 리소스 몇 개 조회 테스트” 목적
공식 개발용 권장은 2Core / 8GB / 30GB Disk, 최소 설치 예제도 3GB 메모리 이상을 전제로 함
Rocky 8.10 VM
 ├─ Swap 4GB
 ├─ k3s
 ├─ kubectl
 ├─ helm
 └─ CloudForet
     ├─ console
     ├─ inventory
     ├─ identity
     ├─ mongodb
     └─ redis
사전 설정
Swap 4GB 추가 / k3s 설치 / helm 설치 / CloudForet Helm Repo 추가 / Namespace 생성 / RBAC 적용 
1) 최소 설치용 values 파일 준비
1C/2GB에서는 기본 설치하면 Pod가 너무 많이 떠서 거의 버거움
CloudForet 최소 설치 예제에서는 cost-analysis, notification 등을 끄고 scheduler/worker를 줄이는 방식을 사용
wget https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/values/minimum.yaml -O minimum.yaml
cp minimum.yaml minimum-1c2g.yaml
vi minimum-1c2g.yaml
global:
  shared_conf:
    LOG_LEVEL: INFO

cost-analysis:
  enabled: false

notification:
  enabled: false

marketplace-assets:
  enabled: false

plugin:
  enabled: true
  scheduler: false
  worker: false

inventory:
  enabled: true
  scheduler: false
  worker: false

monitoring:
  enabled: false

statistics:
  enabled: false
2) CloudForet 설치
helm install cloudforet cloudforet/spaceone \
  -n spaceone \
  -f minimum-1c2g.yaml
kubectl get pods -n spaceone -w
3) 초기화 작업
wget https://raw.githubusercontent.com/cloudforet-io/charts/master/examples/initializer.yaml -O initializer.yaml

helm install cloudforet-initializer cloudforet/spaceone-initializer \
  -n spaceone \
  -f initializer.yaml
kubectl get pods -n spaceone | grep initialize
kubectl logs -n spaceone $(kubectl get pod -n spaceone | grep initialize | awk '{print $1}')
로그 끝 부분 확인 시 'FINISH SPACEONE INITIALIZE' 문구 확인
콘솔 접속
폐쇄망 환경으로 SSH Port Forwarding 진행

VM 서버
nohup kubectl port-forward -n spaceone svc/console 8080:80 >/tmp/console.log 2>&1 &
nohup kubectl port-forward -n spaceone svc/console-api 8081:80 >/tmp/console-api.log 2>&1 &
nohup kubectl port-forward -n spaceone svc/console-api-v2-rest 8082:80 >/tmp/console-api-v2.log 2>&1 &
접속 PC 터미널
ssh -i pemkey -L 8080:127.0.0.1:8080 -L 8081:127.0.0.1:8081  -L 8082:127.0.0.1:8082 vmuser@VMIP
콘솔 접속
도메인  : root
초기 ID : admin
초기 PW : Admin123!@#


최소 사양으로 구성하여 서비스 접속 및 로그인에 초점을 둠


구성 확장
minimum.yaml 수정
플러그인 및 인벤토리 worker 활성화 > helm update -f 
plugin:
  enabled: true
  scheduler: false
  worker: true

inventory:
  enabled: true
  scheduler: false
  worker: true
1) 유저 추가
root 도메인으로 admin 접속
[IAM] +add 통한 유저 추가
초기 ID : 설정
초기 PW : 설정

2) 신규 유저 계정으로 접속
도메인 변경 (root 도메인X)

3) 현재 상황
✅ Root Domain 생성
✅ User Domain(spaceone) 생성
✅ Managed Repository 생성
✅ Domain Admin User 생성
✅ Role / Policy 생성
✅ Console ↔ Repository 연동 성공
✅ Dashboard 메뉴 활성화
✅ Asset Inventory 메뉴 활성화
✅ Cost Explorer 메뉴 활성화
✅ Alert Manager 메뉴 활성화
4) Service Account 생성

5) Collector 생성

6) Collector Data 확인
AWS에서 신규 생성한 볼륨을 SpaceOne에서 확인 완료 (연동)

Trouble Shooting
1) Github 다운로드 실패
curl -sfL https://get.k3s.io | sh - 
[INFO] Finding release for channel stable 
[INFO] Using v1.35.5+k3s1 as release 
[INFO] Downloading hash https://github.com/k3s-io/k3s/releases/download/v1.35.5%2Bk3s1/sha256sum-amd64.txt [ERROR] Download failed
확인 사항
# 1. DNS 확인
nslookup github.com

# 2. GitHub HTTPS 접근 확인
curl -Iv https://github.com

# 3. 실제 실패한 파일 직접 확인
curl -IvL "https://github.com/k3s-io/k3s/releases/download/v1.35.5%2Bk3s1/sha256sum-amd64.txt"

# 4. 프록시 환경변수 확인
env | grep -i proxy
확인 결과
DNS 정상 / TCP 443 정상 / TLS 인증서 정상 / GitHub 응답은 오는데 HTTP/2 504 발생
아래 명령어를 통해 해결
curl -4 --http1.1 -sfL https://get.k3s.io | INSTALL_K3S_VERSION=v1.32.6+k3s1 sh -
원인
GitHub 접속 자체는 가능
↓
HTTP/2 환경에서 GitHub Release 다운로드 실패 (504)
↓
k3s 최신버전(v1.35.5) 다운로드 실패
↓
구버전(v1.32.6) + HTTP/1.1 경로로 우회 성공
2) Github 다운로드 실패2
Error: INSTALLATION FAILED: failed to fetch https://github.com/cloudforet-io/charts/releases/download/spaceone-1.12.15/spaceone-1.12.15.tgz : 504 Gateway Timeout
로컬에서 수동으로 다운로드 → SCP를 통해 VM 업로드하여 해결
3) 404 에러


3-1) 증상
CloudForet Console 접속 시 로그인 화면이 아니라 아래 화면으로 이동함.
http://localhost:8080/error-page
404
Sorry, we can’t seem to find what you’re looking for.
처음에는 Console 정적 페이지는 뜨지만, 내부 API 호출 실패로 인해 /error-page로 이동하는 상태
3-2) 실제 원인
원인 1.
본체: cloudforet/*:2.0.dev*
initializer: cloudforet/spacectl:1.12.1

cloudforet/spacectl:1.12.1  ← 존재
cloudforet/spacectl:1.12.12 ← 없음
cloudforet/spacectl:1.12.13 ← 없음
cloudforet/spacectl:1.12.15 ← 없음
cloudforet/spacectl:latest  ← 없음
spaceone-1.12.15 chart를 사용했을 때는 본체 이미지가 2.0.dev 계열로 배포되어 spacectl:1.12.1과 API 버전이 맞지 않음
No module named 'spaceone.api.identity.v2'
그래서 본체 chart를 1.12.12로 낮춰서 spacectl:1.12.1과 호환되도록 맞췄음
원인 2.
Console API Endpoint가 예제값으로 남아 있었음
console-conf ConfigMap 안의 production.json이 아래처럼 되어 있었음
"CONSOLE_API": {
  "ENDPOINT": "https://console.api.example.com"
},
"CONSOLE_API_V2": {
  "ENDPOINT": "https://console-v2.api.example.com"
}
즉 브라우저가 실제 VM의 API가 아니라 존재하지 않는 예제 주소로 요청
그래서 Console 화면은 뜨지만 API 호출이 실패했고, 결과적으로 404 페이지로 이동
원인 3. 
로컬 브라우저 기준 8081, 8082 터널링이 빠졌음
Console 설정을 아래처럼 변경
"CONSOLE_API": {
  "ENDPOINT": "http://localhost:8081"
},
"CONSOLE_API_V2": {
  "ENDPOINT": "http://localhost:8082"
}
그런데 브라우저에서 보는 localhost는 VM의 localhost가 아니라 내 PC의 localhost이므로 VM에서만 포트포워딩을 해서는 부족
구조는 아래와 같아야 함
내 PC 브라우저 localhost:8080
  → SSH 터널
  → VM localhost:8080
  → Kubernetes svc/console

내 PC 브라우저 localhost:8081
  → SSH 터널
  → VM localhost:8081
  → Kubernetes svc/console-api

내 PC 브라우저 localhost:8082
  → SSH 터널
  → VM localhost:8082
  → Kubernetes svc/console-api-v2-rest
8080만 SSH 터널링하면 Console 정적 화면은 뜨지만, API 호출은 실패
원인 4.
Initializer가 제대로 완료되지 않아 초기 데이터가 불완전했음
처음 initializer 실행 시 아래 오류가 발생했음
channel = identity:50051
Channel is not ready
원인은 identity 서비스가 완전히 준비되기 전에 initializer가 실행되었기 때문
또 한 번은 namespace가 맞지 않아 initializer가 다른 namespace에서 identity:50051을 찾으면서 실패
global:
  namespace: cloudforet
CloudForet 본체는 spaceone namespace에 있었기 때문에 아래처럼 수정
global:
  namespace: spaceone
3-3) 해결 과정
1단계. CloudForet 본체 버전 정리
기존 1.12.15 제거 후 1.12.12로 재설치
helm uninstall cloudforet-initializer -n spaceone
helm uninstall cloudforet -n spaceone
curl -4 --http1.1 -L -o spaceone-1.12.12.tgz \
https://github.com/cloudforet-io/charts/releases/download/spaceone-1.12.12/spaceone-1.12.12.tgz
helm install cloudforet ./spaceone-1.12.12.tgz \
  -n spaceone \
  -f minimum-1c2g.yaml
2단계. Initializer namespace 수정
initializer.yaml을 수정
global:
  namespace: spaceone

설치:
helm install cloudforet-initializer cloudforet/spaceone-initializer \
  -n spaceone \
  -f initializer.yaml
3단계. Console API endpoint 수정
console-conf의 production.json을 수정
kubectl patch cm console-conf -n spaceone --type merge -p \
'{"data":{"production.json":"{\"AMCHARTS_LICENSE\":{\"CHARTS\":\"\",\"MAPS\":\"\",\"TIMELINE\":\"\"},\"ASSET_PATH\":{},\"CONSOLE_API\":{\"ENDPOINT\":\"http://localhost:8081\"},\"CONSOLE_API_V2\":{\"ENDPOINT\":\"http://localhost:8082\"},\"DOMAIN_IMAGE\":{},\"DOMAIN_NAME\":\"spaceone\",\"DOMAIN_NAME_REF\":\"config\",\"GTAG_ID\":\"DISABLED\",\"GTM_ID\":\"DISABLED\",\"MOCK\":{\"ALL\":false,\"ENDPOINT\":\"\"}}"}}'

Console Pod 재시작:
kubectl delete pod -n spaceone -l app.kubernetes.io/name=console

확인:
kubectl exec -n spaceone deploy/console -- cat /var/www/config/production.json
4단계. VM 내부 Kubernetes 포트포워딩
VM에서 실행:
kubectl port-forward -n spaceone svc/console 8080:80
kubectl port-forward -n spaceone svc/console-api 8081:80
kubectl port-forward -n spaceone svc/console-api-v2-rest 8082:80
백그라운드 실행 버전:
nohup kubectl port-forward -n spaceone svc/console 8080:80 >/tmp/console.log 2>&1 &
nohup kubectl port-forward -n spaceone svc/console-api 8081:80 >/tmp/console-api.log 2>&1 &
nohup kubectl port-forward -n spaceone svc/console-api-v2-rest 8082:80 >/tmp/console-api-v2.log 2>&1 &
5단계. 로컬 PC에서 SSH 터널링
로컬 PC에서 실행:
ssh -i pms-test2.pem \
  -L 8080:127.0.0.1:8080 \
  -L 8081:127.0.0.1:8081 \
  -L 8082:127.0.0.1:8082 \
  vmuser@123.37.28.73
콘솔 접속 : http://localhost:8080/sign-in
3-4) 확인했던 주요 증거
Console 정적 파일은 정상
GET / 200
GET /assets/index...js 200
GET /config/production.json 200
즉 nginx나 console Pod 자체 문제는 아니었음
API endpoint가 example.com으로 되어 있었음
"CONSOLE_API":{"ENDPOINT":"https://console.api.example.com"}
/reflection 요청이 실패했음
브라우저 DevTools에서 확인:
Request URL: http://localhost:8081/api/reflection
Console API 로그:
Token is not set. (Headers.authorization: Bearer )
이 자체는 로그인 전이면 발생 가능하지만, 로그인 화면으로 정상 진입하지 못하는 상태에서는 API endpoint/초기화 문제 확인 포인트가 되었음
Initializer 실패 로그
ERROR_GRPC_CONNECTION
channel = identity:50051
Channel is not ready
그리고 버전 불일치 시:
No module named 'spaceone.api.identity.v2'
3-5) 최종 결론
이번 404 에러의 핵심 원인은 다음과 같다.

Console 설정의 API endpoint가 example.com으로 남아 있었음
로컬 브라우저 기준 8081/8082 SSH 터널링이 빠져 있었음
Initializer가 identity 준비 전 실행되거나 namespace/version 불일치로 초기화가 불완전했음

최종 해결은 다음 조합으로 완료함
CloudForet chart: 1.12.12
Initializer namespace: spaceone
Console API endpoint: localhost:8081 / localhost:8082
VM port-forward: 8080, 8081, 8082
Local SSH tunnel: 8080, 8081, 8082
Browser cache/site data 초기화 후 /sign-in 접속
Collector 생성 시 에러
Collector 신규 생성 시 
Service Account 선택(oliver) 후 
Additional Options Reload 발생

원인
AWS Collector 플러그인을 실행할 Supervisor가 등록되어 있지 않아 발생
→ TOKEN 오류
   spaceone 서비스 계정에서 토큰 생성하여 conf 파일에 추가, 업데이트
→ RBAC 403 오류

supervisor가 바라보는 spaceone-plugin 네임스페이스 생성
spaceone-plugin 네임스페이스에 Role 생성
spaceone 네임스페이스의 default ServiceAccount를 그 Role에 RoleBinding

문제:
supervisor-scheduler는 플러그인을 만들려고 했지만
spaceone-plugin 네임스페이스 접근 권한이 없었음

해결:
spaceone:default ServiceAccount에
spaceone-plugin 네임스페이스 조작 권한을 RoleBinding으로 부여

결과:
AWS Collector 플러그인 Pod 4개 생성 성공


SSH Local Port Forwarding
Mon, 08 Jun 2026 05:31:14 GMT
환경 제약

Kubernetes 내부 Service는 외부에서 직접 접근 불가
Worker Node가 Private 성격
보안그룹/방화벽에서 일부 포트만 허용
Grafana/ArgoCD/Kiali는 ClusterIP 또는 내부 서비스
내 PC는 Kubernetes 내부망에 직접 붙어있지 않음

SSH 터널링 / Port Forwarding 활용
실습 환경에서는 Kubernetes 내부 서비스가 외부에 직접 노출되어 있지 않았기 때문에,
Grafana, ArgoCD, Kiali, Prometheus와 같은 관리 UI에 직접 접근할 수 없었음
이를 해결하기 위해 kubectl port-forward와 SSH Local Port Forwarding을 함께 사용
예를 들어 Grafana의 경우 Kubernetes 내부 Service를 로컬 포트로 포워딩
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80
이후 내 PC에서 직접 접근이 어려운 경우 SSH 터널링을 사용하여 서버의 localhost 포트를 내 PC로 가져옴
ssh -L 3000:localhost:3000 root@<서버공인IP>
이 구조를 통해 외부에 서비스를 직접 노출하지 않고도 안전하게 내부 관리 UI에 접근할 수 있었음
불필요하게 NodePort나 LoadBalancer를 열지 않아도 된다는 장점이 있음



Kubernetes 스킬업 실습 과정
Fri, 05 Jun 2026 09:19:25 GMT
Kubernetes 스킬업 실습 전체 과정 정리
0. 실습 환경

실습 목적:
Kubernetes를 운영 엔지니어 관점에서 직접 구축하고 장애까지 경험하는 것

서버:
vm-pms-test  - Control Plane - 192.168.1.254
vm-pms-test2 - Worker Node   - 192.168.1.206
(테스트 환경 이슈로 Worker Node는 1대로 수행)

OS:
Ubuntu 24.04

Runtime:
containerd

CNI:
Calico

특징:
폐쇄망/제한망 유사 환경
Proxy 경유
Security Group 영향
Ingress, Monitoring, GitOps, Istio까지 확장

핵심 학습:
Kubernetes 장애는 YAML만 보는 게 아니라
노드, 네트워크, 프록시, 방화벽, 런타임까지 함께 봐야 함


1. Kubernetes 기본 클러스터 구성
실습 목표

kubeadm 기반 클러스터 구축
Master/Worker 구조 이해
Kubernetes 핵심 컴포넌트 이해

구성
Master : vm-pms-test (192.168.1.254)
Worker : vm-pms-test2 (192.168.1.206)
설치 요소

containerd
kubeadm
kubelet
kubectl

필수 설정

swapoff
br_netfilter
ip_forward

핵심 명령

kubeadm init
kubeadm join
kubectl get nodes
kubectl get pods -A

결과

클러스터 생성 완료
Worker Join 완료
아직 CNI 미설치 상태
Node 상태 NotReady

핵심 학습

Kubernetes 설치는 끝이 아니라 시작

2. Service + Busybox 통신 테스트
실습 목표

Pod 네트워크 이해
Service 이해
DNS 이해
Pod 간 통신 확인

수행 내용

Calico 설치
Node Ready 확인
nginx Deployment 생성
ClusterIP Service 생성
Busybox 생성
nslookup 테스트
HTTP 호출 테스트

주요 컴포넌트

Calico
CoreDNS
Service
Deployment
Busybox

트러블슈팅
1) Pod가 떠도 통신이 안됨
확인 (Calico 원인 가능)
kubectl get pods -o wide
2) Worker 통신 실패
확인 (0이면 1로 변경)
sysctl net.ipv4.ip_forward
3) iptables 문제
확인 (FORWARD DROP 상태면 통신 불가)
iptables -L -n
4) 보안그룹 문제
확인 (나는 해당 문제로 통신이 불가했었음)
통신에 필요한 포트들은 사전에 허용 및 테스트를 통하여 추가 필요
핵심 학습:
Kubernetes 통신의 시작은 Service와 DNS,
Pod가 Running이라고 끝이 아니라
실제 통신이 되는지 반드시 검증해야 함
3. Ingress 구성
실습 목표

외부 접근 구현
Ingress 이해
도메인 라우팅 이해

수행 내용

NodePort 이해
ingress-nginx 설치
Ingress 생성
hosts 설정
nginx.test.local 접속

주요 컴포넌트

Ingress Controller
Service
CoreDNS
nginx

핵심 학습:
Service는 내부 연결
Ingress는 외부 진입점
운영 환경에서는 IP보다 도메인이 중요
사용자 → Ingress → Service → Pod 흐름 이해
4. Volume / PV / PVC 실습
실습 목표

데이터 영속성 이해
PV/PVC 이해
Pod 삭제 후 데이터 유지 확인

수행 내용

PV 생성
PVC 생성
Pod 연결
파일 생성
Pod 삭제
Pod 재생성
데이터 유지 확인

주요 개념

PV
PVC
Volume
Bound
Persistent Storage

핵심 학습 :
Pod는 언제든 죽을 수 있음
데이터는 Pod가 아니라 Volume에 저장해야 함
Stateful 서비스 운영의 기초는 PV/PVC 
5. Resource Request / Limit 실습
실습 목표

CPU/Memory Resource 이해
Request 이해
Limit 이해
Scheduler 동작 이해

수행 내용

Resource 설정 Deployment 생성
CPU 단위 학습
Memory 단위 학습
Request 설정
Limit 설정
QoS 개념 이해

주요 개념

CPU
Memory
Request
Limit
Scheduler
QoS

핵심 학습
Request는 최소 보장
Limit은 최대 허용
Scheduler는 Request를 보고 Node를 선택함
운영자는 Pod보다 Resource를 먼저 봐야 함
6. CPU 부하 및 Metrics Server
실습 목표

Metrics Server 설치
CPU 사용량 확인
Node 사용량 확인
stress 테스트

수행 내용

Metrics Server 설치
Metrics API 오류 해결
kubectl top 사용
stress 설치
CPU 부하 생성
Pod 사용량 확인
Node 사용량 확인

주요 개념

Metrics Server
kubectl top
CPU Usage
Memory Usage
CPU Throttling

트러블슈팅

Metrics API not available
kubelet 인증서 문제
--kubelet-insecure-tls 적용

핵심 학습
설정(Request/Limit)만으로는 부족함
운영자는 실제 사용량을 볼 수 있어야 함
Metrics Server는 Kubernetes 관측의 시작점
7. Rolling Update 실습
실습 목표

Rolling Update 이해
무중단 배포 이해
Rollback 이해

수행 내용

Deployment 확인
이미지 변경
Rollout 진행
Pod 변화 관찰
Revision 확인
Rollback 수행

주요 개념

Deployment
ReplicaSet
Rolling Update
Rollback
Revision

주요 명령
kubectl rollout status
kubectl rollout history
kubectl rollout undo
kubectl get pods -w
핵심 학습 :
Deployment는 단순 Pod 생성기가 아님
Rolling Update는 무중단 배포의 핵심
운영자는 장애 발생 시 Rollback을 할 수 있어야 함
8. Helm 실습
실습 목표

Helm 이해
Repository 이해
Chart 이해
Release 이해

수행 내용

Helm 설치
Helm Repository 추가
Chart 검색
Ingress-Nginx 설치
Helm Upgrade
Helm Rollback
Helm 삭제

주요 개념

Chart
Repository
Release
Values.yaml
Upgrade
Rollback

핵심 학습 :
Kubernetes의 패키지 매니저는 Helm
복잡한 애플리케이션을 한 줄로 설치
이후 Monitoring, ArgoCD, Istio의 기반이 됨
9. Monitoring / Grafana / Loki
실습 목표

Monitoring 구축
Metrics 확인
Log 확인
Dashboard 활용

수행 내용

Prometheus 설치
Grafana 설치
Loki 설치
Promtail 설치
Dashboard 확인
Loki 연동
로그 조회

주요 개념

Prometheus
Grafana
Loki
Promtail
Observability

트러블슈팅

Loki Datasource 연결 실패
Service 이름 확인
Endpoint 확인
Grafana Datasource 수정

핵심 학습 :
운영자는 서비스가 아니라 데이터를 봄
Metrics와 Logs를 함께 봐야 장애 원인을 찾을 수 있음
Grafana는 운영자의 메인 대시보드
10. HPA 실습
실습 목표

HPA 이해
Auto Scaling 이해
CPU 기반 확장 이해

수행 내용

HPA 생성
CPU 목표 설정
Load Generator 실행
CPU 증가 확인
Pod 자동 증가 확인
부하 제거
Pod 자동 감소 확인

주요 개념

HPA
Scale Out
Scale In
Metrics Server
Deployment
ReplicaSet

주요 명령
kubectl autoscale
kubectl get hpa
kubectl describe hpa
kubectl get pods -w
핵심 학습 :
Kubernetes는 스스로 확장할 수 있음
HPA는 Metrics Server와 Request를 기반으로 동작함
자동 확장은 Kubernetes의 핵심 기능 중 하나
11. GitOps / ArgoCD
실습 목표

GitOps 이해
ArgoCD 구축
GitHub 연동
Auto Sync
Self Heal

수행 내용

ArgoCD 설치
UI 접속
Git Repository 등록
Application 생성
Sync 수행
Auto Sync 활성화
Self Heal 확인

주요 개념

GitOps
ArgoCD
Application
Sync
Auto Sync
Self Heal

트러블슈팅

GitHub 접근 실패 / Repo Server 통신 문제
ㄴ 프록시 설정 (폐쇄망 환경에 따른 에러 발생)
GHCR InvalidImageName
ㄴ 이미지 경로 대소문자 구분

핵심 학습 : 
Cluster를 수정하는 것이 아니라 Git을 수정함
ArgoCD는 Git 상태를 지속적으로 유지함
12. HTTPS Ingress / TLS
실습 목표

HTTPS 이해
TLS 이해
인증서 이해
Secret 활용

수행 내용

Self-Signed 인증서 생성
TLS Secret 생성
Ingress TLS 설정
HTTPS 접속
curl 테스트

주요 개념

HTTPS
TLS
Secret
Certificate
TLS Termination

트러블슈팅

Self-Signed 경고
ㄴ curl -k 옵션을 통해 확인 (-k | 인증서 검증 무시)
Host 불일치
ㄴ secret 재생성 후 Ingress 재적용
Secret 누락
ㄴ 위 방법으로 해결

핵심 학습 :
실제 서비스는 HTTPS가 기본
인증서는 Secret으로 관리함
Ingress는 TLS 종료 지점이 될 수 있음
13. CI/CD / Jenkins / Kaniko
실습 목표

CI/CD 구조 이해
Jenkins Pipeline 이해
Kaniko 기반 이미지 빌드 이해
Docker Daemon 없는 빌드 방식 이해
GHCR Push/Pull 구조 이해
ArgoCD와 역할 분리 이해

수행 내용

Jenkins Pipeline 구성
Kaniko Agent Pod 사용
Dockerfile 기반 이미지 빌드
GHCR Push
Kubernetes Deployment 이미지 반영
ArgoCD 배포 흐름과 연결

주요 개념

CI
CD
Jenkins
Jenkinsfile
Kaniko
Registry
GHCR
imagePullSecret
GitOps 연계

핵심 학습 : 
Jenkins는 이미지를 만들고, ArgoCD는 배포
Kaniko는 Docker Daemon 없이 이미지를 빌드할 수 있음
CI/CD 장애는 Git → Build → Push → Pull → Deploy 단계로 나눠서 봐야 함
14. Istio / Service Mesh
실습 목표

Service Mesh 이해
Istio 설치
Sidecar 이해
mTLS 이해

수행 내용

Istio 설치
Namespace Label 적용
Sidecar Injection
Envoy 확인
서비스 호출 생성
Prometheus 메트릭 확인

주요 개념

Service Mesh
Istio
Sidecar
Envoy
mTLS
Observability

트러블슈팅

istio_requests_total 미수집
ㄴ kubectl label namespace / Pod 재생성
트래픽 부족
ㄴ curl을 통한 요청 반복 수행

핵심 학습 :
서비스 간 통신도 관리 대상
Envoy가 모든 트래픽을 관찰함
mTLS는 서비스 간 통신을 보호함
15. Kiali / Prometheus 연동
실습 목표

Kiali 이해
Service Graph 이해
Prometheus 연동

수행 내용

Kiali 설치
접속
Prometheus 연동 확인
트래픽 생성
Graph 확인
mTLS 상태 확인

주요 개념

Kiali
Service Graph
Edge
Traffic
Error Rate
Response Time

핵심 학습 :
Kiali는 Istio의 눈
Prometheus 데이터를 기반으로 서비스 관계를 보여줌
운영자는 서비스 흐름을 시각적으로 확인할 수 있음
16. 장애 대응 / cordon / drain / PDB
실습 목표

Node 유지보수
Cordon
Drain
PDB
장애 대응

수행 내용

Cordon 수행
Drain 수행
Pod 재배치 확인
PDB 생성
Eviction 확인
Uncordon 수행

주요 개념

Cordon
Drain
PDB
Eviction
Availability

핵심 학습 :
노드를 끄기 전에 반드시 Drain
PDB는 서비스 가용성을 보호함
Kubernetes 유지보수는 Cordon → Drain → 작업 → Uncordon 순서
17. Node / Cluster Upgrade 흐름
실습 목표

Kubernetes Upgrade 이해
Node Upgrade 이해
Rolling Update 이해

수행 내용

Cluster Upgrade
Node Pool Upgrade
신규 Node 생성
Drain 수행
Pod 재배치
기존 Node 제거
신규 Node 운영

주요 개념

Cluster Upgrade
Node Pool Upgrade
Rolling Update
Cordon
Drain
PDB

핵심 학습 :
Control Plane과 Node Upgrade는 별개
Node Pool Version과 Node Version은 다를 수 있음
업그레이드의 목표는 버전 상승이 아니라 서비스 무중단 유지
18. 전체 트러블슈팅 정리
실습 중 경험한 대표 장애

Metrics API not available
Ingress 접근 불가
Proxy 문제
ArgoCD Repository 연결 실패
InvalidImageName
ImagePullBackOff
Sidecar 미주입
Kiali No Data
TLS Secret 누락
Self-Signed 인증서 경고
PDB 위반
Standalone Pod Eviction 실패
DaemonSet Drain 실패

가장 중요한 학습

증상 → 원인 → 분석 → 조치 순서로 접근
kubectl describe 와 kubectl logs 활용
네트워크와 Proxy 문제 분석 능력
운영자는 구축보다 문제 해결 능력이 중요




Gitea 세팅 후 계정 접근 실패
Thu, 21 May 2026 05:39:37 GMT
Gitea 세팅 후 계정 접근 실패
🔍원인
Gitea 초기 세팅 완료 후 admin 계정으로 접근 시 비밀번호 접근 실패

Gitea Pod 내부 접속하여 비밀번호 변경 시도kubectl exec -it  -- /bin/bash
gitea admin user change-password -u admin -p "새로운비밀번호"


Command error: user does not exist [uid: 0, name: admin]
- admin 계정이 존재하지 않아 비밀번호 변경 실패




2. 애초 admin 계정이 생성되지 않음



### 📝결과
1. CLI를 통해 관리자 계정 직접 생성
gitea admin user create --admin --username admin --password "1234" --email "admin@example.com"
- CLI를 통해 admin 계정 생성하여 접근 성공 확인



2. 근본적인 에러발생 이유
values.yaml 생성 시 Password 설정 오류
```Yaml
#수정 전
admin:
  username: admin
  password: 1234

#수정 후
admin:
  username: admin
  password: "1234"

Gitea 초기화 스크립트의 특징 (실패 시 재시도 안 함)
Gitea Pod가 처음 뜰 때 실행되는 내부 로직은 대략 다음과 같은 순서로 동작

1) 데이터베이스(SQLite) 파일 생성 및 기본 테이블 구조(스키마) 생성 ➔ (성공)
2) values.yaml에 적힌 정보를 바탕으로 admin 유저 생성 명령어 실행 ➔ (문자열/형식 오류로 인해 실패)
3) 여기서 중요한 점은 유저 생성 명령어가 실패하더라도 전체 시스템이 멈추지 않고 다음 단계(Gitea 웹 서버 실행)로 그냥 넘어감 
게다가 1번 단계에서 DB 파일이 이미 만들어졌기 때문에 Gitea는 시스템이 '이미 완전히 초기화되었다'고 판단



결론적으로 발생한 상황
DB는 만들어졌지만 관리자 계정은 없는 상태

Gitea는 첫 구동 때만 이 자동 생성을 시도하므로 이후에 Pod를 껐다 켜거나 values.yaml을 수정해서 배포해도 이미 DB가 존재하기 때문에 두 번 다시 values.yaml의 admin 정보를 읽어 계정 생성을 시도하지 않음
비밀번호 변경 명령어를 쳤을 때 user does not exist(유저가 존재하지 않음) 에러가 났던 것이고 계정을 '직접 새로 생성'해 주어야만 해결.



Terraform 401 인증 에러
Thu, 21 May 2026 04:43:44 GMT
Terraform 401 인증 에러 발생
You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

Error: Failed to get endpoint list
  with provider["registry.terraform.io/samsungsdscloud/samsungcloudplatformv2"],
  on provider.tf line 25, in provider "samsungcloudplatformv2":
  25: provider "samsungcloudplatformv2" {
Error details: {"status":"UNAUTHORIZED","name":"Request was rejected by
gateway","message":"[Security Configuration] Access key not allowed."}

🔍원인

API 호출 IP 접근 제어 (가장 유력함)
Terraform plan 결과에 출력된 현재 퍼블릭 IP가 SCP 콘솔의 API 접근 허용 IP 목록에 등록되어 있는지 확인


확인하였으나 허용IP 목록에 등록되어 있음





Access Key 및 Secret Key 오류
provider.tf 파일이나 환경 변수에 입력한 인증 정보(Access Key, Secret Key 등)가 잘못 입력되었거나 만료되었을 수 있음


Access Key 및 Secret Key 재발급
provider.tf 파일에 인증정보 넣지 않고 conf 디렉토리의 config.json으로 변수 선언
export를 통해 직접 Access Key 및 Secret Key 설정해 보았으나 동일하게 인증 에러 발생




프로젝트 및 권한 부족
해당 Access Key를 발급받은 계정에 현재 작업하려는 프로젝트(Project ID)에 대한 접근 권한이나 인프라 생성/조회 권한이 부여되지 않았을 수 있음


운영자 권한 확인




✅확인

credential.json 파일 확인


credential.json 파일의 auth_url 재확인 > 이상없음






Terraform 상세 로그 활성화export TF_LOG=DEBUG


DEBUG 로그 확인 시 API Gateway 통신은 정상, 엔드포인트 조회 문제
네트워크 차단 문제가 아닌 Access Key 권한 문제 확률로 확인




📝결과
콘솔의 인증키 보안설정 재확인

수정 전 : 임시키 인증 | 접근 허용 IP 미사용
수정 후 : 인증키 인증 | 접근 허용 IP 미사용
테스트를 위해 접근 허용 IP는 미사용으로 시도

*인증키 보안 설정이 인증키 인증이 아닌 임시키로 되어 있어 발생했던 인증 에러







sslip.io 접근 불가
Tue, 19 May 2026 06:12:02 GMT
sslip.io 접근 불가
🔍현상
테스트 용도의 https://publicip.sslip.io 접근 시 접근불가



✅확인

클라우드 방화벽 확인
HTTPS(443)/HTTP(80) 포트의 0.0.0.0/0 Inbound Allow 확인

sslip.io 도메인 차단 우회



https://publicip 접근 불가
http://publicip 접근 가능 


서버 내 서비스 확인
```
ubuntu@web-ide:~$ curl -vk https://localhost


Host localhost:443 was resolved.
IPv6: ::1
IPv4: 127.0.0.1
Trying [::1]:443...
connect to ::1 port 443 from ::1 port 52466 failed: Connection refused
Trying 127.0.0.1:443...
connect to 127.0.0.1 port 443 from 127.0.0.1 port 59452 failed: Connection refused
Failed to connect to localhost port 443 after 2 ms: Couldn't connect to server
Closing connection
curl: (7) Failed to connect to localhost port 443 after 2 ms: Couldn't connect to server

docker ps
CONTAINER ID   IMAGE                      COMMAND                  CREATED          STATUS          PORTS                                                                                  NAMES
0330a5a4c896   cwj3688/code-server-hol3   "/usr/bin/entrypoint…"   14 minutes ago   Up 14 minutes   0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp, 0.0.0.0:80->8080/tcp, [::]:80->8080/tcp   code-server-hol3



📝해결
서비스 확인 시 443포트로 오픈되어 있지 않음

docker-compose.yaml 수정으로 Caddyfile 재배포


Yaml 수정 전
services:
code-server:
  image: cwj3688/code-server-hol3
  container_name: code-server-hol3
  restart: always
  ports:
    - "3000:3000"
    - "80:8080"
  volumes:
    - /home/ubuntu/project:/home/coder/project
    - /var/run/docker.sock:/var/run/docker.sock
    - /home/ubuntu/.scp:/home/coder/.scp
    - /home/ubuntu/.scpconf:/home/coder/.scpconf
    - /home/ubuntu/.kube:/home/coder/.kube
    - /home/ubuntu/.config:/home/coder/.config
    - /home/ubuntu/.local:/home/coder/.local

  environment:
    # - PASSWORD=admin12345!!
    - PASSWORD=${PASSWORD}
  command: /home/coder/project
  # command: --auth none /home/coder/project
  group_add:
    # - $(shell getent group docker | cut -d: -f3)
    - ${DOCKER_GID}



Yaml 수정 후
Caddy(HTTPS 프록시) 추가
services:
code-server:
  image: cwj3688/code-server-hol3
  container_name: code-server-hol3
  restart: always
  ports:
    - "3000:3000"

  volumes:
    - /home/ubuntu/project:/home/coder/project
    - /var/run/docker.sock:/var/run/docker.sock
    - /home/ubuntu/.scp:/home/coder/.scp
    - /home/ubuntu/.scpconf:/home/coder/.scpconf
    - /home/ubuntu/.kube:/home/coder/.kube
    - /home/ubuntu/.config:/home/coder/.config
    - /home/ubuntu/.local:/home/coder/.local
  environment:
    - PASSWORD=${PASSWORD}
  command: /home/coder/project
  group_add:
    - ${DOCKER_GID}

# 새롭게 추가된 Caddy(HTTPS 프록시) 컨테이너
caddy:
  image: caddy:alpine
  container_name: caddy-proxy
  restart: always
  ports:
    - "80:80"
    - "443:443"
  command: caddy reverse-proxy --from 123.41.35.83.sslip.io --to http://code-server:8080
  volumes:
    - caddy_data:/data



volumes:
  caddy_data:



2. 컨테이너 재배포
1. 기존 컨테이너 종료
sudo docker compose down
2. 비밀번호 및 권한 변수 다시 불러오기
PASSWORD=$(cat /home/ubuntu/project/env-info.txt | grep "Password:" | awk '{print $NF}')
DOCKER_GID=$(getent group docker | cut -d: -f3)
3. 새로운 구성(Code-Server + Caddy)으로 띄우기
sudo PASSWORD=$PASSWORD DOCKER_GID=$DOCKER_GID docker compose up -d
- 비밀번호 및 권한 변수(PASSWORD, DOCKER_GID)를 다시 불러온 이유
리눅스의 환경 변수는 '휘발성 메모리'와 같음 
특정 터미널 창이나 스크립트가 실행되는 동안에만 존재하고, 창을 닫거나 스크립트가 끝나면 싹 사라짐




3. Caddy 란?
Caddy는 Nginx나 Apache와 같은 웹 서버 프로그램
하지만 다른 웹 서버들과 차별화되는 엄청난 강력한 무기가 하나 있는데, 
바로 자동 HTTPS(SSL 인증서) 발급 기능

- 리버스 프록시(Reverse Proxy) 역할
위 내용 '[[확인](https://velog.io/@sunny-10/sslip.io-%EC%A0%91%EA%B7%BC-%EB%B6%88%EA%B0%80#%ED%99%95%EC%9D%B8)]' 부분 확인 시 Code-Server 컨테이너는 HTTP(8080 포트)로만 통신
그래서 Caddy가 외부에서 들어오는 HTTPS 요청을 자기가 대신 받아서, 
내부의 Code-Server에게 HTTP로 안전하게 토스

- 무료 보안 인증서 자동 세팅
원래 https:// 자물쇠 마크를 띄우려면 인증 기관에 가서 도메인을 증명하고 복잡한 인증서를 발급받아 서버에 세팅해야 함
하지만 Caddy는 Publicip.sslip.io 라는 주소만 알려주면, 
자기가 알아서 Let's Encrypt 같은 기관과 통신해 무료 보안 인증서를 받아오고 주기적으로 갱신까지 해줌



VM Init 스크립트 주의사항
Tue, 19 May 2026 05:11:04 GMT
VM Init 스크립트 주의점
🔍현상
정상적으로 작성한 VM Init 스크립트를 통해 VM 생성하였음에도
스크립트 인식을 하지 못하는 경우
📝해결
bash 쉘은 줄바꿈이 있으면 새로운 명령어로 인식하기에
한줄로 이어쓰거나 역슬래시('')를 활용
주로 Copy&Paste 오류 또는 형식에 맞지않게 가져오는 경우 발생


✅예시
문제가 발생한 Init 스크립트
#!/bin/bash

# 스크립트 실행 중 오류 발생시 즉시 중단
set -e

# 웹 IDE 초기화를 위한 저장소 URL과 디렉토리, 이미지 이름 설정
REPO_URL="https://github.com/xxx/init-webide.git"
REPO_DIR="init-webide"
IMAGE_NAME="xxx/code-server-xxx"
HOME_DIR="/home/ubuntu"
PROJECT_DIR="${HOME_DIR}/project" # HOME_DIR 변수를 사용하여 경로 설정

# 저장소 클론 및 디렉토리 이동
git clone "$REPO_URL"
cd "$REPO_DIR"

# Docker 설치 스크립트 실행
chmod +x install_docker.sh
./install_docker.sh

# Public IP 업데이트 스크립트 실행
chmod +x update_ip.sh
./update_ip.sh

# Docker 이미지 다운로드
docker pull "$IMAGE_NAME"

# 프로젝트 및 설정 디렉토리 생성
mkdir -p "$PROJECT_DIR"
mkdir -p "${HOME_DIR}/.scp" "${HOME_DIR}/.scpconf" 
"${HOME_DIR}/.kube" "${HOME_DIR}/.config" "${HOME_DIR}/.local" # 🔴줄바꿈

# 랜덤 패스워드 생성 및 파일에 저장
PASSWORD=$(openssl rand -base64 12)
echo "Your Web-IDE Password: ${PASSWORD}" > 
"${PROJECT_DIR}/env-info.txt" # 🔴줄바꿈

# Docker 그룹 ID 및 패스워드를 환경 변수로 전달하여 컨테이너 실행
DOCKER_GID=$(getent group docker | cut -d: -f3) 
PASSWORD=${PASSWORD} # 🔴줄바꿈 
docker compose up -d

# 권한 설정 (모든 경로에 HOME_DIR 변수 적용)
chown -R 1000:1000 "$HOME_DIR"

# 콘솔에 패스워드 및 저장 경로 출력 (변수명 오류 수정)
echo "================================================================"
echo "   A new password for the Web-IDE has been generated."
echo "   Password: ${PASSWORD}"
echo "   It has been saved to: ${PROJECT_DIR}/env-info.txt"
echo "================================================================"

echo "Web-IDE setup is complete!"



문제를 해결한 Init 스크립트
#!/bin/bash

# 스크립트 실행 중 오류 발생시 즉시 중단
set -e

# 웹 IDE 초기화를 위한 저장소 URL과 디렉토리, 이미지 이름 설정
REPO_URL="https://github.com/xxx/init-webide.git"
REPO_DIR="init-webide"
IMAGE_NAME="xxx/code-server-xxx"
HOME_DIR="/home/ubuntu"
PROJECT_DIR="${HOME_DIR}/project" # HOME_DIR 변수를 사용하여 경로 설정

# 저장소 클론 및 디렉토리 이동
git clone "$REPO_URL"
cd "$REPO_DIR"

# Docker 설치 스크립트 실행
chmod +x install_docker.sh
./install_docker.sh

# Public IP 업데이트 스크립트 실행
chmod +x update_ip.sh
./update_ip.sh

# Docker 이미지 다운로드
docker pull "$IMAGE_NAME"

# 프로젝트 및 설정 디렉토리 생성
mkdir -p "$PROJECT_DIR"
mkdir -p "${HOME_DIR}/.scp" "${HOME_DIR}/.scpconf" "${HOME_DIR}/.kube" "${HOME_DIR}/.config" "${HOME_DIR}/.local"

# 랜덤 패스워드 생성 및 파일에 저장
PASSWORD=$(openssl rand -base64 12)
echo "Your Web-IDE Password: ${PASSWORD}" > "${PROJECT_DIR}/env-info.txt"

# Docker 그룹 ID 및 패스워드를 환경 변수로 전달하여 컨테이너 실행
DOCKER_GID=$(getent group docker | cut -d: -f3) PASSWORD=${PASSWORD} docker compose up -d

# 권한 설정 (모든 경로에 HOME_DIR 변수 적용)
chown -R 1000:1000 "$HOME_DIR"

# 콘솔에 패스워드 및 저장 경로 출력 (변수명 오류 수정)
echo "================================================================"
echo "   A new password for the Web-IDE has been generated."
echo "   Password: ${PASSWORD}"
echo "   It has been saved to: ${PROJECT_DIR}/env-info.txt"
echo "================================================================"

echo "Web-IDE setup is complete!"


vi Tiny Version 활용 개선
Tue, 19 May 2026 04:28:11 GMT
vi 편집 시 Tiny Version으로 인한 편집 어려움
🔍현상
vi/vim에서 INSERT MODE(i) 상태에서 방향키를 눌렀는데,
터미널이 방향키 escape sequence(A B C D)를 제대로 해석하지 못해서 발생하는 현상

최소 설치된 Rocky/RHEL/CentOS
vim이 아니라 vi(tiny vi) 사용 중
TERM 환경변수 이상
SSH/콘솔 터미널 호환 문제
vim-enhanced 미설치

📝해결 방법
최우선으로 vi Version 확인
vi --version
Tiny Version일 경우
echo "set nocompatible" >> ~/.vimrc
echo "set esckeys" >> ~/.vimrc
echo "set ttimeout" >> ~/.vimrc
echo "set ttimeoutlen=100" >> ~/.vimrc
echo "set backspace=indent,eol,start" >> ~/.vimrc
1) echo "set nocompatible" >> ~/.vimrc
vim을 옛날 vi 호환 모드가 아니라 vim 방식으로 동작하게 하는 설정.
방향키, 백스페이스, 편집 동작이 더 자연스러워짐.
2) echo "set esckeys" >> ~/.vimrc
Insert 모드에서 방향키 같은 특수 키를 사용할 수 있게 하는 설정.
방향키가 A B C D로 찍히는 문제와 관련 있음.
3) echo "set ttimeout" >> ~/.vimrc
방향키, ESC, Delete 같은 키 입력을 구분할 때 대기 시간을 사용하겠다는 뜻.
4) echo "set ttimeoutlen=100" >> ~/.vimrc
특수 키 입력을 기다리는 시간을 100ms로 설정.
ESC를 눌렀을 때 너무 늦게 반응하거나, 방향키가 문자로 입력되는 문제를 줄여줌.
5) echo 'set backspace=indent,eol,start' >> ~/.vimrc
Backspace가 정상적으로 지울 수 있는 범위를 넓혀주는 설정.
indent = 자동 들여쓰기 삭제 가능
eol    = 줄 끝에서 이전 줄로 이어서 삭제 가능
start  = insert 모드 시작 지점 이전 문자도 삭제 가능
이 설정 없으면 Insert 모드에서 백스페이스가 일부 위치에서 안 먹을 수 있음.
👍권장사항
Tiny Version 보단 Full Version 권장
(Ubuntu 기준)
apt update && apt install -y vim


oh-my-zsh 가이드
Tue, 03 Jun 2025 00:33:44 GMT
1.oh my zsh 설치
$ sudo apt update            # 패키지 목록 업데이트
$ sudo apt install -y zsh        # zsh 설치
$ sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
$ vi ~/.zshrc                    # 테마가 여러 개 있음 마음에 드는 테마를 선택 가능

'
'
  ZSH_THEME="agnoster"
'
'

$ source ~/.zshrc # zsh 적용
아래 링크로 더 많은 테마를 확인할 수 있음
https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
가이드에서 사용할 테마는 ' agnoster ' 

2. 터미널 폰트가 깨져있을 경우
아래 링크로 폰트를 다운 받을 수 있음
https://github.com/powerline/fonts
가이드에서 사용할 폰트는 ' Meslo slashed ' 
다운로드 받은 후 L M S 마음에 드는 사이즈 선택하여 모두 설치해주면 됨

터미널 → 환경설정 → 프로파일 에서 서체 등록 후 터미널 재시작 하면 폰트 적용

3. zsh-autosuggestions 설치 (선택적)
더 많은 정보를 노출 시켜주는 것 뿐만 아니라 막강한 기능들이 있음
https://github.com/zsh-users/zsh-autosuggestions (기능확인)
$ git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
$ git clone https://github.com/zsh-users/zsh-completions ${ZSH_CUSTOM:-${ZSH:-~/.oh-my-zsh}/custom}/plugins/zsh-completions

$ vi ~/.zshrc                     # vi 편집
'
'
plugins=(
        git
        zsh-autosuggestions
        zsh-completions
)
'
'

$ source ~/.zshrc # zsh 적용

적용이 된 걸 확인할 수 있음
(전에 사용했던 명령을 그대로 사용할 시 '→' 방향키를 눌러 바로 적용가능)
4. 멀티라인 작성 (선택적)
커맨드를 입력 시 가시적인 불편함 해소
$ vi ~/.oh-my-zsh/themes/agnoster.zsh-theme

( 빈 곳에 추가 )
prompt_newline() {
  if [[ -n $CURRENT_BG ]]; then
    echo -n "%{%k%F{$CURRENT_BG}%}$SEGMENT_SEPARATOR
%{%k%F{blue}%}$SEGMENT_SEPARATOR"
  else
    echo -n "%{%k%}"
  fi

  echo -n "%{%f%}"
  CURRENT_BG=''
}

( 추가 후 build prompt 에 추가 작성 )

'
'
  prompt_newline
'
'

5. 색상 변경 (선택적)
agnoster 색상 변경
$ vi ~/.oh-my-zsh/themes/agnoster.zsh-theme

prompt_dir() {
  prompt_segment 39d $CURRENT_FG '%~'      # 39d로 변경 (하늘색)
}

VM 재접속 하면 적용




k9s 설치 및 사용
Tue, 03 Jun 2025 00:29:42 GMT

k9s 란?

k9s는 터미널에서 Kubernetes 클러스터를 관리할 수 있는 CLI 도구
kubectl도 같이 사용할 수 있어 같은 컨텍스트에서  kubectl과 k9s를 오가며 사용할 수 있는 장점이 있음

k9s 설치

Ubuntu 환경에서 k9s 설치하기
$ wget https://github.com/derailed/k9s/releases/download/v0.26.7/k9s_Linux_x86_64.tar.gz 
$ tar -zxvf ./k9s_Linux_x86_64.tar.gz 
$ mkdir -p ~/.local/bin
$ mv ./k9s ~/.local/bin && chmod +x ~/.local/bin/k9s                   # 바이너리 이동 및 실행권한 추가
$ rm ./k9s_Linux_x86_64.tar.gz LICENSE README.md                       # 불필요한 코드 제거
$ export PATH=$PATH:$HOME/.local/bin                                   # ~/.bashrc 파일에 경로 추가
$ source ~/.bashrc                                                     # 변경사항 적용


k9s 사용법

$ k9s info
$ k9s                                           # 기본 k9s 실행
$ k9s -n default                                # 지정된 namespace에서 k9s 실행
$ k9s -c pod                                    # k9s를 실행 후 pod 명령을 통한 pod 보기
$ k9s --readonly                                # 읽기 전용 모드로 k9s 실행되어 수정 명령이 비활성

원하는 명령을 입력하면 아래와 같은 상태창을 확인할 수 있음

k9s 사용법은 아래 빨간 상자 내 명령어를 통해 확인할 수 있음


참고 링크 
k9s 란? - https://blog.outsider.ne.kr/1649
k9s를 Ubuntu에 설치하기 - https://jusths.tistory.com/267
k9s 사용법 - https://peterica.tistory.com/276



서비스 메쉬 관측 플랫폼 구성
Sat, 03 May 2025 21:42:08 GMT
[개념]
1. Istio
역할
서비스 메쉬를 구성해 트래픽 관리, 보안, 모니터링, 트레이싱을 지원.
서비스 앞에 Envoy proxy(Sidecar) 를 주입해 네트워크 트래픽을 제어함.
세부 기능:
Ingress Gateway: 외부 트래픽 진입점
VirtualService & DestinationRule: 트래픽 라우팅, 버전 분기 등
Telemetry: Envoy proxy가 Prometheus, OpenTelemetry로 메트릭 및 트레이싱을 수집함
Security: mTLS, 인증/인가, JWT 처리 등
2. OpenTelemetry Collector
역할
Istio/Envoy가 수집한 트레이싱 데이터(Span) 를 수신해서 다양한 백엔드로 전달.
Jaeger, Zipkin, NewRelic, OTLP 등으로 멀티 백엔드 export가 가능.
세부 기능
receivers: 데이터를 수신 (예: OTLP, Zipkin)
processors: 가공 및 필터링 (선택사항)
exporters: 백엔드로 전달 (예: Jaeger, Prometheus Remote Write)
service.pipelines: 위 구성들을 연결
3. Kiali
역할
Istio 서비스 메쉬의 시각화 도구. 실시간 트래픽 흐름, 라우팅 정책, 오류율, 성능 등을 볼 수 있음.
세부 기능
실시간 서비스 맵
요청 수, 지연 시간, 오류율 등 시각화
Istio 설정(VirtualService, DestinationRule 등) 검토 가능
서비스 간 의존성 확인 (디버깅에 매우 유용)
[구성]
1. 기본 Istio 환경 구축 + 샘플 앱 배포
# brew로 istioctl 설치
brew install istioctl

# istioctl 버전 확인을 진행하여 설치 확인
istioctl version

# Istio demo 프로파일로 설치
# → Prometheus, Kiali, Jaeger, Grafana 포함
istioctl install --set profile=demo -y
# Tech CS 분들은 여기서 오류 발생 가능! VPN 연결 후 재시도해 보세요

# 카카오클라우드로 진행 시 failed to call Webhook 발생
# https://kko.kakao.com/NwPwmdCDcA
# deploy 전체 spec 설정이 아닌 pod spec 설정에서 수정해 주세요.
kubectl edit deployment -n istio-system istiod
#***
#spec:
#    hostNetwork: true # 추가
#    dnsPolicy: ClusterFirstWithHostNet
#containers:
#***

# default 네임스페이스에 istio-injection label 추가
kubectl label namespace default istio-injection=enabled

# Bookinfo 샘플 앱 배포
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/platform/kube/bookinfo.yaml

# Gateway + 트래픽 라우팅 정의 적용
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.21/samples/bookinfo/networking/bookinfo-gateway.yaml

# Istio Ingress Gateway의 EXTERNAL-IP 확인
# 주소 확인 후 웹브라우저에서 접속
kubectl get svc istio-ingressgateway -n istio-system
# 예: http:///productpage




필요 조건
추천



단순한 웹 트래픽 라우팅 (e.g. ingress + path 기반)
NGINX Ingress Controller


복잡한 트래픽 분할, 인증(mTLS), 정책 제어, 전체 서비스 메시
Istio Ingress Gateway


A/B 테스트, 카나리 배포, 헤더 기반 라우팅, 가시성 확보가 필요한 환경
Istio


빠르게 설정하고 운영 단순화가 중요한 경우
NGINX


NGINX Ingress Controller는 "단순한 출입문",
Istio + Ingress Gateway는 "보안·관제·스마트 제어까지 가능한 첨단 통제소"
2. Kiali, Prometheus, Grafana로 메트릭 시각화
Prometheus : Istio에서 수집한 메트릭 데이터를 저장
Grafana : Prometheus 데이터를 시각화 (대시보드)
Kiali : Istio 메시에 연결된 서비스 간 관계/트래픽 흐름 시각화
# observability 네임스페이스 생성 (선택)
kubectl create namespace observability
# 필요 시 생성하고, 아래의 파드 생성 시 선택적으로 네임스페이스 변경하여 진행.
# 기본적으로 istio-system 네임스페이스에 생성됨. 변경하는 법은 따로 기재하지 않음.

# Istio에서 제공하는 애드온 매니페스트 적용
# Prometheus, Grafana, Kiali 포함
# istio-system 네임스페이스에 관련 Pod들을 배포
# prometheus는 이미 설치되어 있을 수 있음!
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/grafana.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/kiali.yaml

# 모두 running 되고 있는지 확인
kubectl get pods -n istio-system

# 접근 테스트 (포트포워딩)
# 내부 서비스이기에 서비스화 시키지 않고 포트포워딩 하여 사용합니다!
# 이는 비슷한 구성은 카카오클라우드 grafana 기술문서에도 나와있습니다.

# Kiali (서비스 맵 보기)
# http://localhost:20001
kubectl port-forward svc/kiali -n istio-system 20001:20001
# Grafana (대시보드)
# http://localhost:3000
kubectl port-forward svc/grafana -n istio-system 3000:3000
# Prometheus (메트릭 확인)
# http://localhost:9090
kubectl port-forward svc/prometheus -n istio-system 9090:9090

3. 트레이스 추적
OpenTelemetry Collector : Istio에서 수집한 trace 데이터를 수집/가공/전송
Jaeger : 트레이스 데이터를 저장하고 시각화하는 UI 제공
Istio : Envoy 사이드카에서 trace 생성, OpenTelemetry에 전달
# Jaeger 배포
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/jaeger.yaml

# OpenTelemetry Collector 배포
# 이 구성은 OpenTelemetry Collector가 4317 포트로 OTLP 데이터를 수신하고, 
# 수신한 트레이스를 Jaeger에 전달하도록 설정되어 있음
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.18/samples/addons/extras/opentelemetry.yaml

# 포트포워딩으로 UI 확인
# http://localhost:16686
kubectl port-forward svc/jaeger -n istio-system 16686:16686

# 테스트 명령어 -> 몇번 실행 후 Jaeger UI에서 서비스 간 호출 경로, 요청 지연 시간 등 확인 가능
kubectl exec "$(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name})" \
    -c productpage -- curl -s http://localhost:9080/productpage


(참고)

https://blog.serialexperiments.co.uk/posts/kubernetes-port-forward-already-in-use/
https://nginxstore.com/blog/istio/istio-prometheus-%EB%A9%94%ED%8A%B8%EB%A6%AD-%EC%88%98%EC%A7%91-%EB%B0%8F-grafana-%EC%97%B0%EB%8F%99/
https://istio.io/latest/docs/ops/integrations/jaeger/#installation
https://istio.io/latest/docs/tasks/observability/distributed-tracing/opentelemetry/
https://velog.io/@rudclthe/istio-kiali




Docker & K8S offline Install
Sat, 03 May 2025 20:21:48 GMT
[본 게시글은 22년 기준으로 작성되었음]
테스트 목적 : 폐쇄망에서 Docker 와 K8S를 설치하여 각 서비스의 구조 파악
1. 환경 세팅
VM 3대를 준비 (master 1 + worker 2)
Offline 환경을 구성하기 위해 Outbound정책 Port에 제한을 둠
(단, KIC 환경에서는 VM 생성 시 아웃바운드 정책 Port를 모두 열고 VM생성이 끝나면 SG를 변경해 줄 것)
6443 - api server
2379 - etcd
2380 - etcd
4443 - metric server
179 - calico
10250 - kubelet API

2. Docker 설치
2.1 Docker 설치에 필요한 패키지를 준비
URL을 통해 받거나 Docker가 설치되어 있는 VM에서 구해도 됨 
focal 은 ubuntu 20.xx
bionic 은 ubuntu 18.xx
URL : https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/amd64/
VM 경로 : /var/cache/apt/archives 확인
필요 패키지 - yohan guide (버전을 맞추어 설치)
containerd~
docker-ce-cli~
docker-ce-rootless-extra~
docker-ce~
docker-compose~
docker-scan-plugin~
libltdl~
pigz~
(본 테스트에서는 containerd, docker-ce, docker-cli 로만 구성)
2.2 scp 를 통한 패키지 이동
로컬에서 패키지를 받았으면
로컬 → GateWay(oliver) → offline vm 으로 이동
통신가능한 VM에서 패키지를 받았으면
online vm → GateWay(oliver) → offline vm 으로 이동

2.3 dpkg 를 통한 설치
.deb가 있는 디렉토리에서 dpkg 를 통한 패키지 설치
$ sudo dpkg -i *.deb

Trouble Shooting❗️

containerd 버전문제로 1.4.1 이상으로 해결

dpkg: error processing package docker-ce (–install): dependency problems - leaving unconfigured
의존성 트러블은 패키지가 부족하면 수도 없이 나옴

2.4 docker 설정 및 croup 변경
2.4.1 docker 설정 (선택적)
$ sudo usermod -aG docker $USER 
$ 재시작 하면 적용
사용자 그룹을 추가한다면 sudo 를 안붙여도 됨
2.4.2 cgroup 변경
cat <
2.5 Docker 설치 확인


3. K8S 설치 
kube-apiserver 는 최대 1단계의 마이너 버전 차이까지 가능
ex) 하나의 kube-apiserver 의 버전이 1.21 라면 다른 kube-apiserver 는 1.20 or 1.21 이여야 함
kubelet 은 kube-apiserver 보다 최신이여서는 안됨 그리고 최대 2단계 이전의 마이너 버전 차이까지 가능
ex) kube-apiserver 가 1.21 이라면 kubelet 은 1.21 or 1.20 or 1.19 까지 사용가능
kubectl 은 kube-apiserver 과 최대 1단계의 마이너 버전 차이까지 가능
ex) kube-apiserver 가 1.21 이라면 kubectl 은 1.22 or 1.21 or 1.20 까지 사용가능
3.1 환경 설정
필요한 패키지파일과 이미지 파일을 준비
패키지 파일은 2.1 과 동일하게 구할 수 있음
이미지의 경우 docker save로 .tar 저장
필요 패키지
kubeadm~
kubectl~
kubelet~
kubernetes-cni~
conntrack~
cri-tools~
socat~
필요 이미지
kube-proxy
kube-apiserver
kube-controller-manager
kube-scheduler
etcd
coredns
pause
calico/cni                           (CNI 설치 시 사용)
calico/node                       (CNI 설치 시 사용)
calico/kube-controllers   (CNI 설치 시 사용)

3.2 K8S 설치 (master node)
3.2.1 설치
준비한 이미지 파일을 docker load 로 이미지 업로드 
준비한 패키지 파일을 dpkg 로 설치
$ sudo dpkg -i *.deb
3.2.2 설정
$ sudo swapoff -a
$ sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
$ sudo kubeadm init

(master node)
$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

(확인)
$ kubectl get nodes 
CNI 가 미설치 되어 NotReady  확인 가능 
3.3 CNI 설치
calico 를 사용
앞 서 준비한 calico 이미지 사용
https://projectcalico.docs.tigera.io/manifests/calico.yaml
의 셀스크립트를 calico.yaml 파일 저장
$ kubectl apply -f calico.yaml

(확인)
$ kubectl get all -A
$ kubectl get nodes
3.4 worker node 구축
2.docker 설치와 3.k8s설치 내용대로 설치 (단, init 하지말 것)
worker node의 k8s 설치에 사용 했던 이미지
kube-proxy
coredns
pause
calico/cni                           (CNI 설치 시 사용)
calico/node                       (CNI 설치 시 사용)

(worker node)
master node 에서 init 했을 때 받은 토큰으로 조인
$ sudo kubeadm join 172.30.3.97:6443 --token gdpgce.j5mvth8gt7qu4u86 \
--discovery-token-ca-cert-hash sha256:ed4b205d09552dc4c957fb0e08c962560af5c9c93b0e3f222dfd7e29af7796e0 

(master node 에서 확인)
$ kubectl get all -A
$ kubectl get nodes
3.5 k8s 설치 결과

4. k8s Multi Master 구성
4.1 VM 세팅
앞선 Docker & K8S offline install을 통해 master node 1대, worker node 2대가 구성이 되어 있을 것 (재사용)
같은 방법으로 master node 2대 추가, 기존의 node들은 kubeadm reset 처리
총, master node 3대 worker node 2대를 연결예정
4.2 Main Master Token 얻기
$ sudo kubeadm init --token-ttl 0  --control-plane-endpoint "[Loadbalancer IP]:6443" --upload-certs --pod-network-cidr=192.168.50.0/24 >> kubeadm-init-result.txt
(pod network cidr 를 지정하지 않으면 추 후 조인 시에 중복으로 인해 에러발생할 수 있음)

빨간 상자= control-plane token
노란 상자 = worker token
4.3 각 노드 별 필요한 Token으로 Join
( Controll-plane Node )
 4.1 VM 세팅이 끝난 후 kubeadm init 대신 Controll-plane Token 값 적용 (위 빨간 상자 확인)
(Worker Node)
 4.1 VM 세팅이 끝난 후 Worker Token 값 적용 (위 노란 상자 확인)
4.4 연결 확인
Master node에서 확인
$ kubectl get all -A
$ kubectl get nodes

Main Master 에서만 kubectl apply -f calico.yaml 하면 됨 ( Sub Master 에서 실행 X )
각 Node 들은 필요 이미지만 들고 있으면 됨

(참고)
Docker 참고 주소

get.docker.com
https://choco-life.tistory.com/40
https://docs.cyberwatch.fr/deploy/en/2_deploy_cyberwatch/offline/swarm/install_docker.html

K8S 참고 주소

https://velog.io/@seokbin/Kubernetes-%ED%81%B4%EB%9F%AC%EC%8A%A4%ED%84%B0-%EC%84%A4%EC%B9%98-kubeadm-offline-%ED%99%98%EA%B2%BD
https://github.com/tmax-cloud/install-k8s
https://docs.genesys.com/Documentation/GCXI/latest/Dep/DockerOffline
https://www.sobyte.net/post/2022-06/k8s-intranet/
https://www.centlinux.com/2019/04/install-kubernetes-k8s-offline-on-centos-7.html




k8s 내 Ceph Storage Cluster 구성
Sat, 03 May 2025 19:52:21 GMT
Kubernetes는 여러 스토리지 선택지가 있지만, 
그중 온프레미스 환경에서 관리가 쉽고 강력한 성능을 내는 Ceph이 있습니다. 
Ceph Storage Cluster는 안정적이며, 높은 성능과 Block, File, Object 스토리지로 다양하게 사용이 가능합니다. 
Kubernetes Cluster내에 Ceph Storage Cluster를 구성하여 이를 PVC로 사용하는 테스트 입니다.
k8s 구성 환경
k8s node 1 : 8vCPU / 32 GiB Memory / 볼륨 100GB + 50GB
k8s node 2 : 8vCPU / 32 GiB Memory / 볼륨 100GB + 50GB
k8s node 3 : 8vCPU / 32 GiB Memory / 볼륨 100GB + 50GB
k8s node 4 : 8vCPU / 32 GiB Memory / 볼륨 100GB + 50GB
Ceph 클러스터를 위해 2개의 MGR / 3개의 MON / 디스크 수만큼의 OSD 데몬이 실행되어야 합니다.


1. Rook 예제 및 소스파일 다운로드
Rook 예제 파일은 거의 모든 환경에서 대응할 수 있는 예제코드를 제공
$ git clone https://github.com/rook/rook.git/



2. helm 활용 rook 오퍼레이터 구성
helm 으로 간단하게 rook-ceph 구성
(repo 추가) 
$ helm repo add rook-release https://charts.rook.io/release 
$ helm search repo rook-ceph 

(rook 오퍼레이터 설치) 
$ kubectl create namespace rook-ceph 
(repo 추가) 
$ helm install --namespace rook-ceph rook-ceph rook-release/rook-ceph 
$ kubectl get all -n rook-ceph



3. Ceph 클러스터 구성
기본으로 구성할 경우, 2개의 MGR / 3개의 MON / 빈디스크 수만큼의 OSD 데몬이 생성되며 
최소 3개 노드이상일 경우 기본구성으로 설치하면 적당함 
아래 설치하기 전에 위에 구성한 오퍼레이터가 꼭 동작하고 있어야 하며, 
만약 오퍼레이터가 설치 중이라면 설치완료 후 진행
$ helm install --namespace rook-ceph rook-ceph-cluster --set operatorNamespace=rook-ceph rook-release/rook-ceph-cluster 
$ kubectl get all -n rook-ceph


Trouble Shooting❗️
rook-ceph-osd-prepare-[host명] 파드는 Completed 되었으나 정작 osd 파드가 생성되지 않음
kubectl -n rook-ceph logs 
를 통해 로그 확인 시 
'cephosd: skipping OSD configuration as no devices matched the storage settings for this nod' 가 발생하는 것을 확인
각 노드별 볼륨을 추가하여 해결




4. Toolbox 설치
rook/deploy/examples/ 에 toolbox.yaml 파일을 사용하여 구성 
toolbox를 통해 ceph cli를 사용할 수 있음
$ kubectl apply -f toolbox.yaml 
$ kubectl get deploy rook-ceph-tools -n rook-ceph 
$ kubectl -n rook-ceph exec -it 
(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bash 
(toolbox)$ ceph -s 
(toolbox)$ ceph osd status



5. Dashboard 사용
CephCluster의 Dashboard 서비스를 ssl을 사용하지 않도록 변경하고, 기본 url을 변경
$ kubectl get svc -n rook-ceph 
$ kubectl edit CephCluster rook-ceph -n rook-ceph 
(수정전) 
dashboard : 
  enabled : true 
  ssl : true 

(수정후) 
dashboard : 
  enabled : true 
  ssl : false 
  urlPrefix : /ceph-dashboard

대시보드가 ssl을 사용한다면 8443 포트이지만, 
ssl을 사용하지 않도록 구성하니 7000 포트로 고정 
rook-ceph 예제파일 중 dashboard-loadbalancer.yaml 파일을 수정하고 적용
$ vi dashboard-loadbalancer.yaml 
(수정전) 
port : 8443 
targetPort : 8443 

(수정후) 
port : 7000 
targetPort : 7000 

$ kubectl apply -f dashboard-loadbalancer.yaml

이제 rook-ceph-mgr-dashboard-loadbalancer라는 서비스가 LoadBalancer 타입으로 만들어지고 외부 IP가 확인됨
(본 테스트에서는 카카오클라우드 LB를 사용하여 접속)

브라우저에서 http://PublicIP:7000/ceph-dashboard/ 경로로 접속 
계정은 admin이고 패스워드는 아래 명령으로 확인할 수 있음
# 패스워드 확인 
$ kubectl get secret rook-ceph-dashboard-password -n rook-ceph -o yaml | grep "password:" | awk '{print $2}' | base64 --decode

(아래 접속 화면은 pvc 생성 후 캡처)



6. (Ceph-filesystem) PVC 생성
PVC를 생성하면 자동으로 PV도 함께 생성되고 연결됨
$ vi cephfs-pvc01.yaml 
--- 
apiVersion : v1
kind : PersistentVolumeClaim
metadata :
  name : cephfs-pvc01
spec :
  accessModes :
    - ReadWriteMany
  resources :
    requests :
      storage : 1Gi
  storageClassName : ceph-filesystem

$ kubectl apply -f cephfs-pvc01.yaml 
$ kubectl get pvc  



7. (ceph-block) PVC 생성
CephFS와 가장 큰 차이점은 PVC 생성 시 accessModes값을 ReadWriteOnce로 구성 
RBD는 ReadWriteMany로 구성할 수 없음
$ vi cephblock-pvc01.yaml 
---
apiVersion : v1
kind : PersistentVolumeClaim
metadata :
  name : rbd-pvc
spec :
  accessModes :
    - ReadWriteOnce
  resources :
    requests :
      storage : 10Gi
  storageClassName : ceph-block

$ kubectl apply -f cephblock-pvc01.yaml 
$ kubectl get pvc



8. Test pod 생성 및 확인
pod를 만들어 마운트가 되는지 테스트
$ vi ceph-test-pod.yaml 
---
apiVersion: v1
kind: Pod
metadata:
  name: ceph-test-pod
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - name: ceph-filesystem-01
          mountPath: /data1
        - name: ceph-block-01
          mountPath: /data2
  volumes:
    - name: ceph-filesystem-01
      persistentVolumeClaim:
        claimName: cephfs-pvc01
        readOnly: false
    - name: ceph-block-01
      persistentVolumeClaim:
        claimName: rbd-pvc
        readOnly: false

$ kubectl apply -f ceph-test-pod.yaml

(확인)                    
$ kubectl exec -ti ceph-test-pod /bin/bash                    
rdb-test-pod01>df -h

설정한 마운트 설정에 맞게 마운트가 된 것을 볼 수 있음

(참고)

https://itmaya.co.kr/wboard/view.php?wb=tech&idx=35
https://jay-chamber.tistory.com/entry/rook-ceph-trouble-shooting-OSD%EA%B0%80-%EC%83%9D%EC%84%B1%EB%90%98%EC%A7%80-%EC%95%8A%EC%95%84%EC%9A%94-Try-1
https://rook.io/docs/rook/v1.9/ceph-teardown.html#zapping-devices
24단계 실습으로 끝내는 쿠버네티스(Rook-ceph) https://naver.me/I55O7bmc
https://computing-jhson.tistory.com/112




최종 프로젝트 테라폼 소스
Fri, 23 Dec 2022 02:43:48 GMT
Github Sunny



Miniproject(22.06.07~22.06.14)
Mon, 13 Jun 2022 19:14:23 GMT
Miniproject _4조
Cloud Infra ochestration
: Tool 구성을 aws로 진행



팀원
강재민
김효진
박민선
박지연
임재헌



역할
Ansible 구축
Jenkins 구축
Terraform 구축
문서작성
Ansible 구축






1. 프로젝트 개요
1-1. WorkFlow

1-2. 기술스택과 도구
|스택 및 도구|
|:-:|:-:|
|jenkins|
|Ansible|
|Terraform|
|Docker|
|Kubernetes|
|Git|

2. 프로젝트 구성
초기 Architecture 설계도

네트워크|IPv4 CIDR
|:--:|:--:|
VPC|10.0.0.0/16
public subnet|10.0.10.0/24
private subnet|10.0.30.0/24






Public
Private



Jenkins
13.125.140.70
10.0.10.206


Ansible
13.209.20.29
10.0.10.209


Docker
3.38.107.141
10.0.10.95


Kubernetes
3.38.192.209
10.0.10.248



3. CI/CD를 위한 기본 인프라 구성
3-1. Kubernetes Cluster 구성
|kubeadm|kubelet|kubectl
|:--:|:--:|:--:|:--:|
버전|1.22.8|1.22.8|1.22.8



구성|설정값
|:--:|:--:|
설치방법|Kubeadm
pod-network-cidr|172.16.0.0/16



3-2. Build 및 Deployment Server(Jenkins, Ansible, Docker) 구성
3-2-1) 기본 terraform 구성
vi provider.tf : Infrastructure의 type
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-2"
}





vi vpc.tf : 가용영역1개, public2개, private1개 생성
module "project1_vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "project1_vpc"

  cidr = "10.0.0.0/16"

  azs             = ["ap-northeast-2a"]
  public_subnets  = ["10.0.10.0/24", "10.0.20.0/24"]
  private_subnets = ["10.0.30.0/24"]

  create_database_subnet_group = true

  create_igw = true

  enable_nat_gateway = true
  single_nat_gateway = true

}





vi ec2.tf : 4대의 ec2 생성
resource "aws_key_pair" "project1_key" {
  key_name   = "project1_key"
  public_key = file("/home/vagrant/.ssh/id_rsa.pub")
}

resource "aws_instance" "jenkins" {
  ami                    = "ami-058165de3b7202099"
  availability_zone      = module.project1_vpc.azs[0]
  instance_type          = "t2.medium"
  vpc_security_group_ids = [aws_security_group.all-sg.id]
  subnet_id              = module.project1_vpc.public_subnets[0]
  key_name               = aws_key_pair.project1_key.key_name

  tags = {
    Name = "jenkins"
  }
}


resource "aws_instance" "ansible" {
  ami                    = "ami-058165de3b7202099"
  availability_zone      = module.project1_vpc.azs[0]
  instance_type          = "t2.micro"
  vpc_security_group_ids = [aws_security_group.all-sg.id]
  subnet_id              = module.project1_vpc.public_subnets[0]
  key_name               = aws_key_pair.project1_key.key_name

  tags = {
    Name = "ansible"
  }
}

resource "aws_instance" "docker" {
  ami                    = "ami-058165de3b7202099"
  availability_zone      = module.project1_vpc.azs[0]
  instance_type          = "t2.micro"
  vpc_security_group_ids = [aws_security_group.all-sg.id]
  subnet_id              = module.project1_vpc.public_subnets[0]
  key_name               = aws_key_pair.project1_key.key_name

  tags = {
    Name = "docker"
  }
}


resource "aws_instance" "k8s" {
  ami                    = "ami-058165de3b7202099"
  availability_zone      = module.project1_vpc.azs[0]
  instance_type          = "t2.medium"
  vpc_security_group_ids = [aws_security_group.all-sg.id]
  subnet_id              = module.project1_vpc.public_subnets[0]
  key_name               = aws_key_pair.project1_key.key_name

  tags = {
    Name = "k8s"
  }
}





vi sg.tf : 모든 port를 열어 놓음
resource "aws_security_group" "all-sg" {
  name        = "all-sg"
  description = "Allow all "
  vpc_id      = module.project1_vpc.vpc_id

  ingress {
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
  }

  egress {
    cidr_blocks = ["0.0.0.0/0"]
    from_port   = 0
    protocol    = "-1"
    to_port     = 0
  }
}





3-2-2) Ansible구성

bastionhost 
-- hosts.ini
-- playbook
   ㄴ installJenkins.yml
   ㄴ installDoker.yaml
   ㄴ installk8s.yaml




3-2-3) Jenkins build
- hosts: jenkins_host

  tasks:
    - shell: sudo apt-get update
      ignore_errors: yes
    - shell: sudo apt install -y openjdk-11-jdk
    - shell: curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null
    - shell: echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
    - shell: sudo apt-get update
      ignore_errors: yes
    - command: apt install -y fontconfig jenkins
    - command: apt install -y maven



3-2-4) Docker build
- name: Docker VM Provisioning
  hosts: docker_host
  gather_facts: false

  tasks:
    - command: apt update
      # 사용 가능한 패키지와 그 버전 리스트 업데이트

    - command: apt install -y ca-certificates curl gnupg lsb-release
      # docker 설치

    - command: apt install -y python3-pip
      # python3용 pip 설치 및 python 모듈 구축에 필요한 모든 종속성 설치

    - shell: curl https://get.docker.com | sh
      # docker 설치

    - shell: usermod -aG docker ubuntu
      ubuntu 사용자를 doker 그룹에 추가

    - pip:
        name:
          - docker
          - docker-compose
          # pip를 사용한 docker, docker-compose 설치



3-2-5) ansible build
- name: Ansible VM Provisioning
  hosts: ansible_host
  gather_facts: false

  tasks:
    - command: apt update
    - command: apt install -y ca-certificates curl gnupg lsb-release
    - command: apt install -y python3-pip
    - shell: curl https://get.docker.com | sh
    - shell: usermod -aG docker ubuntu
    - pip:
        name:
          - docker
          - docker-compose
    - command: apt install -y ansible
    - command: apt install -y python3-pip
    - shell: sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/g' /etc/ssh/sshd_config
    - shell: pip install openshift==0.11
    - shell: echo 'ubuntu:ubuntu' | chpasswd
    - shell: sudo systemctl restart ssh
    - shell: mkdir /home/ubuntu/.kube
    - shell: curl -LO https://dl.k8s.io/release/v1.22.8/bin/linux/amd64/kubectl
    - shell: sudo install kubectl /usr/local/bin/
   #- shell: scp ~/.kube/config .kube/config



3-2-6) k8s build
- name: Contorl-Plane VM Provisioning
  hosts: controlplane_host
  gather_facts: false

  tasks:
    - command: apt update
    - command: apt install -y ca-certificates curl gnupg lsb-release
    - command: apt install -y python3-pip
    - shell: curl https://get.docker.com | sh
    - shell: usermod -aG docker ubuntu
    - pip:
        name:
          - docker
          - docker-compose
    - command: apt-get install -y apt-transport-https ca-certificates curl
    - shell: curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
    - shell: echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
    - command: apt-get update
    - shell: sudo apt-get install kubeadm=1.22.8-00 kubelet=1.22.8-00 kubectl=1.22.8-00 -y
    - copy:
        src: "/home/ubuntu/daemon.json"
        dest: "/etc/docker/"
    - shell: sudo systemctl restart docker
    - shell: sudo systemctl daemon-reload && sudo systemctl restart kubelet
    - shell: IPADDR=`ip addr | tail -n 8 | head -n 1 | cut -f 6 -d' ' | cut -f 1 -d '/'`
    - shell: sudo kubeadm init --control-plane-endpoint "{{ lookup('env', 'IPADDR') }}" --pod-network-cidr 172.16.0.0/16 --apiserver-advertise-address "{{ lookup('env', 'IPADDR') }}"
    - shell: mkdir -p /home/ubuntu/.kube
    - shell: sudo cp -i /etc/kubernetes/admin.conf /home/ubuntu/.kube/config
    - shell: sudo chown ubuntu:ubuntu /home/ubuntu/.kube/config
    - fetch:
        src: "/home/ubuntu/.kube/config"
        dest: "/home/ubuntu/.kube/config"
        flat: yes
   #- shell: kubectl create -f https://projectcalico.docs.tigera.io/manifests/tigera-operator.yaml
    - shell: curl https://projectcalico.docs.tigera.io/manifests/custom-resources.yaml -O
    - replace:
        path: /home/ubuntu/custom-resources.yaml
        regexp: 192.168
        replace: 172.16
   #- shell: kubectl create -f custom-resources.yaml
3-2-6) worker node build
- name: Contorl-Plane VM Provisioning
  hosts: controlplane_host
  gather_facts: false

  tasks:
    - command: apt update
    - command: apt install -y ca-certificates curl gnupg lsb-release
    - command: apt install -y python3-pip
    - shell: curl https://get.docker.com | sh
    - shell: usermod -aG docker ubuntu
    - pip:
        name:
          - docker
          - docker-compose
    - command: apt-get install -y apt-transport-https ca-certificates curl
    - shell: curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
    - shell: echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
    - command: apt-get update
    - shell: sudo apt-get install kubeadm=1.22.8-00 kubelet=1.22.8-00 kubectl=1.22.8-00 -y
    - copy:
        src: "/home/ubuntu/daemon.json"
        dest: "/etc/docker/"
    - shell: sudo systemctl restart docker
    - shell: sudo systemctl daemon-reload && sudo systemctl restart kubelet
#! /bin/sh
sudo kubeadm join 10.0.10.248:6443 --token u3adz9.flbop6nslkaupqrq --discovery-token-ca-cert-hash sha256:70f23d516ea80a39c784d129bddb13d6f71a96865b97acac573054443183b355




4. ci/cd 구현
4-1. Kubernetes Cluster Pod 배포를 위한 Ansible Playbook
4-1-1) kubernetes playbook
vi docker_build_and_push.yaml : DockerHub에서 image build 및 push
- name: Docker Image Build and Push
  hosts: docker_host
  gather_facts: false

  tasks:
    - command: docker image build -t repush/cicdproject:"{{ lookup('env', 'BUILD_NUMBER') }}" ~/
    - command: docker login -u repush -p "{{ lookup('env', 'TOKEN') }}"
    - command: docker push repush/cicdproject:"{{ lookup('env', 'BUILD_NUMBER') }}"
    - command: docker logout

첫번째 command: image build command, 변수를 통해 버전을 지정 (중복이 되지 않도록 build 횟수로 버전 생성)
두번째 command: DockerHub login command, 변수를 통해 Token을 지정
세번째 command: push command, 변수를 통해 버전을 지정 (중복이 되지 않도록 build 횟수로 버전 생성)
네번째 command: logout command




vi kube_deploy.yaml : k8s deployment 및 service
- hosts: ansible_host
  gather_facts: no

  tasks:
    #- command: kubectl apply -f java-hello-world/kube_manifest/
    - name: Create Deployment                        # container 배포
      k8s:
        state: present
        definition:
          apiVersion: apps/v1
          kind: Deployment
          metadata:
            name: java-hello
            namespace: default
          spec:
            replicas: 6                              # pod 개수 지정
            selector:
              matchLabels:
                app: java-hello
            template:
              metadata:
                labels:
                  app: java-hello
              spec:
                containers:
                  - name: java-hello
                    image: "repush/cicdproject:{{ lookup('env', 'BUILD_NUMBER') }}"       # DockerHub에 push된 image 
                    imagePullPolicy: Always
                    ports:
                      - containerPort: 8080           # containerPort지정
    - name: Create Service                            # service 배포
      k8s:
        state: present
        definition:
          apiVersion: v1
          kind: Service
          metadata:
            name: java-hello-svc
            namespace: default
          spec:
            type: NodePort
            selector:
              app: java-hello
            ports:
              - port: 80
                targetPort: 8080
                nodePort: 31313                        # nodePort 지정



4-2. Docker Image Build를 위한 이미지용 Dockerfile
4-2-1) Dockerfile
vi Dockerfile
FROM tomcat:9.0-jre11-openjdk                # tomcat:9.0-jre11-openjdk 이미지를 가져옴

COPY webapp.war /usr/local/tomcat/webapps    # 현재 경로의 war파일을 이미지 안에 /usr/local/tomcat/ 경로에 복사




4-3. ci/cd 구현을 위한 Jenkins Job 구성
4-3-1) 사용된 플러그인

Maven Integration plugin 3.19
Maven Invoker plugin 2.4
Publish Over SSH 1.24

4-3-2) JAVA Project Build를 위한 JDK환경변수 세팅
Jenkins 관리 - Global Tool Configuration - JDK

4-3-3) JAVA Project Build를 위한 Maven환경변수 세팅
Jenkins 관리 - Global Tool Configuration - Maven

4-3-4) ci/cd 구현을 위한 Junkins Job 설정
새로운 Item - Pipeline
1) DockerHub 로그인을 위한 로그인 토큰 설정
General

Default Value: DockerHub 계정의 Token


2) 프로젝트의 브랜치 변화 감지를 위한 Build Triggers 설정
Build Triggers

매 분마다 Github의 Push Event감지하는 Polling설정


3) Pipeline과 Jenkins파일 구성
Pipiline - Definition - SCM

Pipiline - Definition - Script Path

Github Repository 내의 jenkinsfile 상대경로


Jenkinsfile 구성

Java Build stage: Maven을 통해 Java Project Archive파일 빌드
Docekr Image Build With Remote Ansible Server AND Remote Docker Server Using Publish Over SSH Module: Publish Over SSH Module모듈로 Docker Image 빌드를 위한 파일을 Ansible서버에 전송 후 Docker서버에 전송, Ansible 서버에 Docker Image 빌드와 Project 배포 실행을 위한 Ansible Playbook 전송 및 실행.

jenkinsfile
pipeline {
    agent any

    tools {
        // Install the Maven version configured as "M3" and add it to the path.
        maven "M2_HOME"
    }

    stages {
        stage('Java Build') {
            steps {
                // Run Maven on a Unix agent.
                sh "mvn -Dmaven.test.failure.ignore=true clean package -f pom.xml"
            }
        }
        stage('Docekr Image Build With Remote Ansible Server AND Remote Docker Server Using Publish Over SSH Module') {
            steps {
                sshPublisher(publishers: [sshPublisherDesc(configName: 'ansible-host', transfers: [sshTransfer(cleanRemote: false, excludes: '', execCommand: '', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: 'java-hello-world', remoteDirectorySDF: false, removePrefix: 'webapp/target/', sourceFiles: 'webapp/target/webapp.war'), sshTransfer(cleanRemote: false, excludes: '', execCommand: '', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: 'java-hello-world', remoteDirectorySDF: false, removePrefix: 'docker/', sourceFiles: 'docker/Dockerfile'), sshTransfer(cleanRemote: false, excludes: '', execCommand: '''scp java-hello-world/Dockerfile 13.125.234.12:~/
scp java-hello-world/webapp.war 13.125.234.12:~/
TOKEN=`echo $TOKEN` BUILD_NUMBER=`echo $BUILD_NUMBER` ansible-playbook java-hello-world/docker_build_and_push.yaml
BUILD_NUMBER=`echo $BUILD_NUMBER` ansible-playbook java-hello-world/kube_deploy.yaml''', execTimeout: 120000, flatten: false, makeEmptyDirs: false, noDefaultExcludes: false, patternSeparator: '[, ]+', remoteDirectory: 'java-hello-world', remoteDirectorySDF: false, removePrefix: 'playbook/', sourceFiles: 'playbook/*.yaml')], usePromotionTimestamp: false, useWorkspaceInPromotion: false, verbose: true)])
            }
        }
    }
}



5. 구현 결과
5-1. Jenkins build

5-2. 로컬에서 접근

5-3. 웹사이트에서 접근

6. 결론
6-1. As-is

기본적으로 이번 프로젝트에서 Jenkins를 통한 GitOps CI/CD는 성공했다.

Terraform과 Ansible을 사용하여 빌드를 자동화하는데 어느정도 구축은 했다.





6.2. To-be

앤서블 플레이북 작성시 몇몇 명령어가 실행되지 못한 점이 아쉬웠다.
앤서블 플레이북을 지금은 shell과 command위주로 사용했는데 모듈을 사용하면 더 완성도있는 결과를 낼 수 있었을것같다.
로드밸드밸런서와 오토스케일링을 활용한 웹서비스 배포를 GUI환경에서는 성공했지만 마지막에 IaC로 구현한 인프라에서는 작동하지 못한 점이 아쉬웠다.
보안그룹을 지금은 간단하게 열어놓았지만 좀더 최적화해서 보안그룹을 구성하면 더 좋을 것 같다.
workernode를 오토스케일링 하여 자동으로 추가하는 작업도 GUI환경에서는 성공했지만 IaC로 구현한 인프라에서는 작동하지 못한 점 또한 아쉽게 되었다.
배스천 호스트를 오토스케일링하고 네트워크 로드밸런서로 구성하여 도메인 네임 엔드포인트로 ssh는 것도 GUI환경에서 성공했지만 IaC로 구현하면서 시간이 부족하여 구성하지 못한 점도 아쉽게 되었다.




DevOps 실현을 위한 CI/CD 구축 (22.06.07)
Tue, 07 Jun 2022 06:46:27 GMT
ArgoCD
GitOps의 구현체
Argo공식site:
https://argo-cd.readthedocs.io/en/stable/
1) Install Argo CD
Argo설치를 위해선 (kubernetes 필요)

Installed kubectl command-line tool.
Have a kubeconfig file (default location is ~/.kube/config).kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

2) Download Argo CD CLI
curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64

chmod +x /usr/local/bin/argocd
cli 설치 링크: 
https://argo-cd.readthedocs.io/en/stable/cli_installation/
kubectl get all -n argocd
# argocd-server    Cluster-IP 확인
외부에서 접근하도록 설정 필요.

3) argo CD 서비스 노출

로드밸런서 타입으로 변경kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'


kubectl describe svc argocd-server -n argocd
Load Balancer Port 확인
![](https://velog.velcdn.com/images/sunny-10/post/4ec8b3c9-3615-4bc1-986f-7aae01182714/image.PNG)

#### 4) 웹 브라우저에서 login
웹브라우저에서 [master_IP]:[port]
    예)  192.168.59.10:31958
https 로 redirect됨.


web UI의 로그인 계정은 admin
암호는 확인해서 입력
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo
[문자들이 나옴]= 암호
![](https://velog.velcdn.com/images/sunny-10/post/2f83bc7a-d04a-4689-a868-67008faeb379/image.PNG)![](https://velog.velcdn.com/images/sunny-10/post/ad26c7d7-1fe7-4b01-9a67-030bbe6b3f43/image.PNG)


#### 5) CLI도 argocd 로그인
argocd 엔터
argocd login --insecure :
                       192.168.100.100:65001
login id : admin
password : (위에서 확인한 문자)

![](https://velog.velcdn.com/images/sunny-10/post/31d5e93c-21b1-4d6f-9a19-447fe0a8bbd7/image.PNG)

#### 6) application 생성하기 - CLI
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
source : (git) --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook 

destination ; local kubernetes cluster
    --dest-server https://kubernetes.default.svc --dest-namespace 
![](https://velog.velcdn.com/images/sunny-10/post/5439a4bf-4e1b-4b34-aca6-b8f3f4aed58f/image.PNG)


#### 7) CLI로 application 확인
argocd app get guestbook
webui로 확인하시면 노란색 (동기화 안됨)

CLI 동기화 하기 
argocd app sync guestbook
argocd app get guestbook
![](https://velog.velcdn.com/images/sunny-10/post/d995350c-f1bd-430a-8aa4-e0c79994ee91/image.PNG)![](https://velog.velcdn.com/images/sunny-10/post/52925320-8fda-4b6c-b80e-fec7fdebb9be/image.PNG)


ArgoCD web UI에서 guestbook application을 삭제해보기
kubernetes 확인


#### 8) guestbook appliname을 WEB UI에서 생성하기
web UI에서 동기화


git------------------kubernetes cluster
        applicaton

git 로그인 repository 생성

guestbook-ui-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-ui
spec:
  replicas: 1
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: guestbook-ui
  template:
    metadata:
      labels:
        app: guestbook-ui
    spec:
      containers:
      - image: gcr.io/heptio-images/ks-guestbook-demo:0.2
        name: guestbook-ui
        ports:
        - containerPort: 80
guestbook-ui-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: guestbook-ui
spec:
  ports:

port: 80
targetPort: 80
selector:
app: guestbook-ui![](https://velog.velcdn.com/images/sunny-10/post/46028ac5-29a5-4d09-a0e3-57333c7ca862/image.PNG)
/guestbook/ 하위에 등록


9) git repo와 kubernetes cluster를 연동하는 application을 생성해보기
source : git URL 
https  :  https://github.com/soyoung-2020/argocd.git  (**)
ssh   : git@github.com:Sunny-1030/argocd.git
 PATH :  repository 하위 디렉토리 명 . guestbook
    repository 하위에 바로 yaml 파일이있을 경우에는  .
    project : default
destination
   https://kuberntes.default.svc
   namespace : default (다른 이름이 지정이 가능하나, 미리 생성해야함)
application name : myguestbook
myguestbook을 kubernetes cluster와 동기화 

10) git repository - guestbook-ui-deployment.yaml
1차 변경
replicas: 1    --->   2 개
local pc라면 commit >  push
git site에서 편집

11) argoCD webui에서  git소스/live소스를 diff 확인  > 동기화sync
kubectl get all -n default
Argocd WebUI  - application 내에서 상단에 “HISTORY”
현시점 외에 과거로 rollback 해보기(2개,1개),  동기화 하면 다시 현재로.(2개)

rollback 시 이전(1개) 으로 돌아가며 sync(동기화)하면 원 상태(2개)로 복구됨
12) kubernetes manifest 를 동기화 해보자.
자신의 git에 repository 생성
nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type:  LoadBalancer    # 서비스 타입
  ports:
  - port: 8080       # 서비스 포트
    targetPort: 80   # 타켓, 즉 pod의 포트
    protocol: TCP
    name: http
  selector:
    app: nginx
nginx-deployment.yaml
apiVersion: apps/v1           # 쿠버네티스 api 버전
kind: Deployment              # 생성할 오브젝트 종류
metadata:                
  name: nginx-deployment      # deployment의 이름
  labels:
    app: nginx                # label 지정
spec:                         # deployment의 스펙을 정의
  replicas: 3                 # 3개의 pod 설정
  selector:                   # deployment가 관리할 pod를 찾는 방법을 정의
    matchLabels:     
      app: nginx
  template:
    metadata:
      labels:                 # pod의 label
        app: nginx
    spec:
      containers:             # 컨테이너 설정
      - name: nginx          
        image: nginx:1.14.2
        ports:
        - containerPort: 80

13) templates 이용하는 방법  - helm (helm chart)
application 추가
repository :    git  -> helm
repository : https://github.com/argoproj/argocd-example-apps.git
path  : apps
chart : repository를 인식하면 자동으로 목록 뜸.  Chart.yaml 선택
하단에 helm 설정파트가 있음 values: values.yaml (또는 values.yaml파일을 보제하여 값을 변경하고자하는 셋팅가능)
repository 
-HTTPS git연결
-SSH git 연결 
    key 생성
    github : public key 등록
    argocd : private 등록, repository 등록 -> application 연결에 사용

필요 조건	추천
단순한 웹 트래픽 라우팅 (e.g. ingress + path 기반)	NGINX Ingress Controller
복잡한 트래픽 분할, 인증(mTLS), 정책 제어, 전체 서비스 메시	Istio Ingress Gateway
A/B 테스트, 카나리 배포, 헤더 기반 라우팅, 가시성 확보가 필요한 환경	Istio
빠르게 설정하고 운영 단순화가 중요한 경우	NGINX

	Public	Private
Jenkins	13.125.140.70	10.0.10.206
Ansible	13.209.20.29	10.0.10.209
Docker	3.38.107.141	10.0.10.95
Kubernetes	3.38.192.209	10.0.10.248