paint-brush
Tập lệnh di chuyển cơ sở dữ liệu đơn giản ở bước CI/CD của bạnby@mindsky
6,573
6,573

Tập lệnh di chuyển cơ sở dữ liệu đơn giản ở bước CI/CD của bạn

Tôi đã thấy rất nhiều tác phẩm xuất sắc, cấp cao trong một số bài gửi tới Cuộc thi viết DevOps. Tuy nhiên, rất ít cá nhân cân nhắc cách giữ cho cơ sở dữ liệu được cập nhật trên các chế độ dự phòng thông thường (dev, stage, prod, v.v.) trong khi làm việc hàng ngày. Bài viết này dành cho các nhà phát triển mới làm quen. Tôi đã lấy Spring làm ví dụ để minh họa một kỹ thuật đơn giản để đưa hệ thống di chuyển cơ sở dữ liệu vào quy trình CI/CD.
featured image - Tập lệnh di chuyển cơ sở dữ liệu đơn giản ở bước CI/CD của bạn
Aleksander Tyryshkin HackerNoon profile picture
0-item
1-item

Tôi đã thấy rất nhiều tác phẩm xuất sắc, cấp cao trong một số bài gửi tới Cuộc thi viết DevOps . Tuy nhiên, rất ít cá nhân cân nhắc cách giữ cho cơ sở dữ liệu được cập nhật trên các chế độ dự phòng thông thường (dev, stage, prod, v.v.) trong khi làm việc hàng ngày. Bài viết này dành cho các nhà phát triển mới làm quen. Tôi đã sử dụng Spring làm ví dụ để minh họa một kỹ thuật đơn giản nhằm đưa hệ thống di chuyển cơ sở dữ liệu vào quy trình CI/CD.

Chúng tôi sẽ yêu cầu các công cụ Liquibase và GitLab CI/CD cho việc triển khai này. Giả sử hiện tại một cơ sở dữ liệu đang hoạt động. Tôi sẽ sử dụng PostgreSQL.

GitLab CI/CD

Nếu bạn đã triển khai GitLab, bạn có thể bỏ qua hoàn toàn bước này.


Để triển khai Gitlab, chúng tôi sẽ sử dụng phương thức Docker. Điều quan trọng cần lưu ý là chúng ta cần tạo biến $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


Bước tiếp theo là cài đặt và cấu hình các Á hậu.


Nếu bạn đã có một dự án dài hạn và mọi thứ đã được thiết lập từ lâu, bạn có thể bỏ qua việc tạo một Á hậu mới.


CI GitLab


Tôi sẽ trình bày việc tạo một trình chạy bằng phiên bản 16.4.1 làm ví dụ. Mọi thứ sau ngày 17.0 sẽ được chuyển sang đăng ký bằng cách sử dụng RUNNER_AUTHENTICATION_TOKEN , nhưng cách tiếp cận gần với cách tiếp cận hiện tại.


Luồng trước GitLab 17.0


Dòng chảy sau GitLab 17.0


Đầu tiên bạn cần cài đặt nguồn Á hậu. Để cài đặt nó thông qua bash trên GitLab đã triển khai của bạn, ví dụ này giúp bạn có thể cài đặt trình chạy cho các hệ thống dựa trên Apple Silicon (hệ điều hành khác bạn có thể tìm thấy ở đây):


 # 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


Bây giờ chúng ta có thể tự tạo trình chạy thông qua giao diện người dùng bằng cách nhấp vào nút New project runner .


Tạo người chạy mới


Mỗi người chạy có thể có một nền tảng, các thẻ xuất hiện màu xanh lam và các cấu hình thời gian chạy khác. Khi chúng ta cần thiết lập khả năng chạy các lệnh từ chương trình, các thẻ sẽ rất hữu ích. Hiện tại, chúng tôi không quan tâm đến mọi thứ khác.


Sau khi tạo Á hậu


Sau khi nhấp vào Create runner , việc duy nhất còn lại cần làm là đăng ký Á hậu của bạn.


 # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU


chất lỏng

Liquibase là một nền tảng mã nguồn mở và miễn phí để quản lý việc di chuyển cơ sở dữ liệu. Tóm lại, Liquibase cho phép bạn mô tả các thủ tục cuộn lên và quay lui bằng cách sử dụng các tệp changset. Bản thân các tập lệnh có thể là các lệnh SQL thông thường cũng như các mô tả sửa đổi độc lập với cơ sở dữ liệu sẽ được chuyển thành tập lệnh phù hợp với cơ sở dữ liệu của bạn. Danh sách các cơ sở dữ liệu được hỗ trợ có sẵn ở đây .


Tôi sẽ chỉ cho bạn cách thực hiện di chuyển trong ứng dụng Spring. Điều này là cần thiết để bạn có thể kiểm soát việc thực hiện tất cả các bộ thay đổi dưới dạng một bước riêng biệt.

Dự án

Để phát triển nhanh ứng dụng Spring, hãy vào đây .


Khởi tạo mùa xuân


Bây giờ chúng ta hãy tạo nhanh application.yml. Cần đặc biệt chú ý đến các tùy chọn đã bật và nhật ký thay đổi. Tùy chọn đầu tiên bật và tắt Liquibase ở cấp ứng dụng, trong khi tùy chọn thứ hai đặt đường dẫn đến nhật ký thay đổi.


 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


