RoofTop Brains & BBQ: Ein Gästbuch für China

1. Ein Gästebuch mit Node.js. Für China. Ja, ganz China Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.

2. „Skalieren von WebApps ist ein gelöstes Problem.“ Ich, klugscheissend Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.

3. Wer nutzt Node.js produktiv? Erst mal ein paar Abfragen. Ich bin selbst eher Generalist als Spezialist, deshalb freue ich mich immer, wenn ein paar Spezialisten dabei sind. Die dann die speziellen Fragen beantworten können, die ich nicht beantworten kann :-)

4. Wer nutzt Docker produktiv? Wer hier nutzt Docker produktiv?

5. Wer nutzt MicroServices produktiv? Und wer nutzt MicroServices?

6. Wer nutzt MicroServices auf Basis von Docker & Node.js? Und wer nutzt MicroServices auf der Basis von Docker, in Node.js? Wer in Go? Rust? Haskell? Clojure?

7. Wir machen das auch. Aber warum?

8. ä Weil es gerade auf der Mitte des Hypecycles angekommen ist, und es jetzt einfach jeder machen muss? Oder gibt es auch gute Gründe?

9. Software Architecture is not about looking cool in front of your friends. Schliesslich ist Softwarearchitektur kein Gefährt, auf dem man seine eigene Coolness produzieren will. Aber es gibt tatsächlich ein paar gute Gründe, warum man MicroServices machen will.

10. ä Neue Projekte machen Spass. Dinge neu beginnen, mit guten Tools, das ist einfach. Man ist sehr produktiv.

11. ä Boilerplate Useful Code Und klar, die entstehende Software sieht ja auch super aus. Sie ist klein, wir haben weitgehend nützlichen Code, der wirkliche Dinge tut, nur wenig Boilerplate, und wir verstehen, was da passiert.

12. Und am Ende habe ich eine Software, die gut funktioniert und genau das tut, was sie machen soll. Unsere Nutzer lieben das, endlich mal was, was wenig Aufwand gekostet hat und gut funktioniert.

13. Und deshalb wollen sie noch mehr davon, und verlangen nach mehr Funktion, und die bauen wir dann auch ein.

14. Und am Ende sieht unsere kleine Software so aus.

15. ä WTF?! Boilerplate Useful Code Die klassische Spaghetti-Lösung hat zwar immer noch Boiler-Plate-Code und funktionalen Code, aber ebenfalls auch viel Code, der nur noch da ist, weil sich niemand traut ihn zu löschen. Code, bei dem Dinge mehrfach vorkommen, wenn auch zum Teil leicht verändert. Bei dem der Technical Debt hoch ist.

16. Und wir alle kennen das Gefühl, wenn man mit aller Energie nur noch einen Big Ball of Mud langsam bewegt? Und es macht weder richtig Spass, noch kommt man gut voran? Und immer wieder, wenn man in Mist fasst denkt man „ok, das sollte man jetzt prinzipiell sauber machen“ - tut es aber nicht, weil keine Zeit dazu da ist?

17. Könnte ich in Zukunft bitte - weniger Redundanz - weniger Komplexität - mehr Vorhersehbarkeit - mehr Verlässlichkeit bekommen? in der Situation fragt man sich, ob man nicht bitte in Zukunft weniger Redundanz, weniger Komplexität, mehr Vorhersehbarkeit und mehr Verlässlichkeit bekommen kann …

18. Und klar kann man. Eigentlich wussten wir ja schon wie das geht, und deshalb hat die Gang of Four das 1994 aufgeschrieben. Eigentlich hätten wir es also schon immer wissen können, und hätten es also auch von Anfang an vermeiden können :-)

19. Brauche ich bei kleinen Projekten nicht, deshalb vergessen wir es bei jeder neuen Sprache erst mal :-) Und warum vergessen wir es jedes mal wieder? Weil wir es bei kleinen Lösungen nicht brauchen. Das Problem entsteht erst mit Wachstum der Software, die nicht mehr in unser Hirn passt.

20. Die Design Patterns erzeugen Vorhersehbarkeit, klare Verantwortung und eine klare Zuordnung von Tätigkeiten zu Code.

21. Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Das ist so eine typische Verteilung von Verantwortung - eine layer-basierte Architektur. So sehen bis heute viele grössere Webapplikationen aus. Wer hat schon einmal an so einer Applikation mit diversen Layers gearbeitet? Genau, ich auch.

22. Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Und auch in den Layers hat alles seinen Platz. Inzwischen haben wir sogar im JavaScript ein MVC-Design, das gleiche im Frontend-Layer, das gleiche dann noch mal im Rest-Service Layer dahinter, unter dem dann ﬁnal ein Business Object layer liegt.

23. Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest / REST Unit-Tests Und weil wir jetzt ja mit Qualität arbeiten gibt es auch noch diverse Testumgebungen, die das ganze stabilisieren. Meist wird die Business-Logik lokal mit Unit Tests stabilisiert, das Backend-Layer mit REST-Integrationstest und das Frontend mit Akzeptanztests.

24. „Bitte zweiten Vornamen einführen.“ Wer - wie ich - solche Architekturen schon mehrfach gebaut hat, ist nach einer Weile genervt von Ihnen. Spätestens, wenn der Pointy Haired Boss um die Ecke kommt und fragt, ob er bitte den zweiten Vornamen ins Formular haben kann.

25. Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest / REST Unit-Tests Und dann muss man tatsächlich die Acceptance Tests, den View, den Controller, das Model, den Controller, das Model, den REST-Test, den Unit-Test, das Business- Object und das ORM anfassen, und die Datenbank ändern.

26. 1 Concern so separated, dass wir 12 mal Code anfassen müssen. Wir haben tatsächlich die Software vorhersehbar gemacht, aber dabei aus einem Concern eine Sache gemacht, die in 12 mal Code anfassen resultiert.

27. Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Everyf*ckingfunctionality Das ist auch kein Wunder - denn die Business-Aspekte treten jeweils in jeder Schicht einmal auf.

28. Solche Architekturen werden von den MicroService-Jungs gerne Lasagne-Architekturen genannt. Sie bestehen aus vielen Schichten,und wenn ich was will, muss ich durch alle durch :-) .

29. Ein Gästebuch mit Node.js. Für China. Ja, ganz China Ok, aber eigentlich sind wir ja für China hier. Und China wartet jetzt, auf Slide 28, immer noch auf sein Gästebuch.

30. Gucken wir doch mal, was wir da so brauchen. Ganz China klingt ja schon mal enterprisig. Schauen wir uns das mal im Detail an.

31. 1.400.000.000 Personen China, das sind zur Zeit etwa 1.4 Milliarden Menschen. Etwa jeder siebte Mensch ist Chinese.

32. 55% 721.434.547 Personen mit Internet Teil meiner Überlegung war, dass vermutlich sehr wenige von denen das Internet nutzen. Das stimmte aber nicht - mehr als die Hälfte nutzt das Internet. Das sind zwar noch immer weniger als die 80% der Einwohner hier, trotzdem mehr als 10 mal so viele Internetnutzer.

33. 1 Besuch pro Woche Ansicht, Blättern, Eintrag, Ansicht Gehen wir mal davon aus, dass man so ein Gästebuch überschaubar nutzt. Man besucht es einmal pro Woche, also 52 mal im Jahr.

34. 1 Besuch pro Woche 3 GET, 1 POST Startseite Blättern Eintragen Angucken Und der durchschnittliche Besuch sind 4 Anfragen, die an dynamischen Content gehen. Startseite, einmal blättern, einmal eintragen, angucken, und wieder weg.

35. 2.885.738.188 Req / Woche 412.248.313 Req / Tag 4.771 Req / Sekunde Das sind dann pro Woche ja nur knappe 3 Milliarden Requests. Am Tag sind das 412 Millionen Requests, weil die Gästebücher nicht saisonal sind - bei e-Commerce hätte man da mehr drauﬂegen müssen. Macht pro Sekunde 4771 Requests.

36. 5.000 Req/Sekunde Average 10.000 Req/Sekunde Peak = 2500 POST &7500 GET Also gehen wir mal von einem Average von 5000 Requests aus, die wir für die Peakzeiten bequem auf 10.000 Requests pro Sekunde hochskalieren müssen. Pro Sekunde sind das 2500 Posts und 7500 Gets,umgerechnet. Das ist wichtig für das Caching - es muss 2500 mal pro Sekunde aktualisiert werden. 2500 mal pro Sekunde, das ist das Der Ton ist das Dis ganz rechts auf der Klaviertastatur, also Taste 79 von 88.

