这是在运行 Docker 的 Ubuntu 14.04 LTS VM 上发生的,我怀疑这respawn
是我的问题的原因,但不确定理想的解决方案。
当前 upstart 脚本 ( cat /etc/init/dockersuitecrm.conf
)
description "Start docker containers"
author "Batman"
start on filesystem and started docker
stop on runlevel [!2345]
respawn
script
docker-compose -f /usr/bin/myapp/docker-compose.yml -p myapp start
end script
这在运行时myapp
是“有效的”,并且是活动的且响应迅速,但当/sbin/init
我使用 进行监控时,它会占用所有 CPU htop
。如果我从 upstart ( ) 中删除条目sudo rm /etc/init/dockersuitecrm.conf
并手动通过 SSH 登录并运行,docker-compose -f /usr/bin/myapp/docker-compose.yml -p myapp start
我不会看到 CPU 处于 100% 的问题,并且像以前一样myapp
再次活动并响应迅速。
所以我怀疑我上面启动docker-compose的方式是错误的。正确的启动方式docker-compose
是始终运行而无需人工干预吗?
编辑:不应该有关系,但/usr/bin/myapp -> /home/batman/dockerapps/myapp
作为符号链接。
答案1
只需使用 crontab,而不是使用时间间隔,只需说 @reboot
因此,以应启动此脚本的用户身份登录并输入命令
crontab -e
然后输入
@reboot /better/enter/fullpath/here/docker-compose -f /usr/bin/myapp/docker-compose.yml -p myapp start
重启系统,看看它是否能正常工作。与 upstart 相比,它有一个优势,即使它启动得晚一点,你也不必太担心网络等依赖项是否已经启动。
答案2
假设您正在使用 Docker Compose 定义版本 2 docker-compose.yml
,您可以执行以下操作:
定义restart: always
如下:
version: '2'
services:
web:
image: nginx
restart: always
参考: https://docs.docker.com/compose/compose-file/compose-file-v2/
答案3
Docker 不会立即准备就绪如果您过早运行脚本,则不会发生任何事情。docker 将在准备就绪后立即开始响应 docker ps 命令,因此您可以在 crontab 中使用此技巧:
纳米/etc/crontabs/root
@reboot /usr/bin/docker ps && /usr/bin/docker-compose -f /prod.yml 启动