> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ko/self-hosted/enterprise/secure-gateway-podman.md). # Podman이 있는 RHEL의 Secure Gateway Roboflow Deployment Manager가 관리하는 Podman 컨테이너로 게이트웨이와 암호화된 캐시를 실행하면서 Kubernetes 없이 Red Hat Enterprise Linux 호스트에 Secure Gateway를 배포합니다. [보안 게이트웨이](/deployment/ko/self-hosted/enterprise/secure-gateway.md) Docker도 Kubernetes도 없는 Red Hat Enterprise Linux 호스트에서도 실행됩니다. 전용 설치 프로그램이 Roboflow Deployment Manager(`rfdm`)의 감독 아래 Podman 컨테이너로 게이트웨이와 암호화된 캐시를 배포하며, Deployment Manager는 Docker 호환 API를 통해 Podman을 제어합니다. Docker 배포와 동일한 게이트웨이( Roboflow API를 프록시하고, 플릿을 위한 모델 가중치와 컨테이너 이미지를 캐시하는, 제어된 단일 egress 지점)를 얻을 수 있으며, RHEL과 함께 제공되는 컨테이너 런타임에서 동일한 air-gapped 번들 모델을 사용할 수 있습니다. {% hint style="info" %} 세 가지 배포 모델을 사용할 수 있습니다. 다음을 사용하세요. [Docker 배포](/deployment/ko/self-hosted/enterprise/secure-gateway.md) 이미 Docker가 실행 중인 호스트에서는 이 페이지를, Docker나 Kubernetes가 없는 RHEL 호스트에서는 이 페이지를, 그리고 [MicroShift의 보안 게이트웨이](/deployment/ko/self-hosted/enterprise/secure-gateway-microshift.md) 를 Kubernetes 플릿으로 관리되는 Red Hat Device Edge 호스트에서 사용하세요. 게이트웨이의 구성 참조(캐싱, TLS 변수, 로그 내보내기)는 세 모델 모두에서 공통입니다. 다음을 참조하세요. [보안 게이트웨이](/deployment/ko/self-hosted/enterprise/secure-gateway.md) 및 [보안 게이트웨이 매뉴얼](https://secure-gateway.roboflow.com/manual/). {% endhint %} ## 아키텍처 * Roboflow Deployment Manager는 호스트에서 systemd 서비스로 실행되며 Podman의 Docker 호환 API(`podman.socket`)를 통해 컨테이너를 관리합니다. 게이트웨이를 구성, 업데이트, 실행 상태로 유지합니다. * 게이트웨이와 그 캐시 백엔드(저장 시 암호화를 지원하는 S3 호환 저장소인 SeaweedFS)는 시스템(root) Podman 인스턴스에서 컨테이너로 실행됩니다. * 게이트웨이는 포트 `80` 및 `443` 를 호스트에서 직접 공개합니다. HTTPS는 `443`에서, HTTP는 `80` 로 리디렉션됩니다. * 캐시는 `/data/seaweedfs` 에 호스트 파일 시스템에 저장되며, 캐시 컨테이너에 바인드 마운트됩니다. LVM 볼륨 그룹이나 스토리지 프로비저너는 필요하지 않습니다. * SELinux는 enforcing 상태를 유지합니다. 관리되는 컨테이너 구성의 볼륨 마운트에는 SELinux 레이블(`:Z`/`z`)가 적용되므로, 수동 재레이블링이나 permissive 모드는 필요하지 않습니다. 이것은 단일 호스트 배포입니다. 고가용성 및 다중 호스트 클러스터는 지원되지 않습니다. {% hint style="warning" %} 게이트웨이 전용 호스트를 사용하세요. Podman과 CRI-O(MicroShift가 사용하는 런타임)는 호스트의 컨테이너 스토리지를 공유하므로, 하나에서 이미지를 정리하면(예: `podman image prune`) 다른 런타임이 캐시한 이미지도 회수될 수 있습니다. 호스트가 MicroShift를 실행 중이면 대신 [MicroShift 배포](/deployment/ko/self-hosted/enterprise/secure-gateway-microshift.md) 를 사용하세요. {% endhint %} ## 사전 요구 사항 * x86\_64 아키텍처의 Red Hat Enterprise Linux 9.x 호스트이며, Podman 4.x 이상이 설치되어 있어야 합니다. 설치 번들은 `linux-amd64` 전용으로 빌드되었습니다. Podman은 추가 구독 없이 RHEL 저장소에서 제공되지만, 최소 설치에는 없을 수 있습니다. 만약 `sudo dnf install podman` 이 실패하면 먼저 `podman --version` 을 실행하세요. 지원 매트릭스를 참조하세요. [지원 매트릭스](#support-matrix). * 루트 권한: 게이트웨이는 시스템(root) Podman 인스턴스 아래에 설치됩니다. * 디스크: 컨테이너 이미지용으로 약 `/` 3 GB, 그리고 `/data`아래의 캐시용 공간이 필요하며, 이는 50 GB까지 증가합니다. * 포트 `80` 및 `443` 호스트에서 게이트웨이가 사용할 수 있는 * 연결된 설치의 경우, 다음으로 아웃바운드 HTTPS가 필요합니다. `api.roboflow.com` 및 `repo.roboflow.com` {% hint style="info" %} MicroShift 배포와 달리 설치할 Kubernetes 배포판은 없습니다. OpenShift pull secret도, LVM 볼륨 그룹도 필요하지 않습니다. Red Hat 구독은 RHEL 자체만 포함하면 됩니다. {% endhint %} ## 연결된 호스트에 설치 Podman 설치 번들을 다운로드하고 무결성을 검증하세요: ```bash curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz curl -fOL https://repo.roboflow.com/rfdm/secure-gateway/podman/latest/secure-gateway-podman-installer-linux-amd64.tar.gz.sha256 echo "$(cat secure-gateway-podman-installer-linux-amd64.tar.gz.sha256) secure-gateway-podman-installer-linux-amd64.tar.gz" \ | sha256sum -c - ``` 압축을 풀고 root로 설치 프로그램을 실행하세요: ```bash tar xzf secure-gateway-podman-installer-linux-amd64.tar.gz cd secure-gateway-podman-installer sudo ./install-podman.sh \ --api-key \ --device-id \ --workspace ``` 설치 프로그램은 다음을 수행합니다: 1. Podman API 소켓(`podman.socket`)를 활성화합니다. 이는 Deployment Manager가 컨테이너를 관리하는 Docker 호환 API입니다. 2. 번들된 Secure Gateway 및 SeaweedFS 이미지를 호스트의 root Podman 스토리지에 로드합니다. 레지스트리에서 가져오는 것은 없습니다. 3. 호스트에 이전 CNI 잔여물이 있어 그렇지 않으면 컨테이너 간 DNS가 깨질 경우, Podman의 네트워크 백엔드를 netavark로 전환합니다. 4. 게이트웨이의 TLS 인증서와 개인 키를 생성합니다. 5. Roboflow Deployment Manager를 Podman 모드의 systemd 서비스로 설치하고 장치 구성을 기록합니다. 6. 다음을 활성화합니다. `podman-restart.service` 그래서 호스트 재부팅 후 컨테이너가 다시 올라옵니다. 7. Deployment Manager를 시작하며, 이것이 게이트웨이와 캐시 컨테이너를 생성하고 시작합니다. 배포를 검증하세요: ```bash sudo systemctl is-active rfdm sudo podman ps curl -fk https:///health ``` 게이트웨이와 캐시 컨테이너 모두 `Up` 상태여야 하며, 상태 확인은 HTTP 200을 반환해야 합니다. `-k` 플래그는 게이트웨이의 인증서를 신뢰할 때까지 필요합니다. 다음을 참조하세요. [TLS 및 신뢰](#tls-and-trust). ## 오프라인 설치 동일한 번들은 인터넷 접속이 없는 호스트에도 설치됩니다. 컨테이너 이미지는 그 안에 OCI 아카이브로 포함되어 있으며 호스트의 Podman 스토리지에 직접 로드됩니다. 컨테이너는 정확한 버전 태그를 참조하므로, 설치 시점이나 그 이후에도 레지스트리에서 가져오는 것은 없습니다. 연결된 머신에서 번들을 다운로드하고 검증한 뒤, 이동식 매체 또는 내부 파일 전송 절차를 통해 호스트로 옮긴 다음 압축을 풀고 `install-podman.sh` 를 위와 동일하게 실행하세요. 검증도 동일합니다. ## TLS 및 신뢰 설치 프로그램은 게이트웨이용 자체 서명 인증서를 생성하며, 게이트웨이는 이를 사용해 포트 `443` 에서 HTTPS를 제공하고 포트 `80` 의 HTTP를 HTTPS로 리디렉션합니다. 생성된 인증서는 공통 이름 `repo.roboflow.com`을 사용하며, `*.roboflow.com`, `localhost`및 `127.0.0.1`도 포함하며, 10년간 유효합니다. 설치 프로그램을 다시 실행하면 해당 생성된 쌍의 남은 유효 기간이 1년 이상인 동안은 그대로 유지되므로, 이미 클라이언트에 배포한 신뢰도 계속 작동합니다. 이는 생성된 자료에만 적용됩니다. 설치 프로그램은 이를 별도로 추적하므로, `--cert` 및 `--key` 없이 다시 실행하면 사용자가 제공한 인증서가 자체 서명 인증서로 덮어써집니다. 게이트웨이는 인증서와 키를 `/etc/secure-gateway/tls/tls.crt` 및 `/etc/secure-gateway/tls/tls.key` 에서 호스트의 파일로 읽습니다. `--cert` 및 `--key` 를 `install-podman.sh` 에 전달하여 처음부터 자체 자료를 설치하거나, 해당 두 파일을 교체한 뒤 게이트웨이 컨테이너를 다시 시작하세요. 인증서는 다음을 포함해야 합니다. `repo.roboflow.com`: 클라이언트 설치 스크립트가 `repo.roboflow.com` 를 게이트웨이의 `/etc/hosts`에 다시 지정합니다. 또한 컨테이너 런타임은 이미지를 가져오기 전에 TLS 호스트 이름을 확인합니다. `*.roboflow.com`는 추가하지 마세요: 클라이언트 설치 스크립트가 이 인증서를 각 클라이언트의 시스템 전체 신뢰 저장소에 설치하므로, 와일드카드를 사용하면 나중에 개인 키를 손에 넣은 누구나 `api.roboflow.com` 또는 다른 roboflow\.com 호스트를 사칭할 수 있게 됩니다. 게이트웨이 프로세스는 컨테이너 내부에서 UID 1000, 그룹 0으로 실행되므로 파일을 소유자 권한으로 읽습니다. 설치 프로그램은 두 파일의 소유자를 `1000:0`로, 키의 권한을 `0640` 로, 인증서의 권한을 `0644` 로, 디렉터리의 소유자를 `root:0` 로, 권한을 `0750`로 설정합니다. 파일을 root로 바꾸고 root 소유로 남겨두는 것이 게이트웨이가 더 이상 키를 읽지 못하는 가장 흔한 원인입니다(참조 [문제 해결](#troubleshooting)). ## Inference Server 연결 Roboflow Inference Server가 실행되는 각 머신에서 게이트웨이의 클라이언트 설치 스크립트를 실행하세요. 그러면 해당 머신의 신뢰 저장소에 게이트웨이 인증서가 추가되고, Roboflow 트래픽(API 호출, 모델 가중치, 컨테이너 이미지 가져오기)이 게이트웨이를 통해 라우팅됩니다. 먼저 이미 신뢰하는 채널을 통해 게이트웨이의 인증서를 클라이언트로 복사하세요(예: `scp` (게이트웨이 호스트에서, 조직의 파일 전송 절차, 이동식 매체). 인증서 검증을 끈 상태로 게이트웨이 자체에서 가져오지 마세요: ```bash sudo cat /etc/secure-gateway/tls/tls.crt > gateway-ca.crt && scp gateway-ca.crt :/tmp/gateway-ca.crt ``` 클라이언트에서, 해당 인증서로 검증된 TLS 연결을 통해 설치 스크립트를 다운로드한 다음 실행하세요. `--resolve` 는 `repo.roboflow.com` 이 인증서가 게이트웨이의 IP에서 커버하는 이름을 가리키므로, 검증을 비활성화하지 않아도 성공합니다. 스크립트는 다음과 함께 요청하세요. `?server=` 그래서 게이트웨이가 스크립트를 템플릿화하는 모든 위치에 올바른 주소를 채우고, 요청에서 받은 `repo.roboflow.com` 호스트 이름이 아닌 ```bash curl -fsSL --cacert /tmp/gateway-ca.crt --resolve repo.roboflow.com:443: \ "https://repo.roboflow.com/install-client.sh?server=" -o install-client.sh sudo bash install-client.sh --server ``` 스크립트를 별도로 다운로드한 다음 실행하면 root로 실행하기 전에 내용을 읽어볼 수도 있습니다. 자신이 제어하는 네트워크 경로에서만 실행하세요: `install-client.sh` 는 `/ca.crt` 및 `/trust-bundle.crt` 를 연결을 검증하지 않은 채 게이트웨이 자체에서 가져오므로, 그 경로의 중간자 공격자가 위의 다운로드가 검증되었더라도 그 단계에서 여전히 신뢰할 수 있는 CA를 공급할 수 있습니다. 또는 개별 Inference Server를 `SECURE_GATEWAY` 환경 변수로 게이트웨이에 연결하세요. 다음을 참조하세요. [Inference Server 연결](/deployment/ko/self-hosted/enterprise/secure-gateway.md#connecting-inference-servers). 사용 `SECURE_GATEWAY=https://repo.roboflow.com`. 버전 전반에 걸쳐 명시적인 HTTPS 스킴을 사용하세요. 예정된 런타임 강화 빌드에서는 바닐라 주소와 평문 게이트웨이를 처리하는 방식이 바뀝니다. 자세한 내용은 [보안 구성 마이그레이션](/deployment/ko/self-hosted/inference-server/configuration/security-migration.md#gateway-transport)를 참조하세요. 호스트 이름도 중요합니다. 생성된 인증서는 `repo.roboflow.com` 를 커버하지만 호스트의 IP 주소는 커버하지 않으므로 `https://` 는 머신이 인증서를 신뢰한 뒤에도 인증서 검증에 실패합니다. 먼저 클라이언트 설치 스크립트를 실행하세요. 그러면 `repo.roboflow.com` 를 게이트웨이의 `/etc/hosts` 를 가리키고 인증서를 설치합니다. 대신 IP 주소를 사용하려면, 이를 포함하는 자체 인증서를 발급받아 `--cert` 및 `--key`로 설치하세요. 게이트웨이만 다음으로의 아웃바운드 접근이 필요합니다. `api.roboflow.com` 및 `repo.roboflow.com`. ## 문제 해결
증상조치
컨테이너가 서로의 이름을 확인할 수 없고, 게이트웨이 로그에 캐시에 도달할 때 이름 확인 오류가 표시됨Podman이 기존 CNI 네트워크 백엔드를 사용 중이며, 컨테이너 DNS가 없습니다. 보통 이전 컨테이너 런타임의 CNI 잔여물 때문입니다. 다음으로 확인하세요. sudo podman info --format '{{.Host.NetworkBackend}}'; 결과는 netavark를 보고해야 합니다. 설치 프로그램은 필요할 때 netavark를 선택하기 위해 /etc/containers/containers.conf.d/ 아래에 drop-in을 씁니다. 수정 후 기존 컨테이너는 이전 백엔드에 남아 있으므로 다음으로 제거하세요. sudo podman rm -f secure-gateway seaweedfs 그리고 Deployment Manager를 다시 시작하세요(sudo systemctl restart rfdm) 그러면 다시 생성됩니다.
게이트웨이가 다음 오류와 함께 실패함 Permission denied TLS 키를 읽는 중인증서와 키 파일은 소유자가 1000:0 (권한 0640 은 키에, 0644 은 인증서에), 디렉터리는 소유자가 root:0 이고 권한은 0750이어야 합니다. 설치 프로그램이 이를 설정하지만, 보통 원인은 인증서를 root로 수동 교체한 경우입니다. 수동으로 설정한 다음 게이트웨이 컨테이너를 다시 시작하세요: sudo chown 1000:0 /etc/secure-gateway/tls/tls.crt /etc/secure-gateway/tls/tls.key, sudo chmod 0640 /etc/secure-gateway/tls/tls.key, sudo chmod 0644 /etc/secure-gateway/tls/tls.crt. 다시 실행하면 install-podman.sh 도 이를 해결하지만, 직접 가져온 인증서를 사용했다면 다시 --cert 및 --key 를 제공해야 하며, 그렇지 않으면 다시 실행할 때 자체 서명 인증서로 바뀝니다.
Permission denied 마운트된 디렉터리에 쓰기볼륨 마운트에 SELinux 레이블이 없습니다. 관리되는 구성의 모든 볼륨에는 :Z (또는 공유 :z) 옵션이 적용됩니다. 수동으로 마운트를 추가했다면 SELinux를 permissive 모드로 바꾸지 말고 레이블을 추가하세요.
게이트웨이가 다음과 함께 크래시 루프를 일으킴 PermissionError 읽는 중 /etc/ssl/certs/ca-certificates.crtSELinux가 Deployment Manager가 마운트하는 호스트 CA 번들에서 컨테이너를 차단하고 있습니다. 거부는 억제되어 있으므로 audit 검색에서는 아무것도 나오지 않습니다. 다음을 실행하세요. sudo setsebool -P container_read_certs on. 설치 프로그램이 이 boolean을 설정하므로, 다시 실행해도 호스트도 함께 수정됩니다.
게이트웨이 로그 초기 핸드셰이크 실패 ... 로컬 캐시 전용 모드로 시작 중게이트웨이가 시작 시 Roboflow API에 도달하지 못했습니다(잘못된 API 키, 아웃바운드 연결 없음, 또는 캐시가 아직 시작 중). 트래픽은 계속 제공하고 로컬 캐시도 유지하지만, S3 백업 캐시 없이 실행되며 다음 재시작 전까지 백엔드에 텔레메트리나 이벤트를 보고할 수 없습니다. 원인을 수정한 다음 게이트웨이 컨테이너를 다시 시작하세요: sudo podman restart <gateway-container>에서 컨테이너 이름 사용 sudo podman ps.
로그 위치Deployment Manager: sudo journalctl -u rfdm. 게이트웨이 및 캐시: sudo podman logs <container>에서 컨테이너 이름 사용 sudo podman ps.
## 지원 매트릭스
RHELPodman참고
9.x4.xPodman 4는 RHEL 9와 함께 제공됩니다
9.x5.xRHEL 9.6 및 Podman 5.4.0에서 검증됨
Podman 4.x는 최소 지원 버전입니다. 현재 RHEL 9.x 릴리스와 함께 제공되는 Podman은 추가 저장소나 패키지 없이 지원됩니다.