I'm setting up a GitHub action for deploying to Azure kubernetes. The deploy job looks as follows:
deploy:
name: Deploy to kubernetes
runs-on: ubuntu-latest
needs: docker
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Setup kubectl
uses: Azure/setup-kubectl@v3
- name: Setup cluster context
uses: Azure/k8s-set-context@v3
with:
method: kubeconfig
kubeconfig: ${{ secrets.AZURE_K8_KUBECONFIG }}
- name: Deploy to Azure
uses: Azure/k8s-deploy@v4
with:
manifests: manifests/test/manifest.yml
images: ghcr.io/${{ env.image_name }}:${{ needs.release-on-push.outputs.version }}
pull-images: false
annotate-namespace: false
When it gets to the deploy phase it runs through a manifest, which looks like this:
apiVersion: v1
kind: Service
metadata:
name: localizer
spec:
selector:
app: localizer
ports:
- name: std-api-ports
port: 8080
targetPort: http-in
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: localizer
labels:
app: localizer
annotations:
nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
nginx.ingress.kubernetes.io/proxy-body-size: "300M"
spec:
ingressClassName: nginx-default
rules:
- host: localizer.UUID.LOCATION.aksapp.io
http:
paths:
- backend:
service:
name: localizer
port:
name: std-api-ports
path: /
pathType: Prefix
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: localizer
labels:
app: localizer
domain: frontend
spec:
replicas: 2
selector:
matchLabels:
app: localizer
strategy:
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
template:
metadata:
labels:
app: localizer
spec:
containers:
- name: localizer
image: ghcr.io/urltorepo
resources:
requests:
cpu: 0.5
memory: 2G
limits:
memory: 2G
ports:
- name: http-in
containerPort: 8080
env:
- name: NODE_ENV
value: "test"
imagePullPolicy: Always
livenessProbe:
httpGet:
path: /ping
port: http-in
failureThreshold: 3
periodSeconds: 30
startupProbe:
httpGet:
path: /ping
port: http-in
failureThreshold: 12
periodSeconds: 10
The workflow then fails due to an error which is as follows:
Run Azure/k8s-deploy@v4
with:
manifests: manifests/test/manifest.yml
images: ghcr.io/***/localizer:
pull-images: false
annotate-namespace: false
namespace: default
strategy: basic
route-method: service
version-switch-buffer: 0
traffic-split-method: pod
percentage: 0
action: deploy
force: false
token: ***
private-cluster: false
skip-tls-verify: false
env:
image_name: ***/localizer
AZURE_WEBAPP_NAME: localizer-app
KUBECONFIG: /home/runner/work/_temp/kubeconfig_1682630327009
Deploying manifests
/opt/hostedtoolcache/kubectl/1.27.1/x64/kubectl apply -f /tmp/manifest.yml --namespace default
service/localizer unchanged
ingress.networking.k8s.io/localizer configured
error: error parsing /tmp/manifest.yml: error converting YAML to JSON: yaml: line 25: mapping values are not allowed in this context
Error: Error: undefined
From the console it would seem that the Service is setup and the Ingress is setup, which leads me to believe that the Deployment is the one with the error. I've run the manifest through a YAML validator and it passes. I've tried commenting out values from the manifest, hence the console showing that the Service is unchanged and Ingress is configured instead of created. I seem to be blind as to what the error could be now.
UPDATE: I've now tried to split the manifest file into three files(Deployment, Ingress and Service). This has allowed me to figure out that it definitely is the Deployment manifest that is causing the error. I've also found that the error is related to "image" element. I've tried to follow a course from Microsoft on Azure kubernetes and if I change out my image with the one in the example, then there isn't a problem.
After the action not working, then I decided to try to write the manifests directly in Azure through the Cloud Shell. The manifests worked as intended which resulted in the understanding that the problem is related to the Deploy action. Finally running the action with debugger activated, the problem finally exposed itself. The image wasn't receiving the version from an earlier job. This resulted in the image being displayed as "ghcr.io/*****/****:". This was then perceived as an object in the Deployment.yml