Habitat-managed Chef with Policyfiles: Learn how to leverage the power of Habitat, chef-client and Policyfiles to produce an immutable application containing all of your chef cookbooks that can be locally tested and provides a consistent and guaranteed picture of desired configuration state across all target environments.
2. Habitat managed Chef is a new method of building, delivering, and running
Chef cookbooks on your infrastructure.
It uses Habitat to package and deliver your Chef cookbooks, chef-client,
attributes, and run-list together, as one atomic package.
Habitat Managed Chef
4. ● Simple cookbooks remediate audit and security issues
● Great for automating server correctness across your
estate, even on ephemeral servers
● Regular Chef, nothing special required
Harden servers using Chef
5. ● Replaces workflows such as the Berkshelf way, role
cookbooks, or environment cookbook pattern with a
simpler, more reliable cookbook development pattern
● Provides a simple way to move cookbooks and chef-
client versions together in lockstep
● Still uses familiar Chef development tools
Improve Cookbook development workflow
6. ● Remove the need for a Chef Server
● Eliminate complex cookbook deployment and
versioning practices
● Great for increasing infrastructure agility or preparing
for application modernization efforts
Simplify Chef
7. ● Modernize applications instead of rewriting them, use
existing, Chef code to help bridge the gap
● Incrementally move services to Habitat, preparing the
way to use Docker, Kubernetes, Mesos, or other
runtime formats
● Great for increasing application reliability and lift-and-
shift plays
Modernize your applications
9. Use your existing Chef cookbooks
for your infrastructure.
Write a Habitat Plan and a Policyfile
Use a Habitat Plan and a policyfile
to create an artifact that contains
all of your cookbook code, chef-
client version of your choice,
attribute overrides, and run-list.
Use Habitat Studio to test your
Plan, and build and iterate quickly.
10. Write a Habitat Plan and a Policyfile
Plan.sh
pkg_name=hardening
pkg_origin=jonlives
pkg_version="0.1.0"
pkg_scaffolding="core/scaffolding-chef"
scaffold_policy_name="hardening"
pkg_svc_user=("root")
11. Write a Habitat Plan and a Policyfile
hardening.rb
name 'hardening'
default_source :chef_repo, '../'
default['auth'] = { 'is_active_directory' => true }
...
cookbook 'line'
cookbook 'os-hardening'
...
run_list [
'hardening::default', 'mycompany-standards::default', 'mycompany-production::default'
]
12. Use Habitat Builder or the On-Prem Habitat
Builder Depot to automate your cookbook
builds and have complete control over your
chef-client version that ships to your
infrastructure, and vendored cookbooks.
Build your Cookbooks
Rest easy knowing that by bundling the
chef-client with your vendored cookbooks,
you're eliminating entire classes of runtime
errors.
Get automatic rebuilds when a new version
of chef-client or any other runtime
dependencies is available.
16. Now you have a .hart file that contains:
● Your desired chef-client version
● All of your vendored cookbooks
● A policyfile, containing your run-list and attribute
overrides
Build your Cookbooks
17. Install the Habitat Supervisor through your
provisioning tool. Use the Habitat Supervisor
to install the cookbook + chef-client Habitat
package.
Deploy your Cookbooks
Define an update strategy to automatically
update your server's cookbook + chef-client
Habitat package by subscribing to Builder
channels.
20. The Habitat Supervisor executes the chef-
client in solo mode. No Chef Server is
required, because all of the cookbooks
already are on your server.
Run your Cookbooks
Use traditional Chef .erb templates, or you
can move configuration templates to
Habitat, to take advantage of information in
the gossip ring.
Your Chef Solo run can still report into Chef
Automate using a data collector token to log
runs.
21. Run your Cookbooks
● Chef-client runs in Chef Solo mode, providing isolation and server stability
● Report handlers still function through a data collector token, which still
allows you to collect Ohai and Node Run data.
● Cookbooks are vendored into the Habitat package and delivered with the
chef-client as one, atomic package, ensuring you'll always have the right
versions.
● Removes the need to resolve and download cookbooks at runtime,
reducing chef run times and eliminating run time depsolver issues.
22. Automatically update chef-client through
Habitat Builder - allowing you to continually
keep your infrastructure up to date.
Manage Chef
See exactly which cookbook versions you
are running in each environment. Have
complete dependency and transitive
dependency control and visibility.
Maintain working cookbook versions paired
with working chef-client versions - so you'll
never get in a bad state again for any server.
23. "It is tempting, if the only tool you have is a hammer,
to treat everything as if it were a nail"
-- Abraham Maslow, law of the instrument
Simplify Chef
24. What is modern Chef, without restrictions?
● Configuration Management
● Service Discovery
● Provisioning
● Scheduling
● Clustering
● Dependency verification
● Secrets Management
Simplify Chef
25. Habitat-managed Chef gives Chef a clear responsibility.
● Configuration Management
● Service Discovery Habitat
● Provisioning Your provisioning tool (ie: Terraform)
● Scheduling Your scheduling tool (ie: Kubernetes, Nomad)
● Clustering Habitat
● Dependency verification Habitat
● Secrets Management Encryption at rest service (ie: Vault)
Simplify Chef
26. What problems does maintaining a Chef Server give us?
● Taking outages for long periods of fleet-wide infrastructure upgrades
● Backups for a Chef Server, including planning for HA or DR scenarios
● Complicated, runtime attribute precedence override problems
● Out-of-sync cookbooks and versioning issues
● Depsolver performance at runtime and network failures
● Run-list management
● Managing data bags, roles, and other mutable run-time json blob storage
● Difficult cookbook code + chef-client version upgrade scenarios
Simplify Chef
27. Habitat-managed Chef uses Chef Solo mode, and eliminates the need for a
Chef Server. Seriously, you don't need one.
Simplify Chef
28. If you're not prepared to switch to Habitat-managed Chef today, you can use
some of these techniques to make your Chef runs more robust by treating
your Chef Server as stateless.
Simplify Chef
29. Remove references to any Chef Server data accesses in your cookbooks:
● Attribute overrides - Replace with policyfile.rb attribute overrides
● Data bags / encrypted data bags / Chef Vault - Replace with Hashicorp
Vault for encrypted data at rest, or policyfile.rb for non-encrypted data
● Chef Search / node state orchestration techniques - replace with
Habitat templates and gossip ring data
● External scripts that manipulate run lists - replace with a proper
provisioning toolset
Simplify Chef
30. ● In our experience, the most complex and error-prone cookbooks attempt
to deploy and orchestrate applications. There is a better way.
● A Habitat plan allows you to package your application and all of its runtime
dependencies together.
● Habitat-managed Chef gives us a bridge to modernize legacy applications.
We can continue running applications using Chef, and then modernize
parts of those applications by creating a Habitat plan. In effect, we can
imbue legacy applications with more agility quickly, without throwing away
years of work or rewriting the application.
Modernize your applications
33. Verify servers using InSpec
● Run server verification locally with InSpec
● InSpec doesn't need Chef or other tools; it runs entirely
independently
● Great for clean room environment server and
deployment verification
Automation that travels with the application. So, what you build, manage, and deploy will behave in any runtime. The application is the unit of automation.
Habitat is a full-featured runtime with deployment coordination and service discovery capabilities built in. Any application – legacy + greenfield – can be contained within a Habitat package.
The unit of deployment is the application and its automation
Everything an application needs, for life, is in the package
Straightforward way to describe how an application behaves
Outward-facing API presents standard interface
As an autonomous actor, application makes progress toward its desired state
Exposes standard interfaces for interacting with others
An atomic, immutable build artifact
Automation travels with the application artifact
That allows the application to run directly on bare metal Operating Systems, in Virtualization, in Containers, or on PaaS without change
Gain same deployment and management characteristics of modern applications even with legacy applications. Same workflow, same interface
Most ppl hate legacy software not because it doesn’t work but because managing it is unpleasant, hard, and filled with traps that lead to outages.
Original source in Google Drive: https://docs.google.com/presentation/d/1i8AN16p-mx7sGogAWMmlHqqM7oKtD458s40QrSF5Rfc/edit?usp=sharing
Automation that travels with the application. So, what you build, manage, and deploy will behave in any runtime. The application is the unit of automation.
Habitat is a full-featured runtime with deployment coordination and service discovery capabilities built in. Any application – legacy + greenfield – can be contained within a Habitat package.
The unit of deployment is the application and its automation
Everything an application needs, for life, is in the package
Straightforward way to describe how an application behaves
Outward-facing API presents standard interface
As an autonomous actor, application makes progress toward its desired state
Exposes standard interfaces for interacting with others
An atomic, immutable build artifact
Automation travels with the application artifact
That allows the application to run directly on bare metal Operating Systems, in Virtualization, in Containers, or on PaaS without change
Gain same deployment and management characteristics of modern applications even with legacy applications. Same workflow, same interface
Most ppl hate legacy software not because it doesn’t work but because managing it is unpleasant, hard, and filled with traps that lead to outages.
Original source in Google Drive: https://docs.google.com/presentation/d/1i8AN16p-mx7sGogAWMmlHqqM7oKtD458s40QrSF5Rfc/edit?usp=sharing
Automation that travels with the application. So, what you build, manage, and deploy will behave in any runtime. The application is the unit of automation.
Habitat is a full-featured runtime with deployment coordination and service discovery capabilities built in. Any application – legacy + greenfield – can be contained within a Habitat package.
The unit of deployment is the application and its automation
Everything an application needs, for life, is in the package
Straightforward way to describe how an application behaves
Outward-facing API presents standard interface
As an autonomous actor, application makes progress toward its desired state
Exposes standard interfaces for interacting with others
An atomic, immutable build artifact
Automation travels with the application artifact
That allows the application to run directly on bare metal Operating Systems, in Virtualization, in Containers, or on PaaS without change
Gain same deployment and management characteristics of modern applications even with legacy applications. Same workflow, same interface
Most ppl hate legacy software not because it doesn’t work but because managing it is unpleasant, hard, and filled with traps that lead to outages.
Original source in Google Drive: https://docs.google.com/presentation/d/1i8AN16p-mx7sGogAWMmlHqqM7oKtD458s40QrSF5Rfc/edit?usp=sharing
Automation that travels with the application. So, what you build, manage, and deploy will behave in any runtime. The application is the unit of automation.
Habitat is a full-featured runtime with deployment coordination and service discovery capabilities built in. Any application – legacy + greenfield – can be contained within a Habitat package.
The unit of deployment is the application and its automation
Everything an application needs, for life, is in the package
Straightforward way to describe how an application behaves
Outward-facing API presents standard interface
As an autonomous actor, application makes progress toward its desired state
Exposes standard interfaces for interacting with others
An atomic, immutable build artifact
Automation travels with the application artifact
That allows the application to run directly on bare metal Operating Systems, in Virtualization, in Containers, or on PaaS without change
Gain same deployment and management characteristics of modern applications even with legacy applications. Same workflow, same interface
Most ppl hate legacy software not because it doesn’t work but because managing it is unpleasant, hard, and filled with traps that lead to outages.
Original source in Google Drive: https://docs.google.com/presentation/d/1i8AN16p-mx7sGogAWMmlHqqM7oKtD458s40QrSF5Rfc/edit?usp=sharing
Chef is a powerful configuration management system -- sometimes too powerful. Over the years configuration management tools were seen as a panacea for many different classes of problems facing infrastructure teams. Chef has experienced this as well, with many capabilities and frameworks bolted-on over the years that half-solved problems such as service discovery, provisioning, scheduling, bootstrapping, clustering, HA, dependency toolchain verification, and the list goes on and on. Some of these bolt-on pieces of functionality were more successful than others.
Automation that travels with the application. So, what you build, manage, and deploy will behave in any runtime. The application is the unit of automation.
Habitat is a full-featured runtime with deployment coordination and service discovery capabilities built in. Any application – legacy + greenfield – can be contained within a Habitat package.
The unit of deployment is the application and its automation
Everything an application needs, for life, is in the package
Straightforward way to describe how an application behaves
Outward-facing API presents standard interface
As an autonomous actor, application makes progress toward its desired state
Exposes standard interfaces for interacting with others
An atomic, immutable build artifact
Automation travels with the application artifact
That allows the application to run directly on bare metal Operating Systems, in Virtualization, in Containers, or on PaaS without change
Gain same deployment and management characteristics of modern applications even with legacy applications. Same workflow, same interface
Most ppl hate legacy software not because it doesn’t work but because managing it is unpleasant, hard, and filled with traps that lead to outages.
Original source in Google Drive: https://docs.google.com/presentation/d/1i8AN16p-mx7sGogAWMmlHqqM7oKtD458s40QrSF5Rfc/edit?usp=sharing