Kubernetes Manifest Components

Introduction

With the help of Kubernetes Manifest Components, you can deploy raw Kubernetes Manifests in Bunnyshell.

Kubernetes Manifest components are defined and edited only from the env.yaml file. Bunnyshell allows you to declare a set of bash commands to be ran when deploying, starting, stopping, or deleting the component.

Bunnyshell will not build the images for these components automatically, so you will need to add a Docker Image Component, or use one of your own images. See Docker Image Components for more details.

Example

Let's start by looking at an example.

-
    kind: KubernetesManifest
    version: v1
    name: my-app
    runnerImage: 'alpine/k8s:1.22.15'
    deploy:
        - 'kustomize create --autodetect --recursive --labels=app.kubernetes.io/instance-my-app:bns,app.kubernetes.io/part-of:env-{{ env.unique }} --namespace {{ env.k8s.namespace }}'
        - 'kustomize edit set image nginx={{ components.my-app-image.image }}'
        - |
            kustomize edit add patch --kind Deployment --name my-app --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/env/-", "value": {"name": "ENV", "value": "bunnyshell"}}]'
        - 'sed -i "s/my-app.mydomain.com/my-app-{{ env.base_domain }}/g" ingress.yaml'
        - 'kubectl apply -k .'
        - SERVICE_ENDPOINT="https://my-app-{{ env.base_domain }}/api"
    destroy:
        - 'kustomize create --autodetect --recursive --namespace {{ env.k8s.namespace }}'
        - 'kubectl delete -k .'
    start:
        - 'kubectl scale --replicas=2 --namespace {{ env.k8s.namespace }} deployment/my-app'
    stop:
        - 'kubectl scale --replicas=0 --namespace {{ env.k8s.namespace }} deployment/my-app'
    exportVariables:
        - SERVICE_ENDPOINT
    gitRepo: 'https://gitlab.com/example/my-app.git'
    gitBranch: master
    gitApplicationPath: /

Component attributes

gitRepo

The URL of the Git repository where the Kubernetes Manifest is located.

gitBranch

The branch where the Kubernetes Manifest is located. This attribute is relative to the gitRepo.

gitApplicationPath

The path to the application folder, relative to the branch.

runnerImage

This is where you specify the image where Bunnyshell runs the commands given in the deploy / destroy / start / stop attributes. It can be the actual image of the component, or any other image.

Commands

In the deploy, start, stop and delete properties you can add any type of commands.

Steps for the deploy property are mandatory. The other properties can be left blank.

• The deploy and start commands always run sequentially, in the order in which components are defined in env.yaml. This is important, because we can extract one of the component’s environment variables to use it later on in a different component.

• The stop and destroy commands run in parallel between components.

Below is a snippet that includes all the four properties mentioned earlier.

    deploy:
        - 'kustomize create --autodetect --recursive --labels=app.kubernetes.io/instance-my-app:bns,app.kubernetes.io/part-of:env-{{ env.unique }} --namespace {{ env.k8s.namespace }}'
        - 'kustomize edit set image nginx={{ components.my-app-image.image }}'
        - |
            kustomize edit add patch --kind Deployment --name my-app --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/env/-", "value": {"name": "ENV", "value": "bunnyshell"}}]'
        - 'sed -i "s/my-app.mydomain.com/my-app-{{ env.base_domain }}/g" ingress.yaml'
        - 'kubectl apply -k .'
        - SERVICE_ENDPOINT="https://my-app-{{ env.base_domain }}/api"
    destroy:
        - 'kustomize create --autodetect --recursive --namespace {{ env.k8s.namespace }}'
        - 'kubectl delete -k .'
    start:
        - 'kubectl scale --replicas=2 --namespace {{ env.k8s.namespace }} deployment/my-app'
    stop:
        - 'kubectl scale --replicas=0 --namespace {{ env.k8s.namespace }} deployment/my-app'

Displaying Components' resources in the UI

In order for Bunnyshell to be able to discover your Kubernetes resources, they need to have the labels listed below set on them. Make sure you replace the COMPONENT NAME section with the actual name of your component.

- app.kubernetes.io/part-of = env-{{ env.unique }}
- app.kubernetes.io/instance-<COMPONENT NAME> = bns

Exposing hosts

If you are using Ingress resources to expose your services from your components, you need to update the (fixed) hosts on these Ingress resources to the (dynamic) values of this pattern. Replace SERVICE with a name of your choosing, and feel free to use any replacement method you prefer, sed is just an example to get you started.

'sed -i "s/web-self-dev-test.mydomain.com/[SERVICE]-{{ env.base_domain }}/g" ingress.yaml'

Value Interpolation for Docker Images

If you are using Bunnyshell to build your images using Docker Image, you can use value interpolation as exemplified below. NAME represents the component name of your Docker Image Component. Bunnyshell will replace it with the built image.

• {{ components.NAME.image }}: contains full image name, including the tag. Example: nginx:latest

• {{ components.dev_test_image.imageName }}: contains only the image name. Example: nginx

• {{ components.dev_test_image.imageTag }}: contains only the image tag. Example: latest

Injecting Bunnyshell Variables in your resources

If you need to inject Bunnyshell environment variables in your resources, please refer to the Value Interpolation page.

 - |
    kustomize edit add patch --kind Deployment --name man-web-self \
      --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/env/-", "value": {"name": "ENV", "value": "bunnyshell"}}]'

exportVariables

Using this property you can export variables from Kubernetes Manifest Components to other components inside the environment. They are captured only during the deploy and can be used after they reach the next interpolation context in the same deploy workflow, or in subsequent start/stop/destroy workflows.

These are not environment variables, but variables exported from your deployment script.

Example: In the section presented below, under deploy, we defined the variable SERVICE_ENDPOINT.

deploy:
        - 'kustomize create --autodetect --recursive --labels=app.kubernetes.io/instance-my-app:bns,app.kubernetes.io/part-of:env-{{ env.unique }} --namespace {{ env.k8s.namespace }}'
        - 'kustomize edit set image nginx={{ components.my-app-image.image }}'
        - |
            kustomize edit add patch --kind Deployment --name my-app --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/env/-", "value": {"name": "ENV", "value": "bunnyshell"}}]'
        - 'sed -i "s/my-app.mydomain.com/my-app-{{ env.base_domain }}/g" ingress.yaml'
        - 'kubectl apply -k .'
        - SERVICE_ENDPOINT="https://my-app-{{ env.base_domain }}/api"

Normally, the variable SERVICE_ENDPOINT would only be available in the scope of the current component. But in this case, we are going to list it under exportedVariables.

exportVariables:
   - SERVICE_ENDPOINT

This way, after the component's deployment finished, Bunnyshell will store the exported variable in a database. The variable will be available for you to use in another component, if need be. You can use the exported variables in interpolation contexts using a key with the format below:

{{ components.NAME.exported.VAR_NAME }}

Kubernetes Manifest Components also have Environment Variables. Environment Variables are injected in the runnerImage.

Usually, environment variables are injected in Kubernetes, where Bunnyshell starts your pod with the image it built. All Component, Environment and Project variables are inherited.