Интеграция Github Actions с KCL для GitOps

Введение​

В разделе GitOps мы представили, как интегрировать KCL с GitOps. В этом разделе мы продолжим предоставлять образцы решений для интеграции KCL и CI. Мы надеемся реализовать сквозной процесс разработки приложений, используя контейнеры, непрерывную интеграцию (CI) для генерации и GitOps для непрерывного развертывания (CD). В этой схеме мы используем приложение Flask и действия Github в качестве примеров.

Примечание. В этом решении можно использовать любое контейнерное приложение и различные системы непрерывной интеграции, такие как Gitlab CI, Jenkins CI и т. д.

Общий рабочий процесс выглядит следующим образом:

• Разработайте код приложения и отправьте его в репозиторий GitHub для запуска CI.
• Действия GitHub создают образы контейнеров из кода приложения и помещают их в реестр контейнеров docker.io.
• GitHub Actions автоматически синхронизирует и обновляет файл развертывания манифеста KCL на основе версии образа контейнера в реестре контейнеров docker.io.

Как ​

1. Получить пример ​

Мы помещаем исходный код приложения и код развертывания инфраструктуры в разные репозитории, которые могут поддерживаться разными ролями для достижения разделения задач.

• Получить код приложения

git clone https://github.com/kcl-lang/flask-demo.io.git/
cd flask-demo

Это веб-приложение, написанное на Python. Мы можем использовать Dockerfile в каталоге приложения для создания образа контейнера этого приложения, а также использовать Github CI для автоматического создания образа с именем flask_demo, конфигурация CI выглядит следующим образом.

# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2
      
      - name: Docker Login
        uses: docker/[email protected]
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          logout: true
      # Runs a set of commands using the runners shell
      - name: build image
        run: |
          make image
          docker tag flask_demo:latest ${{ secrets.DOCKER_USERNAME }}/flask_demo:${{ github.sha }}
          docker push ${{ secrets.DOCKER_USERNAME }}/flask_demo:${{ github.sha }}
      # Trigger KCL manifest
      - name: Trigger CI
        uses: InformaticsMatters/[email protected]
        with:
          ci-owner: kcl-lang
          ci-repository: flask-demo-kcl-manifests
          ci-ref: refs/heads/main
          ci-user: kcl-bot
          ci-user-token: ${{ secrets.DEPLOY_ACCESS_TOKEN }}
          ci-name: CI
          ci-inputs: >-
            image=${{ secrets.DOCKER_USERNAME }}/flask_demo
            sha-tag=${{ github.sha }}

Нам нужен рабочий процесс в репозитории исходного кода, чтобы автоматически запускать рабочий процесс в репозитории манифеста развертывания. На этом этапе нам нужно создать secrets.DEPLOY_ACCESS_TOKEN с разрешениями на операцию Github CI, а информацию об учетной записи Docker Hub push secrets.DOCKER_USERNAME и secrets.DOCKER_PASSWORD можно настроить в настройках Secrets and variables Github, как показано на следующем рисунке.

2. Зафиксируйте код приложения ​

После отправки в репозиторий flask-demo Github автоматически создаст образ контейнера и отправит его в концентратор Docker. Затем он также инициирует действие репозитория flask-demo-kcl-manifest и изменит значение изображения в репозитории манифеста развертывания через KCL Automation API. Теперь давайте создадим отправку в репозиторий flask-demo, и мы увидим, что отправка кода запускает процесс Github CI для репозитория приложений.

3. Автоматическое обновление конфигурации ​

После завершения процесса Github CI в репозитории приложений в репозитории, где хранится конфигурация KCL, будет запущено автоматическое обновление конфигурации CI, которое будет отправлено в основную ветвь репозитория flask-demo-kcl-manifests. Информация о коммите выглядит следующим образом

• Мы можем получить исходный код манифеста развертывания для компиляции и проверки.

git clone https://github.com/kcl-lang/flask-demo-kcl-manifests.git/
cd flask-demo-kcl-manifests
git checkout main && git pull && kcl

Выходной YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flask_demo
  labels:
    app: flask_demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: flask_demo
  template:
    metadata:
      labels:
        app: flask_demo
    spec:
      containers:
        - name: flask_demo
          image: "kcllang/flask_demo:6428cff4309afc8c1c40ad180bb9cfd82546be3e"
          ports:
            - protocol: TCP
              containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: flask_demo
  labels:
    app: flask_demo
spec:
  type: NodePort
  selector:
    app: flask_demo
  ports:
    - port: 5000
      protocol: TCP
      targetPort: 5000

Из приведенной выше конфигурации видно, что изображение ресурса действительно автоматически обновляется до нового созданного значения изображения. Кроме того, мы также можем использовать плагин Argo CD KCL для автоматической синхронизации данных из репозитория Git и развертывания приложения в кластере Kubernetes.

Резюме​

Интегрируя KCL и Github CI, мы можем автоматизировать модификацию и конфигурацию развертывания любого образа выходного контейнера приложения, чтобы обеспечить сквозной процесс разработки приложений и повысить эффективность развертывания исследований и разработок.