The Design Patterns book is more than just a collection of elegant solutions to common problems, it provides us with a vocabulary and framework for analyzing those problems. Discussing and applying design patterns helps shift the focus from the immediate problem to design. As the Puppet community converged on an idea of what "good" code looks like, Puppet design patterns began to emerge and design became more important. With more and more complex software being modeled in Puppet, those design patterns are more relevant than ever before. As the Puppet language takes on more general purpose and orchestration features, the need for good design patterns only grows with every release. This talk will discuss some of those design patterns and the problems that they solve.
Slides from 10/21 talk at PuppetConf 2016 in San Diego.
The Design Patterns book is more than just a collection of elegant solutions to common problems, it provides us with a vocabulary and framework for analyzing those problems. Discussing and applying design patterns helps shift the focus from the immediate problem to design. As the Puppet community converged on an idea of what "good" code looks like, Puppet design patterns began to emerge and design became more important. With more and more complex software being modeled in Puppet, those design patterns are more relevant than ever before. As the Puppet language takes on more general purpose and orchestration features, the need for good design patterns only grows with every release. This talk will discuss some of those design patterns and the problems that they solve.
Puppet is an open source tool for server configuration management and application deployment. It allows users to define the desired state of IT infrastructure and automatically enforces that state. Key features include enforcing consistent configurations across thousands of nodes, increased productivity through automation, and visibility into infrastructure changes. Puppet works by defining resources like packages, files, and services using a declarative language and enforcing that configuration through an agent-master architecture.
1. The document discusses moving from a Dev to DevOps model by addressing issues like siloization between development and operations teams and embracing concepts like infrastructure as code.
2. It recommends several DevOps tools for infrastructure automation including Puppet, Vagrant, and VeeWee which allow developers to define infrastructure in code and provision environments.
3. The Puppet Domain Specific Language (DSL) is demonstrated for declaring resources like users, files, packages, and services with attributes and relationships between them in a declarative way.
PuppetCamp SEA 1 - Puppet Deployment at OnAppWalter Heck
Wai Keen Woon, CTO CDN Division OnApp Malaysia, gave an interesting overview of what the Puppet architecture at OnApp looks like. The CDN division at OnApp is a large provider of CDN services, and as such makes a very interesting candidate for a case study.
Walter Heck, founder of OlinData, presented a step-by-step guide on how to set up a proper puppet repository, complete with the brand new PuppetDB, exported resources and usage of open source modules.
More info at http://blog.carlossanchez.eu/2011/11/15/from-dev-to-devops-slides-from-apachecon-na-vancouver-2011/
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
The document discusses how immutable infrastructure can be achieved through Puppet by treating systems configuration as code. Puppet allows defining systems in code and enforcing that state through automatic idempotent runs, compensating for inherent system mutability. This brings predictability to infrastructure and allows higher level operations by establishing a foundation of reliable, known states.
From Dev to DevOps - Apache Barcamp Spain 2011Carlos Sanchez
UPDATE: updated slides at http://www.slideshare.net/carlossg/from-dev-to-devops-conferencia-agile-spain-2011
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
Slides from 10/21 talk at PuppetConf 2016 in San Diego.
The Design Patterns book is more than just a collection of elegant solutions to common problems, it provides us with a vocabulary and framework for analyzing those problems. Discussing and applying design patterns helps shift the focus from the immediate problem to design. As the Puppet community converged on an idea of what "good" code looks like, Puppet design patterns began to emerge and design became more important. With more and more complex software being modeled in Puppet, those design patterns are more relevant than ever before. As the Puppet language takes on more general purpose and orchestration features, the need for good design patterns only grows with every release. This talk will discuss some of those design patterns and the problems that they solve.
Puppet is an open source tool for server configuration management and application deployment. It allows users to define the desired state of IT infrastructure and automatically enforces that state. Key features include enforcing consistent configurations across thousands of nodes, increased productivity through automation, and visibility into infrastructure changes. Puppet works by defining resources like packages, files, and services using a declarative language and enforcing that configuration through an agent-master architecture.
1. The document discusses moving from a Dev to DevOps model by addressing issues like siloization between development and operations teams and embracing concepts like infrastructure as code.
2. It recommends several DevOps tools for infrastructure automation including Puppet, Vagrant, and VeeWee which allow developers to define infrastructure in code and provision environments.
3. The Puppet Domain Specific Language (DSL) is demonstrated for declaring resources like users, files, packages, and services with attributes and relationships between them in a declarative way.
PuppetCamp SEA 1 - Puppet Deployment at OnAppWalter Heck
Wai Keen Woon, CTO CDN Division OnApp Malaysia, gave an interesting overview of what the Puppet architecture at OnApp looks like. The CDN division at OnApp is a large provider of CDN services, and as such makes a very interesting candidate for a case study.
Walter Heck, founder of OlinData, presented a step-by-step guide on how to set up a proper puppet repository, complete with the brand new PuppetDB, exported resources and usage of open source modules.
More info at http://blog.carlossanchez.eu/2011/11/15/from-dev-to-devops-slides-from-apachecon-na-vancouver-2011/
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
The document discusses how immutable infrastructure can be achieved through Puppet by treating systems configuration as code. Puppet allows defining systems in code and enforcing that state through automatic idempotent runs, compensating for inherent system mutability. This brings predictability to infrastructure and allows higher level operations by establishing a foundation of reliable, known states.
From Dev to DevOps - Apache Barcamp Spain 2011Carlos Sanchez
UPDATE: updated slides at http://www.slideshare.net/carlossg/from-dev-to-devops-conferencia-agile-spain-2011
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
Drupal 8 Theme System: The Backend of FrontendAcquia
If you develop with Drupal, chances are you've worked with Drupal's theme system, whether you knew it or not. With Drupal 8 out, what better time to learn more about the Drupal 8 theme system?
The theme system in Drupal spans both module development and theme development. The main responsibilities of the theme system are to prepare and output markup and other data, and to allow for overrides. The Drupal 8 theme system brings many changes including the Twig templating engine, automatically escaped markup for increased security, changes to theme suggestions, new base themes in core, and more.
Scott Reeves, Team Lead at Digital Echidna, and Drupal 8 theme system co-maintainer and provisional core committer will guide you through Drupal 8’s theme system. The webinar will cover important differences from Drupal 7 and also walk through the internals of different aspects of the theme system and how they might affect your day-to-day work with Drupal.
Topics will include:
-An overview of the important changes to the theme system from Drupal 7 to Drupal 8
-How to use theme hook suggestions to cut down on custom code and create more flexible and reusable components
-Phases of the theme and render systems and where you can step in to alter things
-Debugging tips and Twig magic
PuppetCamp SEA 1 - Version Control with PuppetWalter Heck
Choon Ming Goh, System Administrator at OnApp Malaysia, gave a presentation on how OnApp implements version control. Since they have quite a few repositories, this is all puppetised and that is quite a nice way of doing version control.
The document provides configuration details for setting up a Capistrano deployment with multistage environments and recipes for common tasks like installing gems, configuring databases, and integrating with Thinking Sphinx. It includes base configuration definitions, recipes for setting up Thinking Sphinx indexes and configuration files, and instructions for packaging the Capistrano configurations as a gem.
Puppet for Java developers - JavaZone NO 2012Carlos Sanchez
Example code at https://github.com/carlossg/puppet-for-java-devs
More info at http://blog.carlossanchez.eu/tag/devops
Video at http://vimeo.com/49483627
Puppet is an infrastructure-as-code tool that allows easy and automated provisioning of servers, defining the packages, configuration, services,... in code. Enabling DevOps culture, tools like Puppet help drive Agile development all the way to operations and systems administration, and along with continuous integration tools like Jenkins, it is a key piece to accomplish repeatability and continuous delivery, automating the operations side during development, QA or production, and enabling testing of systems configuration.
Traditionally a field for system administrators, Puppet can empower developers, allowing both to collaborate coding the infrastructure needed for their developments, whether it runs in hardware, virtual machines or cloud. Developers and sysadmins can define what JDK version must be installed, application server, version, configuration files, war and jar files,... and easily make changes that propagate across all nodes.
Using Vagrant, a command line automation layer for VirtualBox, they can also spin off virtual machines in their local box, easily from scratch with the same configuration as production servers, do development or testing and tear them down afterwards.
We’ll show how to install and manage Puppet nodes with JDK, multiple application server instances with installed web applications, database, configuration files and all the supporting services. Including getting up and running with Vagrant and VirtualBox for quickstart and Puppet experiments, as well as setting up automated testing of the Puppet code.
More info at http://blog.carlossanchez.eu/tag/devops
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
Ansible : what's ansible & use case by REXSaewoong Lee
The document discusses using Ansible to upgrade MySQL from version 3.10 to 3.12 across 1000 servers. It provides steps to create backups and run upgrade scripts on each server using Ansible playbooks and bash scripts in a loop. It also asks how to make the deployment easier, safer and more comfortable. Later sections explain Ansible concepts like installation, modules, playbooks, tags, inventory, variables and demonstrate usage through examples.
The document discusses Debian packaging and provides instructions for creating Debian packages. It introduces Debian packaging tools like debhelper, dpkg-dev, and lintian. It then walks through the steps to generate a package including creating the package directory structure, files like control, rules, and copyright. It also discusses collaborating with Debian through documentation, translations, packaging software, and bug reporting.
Continuous Delivery with Maven, Puppet and Tomcat - ApacheCon NA 2013Carlos Sanchez
Continuous Integration, with Apache Continuum or Jenkins, can be extended to fully manage deployments and production environments, running in Tomcat for instance, in a full Continuous Delivery cycle using infrastructure-as-code tools like Puppet, allowing to manage multiple servers and their configurations.
Puppet is an infrastructure-as-code tool that allows easy and automated provisioning of servers, defining the packages, configuration, services,... in code. Enabling DevOps culture, tools like Puppet help drive Agile development all the way to operations and systems administration, and along with continuous integration tools like Apache Continuum or Jenkins, it is a key piece to accomplish repeatability and continuous delivery, automating the operations side during development, QA or production, and enabling testing of systems configuration.
Traditionally a field for system administrators, Puppet can empower developers, allowing both to collaborate coding the infrastructure needed for their developments, whether it runs in hardware, virtual machines or cloud. Developers and sysadmins can define what JDK version must be installed, application server, version, configuration files, war and jar files,... and easily make changes that propagate across all nodes.
Using Vagrant, a command line automation layer for VirtualBox, they can also spin off virtual machines in their local box, easily from scratch with the same configuration as production servers, do development or testing and tear them down afterwards.
We will show how to install and manage Puppet nodes with JDK, multiple Tomcat instances with installed web applications, database, configuration files and all the supporting services. Including getting up and running with Vagrant and VirtualBox for quickstart and Puppet experiments, as well as setting up automated testing of the Puppet code.
Czym jest webpack i dlaczego chcesz go używać?Marcin Gajda
Podczas tworzenia frontendu aplikacji internetowych często odkrywamy, że nasza baza kodu JavaScript dość szybko się rozrasta i lawinowo przybywa nam zależności. Oczywistym rozwiązaniem wydaje się wtedy dzielenie kodu na mniejsze moduły, ale jak to robić mądrze? Tu z pomocą przychodzi nam webpack. Podczas tej prezentacji dowiemy się, w jaki sposób działa to narzędzie, jak konfiguruje się w nim kompilację assetów oraz jakie dodatkowe możliwości ono w sobie kryje.
How to Develop Puppet Modules: From Source to the Forge With Zero ClicksCarlos Sanchez
Puppet Modules are a great way to reuse code, share your development with other people and take advantage of the hundreds of modules already available in the community. But how to create, test and publish them as easily as possible? now that infrastructure is defined as code, we need to use development best practices to build, test, deploy and use Puppet modules themselves. Three steps for a fully automated process
* Continuous Integration of Puppet Modules
* Automatic release and upload to the Puppet Forge
* Deploy to Puppet master
distribute und pip als Ersatz für setuptools und easy_install bieten im Zusammenspiel mit virtualenv viele neue Möglichkeiten bei der Entwicklung und dem Deployment von Python-Applikationen. In diesem Vortrag stelle ich alle Werkzeuge kurz vor und zeige, wie man sie zusammen einsetzen kann.
Introducing containers into your infrastructure brings new capabilities, but also new challenges, in particular around configuration. This talk will take a look under the hood at some of those operational challenges including:
* The difference between runtime and build-time configuration, and the importance of relating the two together.
* Configuration drift, immutable mental models and mutable container file systems.
* Who configures the orchestrators?
* Emergent vs. model driven configuration.
In the process we will identify some common problems and talk about potential solutions.
Talk from PuppetConf 2016
Puppet is an open source tool for server configuration management. It allows systems to be configured and maintained in a consistent, automated way. Puppet uses a declarative language to describe system configuration and can manage a variety of operating systems. It provides benefits like reduced entropy, ability to quickly scale machines, change management tracking and repeatable states. Puppet uses a client-server architecture with SSL encryption and supports concepts like templates, defined types and ordering of resources.
1. The document discusses Docker containers, Docker machines, and Docker Compose as tools for building Python development environments and deploying backend services.
2. It provides examples of using Docker to run sample Python/Django applications with MySQL and PostgreSQL databases in containers, and load testing the applications.
3. The examples demonstrate performance testing Python REST APIs with different database backends and caching configurations using Docker containers.
This document introduces dbdeployer, a tool written in Go that allows users to easily deploy and manage MySQL sandboxes. It summarizes the key features and capabilities of dbdeployer, including installing single or replicated sandboxes, customizing configurations, finding free ports, and exposing various MySQL 8 data dictionary tables. The document provides instructions on downloading, unpacking, and using dbdeployer to deploy different types of MySQL configurations for testing or development purposes.
This document discusses using Puppet resources to describe and manage Google Compute Engine (GCE) infrastructure as code. Resources can represent GCE objects like disks, networks, firewalls, and instances. Common application stacks can then be built by composing these resources, such as defining a network and firewall and launching an instance that uses them. Instances can also consume modules and classes from the Puppet Forge to deploy full applications. This allows infrastructure to be treated declaratively and avoids copy-paste configuration.
Given at zendcon 2007 unconference. My first "talk" ever given. Had a live demo. Note that although some of the information here is still pertinent, a lot is now outdated and most of the links no longer work. This is here for archival reasons
The document discusses software-defined data centers (SDDC) and monitoring. It provides an overview of SDDC components like compute, network, and storage that can be managed as software. The document discusses how SDDC aims to provide flexibility through logical abstraction of hardware. It also discusses challenges in SDDC like the need for automation and orchestration using tools like Puppet, Chef, and Ansible. The document talks about how monitoring fits into the SDDC model and needs to be integrated based on application profiles and SLAs. It provides examples of configuring monitoring tools like Nagios and Icinga using Chef, Puppet, and Ansible.
This document discusses using Fabric and Puppet together to streamline system administration tasks. Fabric can be used to execute tasks across multiple servers using Python, while Puppet defines infrastructure using code and templates. The document suggests using Fabric to set up environments and trigger Puppet deployments, while defining nodes and classes in Puppet. This allows taking advantage of Fabric's host management capabilities and Puppet's declarative approach. Initial Fabric functions would prepare environments, while global functions handle setup/teardown. Puppet would define the desired configuration to deploy using its domain-specific language.
Drupal 8 Theme System: The Backend of FrontendAcquia
If you develop with Drupal, chances are you've worked with Drupal's theme system, whether you knew it or not. With Drupal 8 out, what better time to learn more about the Drupal 8 theme system?
The theme system in Drupal spans both module development and theme development. The main responsibilities of the theme system are to prepare and output markup and other data, and to allow for overrides. The Drupal 8 theme system brings many changes including the Twig templating engine, automatically escaped markup for increased security, changes to theme suggestions, new base themes in core, and more.
Scott Reeves, Team Lead at Digital Echidna, and Drupal 8 theme system co-maintainer and provisional core committer will guide you through Drupal 8’s theme system. The webinar will cover important differences from Drupal 7 and also walk through the internals of different aspects of the theme system and how they might affect your day-to-day work with Drupal.
Topics will include:
-An overview of the important changes to the theme system from Drupal 7 to Drupal 8
-How to use theme hook suggestions to cut down on custom code and create more flexible and reusable components
-Phases of the theme and render systems and where you can step in to alter things
-Debugging tips and Twig magic
PuppetCamp SEA 1 - Version Control with PuppetWalter Heck
Choon Ming Goh, System Administrator at OnApp Malaysia, gave a presentation on how OnApp implements version control. Since they have quite a few repositories, this is all puppetised and that is quite a nice way of doing version control.
The document provides configuration details for setting up a Capistrano deployment with multistage environments and recipes for common tasks like installing gems, configuring databases, and integrating with Thinking Sphinx. It includes base configuration definitions, recipes for setting up Thinking Sphinx indexes and configuration files, and instructions for packaging the Capistrano configurations as a gem.
Puppet for Java developers - JavaZone NO 2012Carlos Sanchez
Example code at https://github.com/carlossg/puppet-for-java-devs
More info at http://blog.carlossanchez.eu/tag/devops
Video at http://vimeo.com/49483627
Puppet is an infrastructure-as-code tool that allows easy and automated provisioning of servers, defining the packages, configuration, services,... in code. Enabling DevOps culture, tools like Puppet help drive Agile development all the way to operations and systems administration, and along with continuous integration tools like Jenkins, it is a key piece to accomplish repeatability and continuous delivery, automating the operations side during development, QA or production, and enabling testing of systems configuration.
Traditionally a field for system administrators, Puppet can empower developers, allowing both to collaborate coding the infrastructure needed for their developments, whether it runs in hardware, virtual machines or cloud. Developers and sysadmins can define what JDK version must be installed, application server, version, configuration files, war and jar files,... and easily make changes that propagate across all nodes.
Using Vagrant, a command line automation layer for VirtualBox, they can also spin off virtual machines in their local box, easily from scratch with the same configuration as production servers, do development or testing and tear them down afterwards.
We’ll show how to install and manage Puppet nodes with JDK, multiple application server instances with installed web applications, database, configuration files and all the supporting services. Including getting up and running with Vagrant and VirtualBox for quickstart and Puppet experiments, as well as setting up automated testing of the Puppet code.
More info at http://blog.carlossanchez.eu/tag/devops
The DevOps movement aims to improve communication between developers and operations teams to solve critical issues such as fear of change and risky deployments. But the same way that Agile development would likely fail without continuous integration tools, the DevOps principles need tools to make them real, and provide the automation required to actually be implemented. Most of the so called DevOps tools focus on the operations side, and there should be more than that, the automation must cover the full process, Dev to QA to Ops and be as automated and agile as possible. Tools in each part of the workflow have evolved in their own silos, and with the support of their own target teams. But a true DevOps mentality requires a seamless process from the start of development to the end in production deployments and maintenance, and for a process to be successful there must be tools that take the burden out of humans.
Apache Maven has arguably been the most successful tool for development, project standardization and automation introduced in the last years. On the operations side we have open source tools like Puppet or Chef that are becoming increasingly popular to automate infrastructure maintenance and server provisioning.
In this presentation we will introduce an end-to-end development-to-production process that will take advantage of Maven and Puppet, each of them at their strong points, and open source tools to automate the handover between them, automating continuous build and deployment, continuous delivery, from source code to any number of application servers managed with Puppet, running either in physical hardware or the cloud, handling new continuous integration builds and releases automatically through several stages and environments such as development, QA, and production.
Ansible : what's ansible & use case by REXSaewoong Lee
The document discusses using Ansible to upgrade MySQL from version 3.10 to 3.12 across 1000 servers. It provides steps to create backups and run upgrade scripts on each server using Ansible playbooks and bash scripts in a loop. It also asks how to make the deployment easier, safer and more comfortable. Later sections explain Ansible concepts like installation, modules, playbooks, tags, inventory, variables and demonstrate usage through examples.
The document discusses Debian packaging and provides instructions for creating Debian packages. It introduces Debian packaging tools like debhelper, dpkg-dev, and lintian. It then walks through the steps to generate a package including creating the package directory structure, files like control, rules, and copyright. It also discusses collaborating with Debian through documentation, translations, packaging software, and bug reporting.
Continuous Delivery with Maven, Puppet and Tomcat - ApacheCon NA 2013Carlos Sanchez
Continuous Integration, with Apache Continuum or Jenkins, can be extended to fully manage deployments and production environments, running in Tomcat for instance, in a full Continuous Delivery cycle using infrastructure-as-code tools like Puppet, allowing to manage multiple servers and their configurations.
Puppet is an infrastructure-as-code tool that allows easy and automated provisioning of servers, defining the packages, configuration, services,... in code. Enabling DevOps culture, tools like Puppet help drive Agile development all the way to operations and systems administration, and along with continuous integration tools like Apache Continuum or Jenkins, it is a key piece to accomplish repeatability and continuous delivery, automating the operations side during development, QA or production, and enabling testing of systems configuration.
Traditionally a field for system administrators, Puppet can empower developers, allowing both to collaborate coding the infrastructure needed for their developments, whether it runs in hardware, virtual machines or cloud. Developers and sysadmins can define what JDK version must be installed, application server, version, configuration files, war and jar files,... and easily make changes that propagate across all nodes.
Using Vagrant, a command line automation layer for VirtualBox, they can also spin off virtual machines in their local box, easily from scratch with the same configuration as production servers, do development or testing and tear them down afterwards.
We will show how to install and manage Puppet nodes with JDK, multiple Tomcat instances with installed web applications, database, configuration files and all the supporting services. Including getting up and running with Vagrant and VirtualBox for quickstart and Puppet experiments, as well as setting up automated testing of the Puppet code.
Czym jest webpack i dlaczego chcesz go używać?Marcin Gajda
Podczas tworzenia frontendu aplikacji internetowych często odkrywamy, że nasza baza kodu JavaScript dość szybko się rozrasta i lawinowo przybywa nam zależności. Oczywistym rozwiązaniem wydaje się wtedy dzielenie kodu na mniejsze moduły, ale jak to robić mądrze? Tu z pomocą przychodzi nam webpack. Podczas tej prezentacji dowiemy się, w jaki sposób działa to narzędzie, jak konfiguruje się w nim kompilację assetów oraz jakie dodatkowe możliwości ono w sobie kryje.
How to Develop Puppet Modules: From Source to the Forge With Zero ClicksCarlos Sanchez
Puppet Modules are a great way to reuse code, share your development with other people and take advantage of the hundreds of modules already available in the community. But how to create, test and publish them as easily as possible? now that infrastructure is defined as code, we need to use development best practices to build, test, deploy and use Puppet modules themselves. Three steps for a fully automated process
* Continuous Integration of Puppet Modules
* Automatic release and upload to the Puppet Forge
* Deploy to Puppet master
distribute und pip als Ersatz für setuptools und easy_install bieten im Zusammenspiel mit virtualenv viele neue Möglichkeiten bei der Entwicklung und dem Deployment von Python-Applikationen. In diesem Vortrag stelle ich alle Werkzeuge kurz vor und zeige, wie man sie zusammen einsetzen kann.
Introducing containers into your infrastructure brings new capabilities, but also new challenges, in particular around configuration. This talk will take a look under the hood at some of those operational challenges including:
* The difference between runtime and build-time configuration, and the importance of relating the two together.
* Configuration drift, immutable mental models and mutable container file systems.
* Who configures the orchestrators?
* Emergent vs. model driven configuration.
In the process we will identify some common problems and talk about potential solutions.
Talk from PuppetConf 2016
Puppet is an open source tool for server configuration management. It allows systems to be configured and maintained in a consistent, automated way. Puppet uses a declarative language to describe system configuration and can manage a variety of operating systems. It provides benefits like reduced entropy, ability to quickly scale machines, change management tracking and repeatable states. Puppet uses a client-server architecture with SSL encryption and supports concepts like templates, defined types and ordering of resources.
1. The document discusses Docker containers, Docker machines, and Docker Compose as tools for building Python development environments and deploying backend services.
2. It provides examples of using Docker to run sample Python/Django applications with MySQL and PostgreSQL databases in containers, and load testing the applications.
3. The examples demonstrate performance testing Python REST APIs with different database backends and caching configurations using Docker containers.
This document introduces dbdeployer, a tool written in Go that allows users to easily deploy and manage MySQL sandboxes. It summarizes the key features and capabilities of dbdeployer, including installing single or replicated sandboxes, customizing configurations, finding free ports, and exposing various MySQL 8 data dictionary tables. The document provides instructions on downloading, unpacking, and using dbdeployer to deploy different types of MySQL configurations for testing or development purposes.
This document discusses using Puppet resources to describe and manage Google Compute Engine (GCE) infrastructure as code. Resources can represent GCE objects like disks, networks, firewalls, and instances. Common application stacks can then be built by composing these resources, such as defining a network and firewall and launching an instance that uses them. Instances can also consume modules and classes from the Puppet Forge to deploy full applications. This allows infrastructure to be treated declaratively and avoids copy-paste configuration.
Given at zendcon 2007 unconference. My first "talk" ever given. Had a live demo. Note that although some of the information here is still pertinent, a lot is now outdated and most of the links no longer work. This is here for archival reasons
The document discusses software-defined data centers (SDDC) and monitoring. It provides an overview of SDDC components like compute, network, and storage that can be managed as software. The document discusses how SDDC aims to provide flexibility through logical abstraction of hardware. It also discusses challenges in SDDC like the need for automation and orchestration using tools like Puppet, Chef, and Ansible. The document talks about how monitoring fits into the SDDC model and needs to be integrated based on application profiles and SLAs. It provides examples of configuring monitoring tools like Nagios and Icinga using Chef, Puppet, and Ansible.
This document discusses using Fabric and Puppet together to streamline system administration tasks. Fabric can be used to execute tasks across multiple servers using Python, while Puppet defines infrastructure using code and templates. The document suggests using Fabric to set up environments and trigger Puppet deployments, while defining nodes and classes in Puppet. This allows taking advantage of Fabric's host management capabilities and Puppet's declarative approach. Initial Fabric functions would prepare environments, while global functions handle setup/teardown. Puppet would define the desired configuration to deploy using its domain-specific language.
PuppetConf. 2016: Puppet Best Practices: Roles & Profiles – Gary Larizza, PuppetPuppet
Here are the slides from Gary Larizza's PuppetConf 2016 presentation called Puppet Best Practices: Roles and Profiles. Watch the videos at https://www.youtube.com/playlist?list=PLV86BgbREluVjwwt-9UL8u2Uy8xnzpIqa
Satellite 6 introduces new features for automation including improved support for Puppet. Puppet allows for recipe-style configuration management and drift management. The presentation demonstrates installing and configuring Puppet on a server and client, writing Puppet code to manage files and directories, and using the Puppet dashboard. Considerations for using Puppet with Satellite 6 include keeping Puppet modules modular and mapping modules to Satellite host groups.
Lean production is an approach that focuses on eliminating waste to ensure quality. It involves doing simple things well, continuous improvement, and involving employees. The goal is to cut costs by reducing various types of waste like overproduction, waiting times, unnecessary transport and motion. Key aspects of lean production include just-in-time delivery from suppliers, cell production, simultaneous engineering, time-based management and continuous improvement through kaizen. Effective lean production requires good supplier relations, skilled employees and a culture of quality and change.
This presentation, by big data guru Bernard Marr, outlines in simple terms what Big Data is and how it is used today. It covers the 5 V's of Big Data as well as a number of high value use cases.
The document discusses Puppet modules, including what they are, best practices for structuring modules, parameters, dependencies, testing modules, and documenting modules. It provides examples of module directory structure, class structure within modules, using parameters and dynamic data, module inheritance, ordering and anchoring classes, and the Modulefile.
modern module development - Ken Barber 2012 Edinburgh Puppet CampPuppet
The document provides information on modern Puppet module development best practices. It discusses what modules are and common patterns like package, config, service that address 80% of module needs. It also covers validation of module parameters using Kwalify schemas, testing modules with rspec-puppet, and packaging modules for release on the Puppet Forge using the puppet-module tool. The document emphasizes the importance of coding style, linting with puppet-lint, and following patterns and best practices to create high quality, reusable modules.
Little documentation and few base themes with 8.x branches - what's a front end developer to do? I'll show you what's changing in Drupal theming between D7 and D8 and how to create a custom theme based on the Classy base theme, step by step. We'll go over Twig basics and Twig debugging.
Best practices in Drupal make individual developers more productive which makes the entire team more productive. This was presented by Somedutta Ghosh in Drupal Camp Kolkata. #drupalcampkolkata
This document compares the content management systems Drupal and WordPress. It provides statistics showing WordPress has more installations than Drupal in Europe. It outlines some of the key differences between the two platforms, such as Drupal using hooks while WordPress uses object-oriented programming, and how they handle content, themes, extensions, and user management. Development aspects like documentation, translations, and code repositories are also contrasted.
This document provides an overview of a talk about PHP survival techniques for Drupal front end development. The talk will use square dancing as an analogy to explain PHP concepts and tricks. It will cover variables, arrays, objects, functions, conditionals, and fancy data structures. The presenter will discuss template files, the Devel module, and provide real-world homework assignments for participants. Overall, the talk aims to help attendees better understand the PHP that powers Drupal snippets and templates.
This document provides an overview of PHP survival techniques for Drupal front end development. It discusses using square dancing as an analogy to explain PHP concepts. Some key points include:
- PHP and templating with PHPtemplate can be understood through analogies to deciding on a dance, choosing clothes, and then dancing.
- Important PHP concepts like variables, arrays, objects, and functions are explained using square dancing terminology like partners, calls and moves.
- Examples from the Drupal theme guide and books on front end Drupal development are used to demonstrate PHP snippets and template files.
- Conditionals, preprocessing functions, and the template.php file allow for customizing and extending themes. Understanding variables and how
The document provides an overview of themes in Moodle and guidance on getting started with theme design. It discusses why themes are used, best practices for theme structure and files, and key configuration settings in the config.php file like specifying stylesheet files and whether to inherit styles from parent themes. The goal is to demonstrate theme design best practices and tools to help with theme development and testing changes locally before deployment.
How to? Drupal developer toolkit. Dennis Povshedny.DrupalCampDN
This document provides recommendations for the technical tools and development environment for a Drupal developer. It discusses setting up a local LAMP stack with Linux, Apache, MySQL, and PHP configured for development. It also recommends version control with Git, debugging with XDebug, and using IDEs like NetBeans or Eclipse. Additional tips include installing browser plugins, following Drupal coding standards, and contributing code back to the community.
The document discusses how Puppet can be used to automate the installation and configuration of Splunk through consistent management of servers. It provides an overview of key Puppet concepts like Facter, Hiera, resources and modules. The presentation demonstrates setting up a Splunk cluster of 4 servers using Vagrant and Puppet to provision and configure the multi-site deployment.
Experiences with backend user rights in TYPO3punkt.de GmbH
For the last several years we've been working on various TYPO3 projects. During that time we've gained some experience in setting up backend users fitting to their needs.
In this talk we would like to share our experiences with and ideas on backend user settings. We will show you how we handle backend user groups in our projects as well as some Dos and Don'ts.
- The document discusses various patterns and techniques the author has found useful when working with Puppet modules over 10+ years, including some that may be considered unorthodox or anti-patterns by some.
- Key topics covered include optimization of reusable modules, custom data types, Bolt tasks and plans, external facts, Hiera classification, ensuring resources for presence/absence, application abstraction with Tiny Puppet, and class-based noop management.
- The author argues that some established patterns like roles and profiles can evolve to be more flexible, and that running production nodes in noop mode with controls may be preferable to fully enforcing on all nodes.
Building and Maintaining a Distribution in Drupal 7 with FeaturesNuvole
Drupal 7 allows to easily build and maintain distributions, i.e. repeatable website templates; you can benefit from this in all cases, whether you aim at large-scale deployments or even at maintaining a single website.
We will show how to package core and contributed modules in a distribution by using a Makefile and a profile and keeping them up-to-date during the whole development cycle.
Then you will learn how to use Code-Driven Development to store all settings in a sustainable way: use the Features module to easily describe configuration in code, a proper separation between Features to make your code reusable and extendible, a well-thought design of Features to create easier development patterns, CTools and Exportables to put your configuration in code even when a module does not support it natively.
Last, we will see how the distributions update mechanism allows you to create a new version of your distribution for easy and painless configuration updates of a live site.
Decoupling Drupal mit dem Lupus Nuxt.js Drupal Stacknuppla
This document summarizes a presentation about decoupling Drupal with the Lupus Nuxt.js stack using custom elements. It discusses:
1. The goals of decoupling the frontend for independent development and reusable components.
2. Using custom elements to render Drupal content on the frontend while still utilizing Drupal features like routing, authentication, and caching.
3. The architecture involves a Nuxt.js frontend that communicates with a Drupal backend via custom elements, allowing both parallel development and server-side rendering or static sites.
The document discusses technical tools and organizational hints for Drupal development. It recommends setting up a LAMP stack with Apache, MySQL, PHP 5.3+, and modules like xdebug. Development tools mentioned include debugging with xdebug, using arrays and the devel module. Version control systems like Git and IDEs like NetBeans or Eclipse are suggested. Coding standards and Doxygen comments are important for the Drupal ecosystem.
This document discusses dependency injection in Drupal 8. It begins by explaining the problems with Drupal 7 code, such as strong dependencies on globals and an inability to reuse or test code easily. It then introduces dependency injection as a design pattern that can help address these issues by reducing hard-coded dependencies. The document outlines how dependency injection works in Symfony and will work in Drupal 8 through the use of a service container that allows injecting dependencies into classes.
- The document is a guide for a Drupal theming course provided by Dropsolid Academy.
- It discusses setting up a development environment for theming including installing Drush and modules like Devel and Theme Developer.
- Visual elements are used throughout to designate tips, code examples, and actions to be completed by the reader.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
Project Management: The Role of Project Dashboards.pdfKarya Keeper
Project management is a crucial aspect of any organization, ensuring that projects are completed efficiently and effectively. One of the key tools used in project management is the project dashboard, which provides a comprehensive view of project progress and performance. In this article, we will explore the role of project dashboards in project management, highlighting their key features and benefits.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
Preparing Non - Technical Founders for Engaging a Tech AgencyISH Technologies
Preparing non-technical founders before engaging a tech agency is crucial for the success of their projects. It starts with clearly defining their vision and goals, conducting thorough market research, and gaining a basic understanding of relevant technologies. Setting realistic expectations and preparing a detailed project brief are essential steps. Founders should select a tech agency with a proven track record and establish clear communication channels. Additionally, addressing legal and contractual considerations and planning for post-launch support are vital to ensure a smooth and successful collaboration. This preparation empowers non-technical founders to effectively communicate their needs and work seamlessly with their chosen tech agency.Visit our site to get more details about this. Contact us today www.ishtechnologies.com.au
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemPeter Muessig
Learn about the latest innovations in and around OpenUI5/SAPUI5: UI5 Tooling, UI5 linter, UI5 Web Components, Web Components Integration, UI5 2.x, UI5 GenAI.
Recording:
https://www.youtube.com/live/MSdGLG2zLy8?si=INxBHTqkwHhxV5Ta&t=0
UI5con 2024 - Boost Your Development Experience with UI5 Tooling ExtensionsPeter Muessig
The UI5 tooling is the development and build tooling of UI5. It is built in a modular and extensible way so that it can be easily extended by your needs. This session will showcase various tooling extensions which can boost your development experience by far so that you can really work offline, transpile your code in your project to use even newer versions of EcmaScript (than 2022 which is supported right now by the UI5 tooling), consume any npm package of your choice in your project, using different kind of proxies, and even stitching UI5 projects during development together to mimic your target environment.
14 th Edition of International conference on computer visionShulagnaSarkar2
About the event
14th Edition of International conference on computer vision
Computer conferences organized by ScienceFather group. ScienceFather takes the privilege to invite speakers participants students delegates and exhibitors from across the globe to its International Conference on computer conferences to be held in the Various Beautiful cites of the world. computer conferences are a discussion of common Inventions-related issues and additionally trade information share proof thoughts and insight into advanced developments in the science inventions service system. New technology may create many materials and devices with a vast range of applications such as in Science medicine electronics biomaterials energy production and consumer products.
Nomination are Open!! Don't Miss it
Visit: computer.scifat.com
Award Nomination: https://x-i.me/ishnom
Conference Submission: https://x-i.me/anicon
For Enquiry: Computer@scifat.com
WWDC 2024 Keynote Review: For CocoaCoders AustinPatrick Weigel
Overview of WWDC 2024 Keynote Address.
Covers: Apple Intelligence, iOS18, macOS Sequoia, iPadOS, watchOS, visionOS, and Apple TV+.
Understandable dialogue on Apple TV+
On-device app controlling AI.
Access to ChatGPT with a guest appearance by Chief Data Thief Sam Altman!
App Locking! iPhone Mirroring! And a Calculator!!
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
Drona Infotech is a premier mobile app development company in Noida, providing cutting-edge solutions for businesses.
Visit Us For : https://www.dronainfotech.com/mobile-application-development/
Most important New features of Oracle 23c for DBAs and Developers. You can get more idea from my youtube channel video from https://youtu.be/XvL5WtaC20A
2. ➤ Architect with Kovarus
➤ Joined in May 2016
➤ Previously at Constant Contact, Sandia
National Laboratories, and a few other
places you’ve never heard of
➤ Operations background, but more of a
developer these days
➤ One of the maintainers of Vox Pupuli
➤ Organizer of the Boston Puppet User
Group
ABOUT ME
5. GANG OF FOUR
➤ Gang of Four (GoF) book introduced the
concept for Object Oriented
programming
➤ 23 patterns with examples written in
C++ and SmallTalk
➤ Published in 1994, more than 500,000
copies sold
➤ One of the best selling software
engineering books in history
➤ Influenced an entire generation of
developers, languages, and tools
6. DESIGN PATTERNS
➤ Can be highly contextual and language dependent, but a lot can be learned from all
of them
➤ The GoF focused on statically-typed, object oriented, compiled languages
➤ Some languages have implemented primitives for these patterns
➤ Not many of the GoF patterns directly apply to Puppet
➤ All of the GoF patterns focus on reinforcing a set of design principles
17. SIX PATTERNS
➤ Resource Wrapper: adding functionality to code you don’t own
➤ Package, File, Service: breaking up monolithic classes
➤ Params: delegating parameter defaults
➤ Strategy: doing the same thing differently
➤ Roles and Profiles: organizing your code for modularity
➤ Factory: creating resources on the fly
19. ABOUT THE WRAPPER PATTERN
➤ Problem: resources you don’t own are missing some functionality or feature
required to implement your requirements
➤ Solution: use composition to add your required functionality without modifying the
code you don’t own
20. ABOUT THE WRAPPER PATTERN
➤ Use the resource wrapper pattern when you need to add functionality to an
existing resource
➤ When you feel the need to write your own resources, or to make changes to Forge
modules, think about whether you should really be using the wrapper pattern
➤ You can do this in Puppet 3 and Puppet 4, but it’s much cleaner in Puppet 4
➤ This pattern forms the basis of many other patterns you’ll see today
21. EXAMPLE: MANAGING USERS
➤ We want to manage our employee user accounts
➤ Requirements:
➤ The user’s UID should be set to their employee ID
➤ All employees need to be members of the ‘employees’ group
➤ We should manage a user’s bash profile by default, but users may opt out of this
upon request
22. EXAMPLE: MANAGING USERS
define mycompany::user (
$employee_id,
$gid,
$groups = ['employees'],
$username = $title,
$manage_profile = true,
) {
if $manage_profile {
file { "/home/${username}/.bash_profile":
ensure => file,
owner => $username,
require => User[$username],
}
}
user { $username:
uid => $employee_id,
gid => $gid,
groups => $groups,
}
}
All employees should be in the ‘employees’ group
Employee ID is used for the user ID
Feature flag to manage your user’s bash profile
Manage ~/.bash_profile with a file resource
Pass your parameters to the user resource
23. EXAMPLE: MANAGING USERS
mycompany::user { 'bob':
employee_id => '1093',
gid => 'wheel',
manage_profile => false,
}
“We have a new employee
named Bob. He’s employee
1093 and he needs to be a
member of the wheel group so
he can sudo. He wants to
manage his own bash
profile.”
24. EXAMPLE: MANAGING USERS
“Hey, I’d like to have my
shell set to /bin/zsh, can you
do that for me?”
mycompany::user { 'bob':
employee_id => '1093',
gid => 'wheel',
shell => '/bin/zsh',
manage_profile => false,
}
Could not retrieve catalog:
Invalid parameter ‘shell’ for
type ‘mycompany::user’
25. EXAMPLE: MANAGING USERS define mycompany::user (
$employee_id,
$gid,
$groups = ['employees'],
$username = $title,
$manage_profile = true,
) {
if $manage_profile {
file { "/home/${username}/.bash_profile":
ensure => file,
owner => $username,
require => User[$username],
}
}
user { $username:
uid => $employee_id,
gid => $gid,
groups => $groups,
}
}
Problem
You must maintain these parameters.
26. EXAMPLE: MANAGING USERS (PUPPET 3)
define mycompany::user (
$username = $title,
$manage_profile = true,
$user = {}
) {
if $manage_profile {
file { "/home/${username}/.bash_profile":
ensure => file,
owner => $username,
require => User[$username],
}
}
$user_defaults = { ‘groups’ => [‘employees’] }
$user_params = merge($user, $user_defaults)
create_resources(‘user’, $username, $user_params)
}
Much more flexible interface
Enforce business rules
Create the user resource by passing
the hash to create_resources
27. EXAMPLE: MANAGING USERS (PUPPET 4)
define mycompany::user (
String $username = $title,
Boolean $manage_profile = true,
Hash $user = {}
) {
if $manage_profile {
file { "/home/${username}/.bash_profile":
ensure => file,
owner => $username,
require => User[$username],
}
}
$user_defaults = { 'groups' => [‘employees’] }
user { $username:
* => $user_defaults + $user,
}
}
Much more flexible interface
Enforce business rules
Use splat operator to pass hash keys
as parameters to the user resource
28. EXAMPLE: MANAGING USERS
mycompany::user { 'bob':
employee_id => '1093',
gid => 'wheel',
manage_profile => false,
}
“Hey, I’d like to have my
shell set to /bin/zsh, can you
do that for me?”
mycompany::user { 'bob':
manage_profile => false,
user => {
'uid' => '1093',
'gid' => 'wheel',
}
}
29. EXAMPLE: MANAGING USERS
mycompany::user { 'bob':
employee_id => '1093',
gid => 'wheel',
manage_profile => false,
}
mycompany::user { 'bob':
manage_profile => false,
user => {
'uid' => '1093',
'gid' => 'wheel',
'shell' => '/bin/zsh',
}
}
“Hey, I’d like to have my
shell set to /bin/zsh, can you
do that for me?”
31. ABOUT THE PACKAGE/FILE/SERVICE PATTERN
➤ Problem: your module’s init.pp is getting too cluttered because all of your code
lives in that one file
➤ Solution: break out the basic functions of your module into separate classes,
generally into a package, config, and service class
32. ABOUT THE PACKAGE/FILE/SERVICE PATTERN
➤ This is one of the first patterns you see when learning Puppet
➤ This is the embodiment of the Single Responsibility and Separation of Concerns
principles
➤ Most modules can be broken down into some form of Package, Config File, and
Service management
➤ Use this specific pattern any time you write a module that manages these things
➤ Keep the spirit of this pattern in mind whenever you write a module that is more
than a few lines long
➤ This has the added benefit of allowing us to utilize class containment for cleaner
resource ordering
33. EXAMPLE: NTP
class ntp {
case $::osfamily {
'Solaris': {
$package_name = ['SUNWntpr', 'SUNWntpu']
$config_file = '/etc/inet/ntp.conf'
$service_name = 'network/ntp'
}
'RedHat': {
$package_name = 'ntp'
$config_file = '/etc/ntp.conf'
$service_name = 'ntpd'
}
}
package { $package_name:
ensure => installed,
}
file { $config_file:
ensure => file,
content => template('ntp/ntpd.conf.erb'),
require => Package[$package_name],
notify => Service[$service_name],
}
service { $service_name:
ensure => running
}
}
Installs the ntp package for that platform
Places the ntp config file
Ensures that the package is installed first
Notifies the ntp service of changes to the file
Manages the ntp service
Set some variables based on the osfamily fact
34. class ntp {
case $osfamily {
'Solaris': {
$package_name = ['SUNWntpr', 'SUNWntpu']
$config_file = '/etc/inet/ntp.conf'
$service_name = 'network/ntp'
}
'RedHat': {
$package_name = 'ntp'
$config_file = '/etc/ntp.conf'
$service_name = 'ntpd'
}
}
class { 'ntp::install': } ->
class { 'ntp::config': } ~>
class { 'ntp::service': }
}
EXAMPLE: NTP
Installs the ntp package
Places the ntp config file
Package is installed first
Manages the ntp service
Notifies the service of changes
35. class ntp::install {
package { $ntp::package_name:
ensure => installed,
}
}
class ntp::config {
file { $ntp::config_file:
ensure => file,
content => template('ntp/ntpd.conf.erb'),
}
}
class ntp::service {
service { $ntp::service_name:
ensure => running,
}
}
EXAMPLE: NTP
37. ABOUT THE PARAMS PATTERN
➤ Problem: hard-coded data makes modules fragile, verbose parameter default and
variable setting logic make classes hard to read
➤ Solution: convert embedded data to parameters and move that data to a separate
class where it can be used as parameter defaults
38. ABOUT THE PARAMS PATTERN
➤ The params pattern breaks out your variable assignment and parameter defaults
into a separate class, typically named params
➤ Makes classes easier to read by moving the default setting logic into a purpose-built
class
➤ Delegates responsibility for setting defaults to the params class
➤ Module data is a new feature designed to eliminate the params pattern by moving
this logic into Hiera
➤ Until module data becomes more ubiquitous, you’ll see params in use in almost
every module
➤ Use this pattern any time you have data that must live in your module
39. EXAMPLE: NTP
Problems
Only supports Solaris and RedHat
~70% of this class is devoted to data
class ntp {
case $osfamily {
'Solaris': {
$package_name = ['SUNWntpr', 'SUNWntpu']
$config_file = '/etc/inet/ntp.conf'
$service_name = 'network/ntp'
}
'RedHat': {
$package_name = 'ntp'
$config_file = '/etc/ntp.conf'
$service_name = 'ntpd'
}
}
class { 'ntp::install': } ->
class { 'ntp::config': } ~>
class { 'ntp::service': }
}
40. EXAMPLE: NTP
class ntp::params {
case $::osfamily {
'Solaris': {
$package_name = ['SUNWntpr', 'SUNWntpu']
$config_file = '/etc/inet/ntp.conf'
$service_name = 'network/ntp'
}
'RedHat': {
$package_name = 'ntp'
$config_file = '/etc/ntp.conf'
$service_name = 'ntpd'
}
}
}
Create a purpose-built class
to store your module’s data
These variables become the default
values for your class parameters
41. EXAMPLE: NTP
class ntp (
$package_name = $ntp::params::package_name,
$config_file = $ntp::params::config_file,
$service_name = $ntp::params::service_name,
) inherits ntp::params {
class { 'ntp::install': } ->
class { 'ntp::config': } ~>
class { 'ntp::service': }
}
Inheriting the params class ensures
that it is evaluated first
Convert the variables to parameters, and set
their defaults to the corresponding variables
in the params class
43. ABOUT THE STRATEGY PATTERN
➤ Problem: you have multiple ways to achieve basically the same thing in your
module, but you need to choose one way based on some criteria (usually a fact)
➤ Solution: break each approach into separate classes and let your caller decide which
to include
44. ABOUT THE STRATEGY PATTERN
➤ This is a GoF pattern
➤ Use this pattern when you have lots of logic doing effectively the same thing but
with different details under certain conditions
➤ The Strategy Pattern uses composition to assemble complex behavior from smaller
classes
45. EXAMPLE: MYSQL
class mysql {
...
case $::osfamily {
'Debian': {
apt::source { 'mysql':
comment => 'MySQL Community APT repository',
location => "http://repo.mysql.com/apt/${::operatingsystem}",
release => $::lsbdistcodename,
repos => 'mysql-5.7',
include => { src => false },
}
}
'RedHat': {
yumrepo { 'mysql':
descr => 'MySQL Community YUM repository',
baseurl => "http://repo.mysql.com/yum/mysql-5.7-community/el/${::lsbmajdistrelease}/${::architecture}",
enabled => true,
}
}
}
...
}
Both managing a package repository
46. EXAMPLE: MYSQL
class mysql::repo::redhat {
yumrepo { 'mysql':
descr => 'MySQL Community YUM repository',
baseurl => "http://repo.mysql.com/yum/mysql-5.7-community/el/${::lsbmajdistrelease}/${::architecture}",
enabled => true,
}
}
class mysql::repo::debian {
apt::source { 'mysql':
comment => 'MySQL Community APT repository',
location => "http://repo.mysql.com/apt/${::operatingsystem}",
release => $::lsbdistcodename,
repos => 'mysql-5.7',
include => { src => false },
}
}
Strategy Classes
47. EXAMPLE: MYSQL
class mysql {
...
case $::osfamily {
'Debian': { include mysql::repo::debian }
'RedHat': { include mysql::repo::redhat }
}
...
}
Context Class
Case statement determines
which strategy class to include
49. ABOUT THE ROLES AND PROFILES PATTERN
➤ Problem: large node statements with many classes, lots of inherited node
statements, difficulty identifying what a server’s purpose is in your environment
➤ Solution: add an extra layer of abstraction between your node and your modules
50. ABOUT THE ROLES AND PROFILES PATTERN
➤ The Roles and Profiles pattern was described by Craig Dunn in his blog post
Designing Puppet - Roles and Profiles
➤ This is one of the most comprehensive design patterns for Puppet
➤ It is the “official” way to structure your Puppet code
➤ You should always use Roles and Profiles
➤ Craig does an excellent job describing these concepts in depth, you should read his
blog post here: http://www.craigdunn.org/2012/05/239/
51. WITHOUT ROLES AND PROFILES node base {
include mycompany::settings
}
node www inherits base {
include apache
include mysql
include php
include nagios::web_server
}
node ns1 inherits base {
include bind
include nagios::bind
bind::zone { ‘example.com': type => master }
}
node ns2 inherits base {
include bind
include nagios::bind
bind::zone { ‘example.com': type => slave }
}
Base node includes common modules
Nodes inherit the base to get common functionality
More specific functionality is added in each node statement
Problems
This file can get really long, really fast
Can violate DRY when you have lots of similar nodes
Edge cases are hard to manage
Node ModulesModules ResourcesResources
52. ROLES AND PROFILES TERMINOLOGY
➤ Module: implements one piece of software or functionality
➤ Profile: combines modules to implement a stack (i.e. “A LAMP stack includes the
apache, mysql, and php modules”)
➤ Role: combine profiles to implement your business rules (i.e. “This server is a web
server”)
➤ A node can only ever include one role
➤ If you think you need to include two roles, you’ve probably just identified another
role
Node ModulesModules ResourcesResourcesRole ModulesProfiles
53. CONVERTING TO ROLES AND PROFILES
class roles::base {
include profiles::base
}
class roles::web_server {
include profiles::base
include profiles::lamp
}
class roles::nameserver::master inherits roles::base {
include profiles::bind::master
}
class roles::nameserver::slave inherits roles::base {
include profiles::bind::slave
}
class profiles::base {
include mycompany::settings
}
class profiles::lamp {
include apache
include mysql
include php
include nagios::web_server
}
class profiles::bind ($type = master) {
include bind
bind::zone { 'example.com':
type => $type,
}
}
class profiles::bind::master {
include profiles::bind
}
class profiles::bind::slave {
class { 'profiles::bind':
type => slave,
}
}
54. CONVERTING TO ROLES AND PROFILES
node www {
include roles::web_server
}
node ns1 {
include roles::nameserver::master
}
node ns2 {
include roles::nameserver::slave
}
node base {
include mycompany::settings
}
node www inherits base {
include apache
include mysql
include php
include nagios::web_server
}
node ns1 inherits base {
include bind
include nagios::bind
bind::zone { ‘example.com': type => master }
}
node ns2 inherits base {
include bind
include nagios::bind
bind::zone { ‘example.com': type => slave }
}
56. ABOUT THE FACTORY PATTERN
➤ Problem: your module has to create a lot of resources of the same type, or you want
to control how resources are created with your module
➤ Solution: create the resources in your class based on data passed to your parameters
57. ABOUT THE FACTORY PATTERN
➤ This is also known as the create_resources pattern
➤ Emerged early on as crude iteration support in older Puppet versions
➤ We already saw this in action in the Resource Wrapper Pattern example
➤ Use this pattern when you want your module to have a single entry point, even for
creating your own resources
58. EXAMPLE: MANAGING CONFIGURATION WITH INI_SETTING
class puppet (
$ca_server = 'puppet-ca.example.com',
$master = 'puppet.example.com',
$pluginsync = true,
$noop = false,
) {
$defaults = { 'path' => '/etc/puppet/puppet.conf' }
$main_section = {
'main/ca_server' => { 'setting' => 'ca_server', 'value' => $ca_server },
'main/server' => { 'setting' => 'server', 'value' => $master },
}
$agent_section = {
'agent/pluginsync' => { 'setting' => 'pluginsync', 'value' => $pluginsync },
'agent/noop' => { 'setting' => 'noop', 'value' => $noop },
}
create_resources('ini_setting', $main_section, merge($defaults, { section => 'main' }))
create_resources('ini_setting', $agent_section, merge($defaults, { section => 'agent' }))
}
Get data from params
Organize the data so
we can consume it
with create_resources
Pass the munged data
to create_resources
59. EXAMPLE: MANAGING CONFIGURATION WITH INI_SETTING (PUPPET 4)
class puppet (
String $path = '/etc/puppet/puppet.conf',
Hash $main_section = {
'ca_server' => 'puppet-ca.example.com',
'server' => 'puppet.example.com'
},
Hash $agent_section = {
'pluginsync' => true,
'noop' => false,
},
) {
['agent', 'main'].each |$section| {
$data = getvar("${section}_section")
$data.each |$key,$val| {
ini_setting { "${section}/${key}":
path => $path,
section => $section,
setting => $key,
value => $val,
}
}
}
}
Pass a hash for each section
Iterate over each section name
Fetch the variable that holds that section’s data
Iterate over that data, passing it to an
ini_setting resource
62. CONTACT INFO
➤ @djdanzilio on Twitter
➤ danzilio on Freenode (you can usually
find me in #voxpupuli, #puppet-dev, and
#puppet)
➤ danzilio on GitHub and The Forge
➤ ddanzilio (at) kovarus (dot) com
➤ blog.danzil.io
➤ www.kovarus.com