May include small fragments of OpenShift Origin and Raspberry Pi 3

@dagwieers

2

Who are you ?

● Dag Wieërs – Freelance Linux and Open Source consultant

– Doing Linux and Open Source since 1994– Founded Linux companies “Life” and “Mind” in 1999– Worked for various companies (IT, Finance, Telco, Gov)

● IBM, Euroclear, AXA, EMC, Punch Telematix, HP, Grondwettelijk Hof, ING● BNPP Fortis, Proximus, Telenet, Federal Police, KBC Securities, Cisco

– Mostly as engineer/architect, but prefers hands-on– Started developing Ansible at the very start (early 2012)– Known for core, debug, fail, set_fact, assert, mail, unarchive,

filetree, dense, …

3

Ansible: What is it ?

● Who is not using Ansible these days ?● Ansible is:

– Agent-less, SSH-based* and easy-to-get-going*– An orchestration engine– A configuration management and provisioning tool– A shell multiplexer (aka. ad-hoc commands) vs shmux*

● Ansible integrates with:– Everything under the sun (Thanks to JSON APIs)

● OSes, network equipment, inventories, CMDB, Satellite, hardware mgmt, hypervisors, ...

4

Ansible: What is new ?

● Ansible v2.2 has been released on 2016-11-01– Large set of modules added in the networking department– Changes to how tasks run in check-mode (check_mode: no)– More VMware modules ported to VMware’s own pyvmomi interface– Windows-integration improvements (e.g. Kerberos, shell/command,

async)– Python 3 support not completed, but mostly works on master node– Many improvements to automated testing and platform support

● Core and Extras modules moved back into main GitHub repo yesterday !– Please migrate your open issues/PRs ASAP* !

5

Ansible: What is cooking ?

● Full Python 3 support ?● Big focus on reducing the issue/PR backlog● Windows platform

– Pipelining, become support, UTF8 powershell, Windows module_utils– win_domain_* (membership, controller), win_dns_client, win_wait_for,

win_disk_image, win_package– Azure modules

● Amazon ECS/CloudFormation/AWS/ELB improvements● Even more networking updates● New ansible-ssh command

7

Ansible: conceptual design

● One master system● Multiple target nodes● Master system is allowed to

connect to target nodes● Master system runs Ansible

playbook with tasks● Master collects task reports,

distributes next task, ...

8

Ansible: task execution model (normal)

● Normal modules:– Master sends instructions to

individual target nodes– Target nodes execute

instructions– Target nodes report back

using JSON● Examples:

– shell, file, unarchive, ...

9

Ansible: task execution model (action plugin)

● Pure action plugin:– Master runs instructions

locally (for each target)– Master reports back

(for each target)using JSON

● Examples:– debug, fail, local_action

10

Ansible: task execution model (processed)

● Modules with action plugin:– Master runs action plugin locally

(for each target node)– Master sends instructions to target

nodes– Target nodes execute instructions– Target nodes report back using

JSON● Examples:

– template, copy, synchronize, ...

11

Ansible: task execution model (delegated)

● Modules being delegated:– Master sends instructions to

delegated node (for each target node)

– Delegated node executes instructions

– Delegated node reports back using JSON

● Example:– e.g. nagios, vsphere, iLo

12

Ansible: task execution model (elevated)

● Modules as root (e.g. sudo):– Master sends instructions to

each target node– Target nodes elevate rights– Target nodes execute

instructions as root– Target nodes reports back

using JSON

13

Ansible: module execution

● Modules are processed before being transferred– Using special markers for injection– Injection of arguments, module_utils and libraries

● Strategies for execution– Create-Copy-Execute/Remove (3 steps)

● Traditional model, used for modules that require multiple files

– Pipelining (1 step)● Send processed module directly to interpreter, where possible

– Ansiballz (aka. Ziploader) (1 step)● Transfer archive with all required files and using python import

14

Ansible: plenty of modules (~1000)

● Most core modules are very good– However some core modules are not idempotent, or do not

support check-mode or diff-mode● Lots of extra modules

– Some are very good, others are limited or only work for a specific use-case, always test

● Writing/improving modules is not hard– Python experience helps, troubleshooting skills trumps– General programming skills and logical thinking is a must

15

Ansible: module documentation

● Let me Google that for you:– “Ansible module index”

http://docs.ansible.com/ansible/list_of_all_modules.html

– Many more modules live in private repositories (e.g. ansible-provisioning), or are waiting in GitHub pull-requests

– Some useful modules are hid well inside Galaxy roles or openshift-ansible

16

Raspberry Pi 3 cluster specs

● Total price: 236 €– 4x Raspberry Pi 3: 4 x 35 € = 140 €– 4x short USB cable: 4 x 13 € = 52 €– 40W USB power hub: 31 €– Mini RPi cluster rack: 13 €– Network switch: 0 € (second-hand)

– 4x short UTP cable: 0 € (home-made)

– USB power supply cable: 0 € (home-made)

17

OpenShift on Raspberry Pi 3: Issue galore

● CentOS 7 supports RPi3 on amrv7hl, but docker is not available on 32bit● CentOS 7 does not support RPi3 on aarch64 !● Cross-compiling and bootstrapping your own (or cheating as I did)● OpenShift Container Platform (v1.3.3) does not build on aarch64● OpenShift Origin v1.4.0 with selected patches does● Origin v1.4.0 needs newer golang for aarch64● Raspberry Pi 3 unable to build OpenShift with 1GB RAM and 5GB swap● Kernel does not support SELinux with overlay graph driver (docker)● Kernel lacks ip_tables, nfs and device-mapper support● No more free diskspace for docker volume

18

OpenShift: Advanced installation method

● Pretty straight-forward (see documentation for details)– Clone: https://github.com/openshift/openshift-ansible– Modify: ansible.cfg (e.g. enable ssh and pipelining)– Copy and modify: inventory/byo/hosts– Run: ansible-playbook playbooks/byo/config.yml

● Used for installation and upgrades● Fully idempotent● Easy to adapt to personal needs

19

Ansible: Debugging techniques

● Adding more than one -v option– Add -vvvv (four) or -vvvvv (five) for extended output

● Use debug strategy to invoke debugger on failed tasks (strategy: debug)

● Use ANSIBLE_DEBUG=1 when running ansible or ansible-playbook● Use ANSIBLE_KEEP_REMOTE_FILES=1 for debugging payload● Use debug, fail or assert statements in playbooks as breakpoints● Use tags for repeated rerunning one or more tasks● Look into ansible-profile for timing tasks

20

Ansible tips & tricks: reduce complexity

Move complexity out of playbooks

1. Start with well-designed inventory (dynamic) + integration

2. Use templates to reduce playbook spaghetti (if-then)

3. Logically group into self-sufficient roles

4. Modify data and simplify expressions using Jinja2 filters

5. Use (custom) lookup_plugins to iterate over collections

6. Push complex logic into (custom) modules (→ locality)

7. Integrate with 3rd party infrastructure through callbacks