GALAXY TECH
Chuyên gia Công nghệ
Thứ hai, 26/10/2020 | 00:00 GMT+7

Cách thiết lập một đường ống triển khai liên tục với GitLab CI / CD trên Ubuntu 18.04

GitLab là một nền tảng cộng tác open-souce cung cấp các tính năng mạnh mẽ ngoài việc lưu trữ một kho mã. Bạn có thể theo dõi các vấn đề, gói server lưu trữ và đăng ký, duy trì Wiki, cài đặt đường ống tích hợp liên tục (CI) và triển khai liên tục (CD), v.v.

Trong hướng dẫn này, bạn sẽ xây dựng một đường dẫn triển khai liên tục với GitLab. Bạn sẽ cấu hình đường ống để xây dựng Docker image , đẩy nó vào register containers GitLab và triển khai nó tới server của bạn bằng SSH. Đường ống sẽ chạy cho mỗi commit được đẩy đến repository .

Bạn sẽ triển khai một trang web tĩnh, nhỏ, nhưng trọng tâm của hướng dẫn này là cấu hình đường ống CD. Trang web tĩnh chỉ dành cho mục đích demo ; bạn cũng có thể áp dụng cấu hình đường ống tương tự bằng cách sử dụng các Docker image khác để triển khai.

Khi bạn hoàn thành hướng dẫn này, bạn có thể truy cập http:// your_server_IP trong trình duyệt để biết kết quả của việc triển khai tự động.

Yêu cầu

Để hoàn thành hướng dẫn này, bạn cần :

Bước 1 - Tạo Kho lưu trữ GitLab

Hãy bắt đầu bằng cách tạo một dự án GitLab và thêm một file HTML vào đó. Sau đó, bạn sẽ sao chép file HTML vào một hình ảnh Nginx Docker, sau đó bạn sẽ triển khai đến server .

Đăng nhập vào version GitLab của bạn và nhấp vào Dự án mới .

Nút dự án mới trong GitLab

  1. Đặt cho nó một tên Dự án thích hợp.
  2. Tùy chọn thêm mô tả Dự án .
  3. Đảm bảo đặt Mức hiển thị thành Riêng tư hoặc Công khai tùy thuộc vào yêu cầu của bạn.
  4. Cuối cùng bấm Tạo dự án

Biểu mẫu dự án mới trong GitLab

Bạn sẽ được chuyển đến trang tổng quan của Dự án.

Hãy tạo file HTML. Trên trang tổng quan về Dự án của bạn, nhấp vào Tệp mới .

Nút file mới trên trang tổng quan dự án

Đặt tên file thành index.html và thêm HTML sau vào nội dung file :

index.html
<html> <body> <h1>My Personal Website</h1> </body> </html>

Nhấp vào Commit thay đổi ở cuối trang để tạo file .

HTML này sẽ tạo ra một trang trống với một dòng tiêu đề hiển thị Trang web Cá nhân của Tôi khi được mở trong trình duyệt.

Dockerfiles là công thức được Docker sử dụng để xây dựng Docker image . Hãy tạo một Dockerfile để sao chép file HTML vào một hình ảnh Nginx.

Quay lại trang tổng quan của Dự án, nhấp vào nút + và chọn tùy chọn Tệp mới .

Tùy chọn file mới trong trang tổng quan của dự án được liệt kê trong nút dấu cộng

Đặt tên file thành Dockerfile và thêm các hướng dẫn sau vào nội dung file :

Dockerfile
FROM nginx:1.18 COPY index.html /usr/share/nginx/html

Lệnh FROM chỉ định hình ảnh sẽ kế thừa từ đó — trong trường hợp này là hình ảnh nginx:1.18 . 1.18 là thẻ hình ảnh đại diện cho version Nginx. Thẻ nginx:latest tham chiếu đến bản phát hành Nginx mới nhất, nhưng điều đó có thể phá vỡ ứng dụng của bạn trong tương lai, đó là lý do tại sao các version cố định được khuyến khích .

Hướng dẫn COPY sao chép index.html sang /usr/share/nginx/html trong Docker image . Đây là folder mà Nginx lưu trữ nội dung HTML tĩnh.

Nhấp vào Commit thay đổi ở cuối trang để tạo file .

Trong bước tiếp theo, bạn sẽ cấu hình một trình chạy GitLab để giữ quyền kiểm soát ai sẽ thực hiện công việc triển khai.

Bước 2 - Đăng ký GitLab Runner

Để theo dõi các môi trường sẽ liên hệ với private key SSH, bạn sẽ đăng ký server của bạn làm trình chạy GitLab.

Trong đường dẫn triển khai, bạn muốn đăng nhập vào server của bạn bằng SSH. Để làm điều này, bạn sẽ lưu trữ private key SSH trong biến GitLab CI / CD (Bước 5). Khóa cá nhân SSH là một phần dữ liệu rất nhạy cảm, vì nó là vé vào server của bạn. Thông thường, private key không bao giờ rời khỏi hệ thống mà nó được tạo. Trong trường hợp thông thường, bạn sẽ tạo SSH key trên server của bạn , sau đó ủy quyền nó trên server (nghĩa là sao chép public key vào server ) để đăng nhập thủ công và thực hiện quy trình triển khai.

Ở đây tình hình thay đổi một chút: Bạn muốn cấp quyền truy cập tự trị (GitLab CI / CD) vào server của bạn để tự động hóa quy trình triển khai. Do đó, private key cần phải rời khỏi hệ thống mà nó được tạo và được GitLab và các bên liên quan khác tin tưởng. Bạn không bao giờ muốn private key của bạn vào một môi trường không do bạn kiểm soát hoặc tin cậy.

