배포 후 마이그레이션
배포 후 마이그레이션은 선택적으로 배포 후 실행할 수 있는 일반 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 인스턴스를 다시 시작합니다.
배포 후 마이그레이션을 사용하면 대신 다음 단계를 따를 수 있습니다:
- 배포 후 마이그레이션을 무시하여 GitLab의 새 버전을 배포합니다.
- 환경 변수가 설정되지 않은 상태에서
rake db:migrate를 다시 실행합니다.
여기서는 마이그레이션이 새로운 버전(더 이상 열에 의존하지 않음)이 배포된 후에 이루어지므로 다운타임이 필요하지 않습니다.
이러한 마이그레이션이 유용한 몇 가지 다른 예:
- GitLab의 버그로 인해 생성된 데이터 정리
- 테이블 제거
- 작업을 한 Sidekiq 큐에서 다른 큐로 마이그레이션
도움말