가이드

작성자 Matt Connor 2026-10-11

서버용 불변 Linux 배포판 비교

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 환경을 구성할 수 있습니다.

서버를 하나의 이미지로 운영하고 재부팅으로 롤백하는 방식입니다. bootc, Fedora CoreOS, Flatcar, Talos를 VPS에서 사용할 때의 비용과 제약을 비교합니다.

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

불변 Linux 배포판은 운영 체제를 하나의 이미지로 릴리스하므로, 실행 중인 시스템을 직접 패치하는 대신 시스템을 교체한다. 실행 중인 시스템의 /usr 아래 파일을 apt upgrade 다시 작성하지 않는다. 새 이미지를 빌드하거나 가져오면 시스템은 현재 실행 중인 이미지 옆에 새 이미지를 준비하고, 다음 재부팅 때 활성 이미지를 교체한다. 이전 이미지는 디스크에 계속 남아 있으므로 잘못된 업데이트를 되돌리는 방법은 재부팅이다.

"불변"이라는 표현은 실제보다 강하게 들린다. root가 디스크에 쓰는 것을 물리적으로 막는 것은 아니다. 이러한 시스템은 시스템 디렉터리를 읽기 전용으로 마운트하고 해당 디렉터리의 소유권을 이미지에 부여한다. 영구 데이터는 /var에 저장된다. 시스템별 설정은 /etc에 저장된다. /usr 아래의 모든 항목은 이미지에 속한다. 따라서 동일한 이미지 태그를 실행하는 두 서버는 동일한 시스템 파일을 보유한다.

Red Hat이 두 모델에 사용하는 이름이 가장 명확하다. package mode와 image mode다. package mode는 실행 중인 시스템과 이를 수정하는 패키지 관리자로 구성된다. image mode는 다른 곳에서 빌드 단계를 수행해 아티팩트를 생성하고, 서버는 지정한 아티팩트를 부팅하는 역할만 한다. 아래의 모든 내용은 이 한 가지 차이에서 비롯된다.

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

2년 동안 실행된 서버에는 아무도 기록하지 않은 이력이 남아 있다. 서둘러 작업한 저녁에 생성된 make install도 있다. 패키지 하나를 설치하려고 추가한 서드파티 저장소도 있다. 장애 중에 수정한 뒤 구성 관리에 되돌려 반영하지 않은 설정 파일도 있다. 이를 configuration drift라고 하며, 메모를 바탕으로 "동일한" 서버를 다시 구축했을 때 동작이 달라지는 경우가 많은 이유이기도 하다. 메모에는 의도가 기록된다. 디스크에는 실제 상태가 기록된다.

Image mode는 drift가 쌓이는 공간을 없앤다. /usr은 런타임에 읽기 전용이므로, 수동으로 수행한 설치는 즉시 실패하거나 한 번의 명령으로 나열할 수 있는 레이어로 기록된다. 따라서 두 시스템의 차이를 고고학적 조사처럼 추적하지 않고 바로 확인할 수 있다. 이는 일반적인 Linux 서버 유지 관리 체크리스트가 규율을 통해 해결하는 문제를 파일 시스템으로 처리하는 방식이다.

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

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

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

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback는 부트로더 순서를 이전 부팅 항목으로 되돌립니다. 이는 한 시간 전에 실행 중이던 커널과 사용자 공간을 포함한 이미지입니다. 이전 이미지는 디스크에서 삭제되지 않았으므로 아무것도 다운로드하거나 다시 빌드하지 않습니다. 아래에서 설명할 자동 업데이트 타이머를 활성화했다면 먼저 중지하십시오. bootc 문서에서는 자동 업그레이드를 수행하는 에이전트가 롤백을 다시 되돌릴 수 있다고 경고합니다.

Fedora CoreOS도 다른 명칭으로 같은 기능을 제공합니다:

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

먼저 Zincati를 중지하십시오. Zincati는 Fedora CoreOS 머신을 최신 릴리스로 유지하는 에이전트입니다. 방금 되돌린 배포판을 다시 설치하지는 않지만, 계속해서 업데이트를 확인하며 새로운 버전이 나타나면 업그레이드할 것입니다. 따라서 수정 사항이 배포될 때까지 머신을 현재 상태로 유지하려면 sudo systemctl disable --now zincati.service을 실행하십시오. -r은 롤백이 준비되면 재부팅을 수행합니다. 신뢰하는 배포판이 가비지 컬렉션(garbage collected)되지 않도록 하려면 다음을 수행하십시오:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status는 부트로더가 제공하는 순서대로 배포판을 나열하며, 현재 실행 중인 항목에 점을 표시하고 고정한 항목에는 Pinned: yes을 표시합니다.

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

