opencsp 서비스 다운타임 없이(?) 도메인 변경하기

OpenCSP/운영 관련

opencsp 서비스 다운타임 없이(?) 도메인 변경하기

miiml 2026. 5. 27. 12:46

기존 사용하던 도메인이 곧 만료될 예정이라 새로 구매했다.

Cloudflare Domains로 등록했는데 기존에 사용하던 것보다 저렴하고, whois 프라이버시도 더 잘 챙겨준다.

구매후엔 기존에 로컬에서 관리하던 cloudflare tunnel의 config.yml를 대시보드로 마이그레이션 했고(cloudflare 기능)

여기에 새로운 도메인의 ingress를 하나씩 다 추가해주면 사용하던 터널 그대로 라우팅만 추가된다.

문제는 Core로 가는 트래픽은 내부에서 k8s ingress 설정과 환경변수, Secret 등도 같이 수정해줘야 하는데 그냥 수정하면 기존에 연결된 세션들과 데이터들이 손상될 수 있을 거 같다.

상용 서비스는 아니니까 그냥 바로 바꿔도 상관없긴하지만, 생각해보니까 마이그레이션 연습해볼 좋은 기회인거 같다.

변경 계획

그래서 제약 조건을 셀프로 만들어봄

마이그레이션 중 기존 서비스의 접근 경로와 모든 기능은 동작해야 한다.
새로운 도메인으로 접근 시 기존 기능 동작과 데이터가 동일해야한다.

2가지 조건을 만족하려면 블루그린이 확실하지만 도메인 교체를 위해 모든 인프라와 서비스를 1개씩 더 띄우는 건 너무 과한거 같다.

여러 부분을 나눠서 변경 계획을 세워야 하는데

큰 scope 에선 하위 서비스들의 마이그레이션 -> 메인 서비스의 마이그레이션 순서로 가야하고,

하위 서비스들도 데이터의 의존성에 따라 순서를 정해줘야 할 듯 하다.

대충 생각해보면 Zitadel이 모든 사용자/테넌트 정보를 들고 있으니까 제일 중요할 것 같지만 (실제로는 맞지만)

OpenCSP에선 모든 Integrations를 BE가 담당하고 있다. (텔레포트 등의 OSS가 커뮤니티 버전에선 OIDC 연동, 마이그레이션 등을 지원하지 않기 때문에 이렇게 설계)

그래서 순서 정리하면

Teleport : 새로운 서비스 띄우고 인테그레이션을 변경해서 기능 테스트
Semaphore, Cilium(hubble) : dual ingress로 띄워서 integration 테스트 할 수 있음
Zitadel, OpenCSP : 동일 네임스페이스 내부 리소스 단위 블루그린으로 테스트
Lago : ingress는 여러개 할 수 있지만 helm chart values에 apiUrl 같은 옵션들 때문에 의미 없어서 그냥 in-place로 업데이트 해주려고 함
마이그레이션 완료 후 기존 리소스 정리

이런식으로 하면 될거 같다.

hubble (https://github.com/h001-lab/OpenCSP-core/commit/7c06b5c29d56db47c0621658ad2dba0f5ecb4f05)

근데 일단 작업 전에 만만한(?) hubble 먼저 수정해봤다.

tls, rules(secret(인증서 SAN)이랑 ingress)에 하나씩 추가해줬고, 2개 도메인 다 접근 되는걸 확인함

잘되는거 확인했으니까 나머지 하나씩 진행해보겠음.

Teleport, Semaphore (https://github.com/h001-lab/OpenCSP-core/commit/31952fab6446be21d3eb0884ef69ab9d4507780a)

Teleport는 오랜만에 접속해봤더니 security patch가 있어서 업그레이드가 필요한 상황이었는데,

어차피 얘는 도메인 교체하려면 서비스 하나 새로 띄우는게 편해서 버전 업그레이드도 같이할 겸 블루그린으로 해보면 좋을 거 같다.

Teleport 같은 경우는 처음 구성 시 사용한 clusterName 자체가 Identity 라서 모든 하위 리소스가 기존 도메인(clusterName)에 종속된다. (도메인 변경 시 새로운 클러스터 구성 필요)

그래서 core에 teleport-miiml이라는 네임스페이스를 하나 더 만들어주고 클러스터를 하나 더 띄워줬다.

이제 계정이나 수동으로 생성한 역할, audit 같은 데이터들을 옮겨야하는데

사용자 계정들은 tbot과 opencsp가 연동되면 알아서 관리해줄거고, UI 관리를 위해 수동 생성한 admin 계정 1개만 만들어주면된다.

근데 이것도 사용자 계정 관리를 위해 teleport operator 를 활성화 시켜뒀기 때문에 동일하게 CR로 관리해주면 될 거 같다.

-> https://github.com/h001-lab/OpenCSP-core/commit/549b1eb7944071bbc3b34e4db1abc7fb2d8aafbc

core에 TeleportUser 타입으로 파일 만들어주면 된다. (근데 이렇게 하면 초기에 비밀번호는 어쩔 수 없이 수동으로 설정해주긴 해야됨)

Audits, Session recordings 같은 건 지금은 로컬 볼륨이지만 나중에 외부 오브젝트 스토리지 만들고 values에서 연결해주면 될 거 같다.

Semaphore는 그냥 ingress 하나 추가로 바로 됨.

Zitadel, OpenCSP (https://github.com/h001-lab/OpenCSP-core/commit/8213f7cc829b49e52f217a9dd59050cbe4c2e69f)

얘네 둘은 postgresql에 있는 기존 데이터는 공유하도록 같은 네임스페이스에 Release 관련 리소스만 하나씩 더 만들어줬다.

작업 중에 teleport-bot CR을 만들어주는 과정에서 teleport-operator가 2개라 충돌나는 부분이 있었다.

그래서 먼저 기존 teleport chart에서 operator.installCRDs: never로 변경해 CRD 설치하지 않게 수정해줬고 (근데 이건 영향이 없었던듯? )

https://github.com/h001-lab/OpenCSP-core/commit/a506143d6df43e9785582accdd532151955dc466

이후에도 계속 cluster-apps 진행 과정에서 리소스 중복 에러가 나서 그냥 기존 teleport-bot을 제거해줬더니 잘 진행됐다.

https://github.com/h001-lab/OpenCSP-core/commit/80155495d7c28b0d47265481b96f1f7a3591713e

그리고 마지막으로 리소스들 이름만 맞춰줬음

opencsp, zitadel 두 서비스 다 서로 다른 파드인데 의도한대로 데이터가 잘 공유된다.

기존 서비스들도 잘 살아있는 상태인데, 위에 teleport tbot 관련 CR 문제로 아마 기존 서비스에선 PAM 기능이 동작하지 않을 것 같다. (그래서 완전한 blue green은 아닌 듯 하고 기존 서비스에 실제 사용자 세션이 남아있었다면 인증서 만료되면서 연결이 끊기거나, 바로 세션이 끊겼을 거 같은 기분)