Senior Consultant at a tech services company with 201-500 employees
Real User
Top 5
2023-02-14T12:30:57Z
Feb 14, 2023
Chef is primarily used for configuration management. For example, if you are managing a large number of servers (thousands or more), it is essential to ensure that the configurations across all servers are consistent. Otherwise, making any changes to the configurations would require writing a script to apply those changes across all the servers. Additionally, end-users may change configurations on multiple servers, leading to inconsistencies across different servers. To avoid this, configuration management is required. We use Chef for this purpose by using a server-client mechanism. We apply changes to the Chef server, and every 30 to 40 minutes (depending on the configuration), Chef will verify whether the server has the required configuration. If not, it will revert to the required configuration automatically.
Chef is a configuration management tool, and I work for the product team of Chef. All the DevOps teams mainly use Chef for configuration management of their servers or infrastructure.
DevOps Engineer at a manufacturing company with 1,001-5,000 employees
Real User
Top 5
2023-09-18T15:42:00Z
Sep 18, 2023
Chef is like a master chef in a kitchen for computer systems. It's used to create recipes (cookbooks) that specify how servers and apps should be set up. Chef then makes sure these instructions are followed the same way on all computers in a network. The ChefServer is like the recipe book, where all these instructions are kept and shared, making it easier to manage and control how software and systems work in a company.
Presales Consultant - Solution Architect at Hewlett Packard Enterprise
Real User
2022-04-05T19:28:23Z
Apr 5, 2022
Chef is mostly for the operating systems to deploy or style, e.g. not containers. Before the containers, you need hardware, then an operating system, then you start to work on Kubernetes. To automate those steps, we use Chef. The tool is useful for provisioning the operating system, because as you talk about the ops, sometimes customers ask to further deploy everything through automation, e.g. starting from scratch. You need to use different tools for you to provision via automation, so you need Chef. We use an automation tool such as Chef, then we were able to run Docker or containers on top of the hardware and operating system.
We use it for deployment of applications. It is a tool that you can use on the back-end for deploying architectures. I have used the product for a couple years. I used to work for an online data center, and we used Chef for a lot of the tools and appointments.
Our primary use case of this solution is for the orchestration of the service deployment, and integrations. Earlier, we had it on-prem but now it's totally on AWS cloud. AWS cloud is easier to use, and changing and refitting the architecture solutions is very easy.
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."
Our primary use case is having the properties set up across the servers. We have Chef recipes deployed and configured across our servers, so we get the same type of replication across our servers and environments. We are using the on-premise version. We have our applications already set up for on-premise. We are using Chef and preparing it for CI/CD and other properties. Now, we are planning ahead and will use the AWS service too.
My primary use case for Chef has been always for infrastructure provisioning. For example, infrastructure as a cloud, provisioning it in a multi-cloud environment. That's predominantly what we're using Chef for.
Senior DevOps Engineer at a tech services company with 1,001-5,000 employees
MSP
2018-07-01T08:03:00Z
Jul 1, 2018
I used Chef for server provisioning in AWS using the knife-aws plugin. I also used Chef as a configuration management tool. It did all the setup and configuration for all the software packages for multiple servers. To make any updates to the server setups, all we did was update the recipes on the Chef Server.
Chef, is the leader in DevOps, driving collaboration through code to automate infrastructure, security, compliance and applications. Chef provides a single path to production making it faster and safer to add value to applications and meet the demands of the customer. Deployed broadly in production by the Global 5000 and used by more than half of the Fortune 500, Chef develops 100 percent of its software as open source under the Apache 2.0 license with no restrictions on its use. Chef...
Chef is primarily used for configuration management. For example, if you are managing a large number of servers (thousands or more), it is essential to ensure that the configurations across all servers are consistent. Otherwise, making any changes to the configurations would require writing a script to apply those changes across all the servers. Additionally, end-users may change configurations on multiple servers, leading to inconsistencies across different servers. To avoid this, configuration management is required. We use Chef for this purpose by using a server-client mechanism. We apply changes to the Chef server, and every 30 to 40 minutes (depending on the configuration), Chef will verify whether the server has the required configuration. If not, it will revert to the required configuration automatically.
I used the solution to transform my infrastructure into code.
Chef is a configuration management tool, and I work for the product team of Chef. All the DevOps teams mainly use Chef for configuration management of their servers or infrastructure.
We were using the tool for managing Kubernetes.
Chef is like a master chef in a kitchen for computer systems. It's used to create recipes (cookbooks) that specify how servers and apps should be set up. Chef then makes sure these instructions are followed the same way on all computers in a network. The ChefServer is like the recipe book, where all these instructions are kept and shared, making it easier to manage and control how software and systems work in a company.
Chef is mostly for the operating systems to deploy or style, e.g. not containers. Before the containers, you need hardware, then an operating system, then you start to work on Kubernetes. To automate those steps, we use Chef. The tool is useful for provisioning the operating system, because as you talk about the ops, sometimes customers ask to further deploy everything through automation, e.g. starting from scratch. You need to use different tools for you to provision via automation, so you need Chef. We use an automation tool such as Chef, then we were able to run Docker or containers on top of the hardware and operating system.
* For software management * Competitive deployment * Upgrade
We use it for training.
We use it for deployment of applications. It is a tool that you can use on the back-end for deploying architectures. I have used the product for a couple years. I used to work for an online data center, and we used Chef for a lot of the tools and appointments.
It's for deployment and configuration automation.
We use it for integration management.
We use it for provisioning Adobe Experience Manager web application environments.
Our primary use case of this solution is for the orchestration of the service deployment, and integrations. Earlier, we had it on-prem but now it's totally on AWS cloud. AWS cloud is easier to use, and changing and refitting the architecture solutions is very easy.
I have used in my current company for three years, and with other clients for more than ten years.
It is for orchestrating our servers and deployments to do integrations.
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."
Our primary use case is having the properties set up across the servers. We have Chef recipes deployed and configured across our servers, so we get the same type of replication across our servers and environments. We are using the on-premise version. We have our applications already set up for on-premise. We are using Chef and preparing it for CI/CD and other properties. Now, we are planning ahead and will use the AWS service too.
My primary use case for Chef has been always for infrastructure provisioning. For example, infrastructure as a cloud, provisioning it in a multi-cloud environment. That's predominantly what we're using Chef for.
I used Chef for server provisioning in AWS using the knife-aws plugin. I also used Chef as a configuration management tool. It did all the setup and configuration for all the software packages for multiple servers. To make any updates to the server setups, all we did was update the recipes on the Chef Server.