Published on 29 March 2018 by

In this second part of this blog series we are going to review some implementation time details that I encounter often with new users and customers. Part 1 can be found here and I would recommend reading that prior to this post.

Implementation

Which release?

Puppet Enterprise has two release trains: LTS (long-term support) and STS (short-term support). Depending on what is important to your organization, you may choose one release train over the other. The LTS is designed for ~24 month supported life cycles, and the STS release train is 6 months and “new feature” focused. Generally speaking, the STS releases are more current and can incorporate both server and agent improvements in each release. Unless there is a specific reason to use an LTS release, I suggest using the STS releases as updates (to either versions) are tested and typically a trivial process with very little downtime.

Takeaway: Unless you have specific LTS requirements, stick with the STS release for the latest feature set.

I just want a sandbox with Puppet already installed

If you don’t want to spin up your own box for testing, you can spin up instances of pre-installed Puppet Enterprise in cloud providers such as AWS and Azure. You can also trial AWS OpsWorks for Puppet Enterprise, which allows you to provision and configure a Puppet master running on AWS in less than 20 minutes. You can manage up to 10 nodes free, however depending on the size machine you select or other cloud-specific settings, you may incur some infrastructure costs. Using Puppet “as a service” in these capacities can be beneficial for the evaluation for those familiar with code as most of the day-to-day work in a mature Puppet infrastructure is writing or editing Puppet code itself, which is easy to pick up and deploy on another server.

Takeaway: If requesting machines is hard, stand up the AWS Puppet Enterprise (PAYG) or Azure Marketplace image. It’s free up to 10 nodes (m3.large is fine).

I don't want to mess with code or integrations just yet

A huge aspect of DevOps and infrastructure as code is, well, code. The code part for Puppet Enterprise can be written, deployed, and edited all on the master. Great, right? Not so fast.

Setting up Code Manager in the beginning is easier than after you have been using Puppet Enterprise, and you start by learning best practices instead of trying to integrate them later. I consider Code Manager deployment the most important piece in the evaluation experience as it helps you develop solid code workflow practices. It is more than just turn-on-and-use; the benefits expand the more you understand continuous integration and continuous delivery (CI/CD) and work with other teams.

If working with code is new to you or your team, setting up an internal server such as GitLab, TFS, or Bitbucket is pretty straightforward — and there is even an approved Puppet module to set up GitLab! Alternatively, public repositories from GitHub work fine, but it’s important to omit sensitive data. Use a clone of our control repo on GitHub. The best time to plant a tree was 20 years ago, and the second best time is now.

Takeaway: You will be in a much better spot if you take a few minutes at the outset to set up Code Manager and use it, then become more expert with it later. Half of DevOps is Dev, and this is the Dev part.

Where to start? What do I automate?

Where to start is always the hardest part of the journey, and where I spend a good amount of time working with prospective Puppet users. You're not evaluating software because you have a ton of free time on your hands. Actually, the opposite is usually true. If you're like most of the people I work with, you're probably trying to change the tires on the freeway going 70 miles per hour because you're A) a masochist or B) your business needs it. Often there is a project, an initiative, a merger, or some other catalyst that leads an organization to look into automation. It is easy to focus on the immediate need, but once that project is done there will be another, and another, and another. Sometimes there is not an immediate tangible project to consider, and you just want to improve your process.

I suggest starting with simple common items that become harder at scale (scale being relative to your organization). Set up time servers, operating system parameters, common core software, remote access settings, etc. Building a strong foundation enables more agility and consistency later. For example, if you provide baseline testing and production environments with Puppet, you can ensure that those environments closely match regardless of what platform they are on or when they were created. This makes deployments more consistent and faster, and makes troubleshooting errors easier.

Takeaway: Start with basics, perhaps items you already considered “done,” to gain confidence. Before you know it your whole application and prerequisites will be modeled in code. This is where plenty of our customers and partners began.

Closing

Stay tuned for the final part of this blog series where we talk about ideas to keep in mind throughout the whole evaluation.

Mike Smith is a sales engineer at Puppet.

Share via:
Posted in:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.