Overview

My work for this project consisted of two parts:

• Dockerizing the components
• Replacing the pusher.py tool for deployment of the newly-made Docker images

Before this project conference workflow looked something like the following:

1. Bringing up local and cloud hosts
2. Pushing out single configurations to a host(based on config.json) over ssh
3. Manually starting, stopping machines.

This approach has a few issues that I try to address in my project. For one, we can only run a single component on a host. This limitation is mostly just set by the complexity of the flumotion configuration required for multiple components on a host. Thus Docker allows us to isolate components for a group and run them on a single host, keeping them confined and isolated.

Docker should also allow for faster and easier deployment. Instead of the large numbers of dependencies that had to be installed on a host, the only dependency now is Docker.

Now, we have a couple different possible workflows I will describe below.

Building locally:

1. Bring up local and cloud hosts with Docker installed
2. Build Docker images locally, pushing to a Docker repo
3. Pull Docker images to host
4. Start image

Building on host:

1. Bring up local and cloud hosts with Docker installed
2. Build Docker images on host
3. Start images

The tool I created with my project utilizes the second method, that is it builds an image on the host that will be running it. It should be clarified that there isn’t much real ‘building’ that occurs. We are just baking the specific configurations for that component into a base flumotion image.

Component Dockerization

While there are 3 different components we have Dockered, two of those – the collector and the encoder – are the same service with simply a different configuration. Thus, I’ll divide discussion into the ‘Flumotion’ image and the ‘Frontend’ image.

To start off, I’ll say that we would like to have a Dockerfile build from scratch(an Ubuntu base image) for all of our images. Not only does this show us exactly what we are doing to get our image, but it also puts our image into source control! Unfortunately, we have to do some trickery for Flumotion that I’ll discuss below.

Flumotion (gst 0.10)

These images build off of an Ubuntu Precise base image. Not using Trusty is a limitation of (unported) Flumotion.

The issue I mentioned above, is that one of our dependencies (keyboard-config) I found impossible to install without input from the user. So, we actually use streamingsystem/precisebase that only has this dependency installed instead of using a base Ubuntu image.

Flumotion (gst 1.0)

The ported Flumotion! This image builds off of an Ubuntu Trusty base image(and no streamingsystem/trustybase nonsense here!).

Frontend/Website

This is the Streaming System frontend and it builds off of an Ubuntu Trusty base as well. Configuration here is kind of weird and it needs some work…