This document provides an overview of Ansible and Drupal. It begins with a list of the top 10 open source projects in 2014, which includes Ansible and Drupal. It then covers some Ansible basics like its goals of not logging into servers and making configurations idempotent. The document outlines common Ansible structures like modules, playbooks, roles and projects. It provides examples of using Vagrant and Ansible together and calling Ansible modules. Overall, the document serves as an introduction to Ansible and how it can be used to manage Drupal configurations.
This document provides tips and tricks for using Ansible more effectively. It discusses best practices for inventory structure and variable organization. The key points are:
- Inventory structure and variable organization should make sense for your environment rather than following a "one size fits all" approach. Context is important.
- Variables can be defined in many places like inventory files, group variables, host variables, role defaults etc. and Ansible has a precedence order for variables.
- Playbooks can be made to run tasks in parallel using tools like parallel or by running tasks asynchronously to improve performance for non-serial tasks.
Ansible 2.0 includes many new features and improvements such as a revamped core, better error handling, improved inheritance models, new strategies, dynamic includes, refreshed inventory, and additional plugins. It summarizes some of the key new capabilities in Ansible 2.0 and notes that future releases will focus on continued bug fixes, bringing Windows fully out of beta, increased networking support, and improving the community process.
Chef - industrialize and automate your infrastructureMichaël Lopez
This document compares configuration management tools Puppet, Ansible, and Chef. It discusses their approaches, languages, stored data formats, use of agents, and provides examples of configuration in each. Chef uses Ruby and JSON files, supports hierarchical execution and searching, and can run with or without a server. Puppet uses Ruby, YAML files and dependency-based configuration. Ansible is agentless and uses YAML files and Python plugins.
V2 of Ansible aims to address technical debt that made the framework difficult to maintain and improve. Key features of V2 include improved error messages, blocks for task grouping, new execution strategies, and better support for variables and object-oriented programming. The changes are designed to be backwards compatible with playbooks while improving testability and flexibility for future development. V2 is currently in development with an expected release in July 2015.
Drupal Camp Brighton 2015: Ansible Drupal Medicine showGeorge Boobyer
In this session we are going to look at the latest craze amongst developers with some Sysadmin responsibilities - Ansible.
As with all trending technologies you can be led to believe that it is the new wonder drug (multi purpose in a jar - if you ain't ill it will fix your car). But in this case we will look at some of the key ways that automated provisioning, configuration and state management can actually cure some of the critical headaches you face securing and managing production infrastructure and Drupal sites - (as with all such wonder drugs seek the advice of your GP before radically changing your lifestyle). Also as a warning once you start delving deeper into the world of web security you'll need a pretty thick skin - denial was a comfortable place to be. We won’t be covering Ansible for use in local development with systems such as VLAD - that hopefully will be the subject of other presentations.
Critically we are going to look at Ansible in a Drupal context with a focus on security and hopefully encourage participation in the development of tighter integration with Drupal site deployment and management as well as security defence measures.
By the end of the session we hope to have been convinced that with the adoption of Ansible you will feel more secure, more efficient and more relaxed about managing your infrastructure and sites and also to show how the principles of collaboration common within the Drupal community can transpose with great effect to the Ansible community . Code examples will be provided to support the topics covered.
This document summarizes a presentation about hacking Ansible to make it more customizable. It discusses how Ansible's plugin system allows it to be extended through modules, filters, lookups, callbacks and caches. Examples are provided of extending Ansible's core functionality by modifying files in the lib directory and writing custom plugins. The presentation also outlines how Ansible's object model works and provides an overview of its growth in modules and plugins over time.
Shared Object images in Docker: What you need is what you want.Workhorse Computing
Docker images require appropriate shared object files (".so") to run. Rather than assume Ubuntu has the correct lib's, use ldd to get a list and install the ones you know you need. This can reduce the underlying images from GB to a few MB.
This document provides tips and tricks for using Ansible more effectively. It discusses best practices for inventory structure and variable organization. The key points are:
- Inventory structure and variable organization should make sense for your environment rather than following a "one size fits all" approach. Context is important.
- Variables can be defined in many places like inventory files, group variables, host variables, role defaults etc. and Ansible has a precedence order for variables.
- Playbooks can be made to run tasks in parallel using tools like parallel or by running tasks asynchronously to improve performance for non-serial tasks.
Ansible 2.0 includes many new features and improvements such as a revamped core, better error handling, improved inheritance models, new strategies, dynamic includes, refreshed inventory, and additional plugins. It summarizes some of the key new capabilities in Ansible 2.0 and notes that future releases will focus on continued bug fixes, bringing Windows fully out of beta, increased networking support, and improving the community process.
Chef - industrialize and automate your infrastructureMichaël Lopez
This document compares configuration management tools Puppet, Ansible, and Chef. It discusses their approaches, languages, stored data formats, use of agents, and provides examples of configuration in each. Chef uses Ruby and JSON files, supports hierarchical execution and searching, and can run with or without a server. Puppet uses Ruby, YAML files and dependency-based configuration. Ansible is agentless and uses YAML files and Python plugins.
V2 of Ansible aims to address technical debt that made the framework difficult to maintain and improve. Key features of V2 include improved error messages, blocks for task grouping, new execution strategies, and better support for variables and object-oriented programming. The changes are designed to be backwards compatible with playbooks while improving testability and flexibility for future development. V2 is currently in development with an expected release in July 2015.
Drupal Camp Brighton 2015: Ansible Drupal Medicine showGeorge Boobyer
In this session we are going to look at the latest craze amongst developers with some Sysadmin responsibilities - Ansible.
As with all trending technologies you can be led to believe that it is the new wonder drug (multi purpose in a jar - if you ain't ill it will fix your car). But in this case we will look at some of the key ways that automated provisioning, configuration and state management can actually cure some of the critical headaches you face securing and managing production infrastructure and Drupal sites - (as with all such wonder drugs seek the advice of your GP before radically changing your lifestyle). Also as a warning once you start delving deeper into the world of web security you'll need a pretty thick skin - denial was a comfortable place to be. We won’t be covering Ansible for use in local development with systems such as VLAD - that hopefully will be the subject of other presentations.
Critically we are going to look at Ansible in a Drupal context with a focus on security and hopefully encourage participation in the development of tighter integration with Drupal site deployment and management as well as security defence measures.
By the end of the session we hope to have been convinced that with the adoption of Ansible you will feel more secure, more efficient and more relaxed about managing your infrastructure and sites and also to show how the principles of collaboration common within the Drupal community can transpose with great effect to the Ansible community . Code examples will be provided to support the topics covered.
This document summarizes a presentation about hacking Ansible to make it more customizable. It discusses how Ansible's plugin system allows it to be extended through modules, filters, lookups, callbacks and caches. Examples are provided of extending Ansible's core functionality by modifying files in the lib directory and writing custom plugins. The presentation also outlines how Ansible's object model works and provides an overview of its growth in modules and plugins over time.
Shared Object images in Docker: What you need is what you want.Workhorse Computing
Docker images require appropriate shared object files (".so") to run. Rather than assume Ubuntu has the correct lib's, use ldd to get a list and install the ones you know you need. This can reduce the underlying images from GB to a few MB.
Making environment for_infrastructure_as_codeSoshi Nemoto
The document provides instructions for setting up an environment for infrastructure as code using tools like Vagrant, Ansible, and Fabric. It details steps to install the necessary tools, create a Vagrant machine, edit configuration files to configure the Vagrant IP address and SSH keys, and then provides a test command to validate the Fabric deployment is working properly.
Take control of your Jenkins jobs via job DSL.Łukasz Proszek
Jenkins jobs can be managed via the GUI, CLI, or script console which become unwieldy for large numbers of jobs. The Jenkins Job DSL plugin allows jobs to be defined and maintained as code using a Groovy domain-specific language. This provides benefits such as version control of job configuration, reuse of common job properties, and programmatic job creation. A seed job can be used to generate other jobs from DSL scripts checked into a code repository and run validation/testing.
Using Test Kitchen for testing Chef cookbooksTimur Batyrshin
Using Test Kitchen and ChefDK, one can test Chef cookbooks across multiple platforms. Key steps include:
1. Installing Chefdk, Docker and generating a new cookbook with boilerplate files and tests.
2. Configuring .kitchen.yml to define platforms, suites, attributes, and dependencies.
3. Adding nodes, data bags, and environments to test integration.
4. Iteratively developing code and running kitchen create, converge, verify on instances to test changes, and finally kitchen test to run all suites and platforms.
This document provides troubleshooting information for Puppet failures. It begins with common failure messages and their potential causes such as "can't find puppet", "can't connect to puppet", and "can't get certificate". It then covers tools for investigating failures like the Puppet REST API, debugging Puppet compiles and applies, and checking for issues via notify resources and debug scripts. The document outlines techniques for locating problems with nodes, workers, variables, and resources conflicting or going stale.
Ansible can be used to summarize documents in 3 sentences or less:
1) The document provides tips and tricks for using Ansible for tasks like automation, orchestration, and distributed batch execution across multiple hosts.
2) It also demonstrates how Ansible can be used for auditing changes to files and system configuration over time through plugins, callbacks, and other extensions.
3) Additionally, the document shows how Ansible can be customized and expanded through techniques like abstracting packages and configurations, creating custom modules, and executing tasks in a more programmatic way.
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.
This document provides tips and tricks for writing Ansible roles, including:
1. It recommends using 'ansible-galaxy init' to automatically generate the directory structure for a role, rather than manually creating files and folders.
2. It describes how to specify role dependencies in the metadata file and how tags and conditionals also apply to dependent roles.
3. It discusses best practices for creating cross-platform roles by using conditionals, includes, and set_facts to target tasks and variables depending on operating system.
The document describes the author's experience deploying and configuring Varnish caching at Opera over many years. Some key points discussed include:
- Initial deployment in 2009 caching static assets for My Opera, which grew to serve 15% of requests
- Troubleshooting issues like session mixing and unauthorized access
- Implementing caching for dynamic pages like the front page while respecting cookies and languages
- Decentralizing caching to multiple data centers for lower latency globally
- Generating and caching thumbnails on-the-fly to handle frequent design changes
- Developing a more generic "shields-up" configuration to cache unpopular content securely
- Ongoing work caching APIs and content on other
Using docker for data science - part 2Calvin Giles
A lightning talk for PyData London (http://www.meetup.com/PyData-London-Meetup/) on using docker and fig to manage your data science development environment.
Chef Workshop: Setup Environment with Chef,Vagrant, and BerkshelfJun Sakata
The document provides an introduction and agenda for a Chef developers' workshop. It outlines the prerequisites including VirtualBox, Vagrant, and Chef. It then covers two parts: 1) getting started with Chef using Vagrant including creating a cookbook and recipes, and 2) exploring the structure of Chef including cookbooks, recipes, attributes and resources. The objectives are to learn the basics of Chef, be able to use Chef to create infrastructure code, and build one's own cookbook.
2012 coscup - Build your PHP application on Herokuronnywang_tw
The document discusses deploying PHP applications on Heroku. It provides an overview of Heroku, including that it is a Platform-as-a-Service, was launched in 2007, uses Amazon Web Services, offers many add-ons, allows easy scaling, supports PostgreSQL, and offers some free usage. It then walks through deploying a basic "Hello World" PHP app on Heroku, including creating an app, adding code, committing and pushing to Heroku, and viewing the deployed app.
Using python and docker for data scienceCalvin Giles
PyData London meetup group lightning talk slides on getting an ipython notebook with the scipy stack and custom packages running in a notebook server in 5 minutes.
This document discusses Puppet modules and provides examples of how to structure modules to allow for customization and reuse. It outlines 10 design rules for Example42 modules, including separating configuration data from module logic, providing choices for configuration file supply, configuring with defaults but allowing customization, and allowing management of general module behavior. The document provides code examples demonstrating how to implement these rules in Puppet modules.
DevOps Hackathon: Session 3 - Test Driven InfrastructureAntons Kranga
We will assume that you already familiar with Vagrant and Chef fundamentals described in session 1 and 2. Today we will go through TestKitchen and ServerSpec. While chef-dk is not stable, this is most reliable path.
Practical activities can be found here:
https://github.com/akranga/devops-hackathon-3
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.
Oliver Hookins presents on Nokia's use of Puppet for application deployment and automation. Some key points:
- Nokia uses Puppet to deploy diverse applications across environments in a consistent way and reduce errors.
- The initial Puppet system led to new problems around node definitions and lack of testing. They aimed to improve with BDD, better versioning, and more testing.
- Their goals included taking a more traditional software development approach, improving developer tools, and enabling easier deployments.
- Current work includes improving testing with Jenkins, moving to an API approach to remove host/role specifics, and developing an ENC.
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.
Ansible, Simplicity, and the Zen of Pythontoddmowen
Slides from the following talk presented at PyCon Australia 2015:
https://www.youtube.com/watch?v=JlrkizEBjXk
Ansible is a configuration management tool, written in Python, that has taken the world of IT automation by storm. Its most remarkable quality is simplicity.
The Zen of Python is a set of aphorisms which capture the design philosophy of the Python language, one being "Simple is better than complex".
This document describes an Ansible role for deploying projects. It discusses the need for continuous deployment, easy maintenance, and reuse of deploy procedures between projects. It then provides details on the role, including example variables, tasks to update code, install dependencies, handle shared resources, build, and finalize deployments. An example playbook demonstrates how to use the role to deploy a Symfony application to production.
The document discusses using Docker and configuration management tools like Ansible and Chef together. It provides examples of building Docker images from code using tools like SBT and Maven. It also describes using Ansible playbooks and Chef recipes to automate pulling, running and managing Docker containers. Configuration files and credentials can be handled securely. Overall, the document shows how Docker and configuration management can be integrated to provide an automated and flexible deployment pipeline.
Making environment for_infrastructure_as_codeSoshi Nemoto
The document provides instructions for setting up an environment for infrastructure as code using tools like Vagrant, Ansible, and Fabric. It details steps to install the necessary tools, create a Vagrant machine, edit configuration files to configure the Vagrant IP address and SSH keys, and then provides a test command to validate the Fabric deployment is working properly.
Take control of your Jenkins jobs via job DSL.Łukasz Proszek
Jenkins jobs can be managed via the GUI, CLI, or script console which become unwieldy for large numbers of jobs. The Jenkins Job DSL plugin allows jobs to be defined and maintained as code using a Groovy domain-specific language. This provides benefits such as version control of job configuration, reuse of common job properties, and programmatic job creation. A seed job can be used to generate other jobs from DSL scripts checked into a code repository and run validation/testing.
Using Test Kitchen for testing Chef cookbooksTimur Batyrshin
Using Test Kitchen and ChefDK, one can test Chef cookbooks across multiple platforms. Key steps include:
1. Installing Chefdk, Docker and generating a new cookbook with boilerplate files and tests.
2. Configuring .kitchen.yml to define platforms, suites, attributes, and dependencies.
3. Adding nodes, data bags, and environments to test integration.
4. Iteratively developing code and running kitchen create, converge, verify on instances to test changes, and finally kitchen test to run all suites and platforms.
This document provides troubleshooting information for Puppet failures. It begins with common failure messages and their potential causes such as "can't find puppet", "can't connect to puppet", and "can't get certificate". It then covers tools for investigating failures like the Puppet REST API, debugging Puppet compiles and applies, and checking for issues via notify resources and debug scripts. The document outlines techniques for locating problems with nodes, workers, variables, and resources conflicting or going stale.
Ansible can be used to summarize documents in 3 sentences or less:
1) The document provides tips and tricks for using Ansible for tasks like automation, orchestration, and distributed batch execution across multiple hosts.
2) It also demonstrates how Ansible can be used for auditing changes to files and system configuration over time through plugins, callbacks, and other extensions.
3) Additionally, the document shows how Ansible can be customized and expanded through techniques like abstracting packages and configurations, creating custom modules, and executing tasks in a more programmatic way.
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.
This document provides tips and tricks for writing Ansible roles, including:
1. It recommends using 'ansible-galaxy init' to automatically generate the directory structure for a role, rather than manually creating files and folders.
2. It describes how to specify role dependencies in the metadata file and how tags and conditionals also apply to dependent roles.
3. It discusses best practices for creating cross-platform roles by using conditionals, includes, and set_facts to target tasks and variables depending on operating system.
The document describes the author's experience deploying and configuring Varnish caching at Opera over many years. Some key points discussed include:
- Initial deployment in 2009 caching static assets for My Opera, which grew to serve 15% of requests
- Troubleshooting issues like session mixing and unauthorized access
- Implementing caching for dynamic pages like the front page while respecting cookies and languages
- Decentralizing caching to multiple data centers for lower latency globally
- Generating and caching thumbnails on-the-fly to handle frequent design changes
- Developing a more generic "shields-up" configuration to cache unpopular content securely
- Ongoing work caching APIs and content on other
Using docker for data science - part 2Calvin Giles
A lightning talk for PyData London (http://www.meetup.com/PyData-London-Meetup/) on using docker and fig to manage your data science development environment.
Chef Workshop: Setup Environment with Chef,Vagrant, and BerkshelfJun Sakata
The document provides an introduction and agenda for a Chef developers' workshop. It outlines the prerequisites including VirtualBox, Vagrant, and Chef. It then covers two parts: 1) getting started with Chef using Vagrant including creating a cookbook and recipes, and 2) exploring the structure of Chef including cookbooks, recipes, attributes and resources. The objectives are to learn the basics of Chef, be able to use Chef to create infrastructure code, and build one's own cookbook.
2012 coscup - Build your PHP application on Herokuronnywang_tw
The document discusses deploying PHP applications on Heroku. It provides an overview of Heroku, including that it is a Platform-as-a-Service, was launched in 2007, uses Amazon Web Services, offers many add-ons, allows easy scaling, supports PostgreSQL, and offers some free usage. It then walks through deploying a basic "Hello World" PHP app on Heroku, including creating an app, adding code, committing and pushing to Heroku, and viewing the deployed app.
Using python and docker for data scienceCalvin Giles
PyData London meetup group lightning talk slides on getting an ipython notebook with the scipy stack and custom packages running in a notebook server in 5 minutes.
This document discusses Puppet modules and provides examples of how to structure modules to allow for customization and reuse. It outlines 10 design rules for Example42 modules, including separating configuration data from module logic, providing choices for configuration file supply, configuring with defaults but allowing customization, and allowing management of general module behavior. The document provides code examples demonstrating how to implement these rules in Puppet modules.
DevOps Hackathon: Session 3 - Test Driven InfrastructureAntons Kranga
We will assume that you already familiar with Vagrant and Chef fundamentals described in session 1 and 2. Today we will go through TestKitchen and ServerSpec. While chef-dk is not stable, this is most reliable path.
Practical activities can be found here:
https://github.com/akranga/devops-hackathon-3
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.
Oliver Hookins presents on Nokia's use of Puppet for application deployment and automation. Some key points:
- Nokia uses Puppet to deploy diverse applications across environments in a consistent way and reduce errors.
- The initial Puppet system led to new problems around node definitions and lack of testing. They aimed to improve with BDD, better versioning, and more testing.
- Their goals included taking a more traditional software development approach, improving developer tools, and enabling easier deployments.
- Current work includes improving testing with Jenkins, moving to an API approach to remove host/role specifics, and developing an ENC.
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.
Ansible, Simplicity, and the Zen of Pythontoddmowen
Slides from the following talk presented at PyCon Australia 2015:
https://www.youtube.com/watch?v=JlrkizEBjXk
Ansible is a configuration management tool, written in Python, that has taken the world of IT automation by storm. Its most remarkable quality is simplicity.
The Zen of Python is a set of aphorisms which capture the design philosophy of the Python language, one being "Simple is better than complex".
This document describes an Ansible role for deploying projects. It discusses the need for continuous deployment, easy maintenance, and reuse of deploy procedures between projects. It then provides details on the role, including example variables, tasks to update code, install dependencies, handle shared resources, build, and finalize deployments. An example playbook demonstrates how to use the role to deploy a Symfony application to production.
The document discusses using Docker and configuration management tools like Ansible and Chef together. It provides examples of building Docker images from code using tools like SBT and Maven. It also describes using Ansible playbooks and Chef recipes to automate pulling, running and managing Docker containers. Configuration files and credentials can be handled securely. Overall, the document shows how Docker and configuration management can be integrated to provide an automated and flexible deployment pipeline.
Ansible has huge potential, also working with docker. These slides give an introduction to how Ansible works and can be used to automate and improve your infrastructure setup.
This document discusses best practices for using Ansible for automation and configuration management. It recommends writing reusable roles with atomic and well-parameterized configuration, keeping roles in separate Git repositories, and using defaults instead of variables where possible. It also presents three patterns for using Ansible: a single playbook with hierarchical variables, configuration encoders to support multiple file formats, and using an Android repo script to manage multiple environments and versions of roles continuously.
Short Introduction to Docker. These slides show the basic idea behind the container technology Docker. The slides present the basic features for the daily use with Docker, Docker Compose, Docker Machine and Docker Swarm.
Docker is specially important for DevOps, because it gives Software Developers more control about their dependencies in different environments.
Ansible is tool for Configuration Management. The big difference to Chef and Puppet is, that Ansible doesn't need a Master and doesn't need a special client on the servers. It works completely via SSH and the configuration is done in Yaml.
These slides give a short introduction & motivation for Ansible.
The document outlines an 90 minute introduction to Ansible using Docker. It discusses setting up the environment with Docker, using ad-hoc commands and playbooks to automate tasks like installing Apache and configuring variables. Exercises demonstrate inventory management, templating configurations with Jinja2, and other core Ansible concepts. The document provides an overview but does not cover more advanced topics like dynamic inventory, roles, writing custom modules, or Ansible Tower.
Zero Downtime Deployment with Ansible - learn how to provision Linux servers with a web-proxy, a database and automate zero downtime deployment of a Java application to a load balanced environment.
These are the slides from a tutorial held at the Velocity Conference in Barcelona November 19th, 2014.
Git repo: https://github.com/steinim/zero-downtime-ansible
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.
Code testing and Continuous Integration are just the first step in a source code to production process. Combined with infrastructure-as-code tools such as Puppet the whole process can be automated, and tested!
The document discusses building a lightweight Docker container for Perl by starting with a minimal base image like BusyBox, copying just the Perl installation and necessary shared libraries into the container, and setting Perl as the default command to avoid including unnecessary dependencies and tools from a full Linux distribution. It provides examples of Dockerfiles to build optimized Perl containers from Gentoo and by directly importing a tarball for minimal size and easy distribution.
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.
Kris Buytaert discusses how they used Vagrant, Puppet, and other tools to improve their Puppet development and testing workflow. Some key points:
- Vagrant allows creating reproducible development environments for Puppet code.
- Puppet style guides help write more readable manifests. Tools like Puppet Lint can validate style.
- Testing Puppet code with rspec-puppet, cucumber-puppet, and other tools helps prevent errors.
- Using Git, GitHub, and Git flow practices helps manage Puppet modules in version control.
- Jenkins can automate building, testing, and deploying Puppet code and modules.
- Demonstr
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.
Vagrant is a well-known tool for creating development environments in a simple and consistent way. Since we adopted in our organization we experienced several benefits: lower project setup times, better shared knowledge among team members, less wtf moments ;-)
In this session I'd like to share our experience, including but not limited to:
- advanced vagrantfile configuration
- vm configuration tips for dev environment: performance, debug, tuning
- our wtf moments
- puphet/phansilbe: hot or not?
- tips for sharing a box
Be a happier developer with Docker: Tricks of the tradeNicola Paolucci
This document provides an overview of how Docker can make developers happy by providing clean and perfect development environments, fast application mobility and repeatability, and enabling great collaboration through microservices architecture. It then discusses various workflows and techniques for using Docker, including developing inside a single running container, leveraging containers to modularize code, reusing Dockerfiles, sharing data between containers through volumes, accessing Docker in a VM through methods like NFS or Samba, using linked containers for simple service connections, and opening ports on containers using techniques like port forwarding, VBoxManage port exposure, and iptables.
A revamped version of the Ansible intro talk from February 2015, brought up-to-date for the January Ansible meetup in Berlin.
Join our group: https://www.meetup.com/Ansible-Berlin
How to make debian package from scratch (linux)Thierry Gayet
- The document discusses two methods for creating Debian packages: using dpkg-deb or dpkg-buildpackage.
- It provides step-by-step instructions for creating the package directory structure, metadata files, building and installing the package, and verifying installation.
- An alternative method using dh_make is also presented, which simplifies the process by automatically generating basic packaging files and directories.
More info at http://blog.carlossanchez.eu/tag/devops
Video en español: http://youtu.be/E_OE4l3t5BA
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.
Be a Happier Developer with Docker: Tricks of the TradeDocker, Inc.
This document discusses various workflows and techniques for using Docker, including:
- Developing inside a single running container for a simplified development environment
- Leveraging containers to modularize code and applications into reusable components
- Sharing data between containers and hosts using volumes to mount folders
- Accessing containers running in virtual machines through NFS, Samba, or by patching boot2docker
- Linking containers to simplify connections between services
- Exposing ports from containers to hosts through port forwarding or iptables rules
AI in the Workplace Reskilling, Upskilling, and Future Work.pptxSunil Jagani
Discover how AI is transforming the workplace and learn strategies for reskilling and upskilling employees to stay ahead. This comprehensive guide covers the impact of AI on jobs, essential skills for the future, and successful case studies from industry leaders. Embrace AI-driven changes, foster continuous learning, and build a future-ready workforce.
Read More - https://bit.ly/3VKly70
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Keywords: AI, Containeres, Kubernetes, Cloud Native
Event Link: https://meine.doag.org/events/cloudland/2024/agenda/#agendaId.4211
The Microsoft 365 Migration Tutorial For Beginner.pptxoperationspcvita
This presentation will help you understand the power of Microsoft 365. However, we have mentioned every productivity app included in Office 365. Additionally, we have suggested the migration situation related to Office 365 and how we can help you.
You can also read: https://www.systoolsgroup.com/updates/office-365-tenant-to-tenant-migration-step-by-step-complete-guide/
Discover the Unseen: Tailored Recommendation of Unwatched ContentScyllaDB
The session shares how JioCinema approaches ""watch discounting."" This capability ensures that if a user watched a certain amount of a show/movie, the platform no longer recommends that particular content to the user. Flawless operation of this feature promotes the discover of new content, improving the overall user experience.
JioCinema is an Indian over-the-top media streaming service owned by Viacom18.
AppSec PNW: Android and iOS Application Security with MobSFAjin Abraham
Mobile Security Framework - MobSF is a free and open source automated mobile application security testing environment designed to help security engineers, researchers, developers, and penetration testers to identify security vulnerabilities, malicious behaviours and privacy concerns in mobile applications using static and dynamic analysis. It supports all the popular mobile application binaries and source code formats built for Android and iOS devices. In addition to automated security assessment, it also offers an interactive testing environment to build and execute scenario based test/fuzz cases against the application.
This talk covers:
Using MobSF for static analysis of mobile applications.
Interactive dynamic security assessment of Android and iOS applications.
Solving Mobile app CTF challenges.
Reverse engineering and runtime analysis of Mobile malware.
How to shift left and integrate MobSF/mobsfscan SAST and DAST in your build pipeline.
Northern Engraving | Nameplate Manufacturing Process - 2024Northern Engraving
Manufacturing custom quality metal nameplates and badges involves several standard operations. Processes include sheet prep, lithography, screening, coating, punch press and inspection. All decoration is completed in the flat sheet with adhesive and tooling operations following. The possibilities for creating unique durable nameplates are endless. How will you create your brand identity? We can help!
Northern Engraving | Modern Metal Trim, Nameplates and Appliance PanelsNorthern Engraving
What began over 115 years ago as a supplier of precision gauges to the automotive industry has evolved into being an industry leader in the manufacture of product branding, automotive cockpit trim and decorative appliance trim. Value-added services include in-house Design, Engineering, Program Management, Test Lab and Tool Shops.
"NATO Hackathon Winner: AI-Powered Drug Search", Taras KlobaFwdays
This is a session that details how PostgreSQL's features and Azure AI Services can be effectively used to significantly enhance the search functionality in any application.
In this session, we'll share insights on how we used PostgreSQL to facilitate precise searches across multiple fields in our mobile application. The techniques include using LIKE and ILIKE operators and integrating a trigram-based search to handle potential misspellings, thereby increasing the search accuracy.
We'll also discuss how the azure_ai extension on PostgreSQL databases in Azure and Azure AI Services were utilized to create vectors from user input, a feature beneficial when users wish to find specific items based on text prompts. While our application's case study involves a drug search, the techniques and principles shared in this session can be adapted to improve search functionality in a wide range of applications. Join us to learn how PostgreSQL and Azure AI can be harnessed to enhance your application's search capability.
inQuba Webinar Mastering Customer Journey Management with Dr Graham HillLizaNolte
HERE IS YOUR WEBINAR CONTENT! 'Mastering Customer Journey Management with Dr. Graham Hill'. We hope you find the webinar recording both insightful and enjoyable.
In this webinar, we explored essential aspects of Customer Journey Management and personalization. Here’s a summary of the key insights and topics discussed:
Key Takeaways:
Understanding the Customer Journey: Dr. Hill emphasized the importance of mapping and understanding the complete customer journey to identify touchpoints and opportunities for improvement.
Personalization Strategies: We discussed how to leverage data and insights to create personalized experiences that resonate with customers.
Technology Integration: Insights were shared on how inQuba’s advanced technology can streamline customer interactions and drive operational efficiency.
ScyllaDB is making a major architecture shift. We’re moving from vNode replication to tablets – fragments of tables that are distributed independently, enabling dynamic data distribution and extreme elasticity. In this keynote, ScyllaDB co-founder and CTO Avi Kivity explains the reason for this shift, provides a look at the implementation and roadmap, and shares how this shift benefits ScyllaDB users.
Introducing BoxLang : A new JVM language for productivity and modularity!Ortus Solutions, Corp
Just like life, our code must adapt to the ever changing world we live in. From one day coding for the web, to the next for our tablets or APIs or for running serverless applications. Multi-runtime development is the future of coding, the future is to be dynamic. Let us introduce you to BoxLang.
Dynamic. Modular. Productive.
BoxLang redefines development with its dynamic nature, empowering developers to craft expressive and functional code effortlessly. Its modular architecture prioritizes flexibility, allowing for seamless integration into existing ecosystems.
Interoperability at its Core
With 100% interoperability with Java, BoxLang seamlessly bridges the gap between traditional and modern development paradigms, unlocking new possibilities for innovation and collaboration.
Multi-Runtime
From the tiny 2m operating system binary to running on our pure Java web server, CommandBox, Jakarta EE, AWS Lambda, Microsoft Functions, Web Assembly, Android and more. BoxLang has been designed to enhance and adapt according to it's runnable runtime.
The Fusion of Modernity and Tradition
Experience the fusion of modern features inspired by CFML, Node, Ruby, Kotlin, Java, and Clojure, combined with the familiarity of Java bytecode compilation, making BoxLang a language of choice for forward-thinking developers.
Empowering Transition with Transpiler Support
Transitioning from CFML to BoxLang is seamless with our JIT transpiler, facilitating smooth migration and preserving existing code investments.
Unlocking Creativity with IDE Tools
Unleash your creativity with powerful IDE tools tailored for BoxLang, providing an intuitive development experience and streamlining your workflow. Join us as we embark on a journey to redefine JVM development. Welcome to the era of BoxLang.
Session 1 - Intro to Robotic Process Automation.pdfUiPathCommunity
👉 Check out our full 'Africa Series - Automation Student Developers (EN)' page to register for the full program:
https://bit.ly/Automation_Student_Kickstart
In this session, we shall introduce you to the world of automation, the UiPath Platform, and guide you on how to install and setup UiPath Studio on your Windows PC.
📕 Detailed agenda:
What is RPA? Benefits of RPA?
RPA Applications
The UiPath End-to-End Automation Platform
UiPath Studio CE Installation and Setup
💻 Extra training through UiPath Academy:
Introduction to Automation
UiPath Business Automation Platform
Explore automation development with UiPath Studio
👉 Register here for our upcoming Session 2 on June 20: Introduction to UiPath Studio Fundamentals: https://community.uipath.com/events/details/uipath-lagos-presents-session-2-introduction-to-uipath-studio-fundamentals/
What is an RPA CoE? Session 2 – CoE RolesDianaGray10
In this session, we will review the players involved in the CoE and how each role impacts opportunities.
Topics covered:
• What roles are essential?
• What place in the automation journey does each role play?
Speaker:
Chris Bolin, Senior Intelligent Automation Architect Anika Systems
Must Know Postgres Extension for DBA and Developer during MigrationMydbops
Mydbops Opensource Database Meetup 16
Topic: Must-Know PostgreSQL Extensions for Developers and DBAs During Migration
Speaker: Deepak Mahto, Founder of DataCloudGaze Consulting
Date & Time: 8th June | 10 AM - 1 PM IST
Venue: Bangalore International Centre, Bangalore
Abstract: Discover how PostgreSQL extensions can be your secret weapon! This talk explores how key extensions enhance database capabilities and streamline the migration process for users moving from other relational databases like Oracle.
Key Takeaways:
* Learn about crucial extensions like oracle_fdw, pgtt, and pg_audit that ease migration complexities.
* Gain valuable strategies for implementing these extensions in PostgreSQL to achieve license freedom.
* Discover how these key extensions can empower both developers and DBAs during the migration process.
* Don't miss this chance to gain practical knowledge from an industry expert and stay updated on the latest open-source database trends.
Mydbops Managed Services specializes in taking the pain out of database management while optimizing performance. Since 2015, we have been providing top-notch support and assistance for the top three open-source databases: MySQL, MongoDB, and PostgreSQL.
Our team offers a wide range of services, including assistance, support, consulting, 24/7 operations, and expertise in all relevant technologies. We help organizations improve their database's performance, scalability, efficiency, and availability.
Contact us: info@mydbops.com
Visit: https://www.mydbops.com/
Follow us on LinkedIn: https://in.linkedin.com/company/mydbops
For more details and updates, please follow up the below links.
Meetup Page : https://www.meetup.com/mydbops-databa...
Twitter: https://twitter.com/mydbopsofficial
Blogs: https://www.mydbops.com/blog/
Facebook(Meta): https://www.facebook.com/mydbops/
5. blue-bag
ANSIBLE & DRUPAL: MEDICINE SHOW
w
Special formula
Requires prescription
Ingredients:
Forked Roles
Custom Roles
Custom Inventory & Vars
Featured multistage Playbook
w
Limited Edition
Ingredients:
multistage playbook
Multiple plays, Forked Roles
Custom Roles, Vault
Plugins & filters,
Complex Inventory & Vars
w
Original Recipe
Available over the counter
Ingredients:
Galaxy Roles
Custom Vars
Simple Playbook
Documentation
6. blue-bag
ANSIBLE & DRUPAL: TOP 10
1. Docker
2. Kubernetes
3. Taiga
4. Apache Mesos
5. OpenStack
6. Ansible
7. ownCloud
8. Apache Hadoop
9. Drupal
10.OpenDaylight
http://opensource.com/business/14/12/
top-10-open-source-projects-2014
Top 10 open source projects in 2014
7. blue-bag
ANSIBLE BASICS
Agentless
Uses SSH
YAML for configuration
Modules
Open source
not just provisioning
“Ansible is a radically simple IT automation system. It handles
configuration-management, application deployment, cloud
provisioning, ad-hoc task-execution, and multinode
orchestration.
Python
Extensible
12. blue-bag
ANSIBLE GOALS
Don’t log into servers
No need for bash scripts
Document build and configuration
(in source control)
Idempotent (idem-what’s-that-again?)
13. blue-bag
ANSIBLE GOALS
Don’t log into servers
No need for bash scripts
Document build and configuration
(in source control)
Idempotent (idem-what’s-that-again?)
Maintain configuration across inventory
14. blue-bag
ANSIBLE GOALS
Don’t log into servers
No need for bash scripts
Document build and configuration
(in source control)
Idempotent (idem-what’s-that-again?)
Maintain configuration across inventory
Retain & share knowledge
31. blue-bag
ANSIBLE BASICS: MODULES
$ ansible-docs -l
…
alternatives Manages alternative programs for common commands
apache2_module enables/disables a module of the Apache2 webserver
apt Manages apt-packages
apt_key Add or remove an apt key
apt_repository Add and remove APT repositories
apt_rpm apt_rpm package manager
assemble Assembles a configuration file from fragments
assert Fail with custom message
at Schedule the execution of a command or script file via
the at command.
authorized_key Adds or removes an SSH authorized key
…
patch Apply patch files using the GNU patch tool.
32. blue-bag
ANSIBLE BASICS: MODULES
$ ansible-docs -s patch
- name: Apply patch files using the GNU patch tool.
action: patch
basedir # Path of a base directory in which the patch file will be applied. May be
omitted when `dest' option is specified, otherwise required.
dest # Path of the file on the remote machine to be patched. The names of the
files to be patched are usually taken from the patch file, but if there's
just one file to be patched it can specified with this
remote_src # If False, it will search for src at originating/master machine, if True it
will go to the remote/target machine for the src. Default is False.
src= # Path of the patch file as accepted by the GNU patch tool.
strip # Number that indicates the smallest prefix containing leading slashes that
will be stripped from each file name found in the patch file. For more
information see the strip parameter of the GNU patch to
Note old syntax!
- name: Apply patch files using the GNU patch tool
patch:
src: /tmp/index.html.patch
dest: /var/www/index.html
33. blue-bag
ANSIBLE / VAGRANT
"## demo
"## Vagrantfile
%## hosts
# -*- mode: ruby -*-
# vi: set ft=ruby :
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.ssh.insert_key = false
config.vm.provider :virtualbox do |vb|
vb.customize ["modifyvm", :id, "--memory", "256"]
end
# Application server 1.
config.vm.define "app1" do |app|
app.vm.hostname = "bbdemo-app1.dev"
app.vm.box = "chef/debian-7.4"
app.vm.network :private_network, ip: "192.168.100.120"
end
# Application server 2.
config.vm.define "app2" do |app|
app.vm.hostname = "bbdemo-app2.dev"
app.vm.box = "chef/debian-7.4"
app.vm.network :private_network, ip: "192.168.100.121"
end
# Database server.
config.vm.define "db" do |db|
db.vm.hostname = "bbdemo-db.dev"
db.vm.box = "chef/debian-7.4"
db.vm.network :private_network, ip: "192.168.100.122"
end
end
# Application servers
[webservers]
192.168.100.120
192.168.100.121
# Database server
[dbservers]
192.168.100.122
# Group 'multi' with all servers
[multi:children]
app
db
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
45. blue-bag
ANSIBLE BASICS: PROJECT STRUCTURE
https://github.com/iAugur/ansible-playbook-template
Use a template for
Ansible projects.
Common structure
Autodiscovery
46. blue-bag
ANSIBLE BASICS: PROJECT STRUCTURE
https://github.com/iAugur/ansible-playbook-template
"## LICENSE
"## README.md
"## ansible.cfg
"## common
& "## handlers
& & %## main.yml
& %## vars
& %## main.yml
"## group_vars
& %## all.yml
"## host_vars
& %## local.yml
"## hosts
"## log
"## playbook.yml
"## roles
%## base
"## README.md
"## defaults
& %## main.yml
"## files
"## handlers
& %## main.yml
"## meta
& %## main.yml
"## tasks
& %## main.yml
"## templates
%## vars
%## main.yml
Use a template for
Ansible projects.
Common structure
Autodiscovery
49. blue-bag
# Application servers
[webservers]
192.168.100.120
192.168.100.121
# Database server
[dbservers]
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
ANSIBLE BASICS: HOSTS & GROUPS
50. blue-bag
# Application servers
[webservers]
192.168.100.120
192.168.100.121
# Database server
[dbservers]
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
# Application servers
[webservers]
bbdemo-app1.dev
bbdemo-app2.dev
192.168.100.120
192.168.100.121
# Database server
[dbservers]
bbdemo-db.dev
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
ANSIBLE BASICS: HOSTS & GROUPS
51. blue-bag
# Application servers
[webservers]
192.168.100.120
192.168.100.121
# Database server
[dbservers]
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
# Application servers
[webservers]
bbdemo-app1.dev
bbdemo-app2.dev
192.168.100.120
192.168.100.121
# Database server
[dbservers]
bbdemo-db.dev
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
# Application servers
[webservers]
bbdemo-app1.dev
bbdemo-app2.dev
# Database server
[dbservers]
bbdemo-db.dev
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
ANSIBLE BASICS: HOSTS & GROUPS
52. blue-bag
# Application servers
[webservers]
192.168.100.120
192.168.100.121
# Database server
[dbservers]
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
# Application servers
[webservers]
bbdemo-app1.dev
bbdemo-app2.dev
192.168.100.120
192.168.100.121
# Database server
[dbservers]
bbdemo-db.dev
192.168.100.122
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
# Variables that will be applied to all
servers"
[multi:vars]
ansible_ssh_user=vagrant
ansible_ssh_private_key_file=~/.vagrant.d/
insecure_private_key
# Application servers
[webservers]
bbdemo-app1.dev
bbdemo-app2.dev
# Database server
[dbservers]
bbdemo-db.dev
# Group 'multi' with all servers
[multi:children]
webservers
dbservers
ANSIBLE BASICS: HOSTS & GROUPS
# ../host_vars/bbdemo-app1.dev
——-
ansible_ssh_host: 192.168.100.120
# ../host_vars/bbdemo-app2.dev
——-
ansible_ssh_host: 192.168.100.121
# ../host_vars/bbdemo-db.dev
——-
ansible_ssh_host: 192.168.100.122
# ../group_vars/all
——-
ansible_ssh_user: vagrant
ansible_ssh_private_key_file: ~/.vagrant.d/
insecure_private_key
# ../group_vars/webservers
——-
http_port: 80
# ../group_vars/dbservers
——-
db_port: 3306
53. blue-bag
ANSIBLE BASICS: LIMITING HOSTS
List Hosts
$ansible-playbook --list-hosts main.yml
Limit to Host
$ansible-playbook --limit app1 main.yml
Limit to group
$ansible-playbook -l webservers main.yml
Limit to set (note quotes!)
$ansible-playbook -l 'multi:!webservers' main.yml
More commonly in a playbook:
- hosts: multi:&dbservers
gather_facts: true
tags: [database_setup]
roles:
- { role: config-db , tags: ["dbserver-base"]}
54. blue-bag
ANSIBLE BASICS: TAGS
- hosts: servers
gather_facts: true
sudo: true
tags: [provision_core]
roles:
- { role: ansible-role-first5base , tags: ['base'], sudo: true }
- name: Set hostname
hostname: name={{ inventory_hostname_short }}
sudo: true
tags:
- configuration
- hosts
In a playbook
In a role / task
59. blue-bag
ANSIBLE BASICS: VARIABLES
Variable Precedence
extra vars (-e in the command line) always win
then comes connection variables defined in inventory (ansible_ssh_user, etc)
then comes "most everything else" (command line switches, vars in play,
included vars, role vars, etc)
then comes the rest of the variables defined in inventory
then comes facts discovered about a system
then "role defaults", which are the most "defaulty" and lose in priority to
everything.
https://docs.ansible.com/playbooks_variables.html
Override once - put variables in sensible places
Role vars
Use defaults as a template for the variables to be overridden
Use vars/main.yml as constants that don't get overridden
e.g. Apache Daemon:
Debian is 'apache2'
Centos is 'httpd'
Role authors - name vars with role name to avoid collisions.
60. blue-bag
ANSIBLE BASICS: VARIABLES
Better to put your vars in one correct place.
Common uses for precedence
role defaults (defaults/main.yml - apache_listen_port:80)
group_vars/all (http_port: 80)
group_vars/webservers (apache_listen_port: "{{http_port}}")
host_vars/web01.example.com (apache_listen_port: "8080")
command line extra vars -e (not so common)
Use Jinja filters (sparingly) - more later ...
62. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
63. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
Ignore any plain text password
files
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
64. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
Ignore any plain text password
files
Use separate files for role vars
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
65. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
Ignore any plain text password
files
Use separate files for role vars
Put all secrets in Ansible Vault
use a pattern: secrets*.yml
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
66. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
Ignore any plain text password
files
Use separate files for role vars
Put all secrets in Ansible Vault
use a pattern: secrets*.yml
Encrypt all secrets:
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
67. blue-bag
ANSIBLE BASICS: VAULT
Put all of your project files in GIT
Ignore any plain text password
files
Use separate files for role vars
Put all secrets in Ansible Vault
use a pattern: secrets*.yml
Encrypt all secrets:
"## all
& "## all.yml
& "## firewall.yml
& "## first5base.yml
& "## first5ntp.yml
& "## first5ssh.yml
& "## first5user.yml
& "## newrelic.yml
& "## secrets-s3cmd.yml
& "## secrets-ssh.yml
& "## secrets-sql.yml
& %## secrets.yml
$ansible-vault encrypt secrets*.yml
69. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
70. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
71. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
Place secrets in vault
$ansible-vault encrypt group_vars/all/secrets.yml
$ansible-vault decrypt group_vars/all/secrets.yml
72. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
Place secrets in vault
$ansible-vault encrypt group_vars/all/secrets.yml
$ansible-vault decrypt group_vars/all/secrets.yml
Automate vault
$ansible-playbook play.yml--ask-vault-pass
$ansible-playbook play.yml--vault-password-file ~/.vault_pass.txt
73. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
Place secrets in vault
$ansible-vault encrypt group_vars/all/secrets.yml
$ansible-vault decrypt group_vars/all/secrets.yml
Automate vault
$ansible-playbook play.yml--ask-vault-pass
$ansible-playbook play.yml--vault-password-file ~/.vault_pass.txt
Add Vault password file location to ansible.cfg
[defaults]
vault_password_file = vault.txt
74. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
Place secrets in vault
$ansible-vault encrypt group_vars/all/secrets.yml
$ansible-vault decrypt group_vars/all/secrets.yml
Automate vault
$ansible-playbook play.yml--ask-vault-pass
$ansible-playbook play.yml--vault-password-file ~/.vault_pass.txt
Add Vault password file location to ansible.cfg
[defaults]
vault_password_file = vault.txt
Run plays as normal
$ansible-playbook playbook.yml
75. blue-bag
ANSIBLE BASICS: VAULT
Create a vault Password file (vault_pass.txt)
gitignore vault password files
add single line with vault password in plain text
Add Sudo password to all/secrets.yml
ansible_sudo_pass: 'ECyDPIm%Jpw5JVIFI@FWX2hLuG'
Place secrets in vault
$ansible-vault encrypt group_vars/all/secrets.yml
$ansible-vault decrypt group_vars/all/secrets.yml
Automate vault
$ansible-playbook play.yml--ask-vault-pass
$ansible-playbook play.yml--vault-password-file ~/.vault_pass.txt
Add Vault password file location to ansible.cfg
[defaults]
vault_password_file = vault.txt
Run plays as normal
$ansible-playbook playbook.yml
Working with teams - use GPG:
http://benincosa.com/?p=3235
80. blue-bag
ANSIBLE BASICS: TESTING
Test play books
$ansible-playbook --syntax-check --list-tasks playbook.yml
Check mode
$ansible-playbook playbook.yml --check
$ansible-playbook playbook.yml --check --diff
Test against Virtual machines
$ ansible-playbook playbook.yml --limit local
81. blue-bag
ANSIBLE: ORIGINAL RECIPE
w
Original Recipe
Availableoverthecounter
Contents:
Galaxy Roles
Custom Vars
Simple Playbook
x
Multipurpose in a jar
Want a quick solution?
Easy to maintain
Generic
Documented examples
82. blue-bag
---
- hosts: all
roles:
- geerlingguy.mysql
- geerlingguy.apache
- geerlingguy.php
A LAMP SERVER IN SIX LINES OF YAML
Jeff Geerling - Ansible for Devops
ANSIBLE: ORIGINAL RECIPE
83. blue-bag
For all local
development
use VLAD
http://git.io/DCB-Vlad http://www.drupalvm.com/
For all local development
use Drupal VM
s
ANSIBLE: ORIGINAL RECIPE OTHER BRANDS
84. blue-bag
ANSIBLE: SPECIAL FORMULA
w
Special Formula
Noprescription!
Contents:
Forked Roles
Custom Roles
Custom Inventory & Vars
Featured multistage playbook
x
Mostly Galaxy Roles
Customised to needs
Match local & production
Separate plays
88. blue-bag
ANSIBLE: WORKING WITH LISTS
Get a list of the IPS from a dictionary & host group:
vars:
firewall_whitelist:
- { name: 'local', ip: "192.168.100.1" }
- { name: 'fred', ip: '192.168.100.120' }
- { name: 'bob', ip: '192.168.100.121' }
firewall_whitelistgroup: "webservers"
tasks:
- name: Setfact for allowed ips list for chain script
set_fact:
allowed_ips: "{{ firewall_whitelist|map(attribute='ip')|list|unique }}"
- name: Setfact list using group for var firewall_whitelistgroup
set_fact:
hosts_ips: "{{ groups[firewall_whitelistgroup] }}"
- name: Show the union of list 1 & 2
debug: msg="{{ allowed_ips|union(hosts_ips) }}"
89. blue-bag
ANSIBLE: WORKING WITH LISTS
Flattening and joining lists:
- name: Get the servers' ansible_all_ipv4_addresses
set_fact:
ip_list2: "{{hostvars|fetchlistfromdict(groups.multi)|
map(attribute='ansible_all_ipv4_addresses')|list }}"
TASK: [Show the list we obtained for ansible_all_ipv4_addresses]
**************
ok: [app1] => {
"msg": "[['10.0.2.15', '192.168.100.120'], ['10.0.2.15',
'192.168.100.121'], ['10.0.2.15', '192.168.100.122']]"
}
90. blue-bag
ANSIBLE: WORKING WITH LISTS
Your first Plugin!
./plugins/filter_plugins/flatten_dict_values.py
# This function will take a dictionary composed of sub arrays
# and flatten it
# e.g.
# [[u'321.321.321.321', u'10.10.20.54'], [u'46.101.45.10', u'10.10.20.55']]
# to
# [u'321.321.321.321', u'10.10.20.54', u'123.123.123.123', u'10.10.20.55']
def flatten_dict_values(dictionary):
result = []
result = reduce(list.__add__, dictionary,[])
return result
class FilterModule (object):
def filters(self):
return {
"flatten_dict_values": flatten_dict_values
}
# http://feldboris.alwaysdata.net/blog/python-trick-how-to-flatten-dictionaries-values-composed-of-iterables.html
# http://stackoverflow.com/questions/15995/useful-code-which-uses-reduce-in-python
91. blue-bag
ANSIBLE: WORKING WITH FILES
Copy a file
Copy multiple files
Work with archives
Line in file
Block in file
Templates
92. blue-bag
ANSIBLE: WORKING WITH FILES
Copy a file
- name: Upload the exclude list for archives etc
copy:
src: exclude-list.txt
dest: "{{ proj_site_root }}/exclude-list.txt"
owner: "{{ user }}"
group: "{{ user_admin_group }}"
tags: [site_files]
93. blue-bag
ANSIBLE: WORKING WITH FILES
Copy multiple files
- name: Apache | Put up Holding page
copy:
src: "{{ item }}"
dest: "{{ apache_default_site }}"
owner: "{{ apache_admin_user }}"
group: "{{ apache_admin_group }}"
mode: 0644
with_fileglob:
- default-site/*
94. blue-bag
ANSIBLE: WORKING WITH FILES
Work with archives
- name: Upload & unarchive a set of files
unarchive:
src: "sitefiles/{{ proj_short_name }}.tar"
dest: "/tmp/{{ proj_short_name }}”
copy: yes
tags: [site_files]
95. blue-bag
ANSIBLE: WORKING WITH FILES
Work with rsync
- name: Rsync the uploaded files
synchronize:
src: "/tmp/{{ proj_short_name }}/files"
dest: "{{ site_folder }}/{{ site_docroot }}/sites/default"
archive: no
delete: no
recursive: yes
# times: yes
# perms: yes
checksum: yes
rsync_opts: "--include='.htaccess' --exclude-from '{{ proj_site_root }}/exclude-list.txt'"
delegate_to: "{{ inventory_hostname }}"
tags: [site_files]
notify:
- clear Drupal cache
- Remove sync files
96. blue-bag
ANSIBLE: WORKING WITH FILES
Line in file
- name: Update git config to ignore mode changes
lineinfile:
dest: "{{ site_folder }}/{{ site_docroot }}/.git/config"
regexp: ^[s]*filemode = true
line: " filemode = false"
tags: [repo_setup]
99. blue-bag
ANSIBLE: WORKING WITH FILES
Templates
- name: Apache | test Updated hosts
template:
src: config-test.conf.j2
dest: "/tmp/config-test.conf"
mode: 0644
owner: root
group: root
validate: 'apachectl -t -f %s'
register: apache_result
when: vhost_updated.changed
ignore_errors: yes
sudo: true
tags: [apache]
# {{ ansible_managed }}
<VirtualHost *:{{ http_port }}>
ServerAdmin {{ apache_server_admin }}
ServerName {{ webserver_hostname }}
{% if webserver_hostname_alias is defined
and webserver_hostname_alias|length > 0 %}%}
ServerAlias {{ webserver_hostname_alias }}
{% endif %}
DocumentRoot {{ apache_default_site }}
{% if apache_server_status_enabled %}
<Location /server-status>
SetHandler server-status
{% if apache_vhosts_version == '2.4' %}
{% for entry in incoming_ip_whitelist %}
Require ip {{ entry.ip }}
{% endfor %}
{% else %}
Order deny,allow
Deny from all
Allow from 127.0.0.1
{% for entry in incoming_ip_whitelist %}
Allow from {{ entry.ip }}
{% endfor %}
{% endif %}
</Location>
{% endif %}
100. blue-bag
A FIRST ROLE: BASIC SECURITY - FIRST 5
Lock down SSH
Create users and groups
Limit SSH to RSA key:
(no passwords / no root)
Limit to AllowGroups
Update APT - unattended updates security
Configure hostname
Configure IPTables
Configure Fail2ban
101. blue-bag
Take what we know
Research
Create templates / vars
Consistent across infrastructure
Use tasks to implement
Idempotent
Version controlled
Documented
A FIRST ROLE: BASIC SECURITY - FIRST 5
103. blue-bag
FIRST5: SSH - EXAMPLE
"## README.md
"## defaults
%## main.yml
"## tasks
& "## main.yml
& %## ssh_config.yml
"## templates
& %## ssh_config.j2
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
104. blue-bag
FIRST5: SSH - EXAMPLE
# {{ ansible_managed }}
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port {{ ssh_port }}
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits {{ ssh_server_key_bits }}
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime {{ ssh_login_grace_time }}
templates/ssh_config.j2
105. blue-bag
FIRST5: SSH
"## README.md
"## defaults
%## main.yml
"## tasks
& "## main.yml
& %## ssh_config.yml
"## templates
& %## ssh_config.j2
# SSH Settings
# optionally change port
ssh_port: 22
# reduce login grace time from 120 (2 minutes)
ssh_login_grace_time: 20
# increase the server key bit encryption default=768
ssh_server_key_bits: 4096
# control the parallelism
ssh_max_startups: 3:50:10
# control forwarding
ssh_allow_tcp_forwarding: “no”
ssh_allow_x11_forwarding: “no”
110. blue-bag
BASIC SECURITY: DRUPAL SECURITY
Ansible role quickly address
security issues such as
SA-CORE-2014-005
Inventory of Drupal sites
Task to apply patch
Test for vulnerability
Re-use for future patches
115. blue-bag
ANSIBLE: COOK YOUR OWN
Limited Edition
Prescription only
Contents:
Featured multistage Playbook
Multiple plays
Forked Roles
Custom Roles
Vault
Plugins & filters
Complex Inventory & Vars
l
Drupal
x
Fully customisable
Extensible
Secure
Manage production
Manage host / server / db
assignment
Operating heavy machinery?
Non drowsy!
116. blue-bag
ANSIBLE: INVENTORY DRIVEN SETUP
Ansible iterates hosts
Not always one site per server
Simple to reassign sites / dbs to new servers
Keeps all vars together at appropriate 'level'
Structured
Inheritance of vars - e.g. Project vars
Separates sites & failures
Can use handlers for things like Drush CC
without cc all sites because one changed
118. blue-bag
ANSIBLE: HACKING THE INVENTORY
#### inventory groups
# group for project
# /group_vars/project1.yml
[project1]
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
www_project1_co_uk
dev_project1_co_uk
staging_project1_co_uk
# group for project
[project2]
www.project2.co.uk
dev.project2.co.uk
staging.project2.co.uk
www_project2_co_uk
dev_project2_co_uk
staging_project2_co_uk
# group for server setup
[servers]
web01.myserver.net
web02.myserver.net
db01.myserver.net
# group for webserver vars
[webservers:children]
webserver01
# Group for DB server vars
[dbservers:children]
dbserver01
# Group to allocate 'sites to server
the first entry pins the group to the actual
server
[webserver01]
web01.myserver.net
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
www.project2.co.uk
dev.project2.co.uk
staging.project2.co.uk
# Group to allocate 'dbs' to server
the first entry pins the group to the actual
server
[dbserver01]
db01.myserver.net
www_project1_co_uk
dev_project1_co_uk
staging_project1_co_uk
www_project2_co_uk
dev_project2_co_uk
staging_project2_co_uk
119. blue-bag
ANSIBLE: HACKING THE INVENTORY
# group for server setup
[servers]
web01.myserver.net
db01.myserver.net
# group for webserver vars
[webservers:children]
webserver01
# Group for DB server vars
[dbservers:children]
dbserver01
[webserver01]
web01.myserver.net
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
[dbserver01]
db01.myserver.net
www_project1_co_uk
dev_project1_co_uk
staging_project1_co_uk
# group for server setup
[servers]
server01.myserver.net
# group for webserver vars
[webservers:children]
server01
[server01]
server01.myserver.net
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
www_project1_co_uk
dev_project1_co_uk
staging_project1_co_uk
# group for server setup
[servers]
web01.myserver.net
web02.myserver.net
db01.myserver.net
db02.myserver.net
# group for webserver vars
[webservers:children]
webserver01
webserver02
# Group for DB server vars
[dbservers:children]
dbserver01
dbserver02
[webserver01]
web01.myserver.net
www.project1.co.uk
[dbserver01]
db01.myserver.net
dev_project1_co_uk
staging_project1_co_uk
[webserver02]
web02.myserver.net
dev.project1.co.uk
staging.project1.co.uk
[dbserver02]
db02.myserver.net
www_project1_co_uk
# Group for DB server vars
[dbservers:children]
server01
Simple Lamp
Separate web / DB
Multiple Servers
# groups for assigning hosts to physical server
120. blue-bag
ANSIBLE: HACKING THE INVENTORY
[webserver01]
web01.myserver.net
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
[webserver01]
web01.myserver.net
www.project1.co.uk
Once setup - easy to assign sites to servers preserving
all vars
[webserver02]
web02.myserver.net
dev.project1.co.uk
staging.project1.co.uk
122. blue-bag
ANSIBLE: HACKING THE INVENTORY
All
Group: Host
Project
Host
Group: Type
General defaults:
common ups, API keys, server role vars etc
Server type vars - (i.e. webservers)
eg. DB port, apache cfg, server type role vars
Project defaults:
repo, folder structure, Drupal version
Host details for Group Host
e.g. SSH details
Site / DB specific details
e.g. repo branch, vhost name, db name
123. blue-bag
ANSIBLE: INVENTORY DRIVEN SETUP
Ansible iterates hosts
Simple to reassign sites / dbs to new servers
Keeps all vars together at appropriate 'level'
Structured
Inheritance of vars - e.g. Project vars
Separates sites & failures
Can use handlers for things like Drush CC
without cc all sites because one changed
124. blue-bag
playbook: playbook.yml
play #1 (servers): TAGS: [provision_core, init]
play #2 (webservers:&servers): TAGS: [provision_webserver]
play #3 (dbservers:&servers): TAGS: [provision_dbserver]
play #4 (webservers:!servers): TAGS: [sites_setup]
# group for server setup
[servers]
web01.myserver.net
db01.myserver.net
# group for webserver vars
[webservers:children]
webserver01
# Group for DB server vars
[dbservers:children]
# groups for assigning hosts to physical server
[webserver01]
web01.myserver.net
www.project1.co.uk
dev.project1.co.uk
staging.project1.co.uk
[dbserver01]
db01.myserver.net
www_project1_co_uk
dev_project1_co_uk
staging_project1_co_uk
ANSIBLE: HACKING THE INVENTORY
125. blue-bag
ANSIBLE & DRUPAL
Put all sites in maintenance mode
(Note: better to use maintenance site and re-point traffic to that so you can still work
on your site on your ip)
Pull latest changes
Use in harmony with DrushClear caches and
other Drush actions
see https://github.com/jenitehan/drupal_update_check
Extend Drush / Drupal to output JSON
$drush pmi --format=json
Automate common tasks
126. blue-bag
ANSIBLE & DRUPAL: EXAMPLE 2
Use Case: Commerce site
Product Image updates
Replace the image(s)
Clear the Image Cache / styles
127. blue-bag
---
# vars file for base
files_src_path: “/path/to/local/updated/images”
files_dest_path: “/sites/default/files”
files_to_update:
- “fa9001.jpg"
- “fa9002.jpg"
image_cache_folders:
- “styles/thumbnail/public/product_images"
- "styles/product_gallery/public/product_images"
- "styles/medium_tall/public/product_images"
- "styles/product_full/public/product_images"
ANSIBLE & DRUPAL: EXAMPLE 2
./roles/updateimages/vars/main
128. blue-bag
- name: clear Drupal cache
command: "drush cc all chdir={{ site_folder }}/{{ site_docroot }}"
register: command_result
failed_when: "'cache was cleared' not in command_result.stderr"
ANSIBLE & DRUPAL: DRUSH
Create Drush handler
common/handlers/main.yml
145. blue-bag
CONCLUSION / QUESTIONS
For all local
development
use VLAD
http://git.io/DCB-Vlad
For Ansible get the books
https://leanpub.com/
ansible-for-devops
http://www.ansible.com/
ansible-book