Managing Secure Multi-Datacenter Cloud Foundry with Vault and Concourse

by Alexander LomovMay 3, 2017
How to create repeatable and secure Cloud Foundry deployments across multiple data centers with related services and simplify deployment management?

Managing distributed environments

Let’s be honest: Cloud Foundry is widely used by enterprises across different industries that care about accessibility to their services a lot. Furthermore, such companies often have affiliated departments distributed geographically all over the world. This all calls for enabling multiple Cloud Foundry deployments distributed across several data centers.

In order to cope with the complexity of managing such deployment, Altoros comes with an architecture that is based on the state-of-the-art tools available in open source. This system allows for creating repeatable and secure Cloud Foundry deployments across multiple data centers with related services and simplifying deployment management.

With our new reference architecture, we describe deployment management using Concourse, BOSH, and Vault at a high level. Concourse and BOSH were specifically designed for deploying, managing, and updating the Cloud Foundry PaaS with related services. In this blog post, we provide excerpts from the reference architecture, highlighting the layers of active-active Cloud Foundry deployment, what they are responsible for, and how they are interrelated.


What is Vault?


Vault is a tool for storing and managing secrets, such as API keys, passwords, certificates, etc. In addition, all the configuration properties are also stored in Vault: services’ IP addresses, connection properties, etc. The tool provides a unified interface to any secret, while granting tight access control and recording a detailed audit log. Vault is also responsible for secrets encryption on a hard drive and safe delivery of secrets to final recipients.

The main problem in a data center deployment is application data synchronization. In order to achieve application data accessibility across all data centers, we use the so called active-active deployments of data services, such as MariaDB and MongoDB. Since Cloud Foundry is used as a stateless application runtime, we provide each data center with its own Cloud Foundry installation and synchronize them through CI built upon Concourse.

Such Cloud Foundry deployments are commonly referred to as active-active deployments, having a load balancer in front of them as a single entry point for user traffic. The main benefit of these deployments is improved availability: a system like that can easily survive outage of at least one data center.

Using Vault allows for easily sharing secrets and configuration data between environments and enables smooth deployment of active-active data services. It also aids engineers in creating and synchronizing Cloud Foundry deployments as a part of a single system. Running system upgrades also becomes more convenient. This approach can be simplified by using Vault and Concourse pipelines.

pipeline-dependencies-multi-datacenter-cloud-foundry-reference-architecture-using-vault-and-concoursePipeline dependencies


The layers comprising the solution

The described system can be divided into a number of isolated layers. You can see an example of such division of an active-active Cloud Foundry deployment on the diagram below. The picture demonstrates a deployment in two data centers running vSphere. Each of the layers has its own responsibility, supporting other layers:

  1. The supervisor layer is represented by the control plane components and is used to create and manage all the other layers. A control plane (or a management plane) is a set of components used to create and manage components in different environments. It is built upon the tools mentioned above: BOSH, Concourse, and Vault. A control plane is usually deployed in a distinct data center or a physical server to make it independent and fail-proof. The detailed description of this layer can be found in the full document (pages 7–8).
  2. The virtualization layer is responsible for spinning up a new infrastructure, with any kind of virtualization supported by BOSH: AWS, vSphere, Google Compute Engine, Microsoft Azure, OpenStack, SoftLayer, RackHD, VMware Photon, etc.
  3. The Ops tools layer. This one usually contains the components used to maintain an environment. An operator has an access to this layer only through the control plane.
  4. The data services layer is responsible for storing and sharing state data used by application instances. In order to provide high availability, we deploy active-active clusters of MariaDB and MongoDB to environments in several different data centres.
  5. The runtime layer is served by Cloud Foundry itself to run applications and bind them with data storage services. Since applications deployed to Cloud Foundry are stateless and share data only through active-active clusters of data services, application data is always up-to-date and accessible.

multi-data-center-cloud-foundry-reference-architecture-using-concourse-vault-bosh-layers-of-an-active-active-deployment-v11Layers of an active-active Cloud Foundry deployment

The architecture involving a control plane—built upon BOSH, Concourse, and Vault—enables predictable, repeatable, and configurable Cloud Foundry environments in multiple data centers. Furthermore, this approach allows for protecting sensitive data and sharing it across active-active deployments to multiple clouds. It also makes designing active-active and hybrid architectures easier.

To learn more about the deployment process of the described architecture, check out the full guide.


Related video


Related reading