Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/Azure/k8s-deploy below:

Azure/k8s-deploy: GitHub Action for deploying to Kubernetes clusters

This action is used to deploy manifests to Kubernetes clusters. It requires that the cluster context be set earlier in the workflow by using either the Azure/aks-set-context action or the Azure/k8s-set-context action. It also requires Kubectl to be installed (you can use the Azure/setup-kubectl action).

If you are looking to automate your workflows to deploy to Azure Web Apps and Azure Web App for Containers, consider using Azure/webapps-deploy action.

This action requires the following permissions from your workflow:

permissions:
   id-token: write
   contents: read
   actions: read

Following are the key capabilities of this action:

• Artifact substitution: Takes a list of container images which can be specified along with their tags or digests. They are substituted into the non-templatized version of manifest files before applying to the cluster to ensure that the right version of the image is pulled by the cluster nodes.

• Object stability checks: Rollout status is checked for the Kubernetes objects deployed. This is done to incorporate stability checks while computing the action status as success/failure.

• Secret handling: The secret names specified as inputs in the action are used to augment the input manifest files with imagePullSecrets values before deploying to the cluster. Also, checkout the Azure/k8s-create-secret action for creation of generic or docker-registry secrets in the cluster.

• Deployment strategy Supports both canary and blue-green deployment strategies

  • Canary strategy: Workloads suffixed with '-baseline' and '-canary' are created. There are two methods of traffic splitting supported:

    • Service Mesh Interface: Service Mesh Interface abstraction allows for plug-and-play configuration with service mesh providers such as Linkerd and Istio. Meanwhile, this action takes away the hard work of mapping SMI's TrafficSplit objects to the stable, baseline and canary services during the lifecycle of the deployment strategy. Service mesh based canary deployments using this action are more accurate as service mesh providers enable granular percentage traffic split (via service registry and sidecar containers injected into pods alongside application containers).
    • Only Kubernetes (no service mesh): In the absence of service mesh, while it may not be possible to achieve exact percentage split at the request level, it is still possible to perform canary deployments by deploying -baseline and -canary workload variants next to the stable variant. The service routes requests to pods of all three workload variants as the selector-label constraints are met (KubernetesManifest will honor these when creating -baseline and -canary variants). This achieves the intended effect of routing only a portion of total requests to the canary.

  • Blue-Green strategy: Choosing blue-green strategy with this action leads to creation of workloads suffixed with '-green'. An identified service is one that is supplied as part of the input manifest(s) and targets a workload in the supplied manifest(s). There are three route-methods supported in the action:

    • Service route-method: Identified services are configured to target the green deployments.
    • Ingress route-method: Along with deployments, new services are created with '-green' suffix (for identified services), and the ingresses are in turn updated to target the new services.
    • SMI route-method: A new TrafficSplit object is created for each identified service. The TrafficSplit object is updated to target the new deployments. This works only if SMI is set up in the cluster.

    Traffic is routed to the new workloads only after the time provided as version-switch-buffer input has passed. The promote action creates workloads and services with new configurations but without any suffix. reject routes traffic back to the old workloads and deletes the '-green' workloads.

(Required)

(Required)

(Required)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional but required if strategy is canary)

For example, if Deployment hello-world was found in the input manifest file with 'replicas: 4' and if 'strategy: canary' and 'percentage: 25' are given as inputs to the action, then the Deployments hello-world-baseline and hello-world-canary are created with 1 replica each. The '-baseline' variant is created with the same image and tag as the stable version (4 replica variant prior to deployment) while the '-canary' variant is created with the image and tag corresponding to the new changes being deployed

(Optional and relevant only if strategy is canary and traffic-split-method is smi)

    strategy: canary
    trafficSplitMethod: smi
    percentage: 20
    baselineAndCanaryReplicas: 1

In this case, stable variant will receive 80% traffic while baseline and canary variants will receive 10% each (20% split equally between baseline and canary). However, instead of creating baseline and canary with 3 replicas each, the explicit count of baseline and canary replicas is honored. That is, only 1 replica each is created for baseline and canary variants.

(Optional and relevant only if strategy is blue-green)

(Optional and relevant only if strategy is blue-green)

(Optional and relevant only using K8's deploy for a cluster with private cluster enabled)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

(Optional)

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     manifests: |
        dir/manifestsDirectory
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2

- uses: Azure/k8s-deploy@v5
  with:
     resource-group: yourResourceGroup
     name: yourClusterName
     action: deploy
     strategy: basic

     private-cluster: true
     manifests: |
        manifests/azure-vote-backend-deployment.yaml
        manifests/azure-vote-backend-service.yaml
        manifests/azure-vote-frontend-deployment.yaml
        manifests/azure-vote-frontend-service.yaml
     images: |
        registry.azurecr.io/containername

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        dir/manifestsDirectory
     strategy: canary
     action: deploy
     percentage: 20

To promote/reject the canary created by the above snippet, the following YAML snippet could be used:

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        dir/manifestsDirectory
     strategy: canary
     action: promote # substitute reject if you want to reject

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        dir/manifestsDirectory
     strategy: canary
     action: deploy
     traffic-split-method: smi
     percentage: 20
     baseline-and-canary-replicas: 1

To promote/reject the canary created by the above snippet, the following YAML snippet could be used:

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }} '
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        dir/manifestsDirectory
     strategy: canary
     traffic-split-method: smi
     action: reject # substitute promote if you want to promote

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        ingress.yml
     strategy: blue-green
     action: deploy
     route-method: ingress # substitute with service/smi as per need
     version-switch-buffer: 15

To promote/reject the green workload created by the above snippet, the following YAML snippet could be used:

