Skip to content

Jinja Deployment

To start a new Jinja templated deployment i.e. for a NGINX server with releases test and prod in the namespace playground, create the basic repository structure as follows:

mkdir my-deployment && cd my-deployment
mkdir -p namespaces/playground
touch defaults.yml namespaces/playground/test.yml namespaces/playground/prod.yml

Default Variables

Add your defaults variables (for all namespaces and releases) to the defaults.yml.

It has proved helpful to set all default values in defaults.yml so that the Jinja templates in the template directory can be rendered without errors.

Tip

In addition it makes sens to pin the image versions in the [Namespace/Release Configuration] while setting the most recent configuration in the defaults.yml. In doing so, you can deploy newer versions in non-production environments for testing purpose (i.e. using CI/CD) and have pinned versions and controlled updates in production environments.

A possible defaults.yml might look as follows:

defaults.yml
versions:
  nginx: 1.23

nginx:
  image: nginx
  listen: 0.0.0.0:80
  locations:
    - name: default
      upstream: 0.0.0.0:8000

Namespace/Release Configuration

The destination namespace and the releases of the deployment must be defined by creating the namespace/release configurations in namespaces/<namespace>/<release>.yml.

For the namespace playground and releases test and prod the following configuration file must be created:

namespaces/playground/test.yml
versions:
  nginx: 1.22

nginx:
  image: registry.awesome-it.de/upstream-docker/library/nginx
  locations:
    {% for name in ["service-1", "service-2"] %}
    - name: {{ name }}
      upstream: 0.0.0.0:{{ 8000 + loop.index0 }}
    {% endfor %}
namespaces/playground/test.yml
# Inherit from defaults.yml
#versions:
#  nginx: <version>

Render

After default variable and namespace/release configuration has been created, the template can be rendered into k8s resource manifest files:

adeploy -p jinja render .
Example run ...

This will create vanilla k8s manifest files in the build output folder for each release.

Tip

You can (re-)create the output for a specific namespace or release by filter for the specific namespaces or releases as adeploy --filter-namespace <namespace> --filter-release <release>. You can pass these arguments multiple times to include multiple namespaces or release.

Test

You can now test the generated deployment from the build folder by applying the manifest file in a dry-run using the server stragegy (i.e. kubectl apply --dry-run=server). In doing so, the API resources are submitted using server-side requests but not persisted by the API. This can be done as follows:

adeploy -p jinja test
Example run ...

Tip

Similar to the build, you can also run the tests for specific namespaces or releases only by specifying both or one of the attributes --filter-namespace <namespace> or --filter-release <release> i.e. adeploy --filter-namespace playground -p jinja test .

Deploy

The generated and tested k8s resources can now be deployed to the k8s cluster as follows:

adeploy -p jinja deploy
Example run ...

Note

adeploy will not create namespaces for you, so you still need to manually create i.e. the playground namespace first.

Tip

adpeloy will store the destination cluster of your deployment in ~/.adeploy. If you accidentally have a wrong cluster enabled in your current context, adeploy will warn you accordingly before it continues.

Tip

Run adpeloy in debug mode using adeploy -d -p jinja deploy to get verbose output e.g. the kubectl commands that are being executed by adeploy.

Hava a look at the common topic for more adeploy features that can be used in both, Helm chart templates and Jinja deployment templates i.e. to manage labels, secrets, resource limits or to run automated deployment pipelines.