37. POST: 100.000 LPUSH/s GET: 50.000 LRANGE/s Benötigt: 2.500 POST 7.500 GET 10.000 Req/s Ok, gucken wir mal, ob das machbar ist. Erster Kandidat: Redis. Redis haben wir schon bei ein paar dicken Applikationen im Einsatz, das kann das gut. und ich habe es noch mal extra auf einem normalen, etwas dickeren Amazon-Server (c3.large) gemessen, da komme ich bequem im Redisbenchmark auf 100.000 LPUSH, mit dem ich Daten in eine Liste eintrage, und auf 50.000 LRANGE-Leserequests, bei denen ich die letzten 10 Einträge abhole. Das ist doch cool.

38. >100.000 Req/s Benötigt: 10.000 Req/s 10.000 Req/s Und, kann das auch der Webserver? Je nach Amazon-Klasse kann ein nginx-Node unterschiedliche Requests, praktisch sind es aber fast immer 6-stellige Zahlen. Also: kein Problem.

39. >50.000 Req/s Benötigt: 10.000 Req/s 10.000 Req/s Und node.js selbst? Wenn er eine CPU für sich alleine bekommt, dann kann er auf den 4 Cores bequem 50.000 Requests in der Sekunde abfackeln. Die Rahmenbedingungen sind also gegeben.

40. Das ist doch machbar. Aller Erfahrung nach sollte das also gehen.

41. Und zwar auf einem einzigen Rechner. Und zwar auf einem einzigen Rechner. 2 CPUs mit jeweils 4 Kernen, sollte gehen.

42. Klar geht das. Mit einem HelloWorld. Der Nachteil an der Überlegung: das geht, klar. Mit einem hello-World-Script. Wenn meine Software darüber hinaus geht sieht es anders aus.

43. Was im Request passiert Kernel Serverprocess Compiler/Interpreter Applikation Aber schauen wir uns das mal im Detail an. Wenn der Request auf dem Webserver landet, dann ist das erst mal ein Interrupt auf Hardware-Eben, der dann den Kernel veranlasst, eines seiner Module danach zu befragen, was damit geschehen sollte. Das liest die Daten aus und gibt sie an den Servierprozess weiter, und der wirft den Compiler/Interpreter an. Und erst da beginnt die Applikation.

44. Was im Request passiert 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befüllen 13.Template rendern 14.Response erstellen Und da beginnt erst die richtige Arbeit. Der Request muss vom Framework geparsed werden. Dann wird der Router angeworfen, um herauszuﬁnden, welcher Controller sich darum kümmert. Dann wird dieser angeworfen, und muss erst mal gucken, welche Daten da von ihm von draussen kamen. Und dann denkt er über diese Daten nach, und ﬁndet heraus, was auf dieser Basis er von der Datenbank holen soll. Also einen Datenbankrequest gebaut, den über Kernel zur DB, dort bearbeitet, wieder zurück, Ergebnis demarshallen, Aufbereiten, damit rechnen, das Template initialisieren, befüllen und rendern, und dann dem Webserver zur Ausgabe geben.

45. Was im Request passiert Applikation: 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befallen 13.Template rendern 14.Response erstellen Nimmt man die ganzen Indirektionen und Abstraktionen raus, dann gibt es eigentlich nur 3 Dinge wirklich zu tun - Request verstehen, Wert berechnen und wieder zurückgeben. Die Datenbank könnte ich ja auch selbst im Ram halten.

46. Was im Request passiert Real Code Boilerplate Language Prozess Kernel Die wahre Ressourcennutzung in meinem Request liegt also nicht im Funktionalen Code, sondern in der ganzen Boilerplate drumherum. Etwas ist zwangsläuﬁg, weil wir einen Kernel mit Prozessen etc haben, vieles ist aber die Boilerplate unserer Programmierumgebungen.

47. Fun Fact 1:   Bei PHP-Symfony- Applikationen liegt der funktionale Anteil   unter 0.1 %. Ich kenne das selbst sehr gut aus Consulting-Projekten im PHP-Bereich: der tatsächlich relevante Code ist nur ein Bruchstück dessen, womit die CPU ihre Zeit verbringt. In diesem Kontext - bei Symfony, das ist quasi Spring für PHP, liegt es praktisch immer unter 0.1%.