Phải làm gì với các biến?

Cách tốt nhất là đưa chúng vào GitLab, điều này sẽ giúp tùy chỉnh ứng dụng một cách linh hoạt giữa các vị trí dev/prod.


Các biến trong GitLab


Chúng tôi sử dụng Kubernetes trong dự án của mình và các tham số này phải do chính các nhóm đặt ra khi xây dựng ứng dụng bằng các tệp giá trị được định cấu hình sẵn cho các lược đồ khác nhau



 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"



Hãy quay lại việc tùy chỉnh. Theo tôi, việc tạo ra các ứng dụng hoàn toàn tự cung cấp và sẵn sàng triển khai ngay lập tức là một cách làm thông minh. Để xây dựng thêm một giai đoạn riêng biệt trong CI/CD, hãy tạo một tệp di chuyển. Chúng tôi có thể sử dụng các công cụ khác nhau cho các nhóm khác nhau và chúng tôi không bị hạn chế đối với hệ thống di chuyển với tệp này.


 #!/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



Tất cả các lệnh có thể có có thể được tìm thấy trong tài liệu Liquibase . Bây giờ chúng tôi chỉ cần update , cho phép chúng tôi cập nhật lên phiên bản hiện tại từ tệp Changelog-master.xml.

Bước tiếp theo là tạo tệp a.gitlab-ci.yml ở thư mục gốc của dự án có chứa hướng dẫn về cách tiến hành quy trình CI/CD.


Đầu tiên, tôi muốn thu hút sự chú ý đến trình liên kết tích hợp cho tệp gitlab-ci.yml , có thể tìm thấy trong dự án tại đường dẫn tương đối ci/lint . Trước khi thay đổi cấu hình, tôi khuyên bạn nên sử dụng nó. Cũng giả định rằng bạn biết cách làm việc với các tệp YAML.

Các giai đoạn và công việc

 stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev

Thẻ migration hướng dẫn trình chạy được tạo trước đó của chúng tôi phản ứng với tác vụ này và chạy các tập lệnh trong phần script . Chuỗi stage xác định giai đoạn mà công việc này thuộc về. Nếu cần thiết, cùng một người chạy có thể làm việc trên nhiều dự án cùng một lúc. Khối môi trường đề cập đến môi trường . Đây là một loại bảng thông tin nơi bạn có thể xem trạng thái các gian hàng của mình (nhà phát triển, tiền sản xuất, sản xuất, v.v.) và thực hiện các hành động như triển khai thủ công. Ngoài ra, các biến giới hạn môi trường có thể được cấu hình; tuy nhiên, tôi chưa có cơ hội thử nghiệm tính năng cao cấp này.


Từ chối các biện pháp có sai sót

Yêu cầu hợp nhất cài đặt


Bạn có thể dừng việc hợp nhất tương ứng trong trường hợp có sự cố xảy ra với quy trình triển khai. Đặc biệt, điều này rất hữu ích nếu các xét nghiệm được tích hợp vào CI/CD như một giai đoạn độc lập. Mặc dù Liquibase không có các thử nghiệm trong ví dụ của chúng tôi, nhưng nó có thể gặp trục trặc nếu nhập đường dẫn tệp không chính xác.


Tất cả các hoạt động hợp nhất sẽ không được phép nếu hộp kiểm không được đánh dấu sau khi định cấu hình CI/CD.


Lần chỉnh sửa cuối cùng

Dự án


Hãy tạo một tệp di chuyển và kích hoạt nó. Để làm điều này, chúng ta cần tạo tệp changelog-master.xml làm điểm đầu vào.


Đó là một cách tốt để có nhiều Changelog.xml để quản lý linh hoạt hơn. Bạn có thể xây dựng hệ thống phân cấp nhật ký thay đổi từ chúng. Tuy nhiên, trong ví dụ của chúng tôi, chúng tôi sẽ sử dụng một cách đơn giản hơn.


 <?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>


Cách tốt nhất là đặt tên di chuyển theo ngày và giờ. Điều này sẽ tránh phá vỡ việc sắp xếp di chuyển khi một nhóm phát triển lớn đang làm việc cùng lúc.


 --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;


Bạn có thể sử dụng các định dạng XML, YAML hoặc JSON khác nhau để mô tả quá trình di chuyển, nhưng theo tôi, SQL là cách dễ đọc nhất.


Đường ống


Chúng tôi cố gắng thực hiện và mọi thứ đều thành công. Kiểm tra cơ sở dữ liệu của chúng tôi và xem mục trong cơ sở dữ liệuchangelog.



Hàng trong cơ sở dữ liệu


Phần kết luận

Trong bài viết này, chúng tôi đã thảo luận cách tự triển khai GitLab, tải xuống và định cấu hình các trình chạy, đồng thời quan trọng nhất là tích hợp hệ thống di chuyển cơ sở dữ liệu vào quy trình CI/CD của bạn. Tôi hy vọng hướng dẫn này sẽ hỗ trợ bạn thực hiện hướng dẫn này.