Synology NAS に Docker をインストールする

まずモデルがサポートしているかどうかを確認してください

Container Manager はすべての Synology モデルで提供されているわけではありません。Synology はモデルごとに決定し、リストにないモデルではロックを解除する設定はありません。 Plus シリーズ モデル (DS220+ や DS920+ など、名前に + が付いているもの) はこれをサポートしており、Synology は、DS124、DS223、DS423 に加え、DSM 7.2 の DS420j など、厳選されたバリュー モデルもリストしています。他のほとんどの小規模な J シリーズおよび古い Play モデルには、このパッケージはまったく提供されません。

2 分間のチェックにより、実際の NAS が検出されます。パッケージ センター を開き、コンテナ マネージャー を検索します (DSM 7.1 以前では、Docker を検索します)。表示されている場合、そのモデルはサポートされています。表示されない場合は、そのパッケージがあなたのモデルでは利用できないだけです。隠れたスイッチを見つけることはできません。

パッケージ センターからパッケージをインストールします

インストール自体は最も簡単な部分です。これは、Synology 独自のストアからの通常の公式 DSM パッケージです。 パッケージ センターを開き、コンテナ マネージャー (DSM 7.1 以前ではDocker) を検索して、インストール をクリックします。 DSM がパッケージをどのボリュームに保存するかを尋ねた場合は、メインの最も広いボリュームを選択してください。

インストールが完了するまで待ってから、パッケージを一度開き、DSM が作業フォルダーを作成します。 DSM 7.2 以降では、概要、プロジェクト、コンテナ、イメージ、レジストリ、 ネットワークおよびログという名前のタブが表示されます。古い Docker パッケージの画面はやや簡素に見えますが、動作は同じです。プロジェクトは、1 つのアプリに属する複数のコンテナを 1 つの Compose ファイルから一緒に実行する方法です。最初のコンテナにはプロジェクトは必要ありません。

他の作業の前に Docker 共有フォルダーを作成します

これは初心者が飛ばして後悔するステップです。コンテナの内部は一時的なものです。コンテナを削除すると、コンテナ内に保存されているものはすべて削除されます。実際のデータは、コンテナが指す通常の共有フォルダに存在する必要があります。

[コントロール パネル] → [共有フォルダ] → [作成] を開き、フォルダに docker という名前を付けます。その中に、アプリごとに 1 つのサブフォルダーを作成します。たとえば、docker/porttainer や docker/jellyfin などです。 1 つのアプリ、1 つのフォルダー: バックアップとクリーンアップはシンプルです。後でコンテナーを作成するときは、ここでそのデータ パスをそのフォルダーにマップします。このマッピングはボリュームと呼ばれ、このページで最も重要な考え方です。

最初のコンテナをテストとして実行する

実際に興味のあるアプリから始めないでください。小さな使い捨てコンテナから始めて、イメージのダウンロード、ポート、ボリューム、ログなどのチェーン全体が機能することを証明します。コンテナ マネージャーでレジストリを開き、小さなテスト イメージ (小さな静的 Web サーバーが理想的です) を検索してダウンロードします。公式プロジェクトまたは有名なメンテナーによって公開されたイメージを優先します。見知らぬ人によるランダムな再アップロードは危険です。ダウンロードしたイメージは、イメージ の下に配置されます。

画像を選択し、実行を選択します。コンテナには、6 か月後に認識できる明確な名前を付けます。ポートの場合: コンテナー自体のポートはアプリによって固定されます。ジョブはローカル (ホスト) ポートです。 DSM 自体はすでに独自の Web インターフェイスに 5000 と 5001 を使用しているため、8080 以上のような明確なものを選択して書き留めます。アプリが何かを保存する場合は、そのデータ パスを Docker 共有フォルダー内のフォルダーにマップします。テスト アプリの場合は、テスト サブフォルダーで問題ありません。テスト コンテナの自動再起動はオフのままにしておきます。ループで永遠に再起動するのを監視するのではなく、失敗した場合に失敗するのを確認したいのです。

ログを読んでブラウザで開きます

ブラウザをタッチする前に、コンテナを起動し、ログ タブを開きます。ログはアプリがあなたに話しかけているものです。正常なアプリは、ready 行 (多くの場合、リッスンしているアドレスとポート) を出力します。ループ内で起動および停止するコンテナーは、書き込みできないフォルダー、必要な設定、またはすでに使用されているポートなど、何かが不足していることを示しています。ログの最後の数行は通常、問題をわかりやすい言葉で示しています。

ここでブラウザを開いて、選択したポート (たとえば、ポート 8080) を使用して NAS アドレスにアクセスします。アプリ自身のページが表示されるということは、イメージがダウンロードされ、コンテナが実行され、それにアクセスできるというチェーンが機能していることを意味します。

削除テストを実行する — 本当のレッスン

今度は、誰もやりたくない、誰もがやるべきステップです。 1 つの使い捨てファイルまたは設定をテスト アプリに配置し、コンテナーを停止して完全に削除します。 File Station で docker 共有フォルダーを開きます。マッピングしたデータはまだそこにあります。これは、コンテナー内にまったく存在しなかったためです。同じボリューム マッピングを使用してコンテナを再作成すると、同じ設定が再度表示されます。

アプリは使い捨てでした。データはそうではありませんでした。代わりにデータが消えた場合は、可能な限り安価な価格で最も価値のあるコンテナーの教訓を学んだことになります。つまり、アプリはコンテナー独自の一時レイヤーにデータを保存しており、実際のものを信頼するにはボリューム マッピングが必要です。

実際のアプリ以前の正直な制限