Monthly Archives: June 2015

Triton Bare Metal Containers FTW!


If you haven’t heard of Docker, I’m not sure what cave you’ve been living in but here’s the short story:

Hardware level virtualization, like you are used to (VMWare, Virtualbox, KVM, Xen, Amazon, Rackspace, Azure, etc.) is slow and awful. Virtualization at the OS level, where processes share isolated access to a single Operating System kernel, is much more efficient and therefore awesome. Another way of saying OS level virtualization is “containers” such as have existed in FreeBSD and Solaris for over a decade.

Docker is hacking together a whole slew of technologies (cgroups, union filesystems, iptables, etc.) to finally bring the concept of containers to the Linux masses. Along the way, they’ve also managed to evolve the concept a little adding the idea of running a container as very portable unit which runs as a process.

Instead of managing dependencies across multiple environments and platforms, an ideal Docker container encapsulates all the runtime dependencies for a service or process. Instead including a full root file system, the ideal Docker container could be as small as a single binary. Taking that hand in hand with the growing interest in developing reusable microservices, we have an amazing tech revolution on our hands.

That is not to say that everything in the Docker world is all roses. I did say that Docker is hacking together a slew of technologies so while marketing and demos portray:

You are more likely to start with something like this:

Either way, tons of containers per host is great until you realize you are lugging them around on a huge, slow, whale of a cargo ship.

  1. Currently, Docker’s level of isolation between containers is not that great so security and noisy neighbors are issues.
  2. Containers on the same host can’t easily run on the same ports so you may have to do some spaghetti networking.
  3. On top of that, if you are running Docker in Amazon, Google, Azure, etc. you are missing the whole point which was to escape the HW level virtualization.

Joyent to the rescue!

Joyent is the only container based cloud provider that I’m aware of. They have been running the vast majority of my cloud instances (possibly yours as well) on OS level virtualization for years now (years before Docker was a twinkle in Shamu’s eye). As such, they are possibly the most experienced and qualified technical leaders on the subject.

They run a customized version of Illumos, an OpenSolaris derivative, with extremely efficient zone technology for their containers. In January (Linux and Solaris are Converging but Not the Way you Think), I wrote about the strides Joyent made allowing Linux binaries to run inside Illumos zones.

Triton May Qualify as Witchcraft

The love child of that work, announced as GA last week, was Triton- a Docker API compliant (for the most part) service running zone based Docker containers on bare metal in the cloud. If running on bare metal weren’t enough of an advantage, Joyent completely abstracted away the notion of the Docker host (ie. the cargo ship). Instead, your Docker client speaks to an API endpoint which schedules your bare metal containers transparently across the entire cloud.

Addressing each of the points I mentioned above:

  1. Zones in Illumos/Joyent provide complete isolation as opposed to Linux based containers so no security or noisy neighbor problems.
  2. Every container gets it’s own public ip address with a full range of ports so no spaghetti networking
  3. No Docker host and no HW virtualization so every container is running full speed on bare metal

Going back to the boat analogy, if Docker containers on Linux in most clouds looks like this:

Docker containers as zones on bare metal in Joyent look like this:

Enough of the FUD

I’m not a big fan of marketing FUD so I’ve been kicking the tires on the beta version of Triton for a while. Now with the GA, here are the pros and cons.


  1. Better container isolation
  2. Better networking support
  3. Better performance
  4. No overhead managing a Docker host
  5. Great pricing (per minute and much lower pricing)
  6. User friendly tooling in the portal, including log support and running commands on containers using docker exec.


  1. The API still isn’t fully supported so things like build and push don’t work. You can mostly work around this using a docker registry.
  2. Lack of a Docker Host precludes using some of the patterns that have emerged for logging, monitoring, and sharing data between containers.


Docker is a game changer but it is far from ready for prime time. Triton is the best choice available today for running container based workloads in general, and for production Docker workloads specifically.

At Codefresh, we’re working to give you the benefits of containers in your development workflow without the headache of actually keeping the ship afloat yourselves.  Sign up for our free Beta service to see how simple we can make it for you to run your code and/or Docker containers in a clean environment. Take a look at my getting started walkthrough or contact me if you have any questions.

Code Fast with CodeFresh!


In case you were wondering why I haven’t written a word in the past two months, the answer is CodeFresh. We’ve been working day and night with our private beta customers to make CodeFresh the fastest and easiest way for you to hack on your code.

What is CodeFresh?

It’s super simple. It’s super fast. It’s easiest to explain with a quick walkthrough:

First, go to and login with your Github or Bitbucket account:

Once you’ve authorized the application you’ll get a list of your repositories. 

If you’re part of an organization on Github, you can switch to the organizational context in the upper right corner:

I want to hack on the math-race project so I click “Launch”:

A div will pop up showing me the progress as CodeFresh clones the repo and automatically builds a Docker container with my app inside it. At the end of the process I get two green buttons – ‘Open in IDE’ and ‘Launch app’.

Let’s start with ‘Launch app’:

The browser opens up a new tab with my app which is already running but there is actually a problem (yes, I knew there was going to be a problem). When I fill in the name field, the game is supposed to start.

Let’s go back and open up the IDE. This will put me into a custom version of the Orion web based IDE, including a shell window running in the Docker container:

Specifically, I know that this app needs the host and port that the app is running on to be hard coded into the config.js file, so I’ll open that up in the IDE and give it the host and port from the tab the app launched in. Don’t forget to save the file.

Then click the stop and start buttons at the top of the IDE to re-launch the app.

Then I switch back to the other browser tab and hit refresh and everything is working:

I could just as easily have edited the files in vi from the terminal:

And once I’m done with my changes, I can commit them and push them back to git:

For the best experience download our chrome extension here:


Browse to a Github repo and click the Launch button.

You can also launch an environment for a specific branch straight from Github:

Or from a pull request:

Obviously you can do all this from the CodeFresh interface as well but with the extension you can actually run any SHA from any public repository on Github with a click.

As you can imagine, CodeFresh makes it incredibly easy to take a new repo and see if it suits your needs, or to test code in a new pull request before merging.

While you don’t need to know anything about Docker to use CodeFresh, we are Docker based so if you have a Dockerfile in your repo, we can use it to build your environment.

Anyway- that was a quick tour of the app but there are tons more features in there and we’ll be adding more and more features constantly so take a look and let us know what you think.

If you have any issues, the team will be happy to help- just click on the “chat” icon at the bottom right of the site:

Obviously, you can reach out to me as well.