IBM i DevOps TechTalk
DROPS – Part 2 #18

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. Today we’ll be listening to Alan Ashley, a senior solutions architect, and Jeff Tickner, the CTO of North America, discuss DROPS and deployment of software changes. Let’s listen in while Alan interviews Jeff.

Alan Ashley – So, Jeff, in the past we’ve talked about deployments and how it’s not only the IBM i, but we’ve got to deploy to multiple systems, whether it be Windows or Linux, on top of using the IBM i. And I know that ARCAD got DROPS and this can handle those multiple platforms. I keep hearing things like infrastructures code, different terms like this. How does that enhancement? How can we enhance DROPS using maybe some open system tools that maybe already in your environment going forward?

Jeff Tickner – So I always say, look at the tools you’re using already because you might very well have people that are familiar with them. And that’s one thing. And ARCAD, we’ve tried to keep all of our tools open and DROPS is very open. So I think we’ve talked about how you can have pipelines that invoke DROPS as a stage in a pipeline to automatically update QA, etc. So that’s getting DROPS started.
But we can start DROPS from anything. We’ve had customers start DROPS from project systems like Jira to start a deployment based on a update of a task. We can do it from a pipeline, any kind of pipeline, from command line. But once we get it started, DROPS really takes that infrastructure as code out to its obvious conclusion. And it exposes not just IBM i servers as targets as code, but of course other platforms. And you can talk to any platform, so we can package any type of artifact and hang on to it in a repository and then push it out synchronously. So I’m going to update my website and I’m going to update my DB2 database because I’m expanding a field, the classic example there.
And instead of everybody being involved all weekend, it’s DROPS doing it to test; It worked. Let’s do that same process out. And where we can enhance DROPS is by interacting with those tools that you might already be using. One of my favorites is Ansible. Ansible is amazing. And it’s really surprising. IBM put a lot of effort into porting Ansible to execute natively on the IBM i.
They have a GitHub repository full of Ansible playbooks and modules. They can do things like install PTF or check if they’re there. All kinds of cool stuff. And when we saw that, we integrated Ansible into DROPS. So if you already are using Ansible and you say, I’d like DROPS to orchestrate my IBM i deployments and my update of my webserver, but Ansible is shutting it down for me now so I can update it and then it starts it up.
You already have a playbook. We’re going to call that playbook for you at the appropriate time in conjunction with the update to the DB2 database. And we can even do stuff on the IBM i. Ansible cool feature is it has intelligence in its tasks. It’s modules. They’re written in Python, they’re open source, they’re from IBM.
You can go to IBM’s GitHub repository and pull all the Python and YAML down, and you can extend it. And what that means is they can check to see, for example, if you were deploying a cool new SQL feature in your business application and you say, I have to have this PTF before I deploy it. You can actually check to see if the PTF exists.
It would be a bit of a challenge in DROPS itself because it’s a lot of scripting. But here’s Ansible sitting there already having a task.

A.A. – And on Ansible, I’ve attended a couple of sessions at COMMON over the years, and one of the things that’s really come out is the IBM i aspect of Ansible, because of course it was written for the Linux side of things, and those types of systems. But now that the IBM i side has come in and like Jeff was mentioning, the ability to maybe go check for PTFs but not only check for PTFs, you can actually have it download them and install them as part of this process.
So this is oh, you’re missing SF 12345. Go get it and install it. And if it requires an IPL, let me know. Otherwise just install it. Another way you can search for these. If you just do a search for Ansible Galaxy, you can see a lot of information on it there as well and how this starts to tie in. You hear things like code assist and that’s where Ansible can tie into that as well. But when it comes to the DROPS side of things with tying in to Ansible, let DROPS do what it does, really. It’s really powerful about deploying and keeping those artifacts separate from each other and very consistent across deployments and license will do the heavy work.

