veyepar: NoOps with Ansible and Puppet

Author(s):	Monty Taylor
Location	OGGB 260-098
Date	jan Fri 16	Days Raw Files
Start	15:40	First Raw Start	15:14
Duration	0:45:00	Offset	0:25:21
End	16:25	Last Raw End	16:36
Chapters	00:00
Total cuts_time	54 min.

http://lca2015.linux.org.au/schedule/30268/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf NoOps_with_Ansible_and_Puppet.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

Four years ago, I started a running my first in-cloud project, and I did it as naively as possible - I used the cloud API to get a machine, and then I ran and administered that machine the same way I've adminned every other machine for the past 20 years. As I started adding machiens, it became clear that now was the time to learn this new fangled puppet stuff.

Puppet turned out to be wonderful for repeatability, but the fine folks who wrote it had some really weird ideas about what sorts of things I wanted their help with and what sorts of things I didn't. For instance, I don't really think that it should take 100 lines of a weird DSL to add a user with an SSH key.

Fast forward to today, and we have a control plane of 76 nodes and an elastic pool that runs around 1000 nodes, but creates and destroys between 10k and 20k machines a day. Ths is currently done using a combination of Ansible, Puppet and custom written management tools, and is run automatically continuously deployed from our master branch with every aspect of the deployment being 100% open and Open Source. That is - any of you can go submit a patch to our git repo and if we land it, it will immediately change the running production system - and that's the only way the system gets changed.

While we'll use our current system as an example case to talk about concretely (since it's open source and all) the main point of this talk will be to talk about how to use modern tools ot admin systems efficiently and without throwing away any of the old Linux knowledge we all have.

Comment:

production notes