48. 0 750 1500 2250 3000 Request / Sekunde Node.js nativ Node.js Express-Routing Node.js Express + Jade-Template Fun Fact 2: Dito Node.js Bei Node.js ist es aber auch nicht wirklich besser. In meiner lokalen Testumgebung auf einem i7-Core, ohne Virtualisierung konnte die gleiche Gästebuchapplikation mit nativem Code etwa 2500 Request, mit express als Framework etwa 1500 Requests - und mit Jade zur Ausgabe bei nur einem Template, aber einer Schleife nur noch 50. Hier wirken also 98% Boilerplate.

49. Fun Fact 3:   Das Gästebuch als Kernelmodul würde auf einem Raspberry PI China versorgen. Und noch ein Fun-Fact: wenn wir das ganze als Kernelmodul in C direkt auf dem ethernet-Driver programmieren würden, könnten wir China vermutlich mit einem Raspberry PI versorgen.

50. Wäre es dann zum Skalieren nicht viel sinnvoller auf den funktionalen Code zu fokussieren? Da stellt sich die Frage: wenn ich so viele Dinge mache, die eigentlich nur Boilerplate sind, damit der Code sich um sich selbst kümmern kann und der Entwickler auf der Ebene höherer Konstrukte arbeitet, wäre es nicht besser, bei skalierbaren Applikationen den Fokus auf den echt wirksamen Code zu setzen?

51. Und davon dann für jede Funktion eine kleine Applikation anbieten, die genau diese Sache schnell & skalierbar macht? Man könnte dann ja die ganze grosse Applikation in kleine Scheiben schneiden, die für den jeweiligen Aspekt im wesentlichen aus viel Funktion und wenig Boilerplate bestehen. Und diese Scheiben wären dann echt schnell und skalierbar.

52. Ravioli instead of Lasagna or Spaghetti

53. Ack, und das könnten wir dann „MicroServices“ nennen. Ja, könnte man machen, und das könnte man dann MicroServices nennen. Die Jungs, die damit angefangen haben - und damit meine ich vor allem Amazon und Konsortien - haben genau diese Aufgabe und diesen Plan gehabt. Wenn ich viele Millionen Server habe ist es wichtig, ob ich 0.1%,1% oder 80% der CPU für echte Funktion nutze. 100 mal mehr Server, dafür aber schönerer Code - das ist schwer zu verargumentieren.

54. „The services are small - fine-grained to perform a single function.“ Schauen wir uns doch mal die Quasioffizielle Definition von MicroServices in der Wikipedia an: the die Services sind kleingeschnitten, so dass sie nur eine einzige kleine Funktion erfüllen.

55. Each service is elastic, resilient, composable, minimal, and complete. Sie sind elastisch, minimal, vollständig und man kann sie verdrahten.

56. The culture and design principles should embrace failure and faults, similar to anti-fragile systems. Damit ich das brauchbar machen kann, brauche ich eine Kultur der Fehlertoleranz. Ich muss es überleben, wenn ein paar von denen zeitweilig weg sind.

57. The organization culture should embrace automation of deployment and testing. Und am Ende soll die Organisationskultur das ganze auch automatisieren können, damit ich schnell skalieren kann - und auch schnell entwickeln kann. Und während ich die Aspekte Agilität, Developereﬃzienz und Agilität normalerweise liebe, verzichte ich heute zugunsten der Zeit und der Skalierbarkeit darauf.

58. ä MicroServices „Applications that ﬁt in your head. Eine ebenfalls schöne Deﬁnition ist : Applikationen, die in den Kopf passen.

59. ä MicroServices „Applications that ﬁt in your head. Boilerplate Useful Code Boilerplate Useful Code Boilerplate Useful Code Also: ganz viele kleine Greenﬁelds.

60. ä MicroServices Node.js Docker WTF Node.js & Docker?! Ok, MicroServices macht also Sinn - aber warum, um Himmels Willen, nodejs? Und warum bitteschön Docker? Kann

61. ä Es skaliert gut … … über Entwickler Die Antwort darauf ist einfach - beide Werkzeuge skalieren sehr gut über die Ressource, die in unserer Branche am wenigstens vorhanden ist - Developer.

