가이드

작성자 Matt Connor 2026-08-19 · 업데이트됨 2026-08-21

서버용 불변 리눅스 배포판 비교: Fedora CoreOS, Talos

Q: 불변 서버에는 어떻게 패키지를 설치합니까?

이미지에 패키지를 추가한 뒤 재배포해야 합니다. bootc의 경우 Containerfile에 RUN dnf -y install ... 줄을 추가하고, 다시 빌드하여 푸시한 뒤 서버에서 sudo bootc upgrade --apply을 실행합니다. Fedora CoreOS는 sudo rpm-ostree install을 사용하여 패키지를 계층화(layering)하고 재부팅할 수 있지만, 향후 업데이트 시마다 해당 패키지를 다시 적용해야 하는 비용이 발생합니다. Flatcar와 Talos에는 패키지 관리자가 없으므로 컨테이너를 사용해야 합니다. bootc 호스트에서 일회성 디버깅 도구가 필요하다면 sudo bootc usr-overlay를 사용하여 다음 재부팅 시 사라지는 쓰기 가능한 /usr 환경을 구성할 수 있습니다.

Fedora CoreOS, Flatcar, Talos 등 이미지 기반 운영 체제의 작동 원리를 설명합니다. 서버에서 패키지 관리자 대신 이미지를 교체하는 방식의 장단점과 구성 드리프트를 방지하는 불변 시스템의 실질적인 운영 환경을 분석합니다.

불변(Immutable) Linux 배포판이란 무엇인가

불변 Linux 배포판은 운영 체제를 하나의 이미지로 제공하므로, 시스템을 제자리에서 패치하는 대신 통째로 교체합니다. 실행 중인 시스템에서 apt upgrade를 사용하여 /usr 아래의 파일을 다시 쓰는 방식은 존재하지 않습니다. 새로운 이미지를 빌드하거나 가져오면, 시스템은 이를 현재 실행 중인 이미지 옆에 준비해 두었다가 다음 재부팅 시 활성 이미지를 교체합니다. 이전 이미지는 디스크에 그대로 남아 있으므로, 잘못된 업데이트를 되돌리는 방법은 재부팅뿐입니다.

"불변(immutable)"이라는 용어는 다소 과장된 측면이 있습니다. 물리적으로 root 사용자가 디스크에 쓰는 것을 막을 방법은 없습니다. 이러한 시스템은 시스템 디렉터리를 읽기 전용으로 마운트하고 해당 디렉터리의 소유권을 이미지에 부여하는 방식으로 작동합니다. 영구 데이터는 /var에 저장됩니다. 기기별 설정은 /etc에 위치합니다. /usr 아래의 모든 것은 이미지에 귀속되며, 이것이 동일한 이미지 태그를 실행하는 두 서버가 동일한 시스템 파일을 유지하는 이유입니다.

Red Hat에서 사용하는 두 가지 모델 명칭이 가장 명확합니다. 바로 패키지 모드(package mode)와 이미지 모드(image mode)입니다. 패키지 모드는 실행 중인 시스템과 이를 수정하는 패키지 관리자의 조합입니다. 이미지 모드는 외부에서 빌드 단계를 거쳐 아티팩트를 생성하고, 서버는 지정된 아티팩트로 부팅하는 역할만 수행합니다. 아래의 모든 내용은 이 한 가지 차이점에서 비롯됩니다.

서버에서 읽기 전용 시스템이 중요한 이유

2년 동안 운영된 서버에는 아무도 기록하지 않은 역사가 쌓여 있습니다. 급하게 처리했던 저녁 시간의 make install 작업, 특정 패키지 하나를 설치하려고 추가한 서드파티 저장소, 장애 대응 중에 수정하고는 구성 관리 도구에 다시 반영하지 않은 설정 파일 등이 그 예입니다. 이를 구성 드리프트(configuration drift)라고 하며, 기록에 의존해 "동일한" 서버를 다시 구축할 때마다 동작이 달라지는 주된 원인이 됩니다. 기록에는 의도가 담겨 있지만, 디스크에는 실제 상태가 담겨 있기 때문입니다.

