Zero to Hero: Docker and Kubernetes in Production - Part 2) Dockerising your applications

by Mike Daniel

Hello and welcome to part 2 of my Zero to Hero series to help you go from knowing nothing, to hopefully knowing something about using containers and orchestrating them in production environments. I'm Mike and, with luck, over the coming posts I'll be able to impart some of the knowledge I've acquired whilst being a Technical Director and Founder at startups and SMEs in an easy to digest way. If you want to connect, feel free to reach out to me on Twitter @MikeDanielDev.

If you read the first part of this series, you'll have been introduced to the concepts behind Docker. Fundamentally, it's about packaging applications so they have everything they need bundled in one, easily deployed "container". Read

Thinking Containers.

Before you begin moving your application into a container it would be good to get us thinking in a slightly different way. I personally really like the concept of the 12 Factor App which is a methodology for making applications in a far more robust and versatile way. What I like about it is that it works for applications of all shapes and sizes, and you can pick and choose the factors that are applicable to your application. I'd recommend a read through when you have some time.

With that, here are some things to think differently about.

1) Think isolated applications.

You may have had multiple applications with all their dependencies in the same place before, but all this will change when we move to containerised applications. So from now, try to think of each application in your product as separate entities with their dependencies isolated from each other.

You can start by planning which applications will go where and which applications need to talk to each other.

2) Think immutable, transient code.

Your container will have absolutely everything your applications need, your code will be in a state ready to run, bundled into an image that can be used and deployed anywhere without worrying about dependencies. But it will be immutable. You won't be able to change anything code-wise in the image and it would be bad practice to do so. Equally, your code is now transient. Containers will be freely shutdown and recreated (e.g. when there's a crash) and each time a container is recreated it will lose any changes that occurred in it (there should be none) and will be identical to the stored image in your repository.

You can start by thinking about what state your code has to be in to actually work. Do you need to compile it? Does it need a particular directory structure?

3) Prepare to abstract your environment & storage.

The natural outcome of number two is that since our code should be fixed in our image, we have to abstract out things that may be dynamic. Often many of these dynamic elements will be related to the environment the image is in, so naturally you'll be looking at using environment variables. Or, perhaps you have a part of your application where you need to persist data - such as DB or file storage - these will need to be identified as again, we shouldn't store these in our images.

Start by reading up on how to add environment variables to your stack, and then start using them for application configuration. Likewise, identify where you need to persist data.

Containerising your application.

And here we are. The time has come for you to Dockerise your application. And I'm merely going to point you in the right direction. If you've thought on and even implemented the first three steps mentioned above, then you'll be ready for the next steps. But be warned, this conversion of your app could take weeks, or even months. Remember to start small and build up. Your journey will be quite unique so I'll list some useful links to help you on your way.

Overviews.

Stack specific tutorials.

To be honest you could Google pretty much any combination of technologies and find a tutorial to Dockerise them. Go ahead and explore and migrate your application to Docker and we'll pick up the ball in Part 3 where we implement our Docker containers and show the world why we bothered to do this in the first place.