We here at Puppet have just released Puppet Enterprise 2019.1, and we’re super excited about the many ways that this new version has advanced our user experience. Amidst the many improvements lies a completely new feature that we believe deserves some special attention.
This feature will dramatically improve the agentless workflows within the application, and serves to unlock a new world of enablement possibilities for delegating access to managing infrastructure without the use of the Puppet agent.
A little background
Since the release of 2019.0.1, Puppet Enterprise users have had the ability to execute Bolt tasks in ad-hoc fashion on infrastructure in their ecosystem over SSH and WinRM, without installing the Puppet agent on the task targets. By introducing this new functionality, Puppet opened the door for the users of Puppet Enterprise to effect change on agentless inventory.
Agentless made easy with the Inventory Service
With the release of 2019.1 and the introduction of the Inventory service, this workflow has become even easier and more powerful. Administrators are now able to securely store the target connection information in Inventory; once in Inventory, these agentless nodes become accessible within Puppet Enterprise in the same manner as agent-managed infrastructure, with all the activity logging and trappings that our users expect and rely on. This makes it possible to view, audit, group, and target these nodes in many of the same workflows that users are already accustomed to.
But that’s not all. The real magic in this sauce: after these agentless nodes have been added and grouped, Administrators are able to then grant inventory specific Bolt task permissions to users and roles within their system. This means that when an action needs to be taken by a permissioned user, they can simply select the necessary Task, select the nodes as they would any other managed nodes in their infrastructure, and take the necessary action against them without ever needing access to the credentials that are used within the process.
Sound complicated? It’s not! It’s as easy as 1-2-3: Add, group, permission. Let’s walk through an example so you can see what I mean.
Let’s say you are Administrator on Puppet Enterprise, and your infrastructure includes 4 nodes without a Puppet agent that are used by the development team. You aren’t allowed to provide the devs with the root credentials for these nodes, so you are regularly being pinged to SSH into them and restart a service to get the team unblocked. Sounds annoying right? Let’s see what Puppet Enterprise 2019.1 can do to help improve your mood.
Step 1: Add
First things first, you will add the nodes to your Inventory. Click the Inventory link in the left hand navigation to get to the Inventory page.
This should look familiar, since it’s the same form that you’ve been using on the Task page to run ad-hoc actions against these nodes when the need arose before you upgraded to 2019.1. So, you input the certnames for the dev nodes, add the root username and paste in the SSH key. With the form now complete, you go ahead and add the nodes.
Step 2: Group
Now that these agentless nodes are represented within your system, the next step is to group them so they are easier to manage.
Next, you create the gemstone-dev group as a child of the All nodes group, pin the certnames that you just added to Inventory, and commit those changes.
Step 3: Permission
You’re nearly there! The last step is to grant the members of the dev team permission to run the service task against the nodes in the new group. So, you navigate to the gemstone dev role using the left hand navigation, click the Permissions tab, and add a permission to run the service task against only the gemstone-dev node group.
And that’s it! You just brought the gemstone nodes into PE without installing an agent, and enabled the team to solve their own problem. Now let’s see what that problem solving workflow looks like from the team member perspective: meet Jenny Engineer.
The individual user perspective
Jenny Engineer introduced a bug into the dev system which has broken the environments and blocked her team. Luckily she has been empowered to unblock herself in this situation, so she logs into Puppet Enterprise and navigates to the Task setup page.
She clicks on the task dropdown menu and only sees one task: service. So she chooses it, easy enough. She browses the task metadata section to understand how to use the parameters, populates the required parameters for the task, then scrolls down to the Inventory section and selects Node group. She chooses All nodes, and when the table populates, only the dev nodes she uses populate in the table! Like magic. A quick click on the tooltip above the table informs her that her permission has granted her access to only 4 of the nodes in the system. But that’s all she needs, so all is well.
Jenny clicks Run Task, and within seconds the service is restarted on the nodes she needs it to be. She has unblocked her team, and she can return to building software.
And there you have it! We hope this has provided a sense of the power that lies within this new and exciting feature, and we would love to hear your thoughts and feedback.
Want more? We also encourage you to learn more about: