Reviews (1-11 of 11)
- Maintain configurations
- Create a more organized look at what it takes to run a particular application
- Automate deployments
- Coming from Chef, I was much more used to everything being executed from the top down, Puppet executes actions at random and so if you need something like a directory to be created before a file is placed you will need to explicitly declare the order of execution.
- Coming from Chef I also learned to love the knife command, this allows you a few things, but a very valuable action allowed by the knife command is the ability to list nodes that are currently running Chef.
- The ability to use commands across multiple host in parallel(once again, a knife command).
If you're looking for more control over your systems as a whole without having to write your own scripts or install multiple configuration management systems then Puppet is not what you're looking for.
- Provides a reliable mechanism for deploying infrastructure-as-code, especially when integrated with source control (such as Git).
- Manages system configuration drift to provide greater stability and system up-time; the same configuration-as-code can be pushed out over and over.
- A strong asset when moving teams towards DevOps by providing development a way to take control of their own assets.
- A bit of a steep learning curve but something that can be easily understood once a few basics are grasped and use of Puppet is put into practice.
- Does not fit well with existing infrastructure but that is not necessarily a failing with Puppet but can require a radical shift in thinking and procedures to reliably implement.
- Deploying infrastructure-as-code from a central version-control repository
- Providing a reliable mechanism for quickly building out new datacenters or recovering from a major disaster-type event
- Standardizing middleware, code, and configurations running systems and applications
- Automatically pushing configurations out to multiple clients from a central repository
- Managing existing infrastructure and/or forcing a standard configuration onto already-deployed and running infrastructure
- Provides a clear map of how a system is configured
- Eases the creation of a system in a specific cluster as it is scripted in code
- Simplifies configuration changes to a cluster or to every system such as rolling out vhost configurations, updating ldap roles, NFS mounts, etc
- The syntax is very easy to read and carries a lot of fluidity once the language is learned.
- It is occasionally squirrelly such as if I want a tarball to decompress once, I have to do run a exec command and onlyif => 'test ! -d /directory_name'.
- I cant for the life of me figure out how to execute it based on environment(production, development, staging) so I am still using puppet 3.7 that utilizes manifest nodes. I would like to utilize puppet 4 because it supports Lambdas and a very Ruby-like syntax for iterations but it requires the use of environments which we do not need. It would be nice to allow for both methods(manifest nodes AND environments) like 3.7 supported.
- It would be nice if the language still supported inline ruby. The new generation language is great for basic tasks but being able to do things like pulling data from a MariaDB database and utilizing that data in a manifest is very nice when operating at scale. We personally do not need it but I can see that being something very useful for those who code their own front ends for larger organizations.
Let me start by saying like any configuration management software, there is a learning curve and there must exist a respect for what it can do across hundreds or thousands of servers with a single Puppet run, or what it can break with that same ease of use! That being said puppet, working in unison with The Foreman, Mcollective and Hiera, are some of the most powerful, and for me personally, the most enjoyable and rewarding set of admin tools I've used in years.
At my current company we needed to automate deployments and configuration consistency across multiple data centers both Colo and Cloud internationally while remaining flexible enough to change parameters, environment settings and application code in a timely and controllable manner.
We needed a full server life cycle management system that automated provisioning, configuration, changes and clean removal of dynamic resources such as on demand server capacity.
- Create a specific role based server from a vanilla provisioning template and maintain configuration state via Puppet automated catalog runs.
- Add new functionality, services or configuration data to all servers or a subset of servers without ever needing to log into them.
- Integrates seamlessly into other server life cycle technologies such as The Foreman and Mcollective for even greater management and automation.
- Steep learning curve for first time users.
- The complexity can get a little overwhelming in a more collaborative deployment methodology across multiple platforms and data centers.
- Some external changes to Puppet like the new Puppet 4 architecture can cause considerable time consuming migration efforts especially if you have a lot of legacy classes and configuration that do not conform readily to the new design.
- Automation of redundant tasks
- Abstraction of complex tasks
- Integrates well with other community/open-source projects (e.g. Cobbler, Foreman)
- System user interfaces (e.g. Puppet Dashboard)
- Integrated support for password management
- Backend Ruby scripts are very embedded and cumbersome to find/edit in cases where manual bug workarounds are necessary to implement
- Automating software install.
- Configuring software after post install.
- Taking the same Puppet code to another environment and have it easily deploy there.
- Decrease the learning curve.
- Introduce ways easy ways to write Puppet code to those who have not done it.
- Introduce a UI for those who are fearful of command line.
- certificate management for new device trusts
- viewing all systems currently under puppet control
- view logs from all systems to detect errors and missed runs
- clean interface to navigate through system
- web UI could use quite a bit more functionality to differentiate it from the free version
- multi-tenancy would be a big benefit in our use case
- view and edit puppet code within console ui
- It's compatible with all the operating systems that the employees use at our organization.
- Easy to install and initial setup is easy.
- It provides good tools for testing if everything is running properly and in order.
- If you want to do advanced tasks with it, you need to be familiar with Ruby, which not everyone has knowledge about it.
- It doesn't have its own dashboard.
- The support for the tool is not very high due to being an open source software.
It is currently in development, but will hopefully make it out to be used throughout the organization.
There are few business problems, mainly with the limitation in support for open sourced software, which would be solved by using the closed sourced counterpart, but that would defeat the purpose of open source...
If people helping people is a powerful thing... then Puppet helping Puppet is also a very powerful thing.
- Plays well with other open sourced software
- A generally accepted open sourced tool for automation
- Easy to understand
- It is most importantly free
- Support... support.... support
- Does not always work well with other software
The coding is easy to understand and can be as complex as you make it.
- Maintain a solid baseline across many servers.
- Apply updates to many servers.
- Easy to make changes all in one place rather than on 50 servers.
- No GUI for non sys-admin users.
- Ruby syntax is troubling at times.
- No automated deployment.
- It allows for uniform configuration.
- It allows you to deploy software effectively without having to learn specific nuances of it.
- It allows you to be OS agnostic in that it can translate commands between OS distributions.
- The OpenSource branch of the product does not come with a reasonable dashboard. A third party one must be used.
- Puppet by itself, while good, needs additions made to it to become great, such as Heira, r10k, GIT, etc...
- Puppet has a learning curve. It is best to start with something small, such as NTP and work your way up from there. Do not start with something like Apache.
- Deploying MCollective really helps to round out the Puppet experience.
Puppet Enterprise Scorecard Summary
What is Puppet Enterprise?
Puppet Enterprise Technical Details