サーバー構成「インストールスクリプト」のベストプラクティスは何ですか? [閉鎖]

サーバー構成「インストールスクリプト」のベストプラクティスは何ですか? [閉鎖]

さまざまな「標準」パッケージ(Apache、PHP、MariaDB、複数のプログラミング言語)と複数のWebアプリケーション(Moodleを含む)で構成され、コンポーネントのgitリポジトリからインストールされるWebアプリケーションを実行するようにサーバーを設定する必要があります。 (パッケージのバージョンが古すぎるか存在しないため)。

現在、私たちはこの目的のためにDebianを使用していますが、他の内部サーバーをよりよく収容するためにデフォルトパッケージが利用可能になるように十分に更新された場合は、将来の時点でScientific Linuxに切り替えることができます。

多くのシステムと同様に、最初のバージョンは(最小のOSインストール後)パッケージをインストールし、gitリポジトリなどからダウンロードするための迅速で汚れたシェルスクリプトで始まり、何もしようとするプロジェクト時間がありませんでした。ソリューションをインストールします。

時間が経つにつれて、2番目の反復は徐々にこの基盤に基づいて構築され、現在必要なすべてのコンポーネントをダウンロードし、WebおよびDBサーバーを構成し、Moodleを設定するなどのタスクを実行する1100行(!)インタラクティブシェルスクリプトに進化しました。

私はこのスクリプトがかなり強力でハッキング的ではないと思いますが、このプロセスを実行する理想的な方法ではないと確信しています。私が考えたことの1つは、読み込み/編集/更新をより簡単にするために、スクリプトを各機能(少なくとも機能はあります)ごとに別々のファイルに分割し、それをオールインワン設定ファイルにリンクすることです。

それとも私はモンスターを作り、そのようなソフトウェアのインストールと設定を管理するより良い方法が必要ですか?

私が考慮した他の可能性は次のとおりです。

私のソフトウェアインストールプロセスを一種のDebianパッケージに変換できますか? dpkg-reconfigure(またはこれと似ていますか?)を使用して管理者に必要な設定を照会することは可能ですが、残念ながら私はそれについての経験はありません。これは、いくつかの必須の「パッケージ」をDebianパッケージの依存関係として追加するのではなく、gitリポジトリからダウンロードする必要があるためです。

この特定のタスクのためにシェルスクリプトに頼るのではなく、他の既存のソフトウェア管理またはスクリプトシステムを考慮する必要がありますか?

ベストアンサー1

おすすめ記事