이미지 모드는 드리프트가 발생하는 지점을 제거합니다. /usr은 런타임에 읽기 전용으로 동작하므로, 수동으로 설치를 시도하면 즉시 실패하거나 명령 한 번으로 나열할 수 있는 레이어로 기록됩니다. 이로써 두 서버 간의 차이를 고고학적 발굴 작업 없이도 명확하게 확인할 수 있습니다. 이는 일반적인 리눅스 서버 유지보수 체크리스트가 규율을 통해 해결하려는 문제를 파일 시스템 수준에서 직접 처리하는 방식입니다.

롤백은 재부팅이며, 이것이 이 모델의 핵심입니다

이 모델이 상정하는 장애는 이미 문서화한 사례, 즉 커널 업데이트 후 부팅되지 않는 VPS와 같습니다. 패키지 모드에서는 제공자의 복구 콘솔을 통해 복구합니다. 디스크를 마운트하고 chroot로 진입한 뒤, 수동으로 커널 패키지를 제거해야 합니다. 부트로더가 이전 커널을 보관하기 때문에 이 방법이 통하지만, 버전 관리가 되는 것은 커널뿐입니다. 같은 트랜잭션으로 설치된 glibc 업데이트나 systemd 변경 사항은 이미 적용된 상태이며, 이를 한 번에 되돌릴 수 있는 단일 명령은 없습니다.

이미지 모드에서는 시스템 전체가 하나의 단위입니다. bootc 호스트에서는 다음과 같이 처리합니다:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback은 부트로더 순서를 이전 부팅 항목으로 되돌립니다. 이는 한 시간 전에 실행 중이던 커널과 사용자 공간을 포함한 이미지입니다. 이전 이미지는 디스크에 그대로 남아 있으므로, 아무것도 새로 다운로드하거나 빌드하지 않습니다.

Fedora CoreOS도 다른 명칭을 사용하지만 같은 방식을 따릅니다:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

먼저 Zincati를 중지하십시오. Zincati는 Fedora CoreOS 머신을 최신 릴리스로 유지하는 에이전트이므로, 그대로 두면 방금 되돌린 업데이트를 다시 준비하게 됩니다. -r은 롤백이 준비되면 재부팅을 수행합니다. 신뢰하는 배포판이 가비지 컬렉션(garbage collected)으로 삭제되지 않게 하려면 다음을 수행하십시오:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status는 부트로더가 제공할 순서대로 배포판 목록을 보여주며, 현재 실행 중인 항목에 점(dot)을 표시하고 고정(pinned)된 항목에는 Pinned: yes을 표시합니다.

Talos는 워크스테이션에서 단일 API 호출로 이를 수행합니다:

talosctl rollback --nodes 10.20.30.40

Flatcar는 두 개의 /usr 파티션을 유지하며 그 사이를 전환합니다. 각 슬롯은 파티션 테이블에 우선순위와 시도 횟수(try counter)를 가지며, 성공적으로 부팅되지 않는 슬롯은 시도 횟수가 소진되어 부트로더가 다른 슬롯을 선택하게 됩니다. 현재 어떤 슬롯을 사용 중인지, 그리고 해당 슬롯이 정상으로 표시되었는지 확인하십시오:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

정상적으로 실행 중인 슬롯은 priority=1 tries=0 successful=1를 포함하는 줄을 출력합니다. 일치하는 줄이 없다면 현재 슬롯이 아직 확인되지 않은 상태이며, 이는 업데이트 후 첫 번째 정상 부팅을 기다리는 머신의 상태입니다.

"패키지 설치"를 대체하는 방법: bootc와 Containerfile

