Automation: When OpenStack Meets Ansible A Few Things About Me … ALCATEL LUCENT ENTERPRISE TECHNICAL DIRECTOR, PERSONAL CLOUD SOLUTIONS • Cloud Architecture and Application/Infrastructure Design • R&D Development, Automation, Operations … OPEN SOURCE PROJECT FOUNDER, LEADER AND/OR CONTRIBUTOR FOR: • OpenBricks & GeeXboX : Embedded Linux cross-build tool and distribution. • uShare UPnP A/V & DLNA Media Server, FFMpeg, MPlayer … LINUX FOUNDATION CONFERENCES REGULAR LINUX FOUNDATION’S EVENTS SPEAKER • Various talks on: • Linux Embedded Systems at Embedded Linux Conference (Europe) • Android Architecture and Device Porting at Android Builder Summit GNU/LINUX MAGAZINE FRANCE RECURRENT TECHNICAL WRITER • Various publications on: • Android Architecture Internals • Cloud (OpenStack, Ansible …)
Automation: When OpenStack Meets Ansible Self-Promotion Time ! Series of articles published in GNU/Linux Magazine France Android 4: Fondements Internes Benjamin Zores, Ed. Diamond – Sept. 2014
Developer Is A Lazy Developer ! Don’t do over and over again things that someone else can do for you. (especially if that someone is a bot) Extending Cloud Automation: When OpenStack Meets Ansible Why we’re here ?
Automation: When OpenStack Meets Ansible How one feels after deploying its servers through shell scripts … #!/bin/sh echo “net.core.rmem_default=16384" | sudo tee -a /etc/sysctl.conf echo “deb http://nwps.ws/pub/mariadb/repo/5.5/debian wheezy main” | \ sudo tee –a /etc/apt/conf.d/mariadb.conf sudo apt-get -y install mariadb-server […] AWESOME !!
Automation: When OpenStack Meets Ansible State of the Art Original Rockstars ! - Great Tools - Field Pioneers But just incredibly complex to start with, even for simple cases. Not everyone is managing 500 servers in the cloud after all …
Automation: When OpenStack Meets Ansible Ansible Inventory [europe] foo.domain.com [usa] 192.168.0.1 [world:children] europe usa [webservers] www[01:50].domain.com [databases] db-[a:f].domain.com Hosts can be described by FQDN or IP With support for infinite depth inheritance [targets] localhost ansible_connection=local web1.domain.com ansible_connection=ssh ansible_ssh_user=user1 web2.domain.com ansible_connection=ssh ansible_ssh_user=user2 With support for wildcards And per-host tuning variables.
Automation: When OpenStack Meets Ansible Ansible Modules (235 in Ansible v1.7.1) # ansible-doc -l acl Sets and retrieves file ACL information. add_host Add a host (and alternatively a group) to the ansible-playbook 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 [...] xattr Set/retrieve extended attributes yum Manages packages with the `yum' package manager zfs Manage zfs zypper Manage packages on SuSE and openSuSE
Automation: When OpenStack Meets Ansible Ansible Module How-To # ansible-doc shell > SHELL The [shell] module takes the command name followed by a list of space-delimited arguments. It is almost exactly like the [command] module but runs the command through a shell (`/bin/sh') on the remote node. Options (= is mandatory): - chdir cd into this directory before running the command - creates a filename, when it already exists, this step will *not* be run. - executable change the shell used to execute the command. Should be an absolute path to the executable. = free_form The shell module takes a free form command to run, as a string. There's not an actual option named "free form". See the examples! - removes a filename, when it does not exist, this step will *not* be run. Notes: If you want to execute a command securely and predictably, it may be better to use the [command] module instead. Best practices when writing playbooks will follow the trend of using [command] unless [shell] is explicitly required. When running ad-hoc commands, use your best judgement. # Execute the command in remote shell; stdout goes to the specified # file on the remote - shell: somescript.sh >> somelog.txt
Automation: When OpenStack Meets Ansible Ansible Playbooks --- - hosts: lan1 remote_user: ben sudo: no vars: name: ”My First Playbook” tasks: - name: verify servers activity ping: - name: say hello shell: /bin/echo "{{name}} {{msg}}” notify: - we are done handlers: - name: we are done shell: /bin/echo ”That’s it !" YAML File Format
Automation: When OpenStack Meets Ansible Example: (Parts of) MariaDB Cluster Automation templates/mariadb.cnf.j2: [mysqld] wsrep_node_address={{ ansible_eth0.ipv4.address }} wsrep_node_name='{{ ansible_hostname }}’ {% if mariadb_extra_cfg is defined %} {% for key, value in mariadb_extra_cfg.iteritems() %} {{ key }}{% if value is not none %}={{ value }}{% endif %} {% endfor %} {% endif %} Target /etc/mysql/mariadb.cnf: wsrep_node_address=192.168.0.1 wsrep_node_name=my-db-maria1 skip-external-locking skip-name-resolve
Automation: When OpenStack Meets Ansible OpenStack in a Nutshell - #1 (most widely adopted) Open-Source IaaS project. - Awesome REST Management API. - Perfect for instant spawning of new Virtual Machines (VMs) - But VMs yet to be configured ... What if I could connect OpenStack VMs with Ansible for nightly CI ?
Automation: When OpenStack Meets Ansible (One of my) Cloud application: OpenTouch TeamShare - Online collaboration tool for SMBs. - Provides multi-projects file storage and sharing for enterprises. - With project management, chat and collaboration capabilities.
Automation: When OpenStack Meets Ansible (One of my) Cloud application network topology - 2x HAProxy Load-Balancers - 2x NGINX frontal Web Servers - 2x NGINX frontal Web File Servers - 2x PHP Backends - 1x SMTP Server - 3x MariaDB Master-Master Galera Cluster + 2x Galera Arbiters - 2x MongoDB Master-Slave Cluster + 1x MongoDB Arbiter - 3x RabbitMQ Master-Master Clusters - 1x LibreOffice Server - 1x NFS Server Now let’s say that I want to test both my application and my infrastructure every single night for non-regression !
Automation: When OpenStack Meets Ansible AvOID: Ansible OpenStack Instances Deployer - Open Source software by Alcatel-Lucent Enterprise. - Written in Python with dependencies to OpenStack Nova/Neutron APIs. - Relies on Ansible with IaaS bindings: - Currently OpenStack only - But wide open to support many much more … who knows … - Comes as a library with both CLI and Web clients. How it works: 1. Describe your infrastructure topology in a YAML file once and for all. 2. Run avoid-cli. Grab a coffee, that’s it. How it (internally) works: 1. Parses your topology file. 2. Optionally terminates (all) OpenStack VMs and spawn new ones and build Ansible inventory file. 3. Creates VMs dependency graph for parallelized post-configuration by Ansible. 4. Post-configure VMs through Ansible playbooks (continuous-integration style).
Automation: When OpenStack Meets Ansible AvOID command-line # avoid-cli Usage: avoid-cli <topology_file.yml> <command> [opts] where <command> is: - status: list topology status - redeploy <list of playbooks or VM names>: terminate VM, spawn a new one and restart playbook - redeployall: redeploy all nodes - runplaybook <list of playbooks>: restart playbook as it - runallplaybooks: restart all playbooks - geninventory: generate Ansible inventory file based on topology.yml
Automation: When OpenStack Meets Ansible AvOID Web UI # avoid-web my-topo-dev.yml Read of my-dev.yml done: 32 VMs and 22 playbooks Now go to http://localhost:8888/ !