Add support for environment based configuration

[tristanpemble]

When running my application deploys, a lot of how they are configured depends on the target environment. For example, running MySQL locally I might only want to allocate 1GB of memory, but in production it would be much higher.

One of the ways I was thinking this could be possible, is if the service.yml allowed Jinja2 templating in the configuration values. This could be a powerful feature, especially if it were combined with a Jinja2 filter that allowed you to pull an environment variable. Imagine this:

# ./service.yml
name: my-microservice
memory: "{{ env('MEMORY') | default('0.5G') }}"

This could of course be handled in the K8S template, too:

# ./k8s/deployment.yaml
# ...
         resources:
           limits:
             memory: {{ env('MEMORY') | default('0.5G') }}
             cpu: {{ env('CPU') | default('0.25') }}
# ...

But I think the self documenting nature of the first example, by being contained in service.yml, is more advantageous.

This would allow you to use a local .env file in development, with something like source .env && forge deploy. It would also be helpful for handling deploys in CI environments, without storing production values in the Git repository.

[tristanpemble]

Fat-fingered the submit button before finishing up the issue description, reopening now that I have written out the full feature request.

[tristanpemble]

Thinking about it more, I think just passing the environment in as a dict to the templates would be all that is really necessary:

# ./service.yml
name: my-microservice
memory: 0.5G
cpu: 0.25

# ./k8s/deployment.yaml
# ...
         resources:
           limits:
             memory: {{ env.MEMORY | default(service.memory) }}
             cpu: {{ env.CPU | default(service.cpu) }}
# ...

the downside being that there's no list of environment variables available directly in the service.yml, which can just be managed by documenting them. this also feels less like you're setting defaults when editing service.yml, since it's not immediately clear that they could be overridden when viewing that file, so that might be confusing.

The Jinja2 templating in service.yml might be useful in other contexts, but would be unnecessary here.

[rhs]

I implemented both the jinja2 templating of service.yaml and passing env into the k8s templates as you describe, so I believe either of your examples should work.

I'm currently working on adding some more docs. I'll post here again when the docs are done, but if you install the latest, you should be able to play around with the new features you've described.