bootc는 이 패턴을 일반화한 도구입니다. 이 도구는 OCI(Open Container Initiative) 컨테이너 이미지를 사용하여 트랜잭션 방식의 제자리(in-place) 운영체제 업데이트를 수행하며, CNCF Sandbox 프로젝트입니다. 서버 자체가 하나의 Containerfile이 되는 셈입니다. 2026년 8월 기준으로 Fedora 베이스 이미지는 quay.io/fedora/fedora-bootc:44이며, CentOS Stream 베이스는 quay.io/centos-bootc/centos-bootc:stream10입니다.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

다른 이미지와 마찬가지로 빌드하고 푸시합니다.

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

그런 다음 서버에서 다음을 실행합니다.

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade는 이미지 소스를 쿼리하고 다음 부팅을 위해 새 이미지를 대기열에 추가합니다. --check은 업데이트 가능 여부를 보고하며 아무것도 변경하지 않습니다. --apply은 해당 이미지로 재부팅합니다. bootc switch registry.example.com/edge/web:next은 /etc와 /var을 보존하면서 시스템이 다른 이미지를 가리키도록 변경합니다. 이를 통해 서버를 재설치하지 않고도 이미지 스트림 간에 전환할 수 있습니다.

자동 업데이트를 원한다면 프로젝트에서 제공하는 타이머를 활성화하십시오.

sudo systemctl enable --now bootc-fetch-apply-updates.timer

이것이 Ubuntu의 자동 업그레이드와 Rocky 및 Alma의 dnf-automatic에 대한 이미지 모드 방식의 해답입니다. 차이점은 적용되는 결과물에 있습니다. 패키지 모드 타이머는 그날 밤 저장소에 있는 버전을 적용하므로, 결과적으로 각 머신마다 설치된 패키지 구성이 조금씩 달라질 수 있습니다. 반면 이미지 모드 타이머는 이미 다른 곳에서 부팅하여 검증된 단일 아티팩트를 적용합니다.

이 Containerfile로부터 두 가지 빌드 규칙이 도출됩니다. 쓰기 가능한 데이터는 /var 아래에 위치해야 하므로, 설치 디렉터리 내부에 쓰기를 시도하는 소프트웨어는 빌드 시점에 심볼릭 링크를 생성하거나 systemd BindPaths= 라인을 추가해야 합니다. 또한 /etc은 업데이트 시 3-way 병합(three-way merged)됩니다. 즉, 수정하지 않은 파일은 이미지의 새 버전으로 업데이트되지만, 로컬에서 편집한 파일은 그대로 유지됩니다.

라이브 서버에서 일회성 디버깅 세션을 위해 도구가 필요한 경우 다음을 사용합니다.

sudo bootc usr-overlay
sudo dnf -y install strace

이 명령은 /usr 위에 일시적인 쓰기 가능 오버레이를 추가하며, 다음 재부팅 시 삭제됩니다. 이는 문제를 조사하기 위한 용도이지 해결하기 위한 용도가 아닙니다. 이 방식으로는 커널을 변경할 수 없으며, 설치한 모든 것은 설계상 재부팅 시 사라집니다.

Fedora CoreOS: 한 번의 프로비저닝, 영구적인 업데이트

Fedora CoreOS는 대화형 설치 프로그램을 제공하지 않습니다. Butane YAML 파일을 작성하고 이를 Ignition JSON으로 변환한 뒤, 첫 부팅 시점에 해당 파일을 시스템에 전달해야 합니다.

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition은 첫 부팅 시 initramfs 단계에서만 실행됩니다. 이는 cloud-init에 익숙한 사용자들이 자주 실수하는 부분입니다. 설정 파일에 SSH 키가 포함되어 있지 않으면 시스템에 접속할 방법이 없으며, 이 경우 처음부터 다시 프로비저닝해야 합니다. 중요한 서버에 적용하기 전에 테스트용 머신에서 설정을 먼저 검증하십시오.

라이브 환경에서 디스크로 설치하는 방법은 다음과 같습니다.

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

