forked from baron/baron-sso
병합 후 flow업데이트
This commit is contained in:
@@ -2,42 +2,47 @@
|
||||
|
||||
## 목적
|
||||
|
||||
WORKS Drive는 Docker Registry HTTP API v2 backend로 직접 사용하지 않는다. 대신 프로덕션 배포용 Docker 이미지를 `docker save` 결과물로 내보내고, zstd 압축 archive와 검증 파일을 WORKS Shared Drive에 보관하는 CLI 기반 보조 저장소로 사용한다.
|
||||
WORKS Drive는 Docker Registry HTTP API v2 backend로 직접 사용하지 않는다. 대신 stage/production 공용 Docker 이미지를 `docker save` 결과물로 내보내고, zstd 압축 archive와 검증 파일을 WORKS Shared Drive에 보관하는 CLI 기반 이미지 산출물 저장소로 사용한다.
|
||||
|
||||
이 방식은 다음 상황을 목표로 한다.
|
||||
|
||||
- Harbor 또는 공용 Registry 장애 시 수동 복구용 이미지 보관
|
||||
- 작은 규모의 프로덕션 배포 이미지 이관
|
||||
- 공용 Registry 없이 WORKS Drive 접근 권한만으로 이미지 산출물 보관
|
||||
- 작은 규모의 stage/production 배포 이미지 이관
|
||||
- `docker load` 기반 오프라인 배포
|
||||
|
||||
Harbor는 이 흐름의 1차 이미지 저장소다. Gitea Actions의 publish workflow가 `reg.hmac.kr/baron_sso/<service>:<image_tag>` 형태로 이미지를 push하고, staging/production deploy workflow는 같은 image tag를 Harbor에서 pull한다. WORKS Drive는 같은 이미지를 별도로 보관하는 복구용 archive이며, staging/prod가 평상시에 직접 pull하는 대상이 아니다.
|
||||
Gitea Actions의 shared image publish workflow는 `baron_sso/<service>:<image_tag>` 형태의 로컬 이미지를 빌드한 뒤 WORKS Drive archive로 업로드한다. Harbor registry login/push/pull은 이 publish 흐름의 필수 조건이 아니다. staging/production은 같은 image tag 계약을 공유하며, WORKS Drive archive를 검증한 뒤 `docker load`로 배포 대상 호스트에 적재하는 흐름으로 확장한다.
|
||||
|
||||
## 현재 Gitea Actions 설정 상태
|
||||
|
||||
2026-06-19 기준 repo Actions 설정에서 Harbor 변수/시크릿은 등록되어 있다.
|
||||
2026-06-19 기준 Docker image archive 업로드 단계는 `.gitea/workflows/image_publish.yml`의 `Upload built images to WORKS Drive archive` step에서 실행된다. 이 workflow는 stage/production 공용 산출물을 만들며 `dev` branch의 commit hash 4자리로 immutable tag를 계산한다.
|
||||
|
||||
- `HARBOR_ENDPOINT=https://reg.hmac.kr`
|
||||
- `HARBOR_HOSTNAME=reg.hmac.kr`
|
||||
- `HARBOR_ROBOT_ACCOUNT=robot$namecard_sso`
|
||||
- secret `HARBOR_ROBOT_KEY`
|
||||
업로드를 실행하려면 최소한 다음 값을 등록해야 한다.
|
||||
|
||||
Docker image archive 업로드 단계는 `.gitea/workflows/production_image_publish.yml`의 `Upload pushed images to WORKS Drive archive` step에서 실행된다. 단, 이 step은 다음 조건을 만족할 때만 실행된다.
|
||||
|
||||
```yaml
|
||||
if: ${{ vars.WORKS_DRIVE_DOCKER_IMAGE_ARCHIVE_ENABLED == 'true' }}
|
||||
```
|
||||
|
||||
현재 repo Actions 설정에는 Docker image archive용 WORKS Drive 변수/시크릿이 등록되어 있지 않다. 업로드를 켜려면 최소한 다음 값을 등록해야 한다.
|
||||
|
||||
- variable `WORKS_DRIVE_DOCKER_IMAGE_ARCHIVE_ENABLED=true`
|
||||
- variable `WORKS_SHAREDRIVE_DOCKER_IMAGE_DIR=docker-build-image`
|
||||
- variable `WORKS_DRIVE_SHARED_DRIVE_ID`
|
||||
- 선택 variable `WORKS_DRIVE_PARENT_FILE_ID`
|
||||
- secret `WORKS_DRIVE_OAUTH_CLIENT_ID`
|
||||
- secret `WORKS_DRIVE_OAUTH_CLIENT_SECRET`
|
||||
- secret `WORKS_DRIVE_OAUTH_CLIENT_SERVICE_ACCOUNT`
|
||||
- secret `WORKS_DRIVE_OAUTH_CLIENT_PRIVATE_KEY`
|
||||
- refresh token 방식을 쓸 경우 secret `WORKS_DRIVE_OAUTH_REFRESH_TOKEN`
|
||||
- secret `WORKS_DRIVE_ACCESS_TOKEN`, 또는 variable `WORKS_DRIVE_ACCESS_TOKEN_FILE`, 또는 variable `WORKS_DRIVE_ACCESS_TOKEN_CMD`, 또는 refresh-token 방식의 secret `WORKS_DRIVE_OAUTH_REFRESH_TOKEN`
|
||||
- refresh-token 방식을 쓸 경우 secret `WORKS_DRIVE_OAUTH_CLIENT_ID`, secret `WORKS_DRIVE_OAUTH_CLIENT_SECRET`
|
||||
|
||||
서비스 계정 JWT 방식은 upload script의 fallback으로 남아 있지만 shared image publish workflow의 기본 필수 인증값은 아니다.
|
||||
|
||||
## WORKS Drive 토큰 운영
|
||||
|
||||
WORKS OAuth의 Access Token은 Developer Console 설정에 따라 1시간 또는 24시간 동안 유효하고, Refresh Token은 90일 동안 유효하다. 따라서 Gitea secret에 `WORKS_DRIVE_ACCESS_TOKEN`만 고정해 두는 방식은 publish workflow가 장시간 중단된 뒤 재실행될 때 실패할 수 있다.
|
||||
|
||||
`image_publish.yml`은 업로드 직전에 `Resolve WORKS Drive access token` step을 실행한다.
|
||||
|
||||
- `WORKS_DRIVE_ACCESS_TOKEN`이 있으면 이를 마스킹한 뒤 해당 workflow run 안에서만 사용한다.
|
||||
- `WORKS_DRIVE_ACCESS_TOKEN_FILE` 또는 `WORKS_DRIVE_ACCESS_TOKEN_CMD`가 있으면 그 결과를 같은 방식으로 사용한다.
|
||||
- 위 값이 없고 `WORKS_DRIVE_OAUTH_REFRESH_TOKEN`이 있으면 `grant_type=refresh_token`으로 새 Access Token을 발급하고, 이후 다섯 개 이미지 업로드는 모두 이 Access Token을 공유한다.
|
||||
|
||||
Refresh Token Rotation이 켜져 있으면 WORKS가 refresh 응답에 새 Refresh Token을 포함할 수 있다. workflow는 이 값을 로그에 노출하지 않도록 마스킹하고 `${RUNNER_TEMP}/works-drive-rotated-refresh-token`에 `0600` 권한으로 캡처한다. 다만 Gitea repository secret을 자동 갱신하려면 별도의 secret 쓰기 권한이 있는 Gitea token과 secret update 절차가 필요하므로, 기본 publish workflow는 repository secret을 직접 변경하지 않는다.
|
||||
|
||||
운영 권장값은 다음 중 하나다.
|
||||
|
||||
- Refresh Token Rotation을 끄고 `WORKS_DRIVE_OAUTH_REFRESH_TOKEN`으로 매 run마다 Access Token만 자동 발급한다.
|
||||
- Rotation을 켠 경우 publish run에서 rotated refresh token 경고가 나오면 `WORKS_DRIVE_OAUTH_REFRESH_TOKEN` secret을 수동 갱신한다.
|
||||
- secret 자동 갱신이 필요하면 Gitea secret write 전용 token을 별도 설계로 추가한다.
|
||||
|
||||
## 저장 구조
|
||||
|
||||
@@ -207,13 +212,13 @@ scripts/docker-image/verify_archive.sh \
|
||||
|
||||
## Staging/Production 계약
|
||||
|
||||
Action에서 `dev` 브랜치를 checkout한 뒤 한 번만 이미지를 빌드하고 immutable `image_tag`를 계산한다. staging과 production은 같은 image_tag를 입력받아 같은 registry image를 pull한다.
|
||||
Action에서 `dev` 브랜치를 checkout한 뒤 한 번만 이미지를 빌드하고 immutable `image_tag`를 계산한다. staging과 production은 같은 image_tag를 입력받아 같은 image archive를 사용한다.
|
||||
|
||||
```text
|
||||
dev branch -> publish image tag vX.YYMM.<commit4> -> staging deploy -> production deploy
|
||||
```
|
||||
|
||||
WORKS Drive archive도 Action에서 push된 이미지를 다시 pull한 뒤 `docker save`로 만든다. 따라서 WORKS archive, staging, production은 모두 같은 registry image tag를 기준으로 한다.
|
||||
WORKS Drive archive는 Action에서 로컬로 빌드된 이미지를 `docker save`로 내보내 생성한다. 따라서 WORKS archive, staging, production은 모두 같은 immutable image tag를 기준으로 한다.
|
||||
|
||||
## 제한
|
||||
|
||||
|
||||
Reference in New Issue
Block a user