talosctl rollback --nodes 10.20.30.40

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

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

정상적으로 실행 중인 슬롯은 tries=0 successful=1가 포함된 줄을 출력합니다. 같은 줄에 있는 우선순위 숫자는 부트로더가 선호하는 슬롯의 순위일 뿐이므로, 완벽하게 정상인 머신에서도 1이나 2로 표시될 수 있습니다. 일치하는 줄이 없다면 현재 슬롯이 아직 확인되지 않은 상태이며, 이는 업데이트 후 첫 번째 정상 부팅이 이루어지기 전의 상태입니다.

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

bootc는 이 패턴을 일반화한 도구다. OCI (open container initiative) 컨테이너 이미지를 사용해 트랜잭션 방식으로 운영 체제를 현재 위치에서 업데이트하는 도구라고 설명하며, 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

다른 이미지와 같은 방식으로 빌드하고 push한다.

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을 보존하면서 시스템이 다른 이미지를 사용하도록 지정한다. 이 방식으로 재설치하지 않고 서버를 이미지 스트림 사이에서 이동할 수 있다.

무인 업데이트를 사용하려면 프로젝트에서 제공하는 timer를 활성화한다.

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

이는 Ubuntu의 무인 업그레이드와 Rocky 및 Alma의 dnf-automatic에 해당하는 image-mode 방식이다. 차이는 적용되는 대상이다. package-mode timer는 해당 시점에 저장소에 있는 버전을 적용하므로 그 결과로 구성되는 패키지 집합이 각 시스템마다 조금씩 다르다. image-mode timer는 다른 곳에서 이미 부팅한 하나의 아티팩트를 적용한다.

이 Containerfile에서는 2가지 빌드 규칙이 따른다. 쓰기 가능한 데이터는 /var 아래에 있어야 한다. 따라서 자체 설치 디렉터리 안에 쓰기를 요구하는 소프트웨어에는 빌드 시 symlink 또는 systemd BindPaths= 줄을 추가해야 한다. 또한 /etc은 업데이트 시 3-way merge된다. 따라서 한 번도 수정하지 않은 파일에는 이미지의 새 버전이 적용되고, 로컬에서 수정한 파일은 유지된다.

실행 중인 시스템에서 한 번의 디버깅 세션에 사용할 도구가 필요하면 다음을 실행한다.

sudo bootc usr-overlay
sudo dnf -y install strace

이 명령은 /usr에 임시 쓰기 가능 overlay를 추가하며, 다음 재부팅 시 폐기된다. 이 기능은 문제를 확인하기 위한 것이지 문제를 수정하기 위한 것이 아니다. 이 방법으로 kernel을 변경할 수 없으며, 설치한 항목은 모두 설계상 재부팅 시 사라진다.

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 키가 없으면 시스템에 접속할 방법 없이 부팅되며, 처음부터 다시 프로비저닝해야 해결할 수 있습니다. 중요한 서버에 적용하기 전에 일회성 테스트 시스템에서 설정을 검증해야 합니다.

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

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

업데이트는 기본적으로 자동으로 수행됩니다. 업데이트 여부가 아니라 업데이트 시점을 제어합니다. 주기적 전략을 선택하는 TOML 파일을 /etc/zincati/config.d/55-updates-strategy.toml에 작성합니다.

[updates]
strategy = "periodic"

이 전략에서는 array-of-tables 항목마다 유지 관리 시간을 하나씩 추가합니다. 각 시간 설정은 큰따옴표 2개로 묶은 대괄호 안에 updates.periodic.window 이름을 헤더로 작성하고, 이어서 다음 3개의 키를 지정합니다.

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

이 명령은 패키지가 추가된 새 배포를 생성합니다. 변경 사항은 재부팅한 후에만 적용됩니다. 이후에 비용이 발생합니다. 새 base image를 적용할 때마다 레이어링한 패키지 집합이 그 위에 다시 적용됩니다. 따라서 업데이트 당일 해당 패키지가 repository에서 사라져 있으면 업데이트가 실패합니다. Fedora 공식 문서는 규모가 있는 작업에는 컨테이너를 사용하고, 운영 체제를 실제로 변경해야 하는 경우에는 bootc image를 사용하도록 안내합니다.

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