업데이트는 기본적으로 자동 수행됩니다. 사용자는 업데이트 여부가 아닌 시점을 제어합니다. /etc/zincati/config.d/55-updates-strategy.toml 경로에 주기적 업데이트 전략을 정의하는 TOML 파일을 생성하십시오.

[updates]
strategy = "periodic"

해당 전략 하에서 배열 테이블 항목마다 유지보수 창을 하나씩 추가합니다. 각 창은 이중 대괄호로 감싼 updates.periodic.window 헤더로 시작하며, 그 아래에 다음 세 가지 키를 작성합니다.

days: "Sat" 및 "Sun"와 같은 요일 이름 목록입니다.
start_time: 유지보수 창이 시작되는 시간이며, "22:30" 형식으로 작성합니다.
length_minutes: 60과 같이 창이 유지되는 시간입니다.

위 시간은 모두 UTC 기준입니다. 업데이트를 완전히 중단하려면 sudo systemctl disable --now zincati.service 명령을 실행하십시오. 이 경우 패치 일정에 대한 책임은 전적으로 사용자에게 있습니다.

패키지 레이어링은 탈출구 역할을 합니다.

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

이 명령은 패키지가 추가된 새로운 배포판을 빌드하며, 변경 사항은 재부팅 후에만 적용됩니다. 비용은 나중에 발생합니다. 레이어링된 패키지 세트는 새로운 베이스 이미지가 적용될 때마다 다시 설치되므로, 업데이트 당일에 저장소에서 패키지가 사라지면 업데이트가 실패합니다. Fedora 공식 문서에서는 중요한 작업은 컨테이너를 사용하고, 운영체제 자체를 변경해야 하는 경우에는 bootc 이미지를 사용할 것을 권장합니다.

Flatcar Container Linux: 패키지 관리자가 전혀 없음

Flatcar는 CoreOS Container Linux의 계보를 잇는 운영체제로, 범용 옵션 중 가장 엄격한 구성을 취합니다. 의존할 수 있는 패키지 관리자가 없습니다. 실행하는 모든 것은 컨테이너입니다. 프로비저닝은 Fedora CoreOS와 동일하게 Ignition을 사용합니다. 업데이트는 위에서 설명한 두 개의 A/B /usr 파티션을 통해 이루어지며, update_engine에 의해 구동되고 locksmithd이 재부팅 시점을 결정합니다.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT 상태는 패시브 슬롯에 이미 새 이미지가 담겨 있으며 재부팅만 남았음을 의미합니다. 기본 재부팅 전략은 5분 지연을 포함한 reboot이므로, 별도의 설정을 하지 않으면 단일 운영 VPS는 자체 일정에 따라 재시작됩니다. /etc/flatcar/update.conf에서 재부팅 허용 시간을 설정하십시오:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off 설정은 재부팅을 사용자가 직접 수행하도록 합니다. 같은 파일 내의 SERVER=disabled는 업데이트 확인을 완전히 중단시킵니다. 클러스터 환경에서는 REBOOT_STRATEGY=etcd-lock과 locksmithctl set-max 4를 조합하여 한 번에 재부팅할 수 있는 노드 수를 제한함으로써, 업데이트로 인해 전체 서비스가 동시에 중단되는 일을 방지할 수 있습니다.

Talos Linux: 셸, SSH, 콘솔 없음

Talos는 네 가지 운영체제 중 가장 범위가 좁으며 그 목적이 가장 명확합니다. Talos는 Kubernetes 노드를 실행하기 위해 설계되었습니다. SSH 데몬, 셸, 콘솔 로그인이 존재하지 않습니다. 모든 작업은 워크스테이션에서 talosctl를 사용하여 gRPC API를 호출하는 방식으로 이루어지며, 이는 git으로 관리하는 머신 설정(machine config)을 기반으로 합니다.

talosctl upgrade --nodes 10.20.30.40 \
  --image ghcr.io/siderolabs/installer:v1.10.6