J.T. – So DROPS is being open. It does have its own artifact repository, but I’ve integrated DROPS with other repositories like Azure Artifacts or Artifactory when that’s the corporate standard at a customer site. If they say, that’s great, you’re using save files, but I want them in my corporate repository. DROPS can interact with that.
But the interesting thing is we were talking about triggering DROPS. We actually did a project with IBM in Europe where they wanted to stand up in LPAR, and it was driven by a big old Ansible playbook. And they called DROPS from that Ansible playbook and DROPS part was to they stood up an LPAR in the cloud and DROPS part was to deploy all the DB2 files and populate them with data so that that portion, they did a container, a whole bunch of stuff.
Bu you can’t just think of one is the starting point and one is the ending point. It’s an ecosystem. And DROPS is integrated with that complete ecosystem of tools, yet to have an open mind. But again look at what you’re using at your company right now? Ask around, how do the web guys do it?
Because there’s a guy then at your company that knows how to use Ansible, that they’re using Ansible to deploy the web updates. And then when you say, I’d like to synchronize my DB2 updates with your web stuff, if they have a scripted process, it doesn’t have to be Ansible. They could have written a script themselves and DROPS can call it.
And now you have a synchronous process and you’re reusing the knowledge base, the subject matter expert you already have. All you’re doing is acting as an orchestrater. But of course, DROPS could do it all itself. You know that. That’s the thing. We don’t want to reinvent the wheel. If you already have a process, let’s just put it orchestration over the top of it.

A.A. – And DROPS drive and gather your multiple deployment processes, letting them come in and be run in parallel or serial depending on what your environment requires. Because sometimes you do have to have things run in serial right before it can go parallel because of just the way your infrastructure is defined.

J.T. – So the most important thing is the database. And most of the database lives on the i. DROPS now supports the Z also. So if you have a Z based database we support that now as well. So update the database. Start working on the user interfaces as a big synchronous deployment process that you can test before you try it against production.
That’s the interesting thing when people are stuck in that pizza party mode, we’re going to spend the whole weekend here because they haven’t tried it before. They haven’t tried all those moving pieces before. And here we can provide the overarching synchronization of all those moving pieces and have a reproducible process.
And you’ve built a framework for next time, it might be some work to set up the first time, but all you’re going to do next time is change the packages? And then next time it’s going to be even easier. And the time after that easier. Everybody’s going to be happier with you.

A.A. – One of the things that I’ve seen with DROPS is once you’ve got this process defined and let’s say you add another server into the mix. It’s really easy just to add that server into the flow; the various different diagrams and you can literally just go, we need to add a new environment. You add DROPS into the flow and it takes over.
And this is where we talked about Ansible a little bit here. Let’s say you drop this new server at. Maybe it’s back level on something. Guess what? Ansible is going to now pick that up and go: you’re missing these required PTFs. You can go: we’ve installed and things like that.

J.T. – We do actually for a large customer, large bank, lots and lots of IBM i. They want to do a upgrade of our tools and the open systems tools we were dependent on. And they asked us to build a playbook, that would update ARCAD and check PTFs and update some open systems tools that we needed.
And we did it across, hundreds of hours, so again, DROPS wasn’t involved. It was Ansible, but they were updating DROPS with Ansible. So once you have the steps involved, it’s reproducible. That playbook goes Python tasks. Those are now available for the next time, because there’s just infrastructure as code.
That’s what we started talking about in the first place. And so we’re just extending that out. That’s the benefit. You don’t start from scratch when you’re writing an RPG program. You can’t be something. Now you can do your deployments the same way: you copy something and you say, what’s different about this? If it’s just a package that copy is probably going to be fine.
If you’re adding in a new platform or a new server, then you just extend it out a little bit and DROPS makes it very easy to do that.

A.A. – And I do want to bring up the point of when you’re talking about DROPS. And we talked about just briefly at the beginning, the getting started part of this. And I do want to point out that Jeff talked about this whole process can be started from a JIRA ticket.
It can be started from an ADBS pipeline. It can be, whatever the case may be, because we’re kicking off a CLI behind the scenes saying basically start this deployment and then DROPS takes over and it can update the pipelines as it’s going through, as it’s moving through the process. So there’s multiple ways to get it started.
Of course you can always just go into DROPS and kick it off. But most things start somewhere a long way away and get triggered along the way and DROPS can pick up those triggers just as well as any other platform.

