Breadcrumb

So you’ve heard about Puppet, DevOps, infrastructure automation, infrastructure as code, configuration management, or any of the other current IT buzzwords and you want to kick the tires with the Puppet Enterprise trial. Awesome! And even better, our trial is free for up to 10 nodes and not time-limited, so you can really dig in.

As a sales engineer at Puppet, I help customers with all levels of experience evaluate Puppet Enterprise. This is the first blog post in a three-part series in which I will identify some of the issues I come across often. First (in this blog post) we will cover preparation tasks and topics to consider before starting. The second part will be related to implementation details and getting started. The third and final part will be related to overarching ideas to keep in mind throughout the process.

However, this is the age of instant gratification, of which I enjoy as well, so I’ll start with a TL;DR which I will repeat at the end of this series. It may be interesting to see how your perspective of the ideas changes throughout.

TL;DR

When evaluating solutions, consider your future growth and future use cases. You may only need some capabilities of the platform today, but down the road you will likely have a whole new set of challenges — and bending a tool to do things it wasn’t meant to do often leads to extra work, downtime, and frustration. You want a solution that allows you to start small and can scale with you.

Often the errors and frustrations I encounter are not errors with Puppet, but with not starting with a clear understanding of how the existing systems we are working on — networking, firewalls, non-default Linux images, etc. — are configured. Using sandboxes or labs to evaluate Puppet provides a clean slate, which will minimize configuration-related issues so you can get down to business. It is very easy to take network, DNS, and firewall configurations for granted.

Start simple. Want to automate that important new app? You will get there. Start by automating things you are familiar with, such as the prerequisites for your existing software or dev/test/qa/prod baselines, and build from there. The formula for success that we see with our customers is to start small, show success, automate more.

Pervasive automation is the future. Changes in culture, process, and technology are key to making this shift. Change doesn’t happen overnight, and it shouldn’t. Just be open to it in various forms.

Prep work

Linux? Do I need Linux?

Yes, you need a Linux server for the Puppet master. This list has all the supported distros.

If you are not familiar with Linux, you have a couple options. The first option is to stand up a Linux machine on your own and learn a bit about it. This guide is a great walkthrough for installing CentOS 7. If you prefer to not install Linux yourself, you can also use Vagrant and some CentOS boxes on your local machine. This will allow you to quickly spin up a machine that already has the OS installed.

Once Linux is installed, you will want to set the hostname, configure the network, and either configure or disable the firewall for the needed ports. (Disabling may be easier, but that poses its own security risks.) Each one of those tasks is heavily documented for all operating systems. Check out the Puppet installation guide and read it thoroughly. It’ll save you time. From there, download the Puppet Enterprise trial. If that sounds like too much, the AWS Puppet Enterprise pay-as-you-go image might be a better option as the licensing is still free for up to 10 nodes. Additionally, you can always reach out [email protected] to have a sales engineer help you with the install, but you will still need to have instances (local or remote resources) available.

Takeaway: If you aren’t a Linux user, don’t be afraid. Many customers I work with have Puppet Enterprise as their only Linux server and have never used Linux before.

I know Linux, but I'm getting this error

You probably have some existing Linux machines available, but be wary because they may have pre-existing configurations. To run Puppet Enterprise you need root access to the machine (full admin rights), write/exec access to /tmp, specific packages, etc. I often hear, “It’s our standard build. I am not actually sure what’s in it.” These unknowns can cause issues and delay your evaluation. A clean OS makes it easier to get started so you don’t waste cycles on troubleshooting while you’re trying to learn a new tool.

DNS? Hostnames? Networking?

I'm reminded of a haiku:

It's not DNS
There's no way it's DNS
It was DNS

Set your hostnames to something you know. Check to make sure they are what you expect. Ensure IP resolution works via “ping ”. It’s imperative to be able to ping each node by name (testbox01, testbox02, etc. not 192.168.1.20, 192.168.1.21, etc.) which can be achieved with either a DNS server or host file edits. Often this is taken for granted in existing infrastructure, but it becomes an issue when you’re building infrastructure for evaluation purposes. Don’t be afraid to talk to your network admins for help on this. The easiest way to do this without possibly affecting other architecture is to edit each machine's hosts file without using an existing DNS server or setting up a new one. Trust is established via a certificate authority (CA) in Puppet Enterprise, so name resolution is critical.

Takeaway: I'm not joking when I say 30 to 50 percent of the frustrations people see as Puppet errors turn out to be the result of not knowing a hostname, or connections being blocked by routing and firewall rules, or not configuring the proxy. Networking errors can manifest themselves in creative ways, and the log won't necessarily say “open port 8140” or “this hostname is set wrong.”

The Interwebs

Do you have internet access? It’s okay if you don’t. Need a proxy? That’s fine, we can use proxies. Puppet Enterprise assumes you have internet access, so when you install modules, download agents, and perform various other setup tasks, it may reach out to the web. If you have an HTTP proxy server that's fine, too — you just have to tell Puppet about it. Go here for agent repos, here for proxy config in Puppet Server, and here for Code Manager. Puppet Enterprise works fine completely air-gapped from the internet, but this requires some additional planning, implementation steps, and day-to-day workflow steps (although the overall workflow is largely the same).

Takeaway: Puppet works in offline environments, but requires additional steps that don’t always add value to the evaluation experience unless the specific offline workflow is the evaluation goal. If not, it is quicker to learn and evaluate Puppet Enterprise in an online environment.

Closing

Stay tuned for the next part where we talk about topics that often arise during the installation and evaluation.