태그를 이동하려는 릴리스 버전으로 교체하십시오. 업그레이드는 이전 커널과 OS 이미지를 유지하는 A-B 방식을 사용하므로, 새 버전으로 부팅에 실패하면 Talos가 자동으로 이전 상태로 롤백합니다. 셸이 없기 때문에 디버깅 방식은 기존과 다릅니다. 서버에 직접 접속하여 journalctl을 사용하는 대신 talosctl logs과 talosctl dmesg을 사용해야 합니다.

워크로드가 Kubernetes가 아니라면 Talos는 적합한 선택이 아닙니다. 만약 Kubernetes 환경이라면, Talos는 "누군가 노드에 로그인하여 설정을 변경했다"는 유형의 사고를 원천 차단함으로써 전체 장애 범주를 제거합니다.

VPS 임대 사용자가 실제로 포기해야 하는 것들

실행 중인 시스템에 대한 임의 설치. 이것이 가장 큰 차이점입니다. 새벽 2시에 장애가 발생했을 때 sudo apt install htop를 사용하는 것은 불가능합니다. bootc를 사용하면 재부팅 시 사라지는 일시적인 오버레이가 생성됩니다. Fedora CoreOS는 재부팅이 필요한 계층화된 배포 방식을 사용합니다. Flatcar와 Talos는 아예 아무것도 제공하지 않습니다.

이전에는 없던 빌드 파이프라인. 패키지를 추가하려면 Containerfile을 수정하고, 이미지를 빌드하고, 레지스트리에 푸시한 뒤 서버를 롤링해야 합니다. 파이프라인이 이미 구축되어 있다면 비용이 적게 들지만, 그렇지 않다면 이를 구축하는 것은 상당한 작업입니다. 또한 서버가 접근할 수 있는 레지스트리가 필요하며, 이는 별도로 운영하거나 비용을 지불해야 하는 또 하나의 서비스가 됩니다.

커널 모듈. 커널은 이미지에서 제공되므로, 실행 중인 커널에 맞춰 컴파일된 모듈은 다음 업데이트 시 유지되지 않습니다. 트리 외부(out-of-tree) 모듈과 DKMS(dynamic kernel module support) 패키지는 해당 이미지의 커널에 맞춰 이미지 내부에 빌드해야 합니다. 기본 이미지에 포함되지 않은 모듈이 필요한 경우, 이는 설치 문제가 아니라 빌드 문제가 됩니다.

벤더 및 제공업체 에이전트. 모니터링 및 백업 에이전트는 일반적으로 /usr에 기록하고 유닛을 활성화하는 설치 스크립트가 포함된 .deb 또는 .rpm 형태로 제공됩니다. 읽기 전용 시스템에서는 해당 스크립트가 실패합니다. 일부 벤더는 컨테이너를 배포하거나 이미지 모드 설치 방법을 문서화하지만, 그렇지 않은 곳도 많습니다. 도입을 결정하기 전에 이를 확인하십시오. 모니터링할 수 없는 서버군은 설정이 틀어진 서버군보다 더 위험하기 때문입니다.

이미지 자체. 대부분의 VPS 제어판은 Ubuntu나 Debian 옆에 Fedora CoreOS, Flatcar, Talos를 나열하지 않습니다. 사용자가 직접 디스크를 제공해야 하며, 이에 대해서는 다음 섹션에서 다룹니다.

임대 VPS에 설치하기

먼저 제공업체와 관련하여 두 가지를 확인하십시오. VNC나 시리얼 콘솔과 같은 대역 외(out-of-band) 콘솔 접근 권한이 있는지, 그리고 구조(rescue) 시스템으로 부팅할 수 있는지 확인해야 합니다. 콘솔이 없으면 서버가 다시 켜지지 않을 때 5분 만에 해결할 문제를 고객 지원 티켓으로 넘겨야 합니다.