Flatcar는 CoreOS Container Linux의 후속 배포판이며, 범용 옵션 중 가장 엄격하다. 사용할 수 있는 패키지 관리자가 없다. 실행하는 모든 것은 컨테이너다. 프로비저닝에는 Fedora CoreOS와 동일하게 Ignition을 사용한다. 업데이트는 앞에서 설명한 2개의 A/B /usr 파티션을 대상으로 하며, update_engine이 업데이트를 수행하고 locksmithd이 재부팅 시점을 결정한다.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT은 수동 슬롯에 새 이미지가 이미 저장되어 있고 재부팅만 남았다는 의미다. 기본 재부팅 전략은 reboot이며 5분 지연이 적용된다. 따라서 별도로 지정하지 않으면 단일 프로덕션 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는 네 가지 운영체제 중 가장 범위가 좁으며 그 목적이 가장 명확합니다. 이 운영체제는 Kubernetes 노드를 실행하기 위해 설계되었습니다. SSH 데몬, 로그인 셸, 콘솔 로그인이 존재하지 않습니다. 물리적 콘솔에는 로그인 프롬프트 대신 시스템 상태를 점검할 수 있는 대시보드가 표시됩니다. 모든 작업은 워크스테이션에서 talosctl을 사용하여 수행하는 gRPC API 호출이며, 이는 git으로 관리하는 머신 설정(machine config)을 기반으로 합니다.

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.2

Talos 1.14 버전부터 ghcr.io/siderolabs/installer 이미지는 더 이상 배포되지 않으며, 설치용 이미지는 Image Factory를 통해 제공됩니다. 해당 경로의 긴 ID는 사용자 정의가 없는 머신을 위한 빈 스키마틱(schematic)입니다. 노드 설치 시 사용했던 스키마틱을 사용해야 시스템 확장 기능이 함께 포함되며, 태그를 업그레이드하려는 릴리스 버전으로 교체하십시오. 업그레이드는 이전 커널과 OS 이미지를 유지하는 A-B 방식을 사용하므로, 새 버전으로 부팅에 실패하면 Talos가 자동으로 이전 상태로 롤백합니다. 로그인 셸이 없기 때문에 디버깅 방식도 다릅니다. 장비 내부에서 journalctl을 사용하는 대신 talosctl logs과 talosctl dmesg를 사용합니다. 노드에서 도구가 필요한 경우, talosctl debug을 사용하여 사용자가 제공한 이미지로부터 권한이 부여된 컨테이너를 실행하고 그 셸로 진입할 수 있습니다. 컨테이너는 종료 시 자동으로 삭제됩니다.

워크로드가 Kubernetes가 아니라면 Talos는 적합한 선택이 아닙니다. 만약 Kubernetes라면, Talos는 "누군가 노드에 로그인하여 무언가를 변경했다"는 상황 자체가 발생할 수 없으므로 특정 범주의 장애를 완전히 제거합니다.

VPS 테넌트가 실제로 포기하는 것

실행 중인 시스템에 임시로 설치하는 작업. 가장 큰 차이점이다. 장애가 발생한 새벽 2시에 sudo apt install htop를 실행할 수 없다. bootc에서는 재부팅 시 사라지는 임시 overlay를 사용한다. Fedora CoreOS에서는 재부팅이 필요한 layered deployment를 사용한다. Flatcar와 Talos에서는 아무것도 제공되지 않는다.

이전에는 필요하지 않았던 빌드 파이프라인. 패키지를 추가하려면 Containerfile을 수정하고, 이미지를 빌드하고, registry에 push한 다음 서버를 순차적으로 업데이트해야 한다. 파이프라인이 이미 있으면 비용이 적다. 파이프라인이 없을 때 새로 구축하려면 실제 작업이 필요하다. 또한 서버가 접근할 수 있는 registry가 필요하다. 이는 별도로 운영해야 하는 서비스이거나 추가 비용이 발생하는 서비스다.

커널 모듈. 커널은 이미지에서 제공되므로 실행 중인 커널에 맞춰 컴파일한 모듈은 다음 업데이트 후에도 유지되지 않는다. 트리 외부 모듈과 DKMS (dynamic kernel module support) 패키지는 해당 이미지의 커널을 기준으로 이미지에 포함해 빌드해야 한다. 기본 이미지에 없는 모듈이 필요한 작업은 설치 문제가 아니라 빌드 문제가 된다.

공급업체 및 프로바이더 에이전트. 모니터링 및 백업 에이전트는 대개 /usr에 파일을 기록하고 unit을 활성화하는 설치 스크립트가 포함된 .deb 또는 .rpm 형태로 제공된다. 읽기 전용 시스템에서는 해당 스크립트가 실패한다. 일부 공급업체는 컨테이너를 제공하거나 image-mode 설치 방법을 문서화한다. 많은 공급업체는 그렇게 하지 않는다. 커밋하기 전에 이를 확인해야 한다. 모니터링할 수 없는 fleet은 구성이 점차 달라지는 fleet보다 운영 상태가 나쁘기 때문이다.

