Docker 설치

개요

이 페이지는 PlantPulse 플랫폼을 Docker Compose 스택으로 수동(단계별) 설치하는 방법과 폐쇄망(Airgap) 설치 방법을 안내합니다.

일반적인 환경에서는 원라인 설치를 권장합니다. 원라인 설치는 패키지 다운로드부터 환경 자동 감지, 설치, 부팅 검증까지 한 번에 처리합니다. 아래와 같은 경우에만 이 페이지의 수동 절차를 사용해 주세요.

각 설치 단계를 직접 검토·승인하며 진행해야 하는 경우 (보안 심사, 변경 관리 절차 등)
환경 변수(bin/env.sh)를 자동 감지값이 아닌 값으로 직접 지정해야 하는 경우
인터넷이 차단된 폐쇄망 환경에 설치하는 경우 → 폐쇄망(Airgap) 설치

설치되는 모양 — 컨테이너 아홉 개

플랫폼은 docker compose 스택 하나로 동작합니다. 정본은 compose/docker-compose.yml 이며, 운영 스크립트도 모두 이 파일을 거쳐 컨테이너를 다룹니다.

컨테이너	계층	역할
`plantpulse-certs`	인증서	TLS 자재를 굽고 종료되는 원샷. 정상 상태가 `Exited (0)` 입니다
`plantpulse-datalake`	인프라	스토리지·메시징·분석·CEP·SQL·모니터
`plantpulse-server-web`	애플리케이션	웹 콘솔
`plantpulse-batch-web`	애플리케이션	배치
`plantpulse-warehouse`	애플리케이션	데이터 웨어하우스
`plantpulse-plugin-opcua-server`	애플리케이션	OPC-UA 서버 플러그인 (11004 / 11005)
`plantpulse-plugin-aasx-server`	애플리케이션	AASX 서버 플러그인
`plantpulse-ha`	애플리케이션	이중화 복구 데몬 (10210)
`plantpulse-proxy`	엣지	사용자가 닿는 유일한 입구 (80 / 443 / 1883 / 1884)

상시 컨테이너는 여덟 개입니다

plantpulse-certs 는 인증서를 만들고 스스로 끝나는 원샷이라 Exited (0) 이 정상입니다. docker ps 에는 나머지 여덟 개가 (healthy) 로 보이면 정상입니다. 원샷을 «죽은 컨테이너» 로 오해하지 마세요 — status.sh 와 ops-check.sh 는 이 컨테이너만 종료 코드로 판정합니다.

이 밖에 미러링용 plantpulse-mirror-maker 가 compose 에 정의돼 있지만 mirror 프로파일에 묶여 있어 기본적으로 뜨지 않습니다.

예전의 단일 컨테이너 구성은 없어졌습니다

2026-08-29 이전에는 모든 구성 요소가 plantpulse-platform 컨테이너 하나에서 함께 도는 «모놀리스» 구성을 고를 수 있었습니다. 이 구성은 폐기되었고 선택 변수(PP_TOPOLOGY)와 compose 파일도 함께 삭제되었습니다. 이제 고를 것이 없습니다 — bin/up.sh 가 위 스택을 띄웁니다.

옛 런북에 남아 있는 docker logs plantpulse-platform 같은 명령은 그 이름의 컨테이너가 없으므로 동작하지 않습니다. 대체 명령은 운영 명령 요약에 있습니다.

앱마다 컨테이너를 나눈 첫 번째 목적은 OOM 격리입니다. 한 앱이 메모리를 다 써도 다른 앱과 인프라는 살아 있고, 앱 단위로 재시작·롤백할 수 있습니다.

사전 준비

설치를 시작하기 전에 아래 사항을 확인해 주세요.

