これは、Ubuntu 14.04 LTSにありますVM Dockerを実行しており、respawn
が私の問題の原因であると考えていますが、理想的な解決策は定かではありません。
現在のスタートアップスクリプト(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
は生きていて応答性が高いが、htop
で監視すると/sbin/init
がすべてのCPUを占有するという点で、この「機能」は機能します。 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
。
時間間隔を使用する代わりに、単にcrontabを使用します@rebootと言うだけです
そのため、このスクリプトを開始するユーザーとしてログインし、コマンドを入力します
crontab -e
そして、入力します
@reboot /better/enter/fullpath/here/docker-compose -f /usr/bin/myapp/docker-compose.yml -p myapp start
システムを再起動し、機能するかどうかを確認します。 upstartに比べて1つの利点があります。それが少し遅れて開始されたとしても、ネットワーキングなどの依存関係について既に心配する必要はありません。
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/
Dockerはすぐには準備できません。スクリプトの実行が早すぎると、何も起こりません。 Dockerは準備が整うとすぐにdocker psコマンドへの応答を開始するため、crontabでこのトリックを使用できます。
nano/etc/crontabs/root
@reboot/usr/bin/docker ps &&/usr/bin/docker-compose -f /prod.yml start