chhanz's Tech Blog

[AWS] Amazon S3 Files - S3 버킷을 파일 시스템으로 마운트하기

Thu, 09 Apr 2026 00:00:00 +0900

개요

Amazon S3 버킷을 NFS 파일 시스템으로 마운트하여 일반 파일 명령어(ls, cp, cat 등)로 접근할 수 있는 Amazon S3 Files 기능이 2026년 4월에 출시되었습니다.
이번 포스트에서는 S3 Files 의 개념과 EC2 에서 마운트하는 방법을 기록하도록 하겠습니다.

S3 Files 란?

S3 Files 는 S3 버킷을 NFS v4.1/v4.2 파일 시스템으로 마운트할 수 있게 해주는 기능입니다.
내부적으로 Amazon EFS 기반의 고성능 스토리지를 활용하며, 활성 데이터에 대해 약 ~1ms 수준의 지연시간을 제공합니다.

데이터는 S3 를 떠나지 않으며, S3 API 와 파일 API 를 동시에 사용할 수 있습니다.

지원하는 컴퓨팅 서비스

Amazon EC2
Amazon ECS
Amazon EKS
AWS Lambda

성능 스펙

항목	수치
지연시간 (활성 데이터, 소파일)	~1ms
최대 읽기 IOPS (파일시스템당)	250,000
최대 쓰기 IOPS (파일시스템당)	50,000
집계 읽기 처리량	수 TB/s
집계 쓰기 처리량	1~5 GiB/s (리전별)
최대 클라이언트당 읽기 처리량	3 GiB/s
동시 연결	최대 25,000개

파일 시스템 기능

S3 Files 는 아래와 같은 파일 시스템 기능을 지원합니다.

NFS v4.1 / v4.2 프로토콜 지원
POSIX 권한 (UID/GID 를 오브젝트 메타데이터에 저장)
NFS close-to-open 일관성
파일 잠금(locking) 지원
디렉토리 / 서브디렉토리 탐색

작동 원리

읽기

소파일 (< 128KB) → 고성능 스토리지에서 저지연 서빙
대파일 (≥ 128KB, S3 동기화된 데이터) → S3 에서 직접 스트리밍 (S3 Files 요금 없음)

쓰기

고성능 스토리지에 먼저 기록 → 60초 배치 윈도우 후 S3 자동 동기화
60초 내 연속 쓰기는 단일 S3 PUT 으로 통합

미접근 데이터

30일 (기본값, 1~365일 설정 가능) 동안 접근이 없으면 고성능 스토리지에서 자동 삭제
이후 접근 시 S3 에서 다시 로드

보안

전송: TLS 1.3
저장: SSE-S3 / SSE-KMS
접근 제어: IAM + POSIX 권한
모니터링: CloudWatch / CloudTrail

파일 시스템 생성

콘솔에서 생성

S3 콘솔에서 파일 시스템을 생성하는 방법은 아래와 같습니다.

1) S3 콘솔 좌측 메뉴에서 파일 → 파일 시스템 을 클릭합니다.

2) 파일 시스템 생성 버튼을 클릭한 후, 범용 버킷 또는 접두사를 입력합니다.
형식: s3://버킷명 또는 s3://버킷명/접두사/

3) VPC 를 선택하고 파일 시스템 생성 을 클릭합니다.
생성 완료 후 모든 AZ 에 마운트 타겟이 자동으로 생성됩니다. (수 분 소요)

위와 같이 파일 시스템이 생성되고, 탑재 대상(Mount Target) 목록을 확인 할 수 있습니다.

EC2 에서 마운트하기

사전 조건

EC2 에서 S3 Files 파일 시스템을 마운트하기 위해서는 아래 조건이 필요합니다.

amazon-efs-utils 버전 3.0.0 이상 필요 (S3 Files 지원)
- ⚠️ Amazon Linux 2023 기본 패키지 버전은 2.4.2 로 S3 Files 를 지원하지 않습니다.
- 별도의 efs-utils 전용 리포지토리에서 설치해야 합니다.
S3 버킷 Versioning 활성화 필요 (S3 Files 필수 요건)
EC2 IAM Role 에 AmazonS3FilesClientFullAccess 정책 추가
보안 그룹 설정 (아래 참조)

보안 그룹 설정

EC2 인스턴스와 마운트 타겟 간 NFS 통신을 위해 보안 그룹을 아래와 같이 설정해야 합니다.

대상	방향	프로토콜	포트	소스/대상
EC2 보안 그룹	Outbound	TCP	2049	마운트 타겟 보안 그룹
마운트 타겟 보안 그룹	Inbound	TCP	2049	EC2 보안 그룹

위와 같이 마운트 타겟의 보안 그룹에서 EC2 보안 그룹으로부터의 TCP 2049 Inbound 를 허용해야 합니다.

amazon-efs-utils 3.0.0 이상 설치

앞서 언급한 바와 같이 Amazon Linux 2023 기본 패키지는 amazon-efs-utils 2.4.2 버전이므로 S3 Files 를 지원하지 않습니다.
아래 두 가지 방법 중 하나로 3.0.0 이상 버전을 설치할 수 있습니다.

방법 1: 전용 installer 스크립트 사용

curl https://amazon-efs-utils.aws.com/efs-utils-installer.sh | sudo sh -s -- --install

방법 2: efs-utils 리포지토리 추가 후 직접 설치

installer 스크립트 실행 후 전용 리포지토리가 추가됩니다. 아래와 같이 패키지를 확인하고 설치합니다.

$ yum list | grep efs-utils
amazon-efs-utils.x86_64          3.0.1-1.amzn2023          efs-utils

$ sudo yum install amazon-efs-utils-3.0.1-1.amzn2023

설치가 완료되면 아래와 같이 확인 할 수 있습니다.

$ rpm -qa | grep efs
amazon-efs-utils-3.0.1-1.amzn2023.x86_64

마운트

마운트 디렉토리를 생성하고 mount 명령어로 S3 Files 파일 시스템을 마운트합니다.

mkdir ./s3files
sudo mount -t s3files fs-0f6284xxxxxxxxx:/ /root/s3files

마운트가 완료되면 df -hT 명령어로 확인 할 수 있습니다.

$ df -hT /root/s3files/
Filesystem   Type  Size  Used Avail Use% Mounted on
127.0.0.1:/  nfs4  8.0E     0  8.0E   0% /root/s3files

mount 명령어로도 NFS4 프로토콜로 마운트된 것을 확인 할 수 있습니다.

$ mount | grep s3files
127.0.0.1:/ on /root/s3files type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,...,addr=127.0.0.1)

위와 같이 nfs4 타입으로 마운트되었으며, NFS v4.2 프로토콜을 사용하는 것을 확인 할 수 있습니다.

파일 생성 및 S3 동기화 확인

마운트된 디렉토리에서 파일을 생성하면 S3 버킷에 자동으로 동기화됩니다.

$ touch s3files/s3-test.txt

$ ls -l s3files/
total 4
-rw-r--r-- 1 root root 0 Apr 10 00:53 s3-test.txt

S3 콘솔에서 확인하면 s3-test.txt 오브젝트가 자동으로 생성된 것을 확인 할 수 있습니다.

위와 같이 파일 시스템에서 생성한 파일이 S3 버킷에 자동으로 동기화되는 것을 확인 할 수 있습니다.

기술 제약 및 참고 사항

S3 Files 사용 시 아래 사항을 참고하시기 바랍니다.

내부적으로 Amazon EFS 기반으로 구현
Linux 기반 컴퓨팅만 지원 (Windows 미지원)
파일 크기 임계값 기본값: 128KB (설정 가능)
데이터 보존 기간: 1~365일 (기본 30일, 설정 가능)
VPC 내 마운트 타겟 필요 (AZ 당 최대 1개)
S3 버킷 변경 → 파일 시스템 반영: 수 초 ~ 수 분
파일 시스템 변경 → S3 동기화: 수 분 이내 (60초 배치 윈도우)

기존 서비스와 비교

S3 Files 와 기존 AWS 파일 스토리지 서비스를 비교하면 아래와 같습니다.

서비스	주요 용도	프로토콜	적합한 워크로드
S3 Files	S3 데이터를 파일로 접근	NFS v4.1/v4.2	AI/ML, 데이터 분석, S3 데이터 파일 접근
EFS	일반 공유 파일 스토리지	NFS v4.0/v4.1	웹 서버, CMS, 공유 홈 디렉토리
FSx for Lustre	고성능 병렬 파일 시스템	Lustre	HPC, GPU 클러스터, 대규모 연산
FSx for NetApp ONTAP	엔터프라이즈 NAS	NFS, SMB, iSCSI	온프레미스 NAS 마이그레이션

S3 Files 의 핵심 장점은 기존에 S3 와 파일 시스템을 이중으로 관리하던 워크로드에서 파일 시스템 복사본을 제거할 수 있다는 점입니다.
AWS 에 따르면 기존 S3 ↔ 파일 시스템 이중 관리 대비 최대 90% 비용 절감이 가능하다고 합니다.

주요 활용 사례

AI 에이전트 워크플로우

여러 AI 에이전트가 Python 라이브러리, CLI 도구, 쉘 스크립트를 사용하여 공유 S3 데이터에 동시 접근하고, 중간 결과를 교환하거나 컨텍스트를 유지할 수 있습니다.

ML 훈련 파이프라인

기존 방식: S3 → 로컬 파일 시스템으로 복사 → 전처리 → 훈련 → 결과를 S3 에 업로드
S3 Files 사용: S3 데이터를 그대로 파일 시스템으로 접근 → 복사 단계 제거

데이터 분석 / 공동 작업

연구원, 분석가, 데이터 과학자가 최대 25,000개 동시 연결로 동일한 S3 버킷 데이터에 접근하여 협업할 수 있습니다.

미디어 제작

VFX 스튜디오, 렌더팜에서 기존 파일 기반 도구를 그대로 사용하면서 S3 에 저장된 영상 및 에셋에 직접 접근할 수 있습니다.

참고 자료

[Docker] Traefik 기본 사용법

Fri, 27 Feb 2026 00:00:00 +0900

Traefik 기본 사용법

이번 포스팅에서는 Docker 환경에서 Traefik을 구성하고 사용하는 방법에 대해 기록하도록 하겠습니다.

Traefik 이란?

Traefik은 클라우드 네이티브 환경을 위한 리버스 프록시 / 로드 밸런서입니다.
Nginx나 HAProxy와 같은 전통적인 프록시와 달리, 서비스를 자동으로 감지하고 라우팅 설정을 동적으로 업데이트하는 것이 특징입니다.

특히 Docker 환경에서 컨테이너에 레이블(Label)만 추가하면 자동으로 라우팅이 설정되어, 별도로 설정 파일을 관리할 필요가 없습니다.

테스트 환경

테스트 환경 : Amazon Linux 2023
Traefik : v3.3

핵심 개념

Traefik 은 4가지 핵심 컴포넌트로 구성됩니다.

EntryPoints

외부에서 들어오는 네트워크 포트를 정의합니다.

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

Routers

요청을 규칙에 따라 분류하여 적절한 서비스로 연결합니다.

# Host 기반 라우팅
rule: "Host(`example.com`)"

# Path 기반 라우팅
rule: "PathPrefix(`/api`)"

# 복합 조건
rule: "Host(`example.com`) && PathPrefix(`/api`)"

Middlewares

라우터와 서비스 사이에서 요청/응답을 변환하는 플러그인입니다.

미들웨어	용도
`basicAuth`	HTTP Basic 인증
`redirectScheme`	HTTP → HTTPS 리다이렉트
`stripPrefix`	URL 경로 앞부분 제거
`rateLimit`	요청 속도 제한
`headers`	헤더 추가/수정

Providers

Traefik이 라우팅 설정을 읽어오는 소스입니다.

Provider	설명
`docker`	Docker 컨테이너 레이블 자동 감지
`file`	정적 YAML/TOML 파일
`kubernetes`	Kubernetes Ingress

설치 (Docker Compose)

아래와 같은 방법으로 Traefik 을 구성합니다.

디렉토리 구조

traefik/
├── docker-compose.yml
├── traefik.yml        ← 정적 설정 (Static Config)
└── dynamic.yml        ← 동적 설정 (Dynamic Config)

traefik.yml (정적 설정)

# traefik.yml
api:
  dashboard: true
  insecure: true       # 대시보드 인증 없이 접근 (개발용)

entryPoints:
  web:
    address: ":80"

providers:
  docker:
    exposedByDefault: false   # 레이블 없는 컨테이너는 노출 안 함
  file:
    filename: /etc/traefik/dynamic.yml
    watch: true               # 파일 변경 자동 감지

log:
  level: INFO

docker-compose.yml

services:
  traefik:
    image: traefik:v3.3
    container_name: traefik
    restart: unless-stopped
    ports:
      - "80:80"
      - "127.0.0.1:8888:8080"   # 대시보드 (로컬 전용)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./dynamic.yml:/etc/traefik/dynamic.yml:ro
    networks:
      - traefik_net

networks:
  traefik_net:
    external: true

대시보드 포트(8888)는 127.0.0.1에만 바인딩하여 외부 노출을 차단합니다.

실전 예시 1 — Docker 컨테이너 라우팅

컨테이너에 레이블만 추가하면 Traefik 이 자동으로 라우팅 설정을 감지합니다.

services:
  myapp:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.myapp.rule=Host(`myapp.example.com`)"
      - "traefik.http.routers.myapp.entrypoints=web"
      - "traefik.http.services.myapp.loadbalancer.server.port=80"
    networks:
      - traefik_net

위와 같이 레이블을 추가하면 myapp.example.com 으로 들어오는 요청이 해당 컨테이너로 자동 라우팅되는 것을 확인 할 수 있습니다.

실전 예시 2 — Path 기반 라우팅

여러 서비스를 하나의 도메인에서 경로로 분리할 때 아래와 같이 구성합니다.

services:
  # docs.example.com/      → open-webui
  open-webui:
    image: ghcr.io/open-webui/open-webui
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.webui.rule=Host(`docs.example.com`)"
      - "traefik.http.routers.webui.entrypoints=web"

  # docs.example.com/docs/ → mkdocs
  mkdocs:
    image: squidfunk/mkdocs-material
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.mkdocs.rule=Host(`docs.example.com`) && PathPrefix(`/docs`)"
      - "traefik.http.routers.mkdocs.entrypoints=web"

실전 예시 3 — BasicAuth 미들웨어

특정 서비스에 HTTP Basic 인증을 추가하는 방법입니다.

비밀번호 해시 생성

$ htpasswd -nb username password
username:$apr1$xxxxxxxx$hashedpassword

dynamic.yml 에 미들웨어 정의

출력된 해시를 그대로 dynamic.yml 에 붙여넣으면 됩니다.

# dynamic.yml
http:
  middlewares:
    my-auth:
      basicAuth:
        users:
          - "username:$apr1$xxxxxxxx$hashedpassword"

컨테이너 레이블에서 참조

labels:
  - "traefik.http.routers.myapp.middlewares=my-auth@file"

파일 프로바이더의 미들웨어를 Docker 레이블에서 참조할 때는 반드시 @file 접미사를 붙여야 합니다.

실전 예시 4 — ELB 헬스체크 처리

AWS ELB(Elastic Load Balancer) 뒤에 Traefik을 배치할 때, ELB 헬스체크는 Host 헤더를 포함하지 않습니다.
이 경우 아래와 같이 별도 라우터를 파일 프로바이더로 등록합니다.

# dynamic.yml
http:
  routers:
    elb-health:
      rule: "Path(`/health`)"
      entryPoints:
        - web
      service: health-service
      priority: 1

  services:
    health-service:
      loadBalancer:
        servers:
          - url: "http://localhost"

위와 같이 구성하면 Host 조건 없이 /health 경로만으로 라우팅되어 ELB 헬스체크가 정상 통과됩니다.

대시보드

Traefik 대시보드를 통해 현재 라우터/서비스/미들웨어 상태를 실시간으로 확인 할 수 있습니다.

# 로컬에서 접속
http://localhost:8888/dashboard/

# API 로 라우터 목록 확인
$ curl http://localhost:8888/api/http/routers | jq .

주의 사항

Docker 레이블의 Host rule 작성 시 반드시 백틱(`)을 사용해야 합니다.

# ✅ 올바른 문법
- "traefik.http.routers.myapp.rule=Host(`myapp.example.com`)"

# ❌ 작동 안 함
- 'traefik.http.routers.myapp.rule=Host("myapp.example.com")'

참고 자료

[AWS] Firecracker microVM with Amazon EC2 Nested Virtualization

Mon, 23 Feb 2026 00:00:00 +0900

Firecracker microVM with Amazon EC2 Nested Virtualization

Firecracker 란?

Firecracker는 AWS에서 개발한 오픈소스 VMM(Virtual Machine Monitor)입니다.
KVM을 사용하여 경량 microVM을 생성하고 관리하며, AWS Lambda와 AWS Fargate의 기반 기술로 사용되고 있습니다.

Firecracker는 64-bit Intel, AMD, Arm CPU를 지원하며, hardware virtualization 기능이 필요합니다.
Fly.io, Kata Containers, firecracker-containerd 등 다양한 프로젝트에서 활용되고 있습니다.

이번 포스팅에서는 AWS EC2 Nested Virtualization 환경에서 Firecracker microVM을 설치하고 실행하는 방법에 대해 기록하도록 하겠습니다.

EC2 Nested Virtualization

기존에는 EC2에서 KVM을 사용하기 위해 .metal 인스턴스 타입을 사용해야 했습니다.
.metal 인스턴스는 비용이 높아 Firecracker와 같은 KVM 기반 기술을 테스트하기에 부담이 되었습니다.

하지만 AWS Nitro 기반 일반 EC2 인스턴스에서 Nested Virtualization(KVM)을 지원하게 되면서, C8i, M8i, R8i 인스턴스 타입에서도 KVM을 사용할 수 있게 되었습니다.

참고: Nested Virtualization은 현재 C8i, M8i, R8i 인스턴스 타입에서만 지원됩니다. (출처: AWS 공식 문서)

테스트 환경

테스트 환경: Amazon Linux 2023 (Nitro 기반 EC2 인스턴스)
Firecracker 버전: v1.14.1
Guest OS: Ubuntu 24.04

KVM 지원 확인

먼저 EC2 인스턴스에서 KVM이 지원되는지 확인합니다.

[root@ip-172-31-53-163 ~]# ls -la /dev/kvm
crw-rw-rw-. 1 root kvm 10, 232 Feb 23 12:20 /dev/kvm

[root@ip-172-31-53-163 ~]# lsmod | grep kvm
kvm_intel             393216  0
kvm                  1155072  1 kvm_intel
irqbypass              16384  1 kvm

위와 같이 /dev/kvm 디바이스가 존재하고 KVM 모듈이 로드되어 있으면 Firecracker를 사용할 수 있습니다.

KVM이 지원되지 않는 경우
/dev/kvm 디바이스가 없다면 EC2 인스턴스를 생성할 때 “Enable nested virtualization” 옵션이 활성화되어 있는지 확인하세요.
AWS 콘솔에서 인스턴스 생성 시 → Advanced details → Enable nested virtualization 항목을 체크합니다.
2026년 02월 23일 기준, 지원 인스턴스 타입은 C8i, M8i, R8i 만 해당됩니다.

Firecracker 설치

아래와 같은 방법으로 Firecracker 바이너리를 다운로드합니다.

$ ARCH="$(uname -m)"
$ release_url="https://github.com/firecracker-microvm/firecracker/releases"
$ latest=$(basename $(curl -fsSLI -o /dev/null -w  %{url_effective} ${release_url}/latest))
$ curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz \
    | tar -xz
$ mv release-${latest}-$(uname -m)/firecracker-${latest}-${ARCH} firecracker

바이너리가 정상적으로 다운로드 되었는지 확인합니다.

[root@ip-172-31-53-163 ~]# ./firecracker --version
Firecracker v1.14.1

Kernel 및 RootFS 준비

Firecracker microVM을 실행하기 위해서는 Linux kernel과 rootfs 이미지가 필요합니다.
아래와 같이 Firecracker CI에서 제공하는 테스트용 kernel과 rootfs를 다운로드합니다.

Amazon Linux 2023에서 squashfs 처리 및 iptables 관리를 위해 아래 패키지를 먼저 설치합니다.
# yum -y install squashfs-tools-4.5-3.amzn2023.0.2.x86_64
# yum -y install iptables-nft-1.8.8-3.amzn2023.0.2.x86_64

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest_version=$(basename $(curl -fsSLI -o /dev/null -w  %{url_effective} ${release_url}/latest))
CI_VERSION=${latest_version%.*}

# Kernel 다운로드
latest_kernel_key=$(curl "http://spec.ccfc.min.s3.amazonaws.com/?prefix=firecracker-ci/$CI_VERSION/$ARCH/vmlinux-&list-type=2" \
    | grep -oP "(?<=<Key>)(firecracker-ci/$CI_VERSION/$ARCH/vmlinux-[0-9]+\.[0-9]+\.[0-9]{1,3})(?=</Key>)" \
    | sort -V | tail -1)
wget "https://s3.amazonaws.com/spec.ccfc.min/${latest_kernel_key}"

# RootFS 다운로드 (squashfs → ext4 변환)
latest_ubuntu_key=$(curl "http://spec.ccfc.min.s3.amazonaws.com/?prefix=firecracker-ci/$CI_VERSION/$ARCH/ubuntu-&list-type=2" \
    | grep -oP "(?<=<Key>)(firecracker-ci/$CI_VERSION/$ARCH/ubuntu-[0-9]+\.[0-9]+\.squashfs)(?=</Key>)" \
    | sort -V | tail -1)
ubuntu_version=$(basename $latest_ubuntu_key .squashfs | grep -oE '[0-9]+\.[0-9]+')

wget -O ubuntu-$ubuntu_version.squashfs.upstream "https://s3.amazonaws.com/spec.ccfc.min/$latest_ubuntu_key"

# SSH 키 생성 및 rootfs에 삽입
unsquashfs ubuntu-$ubuntu_version.squashfs.upstream
ssh-keygen -f id_rsa -N ""
cp -v id_rsa.pub squashfs-root/root/.ssh/authorized_keys
mv -v id_rsa ./ubuntu-$ubuntu_version.id_rsa

# ext4 이미지 생성
sudo chown -R root:root squashfs-root
truncate -s 1G ubuntu-$ubuntu_version.ext4
sudo mkfs.ext4 -d squashfs-root -F ubuntu-$ubuntu_version.ext4

다운로드 완료 후 파일 목록을 확인합니다.

[root@ip-172-31-53-163 ~]# ls -l | egrep "ubuntu|id_rsa|vmlinux"
-rw-r--r--.  1 root root        607 Feb 23 12:47 id_rsa.pub
-rw-r--r--.  1 root root 1073741824 Feb 23 13:07 ubuntu-24.04.ext4
-rw-------.  1 root root       2655 Feb 23 12:47 ubuntu-24.04.id_rsa
-rw-r--r--.  1 root root  107810816 Nov 18 09:37 ubuntu-24.04.squashfs.upstream
-rw-r--r--.  1 root root   44278288 Nov 18 09:37 vmlinux-6.1.155

네트워크 설정

Firecracker는 TUN/TAP 네트워크 백엔드만 지원합니다.
microVM을 시작하기 전에 TAP 디바이스와 NAT를 먼저 설정합니다.

TAP_DEV="tap0"
TAP_IP="192.168.0.1"
MASK_SHORT="/24"

# TAP 디바이스 생성
sudo ip link del "$TAP_DEV" 2> /dev/null || true
sudo ip tuntap add dev "$TAP_DEV" mode tap
sudo ip addr add "${TAP_IP}${MASK_SHORT}" dev "$TAP_DEV"
sudo ip link set dev "$TAP_DEV" up

# iptables NAT 설정
sudo iptables -P FORWARD ACCEPT
HOST_IFACE=$(ip -j route list default | jq -r '.[0].dev')
sudo iptables -t nat -D POSTROUTING -o "$HOST_IFACE" -j MASQUERADE || true
sudo iptables -t nat -A POSTROUTING -o "$HOST_IFACE" -j MASQUERADE

vm_config.json 작성

API 방식 대신 config 파일을 사용하면 한 번에 microVM을 구성하고 시작할 수 있습니다.

{
  "boot-source": {
    "kernel_image_path": "vmlinux-6.1.155",
    "boot_args": "console=ttyS0 reboot=k panic=1"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "is_root_device": true,
      "is_read_only": false,
      "path_on_host": "ubuntu-24.04.ext4",
      "cache_type": "Unsafe",
      "io_engine": "Sync"
    }
  ],
  "machine-config": {
    "vcpu_count": 2,
    "mem_size_mib": 1024,
    "smt": false
  },
  "network-interfaces": [
    {
      "iface_id": "eth0",
      "host_dev_name": "tap0",
      "guest_mac": "06:00:c0:a8:00:02"
    }
  ]
}

Firecracker microVM 실행

--config-file 옵션으로 vm_config.json을 지정하여 microVM을 시작합니다.
--enable-pci 플래그는 VirtIO 장치를 PCI transport로 생성하여 높은 처리량과 낮은 지연을 제공합니다.

[root@ip-172-31-53-163 ~]# sudo ./firecracker \
    --api-sock /tmp/firecracker.socket \
    --config-file vm_config.json \
    --enable-pci
2026-02-23T13:00:50.965053032 [anonymous-instance:main] Running Firecracker v1.14.1
2026-02-23T13:00:50.965322102 [anonymous-instance:main] Listening on API socket ("/tmp/firecracker.socket").
2026-02-23T13:00:51.022688684 [anonymous-instance:main] pci: adding PCI segment: id=0x0, ...
2026-02-23T13:00:51.023549260 [anonymous-instance:main] Artificially kick devices
...
Successfully started microvm that was configured from one single json

동작 확인

microVM이 시작되면 Host에서 ping 및 SSH로 접속할 수 있습니다.

# Host에서 microVM ping 확인
[root@ip-172-31-53-163 ~]# ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=127 time=0.299 ms

# SSH 접속
[root@ip-172-31-53-163 ~]# ssh -i ubuntu-24.04.id_rsa root@192.168.0.2
Welcome to Ubuntu 24.04.3 LTS (GNU/Linux 6.1.155 x86_64)
...
root@ubuntu-fc-uvm:~#

microVM 내부에서 외부 네트워크 연결이 가능하도록 설정하고 외부 통신 여부 확인합니다.

# 기본 라우팅 및 DNS 설정
[root@ip-172-31-53-163 ~]# ssh -i ubuntu-24.04.id_rsa root@192.168.0.2 \
    "ip route add default via 192.168.0.1 dev eth0"
[root@ip-172-31-53-163 ~]# ssh -i ubuntu-24.04.id_rsa root@192.168.0.2 \
    "echo 'nameserver 8.8.8.8' > /etc/resolv.conf"

# 외부 통신 확인
root@ubuntu-fc-uvm:~# ping 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=3.19 ms

root@ubuntu-fc-uvm:~# curl naver.com
<html>
<head><title>301 Moved Permanently</title></head>
...

tmux 를 이용한 microVM 관리

Firecracker microVM을 실행하면 해당 터미널이 VM 콘솔로 점유됩니다.
tmux를 활용하면 별도 터미널 없이 백그라운드 세션으로 microVM을 관리할 수 있습니다.

# tmux 세션으로 microVM 시작
[root@ip-172-31-53-163 ~]# tmux new-session -d -s u24 \
    '/root/firecracker --api-sock /tmp/firecracker-u24.socket \
    --config-file vm_config.json --enable-pci'

# 실행 중인 세션 확인
[root@ip-172-31-53-163 ~]# tmux list-session
u24: 1 windows (created Mon Feb 23 13:31:49 2026)

# 세션에 접속 (VM 콘솔 진입)
[root@ip-172-31-53-163 ~]# tmux attach-session -t u24

참고

Firecracker 공식 사이트: https://firecracker-microvm.github.io/
Firecracker GitHub: https://github.com/firecracker-microvm/firecracker
Firecracker Getting Started: https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md
Firecracker RootFS & Kernel Setup: https://github.com/firecracker-microvm/firecracker/blob/main/docs/rootfs-and-kernel-setup.md
Firecracker Network Setup: https://github.com/firecracker-microvm/firecracker/blob/main/docs/network-setup.md

[AWS] Amazon Bedrock 과 Claude Code 연동 with code-server

Fri, 13 Feb 2026 00:00:00 +0900

Amazon Bedrock과 Claude Code 연동

이번 포스팅에서는 AWS EC2 인스턴스에서 Amazon Bedrock을 활용하여 Claude Code를 사용하는 방법에 대해 기록하도록 하겠습니다.

Claude Code는 Anthropic에서 제공하는 AI 코딩 어시스턴트로, Amazon Bedrock을 통해 AWS 환경에서 안전하게 사용할 수 있습니다. 이를 통해 Anthropic 계정 없이도 AWS IAM 역할 기반 인증으로 Claude Code를 활용할 수 있습니다.

테스트 환경

테스트 환경: Amazon Linux 2023.10.20260202
AWS Region: ap-northeast-2

IAM 역할 생성

Amazon Bedrock을 사용하기 위해 EC2 인스턴스에 연결할 IAM 역할을 생성합니다.

Trust Policy JSON 파일 생성

아래와 같이 Trust Policy JSON 파일을 생성합니다.

cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

IAM 역할 생성

아래 명령어를 통해 IAM 역할을 생성합니다.

aws iam create-role \
  --role-name Bedrock_Profile \
  --assume-role-policy-document file://trust-policy.json \
  --description "Bedrock_Profile"

관리형 정책 연결

Bedrock 및 MCP 서비스 사용을 위한 관리형 정책을 연결합니다.

aws iam attach-role-policy \
  --role-name Bedrock_Profile \
  --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess

aws iam attach-role-policy \
  --role-name Bedrock_Profile \
  --policy-arn arn:aws:iam::aws:policy/AWSMcpServiceActionsFullAccess

인스턴스 프로파일 생성

aws iam create-instance-profile \
  --instance-profile-name Bedrock_Profile

역할을 인스턴스 프로파일에 추가

aws iam add-role-to-instance-profile \
  --instance-profile-name Bedrock_Profile \
  --role-name Bedrock_Profile

위와 같이 IAM 역할 생성이 완료되면 EC2 인스턴스에 해당 인스턴스 프로파일을 연결합니다.

code-server 설치

브라우저에서 VS Code 환경을 사용하기 위해 code-server를 설치합니다.

[root@ip-172-31-45-222 ~]# curl -fsSL https://code-server.dev/install.sh | sh
Amazon Linux 2023.10.20260202
Installing v4.108.2 of the amd64 rpm package from GitHub.

+ mkdir -p ~/.cache/code-server
+ curl -#fL -o ~/.cache/code-server/code-server-4.108.2-amd64.rpm.incomplete -C - https://github.com/coder/code-server/releases/download/v4.108.2/code-server-4.108.2-amd64.rpm
######################################################################## 100.0%
+ mv ~/.cache/code-server/code-server-4.108.2-amd64.rpm.incomplete ~/.cache/code-server/code-server-4.108.2-amd64.rpm
+ rpm -U ~/.cache/code-server/code-server-4.108.2-amd64.rpm

rpm package has been installed.

To have systemd start code-server now and restart on boot:
  sudo systemctl enable --now code-server@$USER
Or, if you don't want/need a background service you can run:
  code-server

Deploy code-server for your team with Coder: https://github.com/coder/coder

systemd를 통해 code-server 서비스를 활성화합니다.

[root@ip-172-31-45-222 ~]# systemctl enable --now code-server@root
Created symlink /etc/systemd/system/default.target.wants/code-server@root.service → /usr/lib/systemd/system/code-server@.service.

~/.config/code-server/config.yaml 에서 bind-addr 를 0.0.0.0:80 과 같은 환경에 적합한 설정으로 변경하고 접속을 위한 password 를 확인합니다.

Claude Code 확장 플러그인 설치

위 단계에서 확인 된 정보를 통해 code-server 에 접속하고, code-server의 확장 플러그인에서 Claude Code를 설치합니다.

Amazon Bedrock 사용 설정

먼저 code-server 에 Claude Code가 Amazon Bedrock을 사용하도록 설정합니다. 로그인 프롬프트를 사용안하도록 아래와 같이 설정합니다.

code-server 설정에서 Claude Code가 CLI 모드로 동작하도록 설정하면 브라우저 환경에서도 Claude Code를 사용할 수 있습니다.

Cluade Code CLI 에서 Amazon Bedrock 을 사용하도록 아래 설정을 설정합니다.

[root@ip-172-31-45-222 ~]# cat ~/.claude/settings.json
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "ap-northeast-2"
  }
}

인스턴스 프로파일을 통해 Bedrock에서 Claude 모델이 사용 가능한지 확인합니다.

[root@ip-172-31-45-222 ~]# aws bedrock list-foundation-models | grep "anthropic.claude-opus-4-5-20251101-v1"
            "modelArn": "arn:aws:bedrock:ap-northeast-2::foundation-model/anthropic.claude-opus-4-5-20251101-v1:0",
            "modelId": "anthropic.claude-opus-4-5-20251101-v1:0",

Claude Code CLI 설치

터미널에서 Claude Code를 사용하기 위해 CLI를 설치합니다.

[root@ip-172-31-45-222 ~]# curl -fsSL https://claude.ai/install.sh | bash
Setting up Claude Code...

✔ Claude Code successfully installed!

  Version: 2.1.39

  Location: ~/.local/bin/claude

  Next: Run claude --help to get started

✅ Installation complete!

위와 같이 설치가 완료되면 Claude Code가 정상적으로 로드되는 것을 확인할 수 있습니다.

참고

Claude Code Third-Party Provider 설정: https://code.claude.com/docs/ko/vs-code#use-third-party-providers
code-server : https://github.com/coder/code-server

[AI] opencode - Amazon Bedrock과 연동하여 opencode 사용하기

Mon, 09 Feb 2026 00:00:00 +0900

opencode 란?

opencode는 터미널에서 사용할 수 있는 AI 기반 코딩 어시스턴트입니다.
다양한 AI 프로바이더를 지원하며, Amazon Bedrock과 연동하여 AWS 환경에서 손쉽게 AI 코딩 어시스턴트를 활용할 수 있습니다.

이번 포스팅에서는 opencode를 설치하고 Amazon Bedrock과 연동하여 사용하는 방법에 대해 기록하도록 하겠습니다.

공식 사이트: https://opencode.ai/

테스트 환경

테스트 환경: Amazon Linux 2023
AWS Region: ap-northeast-2

설치

아래와 같이 opencode를 설치합니다.

$ curl -fsSL https://opencode.ai/install | bash

Installing opencode version: 1.1.53
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■ 100%
Successfully added opencode to $PATH in /root/.bashrc

                                 ▄
█▀▀█ █▀▀█ █▀▀█ █▀▀▄ █▀▀▀ █▀▀█ █▀▀█ █▀▀█
█░░█ █░░█ █▀▀▀ █░░█ █░░░ █░░█ █░░█ █▀▀▀
▀▀▀▀ █▀▀▀ ▀▀▀▀ ▀  ▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀ ▀▀▀▀


OpenCode includes free models, to start:

cd <project>  # Open directory
opencode      # Run command

For more information visit https://opencode.ai/docs

위와 같이 설치가 완료된 것을 볼 수 있습니다.

Amazon Bedrock Provider 설정

AWS 자격 증명 확인

Amazon Bedrock을 사용하기 위해서는 AWS 자격 증명이 필요합니다.
저의 경우, EC2 인스턴스 프로파일(IAM Role)을 사용하여 인증하도록 설정하였습니다.

$ aws configure list
NAME       : VALUE                    : TYPE             : LOCATION
profile    : <not set>                : None             : None
access_key : ****************1234     : iam-role         :
secret_key : ****************5678     : iam-role         :
region     : ap-northeast-2           : imds             :

AWS Config 설정

아래와 같이 AWS config 파일을 구성합니다.

$ cat ~/.aws/config
[default]
region = ap-northeast-2
credential_source = Ec2InstanceMetadata
output = json

opencode 인증 설정

opencode에서 Amazon Bedrock을 IAM 인증으로 사용하기 위해 아래와 같이 auth.json 파일을 구성합니다.

$ cat ~/.local/share/opencode/auth.json
{
  "amazon-bedrock": {
    "type": "iam"
  }
}

opencode Provider 설정

IAM role 인증이 정상적으로 동작하도록 opencode 설정 파일을 아래와 같이 구성합니다.

$ cat ~/.config/opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "amazon-bedrock": {
      "options": {
        "region": "ap-northeast-2",
        "profile": "default"
      }
    }
  }
}

예제 이미지

인증 실패

위와 같이 IAM role 인증이 실패하는 경우가 발생하는 경우, auth.json 에 type 이 iam 으로 잘 설정이 되어 있는지 확인이 필요합니다.

인증 성공

위와 같이 API KEY 없이 IAM role 인증으로 Amazon Bedrock 사용이 가능한 것을 확인 할 수 있습니다.

참고

opencode 공식 문서: https://opencode.ai/docs
Amazon Bedrock 문서: https://docs.aws.amazon.com/bedrock/

[Linux] ISC DHCP 에서 Kea DHCP 로 마이그레이션 (Docker)

Mon, 09 Feb 2026 00:00:00 +0900

ISC DHCP 에서 Kea DHCP 로 마이그레이션 (Docker)

ISC DHCP EOL (End of Life)

ISC(Internet Systems Consortium) 는 2022년 말에 ISC DHCP (dhcpd) 의 유지보수 종료를 공식 발표하였습니다.
1995년부터 약 30년간 사용되어 온 ISC DHCP 는 더 이상 업데이트가 제공되지 않으며, 심각한 보안 취약점이 발견되더라도 패치가 제공되지 않습니다.

ISC 는 후속 DHCP 서버로 Kea DHCP 를 권장하고 있으며, 마이그레이션을 위한 도구인 KeaMA(Kea Migration Assistant) 와 공식 Docker 이미지도 제공하고 있습니다.

이번 포스팅에서는 기존 ISC DHCP 설정을 Docker 기반의 Kea DHCP 로 마이그레이션하는 방법에 대해 기록하도록 하겠습니다.

Kea DHCP 란?

Kea DHCP 는 ISC 에서 개발한 차세대 오픈소스 DHCP 서버입니다.
ISC DHCP 와 비교하여 아래와 같은 특징이 있습니다.

JSON 기반 설정 파일 형식
REST API 를 통한 원격 관리 지원 (kea-ctrl-agent)
데이터베이스 백엔드 지원 (MySQL, PostgreSQL)
멀티스레드 지원으로 높은 성능
DHCPv4, DHCPv6, Dynamic DNS 가 별도 프로세스로 분리
Hook 라이브러리를 통한 기능 확장
High Availability 지원

테스트 환경

테스트 환경: Amazon Linux 2
기존 DHCP 서버: ISC DHCP (dhcpd)
마이그레이션 대상: Kea DHCP (Docker Container)
Kea DHCP 이미지: docker.cloudsmith.io/isc/docker/kea-dhcp4

Step 1) 기존 ISC DHCP 설정 확인 및 백업

마이그레이션 전 반드시 기존 설정 파일과 Lease 파일을 백업합니다.

$ sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.backup
$ sudo cp /var/lib/dhcpd/dhcpd.leases /var/lib/dhcpd/dhcpd.leases.backup

기존 ISC DHCP 설정 파일을 확인합니다.

$ cat /etc/dhcp/dhcpd.conf
#
# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.example
#   see dhcpd.conf(5) man page
#

# Global configuration ####################################
option domain-name "chhanz.xyz";
default-lease-time 3600;
max-lease-time 7200;
authoritative;

# subnet configuration ####################################
subnet 10.100.200.0 netmask 255.255.255.0 {
option routers                  10.100.200.1;
option subnet-mask              255.255.255.0;
option domain-name-servers      1.1.1.1;
option time-offset              -18000;
range 10.100.200.100 10.100.200.200;
}

host pve1.chhanz.xyz {
hardware ethernet BC:24:11:F3:9F:00;
fixed-address 10.100.200.50;
}

host pve2.chhanz.xyz {
hardware ethernet BC:24:11:D7:AA:55;
fixed-address 10.100.200.51;
}

host pve3.chhanz.xyz {
hardware ethernet BC:24:11:C9:53:86;
fixed-address 10.100.200.52;
}

위와 같이 10.100.200.0/24 서브넷에 대한 DHCP 설정과 Proxmox 노드 3대에 대한 고정 IP 할당 설정이 되어 있습니다.

Step 2) Kea DHCP Docker 이미지 Pull

ISC 에서 제공하는 공식 Kea DHCP Docker 이미지를 가져옵니다.

[root@chhan-al2 ~]# docker pull docker.cloudsmith.io/isc/docker/kea-dhcp4
Using default tag: latest
latest: Pulling from isc/docker/kea-dhcp4
f637881d1138: Pull complete
d39b6622b069: Pull complete
307f453979a4: Pull complete
Digest: sha256:fdc40a60b0c392247d2411fb445b88b9d204d929ed4e8431a235edcefbe6a0bd
Status: Downloaded newer image for docker.cloudsmith.io/isc/docker/kea-dhcp4:latest
docker.cloudsmith.io/isc/docker/kea-dhcp4:latest

위와 같이 이미지가 정상적으로 다운로드 된 것을 확인 할 수 있습니다.

Step 3) KeaMA Docker 를 이용한 설정 변환

ISC 에서 제공하는 KeaMA(Kea Migration Assistant) Docker 이미지를 사용하여 기존 dhcpd.conf 를 Kea JSON 설정 파일로 자동 변환합니다.

먼저 KeaMA Docker 이미지를 가져옵니다.

[root@chhan-al2 ~]# docker pull docker.cloudsmith.io/isc/keama/keama:4.5.0
4.5.0: Pulling from isc/keama/keama
4693057ce236: Pull complete
9ad60c84bfbe: Pull complete
ce0f4c80e9b7: Pull complete
...생략
Digest: sha256:1ce87368b16d528a0f6c64b48e5316caaa21bccca99bfe7a3e9b368eaa6b1f1f
Status: Downloaded newer image for docker.cloudsmith.io/isc/keama/keama:4.5.0
docker.cloudsmith.io/isc/keama/keama:4.5.0

변환 결과를 저장할 디렉토리를 생성하고 권한을 설정합니다.

[root@chhan-al2 ~]# mkdir convert
[root@chhan-al2 ~]# chown 1000:1000 convert

아래와 같이 KeaMA 컨테이너를 실행하여 설정 파일을 변환합니다.

[root@chhan-al2 ~]# docker run -ti --rm \
	-v /etc/dhcp/dhcpd.conf:/home/keama/app/dhcpd.conf \
	-v /root/convert:/home/keama/app/convert \
	docker.cloudsmith.io/isc/keama/keama:4.5.0 \
	/home/keama/app/keama -4 -i /home/keama/app/dhcpd.conf -o /home/keama/app/convert/kea-dhcpd.conf
KEAMA 4.5.0
Reading isc-dhcp config (IPv4 mode) from /home/keama/app/dhcpd.conf, writing Kea JSON config to /home/keama/app/convert/kea-dhcpd.conf.
Started parsing new subnet declaration in line 15
Converted subnet 10.100.200.0/24 (lines 15 to 22)...
Parsing new host declaration at line 24
Converted host hw-address:bc:24:11:f3:9f:00 hostname:pve1.chhanz.xyz ip-address:10.100.200.50  (lines 24 to 27)
Parsing new host declaration at line 28
Converted host hw-address:bc:24:11:d7:aa:55 hostname:pve2.chhanz.xyz ip-address:10.100.200.51  (lines 28 to 31)
Parsing new host declaration at line 32
Converted host hw-address:bc:24:11:c9:53:86 hostname:pve3.chhanz.xyz ip-address:10.100.200.52  (lines 32 to 35)
Parsed 36 lines from the input (ISC DHCP config) /home/keama/app/dhcpd.conf file.
Wrote 1964 bytes to Kea JSON output /home/keama/app/convert/kea-dhcpd.conf file.

위와 같이 서브넷 1개와 호스트 예약 3개가 정상적으로 변환된 것을 확인 할 수 있습니다.

변환된 설정 파일 확인

[root@chhan-al2 ~]# cat convert/kea-dhcpd.conf
{
  #
  # DHCP Server Configuration file.
  #   see /usr/share/doc/dhcp*/dhcpd.conf.example
  #   see dhcpd.conf(5) man page
  #
  #
  # Global configuration ####################################
  #option domain-name "chhanz.xyz";
  #option domain-name-servers ns.chhanz.xyz;
  /// This configuration declares some subnets but has no interfaces-config
  /// Reference Kea #245
  "Dhcp4": {
    "valid-lifetime": 3600,
    "max-valid-lifetime": 7200,
    "authoritative": true,
    "subnet4": [
      # subnet configuration ####################################
      {
        "id": 1,
        "subnet": "10.100.200.0/24",
        "option-data": [
          {
            "space": "dhcp4",
            "name": "routers",
            "code": 3,
            "data": "10.100.200.1"
          },
          {
            "space": "dhcp4",
            "name": "subnet-mask",
            "code": 1,
            "data": "255.255.255.0"
          },
          {
            "space": "dhcp4",
            "name": "domain-name-servers",
            "code": 6,
            "data": "1.1.1.1"
          },
          {
            "space": "dhcp4",
            "name": "time-offset",
            "code": 2,
            "data": "-18000"
          }
        ],
        "pools": [
          {
            "pool": "10.100.200.100 - 10.100.200.200"
          }
        ]
      }
    ],
    "host-reservation-identifiers": [
      "hw-address"
    ],
    "reservation-mode": "global",
    "reservations": [
      {
        "hostname": "pve1.chhanz.xyz",
        "hw-address": "bc:24:11:f3:9f:00",
        "ip-address": "10.100.200.50"
      },
      {
        "hostname": "pve2.chhanz.xyz",
        "hw-address": "bc:24:11:d7:aa:55",
        "ip-address": "10.100.200.51"
      },
      {
        "hostname": "pve3.chhanz.xyz",
        "hw-address": "bc:24:11:c9:53:86",
        "ip-address": "10.100.200.52"
      }
    ]
  }
}

참고 : KeaMA 가 변환한 결과에는 주석(#, ///) 과 함께 interfaces-config, lease-database, loggers 등의 항목이 포함되어 있지 않습니다.
이 항목들은 수동으로 추가해야 하며, 주석도 제거해야 합니다. (Kea 는 표준 JSON 을 사용하므로 주석을 지원하지 않습니다)

Step 4) 변환된 설정 파일 수정

KeaMA 가 변환한 설정 파일은 그대로 사용할 수 없으며, 아래와 같은 수정이 필요합니다.

[root@chhan-al2 ~]# mkdir -p /etc/kea/config
[root@chhan-al2 ~]# mkdir -p /etc/kea/leases

변환된 파일을 복사하고 수정합니다.

[root@chhan-al2 ~]# cp convert/kea-dhcpd.conf /etc/kea/config/kea-dhcp4.conf
[root@chhan-al2 ~]# vi /etc/kea/config/kea-dhcp4.conf

아래와 같은 항목들을 수정합니다.

1) 주석 제거

Kea 는 표준 JSON 형식을 사용하므로 KeaMA 가 남긴 #, /// 주석을 모두 제거합니다.

2) `interfaces-config`, `control-socket`, `lease-database` 추가

KeaMA 변환 결과에는 포함되지 않는 항목들을 Dhcp4 블록 상단에 추가합니다.

    "interfaces-config": {
      "interfaces": [ "eth1" ],
      "dhcp-socket-type": "raw"
    },
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/var/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv",
      "lfc-interval": 3600
    },

3) `option-data` 에서 불필요한 필드 제거

KeaMA 가 생성한 space, code 필드는 생략 가능하므로 간결하게 정리합니다.
또한 subnet-mask 옵션은 Kea 가 서브넷 정의에서 자동으로 처리하므로 제거합니다.

변경 전 (KeaMA 변환 결과):

          {
            "space": "dhcp4",
            "name": "routers",
            "code": 3,
            "data": "10.100.200.1"
          },

변경 후:

          {
            "name": "routers",
            "data": "10.100.200.1"
          },

4) `reservation-mode` 를 신규 키워드로 변경

Kea 2.6 이상에서 reservation-mode 는 deprecated 되었습니다.
아래와 같이 reservations-global, reservations-in-subnet 으로 변경합니다.

변경 전 (KeaMA 변환 결과):

    "reservation-mode": "global",

변경 후:

    "reservations-global": true,
    "reservations-in-subnet": false,

5) `loggers` 추가

Docker 환경에서 docker logs 로 로그를 확인할 수 있도록 stdout 출력 설정을 추가합니다.

    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [
          {
            "output": "stdout",
            "flush": true
          }
        ],
        "severity": "INFO",
        "debuglevel": 0
      }
    ]

최종 설정 파일

위 수정 사항을 모두 반영한 최종 설정 파일은 아래와 같습니다.

[root@chhan-al2 ~]# cat /etc/kea/config/kea-dhcp4.conf
{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "eth1" ],
      "dhcp-socket-type": "raw"
    },
    "control-socket": {
      "socket-type": "unix",
      "socket-name": "/var/run/kea/kea4-ctrl-socket"
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv",
      "lfc-interval": 3600
    },
    "authoritative": true,
    "valid-lifetime": 3600,
    "max-valid-lifetime": 7200,
    "subnet4": [
      {
        "id": 1,
        "subnet": "10.100.200.0/24",
        "option-data": [
          {
            "name": "routers",
            "data": "10.100.200.1"
          },
          {
            "name": "domain-name-servers",
            "data": "1.1.1.1"
          },
          {
            "name": "time-offset",
            "data": "-18000"
          }
        ],
        "pools": [
          {
            "pool": "10.100.200.100 - 10.100.200.200"
          }
        ]
      }
    ],
    "host-reservation-identifiers": [
      "hw-address"
    ],
    "reservations-global": true,
    "reservations-in-subnet": false,
    "reservations": [
      {
        "hostname": "pve1.chhanz.xyz",
        "hw-address": "bc:24:11:f3:9f:00",
        "ip-address": "10.100.200.50"
      },
      {
        "hostname": "pve2.chhanz.xyz",
        "hw-address": "bc:24:11:d7:aa:55",
        "ip-address": "10.100.200.51"
      },
      {
        "hostname": "pve3.chhanz.xyz",
        "hw-address": "bc:24:11:c9:53:86",
        "ip-address": "10.100.200.52"
      }
    ],
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output-options": [
          {
            "output": "stdout",
            "flush": true
          }
        ],
        "severity": "INFO",
        "debuglevel": 0
      }
    ]
  }
}

ISC DHCP 와 Kea DHCP 설정 비교

항목	ISC DHCP (dhcpd.conf)	Kea DHCP (kea-dhcp4.conf)
설정 형식	자체 문법	JSON
Subnet 선언	`subnet 10.100.200.0 netmask 255.255.255.0`	`"subnet": "10.100.200.0/24"`
IP 범위	`range 10.100.200.100 10.100.200.200;`	`"pool": "10.100.200.100 - 10.100.200.200"`
고정 IP 할당	`host pve1 { hardware ethernet ...; fixed-address ...; }`	`"reservations": [{"hw-address": "...", "ip-address": "..."}]`
옵션 설정	`option routers 10.100.200.1;`	`"option-data": [{"name": "routers", "data": "10.100.200.1"}]`
Lease 저장	`/var/lib/dhcpd/dhcpd.leases`	`/var/lib/kea/kea-leases4.csv` 또는 DB
서비스명	`dhcpd`	`kea-dhcp4`

Step 5) 설정 파일 검증

컨테이너를 실행하기 전에 설정 파일의 문법을 검증합니다.

[root@chhan-al2 ~]# docker run --rm \
    -v /etc/kea/config:/etc/kea \
    docker.cloudsmith.io/isc/docker/kea-dhcp4 \
    kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
2026-02-09 06:04:14.319 WARN  [kea-dhcp4.dhcpsrv/1.140164228530912]
DHCPSRV_MT_DISABLED_QUEUE_CONTROL disabling dhcp queue control when multi-threading is enabled.
2026-02-09 06:04:14.319 WARN  [kea-dhcp4.dhcp4/1.140164228530912]
DHCP4_RESERVATIONS_LOOKUP_FIRST_ENABLED Multi-threading is enabled and host reservations lookup is always performed first.
2026-02-09 06:04:14.319 INFO  [kea-dhcp4.dhcpsrv/1.140164228530912]
DHCPSRV_CFGMGR_NEW_SUBNET4 a new subnet has been added to configuration: 10.100.200.0/24 with params: valid-lifetime=3600
2026-02-09 06:04:14.319 INFO  [kea-dhcp4.dhcpsrv/1.140164228530912]
DHCPSRV_CFGMGR_SOCKET_TYPE_SELECT using socket type raw
...생략

위와 같이 DHCPSRV_CFGMGR_NEW_SUBNET4 로그에서 10.100.200.0/24 서브넷이 정상적으로 추가된 것을 확인 할 수 있습니다.
ERROR 없이 출력이 완료되면 설정 파일에 문제가 없는 것입니다.

Step 6) 기존 ISC DHCP 서비스 중지

Kea DHCP 컨테이너를 시작하기 전에 기존 ISC DHCP 서비스를 중지합니다.
동일한 포트(UDP 67/68) 를 사용하기 때문에 반드시 기존 서비스를 먼저 중지해야 합니다.

[root@chhan-al2 ~]# systemctl stop dhcpd
[root@chhan-al2 ~]# systemctl disable dhcpd
Removed symlink /etc/systemd/system/multi-user.target.wants/dhcpd.service.

Step 7) Kea DHCP 컨테이너 실행

아래와 같이 Kea DHCP 컨테이너를 실행합니다.
DHCP 서버는 브로드캐스트 패킷을 수신해야 하므로 --net host 옵션을 사용합니다.

[root@chhan-al2 ~]# docker run -d \
    --name kea-dhcp4 \
    --restart=always \
    --net host \
    -v /etc/kea/config:/etc/kea \
    -v /etc/kea/leases:/var/lib/kea \
    docker.cloudsmith.io/isc/docker/kea-dhcp4

컨테이너 실행 상태를 확인합니다.

[root@chhan-al2 ~]# docker ps
CONTAINER ID   IMAGE                                          COMMAND                  CREATED         STATUS         PORTS   NAMES
a1b2c3d4e5f6   docker.cloudsmith.io/isc/docker/kea-dhcp4      "/usr/sbin/kea-dhcp4…"   5 seconds ago   Up 3 seconds           kea-dhcp4

위와 같이 Kea DHCP 컨테이너가 정상적으로 실행 중인 것을 확인 할 수 있습니다.

Step 8) 동작 확인

로그 확인

아래와 같이 컨테이너 로그를 통해 Kea DHCP 서버의 동작 상태를 확인합니다.

[root@chhan-al2 ~]# docker logs -f kea-dhcp4
2026-02-09 06:13:00.211 INFO  [kea-dhcp4.dhcp4/1.140589193589472]
DHCP4_STARTING Kea DHCPv4 server version 3.0.2 (stable) starting
...생략
2026-02-09 06:13:00.213 INFO  [kea-dhcp4.dhcpsrv/1.140589193589472]
DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth1
2026-02-09 06:13:00.213 INFO  [kea-dhcp4.dhcp4/1.140589193589472]
DHCP4_CONFIG_COMPLETE DHCPv4 server has completed configuration: added IPv4 subnets: 1; DDNS: disabled
...생략
2026-02-09 06:13:00.251 INFO  [kea-dhcp4.dhcp4/1.140589193589472]
DHCP4_MULTI_THREADING_INFO enabled: yes, number of threads: 2, queue size: 64
2026-02-09 06:13:00.251 INFO  [kea-dhcp4.dhcp4/1.140589193589472]
DHCP4_STARTED Kea DHCPv4 server version 3.0.2 started

위와 같이 Kea DHCP 서버 버전 3.0.2 가 정상적으로 시작된 것을 확인 할 수 있습니다.

DHCP 클라이언트가 IP 를 요청하면 아래와 같은 로그를 확인 할 수 있습니다.

2026-02-09 06:13:12.733 INFO  [kea-dhcp4.packets/1.140589172878136]
DHCP4_PACKET_RECEIVED [hwtype=1 bc:24:11:27:12:8c], cid=[no info], tid=0x9ae58e2a:
DHCPDISCOVER (type 1) received from 0.0.0.0 to 255.255.255.255 on interface eth1
2026-02-09 06:13:12.733 INFO  [kea-dhcp4.leases/1.140589172878136]
DHCP4_LEASE_OFFER [hwtype=1 bc:24:11:27:12:8c], cid=[no info], tid=0x9ae58e2a:
lease 10.100.200.100 will be offered
...생략
2026-02-09 06:13:12.734 INFO  [kea-dhcp4.leases/1.140589173021496]
DHCP4_LEASE_ALLOC [hwtype=1 bc:24:11:27:12:8c], cid=[no info], tid=0x9ae58e2a:
lease 10.100.200.100 has been allocated for 3600 seconds
2026-02-09 06:13:12.734 INFO  [kea-dhcp4.packets/1.140589173021496]
DHCP4_PACKET_SEND [hwtype=1 bc:24:11:27:12:8c], cid=[no info], tid=0x9ae58e2a:
trying to send packet DHCPACK (type 5) from 10.100.200.1:67 to 10.100.200.100:68 on interface eth1

위와 같이 DHCPDISCOVER → DHCPOFFER → DHCPREQUEST → DHCPACK 과정을 거쳐 10.100.200.100 IP 가 정상적으로 할당되는 것을 확인 할 수 있습니다.

Lease 파일 확인

[root@chhan-al2 ~]# cat /etc/kea/leases/kea-leases4.csv
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
10.100.200.100,bc:24:11:27:12:8c,,3600,1770621192,1,0,0,rhel7,0,,0

위와 같이 DHCP IP 가 정상적으로 할당되는 것을 확인 할 수 있습니다.

설정 변경 시 컨테이너 재시작

설정 파일을 수정한 후에는 아래와 같이 컨테이너를 재시작합니다.

[root@chhan-al2 ~]# vi /etc/kea/config/kea-dhcp4.conf
[root@chhan-al2 ~]# docker restart kea-dhcp4
kea-dhcp4

참고

ISC DHCP 마이그레이션 가이드: https://www.isc.org/dhcp_migration/
KeaMA 웹 인터페이스: https://dhcp.isc.org/
KeaMA Docker 이미지: https://cloudsmith.io/~isc/repos/keama/packages/
Kea DHCP 공식 문서: https://kea.readthedocs.io/
Kea Docker 이미지: https://cloudsmith.io/~isc/repos/docker/packages/
KeaMA 매뉴얼: https://kb.isc.org/docs/kea-migration-assistant
이전 포스팅 - DHCP 서버 구성: https://tech.chhanz.xyz/linux/2020/11/17/configuration-dhcp/

[OpenWebUI] SQLite to PostgreSQL Migration

Mon, 02 Feb 2026 00:00:00 +0900

Open WebUI - SQLite to PostgreSQL Migration

Open WebUI 란?

Open WebUI 는 다양한 LLM(Large Language Model) 을 웹 브라우저에서 편리하게 사용할 수 있도록 해주는 오픈소스 웹 인터페이스입니다.
기본적으로 데이터 저장소로 SQLite 를 사용하지만, 다수의 사용자가 동시에 접근하는 환경에서는 SQLite 의 동시 접근성 한계로 인해 데이터베이스 잠금(lock) 이슈가 발생할 수 있습니다.

이번 포스팅에서는 이러한 SQLite 의 한계를 해결하기 위해 Open WebUI 의 데이터베이스를 PostgreSQL 로 마이그레이션하는 방법에 대해 기록하도록 하겠습니다.

테스트 환경

항목	내용
OS	Amazon Linux 2023
Open WebUI	`ghcr.io/open-webui/open-webui:main`
PostgreSQL	`postgres:18-alpine` (Docker)
Migration Tool	open-webui-postgres-migration

사전 준비 - PostgreSQL 구성

먼저 마이그레이션 대상이 될 PostgreSQL 을 Docker Compose 로 구성합니다.
아래와 같이 compose.yaml 파일을 작성합니다.

$ cat pgsql/compose.yaml
services:

  db:
    image: postgres:18-alpine
    restart: always
    shm_size: 512mb
    volumes:
      - /root/data/pgsql:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: postgres
    ports:
      - "5432:5432"

아래 명령어를 통해 PostgreSQL 컨테이너를 시작합니다.

$ cd pgsql && docker compose up -d

Step 1) PostgreSQL 데이터베이스 초기화 (Bootstrap)

Open WebUI 가 사용하는 테이블 스키마를 PostgreSQL 에 생성하기 위해, 임시로 Open WebUI 를 PostgreSQL 에 연결하여 구동합니다.
이 과정을 통해 Open WebUI 가 자동으로 필요한 테이블을 생성합니다.

$ cat open-webui-imsi.sh
#!/bin/bash

docker run -d \
    --restart=always \
    -e DATABASE_URL=postgres://'postgres':'passwd'@<host ip>:5432/postgres \
    --name open-webui-imsi \
    ghcr.io/open-webui/open-webui:main

위 스크립트를 실행하여 임시 컨테이너를 구동합니다.

$ bash open-webui-imsi.sh

테이블 생성이 완료되면 임시 컨테이너를 중지하고 삭제합니다.

$ docker stop open-webui-imsi && docker rm open-webui-imsi

Step 2) 기존 SQLite 데이터베이스 백업

마이그레이션 진행 전 반드시 기존 SQLite 데이터베이스를 백업합니다.

$ cp /root/data/webui.db /root/data/webui.db.backup

또한 기존 Open WebUI 컨테이너를 중지하여 데이터 정합성을 확보합니다.

$ docker stop open-webui

Step 3) 마이그레이션 도구 설치

마이그레이션에는 open-webui-postgres-migration 도구를 사용합니다.
아래와 같이 도구를 설치합니다.

$ git clone https://github.com/taylorwilsdon/open-webui-postgres-migration.git
$ cd open-webui-postgres-migration
$ python -m venv venv
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt

Step 4) 마이그레이션 실행

Foreign Key Check 에러 해결

마이그레이션 도구를 실행하면 SQLite 데이터베이스의 무결성 검사(Integrity Check) 를 수행합니다.
이 과정에서 아래와 같이 Foreign Key Check 에러가 발생할 수 있습니다.

(venv) $ python migrate.py
╭──────────────────────────────────────────────────────────────────────╮
│ SQLite Database Configuration                                        │
╰──────────────────────────────────────────────────────────────────────╯
SQLite database path (webui.db): /root/data/webui.db

✓ Valid SQLite database (version 3.40.0)
╭──────────────────────────────────────────────────────────────────────╮
│ Running SQLite Database Integrity Check                               │
╰──────────────────────────────────────────────────────────────────────╯
Failed Foreign Key Check: [('chat_file', 1, 'chat', 1), ('chat_file', 2, 'chat', 1),
('chat_file', 3, 'chat', 1), ('chat_file', 4, 'chat', 1), ('chat_file', 5, 'chat', 1),
('knowledge_file', 1, 'knowledge', 1), ('knowledge_file', 2, 'knowledge', 1),
...생략
Aborting migration due to database integrity issues

이 에러는 chat_file 및 knowledge_file 테이블에 부모 테이블(chat, knowledge) 에 존재하지 않는 고아 레코드(orphaned records) 가 남아 있어 발생합니다.

아래와 같이 SQLite 에서 고아 레코드를 정리하여 해결합니다.

참고 : https://github.com/taylorwilsdon/open-webui-postgres-migration/issues/19

$ sqlite3 /root/data/webui.db

-- Remove orphaned chat_file records
DELETE FROM chat_file WHERE chat_id NOT IN (SELECT id FROM chat);

-- Remove orphaned knowledge_file records
DELETE FROM knowledge_file WHERE knowledge_id NOT IN (SELECT id FROM knowledge);

마이그레이션 수행

고아 레코드 정리 후 다시 마이그레이션 도구를 실행합니다.

(venv) $ python migrate.py
╭──────────────────────────────────────────────────────────────────────╮
│ SQLite Database Configuration                                        │
╰──────────────────────────────────────────────────────────────────────╯
SQLite database path (webui.db): /root/data/webui.db

✓ Valid SQLite database (version 3.40.0)
╭──────────────────────────────────────────────────────────────────────╮
│ Running SQLite Database Integrity Check                               │
╰──────────────────────────────────────────────────────────────────────╯
┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Check Type        ┃ Status    ┃
┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Integrity Check   │ ✅ Passed │
│ Quick Check       │ ✅ Passed │
│ Foreign Key Check │ ✅ Passed │
└───────────────────┴───────────┘
╭──────────────────────────────────────────────────────────────────────╮
│ PostgreSQL Connection Configuration                                  │
╰──────────────────────────────────────────────────────────────────────╯
PostgreSQL host (localhost): <host ip>
PostgreSQL port (5432):
Database name (postgres):
Username (postgres):
Password:

Connection Details:
 host:      <host ip>
 port:      5432
 dbname:    postgres
 user:      postgres
 password:  ********

✓ Database connection successful!
✓ PostgreSQL database has been properly bootstrapped!

Proceed with these settings? [y/n]: y
╭──────────────────────────────────────────────────────────────────────╮
│ Batch Size Configuration                                             │
╰──────────────────────────────────────────────────────────────────────╯
The batch size determines how many records are processed at once.
A larger batch size may be faster but uses more memory.
Recommended range: 100-5000

Batch size (500):
╭──────────────────────────────────────────────────────────────────────╮
│ Starting Migration Process                                           │
╰──────────────────────────────────────────────────────────────────────╯
  Migrating auth...             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating chat...             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating document...         ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating prompt...           ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating memory...           ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating model...            ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating tool...             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating function...         ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating config...           ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating tag...              ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating file...             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating user...             ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating knowledge...        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating knowledge_file...   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
  Migrating chat_file...        ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100%
...생략

위와 같이 모든 테이블의 마이그레이션이 정상적으로 완료된 것을 확인 할 수 있습니다.

Step 5) Open WebUI 설정 변경

마이그레이션이 완료되었으므로, Open WebUI 가 PostgreSQL 을 사용하도록 설정을 변경하여 컨테이너를 재시작합니다.

$ cat open-webui.sh
#!/bin/bash

docker run -d -p 80:8080 \
    -v /root/data:/app/backend/data \
    --restart=always \
    -e WEBUI_SECRET_KEY='1234567890abcdefg' \
    -e DATABASE_URL=postgres://'postgres':'password'@<host ip>:5432/postgres \
    --name open-webui \
    ghcr.io/open-webui/open-webui:main

$ bash open-webui.sh

위와 같이 DATABASE_URL 환경 변수를 PostgreSQL 연결 문자열로 설정하여 Open WebUI 를 시작합니다.

마무리

위와 같은 방법으로 Open WebUI 의 데이터베이스를 SQLite 에서 PostgreSQL 로 마이그레이션이 가능합니다.
PostgreSQL 로 전환 후에는 다수의 사용자가 동시에 접근하는 환경에서도 데이터베이스 잠금 이슈 없이 안정적으로 서비스를 운영할 수 있습니다.

참고

Open WebUI GitHub : https://github.com/open-webui/open-webui
Migration Tool : https://github.com/taylorwilsdon/open-webui-postgres-migration
Foreign Key Check Issue : https://github.com/taylorwilsdon/open-webui-postgres-migration/issues/19
WEBUI_SECRET_KEY : https://docs.openwebui.com/getting-started/env-configuration/#webui_secret_key

[Container] Finch - Docker Desktop 대체 오픈소스 컨테이너 도구 사용법

Tue, 20 Jan 2026 00:00:00 +0900

[Container] Finch - Docker Desktop 대체 오픈소스 컨테이너 도구 사용법

Finch 란?

Finch는 AWS에서 개발한 오픈소스 컨테이너 개발 도구입니다. macOS / Windows / Linux 환경에서 Docker Desktop의 대안으로 사용할 수 있으며, containerd와 nerdctl을 기반으로 동작합니다. 라이선스 비용 없이 로컬 환경에서 컨테이너 이미지를 빌드, 실행, 배포할 수 있어 개인 개발자나 소규모 팀에게 유용한 도구입니다.

이번 포스팅에서는 Finch의 기본 사용법에 대해 작성하도록 하겠습니다.

테스트 환경

테스트 환경: macOS (Apple Silicon / ARM64)
Finch Server Version: v2.1.3
VM Kernel: 6.12.53-69.119.amzn2023.aarch64
VM Operating System: Fedora Linux 42 (Cloud Edition)

Finch VM 시작

Finch는 Linux 컨테이너를 실행하기 위해 내부적으로 경량 VM(Lima)을 사용합니다. VM이 중지된 상태에서 명령어를 실행하면 아래와 같은 에러가 발생합니다.

$ finch stats
FATA[0000] instance "finch" is stopped, run `finch vm start` to start the instance

아래와 같이 VM을 시작합니다.

$ finch vm start
INFO[0000] Starting existing Finch virtual machine...
INFO[0037] Finch virtual machine started successfully

위와 같이 Finch VM이 정상적으로 시작된 것을 확인 할 수 있습니다.

컨테이너 이미지 Pull

아래와 같이 Docker Hub에서 httpd 이미지를 가져옵니다.

$ finch pull httpd
docker.io/library/httpd:latest:                                                   resolved       |++++++++++++++++++++++++++++++++++++++|
index-sha256:dd178595edd6d4f49296f62f9587238db2cd1045adfff6fccc15a6c4d08f5d2e:    done           |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:d455e832e73abe8385397a4942fbb118a0ad7bdc37a5c695c2bce15f88bd8c5e: done           |++++++++++++++++++++++++++++++++++++++|
config-sha256:3bd0a578c1bd6b6cb48eaddd1c8daaba6f1362fc792a4a1f9618275b20ed5314:   done           |++++++++++++++++++++++++++++++++++++++|
elapsed: 1.5 s                                                                    total:   0.0 B (0.0 B/s)

컨테이너 실행

아래와 같이 httpd 컨테이너를 백그라운드로 실행합니다.

$ finch container run --name my-httpd -d -p 8080:80 httpd
38f1c0971d8b95cfabb27fb051979a75bafcf7ed0ac833dc69d03de2649cb620

실행 중인 컨테이너를 확인합니다.

$ finch ps -a
CONTAINER ID    IMAGE                             COMMAND               CREATED           STATUS    PORTS                   NAMES
38f1c0971d8b    docker.io/library/httpd:latest    "httpd-foreground"    11 seconds ago    Up        0.0.0.0:8080->80/tcp    my-httpd

위와 같이 my-httpd 컨테이너가 정상적으로 실행 중인 것을 확인 할 수 있습니다.

컨테이너 동작 확인

아래와 같이 curl 명령어로 웹 서버가 정상 동작하는지 테스트합니다.

$ curl localhost:8080
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>It works! Apache httpd</title>
</head>
<body>
<p>It works!</p>
</body>
</html>

위와 같이 Apache httpd 웹 서버가 정상적으로 응답하는 것을 확인 할 수 있습니다.

컨테이너 이미지 빌드

이번 섹션에서는 Finch를 사용하여 직접 컨테이너 이미지를 빌드하는 방법에 대해 기록하도록 하겠습니다.

샘플 애플리케이션 준비

간단한 Python Flask 웹 애플리케이션을 예제로 사용합니다. 아래와 같이 프로젝트 디렉토리를 생성하고 파일을 준비합니다.

$ mkdir finch-demo && cd finch-demo

아래와 같이 Flask 애플리케이션 파일을 작성합니다.

$ vi app.py
from flask import Flask
import os

app = Flask(__name__)

@app.route('/')
def hello():
    hostname = os.uname().nodename
    return f'''
<!DOCTYPE html>
<html>
<head>
    <title>Finch Demo App</title>
</head>
<body>
    <h1>Hello from Finch!</h1>
    <p>Container Hostname: {hostname}</p>
    <p>Built with Finch - Open Source Container Tool</p>
</body>
</html>
'''

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

다음으로 의존성 파일을 작성합니다.

$ vi requirements.txt
flask==3.0.0

Containerfile 작성

아래와 같이 Containerfile을 작성합니다. Finch는 Dockerfile과 Containerfile 모두 지원합니다.

$ vi Containerfile
FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

프로젝트 구조는 아래와 같습니다.

$ ls -l
total 24
-rw-r--r--@ 1 cheolhee  staff  434 Jan 20 13:38 app.py
-rw-r--r--@ 1 cheolhee  staff  166 Jan 20 13:38 Containerfile
-rw-r--r--@ 1 cheolhee  staff   13 Jan 20 13:38 requirements.txt

이미지 빌드

아래와 같이 finch build 명령어를 사용하여 이미지를 빌드합니다.

$ finch build -t finch-demo:v1.0 .
[+] Building 9.0s (10/10) FINISHED
 => [internal] load build definition from Containerfile                                                                                          0.0s
 => => transferring dockerfile: 208B                                                                                                             0.0s
 => [internal] load metadata for docker.io/library/python:3.11-slim                                                                              2.7s
 => [internal] load .dockerignore                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                  0.0s
 => [1/5] FROM docker.io/library/python:3.11-slim@sha256:5be45dbade29bebd6886af6b438fd7e0b4eb7b611f39ba62b430263f82de36d2                        3.5s
 => => resolve docker.io/library/python:3.11-slim@sha256:5be45dbade29bebd6886af6b438fd7e0b4eb7b611f39ba62b430263f82de36d2                        0.0s
 => => sha256:518abaec573aacfc293edf9e19b26274fc7ee5d3448e80f90eecdae829acd7e7 249B / 249B                                                       0.5s
 => => sha256:068949646e5ac13b4b3f99bca3f1249ca853fc5bd30512ea7d447af7a649b011 14.31MB / 14.31MB                                                 1.8s
 => => sha256:d67bedf18e0abdffd887db745e6a45c9173ae1b93fd7fac8d7a8c6b2e5346455 1.27MB / 1.27MB                                                   1.7s
 => => sha256:d637807aba98f742a62ad9b0146579ceb0297a3c831f56b2361664b7f5fbc75b 30.13MB / 30.13MB                                                 2.8s
 => => extracting sha256:d637807aba98f742a62ad9b0146579ceb0297a3c831f56b2361664b7f5fbc75b                                                        0.4s
 => => extracting sha256:d67bedf18e0abdffd887db745e6a45c9173ae1b93fd7fac8d7a8c6b2e5346455                                                        0.0s
 => => extracting sha256:068949646e5ac13b4b3f99bca3f1249ca853fc5bd30512ea7d447af7a649b011                                                        0.2s
 => => extracting sha256:518abaec573aacfc293edf9e19b26274fc7ee5d3448e80f90eecdae829acd7e7                                                        0.0s
 => [internal] load build context                                                                                                                0.0s
 => => transferring context: 527B                                                                                                                0.0s
 => [2/5] WORKDIR /app                                                                                                                           0.1s
 => [3/5] COPY requirements.txt .                                                                                                                0.0s
 => [4/5] RUN pip install --no-cache-dir -r requirements.txt                                                                                     2.0s
 => [5/5] COPY app.py .                                                                                                                          0.0s
 => exporting to image                                                                                                                           0.6s
 => => exporting layers                                                                                                                          0.5s
 => => exporting manifest sha256:e045216b9a5483b26e5c9b16630913ce1c2b35b279158af02bae3d0a0080176d                                                0.0s
 => => exporting config sha256:8c89f20c21344cbd96815ff7340b7e8f52784e4ab67b09b6239efd3c40fcb443                                                  0.0s
 => => naming to docker.io/library/finch-demo:v1.0                                                                                               0.0s
 => => unpacking to docker.io/library/finch-demo:v1.0                                                                                            0.1s

위와 같이 이미지 빌드가 완료된 것을 확인 할 수 있습니다.

빌드된 이미지 확인

아래와 같이 빌드된 이미지를 확인합니다.

$ finch images
REPOSITORY       TAG       IMAGE ID        CREATED           PLATFORM       SIZE       BLOB SIZE
finch-demo       v1.0      e045216b9a54    11 seconds ago    linux/arm64    184.4MB    51.4MB
jekyll/jekyll    latest    400b8d1569f1    21 hours ago      linux/amd64    907.3MB    322.1MB

위와 같이 finch-demo:v1.0 이미지가 정상적으로 빌드된 것을 확인 할 수 있습니다.

빌드한 이미지로 컨테이너 실행

아래와 같이 빌드한 이미지를 사용하여 컨테이너를 실행합니다.

$ finch run --name demo-app -d -p 5000:5000 finch-demo:v1.0
acdbff628decca37867d875494c9fd9615df724ded3205bd72d8377761905652

실행 중인 컨테이너를 확인합니다.

$ finch ps
CONTAINER ID    IMAGE                                COMMAND            CREATED          STATUS    PORTS                     NAMES
acdbff628dec    docker.io/library/finch-demo:v1.0    "python app.py"    9 seconds ago    Up        0.0.0.0:5000->5000/tcp    demo-app

동작 확인

아래와 같이 curl 명령어로 애플리케이션이 정상 동작하는지 확인합니다.

$ curl localhost:5000
<!DOCTYPE html>
<html>
<head>
    <title>Finch Demo App</title>
</head>
<body>
    <h1>Hello from Finch!</h1>
    <p>Container Hostname: acdbff628dec</p>
    <p>Built with Finch - Open Source Container Tool</p>
</body>
</html>

위와 같이 Finch로 빌드한 Flask 애플리케이션이 정상적으로 동작하는 것을 확인 할 수 있습니다.

컨테이너 관리 명령어

컨테이너 삭제

아래 명령어로 실행 중인 컨테이너를 강제 삭제할 수 있습니다.

$ finch container rm -f my-httpd
my-httpd

컨테이너 재시작

$ finch container restart blog
blog

컨테이너 로그 확인

-f 옵션을 사용하여 실시간 로그를 확인할 수 있습니다.

$ finch logs -f blog
Fetching gem metadata from https://rubygems.org/..........
Using bundler 2.3.25
Fetching public_suffix 5.0.3
Using colorator 1.1.0
Fetching concurrent-ruby 1.2.2
Installing public_suffix 5.0.3
Installing concurrent-ruby 1.2.2
Using eventmachine 1.2.7
....

이미지 관리

이미지 목록 확인

$ finch images
REPOSITORY    TAG       IMAGE ID        CREATED          PLATFORM       SIZE       BLOB SIZE
httpd         latest    dd178595edd6    2 minutes ago    linux/arm64    159.2MB    45.5MB

이미지 삭제

$ finch rmi dd178595edd6
Untagged: docker.io/library/httpd:latest@sha256:dd178595edd6d4f49296f62f9587238db2cd1045adfff6fccc15a6c4d08f5d2e
Deleted: sha256:37127a0fa4c7aa2f661f5d88d5e0b6194640848159d7a56c5c0b7afb445aa6fe
Deleted: sha256:e2be4c959abac10d36314c871065c3ddeb6b1b76cfebd5bce06a05a5dde1d68e
Deleted: sha256:5f70bf18a086007016e948b04aed3b82103a36bea41755b6cddfaf10ace3c6ef
Deleted: sha256:0477352d89d2859cc39547b0769fc84ad80cb2fa92caca62531acef033043ea8
Deleted: sha256:f025424b0a4653e7ecc10f1d1f8a35458ae674db8c1f01df825a9b74808621b3
Deleted: sha256:3958c2a874d9078e3c5663b3a82cd3d9b87f2c19c9bdf2f720f6b9902c475eb2

Finch Compose를 이용한 멀티 컨테이너 실행

Finch는 Docker Compose와 호환되는 finch compose 명령어를 제공합니다. 이번 섹션에서는 Finch Compose를 사용하여 여러 컨테이너를 함께 실행하는 방법에 대해 기록하도록 하겠습니다.

샘플 애플리케이션 준비

Flask 웹 애플리케이션과 Redis를 연동하는 간단한 방문자 카운터 예제를 사용합니다. 아래와 같이 프로젝트 디렉토리를 생성합니다.

$ mkdir finch-demo && cd finch-demo

아래와 같이 Flask 애플리케이션 파일을 작성합니다.

$ vi app.py
from flask import Flask
import redis
import os

app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)

def get_hit_count():
    retries = 5
    while True:
        try:
            return cache.incr('hits')
        except redis.exceptions.ConnectionError as exc:
            if retries == 0:
                raise exc
            retries -= 1

@app.route('/')
def hello():
    count = get_hit_count()
    hostname = os.uname().nodename
    return f'''
<!DOCTYPE html>
<html>
<head>
    <title>Finch Compose Demo</title>
</head>
<body>
    <h1>Hello from Finch Compose!</h1>
    <p>Container Hostname: {hostname}</p>
    <p>Visit Count: {count}</p>
</body>
</html>
'''

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

다음으로 의존성 파일을 작성합니다.

$ vi requirements.txt
flask==3.0.0
redis==5.0.1

Containerfile 작성

아래와 같이 Containerfile을 작성합니다.

$ vi Containerfile
FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

Compose 파일 작성

아래와 같이 compose.yaml 파일을 작성합니다. Finch는 Docker Compose 파일 형식과 호환됩니다.

$ vi compose.yaml
services:
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - redis
    restart: unless-stopped

  redis:
    image: redis:alpine
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  redis-data:

프로젝트 구조는 아래와 같습니다.

$ ls -l
total 32
-rw-r--r--@ 1 cheolhee  staff  748 Jan 20 13:43 app.py
-rw-r--r--@ 1 cheolhee  staff  243 Jan 20 13:44 compose.yaml
-rw-r--r--@ 1 cheolhee  staff  166 Jan 20 13:44 Containerfile
-rw-r--r--@ 1 cheolhee  staff   26 Jan 20 13:43 requirements.txt

Compose로 컨테이너 실행

아래와 같이 finch compose up 명령어를 사용하여 멀티 컨테이너 환경을 실행합니다.

$ finch compose up -d
INFO[0000] Creating network finch-demo_default
INFO[0000] Creating volume finch-demo_redis-data
WARN[0000] Ignoring: service web: depends_on: redis: [Required]
INFO[0000] Ensuring image redis:alpine
docker.io/library/redis:alpine:                                                   resolved       |++++++++++++++++++++++++++++++++++++++|
index-sha256:6cbef353e480a8a6e7f10ec545f13d7d3fa85a212cdcc5ffaf5a1c818b9d3798:    done           |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:1023a5ac993a92700157e724a9aa077428b9f5d1ef54f0ab1aa5e74371eab6c3: done           |++++++++++++++++++++++++++++++++++++++|
config-sha256:733d545e87b547f001d2a7965cb668561dd4e92751f84c519c8b6892c4162961:   done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:25e9d7d40e446acd1c87bc032302c12d6f69eb8ee0006879fb2be002ac7278db:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:ce3e85348d1524ee75ee16ea693b051e47a77cf7bfc2fd5fb21474f22f1d7ee6:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:b0abe8c185e79f4788817e25569e9b70ecb3d192996c09a18290cbb77f51b923:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:4e748fe7e898af4bba0af4ecc768150ae7883bf856f039c2c1051c47bb032a61:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:6b59a28fa20117e6048ad0616b8d8c901877ef15ff4c7f18db04e4f01f43bc39:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:d8d7a3e38cc296564e247ed12159d54a7ecdd0725b4664fe6d4f70420fa41523:    done           |++++++++++++++++++++++++++++++++++++++|
layer-sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1:    done           |++++++++++++++++++++++++++++++++++++++|
elapsed: 6.9 s                                                                    total:  31.7 M (4.6 MiB/s)
INFO[0006] Building image finch-demo-web
[+] Building 4.1s (10/10) FINISHED
 => [internal] load build definition from Containerfile                                                                                          0.0s
 => => transferring dockerfile: 208B                                                                                                             0.0s
 => [internal] load metadata for docker.io/library/python:3.11-slim                                                                              1.3s
 => [internal] load .dockerignore                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                  0.0s
 => [1/5] FROM docker.io/library/python:3.11-slim@sha256:5be45dbade29bebd6886af6b438fd7e0b4eb7b611f39ba62b430263f82de36d2                        0.0s
 => => resolve docker.io/library/python:3.11-slim@sha256:5be45dbade29bebd6886af6b438fd7e0b4eb7b611f39ba62b430263f82de36d2                        0.0s
 => [internal] load build context                                                                                                                0.0s
 => => transferring context: 854B                                                                                                                0.0s
 => CACHED [2/5] WORKDIR /app                                                                                                                    0.0s
 => [3/5] COPY requirements.txt .                                                                                                                0.1s
 => [4/5] RUN pip install --no-cache-dir -r requirements.txt                                                                                     2.1s
 => [5/5] COPY app.py .                                                                                                                          0.0s
 => exporting to image                                                                                                                           0.7s
 => => exporting layers                                                                                                                          0.5s
 => => exporting manifest sha256:26a0db072b8e9c4fe1959e74a5ffbdd8022032094190a7546e928c581f4efa5a                                                0.0s
 => => exporting config sha256:9583b0d9807ddc747aa3b5203bafc124edad0a624b89a3e3fa1b7a02a5de6145                                                  0.0s
 => => naming to docker.io/library/finch-demo-web:latest                                                                                         0.0s
 => => unpacking to docker.io/library/finch-demo-web:latest                                                                                      0.1s
INFO[0011] Creating container finch-demo-redis-1
INFO[0011] Running [/usr/local/bin/nerdctl run --cidfile=/tmp/compose-3033891241/cid -l=com.docker.compose.project=finch-demo -l=com.docker.compose.service=redis -d --name=finch-demo-redis-1 --pull=never --net=finch-demo_default --hostname=redis --restart=unless-stopped -v=finch-demo_redis-data:/data redis:alpine]
WARN[0000] volume "finch-demo_redis-data" already exists and will be returned as-is
INFO[0011] Creating container finch-demo-web-1
INFO[0011] Running [/usr/local/bin/nerdctl run --cidfile=/tmp/compose-3371262174/cid -l=com.docker.compose.project=finch-demo -l=com.docker.compose.service=web -d --name=finch-demo-web-1 --pull=never --net=finch-demo_default --hostname=web -p=5000:5000/tcp --restart=unless-stopped finch-demo-web]

위와 같이 웹 애플리케이션과 Redis 컨테이너가 함께 실행된 것을 확인 할 수 있습니다.

실행 중인 컨테이너 확인

아래와 같이 실행 중인 컨테이너를 확인합니다.

$ finch ps -a
CONTAINER ID    IMAGE                                      COMMAND                   CREATED           STATUS    PORTS                     NAMES
946badd3438c    docker.io/library/finch-demo-web:latest    "python app.py"           22 seconds ago    Up        0.0.0.0:5000->5000/tcp    finch-demo-web-1
c4e7f14ce140    docker.io/library/redis:alpine             "docker-entrypoint.s…"    22 seconds ago    Up                                  finch-demo-redis-1

위와 같이 finch-demo-web-1과 finch-demo-redis-1 컨테이너가 정상적으로 실행 중인 것을 확인 할 수 있습니다.

동작 확인

아래와 같이 curl 명령어로 애플리케이션이 정상 동작하는지 확인합니다. 요청할 때마다 방문자 카운트가 증가합니다.

$ curl localhost:5000
<!DOCTYPE html>
<html>
<head>
    <title>Finch Compose Demo</title>
</head>
<body>
    <h1>Hello from Finch Compose!</h1>
    <p>Container Hostname: web</p>
    <p>Visit Count: 1</p>
</body>
</html>

$ curl localhost:5000
<!DOCTYPE html>
<html>
<head>
    <title>Finch Compose Demo</title>
</head>
<body>
    <h1>Hello from Finch Compose!</h1>
    <p>Container Hostname: web</p>
    <p>Visit Count: 2</p>
</body>
</html>

위와 같이 Flask 애플리케이션과 Redis가 정상적으로 연동되어 방문자 카운트가 증가하는 것을 확인 할 수 있습니다.

Compose 환경 종료

아래와 같이 finch compose down 명령어를 사용하여 모든 컨테이너와 네트워크를 종료합니다.

$ finch compose down
INFO[0000] Removing container finch-demo-web-1
INFO[0000] Removing container finch-demo-redis-1
INFO[0001] Removing network finch-demo_default

볼륨까지 함께 삭제하려면 -v 옵션을 추가합니다.

$ finch compose down -v
INFO[0000] Removing container finch-demo-web-1
INFO[0000] Removing container finch-demo-redis-1
INFO[0001] Removing volume finch-demo_redis-data
INFO[0001] Removing network finch-demo_default

시스템 정보 확인

아래와 같이 Finch 시스템 정보를 확인할 수 있습니다.

$ finch system info
Client:
 Namespace:	finch
 Debug Mode:	false

Server:
 Server Version: v2.1.3
 Storage Driver: overlayfs
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Log:     fluentd journald json-file none syslog
  Storage: native overlayfs stargz
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version:   6.12.53-69.119.amzn2023.aarch64
 Operating System: Fedora Linux 42 (Cloud Edition)
 OSType:           linux
 Architecture:     aarch64
 CPUs:             4
 Total Memory:     7.739GiB
 Name:             lima-finch
 ID:               501dce95-ed66-4c39-852d-642a4008f6d0

위와 같이 Finch VM은 내부적으로 Fedora Linux 42 기반으로 동작하며, overlayfs 스토리지 드라이버와 systemd cgroup을 사용하는 것을 확인 할 수 있습니다.

Docker 명령어와 비교

Finch는 nerdctl을 기반으로 하기 때문에 Docker CLI와 거의 동일한 명령어 체계를 사용합니다.

Docker 명령어	Finch 명령어
`docker pull`	`finch pull`
`docker run`	`finch run` 또는 `finch container run`
`docker ps`	`finch ps`
`docker images`	`finch images`
`docker logs`	`finch logs`
`docker rm`	`finch container rm`
`docker rmi`	`finch rmi`
`docker build`	`finch build`
`docker compose up`	`finch compose up`
`docker compose down`	`finch compose down`

참고

Finch GitHub: https://github.com/runfinch/finch
Finch 공식 사이트: https://runfinch.com/

위와 같은 방법으로 macOS 환경에서 Docker Desktop 대신 Finch를 사용하여 컨테이너를 관리할 수 있습니다. Docker CLI와 유사한 명령어 체계를 제공하기 때문에 기존 Docker 사용 경험이 있다면 쉽게 적응할 수 있습니다.

adb 를 이용하여 Android 16 무선 페어링 방법

Wed, 14 Jan 2026 00:00:00 +0900

adb 를 이용하여 Android 16 무선 페어링 방법

정확한 사용 방법에 대해서 기록된 내용이 없어서, 해당 포스팅을 작성하게 되었습니다.

How to

adb 를 사용하는 방법은 PC, APP 둘 다 동일한 방법으로 진행하면 됩니다.

PC : https://developer.android.com/tools/releases/platform-tools?hl=ko
Mobile : ADB Shell 최신 버전

Connect

개발자 옵션에서 무선 디버깅을 활성화합니다.

“페어링 코드로 기기 페어링” 을 누르고 나오는 정보를 아래와 같이 터미널을 통해 페어링을 먼저합니다.

$ adb pair 127.0.0.1:43033
Enter pairing code: 123456
Successfully paired to 127.0.0.1:43033 [guid=adb-abcdefg-chhanz]

페어링이 완료된 이후, “무선 디버깅” 메뉴에 표기된 ‘IP 주소 및 포트’ 정보를 기반으로 connect 합니다.
해당 포트값은 pair 용 포트와 connect 용 포트 번호가 다릅니다.

$ adb connect 127.0.0.1:43853
connected to 127.0.0.1:43853

이후 adb devices 와 같은 명령어로 장치 접속 상태를 확인합니다.

Container Registry - Github Package Registry 사용 with GITHUB CLI

Tue, 13 Jan 2026 00:00:00 +0900

Github Package Registry

DockerHub 의 대안으로 Github Package Registry 를 사용해보고 github-cli 인 gh 를 사용하여 보다 안전하게 컨테이너 이미지를 관리하는 방법에 대해 작성해보도록 하겠습니다.

Github CLI 설치

Github CLI (https://cli.github.com/) 페이지를 참고하여 설치를 수행합니다.

저의 경우, Linux 시스템에 아래와 같은 방법으로 설치하였습니다.

type -p yum-config-manager >/dev/null || sudo yum install yum-utils
sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo yum install gh

Github CLI 를 이용하여 로그인을 하는 사유에는 암호화가 안되고 텍스트로 보관하고 있던 토큰값을 관리하는데 귀찮음(?), 안정성에 문제로 인해 gh 를 이용하면 좋을 것 같아 이번 포스트에서는 해당 방법을 사용하였습니다.

gh auth 명령어를 이용하여 Github 를 로그인 할 수 있습니다.

$ gh auth login --scopes write:packages
? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

! First copy your one-time code: 1234-abcd
Press Enter to open https://github.com/login/device in your browser...

브라우져를 통해 github 에 one-time code 와 함께 device 인증을 수행하면 위와 같이 인증이 완료된 모습을 확인 할 수 있으며, 다음 단계가 수행이 됩니다.

...
✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
! Authentication credentials saved in plain text
✓ Logged in as chhanz

참고로 --scopes write:packages 는 차후 컨테이너 이미지 저장소에 이미지 PUSH 를 위해 미리 권한을 부여하였습니다.
필요시에 적합한 권한을 부여하여 로그인을 수행하면 됩니다.
만약 새로운 권한이 필요한 경우, gh auth refresh 를 사용하여 권한을 추가하면 됩니다.

Github 로그인 상태 확인

gh auth status 명령을 통해 로그인 상태, 권한 등에 대해 확인이 가능합니다.
해당 명령어로는 기본적으로 암호화된 토큰 정보만 확인이 가능합니다.

$ gh auth status
github.com
  ✓ Logged in to github.com account chhanz (/root/.config/gh/hosts.yml)
  - Active account: true
  - Git operations protocol: https
  - Token: git_***.......
  - Token scopes: 'gist', 'read:org', 'repo', 'workflow', 'write:packages'

Push the Container Image

이번 테스트에서는 podman 을 이용하여 이미지를 PUSH 하는 예제를 보여드릴 것입니다.
하지만 docker 도 동일한 방법으로 사용이 가능합니다.

$ export CR_PAT=$(gh auth token) \
&& echo $CR_PAT | podman login ghcr.io -u <<USERNAME>> --password-stdin
Login Succeeded!

위 명령어를 통해 gh 로 토큰값을 받아와서 ghcr.io, Github Package Registry 를 로그인합니다.

$ podman images
REPOSITORY                              TAG         IMAGE ID      CREATED       SIZE
ghcr.io/chhanz/git-readme-stats-docker  latest      2f2b17297e20  5 hours ago   300 MB

위와 같이 빌드된 이미지를 tag 를 아래 구조를 참고하여 수정한 이미지를 활용합니다.

ghcr.io/네임스페이스/컨테이너 이미지 이름:태그

$ podman push ghcr.io/chhanz/git-readme-stats-docker
Getting image source signatures
Copying blob f35e3e5c2bc9 done   |
Copying blob 0649e2656ebe done   |
Copying blob e5aa2ce04d97 done   |
Copying blob def753c8a096 done   |
Copying blob bf948625900f done   |
Copying blob 7bb20cf5ef67 done   |
Copying config 2f2b17297e done   |
Writing manifest to image destination

설정된 태그를 이용하여 위와 같이 PUSH 를 수행합니다.

Change package visibility

기본적으로 PUSH 된 이미지는 private 로 되어 있습니다.
GITHUB 정책에 의하여 무료로 사용 가능한 private 제한이 있고, public 이미지의 경우 무료로 사용이 가능합니다.

위와 같은 사유로 인해 이미지를 Public 으로 변경을 해보도록 하겠습니다.

GITHUB 의 Package 메뉴를 선택하면 위와 같이 이미지가 PUSH 된 것을 확인 할 수 있습니다.
먼저 Connect Repository 를 선택하고 해당 이미지와 연결할 Repository 를 지정합니다.

위와 같이 Repository 가 연결된 것을 확인 할 수 있습니다.
이후 Package settings 를 선택합니다.

설정 하단에 Change package visibility 부분에 Change visibility 를 이용하여 private 에서 public 이미지로 변경을 합니다.

위와 같은 방법으로 이미지를 Public 으로 변경합니다.

https://github.com/chhanz?tab=packages 를 보시면 이미지가 Public 으로 전환 된 것을 확인 할 수 있습니다.

참고 문서

mcpo - Open WebUI MCP 서버 연동 도구

Mon, 05 Jan 2026 00:00:00 +0900

mcpo 란

mcpo 는 MCP 서버 명령을 받아 표준 RESTful OpenAPI를 통해 접근 가능하게 해주는 매우 간단한 프록시입니다.
이러한 기능을 활용하여 LLM 에이전트 및 OpenAPI 를 사용하는 애플리케이션과 연동하는데 도움이 됩니다.

mcpo 의 필요성

MCP 서버는 일반적으로 원시 표준 입출력(stdio)을 통해 통신하는데, 이는 다음과 같은 단점이 있습니다.

🔓 본질적으로 보안에 취약합니다.
❌ 대부분의 도구와 호환되지 않습니다.
🧩 문서화, 인증, 오류 처리 등과 같은 표준 기능이 부족합니다.

위와 같은 단점을 보완하고 여러 MCP 서버를 통합 관리하는데 편리함을 제공합니다.

개인적으로는 MCP 서버를 stdio 형태로 사용하면 사용자의 Laptop 과 같은 디바이스의 리소스를 사용하므로 발생되는 문제, LLM 의 재시작으로 인해 MCP 서버의 재시작등의 관리적으로 연관된 불편함이 다수 존재하였습니다.

mcpo 는 이러한 불편함을 통합 관리하게 만들어주므로 인해 편리함을 제공하였다고 생각합니다.

Build

이번 포스팅에서는 mcpo 를 container 이미지로 빌드하고 빌드된 이미지를 이용하여 사용하는 방법에 대해 설명을 드리겠습니다.

아래와 같은 방법으로 mcpo container 이미지를 빌드합니다.

$ git clone https://github.com/open-webui/mcpo.git
$ cd mcpo/
$ docker build -t mcpo .
$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
mcpo         latest    98c0476e1d50   15 seconds ago   539MB

$ docker run --rm mcpo

 Usage: mcpo [OPTIONS]

╭─ Options ────────────────────────────────────────────────────────────────────╮
│ --host                -h      TEXT     Host address [default: 0.0.0.0]       │
│ --port                -p      INTEGER  Port number [default: 8000]           │
│ --cors-allow-origins          TEXT     CORS allowed origins [default: *]     │
│ --api-key             -k      TEXT     API key for authentication            │
│ --strict-auth                          API key protects all endpoints and    │
│                                        documentation                         │
│ --env                 -e      TEXT     Environment variables                 │
│ --env-path                    TEXT     Path to environment variables file    │
│ --type,--server-type          TEXT     Server type [default: stdio]          │
│ --config              -c      TEXT     Config file path                      │
│ --name                -n      TEXT     Server name                           │
│ --description         -d      TEXT     Server description                    │
│ --version             -v      TEXT     Server version                        │
│ --ssl-certfile        -t      TEXT     SSL certfile                          │
│ --ssl-keyfile         -K      TEXT     SSL keyfile                           │
│ --root-path                   TEXT     Root path                             │
│ --path-prefix                 TEXT     URL prefix                            │
│ --header              -H      TEXT     Headers in JSON format                │
│ --hot-reload                           Enable hot reload for config file     │
│                                        changes                               │
│ --log-level                   TEXT     Set log level (DEBUG, INFO, WARNING,  │
│                                        ERROR, CRITICAL)                      │
│ --install-completion                   Install completion for the current    │
│                                        shell.                                │
│ --show-completion                      Show completion for the current       │
│                                        shell, to copy it or customize the    │
│                                        installation.                         │
│ --help                                 Show this message and exit.           │
╰──────────────────────────────────────────────────────────────────────────────╯

사용 방법

먼저 사용할 MCP 서버들을 json 형태로 선언합니다.

테스트에 활용될 MCP 서버는 아래와 같이 time, memory 를 사용하도록 하겠습니다.

mcpo.json 예제입니다.

$ cat ~/mcpo.json
{
  "mcpServers": {
        "time": {
      "command": "uvx",
      "args": ["mcp-server-time", "--local-timezone=Asia/Seoul"]
    },
        "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "tags": ["memory", "notes"]
    }
  }
}

아래와 같은 방법으로 빌드한 이미지를 실행하고 미리 작성한 mcpo.json 을 —config 옵션을 이용하여 지정합니다.

참고로 --api-key "top-secret" 옵션을 추가하면 API 인증을 설정 할 수 있으니, 구성 환경에 적합하게 활용하면 도움이 될 것 같습니다.

$ docker run -d -p 8000:8000 \
        -v /root/mcpo.json:/app/mcpo.json \
        --restart=always \
        --name mcpo mcpo -- mcpo --config /app/mcpo.json
5414cbd48fd916fd1e9582ade16157a6cc0238c5ae631c830dc411eb4e39817c

$ docker logs -f mcpo
...
2026-01-05 00:48:28,993 - INFO - Successfully connected to 'time'.
2026-01-05 00:48:28,994 - INFO - Initiating connection for server: 'memory'...
Knowledge Graph MCP Server running on stdio
2026-01-05 00:48:39,094 - INFO - Successfully connected to 'memory'.
2026-01-05 00:48:39,095 - INFO -
--- Server Startup Summary ---
2026-01-05 00:48:39,095 - INFO - Successfully connected to:
2026-01-05 00:48:39,096 - INFO -   - time
2026-01-05 00:48:39,096 - INFO -   - memory
2026-01-05 00:48:39,097 - INFO - --------------------------

INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
...

위와 같이 docker logs 를 이용하여 현재 시작된 MCP 서버를 확인 할 수 있으며, 아래와 같은 방법으로 OpenAPI 호환 API 를 호출 테스트를 할 수 있습니다.

$ curl -s localhost:8000/openapi.json | jq
{
  "openapi": "3.1.0",
  "info": {
    "title": "MCP OpenAPI Proxy",
    "description": "Automatically generated API from MCP Tool Schemas\n\n- **available tools**：\n    - [time](/time/docs)\n    - [memory](/memory/docs)",
    "version": "1.0"
  },
  "paths": {}
}

$ curl -s localhost:8000/time/openapi.json | jq
{
  "openapi": "3.1.0",
  "info": {
    "title": "mcp-time",
    "description": "mcp-time MCP Server",
    "version": "1.25.0"
  },
  "servers": [
    {
      "url": "/time"
    }
  ],
  "paths": {
    "/get_current_time": {
      "post": {
        "summary": "Get Current Time",
        "description": "Get current time in a specific timezones",
        "operationId": "tool_get_current_time_post",
...

$ curl -s localhost:8000/memory/openapi.json | jq | head -n6
{
  "openapi": "3.1.0",
  "info": {
    "title": "memory-server",
    "description": "memory-server MCP Server",
    "version": "0.6.3"
...

이와 같이 Proxy 된 MCP 서버를 Open WebUI 와 같은 도구에 연결하여 사용하거나, stdio 사용에 보안적인 문제로 인해 고민중이라면 mcpo 를 사용하는 것도 좋은 방안이 될 것 같습니다.

참고 문서

MCP Support - https://docs.openwebui.com/features/plugin/tools/openapi-servers/mcp/
mcpo - https://github.com/open-webui/mcpo

Grype - 오픈 소스 취약점 스캔 도구

Wed, 12 Nov 2025 00:00:00 +0900

Grype 란?

Grype는 Anchore에서 개발한 오픈 소스 취약점 스캔 도구입니다.
컨테이너 이미지와 파일시스템에서 알려진 취약점을 빠르게 검색할 수 있으며, 다양한 패키지 관리자와 프로그래밍 언어를 지원합니다.
CVE 데이터베이스를 기반으로 보안 취약점을 식별하고, CI/CD 파이프라인에 통합하여 자동화된 보안 검사를 수행할 수 있습니다.

Grype 설치

Grype는 간단한 설치 스크립트를 통해 설치할 수 있습니다.
아래 명령어는 최신 버전을 다운로드하여 /usr/local/bin 디렉토리에 설치합니다.

$ sudo curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin
[info]\033[0m checking github for the current release tag \033[0m
[info]\033[0m fetching release script for tag='v0.103.0' \033[0m
[info]\033[0m checking github for the current release tag \033[0m
[info]\033[0m using release tag='v0.103.0' version='0.103.0' os='linux' arch='amd64' \033[0m
[info]\033[0m installed /usr/local/bin/grype \033[0m

$ sudo which grype
/usr/local/bin/grype

Grype 사용법

CVE 데이터베이스 검색

특정 CVE 번호로 취약점 정보를 검색할 수 있습니다. 이 명령어는 Grype의 취약점 데이터베이스에서 해당 CVE가 영향을 미치는 패키지와 버전 정보를 조회합니다.

$ sudo grype db search "CVE-2024-56737"
VULNERABILITY   PACKAGE                              ECOSYSTEM  NAMESPACE                      VERSION CONSTRAINT
CVE-2024-56737  cpe:2.3:a:gnu:grub2:*:*:*:*:*:*:*:*             nvd:cpe                        <= 2.12
CVE-2024-56737  grub2                                deb        debian:distro:debian:11
CVE-2024-56737  grub2                                deb        debian:distro:debian:12
CVE-2024-56737  grub2                                deb        debian:distro:debian:13        < 2.12-6
CVE-2024-56737  grub2                                deb        debian:distro:debian:14        < 2.12-6
CVE-2024-56737  grub2                                deb        debian:distro:debian:unstable  < 2.12-6
CVE-2024-56737  grub2                                deb        echo:distro:echo:rolling       < 2.12-6
CVE-2024-56737  grub2                                rpm        mariner:distro:azurelinux:3.0  < 0:2.06-25.azl3
CVE-2024-56737  grub2                                rpm        mariner:distro:mariner:2.0     < 0:2.06-15.cm2
CVE-2024-56737  grub2                                rpm        sles:distro:sles:12.3          < 0:2.02-150.1
CVE-2024-56737  grub2                                rpm        sles:distro:sles:12.5          < 0:2.02-181.2 || < 0:2.02-181.2
CVE-2024-56737  grub2                                rpm        sles:distro:sles:15.3          < 0:2.04-150300.22.52.3
CVE-2024-56737  grub2                                rpm        sles:distro:sles:15.4          < 0:2.06-150400.11.55.2 || < 0:2.06-150400.11.55.2
...

시스템 전체 스캔

아래와 같은 방법을 통해 시스템 전체에 대해 스캔 할 수 있습니다.
이번 글에서는 ignore-package.yml 를 이용하여 runc 패키지의 취약점만 확인 할 수 있도록 ignore 옵션을 활용하였습니다.

$ cat ignore-package.yml
ignore:
  - package:
      name: "linux-kernel"
      type: "linux-kernel"
  - package:
      name: "*"
      type: "python"
  - package:
      name: "*"
      type: "go-module"
  - package:
      name: "kernel"
      type: "rpm"
  - package:
      name: "kernel-libbpf"
      type: "rpm"
  - package:
      name: "kernel-tools"
      type: "rpm"

설정 파일을 적용하여 루트 디렉토리를 스캔합니다. 스캔 결과에는 발견된 취약점의 심각도, 설치된 버전, 수정 버전 등이 표시됩니다.

$ sudo grype / -c ignore-package.yml
 ✔ Indexed file system                                                                                     /
 ✔ Cataloged contents                       8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1
   ├── ✔ Packages                        [1,321 packages]
   ├── ✔ Executables                     [1,889 executables]
   ├── ✔ File metadata                   [42,029 locations]
   └── ✔ File digests                    [42,029 files]
 ✔ Scanned for vulnerabilities     [5 vulnerability matches]
   ├── by severity: 7 critical, 1526 high, 3982 medium, 58 low, 0 negligible
   └── by status:   5105 fixed, 468 not-fixed, 5568 ignored
NAME  INSTALLED              FIXED IN               TYPE  VULNERABILITY       SEVERITY  EPSS           RISK
runc  1.1.11-1.amzn2023.0.1  1.1.13-1.amzn2023.0.1  rpm   ALAS2023-2024-710   Medium    < 0.1% (24th)  < 0.1
runc  1.1.11-1.amzn2023.0.1  1.2.4-2.amzn2023.0.1   rpm   ALAS2023-2025-1041  High      < 0.1% (5th)   < 0.1
runc  1.1.11-1.amzn2023.0.1  1.1.14-1.amzn2023.0.1  rpm   ALAS2023-2024-725   Low       < 0.1% (4th)   < 0.1
runc  1.1.11-1.amzn2023.0.1  1.3.2-2.amzn2023.0.1   rpm   ALAS2023-2025-1263  High      < 0.1% (0th)   < 0.1
runc  1.1.11-1.amzn2023.0.1  1.2.6-1.amzn2023.0.1   rpm   ALAS2023-2025-1078  Medium    < 0.1% (0th)   < 0.1

취약점 패치 적용

스캔 결과에서 발견된 취약점을 해결하기 위해 패키지를 업데이트합니다.

$ sudo rpm -qa | grep runc
runc-1.1.11-1.amzn2023.0.1.x86_64

$ sudo yum update runc
...
Upgraded:
  runc-1.3.3-2.amzn2023.0.1.x86_64

Complete!

$ sudo rpm -qa | grep runc
runc-1.3.3-2.amzn2023.0.1.x86_64

패치 후 재스캔

패키지 업데이트 후 다시 스캔하여 취약점이 해결되었는지 확인합니다.

$ sudo grype / -c ignore-package.yml
 ✔ Indexed file system                                                                                  /
 ✔ Vulnerability DB                [no update available]
 ✔ Cataloged contents                    8a5edab282632443219e051e4ade2d1d5bbc671c781051bf1437897cbdfea0f1
   ├── ✔ Packages                        [1,322 packages]
   ├── ✔ Executables                     [1,890 executables]
   ├── ✔ File metadata                   [42,034 locations]
   └── ✔ File digests                    [42,034 files]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 4 critical, 1509 high, 3961 medium, 57 low, 0 negligible
   └── by status:   5063 fixed, 468 not-fixed, 5531 ignored
No vulnerabilities found

보시는 것처럼 취약점이 해결된 것을 확인 할 수 있었습니다.

컨테이너 이미지 검사

Grype 는 Docker 이미지의 취약점도 검사할 수 있습니다.

사용 방법은 아래와 같습니다.

$ sudo grype docker.io/library/nginx:1.28.0-alpine
 ✔ Loaded image                                                           index.docker.io/library/nginx:1.28.0-alpine
 ✔ Parsed image                               sha256:c318e336065b17ff460aeac6d14bce5d0b13e35f25d5cb1843b635359fc00c9a
 ✔ Cataloged contents                                c9fe5d237739ac0665d879b1ca8e4a81b8c1ab0a6158922e59937ca8163b43a7
   ├── ✔ Packages                        [68 packages]
   ├── ✔ File digests                    [976 files]
   ├── ✔ File metadata                   [976 locations]
   └── ✔ Executables                     [123 executables]
 ✔ Scanned for vulnerabilities     [15 vulnerability matches]
   ├── by severity: 2 critical, 3 high, 3 medium, 7 low, 0 negligible
NAME           INSTALLED   FIXED IN   TYPE  VULNERABILITY   SEVERITY  EPSS          RISK
libxml2        2.13.4-r6   2.13.9-r0  apk   CVE-2025-49796  Critical  0.4% (62nd)   0.4
libxml2        2.13.4-r6   2.13.9-r0  apk   CVE-2025-6021   High      0.4% (58th)   0.3
tiff           4.7.1-r0               apk   CVE-2023-6277   Medium    0.4% (61st)   0.2
libxml2        2.13.4-r6   2.13.9-r0  apk   CVE-2025-49794  Critical  0.3% (48th)   0.2
tiff           4.7.1-r0               apk   CVE-2023-52356  High      0.3% (49th)   0.2
libxml2        2.13.4-r6   2.13.9-r0  apk   CVE-2025-49795  High      0.1% (34th)   0.1
nginx          1.28.0-r1              apk   CVE-2025-53859  Medium    0.1% (28th)   < 0.1
tiff           4.7.1-r0               apk   CVE-2023-6228   Medium    < 0.1% (2nd)  < 0.1
libxml2        2.13.4-r6   2.13.9-r0  apk   CVE-2025-6170   Low       < 0.1% (6th)  < 0.1
busybox        1.37.0-r13             apk   CVE-2025-46394  Low       < 0.1% (1st)  < 0.1
busybox-binsh  1.37.0-r13             apk   CVE-2025-46394  Low       < 0.1% (1st)  < 0.1
ssl_client     1.37.0-r13             apk   CVE-2025-46394  Low       < 0.1% (1st)  < 0.1
busybox        1.37.0-r13             apk   CVE-2024-58251  Low       < 0.1% (3rd)  < 0.1
busybox-binsh  1.37.0-r13             apk   CVE-2024-58251  Low       < 0.1% (3rd)  < 0.1
ssl_client     1.37.0-r13             apk   CVE-2024-58251  Low       < 0.1% (3rd)  < 0.1

스캔 결과는 취약점의 심각도(Critical, High, Medium, Low)와 EPSS(Exploit Prediction Scoring System) 점수를 포함하여 우선순위를 판단할 수 있도록 출력합니다.

참고 문서

https://github.com/anchore/grype

[Linux] Loop Mount 구성

Mon, 29 Sep 2025 00:00:00 +0900

Loop Devive 란?

루프 장치(Loop device)는 유닉스 계열 운영 체제에서 특정 파일을 일반 블록 장치처럼 접근할 수 있게 해주는 가상 장치로, 파일 시스템이 포함된 ISO 이미지나 디스크 이미지를 마운트하는 등의 용도로 사용됩니다.
루프 장치를 통해 파일 전체를 하나의 디스크처럼 취급하여 해당 파일 시스템을 직접 마운트하고 읽거나 쓸 수 있습니다.

Mount the Loop device

이러한 Loop Device 와 같은 가상 장치를 통해 Cloud Image, ISO, 파일을 mount 하고 블록 장치와 같은 형태로 사용 할 수 있습니다.

이번 글에서는 Cloud Image 의 형태에 따라 Loop device 를 사용하는 방법에 대해 작성해보았습니다.

Single Partition 구조

일반적으로 파티션 한개를 이미지 백업 받은 파일을 loop device 를 이용하여 mount 하는 방법은 일반적인 ISO 이미지를 mount 하는 방법과 유사합니다.

# parted part-image-backup.img unit B print
Model:  (file)
Disk /data/part-image-backup.img: 8587820544B
Sector size (logical/physical): 512B/512B
Partition Table: loop
Disk Flags:

Number  Start  End          Size         File system  Flags
 1      0B     8587820543B  8587820544B  xfs

한개의 파티션을 dd 를 통해 파일로 생성한 형태의 구조입니다.

이런 경우, 아래와 같은 방법으로 파일시스템 탑재를 하고 수정 및 확인이 가능합니다.

# mount -o loop,nouuid part-image-backup.img /mnt

# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0     7:0    0    8G  0 loop /mnt        <<<----!!!
...

# cat /mnt/etc/os-release |head -n1
NAME="Amazon Linux"

Multiple Partition 구조

디스크 (or 볼륨) 의 모든 파티션을 이미지 백업을 하거나 Cloud Image 와 같은 형태로 제공이 되는 파일을 loop device 를 이용하여 mount 하여 사용이 가능하게 하는 방법입니다.

테스트에 사용된 Cloud Image 정보는 아래와 같습니다.

$ sudo qemu-img info rhel-9.6-x86_64-kvm.raw
image: rhel-9.6-x86_64-kvm.raw
file format: raw
virtual size: 10 GiB (10737418240 bytes)
disk size: 1.61 GiB
Child node '/file':
    filename: rhel-9.6-x86_64-kvm.raw
    protocol type: file
    file length: 10 GiB (10737418240 bytes)
    disk size: 1.61 GiB
    Format specific information:
        extent size hint: 1048576

먼저 이미지의 파티션 구조를 파악합니다.

# parted rhel-9.6-x86_64-kvm.raw unit B print
Model:  (file)
Disk /root/rhel-9.6-x86_64-kvm.raw: 10737418240B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start        End           Size         File system  Name  Flags
 1      1048576B     2097151B      1048576B                        bios_grub
 2      2097152B     211812351B    209715200B   fat16              boot, esp
 3      211812352B   1285554175B   1073741824B  xfs                bls_boot
 4      1285554176B  10737401343B  9451847168B  xfs

/ 파일시스템은 1285554176 B 부터 섹터가 시작이 되는 것으로 확인 됩니다.

losetup 명령어를 통해 파티션 시작 섹터를 지정하여 loop device 생성합니다.

# losetup -o 1285554176 /dev/loop0 rhel-9.6-x86_64-kvm.raw

# losetup -l
NAME       SIZELIMIT     OFFSET AUTOCLEAR RO BACK-FILE                     DIO LOG-SEC
/dev/loop0         0 1285554176         0  0 /root/rhel-9.6-x86_64-kvm.raw   0     512

위와 같이 loop0 디바이스가 생성이 되면 아래와 같은 방법을 통해 mount 를 수행하고 파일시스템을 탑재할 수 있습니다.

$ sudo lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0           7:0    0  8.8G  0 loop
nvme0n1       259:0    0   50G  0 disk
├─nvme0n1p1   259:1    0   50G  0 part /
├─nvme0n1p127 259:2    0    1M  0 part
└─nvme0n1p128 259:3    0   10M  0 part /boot/efi

$ sudo mount /dev/loop0 /mnt

$ sudo cat /mnt/etc/redhat-release
Red Hat Enterprise Linux release 9.6 (Plow)

참고 문서

https://linux.die.net/man/8/losetup

[AWS] CloudFormation과 SSM을 이용한 RHEL HA 클러스터 자동 구성

Wed, 20 Aug 2025 00:00:00 +0900

RHEL HA 클러스터 자동 구성

AWS에서 RHEL 기반 고가용성(HA) 클러스터를 자동으로 구성하는 솔루션을 소개합니다.
CloudFormation 템플릿과 SSM 문서를 활용하여 Pacemaker 기반의 HA 클러스터를 완전 자동화된 방식으로 배포할 수 있습니다.

[주의] 해당 솔루션은 POC 환경 혹은 개발 환경, 이슈 재현 환경등으로 사용하는 것을 권장 드립니다.

운영 환경에는 적합한 설정이 아닌 부분이 있을 수 있습니다.

솔루션 소스

Github 의 chhanz/rhel.ha-cluster_pacemaker_on_aws 에서 소스를 제공하고 있습니다.

솔루션 개요

이 솔루션은 두 가지 주요 구성 요소로 이루어져 있습니다:

CloudFormation 템플릿 (deployment.yaml) - AWS 인프라 자동 구성
SSM 문서 (ha-cluster-setup-document.json) - HA 클러스터 자동 설정

아키텍처 구성

인프라 구성

기본 리전 : ap-northeast-2 (서울)
VPC: 10.0.0.0/16 CIDR 블록
서브넷:
- SubnetB (ap-northeast-2b): 10.0.1.0/24
- SubnetD (ap-northeast-2d): 10.0.2.0/24
EC2 인스턴스: RHEL 9.6 (t3.medium) 2대
보안 그룹: 클러스터 내부 통신 허용
IAM 역할: STONITH 및 Elastic IP 관리 권한

HA 클러스터 구성

Pacemaker/Corosync 기반 클러스터
STONITH: fence_aws 사용
Ansible: rhel-system-roles 로 자동 구성
선택적 Dummy 리소스: 테스트용 Dummy 리소스

배포 과정

1단계: 인프라 배포

CloudFormation 스택을 생성하여 AWS 인프라를 구성합니다.

# CloudFormation 스택 생성
aws cloudformation create-stack \
    --stack-name rhel-ha-cluster \
    --template-body file://deployment.yaml \
    --parameters ParameterKey=SameSubnet,ParameterValue=false \
    --capabilities CAPABILITY_NAMED_IAM \
    --region ap-northeast-2

파라미터 설명

SameSubnet:
- false (기본값): 서로 다른 AZ에 배치 (권장)
- true: 같은 서브넷에 배치

인스턴스가 생성되고 운영체제 업데이트 및 최초 설정 작업이 수행되고, 운영체제 재부팅이 진행 될 것 입니다.
진행이 완료된 이후, 다음 단계로 가시면 됩니다.

2단계: SSM 문서 생성

HA 클러스터 자동 설정을 위한 SSM 문서를 생성합니다.

# SSM 문서 생성
aws ssm create-document \
    --name "HA-Cluster-Setup" \
    --document-type "Command" \
    --document-format "JSON" \
    --content file://ha-cluster-setup-document.json \
    --region ap-northeast-2

3단계: HA 클러스터 구성

생성된 인스턴스에서 HA 클러스터를 자동으로 구성합니다.

[주의] HA 클러스터 설정 실행은 Node 1 에서만 SSM 문서 “명령 실행” 을 수행합니다.

# 인스턴스 정보 확인
aws cloudformation describe-stacks \
    --stack-name rhel-ha-cluster \
    --query 'Stacks[0].Outputs' \
    --region ap-northeast-2

# HA 클러스터 설정 실행 > Node 1 로 사용될 인스턴스 한대에 대상으로 SSM 문서 명령 실행
aws ssm send-command \
    --document-name "HA-Cluster-Setup" \
    --instance-ids "i-xxxxxxxxx" \
    --parameters '{
        "Node1InstanceId":"i-xxxxxxxxx",
        "Node1PrivateIP":"10.0.1.10",
        "Node2InstanceId":"i-yyyyyyyyy",
        "Node2PrivateIP":"10.0.2.20",
        "ClusterPassword":"secure-password",
        "ClusterName":"my-ha-cluster",
        "DeployDummyResource":"false"
    }' \
    --region ap-northeast-2

혹은 Systems Manager > “문서” 에서 “HA-Cluster-Setup” 를 검색하고 실행하면 AWS 콘솔에서도 각 파라미터를 입력 할 수 있도록 제공합니다.

주요 기능

자동화된 구성

시스템 업데이트: 최신 패키지로 자동 업데이트
사용자 생성: haadm 계정 자동 생성
인스턴스 연결: Session Manager 를 사용하도록 설정
필수 패키지: rhel-system-roles, AWS CLI, 기타 도구 설치

HA 클러스터 설정

방화벽/SELinux: 자동 비활성화
부팅 시 시작: 비활성화 (수동 시작)
클라우드 에이전트: 자동 설치
STONITH 설정: fence_aws 사용

네트워크 구성

호스트 파일: 자동 업데이트 (/etc/hosts)
Ansible 인벤토리: 동적 생성

생성되는 파일들

SSM 문서 실행 시 /usr/local/ha_cluster/에 다음 파일들이 생성됩니다:

inventory.yml: Ansible 인벤토리
update-hosts.yaml: 호스트 파일 업데이트 플레이북
fast-aws-playbook.yaml: HA 클러스터 배포 플레이북
group_vars/${CLUSTER_NAME}.yml: 클러스터 설정 변수

클러스터 상태 확인

배포 완료 후 클러스터 상태를 확인할 수 있습니다.

# 클러스터 상태 확인
$ sudo pcs status
Cluster name: fast-aws-rh-cluster
Cluster Summary:
  * Stack: corosync (Pacemaker is running)
  * Current DC: fast-aws-rh-node-1 (version 2.1.9-1.2.el9_6-49aab9983) - partition with quorum
  * Last updated: Wed Aug 20 04:51:15 2025 on fast-aws-rh-node-1
  * Last change:  Wed Aug 20 04:50:26 2025 by root via root on fast-aws-rh-node-1
  * 2 nodes configured
  * 4 resource instances configured

Node List:
  * Online: [ fast-aws-rh-node-1 fast-aws-rh-node-2 ]

Full List of Resources:
  * mystonith   (stonith:fence_aws):     Started fast-aws-rh-node-1
  * example-1   (ocf:pacemaker:Dummy):   Started fast-aws-rh-node-2
  * example-2   (ocf:pacemaker:Dummy):   Started fast-aws-rh-node-1
  * example-3   (ocf:pacemaker:Dummy):   Started fast-aws-rh-node-2

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

클러스터 설정 확인

$ sudo pcs config
Cluster Name: fast-aws-rh-cluster
Corosync Nodes:
 fast-aws-rh-node-1 fast-aws-rh-node-2
Pacemaker Nodes:
 fast-aws-rh-node-1 fast-aws-rh-node-2

Resources:
  Resource: example-1 (class=ocf provider=pacemaker type=Dummy)
    Operations:
      migrate_from: example-1-migrate_from-interval-0s
        interval=0s timeout=20s
      migrate_to: example-1-migrate_to-interval-0s
        interval=0s timeout=20s
      monitor: example-1-monitor-interval-10s
        interval=10s timeout=20s
      reload: example-1-reload-interval-0s
        interval=0s timeout=20s
      reload-agent: example-1-reload-agent-interval-0s
        interval=0s timeout=20s
      start: example-1-start-interval-0s
        interval=0s timeout=20s
      stop: example-1-stop-interval-0s
        interval=0s timeout=20s
  Resource: example-2 (class=ocf provider=pacemaker type=Dummy)
    Operations:
      migrate_from: example-2-migrate_from-interval-0s
        interval=0s timeout=20s
      migrate_to: example-2-migrate_to-interval-0s
        interval=0s timeout=20s
      monitor: example-2-monitor-interval-10s
        interval=10s timeout=20s
      reload: example-2-reload-interval-0s
        interval=0s timeout=20s
      reload-agent: example-2-reload-agent-interval-0s
        interval=0s timeout=20s
      start: example-2-start-interval-0s
        interval=0s timeout=20s
      stop: example-2-stop-interval-0s
        interval=0s timeout=20s
  Resource: example-3 (class=ocf provider=pacemaker type=Dummy)
    Operations:
      migrate_from: example-3-migrate_from-interval-0s
        interval=0s timeout=20s
      migrate_to: example-3-migrate_to-interval-0s
        interval=0s timeout=20s
      monitor: example-3-monitor-interval-10s
        interval=10s timeout=20s
      reload: example-3-reload-interval-0s
        interval=0s timeout=20s
      reload-agent: example-3-reload-agent-interval-0s
        interval=0s timeout=20s
      start: example-3-start-interval-0s
        interval=0s timeout=20s
      stop: example-3-stop-interval-0s
        interval=0s timeout=20s

Stonith Devices:
  Resource: mystonith (class=stonith type=fence_aws)
    Attributes: mystonith-instance_attributes
      pcmk_delay_max=45
      pcmk_host_map=fast-aws-rh-node-1:i-123456789012abcdef;fast-aws-rh-node-2:i-09876543214321ffedcba
      pcmk_reboot_retries=4
      pcmk_reboot_timeout=600
      power_timeout=600
      region=ap-northeast-2
    Operations:
      monitor: mystonith-monitor-interval-300
        interval=300 timeout=60
      start: mystonith-start-interval-0s
        interval=0s timeout=600

Cluster Properties: cib-bootstrap-options
  cluster-infrastructure=corosync
  cluster-name=fast-aws-rh-cluster
  dc-version=2.1.9-1.2.el9_6-49aab9983
  have-watchdog=false
  stonith-watchdog-timeout=0

STONITH 테스트

$ sudo pcs stonith fence fast-aws-rh-node-2
Node: fast-aws-rh-node-2 fenced

정리

사용이 완료된 후에는 다음 명령어로 리소스를 정리할 수 있습니다.

# CloudFormation 스택 삭제
aws cloudformation delete-stack \
    --stack-name rhel-ha-cluster \
    --region ap-northeast-2

# SSM 문서 삭제
aws ssm delete-document \
    --name "HA-Cluster-Setup" \
    --region ap-northeast-2

참고 문서

rhel.ha-cluster_pacemaker_on_aws:
https://github.com/chhanz/rhel.ha-cluster_pacemaker_on_aws
Red Hat High Availability Add-On Reference :
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_high_availability_clusters/index

UV - Rust로 작성된 빠른 Python 패키지 관리자

Wed, 30 Jul 2025 00:00:00 +0900

UV

UV 는 Rust로 작성된 Python 패키지 및 프로젝트 관리자로 pip 의 대안으로 떠오르는 패키지 관리자입니다.

Highlights

🚀 pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv 등을 대체하는 단일 도구입니다.
⚡️ pip보다 10-100배 빠릅니다.
🗂️ 범용 잠금 파일을 통한 포괄적인 프로젝트 관리를 제공합니다.
❇️ 인라인 의존성 메타데이터를 지원하여 스크립트를 실행합니다.
🐍 Python 버전을 설치하고 관리합니다.
🛠️ Python 패키지로 게시된 도구를 실행하고 설치합니다.
🔩 친숙한 CLI로 성능 향상을 위한 pip 호환 인터페이스를 포함합니다.
🏢 확장 가능한 프로젝트를 위한 Cargo 스타일 워크스페이스를 지원합니다.
💾 의존성 중복 제거를 위한 글로벌 캐시로 디스크 공간을 효율적으로 사용합니다.
⏬ curl 또는 pip을 통해 Rust나 Python 없이도 설치 가능합니다.
🖥️ macOS, Linux, Windows를 지원합니다.

Installation

/> # python --version
Python 2.7.18          <<<---- 운영체제 Python 버전

/> # curl -LsSf https://astral.sh/uv/install.sh | sh
downloading uv 0.8.4 x86_64-unknown-linux-gnu
no checksums to verify
installing to /root/.local/bin
  uv
  uvx
everything's installed!

To add $HOME/.local/bin to your PATH, either restart your shell or run:

    source $HOME/.local/bin/env (sh, bash, zsh)
    source $HOME/.local/bin/env.fish (fish)

How to

프로젝트 초기화

/> # uv init uv-test
Initialized project `uv-test` at `/root/uv-test`

/> # cd uv-test; tree -a
.
├── main.py
├── pyproject.toml    <<--- 프로젝트의 메타데이터와 설정을 저장하는 파일
├── .python-version   <<--- 프로젝트에서 사용할 Python 버전을 지정하는 파일
└── README.md

의존성 패키지 추가

/> uv add flask
Using CPython 3.7.16 interpreter at: /usr/bin/python3.7
Creating virtual environment at: .venv
Resolved 24 packages in 115ms
Prepared 9 packages in 53ms
Installed 9 packages in 15ms
 + click==8.1.8
 + flask==2.2.5
 + importlib-metadata==6.7.0
 + itsdangerous==2.1.2
 + jinja2==3.1.6
 + markupsafe==2.1.5
 + typing-extensions==4.7.1
 + werkzeug==2.2.3
 + zipp==3.15.0

/> # cat uv.lock
version = 1
revision = 3
requires-python = ">=3.7"
resolution-markers = [
    "python_full_version >= '3.10'",
    "python_full_version == '3.9.*'",
    "python_full_version == '3.8.*'",
    "python_full_version < '3.8'",
]
... skip

/> # uv pip freeze > requirements.txt
/> # cat requirements.txt
click==8.1.8
flask==2.2.5
importlib-metadata==6.7.0
itsdangerous==2.1.2
jinja2==3.1.6
markupsafe==2.1.5
typing-extensions==4.7.1
werkzeug==2.2.3
zipp==3.15.0

의존성 패키지 제거

/> # uv add flask_cors
Resolved 26 packages in 42ms
Prepared 1 package in 11ms
Installed 1 package in 1ms
 + flask-cors==5.0.0

/> # uv remove flask-cors
Resolved 24 packages in 41ms
Uninstalled 1 package in 0.40ms
 - flask-cors==5.0.0
/> # uv pip freeze > requirements.txt
/> # cat requirements.txt
click==8.1.8
flask==2.2.5
importlib-metadata==6.7.0
itsdangerous==2.1.2
jinja2==3.1.6
markupsafe==2.1.5
typing-extensions==4.7.1
werkzeug==2.2.3
zipp==3.15.0

패키지 버전 고정

/> # uv lock
Resolved 24 packages in 0.80ms

가상 환경 생성

/> # uv venv
Using CPython 3.7.16 interpreter at: /usr/bin/python3.7
Creating virtual environment at: .venv
✔ A virtual environment already exists at `.venv`. Do you want to replace it? · yes
Activate with: source .venv/bin/activate

UV 프로젝트로 실행

/> # uv run main.py
Installed 9 packages in 16ms
Flask 버전: 2.2.5
Python 버전: 3.7.16 (default, Jun 27 2025, 23:12:33)
...

테스트 결과 :

$ curl -s 172.31.46.51:5000 | egrep "\"version-l|\"version-v"
                <div class="version-label">Flask Version:</div>
                <div class="version-value">2.2.5</div>
                <div class="version-label">Python Version:</div>
                <div class="version-value">3.7.16 (default, Jun 27 2025, 23:12:33)

프로젝트 이외 경로에서 실행 방안

/> # uv run --project /root/uv-test /root/uv-test/main.py

pip 과 비교

기존 pip 을 통해 패키지를 설치하고 관리하는 방법에 비해 매우 빠른 성능으로 패키지를 설치 관리 할 수 있었습니다.
실제 대규모 프로젝트에서는 많은 의존성으로 인해 빌드 과정이 복잡해질 것이며, UV 를 사용하게되면 성능적 (속도)으로 효과적인 개선 효과를 만들 수 있을 것으로 기대합니다.

참고 자료

https://github.com/astral-sh/uv

RHEL BYOL AMI 생성 가이드

Wed, 04 Jun 2025 00:00:00 +0900

RHEL BYOL AMI 생성

AWS 와 같은 기타 CSP 를 사용하게 되면 PAYG 라이센스의 RHEL 을 사용합니다.
PAYG 라이센스가 아닌 BYOL (Bring Your Own License) RHEL 을 사용하면서, OpenSCAP 프로파일 적용, 파티션 구분 및 파일시스템 분리 등을 위한 커스텀한 RHEL BYOL AMI 을 생성하는 방안에 대해 설명을 드리겠습니다.

이번 포스팅은 AWS 를 대상으로 진행이 되었으나, GCP, Azure, Oracle Cloud, VMWare, qcow2, iso 로 사용 가능한 이미지가 생성에도 활용이 가능합니다.

Recommanded

Developers Subscription 등록 필요
- https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription
아래 페이지에서도 등록이 가능합니다.
- https://developers.redhat.com/products/rhel/download
정상적으로 등록이 된다면 아래와 같이 서브스크립션이 확인이 될 것입니다.

How to create BYOL AMI

Red Hat Insights > Inventory > Images
Select target environment > AWS
- Select the RHEL Release version
Enter the account ID for shared AMI
Select “Registration method”
Select the “OpenSCAP profile”
File system configuration
Select the “Disable repeatable build“ for use the newest state of repositories
(optional) if you need custom repositories, add custom repository information
(optional) if you need additional packages
(optional) if you need add user
Select the timezone
Select the Locale
Select the hostname
(optional) Customize kernel name and kernel arguments.
(optional) Customize firewall settings for your image.
(optional) Enable, disable and mask systemd services.
(optional) Configure the image with a custom script that will execute on its first boot.
Select the Blueprint name
Review
Create blueprint and build image
building the image
Shared AMI
Create the instance from shared AMI

[root@ip-172-31-8-200 ~]# cat /var/log/messages | grep rhel-image
Jun  4 01:16:27 ip-172-31-8-200 systemd: Hostname set to <rhel-image-builder>.

[root@ip-172-31-8-200 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 10.0 (Coughlan)

[root@ip-172-31-8-200 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3   20G  1.9G   18G  10% /
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           1.8G     0  1.8G   0% /dev/shm
efivarfs        128K  3.6K  120K   3% /sys/firmware/efi/efivars
tmpfs           707M  8.6M  698M   2% /run
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
/dev/nvme0n1p2  200M  8.4M  192M   5% /boot/efi
tmpfs           1.0M     0  1.0M   0% /run/credentials/serial-getty@ttyS0.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs           354M  4.0K  354M   1% /run/user/1001

[root@ip-172-31-8-200 ~]# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0   20G  0 disk
├─nvme0n1p1 259:1    0    1M  0 part
├─nvme0n1p2 259:2    0  200M  0 part /boot/efi
└─nvme0n1p3 259:3    0 19.8G  0 part /

[root@ip-172-31-8-200 ~]# rpm -qa | egrep "cloud-init|tmux"
cloud-init-24.4-3.el10.noarch
tmux-3.3a-13.20230918gitb202a2f.el10.x86_64

[root@ip-172-31-8-200 ~]# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Not registered

[root@ip-172-31-8-200 ~]# yum repolist
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use "rhc" or "subscription-manager" to register.

No repositories available

Register subscription

[root@ip-172-31-8-200 ~]# subscription-manager register
Registering to: subscription.rhsm.redhat.com:443/subscription
Username: chhanz
Password: ******
The system has been registered with ID: 1234-1234-1234-1234-1234
The registered system name is: ip-172-31-8-200.ap-northeast-2.compute.internal
[root@ip-172-31-8-200 ~]# subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Registered

[root@ip-172-31-8-200 ~]# yum repolist
Updating Subscription Management repositories.
repo id                                                      repo name
rhel-10-for-x86_64-appstream-rpms                            Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs)
rhel-10-for-x86_64-baseos-rpms                               Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs)

참고 자료

https://docs.redhat.com/ko/documentation/red_hat_enterprise_linux/8/html/creating_customized_images_by_using_insights_image_builder/index

RHEL Lightspeed 사용기

Tue, 03 Jun 2025 00:00:00 +0900

RHEL Lightspeed 사용기

RHEL Lightspeed 은 Red Hat 이 수십 년간 축적해온 Linux 전문 지식이 적용된 AI 기반 서비스를 활용하면 간소화된 명령으로 Red Hat Enterprise Linux를 구축, 배포, 관리할 수 있는 도구입니다.

RHEL Lightspeed 은 Red Hat Enterprise Linux 9.6 및 10에서 사용할 수 있습니다.

이번 포스팅에서는 RHEL Lightspeed 이 어떻게 RHEL 에서 사용되고, 활용 할 수 있을지 몇가지 예제를 수행하여 활용을 해보았습니다.

Recommanded

기본적으로 Developers Subscription 이상의 서브스크립션이 필요합니다.
rhc 혹은 subscription-manager 명령어를 통해 운영체제에 서브스크립션이 활성화 된 상태가 필요합니다.

command-line-assistant 설치

아래와 같은 방법으로 command-line-assistant (이하 CLA) 를 설치합니다.

$ sudo dnf install command-line-assistant

How to

기본적으로 아래와 같은 구문으로 명령어를 수행합니다.

$ c "질문"

Example

What is redhat?
아래와 같이 RHEL 과 관련한 질문을 할 수 있습니다.

What is this error messages?
아래와 같이 파이프(|)를 통해 시스템에서 발생되는 메시지에 대한 자료를 요청 할 수 있습니다.

How do I install NFS Server?
아래와 같이 RHEL 에 서버 역할을 구성하는 방안에 대해 질의하고 안내 받을 수 있습니다.

특정 포맷의 데이터를 원하는 형태로 가공을 요청 할 수 있습니다.

테스트 데이터 (json)

  $ cat test.json
  [{
  "id": 1,
  "first_name": "Jeanette",
  "last_name": "Penddreth",
  "email": "jpenddreth0@cs.dom",
  "gender": "Female",
  "ip_address": "2.5.1.2"
  }, {
  "id": 2,
  "first_name": "Giavani",
  "last_name": "Frediani",
  "email": "gfrediani1@se.dom",
  "gender": "Male",
  "ip_address": "2.1.4.2"
  }, {
  "id": 3,
  "first_name": "Noell",
  "last_name": "Bea",
  "email": "nbea2@ik.dom",
  "gender": "Female",
  "ip_address": "1.6.1.2"
  }, {
  "id": 4,
  "first_name": "Willard",
  "last_name": "Valek",
  "email": "wvalek3@v.com",
  "gender": "Male",
  "ip_address": "6.6.8.6"
  }]

아래와 같이 CLA 를 이용하여 table 형태로 편리하게 포맷을 변경 할 수 있습니다.

특정 명령어 생성 지원
파이프(|)를 통해 특정 출력에 대해 특정 조건의 명령어 생성을 요청 할 수 있습니다.
또한 한글로 질문을 할 수 있습니다. 하지만 답변은 영문으로만 제공이 되는 것을 볼 수 있었습니다.

테스트용 소스 코드 생성 지원 아래와 같이 테스트를 위한 소스 코드 생성을 지원하는 것을 확인 할 수 있었습니다.

여러 조건의 명령어 생성 지원 아래와 같은 여러 조건의 명령을 one line 명령어로 생성 지원하는 것을 확인 할 수 있었습니다.

특정 어플리케이션 (httpd) 의 설정 파일 점검 아래와 같이 httpd 의 설정 파일을 점검 요청 할 수 있었습니다.

[root@ip-172-31-8-200 conf]# systemctl start httpd
Job for httpd.service failed because the control process exited with error code.
See "systemctl status httpd.service" and "journalctl -xeu httpd.service" for details.

위와 같이 httpd 서비스가 정상적으로 동작을 안하는 문제로 인해 CLA 에게 설정 파일 검토를 요청 하였습니다.

위와 같이 Listen 구문에 문제가 있는 것을 확인했고, 가능한 설정 방법에 대해 안내를 지원하였습니다.

[root@ip-172-31-8-200 conf]# cat httpd.conf | grep Listen
# Listen: Allows you to bind Apache to specific IP addresses and/or
# Change this to Listen on a specific IP address, but note that if
#Listen 12.34.56.78:80
Listen 9999999

실제로 위와 같이 잘못된 Listen 설정을 확인 할 수 있었습니다.

총평

그 외에도 데이터를 기반한 스크립트 생성, 명령어 간편화 등등 여러 플랫폼을 사용하지 않고 RHEL 운영체제 명령어를 통해 지원을 받을 수 있는 점에서 도움이 되는 기능이 였습니다.

또한 현재 Red Hat 에서 제공하는 interactive lab 을 통해 위 기능을 직접 사용해보고 활용 방법에 대해 실습 할 수 있는 랩도 제공 중이오니 직접 실습을 해보시면 도움이 될 것 같습니다.

[+] https://www.redhat.com/en/interactive-labs/Solve-problems-with-Command-Line-Assistant

참고 자료

https://www.redhat.com/ko/technologies/linux-platforms/enterprise-linux-10/lightspeed

멀티 클라우드 환경에 호환 가능한 클라우드 이미지 개발 - 발표 자료

Fri, 21 Mar 2025 00:00:00 +0900

[OpenInfra Korea User Group - 3월 Meetup] 발표 자료 공유

2025/3/6 에 열린 OpenInfra Korea User Group 3월 Meetup 에서 “멀티 클라우드 환경에 호환 가능한 클라우드 이미지 개발”이라는 주제로 발표를 진행했습니다!

발표 영상은 아래 Youtube 를 참고하시면 됩니다.

OpenInfra Korea User Group : Link

[Linux] Bootc 사용법

Sun, 09 Mar 2025 00:00:00 +0900

bootc 이미지 빌드 및 관리 가이드

bootc 는 부팅 가능한 컨테이너의 핵심 요소이며, 부팅 가능한 컨테이너를 관리하기 위한 여러 systemd, timer 와 함께 제동 되는 CLI 도구 입니다.
또한 업데이트를 다운로드하고 대기 시키는 역할을 하고 시스템을 관리하고 시스템 상태 검사를 하는데 사용합니다.

https://docs.fedoraproject.org/en-US/bootc/getting-started/

bootc 를 이용한 부팅이 가능한 컨테이너를 사용하는 것에 대한 장점

DevOps를 위한 통합된 접근 방식

부팅 가능한 컨테이너는 Linux의 역할을 한 단계 더 발전시켜 GitOps 및 CI/CD(Continuous Integration/Continuous Delivery)를 포함한 컨테이너 기반 툴링과 개념을 통해 전체 OS를 관리할 수 있도록 합니다. 이 간소화된 접근 방식은 패치를 다른 위치에 푸시하거나 운영 팀과 애플리케이션 개발 주기 간의 격차를 메우는 경우 대규모로 Linux를 관리하는 과제를 해결하는 데 도움이 됩니다.
간소화된 보안

이미지 기반 시스템에는 수십 가지의 보안 이점이 있지만 OS가 컨테이너 이미지 형태로 제공된다는 사실을 강조하고 싶습니다. 즉, 패치, 검사, 검증 및 서명을 처리하기 위해 고급 컨테이너 보안 도구와 같은 컨테이너 보안의 지난 10년 간의 발전을 활용할 수 있습니다. 이제 커널, 드라이버, 부트로더 등에 컨테이너 보안 검사를 적용할 수 있습니다.
속도 및 생태계 통합

보안 이점과 마찬가지로 부팅 가능한 컨테이너는 컨테이너를 중심으로 등장한 도구와 기술의 광대한 생태계에 통합됩니다.
부팅 가능한 컨테이너를 사용하면 새로운 규모와 속도로 Linux 시스템을 빌드, 배포 및 관리할 수 있습니다. 부팅 가능한 컨테이너의 초기 채택자로부터 일관된 피드백은 이러한 모든 작업을 더 짧은 시간 내에 관리하기 위한 간소화된 툴체인을 관찰한다는 것입니다.

이번 포스팅에서는 bootc 이미지 빌드부터 관리까지 전체적인 내용을 다뤄보겠습니다.

bootc 이미지 빌드 및 관리

1. 기본 이미지 빌드

Containerfile을 이용하여 bootc 이미지를 빌드합니다.

# podman build -t bootc .
STEP 1/7: FROM quay.io/centos-bootc/centos-bootc:stream9
STEP 2/7: RUN dnf -y install httpd cloud-init plymouth vim && \
     systemctl enable httpd && \    
     systemctl enable cloud-init.service && \    
     mv /var/www /usr/share/www && \    
     echo 'd /var/log/httpd 0700 - - -' > /usr/lib/tmpfiles.d/httpd-log.conf && \
     sed -ie 's,/var/www,/usr/share/www,' /etc/httpd/conf/httpd.conf
STEP 3/7: RUN mkdir -p /usr/lib/bootc/kargs.d
--> 4f70d792d20d
STEP 4/7: RUN cat <<EOF >> /usr/lib/bootc/kargs.d/kcmdline.toml (kargs = ["console=ttyS0,114800n8","selinux=0"]...)
--> a7e112a51f79
STEP 5/7: RUN rm /usr/share/httpd/noindex -rf
--> 83c9cccb104d
STEP 6/7: COPY index.html /usr/share/www/html
--> 91dc066387f9
STEP 7/7: EXPOSE 80
COMMIT bootc
--> db1bdf3e68dd
Successfully tagged localhost/bootc:latest
db1bdf3e68dda4ab9365ad5571236d52c961447fc0cdb008f7090cc721d05158

2. 이미지 태깅 및 푸시

여러 버전의 이미지를 태깅하고 레지스트리에 푸시합니다.
테스트의 편의를 위해 ECR 을 사용하였으나, 사설 레포지토리 및 기타 솔루션을 사용 할 수 있습니다.

# podman tag bootc:latest public.ecr.aws/w4****s3/bootc:latest
# podman push public.ecr.aws/w4****s3/bootc:latest
Getting image source signatures
Copying blob 54cc565ad42f skipped: already exists
Copying blob 54cc565ad42f skipped: already exists
...

# podman tag bootc:latest public.ecr.aws/w4****s3/bootc:v1
# podman push public.ecr.aws/w4****s3/bootc:v1

# podman images
REPOSITORY                                TAG         IMAGE ID      CREATED        SIZE
public.ecr.aws/w4****s3/bootc             v1          db1bdf3e68dd  3 minutes ago  1.86 GB
public.ecr.aws/w4****s3/bootc             latest      db1bdf3e68dd  3 minutes ago  1.86 GB
localhost/bootc                           latest      db1bdf3e68dd  3 minutes ago  1.86 GB
quay.io/centos-bootc/centos-bootc         stream9     f9e21da0d9d0  2 weeks ago    1.57 GB
quay.io/centos-bootc/bootc-image-builder  latest      bfc3eaae8414  5 weeks ago    774 MB

3. 컨테이너로 실행 테스트

빌드된 이미지를 컨테이너로 실행하여 웹 서버 동작을 테스트합니다.

# podman run --rm -d --name test-web -p 80:80  public.ecr.aws/w4****s3/bootc:latest
b309f135c7d0d950dd86e2e263602770cada47c616911dc04b828afdc6f71886

# curl localhost:80
TEST INDEX v1

AMI 생성 프로세스

1. AMI 생성을 위한 설정

config.toml 설정 파일:

# cat config.toml
[[customizations.user]]
name = "centos"
password = "password"
key = "ssh-rsa AAAAB3Nz..."
groups = ["wheel"]

[[customizations.disk.partitions]]
mountpoint = "/"
minsize = "7 GiB"
label = "root"
fs_type = "xfs"

2. AMI 생성 스크립트

bootc-image-builder 를 이용하여 빌드한 컨테이너 이미지를 AMI 로 생성합니다.
bootc-image-builder 는 퍼블릭 클라우드 뿐만 아니라 다양한 환경에 적합한 이미지를 생성하고 변환하는 역할을 합니다.

create-ami.sh:

sudo podman run \
  --rm \
  -it \
  --privileged \
  --security-opt label=type:unconfined_t \
  -v $HOME/.aws:/root/.aws:ro \
  -v ./config.toml:/config.toml:ro \
  -v /var/lib/containers/storage:/var/lib/containers/storage \
  --env AWS_PROFILE=default \
  quay.io/centos-bootc/bootc-image-builder:latest \
  --type ami \
  --aws-ami-name http-bootc-ami \
  --aws-bucket s3test \
  --aws-region ap-northeast-2 \
  public.ecr.aws/w4****s3/bootc:latest

3. AMI 생성 실행 결과

# ./create-ami.sh
[/] Image building step
[4 / 4] Pipeline image [------------------------------------------------------------------------------------------------------------>] 100.00%
[10 / 10] Stage org.osbuild.selinux [----------------------------------------------------------------------------------------------->] 100.00%
Message: Build complete!
Uploading http-bootc-ami to s3test:dda70dae-aafb-4b31-9ddb-fcd2dfadec0a-http-bootc-ami
7.20 GiB / 7.20 GiB [------------------------------------------------------------------------------------------------>] 100.00% 201.82 MiB p/s
File uploaded to https://s3test.s3.ap-northeast-2.amazonaws.com/dda70dae-aafb-4b31-9ddb-fcd2dfadec0a-http-bootc-ami
Registering AMI http-bootc-ami
7.20 GiB / 7.20 GiB [------------------------------------------------------------------------------------------------------->] 100.00% 0 B p/s
7.20 GiB / 7.20 GiB [------------------------------------------------------------------------------------------------------->] 100.00% 0 B p/s
Deleted S3 object s3test:dda70dae-aafb-4b31-9ddb-fcd2dfadec0a-http-bootc-ami
AMI registered: ami-0526*************
Snapshot ID: snap-0ce7*************
7.20 GiB / 7.20 GiB [--------------------------------------------------------------------------------------------------] 100.00% 26.24 MiB p/s

4. 생성된 AMI 로 생성된 인스턴스의 파일시스템 확인

[root@ip-*********** ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           759M  516K  758M   1% /run
efivarfs        128K  3.4K  120K   3% /sys/firmware/efi/efivars
/dev/nvme0n1p3  7.8G  1.9G  5.9G  24% /sysroot
composefs       7.2M  7.2M     0 100% /
...

[root@ip-*********** ~]# lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0  7.2M  1 loop
zram0       252:0    0  3.7G  0 disk [SWAP]
nvme0n1     259:0    0    8G  0 disk
├─nvme0n1p1 259:1    0    1M  0 part
├─nvme0n1p2 259:2    0  200M  0 part /boot/efi
└─nvme0n1p3 259:3    0  7.8G  0 part /var
                                     /sysroot/ostree/deploy/default/var
                                     /etc
                                     /boot
                                     /sysroot

위와 같이 composefs 를 이용한 특수한 구성을 이용하는 운영체제로 시작됩니다.

bootc 운영 관리

1. bootc 기본 명령어

# bootc --help
Deploy and transactionally in-place with bootable container images.

Commands:
  upgrade      Download and queue an updated container image to apply
  switch       Target a new container image reference to boot
  rollback     Change the bootloader entry ordering
  edit         Apply full changes to the host specification
  status       Display status
  usr-overlay  Adds a transient writable overlayfs on `/usr`
  install      Install the running container to a target
  container    Operations which can be executed as part of a container build

2. 시스템 상태 확인 및 업그레이드

bootc 를 통한 이미지 관리 체계

상태 확인:

# bootc status
No staged image present
Current booted image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e
No rollback image present

업그레이드 실행:

레포지토리에 있는 최신 버전의 이미지를 Pull 하고, 부팅을 위해 staged image 로 준비합니다.

# bootc upgrade
layers already present: 0; layers needed: 72 (1.1 GB)
Fetched layers: 1.01 GiB in 87 seconds (11.86 MiB/s)
  Deploying: done (4 seconds)       Queued for next boot: public.ecr.aws/w4****s3/bootc:latest
  Version: stream9.20250129.0
  Digest: sha256:01fe8dea52017556f85932f5debb142cd48bc5d9162a23030239ebf64f7b2b1e
Total new layers: 72    Size: 1.1 GB
Removed layers:   72    Size: 1.9 GB
Added layers:     72    Size: 1.1 GB

# bootc status
Current staged image: public.ecr.aws/w4****s3/bootc:latest      <<----!!!
    Image version: stream9.20250129.0 (2025-02-17 06:52:27.362887944 UTC)
    Image digest: sha256:01fe8dea52017556f85932f5debb142cd48bc5d9162a23030239ebf64f7b2b1e
Current booted image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e
No rollback image present

재부팅 후 :

# bootc status
No staged image present
Current booted image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 06:52:27.362887944 UTC)
    Image digest: sha256:01fe8dea52017556f85932f5debb142cd48bc5d9162a23030239ebf64f7b2b1e
Current rollback image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e

# curl localhost
TEST INDEX v2

3. 이미지 롤백 및 전환

롤백 실행:

# bootc rollback
Next boot: rollback deployment

# reboot

재부팅 후:

# bootc status
No staged image present
Current booted image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e
Current rollback image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 06:52:27.362887944 UTC)
    Image digest: sha256:01fe8dea52017556f85932f5debb142cd48bc5d9162a23030239ebf64f7b2b1e

# curl localhost
TEST INDEX v1

특정 이미지로 전환:

# bootc switch public.ecr.aws/w4****s3/bootc:v3
layers already present: 71; layers needed: 1 (230 bytes)
Fetched layers: 230 B in 21 seconds (10 B/s)
  Deploying: done (4 seconds)           Queued for next boot: public.ecr.aws/w4****s3/bootc:v3
  Version: stream9.20250129.0
  Digest: sha256:eeb8035601e584bf5cb21f5906a9c5eda097c0891e52d427017b5253cb4d0191
  
# bootc status
Current staged image: public.ecr.aws/w4****s3/bootc:v3
    Image version: stream9.20250129.0 (2025-02-17 07:00:14.550632920 UTC)
    Image digest: sha256:eeb8035601e584bf5cb21f5906a9c5eda097c0891e52d427017b5253cb4d0191
Current booted image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e
Current rollback image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 06:52:27.362887944 UTC)
    Image digest: sha256:01fe8dea52017556f85932f5debb142cd48bc5d9162a23030239ebf64f7b2b1e
    
>> 재부팅 진행

# bootc status
No staged image present
Current booted image: public.ecr.aws/w4****s3/bootc:v3
    Image version: stream9.20250129.0 (2025-02-17 07:00:14.550632920 UTC)
    Image digest: sha256:eeb8035601e584bf5cb21f5906a9c5eda097c0891e52d427017b5253cb4d0191
Current rollback image: public.ecr.aws/w4****s3/bootc:latest
    Image version: stream9.20250129.0 (2025-02-17 05:03:12.502233712 UTC)
    Image digest: sha256:326be670c2b10bdb187fbbcb9b28fbcde66c9cbe1d32915478089af9478d373e

# curl localhost
TEST INDEX v3

파일시스템 관리

1. 영구 저장소 사용

/var 디렉토리는 재부팅 후에도 유지되는 영구 저장소입니다:

[root@ip-172-31-1-74 ~]# mkdir /var/data

[root@ip-172-31-1-74 ~]# dd if=/dev/zero of=/var/data/bigfile count=1 bs=1G
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.29051 s, 250 MB/s

[root@ip-172-31-1-74 ~]# ls -l /var/data/
total 1048576
-rw-r--r-- 1 root root 1073741824 Feb 17 07:11 bigfile

[root@ip-172-31-1-74 ~]# reboot

[root@ip-172-31-1-74 ~]# uptime
 07:13:15 up 0 min,  1 user,  load average: 0.07, 0.02, 0.00

재부팅 후에도 데이터 유지:

[root@ip-172-31-1-74 ~]# ls -l /var/data
total 1048576
-rw-r--r-- 1 root root 1073741824 Feb 17 07:11 bigfile

2. /usr 임시 작업

bootc usr-overlay를 사용한 임시 쓰기 작업:

# echo "Enabled USR" > /usr/share/www/html/index.html
-bash: /usr/share/www/html/index.html: Read-only file system

# bootc usr-overlay
Development mode enabled.

# echo "Enabled USR" > /usr/share/www/html/index.html
# curl localhost
Enabled USR

재부팅 후 원래 상태로 복구:

# uptime
 07:16:11 up 1 min,  1 user,  load average: 0.03, 0.01, 0.00
# curl localhost
TEST INDEX v3

자동 업데이트 관리

1. 업데이트 타이머 설정

타이머 상태 확인:

# systemctl status bootc-fetch-apply-updates.timer
● bootc-fetch-apply-updates.timer - Apply bootc updates
     Loaded: loaded (/usr/lib/systemd/system/bootc-fetch-apply-updates.timer; disabled; preset: disabled)
     Active: active (waiting) since Wed 2025-02-26 12:04:05 UTC; 1min 21s ago
      Until: Wed 2025-02-26 12:04:05 UTC; 1min 21s ago
    Trigger: Wed 2025-02-26 14:21:43 UTC; 2h 16min left
   Triggers: ● bootc-fetch-apply-updates.service
       Docs: man:bootc(8)

Feb 26 12:04:05 localhost systemd[1]: Started Apply bootc updates.

2. 업데이트 시간 설정

주간 업데이트 설정:

# systemctl edit bootc-fetch-apply-updates.timer
[Timer]
OnCalendar=Sun *-*-* 00:00:00

Timer 구문은 아래와 같은 방법으로 구문 확인 가능합니다.

# systemd-analyze calendar --iterations 5 "Sun *-*-* 00:00:00"
Normalized form: Sun *-*-* 00:00:00
    Next elapse: Sun 2025-03-02 00:00:00 UTC
       From now: 2 days left
       Iter. #2: Sun 2025-03-09 00:00:00 UTC
       From now: 1 week 2 days left
       Iter. #3: Sun 2025-03-16 00:00:00 UTC
       From now: 2 weeks 2 days left
       Iter. #4: Sun 2025-03-23 00:00:00 UTC
       From now: 3 weeks 2 days left
       Iter. #5: Sun 2025-03-30 00:00:00 UTC
       From now: 1 month 0 days left

3. 자동 업데이트

bootc-fetch-apply-updates 의 기본 서비스 구성:

# cat /usr/lib/systemd/system/bootc-fetch-apply-updates.service
[Unit]
Description=Apply bootc updates
Documentation=man:bootc(8)
ConditionPathExists=/run/ostree-booted

[Service]
Type=oneshot
ExecStart=/usr/bin/bootc update --apply --quiet      <<---!! 자동 재부팅 설정 되어 있음.

# systemctl list-timers
NEXT                        LEFT        LAST                        PASSED       UNIT                            ACTIVATES
Thu 2025-02-27 14:30:38 UTC 8h left     Wed 2025-02-26 14:30:38 UTC 15h ago      systemd-tmpfiles-clean.timer    systemd-tmpfiles-clean.service
Fri 2025-02-28 00:00:00 UTC 17h left    Thu 2025-02-27 00:00:02 UTC 6h ago       logrotate.timer                 logrotate.service
Sun 2025-03-02 00:00:00 UTC 2 days left Thu 2025-02-27 06:09:29 UTC 1min 23s ago bootc-fetch-apply-updates.timer bootc-fetch-apply-updates.service

3 timers listed.
Pass --all to see loaded but inactive timers, too.

참고: journalctl 을 이용한 업데이트 로그 확인

  Feb 27 01:22:27 hostname bootc[1699]: Fetching ostree-unverified-registry:public.ecr.aws/w4****s3/bootc:latest
  Feb 27 01:22:28 hostname bootc[1699]: No changes in public.ecr.aws/w4****s3/bootc:latest
  Feb 27 01:22:28 hostname bootc[1699]: No update available.

4. 자동 업데이트 비활성화

# systemctl mask bootc-fetch-apply-updates.timer
Created symlink /etc/systemd/system/bootc-fetch-apply-updates.timer → /dev/null

참고 자료

[Linux] mount-s3 설치 및 사용

Fri, 27 Dec 2024 00:00:00 +0900

`mount-s3` 설치 및 사용

설치

[root@ip-172-31-5-165 ~]# yum -y install https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm

...
Installed:
  mount-s3.x86_64 0:1.0.0-1

Dependency Installed:
  fuse.x86_64 0:2.9.2-11.amzn

aws configure

[root@ip-172-31-5-165 ~]# aws configure
AWS Access Key ID [None]: ******************
AWS Secret Access Key [None]: ******************
Default region name [None]: ap-northeast-2
Default output format [None]: json

[root@ip-172-31-5-165 ~]# aws s3 ls | tail -n1
2023-01-17 01:12:23 s3fsmounttest

mount

[root@ip-172-31-5-165 ~]# mount-s3 s3fsmounttest /root/test
bucket s3fsmounttest is mounted at /root/test

[root@ip-172-31-5-165 ~]# df
Filesystem     1K-blocks    Used Available Use% Mounted on
devtmpfs          479016       0    479016   0% /dev
tmpfs             487796       0    487796   0% /dev/shm
tmpfs             487796     412    487384   1% /run
tmpfs             487796       0    487796   0% /sys/fs/cgroup
/dev/xvda1       8376300 1806468   6569832  22% /
tmpfs              97560       0     97560   0% /run/user/1000

[root@ip-172-31-5-165 ~]# mount | grep test
mountpoint-s3 on /root/test type fuse (rw,nosuid,nodev,noatime,user_id=0,group_id=0,default_permissions)

테스트

[root@ip-172-31-5-165 ~]# cp mount-s3.rpm /root/test/
[root@ip-172-31-5-165 ~]# ls -la /root/test
total 10189
drwxr-xr-x 2 root root        0 Aug 10 04:31 .
dr-xr-x--- 5 root root      147 Aug 10 04:31 ..
-rw-r--r-- 1 root root 10432224 Aug 10 04:31 mount-s3.rpm
-rw-r--r-- 1 root root       68 May 11 04:01 prj.txt

[root@ip-172-31-5-165 ~]# aws s3 ls s3testfsmount
2023-08-10 04:31:57   10432224 mount-s3.rpm
2023-05-11 04:01:01         68 prj.txt