Chef Automate (First 10 nodes free)
Chef | 1.8.85Linux/Unix, CentOS 7.2 - 64-bit Amazon Machine Image (AMI)
External reviews
External reviews are not included in the AWS star rating for the product.
Chef for cooking safe security
What do you like best about the product?
I like the open community with lots of resources present in the documentation and also video tutorials which help someone like me who was new to this technology pick up and complete the tasks assigned easily and effectively .
What do you dislike about the product?
Compatibility with different programming languages such as python.
What problems is the product solving and how is that benefiting you?
Benchmarking and compliance is a huge headache for anyone working in this sector which is minimized by chef.
- Leave a Comment |
- Mark review as helpful
Progress Chef is an excellent tool for devops automation.
What do you like best about the product?
Progress Chef is an amazing tool for devops automation. The ease with which we can configure the instructions using receipes and cookbooks are the best feature. It is implemented using Ruby language which is super easy to understand and use as well.
What do you dislike about the product?
The chef workstation for development for cookbooks and recipes should possible be replaced by something of a UI based. Something similar to Jenkins which can provide easy configuration options.
What problems is the product solving and how is that benefiting you?
We are using Progress Chef to automate our server patching tasks. As part of security remediation, patching is one of the tedious task which we could automate completely thanks to Chef.
Easy to learn and implement
What do you like best about the product?
It is easy to pick up the concepts and even easier to implement
What do you dislike about the product?
Moving between versions can be a headache.
What problems is the product solving and how is that benefiting you?
Compliance reporting and easier configuration management
Chef reviews
What do you like best about the product?
The vast variety of receipies in the community. Almost every tool installation has their own recipe. And easy management of central store for receipies.
What do you dislike about the product?
The configuration tree for the receipe can be bit less complex.
What problems is the product solving and how is that benefiting you?
Managing multiple organisations in a single chef server .
Best server management tool
What do you like best about the product?
I was in deployment department so for every software I need to configure all server manuall like supponse you have many servers that time you don't need to configure you all server just only update on workstation then it will update on all servers another thing is some times yon need to change you ENV variable so that time you can't run you dockesr image for all server instead of these just replace value by suing chef is another best part also for CI/DC part is best
What do you dislike about the product?
Here is nothing for dislike, but If they provide us containerization with server configuration like dockers with chef that time it will really easy to handle and many people will switch on this
What problems is the product solving and how is that benefiting you?
We had one project in which we white label all things and deployed code on a different server for every client, so at that time, I needed to deploy code on 24 servers, and 70% of work for all servers were the same that time the first time I used chef and It reduced my working time from 2 weeks to 2 days and some time clint give updated information about his env like SMTP or third party URL so that time chef really helpfull
Recommendations to others considering the product:
If you want both CI/CD and server configuration in good manner that time use chef
Chef Review
What do you like best about the product?
Its very good tool to setup configuration management
What do you dislike about the product?
its a agent based tool thats why we need to install agent everytiem
What problems is the product solving and how is that benefiting you?
we are doing configuration management using the chef
Recommendations to others considering the product:
yes i always recommended chef to use for CI/CD
Easy to deploy with Chef
What do you like best about the product?
We have build the scripts which makes it very easy to deploy with Chef.
What do you dislike about the product?
If something goes wrong its not easy to debug
What problems is the product solving and how is that benefiting you?
All our deployments are with Chef now.
Recommendations to others considering the product:
Try it.
Chef Configuration Management tool
What do you like best about the product?
Most of our client uses Chef to deploy new code in an automated fashion. We also use it to update existing configurations and push those changes in an automated fashion to large groups of servers. Having the ability to deploy simple or full system changes out to a large group of servers with little human interaction has been a game changer for our company allowing us to deploy at scale and grow our infrastructure as our company grows.
What do you dislike about the product?
It is very complex tool and The Chef-client agent needs to be run on the nodes frequently to update the details of it state to master. And also to index the nodes based on tags.
What problems is the product solving and how is that benefiting you?
Chef is really great when teams are attempting to migrate over from legacy systems. In our case, it was a switch over from AIX to Linux. Thus, it was a great opportunity to use Chef to build out deployment cookbooks that could then be used win order to set up the new servers in preparation for the upgrade.
Recommendations to others considering the product:
Yes, Centralized Configuration Management; Chef really excels at that as it provides a wide range of features that are well thought of, such as data bags, encrypted data bags, roles, shared repositories, cookbooks versioning, environment locking..etc
It never uses any type of human-readable interface. Therefore, you don't have to go into a GUI nor use a command line tool.
We use it for provisioning and ongoing configuration management. We provision boxes with Chef by taking a base AMI that already has Chef installed, and already has the appropriate credentials to connect to the main server. Then, this will be able to roll out and deploy the configuration. In addition, it runs every five minutes, so any unexpected changes to the configuration get automatically reverted.
This means, you get developers, who go into the box and change something, thinking it will be okay. Then, they come to you, asking "Why isn't this change that I'm making working?" We have to explain, "Because it shouldn't be going into the box in the first place."
How has it helped my organization?
One thing that we've been able to do is a tiered permission model, allowing developers and their managers to perform their own operations in lower environments. This means a manager can go in and make changes to a whole environment, whereas a developer with less access may only be able to change individual components or be able to upgrade the version for software that they have control over. This allows us to return some of the control back to the developers, which saves our nights and weekends.
What is most valuable?
One advantage Chef has over Ansible is your operations can be entirely headless, meaning that they can interact directly with the Chef database using shared credentials. It never uses any type of human-readable interface. Therefore, you don't have to go into a GUI nor use a command line tool. You can hit the database directly with a library.
With Ansible, a lot of the operations require that you have some type of frontward-facing tool in order for it to perform, e.g., command line or a GUI available. For a smaller scale operation, if you're managing fewer than 100 nodes, this might be fine, as it might be more helpful if you can transfer some of the power over to your developers in order to perform certain operations.
However, if you're handy enough with DSL and you can present your own front-facing interface to your developers, then you can actually have a lot more granular control with Chef in operations over what developers can perform and what they can't.
What needs improvement?
One of the biggest things that I miss is in Chef 11 and earlier, organizations were able to be managed directly through the Chef control command line utility. Now, while we prefer to interact directly with the database, there is still some value in being able to have access to the command line utility. While that functionality is still present and in the documentation, it has been broken since Chef 12. We are now looking at Chef 14, and they already have Chef 15 in the pipeline, but there appears to be no effort to fix this functionality, which is definitely broken, provides a false positive for a result when you perform the operation, and doesn't work.
It would be nice to have an update to Chef Zero, such that it was more geared toward containers. Before Docker took hold, there was something called Chef Zero Vagrant, which was a plugin for Vagrant which would provision your developer's local copies of their environment for local testing. This was great for the technology, but we haven't seen an evolution of it now that the containerization technology has moved forward.
For how long have I used the solution?
More than five years.
What do I think about the stability of the solution?
It all seems to be very solid and stable.
What do I think about the scalability of the solution?
We have rolled out around 500 nodes. Part of the reason why we have stuck with it is that it managed to effectively scale with us and stay stable at the same time.
How is customer service and technical support?
I've contacted them before about the same issues that I have mentioned for improvement. Because Chef is being developed by a hybrid team of open source contributors, as well as the Chef core team, I am not sure my communications have gone to the right people yet.
What about the implementation team?
The integration and configuration of AWS within our environment is a whole other skill set. Any configuration management or infrastructure as code will be a learning curve. Integrating it requires rearchitecting, not necessarily of the design, but certainly of the philosophy by which you approach. That is part of the benefit of it as well, you can develop a new way of thinking among the developers who will assist in producing code, which is automated, scalable, easier to write automated tests for, etc.
I don't know if it can be made easier in the adoption of it, since it is already a significant change, which is a good thing.
What's my experience with pricing, setup cost, and licensing?
When we're rolling out a new server, we're not using the AWS Marketplace AMI, we're using our own AMI, but we are paying them a licensing fee.
We went the AWS route because we are fully cloud-based anyway. It was something that people who came before me were already familiar with, so it was a lot easier for me to get buy-in.
The price per node is a little weird. It doesn't scale along with your organization. If you're truly utilizing Chef to its fullest, then the number of nodes which are being utilized in any particular day might scale or change based on your Auto Scaling groups. How do you keep track of that or audit it? Then, how do you appropriately license it? It's difficult.
All you can do is communicate with them what's happening and get something that you're both comfortable with. However, if you're doing that, then what's the point of having the per-node model in the first place? It would be better to move to a fixed-pricing model.
Which other solutions did I evaluate?
We have also looked at Ansible, Puppet, and SaltStack. They all sort of have managed solutions which you can potentially purchase. Puppet definitely has a sort of old school thought process working behind it.
Over two to three years, we have not seen a stable release of Salt. They have some good ideas, but it isn't stable enough yet to use in a production environment.
Make sure that the operations crew has a background in Ruby, if you're going to choose Chef. If you have a Python crew, then look at Ansible as a potential option. Because I think they're catching up, and they will surpass Chef in pretty much every way sometime in the next 12 to 18 months.
Though, Chef Automate is still the most reliable solution.
What other advice do I have?
At the top level, it is integrated with Terraform, which is delivering whole entities and groups of nodes. Then, those nodes are individually being provisioned with Chef. The integration is seamless.
I've run my own Chef server before. We've done completely headless with Chef Zero, where we're distributing the code directly to box during provisioning. We've used Chef pretty much every way that it can be used.
The AWS software is good. There is definitely value for somebody who is trying to understand it and be able to have a deployment of it for observation. Coming into it, there's a lot to understand, as with any technology.
It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools
It's for deployment and configuration automation.
How has it helped my organization?
It streamlined our deployments and system configurations across the board rather than have us use multiple configurations or tools, basically a one stop shop.
You set it and forget it. You don't have to worry about the reliability or the deviations from any of the other configurations.
What is most valuable?
Its versatility is the most valuable feature. It's not necessarily the end all or be all solution for configuration management, deployment, etc. However, for what we use it for, it fits right in and it doesn't bloat our infrastructure (or any of our instances) that we deployed to.
What needs improvement?
The compatibility with the different platforms that we are using needs improvement. We are mainly a Linux shop, but for a lot of ancillary Windows services that we were bringing in from vendors of third-party customers and things that we are using for the supply chain that we were running, Chef did not necessarily fit across the board for what we are doing there. In-house, the product has been pretty functional for us.
I would like them to add database specific items, configuration items, and migration tools. Not necessarily on the builder side or the actual setup of the system, but more of a migration package for your different database sets, such as MongoDB, your extenders, etc. I want to see how that would function with a transition out to AWS for Aurora services and any of the RDBMS packages. If there was something that was automated rather than through the package of the database system itself, this might aid us for a lot of DR stuff, resiliency, multi-region, etc. Especially when consolidating from a lot of on-premise stuff to cloud services, this functionality might improve our rate of deployment.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
We had high uptime for it. We didn't have too many issues with the releases and the versioning that they have beeen putting out. Mostly, everything went smoothly even with major foundational changes. Overall, anytime you're doing a foundational change, there will be some growing pains, and you expect that with any tool set.
What do I think about the scalability of the solution?
Scalability is decent. Our environment has over 3200 nodes for production and lower environments. We haven't had too many problems with load or scale. When we did have issues, there were always additional resources we could deploy to scale wide or horizontally. We could also up the instant size depending on what the machines were doing.
How is customer service and technical support?
We did use technical support, but not on a regular basis. We use our contact there, our account manager, who is always readily available, if not over the phone, by email. We either open up a ticket with them or contact them directly, and they go ahead and research the issue, then get back to us with their findings.
How was the initial setup?
The integration and configuration of the product in our AWS environment was functional at the time. I didn't get to do the migration after the production environment. However, everything up until then, we had handled in our lower environments. It seemed to work as described and within the confines of what we were dealing with, and it was functional for us. I just never got to work with it in the production realm.
What was our ROI?
I have seen the ROI, but it was brief. It cut down on our workload. We supported 36 to 38 development teams with a team of six DevOps engineers. We had embedded DevOps personnel within their teams. It could have gotten to the point where we needed individual DevOps personnel for every team, but Chef allowed us, as a group of five, depending on the time we were there, to reach out to them individually, and help them on a one-to-one basis. At the same time, we provide a center of excellence for best practices. This easily could've scaled to each team needing their own direct support person, but with the ability to manage these configurations through Chef, it allowed us to hand them their best practices straight across the board. Therefore, we didn't have to go ahead and drop in on each team and help them through their migration practice.
Which other solutions did I evaluate?
We also looked at Puppet, Ansible, and Jenkins. Chef rolled things into one for us with the way that they were running their deployments.
It was more of a one stop convenience going with Chef. A lot of the features, plugins, and compatibility items that we were looking for were already bundled into the package. Rather than piecemeal things together with the other services, we directly went with Chef to make sure it was a smooth, functional package for us. We went with Chef and its suite of tools to manage things more centrally.
What other advice do I have?
Make sure when you are tooling that what you are trying to create is functional within the product. Don't try and make it do something that it's not technically, nor architecturally, designed to do. While there are corner cases for things like that, if you're going to start to wander down that road, maybe you better take another look at a wider set of tools rather than just the one that you've got your eye on or the one your executives have their eyes on.
The product is functional. The ease of setup for almost everything that we did tooling-wise was straightforward. We didn't have too many issues which were out of the ordinary, corner case scenarios when using the product. That's always a bonus. Especially in ease of the installation and configuration, it is always a good thing when you're dealing with a product like this.
It integrates with softer packages, modern packages, alerting packages, etc. Aside from the base infrastructure, there are a lot of Chef tooling and plugins which make it a rather straightforward addition to the tool set. Almost everything was off-the-shelf or out-of-the-box. We did not have to configure or rewrite it ourselves, which was a big bonus. Most of these products are usually commercialized and available with ready support and tooling.
showing 31 - 40