Cloud Foundry Advisory Board Meeting, May 2019: Sidecars and the Vault Plug-in

The Cloud Foundry Community Advisory Board (CAB) meeting for May 2019 featured two community projects: sidecars and the Vault plug-in. The call—led by Dr. Max of IBM—also highlighted updates from members of the development teams.

Sidecars processes in Cloud Foundry

Sidecars in Cloud Foundry represent additional dependent processes that run in a container as the main app process. With the recent addition of sidecar support in Cloud Foundry, users may find it helpful when there are two processes that need to:

• communicate over a UNIX socket or via localhost
• share the same file system
• be scaled and placed together
• have fast interprocess communication

A sample sidecar architecture (Image credit)

According to Scott Sisil of Pivotal, sidecars were a highly sought-after feature, and its addition is already enticing new and even former users back to the Cloud Foundry ecosystem.

Scott Sisil

“We’ve actually had users switch off the platform, because we were unable to run their sidecar-dependent apps on Cloud Foundry. Since we released this feature, we’ve been happy to see people coming back.” —Scott Sisil, Pivotal

During the call, Scott demonstrated how sidecars work—by deploying a Ruby app, which talks to a separate Golang binary that is run as a sidecar process.

At the moment, sidecars are available in alpha. All the code and configuration required to run a sidecar and an app are packaged together in the same droplet, which is deployed in a single container on Diego. Both processes within the container are health-checked independently.

“You can run as many sidecars as you would like. You can attach a single sidecar to multiple processes.” —Scott Sisil, Pivotal

To learn more about sidecars in Cloud Foundry, check out the official documentation.

Sidecars’ GitHub repo

The Vault plug-in

The Vault plug-in for Cloud Foundry is a standalone back-end authentication add-in that is supposed to be used together with the HashiCorp Vault tool. The plug-in enables an application running in Cloud Foundry to employ Instance Identity to authenticate with HashiCorp Vault.

Sergey Matochkin

During the call, Sergey Matochkin, Adam Williams, and Ray Harrison of Comcast explained the idea behind the Vault plug-in for Cloud Foundry, as well as how it works in practice.

With the Vault plug-in, Cloud Foundry applications no longer need to be bootstrapped with credentials. Instead, they can use certificates provided by Cloud Foundry to authenticate themselves and gain access to Vault secrets.

“Our goal is to make secret management really easy for Cloud Foundry applications by getting rid of a lot of the complexity that exists, while still maintaining a high level of security.” —Adam Williams, Comcast

The Vault plug-in architecture (Image credit)

Ray Harrison

The Vault plug-in is currently a work in progress. The Comcast team is encouraging other users to try it out and provide feedback.

“The work that we’re doing here really is to help to make it less painful for us. We hope that this is helpful to others, as well.” —Ray Harrison, Comcast

Vault plug-in’s GitHub repo

Runtime PMC

Eric Malm

Eric Malm of Pivotal provided several new developments:

• cf-deployment v8.0 and v9.0 were released. cflinuxfs2 is no longer supported. Issues with Gorouter CVE were fixed.
• The CF CLI v6.47 was released, which has improved support for client credentials.
• The CAPI team added initial support for running sidecars.
• The UAA team released v73, which has breaking changes for TLS configuration properties.
• The networking team is progressing on dynamic egress as a flexible replacement for application security groups.
• The Garden team released initial support for better CPU metrics.
• The Garden Windows team announced support for Windows 2019 Diego cells.
• The Diego team is working on improving Locket consumption of database connections.
• The Eirini team is completing improvements to staging tasks and is transitioning toward cflinuxfs3.

Runtime PMC’s GitHub repo

BOSH

Mukesh Gadiya

Mukesh Gadiya of Pivotal noted that two separate teams are officially maintaining BOSH Director and BOSH Systems from now on. He also listed the following updates:

• BOSH Director
• v269.0.1 was released, which has a new life-cycle hook—pre-stop.
• An exported_from section was added to the releases manifest.
• The OpenStack CPI team added parallel resurrection functionality.
• The team is working on making BOSH start, stop, and recreate commands more predictable.
• The removal for v1 manifests support is ongoing.
• BOSH Systems
• The team cut the v1.11 DNS release, which has support for per-job link healthiness.
• A new Xenial stemcell line in v315.x was cut.
• Technical exploration on creating bionic stemcells is ongoing.
• Exploration of using presigned URLs with blobstores to eliminate the need for blobstore creds on each VM is planned.

BOSH’s GitHub repo

CF Extensions

Dr. Max

Michael Maximilien (aka Dr. Max) of IBM reported a few developments:

• App-AutoScaler
• App-AutoScaler is now a Stratos UI extension.
• The v1.2.1 release includes metrics, caching, secure connections, and Prometheus health endpoint.
• Abacus
• End of life is planned.
• Stratos
• v2.4.0 was released.

CF Extension’s GitHub repo

Foundation updates

Swarna Podila

Swarna Podila noted the return of the Quarterly Release Summary and urged users to participate in the Cloud Foundry User Survey. The CF Foundation also published an amazing release notes report, which overviews all the features delivered across the core ecosystem projects in Q1 2019.

Call for papers (CFP) for the upcoming summit in Europe ends on May 31, 2019. CFP notifications are set to go on June 17, 2019. Contributor Summit, the day zero event, is scheduled for September 10, 2019.

The next CAB call is scheduled for Wednesday, June 19. The call will start at 8 a.m. Pacific Time. Anyone interested can join the Cloud Foundry’s CAB Slack channel.

Want details? Watch the video!