Bên cạnh GitLab, trình chạy GitLab là một hệ thống khác mà private key của bạn sẽ nhập. Đối với mỗi đường ống, GitLab sử dụng các trình chạy để thực hiện công việc nặng nhọc, nghĩa là thực thi các công việc bạn đã chỉ định trong cấu hình CI / CD. Điều đó nghĩa là công việc triển khai cuối cùng sẽ được thực thi trên một trình chạy GitLab, do đó private key sẽ được sao chép vào trình chạy để nó có thể đăng nhập vào server bằng SSH.

Nếu bạn sử dụng GitLab Runners không xác định (ví dụ: chạy chung ) để thực hiện công việc triển khai, thì bạn sẽ không biết về việc hệ thống đang tiếp xúc với private key . Mặc dù người chạy GitLab dọn dẹp tất cả dữ liệu sau khi thực hiện công việc, bạn có thể tránh gửi private key đến các hệ thống không xác định bằng cách đăng ký server của bạn làm người chạy GitLab. Sau đó, private key sẽ được sao chép vào server do bạn kiểm soát.

Bắt đầu bằng cách đăng nhập vào server của bạn:

  • ssh sammy@your_server_IP

Để cài đặt dịch vụ gitlab-runner , bạn sẽ thêm repository GitLab chính thức. Download và kiểm tra lệnh cài đặt :

  • curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh > script.deb.sh 
  • less script.deb.sh

Khi thấy ổn với sự an toàn của tập lệnh, hãy chạy trình cài đặt:

  • sudo bash script.deb.sh

Nó có thể không rõ ràng, nhưng bạn phải nhập password của user không phải root để tiếp tục. Khi bạn thực hiện lệnh trước đó, kết quả kết quả sẽ như sau:

Output
[sudo] password for sammy:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100  5945  100  5945    0     0   8742      0 --:--:-- --:--:-- --:--:--  8729

Khi lệnh curl kết thúc, bạn sẽ nhận được thông báo sau:

Output
The repository is setup! You can now install packages.

Tiếp theo cài đặt dịch vụ gitlab-runner :

  • sudo apt install gitlab-runner

Xác minh cài đặt bằng cách kiểm tra trạng thái dịch vụ:

  • systemctl status gitlab-runner

Bạn sẽ có active (running) trong kết quả :

Output
● gitlab-runner.service - GitLab Runner    Loaded: loaded (/etc/systemd/system/gitlab-runner.service; enabled; vendor preset: enabled)    Active: active (running) since Mon 2020-06-01 09:01:49 UTC; 4s ago  Main PID: 16653 (gitlab-runner)     Tasks: 6 (limit: 1152)    CGroup: /system.slice/gitlab-runner.service            └─16653 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitla

Để đăng ký người chạy, bạn cần lấy mã thông báo dự án và URL GitLab:

  1. Trong dự án GitLab của bạn, chuyển đến Cài đặt > CI / CD > Người chạy .
  2. Trong phần Cài đặt một Runner cụ thể theo cách thủ công , bạn sẽ tìm thấy mã thông báo đăng ký và URL GitLab. Sao chép cả hai vào một editor ; bạn cần chúng cho lệnh tiếp theo. Chúng sẽ được gọi là https:// your_gitlab.com và project_token .

Phần người chạy trong cài đặt ci / cd với nút mã thông báo sao chép

Quay lại terminal của bạn, đăng ký người chạy cho dự án của bạn:

  • sudo gitlab-runner register -n --url https://your_gitlab.com --registration-token project_token --executor docker --description "Deployment Runner" --docker-image "docker:stable" --tag-list deployment --docker-privileged

Các tùy chọn lệnh có thể được hiểu như sau:

  • -n thực hiện lệnh register không tương tác ( ta chỉ định tất cả các tham số làm tùy chọn lệnh).
  • --url là GitLab URL mà bạn đã sao chép từ trang nhì trong GitLab.
  • --registration-token là mã thông báo bạn đã sao chép từ trang người chạy trong GitLab.
  • --executor là kiểu người thi hành. docker thực thi từng công việc CI / CD trong containers Docker (xem tài liệu của GitLab về trình thực thi ).
  • --description là mô tả của người chạy, sẽ hiển thị trong GitLab.
  • --docker-image là --docker-image Docker mặc định để sử dụng trong các công việc CI / CD, nếu không được chỉ định rõ ràng.
  • --tag-list là danh sách các thẻ được gán cho người chạy. Thẻ được dùng trong cấu hình đường ống để chọn các trình chạy cụ thể cho công việc CI / CD. Thẻ deployment sẽ cho phép bạn tham chiếu đến trình chạy cụ thể này để thực hiện công việc triển khai.
  • --docker-privileged thực thi containers Docker được tạo cho mỗi công việc CI / CD ở chế độ quyền . Vùng chứa quyền có quyền truy cập vào tất cả các thiết bị trên server và có quyền truy cập gần như vào server lưu trữ như các quy trình chạy bên ngoài containers (xem tài liệu của Docker về quyền thời gian chạy và các khả năng của Linux ). Lý do chạy ở chế độ quyền là vì vậy bạn có thể sử dụng Docker-in-Docker ( dind ) để xây dựng Docker image trong đường dẫn CI / CD của bạn . Thực tiễn tốt là cung cấp cho một container các yêu cầu tối thiểu mà nó cần. Đối với bạn, yêu cầu phải chạy ở chế độ quyền để sử dụng Docker-in-Docker. Hãy lưu ý, bạn chỉ đăng ký trình chạy cho dự án cụ thể này, nơi bạn có quyền kiểm soát các lệnh đang được thực thi trong containers quyền .

