• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Docker and Go: why did we decide to write Docker in Go?
 

Docker and Go: why did we decide to write Docker in Go?

on

  • 51,963 views

Docker is currently one of the most popular Go projects. After a (quick) Docker intro, we will discuss why we picked Go, and how it turned out for us. ...

Docker is currently one of the most popular Go projects. After a (quick) Docker intro, we will discuss why we picked Go, and how it turned out for us.

We tried to list all the drawbacks and minor inconveniences that we met while developing Docker; not to complain about Go, but to give the audience an idea of what to expect. Depending on your project, those drawbacks could be minor inconveniences or showstoppers; we thought you would want to know about them to help you to make the right choice!

Statistics

Views

Total Views
51,963
Views on SlideShare
47,615
Embed Views
4,348

Actions

Likes
79
Downloads
205
Comments
0

41 Embeds 4,348

http://java.dzone.com 2776
https://twitter.com 624
http://devopsbox.es 179
http://heliocordeiro.tumblr.com 149
http://yoshidashingo.hatenablog.com 145
http://irrlab.com 125
http://www.scoop.it 122
http://www.redditmedia.com 93
http://localhost 23
http://beta.doyoubuzz.com 13
http://www.linkedin.com 10
http://python.dzone.com 9
http://ruby.dzone.com 7
https://www.google.com 6
http://moderation.local 6
http://news.google.com 6
http://www.fbnead.com.br 5
http://cloud.feedly.com 5
http://plus.url.google.com 5
http://www.google.com 4
http://irrlab.wordpress.com 4
https://www.rebelmouse.com 3
http://assets.txmblr.com 3
http://feedly.com 3
https://www.linkedin.com 3
http://php.dzone.com 2
http://durch.io 2
http://www.heliocordeiro.tumblr.com 2
http://bundlr.com 2
https://reader.aol.com 1
http://tweetedtimes.com 1
http://twicli.neocat.jp 1
http://www.google.co.jp 1
http://www.google.nl 1
https://www.google.pl 1
http://www.tumblr.com 1
http://home.jolidev.com 1
https://in.linkedin.com 1
http://cloud.dzone.com 1
http://www.dzone.com 1
http://www.google.co.uk 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Docker and Go: why did we decide to write Docker in Go? Docker and Go: why did we decide to write Docker in Go? Presentation Transcript

    • Docker: an insider view Google Developers Group Meetup November 2013, Google West Campus 2 Michael Crosby — @crosbymichael Jérôme Petazzoni — @jpetazzo Victor Vieux — @vieux
    • Outline ● ● ● ● ● ● what is Docker why it is written in Go some implementation details drawbacks more drawbacks discussion
    • What’s Docker?
    • Docker solves the “Matrix from Hell”
    • Docker solves the “Matrix from Hell”
    • Docker solves the “Matrix from Hell” static website ? ? ? ? ? ? web frontend ? ? ? ? ? ? background workers ? ? ? ? ? ? user DB ? ? ? ? ? ? analytics DB ? ? ? ? ? ? queue ? ? ? ? ? ? dev VM QA server single prod server on-site cluster public cloud contributor laptop
    • Real-world analogy: containers
    • Worldwide shipping: another Matrix from Hell clothes ? ? ? ? wine ? ? ? ? coffee ? ? ? ? electronics ? ? ? ? cars ? ? ? ? raw materials ? ? ? ? ships trains trucks storage
    • Solution: the intermodal shipping container clothes wine coffee electronics cars raw materials ships trains trucks storage
    • Solution to the deployment problem: the Linux container
    • What’s a Linux container? High level approach Chroot on steroids ● normal processes, but isolated ● share kernel with the host ● no device emulation (neither PV nor HVM) ● doesn’t need a /sbin/init (runs the app/DB/whatever directly) “Application Container”
    • What’s a Linux container? Low level approach Lightweight Virtual Machine ● own process space ● own network interface ● can run stuff as root ● can have its own /sbin/init (different from the host) “Machine Container”
    • Separation of concerns: Dave, from the dev team ● ● ● ● ● ● ● my code my framework my libraries my system dependencies my packaging system my distro my data I don’t care where it’s running or how.
    • Separation of concerns: Oscar, from the ops team ● ● ● ● ● logs backups remote access monitoring uptime I don’t care what’s running in it.
    • OK, so what’s Docker?
    • Runtime for Linux containers jpetazzo@tarrasque:~$ sudo docker run -t -i ubuntu bash root@092ee318746f:/# jpetazzo@tarrasque:~$ sudo docker run -d johncosta/redis c6000fa5ddc6 jpetazzo@tarrasque:~$ sudo docker inspect c6000fa5ddc6 ... "NetworkSettings": { "IPAddress": "172.17.0.8", "Ports": { "6379/tcp": null } ...
    • Standard format for containers, and a place to share them ● fetch an image from the registry with “docker pull” ● enter the image with “docker run”, do some changes ● record those changes with “docker commit”, repeat as many time as needed ● then share the result with “docker push”, on the public registry or on a private one
    • Why Go? The Five Reasons Why We Used Go
    • Why Go? 1) static compilation ● “go build” will embed everything you need (no more “install this in order to run my stuff”) ● … except dynamic libraries if you use cgo (cgo lets you use any C library) ● and … except libc (but who doesn’t have libc?) ● you can have a real static binary (if you hack the build process a bit…)
    • Why Go? 1) static compilation ● easier to install, easier to test, easier to adopt ● good candidate for bootstrap (i.e. the first installed thing, which will install the other things) ● “no dependencies? me gusta!” -- Anonymous BOFH
    • Why Go? 2) neutral ● ● ● ● it’s not C++ it’s not Python it’s not Ruby it’s not Java
    • Why Go? 3) it has what we need ● good asynchronous primitives (wait for I/O, wait for processes…) ● low-level interfaces (manage processes, syscalls…) ● extensive standard library and data types ● strong duck typing
    • Why Go? 4) full development environment Go addresses multiple issues of the development workflow. ● ● ● ● ● go doc (see documentation for any package) go get (fetch dependencies on github etc.) go fmt (solve “tabs vs. spaces” once for all) go test (runs all Test* functions in *_test.go) go run (rapid script-like prototyping)
    • Why Go? 5) multi-arch build ...without pre-processors _linux.go _darwin.go
    • Drawbacks Because that’s the most interesting thing in Amazon reviews
    • “Go doesn’t solve any problem” Jonn Mostovoy @podmostom29 Sep @benoitc @arnaudsj in not solving any problems. Everything they claim to solve is better solved in Dv2. 0, Erlang or will be solved in Rust.. But... ● Go is easier than Erlang ● Go is more real than Rust ● Don’t know about D 2.0 though!
    • maps aren’t thread-safe ● deliberate decision: they’re fast (and it’s up to you to ensure that they’re safe) ● you have to protect access with sync.Mutex ● or, use channels of channels! m := NewMap() response := make(chan string) m<-Get{Key: “fortytwo”, Replyto: response} value := <-response
    • go get ● can’t pin a particular revision ● Docker had to vendor all dependencies (i.e. import their source code in our repo) ● must deal with private repos manually
    • go test ● can’t have destructors/cleanups/… in tests ● use a test named “z_final_test.go” ● … which doesn’t work too well when running individual tests!
    • go build ● it’s painful to build multiple binaries, when they share some common code ● each program has to be in its own package, and package must be “main” ● you have to put shared/common stuff aside, or use named import tricks (bleh)
    • flag package ● doesn’t handle short/long options (-o --option) ● doesn’t handle options grouping (-abc -a -b -c) ● seriously just don’t use it (use getopt or go-flags instead) unless your primary target is Plan9 of course!
    • no IDE Let’s ask Samuel Jackson what he thinks about it
    • Error handling can be verbose if err := openFile(); err != nil { return err } if err := readAll(); err != nil { return err } if err := closeFile(); err != nil { return err } ...
    • Error handling ● panic / recover (don’t abuse it; only use it internally!) ● deploy one-off utility types http://talks.golang.org/2013/bestpractices.slide#5
    • can’t select on readers/writers select { case data = <-inputChannel: … case data = <-otherInputChannel: … case data = connection.Read(): … }
    • can’t select on readers/writers ● for readers: ○ start a goroutine with access to an output channel ○ the goroutine do blocking reads on the readers… ○ …and pushes the results on the output channel ● for writers: ○ adaptation is left as an exercise for the reader → reduce everything to channels!
    • Some useful resources: ● The Holy Reference: http://golang.org/ref/spec ● Some useful patterns: http://golang.org/doc/effective_go.html ● Some best practices: http://talks.golang.org/2013/bestpractices.slide ● Embedded documentation: godoc -http=:6060 & chrome http://localhost:6060 Michael Crosby — @crosbymichael Jérôme Petazzoni — @jpetazzo Victor Vieux — @vieux
    • Thank you! Questions? Michael Crosby — @crosbymichael Jérôme Petazzoni — @jpetazzo Victor Vieux — @vieux