AWS OpsWorks Orchestration War Stories – Andrew Boag
- Autoscaling too slow since running build-from-scratch every time
- Communications dependencies
- Full stack rebuild in 20-40 minutes to use data currently in production
- A bit longer in a different region
- Great for load testing
- If we ere doing again
- AMI-based better
- OPSWorks not suitable for all AWS stacks
- Golden master for flexable
- Auto-Scaling
- Not every AMI instance is Good to Go upon provisioning
- Not a magic bullet, you can’t broadly under-provision
- needs to be throughly load-tested
- Tips
- Dual factor authentication
- No single person / credentials should be able to delete all cloud-hosted copies of your data
- Looked at Cloudformation at start, seemed to be more work
- Fallen out of love with OpsWorks
- Nice distinction by Andrew Boag: he doesn’t talk about “lock-in” to cloud providers, but about “cost to exit”. – Quote from Paul
Slim Application Containers from Source – Sven Dowideit
- Choose a base image and make a local version (so all your stuff uses the same one)
- I’d pick debian (a little smaller) unless you can make do with busybox or scratch
- Do I need these files? (check though the Dockerfile) eg remove docs files, manpages, timezones
- Then build, export, import and it comes all clean with just one layer.
- If all your images use same base, only on the disk once
- Use related images with all your tools, related to deployment image but with the extra dev, debug, network tools
- Version the dev images
- Minimise to 2 layers
- look at docker-squash
- Get rid of all the sourc code from your image, just end up with whats need, not junk hidden in layers
- Static micro-container nginx
- Build as container
- export as tar , reimport
- It crashes 🙁
- Use inotifywait to find what extra files (like shared libraries) it needs
- Create new tarball with those extra files and “docker import” again
- Just 21MB instead of 1.4GB with all the build fragments and random system stuff
- Use docker build as last stage rather than docker import and you can run nginx from docker command line
- Make 2 tar files, one for each image, one in libs/etc, second is nginx
Containers and PCP (Performance Co-Pilot) – Nathan Scott
- Been around for 20+ years, 11 years open source, Not a big mindshare
- What is PCP?
- Toolkit, System level analysis, live and historical, Extensible, distributed
- pmcd daemon on each server, plus for various functions (bit of like collectd model)
- pmlogger, pmchart, pmie, etc talk (pull or poll) to pmcd to get data
- With Containers
- Use –container= to grab info inside a container/namespace
- Lots of work still needed. Metrics inside containers limited compared to native OS
The Challenges of Containerizing your Datacenter – Daniel Hall
- Goals at LIFX
- Apps all stateless, easy to dockerize
- Using mesos, zookeeper, marathon, chronos
- Databases and other stuff outside that cloud
- Mesos slave launches docker containers
- Docker Security
- chroot < Docker < KVM
- Running untrusted Docket containers are a BAD IDEA
- Don’t run apps as root inside container
- Use a recent kernel
- Run as little as possible in container
- Single static app if possible
- Run SELinux on the host
- Finding things
- Lots of micoroservices, marathon/mesos moves things all over the place
- Whole machines going up and down
- Marathon comes with a tool that pushes it’s state into HAProxy, works fairly well, apps talk to localhost on each machines and haproxy forwards
- Use custom script for this
- Collecting Logs
- Not a good solution
- can mount /dev/log but don’t restart syslog
- Mesos collects stdout/stderror , hard to work with and no timestamps
- Centralized logs
- rsyslog log to 127.0.0.1 -> haproxy -> contral machine
- Sometimes needs to queue/drop if things take a little while to start
- rsyslog -> logstash
- elasticsearch on mesos
- nginx tasks running kibana
- Troubleshooting
- Similar to service discover problem
- Easier to get into a container than getting out
- Find a container in marathon
- Use docker exec to run a shell, doesn’t work so well on really thin containers
- So debugging tolls can work from outside, pprof or jsonsole can connect to exposed port/pid of container