memory-management - 没有足够的内存来运行整个 docker-compose 堆栈

Question

我们的微服务堆栈现在已经增加了 15 个用于业务逻辑的小型服务，例如身份验证、消息传递、计费等。现在已经到了 docker-compose up 的地步。比我们的开发人员在他们的笔记本电脑上使用更多的内存。

这不是一个疯狂的数量，大约 4GB，但我经常感觉到我的 8GB 机器上的压力(谢谢，Chrome)。

我们可以并且正在做应用级优化，但最终我们将需要一个替代策略。

我看到两个明显的选择:

使用大型多云开发机器，可能配备了 docker-machine 和 aws。

将一些机器旋转到共享的开发云中，例如 postgres 和 redis

这些都不是很令人满意，在 (1) 中，本地文件没有同步，使本地开发成为一场噩梦，而在 (2) 中，我们可以破坏彼此的环境。

帮助!

附录 I:来自 docker stats 的输出

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

我们也一直在努力解决这个问题，但仍然没有真正理想的解决方案。但是，我们目前正在辩论两个想法。

在云中运行“开发”环境，该环境在构建时不断更新每个镜像的主版本/最新版本。然后每个单独的项目都可以在他们的 docker-compose.yml 文件中代理到该环境......所以他们在本地运行他们的服务，但所有依赖项都是远程的。这其中的一个重要部分(来自您的问题)是您共享了数据库等依赖项。永远不会是这种情况......永远不要跨数据库集成。每个服务都应该存储自己的数据。

每个服务负责构建其应用程序的“模拟”版本，可用于本地开发和中级集成测试。模拟版本不应该有依赖性，并且应该使某人只需要他们的服务中的一个层(3 或 4 个模拟，而不是 3 或 4 个真实服务，每个服务都有 3 或 4 个自己的等等)。