目前，我们正在devise新的Apache Mesos云设置的架构。 目标是通过将不同的堆栈移动到相同的架构来统一我们的系统。 主要工作负载是使用Apache Spark的大数据分析以及我们的企业基础架构，包括Web服务器，邮件服务器等。 我们的想法是在运行在Mesos（Marathon / Chronos，Aurora或Singularity）可用调度器之上的Docker容器中运行我们的Web服务。 这将成为第一个Mesos框架组。 在它旁边，我们将拥有Apache Spark框架和多个用于数据存储的数据库框架。 这将是第二组Mesos框架。 我们将在并行运行之后select具体的testing。 然而，我们很难决定运行Mesos本身的基础。 理想情况下，我们希望尽可能靠近金属。 我们也希望使用一个编排解决scheme来确保Mesos＆framework守护进程总是在失败时运行/重新启动。 我们正在考虑的选项如下： 1）在最小的OS中运行Mesos＆框架作为docker容器。 在这方面，我们正在倾向于CoreOS和舰队。 2）直接在Ubuntu / Debian服务器上运行Mesos和框架。 对于这个select，我们倾向于工头和木偶。 至于这个问题，我们正在寻找解决scheme，按照重要性： 是最简单的configuration 是最容易维护和保持更新 有最小的开销 我们之前没有和CoreOS合作过，但是我们似乎正在向前迈进。 我有一个很大的（主观）问题，就是我们在Docker容器上运行Mesos，然后在Mesos上运行Docker容器。 这似乎“不洁净”，对我来说是错误的。 这是没有价值的考虑吗？ 类似的想法涉及层之间的冗余。 为了解释我来自哪里，我宁愿如果Mesos是一个真正的操作系统，只是在金属顶部运行。 看来，不pipe你使用什么样的基础，你最终都会在不止一层的架构上（即CoreOS＆Fleet＆SystemD == Mesos＆Marathon＆Chronos）具有相同的function。 这是不可避免的？ 有没有其他好的select来运行我们没有考虑到的Mesos下面的图层，牢记我们的标准？
我有一个安装CoreOS（835.9.0）的vanilla，它不会在启动时启动docker守护进程。 它只开始时，我SSH进入，例如docker ps 。 我如何使docker守护进程在系统启动时自动启动？ 当我说docker守护进程时，我的意思是ps -ef | grep docker ps -ef | grep docker显示没有进程，直到我做docker ps
比方说，我有一个Web服务器的Docker容器（如Apache 2）。 现在我想更新它下面的操作系统。 这个SF答案说最好的方法是重build基础图像和我的Apache图像。 但是部署映像意味着停机时间，因为在创build新容器之前必须删除旧容器，因此只有一个容器绑定到端口80/443。 但是，如何以零停机时间部署此更新？ 我应该使用负载均衡器并使用集装箱间通信吗？ 我该如何更新负载均衡器？
我正在使用CoreOS来安排系统单元与车队。 我有两个单元（ firehose.service和firehose-announce.service 。我试图让firehose-announce.service启动并停止与firehose.service 。下面是firehose-announce.service的单元文件： [Unit] Description=Firehose etcd announcer BindsTo=firehose@%i.service After=firehose@%i.service Requires=firehose@%i.service [Service] EnvironmentFile=/etc/environment TimeoutStartSec=30s ExecStartPre=/bin/sh -c 'sleep 1' ExecStart=/bin/sh -c "port=$(docker inspect -f '{{range $i, $e := .NetworkSettings.Ports }}{{$p := index $e 0}}{{$p.HostPort}}{{end}}' firehose-%i); echo -n \"Adding socket $COREOS_PRIVATE_IPV4:$port/tcp to /firehose/upstream/firehose-%i\"; while netstat -lnt | grep :$port >/dev/null; do etcdctl set /firehose/upstream/firehose-%i $COREOS_PRIVATE_IPV4:$port –ttl […]
我很难搞清楚如何删除不再有文件的systemd单元。 他们似乎仍然在某种程度上在系统中徘徊。 旧的破碎单位，我想删除： core@ip-172-16-32-83 ~ $ systemctl list-units –all firehose-router* UNIT LOAD ACTIVE SUB DESCRIPTION <E2><97><8F> [email protected] not-found failed failed [email protected] <E2><97><8F> [email protected] not-found failed failed [email protected] LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, ie generalization of SUB. SUB = The low-level unit activation state, […]