我们谈论的是Docker容器,例如sysdig,consul,fluentd,mesos-slave等,我们几乎在所有机器上运行。
当前,我们正在使用Ubuntu的Upstart和CoreOS的Fleetctl。我们正在迁移到Ubuntu 18.04 LTS,目前正在考虑是否将配置转换为:
Systemd可以进行运行状况检查,并自动使死掉的进程重新联机。它也与我们大量使用的Upstart最相似。我们的Upstart配置文件是通过cloud-config生成的,如下所示:
- >
/usr/local/bin/generate-docker-upstart fluentd registry/fluentd:1.0.1
-e HOST=elasticsearch
-e PORT=9200
-e INDEX=fluentd
-e NODE=`hostname -s`
-e ROLE=app
-e ENVIRONMENT={{Ref:Environment}}
-e TENANT={{Ref:Tenant}}
-p 24224:24224
--name \$NAME \$IMAGE
我们使用AWS CloudFormation使虚拟机联机。
我们不能使用真实的容器编排框架(我们已经使用Marathon / Mesos),因为这些服务必须在每台主机上运行,并且必须在Marathon / Mesos运行之前。
哪种解决方案最有意义?尽管已经在Mesos上使用Marathon,将这些文件转换为systemd还是开始使用docker-compose?
答案 0 :(得分:0)
答案 1 :(得分:0)
免责声明:我不是一个精通systemd的用户,所以我的回答将总结docker-compose的某些功能并给出一些指示。
您说
我们不能使用真实的容器编排框架[…]哪种解决方案最有意义?尽管已经在Mesos上使用Marathon,将这些文件转换为systemd还是开始使用docker-compose?
但是可以注意到,docker-compose
本身是一个容器编排工具(尽管比其他一些编排解决方案更轻巧)。
Systemd可以进行运行状况检查,并自动使死掉的进程重新联机。它也与我们大量使用的Upstart最相似。我们的Upstart配置文件是通过cloud-config生成的,如下所示:[…]
您可能已经对docker-compose
有了一些见解,但是为了完整起见,它可能被视为Python中实现的“ Docker前端”,它允许:
用YAML中的声明性配置替换复杂的Docker命令(例如docker build
,docker run
等)。有关此表达性规范的更多详细信息,请参见the doc。
管理多容器应用程序的整个生命周期(可能使用自定义网络,卷等)。特别是,可以告诉docker-compose
总是在出现错误的情况下重新启动给定的容器,并通知specify health checks。
例如,请参见以下两个指针:
https://blog.codeship.com/ensuring-containers-are-always-running-with-dockers-restart-policy/(我个人更喜欢restart: unless-stopped
政策)
https://howchoo.com/g/zwjhogrkywe/how-to-add-a-health-check-to-your-docker-container(带有涉及容器健康检查的Python Web应用程序示例)。
最后,请注意,使用docker swarm
是另一种替代解决方案,至少与docker-compose
一样“标准”,并且还具有集群功能-将一组Docker引擎转变为一个虚拟Docker引擎(source)。
两个相关的指针: