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 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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
Container Networking is a BOSH release deployed on top of CF Deployment containing a policy server and Garden-runC integration.
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.
Open Service Broker API
Open Service Broker API provides a common standard for services integration supported by Kubernetes, OpenShift, and Cloud Foundry.
— Matt M (@1mattmc) March 29, 2017
Chip Childers presenting the project at KubeCon 2017
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.
Diego on PostgreSQL
Diego now supports storing Bulletin Board System (BBS) data in such relational databases as PostgreSQL and MySQL.
Why it matters? This feature helps to avoid performance bottlenecks of Cloud Foundry deployments on slow hard drives.
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!
- 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!
About the speaker
To stay tuned with the latest updates, subscribe to our blog or follow @altoros.