Skip to main content

Managing environments Gimlet specific content

In system configuration, we like declarative, text based file formats that can be versioned in git.

The declarative approach has a benefit over procedural approaches, it being that instead of trying to capture a decision tree in code, you only describe the desired output. Leaving the “how” up to the tooling.

As a developer, this is great, as you only have to describe how the system should look, and if the tooling accepts your change, you can be sure that it does everything it can to achieve the desired state.

With Gimlet, the Gimlet manifest is a declarative file that captures the desired state of an environment - be that staging, production, or a qa environment - and it is stored in your application source code repository. Right next to your application code.

Introducing the Gimlet environment manifest​

With Gimlet, environment configuration happens in your source code repository in Gimlet environment manifest files:

# .gimlet/staging.yaml
app: myapp
env: staging
namespace: my-team
chart:
  repository: https://chart.onechart.dev
  name: onechart
  version: 0.32.0
values:
  replicas: 1
  image:
    repository: myapp
    tag: 1.1.0
  ingress:
    host: myapp.staging.mycompany.com
    tlsEnabled: true

It looks rather similar to Helm's values.yaml file.

Not by accident, the values field carries the content that you previously placed in the values.yaml file.

In addition, it captures the name of the application instance, the logical name of the environment, the namespace where it goes, and the chart name and version.

Capturing the chart name and version also lifts responsibilities from CI, as it allows you to deploy different manifest versions on different environments without modifying the CI pipeline.

To create your first environment file, use gimlet manifest create on your values.yaml file from the previous tutorial. It reads the values.yaml file and converts its contents into the Gimlet manifest format.

gimlet manifest create \
  -f values.yaml \
  --env staging \
  --app myapp \
  --chart onechart/onechart \
  --namespace my-team \
  > .gimlet/staging.yaml
app: myapp
env: staging
namespace: my-team
chart:
  repository: https://chart.onechart.dev
  name: onechart
  version: 0.32.0
values:
  replicas: 1
  image:
    repository: myapp
    tag: 1.1.0
  ingress:
    host: myapp.staging.mycompany.com
    tlsEnabled: true

Continue reading to see how you get Kubernetes manifests from the environment file.

Generating Kubernetes manifests for an environment​

Gimlet CLI has numerous tools to help your local workflows. With the gimlet manifest template command, you can render the exact Kubernetes manifest that is later applied on the cluster through automation. If in doubt, you can always fall back to this method to debug your manifests.

Now run gimlet manifest template to get Kubernetes manifests from your environment file:

gimlet manifest template \
  -f .gimlet/staging.yaml \
  -o manifests.yaml

It knows how to process the gimlet manifest file and essentially performs the equivalent of helm template to produce the Kubernetes manifests.

Now that you have the tool to manage environments, make a change in the .gimlet/staging.yaml file:

  • increase the replica count to 2
  • render the manifests
  • and apply it on the cluster
gimlet manifest template \
  -f .gimlet/staging.yaml | kubectl apply -f -