Continuous Integration (CI) – Deployment (CD) với gitlab – kỉ nguyên mới cho CI/CD

Để đọc bài viết này bạn cần biết về docker: nếu bạn chưa biết docker thì có thể bỏ ra nửa tiếng đồng hồ để làm quen với nó qua loạt bài viết về docker của mình

Ngoài ra bạn còn cần biết đôi chút về CI, nếu chưa biết thì có thể đọc qua bài viết về CI với CircleCI của mình.

CD thì mình sẽ nói trong bài viết luôn.

Bài viết này mình sẽ demo bằng rails, các ngôn ngữ, framework khác cũng tương tự nhé, cái mình muốn đưa đến cho bạn là cái nhìn từ tổng quan đến chi tiết việc cài đặt, tích hợp all-in-one với gitlab 🙂

Đôi chút về các dịch vụ CI

Xưa nay, khi nhắc đến CI, chúng ta thường nghĩ theo 2 hướng:

  • Tự mình cài đặt hạ tầng và server (jenkins chẳng hạn). Cách này thì thường mấy công ty hay làm, chứ cá nhân thì tìm hiểu cho biết thôi 😀
  • Sử dụng các dịch vụ có sẵn (miễn phí và có phí): CircleCI, HoundCI, TravisCI… Hàng trả phí thì không nói rồi, còn hàng miễn phí thì cơ bản là bị giới hạn tè le. Công ty cũ mình hồi chơi hàng miễn phí của CircleCI, sau chịu không nổi, nâng cấp lên trả phí mà vẫn gánh không nổi, có dự án phải chờ tới 2 tiếng mới được build :((

Cái nào cũng có cái lợi, cái hại hết, và rồi gitlab đưa ra 1 giải pháp toàn diện hơn: bạn thích kiểu nào thì gitlab chiều kiểu nấy.

Gitlab CI

Gitlab Runner

Với Gitlab CI, để chạy được CI, bạn cần 1 tool gọi là Gitlab Runner

Runner sẽ là thằng thực hiện các việc như pull code về, cài đặt môi trường, chạy test, chạy linter, nói chung là chạy hết các việc mà mình định nghĩa cho nó.

Gitlab chia Runner ra làm 2 loại:

  • Shared runner: là loại chia sẻ với nhau để dùng chung, mặc định, Gitlab cung cấp cho mình nhiều shared runner để mình có thể dùng liền. Hoặc mình cũng có thể kiếm các shared của người khác mà chạy, và tất nhiên, mình cũng có thể share các runner của mình cho người khác.
  • Specific runner: là loại mà tự mình tạo ra, cho mình mình dùng thôi. Nếu không thích giữ làm của riêng thì có thể đem share ra 🙂

Nguyên lý hoạt động của các Runner là nó tương tác với Gitlab qua Gitlab API, nên mình chỉ cần 1 máy tính có kết nối mạng là có thể dùng nó làm server cài runner đặng chạy CI rồi 🙂 Vậy nên, bạn có thể dùng bất cứ gì: máy tính cá nhân, VPS, máy server, máy ảo,… để cài runner.

Shared runner có ưu điểm là có sẵn, chả phải cài đặt gì, free, nhanh gọn. Nhưng nhược điểm là cấu hình cùi, lại phải share ra nữa, và cái bất tiện lớn nhất là nhiều khi nó không đủ môi trường/quyền để mình làm các job của mình. Cho nên mình chọn phương án dùng Specific Runner, tự cài lấy 1 cái cho mình, thích làm gì thì làm :v

Mình đã thử trên cả con Macbook pro 2016 của mình, và cả VPS EC2 ubuntu, cả 2 đều chạy mượt mà, ok với các yêu cầu đơn giản, phức tạp hơn 1 tí thì bị conflict hệ điều hành do các câu lệnh nó khác nhau.

Vậy làm sao???

-> Docker 😛

Docker

Docker nó sẽ giúp mình đóng gói hết môi trường vào 1 gói, xong Runner sẽ lấy con docker đó về, làm việc trong đó. Cho nên sau này cần nâng cấp, cần build nhanh hơn, ta phải dùng nhiều Runner, nhiều server hơn, thì không phải lo việc cài đặt, cập nhật môi trường gì cả. Cứ làm ở con docker gốc là xong 😛

Gitlab cũng cung cấp luôn Gitlab Registry để host cái Docker image của mình luôn, khỏi lo chuyện chuyển qua lại nhiều interface nữa 🙂 (trước kia thì mình hay dùng docker hub, nhưng với mục đích chứa image cho CI này thì mình thấy để bên này là được rồi cần backup thì cứ push thêm 1 bản sang bên kia :P).

Bạn vào project -> Registry để biết cách push docker của mình lên.

Cài đặt và kết nối Runner với project

Trước khi cài đặt thì bạn lên gitlab project -> setting (cái bánh răng phí trên bên phải) -> Runners. Cột bên trái Specific Runner sẽ có 4 thông tin để đăng ký Runner sau này.

Bạn vào Gitlab Runner Intall guide để xem hướng dẫn cài đặt cho hệ điều hành của mình.

Sau khi cài xong, thực hiện việc đăng ký 1 Runner:

Theo bước 2 trên kia thì URL sẽ là https://gitlab.com/ci

gitlab-ci token thì lấy ở bước 3 trên kia.

Điền cái tên cho runner thôi.

Điền tag, tạm thời ở bài viết này mình không nói về tag nên có thể bỏ qua. Bạn nào muốn tìm hiểu về tag thì xem trên docs lát mình sẽ đưa, khá hữu dụng cho các dự án lớn lớn tí.

Đăng ký xong rồi, bây giờ chọn phương thức cho nó chạy.

Ở trên nó liệt kê ra rất nhiều phương thức để chạy runner, có 2 cái đáng chú ý là shell-chạy trực tiếp trên máy cài Runnerdocker-chạy trong docker.

Ở bài viết này mình chọn docker 🙂 Bạn nào không thích docker thì có thể thử với shell để nó dùng môi trường của máy bạn, cài file đồ lên máy bạn luôn 😛

Điền tên của docker image vào, lưu ý, tên này mình phải đặt trùng với tên lấy ở tab Registry trên Gitlab project.

Cú pháp Gitlab đưa ra là: registry.gitlab.com/user_name/project_name

Xong, bây giờ chạy cái service lên:


Đến lúc này, bạn lên refresh trang Runners sẽ thấy runner của bạn sẽ được liệt kê và ở trạng thái active màu xanh lá cây.

Bên cột Shared Runners, mình tắt option này đi, click vào Disable shared Runners for this project.

Gitlab CI

Để nói cho Gitlab CI những việc cần làm, ta cần định nghĩa nó trong file .gitlab-ci.yml và để nó ở thư mục gốc của dự án.

Cùng xem qua file của 1 dự án của mình.

Với dân dev thì yml rất gần gũi thân thuộc đúng không? Mà không thân thuộc thì đọc cũng tự hiểu cú pháp 😛

Những key ở root level được gọi là các jobs. Các job name này phải là duy nhất, không được trùng nhau. Gitlab nó có sẵn các job mặc định, mình có đặt tên job thì né mấy tên này ra.

  • cache: job mặc định của Gitlab CI, định nghĩa thư mục sẽ cache, và mình cho cache luôn cả nhưng file không được git track. Ngoài cache global thế này, mình có thể định nghĩa cache trong từng job con nữa.
  • before_script: job mặc định của Gitlab CI, là các lệnh sẽ chạy trước tiên. Ở đây mình bundle vào thư mục /cache để phục vụ cache, những lần sau sẽ tiết kiệm kha khá thời gian bundle install 🙂
  • stages: job này định nghĩa ra các stage, mình tạm dịch là các vùng làm việc. Các stage này sẽ chạy tuần tự từ trên xuống dưới. Các job sau này sẽ được phân vào các stage này để quản lí tiến trình. vd: mình cần chạy linter trước để bắt các lỗi về convention, sercurity, xong rồi mình mới muốn test rồi deploy nếu thành công.
  • rspec: đây là job mình tự định nghĩa, mình gắn nó vào test stage, vậy nên, mặc dù nó được định nghĩa trước nhưng nó sẽ chạy sau các job được gắn stage là linter
  • pronto: cũng là 1 job mình tự định nghĩa, nó được gắn vào linter stage để chạy trước rspec. pronto là 1 ruby gem phục vụ việc chạy linter, và có hỗ trợ chỉ check ở những dòng code mà mình thay đổi thôi chứ không chạy toàn dự án như rubocop 🙂 (bản thân pronto không định nghĩa việc linter, mà nó dùng các runner của nó, mình hay dùng pronto-rubocop).
  • deploy: job này mình định nghĩa để sau khi lint, test xong thì sẽ deploy lên staging server luôn. Practice cho các stage: lint, test, build, deploy… là tuỳ thuộc vào mỗi người tự định nghĩa, theo nhu cầu của mình 🙂

À, nói thêm 1 chút về trình tự chạy các job: các job trong cùng 1 stage sẽ được chạy đồng thời (song song), khác stage thì chạy tuần tự (nối tiếp), jobs của stage trước xong hết thì mới tới jobs của stage tiếp theo, cứ thế mà làm.

Để hiểu rõ hơn về các lệnh khác nữa, bạn có thể tham khảo ở https://docs.gitlab.com/ce/ci/yaml/

Run CI

Thêm biến môi trường cho pronto

Để chạy được lệnh pronto run -f gitlab --exit-code, mình cần thêm biến môi trường cho nó để nó có thể truy cập vào code của mình.

Bạn truy cập vào trang profile setting, tab Access Token và tạo lấy 1 token.

Sau đó sang Project setting -> Variables, điền các biến môi trường sau:

Chi tiết hơn về 2 cài đặt này ở đây.

Trigger

Mỗi khi có 1 push, Gitlab sẽ bắn sự kiện cho Gitlab CI để nó biết đường chạy. Gitlab CI sẽ làm việc với Runner, và mình chỉ việc ngồi chơi, nhìn tụi nó làm :v

Nhìn ở đâu?


Nhiều bạn chuyển từ các CI Services khác sang đây thì thấy giao diện hơi rối 1 tí, nhưng không sao, tí là quen thôi.

Bạn vào project, tab Pipelines, ở đây sẽ liệt kê ra các lần chạy CI, mỗi lần chạy CI sẽ bao gồm 1 hoặc nhiều builds. Bạn vào từng build cụ thể để xem trực tiếp là nó đang làm gì, hoặc đã làm gì 😛 Đồng thời xem log về lỗi, đang chạy trên runner nào, đang chạy ở máy nào…

Phía trên, có tab Builds để bạn vào xem danh sách các builds của mình.

Run CD

Thực ra CD mình định nghĩa luôn trong file .gitlab-ci.yml luôn rồi đó, tỏng deploy stage ấy. 🙂

Kết

Với những cái nhìn từ tổng quan đến chi tiết như này, mình hy vọng cuộc đời code của bạn sẽ tươi đẹp hơn và tập trung được nhiều hơn vào các mục tiêu của mình 🙂

Có bạn hỏi sao không làm step-by-step luôn, mà cứ cưỡi ngựa xem hoa thế?

Mình nghĩ tốt hơn là cùng đọc, cùng tìm hiểu, cùng làm thì sẽ hiệu quả hơn. Chúng ta qua thời sinh viên rồi, ai chơi cầm tay chỉ việc thế nữa :v

Nhưng em đang là sinh viên anh ơi

Thế thì chúc mừng bạn, bạn vừa có 1 guide line khá chi tiết để tiếp cận với hơi bị nhiều thứ đấy, mà mấy cái này trên trường không dạy đâu :v

Lập trình và hơn thế nữa

Spread the love
  •  
  •  
  •  
  •  
  •  

Leave a Reply

Be the First to Comment!

Notify of
avatar