본문으로 건너뛰기

시작 · 정지 · 재시작

데이터레이크를 켜고 끄는 자리는 둘입니다. 컨테이너 자체는 호스트에서, 컨테이너 안의 서비스 하나는 pd 로 다룹니다. 어느 쪽을 써야 하는지부터 정하세요.

하려는 일어디서명령
플랫폼 전체를 켜고 끄기호스트up.sh · down.sh · restart.sh
설정 · 비밀번호를 바꾼 뒤 데이터레이크만 다시 만들기호스트restart-datalake.sh
앱 하나(서버 · 배치 · 웨어하우스)만 재시작호스트restart-server.sh · restart-batch.sh · restart-warehouse.sh · restart-one.sh <서비스>
데이터레이크 안 서비스 하나(CEP · 워크플로우 …)만 재기동컨테이너 안pd restart <서비스>
상태 확인호스트 / 컨테이너 안status.sh / pd status

호스트 동사​

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

./up.sh                 # 기동 — 준비될 때까지 기다린다. 종료 코드 0 = 쓸 수 있다
./down.sh               # 정지 — 컨테이너 · 볼륨은 남는다
./restart.sh            # 전체 재시작 — graceful drain → 재기동 → 준비 대기. 인자를 받지 않는다
./restart-datalake.sh   # 데이터레이크만 — drain → 재생성 → 준비 대기 → 의존 앱 판정
./status.sh             # 컨테이너 · 헬스 · 볼륨 요약. 0 = 정상 / 2 = 비정상
동사종료 코드 0 의 뜻알아 둘 것
up.sh«쓸 수 있다» — 명령 성공이 아닙니다. 준비 판정이 통과할 때까지 재확인합니다(기본 900초, 15초 간격)PP_WAIT=0 이면 기다리지 않고, 그때의 0 은 준비를 뜻하지 않습니다
restart.sh재시작 후 준비 완료앱 여섯 · 프록시 · 인증서 컨테이너까지 전부. 언어 · 타임존처럼 앱에도 닿는 값을 바꿨을 때
restart-datalake.sh데이터레이크가 다시 healthy, 그 의존 앱들도컨테이너 하나지만 스택 이벤트입니다 — 앱 전부가 여기에 연결을 들고 있어서, 끝난 뒤 앱들을 판정하고 스스로 못 돌아온 것만 한 번 더 restart 합니다. 부팅만큼 걸립니다
status.sh정상볼륨 · conf 는 보고만 하고 종료 코드에 넣지 않습니다
값을 바꿨으면 docker restart 가 아니라 restart-datalake.sh 입니다

사이드카 · 노드 파일의 값은 compose 가 컨테이너를 다시 만들 때 환경변수로 들어갑니다. docker restart plantpulse-datalake 는 같은 환경변수로 다시 켤 뿐이라 새 값이 안 들어갑니다.

기동 순서​

컨테이너 사이​

plantpulse-certs(TLS 자재) → plantpulse-datalake → 앱 여섯 · 프록시. 앱은 데이터레이크가 healthy 가 된 뒤에야 뜹니다. 데이터레이크의 기동 유예는 900초이고, 첫 부팅은 Cassandra 스키마 생성으로 그만큼 걸릴 수 있습니다.

데이터레이크 안​

컨테이너가 켜지면 pd start 가 자동으로 돕니다.

  1. 코어 포트(6379 · 5432 · 9042)가 이미 열려 있으면 «already running» 으로 거부.
  2. 필수 시크릿 15개(워커는 +1)가 다 있는지 확인. 없으면 이름을 전부 나열하고 exit 3.
  3. TLS 자재 확인(/var/security/plantpulse).
  4. 설정 렌더 — 템플릿 전부를 PP_HOME 아래 실제 파일로. 매번, 예외 없이.
  5. storage → analytics → messaging → timeseries → cep → workflow → data-gateway → admin-api 순으로 띄우고, 각각 헬스체크 UP 을 기다립니다.

끝 줄이 결과입니다.

datalake started: 8 service(s) ready. Logs: pd logs                                  # exit 0
datalake started with 1 service(s) not ready (7 ready). Check: pd status              # exit 6

종료 순서​

호스트의 down.sh · restart.sh 는 앱을 먼저 내리고 데이터레이크를 drain 합니다 — 컨테이너 안에서 pd stop 이 역순(admin-api → … → storage)으로 서비스를 내리고, 각각 «멈췄다» 를 증명합니다(30초 대기 → SIGTERM 15초 → SIGKILL 10초). 컨테이너의 정지 유예(stop_grace_period)는 180초입니다.

storage 만 내리고 나머지를 두지 마세요

위의 모든 서비스가 storage 에 붙어 있습니다. 내릴 거면 전체를 역순으로 내리는 pd stop 이 맞고, 그럴 거면 컨테이너 자체를 내리는 호스트의 down.sh 가 더 맞습니다. pd stop 전체를 «잠깐 조용히 하려고» 치면 컨테이너 HEALTHCHECK 가 몇 분 안에 unhealthy 가 되고 호스트 쪽 감시가 반응합니다.

서비스 하나만 — pd​

docker exec plantpulse-datalake pd status            # 어느 것이 STOPPED 인가
docker exec plantpulse-datalake pd logs --lines 100 cep
docker exec plantpulse-datalake pd restart cep       # stop → 정지 증명 → 5초 → start
서비스다시 띄우면
storage의존하는 전부가 연결을 잃습니다. 가능하면 호스트의 restart-datalake.sh 로 전체를
analytics실행 중인 SQL · Spark 잡이 전부 중단됩니다. 아카이브 잡이 도는 중이면 끝난 뒤에
messaging수초간 모든 메시지 수신이 멈춥니다. 소비자(서버 · CEP · 배치)는 자동 재접속합니다
timeseries · cep · workflow · data-gateway · admin-api그 서비스만. 앱은 자동 재접속

pd restart 는 정지를 먼저 증명합니다. 정지에 실패하면(exit 7) 거기서 멈춥니다 — 그때는 pd kill --dry-run → pd kill → pd status → pd start.

상태 확인 한 줄씩​

./status.sh                                            # 호스트: 0 정상 / 2 비정상
docker ps --format 'table {{.Names}}\t{{.Status}}'      # 컨테이너와 (healthy)
docker exec plantpulse-datalake pd status              # 서비스 포트 표
curl -kfsS https://<서버IP>:4950/api/health | jq .status   # 콘솔 헬스 API
«Up 인데 죽어 있다» — 메모리 OOM

컨테이너 안 PID 1 이 systemd 라, Java 프로세스만 cgroup 에 OOM-kill 되고 docker ps 는 계속 Up (healthy) 을 보였다가 뒤늦게 unhealthy 가 됩니다. pd status 가 전부 STOPPED 인데 컨테이너가 살아 있으면 먼저 이것을 의심하세요.

dmesg -T | grep -i "memory cgroup"                                   # 호스트
docker inspect plantpulse-datalake --format '{{.State.OOMKilled}}'

한계를 올리는 방법은 설정 바꾸는 법 — 메모리에 있습니다.

자동 시작​

컨테이너는 restart: always 라 호스트가 재부팅되면 Docker 데몬이 스스로 띄웁니다. 별도 systemd 유닛이 필요 없습니다. 다만 down.sh 로 일부러 내린 스택은 재부팅 뒤에도 내려간 채입니다 — up.sh 로 올리세요.

관련 문서​