When I was making my first switch from a product engineering team to being field facing software engineer, one of my first projects was an integration project for a federal agency. The very first piece of enterprise software minus my productivity and development suite I was exposed to was BMC’s Control-M about 15 years ago. A lot of batch files to extract and transform data had to be run in order and on a daily basis; Control-M at the time was a job runner.
Fast forward to the Kubernetes days [e.g today], and Jobs are still a very valid use case for Kubernetes. Since Shipa 1.6.0, Jobs support has been included inside Shipa. As of our current version of Shipa, 1.6.4, Jobs can now be exposed via the UI. If you are curious about Jobs, the first step is some background on Kubernetes Jobs.
What is a Kubernetes Job?
Imagine that you wanted to calculate PI and needed some computational firepower. There are a few models that would fit that depending on if you want to do that on the client or server-side. If you were architecting today, you might throw the calculation into a function like a Lamba. Though if you need even more concurrency, control, or firepower, a good option would be a Kubernetes Job. A Job in the Kubernetes sense is a short-lived workload that gets scheduled and spins up a Pod to execute then terminates the Pod when the work is complete.
Jobs can also spin up multiple Pods for needing to run items with multiple iterations and even concurrently/in parallel. Historically, running batch jobs on Kubernetes was important that systems that played into how Kubernetes itself was designed such as Google’s Borg and FaceBook’s Tupperware were job runners and schedulers initially. Even Apache Mesos had its start as a job runner and task scheduler. Ironically, you might just think of your workloads on Kubernetes as just really long-running Jobs. Though if you never used a Kubernetes Job before or looking for a better way to expose Jobs to developers, let’s take a look at Shipa Jobs.
Your First Shipa Job
Head over to Shipa Cloud; if you don’t have a Shipa Cloud account, sign up for free and forever. Assuming that you have a Kubernetes cluster connected to Shipa and a Shipa Framework created, you are ready to create a Job.
As a refresher, you do need a Framework [logical home for your abstractions] and a Kubernetes cluster to execute on. If you don’t have a Framework, you can create a basic Framework by going to Frameworks and + Create Framework. Can name the Framework something like “job-framework” then hit create.
With those Shipa Objects out of the way, you are now ready to create a Job.
Shipa Cloud -> Applications -> Jobs Tab -> +Create Job
Now you are ready to fill in some details. Let’s run a basic example, saying “howdy”.
Name: howdy
Framework: job-framework
Team: shipa-team
Restart Policy: never
Click Next and now you can wire up the Container Definitions. We only need one, we will use a busybox base image.
Container No 1:
Container name: busybox
Image name: docker.io/busybox
Command: echo howdy from my first Job!
Then click Create and you are off to the races.
Run the Shipa CLI Command “shipa job list” to get more information.
Just like that, you just ran your first Shipa Job. Be sure to stay tuned as we continue to add features to Shipa Cloud to make Kubernetes an afterthought.
Cheers,
-Ravi
