CI/CD on Jenny blog

在 Argo CD 中使用 Github App Credential 作為驗證方式

Tue, 10 Jan 2023 16:05:56 +0800

在 Argo CD 中使用 Github App Credential 作為驗證方式

前言

在先前文章使用 Docker Desktop 運行 Argo CD 以及在 Argo CD 內建立 App 偵測 repository 狀態有提到 private repository 驗證的方式有 SSH、Https 以及 Github App Credential

此文章來筆記下，如何在 Argo CD 中使用 Github App Credential 作為驗證方式

實作

建立 Github App
- 步驟可參考 👉 官方文件
- 其中，特別需要設定的值
  - Github App Name: 為你的 Github App 取名稱
  - Homepage URL: 你的 web app URL
    - 我的 argo cd 是以 docker desktop 啟動，並利用 port forward 方式，讓本地利用 localhost 可連線 dashboard，可參考我的文章使用 Docker Desktop 運行 Argo CD
  - Callback URL: 當 github 認證完畢後，要 redirect 回去的 URL
建立完成 Github App 後，還有兩件事情要做，Argo CD 設定連線時會用到
- 查看 Github App Installation ID
- 看 URL https://github.com/settings/installations/{Your Github App Installation ID}, 可確認 Github App Installation ID
建立 private key
- 到 Settings / Developer settings / Github Apps / {your-github-app-name} 的 General
- 將頁面往下拉可以看見 Private keys，點 Generate a private key 建立一組 private key
到 Argo CD 的 Repositories 設定連線資訊
- 如何到這頁來設定，可參考官方文件
- 這邊要填寫與設定的資訊分成兩部分
  1. 先選到 VIA GITHUB APP
  2. 依照上面的訊息完成填寫框 2的內容
  3. 點 CONNECT，完成
連線成功
建立一組 NEW APP

心得

看到官方提供驗證 private repository 的方式有 Github App Credential，讓我相當好奇，於是就有了這篇文章。
後續再寫一篇文章來記錄 Github App 與 OAuth App差異。

參考資料 👐

🍀 「記錄」是為了有意識地、有條理地統整所學的學習知識。
🍀 最後，若喜歡我的分享，可以免費幫我按讚，是對我最大的鼓勵! ✨ ✨ ✨

Argo CD 是什麼?

Thu, 05 Jan 2023 10:56:11 +0800

Argo CD 是什麼?

Argo CD是一個用於持續交付（Continuous Delivery）的工具，用於自動化應用程序的部署、更新和操作。
它是基於Kubernetes的開源項目，旨在幫助團隊更有效地管理和交付應用程序。

Argo CD允許開發人員和運維團隊使用 GitOps 模型來管理基礎設施和應用程序的狀態。

GitOps是一種軟體開發實踐，它將Git作為單一可信源來管理應用程序的狀態和配置。

透過將應用程序的狀態描述為Git存儲庫中的一組聲明，Argo CD可以根據這些聲明自動驅動應用程序的部署和更新。

前言

這部分會分享 Argo CD 的中心思想、架構與功能。

中心思想 GitOps pattern

Argo CD 遵循 GitOps 模式，即以 Git repositories 作為唯一識別 application 狀態的來源

Argo CD 作為 kubernetes controller

Argo CD 作為 kubernetes controller，持續偵測運行中的 application，並比較現在狀態與目標狀態！
可用以下幾種方式建立 Argo CD 的 kubernetes manifest
- kustomize applications
- helm charts
- jsonnet files
- Plain directory of YAML/json manifests
- Any custom config management tool configured as a config management plugin

Argo CD architecture

架構圖

有哪些 Components？

API Server
- 可以被 Web UI, CLI, 以及 CI/CD systems 介接的 gRPC/REST server
- 它有幾項責任
  - 應用管理與狀態回報
  - 處理 application 的操作，如 sync, rollback, 其他使用者定義的動作
  - 管理 credential，如 K8s secrets
  - 管理驗證與權限
  - 執行 RBAC
  - Git webhook 事件的傾聽者/傳送者
Repository Server
- 管理本地 Git repository 的快取 (Cache)
- 當有新增以下參數，需建立 Kubernetes manifests
  - repository URL
  - revision (commit, tag, branch)
  - application path
  - template specific settings: parameters, helm values.yaml
Application Controller
- 屬於 Kubernetes controller
  - 更多關於 Kubernetes controller
- 持續偵測運行中的 application，並比較現在狀態與目標狀態，若偵測到 OutOfSync 則會選擇性採取正確動作
- 此元件負責為生命週期事件(PreSync, Sync, PostSync)去調用使用者定義的 hooks

Features

根據提供的功能，可以將其分為以下幾項：

