This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.The next post in the series is
here.
This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
Let’s take a break from Java Batch and look at something related but totally different, just for a little bit. I was reading about Kubernetes Jobs and trying to figure out how it might interact with Java Batch. I thought I’d share what I learned. To be clear, I’m not an expert in Kubernetes or Kubernetes Jobs, so there’s a fair chance I got something wrong or at the very least that I’m oversimplifying something. And, of course, I’m just rambling along here and not endorsing it or anything like that.
So Kubernetes Jobs is still just some YAML that you use with kubectl to get pods created and running your stuff. In the YAML you specify a ‘kind’ value of ‘Job’ and there’s a spec section where you put all your stuff telling it what you want done. Down in there is the ‘command’ where you actually specify the thing that’s going to happen when all this gets spun up.
And what might that be? Well, it is probably a script that’s going to run a bunch of stuff that includes whatever your job is. Maybe it starts a JVM to run some Java stuff or maybe it runs something else entirely. If you run some Java, does that Java implement the whole ‘job’? Maybe. The Kubernetes Jobs stuff has a few different models you can use depending on how you think about what you want each instance to do. We’ll get into that in the coming weeks.
A very important thing about Kubernetes Jobs seems to be how the command completes. The returned value from the command indicates whether the instance was successful or not. That’s going to tie into restart handling and a bunch of other stuff.
Well, what would that return value be? If you ran a script it is going to be the return value from the script. Which could be whatever you want. If you launched a JVM then the JVM would have exited with a completion code and maybe you could propagate that back out, if that value indicates whether your application was successful or not.
Of course, if you started a Liberty server to run a JSR-352 batch job inside the pod, the server will just stay up after the job completes. You’d need to find some way to indicate to the controlling script that the job was finished and it should take down the server. And some way to propagate the exit status value (a String remember) into some sort of returned value from the script that launched it all.
Well, all we’ve done so far is use Kubernetes Jobs to run something and we’ve got some stuff to think about. Next week we’ll look at some of the simpler controls.