제공업체가 사용자 지정 이미지를 허용한다면, 공급업체의 raw 또는 qcow2 이미지를 업로드하는 것으로 작업이 완료됩니다. 그렇지 않다면 구조 시스템에서 직접 디스크에 기록해야 합니다. Flatcar는 이를 위해 자체 포함된 스크립트를 제공하며, 모든 Linux 환경에서 실행할 수 있습니다.

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

이 스크립트는 작업 도중 대상 장치의 파티션을 다시 나누므로, 교체하려는 서버가 아닌 구조 시스템에서 실행해야 합니다. 장치에 최소 8 GB의 사용 가능한 공간이 필요하며, 구조 환경은 bash, bzip2 또는 lbzip2, lsblk, wget, udevadm, gpg 및 gawk을 제공해야 합니다. ignition.json에는 SSH 키가 포함되어 있어야 하며, 그렇지 않으면 설치된 시스템에 접속할 방법이 없습니다.

Fedora CoreOS도 동일한 형태를 가지며, 설치 프로그램은 컨테이너로 실행됩니다.

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

실행하기 전에 lsblk로 장치 이름을 확인하십시오. 잘못된 장치에 기록하면 해당 장치의 모든 데이터가 삭제되며, 확인 메시지도 표시되지 않습니다.

bootc는 실행 중인 Linux 시스템을 현장에서 직접 변환하므로 구조 모드를 건너뛸 수 있는 유일한 경로를 제공합니다.

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

실행하기 전에 사용 중인 기본 이미지의 문서를 읽고, 폐기해도 상관없는 서버에서 먼저 시도해 보십시오. 재부팅 후에는 시스템이 해당 이미지를 실행하게 되며, 기존에 설치되어 있던 패키지 세트는 모두 사라집니다.

불변 서버를 운영해야 하는 대상과 그렇지 않은 대상

서버를 가축(cattle)처럼 관리한다면 이 방식이 적합합니다. 하나의 레시피로 여러 대의 머신을 생성하는 경우, 1시간만 유지되는 CI(continuous integration) 러너, 수리 대신 교체하는 k3s나 Kubernetes 노드가 이에 해당합니다. 서버가 고장 났을 때 "삭제하고 새로 만든다"는 대응이 가능한 모든 환경이 여기에 속합니다. 또한 감사인에게 머신에서 실행 중인 내용을 증명해야 할 때, 패키지 목록이 아닌 이미지 다이제스트(image digest)로 답변할 수 있어 유리합니다.

직접 관리하는 VPS 한 대에 세 가지 서비스를 운영하고, 필요할 때마다 소프트웨어를 설치하며, 빌드 파이프라인이 없는 경우에는 이 방식을 권장하지 않습니다. 이미지 모드는 작업을 없애주는 것이 아니라, 서버에서 빌드 과정으로 옮기는 것뿐이며 그 대가로 레지스트리와 파이프라인을 구축해야 합니다. 작업을 처리할 환경이 갖춰져 있다면 동일한 서버를 유지하고 재부팅만으로 롤백할 수 있는 이점을 얻습니다. 하지만 그렇지 않다면 잘 작동하던 서버에 복잡한 요소만 추가하여 새벽 2시의 장애 대응을 더 어렵게 만들 뿐입니다.

지루하지만 안정적인 중간 지점은 여전히 유효합니다. 자동 보안 업데이트가 적용된 일반적인 배포판을 사용하고, 실제로 연습해 본 재빌드 절차를 갖추는 것입니다. 어떤 기반을 선택할지는 별개의 결정이며, VPS에서 실행할 OS 선택하기에서 다룹니다. 이미지 모드는 소프트웨어를 머신에 전달하는 방법에 대한 아주 오래된 논쟁의 최신 버전일 뿐이며, Linux 배포판의 역사는 대체로 그 논쟁이 반복되는 과정입니다.

FAQ

불변(immutable) 리눅스 배포판은 정말로 불변입니까?

