How do you support many different authorization methods (OAUTH, HTTP Basic/Digest, SSL certificates…) for many different apps (a Rails website, a Python/Flask API, realtime events streaming with Node.js, and more…)? We review a bunch of options, and propose an original way to do it with Docker and Containers.
8. Solution 1
●
●
●
●
●
●
this is actually what most people do
because at first the matrix isn’t that big
then you add more services
want to support more backends
you end up picking one auth method
N implementations instead of MxN
9. Solution 1
●
●
●
●
●
●
this is actually what most people do
because at first the matrix isn’t that big
then you add more services
want to support more backends
you end up picking one auth method
N implementations instead of MxN
Grade: C
10. Solution 1
●
●
●
●
●
this is actually what most people do
because at first the matrix isn’t that big
then you add more services
want to support more backends
you end up picking one (or two) auth method
○ e.g. basic auth over SSL + API tokens
● N implementations (or 2xN) instead of MxN
Grade: B
11. Solution 2
● delegate auth to a proxy/external process
Client
Here there be $AUTH
Proxy
Here there be simple HTTP headers
Service
12. Solution 2: the problems
●
●
●
●
●
I work on the Ruby API
I don’t want to install the Node.js stuff
but the auth component is in Node.js!
I have to learn how to deploy Node.js
also, deployment is more complex
13. Solution 2: the problems
●
●
●
●
●
I work on the Ruby API
I don’t want to install the Node.js stuff
but the auth component is in Node.js!
I have to learn how to deploy Node.js
also, deployment is more complex
Grade: B
(single lang shops)
Grade: D
(everybody else)
15. Solution 3
● put each component in a VM
Client
Here there be $AUTH
Proxy VM
Here there be simple HTTP headers
Service VM
16. Solution 3: the problems
● create (and maintain) VM images
● VMs are RAM-heavy
○ now you have a good reason to get 16 GB of RAM!
● VMs are disk-heavy
○ now you need to download a 500 MB VM to update
the auth proxy to test a 4-lines commit
● VM networking is not awesome
○ discovery and plumbing can require some voodoo
17. Solution 3
Grade: B
(if you have a vagrant
guru in residence,
and super shiny
awesome laptops)
Grade: D
(everybody else)
20. Solution 4
● put each component in a container
Client
Here there be $AUTH
Proxy LXC
Here there be simple HTTP headers
Service LXC
21. Solution 4: pros and cons
● your dev env must be Linux
● or you can use a VM
○ but just one
○ no Hogwarts diploma required
● containers are lightweight
○ I can run 100 containers on my laptop
○ updating a container is more like “git pull”
● networking is easier
○ and is getting even more easier!
○ service discovery
24. What’s a Linux container?
High level approach
Lightweight Virtual Machine
● looks like a VM
● can run stuff as root
● can install packages
● can run sshd, syslog, cron...
“Machine Container”
25. What’s a Linux container?
Low level approach
Chroot on steroids
● normal processes, but isolated
● share kernel with the host
● doesn’t need to run ssh, syslog, cron...
“Application Container”
26. What’s a Linux container?
Technical approach
Two big sets of kernel features:
● namespaces
○ isolate containers
○ one namespace cannot see/affect another
● control groups
○ meter and limit resources
○ CPU, RAM, disk I/O…
○ prevent a single container from hogging the host
Note: you can use namespaces and/or
cgroups without using containers
28. 1. Runtime for Linux containers
jpetazzo@tarrasque:~$ sudo docker run -t -i ubuntu bash
root@092ee318746f:/#
→ create an Ubuntu VM, and run a shell in it.
Total time: less than 0.5s
(If necessary, the “ubuntu” image
will be downloaded automatically.)
30. 2. Standard format for containers
3. Public place to share them
● library of standard images
(ubuntu, fedora, redis, postgresql…)
● create your own images
(from scratch or based on existing ones)
● upload them to the public registry
(searchable index w/ social features)
● upload them to private registry
● 3rd party hosted registries already exist
31. Real world example:
Test this new Ghost blog engine
● Look for “ghost” on http://index.docker.io/
● Find orchardup/ghost
jpetazzo@tarrasque:~$ sudo docker run -d orchardup/ghost
c6000fa5ddc6
Total time: <0.5s
(+5m to download the image on this hotel WiFi)
32. Runtime for Linux containers
jpetazzo@tarrasque:~$ sudo docker inspect c6000fa5ddc6
...
"PortMapping": {
"Tcp": {
"2368": "49153"
},
...
→ if I run this on a server somewhere, the new
service is publicly available on port 49153.
33. How does the Auth problem fit in?
● create a “HTTP Basic Auth + SSL” container
○ based on e.g. existing Nginx container
○ inject a custom auth header, e.g. x-username
○ strip rogue x-username header (duh!)
● lock the Ghost service so it doesn’t expose
its TCP port anymore to the outside world
○ but it will still accept connections from containers
● patch the Ghost service to look for the
header
35. Creating an image with run/commit
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
docker run ubuntu bash
apt-get install this and that
docker commit <containerid> <imagename>
docker run <imagename> bash
git clone git://.../mycode
pip install -r requirements.txt
docker commit <containerid> <imagename>
repeat steps 4-7 as necessary
docker tag <imagename> <user/image>
docker push <user/image>
36. Creating an image with a Dockerfile
# This is a Dockerfile to build a CouchDB container
FROM ubuntu
RUN apt-get -y update
RUN apt-get install -y g++ erlang-dev erlang-base-hipe …
RUN apt-get install libmozjs185-dev libicu-dev libtool …
RUN apt-get install make wget
RUN wget http://.../apache-couchdb-1.3.1.tar.gz
| tar -C /tmp -zxfRUN cd /tmp/apache-couchdb-* && ./configure && make install
RUN printf "[httpd]nport = 8101nbind_address = 0.0.0.0"
>/usr/local/etc/couchdb/local.d/docker.ini
EXPOSE 8101
CMD ["/usr/local/bin/couchdb"]
docker build -t jpetazzo/couchdb .
docker push jpetazzo/couchdb
38. Solution 4: moment of truth
● we just built perfect packages:
○ distro-independent
○ without dependency issues
○ that can run in dev, staging, production
● without getting our hands dirty
○ and barely rolling up our sleeves
● we can share them with other projects/shops
Please allow me to verbosely formulate my genuine enthusiasm.
40. Deploying Containers
● docker pull + docker run from registry
● Docker can be controlled through REST API,
so you can control a fleet of Docker hosts
● PAAS-like: Cocaine, Deis, Maestro…
♥ OpenStack?
● Nova can deploy Docker containers (since Havana)
● Heat can deploy Docker containers (since last week)
42. Future of Docker
● service discovery
(containers will be able to discover
resources)
● compatibility with Red Hat Enterprise Linux
(currently Docker runs best on Ubuntu)
● support for other runtimes and storage
(Jails, Zones, BTRFS, ZFS…)