サービスの作成時に発生する問題の1つ（この場合、クラウドでもVDSでもかまいません）は、クライアントマシンの作成方法です。



競合他社のほとんどは、システム管理者が一度インストールして構成したイメージのクローンを作成します。 各マシンのゼロからクリーンインストールを使用します。





以下に、この決定の原因、両方のアプローチの長所と短所を説明します。

それがすべて始まった方法...

クラウドが最初の機能を獲得したばかりのとき、仮想マシンの作成を自動化するタスクが発生しました。 もちろん、表面にある最初の解決策は、クローンを作成することでした。 幸いなことに、すべてのビジネスには1つのチームがあります（xe vm-clone）。 次に、ネットワーク設定、ホスト名、およびルートパスワードを調整する必要がありました。 すべての作業-半日。 さて、ノミを捕まえながら2日間。



やった？ 彼らはそれをやった。 幸いなことに、ベータ版のテスターでさえこのバージョンを見ていませんでした。





ディスククローン作成のすべてのマイナス要因を分析した後、「インストール」というアイデアに思いつきました。 このプロセスは、控えめに言っても厄介で、約1か月半かかりました。その間、各Linuxディストリビューションの詳細を非常に深く研究する必要がありました。



その結果、既存のテンプレートシステムにより、作成したマシンの設定を非常に簡単に変更でき、プロセス全体が神秘的で非常に重要な神秘的な「マスターコピー」に結び付けられることはありません。



「クリーンインストール」とは何ですか？ これは、空のディスクを持つ仮想マシンが作成され、特別なカーネルが特別なinitrdで起動され、その中にインストーラー（netinst）がある場合です。 このインストーラーは、質問への回答を含むファイルを受け取ります（各ディストリビューションには独自のものがあります）。



実際、すでにインストールされているOSのディスクのクローン作成と完全インストールの違いは何ですか（もちろん、これはプロセスに関するものではなく、結果に関するものです）？

1. 一意のsshキー。 はい、各sshサーバーには秘密鍵があります。秘密鍵は各サーバーで一意でなければなりません。 このキー（debian / ubuntu内）はインストール時に生成されます（初回ではありません）。 また、2つのクライアント仮想マシンに同じ秘密鍵がある場合、1つのクライアントのサーバーが別のクライアントのサーバーになりすますことができるため、これは巨大なセキュリティホールになります。 Apacheを使用したSSL証明書とその秘密鍵、およびopensslを使用する他のサービスにもまったく同じことが当てはまります。
2. SQLサーバーをdebian / ubuntuにインストールすると、dpkgがデータベースを更新できるように、ランダムに生成されたパスワードを使用してデータベースに特別なアカウントが作成されます。 このアカウントのパスワードは、仮想マシン間で一意である必要があります。 同じ場合は、「クラウドネイバー」がSQLの管理パスワードを知っていることを意味します。 いいですか そうでもない。
3. 作成日ファイル。 クローンを作成すると、イメージが作成された日付は、クラウド管理者が作成した瞬間を指していることがわかります。 また、ファイルの一部（管理者が更新をロールする場合）の日付はまったく異なります。 致命的？ いや 不快ですか？ はい
4. ログファイルには追加の情報が含まれます。許可ログの無関係なログイン、インストールログには通常、未知の起源年のナンセンスがいっぱいです。
5. すべての可能なタイプのuuid（ファイルシステムUUIDを含む）がディスク間で繰り返されます。これにより、UUIDの「一意」という言葉は無意味になります。

もちろん、これはすべて変更および修正できます。 あなたがそれについて知っていれば。 そして、あなたが知らない場合は？ 誰かがサブシステムの1つ（udev、device-mapper、他のどこかで、別の一意の識別子を忘れてしまったという事実により、数千の仮想マシンに穴が残っているという事実を認識してください。その後、考えるのを忘れていた）？ これらのエラーを回避するには、すべての分布を徹底的に調査する必要があります。 みなさん。 そして、Debian、Susi、centos、Ubuntu（UbuntuはDebianのフォークですが、かなりの数の違いが蓄積されていますが）; そして、別のディストリビューションが追加された場合はどうなりますか？



クローン作成中の責任のレベルは非常に大きくなっています。 そして、利益に不釣り合いです。



しかし、実際には、クローニングの代わりに施設を使用する真の動機は、方法のイデオロギー的純粋さでした。 おそらくこれは誰かにとって奇妙に思えるかもしれませんが、私は多くの点で「機能させる」だけでなく、アーキテクチャに固有のイデオロギーに従うことを望んでいます。 ディストリビューションの作成者が彼らのディストリビューションがインストールされると仮定する場合、それがインストールされていれば正しいです。



ただし、クリーンインストールにはユーザーにとっても小さな利点があります。



たとえば、CentOSユーザーは/ rootで、マシンがインストールされた設定を含むanaconda-ks.cfgファイル、およびインストールログを含むinstall.logおよびinstall.log.syslogを見つけます。 これらのファイルは、それらが置かれているマシンに特に関連しており、一度配信された任意のマシンには関連しません。 同様に、Debian / Ubuntuユーザーは/ var / log / installディレクトリにログを見つけます。 私はすでにファイルの正しい日付について上に書いた。



ディスクのクローン作成と比較して、「フルインストール」に欠点がないという事実については嘘をつきません。 彼らです。 しかし、それらはすべてインストールの瞬間にのみ関係し、マシンのさらなる寿命には影響しません。



