![Infrastructure as Code/Software
Defined Environment
package "apache2" do
package_name node['apache']['package']
end
service "apache2" do
case node['platform_family']
when "rhel", "fedora", "suse"
service_name "httpd"
# If restarted/reloaded too quickly httpd has a habit of failing.
# This may happen with multiple recipes notifying apache to restart - like
# during the initial bootstrap.
restart_command "/sbin/service httpd restart && sleep 1"
reload_command "/sbin/service httpd reload && sleep 1"
Enter Chef!](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/85/Chef-for-DevOps-an-Introduction-15-320.jpg)
![Chef Recipe Example
bash "install_tomcat6" do
tomcat_version_name = "apache-tomcat-#{node[:tomcat6][:version]}"
tomcat_version_name_tgz = "#{tomcat_version_name}.tar.gz"
user "root"
cwd usr_share_dir
not_if do ::File.exists?(::File.join(usr_share_dir,tomcat_version_name))
end
code <<-EOH
wget http://archive.apache.org/dist/tomcat/tomcat-
6/v#{node[:tomcat6][:version]}/bin/#{tomcat_version_name_tgz}
tar -zxf #{tomcat_version_name_tgz}
rm #{tomcat_version_name_tgz}
chown -R #{node[:tomcat6][:user]}:#{node[:tomcat6][:user]}
#{tomcat_version_name}
EOH
end
Source: http://community.opscode.com/cookbooks/tomcat6/source](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/85/Chef-for-DevOps-an-Introduction-40-320.jpg)
![Chef attributes file Example
require 'openssl'
pw = String.new
while pw.length < 20
pw << OpenSSL::Random.random_bytes(1).gsub(/W/, '')
end
# Where the various parts of tomcat6 are
case platform
when "centos"
set[:tomcat6][:start] = "/etc/init.d/tomcat6 start"
set[:tomcat6][:stop] = "/etc/init.d/tomcat6 stop"
set[:tomcat6][:restart] = "/etc/init.d/tomcat6 restart"
set[:tomcat6][:home] = "/usr/share/tomcat6" #don't use trailing slash. it
breaks init script
set[:tomcat6][:dir] = "/etc/tomcat6/"
set[:tomcat6][:conf] = "/etc/tomcat6"
set[:tomcat6][:temp] = "/var/tmp/tomcat6"
set[:tomcat6][:logs] = "/var/log/tomcat6"
set[:tomcat6][:webapp_base_dir] = "/srv/tomcat6/"
set[:tomcat6][:webapps] = File.join(tomcat6[:webapp_base_dir],"webapps")
set[:tomcat6][:user] = "tomcat"
set[:tomcat6][:manager_dir] = File.join(tomcat6[:home],"webapps/manager")
set[:tomcat6][:port] = 8080
set[:tomcat6][:ssl_port] = 8433
Source: http://community.opscode.com/cookbooks/tomcat6/source](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/85/Chef-for-DevOps-an-Introduction-41-320.jpg)
![Infrastructure as Code/Software
Defined Environment
package "apache2" do
package_name node['apache']['package']
end
service "apache2" do
case node['platform_family']
when "rhel", "fedora", "suse"
service_name "httpd"
# If restarted/reloaded too quickly httpd has a habit of failing.
# This may happen with multiple recipes notifying apache to restart - like
# during the initial bootstrap.
restart_command "/sbin/service httpd restart && sleep 1"
reload_command "/sbin/service httpd reload && sleep 1"
Enter Chef!](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/75/Chef-for-DevOps-an-Introduction-15-2048.jpg)
![Chef Recipe Example
bash "install_tomcat6" do
tomcat_version_name = "apache-tomcat-#{node[:tomcat6][:version]}"
tomcat_version_name_tgz = "#{tomcat_version_name}.tar.gz"
user "root"
cwd usr_share_dir
not_if do ::File.exists?(::File.join(usr_share_dir,tomcat_version_name))
end
code <<-EOH
wget http://archive.apache.org/dist/tomcat/tomcat-
6/v#{node[:tomcat6][:version]}/bin/#{tomcat_version_name_tgz}
tar -zxf #{tomcat_version_name_tgz}
rm #{tomcat_version_name_tgz}
chown -R #{node[:tomcat6][:user]}:#{node[:tomcat6][:user]}
#{tomcat_version_name}
EOH
end
Source: http://community.opscode.com/cookbooks/tomcat6/source](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/75/Chef-for-DevOps-an-Introduction-40-2048.jpg)
![Chef attributes file Example
require 'openssl'
pw = String.new
while pw.length < 20
pw << OpenSSL::Random.random_bytes(1).gsub(/W/, '')
end
# Where the various parts of tomcat6 are
case platform
when "centos"
set[:tomcat6][:start] = "/etc/init.d/tomcat6 start"
set[:tomcat6][:stop] = "/etc/init.d/tomcat6 stop"
set[:tomcat6][:restart] = "/etc/init.d/tomcat6 restart"
set[:tomcat6][:home] = "/usr/share/tomcat6" #don't use trailing slash. it
breaks init script
set[:tomcat6][:dir] = "/etc/tomcat6/"
set[:tomcat6][:conf] = "/etc/tomcat6"
set[:tomcat6][:temp] = "/var/tmp/tomcat6"
set[:tomcat6][:logs] = "/var/log/tomcat6"
set[:tomcat6][:webapp_base_dir] = "/srv/tomcat6/"
set[:tomcat6][:webapps] = File.join(tomcat6[:webapp_base_dir],"webapps")
set[:tomcat6][:user] = "tomcat"
set[:tomcat6][:manager_dir] = File.join(tomcat6[:home],"webapps/manager")
set[:tomcat6][:port] = 8080
set[:tomcat6][:ssl_port] = 8433
Source: http://community.opscode.com/cookbooks/tomcat6/source](https://image.slidesharecdn.com/cheffordevops-anintroduction-130402100124-phpapp01/75/Chef-for-DevOps-an-Introduction-41-2048.jpg)
Uploaded bySanjeev Sharma
Chef for DevOps - an Introduction
The document provides an overview of DevOps principles and IBM's continuous delivery solutions, including the introduction of Chef as an automation platform for infrastructure management. It discusses the benefits of DevOps, such as increased deployment speed, improved collaboration between development and operations, and better quality assurance through automation. Additionally, it outlines the key concepts and architecture of Chef, highlighting its role in facilitating continuous integration and delivery in software development.
More Related Content
Similar to Chef for DevOps - an Introduction
Chef for DevOps - an Introduction
- 1. Chef for DevOps Concepts and Overview Sanjeev Sharma Executive IT Specialist IBM Rational Specialty Architect IBM Software Group
- 2. Me • 19 yearin the software industry • 17+ years he has been in Technical Sales with Rational and IBM o Mid-Atlantic BU in the East IMT • Areas of work: Sanjeev Sharma o DevOps sanjeev.sharma@us.ibm.com @sd_architect o Mobile Development o Application Lifecycle Management o Enterprise Architecture o Agile Transformation o Software Delivery Platforms o Software Supply Chains. • Blog @ bit.ly/sdarchitect • Twitter: @sd_architect
- 3. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
- 4. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
- 5. Businesses are challengedto meet time pressures with quality software 41% 51% 45% experience delays experience delays applications rolled in integration, configuration back due to quality due to troubleshooting and issues escaping and fine-tuning issues testing of applications* into production* in production* Business Line of Development IT Operations Owners Customers Business & Test GAP GAP Up to 4-6 Weeks to deliver a simple code change** * Forrester/IBM Study: A New View of IBM’s Opportunity for Integrated Optimized Systems Address , 2011 ** Forrester “Five Ways To Streamline Release Management”, 2011
- 6. Patterns of challenges Differences in dev Backlog of agile Manual (tribal) Lack of feedback and and ops releases that Ops processes for release quality metric leads to environments cause cannot handle lack missed service level failures repeatability/speed targets Dev Who did this last time? Daily Build Dave… Prod Dave’s not here Monthly Delivery man…
- 7. DevOps: The timeis now Four key drivers are making DevOps a 2013 imperative for all organizations. Business Agility Cloud Agile DevOps Computing Development Operational Discipline
- 8. Why DevOps? • Timeto value o Deploy faster. Deploy Often o Reduce cost/time to deliver • Developer ‘Self-service’ o Allow Developers to Build and Test against ‘Production-like’ systems • Increase Quality o Reduce cost/time to test o Increase test coverage • Increase environment utilization o Virtualize Dev and Test Environments
- 9. Why DevOps? • Deployment o Minimize deployment related downtime o Minimize roll-backs of deployed Apps • Defect Resolution o Increase the ability to reproduce and fix defects o Minimize ‘mean-time-to-resolution’ (MTTR) o Reduce defect cycle time • Collaboration o Reduce challenges related to Dev and Ops collaboration
- 10. A blueprint forcontinuous delivery of software-driven innovation dev·ops noun 'dev-äps Enterprise capability for continuous software delivery that enables clients to seize market opportunities and reduce time to customer feedback. DevOps Lifecycle Customer Business Development/T Operations/Prod s Owners est uction Continuous Feedback and Improvements Accelerated software delivery Improved governance across the lifecycle Reduced time to obtain and Balanced quality, cost and speed respond to customer feedback 10
- 11. DevOps Principles and Values • Develop and test against a production-like system People • Iterative and frequent deployments using repeatable Process and reliable processes Tools • Continuously monitor and validate operational quality characteristics • Amplify feedback loops
- 12. Key Concepts 1. ContinuousIntegration 2. Continuous Delivery 3. Continuous Test 4. Continuous Monitoring 5. Infrastructure as Code 6. Build and Delivery Pipeline
- 13. Continuous Delivery http://bit.ly/PRQ4a7
- 14. Build & DeliveryPipeline Continuously Deliver to the next Stage.
- 15. Infrastructure as Code/Software Defined Environment package "apache2" do package_name node['apache']['package'] end service "apache2" do case node['platform_family'] when "rhel", "fedora", "suse" service_name "httpd" # If restarted/reloaded too quickly httpd has a habit of failing. # This may happen with multiple recipes notifying apache to restart - like # during the initial bootstrap. restart_command "/sbin/service httpd restart && sleep 1" reload_command "/sbin/service httpd reload && sleep 1" Enter Chef!
- 16. Delivery Pipeline Build, Package, & Unit Test .jsp .html Application Binaries & Platform Deploy .java Configuration .sh chef recipes Environment Deployable Artifacts Running System Source Artifacts Source Control Library Management
- 17. Continuous Delivery flow Test Automation Cloud Platform Provider Developer Tools Execute Request tests cloud resources Provision Deliver resources changes Automation Agent Post results (execute delivery process) Source Control and Change Management server Publish packages Retrieve packages Trigger delivery Artifact Library Post changes Virtual System Publish Build Server packages 17
- 18. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
- 19. Standardize Plan & Track Manage Changes Automate Delivery Feedback IBM Workload Deployer IBM PureApplication Rational Team Concert Provisioning Systems Agile Deployment of Development Virtual Systems
- 20. DevOps capabilities Collaborative Development Continuous Testing Continuous Release Build Quality Automation Management Application Environment Release Provisioning Automation Change Source Control Test Service Management Management Automation Virtualization Continuous Monitoring Application Performance Monitoring Delivery Pipeline Continuous Delivery Open Lifecycles Integration Platform
- 21. DevOps tool chain Collaborative Development Continuous Testing Continuous Release IBM SmartCloud Build IBM Rational Quality IBM Rational Provisioning Automation Jenkins Management Build Forge Quality Manager Chef IBM Application Workload IBM Rational EnvironmentDeployer Release Automation Provisioning Automation Framework IBM Pure IBMSource Control Rational Systems Change IBM Rational Test Service Management Team Management Concert Test Workbench Automation Virtualization Continuous Monitoring IBM SmartCloud Application Application Performance Monitoring Performance Management IBM SmartCloud Delivery Pipeline Continuous Delivery Continuous Delivery Open Lifecycles Integration Platform
- 22. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
- 23. What is Chef? Chef is an automation platform from Opscode for developers & systems engineers to continuously define, build, and manage infrastructure. CHEF USES: Recipes and Cookbooks that describe Infrastructure as Code. Chef enables people to easily build & manage complex & dynamic applications at massive scale • New model for describing infrastructure that promotes reuse • Programmatically provision and configure • Reconstruct business from code repository, data backup, and bare metal resources Source: http://bit.ly/15Qclab
- 24. The value ofChef
- 25. The value ofChef
- 26. The value ofChef
- 27. The value ofChef
- 28. Chef Concepts –the System • chef-client Runs on Systems • Configured or Managed systems are called Nodes • chef-client talks to Chef Server • Ohai a client to detect certain Node environment properties and provide them to the chef-client • Repositories are where Chef data objects are stored • Knife is the command-line user’s tool for Chef • A workstation is where authoring and data definition is done by users Source: http://bit.ly/ZxK7An
- 29. Chef Concepts –the diagram
- 30. Resources, Actions and Providers • A Resource defines that Action that needs to be taken (like install a package, restart a service, etc.) • A Provider does the work (steps) to carry out the actions the Resource describes. • Providers are platform specific, Resources are not • Actions are decoupled from the steps required to take a system from current state to desired state Source: http://bit.ly/ZxK7An
- 31. Chef Concepts –Recipes and Cookbooks • Cookbooks are collections of Recipes and associated Attributes, defining a scenario • Cookbooks are the fundamental unit of configuration and policy distribution in Chef • Recipes are collections of Resources, written in Ruby • Attributes provide specific details of a Node (like IP address, list of loaded kernel modules, etc.) Source: http://bit.ly/ZxK7An
- 32. Chef Concepts –the diagram
- 33. Chef Concepts –more stuff • A Role is used to define patterns and processes that exist across Nodes • A Run-list is an ordered list of Recipes or Roles that are run in exact order • A Data bag is a global variable and includes sensitive information like passwords (encrypted) Source: http://bit.ly/ZxK7An
- 34. Chef Concepts –the diagram
- 35. Chef Concepts –in summary • Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location. • Each Chef organization is comprised of one (or more) workstations, a single server, and every node that will be configured and maintained by Chef. • Cookbooks (and recipes) are used to tell Chef how each node in your organization should be configured. The chef-client (which is installed on every node) does the actual configuration. Source: http://docs.opscode.com
- 36. Chef Concepts –the diagram
- 37. Chef Concepts –the UML view
- 38. How Chef works?– yet another summary • Chef relies on abstract definitions (known as cookbooks and recipes) that are written in Ruby and are managed like source code. • Each definition describes how a specific part of your infrastructure should be built and managed. • Chef applies those definitions to servers and applications, as specified, resulting in a fully automated infrastructure. • When a new server comes online, the only thing that Chef needs to know is which cookbooks and recipes to apply. Source: http://docs.opscode.com
- 39. A Chef run– how Chef configures a Node?
- 40. Chef Recipe Example bash"install_tomcat6" do tomcat_version_name = "apache-tomcat-#{node[:tomcat6][:version]}" tomcat_version_name_tgz = "#{tomcat_version_name}.tar.gz" user "root" cwd usr_share_dir not_if do ::File.exists?(::File.join(usr_share_dir,tomcat_version_name)) end code <<-EOH wget http://archive.apache.org/dist/tomcat/tomcat- 6/v#{node[:tomcat6][:version]}/bin/#{tomcat_version_name_tgz} tar -zxf #{tomcat_version_name_tgz} rm #{tomcat_version_name_tgz} chown -R #{node[:tomcat6][:user]}:#{node[:tomcat6][:user]} #{tomcat_version_name} EOH end Source: http://community.opscode.com/cookbooks/tomcat6/source
- 41. Chef attributes fileExample require 'openssl' pw = String.new while pw.length < 20 pw << OpenSSL::Random.random_bytes(1).gsub(/W/, '') end # Where the various parts of tomcat6 are case platform when "centos" set[:tomcat6][:start] = "/etc/init.d/tomcat6 start" set[:tomcat6][:stop] = "/etc/init.d/tomcat6 stop" set[:tomcat6][:restart] = "/etc/init.d/tomcat6 restart" set[:tomcat6][:home] = "/usr/share/tomcat6" #don't use trailing slash. it breaks init script set[:tomcat6][:dir] = "/etc/tomcat6/" set[:tomcat6][:conf] = "/etc/tomcat6" set[:tomcat6][:temp] = "/var/tmp/tomcat6" set[:tomcat6][:logs] = "/var/log/tomcat6" set[:tomcat6][:webapp_base_dir] = "/srv/tomcat6/" set[:tomcat6][:webapps] = File.join(tomcat6[:webapp_base_dir],"webapps") set[:tomcat6][:user] = "tomcat" set[:tomcat6][:manager_dir] = File.join(tomcat6[:home],"webapps/manager") set[:tomcat6][:port] = 8080 set[:tomcat6][:ssl_port] = 8433 Source: http://community.opscode.com/cookbooks/tomcat6/source
- 42. Puppet – theother player • Puppet is another Infrastructure as Code system • Puppet has its own Ruby DSL, while Chef runs Ruby natively • Puppet is considered for sys-admin friendly, where as Chef is more developer friendly • IBM has chosen to align with Chef for its cloud offerings (SmartCloud Orchestrator, SmartCloud Continuous Delivery)
- 43. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
- 44. Chef addresses Patternsof challenges Differences in dev Backlog of agile Manual (tribal) Lack of feedback and and ops releases that Ops processes for release quality metric leads to environments cause cannot handle lack missed service level failures repeatability/speed targets Dev Who did this last time? Daily Build Dave… Prod Dave’s not here Monthly Delivery man…
- 45. DevOps Principles and Values • Develop and test against a production-like system People • Iterative and frequent deployments using repeatable and reliable Process processes Tools • Continuously monitor and validate operational quality characteristics • Amplify feedback loops
- 46. Delivery Pipeline –Chef is Infrastructure as Code Build, Package , & Unit Test .jsp .html Application Binaries & Platform Deploy .java Configuration .sh chef recipes Environment Deployable Artifacts Running System Source Artifacts Source Control Library Management
- 47. Chef and theDelivery Pipeline • (Re)Build each environment using Chef, on demand • Ensure each environment is ‘production-like’ in nature • Re-create any environment from the past (for defect resolution)
- 48. Chef and theDelivery Pipeline • In some organizations, only Dev and QA may be ready to be virtualized for Continuous Delivery • Delivery to Prod would then happen manually, from Asset Repository
- 49. Chef and theContinuous Delivery flow Test Automation Cloud Platform Provider Developer Tools Execute Request tests cloud resources Provision Deliver resources changes Automation Agent Post results (execute delivery process) Source Control and Change Management server Publish packages Retrieve packages Trigger delivery Artifact Library Post changes Virtual System Publish Build Server packages 49
- 50. Wait, there’s more: IBM’s Weaver Weaver is a Domain-Specific Language (DSL) based on the Ruby platform allowing to express the blueprint of an "environment", how to assemble and deploy it. • Weaver is not a competitor to Chef or Puppet. • There is a gap in how an "environment" and all its component are specified and interlinked. • A unified view of an environment is important, i.e., what application is deployed on what system(s), what are its configuration values etc with the need to understand and study numerous Chef recipes or Puppet modules that comprise the system configuration. • Weaver allows you to specify that unified view and drive the deployment from it. Source: https://jazz.net/wiki/bin/view/Main/SCCDWeaverLanguage
- 51. Where to getmore information? • Chef Documentation o http://docs.opscode.com/chef/ • IBM SmartCloud Continuous Delivery project o https://jazz.net/products/smartcloud-continuous-delivery/ • IBM Enterprise DevOps blog o http://ibm.co/JrPVGR • Understanding DevOps (Series on my Blog) o http://bit.ly/MyDevOps
- 52.
- 53. www.ibm.com/software/rational © Copyright IBMCorporation 2012. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
- 54. Please note (Mandatory legalese) IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here.