Quadlet: Podman 컨테이너를 systemd로 실행하기

 (mo8it.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Podman은 데몬이 없기 때문에 서버 부팅 뒤 컨테이너를 안정적으로 올릴 실행 주체가 필요하며, Quadlet은 이를 systemd 서비스 파일 방식으로 해결함
  • 기존 podman generate systemd는 컨테이너 생성과 서비스 파일 생성을 따로 처리해야 했고, 생성 파일을 바꿀 때마다 수동 편집 부담이 생겼음
  • Quadlet은 ~/.config/containers/systemd의 .container 파일에 [Container], [Service], [Install] 설정을 함께 두어 Podman 옵션과 systemd 동작을 한곳에서 관리함
  • rootless Podman에서는 부팅 자동 시작을 위해 WantedBy=default.target와 linger 활성화가 필요하며, multi-user.target은 사용자 모드에 정의되어 있지 않음
  • AutoUpdate=registry, systemd 의존성, 디렉터리별 파일 그룹화, podlet 변환 도구까지 활용하면 Quadlet은 rootless·daemonless Podman 운영에 잘 맞음

왜 Quadlet이 필요한가

  • Quadlet은 Podman 컨테이너를 systemd 서비스처럼 실행하게 해 주는 방식임
    • 컨테이너를 백그라운드에서 실행할 수 있음
    • 서버 재부팅 뒤 컨테이너를 자동으로 시작할 수 있음
  • Podman 컨테이너를 systemd 아래에서 실행하는 방식 자체는 새롭지 않음
    • 기존에는 podman generate systemd 명령을 사용했음
    • 이 명령은 이제 Quadlet으로 마이그레이션하라는 사용 중단 경고를 표시함
  • Podman은 daemonless 구조이므로, 데몬 없이 컨테이너를 시작해 줄 실행 주체가 필요함

기존 podman generate systemd 방식의 불편함

  • 예전 방식은 먼저 podman create로 컨테이너를 만들어야 했음
    • 예시 컨테이너는 docker.io/library/postgres:16 이미지를 사용함
    • -p 5432:5432, 볼륨 마운트, POSTGRES_PASSWORD 환경 변수, io.containers.autoupdate=registry 라벨을 포함함
  • 이후 podman generate systemd test-db -fn --new를 실행해 container-test-db.service 파일을 생성했음
  • 생성된 서비스 파일은 ~/.config/systemd/user에 배치하고 다음 명령으로 활성화·시작했음
    • systemctl --user enable --now container-test-db
  • 이 흐름은 컨테이너 생성, 서비스 파일 생성, 필요한 경우 파일 이동, 서비스 활성화를 반복하게 만듦
  • 컨테이너 생성 명령이 길어지면 나중에 다시 실행하기 위해 셸 스크립트를 별도로 관리해야 했음
  • 생성된 systemd 서비스 파일을 커스터마이즈하려면 매번 다시 수동 수정해야 했음

Quadlet 파일 구성

  • Quadlet 방식에서는 ~/.config/containers/systemd 디렉터리를 만들고 그 안에 .container 파일을 둠
  • 예시 test-db.container 파일은 다음 요소를 포함함
    • [Container]
      • Image=docker.io/library/postgres:16
      • AutoUpdate=registry
      • PublishPort=5432:5432
      • Volume=%h/volumes/test-db:/var/lib/postgresql/data:Z
      • Environment=POSTGRES_PASSWORD=CHANGE_ME
    • [Service]
      • Restart=always
    • [Install]
      • WantedBy=default.target
  • .container 파일은 일반 systemd 서비스 파일이지만, 특별한 [Container] 섹션을 포함함
  • [Container]의 많은 옵션은 podman create에서 쓰는 명령줄 옵션에 대응함
    • Image: 사용할 이미지와 태그
    • AutoUpdate=registry: --label "io.containers.autoupdate=registry"에 대응
    • PublishPort: -p에 대응
    • Volume: -v에 대응
    • Environment: -e에 대응
  • 사용자 홈 디렉터리에는 ~ 대신 systemd 지정자인 %h 를 사용해야 함
  • [Service]의 Restart=always는 수동으로 중지하지 않는 한 컨테이너를 항상 재시작하게 함
  • [Install]의 WantedBy=default.target는 컨테이너가 부팅 시 자동 시작되게 함

rootless Podman에서 필요한 systemd 설정

  • rootless 컨테이너에서는 multi-user.target이 아니라 default.target 을 사용해야 함
    • multi-user.target은 systemd 사용자 모드에 정의되어 있지 않음
    • systemctl --user status multi-user.target로 확인할 수 있음
    • 시스템 모드에서는 systemctl status multi-user.target로 확인 가능함
  • systemd 사용자 서비스로 컨테이너를 실행하므로, 사용자가 로그인하지 않아도 컨테이너가 시작되게 하려면 linger를 활성화해야 함
    • loginctl enable-linger
  • 서버 재부팅 후 자동 시작이 필요하다면 linger 활성화가 필수임
  • 새 서비스 파일을 systemd가 발견하게 하려면 다음 명령을 실행함
    • systemctl --user daemon-reload
  • 컨테이너 시작과 상태 확인은 systemd와 Podman 양쪽에서 할 수 있음
    • systemctl --user start test-db
    • systemctl --user status test-db
    • podman ps
  • 기본 컨테이너 이름은 서비스 파일 이름 앞에 systemd-가 붙은 형태임
    • test-db.container의 기본 컨테이너 이름은 systemd-test-db
    • 충돌을 피하기 위한 이름 규칙임
    • [Container] 섹션의 ContainerName 옵션으로 직접 지정할 수 있음

Quadlet의 운영상 장점

  • Quadlet은 컨테이너 서비스 설정을 파일 하나로 관리하게 해 줌
    • 기존 방식처럼 서비스 파일을 생성하는 스크립트와 생성된 서비스 파일을 따로 관리하지 않아도 됨
  • systemd의 [Unit]과 [Service] 섹션에서 가능한 옵션을 사용할 수 있음
    • 예를 들어 컨테이너 시작 전 실행할 명령을 StartExecPre로 지정할 수 있음
    • 생성된 파일을 나중에 수동으로 고치는 과정이 줄어듦
  • 셸 스크립트를 작성하고 디버깅하는 대신 구성 파일 중심으로 컨테이너를 운영할 수 있음
  • 컨테이너 간 의존성을 systemd 방식으로 표현하기 쉬움

컨테이너 간 의존성 표현

  • 앱 컨테이너가 데이터베이스 컨테이너에 의존한다면 systemd의 [Unit] 섹션으로 관계를 지정할 수 있음
  • OxiTraffic 컨테이너는 test-db 컨테이너에 의존하는 예시임
    • [Unit]에 Requires=test-db.service를 설정해 데이터베이스가 시작될 때만 앱이 시작되게 함
    • After=test-db.service를 설정해 두 컨테이너가 병렬로 시작되지 않게 함
  • 참조할 때는 .container 파일명이 아니라 서비스 이름을 사용함
    • test-db.container: 파일 이름
    • test-db.service: 서비스 이름
    • systemd-test-db: 기본 컨테이너 이름
  • 앱이 데이터베이스와 통신하려면 두 컨테이너 모두 [Container] 섹션에 Network 옵션을 추가해야 하지만, 네트워킹은 다루지 않음

여러 파일과 그룹화

  • Quadlet은 컨테이너마다 별도 .container 파일을 두는 방식으로 구성할 수 있음
  • 멀티 컨테이너 앱을 하나의 Docker Compose 파일에 모두 넣는 방식보다, 컨테이너별 파일이 인지 부담을 줄일 수 있음
  • Docker Compose 파일이 수백 줄과 수십 개 컨테이너를 포함하면 유지보수가 어려워질 수 있음
  • Docker Compose도 여러 파일로 나누는 기능을 지원함
  • Quadlet은 ~/.config/containers/systemd 안의 디렉터리에 unit 파일을 둘 수 있음
    • 예시에서는 oxitraffic 디렉터리를 만들고 앱과 데이터베이스 파일을 함께 둘 수 있음

이미지 업데이트

  • AutoUpdate=registry를 설정하면 podman auto-update로 이미지 업데이트를 확인할 수 있음
  • 레지스트리에 사용 중인 태그와 호환되는 새 이미지가 있으면 Podman이 이미지를 pull하고 컨테이너를 재시작함
  • Docker에서는 이 용도로 Watchtower 같은 도구가 필요할 수 있지만, Podman은 해당 기능을 기본 제공함
  • latest 같은 태그는 위험할 수 있음
    • OxiTraffic에서 latest가 다음 버전의 breaking change를 포함할 수 있음
    • PostgreSQL에서 latest를 쓰면 새 major 버전으로 올라갈 수 있고, PostgreSQL major 업그레이드에는 항상 수동 마이그레이션이 필요함
  • 운영에서는 breaking change로 이어지지 않는 태그를 사용해야 함
  • podman auto-update를 수동으로 며칠마다 실행해 무엇이 업데이트됐는지 보고, 이후 컨테이너가 정상인지 확인하는 방식도 가능함

podman-compose와 마이그레이션 도구

  • podman-compose는 Compose 파일을 Podman으로 실행하는 Python 스크립트임
  • 장기적인 Docker Compose 대안으로 보기 어려운 이유는 다음과 같음
    • Compose 명세와 Podman·systemd 사이의 번역 계층이며, systemd의 모든 기능을 쓰게 해 주지 않음
    • 공식 Podman 프로젝트는 Rust나 Go 같은 컴파일 언어로 작성됨
    • 마지막 커밋이 5개월 전이라 활발히 유지보수되지 않음
  • Quadlet은 Podman의 rootless·daemonless 설계와 더 잘 맞음
  • Compose 파일에서 Quadlet을 시도하려면 podlet을 사용할 수 있음
    • Podman 명령이나 Docker Compose 파일에서 Quadlet 파일을 만들 수 있는 Rust 도구임

더 읽을 자료

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Quadlet은 Podman에서 나온 것 중 최고에 가깝고, Podman이 궁금하거나 컨테이너 기반 워크로드로 옮기려는 사람에게 강력히 추천함
    컨테이너를 일반 시스템 서비스처럼 끼워 넣어 다룰 수 있고, 함께 동작시키려고 별도 오케스트레이션 계층을 배우거나 비컨테이너 자원에 의존할 필요가 없음
    기존에 쓰던 systemd 유닛을 그대로 작성하면 되고, 자동 업데이트나 실패 시 서비스 재시작/알림은 덤임
    Docker로 비슷하게 하려던 방식은 거대한 run 명령으로 Docker 데몬을 우회하다가 유령 서비스와 컨테이너가 남는 일이 많았는데, Quadlet은 훨씬 깔끔하고 설정도 /etc/systemd/, .config/systemd, /usr/local/lib/systemd 같은 systemd 유닛 위치에 같이 있어 백업하기 쉬움
    다만 로컬 개발에서 docker-compose의 답은 아니고, Podman 팀도 그 영역에 크게 관심이 없어 보임
    사용자 컨테이너는 백그라운드 데이터베이스 같은 장기 실행 로컬 테스트 인프라에는 좋지만, 일반적인 컴파일 → docker compose up → 테스트 → docker compose down 루프에는 너무 번거로움
    현실적인 답은 .kube Quadlet(Kubernetes play)이거나 Podman 소켓에 대해 docker compose를 쓰는 것임
    몇 달째 여가 시간에 Quadlet을 관리하는 GitOps 도구를 만들 정도로 마음에 들었고, 컨테이너화된 서버를 관리하는 올바른 방식처럼 느껴짐
    [0]은 podman-compose가 아니라는 점이 중요함. 글에서도 podman-compose는 별로이고 개발이 부족하다고 짚었음. Podman은 compose 명세 대부분을 구현하므로 대부분의 상황에서 docker compose를 쓸 수 있음
    RH가 처음 Podman을 밀기 시작했을 때 시도한 사람들이 Podman 3의 애매함과 podman-compose의 나쁜 경험 때문에 이탈했을 가능성이 큼

    • RH 방식에 가깝게 가고 싶어서 Quadlet과 podlet을 써보려 했지만, Podman 위의 docker compose에서 넘어온 경험은 끔찍했음
      여러 플래그를 바꾸고, 버전을 올리고, podlet 자체가 다른 도구로 바꾸라고 권하는 흐름을 따라가다 보니 끝없는 토끼굴이 됐음
      결국 내 systemd는 그냥 podman compose up을 실행함
      compose가 자기 일을 하게 두는 것과 비교해 Quadlet의 장점이 무엇인지 궁금함
      참고로 Podman은 내 사용자로 실행되고, 데몬은 전혀 없음
    • 개발용 요령은 Podman 소켓을 켜고, 루트리스 컨테이너라면 사용자 단위로 켠 뒤, 독립 실행형 docker-compose를 쓰는 것임
    • Windows나 Mac에서는 systemd를 쓸 수 없으니 결국 podman compose만 남음

  • 최근 Quadlet을 발견하고 atomic OS와 루트리스 Quadlet 기반으로 홈랩 전체를 만들었는데 강력히 추천함
    systemd 소켓 활성화도 가능해서 예를 들어 systemd http/https 소켓을 만들고, ssh.socket과 podman.socket이 각각 sshd.service, podman.service를 활성화하듯 Traefik을 자동 활성화할 수 있음
    루트리스 구성에서 원본 IP를 보존하는 사실상 유일한 방법이라 생명의 은인에 가까움. 루트리스 Podman/Docker는 보통 큰 단점 없이 원본 IP 보존을 쉽게 허용하지 않음
    https://github.com/savely-krasovsky/homelab

    • Traefik이 활성화되는 데 얼마나 걸리는지 궁금함

  • Quadlet은 “프로덕션 비슷한 환경에서 상호 의존적인 컨테이너들을 모두 실행한다”는 docker compose 용도에는 좋은 대안임
    하지만 docker compose의 또 다른 용도인 개발 쪽은 더 나았으면 함
    docker compose는 데이터베이스, Redis, OpenSearch, 기타 의존성, nginx 프록시, .:/app을 볼륨으로 마운트한 개발 컨테이너를 함께 띄우고, 함께 없애고, docker-compose.yml을 저장소에 넣을 수 있음
    Quadlet은 모든 파일을 ~/.config/containers/systemd에 두라고 하므로 더 이상 프로젝트에 격리되지 않고, 다른 개발자들과 체크인해서 공유하기에도 편하지 않음. 게다가 그들도 Podman을 써야 함
    대부분은 아직 Docker를 쓰고, Codespaces 같은 호스팅 개발 환경에서도 Docker가 제공됨
    그래서 체크인된 YAML 파일로 docker compose를 씀. 나는 Podman을 쓰기 때문에 모든 볼륨에 수동으로 :Z를 붙여야 하지만, 일반 Docker는 그걸 처리하지 못함
    개발용 docker compose 대안이 있으면 좋겠지만 Quadlet은 잘 맞아 보이지 않음

    • podman-compose --in-pod=1 systemd -a create-unit을 쓰면 podman-compose@ 서비스를 만들 수 있고, 이후 podman-compose systemd -a register로 compose.yml 파일을 $name과 함께 등록할 수 있음
      그러면 podman-compose@$name.service로 compose 파일 기반 pod를 관리할 수 있고, 완전히 루트리스로도 동작함
    • 이 경우 찾는 것은 Podman pod이고, 나는 그 전체를 Ansible로 오케스트레이션한 뒤 Ansible 플레이북을 모두에게 배포해서 로컬에서 실행하게 하겠음
    • systemd-run은 임의 명령을 기반으로 일시적 systemd 서비스를 실행하게 해줌
      필요하면 타이머까지 포함해 systemd 범위 규칙을 따르는 깔끔한 일시적 유닛을 만들어 줌
      [1] https://www.freedesktop.org/software/systemd/man/systemd-run...
    • Quadlet은 대체로 배포용에 가깝다고 봄. compose 대안을 찾는다면 Podman Kube Play[1]를 보는 편이 좋음
      Kubernetes와 비슷한 형식에 컨테이너 빌드 같은 편의 기능이 조금 추가되어 있음
      kube play 파일을 프로젝트 루트에 두고 podman kube play project.yaml --build를 실행하면 pod, 볼륨 등이 함께 실행됨
      Quadlet 파일은 배포 단계에서 유용함. 프로젝트를 VPS에 올리고 싶다면 이미 가진 project.yaml과 함께 Kube Quadlet[2]을 쓰면 됨
      [1] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
      [2] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
    • 우리 회사도 개발에 docker-compose.yml을 쓰고 있어서 고통이 이해됨
      대체로 아주 잘 동작하지만, OSX에서는 그 빌어먹을 중간 VM 때문에 가끔 이상하게 굴 때가 있음
      가끔 Podman 호환성을 확인해 보지만, 이제는 루트리스 철학이 너무 달라서 완전 호환은 불가능하다고 받아들였음
      그래도 이 도구는 프로덕션에는 멋짐. 취미 프로젝트 몇 개를 베어메탈 노드에서 손수 만든 systemd 서비스로 돌리고 있는데, 현재는 사용자 모드 containerd임
      시간이 나면 옮겨볼 수도 있겠음

  • 이 글이 Podman-Compose를 “활발히 유지보수되지 않는다”고 하면서 마지막 커밋이 5개월 전이라고 짚고, 곧바로 대안으로 마지막 커밋이 역시 5개월 전인 Podlet을 추천하는 게 재미있음
    Podlet은 유용할 수 있지만 Docker Compose의 많은 기능을 지원하지 않고 항상 깔끔하게 변환해주지도 않음
    특히 -f docker-compose.yml -f docker-compose.override.yml처럼 여러 YAML 파일을 쌓는 기능을 지원하지 않음

    • compose 파일을 좋아한다면 Docker의 compose 애플리케이션[1]을 Podman[2]과 함께 쓸 수 있음
      compose CLI가 소켓으로 엔진을 제어하는 듯하고, Podman과 Docker 엔진은 거의 같은 API를 가짐
      podman-compose가 기대대로 동작하지 않아서 이 방식을 쓰고 있음
      Docker-compose는 보통 docker 클라이언트 플러그인으로 설치되지만, 나는 Podman과 쓰기 위해 독립 실행형 애플리케이션으로 사용함
      또한 연동 설정에는 DOCKER_HOST 환경 변수보다 docker contexts를 선호함
      순수 Quadlet만으로 충분히 강력하지 않다면 Quadlet[3]과 일반 Podman[4]도 제한된 Kubernetes 매니페스트 실행을 지원함
      아직 compose 파일의 restart 옵션을 Podman이 어떻게 처리하는지는 파악하지 못했음. Podman에는 감독 데몬이 없기 때문임
      반면 healthcheck 옵션은 systemd 타이머에 의존한다는 건 알고 있음
      systemd가 아닌 배포판인 Gentoo에서 Podman을 쓸 때 자동 헬스체크는 동작하지 않았지만, 수동으로 헬스체크를 실행하면 나머지 설정이 끝까지 진행됐음
      [1] https://github.com/docker/compose
      [2] https://docs.podman.io/en/latest/markdown/podman-system-serv...
      [3] https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
      [4] https://docs.podman.io/en/latest/markdown/podman-kube-play.1...
    • 공정하게 보면 Podlet 기능은 지속적인 업데이트가 필요하지 않지만, podman compose는 그렇지 않음
      Podlet은 보조 도구이고, 장기적으로는 Quadlet으로 작업하는 편이 더 좋음
    • 커밋 날짜는 무언가가 유지보수 중임을 보여주기에는 정확하지 않지만, 유지보수되지 않음을 보여줄 수는 있음
      5개월은 유지보수되지 않는다는 뜻이 아니고, 2년 정도는 되어야 함
      그래도 우려를 키우긴 함. 다만 5개월이 유지보수 중이라는 증거는 절대 아님
      유지보수되지 않는 저장소도 업데이트될 이유는 많고, 최근의 별로인 GitHub 보관 기능만이 이를 막아줄 뿐임

  • 몇 년 전 셀프호스팅 구성을 초기화하면서 다른 걸 시도하고 싶어 openSUSE MicroOS를 골랐고, 결국 systemd/Quadlet 아래에서 Podman 컨테이너를 돌리게 됐는데 현재 구성에 꽤 만족함
    컨테이너는 Podman 내장 도구로 자동 업데이트되고, 로그 확인과 모니터링은 평소 systemd 도구로 처리함
    뭔가 바꿔야 할 때도 설정 파일 위치를 잊었더라도 찾기 쉽고, 읽고 수정하기도 쉬움
    루트리스와 데몬리스도 좋음
    중간에 몇 가지를 시도했지만 podman compose는 둔탁하게 느껴졌고, deprecated된 게 반가우며 Quadlet이 갈 길이라는 게 분명함
    학습 곡선이 있고 Docker보다 자료가 적다는 점은 감안해야 함
    로컬 개발에서 여러 서비스 스택을 올리고 내리는 용도라면 여전히 Docker와 docker compose 쪽을 택하겠음

    • 저렴한 오래된 워크스테이션에서 Fedora CoreOS로 Nextcloud를 돌리고 있음
      설정을 맞추는 데는 시간이 좀 걸렸지만, 유지보수가 거의 필요 없다는 점에 매우 감명받았음. 지금까지는 전혀 없었음
      비슷하게 해보고 싶은 사람은 내 설정을 참고할 수 있음
      https://github.com/jeppester/coreos-nextcloud
    • Quadlet + MicroOS 조합은 매우 강력하고, Fedora CoreOS 같은 다른 atomic 배포판도 마찬가지임
      모든 노드를 천천히 MicroOS로 옮기는 중이고, 회사에서도 MicroOS나 비슷한 것을 밀고 있음
      기본 OS의 자동 롤백과 선언형 컨테이너 설정 및 자동 업데이트 조합이 서로 딱 맞물리는 느낌임

  • 형식은 podman generate systemd나 Kubernetes YAML보다 더 명확하고, systemd 통합도 훌륭함
    짜증 나는 점은 Podman upstream이 Debian/Ubuntu용 저장소를 제공하지 않는다는 것임
    Debian stable에서 4.3.1에 묶여 새 기능을 많이 놓쳤고, 결국 Docker compose로 돌아가기로 했음

    • Debian을 돌리는 Raspberry Pi에서 Quadlet을 쓰려다 같은 문제를 만났음
      제안된 우회책은 Podman을 직접 컴파일하거나 debian/testing을 쓰는 것이었음

  • 이 새 접근이 사람들이 Docker에서 Podman으로 옮기는 데 도움이 되길 진심으로 바람
    Docker-Compose는 많은 사람이 전환을 망설이는 이유이고 나도 그랬음
    인정하자면 Quadlet 전까지 Podman에는 제대로 된 답이 없었음
    Docker-Compose 때문에 Docker에서 옮기길 망설였다면, Quadlet을 곁들인 Podman은 훨씬 견줄 만한 대안임
    생각보다 Docker가 그립지 않을 것이고, 루트리스 컨테이너 실행으로 보안 향상도 얻을 수 있음

    • 여러 개의 독립적인 Quadlet 환경을 가질 수 있기 전까지는 전환하지 않겠음
      모든 것을 ~/.config/quadlet/systemd에 넣는 방식은 안 됨
      개발과 테스트에는 이 점이 필수이고, 지금 Quadlet은 엄격히 배포 솔루션임

  • Quadlet은 컨테이너를 일반 시스템 서비스처럼 쓸 수 있게 해줘서 정말 마음에 듦
    다만 루트리스 컨테이너의 사용자 경험은 이런 개념화와 잘 맞지 않음
    보통 시스템 서비스는 시스템 systemd 세션에서 시스템 사용자로 실행되지만, 루트리스 컨테이너의 서비스는 시스템 사용자의 사용자 systemd 세션에 존재함
    시스템 세션 안에서 루트리스 Quadlet을 실행할 수 있으면 좋겠음

    • user-linger를 켜고 사용자 systemd를 통해 루트리스로 실행하는 것과 실질적인 차이가 있는지 궁금함
      나는 항상 그렇게 해왔음
    • 나도 시스템 세션 안에서 루트리스 Quadlet을 실행할 수 있으면 좋겠음
      또한 DynamicUser= 옵션으로 루트리스 Quadlet을 실행할 수 있으면 좋겠음
      DynamicUser=는 시스템 서비스 권한을 제한하는 훌륭한 방식이었는데, 지금 Podman과는 잘 맞지 않음

  • Hacker News 첫 페이지에서 Quadlet을 보니 흥미로움. 충분히 주목받지 못했다고 생각함
    프로젝트의 Ygal과 Valentin이 inlets 터널 클라이언트를 실행하는 법에 대해 게스트 글을 보내준 적이 있음. Ngrok/Cloudflared 비슷하지만 SaaS 제한 없이 셀프호스팅하는 방식임
    https://inlets.dev/blog/2023/10/03/client-quadlet.html
    이들은 [container] 대신 [kube]를 써서 표준 Kubernetes YAML을 가져갈 수 있었고, 꽤 이식성이 좋아짐

  • 관심 있는 사람을 위해, 최근 Quadlet 배포가 얼마나 쉬운지 보여주는 Ansible 템플릿을 만들었음
    GH: https://github.com/Mati365/hetzner-podman-bunjs-deploy

답변달기