https://blogs.oracle.com/pshuff/entry/orchestration_vs_cloudformation
今日はOracle OrchestrationとAmazon CloudFormationを比較対照してみたいと思います。両者は同じ目的を持っており、インスタンスのプロビジョニング時に同じ操作をしますが、主要な違いは、操作方法とインスタンス作成時に必要な要素の定義方法です。数日前にWordPressインスタンスのプロビジョニングに必要な3個のファイルを見てきました。Oracle Orchestrationの情報は以下のドキュメントやチュートリアルにあります。
Oracle® Cloud Using Oracle Compute Cloud Service (IaaS)Amazon CloudFormation に関する情報は以下のホームページやチュートリアルにあります。
Starting an Orchestration
https://docs.oracle.com/cloud/latest/stcomputecs/STCSG/GUID-3E6D0DE6-1A94-4C56-8153-1803D8DC0640.htm#STCSG-GUID-3E6D0DE6-1A94-4C56-8153-1803D8DC0640
Creating Oracle Compute Cloud Service Oracle Linux Instances Using an Orchestration
http://www.oracle.com/webfolder/technetwork/tutorials/obe/cloud/compute-iaas/creating_instances_using_an_orchestration/creating_instances_using_an_orchestration.html
AWS CloudFormationそれでは、WordPressのサンプルでサービスのプロビジョニングに使われるJSONファイルを見ていきましょう。
https://aws.amazon.com/jp/cloudformation/
AWS CloudFormation - Sample Solutions (US West (Oregon) Region]
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-applications-us-west-2.html
AWS CloudFormation - Sample Solutions[Asia Pacific (Tokyo) Region]
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/sample-templates-applications-ap-northeast-1.html
WordPressのサンプル（US Oregon）JSONファイルにとって重要なコンポーネントは以下のものです。
https://s3-us-west-2.amazonaws.com/cloudformation-templates-us-west-2/WordPress_Single_Instance.template
WordPressのサンプル（APAC Tokyo）
https://s3-ap-northeast-1.amazonaws.com/cloudformation-templates-ap-northeast-1/WordPress_Single_Instance.template
{"AWSTemplateFormatVersion": "2010-09-09",
"Description": " ... ",
"Parameters": { ... },
"Mappings": { ... },
"Resources": { ... },
"Outputs": { ... }
}
以下のファイルを使って、S3でシンプルなストレージを作成することができます。
{
"Resources": {
"HelloBucket": {
"Type": "AWS::S3::Bucket"
}
}
}
注意いただきたいのは、本当に必要なのは、リソースの定義だけである、ということです。リソースは”HelloBucket”というラベルを持ち、リソースは"AWS::S3::Bucket"と定義された要素から構成されています。なお、TypeはAWS固有のもので、この汎用的な定義の取得および別のプラットフォームへの移植はできません。S3は通常無限とも言えるストレージサイズを持っているため、どれぐらいのサイズをストレージに割り当てるべきかはわかりません。これは、数日前に見てきたストレージ作成とは根本的に異なります。その時は、storage_pool、ディスクサイズ、起動可能かどうか、どのイメージから起動するか、どのアカウントに関連付けられているか、といったインスタンスのプロパティを定義しなければなりませんでした。CloudFormationインタフェースは、ユーザインターフェイスに埋め込まれたアカウント情報を持つ、Webベースまたはコマンドラインベースのインタフェースから実行されるため、アカウント情報を前提としています。少々複雑なインスタンスを定義することもできます。このインスタンスでは、コンテンツやOSを事前定義したAMIを参照します。また、セキュリティ・ポートを定義し、このインスタンスの接続キーを定義内で定めています。
{
"Resources": {
"Ec2Instance": {
"Type": "AWS::EC2::Instance",
"Properties": {
"SecurityGroups": [
{
"Ref": "InstanceSecurityGroup"
},
"MyExistingSecurityGroup"
],
"KeyName": "mykey",
"ImageId": "ami-7a11e213"
}
},
"InstanceSecurityGroup": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Enable SSH access via port 22",
"SecurityGroupIngress": [
{
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
}
]
}
}
}
}
この例では、ami-7a11e213を使ってEC2インスタンスをプロビジョニングしようとしています。MyExistingSecurityGroupっとラベル済みのセキュリティ資格証明を使い、SSHアクセスのために22/tcpを開けます。AMIの特性を調べなければOSのバージョンが何なのかはわかりません。これはstorage要素とどのOSから起動するかを定義するOracle Orchestrationとは異なります。Amazon CloudFormationもOracle Orchestrationも、どちらもセキュリティグループを定義しますが、少々定義が異なります。とはいえ同じ効果を有します。また、アプリケーションに特徴のいくつかを定義することができます。 CloudFormationの場合、次のパラメータを使用してWordPressを構成することができます。
"Parameters": {
"KeyName": {
"Description": "Name of an existing EC2 KeyPair to enable SSH access into the WordPress web server",
"Type": "AWS::EC2::KeyPair::KeyName"
},
"WordPressUser": {
"Default": "admin",
"NoEcho": "true",
"Description": "The WordPress database admin account user name",
"Type": "String",
"MinLength": "1",
"MaxLength": "16",
"AllowedPattern": "[a-zA-Z][a-zA-Z0-9]*"
},
"WebServerPort": {
"Default": "8888",
"Description": "TCP/IP port for the WordPress web server",
"Type": "Number",
"MinValue": "1",
"MaxValue": "65535"
}
},
アプリケーションに基づいて、これらのパラメータを定義し、起動時にオペレーティングシステムにパラメータが渡されることに注意してください。Oracle Orchestrationの場合、構成にパラメータを追加する際には異なる方法をとります。各アプリケーション用に定義したパラメータを持つのではなく、このようなカスタマイズは、起動時に実行されるPost Install Scriptを使って実施します。これらの設定は、スナップショットもしくは、システムの初期化方式に基づいた、Post Install Scriptを使って行うことができます。この機能は、Enterprise Managerを使って開始します。オンプレミスシステムで使用しているスクリプトをクラウドに変更やアップデートをせずに移植することができます。まとめると、Amazon CloudFormation とOracle Orchestration は非常に似ています。システムを定義するために利用するコンポーネントは類似のことをします。AmazonはAWSで実行していることを前提としているため、事前定義済みのコンポーネントを手早く簡単に作成することができます。 残念ながら、この構成は別のクラウドプロバイダーやオンプレミスのソリューションに変換しません。Oracle Orchestrationの場合はより基本的なものですが、全てをスクラッチから作成し、システム定義のための基盤上に構築できるよう設計されています。CloudFormationにはGUIがあり、コンポーネントをデザイン・パレットにドラッグ＆ドロップすると、JSONファイルを生成することができます。Oracleはちょっと異なるアプローチを取っており、Oracle Marketplaceを使って自動的にJSONファイルを生成します。コンポーネントをドラッグ＆ドロップできるGUIの設計ツールはありませんが、貴社のデータセンターの構成を使い、Orchestration用のJSONファイルを生成するために使われるパラメータリストを生成するツールがあります。このエントリでどちらが優れているかとは言いませんが、主として、このツールとユーティリティでは対象となるオーディエンスや機能が違うことを指摘しています。残念ながら一方の構成を取ると、他方の構成に簡単にマッピングすることはできません。うまくいけば、いつか誰かがこれらのファイルを取得して変換ツールを作ることでしょう。
0 件のコメント:
コメントを投稿