Tagbangers Blog

PCF1.9をAWSにインストールしてみる

はじめに

こんにちは、荻野です。

今回は様々な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が追加されています。

事前準備

構築にあたり以下を準備しました。

  1. AWS IAMアカウント

    administrator権限をもつIAMアカウントを用意しました。

  2. ドメイン
    PCFはアプリケーション用ドメインやシステム管理用ドメインなどにいくつかドメインを必要とします。
    そのため、サブドメイン以下を自由に扱えるドメインを用意しておくとベストです。
    今回は検証ドメインとしてcloud.hangout.yokohamaを用意しました。

  3. Pivotal Network アカウント
    https://network.pivotal.io/ でアカウントを作成しておきます。アカウントの作成は無料です。

  4. cf CLIコマンド
    https://github.com/cloudfoundry/cli#downloads を参考に cf コマンドをインストールしておきます。すでにインストール済みの場合は最新版にアップデートしておくとベストです。

  5. AWS CLIコマンド
    https://aws.amazon.com/jp/cli/ を参考に aws コマンドをインストールしておきます。すでにインストール済みの場合は最新版にアップデートしておくとベストです。

  6. AWS緩和申請
    AWSの必要条件 を満たせるように緩和申請をおこないました。

Installing PCF 1.9.4 on AWS

それではPCFをインストールしていきましょう。本家のドキュメントはこちらになります。

まずは今回の記事の中で目指すゴールの共有ですが、AWSのざっくりとした構成図はこちらです。

S3バケットの数やELBの数など正確に表していません、他にもInternet GatewayやSecurity Groupなども作成されますがこの図では省略しています。

なお、この先はステップが多いので

  1. インストール先の環境作成
  2. OpsManagerのインストールと設定
  3. 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