Process Improvement
How OPSY Lets Developers Start Containerized Projects Fast
It truly is a plug-and-play solution.
When creating a new enterprise-level microservices project, there are many tools that developers can use to make the process easier and less time-consuming. These tools vary depending on the project’s purpose and scope but mainly include cookie-cutter templates, kits, and scaffolding tools. Unfortunately, many of these tools can be opinionated and not enterprise-friendly (look at HTTP proxies, for example).
As with any project in active development, it may take many iterations until requirements and architectural design trade-offs are nailed down. Some basics are used in any project using Docker containers, though, such as including a Dockerfile, files that contain dependencies (this consists of a requirements.txt for Python projects or a package.json for NodeJS projects), security checks and balances, and more all integrated from day one. Although not strictly necessary, and even though some may have to go through a technical board for approval, why not leverage the power that open-source tools provide to jumpstart a new project?
Even if one decided to use an open-source tool to help streamline development, which would be used? Should you copy files from an old project or create something entirely new? At Perlogix, we’ve designed a slightly opinionated way to build and run microservices before getting to a formal environment with a container orchestration platform such as Kubernetes.
We call this OPSY.
What is Docker, anyway?
At a fundamental level, a reproducible build and the run process is preferable to start developing a project locally (and even in a single-server context) until a platform of choice is decided upon. Why is this a preferable approach? Well, scouring through hundreds or potentially thousands of lines of code to find out why a build worked on Heroku but not on ECS doesn’t seem like a very productive use of time. Besides cross-platform incompatibilities, if the project works on one developer’s machine but not on another’s out of the box, this can lead to more time being dedicated to troubleshooting what is going wrong.
Docker solves this problem by packaging all project dependencies and related code into an immutable container that will always run in the same way across any platform that the container is built and run on. This means that if a developer starts a Docker-based project on Linux, another developer on macOS or even Windows can use that same container to develop on, and it will perform exactly the same across each of these platforms.
The only file required for Docker to perform its magic is the all-important Dockerfile. This file lets Docker know how exactly to build and run the project. Other files can extend Docker further, like the .dockerignore file, preventing unwanted copies of sensitive or miscellaneous files to the created container.
What benefits does OPSY bring to the table?
Let’s think of application development like cooking a pizza. You can either make the dough from scratch (DIY approach) or buy some pre-made dough from the store (open-source integration approach). However, even with the store-bought option, you still need to cook the dough (refactor Dockerfile, integrate the new tool into a project) to get it into a state where you can start adding all of the other ingredients. OPSY relieves you of having to both make the dough and cook it. We provide fresh-baked pizza dough ready for you to start adding ingredients to it. Minimal to zero cooking time required!
If you already have a project and want to integrate OPSY into it, all you have to do is drop in the related files specific to the language you have your project in and change the entry-point in the Dockerfile to be the main file you want to run (whether that be a main.py or a server.js). OPSY provides a base Docker configuration and opinionated .dockerignore and .gitignore files to modify freely.
OPSY also helps developers catch common security mistakes made during application development. Suppose an important secrets file is sneakily trying to make its way into the built container, the provided gitleaks.toml file is used to snag these files in their tracks and prevent the container from being built further. With this, developers can be assured that they aren’t accidentally sharing secrets.
Using start.sh You can quickly spin up a Docker container within a specific language folder, post-build status to Slack, and even generate an OpenSSL certificate. After testing, you can also remove all unused images using the same shell script to free up space.
Besides Docker, what else can I do with OPSY?
Along with a catalog of programming language folders equipped with the basics to start containerizing projects, OPSY also comes with some Vagrant environments for Amazon EC2 and Lightweight Kubernetes (aka k3s). These environments help streamline virtual environments to test out Kubernetes or EC2 clusters without leaving a mark on the host OS.
The final few files are specific to Linux servers and include:
- A maintenance script that updates all packages on the system cleans unused Docker resources, cleans cache and log files, and even trims an SSD if present.
- .bashrc and .zshrc files with opinionated defaults and aliases that you might find helpful.
- A default Starship configuration file complete with custom emoji for different git statuses.
- A security script sets permissions on system files to ensure that the server or system being used can’t be easily tampered with.
This all sounds great, but how do I try it out?
Downloads and documentation are available at our GitHub project page:
https://github.com/perlogix/opsy
Each language’s folder also includes a basic README that you can leverage to add your project’s documentation.
Huge credit to Tim Ski for the project and idea behind OPSY! We hope you’ll find it an indispensable part of your DevOps toolkit.
