This document provides instructions for setting up a workstation to test automation code using Chef tools. It discusses installing Chef, Test Kitchen and Vagrant on Linux, Mac OS X and Windows systems. It recommends downloading the apache cookbook from the chef-fundamentals-repo on GitHub to use for testing and reviewing cookbooks. The document introduces Test Kitchen as a way to set up sandbox environments for running cookbooks without extensive workstation configuration.
Testing Your Automation Code (Docker Version)Mischa Taylor
This document provides an introduction to testing infrastructure automation code with Chef. It discusses:
- Adding tests to the apache cookbook from the Chef Fundamentals course using Test Kitchen, ChefSpec, Foodcritic and RuboCop.
- Using Test Kitchen to run cookbooks in a sandbox environment mirroring production.
- Using Foodcritic and RuboCop to detect suspicious code.
- Using ChefSpec to produce runnable documentation.
- The benefits of testing infrastructure code with Chef including making things more testable, repeatable and finding bugs earlier in the development process.
- Test Kitchen allows you to set up sandbox environments using tools like Vagrant to test Chef cookbooks on your workstation without needing a Chef server or nodes.
- The document discusses installing Test Kitchen and the kitchen-vagrant plugin via RubyGems, and generating a Gemfile template to specify the required gems for testing the Apache cookbook.
- A Test Kitchen initialization is run on the Apache cookbook directory to generate files including a .kitchen.yml configuration and Gemfile, and the reader is instructed to run "bundle install" to install the gems.
Regardless of whether you're using chef or any other automated devops tool, you still need to consider where you are going to host things. Redundancy is good, so in this talk I will describe the tools I used as well as how and why I set up my own chef+git server to provide my own cauldron in which to cook up server deployments.
Continuous Infrastructure: Modern Puppet for the Jenkins Project - PuppetConf...Puppet
This document summarizes Tyler Croy's presentation on managing the Jenkins infrastructure using Puppet. It describes how the infrastructure evolved from an unmanaged setup at Sun/Oracle to using masterless Puppet and eventually Puppet Enterprise. Key aspects covered include managing services, hardware, code layout, testing, and deployment process. Special thanks are given to Puppet Labs for their support of the project.
DevOps Hackathon: Session 3 - Test Driven InfrastructureAntons Kranga
We will assume that you already familiar with Vagrant and Chef fundamentals described in session 1 and 2. Today we will go through TestKitchen and ServerSpec. While chef-dk is not stable, this is most reliable path.
Practical activities can be found here:
https://github.com/akranga/devops-hackathon-3
Puppet Camp Düsseldorf 2014: Continuously Deliver Your Puppet Code with Jenki...Puppet
Continuously Deliver Your Puppet Code with Jenkins, r10k and Git (Intermediate) - Toni Schmidbauer, IT Solutions at Spardat GmbH given at Puppet Camp Düsseldorf 2014
Test Driven Development with Puppet - PuppetConf 2014Puppet
The document discusses test driven development (TDD) approaches for Puppet modules. It recommends writing tests before code using tools like RSpec and guard. The document provides examples of unit testing Puppet code and definitions using rspec-puppet. It also discusses acceptance testing Puppet code and modules using Beaker against real systems. Overall, the document promotes writing tests for Puppet code to ensure quality and prevent regressions across different operating systems and versions.
Testing Your Automation Code (Docker Version)Mischa Taylor
This document provides an introduction to testing infrastructure automation code with Chef. It discusses:
- Adding tests to the apache cookbook from the Chef Fundamentals course using Test Kitchen, ChefSpec, Foodcritic and RuboCop.
- Using Test Kitchen to run cookbooks in a sandbox environment mirroring production.
- Using Foodcritic and RuboCop to detect suspicious code.
- Using ChefSpec to produce runnable documentation.
- The benefits of testing infrastructure code with Chef including making things more testable, repeatable and finding bugs earlier in the development process.
- Test Kitchen allows you to set up sandbox environments using tools like Vagrant to test Chef cookbooks on your workstation without needing a Chef server or nodes.
- The document discusses installing Test Kitchen and the kitchen-vagrant plugin via RubyGems, and generating a Gemfile template to specify the required gems for testing the Apache cookbook.
- A Test Kitchen initialization is run on the Apache cookbook directory to generate files including a .kitchen.yml configuration and Gemfile, and the reader is instructed to run "bundle install" to install the gems.
Regardless of whether you're using chef or any other automated devops tool, you still need to consider where you are going to host things. Redundancy is good, so in this talk I will describe the tools I used as well as how and why I set up my own chef+git server to provide my own cauldron in which to cook up server deployments.
Continuous Infrastructure: Modern Puppet for the Jenkins Project - PuppetConf...Puppet
This document summarizes Tyler Croy's presentation on managing the Jenkins infrastructure using Puppet. It describes how the infrastructure evolved from an unmanaged setup at Sun/Oracle to using masterless Puppet and eventually Puppet Enterprise. Key aspects covered include managing services, hardware, code layout, testing, and deployment process. Special thanks are given to Puppet Labs for their support of the project.
DevOps Hackathon: Session 3 - Test Driven InfrastructureAntons Kranga
We will assume that you already familiar with Vagrant and Chef fundamentals described in session 1 and 2. Today we will go through TestKitchen and ServerSpec. While chef-dk is not stable, this is most reliable path.
Practical activities can be found here:
https://github.com/akranga/devops-hackathon-3
Puppet Camp Düsseldorf 2014: Continuously Deliver Your Puppet Code with Jenki...Puppet
Continuously Deliver Your Puppet Code with Jenkins, r10k and Git (Intermediate) - Toni Schmidbauer, IT Solutions at Spardat GmbH given at Puppet Camp Düsseldorf 2014
Test Driven Development with Puppet - PuppetConf 2014Puppet
The document discusses test driven development (TDD) approaches for Puppet modules. It recommends writing tests before code using tools like RSpec and guard. The document provides examples of unit testing Puppet code and definitions using rspec-puppet. It also discusses acceptance testing Puppet code and modules using Beaker against real systems. Overall, the document promotes writing tests for Puppet code to ensure quality and prevent regressions across different operating systems and versions.
Tiny Puppet (tp) is a tool that allows users to easily install and manage applications on any operating system using Puppet. It provides definitions, functions, and data to configure applications using the tp command or in Puppet manifests. Key features include installing applications with one command, testing installed applications, accessing application logs, and uninstalling applications. Tp gets the data it needs to support applications across operating systems from the tinydata module, which currently supports installing and configuring over 149 applications.
Orchestrated Functional Testing with Puppet-spec and Mspectator - PuppetConf ...Puppet
This document discusses using Puppet-spec and Mspectator to orchestrate functional testing of Puppet configurations. Puppet-spec allows running unit and integration tests as part of Puppet runs, while Mspectator provides RSpec matchers to run functional tests across nodes using MCollective. The tests validate resources, packages, files and more, failing runs when tests don't pass to ensure configurations meet standards.
This document provides an overview of Vagrant and how it can be used to create development environments. Vagrant allows users to easily set up and configure virtual machine environments for development and testing. It works by defining a "Vagrantfile" that specifies the virtual machine configuration. Vagrant supports provisioning tools like Puppet, Chef and Docker to automate the configuration of VMs. It also allows sharing files between the host computer and guest VMs for development. The document discusses common Vagrant commands and how it can be used to create reproducible environments for tasks like testing configuration code.
Test-Driven Infrastructure with Ansible, Test Kitchen, Serverspec and RSpecMartin Etmajer
The goal of Continuous Delivery is, briefly, to get features into your users' or customers' hands as quickly and confidently as possible. In order to succeed, Development and Operations teams need to align and come up with both working and deployable software in short, regular intervals. Chef, Puppet, Ansible & Co. enable teams to code up application runtime environments, but alone do not allow for building quality into their processes. In this presentation I will show how you can apply the "Red, Green, Refactor Cycle" of Test-Driven Development and combine it with your configuration management or orchestration tool of choice in order to come up with better infrastructure that can automatically be tested using Ansible, Test Kitchen, Docker, Serverspec and RSpec.
This document describes an opinionated control repository for Puppet that contains manifests, modules, Hiera data, and tools to manage Puppet environments. It includes profiles and sample data for common applications. Optional integrations allow testing infrastructure with Vagrant, Docker, Fabric, and GitLab. The repository is intended as a starting point that can be customized for specific projects. It provides a skeleton for managing Puppet code and infrastructure as code.
The document describes the evolution of a workflow for managing thousands of Puppet modules using R10K and related tools. It started with all modules and code in a single monolithic repository, which led to long test cycles and all-or-nothing deployments. Introducing R10K and the Puppetfile allowed each module to be in its own repository and specify dependencies, enabling faster targeted testing and deployments. Additional tools like Reaktor were created to automate releases and notifications. The optimized workflow provides dynamic environments, simplified development, and easy production deployments.
The document discusses continuous infrastructure testing using ServerSpec to test servers through SSH access. ServerSpec allows writing tests that validate a server's actual state by describing resources like users, packages, services, files and processes and making assertions about their configuration and properties. The tests can be run via Rake and automated through Jenkins to continuously test external managed infrastructure. A demo is given of ServerSpec tests that validate properties of users, packages, services and files.
Many IT operations teams are used to managing infrastructure manually or with simple one-off scripts. This manual work and lack of verifiable behavior results in many issues and in uncertainty. In software development, Test Driven Development (TDD) is well recognized for improving design, increasing code quality, and allowing refactoring and better knowledge sharing.
Similar benefits can be gained in infrastructure projects when infrastructure is treated as code, driving that code development with tests. Configuration management tools such as Chef and Puppet allow infrastructure to be easily described as code and provide a complete support to introduce and run tests. This can allow development and operations teams to collaborate and confidently deliver working infrastructure code.
This document provides an overview of Ansible, an open source tool for configuration management and application deployment. It discusses how Ansible works using simple YAML playbooks to define configurations and execute tasks across nodes in an automated and agentless manner. The document also covers key Ansible concepts like modules, inventory, roles, conditionals and loops. It provides instructions on installing Ansible via pip, yum or apt and highlights many of Ansible's core modules.
Current session guides through Vagrant. Shows some tips and tricks and targeted to software developers.
Practical activities can be found here: https://github.com/akranga/devops-hackathon-1
This document summarizes an approach for testing Ansible code using linting, deployment with Vagrant/Ansible, and verification with Serverspec. It outlines setting up a Vagrant environment, creating a simple playbook to configure /etc/hosts, linting and provisioning the code, and writing a Serverspec test to validate the configuration. The full process is designed to test Ansible code as changes are made by watching for file changes and re-running the tests.
Workshop: Know Before You Push 'Go': Using the Beaker Acceptance Test Framewo...Puppet
This document provides an overview of testing Puppet modules using Beaker and related tools. It demonstrates generating a test Puppet module, installing necessary tools like Bundler and the Puppet module skeleton, and running the initial tests. The document recommends further resources for learning more about Beaker and testing Puppet code.
This document discusses testing principles and tools for infrastructure as code using Chef. It covers test-driven development (TDD) principles like writing tests first to define desired behavior. Chef testing tools covered include ChefSpec for unit testing cookbooks, ServerSpec for integration/black-box testing, and Foodcritic for linting cookbooks. It also discusses Test Kitchen for testing cookbooks across platforms and continuous integration (CI) using these tools.
This document summarizes a workshop on network automation tools including Chef and Zero Touch Provisioning.
The agenda includes demonstrating ZTP to boot three bare metal switches, using Chef to orchestrate the baseline configuration of two switches and enforce configuration statements, creating a VXLAN tunnel between two leaf switches using Cisco's CVX, and starting an Opendaylight controller to configure Openflow on switches.
The workshop will require some Virtualbox experience and a notebook with at least 4GB RAM and 10GB storage. Software needed includes Virtualbox, Hypervisor, and virtualization solutions. Attendees should be DevOps engineers interested in the network side of DevOps.
The workshop will prepare VMs, demonstrate
DevOps hackathon Session 2: Basics of ChefAntons Kranga
The document discusses infrastructure provisioning using Chef. It explains that Chef uses a declarative approach where you describe the desired state rather than how to achieve it. Cookbooks contain recipes that describe resources to bring a VM to the specified state. Cookbooks are repeatable, testable units that can install packages, configure services, create users and templates. Vagrant and Chef are often used together, with Vagrant managing VMs and triggering Chef provisioning to install software inside VMs.
uWSGI - Swiss army knife for your Python web appsTomislav Raseta
uWSGI is a full-stack tool for building hosting services that acts as an application server for Python web apps using the WSGI specification. It provides a pluggable architecture, versatility, high performance, low resource usage, and reliability. Configuration options are extensive and allow for processes, threads, reloading, monitoring and more. Proper configuration and testing is required to optimize performance for production deployments.
Chef is an open-source automation platform that treats infrastructure as code. It allows users to automate how infrastructure is configured, deployed and managed across any environment using a powerful DSL written in Ruby. Key features of Chef include server provisioning, automation of infrastructure changes, and management of configurations through recipes and cookbooks which are shared through an online community. Linecook is presented as an alternative to Chef for server automation that uses shell scripts instead of Ruby code and relies on established tools like SSH, VirtualBox, and bash instead of requiring installation of the Chef platform.
openQA hands on with openSUSE Leap 42.1 - openSUSE.Asia Summit ID 2016Ben Chou
This document provides an overview of openQA and instructions for installing and configuring openQA on openSUSE Leap 42.1. It describes openQA's system architecture and workflow, and includes workshops to install openQA, configure the web UI and a worker, manage API keys, configure test settings, and run an openSUSE installation test.
Community Cookbooks & further resources - Fundamentals Webinar Series Part 6Chef
The document provides an agenda and overview for a Chef Fundamentals webinar. The webinar will cover topics such as setting up a Chef workstation, managing nodes, using Chef resources and recipes, roles, data bags, environments, and community cookbooks. It instructs attendees to ask questions during the webinar using the chat window or discussion forum. The slides and recorded video will be made available after the webinar.
Tiny Puppet (tp) is a tool that allows users to easily install and manage applications on any operating system using Puppet. It provides definitions, functions, and data to configure applications using the tp command or in Puppet manifests. Key features include installing applications with one command, testing installed applications, accessing application logs, and uninstalling applications. Tp gets the data it needs to support applications across operating systems from the tinydata module, which currently supports installing and configuring over 149 applications.
Orchestrated Functional Testing with Puppet-spec and Mspectator - PuppetConf ...Puppet
This document discusses using Puppet-spec and Mspectator to orchestrate functional testing of Puppet configurations. Puppet-spec allows running unit and integration tests as part of Puppet runs, while Mspectator provides RSpec matchers to run functional tests across nodes using MCollective. The tests validate resources, packages, files and more, failing runs when tests don't pass to ensure configurations meet standards.
This document provides an overview of Vagrant and how it can be used to create development environments. Vagrant allows users to easily set up and configure virtual machine environments for development and testing. It works by defining a "Vagrantfile" that specifies the virtual machine configuration. Vagrant supports provisioning tools like Puppet, Chef and Docker to automate the configuration of VMs. It also allows sharing files between the host computer and guest VMs for development. The document discusses common Vagrant commands and how it can be used to create reproducible environments for tasks like testing configuration code.
Test-Driven Infrastructure with Ansible, Test Kitchen, Serverspec and RSpecMartin Etmajer
The goal of Continuous Delivery is, briefly, to get features into your users' or customers' hands as quickly and confidently as possible. In order to succeed, Development and Operations teams need to align and come up with both working and deployable software in short, regular intervals. Chef, Puppet, Ansible & Co. enable teams to code up application runtime environments, but alone do not allow for building quality into their processes. In this presentation I will show how you can apply the "Red, Green, Refactor Cycle" of Test-Driven Development and combine it with your configuration management or orchestration tool of choice in order to come up with better infrastructure that can automatically be tested using Ansible, Test Kitchen, Docker, Serverspec and RSpec.
This document describes an opinionated control repository for Puppet that contains manifests, modules, Hiera data, and tools to manage Puppet environments. It includes profiles and sample data for common applications. Optional integrations allow testing infrastructure with Vagrant, Docker, Fabric, and GitLab. The repository is intended as a starting point that can be customized for specific projects. It provides a skeleton for managing Puppet code and infrastructure as code.
The document describes the evolution of a workflow for managing thousands of Puppet modules using R10K and related tools. It started with all modules and code in a single monolithic repository, which led to long test cycles and all-or-nothing deployments. Introducing R10K and the Puppetfile allowed each module to be in its own repository and specify dependencies, enabling faster targeted testing and deployments. Additional tools like Reaktor were created to automate releases and notifications. The optimized workflow provides dynamic environments, simplified development, and easy production deployments.
The document discusses continuous infrastructure testing using ServerSpec to test servers through SSH access. ServerSpec allows writing tests that validate a server's actual state by describing resources like users, packages, services, files and processes and making assertions about their configuration and properties. The tests can be run via Rake and automated through Jenkins to continuously test external managed infrastructure. A demo is given of ServerSpec tests that validate properties of users, packages, services and files.
Many IT operations teams are used to managing infrastructure manually or with simple one-off scripts. This manual work and lack of verifiable behavior results in many issues and in uncertainty. In software development, Test Driven Development (TDD) is well recognized for improving design, increasing code quality, and allowing refactoring and better knowledge sharing.
Similar benefits can be gained in infrastructure projects when infrastructure is treated as code, driving that code development with tests. Configuration management tools such as Chef and Puppet allow infrastructure to be easily described as code and provide a complete support to introduce and run tests. This can allow development and operations teams to collaborate and confidently deliver working infrastructure code.
This document provides an overview of Ansible, an open source tool for configuration management and application deployment. It discusses how Ansible works using simple YAML playbooks to define configurations and execute tasks across nodes in an automated and agentless manner. The document also covers key Ansible concepts like modules, inventory, roles, conditionals and loops. It provides instructions on installing Ansible via pip, yum or apt and highlights many of Ansible's core modules.
Current session guides through Vagrant. Shows some tips and tricks and targeted to software developers.
Practical activities can be found here: https://github.com/akranga/devops-hackathon-1
This document summarizes an approach for testing Ansible code using linting, deployment with Vagrant/Ansible, and verification with Serverspec. It outlines setting up a Vagrant environment, creating a simple playbook to configure /etc/hosts, linting and provisioning the code, and writing a Serverspec test to validate the configuration. The full process is designed to test Ansible code as changes are made by watching for file changes and re-running the tests.
Workshop: Know Before You Push 'Go': Using the Beaker Acceptance Test Framewo...Puppet
This document provides an overview of testing Puppet modules using Beaker and related tools. It demonstrates generating a test Puppet module, installing necessary tools like Bundler and the Puppet module skeleton, and running the initial tests. The document recommends further resources for learning more about Beaker and testing Puppet code.
This document discusses testing principles and tools for infrastructure as code using Chef. It covers test-driven development (TDD) principles like writing tests first to define desired behavior. Chef testing tools covered include ChefSpec for unit testing cookbooks, ServerSpec for integration/black-box testing, and Foodcritic for linting cookbooks. It also discusses Test Kitchen for testing cookbooks across platforms and continuous integration (CI) using these tools.
This document summarizes a workshop on network automation tools including Chef and Zero Touch Provisioning.
The agenda includes demonstrating ZTP to boot three bare metal switches, using Chef to orchestrate the baseline configuration of two switches and enforce configuration statements, creating a VXLAN tunnel between two leaf switches using Cisco's CVX, and starting an Opendaylight controller to configure Openflow on switches.
The workshop will require some Virtualbox experience and a notebook with at least 4GB RAM and 10GB storage. Software needed includes Virtualbox, Hypervisor, and virtualization solutions. Attendees should be DevOps engineers interested in the network side of DevOps.
The workshop will prepare VMs, demonstrate
DevOps hackathon Session 2: Basics of ChefAntons Kranga
The document discusses infrastructure provisioning using Chef. It explains that Chef uses a declarative approach where you describe the desired state rather than how to achieve it. Cookbooks contain recipes that describe resources to bring a VM to the specified state. Cookbooks are repeatable, testable units that can install packages, configure services, create users and templates. Vagrant and Chef are often used together, with Vagrant managing VMs and triggering Chef provisioning to install software inside VMs.
uWSGI - Swiss army knife for your Python web appsTomislav Raseta
uWSGI is a full-stack tool for building hosting services that acts as an application server for Python web apps using the WSGI specification. It provides a pluggable architecture, versatility, high performance, low resource usage, and reliability. Configuration options are extensive and allow for processes, threads, reloading, monitoring and more. Proper configuration and testing is required to optimize performance for production deployments.
Chef is an open-source automation platform that treats infrastructure as code. It allows users to automate how infrastructure is configured, deployed and managed across any environment using a powerful DSL written in Ruby. Key features of Chef include server provisioning, automation of infrastructure changes, and management of configurations through recipes and cookbooks which are shared through an online community. Linecook is presented as an alternative to Chef for server automation that uses shell scripts instead of Ruby code and relies on established tools like SSH, VirtualBox, and bash instead of requiring installation of the Chef platform.
openQA hands on with openSUSE Leap 42.1 - openSUSE.Asia Summit ID 2016Ben Chou
This document provides an overview of openQA and instructions for installing and configuring openQA on openSUSE Leap 42.1. It describes openQA's system architecture and workflow, and includes workshops to install openQA, configure the web UI and a worker, manage API keys, configure test settings, and run an openSUSE installation test.
Community Cookbooks & further resources - Fundamentals Webinar Series Part 6Chef
The document provides an agenda and overview for a Chef Fundamentals webinar. The webinar will cover topics such as setting up a Chef workstation, managing nodes, using Chef resources and recipes, roles, data bags, environments, and community cookbooks. It instructs attendees to ask questions during the webinar using the chat window or discussion forum. The slides and recorded video will be made available after the webinar.
Chef Fundamentals Training Series Module 2: Workstation SetupChef Software, Inc.
This document provides instructions for setting up a workstation to manage infrastructure with Chef. It covers installing Chef, creating an account on the hosted Chef server, downloading the starter kit which contains files like cookbooks and roles, and configuring the knife command line tool to connect to the Chef server. The document also gives an overview of the components that make up a Chef-managed infrastructure including nodes, roles, environments and data bags.
Lessons from Etsy: Avoiding Kitchen Nightmares - #ChefConf 2012Patrick McDonnell
Talk by Patrick McDonnell (@mcdonnps) at #ChefConf 2012
Chef makes it so easy to change configuration en masse that it can be dangerous if not used with certain precautions and in accordance with a well thought out testing workflow. In our use of Chef at Etsy, we have devised many in-house best practices in response to failures which have helped greatly in avoiding catastrophic outages. This talk will focus on mistakes we've made and how we've avoided repeating them by enforcing standards in cookbooks, testing changes before rollout through the use of environments and in conjunction with the Spork plugin for Knife, and linting cookbooks with Foodcritic. I'll also talk about using handlers intelligently to monitor Chef runs and how to generate reports from the myriad data available in CouchDB.
Node setup, resource, and recipes - Fundamentals Webinar Series Part 2Chef
Part 2 of a 6 part series introducing you to the fundamentals of Chef.
This session includes:
* Node Setup
* Chef Resources and Recipes
After viewing this webinar you will be able to:
- Login to the node in your Chef Training Lab
- Install Chef nodes using "knife bootstrap"
- Explain how knife bootstrap configures a node to use the - Organization created in the previous section
- Explain the basic configuration needed to run chef-client
- Describe in detail what a cookbook is
- Create a new cookbook
- Explain what a recipe is
- Describe how to use the package, service, and template - resources
- Upload a cookbook to the Chef Server
- Explain what a run list is, and how to set it for a node - via knife
- Explain the output of a chef-client run
Video of this webinar can be found at the following URL
https://www.youtube.com/watch?v=S5lHUpzoCYo&list=PL11cZfNdwNyPnZA9D1MbVqldGuOWqbumZ
Using Test Kitchen for testing Chef cookbooksTimur Batyrshin
Using Test Kitchen and ChefDK, one can test Chef cookbooks across multiple platforms. Key steps include:
1. Installing Chefdk, Docker and generating a new cookbook with boilerplate files and tests.
2. Configuring .kitchen.yml to define platforms, suites, attributes, and dependencies.
3. Adding nodes, data bags, and environments to test integration.
4. Iteratively developing code and running kitchen create, converge, verify on instances to test changes, and finally kitchen test to run all suites and platforms.
Chef Fundamentals Training Series Module 3: Setting up Nodes and Cookbook Aut...Chef Software, Inc.
The document provides instructions for setting up a node and writing a cookbook using Chef. Key points:
- It describes how to install Chef on a node using "knife bootstrap" and configure it to use an Organization.
- It explains that cookbooks contain recipes, files and templates to configure infrastructure using resources like packages, services and files.
- The tutorial walks through creating an "apache" cookbook with recipes to install the Apache package, start the service and enable it to start on boot using package and service resources.
Automate Your Automation | DrupalCon ViennaPantheon
Greg Anderson provides guidance on automating various development and deployment tasks. He discusses automating tasks like development, testing, deployment and maintenance. Some key tools mentioned are Travis CI, Circle CI, Composer and hub. Automating tasks improves reliability, makes onboarding easier and allows doing more work. The costs of not automating include increased risk of errors and lost knowledge over time.
Introduction To Continuous Compliance & RemediationNicole Johnson
Success with DevOps can be measured with a number of different metrics. How frequently are systems audited for compliance to various policies? How long does it take to remediate a failing control or vulnerability? This workshop provide an introduction to practice of continuous compliance and remediation. The workshop uses InSpec and Chef for compliance and remediation, respectively. InSpec is an open-source testing framework for infrastructure with a human-readable language for specifying compliance, security and other policy requirements. Chef is an open-source framework for infrastructure automation. Easily integrate automated tests that check for adherence to policy into any stage of your deployment pipeline.
During this session, participants will:
Run InSpec locally on a machine
Run InSpec on a remote machine
Use InSpec in the Chef cookbook development process for integration testing
By the end of this class participants will be able to:
Execute an InSpec test on a local machine
Execute an InSpec test on a remote machine
Generate an InSpec profile
Add InSpec-based integration test to a Chef cookbook
Run InSpec-based integrations tests during Chef cookbook development
Prerequisites
Participants should bring a wifi-enabled laptop to the workshop. Participants will be given a remote workstation with all prerequisites installed. The only thing required to access these workstations will be an SSH client (PuTTY on Windows) and familiarity with a interactive text editor (Vi/Vim, Emacs, or Nano).
It’s best that participants of this workshop have some familiarity and comfort with the following:
Writing code (of just about any flavor) in a text editor
Working on the command line
Basic system administration – installing packages, configuring those packages, starting service
This document discusses automating infrastructure with Chef configuration management. It provides an overview of Chef, including that it uses a server-client model with cookbooks, recipes, and run lists to define and enforce configurations. Instructions are given on installing Chef Server on Ubuntu, setting up a Chef client, uploading cookbooks, creating run lists, and using recipes to deploy Apache and custom HTML content for infrastructure automation with Chef.
Adopt DevOps philosophy on your Symfony projects (Symfony Live 2011)Fabrice Bernhard
This is the presentation given at the Symfony Live 2011 conference. It is an introduction to the new agile movement spreading in the technical operations community called DevOps and how to adopt it on web development projects, in particular Symfony projects.
Plan of the slides :
- Configuration Management
- Development VM
- Scripted deployment
- Continuous deployment
Tools presented in the slides:
- Puppet
- Vagrant
- Fabric
- Jenkins / Hudson
Conan.io - The C/C++ package manager for DevelopersUilian Ries
Conan is a decentralized package manager for C and C++ that handles both source code and pre-compiled binaries. It addresses issues with building dependencies from source by allowing developers to define packages through recipes that specify dependencies and build instructions. Conan packages are cached locally and identified by name, version, and user/channel to allow isolation of builds. The Conan community contributes package recipes through open source projects on GitHub like the Conan Center and Bincrafters organization.
Node object and roles - Fundamentals Webinar Series Part 3Chef
Part 3 of a 6 part series introducing you to the fundamentals of Chef.
This session includes:
* Node object
* Chef roles
After viewing this webinar you will be able to:
- Explain what the node object represents in Chef
- Show details about a node
- Describe what node attributes are
- Retrieve a node attribute
- Describe where and how attributes are set
- Explain the attribute merge order and precedence rules
- Declare an attribute with a recipe and set its value
- Explain what Roles are, and how they are used to provide -larity
- Discuss the Role JSON DSL
- Explain how merge order affects the precedence hierarchy
Video of this webinar can be found at the following URL
https://www.youtube.com/watch?v=nQogf89hgnM&list=PL11cZfNdwNyPnZA9D1MbVqldGuOWqbumZ
EmacsConf 2019: Interactive Remote Debugging and Development with TRAMP ModeMatt Ray
Emacs’ TRAMP Mode allows for remotely editing files and using Emacs Shell Mode with remote systems. This session walked through the basics of using TRAMP Mode with the Free Software tools Vagrant, Chef, InSpec, and the interactive Ruby debugging shell Pry. The speaker notes are included along with the demo notes. The YouTube recording of the talk is available here: https://youtu.be/4pHid-kTBHw
This document provides an overview and agenda for an introductory training course on testing infrastructure automation code with Chef and its tools. The agenda includes an overview of Chef, discussing resources, describing policies with recipes and cookbooks, using a sandbox for testing, verifying node state, getting faster feedback, writing clean code, and wrapping up. Hands-on labs are emphasized for learning Chef through practice. Questions are encouraged throughout, and breaks will be taken as needed.
The document discusses automating software deployment using Ansible. It provides an overview of Ansible's basic concepts like inventory files to define hosts, playbooks to execute tasks on hosts, and roles to bundle related tasks. It then discusses using Ansible roles to automate deployments, including the ansistrano roles which can deploy applications by copying files, managing releases, and supporting deployment hooks. Overall the document presents Ansible as a way to easily automate and standardize software deployment processes.
The document discusses the modern developer toolbox and outlines various tools that developers can use for development environments, testing, debugging, profiling, deployment, logging, and monitoring of applications. It provides recommendations for setting up development environments on different operating systems and with tools like Vagrant, Docker, Ansible, and Homebrew. It also discusses PHP installation and editors/IDEs to use. Testing with PHPUnit, Behat, and Jenkins is covered as well as debugging with XDebug, profiling with XHProf, and deployment with Ansible, Capistrano and other options. Logging with Monolog, Logstash and Kibana is also summarized along with monitoring metrics with StatsD, Graphite and Grafana.
Kevin Smith is the Director of Server Engineering at Opscode and has been developing software for 17 years including 7 years with Erlang. He discusses infrastructure as code, configuration management with Chef, and how Chef can be used in large environments. Specifically, he covers how Chef uses recipes, roles, attributes and resources to declaratively configure nodes. He also discusses how the Chef server and clients interact and how search is used. Finally, he notes how Chef is open source and has a large community contributing cookbooks and tools to support deployments of all sizes.
One commit, one release. Continuously delivering a Symfony project.Javier López
For the last few months we've been implementing a Continuous Delivery pipeline for the redesign of Time Out. In this talk I will demonstrate a real life example of what our pipeline looks like, the different tools we've used to get it done (phing, github, jenkins, ansible, AWS S3, ...), and peculiarities for PHP and Symfony2 projects. Most importantly, I'll be looking at things we've struggled with along the way and the lessons we've learnt.
Similar to Testing Your Automation Code (Vagrant Version) (20)
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
Building RAG with self-deployed Milvus vector database and Snowpark Container...Zilliz
This talk will give hands-on advice on building RAG applications with an open-source Milvus database deployed as a docker container. We will also introduce the integration of Milvus with Snowpark Container Services.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Introducing Milvus Lite: Easy-to-Install, Easy-to-Use vector database for you...Zilliz
Join us to introduce Milvus Lite, a vector database that can run on notebooks and laptops, share the same API with Milvus, and integrate with every popular GenAI framework. This webinar is perfect for developers seeking easy-to-use, well-integrated vector databases for their GenAI apps.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
3. 3
You’ve used and want to
bulletproof
your so that
you are with
Spec
3
4. In this class
• We’ll add tests to the apache cookbook from the
Fundamentals Course
• We’ll show you how to run cookbooks in a sandbox
environment mirroring production with Test
Kitchen
• We’ll show you how to detect suspicious cookbook
code with Foodcritic & RuboCop
• We’ll show you how to produce runnable
documentation with ChefSpec
4
4
5. Using Chef is half the battle
5
“Chef is like....
tests for your infrastructure”
-Ezra Zygmuntowicz, Co-Founder EngineYard
http://www.akitaonrails.com/2008/6/5/railsconf-2008-brazil-rails-podcast-special-edition#.U0HfiF7Ed-8
5
6. Chef makes things more testable
• Chef automates infrastructure in a repeatable
fashion
6
6
7. What’s the other half of the battle?
7
“Have a plan”
-Adam Jacob, Co-Founder Chef
7
8. There’s no more magic to testing
8
http://www.flickr.com/photos/dkeats/4128747046/sizes/s/in/photostream/
8
11. Otherwise you could...
• Verify and validate just before going to production
until time runs out. But time always runs out
11
http://mrg.bz/iEr1oj
11
12. Waiting to test when it’s “done”
12
Intention:
Reality:
Build Test Deploy
Build
T
es
De
ploy
We’re late
no time
to test!
12
18. Test arrangement
• Arrange tests to get feedback fast - at the earliest
possible time
18
seconds
minutes
hours
Foodcritic/Rubocop
ChefSpec
Serverspec
18
19. Reason for multiple tools
• Finding a bug in something that you can’t execute
is freaking hard!
• While fixing bugs before writing code is cheap,
finding them is expensive
19
19
20. The Tools
• Each tool is specialized to give feedback as early
as possible during the cookbook authoring process
20
20
21. What each tool does
• In your text editor when you type in cookbook code:
• Foodcritic analyzes your Chef style
• RuboCop analyzes your Ruby coding technique
• Before you deploy to a test node:
• ChefSpec helps you document and organize your
code
• After you deploy to a test node:
• Serverspec verifies a cookbook behaves as intended
21
21
23. Legend: Do I run that command on my workstation?
$ whoami
i-am-a-workstation
This is an example of a command to run on your workstation
user@hostname:~$ whoami
i-am-a-chef-node
This is an example of a command to run on your target node via SSH.
23
23
31. $ curl -L http://www.getchef.com/chef/install.sh | sudo bash
Workstation Setup - Mac OS X / Linux
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13347 100 13347 0 0 12147 0 0:00:01 0:00:01 --:--:-- 12155
Downloading Chef for mac_os_x...
Installing Chef
installing with sh...
Verifying archive integrity... All good.
Uncompressing The full stack of chef...
Thank you for installing Chef!
Checksum compare with shasum succeeded.
Installing Chef
installing with sh...
Verifying archive integrity... All good.
Uncompressing The full stack of chef
31
31
32. What just happened?
• Chef and all of its dependencies installed via an
operating system-specific package ("omnibus installer")
• Installation includes
• The Ruby language - used by Chef
• knife - Command line tool for administrators
• chef-client - Client application
• ohai - System profiler
• ...and more
32
32
33. OPEN IN EDITOR: $HOME/.bash_profile
export PATH="/opt/chef/embedded/bin:$PATH"
Add Chef Client to PATH
33
33
46. $ knife cookbook site download git
$ knife cookbook site download dmg
$ knife cookbook site download windows
$ knife cookbook site download runit
$ knife cookbook site download yum
$ knife cookbook site download yum-epel
$ knife cookbook site download chef_handler
Download git cookbook + dependencies
46
46
47. $ tar xvf git*.tar.gz
$ tar xvf dmg*.tar.gz
$ tar xvf windows*.tar.gz
$ tar xvf runit*.tar.gz
$ tar xvf yum-3*.tar.gz
$ tar xvf yum-epel*.tar.gz
$ tar xvf chef_handler*.tar.gz
Extract cookbook archives
47
47
48. $ cd /tmp
$ sudo chef-client -z -o git
Use local mode to run cookbook
48
48
61. Developer Tools - Windows
• build-essential cookbook does not currently support
Windows.
• All the necessary developer tools come packaged
with the Omnibus Installer.
61
61
64. > knife cookbook site download build-essential
> knife cookbook site download git
> knife cookbook site download dmg
> knife cookbook site download windows
> knife cookbook site download runit
> knife cookbook site download yum
> knife cookbook site download yum-epel
> knife cookbook site download chef_handler
Download git cookbook + dependencies
64
64
65. > tar xvf build-essential*.tar.gz
> tar xvf git*.tar.gz
> tar xvf dmg*.tar.gz
> tar xvf windows*.tar.gz
> tar xvf runit*.tar.gz
> tar xvf yum-3*.tar.gz
> tar xvf yum-epel*.tar.gz
> tar xvf chef_handler*.tar.gz
Extract cookbook archives
65
65
66. > cd %TEMP%
> chef-client -z -o git
Use local mode to run cookbook
66
PS> cd $env:temp
PS> chef-client -z -o git
Run As
Administrator
Run As
Administrator
66
73. chef-fundamentals-repo
• We’re going to build on the chef-fundamentals-
repo created in the Chef Fundamentals training,
adding tests:
https://github.com/learnchef/chef-fundamentals-repo/
tree/master/cookbooks/apache
73
73
74. $ cd $HOME
Home directory - great place for source
74
$ cd %USERPROFILE%
74
94. $ kitchen init --create-gemfile
create .kitchen.yml
create test/integration/default
create Gemfile
append Gemfile
append Gemfile
You must run ‘bundle install’ to fetch any new
gems.
Create Gemfile template
94
94
95. Kitchen output on Windows
• The strange <-‐[0m<-‐33m characters in the Windows
output are ANSI escape sequences.
95
95
96. Kitchen output on Windows
• ANSICon also adds support for ANSI escape
sequences to Windows as a workaround:
https://github.com/adoxa/ansicon
Download link:
http://adoxa.hostmyway.net/ansicon/
96
96
98. $ kitchen init --create-gemfile
create .kitchen.yml
create test/integration/default
create Gemfile
append Gemfile
append Gemfile
You must run ‘bundle install’ to fetch any new
gems.
Create Gemfile template
98
98
101. 101
No need to install bundler
• Chef install includes the bundler gem
• Outside the Chef install, bundler can be installed via:
•gem
install
bundler
101
102. $ bundle install --path vendor/bundle
Do what Test Kitchen tells you
Fetching gem metadata from https://rubygems.org/..........
Fetching gem metadata from https://rubygems.org/..
Installing mixlib-shellout (1.3.0)
Installing net-ssh (2.8.0)
Installing net-scp (1.1.2)
Installing safe_yaml (1.0.1)
Installing thor (0.19.1)
Installing test-kitchen (1.2.1)
Installing kitchen-vagrant (0.14.0)
Using bundler (1.1.5)
Your bundle is complete! It was installed into ./vendor/bundle
102
102
103. 103
Vendor Everything
• Gems change frequently and sometimes conflict
• -‐-‐path option passed to bundle
install
overrides system gems by installing Gemfile gems
locally
• Bundler docs recommend using vendor/bundle
103
104. 104
If you vendor gems use:
bundle
exec
to read gems in
vendor/bunde
104
111. kitchen login on Windows
• Test Kitchen requires ssh to login to guest VMs
• Easiest way to get ssh is to use the Unix command
line tools packaged with Git for Windows
111
111
112. kitchen login on Windows
• Add the Unix tools to your path
• 64-bit: C:Program
Files
(x86)Gitbin
• 32-bit: C:Program
FilesGitbin
112
112
113. $ bundle exec kitchen login default-centos-64
kitchen login
Last login: Mon Nov 25 07:00:52 2013 from 10.0.2.2
[vagrant@default-centos-64 ~]$ cat /etc/redhat-release
CentOS release 6.4 (Final)
[vagrant@default-centos-64 ~]$ exit
logout
Connection to 127.0.0.1 closed.
113
113
114. 114
kitchen destroy
• kitchen
destroy
<instance_name> shuts down a
sandbox instance and destroys and virtual resources
allocated
114
117. $ bundle exec kitchen converge default-centos-64
Perform Chef run
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'opscode-centos-6.4' could not be found. Attempting
to find and install...
...
[2014-03-30T09:09:59+00:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 11.10.4
[2014-03-30T09:09:59+00:00] INFO: *** Chef 11.10.4 ***
[2014-03-30T09:09:59+00:00] INFO: Chef-client pid: 2542
[2014-03-30T09:09:59+00:00] INFO: Setting the run_list to
["recipe[apache::default]"] from JSON
....
117
117
118. $ bundle exec kitchen converge default-centos-64
Perform Chef run
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'opscode-centos-6.4' could not be found. Attempting to find and install...
...
[2014-03-30T09:09:59+00:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 11.10.4
[2014-03-30T09:09:59+00:00] INFO: *** Chef 11.10.4 ***
[2014-03-30T09:09:59+00:00] INFO: Chef-client pid: 2542
[2014-03-30T09:09:59+00:00] INFO: Setting the run_list to ["recipe[apache::default]"] from JSON
....
[2014-04-07T02:32:50-04:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully
(exit code 1)
>>>>>> Converge failed on instance <default-centos-64>.
>>>>>> Please see .kitchen/logs/default-centos-64.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E chef-solo --config /tmp/kitchen/solo.rb --json-attributes /
tmp/kitchen/dna.json --log_level info]
>>>>>> ----------------------
118
FAIL
118
121. 121
Undefined attribute
• When you see undefined
method
‘[]’
for
nil:NilClass it oftentimes means you have an
undefined attribute
• Let’s see if node["motd"]["company"] is being set
121
125. Good cookbooks
• Good cookbooks can be used in isolation
• They set reasonable defaults for all attributes used
• Test Kitchen is designed to run a cookbook in
isolation to give you feedback on attribute use
125
125
126. Test attributes
• We won’t fix the motd cookbook in this class
• Test Kitchen supports injection of test attributes
• We’ll supply the correct attribute in
the .kitchen.yml configuration file
126
126
129. $ bundle exec kitchen converge default-centos-64
Perform Chef run
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'opscode-centos-6.4' could not be found. Attempting
to find and install...
...
[2014-03-30T09:09:59+00:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 11.10.4
[2014-03-30T09:09:59+00:00] INFO: *** Chef 11.10.4 ***
[2014-03-30T09:09:59+00:00] INFO: Chef-client pid: 2542
[2014-03-30T09:09:59+00:00] INFO: Setting the run_list to
["recipe[apache::default]"] from JSON
....
129
129
130. $ bundle exec kitchen converge default-centos-64
Perform Chef run
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'opscode-centos-6.4' could not be found. Attempting to find and
install...
...
[2014-03-30T09:09:59+00:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 11.10.4
[2014-03-30T09:09:59+00:00] INFO: *** Chef 11.10.4 ***
[2014-03-30T09:09:59+00:00] INFO: Chef-client pid: 2542
[2014-03-30T09:09:59+00:00] INFO: Setting the run_list to ["recipe[apache::default]"]
from JSON
....
[2014-04-07T02:40:03-04:00] INFO: Report handlers complete
Chef Client finished, 5/10 resources updated in 2.52587913 seconds
Finished converging <default-centos-64> (0m4.15s).
-----> Kitchen is finished. (0m4.22s)
130
WIN
130
131. Where to go next
• Learning Chef book excerpt
was sent to you are part of
the class registration.
• Chapter 1 covers Test
Kitchen and .kitchen.yml
format in more detail.
• Appendix provides
sample .kitchen.yml configs
131
131
133. 133
Let’s verify that the Apache cookbook
actually works by
configuring Test Kitchen to allow
web browser access by
the Chef Development workstation
133
136. $ bundle exec kitchen converge default-centos-64
Perform Chef run
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'opscode-centos-6.4' could not be found. Attempting
to find and install...
...
[2014-03-30T09:09:59+00:00] INFO: Forking chef instance to converge...
Starting Chef Client, version 11.10.4
[2014-03-30T09:09:59+00:00] INFO: *** Chef 11.10.4 ***
[2014-03-30T09:09:59+00:00] INFO: Chef-client pid: 2542
[2014-03-30T09:09:59+00:00] INFO: Setting the run_list to
["recipe[apache::default]"] from JSON
....
136
136
142. OPEN IN EDITOR: cookbooks/apache/Gemfile
source 'https://rubygems.org'
gem 'test-kitchen'
gem 'kitchen-vagrant'
gem 'serverspec', '~> 1.1'
Add serverspec to Gemfile
142
142
143. OPEN IN EDITOR: cookbooks/apache/Gemfile
source 'https://rubygems.org'
gem 'test-kitchen'
gem 'kitchen-vagrant'
gem ‘serverspec’, ‘~> 1.1’
Add serverspec to Gemfile
143
PessimisticVersion
Constraint
143
144. Version Constraint
144
•If a gem properly follows semantic
versioning with its versioning scheme.
You can take advantage of this to
choose a version constraint to lock
down the gem in your application.
http://guides.rubygems.org/patterns/#declaring_dependencies
144
145. Semantic Versioning
145
Given a version number MAJOR.MINOR.PATCH, increment
the:
1.MAJOR version when you make incompatible API
changes,
2.MINOR version when you add functionality in a backwards-
compatible manner, and
3.PATCH version when you make backwards-compatible bug
fixes.
Additional labels for pre-release and build metadata are
available as extensions to the MAJOR.MINOR.PATCH format.
http://guides.rubygems.org/patterns/#semantic_versioning
145
146. Versioning Example
146
Let’s say the following releases of a gem exist:
■Version 2.1.0 — Baseline
■Version 2.2.0 — Introduced some new (backward
compatible) features.
■Version 2.2.1 — Removed some bugs
■Version 2.2.2 — Streamlined your code
■Version 2.3.0 — More new features (but still backwards
compatible).
■Version 3.0.0 — Reworked the interface. Code written to
version 2.x might not work.
http://guides.rubygems.org/patterns/#semantic_versioning
146
161. Should vs Expect
161
describe
‘clowns
site’
do
it
‘responds
on
port
80’
do
expect(port
80).to
be_listening
‘tcp’
end
end
Expect Form
One-Liner Should Form
describe
‘clowns
site’
do
describe
port(80)
do
it
{
should
be_listening.with(‘tcp’)
}
end
end
161
162. Expect vs. Should
162
Debate on whether or not to use expect vs. should is
epic:
http://myronmars.to/n/dev-blog/2012/06/rspecs-new-
expectation-syntax
...and pointless. Use whatever makes the most sense
to you. There are some technical limitations to the
‘should’ form, but if you stick to the “one-liner should”
syntax, they are essentially interchangeable.
162
163. We use Expect Form
163
Because all the ChefSpec examples are in the expect
form
163
165. 165
Default location for tests
• By default, Test Kitchen will look in the test/
integration directory for test-related files
• For convenience, Test Kitchen creates this directory
when you run kitchen
init
165
167. 167
Suite subdirectory
• Test Kitchen requires a few more directories underneath
test/integration
• First directory name underneath test/integration should
match the suite name:
└──
test/
└──
integration/
└──
<suite_name>/
167
168. OPEN IN EDITOR: cookbooks/apache/.kitchen.yml
---
driver:
name: vagrant
provisioner:
name: chef_solo
platforms:
- name: centos-6.4
driver_config:
network:
- ["private_network", {ip: "33.33.33.10"}]
suites:
- name: default
run_list:
- recipe[apache::default]
attributes:
motd: {company: Chef}
Network configuration
168
Suite name
168
170. 170
Busser directory
• The next directory level denotes the test plugin, as
Test Kitchen many different kinds of test plugins. A test
plugin is called a busser. We’ll be using the busser
directory called serverspec.
└──
test/
└──
integration/
└──
default/
└──
serverspec/
170
171. 171
Hostname directory
• Serverspec supports testing via SSH, so it requires yet
another directory level to denote the hostname. We
won’t be using this capability, so it should be localhost
└──
test/
└──
integration/
└──
default/
└──
serverspec/
└──
localhost/
171
174. 174
*_spec.rb files
• By convention, Test Kitchen expects files with tests
to end in _spec.rb
174
175. Serverspec expectation form
• Every specialized RSpec-based testing library like
serverspec has their own special twist on the basic
RSpec expectation form
175
175
178. Serverspec commands & matchers
• Serverspec has provides a wide variety of matchers
for each command
• Serverspec commands are well-documented: http://
serverspec.org/resource_types.html
178
178
181. 181
Writing your first test
• Let’s create a serverspec test checking to make sure
the clowns web site is active on port 80
• Let’s use the port resource and the be_listening
matcher
181
182. Spec for clowns
182
require 'serverspec'
include Serverspec::Helper::Exec
describe 'clowns site' do
it 'responds on port 80' do
expect(port 80).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/clown_spec.rb
182
183. 183
kitchen setup
• Before running tests you need to run kitchen
setup
• kitchen
setup loads and configures the file
necessary to run test plugins on the node
• The component that manages Test Kitchen plugins
is called Busser
183
184. $ bundle exec kitchen setup default-centos-64
kitchen setup
-----> Starting Kitchen (v1.2.1)
-----> Setting up <default-centos-64>...
-----> Setting up Busser
Creating BUSSER_ROOT in /tmp/busser
Creating busser binstub
Plugin serverspec installed (version 0.2.6)
-----> Running postinstall for serverspec plugin
Finished setting up <default-centos-64> (0m13.03s).
-----> Kitchen is finished. (0m13.42s)
184
184
185. 185
kitchen verify
• The kitchen
verify command will run the tests in
your *_spec.rb files in the test/integration tree
185
186. $ bundle exec kitchen verify default-centos-64
kitchen verify
-----> Starting Kitchen (v1.2.1)
-----> Verifying <default-centos-64>...
Removing /tmp/busser/suites/serverspec
Uploading /tmp/busser/suites/serverspec/localhost/clown_spec.rb (mode=0644)
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/
embedded/bin/rspec /tmp/busser/suites/serverspec/localhost/clown_spec.rb --color --
format documentation
clowns site
responds on port 80
Finished in 0.02071 seconds
1 example, 0 failures
Finished verifying <default-centos-64> (0m1.17s).
-----> Kitchen is finished. (0m1.45s)
186
186
187. 187
Verifying that the tests work
• Did the test actually do anything? Let’s verify this
by changing the port to a known incorrect value.
187
188. Replace port 80 to 85
188
require 'serverspec'
include Serverspec::Helper::Exec
describe 'clowns site' do
it 'responds on port 85' do
expect(port 85).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/clown_spec.rb
188
189. $ bundle exec kitchen verify default-centos-64
This should fail
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/embedded/bin/rspec /tmp/
busser/suites/serverspec/localhost/clown_spec.rb --color --format documentation
clowns site
responds on port 80 (FAILED - 1)
Failures:
1) clowns site responds on port 80
Failure/Error: expect(port 85).to be_listening 'tcp'
netstat -tunl | grep -- :85
expected Port "85" to be listening "tcp"
# /tmp/busser/suites/serverspec/localhost/clown_spec.rb:7:in `block (2 levels) in <top
(required)>'
Finished in 0.005 seconds
1 example, 1 failure
...
189
189
190. $ bundle exec kitchen verify default-centos-64
This should fail
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/embedded/bin/rspec /tmp/
busser/suites/serverspec/localhost/clown_spec.rb --color --format documentation
clowns site
responds on port 80 (FAILED - 1)
Failures:
1) clowns site responds on port 80
Failure/Error: expect(port 85).to be_listening 'tcp'
netstat -tunl | grep -- :85
expected Port "85" to be listening "tcp"
# /tmp/busser/suites/serverspec/localhost/clown_spec.rb:7:in `block (2 levels) in <top
(required)>'
Finished in 0.005 seconds
1 example, 1 failure
...
190
WIN FAIL
190
191. 191
Back to success
• Remember to reset the tests back to the original port
value so they succeed again!
191
192. Reset back to port 80
192
require 'serverspec'
include Serverspec::Helper::Exec
describe 'clowns site' do
it 'responds on port 80' do
expect(port 80).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/clown_spec.rb
192
193. $ bundle exec kitchen verify default-centos-64
kitchen verify
-----> Starting Kitchen (v1.2.1)
-----> Verifying <default-centos-64>...
Removing /tmp/busser/suites/serverspec
Uploading /tmp/busser/suites/serverspec/localhost/clown_spec.rb (mode=0644)
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/
embedded/bin/rspec /tmp/busser/suites/serverspec/localhost/clown_spec.rb --color --
format documentation
clowns site
responds on port 80
Finished in 0.02071 seconds
1 example, 0 failures
Finished verifying <default-centos-64> (0m1.17s).
-----> Kitchen is finished. (0m1.45s)
193
193
195. Spec for bears
195
require 'serverspec'
include Serverspec::Helper::Exec
describe 'bears site' do
it 'responds on port 81' do
expect(port 81).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/bear_spec.rb
195
196. 196
No need to run kitchen setup
• You only need to run kitchen
setup once per
node. (Though it doesn’t hurt to run it more than
once).
196
197. $ bundle exec kitchen verify default-centos-64
...
----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/
embedded/bin/rspec /tmp/busser/suites/serverspec/localhost/bear_spec.rb /tmp/busser/
suites/serverspec/localhost/clown_spec.rb --color --format documentation
bears site
response on port 81
clowns site
responds on port 80
Finished in 0.00889 seconds
2 examples, 0 failures
...
197
197
198. 198
Code cleanup
• Common code can be moved to a file called
spec_helper.rb in test/integration/default/
serverspec
198
201. require spec_helper clowns
201
require 'spec_helper'
describe 'clowns site' do
it 'responds on port 80' do
expect(port 80).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/clown_spec.rb
201
202. require spec_helper bears
202
require 'spec_helper'
describe 'bears site' do
it 'responds on port 81' do
expect(port 81).to be_listening 'tcp'
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/bear_spec.rb
202
203. $ bundle exec kitchen verify default-centos-64
Testing clowns and bears w/spec_helper.rb
...
----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/
embedded/bin/rspec /tmp/busser/suites/serverspec/localhost/bear_spec.rb /tmp/busser/
suites/serverspec/localhost/clown_spec.rb --color --format documentation
bears site
response on port 81
clowns site
responds on port 80
Finished in 0.00889 seconds
2 examples, 0 failures
...
203
203
204. $ bundle exec kitchen verify default-centos-64
Testing clowns and beras
...
----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/
embedded/bin/rspec /tmp/busser/suites/serverspec/localhost/bear_spec.rb /tmp/busser/
suites/serverspec/localhost/clown_spec.rb --color --format documentation
bears site
response on port 81
clowns site
responds on port 80
Finished in 0.00889 seconds
2 examples, 0 failures
...
204
WIN
204
205. 205
Are the web sites really working?
• While we’ve added checks to verify that the test
node is listening on ports 80 and 81, we haven’t
verified that users see the right content when they
visit these sites.
• Let’s use the command resource with the
return_stdout matcher to do a simple check with
curl to verify that port 80 is clowns and port 81 is
bears.
205
207. Check clown content
207
require 'spec_helper'
describe 'clowns site' do
it 'responds on port 80' do
expect(port 80).to be_listening 'tcp'
end
it 'returns clowns in the HTML body' do
expect(command 'curl localhost:80').to
return_stdout(/clowns/)
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/clown_spec.rb
207
209. Check bear content
209
require 'spec_helper'
describe 'bears site' do
it 'responds on port 81' do
expect(port 81).to be_listening 'tcp'
end
it 'returns bears in the HTML body' do
expect(command 'curl localhost:81').to
return_stdout(/bears/)
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/bear_spec.rb
209
210. $ bundle exec kitchen verify default-centos-64
Testing for content
...
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/embedded/bin/rspec /tmp/busser/
suites/serverspec/localhost/bear_spec.rb /tmp/busser/suites/serverspec/localhost/clown_spec.rb --color --
format documentation
bears site
responds on port 81
returns bears in the HTML body
clowns site
responds on port 80
returns clowns in the HTML body
Finished in 0.0293 seconds
4 examples, 0 failures
Finished verifying <default-centos-64> (0m1.73s).
-----> Kitchen is finished. (0m1.79s)
...
210
WIN
210
211. 211
Detecting the target OS
• Many of the resources require that Serverspec
detect the OS so it can run the correct command for
your platform
expect(package
'httpd').to
be_installed
• You’ll need to add an extra Helper to spec_helper.rb
211
213. Check httpd package
213
require 'spec_helper'
describe 'server' do
it 'has apache installed' do
expect(package 'httpd').to be_installed
end
end
OPEN IN EDITOR:
apache/test/integration/default/serverspec/default_spec.rb
213
214. $ bundle exec kitchen verify default-centos-64
Testing for httpd
...
-----> Running serverspec test suite
/opt/chef/embedded/bin/ruby -I/tmp/busser/suites/serverspec -S /opt/chef/embedded/bin/rspec /tmp/busser/
suites/serverspec/localhost/bear_spec.rb /tmp/busser/suites/serverspec/localhost/clown_spec.rb --color --
format documentation
bears site
responds on port 81
returns bears in the HTML body
clowns site
responds on port 80
returns clowns in the HTML body
Finished in 0.0293 seconds
4 examples, 0 failures
Finished verifying <default-centos-64> (0m1.73s).
-----> Kitchen is finished. (0m1.79s)
...
214
WIN
214
215. 215
kitchen test
• The kitchen
test command will automate all the
previous actions you’ve learned so far into one command.
It runs the following commands in sequence:
• kitchen
destroy (if necessary)
•kitchen
create
•kitchen
converge
•kitchen
setup
•kitchen
verify
•kitchen
destroy
215
216. 216
kitchen test
• The kitchen
test command is intended to be used
as a final check on a fresh image before committing
changes to source control and/or to be used in a
Continuous Integration environment like Jenkins.
216
217. $ bundle exec kitchen test default-centos-64
kitchen test
-----> Starting Kitchen (v1.2.1)
-----> Cleaning up any prior instances of <default-centos-64>
-----> Destroying <default-centos-64>...
2c46b1a4609dc6a2beaf44e1134638b0a8ac47c9c5a02baee0bdb3df64e7bcdf
2c46b1a4609dc6a2beaf44e1134638b0a8ac47c9c5a02baee0bdb3df64e7bcdf
Finished destroying <default-centos-64> (0m0.60s).
-----> Testing <default-centos-64>
-----> Creating <default-centos-64>...
...
Finished in 0.0311 seconds
4 examples, 0 failures
Finished verifying <default-centos-64> (0m1.71s).
-----> Destroying <default-centos-64>...
d22a8c4db8505f89f7f7e65bca26492f58d5637f9a88763d5eb919d860dade4e
d22a8c4db8505f89f7f7e65bca26492f58d5637f9a88763d5eb919d860dade4e
Finished destroying <default-centos-64> (0m0.47s).
Finished testing <default-centos-64> (0m39.78s).
-----> Kitchen is finished. (0m39.84s)
217
217
218. Where to go next
• Jenkins cookbook is chock full of advanced
Serverspec techniques:
https://github.com/opscode-cookbooks/jenkins
218
218
219. Where to go next
• jenkins/test/shared/support contains
examples for implementing custom Serverspec
matchers used in jenkins/test/integration:
•describe
jenkins_job('my-‐project')
do
it
{
should
be_a_jenkins_job
}
end
219
219
220. Where to go next
• test/fixtures contains mini-cookbooks to
exercise resource providers
• Aliased in Berksfile:
•cookbook
'smoke',
path:
'test/fixtures/
cookbooks/smoke'
• Run via Rakefile
220
220
221. Where to go next
• Uses data/path directive in .kitchen.yml to share
test data between serverspec suites
• Directory specified in data/path is copied to /tmp/
kitchen/data on guest
• Reason for weird require_relative directive in tests
that use custom Serverspec matchers:
require_relative
'../../../kitchen/data/
spec_helper'
221
221
223. Better, Faster, Stronger
• Test Kitchen is an invaluable tool for managing
sandbox environments and truly verifying that a
cookbook produces the intended results
• But it does require spinning up an instance and
performing a full Chef converge, which can take a
long time
• Use Test Kitchen judiciously. The other tools can
provide more limited forms of feedback faster.
223
223
225. Feedback on Chef Coding Style
• Foodcritic provides feedback on your Chef coding
style
• It is designed to be used as you are writing Chef
code - how’s that for freaking fast!
• Written by Andrew Crump
http://acrmp.github.com/footcritic
225
225
226. Feedback on Chef Coding Style
• Let’s install Foodcritic on your development
workstation so you can give it a spin
• Add Foodcritic to your Gemfile
• Install the app with bundle
install
226
226
227. OPEN IN EDITOR: cookbooks/apache/Gemfile
source 'https://rubygems.org'
gem 'test-kitchen'
gem 'kitchen-vagrant'
gem 'serverspec', '~> 1.1'
gem 'foodcritic', '~> 3.0'
Add foodcritic to Gemfile
227
227
231. $ bundle exec foodcritic .
Run Foodcritic on your cookbook
231
FC003: Check whether you are running with chef
server before using server-specific features:
cookbooks/apache/recipes/ip-logger.rb:1
FC008: Generated cookbook metadata needs
updating: cookbooks/apache/metadata.rb:2
FC008: Generated cookbook metadata needs
updating: cookbooks/apache/metadata.rb:3
231
234. Feedback on Chef Coding Style
• Foodcritic comes with a set of checks called rules
• Foodcritic rules are documented at http://
acrmp.github.io/foodcritic/
• The default rules are a good start, and you can add
new rules of your own easily
234
234
240. OPEN IN EDITOR: cookbooks/apache/metadata.rb
name 'apache'
maintainer 'Mischa Taylor'
maintainer_email 'misheska@getchef.com'
license 'All rights reserved'
description 'Installs/Configures apache'
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version '0.2.0'
240
Addressing FC008
240
241. $ bundle exec foodcritic .
Rerun foodcritic
241
FC003: Check whether you are running
with chef server before using server-
specific features: ./recipes/ip-
logger.rb:1
241
243. FC003 - Check for chef server before using server-specific features
243
243
244. 244
Ignoring FC003
• Let’s say, for now, we don’t want to fix ip-‐
logger.rb, and we’d like to squelch the FC003
check
244
245. 245
--tags parameter
• The -‐-‐tags
<TAGS> parameter can be used to
specify a list of rules for foodcritic to use
•foodcritic
-‐-‐tags
FC001,FC002,FC008
• The tilde (~) modifier can be used to ignore specific
rules
•foodcritic
-‐-‐tags
~FC003
245
248. 248
Custom rules
• Etsy created some custom Foodcritic rules to check
for issues that caused production outages/
performance degradation.
• Good example for how to create your own custom
rules
• Documented here:
https://github.com/etsy/foodcritic-rules
248
249. Etsy Foodcritic Rules
• ETSY001 - Package or yum_package resource used
with :upgrade action
• ETSY002 - Execute resource used to run git commands
• ETSY003 - Execute resource used to run curl or wget commands
• ETSY004 - Execute resource defined without conditional or
action :nothing
• ETSY005 - Action :restart sent to a core service
• ETSY006 - Execute resource used to run chef-provided command
• ETSY007 - Package or yum_package resource used to install
core package without specific version number
249
249
251. 251
--include parameter
• The -‐-‐include
<PATH> parameter species
additional paths to load rules (shortened with -I)
251
252. $ bundle exec foodcritic -t ~FC003 -I ../../
foodcritic .
Including Custom Rules
ETSY005: Action :restart sent to a core
service: ./recipes/default.rb:19
ETSY005: Action :restart sent to a core
service: ./recipes/default.rb:32
ETSY007: Package or yum_package resource used to
install core package without specific version
number: ./recipes/default.rb:10
252
252
253. 253
Editor support
• Many popular editors can be configured to run
Foodcritic inside the editor (including Vim, GNU
Emacs and Sublime Text). So you can get feedback
even faster.
253
255. RuboCop - Feedback on Ruby Style
• Many people new to Ruby would like some guidance
on how to write idiomatic Ruby
• Get the same kind of feedback for Ruby using
RuboCop that you get for Chef Code using
Foodcritic (Chef code is Ruby)
255
255
257. RuboCop - Feedback on Ruby Style
• Follows community-driven style guide:
https://github.com/bbatsov/ruby-style-guide
• Looks at cookbooks for Ruby best practices, not the
Chef DSL - that’s Foodcritic
257
257
258. RuboCop - Feedback on Ruby Style
• Let’s install RuboCop on your development
workstation so you can give it a spin
• Add RuboCop to your Gemfile
• Install the app with bundle
install
258
258
259. OPEN IN EDITOR: cookbooks/apache/Gemfile
source 'https://rubygems.org'
gem 'test-kitchen'
gem 'kitchen-vagrant'
gem 'serverspec', '~> 1.1'
gem 'foodcritic', '~> 3.0'
gem 'rubocop', '~> 0.20'
Add rubocop to Gemfile
259
259
262. Running RuboCop
• Just run the rubocop command - it recursively
checks all the *.rb files in all subdirectories
underneath the current directory (excluding
vendor/)
262
262
263. $ bundle exec rubocop
Run RuboCop on your cookbook
attributes/default.rb:3:19: C: Prefer single-quoted strings when you don't
need string interpolation or special symbols.
default["apache"]["sites"]["bears"] = { "port" => 81 }
^^^^^^^
attributes/default.rb:3:28: C: Prefer single-quoted strings when you don't
need string interpolation or special symbols.
default["apache"]["sites"]["bears"] = { "port" => 81 }
^^^^^^^
attributes/default.rb:3:41: C: Prefer single-quoted strings when you don't
need string interpolation or special symbols.
default["apache"]["sites"]["bears"] = { "port" => 81 }
^^^^^^
7 files inspected, 52 offenses detected
263
263
264. rubocop-todo.yml via --auto-gen-config
• rubocop-todo.yml will help generate TODOs for each
item on the offense list
• It also shows you what config setting can be used to
mask each offense, which we’ll need to do for some
of these, because Chef code conventions vary
slightly from the Rubocop community standards
264
264
265. $ bundle exec rubocop --auto-gen-config
Generate rubocop-todo.yml
attributes/default.rb:3:28: C: Prefer single-quoted strings when you
don't need string interpolation or special symbols.
default["apache"]["sites"]["bears"] = { "port" => 81 }
^^^^^^^
attributes/default.rb:3:41: C: Prefer single-quoted strings when you
don't need string interpolation or special symbols.
default["apache"]["sites"]["bears"] = { "port" => 81 }
^^^^^^
7 files inspected, 52 offenses detected
Created rubocop-todo.yml.
Run `rubocop --config rubocop-todo.yml`, or
add inherit_from: rubocop-todo.yml in a .rubocop.yml file.
265
265
266. .rubocop.yml Configures RuboCop
• .rubocop.yml can be used to configure RuboCop
(similar to .kitchen.yml in Test Kitchen)
• We’ll add a settings to ignore things, similar to what
we did for Foodcritic, that don’t make as much sense
for Chef.
• Settings are documented in the RuboCop README:
https://github.com/bbatsov/rubocop/blob/master/
README.md
• Cop is the RuboCop equivalent of a rule
266
266
267. OPEN IN EDITOR: cookbooks/apache/.rubocop.yml
inherit_from:
rubocop-‐todo.yml
Include rubocop-todo.yml
267
267
268. $ bundle exec rubocop
Run RuboCop on your cookbook
Inspecting 7 files
.......
7 files inspected, no offenses detected
268
268
270. Match Chef community standards
• First, we’ll move some of the Cops from rubocop-
todo.yml to .rubocop.yml for things that match Chef
community standards (as opposed to the Ruby
community standards)
270
270
272. OPEN IN EDITOR: cookbooks/apache/.rubocop.yml
inherit_from:
rubocop-‐todo.yml
Encoding:
Enabled:
false
Chef does not (yet) support encoding comment
272
272
278. OPEN IN EDITOR: cookbooks/apache/.rubocop.yml
inherit_from:
rubocop-‐todo.yml
Encoding:
Enabled:
false
LineLength:
Max:
200
HashSyntax:
EnforcedStyle:
hash_rockets
StringLiterals:
Enabled:
false
Conflicts w/decision to relax FC002
278
278
279. $ bundle exec rubocop --auto-gen-config
Regenerate rubocop-todo.yml
metadata.rb:2:11: C: Put one space between the method name and the first argument.
maintainer 'Mischa Taylor'
^^^^^^^
metadata.rb:4:8: C: Put one space between the method name and the first argument.
license 'All rights reserved'
^^^^^^^^^^
metadata.rb:5:12: C: Put one space between the method name and the first argument.
description 'Installs/Configures apache'
^^^^^^
metadata.rb:7:8: C: Put one space between the method name and the first argument.
version '0.2.0'
^^^^^^^^^^
7 files inspected, 11 offenses detected
279
279
282. Trailing whitespace & Git
• Whitespace differences make diffs longer and
diverts focus from more important changes
• Even with Git, trailing whitespace can make merge
conflicts more difficult to resolve
282
282
283. 283
Editor support
• Many popular editors can be configured to run
RuboCop inside the editor (including Vim, GNU
Emacs and Sublime Text). So you can get feedback
even faster.
• RuboCop includes great docs on editor configuration
(which work for Foodcritic as well):
https://github.com/bbatsov/rubocop#editor-
integration
283
285. RECAP: Why Not Begin With Testing?
• Finding a bug in something that you can’t execute
is freaking hard!
• While fixing bugs before writing code is cheap,
finding them is expensive
285
285
286. What is ChefSpec?
• ChefSpec helps produce runnable documentation.
Its primary purpose is to help document and
organize your code.
• As a side effect, you’ll end up with a set of tests
which can also be used to uncover bugs when
changes are made.
• Plus, your cookbook code will be improved when it
is guided by tests.
286
286
288. ChefSpec - Runnable Documentation
• Let’s install ChefSpec on your development
workstation so you can give it a spin
• Add ChefSpec to your Gemfile
• Install the app with bundle
install
288
288
294. In-Memory Chef Run Form
294
require
‘chefspec’
describe
‘<recipe_name>’
do
chef_run
=
ChefSpec::Runner.new.converge(<recipe_name>)
<descriptions
here>
end
294
295. In-Memory Chef Run Example
295
require
‘chefspec’
describe
'apache::default'
do
chef_run
=
ChefSpec::Runner.new.converge('apache::default')
<descriptions
here>
end
295
298. Expectation Example
298
require
‘chefspec’
describe
'apache::default'
do
chef_run
=
ChefSpec::Runner.new.converge('apache::default')
it
‘installs
apache2’
do
expect(chef_run).to
install_package(‘httpd’)
end
end
298
299. Runnable Documentation
• expect statement does not actually perform the
httpd package installation
• It just verifies the cookbook syntax that it instructs
Chef to install the package
• Good enough for well-tested primitives like the
package resource
299
299
310. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
describe 'apache::default' do
chef_run = ChefSpec::Runner.new.converge('apache::default')
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
end
Test apache::default recipe
310
310
311. 311
Rspec runs ChefSpec
• There’s no separate chefspec command.
• Just run rspec to run ChefSpec tests.
311
312. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.0006 seconds
1 example, 0 failures
312
312
313. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
describe 'apache::default' do
chef_run = ChefSpec::Runner.new.converge('apache::default')
it 'installs apache2' do
expect(chef_run).to install_package('badhttpd')
end
end
Did it really check anything?
313
313
314. $ bundle exec rspec
Run ChefSpec on your cookbok
F
Failures:
1) apache::default installs apache2
Failure/Error: expect(chef_run).to install_package('badhttpd')
expected "package[badhttpd]" with action :install to be in Chef run. Other
package resources:
package[httpd]
# ./spec/default_spec.rb:7:in `block (2 levels) in <top (required)>'
Finished in 0.00044 seconds
1 example, 1 failure
314
314
315. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
describe 'apache::default' do
chef_run = ChefSpec::Runner.new.converge('apache::default')
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
end
Restore back to working
315
315
316. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.0006 seconds
1 example, 0 failures
316
316
317. Lazy evaluation with let
317
require 'chefspec'
describe 'apache::default' do
let(:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
end
Lazy evaluation
317
318. 318
described_recipe
• let blocks aren’t evaluated until the first time they
are called
• Also allows ChefSpec to run the described_recipe
macro to evaluate the recipe name
318
319. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
describe 'apache::default' do
let(:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
end
Lazy evaluation
319
319
320. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.0006 seconds
1 example, 0 failures
320
320
322. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
at_exit { ChefSpec::Coverage.report! }
describe 'apache::default' do
let (:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
end
Adding resource report
322
322
323. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.01106 seconds
1 example, 0 failures
ChefSpec Coverage report generated...
Total Resources: 9
Touched Resources: 1
Touch Coverage: 11.11%
Untouched Resources:
service[httpd] /recipes/default.rb:14
execute[mv /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.d/welcome.conf.disabled] /recipes/default.rb:19
template[/etc/httpd/conf.d/clowns.conf] /recipes/default.rb:32
directory[/srv/apache/clowns] /recipes/default.rb:43
template[/srv/apache/clowns/index.html] /recipes/default.rb:49
template[/etc/httpd/conf.d/bears.conf] /recipes/default.rb:32
directory[/srv/apache/bears] /recipes/default.rb:43
template[/srv/apache/bears/index.html] /recipes/default.rb:49
323
323
326. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
at_exit { ChefSpec::Coverage.report! }
describe 'apache::default' do
let(:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
...
it 'creates clowns.conf' do
expect(chef_run).to
create_file('/etc/httpd/conf.d/clowns.conf')
end
end
Checking clowns.conf files
326
326
327. $ bundle exec rspec --color
Run ChefSpec on your cookbok
F
Failures:
1) apache::default creates clowns.conf
Failure/Error: expect(chef_run).to create_file('/srv/apache/clowns')
expected "file[/srv/apache/clowns]" with action :create to be in Chef run. Other file resources:
# ./spec/default_spec.rb:13:in `block (2 levels) in <top (required)>'
Finished in 0.01903 seconds
2 examples, 1 failure
Failed examples:
rspec ./spec/default_spec.rb:12 # apache::default creates clowns.conf
327
327
328. $ bundle exec rspec --color
Run ChefSpec on your cookbok
F
Failures:
1) apache::default creates clowns.conf
Failure/Error: expect(chef_run).to create_file('/srv/apache/clowns')
expected "file[/srv/apache/clowns]" with action :create to be in Chef run. Other file resources:
# ./spec/default_spec.rb:13:in `block (2 levels) in <top (required)>'
Finished in 0.01903 seconds
2 examples, 1 failure
Failed examples:
rspec ./spec/default_spec.rb:12 # apache::default creates clowns.conf
328
FAIL
328
329. 329
ChefSpec == Runnable Documentation
• Remember: ChefSpec is just runnable
documentation
• It isn’t actually performing a Chef run to verify that
clowns.conf was created
• Instead it is just verifying that you told Chef to
create the clowns.conf via the file resource, which
you never did - you used the template resource
329
331. OPEN IN EDITOR: spec/default_spec.rb
require 'chefspec'
at_exit { ChefSpec::Coverage.report! }
describe 'apache::default' do
let(:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
...
it 'creates clowns.conf' do
expect(chef_run).to
create_template('/etc/httpd/conf.d/clowns.conf')
end
end
Checking clowns.conf file
331
331
332. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.01955 seconds
2 examples, 0 failures
332
332
333. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.01955 seconds
2 examples, 0 failures
333
WIN
333
335. OPEN IN EDITOR: spec/spec_helper.rb
require 'chefspec'
at_exit { ChefSpec::Coverage.report! }
Checking clowns.conf file
335
335
336. 336
RSpec recurses through spec/*
• RSpec recurses through the spec/ subtree, looking
for tests, so you can create any directory structure
you like underneath
• We’ll move default_spec.rb to spec/recipes
336
338. OPEN IN EDITOR: spec/recipes/default_spec.rb
require 'spec_helper'
describe 'apache::default' do
let (:chef_run)
{ ChefSpec::Runner.new.converge(described_recipe) }
it 'installs apache2' do
expect(chef_run).to install_package('httpd')
end
it 'creates clowns.conf' do
expect(chef_run).to
create_template('/etc/httpd/conf.d/clowns.conf')
end
end
Checking clowns.conf file
338
338
339. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.01955 seconds
2 examples, 0 failures
339
339
340. $ bundle exec rspec --color
Run ChefSpec on your cookbok
.
Finished in 0.01955 seconds
2 examples, 0 failures
340
WIN
340
341. 341
Where to go next
• There’s a lot of ChefSpec written for the community
cookbooks. Check out the spec/ directory your
favorites.
341
343. What is Guard?
• A tool that monitors for filesystem changes and
performs actions (like launching rake tasks)
• Written by Thibaud Guillaume-Gentil
343
343
344. Guard install
• Let’s install Guard on your development
workstation so you can give it a spin
• Add guard to your Gemfile
• Install the app with bundle
install
344
344
349. $ bundle exec guard init
Create Guardfile
02:39:58 - INFO - Writing new Guardfile to /home/vagrant/
chef-fundamentals-repo/cookbooks/apache/Guardfile
02:45:32 - INFO - rubocop guard added to Guardfile, feel
free to edit it
349
349
350. cookbooks/apache/Guardfile
350
# A sample Guardfile
# More info at https://github.com/guard/guard#readme
guard :rubocop do
watch(%r{.+.rb$})
watch(%r{(?:.+/)?.rubocop.yml$}) { |m| File.dirname(m[0]) }
end
350
351. $ bundle exec guard
Run Guard
02:48:54 - INFO - Guard is now watching at '/home/vagrant/
chef-fundamentals-repo/cookbooks/apache'
[1] guard(main)>
351
351
356. 356
Where to go next
Michael Goetz blog posts:
https://micgo.net/check-yo-self-before-you-wreck-yo-self-with-
foodcritic-chefspec/
Foodcritic and Guard:
Serverspec and Guard:
https://micgo.net/serverspec-guard-and-test-kitchen-testing-
servers-like-a-boss/
356
357. 357
Where to go next
Michael Goetz blog posts:
ChefSpec and Guard:
https://micgo.net/continuous-chefspec-validation-with-guard/
357
359. What is Rake?
• Rake includes a language for expressing the
command line steps needed to create an app
• Perfect for capturing all the commands you’ve
learned in this class so others can run them easily,
or in your continuous integration system (Jenkins,
Bamboo, TeamCity, etc.)
359
359
361. Rake - Repeatable Test Commands
• Let’s install Rake on your development workstation
so you can give it a spin
• Add rake to your Gemfile
• Install the app with bundle
install
361
361
370. Task Description
• Every task should have a description which
documents what the task does
• rake
-‐-‐tasks prints out tasks with descriptions
370
370
371. OPEN IN EDITOR: cookbooks/apache/Rakefile
desc 'Run Ruby style checks with Rubocop'
task :rubocop do
sh 'bundle exec rubocop'
end
Rubocop Task
371
371
372. $ bundle exec rake --tasks
Execute Rake Task
rake rubocop # Run Ruby style checks with Rubocop
372
372
374. OPEN IN EDITOR: cookbooks/apache/Rakefile
desc 'Run Ruby style checks with Rubocop'
task :rubocop do
sh 'bundle exec rubocop'
end
desc 'Run Chef style checks with Foodcritic'
task :foodcritic do
sh 'bundle exec foodcritic -t ~FC003 .'
end
Foodcritic Task
374
374
375. $ bundle exec rake foodcritic
Execute Rake Task
bundle exec foodcritic -t ~FC003 .
FC011: Missing README in markdown format: spec/README.md:1
FC031: Cookbook without metadata file: spec/metadata.rb:1
FC045: Consider setting cookbook name in metadata: spec/
metadata.rb:1
375
375
376. $ bundle exec rake foodcritic
Execute Rake Task
bundle exec foodcritic -t ~FC003 .
FC011: Missing README in markdown format: spec/README.md:1
FC031: Cookbook without metadata file: spec/metadata.rb:1
FC045: Consider setting cookbook name in metadata: spec/
metadata.rb:1
376
WAT?
376
377. Foodcritic 3.0.3 issue
• Foodcritic is checking spec/ subtree when it
shouldn’t
• Does not expose command line option to exclude
directories:
https://github.com/acrmp/foodcritic/issues/148
• When fixed, this should work:
bundle
exec
foodcritic
-‐X
spec
-‐t
~FC003
.
377
377
378. OPEN IN EDITOR: cookbooks/apache/Rakefile
desc 'Run Ruby style checks with Rubocop'
task :rubocop do
sh 'bundle exec rubocop'
end
require 'foodcritic'
desc 'Run Chef style checks with Foodcritic'
FoodCritic::Rake::LintTask.new(:foodcritic) do |t|
t.options = {
tags: ['~FC003'],
excludes: ['test', 'spec', 'features']
}
end
Workaround - Use Ruby
378
378
379. Default task
• Rake supports a special task name called default
• default runs when no parameters are supplied to
rake
• default (as well as any other task) can point to a
list of other task names to execute
task
:default
=>
[:foodcritic]
379
379
380. OPEN IN EDITOR: cookbooks/apache/Rakefile
task :default => [:rubocop, :foodcritic]
desc 'Run Ruby style checks with Rubocop'
task :rubocop do
sh 'bundle exec rubocop'
end
require 'foodcritic'
desc 'Run Chef style checks with Foodcritic'
FoodCritic::Rake::LintTask.new(:foodcritic) do |t|
t.options = {
tags: ['~FC003'],
excludes: ['test', 'spec', 'features' ]
}
end
Foodcritic Task
380
380
382. 382
Where to go next
Rake Boot Camp
http://cloud.github.com/downloads/jimweirich/RakePresentations/PowerRake.key.pdf
http://www.confreaks.com/videos/899-railsconf2012-basic-rake
Go to http://confreaks.com
Search for “Basic Rake”
382
383. 383
Where to go next
Rake Tasks can have tests
http://blog.jayfields.com/2006/11/ruby-testing-rake-tasks.html
383
385. What is Jenkins?
• Jenkins is a commonly used, open source
continuous integration system used to build early
and often
• Written by Kohsuke Kawaguchi
385
385
405. OPEN IN EDITOR: test-class-jenkins/recipes/default.rb
include_recipe 'jenkins::java'
include_recipe 'jenkins::master'
# Install version 1.13 of the greenballs plugin
jenkins_plugin 'greenballs' do
version '1.13'
end
Install greenballs plugin
405
405
406. $ bundle exec kitchen converge
Perform Chef run of Jenkins wrapper
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-centos-64>...
Step 0 : FROM centos:6.4
...
----> Converging <default-centos-64>...
Preparing files for transfer
Resolving cookbook dependencies with Berkshelf
3.0.0.rc1...
...
406
406