Fun Challange Link to heading
Prologue Link to heading
A while ago, I stumbled upon an exciting challenge. The final goal is to create a minimalistic environment on Kubernetes (K8s) for running a small Web application of our choice.
Requirements Link to heading
For a task not to be so simple, there are some requirements:
- All resources must be defined in a code.
- Application must not use containers from Docker Hub.
- Use a programming language of your choice.
- Docker HUB containers are allowed for “infrastructure” parts like databases, cache, proxies.
- Solutions should be as simple as possible while applying best practices whenever see a fit for it.
Toolchain Link to heading
Use at least these tools from DevOps toolchain to provision your Web application:
- Minikube (local Kubernetes cluster) for container management
- Application Docker image created from Dockerfile
- Kubernetes YAML files or Helm Chart
- CI/CD: GitLab CI/CD or Jenkins pipeline
Deliverables Link to heading
- Use a public Git repository containing all the resources previously mentioned
- Put up a nice-looking and helpful README file. It should include sections for summary/introduction, installation, usage, dependencies, and whatever else would want for other people to read.
- Write a simple Analysis. Break down into sections what could be improved: deployment, scaling, security etc.
The Hurdle Link to heading
The most challenging for me was to come up with some appropriate application. There are numerous tutorials out there how to run PHP (Wordpress), Python (Flask) or Ruby (Spina) application inside the Kubernetes cluster. I wanted to do something more uniquely. What is the better place to look for an example application than in a library where are hosted millions of repositories? Of course, I am talking about GitHub. I had to dig up a project which is not yet containerised. Easier said than done. All popular and newest projects already have instructions on how to containerise them (running in Docker). I had to extend my search a little.
I’ve found a simple blog example written in Perl, which uses PostgreSQL for storing persistent data.
Mojo::Pg Link to heading
Mojo::Pg is a tiny wrapper around DBD::Pg that makes PostgreSQL a lot of fun to use with the Mojolicous real-time web framework. I’ve tackled the challenge by “Dockerising” this simple but non-trivial Perl application and adding all dependencies for running the app inside Kubernetes cluster.
A little history of Perl Link to heading
Perl gained widespread popularity in the late 1990s as a CGI scripting language. It also came very handily in cases where unique regular expression and string parsing abilities were needed. Later it lost the battle against PHP. It was more comfortable and convenient to copy the entire application to web space as every hosting provider had PHP already set up for you. Perl was not embedded in the web server so it couldn’t compete. Perl evolved into much more flexible and rich language. In my opinion, this flexibility referred to as TMTOWTDI is the main reason most programmers find it annoying to learn. Perl is one of the most hated programming languages according to Stack Overflow, anyway. But still, Perl work in a lot of projects.
As long Perl will come installed by default by most of Linux distributions, and it will be used in the process of building the Linux Kernel it will stay in our lives. 😉
Why Perl Link to heading
In the world of programming, the mainstream is broad. Enterprise software is written predominantly in one of a few major languages. For some, this means Java, for others, is Python or Javascript. Perl is not in this list, not is a trendy programming language. Choosing it for the challenge was me pointing out that “containerising” Perl web applications do not differ as putting into container any other app from your favourite scripting language like Python, JavaScript (Node.js), PHP.
Getting the hands dirty Link to heading
I’ve forked the project and added the missing pieces. I didn’t change the functionality of the application. You can find everything on GitHub and on GitLab.
Epilogue Link to heading
Each and every one of us is unique. Each of us also has it’s own learning style. Some learn by hearing and listening, others by reading or seeing pictures, and there are ones who learn by doing, and we are all unstoppable. In my case, the way to learn something is to do it. If I want to learn how to cook a family ragu, I’ll have a go at doing it. Online learning is becoming more and more popular. MOOCs - Massive Open Online Courses are picking up momentum. I use them to get me a better understanding of the topic, so after I can get my hands dirty with actually doing the stuff.
Whatever is your way of learning, remember “Progress. Not Perfection”
Excerpt Link to heading
- Dockerfile
- Try to follow Dockerfile Best Practices. For me, the most important rule is to never run process inside a container as a privileged user if a service can run without root privileges! In our application, this is the USER
app
. RedHat OpenShift S2I builder images are using USER1001
- Try to follow Dockerfile Best Practices. For me, the most important rule is to never run process inside a container as a privileged user if a service can run without root privileges! In our application, this is the USER
- docker-compose.yml
- It is just used for testing the multi-container Docker applications locally.
- README.md
- The file contains a few information about the application.
- ANALYST.md
- The file has some ideas on how to improve the deployment, for simplicity, the app is missing some production-ready features, but they could be easily added.
- Jenkinsfile
- Declarative Jenkins pipeline without deployment stage. It’s an ideal solution for the simple continuous delivery pipeline as it has very limited and pre-defined structure.
- gitlab-ci.yml
- Simple GitLab CI/CD pipeline without deployment stage. It can be seen in action in Pipelines page.