저는 에 제출된 여러 작품에서 뛰어난 수준의 작품을 많이 보았습니다. 그러나 매일 작업하는 동안 공통 대기(개발, 스테이지, 프로덕션 등)에서 데이터베이스를 최신 상태로 유지하는 방법을 고려하는 사람은 거의 없습니다. 이 문서는 초보 개발자를 대상으로 작성되었습니다. CI/CD 프로세스에 데이터베이스 마이그레이션 시스템을 도입하는 간단한 기술을 보여주기 위해 Spring을 예로 사용했습니다. DevOps Writing Contest 이 배포에는 Liquibase 및 GitLab CI/CD 도구가 필요합니다. 데이터베이스가 실행 중이라고 가정해 보겠습니다. 저는 PostgreSQL을 사용할 예정입니다. GitLab CI/CD 이미 GitLab을 배포한 경우 이 단계를 완전히 건너뛸 수 있습니다. Gitlab을 배포하기 위해 Docker 방법을 사용하겠습니다. 변수를 생성해야 한다는 점에 유의하는 것이 중요합니다. $GITLAB_HOME sudo docker run --detach \ --hostname gitlab.devopscontest.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ee:16.4.1-ee.0 다음 단계는 실행기를 설치하고 구성하는 것입니다. 이미 장기 실행 프로젝트가 있고 모든 것이 오랫동안 설정되어 있는 경우 새 실행기 생성을 건너뛸 수 있습니다. 버전 16.4.1을 예로 들어 러너 생성을 보여드리겠습니다. 사용하여 등록되지만 접근 방식은 현재 접근 방식에 가깝습니다. 17.0 이후의 모든 항목은 RUNNER_AUTHENTICATION_TOKEN 먼저 실행기 소스를 설치해야 합니다. 배포된 GitLab에 bash를 통해 설치하기 위해 이 예제는 Apple Silicon 기반 시스템(여기에서 찾을 수 있는 다른 OS)용 러너를 설치하는 방법을 돕습니다. https://docs.gitlab.com/runner/install/?embedable=true # Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 # Give it permission to execute sudo chmod +x /usr/local/bin/gitlab-runner # Create a GitLab Runner user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash # Install and run as a service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start 이제 버튼을 클릭하여 UI를 통해 실행기 자체를 생성할 수 있습니다. New project runner 각 실행기에는 플랫폼, 파란색으로 표시되는 태그 및 기타 런타임 구성이 있을 수 있습니다. 프로그램에서 명령을 실행할 가능성을 설정해야 할 때 태그가 유용합니다. 당분간 우리는 다른 모든 것에 관심이 없습니다. 클릭한 후 남은 작업은 러너를 등록하는 것뿐입니다. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU 리퀴베이스 는 데이터베이스 마이그레이션 관리를 위한 무료 오픈 소스 플랫폼입니다. 요약하자면 Liquibase를 사용하면 changset 파일을 사용하여 롤업 및 롤백 절차를 설명할 수 있습니다. 스크립트 자체는 기존 SQL 명령일 수도 있고, 데이터베이스에 맞게 조정된 스크립트로 변환될 데이터베이스 독립적인 수정 설명일 수도 있습니다. . Liquibase 지원되는 데이터베이스 목록은 여기에서 확인할 수 있습니다 Spring 애플리케이션에서 마이그레이션을 수행하는 방법을 보여드리겠습니다. 이는 모든 변경 세트의 실행을 별도의 단계로 제어할 수 있도록 하기 위해 필요합니다. 프로젝트 Spring 애플리케이션을 빠르게 개발하려면 . 여기로 이동하세요 이제 활성화된 옵션과 변경 로그 옵션에 특별한 주의를 기울여야 합니다. 첫 번째 옵션은 애플리케이션 수준에서 Liquibase를 활성화 및 비활성화하고, 두 번째 옵션은 변경 로그에 대한 경로를 설정합니다. application.yml. server: port: 80 spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} url: ${DB_HOST} liquibase: enabled: true change-log: classpath:db/changelog/db.changelog-master.xml 변수는 어떻게 해야 할까요? 개발/프로덕션 스탠드 사이에서 애플리케이션을 유연하게 사용자 정의하는 데 도움이 되는 GitLab에 배치하는 것이 좋습니다. 우리는 프로젝트에서 Kubernetes를 사용하며 이러한 매개변수는 다양한 체계에 대해 사전 구성된 값 파일을 사용하여 애플리케이션을 구성할 때 팀에서 직접 설정해야 합니다. env: - name: SPRING_PROFILES_ACTIVE value: "dev" - name: DB_HOST value: "jdbc:postgresql://127.0.0.1:5436/your_db" - name: DB_USERNAME value: "user" - name: DB_PASSWORD value: "pass" 다시 맞춤설정으로 돌아가겠습니다. 내 생각에는 즉시 배포할 준비가 되어 있는 완전히 자급자족하는 앱을 만드는 것이 현명한 방법이라고 생각합니다. CI/CD에서 별도의 단계를 추가로 구축하기 위해 마이그레이션 파일을 구성해 보겠습니다. 팀마다 다른 도구를 사용할 수 있으며 이 파일을 사용하는 마이그레이션 시스템에만 국한되지 않습니다. #!/bin/sh cd /opt/app /opt/app/liquibase \ --changeLogFile=./db/changelog/changelog-master.xml \ --url="$DB_HOST" \ --username="$DB_USERNAME" \ --password="$DB_PASSWORD" \ --logLevel=info \ --headless=true \ update 가능한 모든 명령은 에서 찾을 수 있습니다. 이제 만 필요합니다. 이를 통해 Changelog-master.xml 파일에서 현재 버전으로 업데이트할 수 있습니다. Liquibase 문서 update 다음 단계는 CI/CD 프로세스를 진행하는 방법에 대한 지침이 포함된 프로젝트 루트에 .gitlab-ci.yml 파일을 만드는 것입니다. 먼저 프로젝트의 상대 경로 에서 찾을 수 있는 파일에 대한 하고 싶습니다. 구성을 부풀리기 전에 사용하는 것이 좋습니다. 또한 YAML 파일 작업 방법을 알고 있다고 가정합니다. ci/lint gitlab-ci.yml 내장 링커에 주목 단계와 직업 stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev 태그는 이전에 생성된 실행기에 이 작업에 반응하고 섹션에서 스크립트를 실행하도록 지시합니다. 문자열은 이 작업이 속한 단계를 식별합니다. 필요한 경우 동일한 실행자가 동시에 여러 프로젝트를 수행할 수 있습니다. 환경 블록은 참조합니다. 이는 스탠드 상태(개발, 사전 프로덕션, 프로덕션 등)를 보고 수동 배포와 같은 조치를 취할 수 있는 일종의 대시보드입니다. 또한 환경 바인딩 변수를 구성할 수 있습니다. 그러나 나는 이 프리미엄 기능을 테스트해 볼 기회가 없었습니다. migration script stage 환경을 오류가 있는 조치 거부 배포 절차에 문제가 있는 경우 해당 병합을 중지할 수 있습니다. 특히 테스트가 CI/CD에 독립적인 단계로 통합된 경우에 유용합니다. 이 예에서는 Liquibase에 테스트가 없지만 예를 들어 잘못된 파일 경로를 입력하면 제대로 작동하지 않을 수 있습니다. CI/CD를 구성한 후 확인란을 선택하지 않으면 모든 병합이 허용되지 않습니다. 최종 손질 마이그레이션 파일을 생성하고 활성화해 보겠습니다. 이를 수행하려면 입력 지점으로 파일을 생성해야 합니다. changelog-master.xml 보다 유연한 관리를 위해 여러 개의changelog.xml을 갖는 것이 좋습니다. 이를 통해 변경 로그 계층 구조를 구축할 수 있습니다. 그러나 이 예에서는 더 간단한 방법을 사용하겠습니다. <?xml version="1.1" encoding="UTF-8" standalone="no"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:pro="http://www.liquibase.org/xml/ns/pro" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd"> <include file="db/changelog/changeset-202310151300-create-table.sql"/> </databaseChangeLog> 날짜와 시간을 사용하여 마이그레이션 이름을 지정하는 것이 좋습니다. 이렇게 하면 대규모 개발 팀이 동시에 작업할 때 마이그레이션 정렬이 중단되는 것을 방지할 수 있습니다. --liquibase formatted sql --changeset a.tyryshkin:create-table create table if not exists table ( id bigserial primary key, name varchar(255) ); create sequence if not exists table_id_seq; 다양한 XML, YAML 또는 JSON 형식을 사용하여 마이그레이션을 설명할 수 있지만 내 취향으로는 SQL이 가장 읽기 쉽습니다. 우리는 실행하려고 노력하고 있으며 모든 것이 성공적입니다. 데이터베이스를 확인하고 데이터베이스변경 로그의 항목을 확인하세요. 결론 이 기사에서는 GitLab을 직접 배포하는 방법, 실행기를 다운로드 및 구성하는 방법, 가장 중요하게는 데이터베이스 마이그레이션 시스템을 CI/CD 프로세스에 통합하는 방법에 대해 논의했습니다. 이 가이드가 귀하가 이 가이드를 실행에 옮기는 데 도움이 되기를 바랍니다.
