Modern services accept many configurations that can change their behavior in different ways.
An example of a change like this could look like a service making requests to a third-party service on the internet, and you decide to change the request address depending on whether you’re running it in the staging server, or the production server.
Or, you may want to switch up the algorithms in your service, enable/disable features, or set secrets like private keys or authentication tokens that can be used while interacting with other parties.
In order to configure a service without modifying its source code or mesg.yml file, you can pass deployment time environment variables to change the behavior of your service.
Env variables should be defined in the mesg.yml file first with some optionally set defaults. Then you can dynamically overwrite their values while deploying the service.
Each service has its own unique hash which is calculated from the sum of the service’s source code and mesg.yml file. This is a very important feature used to identify different services uniquely, and it brings safety in perspective of services’ consumers.
This behavior stays the same when you use deploy time env variables. The service’s hash will change accordingly depending on the env variables you passed onto the service. This is a 1:1 match, which means there is a strong correlation between the configuration and service’s hash. The same configuration for a service will produce the same hash, whereas a small difference in the configuration will result into a completely different hash.
Within the following sample mesg.yml file, we’re configuring an IP location service to use MaxMind by default as the geo location database provider by using the env variables:
name: location description: Find Geo Location of an IP Address configuration: env: # We're using MaxMind as a geo location database provider but it can # be changed to another one by overwriting env variables in the deployment time. # Note that service is responsible to respect to these env variables. - PROVIDER=maxmind tasks: locateIP: inputs: ip: type: String outputs: success: data: location: city: type: String country: type: String error: data: message: type: String
If we want to stick with MaxMind we can just deploy the service as it is like this:
$ mesg-core service deploy https://address/of/service-location ✔ Service deployed with hash: 83aeca808856c3bef0c74e68596b39a0bb1d0a35
Or we can change the provider to another one that is supported by the service itself by using ‘env’ flag in the deploy command:
$ mesg-core service deploy --env PROVIDER=ip2location https://address/of/service-location✔ Service deployed with hash: 4e25789a1c769b33017a4995d0ada37e0fbcc315
Great! Now you have learned:
- how to define env variables to your service with some default values by using the ‘myVar=value’ syntax under the env section.
- how to overwrite them in the deploy time with an ‘env’ flag like ‘ — env myVar=newValue’.
- and that the service’s hash will change depending on the env variables you overwrite in the deploy time.
Keep in mind that:
- you can only overwrite env variables you defined in the mesg.yml file.
- you can define env variables for the service under the env section of configuration section and for the dependencies under dependencies’ env section.
- you can overwrite multiple env variables by using multiple ‘env’ flags.
- and you’re also able to configure your services in Workflows by using env variables, which is awesome!