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

现在，我们的微服务栈已经为业务逻辑（如Auth，消息传递，计费等等）提供了15个小型服务。现在， docker-compose up使用的内存比我们的开发人员在他们的笔记本电脑上要多。

这不是一个疯狂的数额，大约4GB，但我经常感觉到我的8GB机器捏（谢谢，铬）。

我们可以做的应用程序级别的优化是肯定的，但最终我们将需要一个替代策略。

我看到了两个明显的select：

1. 使用一个大的多云开发机器，也许提供与docker机器和aws。
2. 把一些机器放到一个共享的dev云中，比如postgres和redis

（1）本地文件不同步，使本地开发成恶梦，（2）我们可以打破对方的环境。

帮帮我！

附录I：docker统计输出

 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

我们也一直在为这个问题而苦苦挣扎，仍然没有一个理想的解决scheme。 但是，我们有两个想法，我们目前正在辩论。

1. 在云中运行一个“开发”环境，它随着每个映像的主/最新版本的不断更新。 然后，每个单独的项目都可以在docker-compose.yml文件中代理该环境…所以它们在本地运行THEIR服务，但所有依赖项都是远程的。 这个（从你的问题）的一个重要部分是你有像数据库共享依赖。 这绝不应该是这样的…从来没有整合数据库。 每个服务应该存储自己的数据。

2. 每个服务都负责构build可用于本地开发和中级集成testing的应用程序的“模拟”版本。 模拟版本不应该有依赖关系，并且应该使某人只需要从他们的服务（3或4个模拟，而不是3或4个真实的服务，每个有3或4个自己的服务等等）的单个层。