黒い群れの果てには白い群れがある
群晖のような家庭用 NAS は 24 時間稼働しているため、バックグラウンドタスクの実行に適しています。例えば、API を使用した価格監視、定期的なデータ処理、通知などです。
以前、群晖のスケジュールタスクやメール、Telegram 通知について試行錯誤しましたが、多くの問題に直面しました。最終的には、次のような効果を実現しました：
群晖のスケジュールタスク#
群晖のスケジュールタスクは、制限されたタイプのみをサポートしています。特に「ユーザー定義スクリプト」タスクは制約が多く、群晖のカスタム Linux に関連しています。
- 「ユーザー定義スクリプト」タスクでは、シェルが直接解釈する非対話型スクリプトを入力する必要があります。su を直接実行することはできず、Docker に入ることもできません。ファイルの操作や操作を行うための権限がありません。
- 群晖の Linux バックエンドには、ユーザーに直接 CLI ツールを提供することは考えられていません。例えば、証明書が存在しないため、TSL や HTTPS の通信を行うことができません（解決するための手順はありますが、非常に面倒です）。そのため、群晖の Linux 内で直接 API を呼び出したりスクリプトを実行したりすることは非常に困難です。
- スケジュールタスクは、異常終了時にのみメール通知を送信します。メール通知の内容は、リダイレクトされていない tty の出力です。したがって、スケジュールタスクをトリガーとしてメール通知を送信するには、送信する内容を cat してから
exit -1する必要があります。
前述のように、群晖の Linux でコマンドを直接実行することは制約が多いため、Docker 内で実現することにしました。
Docker pt. 1#
公式の Ubuntu Docker イメージを直接取得しましたが、この Docker イメージは非常にシンプルで、CLI ツールが何も含まれていませんでした。以前は SSH を備えた Docker イメージを直接取得することを多くの人が推奨していましたが、そのイメージは Ubuntu 14 であり、プライベートにカスタマイズされていましたので、使用したくありませんでした。
- まず、パッケージをインストールするためには、国内のミラーソースに変更する必要がありました。しかし、vim や nano などのエディタが存在しなかったため、それらをインストールするためには再びミラーソースを変更する必要がありました。Ubuntu の典型的な特徴です。私は直接 echo で設定しました。
- SSH をインストールし、設定し、Python をインストールしました。
- フォルダをマッピングして、Docker 内のスクリプトの出力ファイルを直接群晖の Linux で読み取れるようにしました。
- 最後に、作成したスクリプトを実行してみましたが、さらに問題が発生しました。使用したい API に直接アクセスすることはできず、科学的な手法が必要でした...
Docker pt. 2#
次に、cXXXh（手動で修正）イメージを取得し、7890ポートマッピングを追加しました。Docker をすべてブリッジに変更し、Ubuntu コンテナの HTTP/S プロキシを cXXXh コンテナのアドレス + 7890 に設定し、Ubuntu コンテナで API を呼び出しました。この手順により、NAS を透過的なルーターにすることができます。cXXXh コンテナは設定ファイルベースのプロセスであるため、GUI を使用して設定を調整および監視するために Web フロントエンドをインストールしました：
リソースの状況：
2GB のメモリでこれらのタスクを実行するのに十分な余裕があります。
スクリプトが実行できたら、cron を設定して定期的に実行することで、API の監視、データの定期的なクロール、データの処理を実現できます。その後、通知方法を考えることができます。
通知#
私が使用した通知のトリガーメカニズムは非常に基本的です。Ubuntu コンテナ内のスケジュールされたスクリプトが完了すると、結果が群晖の Linux にマウントされたディレクトリに出力されます。トリガー条件が満たされると、出力ファイルに特定の文字列が追加されます。群晖の DSM 設定に「ユーザー定義スクリプト」スケジュールタスクを追加し、実行時に出力ファイルをgrep -qして特定の文字列があるかどうかを確認し、あればexit -1してメールを送信します。
同時に、Telegram のボットも試してみました。Ubuntu コンテナ内から直接通知を送信できます。参考：
透過 Telegram Bot 發送 Synology 系統訊息
旁路由について#
正式なテストは行っていませんが、NAS 上の旁路由は uPnP を使用して透過的なプロキシを実現できます（ルーターに依存します）。手間をかけたくない場合は、プロキシサーバーのみを設定することもできます。パフォーマンスは、モバイルデバイスよりも強力であるはずです。タブレットやホストなど、家庭であまり移動しないデバイスには、一度設定しておけば問題ありません。
また、今回の操作は、以前に白群の第一歩として信じていたオールインワンでデータと計算を分離するという理念に反しています。本当に定期的なトランザクションや計算トランザクションは専用のマシンに任せるべきです（次は N5105 万兆を使いましょうか？）。群晖はできるだけポートを閉じて、正直に NAS を運用するべきです。ただし、看板を見る限り、群晖が 3 つの Docker を実行してスケジュールタスクを実行することは負担ではありませんでした：
タスクについて#
理論的には、群晖の Ubuntu Docker（または「名前を明かしたくない」リモートのどれか）上で、公開インターフェースを公開せずに完全機能のテレグラムボットを実装することができます。公開 IP リソースを持たない人にとっては非常に便利です。
群晖のバックエンドの裸の Linux は非常に使いにくく、多くのツールが見つからないか使用できないため、その魔改造と特殊な CPU アーキテクチャのおかげです。
P.S. 公開 IP リソースを持っている場合は、なぜ手間をかけるのですか？看板を定期的に更新するだけで済みます。