黒い群れの果てには白い群れがある
群晖のような家庭用 NAS は 24 時間稼働しているため、バックグラウンドタスクの実行に適しています。例えば、API による価格監視、定期的なデータ処理、通知などです。
以前、群晖のスケジュールタスクやメール、Telegram 通知を試してみましたが、いくつかの問題に直面しました。最終的には次のような効果を実現しました:
群晖のスケジュールタスク#
群晖のスケジュールタスクは、限られたタイプのみをサポートしています。特に「ユーザー定義スクリプト」タスクは制約が多く、群晖のカスタム Linux に関連しています:
- 「ユーザー定義スクリプト」タスクでは、シェルが直接解釈する非対話型スクリプトを入力する必要があります。su を直接実行することはできず、Docker に入ることもできません。ファイルの操作や操作を行うための権限がありません。
- 群晖の Linux バックエンドは、ユーザーに CLI ツールを提供することを考えていませんでした。例えば、証明書が存在しないため、TSL や HTTPS の通信を行うことができません(非常に手間のかかる方法で解決できますが)。そのため、群晖の Linux 内で直接 API を呼び出してスクリプトを実行することは非常に困難です。
- スケジュールタスクは、異常終了時にのみメール通知を送信します。メール通知の内容は、リダイレクトされていない tty の出力です。したがって、スケジュールタスクをトリガーとしてメール通知を送信するには、送信する内容を cat してから
exit -1
する必要があります。
前述のように、群晖の Linux でコマンドを直接実行することは制約が多いため、Docker 内での実装に切り替えました。
Docker パート 1#
公式の Ubuntu Docker イメージを直接取得しましたが、この Docker イメージは非常にシンプルで、CLI ツールが何もありませんでした。以前は SSH を備えた Docker イメージを直接取得することを多くの人がお勧めしていましたが、そのイメージは Ubuntu 14 であり、プライベートにカスタマイズされていましたので、使用したくありませんでした。
- まず、パッケージをインストールするために、国内のミラーソースに切り替える必要がありました。しかし、vim や nano などのツールが存在しなかったため、それらをインストールするためには再びミラーソースを切り替える必要がありました。Ubuntu は本当に典型的です。私は単純に echo で設定しました。
- SSH をインストールし、設定し、Python をインストールし、...
- フォルダをマッピングして、Docker 内のスクリプトの出力ファイルを直接群晖の Linux で読み取れるようにします。
- 最後に、作成したスクリプトを実行してみると、さらに典型的な問題が発生しました。使用したい API に直接アクセスできないため、ウェブ上で科学的な方法が必要です...
Docker パート 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(または「名前を明かしたくない」リモートのどれか)上で、公開インターフェースを公開せずに完全な機能を備えた Telegram ボットを実装することができます。公開 IP アドレスのリソースがない人にとって非常に便利です。
群晖のバックエンドの裸の Linux は非常に使いにくく、多くのツールが見つからないか使用できないため、その改変と特殊な CPU アーキテクチャのおかげです。
P.S. 公開 IP アドレスのリソースがある場合は、なぜ手間をかけるのですか?ダッシュボードでデータを定期的に更新するだけで十分です。