部署和管理功能：

自動部署應用程序到指定的目標環境
支持多個配置管理/模板工具（Kustomize、Helm、Jsonnet、純YAML）
能夠管理和部署到多個集群

身份驗證和安全功能：

SSO集成（OIDC、OAuth2、LDAP、SAML 2.0、GitHub、GitLab、Microsoft、LinkedIn）
多租戶和RBAC策略用於授權

回滾和配置管理功能：

回滾/任意回滾到Git存儲庫中提交的任何應用程序配置
應用程序資源的健康狀態分析
自動配置漂移檢測和可視化
自動或手動將應用程序同步到所需狀態

用戶界面和集成功能：

提供實時應用程序活動的Web UI
命令行界面（CLI）用於自動化和CI集成
Webhook集成（GitHub、BitBucket、GitLab）
用於自動化的訪問令牌(Access token)

應用程序升級和監控功能：

支持 PreSync、Sync、PostSync 鉤子以支持複雜的應用程序升級（例如藍/綠和金絲雀升級）
應用程序事件和API調用的軌跡
Prometheus metrics
可覆蓋 Helm 參數的參數覆蓋

支援的功能繁多，列出一部分。每一版或者會有些不同，建議可參考官方文件

這些功能可幫助團隊實現自動化部署、安全驗證、配置管理、回滾、監控等在持續交付環境中必要的任務。

心得

Argo CD 在 March 26, 2020 被 CNCF 列入，CNCF 的專案們整合程度越來越高，相信未來的多數公司的 CICD、監控、Log、角色權限控管、資料庫等會以 CNCF 專案為主。
若想知道如何在 docker desktop 建立 Argo CD，請參考文章【使用 Docker Desktop 運行 Argo CD】

參考資料

最後，若喜歡我的分享，可以免費幫我按讚，是對我最大的鼓勵!

使用 Docker Desktop 運行 Argo CD 以及在 Argo CD 內建立 App 偵測 repository 狀態

Wed, 04 Jan 2023 04:39:13 +0000

Prerequisites

開始前，需要先確保有以下的先備知識

kubernetes

Argo CD 介紹

以 GitOps 模式為宗旨的持續部屬 (continuous delivery) 工具
- 關於 GitOps 可以參考文章 GitOps

Getting Started with Argo CD on Docker Desktop

讓我們一步一步開始吧! 💪

建立 namespace

kubectl create namespace argocd

安裝 Argo CD 的 kubernetes resources

需要安裝的 resources 都寫在 install.yaml 內，利用 kubectl apply 指令進行安裝

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

確認 Argo CD 的 pod 的運行狀態為 running

-n 表示指定 namespace 為 argocd，沒設定就是 default namespace
```
kubectl get pod -n argocd
```
pod 運行狀態

取得 Argo CD 初始 admin 的密碼

登入 dashboard 使用

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

將 service argocd-server port forward 到本地

將 service argocd-server 的 port 443 導至本地 port 8000
```
kubectl port-forward svc/argocd-server -n argocd 8000:443
```
port forward 成功

登入 Argo CD dashboard

網址輸入 https://localhost:8000
成功登入 Argo CD dashboard

針對 public git repository 建立一組 application

先 fork 範例 repository - argocd-example-apps
依照官方文件指示步驟進行新增 application
- Step 1
- Step 2，填完資訊，按下 CREATE，能在 dashboard 看到 application
  - app name: guestbook
  - project: default
  - sync policy: Manual
  - Repository URL
  - Revision: HEAD
  - Path: guestbook
  - Destination/Cluster: https://kubernetes.default.svc
  - Namespace: default

針對 private git repository 建立一組 application

選一組 private repo
到 Settings/Repositories
以 ssh-key 方式認證，也能選擇以 Https或者 Github App 的方式驗證
- 可參考Argo CD Private Repositories Credential 設定
- 可參考我的文章使用 Github App Credential 認證
設定完成會顯示 Successful
建立 application
- Step 1
- Step 2
  - 依照官方文件指示步驟填入資料
成功建立一組 private application 🚀

解除安裝 application

執行 DELETE 按鈕

解除安裝 Argo CD

⚠️ 解除安裝 Argo CD 前一定要先解除安裝 application

kubectl -n argocd delete -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

遇過的問題

參考資料

🍀 最後，若喜歡我的分享，可以免費幫我按讚，是對我最大的鼓勵! ✨ ✨ ✨

如何使用 Github Workflow 完成 CI/CD

Sat, 10 Dec 2022 18:33:05 +0800

Github Workflow 介紹

前言

為了利用 Github Workflow 完成 CI/CD，分成幾個部分來寫，分別是

