Engine Yard Kontainers: Configure an application

The way to control an application deployed on Engine Yard Kontainers platform, is through configuration. Following the 12-Factor-App rules, the configuration is done using environment variables. In this article we will explore how to achieve this but also how to a step further.

Worth noticing that every time the configuration changes, the application pods will be re-created in order to use the latest changes. Of course this is done in a rolling fashion with no downtime.

Configuring the application using eyk config:set

We may set one or more environment variables via the command:

  
  eyk config:set <var_1_name>=<var_1_value> <var_2_name>=<var_2_value>
  --app=<app_name>
  

This is the most straightforward way to configure the application. To verify the results you may issue:


 eyk config:list --app=<app_name>
 

 

Configuring the application using eyk config:push

We may store our configuration in a local file that we don't check in our repository. That file may have sensitive information (e.g. passwords). We may use this file in order to configure the application and avoid setting the environment variables one by one. By default, the file that contains the configuration is  the ".env" and has the following form:

 


  RACK_ENV=staging
RAILS_ENV=staging
MY_CUSTOM_VAR=ilias_hello

By issuing the command:


  eyk config:push --app=<app_name> --path=<my_custom_path>

the contents of the configuration file will be uploaded and transformed into environment variables. If we omit the "--path" part then the ".env" file will be used. To verify the results you may issue:


 eyk config:list --app=<app_name>
 

 

Complex configuration patterns

The use of environment variables mean that our application can consume them. For a rails application such variables are:

While in many cases we may have our initializers get the environment variables and use them, there are cases where a .yml file is expected to be in place. For these cases we have introduced the following structure in the root directory of our application:


  ky_specific/
  ├── config
  │   ├── database.yml.erb
  │   ├── newrelic.yml.erb
  │   ├── redis.yml.erb
  │   └── sidekiq.yml.erb
  └── sparkplug.sh
  

 The ".erb" template files give us the opportunity to work with environment variables. An example of "database.yml.erb" template is the following:

  
  <%= ENV["RAILS_ENV"] %>:
    adapter:   <%= ENV["database_yml_dbtype"] %>
    database:  '<%= ENV["database_yml_dbname"] %>'
    username:  '<%= ENV["database_yml_dbuser"] %>'
    password:  '<%= ENV["database_yml_dbpass"] %>'
    host:      '<%= ENV["database_yml_dbhost"] %>'
    reconnect: true
    

 

The script "sparkplug.sh" is a simple shell script like the following:

 


  #!/bin/bash

  erb -T - ky_specific/config/database.yml.erb > config/database.yml
  erb -T - ky_specific/config/newrelic.yml.erb > config/newrelic.yml
  erb -T - ky_specific/config/redis.yml.erb > config/redis.yml
  erb -T - ky_specific/config/sidekiq.yml.erb > config/sidekiq.yml
  

 

The above script can be executed prior the main process in our pod. For example, in the Procfile we may have an entry like:


  web: ./ky_specific/sparkplug.sh && bundle exec rails server -b 0.0.0.0
  -p 5000 
  

 The fact that the script "sparkplug.sh" runs when the process in the pods starts, means that the templates will be parsed whenever we make a configuration change.

Comments

Article is closed for comments.

Powered by Zendesk