Hitch a Ride With Sidecar Support in Pivotal Cloud Foundry 2.6

With the release of Pivotal Cloud Foundry (PCF) 2.6, developers now have the option of natively running custom sidecar processes alongside their applications. This is a new feature, but it’s actually a time-honored practice. You may not have realized it, but if you’re running Pivotal Application Service (PAS), your applications are running sidecar processes. When application identity was added in PCF 2.1, it was done by baking an Envoy sidecar process into every application container. Going back even further, the SSH daemon that’s added into every container to enable the “cf ssh” command could even be considered a sidecar process before sidecars were popularized. 

What Is a Sidecar?

Much like a motorcycle sidecar, in our context a sidecar is an additional process that is attached to our main application. It is run, managed, and scaled alongside the main process. A great example of this is Istio, a service mesh control plane commonly used in conjunction with Envoy. Istio will inject an Envoy container into your pod, then route all traffic to and from your application through that instance of Envoy. This means that as the number of pods scales up and down, so does this sidecar pod. The Envoy-Istio example is the most popular one, but there are many other scenarios where the sidecar pattern is useful.

In a sidecar, the logic that may be common between all applications is moved outside of the codebase. This removes the need to potentially reimplement the same features multiple times for apps in different languages. For example, a sidecar could be:

1. A reverse proxy to shape network traffic

2. An abstraction layer between your application and a target API

3. A process that offloads common monitoring tasks (logging, metrics, etc)

Since a sidecar runs as an entirely different process from the main application, there is no requirement that the sidecar is written in the same language, uses the same runtime, or requires the same dependencies. The level of separation means that sidecars are reusable no matter which stacks they support.

How Do Sidecars Work in PCF?

While many think of sidecars as being an additional container in a pod, the concept doesn’t necessarily require them to be implemented that way. In PAS, sidecars are additional processes managed inside of the same container as your application. Your sidecar is pushed up alongside your code when you do a “cf push”, and you tell PAS how to manage it. Let’s take a look at the following manifest file:

    
applications:

- name: sidecar-dependent-app

  disk_quota: 1G

  instances: 1

  memory: 256M

  env:

    CONFIG_SERVER_PORT: 8082

  stack: cflinuxfs3

  sidecars:

  - name: config-server

    process_types:

    - web

    command: './config-server'

This will be familiar to developers that push to Cloud Foundry, with the exception of the new “sidecars” section. Here we give our process a name, tell it what sort of process it is (much like we can with our application), and tell it how to start the sidecar. In this case, since it’s a prebuilt binary, we don’t need to include any additional buildpacks. (But it is possible to do so. With the support for multiple buildpacks, you could have your application in Ruby with your sidecar in Python, and include both buildpacks for your application.)

Deploying Our App With a Sidecar

Let’s consider a situation where we have an application that reads its configuration from an external source by making an HTTP request. In this scenario, we could move the logic that handles authentication with a config server, decrypting the data, and constantly polling the source to a sidecar process, and simply have our application request the latest config from the sidecar.

Our sidecar runs beside our application, constantly polling for an updated config.

We have two pieces of code, our main application and the configuration server sidecar. See the code here.) Without going through the codebase line-by-line, we can see the important part of our application that handles requests to the “/config” endpoint:

get '/config' do

    puts "Sending a request to the config-server sidecar at localhost:#{ENV['CONFIG_SERVER_PORT']}/config/"

    response = Typhoeus.get("localhost:#{ENV['CONFIG_SERVER_PORT']}/config/")

    puts "Received #{response.body} from the config-server sidecar"

    response.body

end

In short, our application will send an HTTP request to the sidecar which will return the configuration that’s provided to it. Since our example sidecar is written in Go, we’ll start by compiling the sidecar binary that will be pushed up with our main application. Because our applications will be running on Linux, we’ll cross-compile the sidecar code appropriately:

cd config-server-sidecar

GOOS=linux GOARCH=amd64 go build -o config-server .

cd ..

Once compiled, we can get ready to push up our application by copying the sidecar binary into the main applications directory:

cd sidecar-dependent-app

cp ../config-server-sidecar/config-server .

Finally, we’ll push both our application and sidecar up. Since this is still a beta feature, the process will look a little different though. Before we push our code up, we need to tell PAS how everything will run, including our sidecar. From the same directory:

cf v3-create-app sidecar-dependent-app

cf v3-apply-manifest -f manifest.yml

cf v3-push sidecar-dependent-app

Great! With our application up and running, we can send it a request to verify that it’s communicating with the sidecar:

$ curl http://sidecar-dependent-app.my-pas.com/config

{"Scope":"some-service.admin","Password":"not-a-real-p4$$w0rd"}

If we SSH into our application, we can also see this process running in the same container as our application:

$ cf ssh sidecar-dependent-app

vcap@d7da0456-2354-4589-4a4f-1b54:~$ ps -A

    PID TTY          TIME CMD

      1 ?        00:00:00 garden-init

     13 ?        00:00:00 diego-sshd

     18 ?        00:00:00 config-server

     29 ?        00:00:00 ruby

     38 ?        00:00:00 sh

     70 ?        00:00:00 envoy

    113 ?        00:00:00 healthcheck

    135 pts/0    00:00:00 bash

    152 pts/0    00:00:00 ps

Ready To Take The Wheel?

The addition of support for custom sidecars opens up a lot of exciting possibilities. Integration with APM tools, custom configuration management, network shaping, and more are all made possible with this new feature, and we’re excited to see how users of PCF will leverage it! If you’re already a PCF user running 2.6, make sure to check out the docs for more details. If you’re not on 2.6, or not a PAS user currently, you can even kick the tires on Pivotal Web Services for free! Want to learn even more about PAS, Pivotal Container Service and more? Sign up for SpringOne Platform now with code S1P_Save200 to save on your registration!

About the Author

Brian is a Principal Product Marketing Manager on the Technical Marketing team at Pivotal, with a focus on technical educational content for Pivotal customers as well as the open source communities. Prior to Pivotal, Brian worked on both the development and operations of software, with a heavy focus on Cloud Foundry and BOSH at companies in many industries including finance, entertainment and technology. He loves learning and experimenting with new technologies, and more importantly sharing the lessons learned along the way

Follow on Twitter Follow on Linkedin More Content by Brian McClain