이미지 자체. 거의 모든 VPS control panel에는 Ubuntu와 Debian 옆에 Fedora CoreOS, Flatcar 또는 Talos가 표시되지 않는다. 디스크는 직접 제공해야 한다. 다음 섹션에서 이를 설명한다.

임대 VPS에 설치하기

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

제공업체가 사용자 정의 이미지를 허용한다면 공급업체의 raw 또는 qcow2 이미지를 업로드합니다. 하지만 업로드만으로는 로그인할 수 있는 상태가 되지 않습니다. Fedora CoreOS의 core 사용자는 기본 암호나 SSH 키가 없으므로, 사용자의 키가 포함된 Ignition 설정을 전달하거나, Afterburn이 지원하는 클라우드 플랫폼이라면 제공업체의 자체 SSH 키 기능을 통해 키를 설정해야 합니다. 그렇지 않다면 구조용 시스템에서 직접 디스크에 기록해야 합니다. 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

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

불변 서버를 사용해야 하는 경우와 사용하지 말아야 하는 경우

서버를 개별적으로 관리하지 않고 동일한 방식으로 대량 운영한다면 이 방식을 고려할 만하다. 하나의 레시피로 여러 대의 시스템을 생성하는 경우가 해당한다. 1시간 동안만 실행되는 CI(지속적 통합) runner도 적합하다. 수리하는 대신 교체하는 k3s 또는 Kubernetes node에도 적합하다. 장애가 발생한 시스템에 대한 대응이 이미 "삭제하고 새로 만든다"로 정해져 있는 환경이라면 특히 유용하다. 감사자에게 시스템에서 실행 중인 항목을 증명해야 할 때도 효과적이다. 이 경우 답변은 package 목록이 아니라 image digest가 된다.

반대로 서비스 3개가 실행되는 VPS 1대를 직접 관리하고, 필요할 때마다 software를 설치하며, build pipeline이 없다면 이 방식을 선택하지 않는 편이 좋다. image mode는 작업을 없애지 않는다. 작업을 server에서 build 단계로 옮기고, 그 과정에 registry와 pipeline이 필요해진다. 해당 작업을 처리할 환경이 있다면 서로 동일한 server를 운영할 수 있고, rollback도 재부팅으로 수행할 수 있다. 그런 환경이 없다면 정상적으로 작동하던 시스템에 구성 요소만 추가되고, 새벽 2시의 장애 대응은 더 어려워진다.

단순한 중간 선택지도 여전히 유효하다. 일반적인 distribution에 automatic security updates를 적용하고, 실제로 연습한 rebuild 절차를 준비하는 방식이다. 어떤 base를 선택할지는 별도의 결정이며, VPS에서 실행할 OS 선택에서 설명한다. image mode는 software를 시스템에 배포하는 방법을 둘러싼 오래된 논쟁이 최근에 다시 나타난 형태일 뿐이다. Linux distribution의 역사도 대부분 같은 논쟁이 반복된 과정이다.

FAQ

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

아니요, 이름 때문에 혼동이 생깁니다. root 권한으로는 여전히 디스크에 쓰기가 가능합니다. 실제로는 런타임에 /usr이 읽기 전용으로 마운트되고, 다음 이미지 업데이트 시 전체가 교체되는 방식입니다. 반면 /etc와 /var는 쓰기 가능 상태로 유지되며 업데이트 후에도 데이터가 보존됩니다. /usr 하위에서 변경을 시도하면 즉시 거부되거나 다음 업데이트 시 폐기되므로, 시스템 디렉터리는 이미지가 변경될 때만 바뀐다는 실질적인 효과를 얻게 됩니다.

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

제공자가 구조(rescue) 시스템과 콘솔 접근 권한을 제공한다면 일반적으로 가능합니다. 구조 모드로 부팅한 뒤 배포판의 디스크 이미지를 블록 장치에 기록하고 재부팅하면 됩니다. Flatcar의 flatcar-install 스크립트는 어떤 Linux 환경에서든 이 작업을 수행하며, 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는 한발 더 나아가, 새로운 슬롯으로 부팅에 실패하면 자동으로 롤백을 수행합니다. 부팅 항목은 성공적으로 부팅된 후에만 기본값으로 설정되기 때문입니다. 물론 이 기능이 잘못된 업데이트 자체를 막아주지는 않지만, 복구 과정을 매우 간편하게 만들어 줍니다.

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

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

#bootc#immutable#atomic#coreos#updates