バージョン 2.2

アプリ マニフェスト

アプリ マニフェストを使用すると、デベロッパーはアプリ実行環境を宣言方式で記録できます。また、一貫性、再現性のある方法でアプリをデプロイできます。

形式

マニフェストとは、アプリのルート ディレクトリにある YAML ファイルを指し、manifest.ymlmanifest.yamlという名前にする必要があります

Kf アプリのマニフェストでは、最上位要素 applications は 1 つ記述できます。applications 要素には、1 つ以上のアプリケーション フィールドを記述できます。

アプリケーション フィールド

applications の下のオブジェクトには、次のフィールドが使用できます。

フィールド 説明
name string アプリケーションの名前。アプリ名は、小文字のアルファベット、数字、ダッシュで構成される必要があります。名前をダッシュで始めることはできません。
path string アプリのソースへのパス。デフォルトではマニフェストのディレクトリです。
buildpacks string[] アプリに適用する Buildpack のリスト。
stack string Buildpack で作成されたアプリで使用するベースイメージ。
docker object Docker オブジェクト。詳細については、Docker フィールドのセクションをご覧ください。
env map アプリとビルドの環境変数として使用する Key-Value ペア。
services string[] アプリに自動的にバインドされるサービス インスタンス名のリスト。
disk_quota quantity アプリケーションが取得するディスクの量。デフォルトは 1 GiB です。
memory quantity アプリを提供するための RAM の量。デフォルトは、1 GiB です。
cpu quantity アプリケーションを提供するための CPU の量。デフォルトは 0.1(1 CPU の 10 分の 1)です。
instances int 実行するアプリのインスタンス数。デフォルトは 1 です。
routes object アプリがリッスンするルートのリスト。詳細については、ルート フィールドのセクションをご覧ください。
no-route boolean true に設定すると、アプリケーションはルーティングできません。
random-route boolean true に設定すると、アプリにはランダムなルートが与えられます。
timeout int アプリが正常になるまで待機する秒数。
health-check-type string ヘルスチェックのタイプ。portprocessnonehttp のいずれかを使用します。デフォルト: port
health-check-http-endpoint string ヘルスチェックの一部として対象となるエンドポイント。health-check-typehttp の場合にのみ有効です。
command string アプリを起動するコマンド。指定すると、コンテナのエントリポイントに渡されます。
entrypoint string アプリコンテナのエントリポイントをオーバーライドします。
args string[] アプリコンテナの引数をオーバーライドします。
ports object コンテナで公開するポートのリスト。指定すると、このリストの最初のポートがデフォルト ポートとして使用されます。

† Kf に固有

Docker フィールド

application.docker オブジェクトには、次のフィールドが使用できます。

フィールド 説明
image string 使用する Docker イメージ。

ルート フィールド

application.routes オブジェクトには、次のフィールドが使用できます。

フィールド 説明
route string ホスト名、ドメイン、パスを含むアプリへのルート。
appPort int (省略可)ルートがトラフィックを送信するアプリのカスタムポート。

ポート フィールド

application.ports オブジェクトには、次のフィールドが使用できます。

フィールド 説明
port int アプリのコンテナで公開するポート。
protocol string 公開するポートのプロトコル。tcphttp、または http2 にする必要があります。デフォルト: tcp

最小アプリ

これは、アップロードされたソースに基づいてビルドパックを自動検出してアプリをビルドし、その 1 つのインスタンスをデプロイする最小のマニフェストです。

---
applications:
- name: my-minimal-application

シンプルなアプリ

従来の Java アプリの完全なマニフェストを次に示します。

---
applications:
- name: account-manager
  # only upload src/ on push
  path: src
  # use the Java buildpack
  buildpacks:
  - java
  env:
    # manually configure the buildpack's Java version
    BP_JAVA_VERSION: 8
    ENVIRONMENT: PRODUCTION
  # use less disk and memory than default
  disk_quota: 512M
  memory: 512M
  # bump up the CPU
  cpu: 0.2
  instances: 3
  # make the app listen on three routes
  routes:
  - route: accounts.mycompany.com
  - route: accounts.datacenter.mycompany.internal
  - route: mycompany.com/accounts
  # set up a longer timeout and custom endpoint to validate
  # when the app comes up
  timeout: 300
  health-check-type: http
  health-check-http-endpoint: /healthz
  # attach two services by name
  services:
  - customer-database
  - web-cache

Docker アプリ

Kf は Docker コンテナとマニフェストをデプロイしたアプリをデプロイできます。これらの Docker アプリは PORT 環境変数をリッスンする必要があります。

---
applications:
- name: white-label-app
  # use a pre-built docker image (must listen on $PORT)
  docker:
    image: gcr.io/my-company/white-label-app:123
  env:
    # add additional environment variables
    ENVIRONMENT: PRODUCTION
  disk_quota: 1G
  memory: 1G
  cpu: 2
  instances: 1
  routes:
  - route: white-label-app.mycompany.com

複数のポートを有するアプリ

このアプリには、管理コンソール、ウェブサイト、SMTP サーバーを公開する複数のポートがあります。

---
applications:
- name: b2b-server
  ports:
  - port: 8080
    protocol: http
  - port: 9090
    protocol: http
  - port: 2525
    protocol: tcp
  routes:
  - route: b2b-admin.mycompany.com
    appPort: 9090
  - route: b2b.mycompany.com
    # gets the default (first) port

ヘルスチェックの種類

Kf では、次の 3 種類のヘルスチェックをサポートしています。

  1. port(デフォルト)
  2. http
  3. process(またはnone

porthttp では、トラフィックを送信する前にアプリケーションの準備ができていることを確認する Kubernetes の readinessProbe と livenessProbe が設定されます。

port ヘルスチェックは、$PORT にあるポートがリッスンされるようにします。Kf 内部では、TCP Probe が使用されます。

http ヘルスチェックは、health-check-http-endpoint の構成値を使用して、アプリケーションの状態を確認します。Kf 内部では、HTTP Probe が使用されます。

process ヘルスチェックは、コンテナで実行されているプロセスが稼働中かどうかだけをチェックします。Kubernetes の readinessProbe や livenessProbe は設定されません。

既知の相違点

Kf のマニフェストと CF のマニフェストの違いは次のとおりです。

  • Kf では、非推奨の CF マニフェスト フィールドはサポートされていません。これには、マニフェストのルートレベルのすべてのフィールド(アプリケーション以外)とルーティング フィールドが含まれます。
  • Kf は、次の v2 マニフェスト フィールドをサポートしていません。
    • docker.username
  • Kf では、Docker コンテナの自動検出ポートはサポートされていません。