小编Fra*_*ton的帖子

我有一个Dockerised应用程序,我想在代理和非代理主机环境中运行.我试图通过将正常的环境变量(例如http_proxy)复制到容器中来解决此问题,当且仅当它们存在于主机中时.

我可以通过跑步获得90%的路程

set | grep -i _proxy=>proxies.env

在顶级脚本中,然后在我的docker-compose.yml中:

myserver:
  build: ./myserver
  env_file:
   - proxies.env

这会将主机的环境代理变量(如果有)复制到服务器容器中,并且它的工作原理是这些变量在容器运行时可用,换句话说就是Dockerfile CMD或ENTRYPOINT执行的阶段.

但是我有一个容器需要运行npm作为构建步骤,即来自Dockerfile中的RUN命令,并且这些变量在此阶段似乎不存在,因此npm无法找到代理并挂起.在其他作品中,如果我有

RUN set

在我的Dockerfile中,我看不到来自proxies.env的任何变量,但是如果我这样做的话

docker exec -it myserver /bin/bash

然后运行set,我可以从proxies.env看到所有内容.

任何人都可以推荐一种方法,使这些变量在容器构建时可见,而不必对它们进行硬编码,这样我的docker-compose.yml和Dockerfile仍然适用于具有代理的主机和没有代理的主机？

(运行centos 7,docker-compose 1.3.1和docker 1.7.0)

在我看来,CQRS(命令和查询责任隔离)方法可能适合在GAE上实现健壮且响应迅速的社交应用服务器,因为:

1. CQRS不需要SQL数据库(GAE不提供)
2. 它确实需要一个能够保存序列化对象的数据库,GAE实际上提供了这些对象
3. 它需要事件队列,GAE也提供
4. 它支持非阻塞,异步,基于消息的体系结构,它巧妙地解决了GAE对长时间运行事务的限制
5. 它被宣传为具有高度可扩展性,这毕竟是乐观主义者选择GAE的原因

麻烦的是,我是一个生锈的Java程序员,几乎没有与这个选择相关的经验,我非常感谢任何使用过这两者的人的评论,或者至少使用其他人的经验进行调查.

我认为我的主要问题是:

1. CQRS在新应用程序的早期阶段是否过于复杂？
2. 是否存在任何可能导致它们匹配不佳的诱杀陷阱,例如GAE的数据存储可能与CQRS要求不匹配？
3. 任何人都可以推荐Axon或Jdon特别适合(或不适合)GAE吗？
4. 我应该问其他什么问题？