アプリ マニフェストを使用すると、デベロッパーはアプリ実行環境を宣言方式で記録できます。また、一貫性、再現性のある方法でアプリをデプロイできます。
形式
マニフェストとは、アプリのルート ディレクトリにある YAML ファイルを指し、manifest.yml
や manifest.yaml
という名前にする必要があります。
Kf アプリのマニフェストでは、最上位要素 applications
は 1 つ記述できます。applications
要素には、1 つ以上のアプリケーション フィールドを記述できます。
application フィールド
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 |
ヘルスチェックのタイプ。port 、process 、none 、http のいずれかを使用します。デフォルト: port |
health-check-http-endpoint |
string |
ヘルスチェックの一部として対象となるエンドポイント。health-check-type が http の場合にのみ有効です。 |
command |
string |
アプリを起動するコマンド。指定すると、コンテナのエントリポイントに渡されます。 |
entrypoint † |
string |
アプリコンテナのエントリポイントをオーバーライドします。 |
args † |
string[] |
アプリコンテナの引数をオーバーライドします。 |
ports † |
object |
コンテナで公開するポートのリスト。指定すると、このリストの最初のポートがデフォルト ポートとして使用されます。 |
† Kf に固有
docker フィールド
application.docker
オブジェクトには、次のフィールドが使用できます。
フィールド | タイプ | 説明 |
---|---|---|
image |
string |
使用する Docker イメージ。 |
route フィールド
application.routes
オブジェクトには、次のフィールドが使用できます。
フィールド | タイプ | 説明 |
---|---|---|
route |
string |
ホスト名、ドメイン、パスを含むアプリへのルート。 |
appPort |
int |
(省略可)ルートがトラフィックを送信するアプリのカスタムポート。 |
port フィールド
application.ports
オブジェクトには、次のフィールドが使用できます。
フィールド | タイプ | 説明 |
---|---|---|
port |
int |
アプリのコンテナで公開するポート。 |
protocol |
string |
公開するポートのプロトコル。tcp 、http 、または 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 種類のヘルスチェックをサポートしています。
port
(デフォルト)http
process
(またはnone
)
port
と http
では、トラフィックを送信する前にアプリケーションの準備ができていることを確認する Kubernetes の readiness プローブと liveness プローブが設定されます。
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 コンテナの自動検出ポートはサポートされていません。