Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[KubeCon NA 2018] Telepresence Deep Dive Session - Rafael Schloming & Luke Shumaker

139 views

Published on

One of the challenges facing Telepresence is growing the contributor community. It’s a complex application that requires a good understanding of OS networking, VPNs, Kubernetes, and everything in between. We’ll kick off this meeting with a general architectural overview of Telepresence. We’ll talk about how we’ve managed the project to date, and our investments to make it easier. We want to then turn it over for an interactive discussion with participants to see what we can do to make it easier to contribute and grow the Telepresence community.

Published in: Software
  • Be the first to comment

  • Be the first to like this

[KubeCon NA 2018] Telepresence Deep Dive Session - Rafael Schloming & Luke Shumaker

  1. 1. Telepresence Deep Dive Rafael Schloming & Luke Shumaker
  2. 2. datawire.io Project Goals How it works Use Cases: Real & Imagined (aka Roadmap) Future Demo?
  3. 3. datawire.io Telepresence Goals
  4. 4. datawire.io Fast high quality feedback for developers!
  5. 5. datawire.io Crystal ball for code changes!
  6. 6. datawire.io Crystal ball for code changes!
  7. 7. datawire.io Choose any two Realistic Feedback Fast Feedback Time for “Real Work”
  8. 8. datawire.io Telepresence Goal Fast and Realistic Feedback without spending half your time fixing Build System Rot
  9. 9. datawire.io How does it work?
  10. 10. datawire.io Strategy Fast: run the code locally, use all your favorite tools Realistic: wire the local code to a remote cluster Rot Proof: use low level abstractions (network, process, and file system) instead of forking app level configuration
  11. 11. datawire.io Your Code
  12. 12. datawire.io Your Code
  13. 13. datawire.io Your Code
  14. 14. datawire.io Your Code
  15. 15. datawire.io Your Code
  16. 16. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward
  17. 17. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward ssh
  18. 18. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward sshfs ssh
  19. 19. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward sshfs ssh
  20. 20. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward hijack dns & cluster IP ranges (iptables, pf via sshuttle) and divert to cluster sshfs ssh
  21. 21. datawire.io Adapters & Extension Cords
  22. 22. datawire.io Use cases
  23. 23. datawire.io Use Case 1: Development with your IDE & debugger ● The first popular use case ● Easy to explain ● We’d love more documentation on how you do this! ● Extra popular with the Java developers ○ https://www.telepresence.io/tutorials/intellij ○ https://www.telepresence.io/tutorials/java
  24. 24. datawire.io Use Case 2: Full Stack Development ● Single Page App -> API Gateway -> Serverside “Presentation” Logic -> …
  25. 25. datawire.io Use Case 3: Webhooks ● Other Site -> API Gateway -> webhook-handler -> ...
  26. 26. datawire.io Use Case 4: Automated testing with CI ● Telepresence inside your CI so tests can use remote dependencies ● Insures integration testing on local dev environments & within CI is identical ● Avoids the “lets use mocks as a substitute for integration testing” trap
  27. 27. datawire.io Use Case 5: Developing/Testing Ambassador ● Ambassador is our API Gateway built on Envoy Proxy ● Integrates deeply with k8s ● Use Telepresence Heavily for Dev & CI ○ Run ambassador on laptop for dev ○ With telepresence, it behaves just like it’s in the cluster ○ Tests run on laptop to generate traffic ● Advantages ○ Fast dev, fast test suite ○ Easy debugging (if there’s a test failure, you can easily access services) ○ Single source of truth between dev & CI
  28. 28. datawire.io Adapters & Extension Cords are Useful!
  29. 29. datawire.io Going forward
  30. 30. datawire.io Telepresence does a bunch of useful things today ● Inbound network ● Execution (env vars, filesystem) ● Outbound network
  31. 31. datawire.io Decomposition ● The UI / interface is monolithic ● The implementation is monolithic ● We’ve started decomposing some of the implementation so we can build a better UX ○ Inbound ○ Execution ○ Outbound
  32. 32. datawire.io Your Code reverse tunnel (sshd) over a kubectl port-forward hijack dns & cluster IP ranges (iptables, pf via teleproxy) and divert to places sshfs ssh
  33. 33. datawire.io What can we do with decomposition? ● Make telepresence multi-user friendly ○ Avoid the need to provision clusters or namespaces per dev ● Make telepresence require less privileges ● Pipe inbound/outbound to/from different clusters: ○ Shadow or dynamically route requests from prod ○ Send output to staging ● Override remote services piecemeal ○ Send some outbound connections to local docker containers ● Extension points for “developer discovery” ● Union clusters? ○ Run code against arbitrary combination of staging and prod
  34. 34. datawire.io Adapters & Extension Cords are Brittle :-(
  35. 35. datawire.io Not easy to Diagnose
  36. 36. datawire.io Reliability and stability ● Telepresence is very environmentally sensitive ○ Mac OS X has 3 or 4 different DNS implementations! ○ VPNs ○ Linux distros ○ … ● Want to do a better job capturing these different environments for automated tests
  37. 37. datawire.io Testing
  38. 38. datawire.io “Test bench” : A bench with many devices sitting on it, which each run the tests. “Bench test” : When you time the tests, in order to catch performance regressions. testbench: Run tests in many environments We learned that a “testcase” is an environment, as much as it is set-of-actions or a use-case. testbench is a new tool to run the test suite in many environments An “environment” is a virtual machine that has been set up a certain way
  39. 39. datawire.io testbench: Run tests in many environments
  40. 40. datawire.io Environments are a neato text format Python configparser (INI-ish) format inherited from mkosi [Distribution] Distribution=fedora [Output] Bootable=yes Cache= /home/testbench/.cache/pip [Partitions] RootSize=4G [Packages] Packages= # Base OS @core @standard @development-tools # For tests/utils.py git # Python python3-setuptools python3-virtualenv # For Telepresence conntrack-tools docker fuse kubernetes-client sshfs torsocks WithNetwork=yes environments/fedora.mkosi
  41. 41. datawire.io Environments are a neato text format Python configparser (INI-ish) format inherited from mkosi In conjunction with .postinst shell script [Distribution] Distribution=fedora [Output] Bootable=yes Cache= /home/testbench/.cache/pip [Partitions] RootSize=4G [Packages] Packages= # Base OS @core @standard @development-tools # For tests/utils.py git # Python python3-setuptools python3-virtualenv # For Telepresence conntrack-tools docker fuse kubernetes-client sshfs torsocks WithNetwork=yes environments/fedora.mkosi #!/bin/sh sudo groupadd docker gpasswd -a testbench docker systemctl enable NetworkManager systemctl enable docker environments/fedora.postinst
  42. 42. datawire.io Environments are a neato text format Python configparser (INI-ish) format inherited from mkosi In conjunction with .postinst shell script Actually, it’s garbage [Distribution] Distribution=fedora [Output] Bootable=yes Cache= /home/testbench/.cache/pip [Partitions] RootSize=4G [Packages] Packages= # Base OS @core @standard @development-tools # For tests/utils.py git # Python python3-setuptools python3-virtualenv # For Telepresence conntrack-tools docker fuse kubernetes-client sshfs torsocks WithNetwork=yes environments/fedora.mkosi #!/bin/sh sudo groupadd docker gpasswd -a testbench docker systemctl enable NetworkManager systemctl enable docker environments/fedora.postinst
  43. 43. datawire.io Environments are a neato text format Python configparser (INI-ish) format inherited from mkosi In conjunction with .postinst shell script Actually, it’s garbage But we don’t yet know what a good format looks like We don’t know which things are invariant, and which things we want control of Inspirations: ● Like mkosi? ● Like osi-mk? ● Like Dockerfile? ● Like HashiCorp Packer? ● Like Travis CI matrix? ● Some combination of ideas taken from the above?
  44. 44. datawire.io Other problems with testbench of today (AKA “next steps”) ● Can’t run on macOS hosts (sorry, macOS devs)
  45. 45. datawire.io Other problems with testbench of today (AKA “next steps”) ● Can’t run on macOS hosts (sorry, macOS devs) ● Can’t run macOS guests (sorry, GNU/Linux devs) ● Can’t specify network configurations ● Can’t specify remote Kubernetes setup ○ Uses Kubernaut, maybe Kubernaut will grow support for different cluster configs
  46. 46. datawire.io Community ● CircleCI is totally invisible to people who aren’t part of the github.com/telepresenceio organization ● CircleCI only runs for pull requests originating from the original repo ○ Some tests run against a GKE cluster--we don’t want that abused ■ Move to Kubernaut ○ Tests involve pushing to a Docker registry--we don’t want the docker.io/datawire repo abused ■ Set TELEPRESENCE_REGISTRY= when testing locally
  47. 47. datawire.io Demo
  48. 48. datawire.io Get Involved! ● Join our community! ○ Short write ups (a couple paragraphs) of how you use Telepresence are incredibly helpful! ○ Looking for more volunteers to lead / organize parts of Telepresence ○ Write code, help test, do UX testing ● Learn more about the project: ○ www.telepresence.io ○ Join the Slack: http://d6e.co/slack ○ Follow us on Twitter (@telepresenceio) ○ Stop by the Datawire booth (S47) to talk with us about how you can get involved!

×