Skip to content

operations hub rebuild

JJong-03 edited this page Jun 17, 2026 · 4 revisions

운영 — Hub 재구축

Foundation, IoT, Spoke K3s, data-pipeline을 보존한 채 Hub EKS/VPC와 Hub platform만 재구축하는 표준 절차다.

실행 전 차단 조건

infra/foundation, infra/hub, infra/data-pipeline의 Terraform state 소유권과 실제 AWS 리소스가 일치하는지 확인하기 전에는 apply/destroy를 실행하지 않는다.

terraform -chdir=infra/foundation init
terraform -chdir=infra/foundation state list
terraform -chdir=infra/hub init
terraform -chdir=infra/hub state list
terraform -chdir=infra/data-pipeline init
terraform -chdir=infra/data-pipeline state list

현재 통합 기준 이 root들은 S3 backend를 사용하며 root별 key로 state를 분리한다. 빈 state, 접근 실패, 예상하지 않은 drift, remote state output 불일치가 있으면 새 환경으로 가정하지 말고 중단한다.

Hub-only 중지

데이터 수집을 계속할 때는 dummy generator와 data-pipeline을 유지한다. Spoke의 기존 edge-iot-publisher가 Running이면 Hub ArgoCD가 없어도 IoT publish는 계속된다.

scripts/destroy/destroy-hub.sh --plan-only
# infra/hub/tfplan.destroy-hub 검토
scripts/destroy/destroy-hub.sh --yes

--plan-only는 Kubernetes platform cleanup을 실행하지 않고 Hub Terraform destroy plan만 만든다. 실제 삭제에는 --yes가 필수이며, wrapper가 Admin UI Ingress/ALB cleanup 후 Hub infra를 삭제한다.

데이터 수집도 멈출 때만 먼저 다음을 실행한다.

scripts/destroy/stop-dummy-generators.sh

Hub-only 재구축

# Hub infra -> SlowCollector EKS access reconcile -> Hub platform
scripts/build/build-hub.sh

# Foundation의 Route53/ACM을 유지한 일반 재구축에서는 NS 재위임이 필요 없다.
scripts/build/build-admin-ui-after-ns.sh

# 기존 Spoke workload를 sync/restart하지 않고 Hub 제어 경로만 복구
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-a.sh
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-b.sh
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-c.sh

scripts/ops/check-spoke-publisher-safety.sh

HUB_ONLY_RECONNECT=true의 기본값:

SYNC_SPOKE_APP=false
REFRESH_SPOKE_ECR_PULL_SECRET=false
RESTART_SPOKE_AFTER_ECR_SECRET_REFRESH=false

GitOps 변경을 실제 반영할 때만 SYNC_SPOKE_APP=true를 추가한다.

SlowCollector EKS access

build-hub.sh는 data-pipeline의 AEGIS-IAMRole-Lambda-CloudInfraSlowCollector가 존재하면 다음 순서로 EKS access를 자동 복구한다.

  1. Hub와 data-pipeline state가 비어 있지 않은지 확인
  2. 현재 Hub cluster가 ACTIVE인지 대기
  3. SlowCollector EKS access entry와 AmazonEKSAdminViewPolicy association만 target plan/apply
  4. 전체 data-pipeline post-plan이 No changes인지 확인

자동 reconcile을 의도적으로 생략하려면:

RECONCILE_DATA_PIPE_EKS_ACCESS=false scripts/build/build-hub.sh

수동 검토:

scripts/build/reconcile-data-pipe-eks-access.sh --plan-only
# infra/data-pipeline/tfplan.eks-access 검토
scripts/build/reconcile-data-pipe-eks-access.sh

--plan-only가 남긴 plan 파일은 커밋하지 않는다.

Full rebuild

Foundation부터 다시 만드는 작업은 일반 재구축이 아니다. S3, DynamoDB, ECR, Route53/ACM을 포함하는 보호 계층이므로 state와 데이터 복구 계획이 승인된 경우에만 수행한다.

# Foundation을 보존하는 전체 runtime build
scripts/build/build-all.sh --data-pipe --reporting --data-dashboard
scripts/build/build-admin-ui-after-ns.sh

# Spoke는 IoT/K3s Secret을 보존한 reconnect가 기본
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-a.sh
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-b.sh
HUB_ONLY_RECONNECT=true scripts/build/register-spoke-factory-c.sh

최초 구축에서만 --foundation을 추가한다. --iot는 factory-a Thing/Policy/Certificate와 K3s Secret이 없거나 의도적으로 재등록할 때만 사용한다.

Dashboard permanent와 Dashboard DNS root는 build-all.sh가 만들지 않는다. 별도 state 확인 후 먼저 준비해야 한다.

검증

scripts/build/verify-complete.sh
scripts/ops/check-spoke-publisher-safety.sh

추가 확인:

kubectl -n argocd get application
aws logs tail /aws/lambda/AEGIS-Lambda-CloudInfraSlowCollector --since 10m

정상 기준은 Hub platform이 Ready이고, Spoke별 publisher Deployment와 Running Pod가 하나뿐이며 전략이 Recreate이고, SlowCollector 결과에 EKS/Kubernetes 접근 오류가 없는 상태다.

보호 대상

  • Foundation: S3/ECR/DynamoDB/Admin UI Route53/ACM
  • IoT Thing/Policy/Certificate와 로컬 인증서 자료
  • Factory K3s IoT Secret
  • data-pipeline과 reporting
  • Dashboard permanent/DNS
  • S3 raw/processed/processed_agg/reports/image objects

Hub-only 재시작 중에도 Spoke publisher Pod와 data-pipeline이 유지되면 AWS IoT 연결과 데이터 적재는 계속될 수 있다. 연결 상태 확인 기준은 IoT Fleet 연결성을 따른다.

관련 문서: 통합 Build/Destroy, AWS Hub 트러블슈팅

Aegis-Pi Wiki

· 대표 문서 목록은 홈의 문서 탐색 표 참조

시작하기

요구사항

핵심 개념

아키텍처

컴포넌트 (Edge → Cloud → Dashboard)

Dashboard & 운영

시나리오 · 사례 · 참조

Clone this wiki locally