Inspiration

Managing dev and test environments when developing a project is complicated business and consumes a ton of resources, especially for medium to large projects. For such projects, there's a tendency - actually, a real necessity - to have multiple dev machines. Everyone wants a piece of those dev machines and everyone wants it at the exact same time. We all know those moments when everyone's fighting for five minutes to deploy their own branch and how it leads to endless negotiations within the team, lots of time lost and an overall lack of efficiency and productivity. Moreover, these numerous, unwieldy and expensive machines are not even used to their full capacity. Generally, a dev/test machine is usually used at an average capacity of 20%-30%, which means most of the time it's just lying there needlessly consuming money and resources, waiting for someone to give it some attention.

What it does

KuberneteZ is here to save the day and fix all of the abovementioned issues. It uses the same resources for multiple projects and allows for the instantaneous deployment of an application in a collection of containers called a "pod", on a cluster of resources shared among projects. This way, each dev, QA or any other project member can have their own development environment. No, scratch that. As many dev environments as their heart desires, without using up extra resources.

How we built it

KuberneteZ uses - surprise! - Kubernetes! More explicitly, we used a local kubectl stack to deploy a complete application stack in a local Minikube cluster. We used community images for the classic stack employed within our company: nginx, php-fpm and mysql, complemented by shared volumes, so that any project can be deployed via this unique solution.

Challenges we ran into

  • The team was tragically unfamiliar with Kubernetes before we started.
  • Installing and configuring the tools locally proved to be a real challenge - no, this time it wouldn't even "work on local".
  • Configuring the services in a universal reusable playbook was a pain.
  • General understanding of the Kubernetes ecosystem was also bumpy.

Accomplishments that we're proud of

  • We actually understood Kubernetes! (Don't ask us to explain it, though.)
  • We've come up with universal solution that can be genuinely helpful to the company.
  • It works!!! Yeah, we can barely believe it ourselves.

What we learned

No matter how daunting a challenge may appear, you can always breathe in, take a step back and see the bigger picture.

What's next for KuberneteZ

We aim to perfect the playbook to make it production-ready and then carry out our plan for global domination. Well, actually, for mass adoption of this solution within Zitec. We plan to create a company-level cluster comprised of unique resources for all dev/test enviroments, where every product has its own namespace and every work environment is an independent pod.

Built With

Share this project:

Updates