任意のクラウド サービスにコードを「ゼロ構成」(最小構成を意味する) にデプロイするためのオプションは何ですか?
何千ものクラウド プラットフォームがあり、それぞれが特定の言語セット、特定のパッケージ セットをサポートし、特定のワークフローを誇示しており、多くの場合、展開の手間を軽減するための独自のコマンドライン ツール セットを備えています。
しかし、特定のクラウド プラットフォームについて何も知りたくない場合や、今後何年にもわたってクラウドに簡単にデプロイできるコードを書きたい場合はどうすればよいでしょうか?
明らかに、最も具体的な答えは単純です: 必要なもので仮想マシン イメージを構築し、それをクラウド上で実行します (この方法はほぼゼロ構成であり、今日構築した VM イメージはほとんどの VM で引き続き動作することが期待できます)。ホストは 10 年後）。
私の質問は次のとおりです: VM イメージの理想から次の層は何ですか? 任意のソフトウェア スタックの完全な記述を機械可読形式でカプセル化するための、最もオープンで広く受け入れられている標準は何ですかサービス？
「クラウド」とは、PaaS ( Google App Engine、Heroku など) ではなく、EC2 などのIaaS (Infrastructure-as-a-Service プロバイダー)を意味する場合、最近の傾向はInfrastructure-as のようです。 -コード、およびDevOps。これは厳密には「ゼロ構成」ではありません。これは configure onceに似ており、スタック全体の構成を DSL で記述します。これを使用して、クラウド上で実行されている新しく起動された VM のセットだけからスタック全体を構築または再構築できます。
つまり、構成管理システムと、構成管理システムが理解する機械可読な「レシピ」の束があります。言語が実際に XML であるシステムは存在しますが、レシピはある種のカスタム DSL で表現されるのが普通です。
このような構成管理システムのよく知られた例には、次のものがあります。
他にもたくさんあります。しかし、私はそれらの経験がありません（CFEngine、bcfg2（XMLを使用））
これらのツールはべき等です。つまり、必要な回数だけ構成を再実行し続けることができ、レシピで指定された説明を満たすために実行する必要があることだけが実行されます。特定のファイルを特定の内容で特定のディレクトリに配置するように指定した場合、それらは必要な場合にのみ作成 (または変更) されます。パッケージは、必要な場合、またはバージョンがレシピの指定と異なる場合にのみインストールされます。
たとえば、Chef で、ユーザーtomcatが存在する必要があること、特定のバージョンの Java がインストールされている必要があること、postfix が実行されている必要があること、および特定の XML ファイルが特定の場所で利用可能でなければならないことを指定するには、次のようなレシピ:
user "tomcat"
package "java" do
version "1.6.0_u27"
end
directory "/etc/yourapp" do
owner "tomcat"
end
package "postfix"
# Ensure that postfix is installed and running.
service "postfix" do
action [:enable, :start]
end
tempate "/etc/yourapp/config.xml"
source "config.xml.erb" # This will be a template file that references variables
variables(
:db_server => '10.1.2.4' #just an example; there will be ways to automate this
)
mode "0755"
end
Chef の 1 つは、事前に作成されたレシピまたは「クックブック」を提供するもので、インフラストラクチャの一部としてダウンロードして組み込み、使用するだけです。Chef では、必要なサーバーに基づいてクックブックを作成します。次に、スタックを構成するサーバーのどのクラスにどのクックブックを適用するかを指定するロールを定義します。インスタンスにロールを割り当てて起動し、スタック全体が起動するのを確認するだけです。
これは、インフラストラクチャのフルスタック実行可能記述を維持する標準的な方法になりつつあると言えます (単なるクラウドである必要はありません。VMWare および/または VirtualBox でテストしますが、同じレシピで複数のパブリック クラウド ベンダーに展開します。 )
欠点は、DSL を学ぶ必要があることです。また、ワークフローに大幅な変更を加えることもできます。これらのシステムには、それぞれ長所と短所もあります。しかし、この方法で行うことは、カスタマイズされた VM イメージを維持することから確実に次の層になり、多くの点でより柔軟になります。たとえば、すべてのクラウド プロバイダーがインスタンスの同期を維持するために NTP サーバー アドレスを提供する場合、プロバイダーに応じてイメージを変更する必要があります。Chef/Puppet を使用すると、これを自動化してきれいに抽象化できます。
VM イメージは目的の「構成」の凍結されたコピーですが、各コンポーネント (スタック内の各インスタンス) が相互に対話する方法をキャプチャしません。たとえば、アプリケーション サーバーは、データベース サーバー、そのアドレス、さまざまな接続パラメーターについて知る必要があります。データベース サーバーは、接続する可能性のあるすべてのアプリケーション サーバーについて知る必要があります (クラウド コンテキストでは、アプリケーション サーバーは、時間の経過とともに数が増えたり減ったりします）。これは、Chef のようなシステムで自動化するのが非常に簡単な動的なものです。
あなたの質問に対する答えはJelasticだと思います。アプリケーションをクラウドにとどめ、他の人がそれを見ることができるようにするには、最低限 http プロトコルに準拠する必要があります。少なくとも、PHP が言語としてそこに手を差し伸べると思います。それが本当なら、現在市場で利用できるプラットフォームは Jelastic だけです。自分で試して、私に知らせてください。優れた Web コンソールでゼロ構成とベンダー ロックを無料で利用できます。これは単に最高です。私はエバンジェリストのように聞こえるかもしれませんが、私は彼らのスタックに満足している顧客であり (私はプログラミング言語として Java を使用し、スタートアップをしています)、彼らのプラットフォームを本当に愛しています。 .
スーリヤ
ワードアプリケーションの寿命に対する最も簡単な答えは抽象化だと思います。
アプリケーション要件を抽象的かつ簡単な用語で説明し、これをサポートするアプリケーションフレームワークを構築または使用し、アプリケーションのニーズに固有の部分を慎重に分離します。
Pythonでは、これはGoogleAppEngineで何かを構築することを意味する可能性があります。これを取り除くための中心的なアイデアは、アプリケーションに触れることなく、基盤となるインフラストラクチャを常に改善できるということです。これは、アプリケーションの動作を前提としない用語で説明しているためです。このアプローチでアプリケーションの内容と方法を抽象的かつ移植可能な方法で定義する場合のコストですが、これを正しく理解した場合に心配する必要があるのは、使用するコア言語の変更だけです。
この質問が見逃している大きな側面の1つは、変更が適切であるということです。アプリケーションスタック全体を廃棄することを恐れてはいけません。実際、テクノロジーは今日非常に急速に変化しているため、常に先を行き、関連性を保つ必要があります。この唯一の理由から、今後何年も同じ方法でアプリケーションを作成したいと思うことはほとんどありません。
ゼロ構成は、「サービスとしてのインフラストラクチャ」よりも「サービスとしてのプラットフォーム」に見られる特徴である可能性が高くなります。「ゼロ」ではなく「最小限の構成」と言うべきかもしれません。PAAS は、半固定のアーキテクチャを提供し、構成するためのいくつかのレバーを公開します。IAAS を使用すると、おそらくいくつかのツールを使用して、すべてを行うことができます。
コードをローカルで開発し、それを記述子ファイルでパッケージ化してから、App Engine にデプロイする Google App Engine での私の経験について話すことができます。基盤となるマシンや、トラフィックに応じてスケールアップまたはスケールダウンする方法などを気にする必要はありません。プラットフォームは、良い仕事をするか悪い仕事をするかにかかわらず、このようなことを処理します。アイデアは、アプリだけに集中することです。実際には、適切な設計上の決定を下すためには、基礎となるアーキテクチャを少し理解する必要があります。
AppEngine は、Java、Python、および Go をサポートしています。
Heroku と Engine Yard も PAAS であり、Ruby のサポートから始まりました。Heroku は現在、Java、Python、および Node.js もサポートしています。
また、Rackspace の Open Stack イニシアチブもあります。これは、さまざまな IAAS プロバイダーに「移植可能」でありながら、その中で生活できるアーキテクチャーを定義する方向に沿っています。素晴らしいコンセプトですが、多くの人が採用しているとは思いません。http://www.openstack.org/software/
すべてのクラウド プラットフォームは、「私は最善かつ普遍的なソリューションを持っている」というあなたの質問に答えることができますが、開発者が選択する標準だけが残ります。もちろん、独自の VM テンプレートを作成し、それを何年も使用できます。問題は、OS がサポートを失い、いつか減価償却されて安全でなくなることです。そのため、テンプレートだけでなく、アプリケーション インフラストラクチャ全体を更新する必要があります (定期的に更新していない場合)。したがって、VM は問題ありませんが、それは答えではないと思います... 一方、Jelastic デプロイ スクリプトや Azure Cloud Service デプロイ (手動または IDE 経由) などのクラウド プロバイダー ソリューションがあります。ただし、これらのソリューションは将来変更される可能性があり、スクリプトをリファクタリングせずに使用することはできません。3 番目の方法は、Chef、Puppet、docker またはその他の今日以降または将来開発されたものについてはわかりません。それらのほとんどは非常に強力で素晴らしいです。それらの多くは、Amazon または Azure 用の Chef プラグイン、Azure 上のオンデマンドの Puppet サーバー、Amazon または Azure 上の docker などとしてクラウド実装を備えています。問題は、今日はわからないことですが、将来的にはどれが標準になるかということです。これらはすべて非常に若いソリューションであり、（正直に言うと）あまり人気がなく、習得も容易ではありません。そして最後の 1 つ - 標準化され、開発者に愛され、管理者と開発者に愛されている - GIT と継続的な開発 / 継続的な統合。GIT は標準であり、ビジネスや教育でよく採用されているため、将来的にはそうなるでしょう。多くのパブリック クラウド プロバイダー (およびプライベート クラウド プロバイダー) は、git を使用してアプリケーションをクラウド プラットフォームに直接デプロイできるようにしています。Python コードに Azure PaaS ソリューションを使用しています。あとは、デプロイ スロットを作成してコードをプッシュするだけです。Azure Web App プラットフォームには継続的な統合メカニズムがあり、コミットしてから数秒後にコードがデプロイされます。このようなソリューションはいくつかのクラウドで見つけることができますが、どこでも見つけることはできません. これを行うには、多くのパブリック クラウドにあるような IaaS だけでなく、PaaS が必要です。