Sau khi thực hiện lệnh gitlab-runner register , bạn sẽ nhận được kết quả sau:

Output
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Xác minh quá trình đăng ký bằng cách đi tới Cài đặt > CI / CD > Người chạy trong GitLab, nơi người chạy đã đăng ký sẽ hiển thị.

Người chạy đã đăng ký trong phần người chạy của cài đặt ci / cd

Trong bước tiếp theo, bạn sẽ tạo một user triển khai.

Bước 3 - Tạo user triển khai

Bạn sẽ tạo một user không phải sudo dành riêng cho nhiệm vụ triển khai, để sức mạnh của nó bị hạn chế và việc triển khai diễn ra trong một không gian user bị cô lập. Sau đó, bạn sẽ cấu hình đường ống CI / CD để đăng nhập vào server với user đó.

Trên server của bạn, hãy tạo một user mới:

  • sudo adduser deployer

Bạn sẽ được hướng dẫn trong suốt quá trình tạo user . Nhập password mạnh và tùy chọn bất kỳ thông tin user nào khác mà bạn muốn chỉ định. Cuối cùng xác nhận việc tạo user bằng Y

Thêm user vào group Docker:

  • sudo usermod -aG docker deployer

Điều này cho phép người triển khai thực hiện lệnh docker , lệnh này được yêu cầu để thực hiện việc triển khai.

Trong bước tiếp theo, bạn sẽ tạo SSH key để có thể đăng nhập vào server với quyền là người triển khai .

Bước 4 - Cài đặt SSH key

Bạn sẽ tạo SSH key cho user triển khai. GitLab CI / CD sau này sẽ sử dụng khóa để đăng nhập vào server và thực hiện quy trình triển khai.

Hãy bắt đầu bằng cách chuyển sang user triển khai mới được tạo mà bạn sẽ tạo SSH key :

  • su deployer

Bạn sẽ được yêu cầu nhập password của người triển khai để hoàn tất quá trình chuyển đổi user .

Tiếp theo, tạo SSH key 4096 bit. Điều quan trọng là phải trả lời chính xác các câu hỏi của lệnh ssh-keygen :

  1. Câu hỏi đầu tiên: hãy trả lời nó bằng ENTER , nơi lưu trữ khóa ở vị trí mặc định (phần còn lại của hướng dẫn này giả định khóa được lưu trữ ở vị trí mặc định).
  2. Câu hỏi thứ hai: cấu hình password để bảo vệ private key SSH (khóa được sử dụng để xác thực). Nếu bạn chỉ định một passphrase (password bảo vệ) , bạn sẽ phải nhập nó mỗi khi sử dụng private key . Nói chung, một passphrase (password bảo vệ) sẽ thêm một lớp bảo mật khác vào các SSH key , đây là một phương pháp hay. Ai đó sở hữu private key cũng sẽ yêu cầu passphrase (password bảo vệ) để sử dụng khóa. Đối với mục đích của hướng dẫn này, điều quan trọng là bạn phải có passphrase (password bảo vệ) trống, vì đường ống CI / CD sẽ thực thi không tương tác và do đó không cho phép nhập passphrase (password bảo vệ) .

Để tóm tắt, hãy chạy lệnh sau và xác nhận cả hai câu hỏi bằng ENTER để tạo SSH key 4096 bit và lưu trữ nó ở vị trí mặc định với passphrase (password bảo vệ) trống:

  • ssh-keygen -b 4096

Để cấp quyền SSH key cho user trình triển khai , bạn cần phải nối public key vào file authorized_keys quyền_key:

  • cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

~ là viết tắt của user home trong Linux. Chương trình cat sẽ in nội dung của một file ; ở đây bạn sử dụng toán tử >> để chuyển hướng kết quả của cat và nối nó vào file authorized_keys quyền_key.

Trong bước này, bạn đã tạo một cặp SSH key cho đường ống CI / CD để đăng nhập và triển khai ứng dụng. Tiếp theo, bạn sẽ lưu trữ private key trong GitLab để làm cho nó có thể truy cập được trong quá trình chuyển tiếp.

Bước 5 - Lưu trữ Khóa cá nhân trong Biến GitLab CI / CD

Bạn sẽ lưu trữ private key SSH trong biến file GitLab CI / CD, để đường dẫn có thể sử dụng khóa để đăng nhập vào server .

Khi GitLab tạo một đường ống CI / CD, nó sẽ gửi tất cả các biến đến trình chạy tương ứng và các biến sẽ được đặt làm biến môi trường trong suốt thời gian thực hiện công việc. Đặc biệt, các giá trị của biến tệp được lưu trữ trong một file và biến môi trường sẽ chứa đường dẫn đến file này.

Khi bạn đang ở trong phần biến, bạn cũng sẽ thêm một biến cho IP server và user server , biến này sẽ thông báo cho đường dẫn về server đích và user đăng nhập.

Bắt đầu bằng cách hiển thị private key SSH:

  • cat ~/.ssh/id_rsa

Sao chép kết quả vào clipboard của bạn bằng CTRL+C Đảm bảo sao chép mọi thứ bao gồm dòng BEGIN và END :

~ / .ssh / id_rsa
-----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----

Bây giờ chuyển đến Cài đặt > CI / CD > Biến trong dự án GitLab của bạn và nhấp vào Thêm biến . Điền vào biểu mẫu như sau:

  • Khóa: ID_RSA
  • Giá trị: Dán private key SSH của bạn từ clipboard bằng CTRL+V
  • Loại: Tệp
  • Phạm vi môi trường: Tất cả (mặc định)
  • Bảo vệ biến: Đã kiểm tra
  • Biến mặt nạ: Bỏ chọn

Lưu ý: Không thể ẩn biến vì nó không đáp ứng các yêu cầu về biểu thức chính quy (xem tài liệu của GitLab về các biến bị che ). Tuy nhiên, private key sẽ không bao giờ xuất hiện trong log console , điều này khiến việc che giấu nó trở nên lỗi thời.

Một file chứa private key sẽ được tạo trên trình chạy cho mỗi công việc CI / CD và đường dẫn của nó sẽ được lưu trữ trong biến môi trường $ID_RSA .

Tạo một biến khác bằng IP server của bạn. Nhấp vào Thêm biến và điền vào biểu mẫu như sau:

  • Khóa: SERVER_IP
  • Giá trị: your_server_IP
  • Loại: Biến
  • Phạm vi môi trường: Tất cả (mặc định)
  • Bảo vệ biến: Đã kiểm tra
  • Biến mặt nạ: Đã kiểm tra

Cuối cùng, tạo một biến với user đăng nhập. Nhấp vào Thêm biến và điền vào biểu mẫu như sau:

  • Khóa: SERVER_USER
  • Giá trị: người deployer
  • Loại: Biến
  • Phạm vi môi trường: Tất cả (mặc định)
  • Bảo vệ biến: Đã kiểm tra
  • Biến mặt nạ: Đã kiểm tra

Đến đây bạn đã lưu trữ private key trong biến GitLab CI / CD, biến này làm cho khóa khả dụng trong quá trình thực thi đường ống. Trong bước tiếp theo, bạn đang chuyển sang cấu hình đường ống CI / CD.

Bước 6 - Cấu hình .gitlab-ci.yml

Bạn sẽ cấu hình đường dẫn GitLab CI / CD. Đường ống sẽ xây dựng Docker image và đẩy nó vào register containers . GitLab cung cấp register containers cho mỗi dự án. Bạn có thể khám phá register containers bằng cách đi tới Gói & Đăng ký > Đăng ký Vùng chứa trong dự án GitLab của bạn (đọc thêm trong tài liệu đăng ký containers của GitLab .) Bước cuối cùng trong đường dẫn của bạn là đăng nhập vào server của bạn, kéo Docker image mới nhất, xóa containers cũ và bắt đầu containers mới.

Đến đây bạn sẽ tạo .gitlab-ci.yml chứa cấu hình đường ống. Trong GitLab, chuyển đến trang tổng quan về Dự án , nhấp vào nút + và chọn Tệp mới . Sau đó đặt tên File thành .gitlab-ci.yml .

(Ngoài ra, bạn có thể sao chép repository và thực hiện tất cả các thay đổi sau đây đối với .gitlab-ci.yml trên máy local của bạn, sau đó commit và đẩy đến repository từ xa.)

Để bắt đầu thêm những thứ sau:

.gitlab-ci.yml
stages:   - publish   - deploy

Mỗi công việc được giao cho một giai đoạn . Các công việc được giao cho cùng một công đoạn chạy song song (nếu có đủ số người chạy). Các giai đoạn sẽ được thực hiện theo thứ tự mà chúng đã được chỉ định. Ở đây, giai đoạn publish sẽ đi đầu tiên và giai đoạn deploy thứ hai. Các giai đoạn kế tiếp chỉ bắt đầu khi giai đoạn trước kết thúc thành công (nghĩa là tất cả các công việc đã được thực hiện). Nghệ danh có thể được chọn tùy ý.

Khi bạn muốn kết hợp cấu hình CD này với đường ống CI hiện có của bạn , nơi kiểm tra và xây dựng ứng dụng, bạn có thể cần thêm các giai đoạn publish và deploy sau các giai đoạn hiện có của bạn , sao cho việc triển khai chỉ diễn ra nếu các thử nghiệm được thông qua.

Sau đó, thêm nó vào .gitlab-ci.yml của bạn:

.gitlab-ci.yml
. . . variables:   TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest   TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHORT_SHA

Phần biến xác định các biến môi trường sẽ có sẵn trong ngữ cảnh của phần script của công việc. Các biến này sẽ có sẵn như các biến môi trường Linux thông thường; nghĩa là, bạn có thể tham chiếu chúng trong tập lệnh bằng cách bắt đầu bằng ký hiệu đô la, chẳng hạn như $TAG_LATEST . GitLab tạo một số biến xác định trước cho từng công việc cung cấp thông tin ngữ cảnh cụ thể, chẳng hạn như tên nhánh hoặc băm commit mà công việc đang làm việc (đọc thêm về biến xác định trước ). Ở đây, bạn tạo hai biến môi trường từ các biến được định nghĩa . Họ đại diện:

  • CI_REGISTRY_IMAGE : Đại diện cho URL của register containers được liên kết với dự án cụ thể. URL này phụ thuộc vào version GitLab. Ví dụ: URL đăng ký cho các dự án gitlab.com tuân theo mẫu: registry.gitlab.com/ your_user / your_project . Nhưng vì GitLab sẽ cung cấp biến này nên bạn không cần biết URL chính xác.
  • CI_COMMIT_REF_NAME : Tên chi nhánh hoặc thẻ mà dự án được xây dựng.
  • CI_COMMIT_SHORT_SHA : Tám ký tự đầu tiên của bản sửa đổi commit mà dự án được xây dựng.

Cả hai biến đều bao gồm các biến được định nghĩa và sẽ được sử dụng để gắn thẻ Docker image .

TAG_LATEST sẽ thêm thẻ latest vào hình ảnh. Đây là chiến lược phổ biến để cung cấp thẻ luôn đại diện cho bản phát hành mới nhất. Đối với mỗi lần triển khai, hình ảnh latest sẽ được overrides trong register containers bằng Docker image mới được xây dựng.

TAG_COMMIT , mặt khác, sử dụng tám ký tự đầu tiên của commit SHA đang được triển khai làm thẻ hình ảnh, do đó tạo ra một Docker image duy nhất cho mỗi commit . Bạn có thể theo dõi lịch sử của Docker image đến mức độ chi tiết của các commit Git. Đây là một kỹ thuật phổ biến khi thực hiện triển khai liên tục, vì nó cho phép bạn nhanh chóng triển khai version cũ hơn của mã trong trường hợp triển khai bị lỗi.

Khi bạn sẽ khám phá trong các bước tiếp theo, quá trình khôi phục triển khai về bản sửa đổi Git cũ hơn có thể được thực hiện trực tiếp trong GitLab.

$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME chỉ định tên cơ sở Docker image . Theo tài liệu của GitLab , tên Docker image phải tuân theo sơ đồ này:

image name scheme
<registry URL>/<namespace>/<project>/<image>

$CI_REGISTRY_IMAGE đại diện cho phần <registry URL>/<namespace>/<project> và là bắt buộc vì nó là root đăng ký của dự án. $CI_COMMIT_REF_NAME là tùy chọn nhưng hữu ích để lưu trữ Docker image cho các nhánh khác nhau. Trong hướng dẫn này, bạn sẽ chỉ làm việc với một nhánh, nhưng rất tốt nếu bạn xây dựng một cấu trúc có thể mở rộng. Nói chung, có ba cấp độ tên repository hình ảnh được GitLab hỗ trợ:

repository name levels
registry.example.com/group/project:some-tag registry.example.com/group/project/image:latest registry.example.com/group/project/my/image:rc1

Đối với biến TAG_COMMIT bạn đã sử dụng tùy chọn thứ hai, trong đó image sẽ được thay thế bằng tên chi nhánh.

Tiếp theo, thêm phần sau vào .gitlab-ci.yml của bạn:

.gitlab-ci.yml
. . . publish:   image: docker:latest   stage: publish   services:     - docker:dind   script:     - docker build -t $TAG_COMMIT -t $TAG_LATEST .     - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY     - docker push $TAG_COMMIT     - docker push $TAG_LATEST

Phần publish là công việc đầu tiên trong cấu hình CI / CD của bạn. Hãy chia nhỏ nó:

  • image là image Docker để sử dụng cho công việc này. Trình chạy GitLab sẽ tạo containers Docker cho mỗi công việc và thực thi tập lệnh trong containers này. docker:latest hình ảnh docker:latest đảm bảo lệnh docker sẽ khả dụng.
  • stage giao việc cho giai đoạn publish .
  • services chỉ định Docker-in-Docker — dịch vụ dind . Đây là lý do tại sao bạn đăng ký Á hậu GitLab ở chế độ quyền .

Phần script của publish việc publish chỉ định các lệnh shell để thực thi cho công việc này. Thư mục làm việc sẽ được đặt thành folder root khi các lệnh này được thực thi.

  • docker build ... : Tạo Docker image dựa trên Dockerfile và gắn thẻ nó bằng thẻ commit mới nhất được xác định trong phần biến.
  • docker login ... : docker login ... Docker vào register containers của dự án. Bạn sử dụng biến được định nghĩa $CI_BUILD_TOKEN làm mã thông báo xác thực. GitLab sẽ tạo mã thông báo và giữ nguyên giá trị trong suốt thời gian của công việc.
  • docker push ... : Đẩy cả hai thẻ hình ảnh vào register containers .

Sau đó, thêm công việc deploy vào .gitlab-ci.yml của bạn:

.gitlab-ci.yml
. . . deploy:   image: alpine:latest   stage: deploy   tags:     - deployment   script:     - chmod og= $ID_RSA     - apk update && apk add openssh-client     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker pull $TAG_COMMIT"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker container rm -f my-app || true"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker run -d -p 80:80 --name my-app $TAG_COMMIT"

Alpine là một bản phân phối Linux nhẹ và đủ để làm Docker image ở đây. Bạn giao việc cho giai đoạn deploy . Thẻ triển khai đảm bảo công việc sẽ được thực thi trên người chạy được gắn thẻ deployment , chẳng hạn như người chạy mà bạn đã cấu hình ở Bước 2.

Phần script của công việc deploy bắt đầu với hai lệnh cấu hình:

  • chmod og= $ID_RSA : Thu hồi tất cả các quyền cho group và những người khác từ private key , sao cho chỉ chủ sở hữu mới có thể sử dụng. Đây là một yêu cầu, nếu không SSH sẽ từ chối làm việc với private key .
  • apk update && apk add openssh-client : Cập nhật trình quản lý gói của Alpine (apk) và cài đặt openssh-client , cung cấp lệnh ssh .

Bốn lệnh ssh liên tiếp theo sau. Các mẫu cho mỗi là:

ssh connect pattern for all deployment commands
ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "command"

Trong mỗi câu lệnh ssh bạn đang thực hiện command trên server từ xa. Để làm như vậy, bạn xác thực bằng private key của bạn .

