Which of the New Cloud Foundry Features Save DevOps Time Most?

With continued development, Cloud Foundry brings improvement across the platform itself and DevOps experience, too. At the Cloud Foundry Summit 2017 in Silicon Valley, Alex Zalesov, engineer at Altoros, walked attendees through the improvements to the Cloud Foundry ecosystem since the past year.

Cloud Config

Cloud Config represents a YAML file that defines IaaS-specific configuration used by the BOSH Director and all the deployments. It extracts the IaaS configuration data from a manifest, saves it into a file, and uploads it into the Director. The configuration file is then shared across all the BOSH deployments.

Cloud Config and BOSH Director (Source)

Why it matters? Cloud Config enables true deployment portability between clouds. It helps to avoid the need to create multiple manifests for each BOSH deployment, facilitating the process of changing a configuration. In addition, the tool simplifies initial deployment with BOSH Director by using the Terraform files exported from BOSH Bootloader that describes the infrastructure configuration.

“Before Cloud Config, we used to have deployment manifests like cloudfoundry-aws-192.yml. Today, we can remove this AWS specific piece in Cloud Config and have a manifest that deploys a specific version of Cloud Foundry.” —Alex Zalesov, Altoros

GitHub repo

BOSH Bootloader

BOSH Bootloader provides an initial infrastructure for BOSH by exporting it as a сloud сonfig file. Though currently available for AWS and Google Cloud only, BOSH Bootloader is being actively developed to support all the IaaS options available for Cloud Foundry.

BOSH Bootloader commands (Source)

Why it matters? BOSH Bootloader reduces errors while deploying BOSH and running operations. The tool saves the need to spend hours on copying the Terraform output to deployment manifests, making a depot, and debugging issues.

GitHub repo

BOSH 2.0 Links

BOSH 2.0 Links is a mechanism for static service discovery. It eliminates the need to use static IPs when defining a job.

Why it matters? BOSH 2.0 Links separates network and services configurations. Non-networking configurations, such as job properties, can be shared through this service in between deployments. Furthermore, BOSH 2.0 Links allows for a more efficient way of managing releases with Cloud Config.

GitHub repo

BOSH 2.0 CLI

The BOSH 2.0 command line interface (CLI) is written in the Go language (previously, it was on Ruby).

Why it matters? BOSH 2.0 CLI simplifies BOSH operations. It replaces spiff and spruce by replicating their functionalities. The tool also enables auto-generation of certificates and secrets, which is useful for encryption purposes. In addition, it features variable interpolation in manifests, so that a DevOps engineer doesn’t have to use external scripts for replacing variables in manifests with actual values.

“Now, you can just specify the variables stored on the CLI and it will replace the variables automatically. —Aleksey Zalesov, Altoros

GitHub repo | Pivotal Tracker

Mutual TLS

Mutual Transport Layer Security (TLS) is a protocol that establishes secure two-way communication and authentication. Both a client and a server provide certificates to authenticate their identity.

A message flow (Source)

Why it matters? Mutual TLS removes the IaaS selection restrictions for companies with strict security policies. It enables major components in the platform to encrypt their data flow, allowing for securely deploying Cloud Foundry in public clouds.

GitHub repo

CredHub

CredHub is a component designed to enhance Cloud Foundry security. It was developed within the CF-Extensions initiative.

The proposed CredHub architecture (Source)

Why it matters? CredHub reduces the risk of leaking IaaS keys. Some of its features include:

• Facilitating generation of credentials by uploading them from BOSH CLI
• Extracting IaaS keys from BOSH manifests
• Automating the management of the SSL certificates and generation of default secrets
• Automating storage and life-cycle management operations
• Creating access rules with a possibility to set separate authorizations for deployment or management of an infrastructure

CredHub is an external component that is still under development and is not yet being used in Cloud Foundry production deployments.

GitHub repo| Pivotal Tracker

CF Deployment

CF Deployment is used as a method of deploying Cloud Foundry from separate releases. CF Deployment is already an efficient tool for delivering test deployments and building proof of concepts. It is not ready for production yet, because there is no means for migrating a CF release to CF Deployment. The upgrades of CF releases across different versions of CF Deployment are also being tested.

Source

Why it matters? CF Deployment makes the Cloud Foundry deployment process understandable. It supports the Diego runtime and such BOSH 2.0 features as Links, Cloud Config, and CLI.

GitHub repo

Container Networking

Container Networking is a BOSH release deployed on top of CF Deployment containing a policy server and Garden-runC integration.

Container Networking architecture (Source)

Why it matters? Container Networking reduces the latencies in communication between microservices. It enables applications to directly communicate with each other leaving Gorouter out as an intermediary.

GitHub repo

Open Service Broker API

Open Service Broker API provides a common standard for services integration supported by Kubernetes, OpenShift, and Cloud Foundry.

Why it matters? The Open Service Broker API enables the reuse of effort across different ecosystems. It aids developers, independent software vendors, and software-as-a-service providers in delivering services to applications running on distinct cloud-native offerings.

GitHub repo

Diego on PostgreSQL

Diego now supports storing Bulletin Board System (BBS) data in such relational databases as PostgreSQL and MySQL.

Diego architecture (Source)

Why it matters? This feature helps to avoid performance bottlenecks of Cloud Foundry deployments on slow hard drives.

GitHub repo| Pivotal Tracker

Isolation segments

Isolation segments allow for creating multiple groups of applications inside a single Cloud Foundry deployment, separating them on the virtual machine level.

Why it matters? Prior to that, DevOps engineers would need a separate Cloud Foundry deployment per a logical environment for customers with strict security policies.

In Aleksey’s experience, isolation segments have proven very useful when a customer needed to separate production, staging, QA, and development environments. Without separate spaces as an option, a DevOps engineer would end up with four different Cloud Foundry deployments.

Cloud Foundry remains one of the industry’s fastest growing and most adopted cloud development platforms. Its ever improving ecosystem has evolved over the years and there isn’t any drop in developer interest. What new features will we see next year?

Want details? Watch the video!

Related reading

• Discussing CredHub for Centralized Credential Management in Cloud Foundry
• Cloud Foundry CAB, Dec 2016: Open Service Broker API and Diego 1.0
• Cloud Foundry’s Garden: Back Ends, Container Security, and Debugging
• A New Cloud Foundry Container Engine for Linux, Garden-runC v1.0, Is Out!

Related slides

About the speaker

Aleksey Zalesov is a Cloud Foundry/DevOps Engineer at Altoros. He has seven years of experience in managing computer systems, both traditional and cloud-based. Currently, Aleksey designs and implements distributed PaaS systems based on Cloud Foundry. He is passionate about automating cloud infrastructure management with BOSH, while using DevOps techniques in everyday activities. Aleksey’s research interests also include self-managing computer systems and techno-social interactions.