はじめに
こんにちは、荻野です。
今回は様々なIaaS基盤上にPaaSプラットフォームを構築ができる、Pivotal Cloud Foundry (以下PCF) をAWSにインストールする手順を紹介したいと思います。
今回の記事ではPCFの1.9.4をインストールしています。また、Pivotalアカウントはトライアルアカウントを利用しています。PCFは商用ライセンスが必要な製品となりますのでお試しいただく場合にはライセンスにご注意ください。
What is PCF
OSSのPaaSプラットフォームのCloud FoundryをベースにPivotal社がカスタマイズしたエンタープライズ向けのCloud Foundryディストリビューションです。
Cloud Foundryは様々なIaaS基盤の上にPaaS環境を構築することが可能なため、AWS、GCP、Azureと環境を問わずにPaaS環境を構築することが可能です。一般的なPaaSと同様に開発者はアプリケーションの開発に専念することができるようになります。
開発者はアプリケーションを書き上げたらcf pushとコマンドを叩くだけで、アプリケーションを実行するコンテナが立ち上がり、コンテナへのルーティングが設定され、アプリケーションへのアクセスが可能になります。
また、コンテナのスケーリングも非常に簡単に行えますし、ルーティングパスとスケーリングを操作することによって高度なBlue/Greenデプロイも簡単に実現することができます。
Pivotal Cloud FoundryはOSS版のCloud Foundryをベースとし、更に様々な機能・機構が拡張されています。
例えばCFの核とも言えるVMのライフサイクルを管理するソフトウェア BOSHを簡単に利用するためのGUIであるOps Managerが用意されていたり、MySQLやRabbit MQなどを簡単にアプリケーションから利用できるPivotal Servicesが追加されています。
事前準備
構築にあたり以下を準備しました。
- AWS IAMアカウント
administrator権限をもつIAMアカウントを用意しました。
ドメイン
PCFはアプリケーション用ドメインやシステム管理用ドメインなどにいくつかドメインを必要とします。
そのため、サブドメイン以下を自由に扱えるドメインを用意しておくとベストです。
今回は検証ドメインとしてcloud.hangout.yokohamaを用意しました。Pivotal Network アカウント
https://network.pivotal.io/ でアカウントを作成しておきます。アカウントの作成は無料です。cf CLIコマンド
https://github.com/cloudfoundry/cli#downloads を参考に cf コマンドをインストールしておきます。すでにインストール済みの場合は最新版にアップデートしておくとベストです。AWS CLIコマンド
https://aws.amazon.com/jp/cli/ を参考に aws コマンドをインストールしておきます。すでにインストール済みの場合は最新版にアップデートしておくとベストです。- AWS緩和申請
AWSの必要条件 を満たせるように緩和申請をおこないました。
Installing PCF 1.9.4 on AWS
それではPCFをインストールしていきましょう。本家のドキュメントはこちらになります。
まずは今回の記事の中で目指すゴールの共有ですが、AWSのざっくりとした構成図はこちらです。
S3バケットの数やELBの数など正確に表していません、他にもInternet GatewayやSecurity Groupなども作成されますがこの図では省略しています。
なお、この先はステップが多いので
- インストール先の環境作成
- OpsManagerのインストールと設定
- ElasticRunTimeのインストールと設定
に分けて紹介したいと思います。
1. インストール先の環境作成
Step 1: KeyPair作成
まずは今回利用するKeyPairを作成しましょう。コマンドはこちら。
$ aws ec2 create-key-pair --key-name hangout-pcf > keypair.json $ cat keypair.json | jq -r .KeyMaterial > hangout-pcf.pem
もちろんコンソールから作成しても問題ないです。
Step 2: SSL証明書の作成 or アップロード
SSL証明書をAWSにアップロードします。
利用する証明書はオレオレ証明書でもOKなのですが、今回はAWS Certificate Manager(以下ACM)を利用してみます。
この時点で私はAWSにロックインされ始めましたが、CF自体はIaaS非依存ですよ。。。
なお、用意するSSL証明書はSAN拡張を使ったマルチドメイン証明書である必要があります。
ACMはSAN対応しているため問題ないですが、他の認証サービスで用意する場合は注意してください。
今回は以下のドメインで証明書を用意しました。
CommonName: *.cloud.hangout.yokohama SANs: *.system.cloud.hangout.yokohama *.login.system.cloud.hangout.yokohama *.uaa.system.cloud.hangout.yokohama *.apps.cloud.hangout.yokohama
コマンドはこちら。
aws acm request-certificate \ --domain-name \ *.cloud.hangout.yokohama \ --subject-alternative-names \ *.system.cloud.hangout.yokohama \ *.login.system.cloud.hangout.yokohama \ *.uaa.system.cloud.hangout.yokohama \ *.apps.cloud.hangout.yokohama
出力されるJSONは後ほど利用しますのでメモっておいてください。
上記を実行すると --domain-name と --subject-alternative-names で指定したドメインの以下のメールアドレス宛に認証メールが配信されます
- administrator@ - admin@ - hostmaster@ - webmaster@ - postmaster@
どのメールアドレスでも構いませんので、全ドメイン分のメールを確認してapproveしてください。全てのアドレスでapproveが済めばACMで証明書が利用可能になります。
また、現在の発行状況は以下のコマンドで確認できます。
aws acm describe-certificate --certificate-arn $arn | jq -r .Certificate.Status
ISSUEDであれば利用可能な状態です。
もし、外部の証明書を利用する場合は aws iam upload-server-certificate や aws acm import-certificate でAWSに証明書をアップロードしてください。
Step 3: Cloud Formation Templateのダウンロード
AWSユーザーにはおなじみのCloud Formationテンプレートが提供されています。
もちろん、全て手動で作成することもできるのですが今回はこのテンプレートを使います。
まずはPivotal Networkへサインインしてください。
サインイン後こちらからPCF Cloudformation for AWS Setupをダウンロードします。
後はこのファイルをCloud Formationで実行するだけなので簡単ですね!
ただし、デフォルトのテンプレートのままではVPCのCIDRは10.0.0.0/16で固定されています。
もし、ネットワーク要件によりCIDRをカスタマイズしたい場合は、テンプレートのパラメータのひとつ 08OpsManagerTemplate で指定されているテンプレートを変更する必要があります。
例えば、今回のテンプレートでは 08OpsManagerTemplate には https://s3.amazonaws.com/ops-man-references/pcf-cloudformation/1.7.0/3/ops-manager.json が設定されていました。
CIDRはこちらのテンプレートファイルに定義されていますので、例えばVPC CIDRを10.70.0.0/16にしたい場合は以下のように置換してしまいましょう。
※ CIDR Prefixも修正したい場合などはもう少し細かな置換が必要です
$ curl https://s3.amazonaws.com/ops-man-references/pcf-cloudformation/1.7.0/3/ops-manager.json | sed -e 's/10\.0\./10\.70\./g' > new-ops-manager.json
最後に編集したファイルを任意のS3にアップして公開状態にしておき、Cloud Formationの実行時に 08OpsManagerTemplate の値をこのテンプレートのURLへと変更すればOKです。
今回はVPC CIDRを10.70.0.0/16に変更して作成したいと思います。
Step 4: Cloud Formation Stackの作成
先ほどのテンプレートでCloudFormation Stackを作成します。
Create Stackをクリックします。
Upload template to Amazon S3を選択してNextをクリックします。
パラメータを入力します。以下は本家のドキュメントをほぼ踏襲しています。
今回入力したパラメータは以下の通りです。
Parameter | Value |
---|---|
01NATKeyPair | Step 1で作成したKeyPair |
02NATInstanceType | デフォルトのまま |
03OpsManagerIngress | デフォルトのまま |
04RdsDBName | デフォルトのまま |
05RdsUserName | admin |
06RdsPassword | adminpassword |
07SSLCertificateARN | Step 2で作成(or Upload)したSSL証明書のARN |
08OpsManagerTemplate | Step 3でカスタムテンプレートをS3にアップしていた場合のみ変更します パスは https://s3.amazonaws.com/S3バケット名/テンプレートのパス で構成されます |
09ElbPrefix | pcf |
10AllowHttpOnElb | true |
Options は特にいじりません。
I acknowledge that AWS CloudFormation might create IAM resources with custom name. にチェックを入れてCreateしましょう。
作成完了までしばらく待ちます。大体20分くらいで完了すると思います。
無事に完了した場合、pcf-stackのOutputsタブを確認してください。このページは今後何度も参照することになるので別タブで開いておくとベストです。
ここまでに作成されたリソースを確認してみましょう。
大体出来上がってきましたね。ですが、これだけしか作られてないの?もしかしてEC2って手で作るの?と思われる方もいるかもしれません。そんな方は安心してください、この後手で作成するEC2はOps Managerひとつだけです。
なお、Cloud Formationにより同時にRDSも作成されますが今回は使いません。節約の為にも削除してしまいましょう。ResourcesタブでAWS::RDS::DBInstance と表示されているRDSです。
2. Ops Managerのインストールと設定
Ops Managerのインストールと設定をおこないます。
Step 1: Ops ManagerインスタンスAMI IDの取得
Ops ManagerはAMIが提供されているためそちらを利用します。
こちらのページからPivotal Cloud Foundry Ops Manager for AWSをクリックしてPDFをダウンロードします。
このPDFファイルには各リージョンにおけるOps ManagerのAMI IDが記載されているので、利用リージョンに適したAMI IDをメモします。
Step 2: Ops Managerインスタンスの起動
インスタンスの作成をクリックします。
AMIはStep 1で取得したAMI IDでヒットしたものを使いましょう。
インスタンスタイプはドキュメントに従いm3.largeを選択しましょう
ネットワークはCloudFormationのOutputsタブからPcfVpcの値を設定、サブネットは同じくOutputsタブからPcfPublicSubnetIdを設定します。パブリックIPは有効化しておきます。
ルートボリュームのサイズは100GBにしておきます。
NameタグにOps Managerを設定します。
セキュリティグループはCloudFormationのOutputsタグからPcfOpsManagerSecurityGroupIdの値を設定します。
レビュー結果に問題がなければ作成しましょう。
キーペアはインストール先の環境作成セクションのStep 1:で作成したものを指定します。
インスタンスがrunningになれば作成完了です。
Step 3: DNSレコードの登録
Ops Managerにはセキュリティ機構として初回にアクセスされた時のホスト名を記録する機能があります。
再起動後などに異なるホスト名でOps Managerにアクセスをした場合、この機構に引っかかってしまうことがあるためAレコードを作成しておくと良いです。
例えばhogehoge.om.hangout.yokohamaのAレコードにOps ManagerのグローバルIPを登録し、以降はhogehoge.om.hangout.yokohamaでOps Managerにアクセスをします。
$ dig hogehoge.om.hangout.yokohama +noall +answer ; <<>> DiG 9.8.3-P1 <<> hogehoge.om.hangout.yokohama +noall +answer ;; global options: +cmd hogehoge.om.hangout.yokohama. 300 IN A xxx.xxx.xxx.xxx
Step 4: Ops Managerへのログイン
ブラウザを起動してStep 3: で作成したAレコードにアクセスします。
するとまずはOps Managerへのログイン情報を設定する画面が表示されると思います。
今回はOps Manager内部の認証機構を利用するため、Internal Authenticationを選択しました。
UsernameとPasswordは今後Ops Managerにログインするために必要な情報になります。Decryption passphrase は暗号化のためのパスフレーズです。これらは絶対に忘れないようにしましょう。
Setup Authentication.をクリックしてしばらくするとログイン画面に遷移しますので、先ほど設定したUsernameとPasswordでログインします。
ログイン直後の画面です、まださっぱりとしていますが今後サービスをインポートすることで次第に賑やかになっていきます。
オレンジ色になっているAWSのアイコン(タイル)をセットアップしてデプロイをすることでOps Manager Director EC2が作成されることになります。
Step 5: AWS タイル
AWSタイルをクリックします。
Step 6: AWS Configページ
AWS Configページの情報を埋めていきます。
ここにAWSの情報を埋め込むことでOps ManagerはAWSのAPIを通じてリソースの操作が可能になります。
- Use AWS Keysを選択します
- Access Key ID: CloudFormatinのOutputsタブからPcfIamUserAccessKeyの値を設定します
- AWS Secret Key: CloudFormatinのOutputsタブからPcfIamUserSecretAccessKeyの値を設定します
- VPC ID: CloudFormatinのOutputsタブからPcfVpcの値を設定します
- Security Group ID: DescriptionがPCF VMs Security Groupのセキュリティグループのgroup idを設定します
- Key Pair Name: インストール先の環境作成セクションのStep 1: で作成したKeyPair名を指定します
- SSH Private Key: インストール先の環境作成セクションのStep 1: で作成したKeyPairをテキストエディタなどで開き、その値をコピーペーストします
- Region: Ops Managerを起動したリージョンを指定します
- Encrypt EBS Volume: EBS暗号化が必要な場合はチェックします
全ての入力が完了後Saveします。
Step 7: Director Configページ
Director Configページの情報を埋めていきます。
- NTP Servers: 0.amazon.pool.ntp.org,1.amazon.pool.ntp.org,2.amazon.pool.ntp.org,3.amazon.pool.ntp.org
- Enable VM Resurrector Plugin: VM復旧のプラグインが有効化されますのでチェックを入れます
- Blobstore Location: S3 Compatible Blobstoreをチェック
- S3 Endpoint: こちら を参考にエンドポイントを設定します。東京リージョンの場合はs3-ap-northeast-1.amazonaws.comです
- Name: CloudFormationのOutputsタブの PcfOpsManagerS3Bucketの値を設定します
- Access Key ID: CloudFormationのOutputsタブの PcfIamUserAccessKeyの値を設定します
- AWS Secret Key: CloudFormationのOutputsタブの PcfIamUserSecretAccessKeyの値を設定します
他はデフォルトのままSaveします。
Step 8: Create Availability Zonesページ
Create Availability Zonesページの情報を埋めていきます。
AWSのAZ情報をOps Manager側にマッピングしていきます。
- Add をクリック
- CloudFormationのOutputsタブのPcfPrivateSubnetAvailabilityZoneの値を入力します
- Add をクリック
- CloudFormationのOutputsタブのPcfPrivateSubnet2AvailabilityZoneの値を入力します
Saveをクリックします。
Step 9: Create Networksページ
Create Networksページの情報を埋めていきます。
AWSのネットワーク情報をOps Manager側にマッピングしていきます。
以下はマルチAZなネットワークを作成しています。
- Add Network
- Name: 今後ElasticRunTimeをデプロイするネットワークとするため"ert"と入力します
- Service Network: チェックしません
- Subnets1
- VPC Subnet ID: CloudFormationのOutputsタブの PcfPrivateSubnetId の値を入力します
- CIDR: Subnetごとに異なる値です。SubnetのCIDRを入力します(今回は10.70.16.0/20)
- Reserved IP Ranges: Subnetごとに異なる値です。AWSで予約済みのIPアドレスを入力します(今回は10.70.16.1-10.70.16.9 )
- DNS: VPCで固定の値です。今回は10.70.0.2
- Gateway: Subnetごとに異なる値です。今回は10.70.16.1
- Availability Zones: SubnetのZoneを指定します
- Subnet2
- VPC Subnet ID: CloudFormationのOutputsタブの PcfPrivateSubnet2Id の値を入力します
- CIDR: Subnetごとに異なる値です。SubnetのCIDRを入力します(今回は10.70.32.0/20)
- Reserved IP Ranges: Subnetごとに異なる値です。AWSで予約済みのIPアドレスを入力します(今回は10.70.32.1-10.70.32.9 )
- DNS: VPCで固定の値です。今回は10.70.0.2
- Gateway: Subnetごとに異なる値です。今回は10.70.32.1
- Availability Zones: SubnetのZoneを指定します
Saveをクリックします。
Step 10: Assign AZs and Networksページ
Assign AZs and Networksページの情報を埋めていきます。
- Singleton Availability Zone: Ops Manager Directorがインストールされる(EC2が起動する)AZです。どちらを選んでも構いません。
- Network: ertを選択
Saveをクリックします。
Step 11: Securityページ
Securityページはこのままで良いです。
Step 12: Resource Configページ
Resource Configページはこのままで良いです。
Step 13: Ops Director Deploy
Dashboardに戻ってみるとOps Manager Directorのタイルがグリーンになったことが確認できます。
ここで終わりではありません。タイルがグリーンになったあとはApply changesをクリックします。これで設定した情報に基づきデプロイが開始されます。
しばらく経つと完了します。正常に完了すればOpsManager Directorが作成されていると思います。
ここまでに作成されたリソースを確認してみましょう。
完成イメージに近づいてきました。あと一息です。
3. Elastic RunTimeのインストールと設定
Step 1: Elastic RunTimeタイルのインストール
PCFでは様々なサービスがタイルとして提供されています。Elastic RunTimeもタイルが提供されているのでまずはダウンロードします。
こちらにアクセスしてPivotal Cloud Foundry Elastic Runtimeをクリックします
PCF Elastic Runtime をダウンロードします。だいたい5GBくらいです。
ダウンロードが完了したらOps ManagerのDashboardのImport Productをクリックし、先ほどのファイルをアップロードしていきます。
アップロード中、しばらく時間がかかります。
アップロード後、+ボタンをクリックします。
タイルが追加されました!ただし、設定が未完了であることを表すオレンジ色のステータス表示です。以降はPivotal Elastic Runtimeタイルの設定を進めます。
Step 2: Pivotal Elastic Runtimeパネルの設定
追加されたタイルをクリックします。
Step 3: AZ and Network Assignmentsページ
AZ and Network Assignmentsページの情報を埋めていきます。
ジョブが実行されるAZとネットワークの設定になります。
- Place singleton jobs in
- ap-northeast-1a
- Balance other jobs in
- ap-northeast-1a
- ap-northeast-1c
- network
- ert
Saveをクリックします。
Step 4: Domainsページ
Domainsページの情報を埋めていきます。
- System Domain
- PCFがシステムレベルで使用するドメインです
- 今回はsystem.cloud.hangout.yokohamaにしました
- システムレベル、とは具体的にはcf CLIのエンドポイントやAppsManagerと言われるGUIのURLなどに利用されます
- Apps Domain
- アプリケーションがルーティングされるドメインです
- 今回はapps.cloud.hangout.yokohamaにしましたので、例えば以下のようにルーティングができます
- hoge.apps.cloud.hangout.yokohama
- hoge.apps.cloud.hangout.yokoham/fuga
- Apps Domainは後で追加することもできます
Saveをクリックします。
Step 5: Networkingページ
Networkingページの情報を埋めていきます。
このページはAWSを利用する場合は記入項目が少なめです。そのため、特別に設定すべき項目だけ列挙します。
Select one of the following point-of-entry options
今回はELB側でSSL暗号化を担当するのでForward unencrypted ...を選択します。
Loggregator Port
websocketを使ってのログデータのやり取りに関する設定です。AWSの場合は4443ポートを選択します。
これ以外はデフォルトのまま、Saveをクリックします。
Step 6: Application Containerページ
Application Containerページページの情報を埋めていきます。
アプリコンテナへのsshアクセスを許可するか、カスタムBuildpackを有効にするかなどを選択できます。
デフォルトのまま、Saveをクリックします。
Step 7: Application Developer Controlsページ
Application Developer Controlsページの情報を埋めていきます。
コンテナのメモリのデフォルト値などを変更できます。
デフォルトのまま、Saveをクリックします。
Step 8: Application Security Groupページ
Application Security Groupページの情報を埋めていきます。
アプリケーションのセキュリティグループは適切に設定をしましょう。メッセージを読んだら x をタイプします。
Saveをクリックします。
Step 9: Authentication and Enterprise SSOページ
Authentication and Enterprise SSOページの情報を埋めていきます。
認証に関する設定を行います。今回は内部認証機構を利用するためInternal UAAのままとしますが外部プロバイダも利用可能です。
デフォルトのまま、Saveをクリックします。
Step 10: Databases ページ
Databasesページの情報を埋めていきます。
Elastic RunTimeが使用するDatabaseに関する設定です。
今回は Internal Databases - MySQL を選択しましたが、External Databasesを選択すればもちろんRDSも利用可能です。
Saveをクリックします。
Step 11: Internal MySQLページ
Internal MySQLページの情報を埋めていきます。
このページはStep 10:で内部Databaseを選択した場合の設定ですが、E-mail addressのみExternalDBを選択した場合にも設定が必要です。
今回もE-mail addressのみ設定します。
また、バックアップ先にS3を利用することも可能です。
今回はE-mail addressの設定のみをおこないSaveをクリックします。
Step 12: File Storage
File Storageページの情報を埋めていきます。
Elastic RunTimeのコンポーネントであるCloud Controllerが利用するファイルストレージの設定になります。今回はS3を使います。
S3はすでにCloud Formationによって作成されています。
そのためCloudFormationのOutputsタブを見ながらこのページは情報を埋めていきましょう。このページの項目とCloudFormationのOutputsタブの相関図は以下の通りです。
項目 | CloudFormation Outputs タブの値 |
---|---|
Access Key ID | PcfIamUserAccessKey |
AWS Secret Key | PcfIamUserSecretAccessKey |
Buildpacks Bucket Name | PcfElasticRuntimeS3BuildpacksBucket |
Droplets Bucket Name | PcfElasticRuntimeS3DropletsBucket |
Packages Bucket Name | PcfElasticRuntimeS3PackagesBucket |
Resources Bucket Name | PcfElasticRuntimeS3ResourcesBucket |
URL | https://s3-ap-northeast-1.amazonaws.com (東京の場合) |
Saveをクリックします。
Step 13: System Logging
System Loggingページの情報を埋めていきます。
Systemロギングに関する設定です。外部のsyslogサーバにsyslogデータを転送することも可能です。
デフォルトのまま、Saveをクリックします。
Step 14: Custom Branding
Custom Brandingページの情報を埋めていきます。
Apps ManagerとCloud Foundryのログイン画面で表示される情報をカスタマイズできます。
Company Nameだけ変更してみました。Saveをクリックします。
Step 15: Apps Manager
Apps Managerページの情報を埋めていきます。
Apps Managerに関する設定をカスタマイズできます。
デフォルトのまま、Saveをクリックします。
Step 16: Email Notifications
Email Notificationsページの情報を埋めていきます。
メール送信に関するSMTPの設定を行います。メール送信する場合は設定が必要です。SESも利用可能です。
デフォルトのまま、Saveをクリックします。
Step 17: Restore CCDB Encryption Key
Restore CCDB Encryption Keyページの情報を埋めていきます。
ElasticRunTimeの再デプロイの際に指定が必要になるようです。
今回は初回インストールなのでデフォルトのまま、Saveをクリックします。
Step 18: Smoke Tests
Smoke Testsページの情報を埋めていきます。
Smoke Testの時に使うorgとspaceの設定です。
デフォルトのまま、Saveをクリックします。
Step 19: Advanced Features
Advanced Featuresページの情報を埋めていきます。
デフォルトのまま、Saveをクリックします。
Step 20: Errands
Errandsページの情報を埋めていきます。
今回は初回インストールなのでデフォルトのままにします。
デフォルトのまま、Saveをクリックします。
Step 21: Resource Config
Resource Configページの情報を埋めていきます。
EC2のスペックや台数などの調整を行います。そろそろチューニングしなければ、という時にはこの設定を変更します。
また、EC2とELBの紐付けもこのページで行います。
PCFでは、ELB -> Routing機能を持つEC2 -> アプリコンテナと通信がルーティングされていくためEC2とELBの紐付けはとても重要な設定になります。
今回は以下のEC2とELBの紐付けを行います。
Router : pcf-stack-pcf-elb
Diego Brain : pcf-stack-pcf-ssh-elb
TCP Router : pcf-stack-pcf-tcp-elb
Saveをクリックします。
Step 22: Stemcell
StemcellページはStemcellのアップデートが必要な場合に利用します。
今回はアップデートが必要ありませんでしたが、パッチがあたった場合などに更新することがあります。
Step 23: Apply changes
Dashboardに戻るとタイルがグリーンになったことが確認できると思います。
Apply changesをクリック。
実行中。
成功しました!もし失敗してしまった場合はログを確認してみましょう。
ここまでに作成されたリソースはこちら。
当初予定していたリソースが全て作成されました!
驚くことにEC2を作成したのはたったの1度だけです。あとはOps ManagerとOps Manager Directorの力でEC2が作成されていきました。ちなみに死活監視も行われており、EC2に異常が発生した場合は自動的に新しくEC2が立ち上がってきます。
cf push
簡単なSpring Bootアプリを作成してデプロイしてみます。
まずは先ほど作成したPCFにログインします、ようやくcf CLIの出番です。cf CLIの実行にはクレデンシャルが必要となるので以下の手順でゲットしましょう。
Pivotal Elastic Runtime パネルをクリックします。
Credentials タブをクリックします。
UAA Admin Credentials の Link to Credential をクリックするとID/PASSが取得できます。
それではPCFへログインします。
ログインは cf login コマンドです。APIのエンドポイントURLは api.SystemDomain になります。
今回SystemDomainは system.cloud.hangout.yokohama を設定したので、エンドポイントURLは api.system.cloud.hangout.yokohama となります。
$ cf login -a api.system.cloud.hangout.yokohama -o system -s system -u admin API エンドポイント: api.system.cloud.hangout.yokohama Password> 認証中です... OK 組織 system をターゲットにしました スペース system をターゲットにしました API エンドポイント: https://api.system.cloud.hangout.yokohama (API バージョン: 2.65.0) ユーザー: admin 組織: system スペース: system
次に org を作成します。cf create-org コマンドです。
$ cf create-org tagbangers admin として組織 tagbangers を作成しています... OK 役割 OrgManager を組織 tagbangers 内のユーザー admin に割り当てています ... OK
続いて space を作成します。cf create-space コマンドです。
$ cf create-space dev -o tagbangers admin としてスペース dev を組織 tagbangers 内に作成しています... OK admin として役割 RoleSpaceManager を組織 tagbangers / スペース dev 内のユーザー admin に割り当てています... OK admin として役割 RoleSpaceDeveloper を組織 tagbangers / スペース dev 内のユーザー admin に割り当てています... OK
デプロイするユーザーを作成します。cf create-user コマンドです。
$ cf create-user seiya password ユーザー seiya を作成しています... OK TIP: Assign roles with 'cf set-org-role' and 'cf set-space-role'.
デプロイ可能なロールを割り当てます。cf set-space-role コマンドです。
$ cf set-space-role seiya tagbangers dev SpaceDeveloper admin として役割 RoleSpaceDeveloper を組織 tagbangers / スペース dev 内のユーザー seiya に割り当てています... OK
作成したユーザーでログインします。
$ cf login -a api.system.cloud.hangout.yokohama -o tagbangers -s dev -u seiya API エンドポイント: api.system.cloud.hangout.yokohama Password> 認証中です... OK 組織 tagbangers をターゲットにしました スペース dev をターゲットにしました API エンドポイント: https://api.system.cloud.hangout.yokohama (API バージョン: 2.65.0) ユーザー: seiya 組織: tagbangers スペース: dev
次に Spring Bootアプリを作成します。今回は https://start.spring.io/ を使わせてもらいました。以下ではホームディレクトリを利用していますが、適当なディレクトリを利用してください。
$ cd ~ $ curl https://start.spring.io/starter.zip -d baseDir=demo -d style=web | tar -xzvf - $ cd demo
src/main/java/com/example/DemoApplication.java を編集します。
package com.example; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; @SpringBootApplication @RestController public class DemoApplication { @RequestMapping("/") String hello() { return "hello world"; } public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }
ビルドします。
# ~/demo で実行 $ ./mvnw package [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building demo 0.0.1-SNAPSHOT [INFO] ------------------------------------------------------------------------ . . . [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 21.857 s [INFO] Finished at: 2017-02-28T02:10:47+09:00 [INFO] Final Memory: 34M/308M [INFO] ------------------------------------------------------------------------
デプロイします。デプロイは cf push コマンドです。
# ~/demo で実行 $ cf push demo -p target/demo-0.0.1-SNAPSHOT.jar seiya として組織 tagbangers / スペース dev 内のアプリ demo を更新しています... OK demo をアップロードしています... 次のパスからアプリ・ファイルをアップロードしています: /var/folders/r3/bl8m7rmn7tb6fls3b97wj93r0000gn/T/unzipped-app297565075 12.2M、106 個のファイルをアップロードしています Done uploading OK . . . 要求された状態: started インスタンス: 1/1 使用: 1G x 1 インスタンス URL: demo.apps.cloud.hangout.yokohama 最終アップロード日時: Mon Feb 27 17:12:22 UTC 2017 スタック: cflinuxfs2 ビルドパック: java-buildpack=v3.10-offline-https://github.com/cloudfoundry/java-buildpack.git#193d6b7 java-main open-jdk-like-jre=1.8.0_111 open-jdk-like-memory-calculator=2.0.2_RELEASE spring-auto-reconfiguration=1.10.0_RELEASE 状態 開始日時 CPU メモリー ディスク 詳細 #0 実行 2017-02-28 02:13:05 AM 0.0% 1G の中の 334.5M 1G の中の 136.6M
無事に成功したのでアプリにアクセスしてみます。
$ curl demo.apps.cloud.hangout.yokohama hello world
hello world!!
おわりに
だいぶ長くなってしまいましたが、以上がPCF1.9をAWSへインストールする手順となります。
PCFには素晴らしい機能・機構がたくさんありますのでいずれ紹介できればと思います。
それでは、よいPCFライフをお送りください!
Special Thanks! @making