Exercise 4: Your own PaaS

Now that you know how to use docker-compose and docker-machine, we’ve covered all the Docker basics. Congratulations!

This next exercise is more open-ended and intended to challenge you. You can make it as simple or complicated as you like - or work on something different altogether.

My intent with this last exercise is for you to start on a fun project that’s all your own, but still have the benefit of me and other students to help answer any questions you have.

Join the chat room for this exericse: https://gitter.im/atbaker/oscon-exercise-4

Warning

Okay, the gloves are really coming off for this one. I will point you to some relevant resources, but you’re going to have to figure out most of it yourself.

Do not feel bad if you don’t finish this exercise - it’s meant to give you a taste of a project that’s probably too much for today’s session.

Background

One of the most obvious applications of Docker is a Platform-as-a-Service (PaaS). After all, that was dotCloud’s business before they open sourced Docker and reorganized their company around its success.

If you are like most developers, you have probably used Heroku for at least a small project at some point in your career. It has been especially popular among developers because of its free tier - you could run a small app 24/7 for free.

In an undoubtedly wise business decision, it looks like those days will soon be over. Heroku is implementing new pricing schemes that reduce the “free tier” to only 12 hours a day.

So there’s never been a better time to build your own PaaS!

Open source projects like Flynn and Deis are powered by Docker and are great choices. But sometimes you want a small, stupid-proof tool that just does the essentials.

In this exercise, you will build a super-lightweight Platform-as-a-Service using Docker and the programming language of your choice.

Phase 1 (Minimum Viable Product)

The data scientists in your organization are always compaining that they can’t spin up new database instances easily enough.

Create a web application using Python that spawns a new Postgres database every time it receives a GET request to the /postgres URL.

Requirements

  • Must use Docker to start a new Postgres container for each request
  • Must expose port 5432 from the container to the host (but it doesn’t matter which port - you can let Docker decide)
  • Must provide some way for users to know what port their new container is running on so they can connect to it

Architecture tips

You can build this any way you want, but here are my recommendations:

  • To satisfy the last requirement, rather than code a UI, I would just use the DockerUI project. You will be amazed how easy it is to set up
  • If you decide to deploy your PaaS on a server, I would recommend adding lots of swap space to help ensure you don’t run out of memory. This tutorial could come in handy.

Note

Most docker-py commands map to the docker command line client, but one catch is that creating and starting containers are separate API calls. You will need to do both.

Phase 2

Version 0.1 of your [insert cool name here] Docker PaaS was a hit with the data team, but now they’re requesting a few more features. Typical.

Requirements

  • Let your users pull down any Docker image they like, exposing whatever ports are specified in the image (you can decide the best URL structure for this)
  • Add new endpoints to your app which allows users to start and stop their containers by going to /postgres/{container id}/start and /postgres/{container id}/stop
  • Implement some method to limit how many containers are running in the app at any given time. You could do a hard cap on number of running containers, or you could be more nuanced by checking available memory on the host

Thank you

That’s all the content I have for today’s session! Thank you for spending your morning with me.