0
Chef for Openstack
Mohit Sethi
mohit@sethis.in
Whoami?
Mohit Sethi
Developer, Technical Lead
Senior Engineer at HP R&D
You?
• Developers?
• System Administrators?
• Arch...
Journey so far?
• 2010-11:
• CFEngine,
• Puppet
• Chef
• 2011 - Present
• Contributed to Chef core,
• Contributed to Knife...
Goal for today
• Configuration Management Framework – Opscode Chef,
• Principles,
• Automation Constructs
What is Chef?
Chef is a systems integration framework, built to bring the
benefits of configuration management to you enti...
Wait, What?
What is Chef?
Chef is a tool that allows you to define the state your
servers(local or cloud) should be in and then enforc...
Why should I use Chef?
You have Servers.
You need to configure them.
Why should I use Chef?
But I’ve my AWESOME bash scripts, which already does most of
‘those’ things,
Why else?
We are developers, we write multi-tier applications
Why else?
We like to make things interesting,
Why else?
Application grows,
Why else?
Why else?
Meanwhile 6 months later,
• How did I do that?
• Who changed that?
• Why did I do it what way?
• Then It dies,
•...
Why else?
And you will be…
Why Chef?
Provides:
Architecture(1000’ view)
Chef Client runs on your servers
Client talks to a Chef Server
Clients authenticate with RSA keys
Knife is used to talk to Chef-Server &
initiate convergence of a server.
Principles
• Idempotent
• Provision Often
• Infrastructure As Code
• Data-Driven
• Thick Clients, Thin Server
#1 Idempotent
#1 Chef rule: Recipes/ Infrastructure code should be
Idempotent.
The number of Chef runs should not affect t...
#2 Provision Often
If your recipes are not idempotent refer rule #1.
If they are, you should consider provisioning your se...
#3 Infrastructure As Code
Infrastructure should be represented as code,
Server configuration, packages installed, relation...
#4 Data-Driven
• Separate of policy & data (implemented using Attributes &
DataBags)
• Infrastructure code should not have...
#5 Thick Clients, Thin Servers
As much as possible much work is done by Chef-Client(Nodes)
Pull not Push. Chef-client runs...
Okay! let’s write some
infrastructure code…
Vocabulary
• Nodes == Servers
• Attributes ≈ Variables
• Roles can define a Node’s attributes and what Recipes are applied...
Do I need to know Ruby?
A little
It’s a simple syntax
Chef-solo
Chef can also run stand-alone
Nodes == Servers
Nodes have Attributes
Attributes == Variables
Attributes are Searchable
$ knife search node ‘platform:cen...
Attributes
Attributes == Variables
Attributes are Searchable
$ knife search node ‘platform:centos’
search(:node, ‘platform...
Nodes have RunList
A RunList defines:
What Roles or Recipes to apply in Order.
$ knife node show ks.ms.openstack.com –r
{
...
Nodes have Roles
Role: What describes a node
• webserver
• dbserver
• glance-server
• keystone-server
• …etc
Roles have Ru...
Roles
• Roles have Run-List
Roles
• Can have other roles!
Roles
• Can override default attributes
Roles
• Roles are Searchable
• To find all roles where attribute: max_children takes value
50.
$ knife search role ‘max_ch...
Chef manages Resources on Nodes
• Resource: Declare a description of the state a part of node should be
in.
• Have a type
...
Providers
• Resource take action through providers.
• Know how to actually perform the actions specified by a resource,
• ...
Resources
Platform
Provider
Recipes
• Recipes are list of Resources
• Apply resources in the order they are specified
• Recipes are `import` other rec...
Recipes are just Ruby!
Cookbooks
• Cookbooks are packages for recipes,
• Distributable
• Versioned controlled.
• Can have dependency over other C...
Cookbook Structure
• Attributes
• Assets(Files/Templates)
• Providers
• Resources
• Recipes
• Metadata
Cookbook Metadata
• Declares:
• Platform support
• Dependencies
• Recipes
DataBags
• A data bag is a global variable that is stored as JSON data and is
accessible from a server.
• Create a data ba...
Community Cookbooks
• 1000+ cookbooks for everything
- databases, applications, CMS,
package management, Hadoop,
Cloud dep...
Platform Support
• Debian
• Ubuntu
• RHEL
• Centos
• OS X
• Windows
• FreeBSD
• SUSE Enterprise
• Solaris
• SUSE
• IBM AIX
Chef Flavors
• Opscode Hosted-Chef
• http://manage.opscode.com
• Hosted SaaS version of Chef.
• Opscode Enterprise/Private...
Cloud support
• Cloud support by Knife
• EC2, Rackspace, HP, Google, Azure, CloudStack, OpenStack, vSphere, vCloud, Joyent...
Questions??
self.intro do |mohit|
mohit.twitter = @mohitsethi, @openstackindia
mohit.email = mohit@sethis.in
end
Upcoming SlideShare
Loading in...5
×

Chef for openstack

919

Published on

Published in: Technology, Self Improvement
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
919
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Chef for openstack"

  1. 1. Chef for Openstack Mohit Sethi mohit@sethis.in
  2. 2. Whoami? Mohit Sethi Developer, Technical Lead Senior Engineer at HP R&D You? • Developers? • System Administrators? • Architects?
  3. 3. Journey so far? • 2010-11: • CFEngine, • Puppet • Chef • 2011 - Present • Contributed to Chef core, • Contributed to Knife cloud plugins such as ec2, azure, hp, openstack, rackspace, google, cloudstack, vsphere, vcloud • Written extensions for automation tools such as Vagrant, vagrant- hp, vagrant-vsphere
  4. 4. Goal for today • Configuration Management Framework – Opscode Chef, • Principles, • Automation Constructs
  5. 5. What is Chef? Chef is a systems integration framework, built to bring the benefits of configuration management to you entire infrastructure.
  6. 6. Wait, What?
  7. 7. What is Chef? Chef is a tool that allows you to define the state your servers(local or cloud) should be in and then enforces that state on your servers. An API for your entire Infrastructure. A service that exposes data about the state of your infrastructure
  8. 8. Why should I use Chef? You have Servers. You need to configure them.
  9. 9. Why should I use Chef? But I’ve my AWESOME bash scripts, which already does most of ‘those’ things,
  10. 10. Why else? We are developers, we write multi-tier applications
  11. 11. Why else? We like to make things interesting,
  12. 12. Why else? Application grows,
  13. 13. Why else?
  14. 14. Why else? Meanwhile 6 months later, • How did I do that? • Who changed that? • Why did I do it what way? • Then It dies, • I have to rebuild it • Did I forget anything • How did I do it • And you will be >>
  15. 15. Why else? And you will be…
  16. 16. Why Chef? Provides:
  17. 17. Architecture(1000’ view)
  18. 18. Chef Client runs on your servers
  19. 19. Client talks to a Chef Server
  20. 20. Clients authenticate with RSA keys
  21. 21. Knife is used to talk to Chef-Server & initiate convergence of a server.
  22. 22. Principles • Idempotent • Provision Often • Infrastructure As Code • Data-Driven • Thick Clients, Thin Server
  23. 23. #1 Idempotent #1 Chef rule: Recipes/ Infrastructure code should be Idempotent. The number of Chef runs should not affect the state of the server. The server should converge on the first run. And unless previously defined state changes, additional runs should not change anything. Say “what to do” not “how”
  24. 24. #2 Provision Often If your recipes are not idempotent refer rule #1. If they are, you should consider provisioning your servers often. Possibly every 5 minutes. Seriously.
  25. 25. #3 Infrastructure As Code Infrastructure should be represented as code, Server configuration, packages installed, relationships with other servers, should be modeled with code to be automated.
  26. 26. #4 Data-Driven • Separate of policy & data (implemented using Attributes & DataBags) • Infrastructure code should not have sensitive data. Though it can have sane defaults. • Sensitive data should be remain in a secured store, and should only be shared with authorized clients.
  27. 27. #5 Thick Clients, Thin Servers As much as possible much work is done by Chef-Client(Nodes) Pull not Push. Chef-client runs on each node & will interact with server when it needs to. Server is designed to distribute data to each node, including cookbooks, recipes, templates, files and so on. Server also retains a copy of state of node at the conclusion of every chef-client.
  28. 28. Okay! let’s write some infrastructure code…
  29. 29. Vocabulary • Nodes == Servers • Attributes ≈ Variables • Roles can define a Node’s attributes and what Recipes are applied to that Node • Clients == Anything that uses the API • Resources are the basic building blocks to define state • Related Resources are grouped into Recipes • Related Recipes are grouped into Cookbooks
  30. 30. Do I need to know Ruby? A little It’s a simple syntax
  31. 31. Chef-solo Chef can also run stand-alone
  32. 32. Nodes == Servers Nodes have Attributes Attributes == Variables Attributes are Searchable $ knife search node ‘platform:centos’ search(:node, ‘platform:centos’)
  33. 33. Attributes Attributes == Variables Attributes are Searchable $ knife search node ‘platform:centos’ search(:node, ‘platform:centos’)
  34. 34. Nodes have RunList A RunList defines: What Roles or Recipes to apply in Order. $ knife node show ks.ms.openstack.com –r { “run_list”: [ “role[os-base]”, “role[os-identity]”, ] }
  35. 35. Nodes have Roles Role: What describes a node • webserver • dbserver • glance-server • keystone-server • …etc Roles have RunList
  36. 36. Roles • Roles have Run-List
  37. 37. Roles • Can have other roles!
  38. 38. Roles • Can override default attributes
  39. 39. Roles • Roles are Searchable • To find all roles where attribute: max_children takes value 50. $ knife search role ‘max_children:50’ search(:role, ‘max_children:50’)
  40. 40. Chef manages Resources on Nodes • Resource: Declare a description of the state a part of node should be in. • Have a type • Have a name • Have parameters • Take action to put the resource in the declared state • Can send notification to other resources.
  41. 41. Providers • Resource take action through providers. • Know how to actually perform the actions specified by a resource, • Multiple providers per resources type • Eg. Resource “package” have providers apt, yum, rubygems, portage, macports, FreeBSD ports, etc
  42. 42. Resources Platform Provider
  43. 43. Recipes • Recipes are list of Resources • Apply resources in the order they are specified • Recipes are `import` other recipes,
  44. 44. Recipes are just Ruby!
  45. 45. Cookbooks • Cookbooks are packages for recipes, • Distributable • Versioned controlled. • Can have dependency over other Cookbooks
  46. 46. Cookbook Structure • Attributes • Assets(Files/Templates) • Providers • Resources • Recipes • Metadata
  47. 47. Cookbook Metadata • Declares: • Platform support • Dependencies • Recipes
  48. 48. DataBags • A data bag is a global variable that is stored as JSON data and is accessible from a server. • Create a data bag using knife $ knife data bag create DATA_BAG_NAME (DATA_BAG_ITEM) users = Chef::DataBag.new • Can be encrypted • Data values can be fetched from Recipes
  49. 49. Community Cookbooks • 1000+ cookbooks for everything - databases, applications, CMS, package management, Hadoop, Cloud deployments • http://community.opscode.com • https://launchpad.net/openstack-chef
  50. 50. Platform Support • Debian • Ubuntu • RHEL • Centos • OS X • Windows • FreeBSD • SUSE Enterprise • Solaris • SUSE • IBM AIX
  51. 51. Chef Flavors • Opscode Hosted-Chef • http://manage.opscode.com • Hosted SaaS version of Chef. • Opscode Enterprise/Private Chef • Private deployments of Opscode Chef Server • On-Premise deployments • Open Source Chef • Installation
  52. 52. Cloud support • Cloud support by Knife • EC2, Rackspace, HP, Google, Azure, CloudStack, OpenStack, vSphere, vCloud, Joyent, etc • Extensible • Implement own Resources & Providers,
  53. 53. Questions?? self.intro do |mohit| mohit.twitter = @mohitsethi, @openstackindia mohit.email = mohit@sethis.in end
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×