How to change default variables

We set default variables in all Building Blocks but there might be use cases where you want to customize them.
For example if you want to use another namespace or the configuration has to be in another directory than the default one.
This tutorial will show you how you can change these default variables of a Building Block's gitlab job definition.

Set a custom basedir

Let's assume you have an application which needs a Redis service and you want to have all configuration for this application in the same directory. You can add the Redis-HA Building Block in the same directory, but you have to overwrite the BASEDIR variable.

example-application/.gitlab-ci.yml

include:
  - project: syseleven/building-blocks/helmfiles/redis-ha
    file: JobDevelopment.yaml
    ref: 1.31.1

variables:
  BASEDIR: $CI_PROJECT_DIR/example-application

Now you can place your values-redis-ha.yaml in the example-application directory. To also deploy it in the same namespace, see below.

Set a custom namespace

Another use case could be, to deploy a Building Block into the same namespace together with your application. You can do so by overwriting the default namespace variable.

syseleven-redis-ha/.gitlab-ci.yml

include:
  - project: syseleven/building-blocks/helmfiles/redis-ha
    file: JobDevelopment.yaml
    ref: 1.31.1

variables:
  NAMESPACE_REDIS_HA: example-application-namespace

You can find the namespace variable for a Building Block in the Building Blocks repository.

Set a custom release name

If you want to set a custom release name you can do so by overwriting the release name variable.

syseleven-redis-ha/.gitlab-ci.yml

include:
  - project: syseleven/building-blocks/helmfiles/redis-ha
    file: JobDevelopment.yaml
    ref: 1.31.1

variables:
  RELEASE_NAME_REDIS_HA: example-application-redis-ha

You can find the release name variable for a Building Block in the Building Blocks repository.

configure resources

If you face any issues or have special demands within your projects, you can unset the default limits on memory or cpu within your building block configuration.
As it is always a best practice to stick to the default limits we provide - or at least set the limits - you can also remove the default limits for your building blocks described as follows

# here the default values

resources:
  requests:
    cpu: 256m
    memory: 256Mi
  limits:
    cpu: 256m
    memory: 256Mi

---

resources:
  requests:
    cpu: 256m
    memory: 256Mi
  limits:{}

To set the limits to an empty set will unset the default limits without any resource restriction on cpu or memory to unlimited.

The reason for the above mentioned best practice is to keep the limits because of the behaviour of Kubernetes.
Setting limits helps you to protect other deployments from starvation.
Kubernetes prioritize pods where the limits are set before those deployments where it is not set.
Pods where no limits are set will be killed first. This could be critical if you work with in memory data and your project relies e.g on caches.
Requests on the other side helps the schedular to find the best node suitable to run your deployment.

So it is always a good practice to keep an eye on requests and limits.