배포 후 마이그레이션
배포 후 마이그레이션은 선택적으로 배포 후에 실행될 수 있는 정기적인 Rails 마이그레이션입니다. 기본적으로 이러한 마이그레이션은 다른 마이그레이션과 함께 실행됩니다. 이러한 마이그레이션을 건너뛰려면 rake db:migrate를 실행할 때 환경 변수 SKIP_POST_DEPLOYMENT_MIGRATIONS을 비어 있지 않은 값으로 설정해야 합니다.
예를 들어, 다음 명령은 포스트 배포 마이그레이션을 포함하여 모든 마이그레이션을 실행할 것입니다.
bundle exec rake db:migrate
그러나 아래 명령은 포스트 배포 마이그레이션을 건너뛸 것입니다.
SKIP_POST_DEPLOYMENT_MIGRATIONS=true bundle exec rake db:migrate
GitLab.com의 경우, 이러한 마이그레이션은 릴리스 관리자의 재량에 따라 매일 실행됩니다. 이는 배포 후 마이그레이션 파이프라인을 통해 이루어집니다.
배포 통합
예를 들어, 새로운 GitLab 버전을 배포한 후 포스트 배포 마이그레이션을 실행하려는 경우 Chef를 사용 중이라면 보통 chef-client 명령을 사용할 것입니다. 이 기능을 사용하려면 다음 명령을 실행해야 합니다.
SKIP_POST_DEPLOYMENT_MIGRATIONS=true sudo chef-client
모든 서버가 업데이트된 후에는 환경 변수 없이 한 대의 서버에서 다시 chef-client를 실행할 수 있습니다.
다른 배포 기술에 대해서도 이러한 과정이 유사합니다. 먼저 환경 변수를 설정하여 배포한 후, 환경 변수를 설정하지 않고 단일 서버를 재배포합니다.
마이그레이션 생성
배포 후 마이그레이션을 생성하려면 다음의 Rails 생성기를 사용할 수 있습니다.
bundle exec rails g post_deployment_migration migration_name_here
이 명령은 마이그레이션 파일을 db/post_migrate에 생성합니다. 이러한 마이그레이션은 일반적인 Rails 마이그레이션과 정확히 같은 방식으로 동작합니다.
사용 사례
배포 후 마이그레이션을 사용하여 기존 GitLab 버전이 의존하는 상태를 변이하는 마이그레이션을 수행할 수 있습니다. 예를 들어, 테이블에서 열을 제거하고 싶다고 가정해보겠습니다. GitLab 인스턴스가 실행 중일 때 이 열이 존재해야 하기 때문에 다운타임이 필요합니다. 이 경우 일반적으로 다음과 같은 단계를 따르게 됩니다.
- GitLab 인스턴스 중지
- 열을 제거하는 마이그레이션 실행
- GitLab 인스턴스 재시작
배포 후 마이그레이션을 사용하면 다음과 같은 단계를 따를 수 있습니다.
- 열리 중인 버전에서 이제 더는 이 열에 의존하지 않는 새 버전을 배포합니다.
- 환경 변수를 설정하지 않은 채로
rake db:migrate를 다시 실행합니다.
이렇게 하면 새 버전(더는 해당 열에 의존하지 않는)이 배포된 후에 마이그레이션이 이루어지기 때문에 다운타임이 필요하지 않습니다.
이러한 마이그레이션을 사용하는 다른 예시:
- GitLab에서 버그로 생성된 데이터 정리
- 테이블 제거
- 작업을 하나의 Sidekiq 대기열에서 다른 대기열로 마이그레이션
도움말