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.
Strong Core Software, Disappointing Community Additions
What do you like best?
The diverse collection of community cookbooks.
What do you dislike?
The lack of maintenance on the majority of community cookbooks, which requires me to re-invent the wheel rather than use a pre-existing framework.
What problems is the product solving and how is that benefiting you?
Reproducible infrastructure. Chef is a great tool for infrastructure management, as long as you know what you're doing. Chef's documentation does not hand-hold users through its set-up, use, or troubleshooting so I've regularly relied on third-party blogs/instructions to maintain my Chef cookbooks. If you're looking for a tool that guides you through installation, configuration, and use, I recommend Puppet.
Recommendations to others considering the product:
If you're new to configuration management ideas in general, Chef has a steep learning curve. The Chef software gives its admins just enough rope to hang themselves. If you're already familiar with the Chef DSL (or config management DSLs in general), Chef is a powerful tool.
- Leave a Comment |
- Mark review as helpful
Chef is neat and awesome
What do you like best?
Open Source
Community support.
Documentation is great.
Well written Chef blogs to understand steps and procedure.
Automated deployment of application in a farm.
Availability of well written cookbooks.
Ease of development with just enough knowledge of Ruby.
Community support.
Documentation is great.
Well written Chef blogs to understand steps and procedure.
Automated deployment of application in a farm.
Availability of well written cookbooks.
Ease of development with just enough knowledge of Ruby.
What do you dislike?
Installation should be made little faster.
knife-plugins support is less
Some of the cookbooks are not maintained..
knife-plugins support is less
Some of the cookbooks are not maintained..
What problems is the product solving and how is that benefiting you?
We wanted to do one-click installation of application on cloud.
Did a setup right from bare-metal provisioning and then used Chef for application deployment on Private Cloud. Developed shell scripts which triggers chef-client once a machine is ready on blade server. Used knife-plugins to manage private cloud farm.
Some of the benefits realized were ease of testing cookbooks using test-kitchen and Vagrant. Chef-solo was also helpful.
Did a setup right from bare-metal provisioning and then used Chef for application deployment on Private Cloud. Developed shell scripts which triggers chef-client once a machine is ready on blade server. Used knife-plugins to manage private cloud farm.
Some of the benefits realized were ease of testing cookbooks using test-kitchen and Vagrant. Chef-solo was also helpful.
Recommendations to others considering the product:
I recommend to use Chef because of following reasons :
Community support is amazing. You have developers/users in the list who help to solve your problems. You need not be proficient in Ruby, just know-how of Ruby is enough to start developing recipes. Most of the cookbooks available on Chef's git-hub page can be re-used and customized as per your requirement. It also supports majority of Operating Systems. I have worked with other configuration management and remote execution systems, but it all depends what your need is and which one fits your environment. Rather than wading through so many tutorials, decide on one and be on it.
Community support is amazing. You have developers/users in the list who help to solve your problems. You need not be proficient in Ruby, just know-how of Ruby is enough to start developing recipes. Most of the cookbooks available on Chef's git-hub page can be re-used and customized as per your requirement. It also supports majority of Operating Systems. I have worked with other configuration management and remote execution systems, but it all depends what your need is and which one fits your environment. Rather than wading through so many tutorials, decide on one and be on it.
Excelent server automation tool
What do you like best?
There are plenty of well written, documented and supported Chef recipes for dealing with all sorts of server automation, like users management, database management, Solr configuration, full application stack configuration (Sensu, Gitorious, Redmine), SSH, and many more commonly used software. All of them are open-source and have plenty of customization options. Chef itself has good documentation.
Dependencies management is very easy and robust by using librarian-chef.
Chef's verbose mode is very helpful when debugging what a recipe is doing and there's also a dry runner mode which won't actually run anything in the server, which is also helpful in some cases.
Unlike Puppet there's no domain specific language to learn, which is a big advantage for me. You only have to learn a bit of Ruby, which is an easy language to learn and use and you are able to perform any logic pretty easily when compared with Puppet which is quite limiting when you need some custom logic which is not handled by their DSL and you are forced to extend their DSL.
Chef can be configured through an specialized server that will orchestrate all managed servers or they can be used without setting up any Chef server, through chef-solo. Chef-solo can be integrated with Vagrant as well to help setting up a development environment very quickly.
Dependencies management is very easy and robust by using librarian-chef.
Chef's verbose mode is very helpful when debugging what a recipe is doing and there's also a dry runner mode which won't actually run anything in the server, which is also helpful in some cases.
Unlike Puppet there's no domain specific language to learn, which is a big advantage for me. You only have to learn a bit of Ruby, which is an easy language to learn and use and you are able to perform any logic pretty easily when compared with Puppet which is quite limiting when you need some custom logic which is not handled by their DSL and you are forced to extend their DSL.
Chef can be configured through an specialized server that will orchestrate all managed servers or they can be used without setting up any Chef server, through chef-solo. Chef-solo can be integrated with Vagrant as well to help setting up a development environment very quickly.
What do you dislike?
I'd prefer Chef's focused on chef-solo for most of its beginning tutorials as I find it the easier mode to start with and also the most useful one for most small organizations. The fact that chef-solo is not the tutorials assume makes it harder for a beginner to understand how it works.
I also think they could be more backwards compatible in new releases. I remember it took me quite a while to fix some old recipes I had so that it would work in newer Chef releases...
They use JIRA to manage their tickets and I really don't like JIRA.
I also think they could be more backwards compatible in new releases. I remember it took me quite a while to fix some old recipes I had so that it would work in newer Chef releases...
They use JIRA to manage their tickets and I really don't like JIRA.
What problems is the product solving and how is that benefiting you?
We integrate Chef and Capistrano to manage our servers and deploy our applications. Since both are written in Ruby, we can share a dynamic configuration written as a Ruby DSL that is used by both Chef recipes and Capistrano tasks. We use Capistrano to run Chef in the servers requiring changes.
For example, we manage multiple environments and applications in a shared set of servers. We have a database server and two application servers and we are able to properly manage the database in the database server through Chef, configure Solr, install packages in the application servers, set up nginx in the right server and everything that is required for the application to run and finally run the deploy procedure using Capistrano tasks, which are more well suited to handle deploys and rollbacks than Chef is. The server management part is handled by Capistrano running chef-solo in the right servers. Then the deploy proceeds as usual with regular Capistrano tasks. All with a single command line that will inform the application, which application server to deploy to and the environment (production, Cert, experimental, staging and others).
Being able to run a single command to handle the full deployment cycle gives a lot confidence specially because there are lots of steps involved for our applications to be properly configured and run in our servers... It would be really easy to forget some of those steps in a big release without the automated recipes.
For example, we manage multiple environments and applications in a shared set of servers. We have a database server and two application servers and we are able to properly manage the database in the database server through Chef, configure Solr, install packages in the application servers, set up nginx in the right server and everything that is required for the application to run and finally run the deploy procedure using Capistrano tasks, which are more well suited to handle deploys and rollbacks than Chef is. The server management part is handled by Capistrano running chef-solo in the right servers. Then the deploy proceeds as usual with regular Capistrano tasks. All with a single command line that will inform the application, which application server to deploy to and the environment (production, Cert, experimental, staging and others).
Being able to run a single command to handle the full deployment cycle gives a lot confidence specially because there are lots of steps involved for our applications to be properly configured and run in our servers... It would be really easy to forget some of those steps in a big release without the automated recipes.
Recommendations to others considering the product:
I'd recommend starting with the chef-solo mode, which is much easier to start with and well suitable even for more complex servers infra-structure. Also, take some time to learn some Ruby if you are not comfortable with the language.
Simple yet Elegant
What do you like best?
When you are a rapid web designer/developer, you never want to be late on delivery.
Chef should be your choice if you want to automate or config a system the way you want.
It's easier than what you might think.
Test it today!
Chef should be your choice if you want to automate or config a system the way you want.
It's easier than what you might think.
Test it today!
What do you dislike?
I've never had a problem with Chef, so I do not dislike anything about it.
What problems is the product solving and how is that benefiting you?
1. Saving time,
2. Saving Money,
3. Saving Clients
4. Learn how to think big about my future web dev needs.
2. Saving Money,
3. Saving Clients
4. Learn how to think big about my future web dev needs.
Recommendations to others considering the product:
Just use it once and you'll love it.
I use it for production technology at a cyber security startup and absolutely love it
What do you like best?
I love the ease of use, specifically the short time required to get set up and start iterating on a project using chef to manage complex configurations across large clusters of servers.
What do you dislike?
There a few things I don't like, but one in particular is that when first learning chef I found it hard to find exactly what I needed in the documentation and tutorials. Eventually, however, I was able to dig through enough documentation that I found what I needed.
What problems is the product solving and how is that benefiting you?
I am using Chef to automate configuration across many servers that require rapid iterations of changes to configuration. Without chef, I wouldn't be able to deploy changes to hundreds of machines spread across the world.
Recommendations to others considering the product:
Rather than trying to parse through many tutorials, just get started on a project with it. You'll find that Chef's intuitive design makes this method of learning easy!
Vagrant User
What do you like best?
I won't state how much I like chef due to its automation, but I'd like to say that in comparison with puppet and ansible, it gives better control as it allows you to "develop" your system. The dependencies system that's out of the box due to Ruby is really good! As a vagrant only user, chef-zero was the product that I really needed!
What do you dislike?
- I have to write ruby
- As a vagrant user, it feels it has quite some overhead when the system bootstraps
- It takes more time to write something "quick and dirty", while ansible performs better for MVP cases
- As a vagrant user, it feels ugly the way I have to manage my secret files, databags are not the best case
- As a vagrant user, it feels it has quite some overhead when the system bootstraps
- It takes more time to write something "quick and dirty", while ansible performs better for MVP cases
- As a vagrant user, it feels ugly the way I have to manage my secret files, databags are not the best case
What problems is the product solving and how is that benefiting you?
As a team leader, I've manage to create a unified environment for my team members, and having it on git, we are having the opportunity to all extended based on our ongoing needs. Using chef like that, It also gives me the opportunity to have a "shared communication protocol" with the devops side, and not missing any details that have been developed throughout the development phase.
As a business perspective, it has make the dev environment "disposable", as everything that's needed run in the Dev's VM and their laptops have no value now, or worrying if they got stolen
As a business perspective, it has make the dev environment "disposable", as everything that's needed run in the Dev's VM and their laptops have no value now, or worrying if they got stolen
Recommendations to others considering the product:
Make it being easier to bootstrap new projects - MVPs, maybe use some template bucket?
good work in setting up instance in cloud
What do you like best?
After use the chef, it's easy and take very less time to set up a production instance(from 2 weeks to 3 hours). It's easy to learn by official docs.
What do you dislike?
a little expensive for side project / start up project
What problems is the product solving and how is that benefiting you?
set up different environments(DEV/QA/PROD) by chef. Migrating the existing environment to the cloud and also build new environments.
Recommendations to others considering the product:
it's good enough when build a cloud environments. And it's a good option on migrating the existing biz to the cloud.
Chef let IT infrastructure implementation like an art planting.
What do you like best?
1. Chef is cross platform management solution.
2. make automation easier.
3. Just like cooking, follow the menu instruct to make a delicious meal.
4. Node role define flexible, easy and good for work.
2. make automation easier.
3. Just like cooking, follow the menu instruct to make a delicious meal.
4. Node role define flexible, easy and good for work.
What do you dislike?
1. module enhance not easy.
2. knife tool function may be could more and more.
3. Could not direct access to node console.
4. System configuration were handle by admin node(chef server).
2. knife tool function may be could more and more.
3. Could not direct access to node console.
4. System configuration were handle by admin node(chef server).
What problems is the product solving and how is that benefiting you?
not yet.
DevOps Engineer at Refinery29
What do you like best?
Chef is an all around wonderful provisioning system. I see the biggest advantage of Chef over its competitors, namely Puppet and Ansible (I don't have experience with any others), is the company and the community it facilitates. The most helpful part of the community is the wide, seemingly all inclusive, range of open source cookbooks available, which for the most part can be used out of the box to provision any system you might be building.
What do you dislike?
Developing new cookbooks—even more so when extending existing ones—for Chef requires a deep knowledge of how Chef works and of Ruby. Just knowing what you want to do is not enough.
What problems is the product solving and how is that benefiting you?
I used Chef at Elephant Ventures to build provisioning scripts for managing systems used to develop, and ocassionally deploy, web sites for our clients
Recommendations to others considering the product:
If cookbooks exist for everything you need, use Berkshelf with Chef to provision your systems. If cookbooks do not exist for your purposes or you need finer grained control than what existing cookbooks provide, use a different tool. I highly recommend Ansible, having built Refinery29's provisioning system using it, and have mostly heard good things about Salt, but have yet to try it.
Chef is one of best automation tool
What do you like best?
We used chef configuration management is doing good job so faar.
What do you dislike?
Process of deployment configuration is something tricky to understand but once learned is one of the great tool
What problems is the product solving and how is that benefiting you?
We have Internal product that we deploy on four different servers using chef and doing various configurations for each.
showing 51 - 60