この記事では、このようなスクリプトを作成するために使用する手法について説明します。これらの手法は、スクリプトを単純かつ柔軟に保つために、いくつかの熊手を避けるのに役立ちます。 このアプローチは、作成者のニーズ、更新などに応じて動作が変わるスクリプトに適しています。 このアプローチは、自律的に（著者のシステムと通信せずに）動作するスクリプトには適していません。
私はこのアプローチをbashスクリプトで使用していますが、一般的な原則は言語に関係なく適用できます。
短い先史時代（スキップ）：
数年前、私はクライアントが大量に使用するVDSサーバーテンプレートを作成し始めました。 テンプレートを作成した後、それを変更しても機能しなくなります。 エラーを修正する唯一の方法は、時間とギガバイトのスペースを要する新しいテンプレートを公開することです（テンプレート+すべてのサーバー上のテンプレートのコピー）。 過去数年にわたって、いくつかの不快な間違いを犯す可能性がありました。その結果、何年もの間、最初は不快な動作をするテンプレートを維持する必要がありました。
同様の状況は、コントロールパネル、サイトエンジン、単一のコマンドでダウンロード、インストール、構成する必要があるプログラムのみをインストール/構成するためのスクリプトでも発生する可能性があります。 プログラム自体は更新可能であり、それをダウンロードした人はすべて、インストールスクリプトを修正するためのアクセス権をすでに持っていません。
私が使用しているものの一部は、同様のスクリプト、たとえばispsystem、brew installersで見られました。 一部の同僚は提案し、一部の同僚は自分の苦い経験を得た。
一般的なポイント
毎回、サーバーからすべてのコードをダウンロードして実行します。
一般的なコード構造
公開されたスクリプト-最初の実行可能コードファイルのみをダウンロードし、他は何もしません。
最初の実行可能コードファイル-必要なことをすぐに実行し（単純な場合）、共通するものを特定して新しいファイルをアップロードします
残りのファイルは便利な方法で編成されています。これは、作業の過程ですでに変更できます。
公開すべきスクリプトとすべきでないスクリプト
どのような場合でも、公開されたスクリプトは、公開されたタスクを実行するべきではなく、その解決策のヒントさえ持たないはずです。 このスクリプトの唯一のタスクは、開発者のサーバーに接続し、そこから実行するコードをダウンロードする方法を見つけることです。 このコードは、外部の依存関係を最小限に抑えて、できるだけシンプルにする必要があります。 それらは、スクリプトの存続期間を通してサポートされる必要があります。
ここに私が結果として来たコードがあります
function try() { # , - , ... , } # Execute init.sh from panel function execute_init() { local EVAL_CODE=`curl http://panel.1gb.ru/minimal/init.sh` if [ "${EVAL_CODE#\#\!/bin/bash}" != "$EVAL_CODE" ] && [ "${EVAL_CODE%\#BashScriptEnd}" != "$EVAL_CODE" ]; then eval "$EVAL_CODE" return 0 else return 1 fi } try 100000 execute_init
私はこのコードを以前に既知の環境のテンプレートに入れました。特に、そこにカールがあり、多くの試みが必要であることは確かです。 サーバーの起動時に、ネットワークが機能しなかったり、httpサーバーが一時的にエラーを出したりする場合があります。 他のスクリプトは異なる環境で動作し、curlが存在しない場合があります。 これは、必要に応じて何度もサーバーに接続するのに適した場所です。
実行用のコードが完全にロードされていることを確認する必要があります-ifで長い行が正確にチェックします：スクリプトが＃！/ Bin / bashで始まり#BashScriptEndで終わることをチェックします。 したがって、rm -rf / tmp / my-downloadsをrm -rf /にトリミングすることにより、HTMLエラーコードまたはハーフスクリプトが実行されないことを確認できます。
私はこの場所でより複雑なチェックを意図的に行いませんでした-この場合のTCPはデータ破損に対する許容可能な保護を提供し、外部インターフェイスの複雑さは永久に維持されなければなりません。
このスクリプトには、1つの外部依存関係（URL）のみがあります。 将来的には、コードの編成が改善されたため、それを変更する必要がありましたが、依存関係は非常に単純であるため、保守が容易です。 さらに、新しいスクリプトもこの特定のパスを使用します。これは、新しい「正しい」パスではなく、歴史的に開発されたものです。 将来の変更の場合、2つのURLをサポートする必要があるなどの理由で
スクリプトは、環境を決定して、たとえばinit.shの代わりにinit_linux.shまたはinit_freebsd.shをロードする試みを行うべきではありません-そのような試みもあり、不便であることが判明し、今では古いバージョンのスクリプトのスタブをサポートする必要があります。
ダウンロード可能なスクリプトに入れるもの
ここでは、すでに公開されている部分に触れることなく、自由をさらに変更できます。 したがって、すべてが単純な場合は、ここで実行されるコードをすぐに配置できます。 何かが複雑になった場合、将来変更するのは簡単です。
実行可能コードの複雑さが複数のファイルである場合、ここに配置することをお勧めします。
1.新しいファイルをアップロードする機能。 サーバーへの接続方法を正確に再定義し、すべてのスクリプトで使用する必要があります。 次のように、共有ライブラリには適していません まだロードされていません。
2.この関数を1回/数回呼び出して、必要なすべてのファイルを接続して実行します：共通のコードライブラリ、見つかった環境の特定のコードなど。 引数に渡されたコマンドを確認し、このコマンドを実行するコードをロードします。
何を探す
- 実行する前に、ダウンロードしたコードを常に確認してください。 それ以外の場合は、ハーフスクリプトまたは何らかのエラーを実行できます。
- 公開されたスクリプトでは、最小限（理想的には1つ）の外部依存関係は、メインコードの読み込み元のアドレスです。 いつも同じ
- 各ファイルをダウンロードするために、常にいくつかの試行を行います。 作業がローカルネットワーク上で行われている場合でも、エラーなどの何らかの問題を返すと、一時的なサーバーエラーが発生する場合があります。 または、一般的に、接続は受け入れられません。 ダウンロード可能なファイルが1つあり、コマンドが手動で実行される場合、大した問題にはなりません。 しかし、コマンドがオートメーションに組み込まれ、接続されたファイルが多数ある場合、エラーが発生する可能性は非常に現実的です。 本当のことは、ファイル全体をロードしていないことです。
- スクリプトを公開する前に、それを確認する必要があります-1つの文字で封印されているのは残念です。そのため、テンプレートの準備/確認、または最近スクリプトを与えた人とやり取りするために多くの作業をやり直す必要があります
短所とそれらの観点
- ネットワーク（またはインターネット）に接続する必要がある。 このアプローチを適用する文脈では、開発者のサーバー（システムが内部で使用されている場合は自分のサーバーも含む）から何かをダウンロードする必要があり、ネットワークが必要になります。 スクリプトは、ローカルネットワークが機能しない場合は構成できず、ネットワークから受信できない場合はアクセスパスワードを設定できません。 また、利用できない場合、スクリプトは開発者のサーバーからソフトウェア/サイトを展開できません
- 事前定義されたコードの実行 これがあなたのコードであれば、すべてが明確です。 他の人のコードである場合は、それが持つはずの信頼レベルで起動/実行されます。 これがクライアントアプリケーションのインストールである場合-クライアント環境で、開発者はソフトウェア内で何でもでき、コード全体をチェックする人はいません（誰かが-他のリソースからの自動展開を使用する可能性はほとんどありません-サーバーからのコードのみ）