현재 Harbor 공식 문서 기준으로 보면 Replication은 Harbor ↔ Harbor, 또는 Harbor ↔ 다른 Registry 사이에 OCI Artifact/Container Image 등을 복제하는 기능입니다. Push 방식과 Pull 방식 모두 지원합니다.
📘 Harbor Native Replication 학습 시리즈
앞으로 아래 순서로 가면 이해하기 쉽습니다.
- 1단계 — Harbor Replication이 무엇인가? ← 오늘
- 2단계 — Source / Destination / Endpoint / Rule 이해
- 3단계 — Push Replication과 Pull Replication 차이
- 4단계 — Harbor A → Harbor B 실제 설정
- 5단계 — Manual / Scheduled / Event Based 차이
- 6단계 — Project / Repository / Tag 필터링
- 7단계 — Robot Account와 권한 설계
- 8단계 — Kubernetes에서 Harbor Replication 활용
- 9단계 — 운영센터 ↔ DR센터 구성
- 10단계 — 장애·복구·모니터링·운영 주의사항
1단계. Harbor Native Replication이란?
먼저 아주 쉽게 생각해보겠습니다.
현재 Harbor가 하나 있다고 가정하겠습니다.
[Harbor A]
project-a
├─ nginx:1.0
├─ nginx:2.0
└─ my-app:v1여기에 중요한 Docker Image들이 저장되어 있습니다.
그런데 Harbor A가 장애가 나면 어떻게 될까요?
Harbor A 장애
X
Kubernetes
↓
Image Pull 실패
↓
Pod 실행 실패예를 들어 Kubernetes가 다음 이미지를 받아야 하는 상황입니다.
harbor-a.company.com/project-a/my-app:v1그런데 Harbor A가 죽으면 Kubernetes가 이미지를 가져오지 못할 수 있습니다.
그래서 Harbor B를 하나 더 두는 겁니다.
Harbor A
운영센터
↓ 복제
Harbor B
DR센터그리고 Harbor A에 있는 이미지를 Harbor B에도 복사합니다.
이 기능이 바로
Harbor Replication
입니다.
2. Replication을 정말 쉽게 비유하면
NAS 데이터 복제를 생각하면 쉽습니다.
예를 들어:
NAS A
사진1
사진2
문서1
↓ 복제
NAS B
사진1
사진2
문서1Harbor에서는 파일 대신 Container Image / OCI Artifact를 복제합니다.
Harbor A
nginx:1.25
redis:7
myapp:v1
↓ Replication
Harbor B
nginx:1.25
redis:7
myapp:v1즉,
Harbor Replication = Container Registry 데이터 복제
라고 생각하면 됩니다.
3. 여기서 중요한 점
Harbor Replication은 Harbor 서버 전체를 통째로 복제하는 기능은 아닙니다.
이 부분이 매우 중요합니다.
예를 들어 Harbor A에 다음 정보가 있다고 합시다.
Harbor A
사용자
프로젝트
권한
Robot Account
Container Images
설정
로그
DBReplication을 한다고 해서 이 모든 정보가 Harbor B로 그대로 복제되는 것은 아닙니다.
Harbor 공식 문서에서도 Replication 대상은 Registry의 리소스이며, 프로젝트의 Member 정보 등은 복제되지 않는다고 설명합니다.
쉽게 구분하면:
| Container Image | ✅ |
| OCI Artifact | ✅ |
| Image Tag | ✅ |
| 일부 서명 Artifact | ✅ |
| Harbor 사용자 | ❌ |
| 사용자 비밀번호 | ❌ |
| Project Member | ❌ |
| Harbor 설정 전체 | ❌ |
| Harbor DB 전체 | ❌ |
| Redis 데이터 | ❌ |
따라서:
Harbor Replication
≠ Harbor 전체 HA
≠ Harbor DB 복제
≠ Harbor Backup입니다.
이 세 가지를 처음부터 구분해야 합니다.
4. Harbor 내부 구조를 먼저 조금 알아야 합니다
Harbor를 그냥 하나의 프로그램으로 생각하기 쉬운데 실제로는 여러 컴포넌트로 구성됩니다.
대략적으로:
사용자 / Kubernetes
│
↓
Harbor URL
│
┌───────┴────────┐
│ │
Core Registry
│ │
│ Images
│
PostgreSQL
│
RedisHarbor Replication이 주로 대상으로 하는 것은:
Registry
│
└─ Container Images / OCI Artifacts쪽입니다.
즉:
Harbor A Registry
│
│ Replication
↓
Harbor B Registry입니다.
PostgreSQL 자체를 DB Replication하는 개념과는 전혀 다릅니다.
5. 실제 운영에서는 이렇게 생깁니다
예를 들어 서울 운영센터와 DR센터가 있다고 해보겠습니다.
서울 운영센터
Kubernetes Cluster
│
↓
harbor-prod.company.com
│
[ Harbor A ]
│
│ Replication
↓
──────────────────────────────
WAN
──────────────────────────────
│
↓
[ Harbor B ]
│
harbor-dr.company.com
DR센터Harbor A에 다음 이미지가 등록됩니다.
project01/backend:v1Replication을 설정했다면:
Harbor A
project01/backend:v1
↓
Harbor B
project01/backend:v1처럼 복제할 수 있습니다.
6. 누가 복제를 수행하는가?
Harbor Replication을 이해할 때 가장 중요한 개념 중 하나입니다.
Harbor에는 Replication Rule이 있습니다.
쉽게 말하면:
"무엇을, 어디로, 언제 복제할 것인가"
를 정의한 규칙입니다.
예를 들어:
Rule 이름
prod-to-dr
Source
Harbor A
Destination
Harbor B
대상
project01/**
Trigger
Event Based이런 Rule을 만들 수 있습니다.
결과적으로:
개발자
│
│ docker push
↓
Harbor A
project01/app:v1
│
│ Event 발생
↓
Replication Rule
│
↓
Harbor B
project01/app:v1가 됩니다.
7. Replication Endpoint란?
다음 단계에서 자세히 배우겠지만 미리 개념만 잡겠습니다.
Harbor A가 Harbor B로 데이터를 보내려면 Harbor A가 이런 정보를 알아야 합니다.
Harbor B 주소
https://harbor-dr.company.com그리고 인증 정보도 필요합니다.
ID
Password / SecretHarbor에서는 이런 원격 Registry 정보를:
Replication Endpoint
라고 부릅니다.
공식 문서에서도 Replication Rule을 만들기 전에 먼저 Replication Endpoint를 생성하도록 되어 있습니다.
구조는:
Harbor A
Endpoint
│
├─ Name : harbor-dr
├─ URL : https://harbor-dr.company.com
├─ ID
└─ Secret
↓
Harbor B라고 보면 됩니다.
8. 그래서 실제 설정 순서는?
초보자가 가장 먼저 외워야 하는 흐름입니다.
Harbor Replication 설정은 대체로:
① Harbor 준비
↓
② Destination Harbor 준비
↓
③ Registry Endpoint 등록
↓
④ Connection Test
↓
⑤ Replication Rule 생성
↓
⑥ Source Filter 설정
↓
⑦ Trigger 방식 설정
↓
⑧ Replication 실행
↓
⑨ Task / Log 확인입니다.
Harbor UI 기준으로도 원격 Registry를 Endpoint로 먼저 등록한 뒤 Replication Rule에서 해당 Endpoint를 Source 또는 Destination으로 선택합니다.
9. Push 방식과 Pull 방식
Harbor Replication에는 두 가지 중요한 방식이 있습니다.
Push 방식
Harbor A가 Harbor B로 밀어줍니다.
Harbor A
Source
│
│ PUSH
↓
Harbor B
Destination쉽게 말하면:
"내 데이터를 저쪽으로 보내겠다."
입니다.
DR 구축할 때 많이 생각할 수 있는 형태입니다.
Pull 방식
Harbor B가 Harbor A에서 가져옵니다.
Harbor A
Source
│
│ PULL
↓
Harbor B
Destination쉽게 말하면:
"저쪽 데이터를 내가 가져오겠다."
입니다.
Harbor 공식 문서에서도 Replication Rule을 생성할 때 Push-based / Pull-based 중 하나를 선택합니다.
이 차이는 3단계에서 아주 자세히 설명하겠습니다.
10. 언제 복제할 것인가?
Harbor는 Trigger Mode도 제공합니다.
대표적으로:
Manual
Scheduled
Event Based가 있습니다.
Manual
관리자가 직접 실행합니다.
관리자
↓
Replicate 클릭
↓
복제 시작테스트할 때 좋습니다.
Scheduled
주기적으로 실행합니다.
예를 들어:
매일 01:00
Harbor A
↓
Harbor BEvent Based
Image가 Push되면 자동으로 복제합니다.
예:
개발자
│
docker push
↓
Harbor A
myapp:v2
↓ 자동
Harbor B
myapp:v2운영 ↔ DR Registry를 거의 실시간에 가깝게 맞추고 싶다면 중요하게 보게 되는 방식입니다.
다만 진짜 Storage Sync나 DB Streaming처럼 완전한 실시간 동기 복제라고 이해하면 안 됩니다.
네트워크 상태와 Job 처리 등에 따라 Replication에는 지연이 있을 수 있으며 실패한 작업은 재시도될 수 있습니다.
11. Kubernetes와 연결하면 왜 좋은가?
사용 환경에서는 이 부분이 특히 중요합니다.
예를 들어 운영 Kubernetes가:
Kubernetes
│
↓
Harbor A에서 이미지를 받고 있다고 합시다.
Deployment에는:
image: harbor-a.company.com/project01/app:v1이렇게 되어 있습니다.
그리고 Harbor A 이미지를 Harbor B로 복제합니다.
Harbor A
│
Replication
│
↓
Harbor B그러면 DR 상황에서:
Kubernetes DR
│
↓
Harbor B에서 동일한 이미지를 사용할 수 있습니다.
그래서 Harbor Replication은 단순 복사 기능이라기보다:
Container Image DR 전략
에서 상당히 중요한 역할을 합니다.
12. 하지만 이것만으로 DR이 완성되지는 않습니다
초보자가 가장 많이 오해하는 부분입니다.
예를 들어:
Harbor A
↓
Replication
↓
Harbor B가 되어 있다고 해서:
Harbor A 장애
↓
자동으로 Harbor B 전환이 되는 것은 아닙니다.
별도로 고려해야 합니다.
예를 들어:
DNS
Load Balancer
Harbor URL
TLS 인증서
Kubernetes imagePullSecrets
Robot Account
Harbor DB
Redis
Storage등입니다.
즉:
Image 복제
+
Harbor 서비스 이중화
+
DR 전환 체계를 함께 설계해야 진짜 DR이 됩니다.
13. Replication과 HA도 다릅니다
이 차이도 매우 중요합니다.
Harbor HA
목적:
Harbor 자체가 죽지 않도록 구성
예:
LB
│
┌──────┴──────┐
↓ ↓
Harbor Core 1 Harbor Core 2
│ │
└──────┬──────┘
↓
Shared StorageHarbor Replication
목적:
다른 Registry에 Artifact를 복사
Harbor A
↓ WAN
Harbor B따라서:
HA
= 한 사이트 내부 서비스 가용성
Replication
= Registry 간 데이터 복제
DR
= 사이트 장애 대비라고 구분하면 이해하기 쉽습니다.
14. Backup과도 다릅니다
또 하나 중요합니다.
Replication ≠ Backup예를 들어 실수로:
myapp:v1 삭제했는데 Replication Rule에 삭제 전파까지 설정되어 있다면 Destination에서도 삭제될 수 있습니다.
그래서:
Replication
+
Backup전략을 따로 가져가는 것이 좋습니다.
예:
Harbor A
│
┌────────┴────────┐
↓ ↓
Replication Backup
↓ ↓
Harbor B Object Storage
DR센터 Backup 영역이런 식입니다.
15. 전체 그림을 한 번에 정리하면
앞으로 우리가 배우게 될 구조입니다.
개발자 / CI/CD
│
docker push
│
▼
┌─────────────────┐
│ Harbor A │
│ 운영센터 │
│ │
│ project01 │
│ └─ app:v1 │
└────────┬────────┘
│
│
Replication Rule
│
project01/** 복제
│
▼
WAN / 전용회선
│
▼
┌─────────────────┐
│ Harbor B │
│ DR센터 │
│ │
│ project01 │
│ └─ app:v1 │
└────────┬────────┘
│
▼
DR Kubernetes이 그림이 Harbor Native Replication의 핵심입니다.
⭐ 1단계에서 반드시 기억할 7가지
| Harbor | Container Registry |
| Repository | Image 저장 공간 |
| Artifact | 실제 Image/OCI 객체 |
| Endpoint | 상대 Registry 접속정보 |
| Replication Rule | 복제 정책 |
| Push | 내가 상대방에게 보냄 |
| Pull | 내가 상대방에서 가져옴 |
그리고 가장 중요한 한 문장:
Harbor Native Replication은 Harbor 전체 서버를 복제하는 기능이 아니라, Registry에 저장된 Container Image/OCI Artifact를 다른 Registry로 복제하는 기능입니다.
📚 다음 2단계
다음 단계에서는 실제 Harbor 화면을 이해하기 위해 Source / Destination / Endpoint / Rule 네 가지를 집중적으로 설명하는 것이 좋습니다.
특히 아래 구조를 하나씩 뜯어보겠습니다.
Harbor A
│
│ Source
│
├─ Project
├─ Repository
└─ Artifact
│
↓
Replication Rule
│
↓
Endpoint
│
↓
Harbor B
Destination그리고 실제 예제를:
harbor-prod.company.com
→ harbor-dr.company.com기준으로 만들어서 Harbor UI에서 어느 메뉴를 눌러야 하는지까지 연결하겠습니다.
댓글