Cloud Foundry Plugins for the Lazy Developer

July 8, 2015 Simon Elisha

sfeatured-podcastI often say that the best developer is a lazy developer. Not because they do not like to do work, but they hate doing the same thing over and over. After all, that is why we created computers in the first place!

One of the many strengths of Cloud Foundry is the open ecosystem that it promotes. This manifests in many ways, one of which is the CLI Plugin architecture. This enables anyone to contribute great ideas into the CLI in a stable and extensible way.

In this episode, we explore the creation of these plugins and sample some of the cool ones available!




Speaker 1:
Welcome to the Pivotal Perspectives Podcast. The podcast at the intersection of Agile, Cloud, and Big Data. Stay tuned for regular updates, technical deep dives, architecture discussions, and interviews. Now, let’s join Pivotal’s Australia and New Zealand’s CTO, Simon Elisha, for the Pivotal Perspectives Podcast.

Simon Elisha:
Hello, everyone. Welcome back to the podcast. Great to have you back. Thanks for taking the time to join me. I was going to say a quick one today, but it might not be, just depends on how we roll. The topic today that I wanted to have a chat with you about was the concept of plugins for the Cloud Foundry CLI, the Command Line Interface.

Now one of the amazingly powerful parts of Cloud Foundry is the command line. You can do, obviously, lots and lots of things. I think most of the people who use the platform in anger tend to gravitate to the command line, they can use the GUI as well as some great GUI capability in a Pivotal Cloud Foundry as well. One of the things that was introduced fairly recently, this was in the CLI version 6.7 or higher, was the concept of plugins. This is a great idea. If you think about the concept of obviously an open-source software, it’s all about extendability and adjusting things to suit people’s individual needs, or company needs, or just the development of the state-of-play, or the state-of-the-art in terms of how a platform operates and what you might want to do with it. The concept of plugins gave the entire community a safe, secure, and predictable way to insert additional capability within the CLI without having to wait for a brand-new release of the CLI, so very, very handy.

The way you implement these plugins is using the plugin interface. It’s implemented in Go, so good encouragement for you to use Golang or to learn Golang. It certainly seems to have become the preferred language of people doing interesting stuff in a distributed way. Certainly I’ve had a bit of a devil with it myself. I’m by no means an expert, but certainly there’s a degree of elegance and simplicity that’s quite appealing. It also performs really, really well and uses very little computer resource so it’s kind of efficient.

I’ll link in the show notes the steps that you need to actually create the plugins. What is nice is that there is actually a repo with all the different plugins in there. If you want to see how you can register with that repository, it’s on GitHub, cloudfoundry-incubator/CLI-plugin-repo. Again, I’ll put that in the show notes. What’s far more interesting is that there is the public repo and also you can have private repo. You can create your own internal repo server if you want to, which means that you can run in inside your firewall if that’s a requirement of your particular organization.

What I’m really enjoying is the externally-facing or community created set of plugins. There’s a great website. It’s called which lists all of the ones that are currently available. What I wanted to today was to give you a taste of some of those because that will, I think, inspire quite a few of you to say, “Hey, I can write something that I do regularly.” As I often say is that, “The best programmers are lazy programmers.” That’s not to say they don’t like doing stuff, it means they hate doing the same thing over and over and they seek to automate that. The plugin architecture allows you to do that really effectively.

There are a bunch of plugins, but let me call out some of ones that really appeal to me, again, complete personal taste, nothing other than that. The first one that really jumps out at me is called the CLI Recorder. This is genius. This is one that Simon Leung put together. It basically allows to record and playback CLI commands that you’ve issued. Think of it as batching together what you might do on a regular basis. Super simple to use, essentially, once you put the plugin in you simply say CF [space] RECORD and the name of what you want to call that file. You enter all the CF commands you would normally do and at the end you enter STOP. Once you’ve done that you can enter the command CF REPLAY and then the name of the set you’ve created. That means you don’t have to type things lots and lots or times, it just magically happens. I think that’s a really good efficiency thing that you would want to do.

Some other really nifty things that are out there is a simple one but effective one. One from the folks at Stark and Wayne who do some great work on Cloud Foundry, it’s called Open. It does one thing and does it well. It opens the app URL in a browser. If you’re running in the command line and you’ve deployed an application and you want to quickly open it up, you can issue a simple command and open that app up in the browser so you can see that what you think you’ve done has worked. Pretty simple, but nice.

A couple of others that are really interesting and kind of deal with the same problem domain, one is called Autopilot and that’s from Chris Brown. The other is called Scaleover and that’s from Guido Westenberg and Josh Kruk. These are plugins that allow you to do sort of cut over of applications. We’ve talked a few times on the podcast about doing blue-green deployments, so the concept of having an existing deployment and deploying a new version of the application, and migrating seamlessly between the two.

Now, obviously, within native Cloud Foundry we have the basic command sets and the capabilities to do that. What these plugins do in their own special way is further automate that switch over process so that you can do it very elegantly and simply. It becomes a really easy way to do that and straightforward. The two of them, one is called … Let me get the name right again, because I want to make sure I give you the right name. One is called Scaleover and the other one is called Autopilot and you can choose each one and depends on what you like to use and make that work.

Another really nifty one, if you’re using multiple targets, let’s say you’ve got a Cloud Foundry deployed for development and then a completely different one for production, or maybe you’re in an environment where you’re running multiple Cloud Foundry foundations, we have a plugin called CF Targets. CF Targets laid and manage multiple targets really, really easily. This is useful when you’re switching between those targets on a regular basis. Obviously, in the normal sense, you’ll do a CF log-in every time. With the Targets plugin it makes it a lot easier because you simply can just point the target in terms of saying CF SET TARGET and then CF TARGET and it does everything for you. It lets you switch back and forth really easily. One of those little time savers that on the face of it you say, “Well, it just does a small thing.” It’s something that if you’re doing all the time during the day it can just save you a lot of time and a lot of frustration.

That’s the plugin architecture, a little bit about the command line interface plugin. Again, something to look into if you’re doing any sort of repetitive task or things over and over again, think about the plugin as an option to automate that for you. Of course if you’ve created something please feel free to submit it back to the community and allow it to become a piloted ecosystem, be developed over time, and grow.

Thanks again for listening. If you have any ideas or suggestions that you want to pass on we always love to hear from you, Until then, thanks so much for listening and keep on building. (music)

Speaker 1:
Thanks for listening to the Pivotal Perspectives Podcast with Simon Elisha. We trust you’ve enjoyed it and ask that you share it with other people who may also be interested. We’d love to hear your feedback, so please send any comments or suggestions to We look forward to having you join us next time on the Pivotal Perspectives Podcast. (music)

About the Author

Simon Elisha is CTO & Senior Manager of Field Engineering for Australia & New Zealand at Pivotal. With over 24 years industry experience in everything from Mainframes to the latest Cloud architectures - Simon brings a refreshing and insightful view of the business value of IT. Passionate about technology, he is a pragmatist who looks for the best solution to the task at hand. He has held roles at EDS, PricewaterhouseCoopers, VERITAS Software, Hitachi Data Systems, Cisco Systems and Amazon Web Services.

14 Reasons Data Pros Shouldn’t Miss SpringOne Platform
14 Reasons Data Pros Shouldn’t Miss SpringOne Platform

Isn’t SpringOne Platform for Java developers? If this were 2013, you’d be right. But in 2016, application d...

Next’s Revolutionary Approach To Achieve Continuous Compliance’s Revolutionary Approach To Achieve Continuous Compliance

In this post, two members of 18F, the team behind, explain how they apply cloud native developmen...

SpringOne 2021

Register Now