それらをリストします。

1. 特に小さなシステムドライブでは、クローニングよりもインストールが遅い
2. インストールはより気まぐれです-キャッシングプロキシが少なくとも1回「クリック」すると、インストールが「スティック」し、場合によっては致命的です（インストールがフリーズします）。
3. インストールを変更することははるかに困難です;これらの変更をデバッグするには、インストール手順を起動するたびに必要です。

ご覧のとおり、これらの欠点はいずれもインストール完了後のマシンの寿命には影響しません。すべての問題はインストール自体を苦しめるか、計画と展開の問題です。 したがって、いったん問題を克服すると、ディストリビューションの作成者の意図に合った最もクリーンなシステムが得られます。



ただし、競合他社を必死に冒とくしたくありません。 クローン作成のオプションは非常に実行可能であり、デューデリジェンスにより、マシンは「新しくインストールされた」マシンと非常によく似たものになります。 おそらく、私にとっての唯一の質問は「どれくらい似ているか」です...

どのように機能しますか？

データベースにはテンプレートオブジェクトのクラスがあります（SCAPIについてはまだ説明していません）。 テンプレートには、マシンを作成するための一連のパラメーターが格納されます-メモリ、ディスクの最小/最大サイズの制限。 テキストの説明、アイコンへのリンク-要するに、マシンの作成時にユーザーに表示されるすべて（左の例）。 さらに、最も重要なものはそこに保存されます：テキストautoinstall_script。 各テンプレートには独自のスクリプトがありますが、管理スクリプトを使用する実際的な目的のために、同じOSの32ビットバージョンと64ビットバージョンの1つのファイルから生成されます。 これは、一連の変数置換で行われます。なぜなら、 32ビットバージョンと64ビットバージョンの実際のテキストは非常に異なります（パッケージ名だけでなく）。



そのため、ユーザーが「インストール」ボタンをクリックすると、スクリプトはSkapiにマシンを「作成」する一連のコマンド（vm-create、vif-create、vdi-create、vbd-createなど）を渡します。 その後、メインコマンド-vm-installが起動されます。 このコマンドは、インストールに必要なパラメーター（ホスト名など）を受け入れ、マシンテンプレートと一致するスクリプトをデータベースから取得し（vm-create時にテンプレートが渡されます）、インストールプロセスを開始します。 上で書いたように、「インストールプロセス」とは、文字通り、特別なカーネル、特別なinitrd、およびPV-argsを介して準仮想化カーネルに渡される一連のパラメーターを意味します。



initrdの内部では、各システムに独自のインストーラーがあり、独自の形式が必要です。 仮想マシンがインストール用の/ initrdカーネルで起動するとすぐに、その設定は「動作中」に変更され、カーネルはディストリビューションでは通常、ブートではinitrdになります。 （ところで、ロードに使用するカーネルは同じテンプレートを保存します）。



主流のディストリビューションには、preseed、kickstart、およびautoyastの3つのインストール方法があります。



PreseedはUbuntuでも使用されているdebianの成果です。 パッケージがdebメカニズムを通じて尋ねることができる質問への回答が含まれています。 残念ながら、これらの質問に対する答えは常にドキュメントに記載されているわけではありません-deb / udebファイルの内部を見なければならない場合があります（udebはインストーラーフラグメントが格納される小さなdebです） 私は言わなければなりません、debianとubuntuは非常に近いですが、それらの答えのセットは、それらを異なるOSとして認識するのに十分なほど異なります。



preseedの主な利点は、質問の回答をファイルの形式とカーネル引数の形式の両方で転送できることです。これにより、マシンに共通のパラメーターを静的ファイルに転送でき、マシンに固有のすべて（名前、パスワード、IPアドレス） ）PV-argsを介して転送します。 ちなみに、Ubuntu preseedはdebian（テキストモードで同じ赤青）からインストーラーを処理するので、（デスクトップユーザーがインストール時に見る）美しい人はいません。



キックスタート-Red Hatの発明は、他のRHEL機能とともに、CentOSに完全に移植されました。 一連の機能はpreseedよりもわずかに劣っています。そのため、外部のマシンによるロードからの保護を備えた動的なキックスタート生成システム全体を発明する必要がありました（誰かが初期パスワードをダウンロードすると非常に不快になりますか？）。 CentOSのもう1つのおかしな点は、そのnetinstallイメージがXenをサポートしていないことであり、Xenを開始する前にパッチを適用する（kudzuを置き換える）必要があります。



AutoyastはYastの拡張機能であり、Suse構成システム（およびOpenSuse）であり、一方で（多くはより正確にYastコンセプトのフレームワーク内で）それを行うことができます。他方では、同じ方法で通常のPV引数をサポートしません。 さらに、autoyastはvyviglazom XMLで記述されているため、autoyast.xmlのサイズはキックスタートの約5倍であり、あまり有用でない情報が含まれています。



CentOSのインストールの詳細については、個別に言う必要があります。 不変への過度のコミットメントのため、インストール直後のCentOSは、centosと同じくらい古いものです。 つまり、yum updateは、新たにインストールされたシステムで80MB以上の更新を提供します。 ユーザーに古いシステムを残さないために、yumの更新をキックスタートの％投稿セクションに含める必要がありました。