I'm Andy Glover and this is the Java Technical Series of the developerworks podcasts. My guest is Brian Jakovich. He is the director of Elastic Operations for Stelligent. He and I are going to talk about Puppet. So Brian, welcome. Hi, how you doing? It s good to have you. Some time ago we ran a talk with Paul Duval who is the CTO of Stelligent, so it's great to have someone from Stelligent back on this podcast series. So this series is focusing on the cloud, and Stelligent is doing some really interesting work in the cloud. Your title Director of Elastic Operations is indicative your stance on the cloud and something that you and I and Paul have talked about in the past is automation in the cloud and something that comes up a lot is this tool called Puppet. So I thought I'd kick off the conversation by asking you, Brian, what the heck is Puppet? Puppet, at a real low level, is a Ruby-based language that allows you to script your infrastructure -- most specifically infrastructure -- into a scriptable format, so you can continuously run and rebuild your environments to the same standard every time. Okay. So the same standard every time, and that's obviously an important aspect. Talk about this applicability in the cloud. There are various cloud providers. There's Infrastructure as a Service, there s Platforms as a Service. One everyone knows about is Amazon Web Services, AWS, the cloud, right?
Right. So how does Puppet help me do my job better, faster, cheaper with something like AWS? One of the key parts to explain where it is before you get to AWS. Originally, you launch up a server and then you need writing or performing commands to get to your end state of the system. An easier way of doing that would be with Puppet where you actually script the commands and it builds up the infrastructure. In the cloud, the cloud gives you the ability to do that elastically. You can build up your infrastructure using the virtual resources and then apply Puppet on to that to build up the system to the end state. So it's a scripting language, its Ruby based. So you have to know Ruby then to use Puppet. You don't have to know Ruby. So there's an internal DSL and an external DSL. So Puppet has its own, its sys/admin time oriented language that isn't Ruby based, but they also integrate a Ruby-based part of it, too. If you're familiar as a developer, you can script into it as well. So let's talk then about a Puppet script. So a typical task to perform with AWS, is to select an AMI, like an Ubuntu standard image, and then to apply that to an instance type. So let's
say I want to do it on a high memory the MX2 or whatever their nomenclature is. Apply the AMI to an instance and the Ubuntu image is running in the cloud. I want to install some Java components, like I want to put Tomcat on it. And then I want to deploy a WAR to it. Those five or six steps, are all manual at this point without using something like Puppet, right? I'm working either on the command line or I'm going through the AWS management console. How does this work then with Puppet? So I'm writing a script. And how does a script do this? What are the commands and where do I run the script from? And are there component that are required, let's say, on the AWS side for Puppet to work? Yes. So at a very low level, you need Puppet installed on the target environment that you're trying to start up. Okay. So there's like a Puppet kind of client/server architecture here? Yes. There's like three different ways you can run Puppet. There's Puppet Enterprise, which is just their enterprise version. There is master server/master client type of configuration, that actually just a client which run on its own. What you need is to install the actual Puppet package, RPM, gem
packet, on to your target system. And then you can run Puppet at the Puppet client. Okay. So you have a Puppet client that's running your machine, and then you need a Puppet server on the AWS instance, or can it be somewhere else? It can be anywhere else. How are you delineating or specifying your images and instance types? That's all commands you then give to Puppet? The images and instance types? Yes. Puppet knows this on its own. It looks at the internal architecture of whatever it's sitting on, so let's say you're on Ubuntu or CentOS or other operating system, it has its logic built in that looks at the operating system and figures out what it's working with. The specific tool that they use there is called Factor. So Puppet is making my job easier because it's reducing the amount of steps I have to take? Yes. Let's say you're launching up some huge server that takes about an hour and a half to manually provision. Puppet will do the same task, just automatically. It will reduce your steps
to pretty much none So we talked about Infrastructure as a Service and Platform as a Service there seems to be a growing trend of people who prefer the platform route? Because at the end of the day, an infrastructure is a commodity? It's another machine that I run stuff on. The real value perhaps is that I've got a platform that's going to handle all that for me. So platforms that come to mind and platforms that we've talked to on this series are like Jelastic or CloudBees or the Google App Engine, Elastic Beanstalk, or Engine Yard, Heroku. Does Puppet work in those environments as well -- i.e., can Puppet work in a PaaS environment? I'm not going to say no a hundred percent there, but it's better used in the Infrastructure as a Service environments. Generally, Elastic Beanstalk, or Heroku are built to essentially just take your application. And all the platform-specific stuff is built in already whereas with Infrastructure as a Service, you essentially get the virtual hardware and that's all. You have to build it up as you see fit on your own. Is Puppet the only game in town? Are there other Infrastructures as a Service? And why would someone want to look at Puppet as opposed to rolling their own or using Competitor A, B and C?
To roll your own is quite a task. Puppet does a ton of work for you, most specifically with the factor where you figure out the separating system specifics and all prior to actually running your script, that's a lot. If you were to run it just in a bash script, Puppet allows you to make decisions based on what Puppet finds. For instance, you may find you are running on a CentOS system when you were expecting to run on an Ubuntu system. Puppet will change how it builds the system, depending on that. And if you were to use a bash script, it would just run the scripts, this doesn't work with Ubuntu, it would just fail. As to the other options for this, there's Bcfg2 and then Chef. To my knowledge, there's some other ones as well, but those are the big players. What's the advantage of Puppet over Chef? The way I find it, Puppet is a bigger, much bigger, user base. It's almost four to one ratio and it's been around for longer time. As you're learning Puppet and building out your scripts and you generally have questions you re trying to figure out what you need to do in your unusual situations? In addition to that, Puppet allows you to require of other resources. So let's say you wanted to install Tomcat and then also how to
configuration script that you want to put on to the Tomcat web app only after you install Tomcat. Puppet allows you to make that choice. You can require the Tomcat package is installed prior to putting the configuration script on there. With Chef, it can still be done, but it's not as simple and straightforward as it is with Puppet. You mentioned the community aspect of Puppet Is Puppet is open source? Yes. So you have these open source projects and then a community grows around the project itself. And something that results are these extensions or plug-ins. A classic example in the Java world is, you know, Jenkins or...gosh, I can't even remember the old name of Jenkins or the new name, excuse me. The CI server that, you know...hudson, excuse me. Hudson was the old name. Was this great...or, is this great CI server and all these people built all these plug-ins and it kind of created this movement where everyone was moving to, let's use Hudson and/or Jenkins to use our continuous integration. On the Puppet side, you mentioned a large community, a big user base. So there an analogous plug-in feature to Puppet? You can build out modules. And a module would be like a
specific type of installation that you want to do. Say you want to install Tomcat. There are different ways that you can configure Tomcat, but there would be a module called Tomcat. And there is an accepted way of installing it. For instance typically Tomcat is a type of package, so there would a package installation. There could also be a binary installation. It's already ran in this prewritten module. Generally, the modules that are most widely used are on the Puppet GitHub. There are different versions of Puppet and it's an open source framework. Tell me about these different versions, and is there's a company around Puppet that's providing support, et cetera? Yes. Puppet Labs is the company that maintains and builds up Puppet. Yes, they offer a Puppet client type of thing which doesn t really require a master server, where it just works on its own. And then there's also master server configuration of Puppet where essentially you have one master Puppet node that can control all your mini Puppet servers that are essentially your target instances are built using Puppet. Those would be connected to the master. In that configuration, you can continuously make modifications to your infrastructure by using the master server to, say; install Tomcat on all 50 servers. It s here where the Puppet standalone does not offer that feature you run it again, and you can only do it for
that one node at a time; they're not connected. And then lastly, Puppet Enterprise is Puppet's paid version where they have a master server configuration, but they give you much more support and a graphical use interface that allows you to really work with Puppet using the web UI. Okay. So how do I get started with Puppet? What are some good resources here? Okay. So, obviously the Puppet Labs GitHub. You can type; I think probably the easiest way of typing it is go to Google, type Puppet or Puppet GitHub They have a bunch of modules and manifests which are the controlling aspects of Puppet. And they have a lot of resources for getting started. There's also devopscloud.com where Paul Duval is CTO. He did a video series on using Puppet in the cloud. So you've got the cloud and then you've got tools like Puppet that help kind of provision things in the cloud. Is this all collectively part of DevOps? Yes. DevOps allows you to kind of bridge from developer to operations. And Puppet really helps with that. It's scripting for your typical sys admin tasks. It s like the DevOps power tool. DevOps power tool. And it's supported across all
different environments as we've already said, Linux, Mac, Windows, doesn't matter, it's platform agnostic, right? Exactly. This is cool. So we can get more information on the GitHub site. You did mention the DevOps and the cloud series. What about you? Where can we find out more information about you? The Stelligent blog tweets regularly. I'm also publishing a blog series about how we use actually Puppet and AWS for building out a continuous delivery platform for a nonprofit organization called Sea to Shore Alliance. You can find it's a six-part blog series on blog.stelligent.com. That's interesting. That's another kind of keyword Continuous delivery. So you have the DevOps lifecycle and then this continuous delivery aspect of it and Puppet being a large part of that. So this is a blog series that I'll certainly want to check out? Yes. Well. Cool. So Brian, I appreciate you taking time out of your busy day to educate us about Puppet and where it fits in the lifecycle of DevOps and continuous delivery in the cloud. Your whole point about at the end of the day it's an automation feature so it's saving time.
And that is certainly a benefit or a factor that weighs in lots of different kind of products and whatnot with respect to the cloud. You can get started with Puppet for free, and then there are paid versions as well. Yes. [LAUGHTER] So again, I'm Andy Glover, and this is the Java Technical Series of the developerworks podcast. Thanks for listening. My guest again has been Brian Jakovich. He is the director of Elastic Operations for Stelligent. And look forward to talking to you guys again sometime soon. [END OF SEGMENT]