이전 게시물에서 Vault를 설치하고 사용하는 방법에 다뤘다.
이번에는 Vault를 신규 클러스터에 마이그레이션하는 방법에 대해 설명하고자 한다.
Vault 마이그레이션 왜 하는거야?
Devops팀으로서 일을 하다보면 적어도 1년에 한번씩은 EKS 업그레이드를 한다.
작년에는 In-Place 롤링 업데이트로 진행했으나, In-Place는 단점이 잘못되면 RollBack 할 수 없기에 이번에는 Blue/Green 업데이트 방법으로 진행하려고 한다.
Green Cluster를 만들고, 테스트를 해보면 대부분의 K8s Plugin은 문제가 없으나 Vault는 기존의 Secrets을 그대로 이관해야 문제가 있다.(사실 문제라기 보다는 그대로 설치만 해서는 안되고 후속작업이 필요하다고 보는게 맞을것 같다.)
처음에는 Vault Docs에서 마이그레이션 방법을 찾으려고 했고, Enterprise 버전을 사용하면 마이그레이션 명령어가 존재하는것 같다.
하지만 슬픈건.. 회사에서는 Community 버전을 사용하고 있어서 Vault Docs에 나와있는 마이그레이션 명령어를 사용할 수 없었다.
그래서 Vault에서 참조하고 있는 DynamoDB를 그대로 백업하고/복사하면 Vault를 그대로 이관할 수 있지않을까? 하는 생각을 하게 됬고, 찾아보니 일부 해외 커뮤니티에서 유사한 방법으로 마이그레이션 진행하는 글을 보았다.
Vault 마이그레이션 방법이 뭐야?
Vault는 기본적으로 AWS KMS Key를 이용해서 Secrets 정보를 DynamoDB에 저장하게 된다.
- 그래서 Vault를 복구 할 때도 DynamDB, KMS만 그대로 존재한다면 그대로 helm을 다시 배포하면 복구가 된다.
- 복구를 했을 때는 기존과 똑같이 복구가 된다. Secrets, Token 기타 정보 모두
AWS DDB 백업
Vault를 Helm으로 설치할 때, 아래와 같이 특정 DDB Table을 Vault values로 작성해서 배포한다. 해당 DDB Table을 백업하면 된다.
DDB 백업하는 방법은 매우 간단하다. AWS에서 이미 기능을 제공하고 있기 때문에 버튼 몇번으로 백업을 할 수 있다.
AWS DDB 복구
복구하는 방법 또한 매우매우 쉽다. AWS CLI를 통해서 복구할 수도 있고, Console UI에서 복구할 수도 있다.
AWS CLI
복구하고자 하는 DDB Table과 AWS Backup에서 확인한 백업 DDB ARN으로 변경하고 아래 CLI를 실행하면 된다.
aws dynamodb restore-table-from-backup \
--region ap-northeast-2 \
--target-table-name {{ 새로 생성하는 DDB 이름 }} \
--backup-arn {{ 백업한 DDB의 AWS BACKUP ARN }}
AWS Console
Console에서도 매우 쉽게 복구를 할 수 있다. 버튼만 누르면 된다.
복원 버튼을 누르면 DDB Table 이름만 적으면 되고, KMS/IAM은 그대로 DDB에 종속되어 있는 것을 사용하면 된다.
Vault 재배포
DDB 복구까지 했다면, 이제 복구한 DDB Table ARN을 확인하고 Vault Helm values만 변경해서 배포하면 된다.
아래 DDB table만 변경하면 된다.
- 당연히 Vault가 사용하는 ServiceAccount의 Role에 해당 DDB Table을 describe할 수 있는 권한이 있어야 한다.
Vault까지 재배포하고 나면, 이제 끝이다. 별다른 작업을 안해도 된다.
Vault Init/Operator도 모두 되어 있는 상태이며, 기존의 Secrets도 복구 복구되어 있는 상태이다.
그리고 중요한것은 기존에 사용하던 Vault Token도 그대로 쓸 수 있어서 사용자 입장에서 변경해줘야 하는건 하나도 없다!!
왜 기존의 DDB를 그대로 안써?
실제로 작업해보진 않았으나, 해외 커뮤니티를 보면 서로 다른 Cluster에 배포 되어 있는 Vault에서 같은 DDB를 사용하면 Secrets 정보가 누락된다는 글을 봤다. 그래서 굳이 도전?하지 않았고, 백업/복구하는 전략으로 갔다.
그렇기 때문에 Old Vault / New Vault, 2가지가 생기게 되고 Cluster Blue/Green에서 Green Cluster로 완전히 넘어갈 때까지는 Sync 해주는 것이 필요하다.
Sync하는 방법은 아래와 같이 스트림 정보를 내보내기해서 Sync 하는 Lambda를 만들어도 되고 수동으로 Sync 해도 된다.
- 굳이 Sync 때문에 스트림 만들고/Lambda를 만들고 할 필요가 있을까한다ㅋㅋ
- 등록하는게 많지 않고 Green Cluster로 전환하는 시간이 길지 않다면 수동으로 작업하는것도 방법이다.
결론이 뭐야?
결론은 Vault 마이그레이션 하는 방법이 매우 간단하다는것이다. DDB, KMS만 그대로 유지하면 된다.
그리고 이번에 Vault 마이그레이션하면서 Vault 버전도 최신 버전으로 올렸다. 최신 버전이랑 기존에 사용하던 버전이랑 차이를 보면 기능적으로 큰 차이는 없고, UI가 조금 더 깔끔해졌다? 정도인것 같다.
처음에는 Vault를 어떻게 마이그레이션 해야 할까? 고민이 많았는데 생각보다 너무 간단하다.
Docs에 나와있는 방법은 아니지만, 안정적으로 할 수만 있다면 이것도 하나의 방법이지 않을까한다ㅋㅋ
끝!
'기술 이모저모 > [Ops] Devops' 카테고리의 다른 글
[LGTM] Observability 기술스택 변경 여정 첫번째 (0) | 2024.03.09 |
---|---|
[MSA] MSA 구조란 무엇이고, 왜 다들 열광하는가? (2) | 2024.01.07 |
[AWS][istio] istio profile 지정 & client, control plane 버전 (0) | 2023.11.26 |
[AWS][istio] istio-operator를 통한 istio 배포 (2) | 2023.11.26 |
[AWS][Istio] Istio proxy_config 엔드포인트 Priority 확인 방법 (0) | 2023.11.05 |