J.T. – And the CLI provides pretty decent logging too. I’ve always been happy with DROPS is aggregating all of the logs from all the processes it’s managing. And if you call it from the CLI, it pushes those logs back up to the CLI request. So you’re centralizing your logging as well.

A.A. – I will say that some of the logging and DROPS there’s a lot of information that you can find in there about each step that it’s going through. And so maybe even looking at this logs, you say, we need to add a step here or we need to clean this up here because we’re not seeing that.
And that’s like you look at the logs, it’s like we need to do this and then maybe go, I wonder if there’s an Ansible task that can handle this because particular if it’s on the i, Ansible as well on the i a couple of years now that it’s been really popular, there are a lot of builds over playbooks.
It’s a good idea what you can do. And as an old system admin, we didn’t have Ansible. I would have loved to have Ansible 30 years ago when I was doing stuff that would have been fabulous, particularly on the PTFs things.

J.T. – In the old days you had to write CLI for everything. And but where did they they couldn’t be started anywhere. But from the command line. Now you can start Ansible from anywhere. It uses SSH for connection. And the Ansible server can be anywhere as long as they make an SSH connection to your IBM i, which is pretty much the standard now.

A.A. – So we’ve covered multiple system deployments. We’ve talked about infrastructure as code. And that’s a key aspect of things because you’ll hear more and more over the coming years of infrastructure as code, because it is a very powerful concept, in handling your environments, particularly some of those temporary environments that come along.
We talked about one where you can actually have a cloud environment. And then pre-load it, test on it, and have it destroyed when you’re done. So that’s something that can be handled through Ansible. But here’s the thing. Let’s say in DROPS because we’re here to talk about DROPS, you can have the pipeline in your production. Kickoff DROPS. And part of the DROPS deployment is I need to call this Ansible to trigger an environment build. It builds the environment, deploys this artifact of software that you’ve just built. You can run through some various testing on it automatically, depending on whatever your tool set is and then have it destroyed at the end and DROPS started all that. It started that whole process.

J.T. – Yes. DROPS can actually handle containers, but Ansible, to be honest, does a better job. So use the best tool for it, right?

A.A. – Exactly. Use the best tool that’s available for you and what you’re able to use. So we’ve covered a lot here. Deployments, infrastructures, code. We’ve talked a bit about Ansible. And I’m sure within the next six months we’ll talk about Ansible again because it is such a valuable and tool by IBM. But it does tie into a lot of the things that we do at ARCAD to help our lives and which will eventually help customer lives as well, because that is available to us to integrate with, just like we use Jenkins, we use AWS, we use Azure because that’s what makes it easier for the customer because of what they need. So we tie and all that just fine. So we’re good there. And I imagine that Ansible is going to be one of those that keeps coming up from time to time.

J.T. – Yes. And other good news, Alan, is that, if your company is concerned about open source, they could buy Ansible from IBM with a maintenance package as well. So if your company is a little leery about open source, they can buy it, get maintenance. It’s available, Ansible Tower from Red hat. Now it’s their commercial product, just like you have Jenkins has Cloudbees.

A.A. – So keep it all on your private cloud.

J.T. – Yes. Exactly.

A.A. – Very good Jeff, thank you again. And, can’t wait to talk on the whatever our next subject is that we come up with because there’s always so much, so many different areas we can always talk about in these little techtalks. Now, from Git to branches to now, we’re talked a little bit about Ansible and deployments and I’m sure we’ll get into talking about pipelines.
Again others I mean, there’s a lot to really go into, particularly now that we’re getting into some microservices aspects of things and how that can help you through modernization. So I’m sure some of those topics would be coming down the line.

R.B. – Thank you Jeff. Thank you Alan. Great talk on DROPS. There’s more to talk about. As Alan, alluded to, we will be covering this topic again in the future. We’ll be talking more about Ansible and how it works with DROPS. But until then, thanks for listening.