- uses: Azure/k8s-deploy@v5
  with:
     namespace: 'myapp'
     images: 'contoso.azurecr.io/myapp:${{ event.run_id }}'
     imagepullsecrets: |
        image-pull-secret1
        image-pull-secret2
     manifests: |
        deployment.yaml
        service.yaml
        ingress.yml
     strategy: blue-green
     route-method: ingress # should be the same as the value when action was deploy
     action: promote # substitute reject if you want to reject

Following are a few examples of not just this action, but how this action could be used along with other container and k8s related actions for building images and deploying objects onto k8s clusters:

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@v4

         - uses: Azure/docker-login@v1
           with:
              login-server: contoso.azurecr.io
              username: ${{ secrets.REGISTRY_USERNAME }}
              password: ${{ secrets.REGISTRY_PASSWORD }}

         - run: |
              docker build . -t contoso.azurecr.io/k8sdemo:${{ github.sha }}
              docker push contoso.azurecr.io/k8sdemo:${{ github.sha }}

         - uses: azure/setup-kubectl@v4

         # Set the target AKS cluster.
         - uses: Azure/aks-set-context@v4
           with:
              creds: '${{ secrets.AZURE_CREDENTIALS }}'
              cluster-name: contoso
              resource-group: contoso-rg

         - uses: Azure/k8s-create-secret@v4
           with:
              container-registry-url: contoso.azurecr.io
              container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
              container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
              secret-name: demo-k8s-secret

         - uses: Azure/k8s-deploy@v5
           with:
              action: deploy
              manifests: |
                 manifests/deployment.yml
                 manifests/service.yml
              images: |
                 demo.azurecr.io/k8sdemo:${{ github.sha }}
              imagepullsecrets: |
                 demo-k8s-secret

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@v4

         - uses: Azure/docker-login@v1
           with:
              login-server: contoso.azurecr.io
              username: ${{ secrets.REGISTRY_USERNAME }}
              password: ${{ secrets.REGISTRY_PASSWORD }}

         - run: |
              docker build . -t contoso.azurecr.io/k8sdemo:${{ github.sha }}
              docker push contoso.azurecr.io/k8sdemo:${{ github.sha }}

         - uses: azure/setup-kubectl@v4

         - uses: Azure/k8s-set-context@v4
           with:
              kubeconfig: ${{ secrets.KUBE_CONFIG }}

         - uses: Azure/k8s-create-secret@v4
           with:
              container-registry-url: contoso.azurecr.io
              container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
              container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
              secret-name: demo-k8s-secret

         - uses: Azure/k8s-deploy@v4
           with:
              action: deploy
              manifests: |
                 manifests/deployment.yml
                 manifests/service.yml
              images: |
                 demo.azurecr.io/k8sdemo:${{ github.sha }}
              imagepullsecrets: |
                 demo-k8s-secret

We can use this image in other workflows once built.

on: [push]
env:
   NAMESPACE: demo-ns2

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@v4

         - uses: Azure/docker-login@v1
           with:
              login-server: contoso.azurecr.io
              username: ${{ secrets.REGISTRY_USERNAME }}
              password: ${{ secrets.REGISTRY_PASSWORD }}

         - run: |
              docker build . -t contoso.azurecr.io/k8sdemo:${{ github.sha }} --label dockerfile-path=https://github.com/${{github.repo}}/blob/${{github.sha}}/Dockerfile
              docker push contoso.azurecr.io/k8sdemo:${{ github.sha }}

on: [push]
env:
   NAMESPACE: demo-ns2

jobs:
   deploy:
      runs-on: ubuntu-latest
      steps:
         - uses: actions/checkout@master

         - uses: Azure/docker-login@v1
           with:
              login-server: contoso.azurecr.io
              username: ${{ secrets.REGISTRY_USERNAME }}
              password: ${{ secrets.REGISTRY_PASSWORD }}

         - uses: azure/setup-kubectl@v4

         # Set the target AKS cluster.
         - uses: Azure/aks-set-context@v4
           with:
              creds: '${{ secrets.AZURE_CREDENTIALS }}'
              cluster-name: contoso
              resource-group: contoso-rg

         - uses: Azure/k8s-create-secret@v4
           with:
              namespace: ${{ env.NAMESPACE  }}
              container-registry-url: contoso.azurecr.io
              container-registry-username: ${{ secrets.REGISTRY_USERNAME }}
              container-registry-password: ${{ secrets.REGISTRY_PASSWORD }}
              secret-name: demo-k8s-secret

         - uses: azure/k8s-bake@v3
           with:
              renderEngine: 'helm'
              helmChart: './aks-helloworld/'
              overrideFiles: './aks-helloworld/values-override.yaml'
              overrides: |
                 replicas:2
              helm-version: 'latest'
           id: bake

         - uses: Azure/k8s-deploy@v5
           with:
              action: deploy
              manifests: ${{ steps.bake.outputs.manifestsBundle }}
              images: |
                 contoso.azurecr.io/k8sdemo:${{ github.sha }}
              imagepullsecrets: |
                 demo-k8s-secret

• Environment variable HELM_CHART_PATHS is a list of helmchart files expected by k8s-deploy - it will be populated automatically if you are using k8s-bake to generate the manifests.
• Use script to build image and add dockerfile-path label to it. The value expected is the link to the dockerfile: https://github.com/${{github.repo}}/blob/${{github.sha}}/Dockerfile. If your dockerfile is in the same repo and branch where the workflow is run, it can be a relative path and it will be converted to a link for traceability.
• Run docker login action for each image registry - in case image build and image deploy are two distinct jobs in the same or separate workflows.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

k8s-deploy is an open source project that is not covered by the Microsoft Azure support policy. Please search open issues here, and if your issue isn't already represented please open a new one. The project maintainers will respond to the best of their abilities.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4