62. ä „Applications that ﬁt in their heads. Aber das sind doch alles Anfänger! Und klar gibt es dann immer das Argument, dass die Heerscharen der Docker- und Node-JS-Nutzer viele Juniors enthalten. Und klar ist die Antwort: Ja, natürlich, wenn das alles nur Seniors wären, dann wären das ja auch nicht viele Entwickler. Aber es gibt einen Vorteil: MicroServices sind genau darauf eingestellt. Einen Junior kann man deutlich besser mit einem MicroService als mit einem Monolithen betreuen. Die kleinere, einfacher zu verstehende Software.

63. ä „Applications that ﬁt in their heads. Yep, MicroServices eignen sich gut für Anfänger. Das klingt jetzt total doof, ist aber trotzdem so- MicroServices eignen sich gut für Anfänger. Das ist quasi ein Abfallprodukt des Initialplans.

64. „Elastic“, „ﬁne-grained“, „automated“ deployed, „failure“ & „fault“- tolerant? Und bei Docker sprechen auch viele andere Dinge für den Einsatz bei MicroService-Architektur

65. Und das haben auch viele andere gemerkt. Google sagt, es gäbe zur Zeit etwa eine halbe Million Treffer zu Docker und MicroServices, und praktisch seit 2014/15 kommen beide häufig nicht alleine zur Party. Die Trefferzahl zu JavaScript bzw. Nodejs MicroServices liegt auf dem gleichen Niveau.

66. Tools für eine MicroService- Orchestrierung mit Docker Wie sieht das also konkret aus, wenn ich Docker und MicroServices für die Orchestrierung von, sagen wir mal, einem hochskalierbaren Gästebuch einsetzen will. Ich werde zunächst die Mitspieler vorstellen, und dann kurz den Einsatz an einem echten Beispiel zeigen.

67. Outing 1: Ja, es gibt auch andere Tools, die das können. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.

68. Outing 2: Der aktuelle RC von Docker hat vieles Builtin. Und kaputt. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.

69. Tools: Docker - Container-CLI - Erstellen von Images - Veröffentlichen von Images - Remote-Interface zum Docker-Host - Daemon/ Docker-Host - Rest-Service als Interface auf Port - Starten, stoppen, laden von Images Beginnen wir mit Docker. Die, die es schon kennen, langweilt es vermutlich eher.

70. Tools: Docker Machine - Maschinen mit Docker-Host erzeugen - auf VirtualBox - Amazon Eck - Digital Ocean … - Verwaltung der Maschinen - Docker-CLI auf die Maschine wechseln - Listen , Stoppen etc Das nächste Tool der Wahl ist Docker-Maschine. Da kommen die kleinen DOCKER_HOSTS her, mit diversen Interfaces.

71. Tools: Docker Swarm - Docker über mehrere Server - Gemeinsamer Docker-Host - Swarm-Manager mit Fail-Safety - neue Server können Joinen - mit Event-Bus Etwas frischer ist der Docker Swarm, der gerade in der Version 1.0 rausgekommen ist - und vor 2 Wochen gab es dazu die Swarm Week mit vielen Blogartikeln. Ich mag swarm, weil er Dinge, die sonst kompliziert sind (Hallo, Kubernetes), auf einem recht überschaubarem Dilletantenniveau hält.

72. Tools: Swarm-Mode - Neu in Docker 1.12 - Scaling vorhanden - Service Discovery über DNS - Ingress Load Balancing - Rolling Updates! Now: BuiltIn Swarm-Mode Inzwischen - mit dem aktuellen Release-Candidate - ist der Swarm-Mode default-Bestandteil von Docker.

73. Tools: Docker Compose - Docker-Cluster anlegen - YAML-Konﬁguration über docker- compose.yaml - Anlegen von Services/Containern - Anlegen von Netzwerken - Anlegen von gemeinsamen Devices - Skalieren von Services! Damit die diversen Docker-Service mit einander zurecht kommen gibt es Docker Compose. Docker Compose bekommt eine wirklich einfache Yaml-Datei, mit der man nicht nur die Services und Ihr Zusammenspiel orchestrieren kann, sondern auch gemeinsame Volumes und Netzwerke einrichten kann. Und so geil das Tool ist, ein paar Lücken gibt es noch - zB. klappt das verteilen von lokal gebauten Images noch nicht im Schwarm, da muss also die eigene Registry her, wenn man den bedienen will.