아니요, 이름 때문에 혼동이 발생합니다. root 사용자는 여전히 디스크에 쓰기 작업을 할 수 있습니다. 실제로는 런타임에 /usr이 읽기 전용으로 마운트되고 다음 이미지로 전체가 교체되는 방식이며, /etc와 /var는 쓰기 가능 상태로 유지되어 업데이트 후에도 데이터가 보존됩니다. /usr 하위에서 수행한 변경 사항은 시점에 따라 거부되거나 다음 업데이트 시 삭제되므로, 결과적으로 시스템 디렉터리는 이미지가 변경될 때만 바뀝니다.

Fedora CoreOS나 Flatcar를 지원하지 않는 VPS에서 실행할 수 있습니까?

제공자가 구조(rescue) 시스템과 콘솔 접근 권한을 제공한다면 대개 가능합니다. 구조 모드로 부팅한 뒤 배포판의 디스크 이미지를 블록 장치에 기록하고 재부팅하면 됩니다. Flatcar의 flatcar-install 스크립트는 어떤 리눅스 환경에서든 이 작업을 수행하며, Fedora CoreOS는 동일한 방식으로 실행할 수 있는 coreos-installer 컨테이너를 제공합니다. 두 경우 모두 SSH 키가 포함된 Ignition 파일이 필요합니다. 최초 부팅 시 비밀번호를 입력하는 과정이 없기 때문입니다. 콘솔 접근 권한이 없다면 시도하지 마십시오. 서버가 다시 부팅되지 않을 경우 확인할 방법이 전혀 없습니다.

불변 서버에는 어떻게 패키지를 설치합니까?

이미지에 패키지를 추가한 뒤 재배포해야 합니다. bootc의 경우 Containerfile에 RUN dnf -y install ... 줄을 추가하고, 다시 빌드하여 푸시한 뒤 서버에서 sudo bootc upgrade --apply을 실행합니다. Fedora CoreOS는 sudo rpm-ostree install을 사용하여 패키지를 계층화(layering)하고 재부팅할 수 있지만, 향후 업데이트 시마다 해당 패키지를 다시 적용해야 하는 비용이 발생합니다. Flatcar와 Talos에는 패키지 관리자가 없으므로 컨테이너를 사용해야 합니다. bootc 호스트에서 일회성 디버깅 도구가 필요하다면 sudo bootc usr-overlay를 사용하여 다음 재부팅 시 사라지는 쓰기 가능한 /usr 환경을 구성할 수 있습니다.

이미지 모드는 커널 업데이트 후 부팅되지 않는 VPS 문제를 해결해 줍니까?

복구 작업을 구조 콘솔 작업에서 단순 재부팅으로 바꿔줍니다. 이전 이미지, 커널, 사용자 공간이 디스크에 그대로 남아 있으므로 sudo bootc rollback나 sudo rpm-ostree rollback -r를 통해 이전 상태로 복구할 수 있습니다. Talos와 Flatcar는 한 단계 더 나아가, 새로운 부팅 슬롯이 실패할 경우 자동으로 롤백을 수행합니다. 부팅 항목은 성공적으로 한 번 부팅된 후에야 기본값으로 설정되기 때문입니다. 물론 이것이 잘못된 업데이트 자체를 막아주지는 않지만, 복구 비용을 크게 낮춰줍니다.

서버용으로 어떤 불변 배포판을 선택해야 합니까?

컨테이너 이미지처럼 빌드하여 기존 장비에 설치할 수 있는 범용 리눅스 서버를 원한다면 bootc를 선택하십시오. 빌드 과정이 자동화되어 있고 기본적으로 자동 업데이트를 지원하는 모델을 원한다면 Fedora CoreOS를 선택하십시오. A/B 업데이트 방식을 사용하며 패키지 관리자가 아예 없는 최소한의 컨테이너 호스트를 원한다면 Flatcar를 선택하십시오. Talos는 셸이 없고 다른 소프트웨어를 실행할 수 없으므로, 장비가 오직 Kubernetes 노드인 경우에만 선택하십시오.

#bootc#immutable#atomic#coreos#updates