1. Azure Kubernetes服务环境でMicroProfile配置动作検证
アプリケーションは，外部システムとの连携のための接続情报（DBや，外部のHTTPエンドポイント），开発环境，テスト环境，本番环境などの环境设定の差を，プログラム・ソースコードから切ドから离し，外部の 设定ファイル等に书き出すことで容易に接続先や设定を切り替えることができます。
外部，外部の设定ファイルなどに书き出しておくことで，接続先を切り替えるためにアプリケーションションのソースドー编の编集やビルドは不要で，同一のソースコーラ行ライブラリを利用できます。
クラウド・ネィティブなアプリケーションを構築していくために、设定情報の外だしはとても重要です。
「参照：The Twelve Factors のIII. 設定 : 设定を环境変数に格纳する」
Twelve-Factorは 設定をコードから厳密に分離すること を要求する。MicroProfile配置を利用すると，设置情报を下记のようなさまざまな场所から取得できます。
设定の设定场所をConfigSourcesと呼び，同じプロパティが复数のConfigSourceで定义されている场合，ポリシーを适用しどの値が有效かを指定します。
- Java VMのシステム・プロパティから
- OSの环境変数
- 外部构成ファイル（.properties，.xml）から
- LDAP，DB，键值ストアなどの外部データそ＝す
そして変状况によっては，一部のデータソースを动的に切り替えたい场合があります。そして変更した値は，アプリケーションショ再起动することなく，プログラム上ム更新した内容を利用する必要があります。こうしたニーズに Micro，MicroProfile Configでは，构成した値を変更直后から利用できるようになっています。
MicroProfile Config の実装について
Microprofile Config は API のみを規定しており実装は含まれていません。
MicroProfile Config の実装は、各 MicroProfile の実装プロバイダから個別に提供されています。
- Apache Geronimo Config
- WebSphere Liberty 2017 March-June Beta so far
- Payara Server 173 and Payara Micro 173
- WildFly & Thorntail
- microBean™ MicroProfile Config
MicroProfile Config の概要
MicroProfile Configは数少ないAPIから构成されています。
MicroProfile Config API 1.4の一覧
- Config
- ConfigBuilder
- ConfigProperty
- ConfigProvider
- ConfigProviderResolver
- ConfigSource
- ConfigSourceProvider
- Converter
ConfigSource の優先順位
Configこれら，登录されたorg.eclipse.microprofile.config.spi.ConfigSourceから收集された情报で构成されます。これらのConfigSourceは，顺序に従ってソートされます。されます，外部から重要度の低い设定を上书き できます。
デフォルトでは，3つのデフォルトConfigSourceがあります。
- System.getProperties（）（优先顺位= 400）
- System.getenv（）（优先顺位= 300）
- ClassPath上のMETA-INF / microprofile-config.propertiesファイル（デフォルト优先顺位= 100，各ファイル中にconfig_ordinalプロパティを设定して个别に优先顺位を设定可能）
デフォルト値は，アプリケーションのショッケージ时にファイル内で指定でき，値はデプロイメントごとに后から上书きできます。「优先顺位は値が大きいほど优先されます。」
設定情報の取得例
MicroProfile Config仕様では，设置値を読み取るために2种の方法を用意しています。
- プログラム的な设定情报の取得
- アノテーションを利用した设定情报の取得
1. プログラム的な设定情报の取得
プログラム的ムConfigインスタンスを取得し设定情报を取得するサンプルを下记に示します。
public class MyAppWithGetConfigFromProgram {
public Response invokeMicroserviceWithConfig() {
// Config インスタンスの取得
Config config = ConfigProvider.getConfig();
// マイクロサービス A の URL を取得
String microserviceA = config.getValue("URL_OF_MICROSERVICE_A", String.class);
// マイクロサービス A の呼び出し
return invokeMicroservice(microserviceA);
}
}
設定情報を取得するためには、最初に Config インスタンスを取得しなければなりません。
プログラム的に Config インスタンスを取得するためには、ConfigProvider#getConfig() を呼び出して取得できます。
（Config クラスのインスタンスは、生成されたのちコンテキストクラスローダーに登録されます。）
2. アノテーションを利用した设定情报の取得（推奨）
アノテーションを利用しConfigインスタンスを取得し，@ ConfigPropertyで设定情报を取得するサンプルを下记に示します。
@ApplicationScoped
public class MyAppWithGetConfigFromAnnotation {
@Inject
private Config config;
//The property myprj.some.url must exist in one of the configsources, otherwise a
//DeploymentException will be thrown.
@Inject
@ConfigProperty(name="myprj.some.url")
private String someUrl;
//The following code injects an Optional value of myprj.some.port property.
//Contrary to natively injecting the configured value, this will not lead to a
//DeploymentException if the value is missing.
@Inject
@ConfigProperty(name="myprj.some.port")
private Optional somePort;
}
MicroProfile Config サンプル・アプリケーション
1. MicroProfile Configサンプル・プロジェクトの作成
MicroProfile Starter にアクセスし、MicroProfile のプロジェクトを作成します。
（下载）。MPConfigSample.zip。
.
├── pom.xml
├── readme.md
└── src
└── main
├── java
│ └── com
│ └── yoshio3
│ └── MPConfigSample
│ ├── HelloController.java
│ ├── MPConfigSampleRestApplication.java
│ └── config
│ └── ConfigTestController.java
├── resources
│ └── META-INF
│ └── microprofile-config.properties
└── webapp
├── WEB-INF
│ └── beans.xml
└── index.html
11 directories, 8 files
Micro，MicroProfile Config进入ConfigTestController.javaに下记のように记录されています。
package com.yoshio3.MPConfigSample.config;
import org.eclipse.microprofile.config.Config;
import org.eclipse.microprofile.config.ConfigProvider;
import org.eclipse.microprofile.config.inject.ConfigProperty;
import javax.enterprise.context.RequestScoped;
import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
@Path("/config")
@RequestScoped
public class ConfigTestController {
@Inject
@ConfigProperty(name = "injected.value")
private String injectedValue;
@Path("/injected")
@GET
public String getInjectedConfigValue() {
return "Config value as Injected by CDI " + injectedValue;
}
@Path("/lookup")
@GET
public String getLookupConfigValue() {
Config config = ConfigProvider.getConfig();
String value = config.getValue("value", String.class);
return "Config value from ConfigProvider " + value;
}
}
上记のコードでは，プロパティに记された値をHTTPのレスポンスとして返す简単なコードです。
下记のようにHTTPのGETメソッドで呼び出すとreturn文で记载される文字列が返ってきます。
$ curl -X GET http://localhost:8080/data/config/injected
$ curl -X GET http://localhost:8080/data/config/lookup
実际の设定内容は，META_INFディレクトリ配下ののmicroprofile-config.propertiesファイルに记载されています。
# プロパティ・ファイルの場所
└── src
└── main
├── resources
│ └── META-INF
│ └── microprofile-config.properties
记フォルトで下记のプロパティが设定されています。
# プロパティ・ファイルに設定された値
injected.value=Injected value
value=lookup value
2. サンプル・プロジェクトのビルドと実行
MicroProfile Config进入动作确认を行うため，プロジェクトをビルドし，アプリケーションを起动します。
# プロジェクトのビルド
$ mvn clean package
# アプリケーションの実行
$ java -jar target/MPConfigSample-microbundle.jar
......
Payara Micro URLs:
http://192.168.100.7:8080/
'ROOT' REST Endpoints:
GET /data/application.wadl
GET /data/config/injected
GET /data/config/lookup
GET /data/hello
GET /openapi/
GET /openapi/application.wadl
]]
[2020-03-10T22:19:06.610+0900] [] [情報] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1583846346610] [levelValue: 800] Payara Micro 5.194 #badassmicrofish (build 327) ready in 32,755 (ms)
[2020-03-10T22:19:33.646+0900] [] [情報] [] [javax.enterprise.system.container.web.com.sun.web.security] [tid: _ThreadID=29 _ThreadName=http-thread-pool::http-listener(1)] [timeMillis: 1583846373646] [levelValue: 800] Context path from ServletContext: differs from path from bundle: /
上记のようにアプリケーションショ起动がのち，卷曲コマンドを実行し动作确认を行います。
正しく动作している场合，下记のようにプロパティ・ファイルから取得した设定（注入值，值）の文字列が表示されます。
# アノテーションで実装されたエンドポイントへの呼び出し
$ curl localhost:8080/data/config/injected
Config value as Injected by CDI Injected value
# プログラムで実装されたエンドポイントへの呼び出し
$ curl localhost:8080/data/config/lookup
Config value from ConfigProvider lookup value
MicroProfileではプロパティ・ファイルの设定値をシステム・シロパティで上书き设定することができます。そこで环境変数を设定し，环境変数の値をJavaのシステム・プロパティに代入して実行します。すると“ microprofile- config.properties“フ変イルに设定した値を上书きし，环境変数に设定した値が表示されている事を确认できます。
# 環境変数の設定 [.(ドット）を _(アンダーバー）に置き換えて設定]
$ export injected_value="Environment Value"
# 環境変数を Java のシステム・プロパティに設定してアプリを実行
$ java -D"$injected_value" -jar target/MPConfigSample-microbundle.jar
# アプリケーションの動作確認
$ curl http://localhost:8080/data/config/injected
Config value as Injected by CDI Environment Value
ご注意：属性ファイル中では。 （ドット）表记で记していますが，环境変数はOSによっては。（そこでット）表记が使えません。（そこでット）表记箇所を 実い。実装内部で自动的に変换をしています。
3. ローカルのDocker环境での実行
ローカルの环境でアプリケーションの动作确认ができたので，次にローカルのDocker环境でMicroProfileを动作させます。PayaraMicroのDockerコンテナのイメージを作成するため，下记のようなDockerfileを作成してください。
FROM payara/micro:5.201
USER payara
WORKDIR ${PAYARA_HOME}
# Deploy Artifact
COPY ./target/MPConfigSample.war $DEPLOY_DIR
CMD ["--nocluster","--deploymentDir", "/opt/payara/deployments", "--contextroot", "app"]
Dockerbuildコマンドを実行しコンテナのイメージを作成してください。
$ docker build -t tyoshio2002/payara-config-sample:1.0 .
# コマンド実行時のコンソール出力例
Sending build context to Docker daemon 151.2MB
Step 1/5 : FROM payara/micro:5.201
5.201: Pulling from payara/micro
050382585609: Already exists
59f5185426ac: Already exists
4d95208cd9c0: Pull complete
c1409397cf71: Pull complete
Digest: sha256:3ff92627d0d9b67454ee241cc7d5f2e485e46db81a886c87cf16035df7c80cc8
Status: Downloaded newer image for payara/micro:5.201
---> a11a548b0a25
Step 2/5 : USER payara
---> Running in cb755e484e79
Removing intermediate container cb755e484e79
---> 564283252ae4
Step 3/5 : WORKDIR ${PAYARA_HOME}
---> Running in f26dd5cd172c
Removing intermediate container f26dd5cd172c
---> f2bf88b18a77
Step 4/5 : COPY ./target/MPConfigSample.war $DEPLOY_DIR
---> 1b54373fe95a
Step 5/5 : CMD ["--nocluster","--deploymentDir", "/opt/payara/deployments", "--contextroot", "app"]
---> Running in 3eb731eb77c3
Removing intermediate container 3eb731eb77c3
---> 1d11549e99b8
Successfully built 1d11549e99b8
Successfully tagged tyoshio2002/payara-config-sample:1.0
记ンテナのイメージが作成できたのち，コンテナを起动します。下记のコマンドを実行してコンテナを起动してください。
$ docker run -p 8080:8080 -e injection_value =巨大 -it tyoshio2002/payara-config-sample:1.0
# コマンド実行時のコンソール出力例
..... (中略)
[2020-03-11T07:46:59.119+0000] [] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1583912819119] [levelValue: 800] [[
{
"Instance Configuration": {
"Host": "3877abb54d57",
"Http Port(s)": "8080",
"Https Port(s)": "",
"Instance Name": "payara-micro",
"Instance Group": "no-cluster",
"Deployed": [
{
"Name": "MPConfigSample",
"Type": "war",
"Context Root": "/app"
}
]
}
}]]
[2020-03-11T07:46:59.131+0000] [] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1583912819131] [levelValue: 800] [[
Payara Micro URLs:
http://3877abb54d57:8080/app
'MPConfigSample' REST Endpoints:
GET /app/data/application.wadl
GET /app/data/config/injected
GET /app/data/config/lookup
GET /app/data/hello
]]
[2020-03-11T07:46:59.131+0000] [] [INFO] [] [PayaraMicro] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1583912819131] [levelValue: 800] Payara Micro 5.201 #badassmicrofish (build 512) ready in 31,286 (ms)
作成したコンテナの起动が完了したので，コンテナ上で动作するアプリケーションに対して接に対して。
今回は，启动时にコンテナ内部の8080番ポートを，ローカルの8080番ポートにマッピングしていますので，ローカル环境の8080番ポートにアクセスすることで，コンテナのアプリケーションに接続でき続で。
下记のコマンドを実行してください。
$ curl http://localhost:8080/app/data/config/injected
Config value as Injected by CDI hogehoge
コンテナの起动时に引数として环境変数（-e injected_value=hogehoge）を与えているため，起动时に入力した文字列が表示されます。
4. Azure Kubernetes服务环境での実行
ローカルの Docker 環境で動作確認ができたので、Azure Kubernetes Service 環境で動作確認を行います。下記の手順に従い動作確認を行います。
- Azure Container Registry用のリソース・グループを作成
- Azure容器注册表を作成
- Azure容器注册表のパスワードの确认
- Azure容器注册表にログインしイメージを推送
- Azure容器注册表に推送したイメージの确认
- Azure Kubernetes Service用のリソース・グループを作成
- Azure Kubernetes Service用のサービス・プリンシパル作成
- AKSからACRのリソースを参照できるようにACRに参照権限を付与
- AKSの作成
- kubectl AンドのインストールとAKS接続情报の取得
- 展开YAMLの作成
- 部署YAMLの适用
- Podの动作确认
- 环境変数を设定し更新
- KubernetesのConfig Map设定の设定情报の取得
- Config Map値の更新とPodの再开始
4.1. Azure Container Registry用のリソース・グループを作成
まずは、Azure Container Registry を作成し、ローカルで作成した Docker コンテナのイメージをアップロードします。そこで、Azure容器注册表を作成するためのリソース・グループを作成します。
$ az group create --name WebApp-Containers --location "Japan East"
{
"id": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers",
"location": "japaneast",
"managedBy": null,
"name": "WebApp-Containers",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
4.2. Azure Container Registry を作成
次に，Azure Container Registryを作成します。
- --nameにコンテナ・レジストリ名を指定します
- --resource-groupに上记で作成したリソース・グループ名を指定します
- --skuは“基本”，“标准”，“高级”の何れかを指定します
- --admin-enabled trueに设定する事で，コンテナ・レジストリにdockerコマンドでアクセスできるようにします
$ az acr create --name containerreg4yoshio --resource-group WebApp-Containers --sku Basic --admin-enabled true
{
"adminUserEnabled": true,
"creationDate": "2020-03-12T02:27:59.357654+00:00",
"id": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers/providers/Microsoft.ContainerRegistry/registries/containerreg4yoshio",
"location": "japaneast",
"loginServer": "containerreg4yoshio.azurecr.io",
"name": "containerreg4yoshio",
"networkRuleSet": null,
"policies": {
"quarantinePolicy": {
"status": "disabled"
},
"retentionPolicy": {
"days": 7,
"lastUpdatedTime": "2020-03-12T02:28:01.654662+00:00",
"status": "disabled"
},
"trustPolicy": {
"status": "disabled",
"type": "Notary"
}
},
"provisioningState": "Succeeded",
"resourceGroup": "WebApp-Containers",
"sku": {
"name": "Basic",
"tier": "Basic"
},
"status": null,
"storageAccount": null,
"tags": {},
"type": "Microsoft.ContainerRegistry/registries"
}
4.3. Azure容器注册表のパスワードの确认
次に，Azure Container Registryに接続するためのパスワードを确认します。
- --nameにコンテナ・レジストリ名を指定します
- --resource-groupに上记で作成したリソース・グループ名を指定します
$ az acr credential show --name containerreg4yoshio --resource-group WebApp-Containers
{
"passwords": [
{
"name": "password",
"value": "4zaIiLk*************+H1XO4AlYFvN"
},
{
"name": "password2",
"value": "fT03XPs*************Oq2cAZiVHV+L"
}
],
"username": "containerreg4yoshio"
}
4.4. Azure容器注册表にログインしイメージを推送
次に，docker登录コマンドを実行しAzure Container Registryに接続します。
（パスワードは上记で取得したパスワードを入力してください。）
ローカルで作成したDockerコンテナのイメージ名に，コンテナ・レジストリの“ loginServer”名（例：“ containerreg4yoshio.azurecr.io”）を付け加えた 名前でタグ付けします。
最后に，docker pushコマンドを実行し，Azure Container RegistryにイメージをPushします。
# Azure Container Registry にログイン
$ docker login containerreg4yoshio.azurecr.io -u containerreg4yoshio
Password:
Login Succeeded
# Docker コンテナのタグ付け
$ docker tag tyoshio2002/payara-config-sample:1.0 containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample:1.0
# Azure Container Registry にタグ付けしたイメージを Push
$ docker push containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample:1.0
The push refers to repository [containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample]
bbd197848553: Pushed
ec40a5d738cc: Pushed
f95fe3528c56: Pushed
bded2364df91: Pushed
1bfeebd65323: Pushed
1.0: digest: sha256:689dbacc212d37afe09c43417bc79d8e241c3fa7b5cf71c27097ef535cf77f76 size: 1368
4.5. Azure容器注册表に推送したイメージの确认
Azure容器注册表に正しくイメージがPushされていることを确认します。
$ az acr repository list -n containerreg4yoshio -g WebApp-Containers
Argument 'resource_group_name' has been deprecated and will be removed in a future release.
[
"tyoshio2002/payara-config-sample"
]
$ az acr repository show-tags --name containerreg4yoshio --repository tyoshio2002/payara-config-sample
[
"1.0"
]
4.6. Azure Kubernetes Service用のリソース・グループを作成
次にAzure Kubernetes Service（AKS）を作成します。まず，AKSを作成するリソース・グループを作成します。
$ az group create --name MC_yoshio-aks --location "Japan East"
{
"id": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/MC_yoshio-aks",
"location": "japaneast",
"managedBy": null,
"name": "MC_yoshio-aks",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null,
"type": "Microsoft.Resources/resourceGroups"
}
$
4.7. Azure Kubernetes Service用のサービス・プリンシパル作成
KS AKSで利用するサービスプリンシパルを作成します。作成时には既定のロールはアサインしていません。
$ az ad sp create-for-rbac --skip-assignment
{
"appId": "884ac0da-****-****-****-c9e2d3fce495",
"displayName": "azure-cli-2020-03-13-03-12-59",
"name": "http://azure-cli-2020-03-13-03-12-59",
"password": "03a0e079-****-****-****-a760333af0b0",
"tenant": "72f988bf-****-****-****-2d7cd011db47"
}
4.8. AKSからACRのリソースを参照できるようにACRに参照権限を付与
Azureを利用する场合，Kubernetes内でコンテナ・レジストリへの接続情报を登录せず（通常はSecret内に接続情报を登录し利用），AzureのAzure Active Directory（Azure AD）のサーサスプリンシパルシパ利用を ，Azure Container Registry内に存在するコンテナのイメージを取得することができます。
参照：によるービスプリンシパルによるAzure Container Registry认证
まず，ACRに権限を付与するため，az acr showコマンドでACRのリソースIDを取得します。
次に，az角色分配创建コマンドでACRに対して，AKSで利用するサービスプリンシパル（上记で作成）に対してacrpullを许可します。
- --assigneeはappIdを指定（“ appId”：“ 884ac0da- *--***-c9e2d3fce495“，）
- --scopeは上记ACRのIDを指定
- --role acrpullロールを指定するとACRからイメージをプル可能（YAML内でセキュリティ设定不要）
$ az acr show --resource-group WebApp-Containers --name containerreg4yoshio --query "id" --output tsv
/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers/providers/Microsoft.ContainerRegistry/registries/containerreg4yoshio
$ az role assignment create --assignee 884ac0da-****-****-****-c9e2d3fce495 --scope /subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers/providers/Microsoft.ContainerRegistry/registries/containerreg4yoshio --role acrpull
{
"canDelegate": null,
"id": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers/providers/Microsoft.ContainerRegistry/registries/containerreg4yoshio/providers/Microsoft.Authorization/roleAssignments/72cbc68a-****-****-****-1a66c8568cba",
"name": "72cbc68a-****-****- ****-1a66c8568cba",
"principalId": "33472555-****-****-****-31e2064fb702",
"principalType": "ServicePrincipal",
"resourceGroup": "WebApp-Containers",
"roleDefinitionId": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/providers/Microsoft.Authorization/roleDefinitions/7f951dda-****-****-****-43fe172d538d",
"scope": "/subscriptions/f77aafe8-****-****-****-d0c37687ef70/resourceGroups/WebApp-Containers/providers/Microsoft.ContainerRegistry/registries/containerreg4yoshio",
"type": "Microsoft.Authorization/roleAssignments"
}
4.9. AKSの作成
最后に，AKSを作成します。
- --resource-groupは4.6で作成したリソース・グループ名を指定します
- --nameはAKSクラスターの名前を指定します
- --kubernetes-versionはAKSクラスターのKubernetesのバージョンを指定します
- --node-vm-sizeはVMサイズを指定します
- --node-countはKubernetesのワーカー・ノードの数を指定します
- --locationは东日本を指定します
- --service-principalは4.7のサービスプリンシパル作成时のappIdを指定します
- --client-secretは4.7のサービスプリンシパル作成时の密码を指定します
- --generate-ssh-keysは作成时にSSHキー（公共，私人）がユーザーディレクトリの.sshに作成されます
az aks create \
--resource-group MC_yoshio-aks \
--name yoshioAKSCluster1164 \
--kubernetes-version 1.16.4 \
--node-vm-size Standard_DS2_v2 \
--node-count 3 \
--location japaneast \
--service-principal "884ac0da-****-****-****-c9e2d3fce495" \
--client-secret "03a0e079-****-****-****-a760333af0b0" \
--generate-ssh-keys
注意：上记のAKSの作成时のコマンドは开発环境用，検证用として作成しています。AKSの本番环境を构筑するためには， a切ったり，アベイラビリティ・ゾーンとして构筑する必要があるため，本番环境构筑のためにはより多ためにはよりのオプション指定が必要になります。azaks创造コマンドの详细は下记をご参照ください。
参考：az aksコマンドの详细
4.10. kubectl AンドのインストールとAKS接続情报の取得
AKSを操作するためには，kubectlコマンドを利用します。初めてKubernetesを操作する场合，操作环境にkubectl ubンドがインストールされていないかもしれません。 cliコマンドを実行して入手します。
作成したAKSに接続するためには，AKSへの接続情报が必要になります。そこでAKSへの接続情报（クレデンシャル）をaz aks get-credentialsコマンドを実行して取得してください。
# kubectl コマンドのインストール
$ az aks install-cli
Downloading client to "/usr/local/bin/kubectl" from "https://storage.googleapis.com/kubernetes-release/release/v1.17.4/bin/darwin/amd64/kubectl"
Please ensure that /usr/local/bin is in your search PATH, so the `kubectl` command can be found.
$ which kubectl
/usr/local/bin/kubectl
# AKS の接続情報（クレデンシャル）の取得
$ az aks get-credentials --resource-group MC_yoshio-aks --name yoshioAKSCluster1164
Merged "yoshioAKSCluster1164" as current context in /Users/yoterada/.kube/config
# kubernetes のクライアントとサーバのバージョン確認
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T21:03:42Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.4", GitCommit:"224be7bdce5a9dd0c2fd0d46b83865648e2fe0ba", GitTreeState:"clean", BuildDate:"2019-12-13T20:40:52Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
4.11. 展开YAMLの作成
次に，AKS上で作成したコンテナを动作させるために，展开のYAMLを作成します。
下记のYAMLファイルを作成しDeployment.yamlとして保存してください。
apiVersion: apps/v1
kind: Deployment
metadata:
name: payara-config-service
spec:
replicas: 2
selector:
matchLabels:
app: payara-config-service
template:
metadata:
labels:
app: payara-config-service
version: v1
stage: develop
spec:
securityContext:
runAsUser: 1000
containers:
- name: payara-config-service
image: containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample:1.0
resources:
requests:
cpu: 100m
memory: 1Gi
limits:
cpu: 200m
memory: 1Gi
4.12. 部署YAMLの适用
展开Y YAMLファイルを作成したのち，AKS环境に展开します。下记のコマンドを実行してYAMLファイルを适用してください。
$ kubectl apply -f deployment.yaml
deployment.apps/payara-config-service created
4.13. Podの动作确认
正しく，部署YAMLファイルが适用されるとkubectl get poのコマンドでSTATUSがRunningになっていることを确认できます。
$ kubectl get po
NAME READY STATUS RESTARTS AGE
payara-config-service-85f5cdd768-42sh8 1/1 Running 0 28s
payara-config-service-85f5cdd768-fhjrh 1/1 Running 0 28s
仮にRunningのステータスが表示されていない场合は，下记のコマンドを実行して原因を确认してください
$ kubectl describe po payara-config-service-85f5cdd768-42sh8
もしくは
$ kubectl logs payara-config-service-85f5cdd768-42sh8
ステータスがRunningになっている场合，アプリケーションが动作しています。
$ kubectl port-forward payara-config-service-85f5cdd768-42sh8 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
port-forwardコマンドを実行した后，别のターミナルミナ开きcurlコマンド，もしくはブラウザを起动しアプリケーションのエンドポイントにアクセスしてください。
下记のように文字列が表示されていればアプリプーションが正しく动作しています。
$ curl localhost:8080/app/data/config/injected
Config value as Injected by CDI Injected value
4.14. 环境変数を设定し更新
上记で，アプリケーションの动作确认ができましたが现时点で环境変数を设定していないため，アプリケーション内の物フイルに设定した値が表示されています。
アプリケーション外部の环境変数から値をとるために，Kubernetesの展开YAMLを修正し再度デプロイしてください。
追记するYAMLの设定は下记の箇所です。
env:
- name: injected_value
value: ENVIRONMENT VALUE
修正后のYAMLファイルは下记のようになります。
apiVersion: apps/v1
kind: Deployment
metadata:
name: payara-config-service
spec:
replicas: 2
selector:
matchLabels:
app: payara-config-service
template:
metadata:
labels:
app: payara-config-service
version: v1
stage: develop
spec:
securityContext:
runAsUser: 1000
containers:
- name: payara-config-service
image: containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample:1.0
env:
- name: injected_value
value: ENVIRONMENT VALUE
resources:
requests:
cpu: 100m
memory: 1Gi
limits:
cpu: 200m
memory: 1Gi
上记のYAMLファイルを编集した后，YAMLファイルを适用してください。
$ kubectl apply -f deployment.yaml
deployment.apps/payara-config-service configured
YAMLを适用すると，ローリング・アップグレードで新しいPodが启动されます。
# Pod の一覧を取得
$ kubectl get po
NAME READY STATUS RESTARTS AGE
payara-config-service-58cdfd6c7-gfvcl 1/1 Running 0 37s
payara-config-service-58cdfd6c7-hdm6c 1/1 Running 0 48s
# Port Forawrd で k8s 上で動作する Pod の Port をローカルにフォワード
$ kubectl port-forward payara-config-service-58cdfd6c7-gfvcl 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
新しいPodをローカルにフォワードした后，curlコマンドもしくはブラウザからエンドポイントにアクセスしてください。
AMLと，YAMLファイル中に定义した环境変数が表示されるようになります。
$ curl http://localhost:8080/app/data/config/injected
Config value as Injected by CDI ENVIRONMENT VALUE
4.15. KubernetesのConfig Map设定の设定情报の取得
Kubernetesでは，コンテナーの管理（部署.yaml) から設定を切り離して、一元管理できる Config Map という仕組みが用意されています。そこで、Deployment YAML 中に設定した環境変数の設定を Config Map に外だしして Config Map 内で設定情報を管理するようにします。
下记のConfig MapのYAMLファイルを作成しconfigmap.yamlとして保存してください。
apiVersion: v1
kind: ConfigMap
metadata:
name: microprofile-service-config
data:
injected_value: "CONFIG MAP VALUE"
次に，Config Mapの设定を适用します。
# Config Map を適用
$ kubectl apply -f configmap.yaml
configmap/microprofile-service-config createds
# Config Map の設定が追加されている事の確認
$ kubectl get cm
NAME DATA AGE
microprofile-service-config 1 37m
次に，KubernetesのPodから配置映射の値を参照するように部署YAMLファイルの内容を修正します。
修正箇所は下记になります。
env:
- name: injected_value
valueFrom:
configMapKeyRef:
name: microprofile-service-config
key: injected_value
修正した部署YAMLは下记になります。
apiVersion: apps/v1
kind: Deployment
metadata:
name: payara-config-service
spec:
replicas: 2
selector:
matchLabels:
app: payara-config-service
template:
metadata:
labels:
app: payara-config-service
version: v1
stage: develop
spec:
securityContext:
runAsUser: 1000
containers:
- name: payara-config-service
image: containerreg4yoshio.azurecr.io/tyoshio2002/payara-config-sample:1.0
env:
- name: injected_value
valueFrom:
configMapKeyRef:
name: microprofile-service-config
key: injected_value
resources:
requests:
cpu: 100m
memory: 1Gi
limits:
cpu: 200m
memory: 1Gi
部署YAMLを修正した后适用してください。
适用した后状态が正在运行になっていることを确认してください。
再启动したPodをローカルからアクセスできるようにPort Forwardしてください。
# 修正した Deployment YAML の適用
$ kubectl apply -f deployment.yaml
deployment.apps/payara-config-service configured
# 再起動した Pod の一覧を取得
$ kubectl get po
NAME READY STATUS RESTARTS AGE
payara-config-service-68bb7c8dfb-8tcbx 1/1 Running 0 22s
payara-config-service-68bb7c8dfb-f67x6 1/1 Running 0 20s
# ローカルからアクセスするためにポート・フォワードを実行
$ kubectl port-forward payara-config-service-68bb7c8dfb-8tcbx 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
するトトトトトトトトトトトトトトトトト
$ curl http://localhost:8080/app/data/config/injected
Config value as Injected by CDI CONFIG MAP VALUE
上记で，Config Mapから设置値を取り出しアプリケーションから参照できるようになりました。
4.16. Config Map値の更新とPodの再开始
最后に，设定値を変更する方法について确认します。
4.15で设置した配置映射値を更新（CONFIG MAP VALUE NEW“）します。
apiVersion: v1
kind: ConfigMap
metadata:
name: microprofile-service-config
data:
injected_value: "CONFIG MAP VALUE NEW"
ファイルを保存した后，更新した配置地图を再度适用します。
适用した后描述コマンドで正しく修正されているかを确认します。
# 修正した Config Map を適用
$ kubectl apply -f configmap.yaml
configmap/microprofile-service-config configured
# Config Map の値が変わっているか否かの確認
$ kubectl describe cm microprofile-service-config
Name: microprofile-service-config
Namespace: default
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","data":{"injected_value":"CONFIG MAP VALUE NEW"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"microprofile-...
Data
====
injected_value:
----
CONFIG MAP VALUE NEW
Events:
Config Map变为设定を反映した直后，アプリケーションのエンドポイントにアクセスしてみてください。
すると，新しい设定は反映されていない事が确认できます。
これは，KubernetesのPodは配置映射に设置した値を启动时にのみ読みにいくためです。ConfigMapの変更をチェックし自动的に再読み込みは行われないため，すでに启动しているPodにアクセスすると 古い设定情报が表示されます。
curl http://localhost:8080/app/data/config/injected
Config value as Injected by CDI CONFIG MAP VALUE
つまり，设定情报を反映するためにはPodの再开始が必要になります。
（部署YAML中の副本の数分だけPodは启动する。） ことが保证されるため）
そこで，Pod覧を一覧を取得した后，Podを删除して新しいPodが再启动されるのを待ちます。
# Pod の一覧を取得
$ kubectl get po
NAME READY STATUS RESTARTS AGE
payara-config-service-68bb7c8dfb-8tcbx 1/1 Running 0 4m24s
payara-config-service-68bb7c8dfb-f67x6 1/1 Running 0 4m22s
# 特定の Pod を削除
$ kubectl delete po payara-config-service-68bb7c8dfb-8tcbx
pod "payara-config-service-68bb7c8dfb-8tcbx" deleted
# Pod の一覧を取得（payara-config-service-68bb7c8dfb-dx7sg が新しい Pod）
$ kubectl get po
NAME READY STATUS RESTARTS AGE
payara-config-service-68bb7c8dfb-dx7sg 1/1 Running 0 26s
payara-config-service-68bb7c8dfb-f67x6 1/1 Running 0 5m27s
再启动したPodをPort Forwadしてローカルからアクセスできるようにします。
$ kubectl port-forward payara-config-service-68bb7c8dfb-dx7sg 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Foward港口后にアプリケーションのエンドポイントにアクセスするとConfig Mapで更新した値（CONFIG MAP VALUE NEW）が表示されていることを确认できます。
$ curl http://localhost:8080/app/data/config/injected
Config value as Injected by CDI CONFIG MAP VALUE NEW
以上で，AKS环境でのMicroProfile Configの动作确认ができました。
设定を外部に出して管理する事で，ソースコードの修正なしに外部の接続先などを动的に変更することができます。これによりアプリケーションのテストや ぜひ，ご适用ください。