74. Tools: Consul - Key-Value-Storage zur Verwaltung - Fail-Safe - DNS-Support - Support von Docker Swarm - eigentlich „Konsensus-Tool“ Ebenfalls schon länger mit dabei: Consul als Key-Value-Store, der zur Verwaltung der Daten genutzt wird. Er ist Cluster-fähig, und eine der Backends, das vom Docker Swarm verwendet werden kann.

75. Tools: Interlock - Event-Plugin-System - Lauscht auf dem Event-Bus eines Swarm - Startet Plugins: - nginx - haproxy - ergänzt neue Container in nginx/ haproxy ein Und kommen wir zum letzten Tool der Orchestrierung: Interlock. Interlock nennt sich selbst ein Event-Plugin-System, das alle Events aus dem Docker-Schwarm mitbekommt - also zB neue Container, die joinen. Und wenn er erkennt, dass diese Container zu http geroutet werden sollen, dann aktualisiert er den dazugehörigen Proxy oder Webserver.

76. 1. Eine Node-App zu einem Container   machen DockerFile-> ATOM Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerﬁle.

77. docker build -t johannhartmann/ noderedis . docker push johannhartmann/noderedis Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerﬁle.

78. 2. Einen Schwarm erzeugen

79. Aber kommen wir mal zur konkreten Architektur: Draussen wohnt das Internet, hier drinnen wohnen wir - mit 4 Host-Nodes, einem Redis-Node, einem Manager und dem Interlock/Redis-Node als Manager.

80. Manager-Maschine:  Consul starten docker run --restart=unless-stopped -d -p 8500:8500 -h consul progrium/ consul -server -bootstrap Jetzt habe ich also ganz viele Maschinen, und die sollen zu einem Schwarm werden. Und ich beginne mit Consul, dem Storage für den Schwarm.

81. Manager-Maschine: Swarm-Manager starten docker run --restart=unless-stopped -d -p 3375:2375 swarm manage consul://192.168.33.11:8500/ Damit der Schwarm auch tatsächlich einer werden kann starte ich einen Schwarm-Manager. Das können wie bereits gesagt mehrere sein, in diesem Beispiel nutze ich aber nur einen. Der Schwarm-Manager lauscht selbst, wie der Docker-Host sonst auch, auf Port 2375 bzw. 2376 bei tls. Weil ich den Port auf dem Host schon für den normalen Docker-Container nutze, muss ich hier auf Port 3375 ausweichen.

82. Manager-Maschine: Nodes registrieren docker -H=tcp://192.168.33.20:2375 run -d swarm join -- advertise=192.168.33.20:2375 consul://192.168.33.11:8500/ Ein Schwarm ohne weitere Rechner nutzt mir aber nichts. Deshalb registriere ich mal alle anderen Maschinen - beginnend mit den Workern. Die Registration sieht ähnlich dem swarm manage von eben aus, nur jetzt mit dem Kommando join. Er soll sich selbst für den Swarm als Docker-host bekannt machen, und zwar auf der IP 192.168.33.20. Und für die Datenverwaltung soll er auf den Consul-Service auf dem Manager-Node zurückgreifen.

83. Manager-Maschine: Redis, Interlock, Manager docker -H=tcp://192.168.33.250:2375 run -d swarm join -- advertise=192.168.33.250:2375 consul://192.168.33.11:8500/ … Die gleiche Registration passiert auch auf den anderen Maschinen.

84. Wenn sie gejoint haben kann ich mir die vollständige Liste der Container - also der Container, die auf den beteiligten Docker-Hosts laufen, wenn auch nicht im Swarm - wieder mit docker ps -a angucken.

85. Manager-Maschine: Overlay Network docker network create --driver overlay mynet Auch die Docker-Netzwerk-Fähigkeiten lassen sich in dem Swarm nutzen - Voraussetzung it allerdings, dass hier der Key-Value-Storage, hier im Beispiel Consul, existiert. Dann kann ich mit diesem Befehl das Overlay-Network anlegen.

86. Docker Compose: docker-compose.yml https://github.com/johannhartmann/chinaguestbook/blob/ master/docker-compose.yml Docker-Compose wird über die docker-compose.yml gesteuert. Diese Daten enthält alle relevanten Informationen über die Container selbst, den Netzwerke und die gemeinsame Volumes.

