1. 1. Keynote Tuna www.meetup.com/Docker-Hanoi Linh Tran GMO VNLAB
2. 2. DockerCon Day 1 Welcome
3. 3. Our mission is to build tools of mass innovation
4. 4. What is the biggest innovation multiplier today?
5. 5. What is the biggest innovation multiplier today? PROGRAMMING
6. 6. New hardware can do incredible things Millions of programmers Make it programmable Mass innovation
7. 7. What new hardware could do incredible things if made programmable?
8. 8. The Internet is pretty cool...
9. 9. and getting lots of upgrades! Servers, phones, TVs, cars, sensors, drones, homes, watches, maps, payment systems, scientific equipment, virtual worlds, data banks, crypto- currencies... The Internet is pretty cool...
10. 10. Could we make the Internet...
11. 11. Could we make the Internet... PROGRAMMABLE?
12. 12. App App App App App App App App App App App Eager developer The Internet Software walled gardens
13. 13. App App App App App App App App App App App Happy developer The Internet Open software layer
14. 14. For the next 5 years were going to build a software layer to make the Internet programmable
15. 15. How do we get there? 4 big goals.
16. 16. Goal 1 Reinvent the programmers toolbox
17. 17. Building distributed applications is too hard, because the tools are not adequate.
18. 18. Lets give programmers a toolbox designed for distributed applications. Developer experience matters!
19. 19. 1. Choose one fundamental problem. 2. Solve it in the simplest possible way. 3. Repeat. Incremental Revolution
20. 20. Problem 1: runtime How do I run my code repeatably on different machines?
21. 21. Docker container runtime
22. 22. Problem 1: runtime Problem 2: packaging & distribution How do I ship my code across many different machines?
23. 23. Docker distribution tools
24. 24. Problem 1: runtime Problem 2: packaging & distribution Problem 3: service composition How do I organize my application in scalable services?
25. 25. Docker Compose
26. 26. Problem 1: runtime Problem 2: packaging & distribution Problem 3: service composition Problem 4: machine management How do I deploy many machines to run my code?
27. 27. Docker Machine
28. 28. Problem 1: runtime Problem 2: packaging & distribution Problem 3: service composition Problem 4: machine management Problem 5: clustering How do I stop worrying about individual machines?
29. 29. Docker Swarm
30. 30. This is what incremental revolution looks like.
31. 31. What problems are you solving next?
32. 32. https://docker.com/experimental Docker experimental releases
33. 33. Problem 1: runtime Problem 2: packaging & distribution Problem 3: service composition Problem 4: machine management Problem 5: clustering Problem 6: networking How do I securely connect my containers across machines?
34. 34. The network should be part of the application, not the other way around.
35. 35. + SocketPlane Earlier this year...
36. 36. 3 months later...
37. 37. Introducing Docker Network
38. 38. Multi-host networking out of the box
39. 39. Micro-segmentation is built-in Assemble virtual networks into any topology, enforce security policies, insert probes and firewalls.
40. 40. Dont modify your application, Dont rip out your infrastructure. Built on industry standards
41. 41. Do you use DNS? Congratulations, you support Docker service discovery. Standardized service discovery
42. 42. Problem 1: runtime Problem 2: packaging & distribution Problem 3: service composition Problem 4: machine management Problem 5: clustering Problem 6: networking Problem 7: extensibility How do I add my own tools to the toolbox?
43. 43. Introducing Docker Plugins
44. 44. 4 new extension points Network plugins, Volume plugins, Scheduler plugins, Service discovery plugins. ... and more to come.
45. 45. No patches or restarts needed. Dynamic loading
46. 46. Multi-tenant Use different plugins for different applications.
47. 47. if your application works in Docker, it already supports every plugin. No lock-in
48. 48. Goal 2 Build better plumbing
49. 49. To build a developer platform, we need infrastructure plumbing. Lots of it.
50. 50. Infrastructure plumbers around the World are improving the Internets software infrastructure.
51. 51. The principles of software plumbing THOU SHALT I Re-use and improve existing plumbing. II Make new plumbing easy to re-use and improve. III Follow the unix principles: make small simple tools, not big complicated ones. IV Define standard interfaces for assembling larger systems.
52. 52. We have re-used a lot of plumbing to build Docker. LXC selinux apparmor lvm Linux zfs btrfs virtualbox iptables openssl tar git raft aufs serf xen kvm openvzpaxos ssh Go ... jenkins
53. 53. We have also built a lot of our own. networking os containers storage logging build content distribution code signature service discoverymaster election scheduling authentication testing load balancing code review 50% of Dockers source code is plumbing!
54. 54. Plumbing Project Introducing The Docker Lets spin it all out!
55. 55. We need your help! #dockerplumbing
56. 56. Plumbing for.... SECURITY
57. 57. Trusted, cross-platform content distribution on the Internet is an unsolved problem. Is curl | sh really the best we can do?
58. 58. Introducing Notary A trusted publishing system for any content.
59. 59. OS CONTAINERS Plumbing for...
60. 60. Its just plumbing... but its popular plumbing! Containers are 5% of Dockers code
61. 61. Introducing runC A universal runtime for OS containers https://runc.io
62. 62. Introducing RunC The universal container runtime All of Dockers container management plumbing and nothing else Super lightweight Battle-tested and production-ready Supports all security features of Linux: selinux, apparmor, cgroups, seccomp, namespaces, cap-drop.. Supports user namespaces Supports live migration Microsof is contributing Windows support Arm support underway Intel is contributing DPDK, Secure enclave Defines a standard, portable runnable format Usable from the command-line https://runc.io
63. 63. Goal 3. Promote open standards
64. 64. Its getting people to agree on something The real value of Docker is not technology
65. 65. You are the defactor standard. Now its your responsibility to make it a proper standard.
66. 66. What is a proper standard?
67. 67. 1. A formal specification Make it easy for anyone to write their own implementation A proper standard needs...
68. 68. Introducing OCF: a universal intermediary format for OS containers Supports all hardware architectures and OS
69. 69. 1. Aformal specification 2. Independent governance Dont tie the standard to a single company A proper standard needs...
70. 70. Introducing OPEN CONTAINER PROJECT in collaboration with
71. 71. 1. A formal specification 2. Independent governance 3. A neutral reference implementation The best standards start with rough consensus and working code A proper standard needs...
72. 72. Docker donates runC to the Open Container Project runC is now the OCF reference implementation
73. 73. 1. A formal specification 2. Independent governance 3. A neutral reference implementation 4. Support from a broad coalition Your standard must present a majority of the market A proper standard needs...
74. 74. OPEN CONTAINER PROJECT founding members:
75. 75. OPEN CONTAINER PROJECT founding members:
76. 76. 1. Aformal specification 2. Independent governance 3. Aneutral reference implementation 4. Support from a broad coalition 5. An open door to fresh ideas Many people have been thinking about this. Hear them out. A proper standard needs...
77. 77. OPEN CONTAINER PROJECT welcomes the APPC maintainers as founding members
78. 78. Promote open standards
79. 79. Build better plumbing
80. 80. Reinvent the programmer toolbox.
81. 81. Help organizations solve real-world problems in unique ways.
82. 82. Happy hacking!