📘 Harbor Native Replication 2단계
Source / Destination / Endpoint / Replication Rule 쉽게 이해하기
이제부터는 Harbor Replication의 실제 설정 구조로 들어가면 됩니다.
이번 단계의 핵심은 딱 4개입니다.
Source
Destination
Endpoint
Replication Rule이 네 가지 관계만 정확히 이해하면 Harbor Replication 화면을 봐도 훨씬 덜 어렵습니다.
1. 전체 그림부터 보겠습니다
운영 Harbor의 이미지를 DR Harbor로 복제한다고 가정하겠습니다.
[운영센터]
Harbor A
harbor-prod.company.com
│
│ Replication
↓
Harbor B
harbor-dr.company.com
[DR센터]여기서 역할은 다음과 같습니다.
| Source | 복제할 원본 |
| Destination | 복제받을 대상 |
| Endpoint | 상대 Registry의 접속정보 |
| Replication Rule | 무엇을, 어디로, 언제 복제할지 정한 규칙 |
이제 하나씩 보겠습니다.
2. 📤 Source란?
Source = 원본 데이터가 있는 곳입니다.
예를 들어 운영 Harbor에 다음 이미지가 있다고 해보겠습니다.
Harbor A
project01/
├─ api:v1
├─ api:v2
└─ web:v1그리고 이것을 Harbor B로 복제한다면:
Harbor A
↑
Source입니다.
즉,
"어디에 있는 이미지를 복제할 것인가?"
에 대한 답이 Source입니다.
3. 📥 Destination이란?
반대로:
"복제된 이미지를 어디에 저장할 것인가?"
가 Destination입니다.
Harbor A
Source
│
│ Replication
↓
Harbor B
Destination예를 들어:
Source
harbor-prod.company.com
Destination
harbor-dr.company.com입니다.
복제가 성공하면:
Harbor A
project01/api:v1
↓
Harbor B
project01/api:v1처럼 동일한 Artifact가 생깁니다.
4. Source와 Destination은 고정인가?
아닙니다.
이 부분이 중요합니다.
Replication 방식에 따라 Source와 Destination 관점이 달라질 수 있습니다.
예를 들어 Push Replication이면:
Harbor A
Source
│
│ PUSH
↓
Harbor B
Destination입니다.
반면 Harbor B에서 Pull Rule을 만들면:
Harbor A
Remote Source
│
│ PULL
↓
Harbor B
Local Destination이 됩니다.
그래서 Harbor Replication을 볼 때는 항상:
"이 Rule을 어느 Harbor에서 만들었는가?"
를 같이 봐야 합니다.
이건 다음 3단계에서 Push/Pull을 설명할 때 더 자세히 다루겠습니다.
5. 🔌 Endpoint란?
이제 Harbor A가 Harbor B로 이미지를 보내려고 합니다.
그런데 Harbor A 입장에서는 Harbor B에 대해 최소한 이런 정보가 필요합니다.
주소
계정
비밀번호 또는 Secret
인증서 관련 정보
Registry 종류예:
Name:
harbor-dr
URL:
https://harbor-dr.company.com
Username:
robot$replication
Password:
********이 묶음을 Harbor에서는 Endpoint라고 생각하면 됩니다.
즉:
Endpoint = 원격 Registry 접속 프로파일
입니다.
6. 아주 쉽게 비유하면
회사 A가 회사 B에 택배를 보낸다고 생각해보겠습니다.
회사 A
↓
회사 B회사 A는 회사 B의 정보를 알아야 합니다.
회사명
주소
담당자
연락처
출입 인증Harbor도 똑같습니다.
Remote Registry Name
URL
Username
Password / Token
TLS 정보이것이 Endpoint입니다.
7. Endpoint가 왜 필요한가?
Replication Rule에 매번 다음 정보를 직접 넣으면 번거롭습니다.
https://harbor-dr.company.com
robot$replication
Password
TLS 설정그래서 먼저 Endpoint를 하나 등록해 둡니다.
Endpoint
Name: harbor-dr
URL : https://harbor-dr.company.com
Auth: robot account그러면 Replication Rule에서는:
Destination Registry
harbor-dr만 선택하면 됩니다.
즉:
Endpoint 등록
↓
Replication Rule에서 재사용구조입니다.
8. 🔐 Endpoint 계정은 아무 계정이나 써도 되나?
기술적으로 권한이 충분한 계정을 사용할 수 있지만, 운영 환경에서는 보통 Robot Account 같은 전용 계정을 사용하는 것이 좋습니다.
예:
Harbor A
│
│ robot$replication
↓
Harbor B이 계정에는 필요한 권한만 줍니다.
예를 들어 Push Replication이라면 Destination 측에서:
project01
Repository Push
Repository Pull
Artifact 관련 필요한 권한등을 갖도록 설계합니다.
왜 admin 계정을 안 쓰는 게 좋을까요?
admin
= 너무 많은 권한Replication만 필요한데 전체 관리자 권한을 주는 것은 보안 측면에서 좋지 않습니다.
이 부분은 이후 Robot Account 단계에서 별도로 자세히 다루겠습니다.
9. 📋 Replication Rule이란?
이제 핵심입니다.
Replication Rule = 복제 정책
입니다.
쉽게 표현하면:
어떤 Image를 + 어느 Registry로 + 어떤 조건으로 + 언제 복제할 것인가
를 정의합니다.
예:
Rule Name
prod-to-dr
Source
Local Harbor
Destination
harbor-dr Endpoint
Filter
project01/**
Trigger
Event Based이것이 Replication Rule입니다.
10. Rule을 문장으로 바꾸면?
위 설정을 한국말로 바꾸면:
운영 Harbor에서 project01에 등록되는 Artifact를 DR Harbor로 Event 기반으로 자동 복제해라.
입니다.
즉 Rule은 하나의 명령문과 비슷합니다.
[무엇을]
project01/**
[어디서]
Harbor A
[어디로]
Harbor B
[언제]
Image Push Event 발생 시
[어떻게]
Push Replication11. Replication Rule 내부에는 무엇이 있나?
보통 다음 항목들을 보게 됩니다.
Replication Rule
├─ Name
├─ Replication Mode
├─ Source / Destination Registry
├─ Resource Filter
│ ├─ Name
│ ├─ Tag
│ └─ Label
├─ Destination Namespace
├─ Trigger Mode
├─ Override
└─ Delete Remote Resources처음에는 너무 많아 보이지만 크게 나누면 세 가지입니다.
A. 어디서 어디로?
Source
Destination
EndpointB. 무엇을?
Project
Repository
Tag
ArtifactC. 언제?
Manual
Scheduled
Event Based입니다.
12. 실제 예제로 보겠습니다
운영 Harbor:
https://harbor-prod.company.comDR Harbor:
https://harbor-dr.company.com운영 Harbor에 다음 이미지가 있습니다.
project-ai/
├─ inference:v1
├─ inference:v2
└─ trainer:v5우리는 이것을 모두 DR에 복제하고 싶습니다.
Endpoint
먼저 운영 Harbor에:
Endpoint Name:
harbor-dr
URL:
https://harbor-dr.company.com을 등록합니다.
Replication Rule
그다음:
Rule Name:
prod-ai-to-dr
Mode:
Push
Destination:
harbor-dr
Filter:
project-ai/**
Trigger:
Event Based를 만듭니다.
13. 그러면 실제 동작은?
개발자가:
docker push harbor-prod.company.com/project-ai/inference:v3를 실행합니다.
흐름은:
개발자
↓ docker push
Harbor A Registry
↓
project-ai/inference:v3 저장
↓
Event 발생
↓
Replication Rule 확인
↓
project-ai/** 조건 일치
↓
JobService가 Replication Job 실행
↓
Endpoint 정보 사용
↓
Harbor B 접속
↓
project-ai/inference:v3 Push
↓
복제 완료가 됩니다.
14. Kubernetes Pod 구조와 연결하면
1.5단계에서 배운 내용을 연결해보겠습니다.
Harbor A
┌──────────────┐
│ Core │
└──────┬───────┘
│
Replication Rule
│
↓
┌──────────────┐
│ JobService │
└──────┬───────┘
│
│ Endpoint 정보
↓
harbor-dr.company.com
│
↓
Harbor B Registry
│
↓
Storage따라서:
- Core → Replication 정책 관리
- JobService → Replication 작업 수행
- Registry → Image/Artifact 전송·수신
- Endpoint → 상대 Harbor 접속정보
라고 연결해서 이해하면 됩니다.
15. Endpoint와 Destination의 차이가 헷갈릴 수 있습니다
초보 단계에서 가장 많이 헷갈리는 부분입니다.
예를 들어:
Destination
= Harbor B
Endpoint
= Harbor B에 접속하기 위한 정보입니다.
비유하면:
Destination
= 친구 집
Endpoint
= 친구 집 주소 + 현관 비밀번호라고 생각하면 아주 쉽습니다. 😄
16. Source와 Filter도 다릅니다
이것도 중요합니다.
Source가:
Harbor A라고 해서 Harbor A의 모든 Image를 무조건 복제하는 것은 아닙니다.
Filter를 걸 수 있습니다.
예:
Harbor A
project-a
project-b
project-c중에서:
project-a/**만 복제할 수 있습니다.
그래서:
Source
= 어느 Registry인가?
Filter
= 그 Registry에서 무엇을 복제할 것인가?입니다.
17. Namespace란?
Replication Rule 화면에서 Destination Namespace 같은 표현도 볼 수 있습니다.
Harbor에서는 대체로 Project 경로와 관련해서 이해하면 됩니다.
예를 들어 Source가:
Harbor A
project01/app:v1인데 Destination에서는:
Harbor B
backup/project01/app:v1같이 다른 경로 구조로 저장하고 싶을 수 있습니다.
이때 Destination Namespace 설정이 관련됩니다.
초보 단계에서는:
복제된 Repository를 Destination의 어느 Project/경로 아래 둘 것인지 정하는 옵션
정도로 이해하면 충분합니다.
18. Override란?
Destination에 이미 같은 Artifact/Tag가 있을 수 있습니다.
예를 들어:
Harbor B
project01/app:v1이 이미 존재합니다.
그런데 Harbor A에서도:
project01/app:v1을 복제하려고 합니다.
이때 기존 것을 덮어쓸 것인지 결정하는 옵션이 Override입니다.
개념적으로:
Override OFF
이미 있으면
→ 기존 유지 / SkipOverride ON
이미 있어도
→ Source 기준으로 갱신정도로 이해하면 됩니다.
운영에서는 무조건 ON으로 두기보다 Image Tag 정책과 함께 봐야 합니다.
특히:
latest
prod
stable같이 동일 Tag를 재사용한다면 더 신중해야 합니다.
19. Delete Remote Resources란?
조금 위험한 옵션입니다. ⚠️
예를 들어 Source에서:
project01/app:v1을 삭제했습니다.
Rule 설정에 따라 Destination에서도:
project01/app:v1을 삭제하도록 만들 수 있습니다.
즉:
Harbor A
app:v1 삭제
↓ Replication
Harbor B
app:v1 삭제가 가능합니다.
DR 환경에서는 이 옵션을 아주 신중하게 사용해야 합니다.
왜냐하면 실수로 Source에서 이미지를 삭제했는데:
운영 삭제
↓
DR에서도 삭제되면 DR의 의미가 약해질 수 있기 때문입니다.
그래서:
Replication과 Backup은 별개
라고 앞 단계에서 말씀드렸던 것입니다.
20. 네 가지 개념을 한 그림으로 정리
Source
Harbor A / 운영센터
│
│
project01/**
│
↓
┌─────────────────────┐
│ Replication Rule │
│ │
│ Mode : Push │
│ Filter: project01/**│
│ Trigger: Event │
└──────────┬──────────┘
│
│
Endpoint
│
┌──────────┴──────────┐
│ URL │
│ Username │
│ Password / Secret │
│ TLS │
└──────────┬──────────┘
│
↓
Destination
Harbor B / DR센터
│
↓
project01/**21. 제일 쉬운 비유 🎁
택배로 비유하면 완벽합니다.
Source
= 보내는 사람의 창고
Filter
= 어떤 물건을 보낼지
Replication Rule
= 배송 지시서
Endpoint
= 받는 곳 주소 + 출입정보
Destination
= 실제 물건을 받을 창고예:
서울 창고
│
│ "노트북만 부산으로 보내라"
│
↓
배송 지시서
│
│ 부산 창고 주소 확인
↓
부산 창고Harbor로 바꾸면:
Harbor A
│
│ project-ai/** 복제
↓
Replication Rule
│
│ harbor-dr Endpoint
↓
Harbor B입니다.
22. 실제 운영/DR 예제
제가 추천하는 기본적인 이해용 구성은 이런 모습입니다.
운영 K8s Cluster
Harbor PROD
│
harbor-prod.company.com
│
│
Native Replication
│
│
───────── WAN ─────────
│
↓
Harbor DR
│
harbor-dr.company.com
DR Cluster그리고 Rule:
Name
prod-to-dr
Mode
Push
Source
Local PROD Harbor
Destination Endpoint
harbor-dr
Filter
project-prod/**
Trigger
Event Based
Override
환경에 맞게 결정
Delete Remote
초기에는 신중하게 / 보통 OFF부터 검토이렇게 시작하면 구조를 이해하기 좋습니다.
⭐ 2단계에서 꼭 기억할 것
딱 네 문장만 기억하시면 됩니다.
① Source
Image가 현재 있는 Registry
Harbor A② Destination
Image를 복제받을 Registry
Harbor B③ Endpoint
상대 Harbor에 접속하기 위한 주소 + 인증정보
URL
ID
Secret
TLS④ Replication Rule
무엇을 / 어디로 / 언제 복제할지 정한 정책
Source
↓
Filter
↓
Rule
↓
Endpoint
↓
Destination🎯 여기까지 이해했다면
이제 다음 3단계가 굉장히 중요합니다.
Push Replication vs Pull Replication입니다.
겉으로 보면 둘 다:
Harbor A
↓
Harbor B인데 실제로는 누가 연결을 시작하는지, 방화벽을 어느 방향으로 열어야 하는지, 운영센터↔DR센터에서 어떤 방식을 선택해야 하는지가 달라집니다.
특히 DR 구성에서는 이 차이가 설계에 직접 영향을 줍니다. 다음 3단계에서는 방화벽/네트워크 관점까지 포함해서 Push와 Pull을 그림으로 아주 쉽게 설명하면 좋습니다.
댓글