131–140 of 146 posts
What's a good alternative to Chef?
CINC is the recent-ish community build of the code. It's literally a drop-in replacement as the only changes to Chef Client and other bits are branding. It's the CentOS to Chef's RHEL.
Earlier quoted context omitted.
While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack. Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the…
Another approach that we have been exploring with Terraform is to treat the machine configuration as resources[1]. It works pretty well when most of the system is vanilla with a few additions to it (like installing Docker). [1]: https://github.com/numtide/terraform-provider-linuxbox
Earlier quoted context omitted.
While I'm not a proper sysadmin, Ansible is what I gravitated towards (and use for my own projects) and always seemed like the best choice out of Chef, Puppet, and Saltstack. Ansible is/was straight forward to use and understand, very F/OSS, relatively easy to orchestrate (even without tower), and had a nice ecosystem. Ansible always won for me because it was simple, and had just enough (though I always felt that the…
I was anti-HCL/Terraform for a long time due to issues with state files, but lately I honestly prefer it over Ansible whenever possible.. although I'm still not happy with the way cloud-init works on various cloud providers.
- Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your codebase/infrastructure repo is already written in it.
- Someone on your team isn't going to hang everyone else and themselves with the wide open nature of a fully featured programming language at their fingertips
- You've got some innovation tokens to spend
I think HCL is going to get more and more like a fully featured language as time goes on -- if they ever lean in to it (and introduce support for alternative "language runtimes" or something) then I would go terraform and never look back.
It's hard to recommend pulumi over terraform because of momentum, ecosystem, etc, but it does seem like a better base to start off of (and it's what I use for my own stuff).
Earlier quoted context omitted.
> Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML. I am not sure what complex config state management solution brings to the table for immutable containers. The state is immutable, so there's nothing to manage after deployment. It's like using an atom bomb to take out a zit. Puppet/Chef in their glory days, pre-cloud pre-container, excelled at managing desir…
An application running as a container bascially carries the same configuration as one running without the container bits would. That may include things like endpoint addresses, certificates, secrets, but can also be things like feature flags, authorizations, API tokens. Basically anything that's not compiled in is configuration. The deployment side also carries configuration, including things like desired amount of i…
But Kubernetes solves most of this problem in an easier way with Pods, ConfigMaps, Secrets, Services and Endpoints.
Earlier quoted context omitted.
I was anti-HCL/Terraform for a long time due to issues with state files, but lately I honestly prefer it over Ansible whenever possible.. although I'm still not happy with the way cloud-init works on various cloud providers.
I'd like to recommend that you try pulumi. Terraform is definitely a fantastic tool, and it really does have just about everything you want (and is extremely google-able with easy to find experts), but I think the bring-your-own-language paradigm is better for this particular use case if a few things are true: - Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your co…
Progress has an interesting angle of providing a suite of developer tools with their products crossing the categories of both design-time and run-time. There doesn't seem to be too much focus at this point though, in comparison to JetBrains for example. I'd imagine more acquisitions are coming. They have the Telerik suite of tools, which is used by .Net developers, but how many .Net developers use Chef?
Anecdotally, I don’t know anyone in the windows / .NET world that is using chef, or have used it and stuck with it. Most people on that platform seem to gravitate to Chocolatey. That doesn’t mean there aren’t any using Chef primarily but it’s pretty rare it seems.
That being said, the experience on Windows is abysmal. The implementation with ruby on Windows is sloooooooow. You wait seconds just to get things like version.
Chef used to be used as an example of triumph from Ruby. Now I dont think it is far fetch to say Chef is declining. All while Ansible is doing fine.
Chef tried to adapt with Chef Workstation to do push-based config, but has inability to extract state from the system configured. The target system would have to update state to a server, which is fetched indirectly. This doesn't scale, so this is another reason why Ansible and Salt are popular.
Puppet also experiences some of the same issues with Ansible eating their lunch and popularity of push-based config for immutable infra. They attempted to respond with Bolt, but Bolt is based on static hostnames or DNS names, which won't scale given dynamic nature of cloud native and transient ephemeral systems.
In the case of managing fleets of systems that are not atomic stateless nodes, where you need to maintain a state across nodes within a set, both Puppet/Chef do not scale, and create outages (though window is small), because they have to synchronously push state to a server, and rely on eventual convergence. This doesn't scale in cloud computing. With push based config, you can set the cluster into the proper state, and then use service discovery (asynchronous updates) to maintain the state of the cluster. In K8S, kubectl/helm would fill the push role, and etcd used to maintain state. Outside of K8S, such as lambda in cloud, pulumi/terraform could push state, and discovery through cloud metadata (labels, tags, etc) or service discovery like consul to maintain the state.
Chef and Puppet could have responded, but couldn't see past their own platforms that are based on managing desired state for groups of individual atomic systems. They also failed to monetize on things like inventory management that enterprises fork over a lot for such things.
What's a good alternative to Chef?
The alternative is ansible. Everybody I know moved away from Chef to Ansible and never looked back. Historically there were 4 main configuration management tools: puppet/chef/ansible/salt. The first two faded away. They're unarguably not the most usable and require to program in ruby. The next generation ansible/salt came out and arguably did better on every aspect. I think it's fair to say that ansible is the safe s…
That has been my experience/perspective as well. This was what I found industry...
* ~2012 Puppet golden years * ~2014 Chef golden years * ~2016 Surge of popularity for Ansible and Salt. * ~2018+ Kubernetes ubiquity, Terraform for cloud, Ansible for systems
Related to this, saw popularity in SSR (server-side rendering) with Rails before 2012-2016, and after 2016 rise of popularity in SPA (Angular, React, Vue) on top of micro-frameworks like Flask (Python), Express (Node), GoLang, others. Combined with this are ML and other backend infra that requires managing clusters that scale better on Kubernetes, where Chef/Puppet have little presence on either K8S or backend distributed clusters.
Earlier quoted context omitted.
I'd like to recommend that you try pulumi. Terraform is definitely a fantastic tool, and it really does have just about everything you want (and is extremely google-able with easy to find experts), but I think the bring-your-own-language paradigm is better for this particular use case if a few things are true: - Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your co…
And also because terraform is also working on enabling other languages on top of it: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...
> Today, we are pleased to announce the community preview of the Cloud Development Kit for HashiCorp Terraform which allows users to define infrastructure using TypeScript and Python while leveraging the hundreds of providers and thousands of module definitions provided by Terraform and the Terraform ecosystem.
> CDK for Terraform is in alpha and is in the early stages of development. This project is another way to interface with Terraform using languages like TypeScript and Python. We are working to support additional languages such as JavaScript, Java, and C#. In addition to language support, we plan on expanding the scope of CDK for Terraform project to support other first-class commands to provide a user experience similar to the AWS CDK.
This has to be a shot across the bow at pulumi, glad Pulumi innovated and took this direction (maybe CDK was on the roadmap at Hashicorp, not sure) and seemingly spurred TF taking the turn as well.
Earlier quoted context omitted.
I was anti-HCL/Terraform for a long time due to issues with state files, but lately I honestly prefer it over Ansible whenever possible.. although I'm still not happy with the way cloud-init works on various cloud providers.
I'd like to recommend that you try pulumi. Terraform is definitely a fantastic tool, and it really does have just about everything you want (and is extremely google-able with easy to find experts), but I think the bring-your-own-language paradigm is better for this particular use case if a few things are true: - Your team is comfortable with at least one of the languages Pulumi has native support for, ideally your co…