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:
-
A reverse proxy to shape network traffic
-
An abstraction layer between your application and a target API
-
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!