항목	요구 사항
계정 권한	root (또는 sudo 권한). 설치 스크립트가 OS 설정과 Docker 데몬을 구성합니다
운영체제	RHEL/Rocky/Oracle Linux 8·9, Ubuntu 20.04+, Amazon Linux 2/2023
Docker	Compose v2 가 필요합니다 (`docker compose` — 하이픈 없는 형태). `install.sh` 가 없으면 설치합니다
데이터 디스크	`/data1` 경로에 대용량 디스크 마운트 권장 — Docker 데이터(`/data1/docker-data`)와 플랫폼 데이터 볼륨이 이 경로를 사용합니다
레지스트리 접근	`docker.kopens.io` (이미지 레지스트리), `product.kopens.io` (설치 패키지)에 HTTPS 접근 가능해야 합니다. 접근이 차단된 환경은 폐쇄망 설치를 이용해 주세요
레지스트리 자격	`docker.kopens.io` 로그인 자격 (KOPENS 운영팀에서 발급)

디스크 경로 안내: 별도 데이터 디스크가 없다면 루트 디스크에 /data1 디렉토리를 생성해도 동작하지만, 운영 환경에서는 전용 디스크를 /data1에 마운트하는 것을 권장합니다.

수동 설치 절차

1단계: 설치 패키지 다운로드

다운로드 서버에서 설치 패키지(tar.gz)를 받아 표준 경로에 풉니다. Git 클론이나 별도 도구 설치는 필요하지 않습니다.

sudo -i

# 표준 설치 경로 생성 후 패키지 다운로드 + 압축 해제
mkdir -p /opt/kopens/plantpulse-platform-docker
curl -fsSL "https://product.kopens.io/plantpulse-platform/plantpulse-platform-docker.tar.gz" \
  | tar -xz -C /opt/kopens/plantpulse-platform-docker --strip-components=1

