Author: tunghn140706

  • Gitlab CI/CD cho người mới bắt đầu – Phần 2: Configure Runner

    Gitlab CI/CD cho người mới bắt đầu – Phần 2: Configure Runner

    Xin chào mọi người,
    Chúng ta đã quá lâu không gặp lại nhau rồi đúng không?
    Như đã nói từ kì trước, để tiếp tục series "Gitlab CI/CD cho người mới bắt đầu", thì ở bài này mình sẽ viết về cách set-up local gitlab runner, cụ thể hơn, chúng ta sẽ setting 1 runner qua Docker.

    Tại sao lại là Docker chứ không phải là trên Window hay MacOS? Mình chọn Docker vì nó đơn giản với những người mới, cộng với tính linh động của nó trên nhiều môi trường khác nhau. Vì vậy, nên để có thể tiếp tục với tutorial này thì việc đầu tiên bạn cần làm là có docker ở trên máy của mình. (Bạn có thể xem hướng dẫn tải và cài đặt tại đây) Nếu bạn đã cài đặt thành công Docker trên máy, thì chúng ta sẽ bắt đầu vào phần chính ngay thôi.

    Về cơ bản thì việc khởi tạo và chạy runner qua Docker này sẽ trải qua 2 bước: (Chi tiết có thể xem tại đây)

    Bước 1: Khởi tạo và chạy gitlab runner

    https://docs.gitlab.com/runner/install/  
    docker run -d --name gitlab-runner --restart always \
      -v gitlab-runner:/etc/gitlab-runner \
      -v /var/run/docker.sock:/var/run/docker.sock \
      gitlab/gitlab-runner:latest 
    

    Bước 2: Đăng kí gitlab runner đó với project mà chúng ta muốn sử dụng

    docker exec -it gitlab-runner bash 
    
    gitlab-runner register -n  --name GitLabRunner  \
    --executor docker  --docker-image docker:latest  \
    --docker-volumes /var/run/docker.sock:/var/run/docker.sock  \
    --url ${GITLAB_URL}  \
    --registration-token ${GITLAB_TOKEN} \
    --tag-list cicd_tag
    

    Ở bước này chúng ta sẽ cần config 2 biến env trong phần variable tại repo gitlab,

    • Biến thứ nhất GITLAB_URL chính là URL tới repo cần config runners,
    • Biến thứ 2 GITLAB_TOKEN là secret token để runner kết nối với repo trên gitlab. Gitlab Token & Gitlab Url

    (Ngoài ra các bạn có thế xem thêm các cài đặt nâng cao khi đăng kí runner tại đây)

    Khi đăng kí runner như trên, bạn sẽ cần chú ý vào tag-list, tại đây thì runner sẽ nhận diện những job nào được gắn tag đó để khởi chạy!

    Đó, và như vậy là chúng ta đã đăng kí thành công local runner cho repo gitlab. Thật đơn giản phải không? =)))

    Stay tuned and keep waiting for our next articles nhớ <3.
    Xin chào thân ái và quyết thắng tới mn!

  • Gitlab CI/CD cho người mới bắt đầu

    Gitlab CI/CD cho người mới bắt đầu

    CI-CD in gitlab

    Chắc hẳn mọi người đã từng nghe tới CI-CD, rồi thắc mắc không biết nó là gì và chúng ta có thể làm gì với nó? Mình cũng như vậy, thắc mắc ấy đưa mình đến việc viết chuỗi bài này để chia sẻ về những gì mình đã học được về CI-CD.

    Trong bài này thì mình sẽ tập trung vào CI, cũng như cách config file .gitlab-ci.yml và chạy trên share runner của gitlab.

    I. Vậy CI-CD là gì?

    CI (Coutinous Integration) – tích hợp liên tục, là quá trình mà code của chúng ta được build và test trước khi tích hợp vào nhánh chính.

    CD (Continous Delivery) – truyền tải liên tục, là quá trình mà code được triển khai lên môi trường như development hoặc production, và nó diễn ra ngay sau CI

    II. Triển khai CI như thế nào?

    1. Thành phần

    Để có thể triển khai được CI thì trước hết, chúng ta cần biết về 2 thành phần chính cấu thành nên nó. Đó là file gitlab-ci.ymlgitlab runner.

    Mọi người có thể hiểu nôm na nếu gitlab runner như một anh tài xế mà bạn thuê, anh ta rất nhiệt tình, sẵn sàng lái xe đi bất cứ nơi đâu thay cho bạn, nhưng khổ nỗi anh lại không biết đường. Hmm… Làm sao bây giờ? File gitlab-ci.yml lúc ấy xuất hiện như một tấm bản đồ vạn năng.

    File này sẽ được gitlab tự động nhận diện khi bạn commit code lên từ local, và sẽ cấp cho bạn một anh "tài xế" shared runner để đi làm những việc bạn đã vạch sẵn ở trong gitlab-ci.yml.

    Lưu ý:

    Mặc định, gitlab có một số share runner mà người dùng có thể dùng ngay lập tức. Vì vậy, đối với một project vừa và nhỏ, số lượng job cho runner còn ít, thì bạn có thể tận dụng luôn những runner đã có sẵn này. Nhưng với một project lớn hơn, khi mà số lượng cũng như tần suất chạy job ngày càng tăng lên, thì chúng ta nên config riêng một gitlab-runner trên server của mình.

    2. Template

    
    stages:          
      - build
      - test
      - deploy
    
    build-job:      
      stage: build
      script:
        - echo "Compiling the code..."
        - echo "Compile complete."
    
    unit-test-job:
      stage: test   
      script:
        - echo "Running unit tests... This will take about 60 seconds."
        - sleep 60
        - echo "Code coverage is 90%"
    
    lint-test-job:   
      stage: test   
      script:
        - echo "Linting code... This will take about 10 seconds."
        - sleep 10
        - echo "No lint issues found."
    
    deploy-job:     
      stage: deploy  
      script:
        - echo "Deploying application..."
        - echo "Application successfully deployed."
    

    Templete cho một file gitlab-ci.yml

    Chúng ta sẽ cùng nhau đi qua một lượt xem nó có ý nghĩa gì nhé!

    Đầu tiên là stages: đây sẽ là khi chúng ta định nghĩa ra các giai đoạn mà trong pipeline, hay nói cách khác là các job mà runner sẽ phải thực hiện. Như đa số project, workflow sẽ bao gồm 3 giai đoạn, đầu tiên chúng ta sẽ tạo ra một bản build của project, tiếp sau đó sẽ test, và khi đã qua được các bước trên thì sẽ deploy lên môi trường development, staging hay production.

    stages:    
      - build
      - test
      - deploy
    

    Tiếp theo, chúng ta sẽ đi cụ thể tới các build stage nha (Các giai đoạn sau cũng tương tự).

    • build-job là tên của job, cái này các bạn có thể tự thay đổi theo ý mình nhé.
    • stage chỉ ra job này đang nằm trong giai đoạn nào trong 3 stages mà chúng ta đã định nghĩa trước ở trên.
    • script là những câu lệnh mà chúng ta sẽ chạy trong job này.
    build-job:      
      stage: build
      script:
        - echo "Compiling the code..."
        - echo "Compile complete."
    

    Ngoài ra thì còn rất nhiều những thông tin config khác mà các bạn có thể tìm ở đây nha!

    Và như bạn đã thấy ở templete trên, thì một pipeline có thể có nhiều giai đoạn và một giai đoạn có thể chứa nhiều job khác nhau và các job đó có thể được thực hiện song song.

    3. Ví dụ

    Mình sẽ lấy ví dụ từ bẳng việc check lint của một project nodejs nha!

    Bước 1: Chúng ta sẽ phải cài đặt eslint và babel-eslint cho project của mình.

    npm install eslint babel-eslint --dev
    

    Bước 2: Tạo file .eslintrc để config lint rule mà mình muốn:

    {
      "env": {
        "node": true,
        "es6": true,
        "mocha": true
      },
      "parser": "babel-eslint",
      "parserOptions": {
        "ecmaVersion": 2017
      },
      "extends": "eslint:recommended",
      "rules": {
        "comma-spacing": [
          "error",
          {
            "before": false,
            "after": true
          }
        ],
        "indent": [
          "error",
          2,
          {
            "SwitchCase": 1
          }
        ],
        "linebreak-style": [
          "error",
          "unix"
        ],
        "quotes": [
          "error",
          "double"
        ],
        "semi": [
          "error",
          "always"
        ],
        "no-unused-vars": [
          "off"
        ],
        "no-console": 0
      }
    }
    

    Bước 3: Thêm script cho việc check lỗi và fix lỗi lint trong file package.json

    Trong dấu "{}" ở câu lệnh lint là các folder mà mình muốn check lint, các bạn có thể để folder khác cho phù hợp với project của mình nhé!

    Bước 4: Chạy lần lượt hai câu script trên và đẩy code lên git.

    Bước này là để trước khi các bạn check xem những nhánh phụ merge vào có đúng theo rule lint mình đã định nghĩa không, thì nhánh chính của mình đã thỏa mãn những rule đó từ trước.

    Bước 5: Tạo file .gitlab-ci.yml

    
    
    stages:   
      - checklint
    
    lint-test-job: 
      stage: checklint    
      image: node:12.18-alpine 
      only:           
        refs:
          - merge_request
      script:
        - npm install eslint babel-eslint
        - npm run lint
    
    

    Ở đây sẽ có 2 từ khóa mới:

    image: dùng base image là node:12.18-alpine để tạo một node instance chạy các câu lệnh mình định nghĩa ở phần script

    onlyrefs: giới hạn việc chạy job này chỉ khi có merge request

    Bước 6: Tách nhánh mới, đẩy lại code lên gitlab và tạo merge request

    • Đây là ở merge request trước khi chúng ta đẩy file gitlab-ci.yml lên remote repo

    • Sau khi đẩy file gitlab-ci.yml lên

    Bây giờ nếu như mọi người thấy biểu tượng pipeline running như hình 2 ở trên là mình đã thành công rồi nha!

    Từ bây giờ mỗi khi bạn đẩy code mới lên remote repository thì gitlab runner sẽ tự động chạy test lint cho chúng ta!

    Nếu thích bài viêt này thì các bạn nhớ like and và share để ủng hộ mình có động lực viết phần tiếp theo về gitlab runner và CD nha <3

    P/s: Đây là bài viết đầu của mình nên không thể tránh khỏi những thiếu sót, có gì mong được mọi người bỏ qua và góp ý cho mình nha! Cảm ơn mọi người nhiều <3