Containerized Workstations Using Docker to Build Consistent Workstations Arthur Maltson @amaltson http://onthejvm.com Speaker Note: Hello everyone, I’m Arthur Maltson, @amaltson on Twitter and GitHub. I work at . Today I’m going to, quickly, talk to you about new take on an old problem. 

Speaker Note: That problem is, workstation configuration and setup. Whether it’s a brand new workstation for a new hire, or installing new tools for different projects, this usually turns into an yak shaving exercise. 

Speaker Note: I’m sure we’re all familiar with the Wiki Setup Page of Doom? 3 days in and you’re only halfway through. And it’s probably out of date, there’s undocumented edge cases. Yeah, not fun. 

Speaker Note: You may have solved this by sprinkling in some scripts here and there. But that’s really like having all your tools hanging on one wall. This sounds all organized and really not that bad, until… 

Speaker Note: You have to start supporting multiple OS platforms like say Mac and Linux workstations, or a major upgrade between OS versions, say Ubuntu 14.04 vs 12.04. 

Speaker Note: Of course it gets worse if you work with multiple languages and frameworks. At some point the versions of the languages and/or frameworks might even start colliding on your system. Yeah, that wall of tools stops working well. 

Speaker Note: Surely there must be better way. A way that’s both is automated but also provides a level of isolation we want between projects. Well there is.. otherwise I wouldn’t be here. That way is called.. 

Speaker Note: Docker. By making use of Linux cgroups, Docker built an easy to use tool that provides the isolation we want but with the speed we crave. 

Speaker Note: So now your workstation looks like a bunch of smaller toolboxes, each one containing just the right tools you need for the project you’re working on. The next step is really, how do you organize these toolboxes. 

Speaker Note: This is where Fig comes in, a tool from Docker Inc explicitly built for managing workstations. With a simple YAML config and a Docker file, you can have your workstation up in no time. So lets look at an example. 

Speaker Note: On the left is the fig.yml file to run a simple Ruby Sinatra app. It builds a Docker image, shares the current working directory to /code in the container, starts up the app and forwards the default Sinatra port. 

Speaker Note: Here at the left is the Dockerfile fig will use to create a new image with Ruby and bundler installed. It will then run `bundle install` to get the Sinatra dependency. On the right is the simple Sinatra app. 

Speaker Note: Running the `fig up` command starts the Docker build, downloads the base image if needed, shares the directory, runs the bundle install and start the app. And remember, since the ports are forwarded… 

Speaker Note: We can just navigate to localhost at that port, or localdocker on OS X, and we have our application. So let’s step back a minute, without ever having to install or setup Ruby, we can now start working on this app. 

$ fig run web bash Speaker Note: And since your current working directory is automatically shared, you can use all your favourite editors and tools for development. But with a simple `fig run web bash`, you unlock everything that’s installed inside the container. 

Provisioned Docker Image Speaker Note: Also, since you have full control of the Dockerfile, you can pull in prebuilt Docker images from your local Docker Registry. This means you could use something like Chef to do the actual provisioning. 

Provisioned Speaker Note: And if you use Docker for production deployments, you can just pull in and link the backend and database as they were provisioned for production. We can really start avoiding the dev vs prod discrepancy. 

Speaker Note: We started our journey in the Wiki Setup Page of Doom. We then we started to automate what we could, but quickly realized having all our tools on one giant wall is unsustainable. 

Speaker Note: Through the use Docker and Fig, we get two really great tools for bootstrapping and isolating our project work. This gets new team members up and running quickly and keeps old team member’s workstations sane. 

Credits • Slide 1 - Derell Licht, container ship leaving bay area, https://flic.kr/p/pnSzL • Slide 1, 20 - Twitter, Twitter logo blue, https://about.twitter.com/press/brand-assets • Slide 1, 20 - GitHub, Octocat, https://github.com/logos • Slide 2 - Steven and Sarah, Garage Workbench, https://flic.kr/p/f4oak • Slide 3 - Cuny Academic Commons, Motivate Yak Shaving, http://pmip.googlecode.com/svn/trunk/talk/PMIP/img/motivate_yak_shaving.jpg • Slide 4 - mob mob, Finished Workbench - front, https://flic.kr/p/57Kmmq • Slide 5 - Paul Englefield, Workbench, https://flic.kr/p/3aLRao • Slide 6, 18 - Mike Fischer, Workbench, https://flic.kr/p/c83Zy9 • Slide 7, 8 - Sue, Blue Tool Box, https://flic.kr/p/cHgsCQ • Slide 8, 15, 19 - Docker Inc, Docker Logo, https://www.docker.com/legal/marks_and_logos/ • Slide 9, 10, 19 - Morten Nisker Toppenberg, Mobile electronics workbench open, https://flic.kr/p/8yWpiA • Slide 10, 19 - Docker Inc, Fig Logo, http://www.fig.sh/index.html • Slide 15 - Wikimedia, Sublime Text Logo, http://upload.wikimedia.org/wikipedia/en/4/4c/Sublime_Text_Logo.png • Slide 15 - vim.org, Vim: the Editor, http://www.vim.org/logos.php • Slide 15 - GitHub, Atom logo, https://raw.githubusercontent.com/atom/settings-view/master/images/atom.png • Slide 15 - Pivotal, Jasmine logo, https://github.com/pivotal/jasmine/wiki • Slide 15 - Grunt, Grunt logo, https://raw.githubusercontent.com/gruntjs/gruntjs.com/master/src/img/grunt-logo.png • Slide 15 - Apache Foundation, Maven logo, http://maven.apache.org/images/maventxt_logo_200.gif • Slide 15 - David Heinemeier Hansson, Rails Logo remix, https://github.com/rails/rails/blob/master/guides/assets/images/rails_logo_remix.gif • Slide 16, 17 - Wikimedia, Chef Software Inc. company logo, http://en.wikipedia.org/wiki/Chef_(company) • Slide 20 - imgflip, All The Things, https://imgflip.com/i/c03xj Arthur Maltson @amaltson http://onthejvm.com