87. Lokal: Compose-Cloud starten docker-compose build - öhm, doch nicht. docker-compose up Normalerweise würde man jetzt die Pakete für den Docker-compose bauen. Aber: Docker-Compose kann lokal gebaute Pakete noch nicht an einen Schwarm verteilen. Also muss ich sie vorher selbst pushen. Wenn ich das getan habe kann ich meine Cloud aber durchstarten. Das mache ich mit „docker compose up“ - und in Folge werden alle Images auf alle hosts gepullt, und dann anhand der Constraints auf den Hosts gestartet.

88. Benchmark 1 Container Jetzt, wo meine Cloud - wenn auch nur mit einem Container - online ist, kann ich ja mal gucken, wieviel Durchsatz sie hat. Und tatsächlich - es sind nur 80 Requests/ Sekunde.

89. Lokal: Compose-Cloud skalieren docker-compose scale web=100 Also müssen wir das skalieren. Das machen wir mit einem sehr einfachen Befehl - docker-compose scale web=100 - und schwupps, wird die Zahl der laufenden Container auf 100 erhöht. Weil diese Applikation CPU-Bound ist, muss ich schlicht etwa so viele container bauen, wie ich Kerne habe - denn mehr als 100% CPU-Last möchte ich nicht auf den Maschinen haben.

90. Benchmark 100 Container Und tatsächlich - wenn ich 100 Container durchstarte auf den beiden grossen Hosts, dann bekomme ich genug Traﬃc für knapp ein halbes China. Sorry, dass ich hier nicht ganz China gedemoed habe - das war mir bei den m4.x10large-Images zu teuer :-) Aber es geht.

91. Strategie für Micro- Service Architekturen mit Node.js auf Docker 1. Node.js-Services klein schneiden und einzeln als Container paketieren Also, mal alles zusammengenommen: ich zerlege meine App in mehrere Services, die jeweils für sich autark laufen. Jeden dieser Services packe ich in einen Docker-Container.

92. 2. Micro bedeutet auch die Chance, auf Boilerplate verzichten zu können, und das erzeugt Performance Strategie für Micro- Service Architekturen mit Node.js auf Docker Ich nutze die Chance, auf boilerplate und Libraries zu verzichten, wenn ich wirklich skalieren muss. Boilerplate & Frameworks haben einen Impact von Faktor 10 bis Faktor 1000. MicroServices erlauben mir, auch ohne Boilerplate Software zu überleben.

93. 3. diese Services kann man über docker-compose/swarm einfach skalieren Strategie für Micro- Service Architekturen mit Node.js auf Docker Wenn ich die Services in einem Container habe, fällt mir das skalieren leicht.

94. 4. und über Dienste wie interlock auch unmittelbar nach aussen freigeben. Strategie für Micro- Service Architekturen mit Node.js auf Docker Über Dienste wie interlock integriere ich neue Dienste oder zusätzliche Container implizit, ohne dass zusätzlicher Aufwand ensteht. Mit den aktuellen Docker-Tools ist die Schwelle zur Konﬁguration und zur Nutzung deutlich geringer geworden, als dies vorher der Fall war. Ich habe den Komfort von PAAS, ohne mich an einen Anbieter binden zu müssen.

95. Ich brauche 4 m4.10xlarge Hosts für China mit Jade. China-Fazit:

96. Die Docker-Welt hat immer noch viele Bugs und wenig Doku.

97. Es wird trotzdem ein Commodity-Ding für alle.

98. Die aktuellen LargeScale- Tools werden Commodity.

99. Kleine Services, wenig Boilerplate.

100. ä Wenn man das so macht, dann hat die Arbeit wieder deutlich mehr Greenﬁeld-Feeling.

101. Files: https://github.com/johannhartmann/chinaguestbook Slides: http://slideshare.net/johannhartmann Video: Slideshare embedded (Mal ehrlich: ich hätte es trotzdem mit PHP gemacht :-) Vielen Dank!

RoofTop Brains & BBQ: Ein Gästbuch für China

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

RoofTop Brains & BBQ: Ein Gästbuch für China

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (8)

Similaire à RoofTop Brains & BBQ: Ein Gästbuch für China (20)

Plus par Johann-Peter Hartmann (6)

Plus récents (20)