Use GitHub Action to automatically update the application image of the Sealos cluster

In the IT world, automation has undoubtedly become the key to increasing productivity and reducing human errors. As a powerful cloud operating system, Sealos has provided stable and reliable services to many enterprises and developers. At the same time, as technology continues to evolve, it becomes even more important to integrate more features and services. With that in mind, this article will look at how you can leverage GitHub Actions to further enrich Sealos’ automated experience with app updates.

Original link: https://forum.laf.run/d/1059

GitHub Action Introduction

Continuous integration (CI) and continuous deployment/delivery (CD) are crucial aspects of modern software development. They help development teams efficiently verify the quality of their code and ensure it is delivered to production accurately and without errors. GitHub Action is a CI/CD tool born out of this background and is committed to providing developers with a simple and efficient automation tool.

Simply put, GitHub Action is a CI/CD tool that allows developers to automate a variety of tasks in GitHub repositories, thereby greatly improving work efficiency. It automates critical steps such as building, testing, and deploying code, ensuring fast and accurate verification and delivery of every code update or merge request.

But GitHub Action is more than just a traditional CI/CD tool. What makes it unique is its seamless integration with GitHub repositories. This means that developers can configure and manage the entire automated process without leaving the GitHub environment, greatly simplifying the operation process. Additionally, since GitHub is currently the largest code hosting platform in the world, this deep integration makes it easy for a large number of developers to get started and automate using GitHub Actions.

Sealos: for both beginners and experts

Sealos’s visual desktop environment greatly simplifies users’ management and maintenance of distributed applications. Users no longer need to perform complex operations or have a deep technical background to easily manage distributed applications. By reducing complexity and providing an intuitive interface, Sealos significantly reduces the mental load on users, allowing them to focus more on their work.

Sealos overseas cluster: https://cloud.sealos.io

Sealos domestic cluster: https://cloud.sealos.top

But Sealos is not only suitable for ordinary users. For professionals in the cloud native field, it provides a terminal in which you can perform various command line operations.

It also provides a download function for kubeconfig files. With this file, professionals can download it to their local computer and use the kubectl command line tool to directly manage and operate application resources in Sealos. This provides great flexibility for cloud native experts who want to go deeper into management and configuration.

With kubeconfig, we can use it to implement various magical functions, such as the automatic update of application images that will be introduced in this article.

GitHub Action automatically build mirror

For self-developed applications, if you want to automatically update the application’s image, you must first automatically build the image.

GitHub Action is perfectly integrated on the GitHub platform, and you can build images based on source code without additional configuration or switching to other platforms. For public warehouses, GitHub provides a certain amount of free computing, which is suitable for small projects or individual developers.

The process of using GitHub Action to automatically build and push images is as follows:

  1. Create workflow file: Create a .github/workflows directory in your GitHub repository, and create a workflow configuration file in this directory, such as docker_build .yml.

  2. Configure Secret: In order to securely push images to Docker Hub and ghcr.io, you need to configure the corresponding authentication information in the “Secrets” section of the GitHub repository. Typically, this includes your Docker Hub username, password, and ghcr.io token. For example:

  3. Write workflow script: In the configuration file, define the required trigger conditions (such as push to master branch), running environment and execution Order.

    Example:

    # Define the name of the workflow
name: Build and Push Docker Image

# Define the conditions that trigger the workflow
on:
  workflow_dispatch: # Allow manual triggering of workflows
  push: # When a code push event occurs
    branches:
      - master # Only triggered when pushing to the master branch