Các tùy chọn như sau:

  • -i là viết tắt của tệp danh tính và $ID_RSA là biến GitLab chứa đường dẫn đến file private key .
  • -o StrictHostKeyChecking=no đảm bảo bỏ qua câu hỏi, cho dù bạn có tin cậy server từ xa hay không. Câu hỏi này không thể được trả lời trong bối cảnh không tương tác chẳng hạn như đường ống.
  • $SERVER_USER và $SERVER_IP là các biến GitLab mà bạn đã tạo ở Bước 5. Chúng chỉ định server từ xa và user đăng nhập cho kết nối SSH.
  • command sẽ được thực thi trên server từ xa.

Việc triển khai cuối cùng diễn ra bằng cách thực hiện bốn lệnh sau trên server của bạn:

  1. docker login ... : docker login ... Docker vào register containers .
  2. docker pull ... : Kéo hình ảnh mới nhất từ register containers .
  3. docker container rm ... : Xóa containers hiện có nếu nó tồn tại. || true đảm bảo mã thoát luôn thành công, ngay cả khi không có containers nào chạy bằng tên my-app . Điều này đảm bảo quy trình xóa nếu tồn tại mà không phá vỡ đường ống khi containers không tồn tại (ví dụ: đối với lần triển khai đầu tiên).
  4. docker run ... : Bắt đầu một containers mới bằng cách sử dụng hình ảnh mới nhất từ register . Vùng chứa sẽ được đặt tên là my-app . Cổng 80 trên server sẽ được liên kết với cổng 80 của containers (thứ tự là -p host:container ). -d khởi động containers ở chế độ tách rời, nếu không đường ống sẽ bị kẹt khi chờ lệnh kết thúc.

Lưu ý: Có vẻ kỳ lạ khi sử dụng SSH để chạy các lệnh này trên server của bạn, vì trình chạy GitLab thực thi các lệnh là cùng một server . Tuy nhiên, nó là bắt buộc, bởi vì người chạy thực thi các lệnh trong một containers Docker, do đó bạn sẽ triển khai bên trong containers thay vì server nếu bạn thực hiện các lệnh mà không sử dụng SSH. Người ta có thể tranh luận rằng thay vì sử dụng Docker làm trình thực thi chạy , bạn có thể sử dụng trình thực thi shell để chạy các lệnh trên chính server . Tuy nhiên, điều đó sẽ tạo ra một hạn chế đối với đường dẫn của bạn, cụ thể là người chạy phải cùng một server với server mà bạn muốn triển khai. Đây không phải là giải pháp bền vững và có thể mở rộng vì một ngày nào đó bạn có thể cần di chuyển ứng dụng sang một server khác hoặc sử dụng một server chạy khác. Trong mọi trường hợp, việc sử dụng SSH để thực hiện các lệnh triển khai là hợp lý, có thể vì lý do kỹ thuật hoặc liên quan đến di chuyển.

Hãy tiếp tục bằng cách thêm điều này vào công việc triển khai trong .gitlab-ci.yml của bạn:

.gitlab-ci.yml
. . . deploy: . . .   environment:     name: production     url: http://your_server_IP   only:     - master

Môi trường GitLab cho phép bạn kiểm soát việc triển khai trong GitLab. Bạn có thể kiểm tra các môi trường trong dự án GitLab của bạn bằng cách đi tới Hoạt động> Môi trường . Nếu đường ống vẫn chưa hoàn thành, sẽ không có môi trường nào có sẵn, vì không có triển khai nào diễn ra cho đến nay.

Khi một công việc đường ống xác định một phần environment , GitLab sẽ tạo một triển khai cho môi trường đã cho (ở đây là production ) mỗi khi công việc kết thúc thành công. Điều này cho phép bạn theo dõi tất cả các triển khai được tạo bởi GitLab CI / CD. Đối với mỗi lần triển khai, bạn có thể thấy commit liên quan và nhánh mà nó được tạo.

Ngoài ra còn có một nút có sẵn để triển khai lại cho phép bạn quay lại version cũ hơn của phần mềm. URL đã được chỉ định trong phần environment sẽ được mở khi nhấp vào nút Xem triển khai .

Phần only xác định tên của các nhánh và thẻ mà công việc sẽ chạy. Theo mặc định, GitLab sẽ bắt đầu một đường dẫn cho mỗi lần đẩy đến repository và chạy tất cả các công việc (với điều kiện .gitlab-ci.yml tồn tại). Phần only là một tùy chọn hạn chế thực thi công việc đối với một số nhánh / thẻ nhất định. Ở đây bạn muốn thực hiện các công việc triển khai cho các master chỉ chi nhánh. Để xác định các luật phức tạp hơn về việc một công việc có nên chạy hay không, hãy xem cú pháp luật .

Lưu ý: Vào tháng 10 năm 2020, GitHub đã thay đổi quy ước đặt tên cho nhánh mặc định từ master thành main . Các nhà cung cấp khác như GitLab và cộng đồng nhà phát triển nói chung đang bắt đầu làm theo cách tiếp cận này. Nhiệm kỳ master chi nhánh được sử dụng trong hướng dẫn này để biểu thị các chi nhánh mặc định mà bạn có thể có một cái tên khác.

Tệp .gitlab-ci.yml hoàn chỉnh của bạn sẽ trông giống như sau:

.gitlab-ci.yml
stages:   - publish   - deploy  variables:   TAG_LATEST: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:latest   TAG_COMMIT: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_NAME:$CI_COMMIT_SHORT_SHA  publish:   image: docker:latest   stage: publish   services:     - docker:dind   script:     - docker build -t $TAG_COMMIT -t $TAG_LATEST .     - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY     - docker push $TAG_COMMIT     - docker push $TAG_LATEST  deploy:   image: alpine:latest   stage: deploy   tags:     - deployment   script:     - chmod og= $ID_RSA     - apk update && apk add openssh-client     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker pull $TAG_COMMIT"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker container rm -f my-app || true"     - ssh -i $ID_RSA -o StrictHostKeyChecking=no $SERVER_USER@$SERVER_IP "docker run -d -p 80:80 --name my-app $TAG_COMMIT"   environment:     name: production     url: http://your_server_IP   only:     - master

