Explore different tools & platforms for hassle-free and easy management of K8s clusters, here in this blog. Read further to know more!
The Rise of Containers
Today, it wouldn’t be wrong to consider containers and microservice-based architectures as key threads in the fabric of next-gen tools and technologies to modernize enterprise applications. The basic concept behind the approach is to replace traditional, monolithic app development with a Microservices architecture supported by the cloud, API-based services, CI/CD pipelines, and cloud-native storage.
But how easy is the adoption of these advanced tools? Do you have the basic foundation and setup for adopting containers and is your container strategy sustainable for the long haul? These are some of the many challenges that organizations face while adopting containers.
No matter where organizations are in their cloud journey, cloud cost optimization remains an essential and top-priority concern. As organizations align increasing workloads to the cloud in terms of size there is a high possibility to lose sight of the overall cloud environment and the costs associated with it. Therefore, it’s essential to optimize cloud costs so as to maximise return over investment (ROI). With the same concern we were working towards reducing the cost of provisioned storage for one our clients. This post covers a particularly interesting issue around the same.
When I set forth with my journey of containerization with docker, I have gone through a misconception that Overlay networking in docker can’t be set up without any orchestrator like Docker swarm, Kubernetes. But after spending some time with containers I realized that I was wrong, Orchestrators leverage the functionality of overlay networking but it is not true that we cannot use overlay networks without any swarm or Kubernetes.
In the modern world, the container is a fascinating technology, as it has revolutionized software development and delivery. Everyone is using containers because of its dynamic, scalable, and isolated nature.
People do use some orchestration software such as Kubernetes, Openshift, Docker Swarm, and AWS ECS, etc to run their production workloads on containers.
Recently I was working on a project which includes Terraform and AWS stuff. While working on that I was using my local machine for terraform code testing and luckily everything was going fine. But when we actually want to test it for the production environment we got some issues there. Then, as usual, we started to dig into the issue and finally, we got the issue which was quite a silly one 😜. The production server Terraform version and my local development server Terraform version was not the same.
After wasting quite a time on this issue, I decided to come up with a solution so this will never happen again.
But before jumping to the solution, let’s think is this problem was only related to Terraform or do we have faced the similar kind of issue in other scenarios as well.
Well, I guess we face a similar kind of issue in other scenarios as well. Let’s talk about some of the scenario’s first.
Suppose you have to create a CI pipeline for a project and that too with code re-usability. Now pipeline is ready and it is working fine in your project and then after some time, you have to implement the same kind of pipeline for the different project. Now you can use the same code but you don’t know the exact version of tools which you were using with CI pipeline. This will lead you to error elevation.
Let’s take another example, suppose you are developing something in any of the programming languages. Surely that utility or program will have some dependencies as well. While installing those dependencies on the local system, it can corrupt your complete system or package manager for dependency management. A decent example is Pip which is a dependency manager of Python😉.
These are some example scenarios which we have faced actually and based on that we got the motivation for writing this blog.
To resolve all this problem we just need one thing i.e. containers. I can also say docker as well but container and docker are two different things.
But yes for container management we use docker.
So let’s go back to our first problem the terraform one. If we have to solve that problem there are multiple ways to solve this. But we tried it to solve this using Docker.
As Docker says
Build Once and Run Anywhere
So based on this statement what we did, we created a Dockerfile for required Terraform version and stored it alongside with the code. Basically our Dockerfile looks like this:-
In this Dockerfile, we are defining the version of Terraform which needs to run the code. In a similar fashion, all other above listed problem can be solved using Docker. We just have to create a Dockerfile with exact dependencies which are needed and that same file can work in various environments and projects.
To take it to the next level you can also dump a Makefile as well to make everyone life easier. For example:-