> 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).

# RHEL과 Podman에서의 Secure Gateway

Kubernetes 없이 Red Hat Enterprise Linux 호스트에 Secure Gateway를 배포합니다. 게이트웨이와 암호화된 캐시는 Roboflow Deployment Manager가 관리하는 Podman 컨테이너로 실행됩니다.

[보안 게이트웨이](/deployment/ko/self-hosted/enterprise/secure-gateway.md) 또한 Docker도 Kubernetes도 설치되어 있지 않은 Red Hat Enterprise Linux 호스트에서도 실행됩니다. 전용 설치 프로그램은 게이트웨이와 암호화된 캐시를 Podman 컨테이너로 배포하며, Roboflow Deployment Manager(`rfdm`),가 Docker 호환 API를 통해 Podman을 제어합니다. Docker 배포와 동일한 게이트웨이(당신의 전체 배치에 대해 Roboflow API를 프록시하고 모델 가중치와 컨테이너 이미지를 캐시하는, 제어되는 단일 이그레스 지점)를 RHEL에 포함된 컨테이너 런타임에서 동일한 에어갭 번들 모델로 사용할 수 있습니다.

{% 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`)를 통해 컨테이너를 관리합니다. 게이트웨이가 구성된 상태로 유지되고, 업데이트되며, 실행 상태를 유지합니다.
* 게이트웨이와 그 캐시 백엔드(SeaweedFS, 저장 시 암호화를 지원하는 S3 호환 저장소)는 시스템(root) Podman 인스턴스 아래에서 컨테이너로 실행됩니다.
* 게이트웨이는 포트 `80` 와 `443` 를 호스트에 직접 노출합니다: HTTPS는 `443`에서, HTTP는 `80` 에서 HTTPS로 리디렉션됩니다.
* 캐시는 `/data/seaweedfs` 에 호스트 파일 시스템에 저장되며, 캐시 컨테이너에 바인드 마운트됩니다. LVM 볼륨 그룹이나 스토리지 프로비저너는 필요하지 않습니다.
* SELinux는 계속 강제 모드로 유지됩니다. 관리되는 컨테이너 구성의 볼륨 마운트에는 SELinux 레이블(`:Z`/`z`)가 적용되므로, 수동 재레이블링도 허용 모드도 필요 없습니다.

이것은 단일 호스트 배포입니다. 고가용성과 다중 호스트 클러스터는 지원되지 않습니다.

{% 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 -
```

압축을 풀고 루트로 설치 프로그램을 실행합니다:

```bash
tar xzf secure-gateway-podman-installer-linux-amd64.tar.gz
cd secure-gateway-podman-installer

sudo ./install-podman.sh \\
    --api-key   <ROBOFLOW_API_KEY> \\
    --device-id <DEVICE_ID> \\
    --workspace <WORKSPACE>
```

설치 프로그램은:

1. Podman API 소켓(`podman.socket`)을 활성화합니다. Deployment Manager가 컨테이너를 관리하는 Docker 호환 API입니다.
2. 번들된 Secure Gateway 및 SeaweedFS 이미지를 호스트의 루트 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://<host-ip>/health
```

게이트웨이와 캐시 컨테이너는 모두 `실행 중`이어야 하며, 상태 확인은 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`을 포함해야 합니다. 클라이언트 설치 스크립트는 그 호스트 이름을 `/etc/hosts`에서 게이트웨이로 재지정하며, 컨테이너 런타임은 이미지를 가져오기 전에 TLS 호스트 이름을 확인합니다.

게이트웨이 프로세스는 컨테이너 안에서 UID 1000, 그룹 0으로 실행되므로 소유자 권한을 통해 파일을 읽습니다. 설치 프로그램은 두 파일의 소유자를 `1000:0`로, 모드를 `0640` 을 키에,  `0644` 를 인증서에 `root:0` 으로, 그리고 디렉터리의 소유자와 모드를 `0750`으로 설정합니다. 루트가 파일을 교체하고 그대로 루트 소유로 남겨두는 것이 게이트웨이가 더 이상 키를 읽지 못하는 가장 흔한 원인입니다(참조 [문제 해결](#troubleshooting)).

## 추론 서버 연결

Roboflow Inference Server를 실행하는 각 머신에서 게이트웨이의 클라이언트 설치 스크립트를 실행합니다. 이 스크립트는 게이트웨이의 인증서를 머신의 신뢰 저장소에 추가하고 Roboflow 트래픽(API 호출, 모델 가중치, 컨테이너 이미지 가져오기)을 게이트웨이를 통해 라우팅합니다:

```bash
curl -fsSLk https://<host-ip>/install-client.sh | sudo bash -s -- --server <host-ip>
```

다음 `-k` 플래그가 여기서는 필요합니다. 머신이 아직 게이트웨이의 인증서를 신뢰하지 않는데, 바로 그 인증서를 스크립트가 설치하기 때문입니다. 이는 직접 제어하는 네트워크 경로로만 실행하거나, 스크립트를 직접 복사해 와서 먼저 확인한 뒤 실행하십시오.

대안으로, 개별 Inference Server를 다음과 함께 게이트웨이로 지정할 수도 있습니다 `SECURE_GATEWAY` 환경 변수;  [추론 서버 연결](/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://<host-ip>` 는 머신이 인증서를 신뢰한 후에도 인증서 검증에 실패합니다. 먼저 클라이언트 설치 스크립트를 실행하여 `repo.roboflow.com` 을 게이트웨이로 가리키게 하고 `/etc/hosts` 인증서를 설치하십시오. 대신 IP 주소를 사용하려면, 그 주소를 포함하는 자체 인증서를 발급해 `--cert` 와 `--key`로 설치하십시오. 게이트웨이만 `api.roboflow.com` 와 `repo.roboflow.com`.

## 문제 해결

<table data-search="false"><thead><tr><th>증상</th><th>조치</th></tr></thead><tbody><tr><td>컨테이너가 서로의 이름을 해석하지 못하고, 게이트웨이 로그에 캐시에 도달하는 이름 확인 오류가 기록됨</td><td>Podman이 레거시 CNI 네트워크 백엔드를 사용 중이며, 컨테이너 DNS가 없는데, 보통 이전 컨테이너 런타임의 CNI 잔여물 때문입니다. 다음으로 확인하십시오 <code>sudo podman info --format '{{.Host.NetworkBackend}}'</code>; 이 값은 <code>netavark</code>를 보고해야 합니다. 설치 프로그램은 필요할 때 netavark를 선택하도록 <code>/etc/containers/containers.conf.d/</code> 아래에 drop-in을 작성합니다. 기존 컨테이너는 수정 후에도 이전 백엔드를 유지하므로 다음으로 제거하십시오 <code>sudo podman rm -f secure-gateway seaweedfs</code> 그리고 Deployment Manager를 다시 시작하여(<code>sudo systemctl restart rfdm</code>) 다시 생성하십시오.</td></tr><tr><td>게이트웨이가 다음으로 실패함 <code>권한 거부</code> TLS 키를 읽을 때</td><td>인증서와 키 파일은 소유자가 <code>1000:0</code> (모드 <code>0640</code> 을 키에,  <code>0644</code> 을 인증서에), 소유자가 <code>root:0</code> 이고 모드가 <code>0750</code>인 디렉터리 안에 있어야 합니다. 설치 프로그램이 이를 설정합니다. 보통 원인은 루트가 수동으로 교체한 인증서입니다. 수동으로 설정한 뒤 게이트웨이 컨테이너를 재시작하십시오: <code>sudo chown 1000:0 /etc/secure-gateway/tls/tls.crt /etc/secure-gateway/tls/tls.key</code>, <code>sudo chmod 0640 /etc/secure-gateway/tls/tls.key</code>, <code>sudo chmod 0644 /etc/secure-gateway/tls/tls.crt</code>. 다시 실행하면 <code>install-podman.sh</code> 도 이 문제를 해결하지만, <code>--cert</code> 와 <code>--key</code> 를 다시 전달하십시오. 자체 인증서를 가져왔다면, 다시 실행 시 그 인증서가 자체 서명 인증서로 바뀝니다.</td></tr><tr><td><code>권한 거부</code> 마운트된 디렉터리에 쓰기</td><td>볼륨 마운트에 SELinux 레이블이 없습니다. 관리되는 구성의 모든 볼륨에는 <code>:Z</code> (또는 공유 <code>:z</code>) 옵션이 적용됩니다. 직접 마운트를 추가했다면 SELinux를 허용 모드로 바꾸는 대신 레이블을 추가하십시오.</td></tr><tr><td>게이트웨이가 다음과 같이 크래시 루프를 반복함 <code>PermissionError</code> 읽는 중 <code>/etc/ssl/certs/ca-certificates.crt</code></td><td>SELinux가 Deployment Manager가 마운트하는 호스트 CA 번들에 대한 컨테이너 접근을 차단하고 있습니다. 거부는 억제되므로 audit 검색으로는 아무것도 나오지 않습니다. 다음을 실행하십시오 <code>sudo setsebool -P container_read_certs on</code>. 설치 프로그램이 이 boolean을 설정하므로, 다시 실행해도 호스트도 함께 수정됩니다.</td></tr><tr><td>게이트웨이 로그 <code>Init handshake failed ... starting in local-cache-only mode</code></td><td>게이트웨이가 시작 시 Roboflow API에 도달하지 못했습니다(잘못된 API 키, 외부 연결 없음, 또는 캐시가 아직 시작 중이었음). 트래픽은 계속 제공하고 로컬 캐싱도 계속하지만, S3 기반 캐시 없이 실행되며 다음 재시작 전까지 백엔드에 텔레메트리나 이벤트를 보고할 수 없습니다. 원인을 수정한 뒤 게이트웨이 컨테이너를 재시작하십시오: <code>sudo podman restart &#x3C;gateway-container></code>, 컨테이너 이름은 <code>sudo podman ps</code>.</td></tr><tr><td>로그가 있는 위치</td><td>Deployment Manager: <code>sudo journalctl -u rfdm</code>. 게이트웨이와 캐시: <code>sudo podman logs &#x3C;container></code>, 컨테이너 이름은 <code>sudo podman ps</code>.</td></tr></tbody></table>

## 지원 매트릭스

<table data-search="false"><thead><tr><th>RHEL</th><th>Podman</th><th>참고</th></tr></thead><tbody><tr><td>9.x</td><td>4.x</td><td>RHEL 9와 함께 제공되는 Podman 4</td></tr><tr><td>9.x</td><td>5.x</td><td>RHEL 9.6과 Podman 5.4.0에서 검증됨</td></tr></tbody></table>

Podman 4.x는 최소 지원 버전입니다. 최신 RHEL 9.x 릴리스에 포함된 Podman은 추가 저장소나 패키지 없이 지원됩니다.