Perforce Puppet Reviews

My main use case for Perforce Puppet is for configuration management.

The best feature of Perforce Puppet for myself is the agent-based functionality.

The agent-based feature helps me by being stable.

I have used the real-time reporting feature.

This feature helps to improve system and configuration management as it is easy to use.

I don't know what could be improved in Perforce Puppet to make this tool better for the next release. I can't think of anything for now, except maybe the price, which I consider high at 50%.

I have been working with Perforce Puppet for 10 years.

I did not purchase it through AWS Marketplace.

The biggest benefit of Perforce Puppet is that it's stable.

It is scalable to manage a large number of nodes.

I would rate scalability an eight out of ten.

My impression of the technical support is very good.

It is easy to set up Perforce Puppet.

It took me approximately one day to set up.

We did the deployment ourselves without using any kind of reseller integrator.

Regarding the cost, I find it expensive, always.

I don't know how much the license would cost per year or per user approximately.

I am using Perforce Puppet in the IT industry.

I have experience with configuration management tools, specifically Perforce Puppet.

I am a user of Perforce Puppet.

I have used modular architecture to customize and integrate with my current IT environment.

It is flexible and able to address my specific needs.

I have worked with event-driven automation, and it helps to identify potential issues when someone manually changes any configuration on the server. Perforce Puppet reinforces the intended configuration that we have set earlier.

I recommend Perforce Puppet as it's a good tool for all kinds of business and easy to use.

It takes less than three months to learn how to use Perforce Puppet.

On a scale of one to ten, I rate Perforce Puppet an eight.

I use Puppet Enterprise in many projects that require a full control on the Device and make it compliant with the Security regulations of the Company. Puppet Enterprise provides an  autonomous Delivery solution and  agent-server Architecture that was really helpful on our case for Internet base Device Management.

Puppet has help us to make the Linux Clients compliant with the Security requirements, independently where are located and the Operative Linux System release.

The most valuable features vs others:  Out-of-the-box Scalability, Role Based Access Control, Device State Control, Full Internet Based Solution, Secure and Autonomous Enrolment and a Robust Product with great community Support.

The solution has really complex code, you have to understand the Ruby language and customized Domain Scripting Language (DSL). However, once you know the code then you can move ahead without any problems. To improve the Development learning curve, new Puppet Development Kit should maybe include a Development interface with preloaded DSL Dictionary.

I have been using Puppet Enterprise for approximately nine years.

The solution is stable and provides high availability. You can adjust different ratios of coverage to reduce the time out between servers.

The solution is highly scalable out-of-the-box. It is able to be scaled vertically and horizontally, even use specific Federated Architecture to be able to have Regional coverage.

We have not used to technical because the online community has been very good.

We were previously using the community version of Puppet and we switched to the Enterprise version. As well we have reviewed other leader solutions on the market, but were not able to be fully compliant as Puppet Enterprise is.

The initial setup was really simple and straightforward.

Depending on the size of the organization there is a point when the price of Puppet Enterprise should be lower. However, they provide really good functionality, features, and capabilities.

Yes, we compared vs Ansible, Salstack and Chef

My advice to those wanting to use this solution is to make sure they have the skills for it, the learning curve is slower than with others, but could provide a great solution and coverage.

I rate Puppet Enterprise an eight 9 of ten.

Until last year, we were using the enterprise version — Puppet 4 —; however, we recently switched to the open-source version — the community edition. We are using a product called Foreman as a front end for Puppet open source.

We used Puppet solely for Linux. At first, we had around 200 plus Linux servers that were managed by Puppet. It was like infrastructure as a code. If we had to build a new server or update a server, then we just had to commission a new server, apply Puppet control, and it would configure everything for us. That was one of our main use cases.

We also used it for compliance. We had some security products and policies that we needed to implement. This solution made sure that they're always there, that nobody was messing with them. Regarding security compliance, take CrowdStrike for example, it's supposed to be installed on every server — running and reporting properly. Puppet checks that a service is running every 15 minutes. If it's not, it starts it and if it's missing, it installs it. 

Although we started with Linux, we are moving towards adding Windows servers as well. 

We have a central code. If anyone makes any changes to the infrastructure, we'll get notified. We have around 10 people all managing the same infrastructure so there's always the chance of overstepping each other's work. When it's all centralized as a code, a single repository, it's easier to manage because everybody gets notified of what changes are being made.

Puppet has a big code repository hosted at puppet forge. Most of common tools and applications can be managed out of the box or by downloading the respective module from PuppetForge.

There are a couple of factory features included that I like. Anything that we manage through Puppet always runs perfectly. The ability to have infrastructure as a code is nice. Every two or three years we upgrade to the most recent version of Linux and build new machines. Afterward, it's just a matter of assigning roles; then we can forget about it and let it do its thing. 

