Nhảy tới nội dung

Một bài viết được gắn thẻ "gitlab"

Xem tất cả Thẻ

· Một phút để đọc
ManhPT

Why docker swarm? Liên quan gì đến gitlab-runner?

Setup gitlab-runner trên môi trường docker bình thường khá đơn giản trong bài viết này. Nhưng nếu bạn có nhiều máy (máy tính local hoặc server) thì sao? Setup gitlab-runner cho từng máy không phải là một ý hay:

Kết hợp các máy này lại với nhau, tạo thành một cụm docker swarm.

Điều kiện cần

Docker swarm

Có lẽ bạn đã có sẵn môi trường docker swarm trước khi tìm thấy bài viết này. Còn nếu chưa thì bạn vui lòng tham khảo:

Tokens

Bạn vui lòng google hoặc tham khảo nội dung swarm.yml bên dưới để biết cách lấy token.

  • Gitlab runner registration token (có thể lấy của từng project hoặc group)
  • Gitlab personal access token (tại đây)

Deploy stack gitlab-runner

Tạo một file swarm.yml với nội dung như sau:

version: '3.7'

secrets:

# Find your registration token at: "Your project" > "Settings" > "CI/CD" > "Runners settings" > "Specific Runners" (look for registration token)
# Register it as `GITLAB_REGISTRATION_TOKEN`: `docker secret create GITLAB_REGISTRATION_TOKEN YOUR_REGISTRATION_TOKEN`
GITLAB_REGISTRATION_TOKEN:
external: true
# Find your personal access token at: "Your user account" > "Settings" > "Access Tokens" > "Create personal access token" (for api)
# Register it as `GITLAB_PERSONAL_ACCESS_TOKEN`: `docker secret create GITLAB_PERSONAL_ACCESS_TOKEN <YOUR ACCESS TOKEN>`
GITLAB_PERSONAL_ACCESS_TOKEN:
external: true

services:

# Gitlab Runner - https://gitlab.com/gitlab-org/gitlab-runner
runner:
image: gitlab/gitlab-runner:latest
environment:
- CONCURRENT=8
- REGISTER_LOCKED=1
- REGISTER_NON_INTERACTIVE=1
- RUNNER_EXECUTOR=docker
- DOCKER_IMAGE=docker
- DOCKER_VOLUMES=/var/run/docker.sock:/var/run/docker.sock
- RUNNER_NAME=docker
- API_URL=https://gitlab.com/api/v4
- CI_SERVER_URL=https://gitlab.com/ci
entrypoint: "bash"
secrets:
- GITLAB_REGISTRATION_TOKEN
command: |
-c '
set -e
printf "Setting configuration...\\n"
export REGISTRATION_TOKEN="$$(cat /run/secrets/GITLAB_REGISTRATION_TOKEN)"
sed -i "s/^concurrent = .*/concurrent = $${CONCURRENT}/" /etc/gitlab-runner/config.toml
printf "\\n"
printf "Registering runner...\\n"
gitlab-runner register --non-interactive
printf "\\n"
printf "List runners...\\n"
gitlab-runner list
printf "\\n"
printf "Running runner...\\n"
gitlab-runner run --user=gitlab-runner --working-directory=/home/gitlab-runner
'
volumes:
- /var/run/docker.sock:/var/run/docker.sock
deploy:
mode: global
placement:
constraints:
- node.role == manager
labels:
- "traefik.enable=false"
healthcheck:
test: ["CMD-SHELL", "gitlab-runner verify --name docker 2>&1 | grep --quiet \"is alive\""]
start_period: 10s
interval: 10s
timeout: 10s
retries: 10

# Gitlab Manager to unregister GitLab Runners
manager:
image: alpine:latest
environment:
- API_URL=https://gitlab.com/api/v4
- CI_SERVER_URL=https://gitlab.com/ci
secrets:
- GITLAB_PERSONAL_ACCESS_TOKEN
entrypoint: sh
command: |
-c '
set -e
printf "Installing dependencies...\\n"
apk --no-cache add curl jq
printf "\\n"
export PERSONAL_ACCESS_TOKEN="$$(cat /run/secrets/GITLAB_PERSONAL_ACCESS_TOKEN)"
while true; do
printf "Checking runners...\\n"
curl -sS --header "PRIVATE-TOKEN: $${PERSONAL_ACCESS_TOKEN}" "$${API_URL}/runners?per_page=100" | \
jq -c ".[] | select(false==.is_shared) | select(\"online\"==.status) | .id" | \
while read RUNNER_ID; do
printf "Runner $${RUNNER_ID} is online\\n"
done
curl -sS --header "PRIVATE-TOKEN: $${PERSONAL_ACCESS_TOKEN}" "$${API_URL}/runners?per_page=100" | \
jq -c ".[] | select(false==.is_shared) | select(\"online\"!=.status) | .id" | \
while read RUNNER_ID; do
printf "Deleting runner $${RUNNER_ID}...\\n"
curl -sS --request DELETE --header "PRIVATE-TOKEN: $${PERSONAL_ACCESS_TOKEN}" "$${API_URL}/runners/$${RUNNER_ID}"
done
printf "All offline runners deleted\\n"
printf "Waiting for 24 hours...\\n"
sleep 24h
done
printf "\\n"
'
deploy:
labels:
- "traefik.enable=false"
healthcheck:
test: ["CMD-SHELL", "command -v curl"]
start_period: 10s
interval: 10s
timeout: 10s
retries: 10

