O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Chef for DevOps - an Introduction

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Introduction to Chef
Introduction to Chef
Carregando em…3
×

Confira estes a seguir

1 de 54 Anúncio

Chef for DevOps - an Introduction

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/

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/

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Anúncio

Semelhante a Chef for DevOps - an Introduction (20)

Mais de Sanjeev Sharma (20)

Anúncio

Mais recentes (20)

Chef for DevOps - an Introduction

  1. 1. Chef for DevOps Concepts and Overview Sanjeev Sharma Executive IT Specialist IBM Rational Specialty Architect IBM Software Group
  2. 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. 3. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
  4. 4. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
  5. 5. Businesses are challenged to 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. 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. 7. DevOps: The time is now Four key drivers are making DevOps a 2013 imperative for all organizations. Business Agility Cloud Agile DevOps Computing Development Operational Discipline
  8. 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. 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. 10. A blueprint for continuous 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. 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. 12. Key Concepts 1. Continuous Integration 2. Continuous Delivery 3. Continuous Test 4. Continuous Monitoring 5. Infrastructure as Code 6. Build and Delivery Pipeline
  13. 13. Continuous Delivery http://bit.ly/PRQ4a7
  14. 14. Build & Delivery Pipeline Continuously Deliver to the next Stage.
  15. 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. 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. 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. 18. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
  19. 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. 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. 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. 22. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
  23. 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. 24. The value of Chef
  25. 25. The value of Chef
  26. 26. The value of Chef
  27. 27. The value of Chef
  28. 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. 29. Chef Concepts – the diagram
  30. 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. 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. 32. Chef Concepts – the diagram
  33. 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. 34. Chef Concepts – the diagram
  35. 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. 36. Chef Concepts – the diagram
  37. 37. Chef Concepts – the UML view
  38. 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. 39. A Chef run – how Chef configures a Node?
  40. 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. 41. 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
  42. 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. 43. Agenda • A Review of DevOps • IBMs Continuous Delivery solution • Introduction to Chef • Chef and Continuous Delivery
  44. 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 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. 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. 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. 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. 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. 49. Chef and the 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 49
  50. 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. 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. 52. www.ibm.com/software/rational
  53. 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 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. 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.

×