The main thing that we noticed when we switched from the enterprise version to the community version was the difference in cost — the infrastructure is pretty expensive. We work in the education sector so we get really good discounts from vendors. Other universities, including Harvard, use a competing product called Ansible. The only reason they use Ansible is that they got it for a really good price. We tried to get an educator's discount with Puppet, but unfortunately, we couldn't reach an arrangement. That's why we had to switch to the community version.

As far as stability is concerned, this solution is rock solid. We have a single server — it's called the  Puppet Server. We never have to think about having a cluster or backup server for it because it's so stable. That's one of the reasons why we kept using it instead of moving to Ansible. Moving to a different platform would require a massive learning process. 

Puppet is pretty scalable — so far. Currently, we have 400 servers that are communicating with Puppet, pulling policies every 15 minutes. It gets sluggish sometimes, but a single server has been able to manage all of this. I think if we get to more than 500 VMs, we might have to add more servers. Currently, I think we have a very small setup. I think it's more than good for us.

Their technical support has been really good. We have used Puppet technical support as well as third-party support companies. We worked with a company called Bitlancer; they helped us with some of the code. Puppet can provide us with backend support for any service issues, but code is something that we have to work out with the community. The community is very strong as well. If we have any trouble with code, we can ask them in the forums — they're always helpful. I think the support is very good overall.

Before we began using Puppet, everything was manual. Once we moved to Puppet, it opened up a completely new world of automated management, which was amazing. We could never go back. Now, on the Windows side, we use something similar called SCCM. Before that, we used group policies to manage our servers. It's not the same as Puppet because you can only manage things that are built into the OS. Installing software manager roles and configuring servers is difficult. 

The initial deployment is very easy; it's actually one of the best. Even before Puppet, we used to have one script that we used to run. The server was commissioned and then we'd run the script. Now we don't even have to do that because it's part of our image. 

For this reason, any new servers that we build already have Puppet installed. As it's part of our template, all we have to do is push the template and the new server automatically starts communicating. It pulls everything that it needs from the Puppet server directly.

Deployment takes around 10 minutes per server. Our servers get the base policies first and then we can assign the role — the policies are based on their role. It takes roughly two to three runs through Puppet to get all of the policies in place. It sounds like a lot, but it's pretty straightforward.

We have our own people that handle deployment. We have a team of 10 people who manage the infrastructure. They're called the infrastructure group. The IT team is called EIG — Enterprise Infrastructure Group. All of us pretty much continuously building servers and working on different use cases. 

Some maintenance is required. We have to update the infrastructure. It's a bit of a pain point to make sure that everything works once we've upgraded it because Puppet has been evolving pretty fast. From one version to another, a lot of things can break when we upgrade them.  Although it comes with tools that can be used to verify that the code is supported, even after verification, it still breaks sometimes. 

We have definitely seen a return on our investment with this solution. Switching to Puppet Enterprise was a game-changer for us. It was totally worth it, but there is a reoccurring cost associated with it because you have to pay a yearly licensing fee. We got a lot out of it in that time period. When we began exploring in Windows side, we didn't know if we would see a return. 

Puppet was a good product; we used it when we had 200 VMs. When we tried to add Windows servers to it, that's when we realized the price nearly doubled for us because we also have around 200 Windows servers. Puppet doesn't offer discounts for the education or non-profit sectors as pretty much every other product in the IT industry does. We get pro services from Microsoft at a very discounted price; and great offers, too — easily 60% off retail prices. Our managers tried to negotiate with Puppet asking if it was possible to add two hundred servers without doubling the price. Sadly we couldn't come to an agreement. 

That was unfortunate because Puppet Enterprise has some of the features that we are now missing. Now, some of the code that was provided by Puppet is no longer usable on the Puppet community edition. I think that's the only downside of moving to the community version.

We evaluated Ansible — it's also good. The way Ansible works is a bit different than the way Puppet work. That's where we struggled with Ansible. Ansible is the kind of solution that only requires a one-time configuration. If we want to build a new server, we can easily build it with Ansible and Ansible will do all the work for us, but it's the compliance part that was missing from Ansible — it wasn't a built-in functionality. With Puppet, if you have built a server and someone changes something, within 15 minutes, Puppet will run and revert the changes. So, it's the compliance part that we like about Puppet. 

Puppet is one of the best products available — even when it comes to the cloud. It's very popular. There are only two main cloud competitors when it comes to configuration management: Puppet and Chef. I think both are strong products. Puppet has been the king of the market. To anyone interested in using Puppet, I always recommend that you start with the community edition first. If you don't require enterprise features or management, then you can get it for free. If you need those features, then you can always upgrade.

Overall, on a scale from one to ten, I would give Puppet a rating of nine. I don't think that similar products have any strengths that Puppet doesn't have.

