This document discusses common beginner mistakes or "antipatterns" when using Chef. It provides best practices for things like repository structure, cookbook structure, using environments and roles properly, planning data bags in advance, and utilizing tools like the Chef shell. Specific antipatterns called out include having one giant monolithic Git repo or cookbook, overloading environments, forking community cookbooks, putting run lists directly in roles, and not planning data bag structure. The document advocates for separating code into logical modules, using roles to define run lists indirectly, and taking advantage of tools like the Chef shell for development and debugging.
This document discusses Chef cookbook design patterns. It begins with an introduction to Chef and its terminology like cookbooks, recipes, resources, attributes, and run lists. It then covers different types of cookbooks like application cookbooks, library cookbooks, and community cookbooks. It also discusses using data bags versus attributes for configuration data and how to manage cookbook dependencies and run lists. The goal is to provide best practices for structuring Chef cookbooks to manage infrastructure as code.
Growing Pains with Chef – a Tale of DevOps in a Large OrganizationChef Software, Inc.
The triumphs, heartbreaks, and growing pains of embracing DevOps and deploying Chef in a large heterogenous organization while working to keep the lights on.
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.
This document provides steps for writing library cookbooks in Chef, including writing custom resources. It recommends:
1. Disregarding dogma like "unit tests first" and instead starting by making things up and working backwards.
2. Creating a cookbook skeleton and embedding a test cookbook to validate the resource.
3. Iterating by implementing the resource, adding tests and specs, and refactoring with confidence as the resource is developed.
It also provides tips for writing custom resources, such as being explicit, using markers for negative actions, leveraging load_current_value and converge_if_changed, and avoiding leaky abstractions by keeping resources minimal and splitting them as more
Automating your infrastructure with ChefJohn Ewart
This document provides an overview of how to automate infrastructure using Chef:
1. Chef is a tool that helps automate infrastructure management using code and recipes. It can provision, configure, deploy, and orchestrate systems.
2. Chef is used by many large companies and has a large community. It allows managing complex infrastructure on-premises or in the cloud through centralized configuration.
3. The document provides examples of how Chef can be used to provision servers, configure software, manage users/directories/databases, deploy code, and more through resources and recipes. It also discusses Chef concepts like nodes, roles, attributes, and environments.
This document discusses best practices for creating self-contained software releases using Berkshelf and Chef. It recommends packaging the software artifact, cookbook artifact, and documentation together. The cookbook artifact contains the cookbooks and dependencies locked to a specific version. Berkflow is introduced as a tool to install and upgrade environments using these packaged artifacts. Following these practices allows for portable, repeatable, and predictable automation.
This document provides an overview of Chef, a configuration management tool. It discusses how Chef works using a client-server model to configure nodes according to their run lists and roles. Cookbooks contain recipes that specify resources to configure nodes. Chef helps ensure consistency across environments like development, testing, and production.
When most people talk about automating infrastructure, they focus on things like consistency, scalability, and flexibility. While fine goals, we recently converted several projects to Chef for both systems AND application deployment, and found that, with a little work, these tools could also help you enable better software quality assurance, load modeling, and even improve resource allocation.
By sharing cookbooks across projects, we were able to standardize practices and eliminate arbitrary differences, while using parameterization to perfectly isolate the special needs of each project. This allowed us to transfer knowledge among staff much more quickly. Pulling in and parameterizing application state – database contents, website assets, uploaded content – allowed us to spin up new environments with as much or as little state as needed. Integrating with Vagrant and Jenkins, we were then able to use chef to treat the entire image – system and application – as a test fixture. As each engineer (ops or dev) has visibility into the whole stack, we can more easily move people between dev and ops, or between projects.
This document discusses Chef cookbook design patterns. It begins with an introduction to Chef and its terminology like cookbooks, recipes, resources, attributes, and run lists. It then covers different types of cookbooks like application cookbooks, library cookbooks, and community cookbooks. It also discusses using data bags versus attributes for configuration data and how to manage cookbook dependencies and run lists. The goal is to provide best practices for structuring Chef cookbooks to manage infrastructure as code.
Growing Pains with Chef – a Tale of DevOps in a Large OrganizationChef Software, Inc.
The triumphs, heartbreaks, and growing pains of embracing DevOps and deploying Chef in a large heterogenous organization while working to keep the lights on.
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.
This document provides steps for writing library cookbooks in Chef, including writing custom resources. It recommends:
1. Disregarding dogma like "unit tests first" and instead starting by making things up and working backwards.
2. Creating a cookbook skeleton and embedding a test cookbook to validate the resource.
3. Iterating by implementing the resource, adding tests and specs, and refactoring with confidence as the resource is developed.
It also provides tips for writing custom resources, such as being explicit, using markers for negative actions, leveraging load_current_value and converge_if_changed, and avoiding leaky abstractions by keeping resources minimal and splitting them as more
Automating your infrastructure with ChefJohn Ewart
This document provides an overview of how to automate infrastructure using Chef:
1. Chef is a tool that helps automate infrastructure management using code and recipes. It can provision, configure, deploy, and orchestrate systems.
2. Chef is used by many large companies and has a large community. It allows managing complex infrastructure on-premises or in the cloud through centralized configuration.
3. The document provides examples of how Chef can be used to provision servers, configure software, manage users/directories/databases, deploy code, and more through resources and recipes. It also discusses Chef concepts like nodes, roles, attributes, and environments.
This document discusses best practices for creating self-contained software releases using Berkshelf and Chef. It recommends packaging the software artifact, cookbook artifact, and documentation together. The cookbook artifact contains the cookbooks and dependencies locked to a specific version. Berkflow is introduced as a tool to install and upgrade environments using these packaged artifacts. Following these practices allows for portable, repeatable, and predictable automation.
This document provides an overview of Chef, a configuration management tool. It discusses how Chef works using a client-server model to configure nodes according to their run lists and roles. Cookbooks contain recipes that specify resources to configure nodes. Chef helps ensure consistency across environments like development, testing, and production.
When most people talk about automating infrastructure, they focus on things like consistency, scalability, and flexibility. While fine goals, we recently converted several projects to Chef for both systems AND application deployment, and found that, with a little work, these tools could also help you enable better software quality assurance, load modeling, and even improve resource allocation.
By sharing cookbooks across projects, we were able to standardize practices and eliminate arbitrary differences, while using parameterization to perfectly isolate the special needs of each project. This allowed us to transfer knowledge among staff much more quickly. Pulling in and parameterizing application state – database contents, website assets, uploaded content – allowed us to spin up new environments with as much or as little state as needed. Integrating with Vagrant and Jenkins, we were then able to use chef to treat the entire image – system and application – as a test fixture. As each engineer (ops or dev) has visibility into the whole stack, we can more easily move people between dev and ops, or between projects.
This document discusses the use of Chef, an open source configuration management tool, for server management. It notes that Chef allows for repeatable system provisioning and ease of scaling servers without vendor lock-in. Chef manages over 120 servers across 10 environments for the company discussed. Chef uses Ruby code and resources like packages, templates and services to configure and maintain server configurations. It works both on single servers via chef-solo and with a centralized chef-server for cluster management. Common resources, attributes, definitions and recipes are discussed as the basic building blocks for automation with Chef. Gotchas around idempotency, package sources and attribute abuse are also covered.
This document discusses using Chef configuration management with Docker containers. It begins with examples of incrementally building a Docker tutorial using Chef, starting with a "hello world" container and moving on to more advanced containers for an echo server and web application. It then discusses using the kitchen-dokken plugin to test Chef recipes using Docker instead of virtual machines. The examples demonstrate how to version and tag releases as new features and patches are added.
This document provides an introduction to a Chef Jumpstart session. It includes details about the instructor Kimball Johnson and expectations for what attendees will learn. Attendees are asked to introduce themselves and spend 15 minutes getting to know each other. The document then provides an overview of what Chef is, including its core components, architecture, tools, and basic troubleshooting methods.
This document discusses using Jenkins as a continuous integration server for Chef cookbooks. It covers installing and configuring Jenkins and plugins to run Foodcritic, Chefspec, Test Kitchen, and publish cookbooks and artifacts. Pipelines are created using the Build Pipeline and Job DSL plugins to test and promote cookbook releases through different environments. While configuration sometimes requires XML, Jenkins is mature, extensible, and can immediately provide value by catching problems early and keeping infrastructure automated and consistent.
Chef is an open-source configuration management and automation tool. It allows users to define infrastructure through recipes organized into cookbooks. Recipes contain resources that describe how to configure systems. Chef runs use recipes and attributes to test systems and repair any deviations from the defined state. Attributes provide details about nodes and can be used to customize configurations. Ohai detects node attributes which are provided to Chef runs. Cookbooks contain recipes, attributes, files and other components to define common scenarios. Node attributes can be defined in cookbooks and overridden to customize configurations for different environments.
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.
Jonathan Weiss presented on infrastructure automation using the configuration management tool Chef. Chef uses Ruby scripts called cookbooks and recipes to configure and provision servers. It can configure multiple servers from a single definition file. Chef supports common infrastructure resources like packages, files, templates and services. It enforces best practices of infrastructure as code and makes deployment repeatable and automated through all environment stages.
This document provides an overview of configuration management with Chef. It discusses how Chef uses resources like files, packages, and services to define the desired state of nodes. It also covers how attributes, templates, search, and notifications allow flexible configuration and automation. Chef manages infrastructure as code through recipes that define policies declaratively using resources.
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 4: The Chef Client Run and Expanding...Chef Software, Inc.
This document provides an overview of the Chef Fundamentals webinar series module 4. It discusses fixing out of date apt caches using an apt cookbook with an execute resource. It also summarizes the objectives of describing the steps of a chef-client run and the basic security model of Chef. Finally, it covers the node object in Chef including listing, showing details of, and retrieving attributes of nodes directly and via search.
At Ninefold we've spent 3+ years with Chef. We've built a PaaS with Chef and we manage our internal systems with it.
In this presentation we explore the design decisions we needed to make in order to build the platform. It highlights the things we've learned along the way that weren't exactly obvious when we started.
This document discusses setting up a continuous delivery pipeline for Symfony2 projects using Jenkins and Chef. It describes configuring Jenkins to run unit and acceptance tests on code commits and merges. It also covers using Chef to automate infrastructure configuration and deploying builds from Jenkins to servers managed by Chef. The pipeline allows for rapid, reliable, and continuous development and delivery of software.
Learn how in less than 6 months and with a 1-person team, they went from no infrastructure automation, to having all of their infrastructure automated with Ansible. Learn how BigPanda (http://bigpanda.io ) handles zero-downtime infrastructure updates and connects Ansible with their chat infrastructure, and some strategies on managing automation projects with very small teams.
Chef is an infrastructure automation tool that allows users to define and maintain server configurations. It uses recipes, resources, cookbooks and roles to provision and configure servers. Chef works by installing a Chef client on nodes that runs recipes to configure the node according to cookbooks. The Chef server stores cookbooks and node data. Users can write recipes in Ruby syntax to define what configuration should be applied to nodes.
This document discusses using Chef with AWS. It provides an overview of key points on Chef including its execution methods and use of Chef Server for bootstrapping nodes. It describes using Chef for continuous delivery processes on AWS and outlines architectures for high availability Chef implementations on AWS. The document concludes with links to additional Chef resources and a demo of dependency management with Chef Server on AWS.
Environments - Fundamentals Webinar Series Week 5Chef
This document outlines an upcoming six-week webinar series on Chef fundamentals. The topics to be covered include node setup, roles, environments, cookbook version constraints, and using data bags for common configuration. Participants are encouraged to ask questions during the webinars or in the associated discussion group. Recordings and slides from each session will be made available online after the event.
This document discusses the server configuration management tool Chef. It begins by outlining problems with manual system administration and explains that Chef allows for repeatable, version controlled configurations through recipes defined in Ruby. It then describes Chef's client-server architecture and its embrace of modern web technologies. The remainder of the document outlines Chef's components like nodes, attributes, cookbooks and resources and concludes with a link to a demo.
Opscode Webinar: Managing Your VMware Infrastructure with ChefChef Software, Inc.
This document provides an overview of how Chef can be used to manage VMware infrastructure. It discusses four main integration points: 1) VMware Fusion/Workstation and Vagrant to provision development VMs locally, 2) knife-esx to manage individual ESXi hosts, 3) knife-vsphere to manage vCenter and provision/configure VMs, and 4) knife-vcloud to manage vCloud Director and deploy vApps. The document emphasizes that Chef allows infrastructure to be defined as code through recipes and cookbooks rather than using VM templates, making infrastructure more flexible and standardized. It concludes with a demo of Vagrant/Fusion and knife-vsphere.
An Introduction to Shef, the Chef ShellJulian Dunn
Shef is a Chef shell that allows users to interact with Chef in a Ruby environment for tasks like quick prototyping, syntax checking, debugging recipes, and exploring the Chef server. It has three modes: standalone, solo, and client. The document demonstrates how Shef can be used to search nodes, step through recipes, set breakpoints, and help debug issues on production systems. However, it notes some limitations like not being able to modify the run list or have attribute changes propagate.
Jamie Winsor and a team of engineers created Berkshelf to help take the sting out of Chef’s learning curve. After encountering numerous challenges while developing Chef cookbooks, Jamie was inspired to create a tool based on criteria that’d be important for a developer’s productivity. Berkshelf, like Rebar, Go, or Mix, is a source code management tool.
This document discusses the use of Chef, an open source configuration management tool, for server management. It notes that Chef allows for repeatable system provisioning and ease of scaling servers without vendor lock-in. Chef manages over 120 servers across 10 environments for the company discussed. Chef uses Ruby code and resources like packages, templates and services to configure and maintain server configurations. It works both on single servers via chef-solo and with a centralized chef-server for cluster management. Common resources, attributes, definitions and recipes are discussed as the basic building blocks for automation with Chef. Gotchas around idempotency, package sources and attribute abuse are also covered.
This document discusses using Chef configuration management with Docker containers. It begins with examples of incrementally building a Docker tutorial using Chef, starting with a "hello world" container and moving on to more advanced containers for an echo server and web application. It then discusses using the kitchen-dokken plugin to test Chef recipes using Docker instead of virtual machines. The examples demonstrate how to version and tag releases as new features and patches are added.
This document provides an introduction to a Chef Jumpstart session. It includes details about the instructor Kimball Johnson and expectations for what attendees will learn. Attendees are asked to introduce themselves and spend 15 minutes getting to know each other. The document then provides an overview of what Chef is, including its core components, architecture, tools, and basic troubleshooting methods.
This document discusses using Jenkins as a continuous integration server for Chef cookbooks. It covers installing and configuring Jenkins and plugins to run Foodcritic, Chefspec, Test Kitchen, and publish cookbooks and artifacts. Pipelines are created using the Build Pipeline and Job DSL plugins to test and promote cookbook releases through different environments. While configuration sometimes requires XML, Jenkins is mature, extensible, and can immediately provide value by catching problems early and keeping infrastructure automated and consistent.
Chef is an open-source configuration management and automation tool. It allows users to define infrastructure through recipes organized into cookbooks. Recipes contain resources that describe how to configure systems. Chef runs use recipes and attributes to test systems and repair any deviations from the defined state. Attributes provide details about nodes and can be used to customize configurations. Ohai detects node attributes which are provided to Chef runs. Cookbooks contain recipes, attributes, files and other components to define common scenarios. Node attributes can be defined in cookbooks and overridden to customize configurations for different environments.
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.
Jonathan Weiss presented on infrastructure automation using the configuration management tool Chef. Chef uses Ruby scripts called cookbooks and recipes to configure and provision servers. It can configure multiple servers from a single definition file. Chef supports common infrastructure resources like packages, files, templates and services. It enforces best practices of infrastructure as code and makes deployment repeatable and automated through all environment stages.
This document provides an overview of configuration management with Chef. It discusses how Chef uses resources like files, packages, and services to define the desired state of nodes. It also covers how attributes, templates, search, and notifications allow flexible configuration and automation. Chef manages infrastructure as code through recipes that define policies declaratively using resources.
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 4: The Chef Client Run and Expanding...Chef Software, Inc.
This document provides an overview of the Chef Fundamentals webinar series module 4. It discusses fixing out of date apt caches using an apt cookbook with an execute resource. It also summarizes the objectives of describing the steps of a chef-client run and the basic security model of Chef. Finally, it covers the node object in Chef including listing, showing details of, and retrieving attributes of nodes directly and via search.
At Ninefold we've spent 3+ years with Chef. We've built a PaaS with Chef and we manage our internal systems with it.
In this presentation we explore the design decisions we needed to make in order to build the platform. It highlights the things we've learned along the way that weren't exactly obvious when we started.
This document discusses setting up a continuous delivery pipeline for Symfony2 projects using Jenkins and Chef. It describes configuring Jenkins to run unit and acceptance tests on code commits and merges. It also covers using Chef to automate infrastructure configuration and deploying builds from Jenkins to servers managed by Chef. The pipeline allows for rapid, reliable, and continuous development and delivery of software.
Learn how in less than 6 months and with a 1-person team, they went from no infrastructure automation, to having all of their infrastructure automated with Ansible. Learn how BigPanda (http://bigpanda.io ) handles zero-downtime infrastructure updates and connects Ansible with their chat infrastructure, and some strategies on managing automation projects with very small teams.
Chef is an infrastructure automation tool that allows users to define and maintain server configurations. It uses recipes, resources, cookbooks and roles to provision and configure servers. Chef works by installing a Chef client on nodes that runs recipes to configure the node according to cookbooks. The Chef server stores cookbooks and node data. Users can write recipes in Ruby syntax to define what configuration should be applied to nodes.
This document discusses using Chef with AWS. It provides an overview of key points on Chef including its execution methods and use of Chef Server for bootstrapping nodes. It describes using Chef for continuous delivery processes on AWS and outlines architectures for high availability Chef implementations on AWS. The document concludes with links to additional Chef resources and a demo of dependency management with Chef Server on AWS.
Environments - Fundamentals Webinar Series Week 5Chef
This document outlines an upcoming six-week webinar series on Chef fundamentals. The topics to be covered include node setup, roles, environments, cookbook version constraints, and using data bags for common configuration. Participants are encouraged to ask questions during the webinars or in the associated discussion group. Recordings and slides from each session will be made available online after the event.
This document discusses the server configuration management tool Chef. It begins by outlining problems with manual system administration and explains that Chef allows for repeatable, version controlled configurations through recipes defined in Ruby. It then describes Chef's client-server architecture and its embrace of modern web technologies. The remainder of the document outlines Chef's components like nodes, attributes, cookbooks and resources and concludes with a link to a demo.
Opscode Webinar: Managing Your VMware Infrastructure with ChefChef Software, Inc.
This document provides an overview of how Chef can be used to manage VMware infrastructure. It discusses four main integration points: 1) VMware Fusion/Workstation and Vagrant to provision development VMs locally, 2) knife-esx to manage individual ESXi hosts, 3) knife-vsphere to manage vCenter and provision/configure VMs, and 4) knife-vcloud to manage vCloud Director and deploy vApps. The document emphasizes that Chef allows infrastructure to be defined as code through recipes and cookbooks rather than using VM templates, making infrastructure more flexible and standardized. It concludes with a demo of Vagrant/Fusion and knife-vsphere.
An Introduction to Shef, the Chef ShellJulian Dunn
Shef is a Chef shell that allows users to interact with Chef in a Ruby environment for tasks like quick prototyping, syntax checking, debugging recipes, and exploring the Chef server. It has three modes: standalone, solo, and client. The document demonstrates how Shef can be used to search nodes, step through recipes, set breakpoints, and help debug issues on production systems. However, it notes some limitations like not being able to modify the run list or have attribute changes propagate.
Jamie Winsor and a team of engineers created Berkshelf to help take the sting out of Chef’s learning curve. After encountering numerous challenges while developing Chef cookbooks, Jamie was inspired to create a tool based on criteria that’d be important for a developer’s productivity. Berkshelf, like Rebar, Go, or Mix, is a source code management tool.
Chef is awesome, but it’s also very easy to go overboard. In terms of testing and maintainability, sometimes its better to refactor your long recipe into an LWRP. As your infrastructure evolves, so should you cookbooks. But at some point your bound to have a cookbook 500+ lines of antiquated logic. How do you refactor such a large chunk of code that is critical to your infrastructure? How much logic should me moved into other cookbooks? How much logic should be extracted into LWRPs? How much logic should be moved out of Chef, into Ruby, and packaged as a gem?
Are you the only one working on your Chef configuration? I was. Then within six weeks my client quadrupled the staff working with Chef. Okay, they just hired three people but that was still disruptive.
We had to learn how to work together in the same repo. While I knew all the 'best practices' around testing and deploying cookbooks it wasn't as critical when I was the only one committing changes. Suddenly I needed a better plan.
Implementing the community practices would only get me so far. I needed to help this team of diverse skill levels manage their work AND their Chef repository. I needed to highlight to my customer when we were processing interrupts at the expense of scheduled work. I needed to make sure the work was small enough that no one disappeared down a rabbit hole for days on end, but still met the needs of the rest of the organization.
I needed Kanban.
In this talk I will walk through my experiences, painful and glorious, building a team and managing their work. I will cover the good, the bad, and the ugly of a deadline crunched, pre-launch operations team and what we did to bring sanity, from discovering the real flow of work to documenting interruptions, and how we used (and misused) Chef throughout.
1. The document discusses how globalization and the internet have led to a shift where software and technology now directly support customer interactions and digital consumption, rather than just internal business functions.
2. This shift requires businesses to be able to continuously and rapidly deliver new features and fixes to applications in order to improve the customer experience.
3. Successful companies navigating this transition embrace cultural traits like empowering teams, treating failures as learning opportunities, and making decisions based on data rather than arguments. They also take a holistic view of their technology to support new workflows.
This document provides an overview of Opscode and how it uses Chef to help businesses create a "coded business" through technology automation. It discusses how Chef can be used for configuration management, cloud management, and continuous delivery to enable business agility, increase development velocity and consistency, and automate infrastructure. Chef provides a common platform and reusable code/cookbooks to help manage increasing IT complexity as businesses move to cloud-based models.
Automation for Education discusses how automation can help educational institutions manage increasingly complex IT infrastructure with smaller staff sizes. Chef is presented as a tool to help with automation of server configuration, management of public and private clouds, and continuous delivery. Case studies show how universities like Wharton, Marshall, and Minnesota have used Chef to reduce management time and empower their IT staff to take on new projects.
The document discusses safe food handling practices including cleaning, separating, cooking, and chilling foods properly. It emphasizes the importance of cleaning all surfaces, utensils and hands with disinfectant soap. Foods should be separated when storing - keeping raw meats away from other foods. Cooking foods to the proper internal temperatures kills bacteria. Refrigerating and freezing foods at the correct temperatures prevents bacterial growth.
Ab(Using) the MetaCPAN API for Fun and Profit v2013Olaf Alders
This talk builds on the previous Ab(Using) the MetaCPAN API talk from 2012. There are links to comprehensive examples and there is a more in-depth look at the available endpoints.
Feature Flagging your Infrastructure for Fun and ProfitDaniel Schauenberg
At Etsy we run our production stack exclusively on physical hardware and have (including developer and CI VMs) about 1000 nodes managed with a single Chef server running the same cookbooks across development and production nodes. We have built the knife-spork plugin to support our workflow and have 30 engineers making changes about 20 times a day. While this setup keeps configuration changes and package installations consistent across our network, it makes it harder to gradually roll out and test changes on a per node or role basis. In the talk our general workflow will be introduced and explained and how we enable engineers to frequently roll out small changes. Following the general introduction, our workflow for testing changes will be discussed and the library we wrote to enable config flags and gradual roll outs for our infrastructure within our chef recipes.
David Chen presents techniques for optimizing performance on Google App Engine. He discusses analyzing logs to identify inefficient requests and using AppStat to profile RPC calls. Key optimizations include batching and async RPCs, caching results, optimizing datastore usage by reducing indexes and entity size, and hosting dynamic content statically. Server-side caching and tasks are also recommended to improve control flow efficiency.
eSynergy Andy Hawkins - Enabling DevOps through next generation configuration...PatrickCrompton
The document discusses configuration management challenges and how Chef addresses them. It describes how Chef uses recipes, cookbooks and infrastructure as code to automate provisioning and configuration of systems and applications. This allows infrastructure to be easily built, managed and scaled. Complex environments that were previously difficult to manage can now be defined and updated via code.
Chef Cookbook Testing and Continuous IntegrationJulian Dunn
The document discusses tools and best practices for testing Chef cookbooks, including:
- Using ChefSpec for unit testing recipes by making assertions about resources added during a simulated Chef run. Each recipe should have its own test file.
- Using the Chef MiniTest handler and Minitest framework for acceptance testing by writing tests that are executed on nodes after a Chef client run.
- Leveraging Vagrant and Berkshelf to define virtual machines for testing and manage cookbook dependencies, allowing for rapid iteration of tests against a virtualized environment.
The document discusses configuration management tools for software development. It describes Chef, an open-source configuration management tool written in Ruby. Chef can be run on a Chef Server with multiple Chef Clients or in solo mode on a single system. Chef uses cookbooks containing recipes written in Ruby to configure and manage server resources. Recipes define actions and use templates to configure systems. A run list specifies the order of recipes to execute on a system. The document provides instructions for installing Chef and initial bootstrap of a node to begin configuration management.
WordCamp Milwaukee 2012 - Contributing to Open Sourcejclermont
The document discusses contributing to open source projects. There are both altruistic and selfish reasons to contribute including giving back to communities, improving one's own skills, and boosting one's resume. Contributions are not limited to code and include tasks like documentation, translation, testing, and reporting bugs. Getting started involves working on projects of personal interest, following coding standards, understanding communities, and communicating through mailing lists and forums. The document encourages beginning with small contributions and provides helpful links for getting involved in open source.
Become Master of Your Own Universe - DIBI 2013Phil Sturgeon
Being a developer for years its very easy to get type-cast. You become "The CodeIgniter Guy", the one dev in the office that knows how FooCMS works or just end up farming out CRUD day after day. Well I decided to say "nope" to that & accepted a job where I'd need to know how to do…everything.
This talk aims to give you an overview of what you should be looking to learn next if you want to stop being "just a developer" & move into the devops/architecture arena.
Twitter Bootstrap, or why being a PHP Developer is a bad ideaJason Lotito
The document discusses Twitter Bootstrap, an open-source front-end web development framework. It begins with an introduction to Bootstrap, explaining that it is a front-end framework made up of HTML, CSS, and JavaScript that makes web design and development easy. It then provides examples of basic HTML templates using Bootstrap and demonstrates how to easily create common front-end elements like navigation bars, headers and columns. The document suggests that Bootstrap provides pre-built styles and components that simplify the process of building responsive and mobile-first websites.
This document discusses scaling a web application, particularly those built with PHP and MySQL. It begins with introductions and then outlines various strategies for scaling applications and databases. For applications, it recommends profiling code and queries to identify bottlenecks, optimizing frameworks, caching, and monitoring. For databases, it suggests technologies like Memcached, database replication using master-slave, sharding, MySQL Cluster, and storage engines. The overall message is that scaling requires understanding applications and systems, identifying pain points, and having a plan to optimize performance as needs grow.
Cook Up a Runtime with The New OSGi Resolver - Neil Bartlettmfrancis
OSGi DevCon 2013
OSGi applications are assembled from loosely coupled bundles communicating via services. While this model provides huge flexibility and the ability to reuse components, it creates a challenge for the assembler of the application since it is unclear which bundles are needed, which are optional and which are unnecessary.
For example some dependencies are implicit, such as the provider of a service or an extender. We do not want to prematurely lock down these dependencies at build time, but at deployment time a specific provider must be found otherwise the application will fail to behave as expected. Furthermore when third-party libraries are used they often contain static dependencies on additional libraries, which in turn contain additional dependencies, and so on. Much time is wasted in finding a set of bundles that will actually resolve and run in the OSGi environment, and once such a set is found, developers tend to fear making changes to it.
The generic requirements and capabilities model introduced in OSGi Release 4.3, along with the standard Repository and Resolver specifications introduced in OSGi Release 5, provide answers for both of these problems. Using capabilities, we can describe dependencies in an abstract way without prematurely binding to specific providers. Using the resolver, we can narrow our focus to the very small set of bundles that describe our application at the top level, and allow all other dependencies to be computed and managed for us.
This talk begins with a brief technical overview of the new 4.3 and 5.0 specifications and how they can be used to assemble applications with ease. We then demonstrate both development tooling and a runtime platform that can be used to put these ideas into practice.
Cookbook Reusability @ Chef Community summit 2014Sean OMeara
This document summarizes Sean O'Meara's talk at the 2014 Chef Community Summit. Some key points include:
- Cookbook reusability has improved over time with tools like Test Kitchen, Berkshelf, and ChefSpec enabling better testing.
- Attributes are often misused when variables or methods would be better, and internal state should be avoided. Resources and their parameters are preferred.
- Test coverage is important but tedious; full coverage is worth pursuing. Configuration files are key so manage minimal config and let users configure further.
- Cross-platform cookbooks are challenging but possible using platform-specific resource providers in a subclass. Prioritize understandability even if some duplication occurs between
The document discusses Cucumber, a behavior-driven development (BDD) framework that uses natural language to describe features and scenarios. It outlines some key benefits of Cucumber, including encouraging BDD/TDD practices, supporting multiple test drivers and languages. It also notes some potential downsides, such as slower performance and messy directory structures. In conclusion, while Cucumber has advantages for involving whole teams, it is not necessarily suitable for all projects.
Selenium and Cucumber Selenium Conf 2011dimakovalenko
The document discusses Cucumber, a behavior-driven development (BDD) framework that helps with test-driven development (TDD). It outlines some key features of Cucumber, including that it encourages BDD and TDD practices, supports multiple test drivers and languages, and produces readable test results. It also notes some potential downsides, such as that regex step definitions can be hard to find and the natural language parsing can be slower.
This document discusses building agile analytics applications. It recommends taking an iterative approach where data is explored interactively from the start to discover insights. Rather than designing insights upfront, the goal is to build an application that facilitates exploration of the data to uncover insights. This is done by setting up an environment where insights can be repeatedly produced and shared with the team. The focus is on using simple, flexible tools that work from small local data to large datasets.
API Simplicity == Speed; Designing APIs That are Easy and Fun to UseHarold Madsen
This hands-on presentation teaches participants how to design APIs that are simple and consistent to use. If your API is easy to use then it will be more likely to be adopted and will speed product delivery.
This presentation will be given at BYU during the FamilySearch Developers Conference 2014
A presentation I did with @lgladdy back in June 2012 for BathCamp (http://bathcamp.org/events/cms-smackdown).
Before you start commenting like a crazy-assed loon, please remember the title is entirely designed to provoke. Like anything else in this entire universe, I'm long enough in the tooth to know this: "IT DEPENDS".
So: No. I don't think Wordpress shits on all CMS's in every situation*
Peace, out
x
* Just most of them **
** kidding
This document provides information on contributing to the Ruby on Rails framework. It discusses why developers should contribute (e.g. giving back to an open source project they use), what types of contributions are needed (e.g. fixing bugs, writing documentation), and how to get started (e.g. setting up their development environment, downloading the Rails source code, and running tests). The document also lists some specific contribution tasks and resources for learning more about the contribution process.
Similar to ChefConf 2013: Beginner Chef Antipatterns (20)
In this talk, I riff on various jobs you can do with your DevOps knowledge that aren't more of the same (or moving into software engineering). These include sales engineering, consulting, product management, product marketing, and more.
Pull, Don't Push! Sensu Summit 2018 TalkJulian Dunn
Architectures for monitoring and configuration in a microservices era. A talk given by Julian Dunn and Fletcher Nichol at Sensu Summit 2018 in Portland, Oregon.
Now That I Have Choreography, What Do I Do With It?Julian Dunn
This document discusses challenges with orchestration and how the Habitat system addresses them through a distributed, self-managing approach. It outlines how Habitat provides resilience through a supervisor backplane that maintains global state. Services running under Habitat are delegated resilience and can elect leaders independently. Habitat also allows dynamic configuration changes and rolling updates in a leaderless way through interaction with the supervisor network.
Distributed systems are hard; distributed systems of people are harderJulian Dunn
This document discusses challenges of managing distributed teams and provides recommendations. It notes that distributed systems of people are harder than distributed systems alone. It emphasizes the need for shared alignment on strategy and goals, as well as cultural support for autonomy through high trust, transparency, and outcome-focused work. The document also recommends careful selection and usage of collaboration tools to support remote work without replacing the need to establish healthy cultural norms.
Orchestration? You Don't Need Orchestration. What You Want is Choreography.Julian Dunn
This document discusses the differences between orchestration and choreography in configuration management. Orchestration involves a central orchestrator executing ordered operations on independent machines, while choreography involves autonomous actors that make and verify promises to each other to achieve a desired state. The document argues that choreography is preferable because it avoids single points of failure, enables more autonomy between systems, and allows for better coordination across a fleet with less reliance on external real-time state systems.
Chef provides automation capabilities for AIX systems. There were technical challenges in porting Chef to AIX due to differences from Linux like a proprietary compiler and two init systems. Core Chef resources work on AIX with some platform-specific resources in an AIX cookbook. The community has contributed resources to the AIX cookbook and improved Ohai data collection. Future work includes support for other Power platforms and Chef Server on Power. Resources were provided for learning more about automating AIX with Chef.
Configuration Management in a Containerized WorldJulian Dunn
This document discusses configuration management in a containerized world. It provides an overview of Docker's success due to instant productivity, development resembling shipping, and portable artifacts. It then outlines the build, test, ship, and run phases for container management and discusses using tools like Chef to build containers from cookbooks. Lastly, it touches on fleet management across machines using tags and recipes to deploy MySQL and WordPress containers.
Cooking with Chef on Windows: 2015 EditionJulian Dunn
This document discusses using Chef to automate configuration on Windows systems. Key points include:
- ChefDK and Test Kitchen now support testing Chef code on Windows guests.
- Desired State Configuration (DSC) brings a standard declarative language to Windows automation that Chef code can interface with.
- Chef resources continue to improve support for Windows including the new windows_package and reboot resources in 2015.
The document announces the release of ChefDK 0.2.0 which now includes Windows support and tools like ChefSpec, Rubocop, and Foodcritic. It also announces the release of prototypes for Chef integration with PowerShell DSC and new support for Docker containers using Chef recipes instead of Dockerfiles. Finally, it discusses improvements to the Chef community site including replacing community.opscode.com with Supermarket and opening sourcing parts of Supermarket.
Chef NYC Users' Group - Announcements for June 2014Julian Dunn
The document announces the availability of the Chef Development Kit for writing and testing Chef recipes on Mac and Linux as well as its alpha version for Windows. It notes that GitHub will now host issues for Chef, Ohai, and Mixlib projects instead of JIRA and that Curry will flag PRs that don't have a signed CLA. The community site Supermarket is introduced which will replace cookbooks.opscode.com and use 'knife supermarket' commands. Supermarket may also be installed internally and all users must resigh CLAs. Research on containers and Docker is mentioned across several GitHub projects.
This document provides an overview of various productivity tools and shortcuts for the Mac operating system. It discusses global keyboard shortcuts in Mac, using the command line interface, learning basic command line commands, using the third-party terminal emulator iTerm2, useful Mac-specific functions and file system locations, the productivity application Alfred and its powerful features, the additional Alfred PowerPack functionality, and the offline documentation browser Dash.
Chef Cookbook Governance BoF at ChefConfJulian Dunn
The document discusses governance topics for software cookbooks including namespace squatting, rapidly evolving testing ecosystems, namespacing, maintainer responsibilities, quality metrics, how and where to codify things, the ArchLinux package repository process, trusted users, abandonment procedures, and Perl's CPAN repository which provides integrated test reports and some maintenance guidance but no namespacing.
Chef and PowerShell Desired State ConfigurationJulian Dunn
This document discusses using Chef and PowerShell Desired State Configuration (DSC) together for infrastructure configuration and management. It describes how DSC resources can be included and used from Chef to configure Windows features and packages in a declarative way similar to DSC. It also discusses how Chef resources can be mixed with DSC resources for configuration, and how monitoring and run status can integrate between the tools.
What Makes a Good Chef Cookbook? (May 2014 Edition)Julian Dunn
This document provides tips for writing good Chef cookbooks. It recommends putting control flow in attributes, separating recipes by platform, avoiding repetition by using LWRPs, keeping recipes small, using community helpers, and testing code. It also advises being declarative, avoiding poking Chef internals, using native Ruby types, and learning from software developers' best practices.
This document provides advice on writing good cookbooks in Chef. It recommends putting control flow in attributes to make cookbooks cross-platform, separating recipes by operating system, using community helpers, keeping recipes small and simple, hiding complexity using libraries and LWRPs, and following best practices from software development like information hiding, testing, and avoiding hardcoded strings. Good cookbooks are declarative, avoid poking Chef internals, have options for installation, and leverage built-in Chef resources.
Configuration Management Isn't EverythingJulian Dunn
This document discusses configuration management (CM) projects and what leads to their success and failure. It notes that while CM is important, revolutionizing IT requires more than just CM. Successful CM projects have realistic expectations, dedicate resources to own the CM process, conduct candid assessments of current processes, make incremental changes, and plan in advance. They focus on people, process, and products rather than just tools. Unsuccessful projects have unrealistic expectations, rely too much on consultants, take a big bang approach, and lack advance planning. The key is to focus on CM as a long-term investment that improves team collaboration and experimentation.
This document discusses using Chef to automate configuration on Microsoft Windows systems. It provides a timeline of Chef's support for Windows since 2011. It also discusses resources available in Chef for Windows including the registry_key, powershell_script, and batch resources. The document demonstrates automating the installation of a .NET application on Windows using Chef resources. It provides an overview of using Chef to provision infrastructure on Windows via Azure and discusses testing Chef cookbooks on Windows systems.
This document provides an overview and introduction to DevOps and Chef configuration management. It discusses how DevOps aims to align development and operations teams through automation, measurement, and sharing. Chef is presented as a tool that supports DevOps principles by allowing infrastructure to be coded and managed as code. The document uses examples to demonstrate how Chef can be used to declaratively define and manage server configurations, applying changes across multiple nodes. It highlights how this approach helps solve problems of manual configuration drift and complexity that arise in traditional infrastructure management.
Chef Workflow Strategies at SecondMarketJulian Dunn
The document discusses Chef Workflow at SecondMarket. It describes developing cookbooks locally using Vagrant and testing with ChefSpec, integrating changes using Git repos for each cookbook, deploying using Spork to upload stable versions and notify teams, and future goals like improving testing and code reviews. The workflow aims to allow independent development while coordinating changes and communicating deployments.
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.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
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.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
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
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.
Full-RAG: A modern architecture for hyper-personalizationZilliz
Mike Del Balso, CEO & Co-Founder at Tecton, presents "Full RAG," a novel approach to AI recommendation systems, aiming to push beyond the limitations of traditional models through a deep integration of contextual insights and real-time data, leveraging the Retrieval-Augmented Generation architecture. This talk will outline Full RAG's potential to significantly enhance personalization, address engineering challenges such as data management and model training, and introduce data enrichment with reranking as a key solution. Attendees will gain crucial insights into the importance of hyperpersonalization in AI, the capabilities of Full RAG for advanced personalization, and strategies for managing complex data integrations for deploying cutting-edge AI solutions.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
“An Outlook of the Ongoing and Future Relationship between Blockchain Technologies and Process-aware Information Systems.” Invited talk at the joint workshop on Blockchain for Information Systems (BC4IS) and Blockchain for Trusted Data Sharing (B4TDS), co-located with with the 36th International Conference on Advanced Information Systems Engineering (CAiSE), 3 June 2024, Limassol, Cyprus.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
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
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
zkStudyClub - Reef: Fast Succinct Non-Interactive Zero-Knowledge Regex ProofsAlex Pruden
This paper presents Reef, a system for generating publicly verifiable succinct non-interactive zero-knowledge proofs that a committed document matches or does not match a regular expression. We describe applications such as proving the strength of passwords, the provenance of email despite redactions, the validity of oblivious DNS queries, and the existence of mutations in DNA. Reef supports the Perl Compatible Regular Expression syntax, including wildcards, alternation, ranges, capture groups, Kleene star, negations, and lookarounds. Reef introduces a new type of automata, Skipping Alternating Finite Automata (SAFA), that skips irrelevant parts of a document when producing proofs without undermining soundness, and instantiates SAFA with a lookup argument. Our experimental evaluation confirms that Reef can generate proofs for documents with 32M characters; the proofs are small and cheap to verify (under a second).
Paper: https://eprint.iacr.org/2023/1886
3. Chef can have a steep learning curve
Flickr user: chesterbr
Wednesday, May 1, 13
4. ... which we try to mitigate
• learnchef.com
• docs.opscode.com
• Opscode Public/Private
training classes
• Podcasts (Food Fight Show,
etc.)
• Local user groups
• ChefConf! (and the hallway
track)
Wednesday, May 1, 13
5. Still, it’s hard to know
when you’re doing
things right.
Wednesday, May 1, 13
6. Even harder to know when you’re doing
something wrong.
Wednesday, May 1, 13
7. “Best practices” in the community
are evolving all the time.
Wednesday, May 1, 13
8. • “I would have liked to see more about best practices ... [o]ur
instructor had to go ‘off topic’ to explain some common pitfalls.”
- feedback from Chef 2-Day Fundamentals
Wednesday, May 1, 13
9. This talk will give you some best practices to make
you a Master Chef quickly.
Wednesday, May 1, 13
15. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
Wednesday, May 1, 13
16. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
Wednesday, May 1, 13
17. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
• Roles and their names
Wednesday, May 1, 13
18. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
• Roles and their names
• How many environments
Wednesday, May 1, 13
19. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
• Roles and their names
• How many environments
• Clusters within those environments
Wednesday, May 1, 13
20. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
• Roles and their names
• How many environments
• Clusters within those environments
• Data bag hierarchy & naming, data bag item structure
Wednesday, May 1, 13
21. Advance planning
• Plan in advance:
• What cookbooks you’re going to have
• What recipes
• Roles and their names
• How many environments
• Clusters within those environments
• Data bag hierarchy & naming, data bag item structure
• BTW, if you want to go blind: www.textfiles.com/
underconstruction/
Wednesday, May 1, 13
22. The Top Ten List of
Antipatterns
Wednesday, May 1, 13
23. 10. The Giant Git repo for your chef-repo
git://github.com/yourcompany/chef-repo.git
Wednesday, May 1, 13
24. 10. The Giant Git repo for your chef-repo
git://github.com/yourcompany/chef-repo.git
Why is this bad?
Wednesday, May 1, 13
25. 10. The Giant Git repo for your chef-repo
• Mixing temporal data (environments, roles) with
versioned data (cookbooks)
• Git philosophy: One Git repo for each thing you’re
versioning independently
• Don’t be afraid of more Git repos!
Wednesday, May 1, 13
26. 10. The Giant Git repo for your chef-repo
Better:
Wednesday, May 1, 13
27. 10. The Giant Git repo for your chef-repo
git://github.com/yourcompany/chef-data.git
Better:
Wednesday, May 1, 13
28. 10. The Giant Git repo for your chef-repo
git://github.com/yourcompany/chef-data.git
Better:
git://github.com/yourcompany-cookbooks/foo.git
Wednesday, May 1, 13
29. 10. The Giant Git repo for your chef-repo
More reasons to do this:
Wednesday, May 1, 13
30. 10. The Giant Git repo for your chef-repo
git remote add upstream git://github.com/whatevs/
upstream.git
git fetch upstream
git merge upstream/master
More reasons to do this:
Wednesday, May 1, 13
31. 10. The Giant Git repo for your chef-repo
git remote add upstream git://github.com/whatevs/
upstream.git
git fetch upstream
git merge upstream/master
More reasons to do this:
Also, easy to open-source your
cookbooks just by tweaking ACL
Wednesday, May 1, 13
32. 9. The one giant cookbook for your company
git://github.com/yourcompany-cookbooks/yourco.git
Wednesday, May 1, 13
33. 9. The one giant cookbook for your company
git://github.com/yourcompany-cookbooks/yourco.git
Why is this bad?
Wednesday, May 1, 13
34. 9. The one giant cookbook for your company
Flickr user: ctbto
Wednesday, May 1, 13
35. 9. The one giant cookbook for your company
• Chef cookbooks configure a top-level service
Flickr user: ctbto
Wednesday, May 1, 13
36. 9. The one giant cookbook for your company
• Chef cookbooks configure a top-level service
• The Giant Cookbook mixes & matches things
that don’t go with one another
Flickr user: ctbto
Wednesday, May 1, 13
37. 9. The one giant cookbook for your company
• Chef cookbooks configure a top-level service
• The Giant Cookbook mixes & matches things
that don’t go with one another
• Big blast radius on changes to recipes: leads to
accidents
Flickr user: ctbto
Wednesday, May 1, 13
38. 9. The one giant cookbook for your company
Rather than:
+ cookbooks
+ yourcompany
+ recipes
|
+- mainsite-apache-virtualhost.rb
+- anothersite-apache-virtualhost.rb
+- spring-properties.rb
Wednesday, May 1, 13
39. 9. The one giant cookbook for your company
This:
+ cookbooks
+ mainsite
| + recipes
| +- apache-virtualhost.rb
|
+ anothersite
| + recipes
| +- apache-virtualhost.rb
|
+ springproperties
+ recipes
+- properties.rb
Wednesday, May 1, 13
40. 8. Using Chef Environments for more than just logical environment
Wednesday, May 1, 13
41. 8. Using Chef Environments for more than just logical environment
• Environments are a logical concept, mapping to your
actual environments
Wednesday, May 1, 13
42. 8. Using Chef Environments for more than just logical environment
• Environments are a logical concept, mapping to your
actual environments
• Don’t be tempted to overload them as “cluster name”
or “data center name” though!
Wednesday, May 1, 13
43. 8. Using Chef Environments for more than just logical environment
mongos = search(:node, “role:mongodb AND
chef_environment:#{node.chef_environment}”)
Wednesday, May 1, 13
44. 8. Using Chef Environments for more than just logical environment
mongos = search(:node, “role:mongodb AND
chef_environment:#{node.chef_environment}”)
Might not be enough if you have more
than one MongoDB cluster in the
“production” environment
Wednesday, May 1, 13
45. 8. Using Chef Environments for more than just logical environment
Better:
Wednesday, May 1, 13
46. 8. Using Chef Environments for more than just logical environment
node.set[‘mongodb’][‘cluster_name’] =
‘mongocluster1’
mongos = search(:node, “role:mongodb AND
chef_environment:#{node.chef_environment
} AND
mongodb.cluster_name=#{node[‘mongodb’]
[‘cluster_name’]}”)
Better:
Wednesday, May 1, 13
47. 8. Using Chef Environments for more than just logical environment
Even Better:
Wednesday, May 1, 13
48. 8. Using Chef Environments for more than just logical environment
node.set[‘globals’][‘data_center’] = ‘portlandia’
node.set[‘mongodb’][‘cluster_name’] =
‘mongocluster1’
mongos = search(:node, “role:mongodb AND
chef_environment:#{node.chef_environment} AND
mongodb.cluster_name=#{node[‘mongodb’]
[‘cluster_name’]} AND
globals.data_center=#{node[‘globals’]
[‘data_center’]}”)
Even Better:
Wednesday, May 1, 13
50. 7. Forking community cookbooks
• Opscode maintains ~130
cookbooks
Wednesday, May 1, 13
51. 7. Forking community cookbooks
• Opscode maintains ~130
cookbooks
• Others out there are also really
great & well-maintained
(Redis, MongoDB)
Wednesday, May 1, 13
52. 7. Forking community cookbooks
• Opscode maintains ~130
cookbooks
• Others out there are also really
great & well-maintained
(Redis, MongoDB)
• Resist the temptation to fork
cookbooks!
Wednesday, May 1, 13
53. 7. Forking community cookbooks
• Opscode maintains ~130
cookbooks
• Others out there are also really
great & well-maintained
(Redis, MongoDB)
• Resist the temptation to fork
cookbooks!
• You won’t get the benefit of
upstream bugfixes &
enhancements
Wednesday, May 1, 13
54. 7. Forking community cookbooks
• Rather, use application/library cookbook pattern to overlay your changes (thanks,
Bryan Berry)
• Example: SecondMarket’s “wrapper” PostgreSQL cookbook
Wednesday, May 1, 13
55. 7. Forking community cookbooks
• Rather, use application/library cookbook pattern to overlay your changes (thanks,
Bryan Berry)
• Example: SecondMarket’s “wrapper” PostgreSQL cookbook
smpostgresql/recipes/server.rb:
See: github.com/secondmarket-cookbooks/smpostgresql.git
Wednesday, May 1, 13
57. 6. Run list in roles
• Controversial, I know!
Wednesday, May 1, 13
58. 6. Run list in roles
• Controversial, I know!
• Opscode’s own training material says to put run lists
in roles
Wednesday, May 1, 13
59. 6. Run list in roles
• Controversial, I know!
• Opscode’s own training material says to put run lists
in roles
• But... roles aren’t versioned. Anyway, they are
temporal data.
Wednesday, May 1, 13
60. 6. Run list in roles
• Controversial, I know!
• Opscode’s own training material says to put run lists
in roles
• But... roles aren’t versioned. Anyway, they are
temporal data.
• Hard to deploy run_list changes in a role across
environments without the “nuclear” option
Wednesday, May 1, 13
61. 6. Run list in roles
Instead of:
Wednesday, May 1, 13
62. 6. Run list in roles
"run_list": [
"recipe[selinux::permissive]",
"recipe[rsyslog]",
"recipe[chef-client::config]",
"recipe[chef-client::service]",
"recipe[chef-client::delete_validation]",
"recipe[openssh::iptables]"
]
Instead of:
Wednesday, May 1, 13
63. 6. Run list in roles
"run_list": [
"recipe[selinux::permissive]",
"recipe[rsyslog]",
"recipe[chef-client::config]",
"recipe[chef-client::service]",
"recipe[chef-client::delete_validation]",
"recipe[openssh::iptables]"
]
Instead of:
Do:
Wednesday, May 1, 13
64. 6. Run list in roles
"run_list": [
"recipe[selinux::permissive]",
"recipe[rsyslog]",
"recipe[chef-client::config]",
"recipe[chef-client::service]",
"recipe[chef-client::delete_validation]",
"recipe[openssh::iptables]"
]
Instead of:
% knife cookbook create roles
% vi roles/base.rb
“run_list”: [ “recipe[roles::base]” ]
Do:
Wednesday, May 1, 13
65. 6. Run list in roles
roles/recipes/base.rb:
Wednesday, May 1, 13
66. 6. Run list in roles
include_recipe “selinux::permissive"
include_recipe “rsyslog”
include_recipe “chef-client::config”
include_recipe “chef-client::service”
include_recipe “chef-client::delete_validation”
include_recipe “openssh::iptables”
roles/recipes/base.rb:
Wednesday, May 1, 13
67. 6. Run list in roles
include_recipe “selinux::permissive"
include_recipe “rsyslog”
include_recipe “chef-client::config”
include_recipe “chef-client::service”
include_recipe “chef-client::delete_validation”
include_recipe “openssh::iptables”
roles/recipes/base.rb:
• Write conditionals around these too if you want
• Or set role attributes in the recipe
Wednesday, May 1, 13
68. 5. Disorganized data bags
• Remember what I said about
pre-planning?
Flickr user: macsurak
Wednesday, May 1, 13
71. 5. Disorganized data bags
• Only have two-levels (data bag, and then data bag
item) to work with, so plan ahead!
Wednesday, May 1, 13
72. 5. Disorganized data bags
• Only have two-levels (data bag, and then data bag
item) to work with, so plan ahead!
• Avoid making data bag items enormous JSON
hashes - keep them small for performance
Wednesday, May 1, 13
73. 5. Disorganized data bags
• Only have two-levels (data bag, and then data bag
item) to work with, so plan ahead!
• Avoid making data bag items enormous JSON
hashes - keep them small for performance
• 8 KB JSON x 4 Chef runs/h x 1000 nodes = 5.38
GB/week!
Wednesday, May 1, 13
74. 4. Not knowing about or using the chef-shell
Flickr user: blueridgekitties
Wednesday, May 1, 13
75. 4. Not knowing about or using the chef-shell
• Chef-Shell (formerly
Shef): One of the most
under-utilized tools!
• IRB (Interactive Ruby) +
Chef primitives
• Cookbook development
• Production debugging
Flickr user: blueridgekitties
Wednesday, May 1, 13
76. 4. Not knowing about or using the chef-shell
Wednesday, May 1, 13
77. 4. Not knowing about or using the chef-shell
Wednesday, May 1, 13
78. 29: <% @members.each do |member| -%>
30: <%= member['hostname'] %> IN CNAME
<%= member['ec2']['public_hostname'] %>.
31: <% end -%>
4. Not knowing about or using the chef-shell
Wednesday, May 1, 13
79. 4. Not knowing about or using the chef-shell
[jdunn@dns1 ~]$ chef-shell -z
loading configuration: /etc/chef/client.rb
Session type: client
.
.
chef > echo off
chef > members = search('node', "domain:epicfail.com")
chef > members.each do |m|
chef > pp "#{m['hostname']}, #{m['ec2']['public_hostname']}"
chef ?> end
"host1, ec2-50-17-43-13.compute-1.amazonaws.com"
"host37, ec2-23-23-145-243.compute-1.amazonaws.com"
"host3, "
NoMethodError: undefined method `[]' for nil:NilClass
Wednesday, May 1, 13
80. 4. Not knowing about or using the chef-shell
• Way more stuff than this
• Check out my Slideshare deck: slideshare.net/
JulianDunn/an-introduction-to-shef-the-chef-shell
• Chef Shell will save you time, guaranteed!
Wednesday, May 1, 13
81. 3. Who’s Afraid of the Big Bad LWRP
• Myth: LWRPs are hard to write!
You need to know Ruby!
Flickr user: edenpictures
Wednesday, May 1, 13
83. 3. Who’s Afraid of the Big Bad LWRP
• Use inline resources
• Basic Ruby classes and methods go a long way
(Array, Hash, String, etc.)
• The LWRP framework is ... lightweight and does a
lot for you
Flickr user: emawebdesign
Wednesday, May 1, 13
84. 3. Who’s Afraid of the Big Bad LWRP
cookbooks/mouse/recipes/default.rb
mouse “Itchy” do
says “Ow, Scratchy cut off my tail”
tail false
action :say
end
Wednesday, May 1, 13
85. 3. Who’s Afraid of the Big Bad LWRP
cookbooks/mouse/resources/default.rb
actions :say
attribute :given_name, :name_attribute => true
attribute :phrase, :default => “squeak”
attribute :tail, :default => true, :kind_of => [TrueClass, FalseClass]
cookbooks/mouse/providers/default.rb
action :say do
log “My name is #{new_resource.given_name}”
log new_resource.phrase unless new_resource.phrase =~ /^squeak$/
log “I #{new_resource.tail ? ‘do’ : ‘do not’ } have a tail
end
Wednesday, May 1, 13
87. 2. “Not Invented Here” Syndrome
• Bias against using other people’s code/libraries/
cookbooks
• Temptation to write your own bespoke cookbook
• Instead, do your research, find the best one, and use
it in a library/application cookbook pattern
• Contribute improvements/changes back
Wednesday, May 1, 13
90. 1. The Lone Wolf Chef
• Bus/truck factor of 1
• Chef configures applications
• Developers know applications better than you
• Get them involved in writing & maintaining
cookbooks
• Then, everyone is responsible for production-
readiness!
Wednesday, May 1, 13
91. Recap: Top Ten List of Antipatterns
• The one giant Git repo for all Chef data
• The one giant cookbook named after your company
• Using Chef Environments for more than just logical environment
• Forking community cookbooks
• Maintaining the run list in your role
• Disorganized data bags
• Not knowing about or using the chef-shell
• Being afraid of LWRPs
• Not Invented Here Syndrome
• The Lone Wolf Chef
Wednesday, May 1, 13