• Save
Chef for DevOps - an Introduction
Upcoming SlideShare
Loading in...5
×
 

Chef for DevOps - an Introduction

on

  • 4,506 views

This slide deck Introduces Chef and its role in DevOps. The agenda of the deck is as follows: ...

This slide deck Introduces Chef and its role in DevOps. The agenda of the deck is as follows:
- A Review of DevOps
- BMs Continuous Delivery solution
- Introduction to Chef
- Chef and Continuous Delivery
Read more on DevOps: http://sdarchitect.wordpress.com/understanding-devops/

Statistics

Views

Total Views
4,506
Views on SlideShare
3,708
Embed Views
798

Actions

Likes
7
Downloads
1
Comments
0

3 Embeds 798

http://sdarchitect.wordpress.com 746
https://twitter.com 28
https://sdarchitect.wordpress.com 24

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Chef for DevOps - an Introduction Presentation Transcript

  • 1. Chef for DevOps Concepts and Overview Sanjeev Sharma Executive IT Specialist IBM Rational Specialty Architect IBM Software Group
  • 2. Me• 19 year in 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 challenged to meettime 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 OperationsOwners 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 toenvironments 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 time is nowFour key drivers are making DevOps a 2013 imperative for all organizations. Business Agility Cloud Agile DevOps Computing Development Operational Discipline
  • 8. Why DevOps?• Time to 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 for continuous delivery of software-driven innovationdev·ops noun dev-äpsEnterprise capability for continuous software delivery that enables clientsto 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 Concepts1. Continuous Integration2. Continuous Delivery3. Continuous Test4. Continuous Monitoring5. Infrastructure as Code6. Build and Delivery Pipeline
  • 13. Continuous Delivery http://bit.ly/PRQ4a7
  • 14. Build & Delivery Pipeline 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 ArtifactsSource Control LibraryManagement
  • 17. Continuous Delivery flow Test Automation Cloud Platform Provider Developer Tools Execute Request tests cloud resources ProvisionDeliver resourceschanges 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 PureApplicationRational 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 ServiceManagement 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 ServiceManagement 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 asCode.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 of Chef
  • 25. The value of Chef
  • 26. The value of Chef
  • 27. The value of Chef
  • 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 Examplebash "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} EOHend Source: http://community.opscode.com/cookbooks/tomcat6/source
  • 41. Chef attributes file Examplerequire opensslpw = String.newwhile pw.length < 20 pw << OpenSSL::Random.random_bytes(1).gsub(/W/, )end# Where the various parts of tomcat6 arecase platformwhen "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" #dont use trailing slash. itbreaks 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 – the other 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 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 toenvironments 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 ArtifactsSource Control LibraryManagement
  • 47. Chef and the Delivery 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 the Delivery 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 the Continuous Delivery flow Test Automation Cloud Platform Provider Developer Tools Execute Request tests cloud resources ProvisionDeliver resourceschanges 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 get more 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. www.ibm.com/software/rational
  • 53. www.ibm.com/software/rational© Copyright IBM Corporation 2012. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of anykind, 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 shallhave 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 IBMsoftware. 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 capabilitiesreferenced 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 featureavailability 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 MachinesCorporation, 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 changeor withdrawal without notice at IBM’s sole discretion.Information regarding potential future products is intended to outline ourgeneral product direction and it should not be relied on in making a purchasingdecision.The information mentioned regarding potential future products is not acommitment, promise, or legal obligation to deliver any material, code orfunctionality. Information about potential future products may not beincorporated into any contract. The development, release, and timing of anyfuture features or functionality described for our products remains at our solediscretion.Performance is based on measurements and projections using standard IBM benchmarksin a controlled environment. The actual throughput or performance that any user willexperience will vary depending upon many factors, including considerations such as theamount of multiprogramming in the user’s job stream, the I/O configuration, the storageconfiguration, and the workload processed. Therefore, no assurance can be given that anindividual user will achieve results similar to those stated here.