Puppet Enterprise is a stable solution.

Puppet Enterprise should improve the general extensibility for places where they can't install it.

I have been using Puppet Enterprise for five years.

Puppet Enterprise is a stable solution.

Puppet Enterprise is a scalable solution. We usually recommend Puppet Enterprise for larger companies that have mature CI/CD structures and image management processes.

The solution’s initial setup is easy.

Puppet Enterprise can be an expensive solution for smaller businesses.

Puppet Enterprise is more suitable for clients working up much more structured deployment images they manage internally. Before choosing Puppet Enterprise, users should think seriously about what they're trying to accomplish and ensure they put the right pieces in place.

Overall, I rate Puppet Enterprise an eight out of ten.

Our use case is provisioning and then configuration management for on-prem servers primarily. We use it for applications as well. We were using Puppet for database configuration management. Basically,  we mainly use it for configuration management for on-prem servers of infrastructure and then use it a bit on the application side as well.

I like the way it keeps the configuration management profile simple. The programming in it is based on the stage-based coding in BYML, which is very comfortable for us to use. 

The organization of the overall product in terms of usage is very good. 

The number of modules available and the compatibility with a large number of devices makes it simple to use. It was very helpful in managing the server infrastructure on both Linux and Windows platforms, as well as on the network side on the Cisco switches. 

The versatility is great.

Puppet may be already working on this, however, it would be helpful if they made the product agent-less or making an option for agent-less. They may offer that in Puppet Bolt. I haven't explored that much. 

The compliance side needs work. Puppet doesn't have much in terms of dealing with compliance. Chef has inSpec. On Red Hat, we are getting Insight so that we can run some standard templates for compliance, like CIS or DSR, PCI, or something of that nature. We can use those templates to harden the environments and perform a security checklist within those environments.

There's a lot of scope for enhancement on the DevSecOps side. They should definitely include features for compliance, for both the Linux and Windows side of the devices, as well as for network devices. Compliance is something they need to work on.

It would be great if there was integration with some InfoSec tools like Lenovo.

The pricing of the solution is a bit high.

I've been using the solution since about 2016.

It's quite a quite stable product. I actually never had to reach out to Puppet for support, as the product itself is quite stable and it never reached a situation where we were unaware of what was happening and needed the help of technical support. For the last two or three years, it's been perfectly fine. It's pretty much customizable and very stable. It's very good.

Scalability-wise, we tried going with the two nodes for high availability purposes. In terms of clients, as far as the endpoint, you can add as many as you want. The versatility is also good. You can have different types of endpoints from the app ranging from application to the network devices, to Linux servers, to Windows servers. Everything can be added on. It's good. The scalability is fine.

We've never had any issues with the product, therefore we've never had to reach out to technical support. I can't speak to their level of responsiveness or knowledge, however, I can say, for us, the solution works fine without any issues that require support.

The initial setup was not too complex. You need to have a good vision about how you want to implement it across the organization and the use cases. If you have that in place, then you can implement it with relative ease. The installation of it is straightforward, so you just need to follow the documentation and the steps.

We didn't use an integrator or consultant. We handled the implementation ourselves.

The pricing is a bit on the higher side. It can be done more at a more reasonable rate. However,  that depends on the size of the environment we are dealing with and the best deal we can get after negotiation. The pricing is something they can work on to reduce a bit.

We're just customers. We don't have a business relationship with Puppet.

I would recommend it to others who have large-scale environments. It's a very good product for that type of organization. For example, if you have 5,000 or 3,000 plus servers, it's definitely a go-to.

Overall, on a scale from one to ten, I'd rate the solution at an eight.

I think deploying computer direction changes over production environments. The main purpose for this automation tool would be:

• Deploying
• Controlling
• Ordering Change for the System
• IT Infrastructure

Puppet Enterprise has reduced the time of production changes or environment changes. It is reducing the time that the engineers spend applying changes of our infrastructure. They set it all up, the next environment, and after they have been tested, when they have to promote a change, they just apply it, and it's turned on on many of hundreds of open sub-ports. To do it manually, reducing the operative time, is a really big part. I think that's the most valuable thing, because your engineers use their time with creative things, visionary things, not doing repetitive tasks.

There are two kind of Puppets: Enterprise and Open Source. So, I use Puppet Enterprise, it's helped promote the console and the recording, the reading, controlling, the checking of managed change and putting the things back together.

I like it as the main. I can be relaxed, knowing that everything is in the state that it should be without taking many steps to find out how and to fix the things where there were changes properly ensures that.

It saves us time, we can apply patches through Windows servers, with our tools. But, with Puppet, it can save us approximately 38 hours a month.

