Storage in PaaS: Minio and Deis

Storage in PaaS: Minio and Deis

Whether you notice it or not, as an end user, storage is an important component of almost all the software we use today. As a developer however, it is important is to be able retrieve stuff in an easy yet secure and fast way. As I mentioned earlier, Object storage is a great way to achieve this. We also saw how to create a reliable data store, taking WordPress as an example. In this post, we’ll see how Deis, an open source PaaS based on Kubernetes uses Minio for almost all of its storage requirements. But first, introductions.


Simply put, Deis is a platform that lets developers easily deploy and manage their applications. By easily, I mean developers can deploy their code with a simple git push — Deis handles all the building, packaging and deployment processes. We’ll see how it does that in a while. With Deis, developers can also manage the application configuration, create or roll-back releases, get extensive logging and more. Deis is available via command line or REST APIs. Read more on Deis website.

Right now, there are two Deis flavors available. First is Deis Workflow (Deis v2.0) based on Kubernetes. Deis Workflow is in beta, so expect a few things to change in due course of time. Second is Deis v1.13.0, based on CoreOS. It is a long term support release and there are no further features planned for this line. Deis Workflow is supposed to be the successor of Deis, and hence, we’ll limit our discussions to Deis Workflow.


Minio is a minimalistic object storage server written in Golang. Minio server, client and SDK are API compatible with Amazon S3 cloud storage service. If you’re wondering what all these elements are for — Minio server lets you store unstructured data files in a safe, reliable and easy to retrive way. Minio client is S3 compatible implementation of common file handling commands like ls, cp, mkdir, diff and more. Minio SDK lets you embed Minio APIs in your own applications.

For any queries about Minio, head to our Gitter channel. We’re pretty active there and will love to help you out!

Minio in Deis

To understand better, think of Deis as a group of self-contained components that communicate using both the Kubernetes system and an object storage server. There are three deployment methods available in Deis

  • Buildpack deployment: Deis supports deploying applications based on Heroku buildpacks. With this method, you can deploy applications already running on Heroku or applications that follow Heroku best practices.
  • Dockerfile deployment: Deis supports application deployment via Dockerfiles. So, you can simply push the code and a Dockerfile creates the Docker image to be deployed.
  • Docker Image deployment: You can also deploy applications via an existing Docker image. To do this, you’ll have to create the image locally and push it to a public Docker image registry (e.g. DockerHub). Then use Deis pull to deploy the application from the registry directly.

All of the three deployment methods, as well as Deis Workflow internals like postgres, registry and builder components use Minio extensively behind the scenes:

  • Buildpack deployments use Minio to store code and slugs.
  • Dockerfile deployments use Minio to store Dockerfiles and associated artifacts.
  • Docker Image deployments use Minio as the backing store for the internal Docker registry that Workflow runs.
  • The internal Workflow database stores user login information, SSH keys, and more. It backs all data up to Minio.

Minio & Deis in action

To see Minio in action while using Deis Workflow, you’ll need to have Deis Workflow installed. When the Deis Workflow has all its pods running, you can see Minio pod among them. This pod is responsible for backup of critical user and application data. You can install Deis Workflow by following these steps:

  • Install Helm Classic and Deis Workflow CLI tools: Deis CLI lets you interact with Deis Workflow. Ideally, you should install the client in your $PATH to avoid any -bash: command not found errors. So, change your directory to /usr/local/bin and then install Deis client by running:
$ curl -sSL | bash

Check if it’s working fine by:

$ deis version

Next you’ll need to install Helm Classic. Helm is a package manager for Kubernetes. We’ll use it to manage software in our Kubernetes cluster. Install it by:

$ curl -sSL | bash

Again, check if install is successful.

$ helmc version

Boot a Kubernetes cluster: Next step is to boot up a Kubernetes cluster. I have used AWS EC2 as the backend cloud. You can choose to use Google Container Engine or even your own laptop. Since we’ll use command line interface to interact with AWS, you’ll need to install AWS and Kubernetes CLI tools.

$ curl "" -o ""
$ unzip
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
$ curl -O
$ chmod +x kubectl

Once you are done, type

$ aws configure

and add the Key ID, Secret Access Key, default region name & the output format. You can now interact with your AWS account via the CLI. Now create a folder at a suitable place, that will serve as the home to your Kubernetes installation. Then download and unzip Kubernetes

$ curl -sSL -O
$ tar -xvzf kubernetes.tar.gz$ 
cd kubernetes

Now configure the Kubernetes environment

$ export KUBE_AWS_ZONE=us-west-1c
$ export MASTER_SIZE=t2.medium
$ export NODE_SIZE=t2.large
$ export NUM_NODES=2

Now that you’re ready, boot up the cluster using

$ ./cluster/

Install Deis Workflow: To install Deis Workflow, we’ll need to use the Helm package manager. First check if it can connect with your Kubernetes cluster.

$ helmc target

You should get a detailed list like this

This confirms that Helm can talk to your Kubernetes cluster (that we booted in the previous step). Next step is to add Deis charts repo to Helm.

$ helmc repo add deis

Then install Deis Workflow

$ helmc fetch deis/workflow-rc1
$ helmc generate -x manifests workflow-rc1
$ helmc install workflow-rc1

This will complete the installation process. But you’ll have to wait some more for the pods to be ready. You can check the progress using the command

$ kubectl --namespace=deis get pods

Once all the pods show a ready status, you can be assured that Deis Workflow is up and running. Here is how the status looks like.

You can see the deis-minio pod running, confirming that Minio is the default object storage used by Deis. As I said in the beginning, Deis Workflow can be thought of as a collection several pods — with each doing a predefined activity. Here you can see various pods in action.

While you’re at it, help us understand your use case and how we can help you better! Fill out our best of Minio deployment form (takes less than a minute), and get a chance to be featured on the Minio website and showcase your Minio private cloud design to Minio community.

Previous Post Next Post