Package management on Windows with Chocolatey & Puppet
Editor’s note: This is one in a series of posts about using Puppet to automate your Windows servers. Follow us on social media or subscribe to our our RSS feed to be notified when the next post is released.
Chocolatey is a package manager for Windows, like Yum. It uses the NuGet packaging framework and PowerShell for automation scripts. With Chocolatey, you can use non-centralized and private repositories and create your own packages. Chocolatey is a Microsoft-validated tool, and any Windows installer, zip, or binary can be packaged with Chocolatey.
Chocolatey lets you manage all aspects of Windows software: installation, configuration, upgrade and uninstalling. It works with runtime binaries, zips and existing installer technologies like MSI, NSIS and InnoSetup. Chocolatey takes advantage of PowerShell to turn complex tasks into simple function calls.
In this post, we'll take a look at how you can use Puppet to configure and control Chocolatey.
The Chocolatey community repository has thousands of packages that anyone can use, but we recommend you host your own internal package repository server rather than the packages on Chocolatey.org. That way you’ll have complete control over your software.
Let’s look at the Puppet Chocolatey module. It can install Chocolatey and packages, and later all the configuration that goes along with Chocolatey as well — including custom sources and other features. Here’s a couple ways of ensuring Chocolatey is installed:
We can see in this manifest that we can simply include Chocolatey, and the default reaches out to Chocolatey.org to pull down the lastest version of the package. Alternatively, you can have a local URL (a file sitting on an HTTP server).
Above is the anatomy of a package resource. We set Chocolatey as the provider, so we can ensure software is removed, installed, stays up to date, is a particular version, or hold a package on a version.
We can specify default sources in Chocolatey itself, or you can define it here. We can pull the package from one source or more (separated by a semicolon) — either a web data feed or a local file or folder. Getting started with Chocolatey is as simple as dropping some packages into a folder a server somewhere that can serve packages. You have plenty of install and uninstall options as well.
Why Chocolatey? It’s a unified interface to all different types of installers. Here’s the difference between the built-in Windows package provider and Chocolatey:
Note the differences. For the built-in provider, when we need to upgrade we’ll run into maintenance issues. We’ll need to change the manifest over time. Instead, if we take a look at the Chocolatey provider, we can see it looks just like the package provider for other operating systems. We’ve achieving platform-agnostic packaging. You can use that same packaging to ensure the latest version of Git is installed across all of your platforms and operating systems.
There are a few files in the default Chocolatey package template, as it is meant to provide a generalist approach. You can also create your own templates. Chocolatey will by default generate a readme file, install and uninstall PowerShell scripts, and a nuspec — which is a way of describing the packaging format. It has information about the version of the software, any dependencies, etc. For example, if you have a package with Git extensions and it requires Git to be installed first, Chocolatey will be able to manage that for you.
Rob Reynolds is a senior software engineer at Puppet.
- You can learn a lot more about how to manage Windows environments with Puppet in our Windows webinars.
- Check out the Chocolatey package provider on the Puppet Forge.
- Learn how Walmart extends packaging templates.
- See more posts about Chocolatey.
- Visit https://chocolatey.org for more Chocolatey.
- See all posts about Windows.
- Join the Windows Puppet Community Slack Channel