Cuối cùng nhấp vào Commit thay đổi ở cuối trang trong GitLab để tạo .gitlab-ci.yml . Ngoài ra, khi bạn đã nhân bản local repository Git, hãy commit và đẩy file đó vào điều khiển từ xa.

Bạn đã tạo cấu hình GitLab CI / CD để xây dựng Docker image và triển khai nó tới server của bạn. Trong bước tiếp theo, bạn xác nhận việc triển khai.

Bước 7 - Xác thực việc triển khai

Đến đây bạn sẽ xác thực việc triển khai ở nhiều nơi khác nhau của GitLab cũng như trên server của bạn và trong trình duyệt.

Khi một .gitlab-ci.yml được đẩy vào repository , GitLab sẽ tự động phát hiện nó và bắt đầu một đường dẫn CI / CD. Tại thời điểm bạn tạo .gitlab-ci.yml , GitLab đã bắt đầu đường dẫn đầu tiên.

Đi tới CI / CD > Đường ống trong dự án GitLab của bạn để xem trạng thái của đường ống. Nếu công việc vẫn đang chạy / đang chờ xử lý, hãy đợi cho đến khi chúng hoàn tất. Bạn sẽ thấy một đường dẫn Đã qua với hai dấu kiểm màu xanh lục, biểu thị rằng công việc xuất bản và triển khai đã chạy thành công.

Trang tổng quan về đường dẫn hiển thị đường dẫn đã qua

Hãy kiểm tra đường ống. Nhấp vào nút đã qua trong cột Trạng thái để mở trang tổng quan của đường dẫn. Bạn sẽ có được một cái nhìn tổng thể về các thông tin chung như:

  • Thời gian thực hiện của toàn bộ đường ống.
  • Đối với commit và phân nhánh nào, đường ống đã được thực thi.
  • Các yêu cầu hợp nhất có liên quan. Nếu có một yêu cầu hợp nhất mở cho chi nhánh phụ trách, nó sẽ hiển thị ở đây.
  • Tất cả các công việc được thực hiện trong đường dẫn này cũng như trạng thái của chúng.

Tiếp theo nhấp vào nút triển khai để mở trang kết quả của công việc triển khai.

Trang kết quả của công việc triển khai

Trên trang kết quả công việc, bạn có thể thấy kết quả kết quả của kịch bản lệnh của công việc. Đây là nơi cần tìm khi gỡ lỗi đường dẫn bị lỗi. Trong thanh bên bên phải, bạn sẽ tìm thấy thẻ triển khai mà bạn đã thêm vào công việc này và thẻ đã được thực thi trên Trình chạy triển khai của bạn.

Nếu bạn cuộn lên đầu trang, bạn sẽ thấy thông báo Công việc này được triển khai cho production . GitLab nhận ra rằng việc triển khai đã diễn ra do phần môi trường của công việc. Nhấp vào liên kết sản xuất để chuyển sang môi trường production .

Môi trường production trong GitLab

Bạn sẽ có một cái nhìn tổng quan về tất cả các triển khai production . Chỉ có một triển khai duy nhất cho đến nay. Đối với mỗi lần triển khai, có một nút triển khai lại ở bên phải. Việc triển khai lại sẽ lặp lại công việc triển khai của đường ống cụ thể đó.

Việc triển khai lại có hoạt động như dự định hay không phụ thuộc vào cấu hình đường ống, bởi vì nó sẽ không làm được nhiều hơn việc lặp lại công việc triển khai trong các trường hợp tương tự. Vì bạn đã cấu hình để triển khai Docker image bằng cách sử dụng commit SHA làm thẻ, nên việc triển khai lại sẽ hoạt động cho đường ống của bạn.

Lưu ý: Register containers GitLab của bạn có thể có chính sách hết hạn . Chính sách hết hạn thường xuyên xóa các hình ảnh và thẻ cũ hơn khỏi register containers . Do đó, một triển khai cũ hơn policy hết hạn sẽ không thể triển khai lại, vì Docker image cho commit này sẽ bị xóa khỏi register .Bạn có thể quản lý policy hết hạn trong Cài đặt> CI / CD> Chính sách hết hạn thẻ Đăng ký containers . Khoảng thời gian hết hạn thường được đặt ở mức cao, chẳng hạn như 90 ngày. Nhưng khi bạn gặp phải trường hợp cố gắng triển khai một hình ảnh đã bị xóa khỏi register do policy hết hạn, bạn có thể giải quyết vấn đề bằng cách chạy lại công việc xuất bản của đường ống cụ thể đó, quá trình này sẽ tạo lại và đẩy hình ảnh cho commit đã cho vào register .

Tiếp theo, nhấp vào nút Xem triển khai , nút này sẽ mở http:// your_server_IP trong trình duyệt và bạn sẽ thấy tiêu đề Trang web cá nhân của tôi .

Cuối cùng, ta muốn kiểm tra containers đã triển khai trên server của bạn. Đi tới terminal của bạn và đảm bảo đăng nhập lại, nếu bạn đã ngắt kết nối (nó hoạt động cho cả user , sammy và người triển khai ):

  • ssh sammy@your_server_IP

Bây giờ hãy liệt kê các containers đang chạy:

  • docker container ls

