Like many people in the IT industry, when I first heard about Docker, I expected it to be yet another fad. After all, containerization is not something that is new to Linux. Tools like LXC, Virtuozzo and OpenVZ all offer to run your OS and apps in a container and share resources. They all were around well before Docker.
Yet what set Docker apart, for me, was its simplicity. That was the driving force behind my conversion to Docker, which I discuss below.
Before we talk about how I came to adopt Docker, it's probably best if we figure out why it became so popular in the first place—not just for me, but for DevOps engineers everywhere.
First, and most importantly, Docker is a lot easier to grasp than other container technologies. Without having ever touched Docker, you can look at a sample Dockerfile and immediately figure out what is happening—when, and why. This has made something typically only used by system administrators easy to understand for all, and is a great way for developers to package their applications and ship them. It also allows them to rest assured that it will work, first time, every time.
Secondly, Docker has obtained a lot of strategic partnerships with the likes of Red Hat and Google, which has made it a standard tool across providers.
In addition, Docker is also very lightweight and can be used to get the most out of servers you are running, be they in a cloud or on local equipment in your office. This can allow you to quickly and easily spin up and tear down entire development stacks to test changes you are making without affecting other people's environments or workspaces.
How I started using Docker
Docker was something that my previous organization had consistently looked at using, but they were reluctant to take the plunge. When I changed jobs, I was thrown in at the deep end, using Docker, Kubernetes, and CI/CD tools (including Wercker) to internally build our apps and ship/ deploy them. This was initially daunting for both myself and other colleagues (who had started at the same time as me). However, we very quickly adapted to (and more importantly loved) working this way.
The ability to scale environments rapidly with little or no effort, move to running a new version of an application by just pulling the latest version of the container—and, most importantly for us, when we were new to this—access a vast resource of pre-built containers to look at, use and adapt to our own requirements (Docker Hub) was tremendous.
Very quickly, both myself and the colleague I was working closely with were big fans of this way of working, which had been so different to us just a few weeks prior. Before we knew it, we had pipelines configured in Wercker, had developed our own containers on Wercker to allow deployments to unsupported clouds, and loved playing around with it.
Fast-forward, and I changed jobs again, and moved to a smaller company which was an AWS house, where everything was containerized. If I hadn’t been converted before, I would be quickly. Deployments were rapid and painless. We were easily able to do rollbacks if something went wrong. In fact, as we were using Elastic Beanstalk (which is not the greatest of tools, but serves a purpose, and is somewhat ingrained now, although we are looking at changing it, but that’s for another day). When deployments were done, we doubled our environment size, ran half on the new version, and if a failure was detected, we never put those new servers into the ELB—meaning there is rarely, if ever, any impact caused by our deployments. And we deploy all day, every day.
Auto scaling is also fantastically easy with the use of containers, whether scaling up our number of Selenium-automated test browser instances, or our front-end web servers. It is truly effortless and fast. Throw in other tools like Consul and Vault for retrieving credentials and configuration items, and even changes such as migrating to a new DB server or changing a cache timeout are effortless.
Containers have truly changed the way I work. While some organizations still seem reluctant to adopt this way of working in production, mostly because of fears of bugs and support issues, I would certainly recommend that you try it in your development environments—and see if you, too, end up converted.
About the Author
Casey Rogers is an experienced Senior Infrastructure Engineer with more than eight years of experience working with some of the UK’s biggest companies and multinationals. Largely self-taught, Casey has long had an interest in IT and has been brought up around technology. In his spare time, Casey is always tinkering with new technologies and experimenting with new ways to do things.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!