# Define workflow tasks
jobs:
  build-image:
    # Define the environment to run this task: the latest version of ubuntu
    runs-on: ubuntu-latest

    # Define the steps in the task
    steps:
      # Check out the code. Only check out the latest 1 commit
      - uses: actions/checkout@v3
        with:
          fetch-depth: 1

      # Set up the QEMU emulator, which is typically used for multi-platform Docker builds
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v2

      # Set up Docker Buildx for building multi-platform Docker images
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      # Log in to Docker Hub
      - name: Login to DockerHub
        uses: docker/login-action@v2
        with:
          username: ${<!-- -->{ secrets.DOCKER_USERNAME }} # Use the DockerHub username stored in GitHub Secrets
          password: ${<!-- -->{ secrets.DOCKER_PASSWORD }} # Use the DockerHub password stored in GitHub Secrets

      # Log in to ghcr.io (GitHub Container Registry)
      - name: Login to ghcr.io
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${<!-- -->{ github.repository_owner }} # Use the owner name of the repository as the username
          password: ${<!-- -->{ secrets.GHCR_TOKEN }} # Use the access token for ghcr.io stored in GitHub Secrets

      # Build and push the Docker image to docker.io and ghcr.io
      - name: Build and push Docker images to docker.io and ghcr.io
        uses: docker/build-push-action@v2
        with:
          platforms: linux/amd64 # Set the build platform to linux/amd64
          context: . # Docker build context is set to the current directory
          push: true # Set to true to ensure that the built image is pushed
          tags: | # Define push tags
            ${<!-- -->{ secrets.DOCKER_USERNAME }}/xxxx:latest
            ghcr.io/${<!-- -->{ github.repository_owner }}/xxxx:latest

  4. Trigger workflow: Whenever an event that meets the trigger conditions occurs, GitHub Action automatically executes the defined workflow to build and push the Docker image.

  5. Monitoring and debugging: You can view the execution of the workflow, including logs, status and results, in the “Actions” tab of the GitHub repository.

Using GitHub Action to automatically build mirrors not only simplifies the development process, but also ensures that each code change is handled effectively and consistently, greatly improving development efficiency and code quality. At the same time, the security of authentication information is also ensured by using GitHub’s secrets function.

Auto-update Sealos application image

Now we come to the final step. To automatically update the image, first let’s review the entire process:

First, when your application code is updated and merged into the master branch, GitHub Action automatically triggers the task of building the image. After the build is completed, the new application image will be pushed to the image warehouse.

Next, you need to call kubectl in GitHub Action to update the corresponding Deployment or StatefulSet in the Sealos cluster. In this way, the applications in the Sealos cluster will be rolled out using the new image version.

We can leverage a specific GitHub Action: actions-hub/kubectl. This Action provides the ability to execute kubectl commands within a GitHub Actions workflow.

Here’s how to use actions-hub/kubectl in your GitHub Actions workflow to update the Sealos application image:

setting kubeconfig

In order for kubectl to communicate with your Sealos or other Kubernetes cluster, you need to provide a valid Kubeconfig. The Sealos kubeconfig can be downloaded from the desktop.

Once the download is complete, you need to convert its contents to base64 format:

$ cat kubeconfig.yaml | base64

The converted content is then stored in a Secret in the GitHub repository, assuming the Secret is named KUBE_CONFIG . Please refer to the above for Secret configuration method.

use actions-hub/kubectl

Now you only need to add a new job to call kubectl in the previous workflow script for automatically building the image. For example:

# Define the name of the workflow
name: Build and Push Docker Image

# Define the conditions that trigger the workflow
on:
  workflow_dispatch: # Allow manual triggering of workflows
  push: # When a code push event occurs
    branches:
      - master # Only triggered when pushing to the master branch

# Define workflow tasks
jobs:
  build-image:
  ...
  ...
  deploy:
    needs: build-image
    runs-on: ubuntu-latest
    if: github.repository == '<your_repository>'
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - uses: actions-hub/kubectl@master
        env:
          KUBE_CONFIG: ${<!-- -->{ secrets.KUBE_CONFIG }}
        with:
          args: rollout restart deployment my-deployment

In this example, we update a Deployment named my-deployment. The update method is very simple: direct rolling restart. Because the Deployment’s imagePullPolicy defaults to Always, and the image tag remains latest, a direct restart will pull the latest image.

If your image has a different tag each time it is built, you can use this command to update the image:

...
        with:
          args: set image deployment/my-deployment my-container=my-repo/my-image:<tag>

In this example, we update a Deployment named my-deployment and set the image of my-container to my-repo/my-image:< tag>. The tag can be obtained from the job of building the image in the form of environment variables.

If your application is not developed by yourself and the application has provided an image, then you can design a regularly triggered workflow. The task of the workflow is to detect whether the image in the image warehouse (such as Docker Hub) has been updated. If it has been updated, , call kubectl to update the image.