12 Sep 2016 in Docker, DAB, Kubernetes, Kompose

Push a Docker DAB to a Kubernetes Cluster in Two Commands!

Docker Distributed Application Bundles (DABs) are "an experimental open file format for bundling up all the artifacts required to ship and deploy multi-container apps." DABs contain a complete description of all the services required to run an application, along with details about which images to use, ports to expose, and networks used to link services.

A little over a month ago, I wrote about DABs and outlined how they can be used with multi-tier apps to develop locally with Docker Compose and then bundled for deployment to a Docker Swarm cluster.

In this post, I will expand on my previous post and show how DABs can be used to make an artifact that is deployable on a Kubernetes cluster.

Why? Because by doing this we can take advantage of the awesome develop experience that the Docker tools provide to deploy artifacts to a production-ready Kubernetes cluster without needing a whole bunch of Kubernetes experience. Win win.

Note: DAB files are still experimental as of Docker 1.12.

Read More
9 Sep 2016 in Kubernetes, logging, Sumo Logic, Logentries

Off-Cluster Kubernetes Logging With Sumo Logic and Logentries

One of the best parts of my job as a solutions architect for Deis is working with an amazing array of talented engineers at companies solving truly interesting problems.

I was recently working with a company on the forefront of wearable fitness trackers. Their modest but world-class engineering team had reached the outer limits of what could be done with Ansible-based Docker deployments in AWS.

While everything worked, there were areas of API entanglement, and a lack of orchestration that created duplicated effort and an inefficient use of EC2 resources. The company is clearly on a rocketship growth trajectory, so scaling and efficient systems management are forefront on everyone's mind.

Fortunately, they also recognized that the time to pivot to more efficient and scalable architecture is while they're still in an early growth phase.

Kubernetes provides the perfect fit for their use-case because it allows a more atomic service distribution, scaling, and painless service discovery. Also, when the infrastructure below the cluster is configured with autoscaling, rapid growth should be no problem.

In this blog post, I'll take a look at one aspect of the work I did with them: how I got logs shipped off-cluster to Sumo Logic. I will also draw a link to some work I did for another company to send logs to Logentries.

Read More
9 Sep 2016 in Workflow, Release, Announcement

Deis Workflow 2.5 Release

The best way to roll into the weekend is with fresh software, hot off the presses. The Deis Workflow team just merged the final charts for 2.5!

We've got a ton of functionality packed into 2.5, so hold on to your horses!

Workflow 2.5 includes initial support for Kubernetes Horizontal Pod Autoscaling. Which is not only a mouthful, but pretty neat to boot. Workflow 2.5's theme song is "Glassworks" by Philip Glass. I'm pretty sure this is what a Horizontal Pod Autoscaler would sound like if it made noise.

Cast scale at the darkness...

Setting a scaling policy for your application is straightforward. Policies are set per process-type, which allows developers to easily scale processes independently:

$ deis autoscale:set web --min=3 --max=8 --cpu-percent=75
Applying autoscale settings for process type web on scenic-icehouse... done
Read More
7 Sep 2016 in Helm, Kubernetes

Trusting Who's at the Helm

Last year at KubeCon in San Francisco, I first learnt about Helm—a sort of Homebrew for Kubernetes. It seemed too good to be true, so I dug deeper. Fast forward to today, and I find myself packaging applications with Helm.

In this post, I'll talk briefly about why Helm is so exciting, and then show you how to install and use one of the packages I wrote.

Why Use a Package Manager?

A team I worked with was deploying various components to Kubernetes, including: Zookeeper, etcd, Consul, Cassandra, Kafka, and Elasticsearch. Each one of these components was using a manifest file that someone on the team had written by hand, and then these manifest files had been improved over time. Each change, each improvement, reflecting some sort of knowledge or experience the team had gained.

But there are many teams across the world deploying these same components. And let's face it, most deploy situations are similar enough. So each one of these teams is, for the most part, duplicating each other's work.

But what if there was a way to avoid that? What if we could organise that collective knowledge and bring people together to collaborate on it.

Read More
6 Sep 2016 in Helm, Annoucement

Helm Alpha.4: Persistent Storage, Improved Status, Provenance Files, and API Version Checking

Helm 2.0.0-alpha.4 is the penultimate Helm Alpha release. This new version introduces four major changes:

  • ConfigMap storage is now the default backend. When you create a release with Helm, the release data will be stored in config maps in the kube-system namespace. This means releases are now persistent.
  • helm status got a much-needed overhaul, and now provides lots of useful information about the details of a release.
  • The Tiller server now checks the apiVersion field of manifests before loading a chart into Kubernetes. Now, for example, a chart that uses PetSets will stop early if it detects that the Kubernetes installation does not support PetSets.
  • Helm can now cryptographically verify the integrity of a packaged chart using a provenance file. To this end, helm package now has a --sign flag, and several commands now have a --verify flag.

In addition to these, the Helm community has added numerous improvements and bug fixes, including:

  • Fixing a bug that prevented some installations of Alpha.3 from executing helm list
  • Limiting the length of a release name
  • Adding an icon: field to Chart.yaml
  • Improving helm lint and helm upgrade

During this cycle, the Kubernetes Helm community surpassed 50 code contributors, many of whom have contributed multiple PRs! We cannot thank you enough. ❤️

Getting Started

This is the second release of Helm that includes pre-built client binaries.

To get started, download the appropriate client from the release, unpack it, and then initialize Helm:

$ helm init

This will configure your local Helm, and also install and configure the in-cluster Tiller component.

What's Next

The next release, Alpha.5, marks the last major feature release before we focus on stability. You can expect to see helm rollback implemented, along with better version support, and the addition of a dependencies: section in Chart.yaml.

After Alpha.5, the Helm team will focus on closing bugs and improving stability as we sail toward a Helm 2.0.0 final release.