title: How do you manage per-environment data in Docker-based microservices?
body: <p>In a microservice architecture, I'm having a hard time grasping how one can manage environment-specific config (e.g. IP address and credentials for database or message broker).</p>
  
  <p>Let's say you have three microservices ("A", "B", and "C"), each owned and maintained by a different team.  Each team is going to need a team integration environment... where they work with the latest snapshot of their microservice, along with stable versions of all dependency microservices.  Of course, you'll also need QA/staging/production environments as well.  A simplified view of the big picture would look like this:</p>
  
  <p><strong>"Microservice A" Team Environment</strong></p>
  
  <ul>
  <li>Microservice A (<strong>SNAPSHOT</strong>)</li>
  <li>Microservice B (STABLE)</li>
  <li>Microservice C (STABLE)</li>
  </ul>
  
  <p><strong>"Microservice B" Team Environment</strong></p>
  
  <ul>
  <li>Microservice A (STABLE)</li>
  <li>Microservice B (<strong>SNAPSHOT</strong>)</li>
  <li>Microservice C (STABLE)</li>
  </ul>
  
  <p><strong>"Microservice C" Team Environment</strong></p>
  
  <ul>
  <li>Microservice A (STABLE)</li>
  <li>Microservice B (STABLE)</li>
  <li>Microservice C (<strong>SNAPSHOT</strong>)</li>
  </ul>
  
  <p><strong>QA / Staging / Production</strong></p>
  
  <ul>
  <li>Microservice A (STABLE, RELEASE, etc)</li>
  <li>Microservice B (STABLE, RELEASE, etc)</li>
  <li>Microservice C (STABLE, RELEASE, etc)</li>
  </ul>
  
  <p>That's a lot of deployments, but that problem can be solved by a continuous integration server and perhaps something like Chef/Puppet/etc.  The <strong><em>really</em></strong> hard part is that each microservice would need some environment data particular to each place in which it's deployed.  </p>
  
  <p>For example, in the "A" Team Environment, "A" needs one address and set of credentials to interact with "B".  However, over in the "B" Team Environment, <em>that</em> deployment of "A" needs a different address and credentials to interact with <em>that</em> deployment of "B".</p>
  
  <p>Also, as you get closer to production, environmental config info like this probably needs security restrictions (i.e. only certain people are able to modify or even view it).</p>
  
  <p>So, with a microservice architecture, how to you maintain environment-specific config info and make it available to the apps?  A few approaches come to mind, although they all seem problematic:</p>
  
  <ul>
  <li><strong>Have the build server bake them into the application at build-time</strong> - I suppose you could create a repo of per-environment properties files or scripts, and have the build process for each microservice reach out and pull in the appropriate script (you could also have a separate, limited-access repo for the production stuff).  You would need a <em>ton</em> of scripts, though.  Basically a separate one for every microservice in every place that microservice can be deployed.</li>
  <li><strong>Bake them into base Docker images for each environment</strong> - If the build server is putting your microservice applications into Docker containers as the last step of the build process, then you could create custom base images for each environment.  The base image would contain a shell script that sets all of the environment variables you need.  Your Dockerfile would be set to invoke this script prior to starting your application.  This has similar challenges to the previous bullet-point, in that now you're managing a ton of Docker images.</li>
  <li><strong>Pull in the environment info at runtime from some sort of registry</strong> - Lastly, you could store your per-environment config inside something like Apache ZooKeeper (or even just a plain ol' database), and have your application code pull it in at runtime when it starts up.  Each microservice application would need a way of telling which environment it's in (e.g. a startup parameter), so that it knows which set of variable to grab from the registry.  The advantage of this approach is that now you can use the <em>exact</em> same build artifact (i.e. application or Docker container) all the way from the team environment up to production.  On the other hand, you would now have another runtime dependency, and you'd still have to manage all of that data in your registry anyway.</li>
  </ul>
  
  <p>How do people commonly address this issue in a microservice architecture?  It seems like this would be a common thing to hear about.</p>