Simple Multi instance configuration

Simple Multi-instance configuration

Phase II: Simple config server

Goal

Create a simple configuration server that can drive the configurations of several instances spun up as part of a deployable.

Description

In order to really show what Audrey is meant to do, we need to be able to configure several instances that may have dependencies on each other. The key function here is to be able to cross-pollinate the instance configurations in order to resolve inter-instance relationships and dependencies.

An example is the ability to spin up an application server and database server as part of the same deployable, then have the application server’s configuration learn the existence of the database server and modify its configurations accordingly.

The flow will look something like:

1. The jobs for both instances are created by the audrey.rb script (tomorrow, this will be conductor)
   • This job generation also creates information to be POSTed to the config server to pre-seed the instance configurations
2. When the instances spin up, they call Amazon for “user data”. The user data consists of:
   • The instance’s UUID
   • The ConfigServer’s IP address
3. The instance phones home to the ConfigServer for the instance configuration data associated with the UUID
   1. The config server receives the GET request, and jots down the requester’s IP address
   2. The config server applies the IP address of the requester to any instance’s configuration waiting for that data
      • this will be denoted by a “required” parameter in an instances configuration in the deployable that expects that template-type’s IP address
   3. The config server examines the configuration data associated with the UUID
      • if the configuration data is “complete”, it can be sent back to the instance (HTTP 200)
      • if the configuration data is “incomplete”, it cannot be sent back to the instance (HTTP 404)
        • in this case, the instance enters a retry state where it will ask for the configuration data on a recurring basis until the request is successfully fulfilled (i.e., rinse and repeat)

In this example, when the database server phones home to the config server, the config server will populate the app server’s configuration with the database server’s IP address (thus “completing” the app server’s configuration data). The config server can immediately ship the configuration data for the database server. When the app server phones home, the config server will inspect the app server’s configuration data to ensure it’s complete (magic hand wavy? maybe a little). If the database server hasn’t phoned home yet, the configuration data will still be incomplete. In which case, the app server will enter a waiting state and try again. If the database server has phoned home already, the configuration data will be complete, and can be returned to the app server.