미러와 두 번째 사이트
미러는 다른 설치 환경에 있는 리포지토리, 즉 원본의 읽기 전용 사본인 리포지토리입니다. 미러 설치 환경은 HTTPS로 원본에서 변경 사항을 가져옵니다. 데이터베이스, 스토리지, 계정, 키는 자체적으로 유지합니다.
미러는 두 번째 위치에서 다운로드를 제공하거나, 원본을 잃었을 때 인계받을 수 있는 두 번째 사이트를 유지하는 데 사용하세요. 미러는 원본의 백업이 아니며 자동 고가용성도 아닙니다. 전환은 직접 수행합니다. 다른 보호 수단은 백업과 읽기 게이트웨이를 참조하세요.
미러란 무엇인가
미러링되는 리포지토리에 대해 미러 설치 환경은 다음을 복사합니다.
- 게시된 파일. 바이트와 원본과 같은 아티팩트 ID를 그대로 가져옵니다.
- 레이블, 메타데이터, 컬렉션.
- UPack 등록 정보, 스테이지, 현재 파일 경로.
- 리포지토리의 컨테이너 이미지, Git LFS 객체, npm 패키지.
- 삭제. 원본에서 삭제한 파일은 미러에서도 삭제됩니다.
ID, 패키지(버전, 범위, 스테이지), 파일 경로로 하는 다운로드는 미러에서 마지막 동기화 시점의 원본과 같은 방식으로 응답합니다. 원본이 중단되어도 계속 동작합니다.
미러가 복사하지 않는 것은 다음과 같습니다.
- 계정, 그룹, 키, 권한 부여. 미러에는 자체 항목이 있으며 서로 독립적입니다. 원본에서 키를 폐기해도 미러에는 영향이 없습니다.
- 파일을 정리로부터 보호하는 참조, 빌드의 첨부 파일, 감사 기록, 스토리지 정책.
- 첫 번째 동기화 이전의 파일 경로 기록. 미러의 레이블과 경로의 리비전 번호는 미러 자체의 번호입니다.
클라이언트는 미러링되는 리포지토리에 쓸 수 없습니다. 이곳에 대한 업로드, 레이블 변경, 파일 경로, 스테이지, 삭제, 승격은 이유 mirror_read_only와 함께 HTTP 409를 받습니다. 미러 설치 환경의 다른 리포지토리는 평소처럼 동작합니다. 미러링되는 리포지토리에서는 스토리지 정책이 실행되지 않으며, 동기화만 삭제를 수행합니다.
미러 설정
원본에서 키 하나를, 미러에서 명령 하나를 사용합니다.
원본에서 키 만들기
미러에는 원본 리포지토리를 읽기만 할 수 있는 키가 필요합니다. 쓰기 키는 필요하지 않습니다.
- 원본에서 복구 키 또는 운영자 키로 연결하고 서비스 액세스 섹션을 여세요.
- 서비스 계정 만들기 버튼을 선택하고, 리포지토리 권한 항목에서 리포지토리를 추가하세요. 읽기 프리셋 버튼을 선택하면 미러에 필요한 권한이 채워집니다. 여기에는
artifact.list,artifact.read,content.read,annotation.read,asset.read,package.read가 포함됩니다. - 키 발급 버튼을 선택하고, 시크릿을 복사한 뒤 시크릿을 저장했습니다 확인란을 선택하고 키 활성화 버튼을 선택하세요. 활성화하지 않은 키는 15분 후에 만료됩니다.
- 시크릿을 미러 서버의 파일에 저장하세요. 파일에는 키만 한 줄로 들어가며, 출력 가능한 문자 16~4000자여야 합니다. root 또는 Administrators 그룹만 읽을 수 있어야 합니다.
원본은 변경 피드를 제공하는 릴리스여야 합니다. 다음 단계의 명령이 이를 확인합니다.
미러에서 리포지토리 연결
미러에서는 새롭고 비어 있는 리포지토리 이름을 사용하세요. 동기화는 리포지토리를 원본과 같게 만들지만, 원본에 없던 것을 삭제하지는 않습니다.
sudo arkvory configure --root /opt/proanima-arkvory \
--mirror releases \
--mirror-upstream https://arkvory.example \
--mirror-token-file /root/mirror-releases.key$root = 'C:\ProgramData\ProAnima\Arkvory'
& 'C:\Program Files\ProAnima\Arkvory\arkvory.ps1' configure --root $root `
--mirror releases --mirror-upstream https://arkvory.example `
--mirror-token-file C:\secure\mirror-releases.key| 옵션 | 의미 |
|---|---|
--mirror NAME | 이 설치 환경의 리포지토리. 1~64자: 소문자, 숫자, _, -이며 문자 또는 숫자로 시작합니다 |
--mirror-upstream URL | 원본의 오리진: https://host. 경로, 자격 증명, 쿼리는 없어야 합니다. 일반 http://는 localhost, 127.0.0.1, [::1]에서만 허용됩니다 |
--mirror-token-file FILE | 키 파일의 절대 경로 |
--mirror-source NAME | 원본의 리포지토리. 기본값은 --mirror와 같은 이름입니다 |
--mirror-ca-file FILE | 원본의 인증 기관이 들어 있는 PEM 파일. 자체 인증 기관을 사용하는 HTTPS를 참조하세요 |
한 번의 명령에는 리포지토리 하나만 지정하세요. 같은 호출에서 미러 변경을 HTTPS, 백업 보관소, 업데이트 변경과 함께 실행할 수 없습니다.
- 명령은 아무것도 바꾸기 전에 키로 원본을 확인합니다. 원본이 미러 변경 피드를 보고해야 하며, 원본 리포지토리의 피드가 응답해야 합니다.
- 키를
config/mirrors/NAME.token에 저장하고,config/mirrors/mirrors.json을 쓰고,config/runtime.json에ARKVORY_MIRRORS_FILE을 설정합니다. - API와 워커를 다시 시작하고 준비될 때까지 기다립니다. 어느 단계든 실패하면 이전 파일을 복원하고 다시 시작합니다.
Docker Compose에서는 이 명령이 config/compose.mirrors.yml도 씁니다. 이 파일은 미러 파일을 API 및 워커 컨테이너에 마운트합니다. 직접 실행하는 Compose 명령에 이 파일을 추가하세요.
리포지토리의 키를 교체하려면 --mirror와 새 --mirror-token-file만 지정해 명령을 다시 실행하세요. 원본, 스테이지, 인증 기관은 그대로 유지되며, 명령을 다시 실행해도 미러가 가져오기로 바뀌지 않습니다. 명령은 API와 워커를 다시 시작합니다. 또한 워커는 실패할 때마다 키 파일을 다시 읽으므로, 직접 교체한 키 파일은 다시 시작하지 않아도 동작합니다.
sudo arkvory configure --root /opt/proanima-arkvory \
--mirror releases --mirror-token-file /root/new-mirror-releases.key원본이 키를 거부하면 명령은 아무것도 바꾸기 전에 멈추고 이유를 알려 줍니다. 키가 허용되지 않음(401), 키에 리포지토리 읽기 권한이 없음(403), 또는 원본에 리포지토리가 없음(404)입니다. 이미 한 원본을 미러링하는 리포지토리에 다른 원본을 지정하면 NAME mirrors another source; detach it first 메시지와 함께 거부됩니다.
미러 설치 환경에서 사람과 도구가 리포지토리에 접근할 수 있게 하세요. 권한 부여나 서비스 정책에 이름이 지정되는 즉시 리포지토리가 존재합니다. 사람에게는 사용자 및 액세스 섹션의 리포지토리 액세스 관리 항목을, 도구에는 서비스 정책을 사용하세요. 원본의 권한은 이어지지 않습니다.
자체 인증 기관을 사용하는 HTTPS
원본이 기업 인증 기관 또는 자체 서명 인증 기관의 인증서를 사용한다면 --mirror 명령에 --mirror-ca-file /path/ca.pem을 추가하세요. 명령은 각 인증서를 읽을 수 있고 만료되지 않았는지 확인한 다음, 인증서 1~64개를 config/mirrors/ca.pem에 저장합니다(파일은 1 MiB를 넘을 수 없습니다). 이후 워커는 표준 인증서에 더해 이 인증서도 신뢰합니다.
- 이 파일은 설치 환경의 모든 미러에 적용됩니다. 새
--mirror-ca-file은 기존 파일에 추가되며, 이미 있는 인증서는 한 번만 유지됩니다. 마지막 미러를 분리하면 파일이 제거됩니다. - 워커는 한 미러뿐 아니라 모든 연결에 이 전체 집합을 신뢰합니다.
- 인증서 검사는 절대 끄지 않습니다.
복사 대상과 주기
동기화는 미러 설치 환경의 워커가 수행합니다. 별도의 서비스는 없습니다. 워커는 미러링되는 각 리포지토리에 대해 다음 단계를 실행합니다.
- 최초 채우기. 워커는 원본 변경 피드의 현재 위치를 기록합니다. 그런 다음 아티팩트, 패키지, 파일 경로의 목록을 페이지 단위로 읽어 미러를 그와 같게 만듭니다.
- 추적. 워커는 원본의 피드를 읽습니다. 따라잡으면 10초마다 다시 확인합니다. 적용한 변경마다 자신의 위치를 저장합니다.
- 파일 복사. 파일은 파트 단위로 복사됩니다. 워커는 각 파트와 전체 파일의 SHA-256을 확인합니다. 중단된 뒤에는 처음으로 누락된 파트부터 이어서 복사합니다. 파트는 미러의 스토리지 디렉터리 안의
mirror-staging에서 대기합니다. - 오류 후. 워커는 2초에서 시작해 최대 5분까지 두 배씩 늘어나는 시간만큼 쉰 뒤 단계를 반복합니다. 실패하는 미러 하나가 다른 미러를 멈추지 않습니다.
설치 환경 하나는 미러링되는 리포지토리를 최대 64개까지 가질 수 있습니다. 사본은 미러의 용량 제한과 디스크를 사용하므로 원본 리포지토리에 필요한 만큼의 공간을 계획하세요. 스토리지를 참조하세요.
원본 키가 폐기되었거나 원본에 접근할 수 없으면 미러는 이미 가진 데이터를 계속 제공하고 상태에 오류를 표시합니다.
동기화 상태 확인
콘솔에서
메뉴의 미러에는 읽을 수 있는 리포지토리의 모든 미러와 가져오기가 원본, 상태, 마지막 동기화 시각, 복사된 내용과 함께 나열됩니다. 관리자에게는 이 페이지가 항상 보이며, 미러가 없는 동안에는 설정 방법을 안내합니다. 페이지는 20초마다 저절로 새로 고쳐집니다.
| 상태 | 의미 |
|---|---|
| 동기화됨 | 원본을 따라잡았습니다 |
| 따라잡는 중 | 마지막 확인 이후 원본에서 생긴 변경을 복사하는 중입니다 |
| 시작 중 | 구성되었지만 워커가 아직 도달하지 않았습니다 |
| 첫 복사 | 최초 채우기, 또는 원본이 복원된 뒤의 새 채우기입니다 |
| 동기화 오류 | 마지막 시도가 실패했습니다. 다운로드는 계속 동작하며, 워커가 스스로 재시도합니다 |
동기화가 멈추면 페이지에 그 이유와 다음에 할 일이 표시되고, 해결 명령이 있으면 그 명령도 표시됩니다. 예를 들어 원본이 이전 키를 거부한 뒤에는 새 키를 지정하는 명령입니다. 이 설명은 오류 코드를 따릅니다.
미러링되는 리포지토리에 연결하면 콘솔은 카탈로그 위에 미러, 미러 · 동기화 중 또는 미러 · 동기화 오류 배지도 표시합니다. 동기화가 멈춘 동안에는 그 아래에 이유와 다음 단계가 나타나며, 배지는 다시 로드하지 않아도 서버의 상태를 따라갑니다. 배지의 도움말(이 미러 정보)을 열면 원본과 마지막 동기화 시각을 볼 수 있습니다. 콘솔은 미러링되는 리포지토리에서 업로드 버튼과 변경 버튼을 숨깁니다.
API로
getRepositoryMirror는 리포지토리의 상태를 반환합니다. 리포지토리를 읽을 수 있는 권한이 필요합니다. 일반 리포지토리에 대해서는 404로 응답합니다.
| 필드 | 의미 |
|---|---|
mode | mirror 또는 import |
phase | pending(워커가 아직 시작하지 않음), seeding(최초 채우기), following |
caughtUp | 저장된 위치가 원본의 최신 위치와 같으면 true. 최초 채우기가 끝나기 전에는 null |
checkedAt, syncedAt | 워커가 피드를 마지막으로 읽은 시각, 마지막으로 따라잡은 시각 |
copiedArtifacts, copiedBytes | 지금까지 복사한 합계(copiedBytes는 10진수 문자열) |
conflicts | 보류된 원본 항목: count, oldestAt, 그리고 sample에 최대 10개 항목. 보류된 항목을 참조하세요 |
errorCode, errorAt | 단계의 마지막 실패, 또는 null |
오류 코드
errorCode | 의미와 해야 할 일 |
|---|---|
mirror_mismatch | 같은 아티팩트 ID가 원본에서는 다른 콘텐츠입니다. 미러는 자신의 파일을 유지합니다. 아티팩트를 조사하세요. 원인을 알기 전에는 어느 사본도 삭제하지 마세요 |
mirror_source_changed | 리포지토리에 이미 다른 원본의 사본이 있습니다. 분리하거나, 새 원본을 새 리포지토리에 미러링하세요 |
mirror_source_behind | 원본이 복원되었거나 다시 설치되어, 미러 위치의 변경이 미러가 그 위치에서 적용한 변경과 다릅니다. 미러가 원본을 다시 읽으며, 따라잡으면 코드가 사라집니다. 복원된 원본에 없는 파일은 미러에 남습니다 |
mirror_delete_blocked | 원본이 미러에서는 삭제할 수 없는 파일을 삭제했습니다. 참조나 파일 경로 기록처럼 이곳의 무언가가 아직 그 파일을 사용하기 때문입니다 |
mirror_detached | 리포지토리가 분리되었고 자체 변경이 있습니다. 다시는 동기화되지 않습니다. 원본을 새 리포지토리로 미러링하세요 |
mirror_package_conflict | 원본의 버전에 이 리포지토리가 다른 바이트로 보유한 패키지 버전이 있습니다. 해당 항목은 보류되고 동기화는 계속됩니다. 보류된 항목을 참조하세요. 이전 릴리스는 여기서 멈췄습니다 |
mirror_id_taken | 원본의 아티팩트를 이 설치 환경의 다른 리포지토리가 보유하고 있습니다. 해당 항목은 보류됩니다. 보류된 항목을 참조하세요. 컨테이너 이미지 태그, Git LFS 객체, npm 패키지의 변경에서는 동기화가 멈춥니다. 원본 리포지토리 하나는 이곳의 리포지토리 하나만 채울 수 있습니다 |
mirror_unreachable | 원본에 연결할 수 없습니다. 연결이 거부되거나 시간이 초과되었거나, 이름을 확인할 수 없습니다. 워커가 스스로 재시도합니다. 네트워크, 방화벽, 원본의 실행 여부를 확인하세요 |
mirror_certificate | 원본의 인증서를 신뢰할 수 없거나, 만료되었거나, 이름과 일치하지 않습니다. --mirror-ca-file로 해당 인증 기관을 추가하세요(자체 인증 기관을 사용하는 HTTPS 참조) |
mirror_failed | 더 구체적인 코드가 없는 실패입니다. 워커 로그를 읽으세요 |
| 그 외 코드 | 실패한 요청의 코드: 원본이 더 이상 키를 허용하지 않으면 unauthorized(미러에 새 키를 지정하세요), 키에 리포지토리 읽기 권한이 없으면 forbidden, 원본 리포지토리가 없어졌으면 not_found, 미러가 가득 찼으면 capacity_exceeded |
워커 로그(component가 mirror)에는 mirror.started, errorCode와 attempts가 있는 mirror.step_failed, mirror.recovered, mirror.stopped가 있습니다.
보류된 항목
원본의 일부 변경은 여기에 이미 있는 것을 깨뜨리지 않고는 적용할 수 없습니다. 워커는 그런 항목을 보류하고 나머지 변경을 계속 처리하므로, 버전 하나가 이후의 모든 변경을 막지 않습니다. 아무것도 조용히 건너뛰지 않습니다. 보류된 항목은 해결될 때까지 모두 표시됩니다.
| 코드 | 의미 | 해야 할 일 |
|---|---|---|
mirror_package_conflict | 해당 버전에 이 리포지토리가 다른 바이트로 보유한 패키지 버전(그룹, 이름, 버전)이 있습니다. 클라이언트는 계속 여기에 있는 버전을 받으며, 복사된 파일은 패키지 등록 없이 남습니다 | 원본에서 스테이지나 버전을 제거하거나, 다른 버전으로 게시하세요. 가져오기에서는 여기의 버전을 삭제할 수도 있습니다 |
mirror_id_taken | 이 설치 환경의 다른 리포지토리가 아티팩트 ID를 보유하고 있습니다 | 원본 리포지토리 하나는 이곳의 리포지토리 하나를 채웁니다. 다른 미러나 가져오기를 분리하거나 다른 복사본을 삭제하세요 |
- 워커는 각 항목을 마지막 시도 10분 후에 다시 시도하며, 원본을 따라잡을 때마다 최대 8개 항목을 처리합니다. 항목은 적용되거나 원본에 더 이상 없을 때 제거됩니다. 원본에서 버전이 삭제되었거나, 가져오기의 경우 스테이지가 제거된 경우입니다.
- 상태의
conflicts는 보류된 항목 수, 가장 오래된 항목이 보류된 시각, 그리고 최대 10개 항목을 아티팩트 ID, 변경(action과detail), 코드, 첫 시도와 마지막 시도, 시도 횟수와 함께 보여 줍니다. - 콘솔은 미러와 리포지토리 배지 아래에 그 수를 표시합니다. 나머지는 계속 동기화되므로 상태는 바뀌지 않습니다.
- 워커 로그에는 실패한 시도마다
mirror.conflict_set_aside(warning,artifactId,action,errorCode,attempts포함)가, 항목이 제거되면mirror.conflict_resolved가 기록됩니다. - 메트릭
arkvory_mirror_conflicts가 그 수를 세고, 규칙ArkvoryMirrorConflicts는 30분 동안 보류된 항목이 있으면 경고합니다.
컨테이너 이미지 태그와 매니페스트, Git LFS 객체, npm 패키지의 변경은 절대 보류되지 않습니다. 순서가 중요하므로 나중에 적용하면 더 새로운 변경을 되돌릴 수 있기 때문입니다. 이런 변경의 충돌은 해결될 때까지 해당 코드로 동기화를 멈춥니다.
미러 모니터링
미러 설치 환경의 API는 미러링되는 리포지토리마다 repository와 mode 레이블이 있는 메트릭 네 개를 제공합니다.
arkvory_mirror_last_sync_timestamp_seconds: 미러가 마지막으로 따라잡은 시각.arkvory_mirror_last_check_timestamp_seconds: 피드를 마지막으로 읽은 시각.arkvory_mirror_failing: 마지막 시도가 실패한 동안 1. 단, 미러가 복원된 원본을 다시 읽는 동안(mirror_source_behind)에는 아닙니다.arkvory_mirror_conflicts: 보류된 항목의 수.
바로 사용할 수 있는 Prometheus 규칙은 ArkvoryMirrorStale(1시간 넘게 따라잡지 못한 상태가 15분 동안 지속됨)과 ArkvoryMirrorFailing(실패가 15분 동안 지속됨)입니다. 모니터링을 참조하세요. 워커가 아직 도달하지 않은 미러에는 동기화 시각이 없으므로, stale 규칙은 첫 번째 동기화 전에는 발동하지 않습니다. ArkvoryMirrorConflicts는 항목이 30분 동안 보류되어 있으면 경고합니다.
스테이지별 가져오기
--mirror-stages를 지정하면 두 번째 설치 환경의 리포지토리는 미러가 아닙니다. 원본에서 지정한 스테이지가 붙은 버전을 가져오는 일반 쓰기 가능 리포지토리입니다. 개발 서버의 빌드를 프로덕션 서버로 옮길 때 사용하세요.
sudo arkvory configure --root /opt/proanima-arkvory \
--mirror releases --mirror-upstream https://dev.example \
--mirror-token-file /root/dev.key --mirror-stages release- 서로 다른 스테이지 이름을 1~16개, 쉼표로 구분해 나열합니다.
- 버전은 같은 ID, 바이트, 레이블, UPack 등록 정보, 일치하는 스테이지와 함께 한 번 복사됩니다.
- 그 이후에는 이 설치 환경에 속합니다. 원본에서의 변경, 스테이지 제거, 삭제는 반영되지 않습니다. 여기에서 삭제한 버전은 다시 가져오지 않습니다. 여기에서 제거한 스테이지는 제거된 상태로 유지됩니다. 나중에 원본이 버전에 구성된 다른 스테이지를 붙이면 그 스테이지만 추가됩니다.
- 리포지토리의 업로드와 스토리지 정책은 평소처럼 동작합니다.
- 컨테이너 이미지, Git LFS, npm 레지스트리 데이터는 가져오지 않습니다.
- 스테이지를 변경하면 새로 최초 채우기를 시작합니다. 아직 여기에 없는 버전만 가져오고, 이미 있는 버전은 그대로 둡니다.
- 이 리포지토리가 이미 다른 바이트로 보유한 패키지 버전을 가진 원본 버전은
mirror_package_conflict로 보류되고, 가져오기는 다음 버전으로 계속됩니다. 클라이언트는 계속 여기에 있는 버전을 받습니다. 보류된 항목을 참조하세요.
두 설치 환경은 서로에게서 가져올 수 있습니다. 예를 들어 프로덕션은 스테이징에서 release를 가져오고, 스테이징은 프로덕션에서 hotfix를 가져옵니다. 버전은 양쪽에서 같은 ID를 유지하므로 어떤 것도 두 번 복사되거나 순환하지 않습니다.
- 스테이징에서 만든 버전이 프로덕션에서 되돌아오면 새 스테이지만 받습니다.
- 한쪽에서 삭제한 버전은 다른 쪽이 나중에 스테이지를 붙여도 다른 쪽에서 다시 가져오지 않습니다.
- 삭제는 전달되지 않습니다. 다른 쪽은 그곳에서도 삭제할 때까지 자신의 사본을 유지합니다.
두 방향에 서로 다른 스테이지를 사용하세요. 두 방향에 같은 스테이지를 쓰면 한쪽에서 제거한 스테이지는 다른 쪽이 그 버전에 스테이지를 다시 붙일 때 돌아옵니다.
콘솔에는 가져오기 배지가 표시되고, 마지막 시도가 실패하면 가져오기 · 동기화 오류 배지가 표시됩니다. 원본의 키에는 미러와 같은 읽기 전용 권한이 필요합니다.
원본을 잃었을 때 장애 조치
이것은 두 사이트의 독립된 설치 환경 두 개를 위한 수동 전환입니다. 자동이 아닙니다. 미러가 아직 가져오지 못한 변경은 사라집니다.
미리 준비하기
- 가능하면 원본과 같은 릴리스로 두 번째 사이트를 설치하세요. 자체 PostgreSQL과 자체 디스크를 사용합니다. 두 사이트는 아무것도 공유하지 않습니다.
- 원본에 읽기 전용 키를 만들고 모든 리포지토리를 미러로 연결하세요. 나중에 원본에서 만든 리포지토리는 미러에 저절로 나타나지 않으므로 같은 방식으로 연결하세요.
- 미러에서는 클라이언트가 사용할 키를 발급하세요. 전환 후 쓰기가 가능한 키도 포함합니다. 원본의 권한은 이어지지 않으므로, 원본이 침해되어도 미러에는 접근할 수 없습니다.
- 다운로드용 대체 경로로 미러의 주소를 클라이언트(CI, 배포 에이전트)에 설정하세요. 이렇게 하면 원본과의 링크 부하도 줄어듭니다.
- 원본을 해당 사이트 밖의 백업 보관소에 백업하세요. 백업을 참조하세요. 미러는 이를 대체하지 않습니다.
- 위의 규칙으로 미러를 모니터링하세요.
전환
원본이 클라이언트에게 실제로 사용할 수 없고 저절로 돌아오지 않을 것인지 확인하세요. 하나의 논리적 리포지토리에 쓰기를 받는 두 사이트는 나중에 병합할 수 없습니다. 원본에 일부 접근할 수 있다면 서비스를 중지하거나 포트를 닫으세요.
미러에서 각 리포지토리의
syncedAt을 읽으세요. 그 시각 이후 원본에서 일어난 변경은 미러에 없습니다.미러에서 미러링되는 각 리포지토리를 분리하세요. 분리하면 같은 아티팩트 ID와 모든 데이터를 가진 일반 쓰기 가능 리포지토리가 됩니다.
bashsudo arkvory configure --root /opt/proanima-arkvory --mirror-detach releases,prod여러 리포지토리를 쉼표로 구분해 지정하거나, 모든 미러와 가져오기에 대해
all을 지정하세요. 이 명령은 API와 워커를 한 번 다시 시작하므로 잠시 중단됩니다.쓰기를 하는 클라이언트가 DNS 또는 CI 구성을 통해 미러를 가리키게 하세요.
미러에 확인용 파일을 업로드하고 다운로드하세요.
클라이언트에게 보이는 동작은 다음과 같습니다.
- 전환 전에는 미러에서의 다운로드가 동작하고, 쓰기는 409
mirror_read_only를 받습니다. - 분리한 후에는 쓰기가 동작합니다. 배지가 사라집니다.
- 같은 계정을 미러에 만들어 두지 않았다면 원본의 키와 비밀번호는 미러에서 동작하지 않습니다.
되돌릴 방법은 없습니다. 분리한 리포지토리는 다시 미러로 연결할 수 없으며, 그 동기화는 mirror_detached로 멈춥니다. 이전 원본을 되살리려면 그 원본을 비우거나 새로 설치하고, 새 기본 서버의 리포지토리를 미러로 연결하세요. 쓰기가 켜진 상태로 이전 원본과 새 기본 서버를 나란히 실행하지 마세요.
예행연습
분기마다, 그리고 업데이트 후에 전환을 예행연습하세요. 예비 사본에서 리포지토리 하나를 분리하고, syncedAt, 다운로드, 업로드를 확인한 다음 날짜와 결과를 기록하세요. 원본 백업을 빈 설치 환경에 복원하는 테스트는 별도로 수행하세요. 복원을 정기적으로 테스트를 참조하세요.
제한 사항
- 미러는 분리하기 전까지 읽기 전용입니다. 분리한 리포지토리는 다시 미러가 될 수 없습니다.
- 미러는 백업이 아닙니다. 계정, 키, 권한 부여의 사본이 없으며, 참조, 첨부 파일, 감사 기록, 스토리지 정책을 복사하지 않습니다.
- 가져오기 모드는 컨테이너 이미지, Git LFS, npm 데이터를 복사하지 않습니다.
- 새 최초 채우기는 추가와 업데이트만 합니다. 원본을 복원한 뒤에는 원본이 잃은 파일이 미러에 남습니다.
- 원본 리포지토리 하나는 설치 환경의 리포지토리 하나를 채웁니다. 아티팩트 ID가 양쪽에서 같으므로, 같은 원본의 두 번째 미러나 가져오기는 구성할 때 거부됩니다. 같은 이유로, 서로에게서 가져오는 두 설치 환경은 양쪽에서 같은 리포지토리 이름을 사용해야 합니다. 반대쪽에서 온 버전은 여기의 다른 리포지토리로 가져올 수 없으며, 해당 버전은
mirror_id_taken으로 보류됩니다. - 이미 다른 바이트로 여기에 보유된 패키지 버전을 가진 버전은 복사된 뒤
mirror_package_conflict로 보류됩니다. 복사본은 삭제할 때까지 패키지 등록 없이 리포지토리에 남습니다. - 보류된 항목은 해결될 때까지 여기에 없습니다. 컨테이너 이미지 태그, Git LFS 객체, npm 패키지 변경의 충돌은 여전히 동기화를 멈춥니다.
- 미러 설치 환경을 백업에서 복원한 뒤에는, 백업 이후에 가져왔다가 삭제한 버전을 다시 가져올 수 있습니다.
- 두 설치 환경은 각각 따로 업데이트합니다. 원본은 미러 변경 피드를 제공해야 합니다.
- 원본의 신뢰할 인증 기관 집합은 워커 전체에 적용됩니다.
- 자동 장애 조치, 이전 원본의 펜싱, 역방향 동기화는 없습니다.