Generally speaking, Nanobox treats containers as lightweight VMs. So, many concepts from docker swarm or kubernetes won’t track with our system. If you’re familiar with solaris zones, the way we treat containers is very much like a solaris zone.
At a high level, docker (swarm) and kubernetes are moving the process management, logging, supervision, networking, etc out of the container and into the orchestration layer. Details aside, conceptually, they are moving pretty aggressively towards the notion of running simple processes inside of a namespace and a filesystem chroot, then the orchestration layer handles everything else.
Ultimately, the developer is left to define the service details in every implementation, like which commands to run, etc. I don’t necessarily think that’s a bad thing, in fact I think the implementation of kubernetes’ pods is pretty clever, thats just the direction they're going.
Our system was designed differently, on the notion of autonomy. Essentially, a docker image should have everything that it needs to fulfill a responsibility across different roles and states. Then, the orchestration framework will do two things: 1 - run the container (lightweight vm) and 2 - inform it how it should perform.
I’ll give you a simple example: Consider a postgres database. A postgres database can be a standalone node, it can be part of a cluster, it can be the leader of a failover setup, it can be the follower, or it can simply be a backup node.
Our system was designed for a container to come online, and then inform nanobox of it’s capabilities. Sometime later, nanobox can simply tell it to change roles, and it will do it. Nanobox doesn’t have to know anything about how to do that, it can just say “hey database, become the leader” and it will do so.
All of the logic to implement that behavior and functionality is completely encapsulated within the docker image, and consequently, within the container that uses that image. Nanobox ultimately becomes a very powerful control plane, that can completely alter the state and form of an entire cluster, just by starting containers and telling them what to do.
We designed it to mimic an organization of real people. You can (hopefully) tell someone on your team that something needs to be done, and assuming that individual has that skillset, they will do it. You don’t have to setup the perfect ecosystem for them to be able to carry out simple responsibilities, and then spoon-feed them instructions.
I’m not saying that kubernetes and docker are going about it wrong, but they are following the same path as systemd, which was to do as much as possible in one big layer. We tend to prefer the unix philosophy even at a service orchestration level.
I’ll show you a real example, using redis, since redis is crazy simple:
First off, the Dockerfile, you’ll notice that it only installs software. It doesn’t make any assumptions about how and when it will be used: https://github.com/nanobox-io/nanobox-docker-redis/blob/master/4.0/Dockerfile
One of the things it installs are hooks: https://github.com/nanobox-io/nanobox-hooks-redis/tree/master/src. Hooks allow nanobox to “hook” into the service
The first hook being the “plan” hook. https://github.com/nanobox-io/nanobox-hooks-redis/blob/master/src/plan. The plan hook tells nanobox what behaviors and topologies it can be used for.
By default, when the container comes online, redis won’t even be started. When nanobox needs that service to be started, it runs the “start” hook: https://github.com/nanobox-io/nanobox-hooks-redis/blob/master/src/start. But, nanobox doesn’t know how to start redis, that is up to redis to know how to start itself.
Same with configuration. Nanobox will provide the “configure” hook some generic data, and redis will use that (or ignore it) however it needs: https://github.com/nanobox-io/nanobox-hooks-redis/blob/master/src/configure
This is the framework: Containers are simply agents or actors. They are smart enough to implement the service, behaviors, and topologies on their own. Nanobox is responsible for telling them what they should be and when, but not how to do it. Essentially, we're encapsulating behaviour (hooks) inside services (containers).
The end result is a very flexible system with incredible automation.
So in a lot of ways, comparing nanobox to kubernetes or swarm is really difficult, because they really want you to define a service with specific run commands. IE: this service == these containers with these commands. Nanobox is much more than that.
Nanobox expects to be able to compose services across various states and configurations. Meaning, and you’ll see this in the coming weeks, nanobox will let you take a database, convert it into a redundant cluster, and then convert it back. The data will stay around while that happens. Also, and you’ll see this in the coming months, you’ll be able to move an entire app to a different datacenter. All of that is possible because nanobox can remote-control the services in realtime.