Nicht genug RAM, um den gesamten Docker-Compose-Stapel zu laufen

Question

Unser Microservice-Stack hat sich jetzt auf 15 kleine Services für Business-Logik wie Auth, Messaging, Billing usw. aufgeschwungen. Es kommt jetzt zu dem Punkt, wo ein docker-compose up mehr RAM als unsere verwendet Entwickler haben auf ihren Laptops.

Es ist nicht eine verrückte Menge, etwa 4 GB, aber ich fühle regelmäßig die Prise auf meinem 8 GB-Gerät (danke, Chrome).

Es gibt Optimierungen auf App-Ebene, die wir machen können und machen, aber letztendlich werden wir eine alternative Strategie brauchen.

Ich sehe zwei offensichtliche Möglichkeiten:

1. eine große bewölkt Dev-Maschine verwenden, vielleicht mit Docker-Maschine und aws bereitgestellt.
2. Spinnen einige Maschinen in einem gemeinsamen dev Wolke auf, wie Postgres und redis

Diese sind nicht sehr befriedigend, in (1), lokale Dateien nicht synchronisiert werden, ein Alptraum lokalen Entwickler machen, und in (2) wir können uns gegenseitig umbringen.

Hilfe!

Apendix I: Ausgabe von Docker Statistik

CONTAINER   CPU %    MEM USAGE/LIMIT  MEM %    NET I/O    BLOCK I/O 
0ea1779dbb66  32.53%    137.9 MB/8.186 GB 1.68%    46 kB/29.4 kB  42 MB/0 B 
12e93d81027c  0.70%    376.1 MB/8.186 GB 4.59%    297.7 kB/243 kB  0 B/1.921 MB 
25f7be321716  34.40%    131.1 MB/8.186 GB 1.60%    38.42 kB/23.91 kB 39.64 MB/0 B 
26220cab1ded  0.00%    7.274 MB/8.186 GB 0.09%    19.82 kB/648 B  6.645 MB/0 B 
2db7ba96dc16  1.22%    51.29 MB/8.186 GB 0.63%    10.41 kB/578 B  28.79 MB/0 B 
3296e274be54  0.00%    4.854 MB/8.186 GB 0.06%    20.07 kB/1.862 kB 4.069 MB/0 B 
35911ee375fa  0.27%    12.87 MB/8.186 GB 0.16%    29.16 kB/6.861 kB 7.137 MB/0 B 
49eccc517040  37.31%    65.76 MB/8.186 GB 0.80%    31.53 kB/18.49 kB 36.27 MB/0 B 
6f23f114c44e  31.08%    86.5 MB/8.186 GB 1.06%    37.25 kB/29.28 kB 34.66 MB/0 B 
7a0731639e31  30.64%    66.21 MB/8.186 GB 0.81%    31.1 kB/19.39 kB 35.6 MB/0 B 
7ec2d73d3d97  0.00%    10.63 MB/8.186 GB 0.13%    8.685 kB/834 B  10.4 MB/12.29 kB 
855fd2c80bea  1.10%    46.88 MB/8.186 GB 0.57%    23.39 kB/2.423 kB 29.64 MB/0 B 
9993de237b9c  40.37%    170 MB/8.186 GB  2.08%    19.75 kB/1.461 kB 52.71 MB/12.29 kB 
a162fbf77c29  24.84%    128.6 MB/8.186 GB 1.57%    59.82 kB/54.46 kB 37.81 MB/0 B 
a7bf8b64d516  43.91%    106.1 MB/8.186 GB 1.30%    46.33 kB/31.36 kB 35 MB/0 B 
aae18e01b8bb  0.99%    44.16 MB/8.186 GB 0.54%    7.066 kB/578 B  28.12 MB/0 B 
bff9c9ee646d  35.43%    71.65 MB/8.186 GB 0.88%    63.3 kB/68.06 kB 45.53 MB/0 B 
ca86faedbd59  38.09%    104.9 MB/8.186 GB 1.28%    31.84 kB/18.71 kB 36.66 MB/0 B 
d666a1f3be5c  0.00%    9.286 MB/8.186 GB 0.11%    19.51 kB/648 B  6.621 MB/0 B 
ef2fa1bc6452  0.00%    7.254 MB/8.186 GB 0.09%    19.88 kB/648 B  6.645 MB/0 B 
f20529b47684  0.88%    41.66 MB/8.186 GB 0.51%    12.45 kB/648 B  23.96 MB/0 B 

Answer 1

Wir haben auch mit diesem Problem zu kämpfen, und immer noch nicht wirklich eine ideale Lösung. Wir haben jedoch zwei Ideen, über die wir gerade diskutieren.

1. Führen Sie eine "Dev" -Umgebung in der Cloud aus, die ständig mit der Master-/neuesten Version jedes Images aktualisiert wird, wenn es erstellt wird. Dann kann jedes einzelne Projekt in der docker-compose.yml-Datei für diese Umgebung als Proxy verwendet werden. Daher führen sie ihren Dienst lokal aus, aber alle Abhängigkeiten sind remote. Ein wichtiger Teil davon (von Ihrer Frage) ist, dass Sie Abhängigkeiten wie Datenbanken geteilt haben. Dies sollte niemals der Fall sein ... niemals über die Datenbank hinweg integrieren. Jeder Dienst sollte seine eigenen Daten speichern.

2. Jeder Dienst ist verantwortlich für die Erstellung einer "Mock" -Version seiner App, die für lokale Entwicklungstests und Integrationstests auf mittlerer Ebene verwendet werden kann. Die Scheinversionen sollten keine Abhängigkeiten haben und sollten es jemandem ermöglichen, nur eine einzelne Schicht von ihrem Dienst zu benötigen (die 3 oder 4 Mocks, anstelle der 3 oder 4 realen Dienste, jede mit 3 oder 4 eigenen und so weiter).