pocdeploy

5 min read

Background

I created this as a project to create a deployment tool to deploy various applications to Kubernetes. The task was to deploy a Proof of Concept (POC) Django application frontend with a CloudNative PG backend and Prometheus monitoring to a k8s cluster.

My brainstorming process was centered around two ideas. The first was that the job description’s “What you will bring” had the first bullet point to eliminate tediousness in daily work for all engineers. The second was what people do with a POC. They want to show it off, to other devs, Product, maybe even C-suite or the board! Instead of someone having to follow a list of instructions, where missing/mistyping one means nothing will work, wouldn’t it be better to type a single command and have it all done error free?

This led to the creation of pocdeploy. I wanted something that was simple to use but could also be easily extended to fit other use cases, because we’ll need to deploy the next POC and the one after that too! And if we give the developers a tool that makes it that easy, we can ensure they’re creating secure infrastructure every single time. Let the developers focus on development!

Design Decisions

I needed to make some changes to the frontend code to get it running how I wanted. I had to change DEBUG to false, configure the Postgres database, add a wildcard in ALLOWED_HOSTS, serve polls from the ‘/’ endpoint, add a SECRET_KEY, and add the WhiteNoise middleware to serve the static files. I decided to do these as patches because if there are any updates to the source code (bug-fix or security update) then it would be easy to apply and everything should still work. Patches can also be added or removed, and will do nothing if the patch directory specified is empty. The Dockerfile can also be easily updated or switched out to a completely different one as needed (as it will to deploy other POC applications).

There were some files that have no need, or shouldn’t be, edited. These include Kind specific configuration files and Terraform. These were embedded into the binary so the user doesn’t even need to think about them. They can be updated as needed, and new binaries distributed to ensure only secure configurations are being created.

The frontend and backend deployments are within the same namespace so that the CNPG secrets are easily available to the frontend application.

To Use

Clone the directory at https://github.com/harvey-earth/pocdeploy. Ensure all prerequisites listed in the README.md are met. Without changing any of the defaults, running ./bin/pocdeploy create will create a Kind k8s cluster named “test” with one control-plane node and 3 worker nodes running a patched version of the Django polls app with a CloudNativePG cluster backend and Prometheus monitoring. It additionally creates an admin user as specified in the pocdeploy.yaml file.

To cleanup the cluster run ./bin/pocdeploy delete.

If you move the binary to a different directory, you must have the pocdeploy.yaml file in the same directory or the your HOME directory. Additionally the patch_dir, path, and dockerfile variables must be updated to the appropriate values. patch_dir should be set to the directory containing any patches that should be applied to the frontend code. If this is an empty directory then no patches will be applied. path should be set to the directory containing the frontend code. dockerfile should be a path to a working Dockerfile to build the frontend image.

Once the setup is complete, the application will be available at http://localhost.

Further Improvements

v0.0.1 was a bit rushed as it was completed in roughly 6-7 hours of total time. Nevertheless, I enjoyed this and had much bigger plans that I will implement when free time allows.

  • Add tests
    • Need to mock the k8s requests/responses to ensure function changes don’t break. I also need to add return values for functions to be evaluated and tested properly. I wanted to get a working solution and am most embarrassed with the lack of structure I have set up for testing but had to trade testing for time. But this will be needed before new features.
  • Change verbosity
    • There is a lot of output, part of this is to assure the user that the process isn’t hung and is just a longer running process to get everything set up. I’d like to have some different log levels, and maybe even set up a progress bar.
  • CI/CD pipeline
    • Implement a pipeline that will run lint/test/etc and create downloadable releases (like elilogs).
  • Extend to public cloud providers
    • I had started to also do this with AWS, but creating a publicly reachable k8s cluster in the public cloud is not a task to take lightly. There are many scary things that can happen when any port is reachable by the internet, and security is a must. When extending this I have to ensure a secure configuration that is reachable from the deploying machine only (with the exception of exposing the frontend on HTTPS so people can take out their phones and test drive).
  • Use nginx to serve application
    • For the assessment it was sufficient to run the application with python, but there should be a true webserver to serve the application and static files.
  • Allow custom cluster names/ports.
  • Add autoscaler to frontend deployment.
    • This was also originally in the plans which is why the variable defining the deployment size contains “min”.
  • Remove shell commands.
    • A few things I just ran as shell commands with kubectl. This includes the install of the kind nginx-ingress and CNPG operator. These are long for translating to the Golang kubernetes SDK.
  • More backend settings.
    • Allow different versions and cluster sizes for the backend.
  • External repository.
    • Upload the created docker image to a public or private image repository.
  • update command.
    • Recreate and reupload the frontend image, bumping the version number and writing it out to the config file in the current directory and updating the deployment.
  • validate command.
    • Run checks to ensure all k8s components are configured and running correctly. Take actions to remedy broken/changed things.
  • Grafana install.
    • Install Grafana and dashboards to view the CNPG metrics.
  • Extend to other frontend frameworks.
    • “backend-init” and “create-admin” jobs will need to be extended for these frameworks.

Repository

The code for pocdeploy is at:

#programming go golang cli django kubernetes
Next elilogs