Github Workflow 的基本設定
Github Workflow 中進行 CI
登入登出 AWS ECR 與 github container registry
build & upload image
更新 helm value 中的 image tag，後續讓 argocd 得以偵測到 helm values 的變化後，進行自動化部屬

基本設定

action 為 push 的時候，所有 branch 都會進行 github workflow
action 為 pull_request 的時候，只有 main branch 會進行 github workflow
types
paths

on:
  push:
    branches: ["*"]
  pull_request:
    branches: ["main"]
    types:
      - opened
    paths:
      - "**.js"

env 設定

設定方式如下，可以依照自身需求進行設定

env:
  AWS_DEFAULT_REGION: ap-southeast-1
  GIT_USER_NAME: jennyc

permissions 設定

設定方式如下，可以依照自身需求進行設定

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout

自動化測試 CI

checkout repository

使用 actions/checkout@v3 進行

- name: Checkout repository
  uses: actions/checkout@v3

執行 npm install

- name: Install dependencies
  run: npm install

執行 npm test

- name: Run tests
  run: npm run test

Build multi-platform images 並上傳至 AWS ECR

前言

這部分需要先設定 AWS Credential 才能使用 AWS ECR，
接著 build multi-platform image 並且上傳至 AWS ECR。

1. 設定 AWS Credential

設定 AWS Credential
- 使用 GitHub’s OIDC provider 方式取得 short-lived credentials
  - OpenID Connect (OIDC) 設定方式可以參考官方文件
  - 也可以參考這篇文章
- workflow 要怎麼寫?
  - env.AWS_DEFAULT_REGION 需要特別設定，與 AWS ECR 相同的 region
  - role-to-assume 填入 AWS role
  - role-session-name 預設是 GitHubActions，可以自行調整名稱
```
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v1
    with:
        role-to-assume: arn:aws:iam::1234567890:role/example-role
        role-session-name: GitHubActionsWithAwsEcrUsingOIDCSession 
        aws-region: ${{env.AWS_DEFAULT_REGION}}
```

2. 登入 AWS private ECR

有兩種方式

Using access key id and secret access key to login

  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v1
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: ap-southeast-1

Using OpenID Connect (OIDC) to login

官方推薦使用此方式

  - name: Login to Amazon ECR
    id: login-ecr
    uses: aws-actions/amazon-ecr-login@v1

3. 登入 AWS public ECR

可參考官方說明

4. 登出 AWS ECR

- name: Logout of Amazon ECR
  if: always()
  run: docker logout ${{ steps.login-ecr.outputs.registry }}

5. 設定 short sha 為 image tag

設定以 7 digits 長度的 short sha 作為 image tag，原因可以參考:
- 7 digits are the Git default for a short SHA
- 附上其他參考文件 Chapter 7 of the Pro Git book
將 output 出去的參數命名為 sha_short

      - name: Set short sha outputs
        id: vars
        run: echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT

6. Build multi-platform images 並上傳 images 到 AWS ECR

建立多平台 docker images 的官方文件
IMAGE_TAG 會從步驟 5 取得 output 的變數 sha_short
--platform 可接上需要的 platform 參考，例如 linux/amd64, linux/arm64

  - name: Build, tag, and push docker image to Amazon ECR
    env:
        REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        REPOSITORY: pet-app
        IMAGE_TAG: ${{ steps.vars.outputs.sha_short }}
    run: |
        docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
        ( 官方建議: docker run --privileged --rm tonistiigi/binfmt --install all )
        docker buildx create --name mybuilder --driver docker-container --bootstrap
        docker buildx use mybuilder
        docker buildx inspect
        docker buildx build --platform linux/amd64,linux/arm64 -t $REGISTRY/$REPOSITORY:$IMAGE_TAG --push .

為什麼需要 docker run --rm --privileged multiarch/qemu-user-static --reset -p yes ?
- 因為遇到 Error: while loading /usr/local/sbin/node: No such file or directory 問題
  - 先使用方式一 : 連接方式，結果還是有相同問題
```
  ln -s /usr/bin/node /usr/local/sbin/node
```
  - 後來使用方式二
    - 使用 docker buildx 指令前先執行以下命令
```
  docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
```
    - 詳細原因的 Stack Overflow 原始文章在這邊，以下是節錄部分
      
      ` When you ask the Linux kernel to run some executable file, it needs to know, how to load this specific file, and whether this file is compatible with current machine, or not. By default, the ELF binary compiled for, say, arm64v8 is rejected by the kernel, running on amd64 hardware.
      
      However, the binfmt_misc feature of the kernel allows you to tell it, how to handle the executables it cannot usually handle on its own - this includes the cases when the kernel does not know the binary format or considers it incompatible with current machine.
      `
    - github issue