# Gitlab Runner Docker Cleanup - https://gitlab.com/gitlab-org/gitlab-runner-docker-cleanup
cleaner:
image: quay.io/gitlab/gitlab-runner-docker-cleanup
environment:
- CHECK_PATH=/data
- LOW_FREE_SPACE=10G
- EXPECTED_FREE_SPACE=20G
- LOW_FREE_FILES_COUNT=1048576
- EXPECTED_FREE_FILES_COUNT=2097152
- USE_DF=1
- CHECK_INTERVAL=10s
- RETRY_INTERVAL=30s
- DEFAULT_TTL=60m
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- cleaner_data:/data
deploy:
restart_policy:
condition: any
labels:
- "traefik.enable=false"

volumes:
cleaner_data:

Deploy stack này:

docker stack deploy -c swarm.yml runner

Xong rồi đó! Nếu không one hit lên luôn thì tự google nhé =)).

· Một phút để đọc
ManhPT

Vấn đề là...

Nếu bạn đã từng sử dụng git trên "cửa sổ dòng lệnh" (terminal) của windows, linux hay macOS, bạn sẽ thấy rằng mật khẩu git của chúng ta được lưu lại tự động. Sau đó, chúng ta chỉ cần fetch - push - pull bình thường. Không cần nhập lại username và password của git nữa.

Hơi tiếc là Ubuntu nói riêng và linux nói chung không có tính năng này. Dĩ nhiên chúng ta có thể cài đặt thêm phần mềm bên thứ 3 để có được tính năng tương tự. Mmình chưa thử và cũng ko tin tưởng để thử... lol.

Giải pháp

Sau đây là một thủ thuật nhỏ và cực kỳ đơn giản để bạn có thể quên đi việc bị hỏi username và password liên tục mỗi khi git fetch. Đó là sử dụng git credential storage chỉ với một câu lệnh duy nhất.

git config --global credential.helper store
  • store mode: chế độ này lưu thông tin đăng nhập của bạn dưới dạng plain-text mặc định trong file ~/.my-credentials. Bạn sẽ chỉ phải nhập lại mật khẩu khi bạn đã thay đổi mật khẩu trên git server. Cách này không được bảo mật cho lắm vì mật khẩu được lưu cứng dưới dạng không mã hoá. Do đó, ít nhất các bạn cũng nên sử dụng personal access token thay cho mật khẩu, ví dụ: github personal access token, gitlab personal access token... (lúc nào mà nhỡ có bị lộ thì revoke cái là xong).
git config --global credential.helper cache
git config --global credential.helper cache '--timeout 30000'
  • cache mode: chế độ này thì an toàn hơn do mật khẩu của bạn sẽ được lưu trong RAM thay vì file cứng và dĩ nhiên là có timeout - mặc định là 15 phút (900 giây). Bạn có thể tuỳ ý thay đổi thời gian timeout sao cho phù hợp với nhu cầu. Mình khuyến cáo nên sử dụng cách này.

Kết luận

Trong thực tế, việc sử dụng private key vẫn tối ưu và bảo mật hơn so với trực tiếp lưu trữ mật khẩu, nhưng việc setup không đơn giản như trên. Các đồng dâm tuỳ ý chọn lựa nhé.

· Một phút để đọc
ManhPT

Việc cài đặt gitlab-runner sử dụng docker được hướng dẫn khá đầy đủ tại tài liệu chính thống. Nhưng thực tế quá trình cài đặt và sử dụng thường không diễn ra suôn sẻ với mình lắm nên mình chắc nhiều bạn cũng gặp vấn đề giống mình. Bài viết này chủ yếu chỉ ra những điều cần chú ý khi bạn cài đặt và sau khi cài thành công mà pipeline có thể vẫn báo tình trạng stuck (job không thể kích hoạt bởi gitlab-runner).

Triển khai gitlab-runner

Để cài đặt gitlab-runner bạn chỉ cần 2 câu lệnh sau là đủ:

1. Cài đặt gitlab-runner

sudo docker run -d --name gitlab-runner --restart always \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
-v /var/run/docker.sock:/var/run/docker.sock \
gitlab/gitlab-runner:latest

2. Cấu hình gitlab-runner

sudo docker run --rm -t -i \
-v /srv/gitlab-runner/config:/etc/gitlab-runner \
gitlab/gitlab-runner register

Để điền thông tin cấu hình bạn chỉ cần theo sát hướng dẫn tại đây. Vậy là xong rồi!

