VIII. Design container-ready development
Build in container - Test in container - Run in container
Since you got so far to reach this chapter the chances are that you already think Containers - which is brilliant! However, let’s re-wind a little first and look back how software development
used to look like, or indeed, still looks on non-containerised environments.
Depending on your Solution stack you’d be running .NET, Python or Java installations - just to name the few biggest ones. Possibly you’d also run multiple versions of these frameworks alongside each other.
You know - the typical
this app needs 1.1.5 framework, that app needs 1.3.2 frameworksituation…
This is very common, and once in a while such setup causes what we normally define a Dependency hell - where your code just stops working because of framework version conflicts.
There’s also much, much more serious problem with such setup, and that is the following situation.
But it works on my machine…
Sounds familiar? We’ve all seen it; you deploy software to a host and - bang - it doesn’t work!
The Container environment
All you need to do to have a modern, container ready environment is this:
Clean workstation: no frameworks, no rubbish, no magic installations, and no dependencies
Any OS: Windows, Linux, Mac
Docker installed: yes, all you need is that small Docker engine running on your OS
And do you know what’s best in all this?
You can now build software on Mac targeting Windows host or work on Windows machine writing software for Linux
With the setup above your software will now make use of
Dockerfile and Docker Images bringing the benefits of OS, dependencies and code encapsulation.
You will realise stability all across your
environment releases with fully automated CICD pipelines. And, finally you will embed
container native security into your workloads with adoption of the least privileged concept.
The Container way of working
The chances are that once you have your Container environment setup you will probably start
architecting your software with Microservices and Mesh in mind. We already know that microservice architectures introduce agility, fast release patterns and allow re-usability of components. However, microservices also bring few more concepts we need to consider from the
developing and testing container native solutions that are made up of more than one container? Normally you’d run instances of these components compiled from source code on your localhost, right?
The answer is, of course, run these in containers.
You could then either
build and run local containers or reference images from your
Container Registry, which normally would be your Development versions. Execute
docker-compose up and the infrastructure will be
up and running locally for you to develop against.
Docker installation offers you an option to run local Kubernetes cluster, simply check a box in Docker settings to start up Kubernetes. Alternatively, you can also install Minikube which is a small instance of Kubernetes running locally on your device.
Once you have
Kubernetes running locally, you’ll then be able to execute YAML Declarations on your local
k8s instance. These could be either single
Deployments. You can even deploy Helm Charts onto your k8s to re-create an
entire application stack to develop against.