cd /opt/kopens/plantpulse-platform-docker/bin
chmod +x *.sh tools/*.sh

패키지 안에서 실제로 쓰는 곳은 두 군데입니다.

위치	무엇이 있나
`bin/`	설치·운영 스크립트 전부
`compose/`	스택 정본 `docker-compose.yml` 과 클러스터 워커 오버레이

2단계: 사전 점검 (preflight)

preflight.sh는 시스템을 전혀 변경하지 않고 설치 가능 여부만 확인합니다.

./preflight.sh

점검 항목:

Docker 설치/데몬 동작 여부 (미설치여도 무방 — install.sh가 설치합니다)
Docker data-root 상위 경로(/data1) 존재 여부
시크릿 사이드카(/etc/kopens/plantpulse-platform.env) 존재 여부
주요 운영 포트(80, 443, 7443, 4949, 4950) 사용 여부

OK 만 나오면 다음 단계로 진행합니다. ERROR가 있으면 문제 해결을 참고해 주세요. (WARN은 참고용이며 설치를 막지 않습니다.)

3단계: 환경 변수 검토 (env.sh)

bin/env.sh가 호스트 쪽 설정의 정본입니다. 컨테이너가 실제로 보는 값은 compose/docker-compose.yml 이 정합니다 — 자세한 관계는 환경 변수 레퍼런스를 참고해 주세요.

vi env.sh

자원값은 대부분 «계산»됩니다 — 고칠 것이 별로 없습니다

env.sh 는 호스트를 보고 CPU·메모리·디스크를 스스로 정합니다. 고정 기본값이 아니라서, 손대지 않아도 작은 박스에서는 작은 값이 잡힙니다. 박스별로 지정한 값이 항상 이깁니다.

변수	어떻게 정해지나	언제 손대나
`DOCKER_PP_CPUS`	`nproc` (읽기 실패 시 `8`)	컨테이너에 코어를 덜 주고 싶을 때
`DOCKER_PP_CLUSTER_CORES`	`DOCKER_PP_CPUS - 2`, 최소 4 · 최대 30	보통 그대로 둡니다
`DOCKER_PP_MEMORY`	호스트 RAM 의 90%, 최소 `8G`	OS 몫을 더 남기고 싶을 때
`DOCKER_DATALAKE_MEMORY`	`80G`. 호스트가 그보다 작으면 RAM 의 90%	데이터레이크 상한 조정
`DOCKER_PP_DATA_DISK_NAME`	`/` 를 받치는 실제 디스크를 자동 역추적 (실패 시 `sda`)	자동 감지가 틀렸을 때
`PP_LANG`	`en`	한국어 운영이면 `ko`
`PP_TZ`	`Asia/Seoul`	해외 박스
`DOCKER_PP_EXTERNAL_IP`	빈 값	NAT 환경에서 외부 공인 IP 를 알려야 할 때만

DOCKER_PP_EXTERNAL_IP 에 유효하지 않은 IP 를 넣지 마세요

이 값은 PP_SERVICE_IP 를 거쳐 TLS 인증서의 SAN 목록으로 들어갑니다. 형식이 맞지 않는 IP 가 하나라도 섞이면 openssl 이 확장 파일 전체를 거부해 인증서가 한 장도 생성되지 않고, 스택이 뜨지 못합니다. NAT 뒤가 아니라면 비워 두세요 — 그게 기본값입니다.

현재 서버의 값은 아래 명령으로 확인할 수 있습니다.

hostname -I | awk '{print $1}'          # 서버 IP
free -g | awk '/^Mem:/{print $2"G"}'    # 전체 메모리
nproc                                    # CPU 코어 수
lsblk                                    # 디스크 이름 (sda, sdb, nvme0n1 …)

한국어 운영 박스에서 보통 손대는 것은 두 줄뿐입니다.

export PP_LANG=ko
export PP_TZ=Asia/Seoul

로케일은 부팅 시점에만 반영됩니다

PP_LANG / PP_TZ 는 JVM 부트타임에 고정됩니다. 이미 돌고 있는 스택에서 바꾸려면 ./restart.sh 가 필요합니다. 또한 Cassandra 시계열이 KST epoch 로 적재되므로 한국 운영에서는 Asia/Seoul 을 유지해 주세요.

4단계: 설치 실행 (install.sh)

sudo ./install.sh

install.sh 하나가 설치 전 과정을 자동으로 수행합니다.

OS 감지 및 시스템 설정 — 파일 제한(limits), 커널 파라미터(sysctl), 시간 동기화(chrony), SELinux permissive 전환, swap 비활성화
Docker Engine 설치 — OS별 패키지 매니저로 설치 + data-root를 /data1/docker-data로 구성 (Compose v2 가 없으면 함께 설치)
방화벽 설정 — 공개 포트(80/443/7443/4949/4950)를 열고, 내부 포트는 사설망 대역에서만 접근 가능하도록 제한
서비스 자격 생성 — /etc/kopens/plantpulse-platform.env 시크릿 사이드카 생성 (권한 0600, 재실행해도 기존 값을 덮지 않음)
레지스트리 로그인 — docker.kopens.io 자격 입력 (이미 로그인되어 있으면 자동 생략)
스택 기동 — 네트워크/볼륨 생성 → 이미지 pull → 설정 템플릿 시드 → docker compose up -d

설치 시 일회성 옵션 (필요한 경우에만 환경변수로 지정):

옵션	효과
`SKIP_OS=1`	OS 설정·Docker 설치 생략 (Docker가 이미 설치·운영 중인 경우)
`SKIP_LOGIN=1`	레지스트리 로그인 생략 (이미 로그인했거나 이미지가 로컬에 있는 경우)
`SKIP_FW=1`	방화벽 설정 생략 (방화벽을 별도로 관리하는 경우)
`DOCKER_DATA_DIR=<경로>`	Docker data-root 변경 (기본 `/data1/docker-data`)

# 예: Docker가 이미 설치된 서버
SKIP_OS=1 sudo -E ./install.sh

자격증명을 교체하려면 «설치 전»에 해야 합니다

시크릿 사이드카(/etc/kopens/plantpulse-platform.env)는 export VAR=값 형태의 무조건 대입이라 셸 export 를 이깁니다. 설치가 끝난 노드에서 PP_PG_PASSWORD=... ./up.sh 는 조용히 무시됩니다. 납품 시 교체는 설치 전에 export PP_*_PASSWORD=... 로, 설치가 끝난 뒤에는 비밀번호 회전의 passwd.sh 로 하세요.

5단계: 기동과 부팅 검증

install.sh 는 스택을 띄우고 돌아옵니다. 부팅이 끝났는지는 따로 확인해야 합니다.

./up.sh

up.sh 는 멱등이라 이미 떠 있어도 안전하며, 준비될 때까지 기다립니다. 종료 코드 0 은 «명령이 성공했다»가 아니라 «이제 쓸 수 있다» 라는 뜻입니다.

환경 변수	기본값	뜻
`PP_READY_TIMEOUT`	`900`	준비 대기 상한(초)
`PP_READY_INTERVAL`	`15`	확인 간격(초)
`PP_WAIT=0`	—	대기하지 않음. 이때의 `0` 은 준비 완료를 뜻하지 않습니다

최초 클린 설치는 15~18분 걸립니다

프로세스 기동 자체는 3~~5분(JVM 워밍업)이지만, **전 컴포넌트가 안정될 때까지는 15~~18분**이 걸립니다. Cassandra 스키마 마이그레이션과 안정화가 가장 느립니다. 재시작은 스키마가 이미 있으므로 훨씬 빠릅니다.

실측 기준(2026-08-31, 32 vCPU / 128GiB): 데이터레이크 217초, 웹 서버 316초.

준비 판정을 직접 돌려 볼 수도 있습니다.

./stack-verify-boot.sh

이 스크립트는 컨테이너 하나가 아니라 스택 전체를 봅니다 — 원샷이 정상 종료됐는지, 데이터레이크와 앱들이 running·healthy 인지, 프록시가 443 을 서비스하는지까지 확인합니다.

6단계: 상태·운영 점검

./status.sh      # 0 = 정상 / 2 = 비정상
./ops-check.sh

status.sh 는 서비스 목록·컨테이너 상태·health·볼륨을 요약합니다. 종료 코드가 계약입니다 — 자동화에서 그대로 쓸 수 있습니다.

판정	무엇을 비정상으로 보나
서비스 목록을 못 읽음	compose 해석 실패 또는 docker 접근 불가
compose 가 선언한 서비스에 컨테이너가 없음	기동되지 않음
상시 컨테이너가 `running` 이 아님	원샷(`plantpulse-certs`)은 제외
상시 컨테이너의 health 가 `unhealthy`	`starting` / `none` 은 판정 보류
헬스 API 가 OK 가 아님	데이터레이크 안에서 probe

볼륨과 conf 는 보고만 하고 종료 코드에 넣지 않습니다 — 2노드 분리 설치(PP_TIER=APP)에서는 일부가 없는 것이 정상이기 때문입니다.

ops-check.sh 는 여기에 더해 최근 치명적 로그(OOM, FATAL, SSL 오류 등)까지 훑습니다.

헬스 확인

모니터 API는 plantpulse-datalake 컨테이너가 서비스합니다. 어디서 물어보느냐에 따라 명령이 다릅니다.

# 컨테이너 안에서 — 어떤 구성에서도 동작하는 방법
docker exec plantpulse-datalake curl -kfsS https://127.0.0.1:4950/api/health | jq

# 호스트/외부에서 — 4950 이 publish 되어 있습니다
curl -kfsS https://<서버IP>:4950/api/health | jq

"status" 가 OK 또는 WARN 이면 정상 범위이고, FAIL 이면 장애입니다.

다른 포트로는 헬스를 볼 수 없습니다

콘솔과 헬스 API 는 두 포트 모두에서 서비스됩니다 — 4950(HTTPS)와 4949(평문 HTTP). 같은 콘솔·같은 API 이고 스킴만 다릅니다. 4949 는 더 이상 4950 으로 리다이렉트하지 않습니다.

4949 는 평문입니다 — 로그인 비밀번호와 세션 쿠키가 그대로 흐릅니다. 신뢰할 수 없는 망에서는 4950 을 쓰세요. 4949 는 자체 서명 인증서 경고가 실제로 운영자를 막아 세우는 상자를 위한 선택지입니다.

설치 결과물

네트워크와 볼륨

리소스	이름	용도
네트워크	`pp-net`	플랫폼 전용 Docker 네트워크 (기본 `10.99.0.0/24`, 게이트웨이 `10.99.0.1`)
볼륨	`pp-data`	데이터 영구 저장 (Cassandra, PostgreSQL, Kafka 등)
볼륨	`pp-temp`	임시 데이터 (Spark, Hive 작업 공간)
볼륨	`pp-backup`	백업 저장소
볼륨	`pp-security`	TLS 인증서·키스토어. `plantpulse-certs` 가 쓰고 나머지는 읽기 전용으로 봅니다
볼륨	`pp-proxy-certs`	프록시가 443 에 쓰는 인증서

볼륨은 컨테이너를 중지하거나 제거해도 항상 보존되므로, 업데이트·재설치 시에도 데이터가 유지됩니다.

호스트 디렉토리

경로	용도
`/opt/kopens/plantpulse-platform-docker`	설치·운영 스크립트와 compose 정본
`/etc/kopens/conf`	플랫폼 설정 템플릿 (호스트 바인드 마운트). 최초 실행 시 이미지에서 자동 시드되며, 이후 운영자가 호스트에서 직접 편집할 수 있고 재설치해도 보존됩니다
`/etc/kopens/plantpulse-platform.env`	서비스 자격 시크릿 사이드카 (권한 0600)
`/etc/kopens/platform.node.env`	노드별 정체성(`PP_TIER` 등). 노드 간 복사 금지
`/etc/kopens/ca`	공유 클러스터 CA (2노드 분리 설치에서 사용)

접속 주소

용도	주소
웹 콘솔	`http://<서버IP>/` · `https://<서버IP>/` — `plantpulse-proxy` 가 받습니다
관리 UI	`https://<서버IP>:7443`
모니터 UI · 헬스	`https://<서버IP>:4950/api/health`
MQTT	`<서버IP>:1883` (평문) · `<서버IP>:1884` (TLS)
OPC-UA	`<서버IP>:11004` · `<서버IP>:11005`

보안 안내: 웹 콘솔 최초 로그인 후에는 반드시 기본 관리자 비밀번호를 변경해 주세요. → 초기 비밀번호

운영 명령 요약

일상 운영에 사용하는 명령입니다. 모두 /opt/kopens/plantpulse-platform-docker/bin/에서 실행합니다. 모든 동사가 --help 를 지원합니다.

작업	명령	비고
상태 점검	`./status.sh`	서비스 / health / 볼륨 요약. 0=정상 / 2=비정상
운영 점검	`./ops-check.sh`	컨테이너 health + 헬스 API + 최근 치명적 로그
기동	`./up.sh`	멱등. 0 = 준비 완료
정지	`./down.sh`	상태 보존
재시작	`./restart.sh`	graceful drain → 정지 → 기동 → 준비 대기
로그 보기	`./logs.sh [서비스]`	마지막 200줄을 찍고 끝. 따라가려면 `-f`. 인자가 없으면 모든 컨테이너. 목록은 `--list`
컨테이너 진입	`./shell.sh [서비스]`	인자가 없으면 데이터레이크
이미지 갱신	`./update.sh`	pull + 재생성. 실패 시 이전 이미지로 자동 롤백
완전 제거	`./remove.sh`	컨테이너만 제거 (볼륨·설정 보존). `RM_IMAGE=1` / `RM_NETWORK=1`
백업	`./backup.sh [볼륨 …]`	기본 `pp-data` · `pp-security`
부팅 검증	`./stack-verify-boot.sh`	스택 전체 준비 판정
진단 번들	`./doctor.sh`	지원 요청용 tarball. 비밀값은 마스킹됩니다
비밀번호 변경	`./passwd.sh --list`	바꿀 수 있는 키 목록

# 운영 중 빠른 점검 루틴
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh

# 문제가 의심되면 진단 번들 생성
./doctor.sh

옛 이름도 그대로 동작합니다

stack-run.sh · stack-stop.sh · stack-bash.sh · stack-update.sh · stack-remove.sh 는 삭제되지 않았습니다. 직접 실행하면 새 이름을 한 줄로 안내할 뿐 동작은 같습니다. 기존 고객 런북을 한꺼번에 고치지 않아도 됩니다.

주의 — 전체 볼륨 삭제: ./tools/remove-all-volumes.sh는 모든 데이터를 영구 삭제합니다. 반드시 백업 완료 후에만 사용해 주세요.

폐쇄망(Airgap) 설치

인터넷이 차단된 환경에는 세 단계로 설치합니다: 번들 확보 → 매체로 이동 → 폐쇄망 서버에서 로드.

1단계: 번들 확보

권장 경로는 KOPENS 가 발행한 번들을 내려받는 것입니다.

https://product.kopens.io/plantpulse-platform/plantpulse-platform-images-<버전>.tar.gz

인터넷이 되는 서버에서 직접 만들어야 한다면 아래를 사용합니다.

cd /opt/kopens/plantpulse-platform-docker/bin
./airgap-bundle.sh

# 옵션
INCLUDE_DATALAKE=1 ./airgap-bundle.sh    # datalake 이미지까지 포함
OS_TARGET=both ./airgap-bundle.sh        # 대상 서버가 Ubuntu인 경우 deb 패키지도 포함 (기본은 RHEL rpm)

산출물은 plantpulse-platform-images-<버전>.tar.gz 한 파일이며, 다음이 모두 포함됩니다.

Docker Engine 오프라인 설치 패키지 (rpm / deb)
플랫폼 이미지 (docker save 결과)
repo/ — 설치·운영 스크립트와 compose/ 전체

2단계: 폐쇄망 서버로 이동

USB, 내부 파일 서버, scp 등 허용된 매체로 .tar.gz 파일을 대상 서버에 전달합니다.

3단계: 폐쇄망 서버에서 로드 및 설치

sudo -i
mkdir -p /opt/kopens/plantpulse-platform-docker
tar -xzf plantpulse-platform-images-*.tar.gz -C /opt/kopens/plantpulse-platform-docker

cd /opt/kopens/plantpulse-platform-docker/repo/bin
vi env.sh                  # 3단계 환경 변수 검토와 동일하게 수정
./airgap-load.sh

airgap-load.sh가 자동으로 수행합니다.

Docker Engine 오프라인 설치 (rpm -ivh / dpkg -i) — 이미 설치되어 있으면 생략
플랫폼 이미지 docker load
install.sh 호출 (SKIP_LOGIN=1 — 이미지가 이미 로컬에 있으므로 레지스트리 로그인 불필요)

설치 후 부팅 검증(./up.sh 또는 ./stack-verify-boot.sh)과 운영 점검(./ops-check.sh)은 수동 설치와 동일하게 진행해 주세요.

폐쇄망 업데이트

새 버전 이미지를 담은 번들을 같은 절차로 만들어 이동·로드한 뒤, 기존 컨테이너는 ./update.sh 로 재생성합니다.

문제 해결

preflight 점검이 실패하는 경우

메시지	조치
`docker is installed but daemon is not ready while SKIP_OS=1`	Docker 데몬을 먼저 시작해 주세요: `systemctl start docker`. 또는 `SKIP_OS` 없이 실행하면 `install.sh`가 Docker를 구성합니다
포트가 이미 사용 중 (WARN)	해당 포트를 다른 서비스가 사용 중입니다. `ss -tlnp \| grep :<포트>`로 프로세스를 확인하고, 플랫폼 설치 전 정리해 주세요
Docker data-root 상위 경로 없음 (WARN)	`/data1` 디렉토리가 없습니다. 데이터 디스크를 `/data1`에 마운트하거나 디렉토리를 생성해 주세요

스택이 뜨지 않는 경우

docker compose up -d 는 depends_on 조건을 모두 기다리므로, 헬스체크를 통과하지 못하는 컨테이너가 하나 있으면 전체 명령이 한 줄만 남기고 실패합니다.

dependency failed to start: container plantpulse-server-web is unhealthy

이 한 줄은 컨테이너 이름 말고는 아무것도 알려주지 않습니다. 운영 스크립트는 이때 컨테이너 목록·상태·health probe 출력·각 로그 꼬리를 자동으로 함께 출력하므로, 그 출력을 먼저 읽어 주세요. 직접 확인하려면:

cd /opt/kopens/plantpulse-platform-docker/bin

# 어떤 컨테이너가 어떤 상태인가
./status.sh

# 문제가 있는 컨테이너의 로그
./logs.sh --list                       # 볼 수 있는 서비스 목록
./logs.sh plantpulse-server-web -n 200

# 자원 상황
df -h
docker stats --no-stream

자주 확인되는 원인:

원인	확인
메모리 부족(OOM)	`docker inspect <컨테이너> --format '{{.State.OOMKilled}}'`. 앱별 `mem_limit` 은 환경 변수 레퍼런스를 참고
디스크 가득 참	`/data1` 여유 공간
필수 자격증명 누락	compose 가 비밀번호를 `:?` 로 요구합니다. 비어 있으면 스택이 반쯤 뜨지 않고 아예 뜨지 않습니다 — `install.sh` 를 먼저 실행해 사이드카를 만드세요
DB 초기화 지연	최초 설치는 스키마 생성 때문에 오래 걸립니다. 로그에 에러 없이 진행 중이면 조금 더 기다려 주세요

원인 파악이 어려우면 ./doctor.sh로 진단 번들을 생성하여 기술 지원에 첨부해 주세요. 진단 번들은 모든 컨테이너의 상태와 로그를 담습니다.

TLS 핸드셰이크가 `TimeoutException` 으로만 보이는 경우

앱이 백엔드에 붙을 때 쓰는 이름이 인증서 SAN 목록에 없으면, 오류 메시지에 인증서 이야기가 전혀 나오지 않고 타임아웃처럼만 보입니다. 컨테이너 이름을 바꾸었거나 백엔드 호스트를 직접 지정했다면 이 경우를 의심해 주세요. 인증서를 다시 굽는 방법은 보안 관리에 있습니다.

레지스트리 인증 실패

# unauthorized 오류 시 재로그인
docker login docker.kopens.io

로그인 자격이 없거나 만료된 경우 KOPENS 운영팀에 발급을 요청해 주세요.
사내 방화벽이 레지스트리 접속을 차단할 수 있습니다. 네트워크 관리자에게 docker.kopens.io, product.kopens.io 도메인의 HTTPS 접근 허용을 요청해 주세요.
외부 접근이 원천 차단된 환경이라면 폐쇄망(Airgap) 설치를 이용해 주세요.

기술 지원

설치 및 운영 과정에서 도움이 필요하시면 언제든 문의해 주세요: webmaster@kopens.com

개요​

설치되는 모양 — 컨테이너 아홉 개​

사전 준비​

수동 설치 절차​

1단계: 설치 패키지 다운로드​

2단계: 사전 점검 (preflight)​

3단계: 환경 변수 검토 (env.sh)​

4단계: 설치 실행 (install.sh)​

5단계: 기동과 부팅 검증​

6단계: 상태·운영 점검​

헬스 확인​

설치 결과물​

네트워크와 볼륨​

호스트 디렉토리​

접속 주소​

운영 명령 요약​

폐쇄망(Airgap) 설치​

1단계: 번들 확보​

2단계: 폐쇄망 서버로 이동​

3단계: 폐쇄망 서버에서 로드 및 설치​

폐쇄망 업데이트​

문제 해결​

preflight 점검이 실패하는 경우​

스택이 뜨지 않는 경우​

TLS 핸드셰이크가 TimeoutException 으로만 보이는 경우​

레지스트리 인증 실패​

기술 지원​

개요