We are constantly improving new features, like deploying. But also, I think that they're very strange. It is how the community contributes with the models that they have in Puppet first. But it's a continuous improvement process. We are always discovering new things.

No. I haven't had any issue with the stability of the product.

Well, if you are going bigger, you need to have more master servers and perform a low balancing from the servers. Also, yes, I feel like the kind of example, there's a limit of nodes that can be managed from one server. So I don't remember exactly how many. But if you need to add more nodes, you need to deploy another server into a trust relationship. Then you can deploy more nodes. I've had no issues with that.

I haven't gone too big. So I'm only working with one master.

You always find an obstacle, but you to give the feedback to them. Then, they can guide you through this to fix things that can help you to get your goals.

Well at the beginning it was kind of complex. Because you had a lack of knowledge. So we would have to read a lot. Test many things, the configuration. After training, we saw things more clearly. We got to change the approach when they were working on. But no, it wasn't very complex. There's a lot of knowledge that you need to read in the documentation. There were no issues if someone with experience pitched the things together. 

It was a learning curve. Not too hard. It's more like a not too high, not too low. It was a small learning curve.

Well I'm trying to do my job to grow the community around here. Even in Santo Domingo, Dominican Republic, where we recently deployed a project using puppet. The system manager, the assistant system manager right now is being pain when applying changes between environments. Tried creating a folder in 20 servers, for example. 

I'm trying to create a community. More people know about the same, they can share experience and work together. This is part of the mantra we live by. I think that this thing is nice, these things can help you to get your goals quicker, to get these things managed in the proper way, to free up your time to use it in a more productive way.

I think that they can only imagine $120 for node. I think it's not expensive for me, from my perspective because of what you gain and all the balances I think it will cost more than that. If you are going bigger, the licensing stuff can be doable, but I think that you can manage in the license in all the high volumes. From my perspective, I think it's not expensive. I think it's fair.

I was trying to manage some drops raspberry pi from a Puppet master server. I wasn't able to reach that goal because there is no urgency for raspberry pi. I think I can block it, because you can use raspberry pi to manage many automation things. Many things from an IOT. I found that a couple of years ago, and I stopped playing with that.

When you're using the console, it is user friendly. When you have to go down to the folders and the configuring or creating or writing code, you have to use your text editor and get down into the code. So, when everything is already configured and the models are deployed and tested, and you're pretty sure that everything's working fine, you can create a configuration, create your environment groups deploy the changes, go around the changes, using the console, the web console and it works pretty easily.

Puppet3 and 4 series provides optimum deployment solutions for infrastructure and applications.

This product has vastly increased our company’s release management and product stability functionalities.

We would like Puppet to add more integration for applications.

I have used this product for 7+ years.

Need to align with Agent Less Setup.

I have not encountered any issues with stability.

I have not encountered any issues with scalability.

We are highly impressed with their technical support and I would give it a 9 out of 10 rating.

I found the setup to be quite simple and easy.

Implement through vendor as special skills required.

This solution supports more of agent based work.

Before choosing this product, I evaluated a lot of options.

I would recommend to make use of outsourced software solutions such as Atgen for ensuring a stable setup process.

Declarative nature of Puppet with its hub spoke architecture for automation using agents is the best feature.

All of the infrastructure patching and provisioning was done using Puppet.

It needs GUI based automation. There is way too much command line work involved.

Puppet is mainly command line tool with most of the scripts created through declaration. I was hoping they allow creation and deployment of these scripts through GUI based interface. In fact, if possible, they should allow deployment of all of the management infrastructure and agents deployment through process center like mechanism

2 years.

None.

No problems.

No problems.

With the community version, the support is very sketchy. Once we bought into the enterprise version I found it very helpful. In fact, we developed very strong relationships with Puppet folks

Excellent.

I am now using Ansible and it's also a very good product. It easier to use than Puppet.

No. It needed management infrastructure and needed HW procurement.

Vendor Team. Expertise was top notch.

Not measured. Use of Puppet was part of larger cloud agnostic IaaS provisioning project for the enterprise. Return on IaaS project was breaking even in the same year with deployment of 500 VM servers with 3 tier app stack. Annual ROI from savings thereafter was to the tune of 60-80%

We looked at Chef and Salt.

The valuable features I found are installing packages remotely and pushing files from a centralized server. Also, we can create users and monitor services remotely.

We used to have lot of issues related to sudo rights on server. Now, we have centralized sudo file managed by puppet on a centralized linux server. So, any of user requests for addition or removal of sudo access, we make changes on puppet master for specific requested node and changes get pushed to puppet client on next cycle.

The features I used so far are quite interesting and helpful.

I have been using Puppet for one year now.

There were no issues encountered during deployment

The initial setup was quite straightforward. I reviewed some of the videos on YouTube and they helped a lot for implementation.

We implemented it in-house.