官方建議使用以下命令解決 QEMU binaries 問題，官方文件
```
  docker run --privileged --rm tonistiigi/binfmt --install all
```

更新 helm value 的 image tag

前言

應用是以 terraform 方式部屬，並搭配使用 helm charts。而 docker image 的 tag 是寫在 helm values 內。
目標是更新 helm values 的 docker image tag 值，後續讓 argocd 得以偵測到 helm values 的變化後，進行自動化部屬。

需做到兩件事情:

checkout 私有 repository
設定與更新 image tag

1. 先 checkout 私有存放 helm value 的 repository

需要先設定 credential 才能 fetch private repository，有兩種設定的方式

設定 deploy key
- 步驟如下，可參考這篇
  1. Create a new SSH key pair for your repository. Do not set a passphrase.
  2. Copy the contents of the public key (.pub file) to a new repository deploy key and check the box to “Allow write access.”
  3. Add a secret to the repository containing the entire contents of the private key.
  4. As shown in the example below, configure actions/checkout to use the deploy key you have created.
- workflow 要怎麼寫?
  - ssh-key 填入 private key 的 secrets 名稱
  - path 設定 checkout 的 repo 會存在哪一個資料夾內
```
  - name: Checkout ${{env.TERRAFORM_REPOSITORY_NAME}} repo and push file to ${{env.TERRAFORM_REPOSITORY_NAME}}
    uses: actions/checkout@v3
    with:
      repository: ${{env.TERRAFORM_REPOSITORY_OWNER_NAME}}/${{env.TERRAFORM_REPOSITORY_NAME}}
      ssh-key: ${{ secrets.SSH_PRIVATE_KEY }}
      path: ${{env.TERRAFORM_REPOSITORY_NAME}}
```
設定 Personal access token (PAT)
- 建立 PAT 的方式，官方文件
- 將建立完成的 PAT 設定到 repository 的 secrets 中，設定的 secrets 名稱為 GH_PAT，官方文件
- workflow 要怎麼寫?
  - repository 設定為 owner/repository_name
  - token 填入 PAT 的 secrets 名稱，這邊是將 secrets 名稱為 GH_PAT 的內容設定為 PAT
```
- name: Checkout ${{env.TERRAFORM_REPOSITORY_NAME}} repo and push file to ${{env.TERRAFORM_REPOSITORY_NAME}}
    uses: actions/checkout@v3
    with:
        repository: ${{env.TERRAFORM_REPOSITORY_OWNER_NAME}}/${{env.TERRAFORM_REPOSITORY_NAME}}
        token: ${{ secrets.GH_PAT }}
```

2. 設定 image tag

設定以 7 digits 長度的 short sha 作為 image tag
- 7 digits are the Git default for a short SHA
- 附上其他參考文件 Chapter 7 of the Pro Git book

      - name: Set short sha outputs
        id: vars
        run: echo "sha_short=$(git rev-parse --short HEAD)" >> $GITHUB_OUTPUT

3. 更新 image tag

以 yq 的 github action 工具修改 yaml 檔內的 image tag 值
- yq 的官方文件
- yq 的 github
進行 git 操作，設定 user name, user email、commit 以及 push
tag 取上一個步驟 output 的參數 sha_short

      - name: Update image tag
        uses: mikefarah/yq@master
        with:
          cmd: yq -i '.pet_app_dashboard_site.image.tag = "${{ steps.vars.outputs.sha_short }}"' ./${{env.TERRAFORM_REPOSITORY_NAME}}/${{env.HELM_FILE_NAME}}
      - run: |
          cd ${{env.TERRAFORM_REPOSITORY_NAME}}
          git config user.name ${{env.GIT_USER_NAME}}
          git config user.email ${{env.GIT_USER_EMAIL}}
          git add ${{env.HELM_FILE_NAME}}
          git commit -m "update image tag to ${{ steps.vars.outputs.sha_short }}"
          git push origin main

若要將 docker image 上傳至 github container registry 該怎麼做?

1. 登入與登出 github container registry

需要設定 env.REGISTRY 為 ghcr.io

不需要另外設定 github.actor 與 GITHUB_TOKEN

    - name: Login to GitHub Container Registry
      uses: docker/login-action@v2
      with:
      registry: ${{ env.REGISTRY }}
      username: ${{ github.actor }}
      password: ${{ secrets.GITHUB_TOKEN }}

2. Extract metadata

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

3. Build and push docker image

labels 的值可以從步驟二取出 outputs labels 來使用

      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.REPO }}:${{ steps.vars.outputs.sha_short }}
          labels: ${{ steps.meta.outputs.labels }}

參考資料

最後，若喜歡我的分享，可以免費幫我按讚，是對我最大的鼓勵!