Containerize all things?
Containers seem to be the only answer these days for how applications should be deployed, especially in the web-scale and microservices systems models. In jumping on the container bandwagon, most developers see a real benefit in a reduction in the operations burden needed to implement a service, as the focus is almost exclusively on the actual process thread that implements the function being deployed. For example, a rails application that required the implementation of an operating system (which needs security and upgrade management), the web server, the ruby web server interface, and then the ruby application environment is simplified by removing the underlying OS from the equation. Containers do have some complications in deployment still, and those complications are perhaps best handled by an underlying management layer.
Why there is more to implementing containers than just containers
There is no requirement that Docker containers are actually implemented on a virtual service platform, and in fact many are deployed on physical infrastructure (e.g. the Docker management daemon runs directly on a Linux OS on a physical server). This is the simplest deployment model, and the infrastructure operations can often be handled by the now classic compliance driven automation tools like Ansible, Chef, Puppet, Salt, etc. However, this model doesn’t include cluster deployment services that adds another layer on top of the physical platform. As it turns out, while containers do provide good segregation from the base Linux kernel, there are still plenty of options for how the container can impact the underlying operating system. This is especially true if the processes are run as the root user, and the container has been granted access to the underlying Linux file system… So running containers are may well require more than- just containers. A second layer of automation may be required below the container solution (not to mention the likely need for a layer above the basic container service to provide cluster level process distribution and management).
~ OpenStack Magnum does not manage containers directly, rather it manages container management systems, such as Mesos, Kubernetes, and Docker Swarm, that in turn manage the containers.
How Magnum’s approach to container management is different
If we are going to automate the deployment of the underlying infrastructure, and also need to implement automation of the overlay container cluster manager, it makes sense to look at a holistic solution, especially given that most application environments have yet to be able to roll 100% over to containers as their only deployment model. So providing a solution that can enable containers, perhaps even on a per-project basis, and still manage virtual and even physical systems in one consistent abstraction is perhaps very useful. And this is where the Magnum project fits; OpenStack Magnum provides an abstraction to deploying clustered Containers on an OpenStack targeted infrastructure. The underlying components are most often virtual machines, but there is nothing that currently limits deployments to using the OpenStack Nova interfaces into only virtual endpoints. This means containers could be deployed to physical or virtual infrastructure depending on performance, capability, or just resource availability metrics.
Given that Magnum doesn’t just manage the deployment of a single virtual or physical resource, but instead looks at the cluster level of a deployment, it can be used to deploy a company wide container environment, or it can deploy a container cluster on a per-project basis. Its ability to provide and manage multiple isolated clusters of container systems further provides flexibility. With Magnum in place, there is no longer a need to decide if Docker, Kubernetes, or Mesos is the container solution for the entire enterprise or an given project. Run one, run all. Magnum provides the tooling for engineering teams to enable a migration to a container or microservices deployment architecture by leveraging both virtual and container based components while providing the flexibility to deploy and change the actual container management technology implemented.
With Magnum in place, there is no longer a need to decide {on} #Docker, #Kubernetes, or #Mesos... Click To Tweet