Chú ý

  • Cài đặt xong rồi nhưng pipeline của tôi vẫn không được kích hoạt? - Rất có thể bạn cần cấu hình thêm một chút để Runners có thể kích hoạt các jobs không được tags, việc này có thể làm ngay trên giao diện web gitlab. (Link tham khảo)
  • Tôi cần build docker image trên CI nhưng khi chạy thì báo không tìm thấy docker? - Chắc là quên bật --privileged (link tham khảo).
  • Nếu bạn muốn sử dụng gitlab-runner cho docker swarm thì có thể tham khảo tại đây.

· Một phút để đọc
ManhPT

Bạn có bao giờ tự hỏi

  1. Git còn gì ngoài git commit, git pushgit pull? Thỉnh thoảng dùng thêm git merge, còn gì nữa không?
  2. git mergegit rebase khác gì nhau, nên dùng cái nào?
  3. Ở vị trí team leader bạn sẽ vận hành git ra sao để kết hợp với process của team (agile) và giải quyết các conflict trong quá trình code?
  4. Lịch sử git có giá trị như thế nào? Hay bạn chẳng bao giờ để ý đến nó?

Nếu bạn là 1 git command line master thì mọi thứ đều có thể được giải quyết dưới local bằng dòng lệnh. Nhưng khi làm việc trong một nhóm đông thành viên, làm thế nào để xử lý các vấn đề conflict code, release ra sao, thêm feature mới như thế nào, hotfix ra làm sao một cách trơn tru và hiệu quả, giảm thiểu tối đa các bước thủ công, tiến dần đến một git workflow tự động hoàn toàn (devops).

Luôn luôn tạo ra linear history

Git Workflow được giới thiệu sau đây luôn giữ một tư duy cực kỳ nhất quán về git history luôn luôn là linear history (có thể hiểu là history trên một đường thẳng). Nhìn trong hình đủ thấy linear history dễ hiểu hơn rất nhiều so với non-linear history, đủ dễ để nhìn vào graph là có thể thấy được thứ tự của các commit và sự khác nhau giữa các version được release.

Tham khảo

  1. http://www.bitsnbites.eu/a-tidy-linear-git-history/

git mergegit rebase đúng lúc đúng chỗ

Nguyên tắc tiên quyết

  1. Để update code mới nhất, không merge trên local, hãy dùng rebase
  2. merge tự động bằng merge (pull) request (cần cấu hình để khi merge sẽ sinh ra một empty commit nhằm đánh dấu vị trí merge)

Một ví dụ thực tế về linear history

· Một phút để đọc
ManhPT

Giới thiệu Gitlab và Gitlab Flow

Gitlab là một công cụ rất hay và có self-hosted (on-premise) plan cho phép bất cứ ai, công ty hay tổ chức nào cũng có thể cài đặt một Git Platform của riêng mình.

  • Một điểm cộng của Gitlab đó là tính năng Gitlab Board, giúp bạn tổ chức và sắp xếp các issue thành các board giống như Trello, khá tiện lợi cho việc quản lý theo quy trình (VD: Agile).
  • Gitlab còn cho phép bạn tạo các Merge Request (Pull Request, theo cách nói của Github) dựa trên các issue đã có, đồng thời tạo luôn cả source branch giúp bạn.
  • Bên cạnh đó, Gitlab cung cấp Gitlab CI cho phép bạn apply CI/CD vào bất cứ project nào. Với tôi thì đây là một tính năng không thể thiếu khi lựa chọn một công cụ devops.

Trước khi bắt đầu thực hành hoặc đọc tiếp, bạn nên tạo một repo trống để thử nghiệm.

Tại sao cần Gitlab Flow

Thực tế, gitlab flow hay git workflow không phải một khái niệm mới. Do git không hề dễ học cho người mới nên các workflow của nó thường bị bỏ qua, ngoài ra các nhà cung cấp công cụ devops cũng thường đưa ra những git workflow riêng để phù hợp với luồng devops trên công cụ của họ. Bạn có thể tham khảo thêm:

Bắt đầu tạo một issue

Vào Issues > List và chọn New issue. Hoặc bạn có thể chọn Import CSV để import list task có sẵn từ các nguồn khác như Jira, Redmine...

Click New issue như hình minh họa bên dưới.

Điền đầy đủ thông tin tùy theo yêu cầu từng team sau đó Submit issue.

Tạo merge request từ issue

Sau khi đã có issue, ta có thể tạo merge request từ issue đó rất nhanh chỉ cần click Create merge request.

Bạn có thể tạo bao nhiêu merge request tùy ý nhưng thường chỉ nên tạo 1 merge request cho mỗi 1 issue.

Branch đã được tạo sẵn

Sau khi tạo merge request thì Gitlab cũng tạo luôn branch cho bạn.

Sau đó chọn copy câu lệnh checkout mà Gitlab cung cấp sẵn, paste vào terminal/shell của bạn (sau khi đã clone repo) để bắt đầu code.

Đây là các step đơn giản đầu tiên để làm việc với Gitlab Flow. Mọi task như tạo feature mới, fix bug, refactor... đều cần được quy hoạch về step cơ bản này.