Cái nào sẽ liệt kê containers my-app :

Output
CONTAINER ID        IMAGE                                                          COMMAND                  CREATED             STATUS              PORTS                NAMES 5b64df4b37f8        registry.your_gitlab.com/your_gitlab_user/your_project/master:your_commit_sha   "nginx -g 'daemon of…"   4 hours ago         Up 4 hours          0.0.0.0:80->80/tcp   my-app

Đọc hướng dẫn Cách cài đặt và sử dụng Docker trên Ubuntu 18.04 để tìm hiểu thêm về cách quản lý containers Docker.

Đến đây bạn đã xác thực việc triển khai. Trong bước tiếp theo, bạn sẽ trải qua quá trình quay trở lại triển khai.

Bước 8 - Quay lại triển khai

Tiếp theo, bạn sẽ cập nhật trang web, trang này sẽ tạo một triển khai mới và sau đó triển khai lại triển khai trước đó bằng cách sử dụng môi trường GitLab. Điều này đề cập đến trường hợp sử dụng của việc khôi phục triển khai trong trường hợp triển khai bị lỗi.

Bắt đầu bằng cách thực hiện một chút thay đổi trong index.html :

  1. Trong GitLab, đi tới Tổng quan về dự án và mở index.html .
  2. Nhấp vào nút Chỉnh sửa để mở trình chỉnh sửa trực tuyến.
  3. Thay đổi nội dung file thành như sau:
index.html
<html> <body> <h1>My Enhanced Personal Website</h1> </body> </html>

Lưu các thay đổi bằng cách nhấp vào Commit thay đổi ở cuối trang.

Một đường dẫn mới sẽ được tạo để áp dụng các thay đổi . Trong GitLab, đi tới CI / CD> Pipelines . Khi hoàn tất , bạn có thể mở http:// your_server_IP trong trình duyệt cho trang web cập nhật hiện đang hiển thị Trang web Cá nhân Nâng cao của Tôi thay vì Trang web Cá nhân của Tôi .

Khi chuyển đến Operations> En Environment> production, bạn sẽ thấy triển khai mới được tạo. Bây giờ hãy nhấp vào nút triển khai lại của triển khai ban đầu, cũ hơn:

Danh sách các triển khai của môi trường production trong GitLab với nhấn mạnh vào nút triển khai lại của lần triển khai đầu tiên

Xác nhận cửa sổ bật lên bằng cách nhấp vào nút Rollback .

Công việc triển khai của đường ống cũ hơn đó sẽ được khởi động lại và bạn sẽ được chuyển hướng đến trang tổng quan của công việc. Chờ công việc hoàn tất, sau đó mở http:// your_server_IP trong trình duyệt, tại đây bạn sẽ thấy dòng tiêu đề ban đầu Trang web Cá nhân của tôi hiển thị trở lại.

Hãy tóm tắt những gì bạn đã đạt được trong suốt hướng dẫn này.

Kết luận

Trong hướng dẫn này, bạn đã cấu hình một đường dẫn triển khai liên tục với GitLab CI / CD. Bạn đã tạo một dự án web nhỏ bao gồm một file HTML và một file Docker. Sau đó, bạn đã cấu hình đường ống .gitlab-ci.yml thành:

  1. Xây dựng Docker image .
  2. Đẩy Docker image vào register containers .
  3. Đăng nhập vào server , kéo hình ảnh mới nhất, dừng containers hiện tại và bắt đầu một containers mới.

GitLab bây giờ sẽ triển khai trang web đến server của bạn cho mỗi lần đẩy đến repository .

Hơn nữa, bạn đã xác minh việc triển khai trong GitLab và trên server của bạn . Bạn cũng đã tạo triển khai thứ hai và quay trở lại triển khai đầu tiên bằng cách sử dụng môi trường GitLab, điều này thể hiện cách bạn đối phó với các triển khai bị lỗi.

Đến đây, bạn đã tự động hóa toàn bộ chuỗi triển khai. Như vậy, bạn có thể chia sẻ các thay đổi mã thường xuyên hơn với mọi người và / hoặc khách hàng. Do đó, các chu kỳ phát triển có thể trở nên ngắn hơn, vì cần ít thời gian hơn để thu thập phản hồi và xuất bản các thay đổi mã.

Bước tiếp theo, bạn có thể làm cho dịch vụ của bạn có thể truy cập được bằng domain và bảo mật thông tin liên lạc với HTTPS mà Cách sử dụng Traefik làm Reverse-proxy cho Docker Containers là một bước tiếp theo.

Tags:

Các tin liên quan

Cách cài đặt và bảo mật phpMyAdmin trên Ubuntu 20.04
2020-10-22
Cách cài đặt BigBlueButton trên Ubuntu 16.04
2020-10-21
Cách đồng bộ hóa và chia sẻ file với Seafile trên Ubuntu 18.04
2020-10-15
Cách cài đặt MongoDB từ Kho lưu trữ APT mặc định trên Ubuntu 20.04
2020-10-10
Cách cài đặt mongodb trên ubuntu 18.04 từ trang chủ Mongodb
2020-10-08
Cách bảo mật MongoDB trên Ubuntu 18.04
2020-10-08
Cách cấu hình quyền truy cập từ xa cho MongoDB trên Ubuntu 18.04
2020-10-08
Cách cài đặt MongoDB trên Ubuntu 18.04 từ kho APT mặc định
2020-10-08
Làm thế nào để quản lý client OpenSSH trên Ubuntu 18.04
2020-09-30
Cách cài đặt và sử dụng ClickHouse trên Ubuntu 20.04
2020-09-22