By Joe Brockmeier, Senior Evangelist, linux Containers, Red Hat
The conventional wisdom of Linux containers is that each service should run in its own container. Containers should be stateless and have short lifecycles. You should build a container once, and replace it when you need to update its contents rather than updating it interactively. Most importantly, your containers should be disposable and pets are decidedly not disposable . Thus the conventional wisdom is if your containers are pets, you’re doing it wrong . I’m here to gently disagree with that, and say that you should feel free to put your pets in containers if it works for you. What’s a Pet Container?
To take a quick step back, in case you’re new to the debate, what the heck is a pet container? A pet container is one that is treated like any pre-cloud standard (sometimes called “mode 1″) application or server. You hand-apply application and operating system patches to it, log in to do monitoring, or otherwise generally worry specifically about that system.
With containers, we’re supposed to have a full-blown continuous integration/continuous delivery (CI/CD) system set up to test our application from development to production. A developer creates a change, sends it into the CI/CD setup, eventually that builds a new container and it’s automatically spun up to handle work.
I’m generalizing, of course, but the idea is that there’s an automated workflow that creates a container and you shouldn’t really care about any specific instance. The old container is shut down and nobody cares or notices. If your “pet” system shuts down people notice, and quickly! So the industry is trying to move away from that scenario to provide better business value, agility, uptime, and generally help our IT folks stay sane. Not necessarily in that order.
What’s Optimal vs. What Works Right Now
To be sure, you get maximum value out of Linux containers if you architect your application to be cloud native . If you’re creating a new application, you should absolutely avoid creating a monolithic “pet” application.
But what if you don’t have the luxury of starting from scratch? What if you’re in operations and you’re trying to find the best way to manage and deploy existing applications?
“While you don’t get all the benefits from afully orchestrated multi-container applicationwith a pet container, you get several benefits”
One option is to carry on with business as usual and change nothing. Keep running existing applications on bare metal or in virtual machines.
A better option is looking at containerizing those workloads more or less as-is, to get some immediate benefits from the tooling around Docker-formatted containers. The dreaded so-called “pet” container.
Immediate Benefits to Pet ContainersWhile you don’t get all the benefits from a fully orchestrated multi-container application with a pet container, you get several benefits.
First, application isolation. If you have two or more workloads that can run side-by-side on a system in containers you don’t need to worry about dependency conflicts. Application 1, inside a container, can have a different version of python or a database than an application on the host or in a separate container. You can even move a workload based on, say, Red Hat Enterprise Linux 6 to a server running Red Hat Enterprise Linux 7. The container runtime can be Red Hat Enterprise Linux 6 and run on a Red Hat Enterprise Linux 7 system, so you can mix and match.
It also makes it easier to mix standard deployment methods (e.g. RPM) with language-specific deployment methods. Because Docker-formatted containers have versioning and other handy tools, it makes it easier to consume things from an upstream and roll back if you run into issues.
It also helps move applications from an on-premise environment to the cloud. Package up your “pet” and move it from Red Hat Enterprise Linux 6 internally to Red Hat Enterprise Linux 7 running in the cloud. No problem. Move it to another cloud provider if you get more favorable rates, again no problem. Run an instance on your laptop or in staging that is entirely identical to the one in production.
“Going all-in on a full-blown Kubernetes/Docker workflow might be a bit much for an IT department to chew all at once.”
Another benefit is that this serves as a gentle onramp to working with Linux containers. Going all-in on a full-blown Kubernetes/Docker workflow might be a bit much for an IT department to chew all at once. You can start to break out services if you find it useful. For instance, maybe you break out the database from your application to its own container. Maybe you separate front-end and back-end logic altogether into separate containers. Developers and operations can get a handle on the toolchain to work with Linux containers without having to change everything about the way they work.
You can also take advantage of single-purpose OSes like Red Hat Enterprise Linux Atomic Host to run your containers, and simplify maintenance on the host side.
Gradual Beats No MovementIn many cases, when you’re faced with radically revamping the way that a process works nothing moves at all. By adopting the pet model first, you can start down the path without having to blaze the trail all in one go.
If putting applications into “pet” containers shows a benefit, but the organization isn’t ready to go all-in, then by all means adopt the pet container model. It’s a step forwards, and it gives your organization more agility and room to grow. Is it perfect? No, but it’s better and it’s easy to do . Getting to “perfect” (or at least close) is a step or three closer. Even if you aren’t moving any farther right away, you’re still going to see benefits.
I also recommend reading Daniel Riek’s series on pet containers on the Red Hat Enterprise Linux Blog . He provides some additional detail and color on the road to full containerization.
In the meantime, take good care of those pets!
