☰

DockerFile と docker-compose (Homeassistant および Node-red ノード)

tag-icon • tag-icon docker docker-compose
DockerFile と docker-compose (Homeassistant および Node-red ノード)

これが簡単であることを願います。私は Docker を使用して、Raspberry Pi 4 で Homeassistant および Node-Red コンテナーを実行しています。

に基づくこのガイドHomeassistant をサポートするには、DockerFile を作成して Node-Red ノードをインストールすることが推奨されています。インストールは、npmNode-Red コンテナ内のコマンドによって処理されます。

docker-compose.yamlとの両方をDockerfileディレクトリに作成しました(ファイルの内容は下記)。

docker-compose upコンテナを起動するには、ファイルが存在するディレクトリでコマンドを使用しますdocker-compose.yaml。問題なく同じことを実行する systemd サービスも作成しました。

私の問題は、DockerFile実行時に処理されないことですdocker-compose up

コンテナが起動/再起動されるたびdocker-composeに変更を取得する方法はありますか?DockerFile

[docker-compose.yaml]

version: "3.6"
services:
  node-red:
    build: .
    container_name: node-red
    environment:
      TZ: /etc/localtime
    image: nodered/node-red
    restart: unless-stopped
    ports:
      - "1880:1880"
    volumes:
      - "/[folders]/node-red/data:/data"


[DockerFile]
FROM nodered/node-red

RUN npm install node-red-contrib-actionflows \
    # https://flows.nodered.org/node/node-red-contrib-actionflows
                            node-red-contrib-home-assistant-websocket \
    # https://flows.nodered.org/node/node-red-contrib-home-assistant-websocket
                            node-red-contrib-stoptimer \
    # https://flows.nodered.org/node/node-red-contrib-stoptimer
                            node-red-contrib-time-range-switch \
    # A simple Node-RED node that routes messages depending on the time. If the current time falls within the range specified in the node configuration, the message is routed to output 1. Otherwise the message is routed to output 2.
                            node-red-contrib-timecheck \
    # Is it that time yet? This node compares a given time to the current time.
                            node-red-node-timeswitch
    # node to provide a simple timeswitch node to schedule daily on/off events

答え1

簡単にテストしてみましたが、ここには 2 つの問題があると思います。1 つは単純なもので、もう 1 つは実は非常に微妙なものです。

最初の問題は、イメージがすでに存在する場合、Compose はサービスのイメージを自動的に再構築しないことです。サービスを初めて実行すると、Compose は dockerfile を使用してイメージをビルドしますが、その後の実行では既存のイメージを再利用します。ドキュメント実際にはこの点についてイライラするほど不明瞭ですが、サンプル ファイルから実行したときのコマンド出力の方docker-compose upが役立ちます。

...
WARNING: Image for service node-red was built because it did not already exist. To rebuild this image you must use `docker-compose build` or `docker-compose up --build`.
...

必要な動作を得るには、--build同じタグのイメージが存在するかどうかに関係なく再構築をトリガーするフラグを使用するように systemd サービスを変更する必要があると思います。

2 番目に発生していると思われる問題は (これもサンプル構成の修正バージョンを使用して実行した簡単なテストに基づいています)、ビルドごとにベース イメージ タグを上書きしていることです。

Composeファイルリファレンスのディレクティブセクションbuild（3番目のブロックの下）によると、このリンク) と の両方buildがimageサービスに指定されている場合、docker はビルド ディレクティブに従ってイメージをビルドし、イメージ ディレクティブの値を使用してタグ付けします。docker image-compose ファイルのディレクティブとFROMdockerfile のディレクティブは同じタグを使用するため、ローカルでビルドされたイメージに、dockerfile が取得するベース イメージと同じ名前でタグ付けするように Docker に指示していることになります。

つまり、コンテナの各リビルド (最初のビルド後) では、nodered/node-redアップストリームからではなく、以前のバージョンがベース コンテナとして実際に使用されることになります。

imageこれを修正するには、コンポーズファイル内のディレクティブの値を別のものに変更するだけです。例:local-custom-node-red

関連情報