disable edit add patch command tests temporarily

This commit is contained in:
Donny Xia
2020-10-28 12:24:51 -07:00
parent cd2ebd3046
commit 9aafc61c5b
4 changed files with 53 additions and 29 deletions

View File

@@ -4,13 +4,13 @@
## ConfigMap generation and rolling updates ## ConfigMap generation and rolling updates
Kustomize provides two ways of adding ConfigMap in one `kustomization`, either by declaring ConfigMap as a [resource] or declaring ConfigMap from a ConfigMapGenerator. The formats inside `kustomization.yaml` are Kustomize provides two ways of adding ConfigMap in one `kustomization`, either by declaring ConfigMap as a [resource] or declaring ConfigMap from a ConfigMapGenerator. The formats inside `kustomization.yaml` are
> ``` > ```
> # declare ConfigMap as a resource > # declare ConfigMap as a resource
> resources: > resources:
> - configmap.yaml > - configmap.yaml
> >
> # declare ConfigMap from a ConfigMapGenerator > # declare ConfigMap from a ConfigMapGenerator
> configMapGenerator: > configMapGenerator:
> - name: a-configmap > - name: a-configmap
@@ -28,7 +28,9 @@ In this demo, the same [hello_world](helloWorld/README.md) is used while the Con
### Establish base and staging ### Establish base and staging
Establish the base with a configMapGenerator Establish the base with a configMapGenerator
<!-- @establishBase @testAgainstLatestRelease --> <!-- @establishBase @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -46,16 +48,18 @@ commonLabels:
resources: resources:
- deployment.yaml - deployment.yaml
- service.yaml - service.yaml
configMapGenerator: configMapGenerator:
- name: the-map - name: the-map
literals: literals:
- altGreeting=Good Morning! - altGreeting=Good Morning!
- enableRisky="false" - enableRisky="false"
EOF EOF
``` ```
Establish the staging with a patch applied to the ConfigMap Establish the staging with a patch applied to the ConfigMap
<!-- @establishStaging @testAgainstLatestRelease --> <!-- @establishStaging @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -92,8 +96,8 @@ configured with data from a configMap.
The deployment refers to this map by name: The deployment refers to this map by name:
<!-- @showDeployment @testAgainstLatestRelease --> <!-- @showDeployment @testAgainstLatestRelease -->
``` ```
grep -C 2 configMapKeyRef $BASE/deployment.yaml grep -C 2 configMapKeyRef $BASE/deployment.yaml
``` ```
@@ -106,12 +110,12 @@ changed, so such updates have no effect.
The recommended way to change a deployment's The recommended way to change a deployment's
configuration is to configuration is to
1. create a new configMap with a new name, 1. create a new configMap with a new name,
1. patch the _deployment_, modifying the name value of 1. patch the _deployment_, modifying the name value of
the appropriate `configMapKeyRef` field. the appropriate `configMapKeyRef` field.
This latter change initiates rolling update to the pods This latter change initiates rolling update to the pods
in the deployment. The older configMap, when no longer in the deployment. The older configMap, when no longer
referenced by any other resource, is eventually [garbage referenced by any other resource, is eventually [garbage
collected](/../../issues/242). collected](/../../issues/242).
@@ -120,6 +124,7 @@ collected](/../../issues/242).
The _staging_ [variant] here has a configMap [patch]: The _staging_ [variant] here has a configMap [patch]:
<!-- @showMapPatch @testAgainstLatestRelease --> <!-- @showMapPatch @testAgainstLatestRelease -->
``` ```
cat $OVERLAYS/staging/map.yaml cat $OVERLAYS/staging/map.yaml
``` ```
@@ -131,6 +136,7 @@ resource spec.
The ConfigMap it modifies is declared from a configMapGenerator. The ConfigMap it modifies is declared from a configMapGenerator.
<!-- @showMapBase @testAgainstLatestRelease --> <!-- @showMapBase @testAgainstLatestRelease -->
``` ```
grep -C 4 configMapGenerator $BASE/kustomization.yaml grep -C 4 configMapGenerator $BASE/kustomization.yaml
``` ```
@@ -139,11 +145,12 @@ For a patch to work, the names in the `metadata/name`
fields must match. fields must match.
However, the name values specified in the file are However, the name values specified in the file are
_not_ what gets used in the cluster. By design, _not_ what gets used in the cluster. By design,
kustomize modifies names of ConfigMaps declared from ConfigMapGenerator. To see the names kustomize modifies names of ConfigMaps declared from ConfigMapGenerator. To see the names
ultimately used in the cluster, just run kustomize: ultimately used in the cluster, just run kustomize:
<!-- @grepStagingName @testAgainstLatestRelease --> <!-- @grepStagingName @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging |\ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
@@ -161,7 +168,8 @@ The suffix to the configMap name is generated from a
hash of the maps content - in this case the name suffix hash of the maps content - in this case the name suffix
is _5276h4th55_: is _5276h4th55_:
<!-- @grepStagingHash --> <!-- @grepStagingHash @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging | grep 5276h4th55 kustomize build $OVERLAYS/staging | grep 5276h4th55
``` ```
@@ -170,6 +178,7 @@ Now modify the map patch, to change the greeting
the server will use: the server will use:
<!-- @changeMap @testAgainstLatestRelease --> <!-- @changeMap @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
``` ```
@@ -184,6 +193,7 @@ kustomize build $OVERLAYS/staging |\
Run kustomize again to see the new configMap names: Run kustomize again to see the new configMap names:
<!-- @grepStagingName @testAgainstLatestRelease --> <!-- @grepStagingName @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging |\ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
@@ -194,7 +204,8 @@ in three new names ending in _c2g8fcbf88_ - one in the
configMap name itself, and two in the deployment that configMap name itself, and two in the deployment that
uses the map: uses the map:
<!-- @countHashes --> <!-- @countHashes @testAgainstLatestRelease -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \ $(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \
@@ -204,7 +215,7 @@ test 3 == \
Applying these resources to the cluster will result in Applying these resources to the cluster will result in
a rolling update of the deployments pods, retargetting a rolling update of the deployments pods, retargetting
them from the _5276h4th55_ maps to the _c2g8fcbf88_ them from the _5276h4th55_ maps to the _c2g8fcbf88_
maps. The system will later garbage collect the maps. The system will later garbage collect the
unused maps. unused maps.
## Rollback ## Rollback

View File

@@ -102,7 +102,7 @@ For Spring Boot application, we can set an active profile through the environmen
the application will pick up an extra `application-<profile>.properties` file. With this, we can customize the configMap in two the application will pick up an extra `application-<profile>.properties` file. With this, we can customize the configMap in two
steps. Add an environment variable through the patch and add a file to the configMap. steps. Add an environment variable through the patch and add a file to the configMap.
<!-- @customizeConfigMap @testAgainstLatestRelease --> <!-- @customizeConfigMap -->
``` ```
cat <<EOF >$DEMO_HOME/patch.yaml cat <<EOF >$DEMO_HOME/patch.yaml
apiVersion: apps/v1 apiVersion: apps/v1
@@ -281,7 +281,7 @@ The output contains
Add these patches to the kustomization: Add these patches to the kustomization:
<!-- @addPatch @testAgainstLatestRelease --> <!-- @addPatch -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1 kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1

View File

@@ -5,6 +5,7 @@
## ConfigMap 的生成和滚动更新 ## ConfigMap 的生成和滚动更新
kustomize 提供了两种添加 ConfigMap 的方法: kustomize 提供了两种添加 ConfigMap 的方法:
- 将 ConfigMap 声明为 [resource] - 将 ConfigMap 声明为 [resource]
- 通过 ConfigMapGenerator 声明 ConfigMap - 通过 ConfigMapGenerator 声明 ConfigMap
@@ -14,7 +15,7 @@ kustomize 提供了两种添加 ConfigMap 的方法:
> # 将 ConfigMap 声明为 resource > # 将 ConfigMap 声明为 resource
> resources: > resources:
> - configmap.yaml > - configmap.yaml
> >
> # 在 ConfigMapGenerator 中声明 ConfigMap > # 在 ConfigMapGenerator 中声明 ConfigMap
> configMapGenerator: > configMapGenerator:
> - name: a-configmap > - name: a-configmap
@@ -30,7 +31,9 @@ kustomize 提供了两种添加 ConfigMap 的方法:
### 建立 base 和 staging ### 建立 base 和 staging
使用 configMapGenerator 建立 base 使用 configMapGenerator 建立 base
<!-- @establishBase @testAgainstLatestRelease --> <!-- @establishBase @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -48,16 +51,18 @@ commonLabels:
resources: resources:
- deployment.yaml - deployment.yaml
- service.yaml - service.yaml
configMapGenerator: configMapGenerator:
- name: the-map - name: the-map
literals: literals:
- altGreeting=Good Morning! - altGreeting=Good Morning!
- enableRisky="false" - enableRisky="false"
EOF EOF
``` ```
通过应用 ConfigMap patch 的方式建立 staging 通过应用 ConfigMap patch 的方式建立 staging
<!-- @establishStaging @testAgainstLatestRelease --> <!-- @establishStaging @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -94,6 +99,7 @@ EOF
deployment 按照名称引用此 ConfigMap deployment 按照名称引用此 ConfigMap
<!-- @showDeployment @testAgainstLatestRelease --> <!-- @showDeployment @testAgainstLatestRelease -->
``` ```
grep -C 2 configMapKeyRef $BASE/deployment.yaml grep -C 2 configMapKeyRef $BASE/deployment.yaml
``` ```
@@ -102,16 +108,17 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml
更改 Deployment 配置的推荐方法是: 更改 Deployment 配置的推荐方法是:
1. 使用新名称创建一个新的 configMap 1. 使用新名称创建一个新的 configMap
2. 为_deployment_ 添加 patch修改相应 `configMapKeyRef` 字段的名称值。 2. 为*deployment* 添加 patch修改相应 `configMapKeyRef` 字段的名称值。
后一种更改会启动对 deployment 中的 pod 的滚动更新。旧的 configMap 在不再被任何其他资源引用时最终会被[垃圾回收](/../../issues/242)。 后一种更改会启动对 deployment 中的 pod 的滚动更新。旧的 configMap 在不再被任何其他资源引用时最终会被[垃圾回收](/../../issues/242)。
### 如何使用 kustomize ### 如何使用 kustomize
_staging_ 的 [variant] 包含一个 configMap 的 [patch] _staging_ 的 [variant] 包含一个 configMap 的 [patch]
<!-- @showMapPatch @testAgainstLatestRelease --> <!-- @showMapPatch @testAgainstLatestRelease -->
``` ```
cat $OVERLAYS/staging/map.yaml cat $OVERLAYS/staging/map.yaml
``` ```
@@ -121,6 +128,7 @@ cat $OVERLAYS/staging/map.yaml
在 ConfigMapGenerator 中声明 ConfigMap 的修改。 在 ConfigMapGenerator 中声明 ConfigMap 的修改。
<!-- @showMapBase @testAgainstLatestRelease --> <!-- @showMapBase @testAgainstLatestRelease -->
``` ```
grep -C 4 configMapGenerator $BASE/kustomization.yaml grep -C 4 configMapGenerator $BASE/kustomization.yaml
``` ```
@@ -130,6 +138,7 @@ grep -C 4 configMapGenerator $BASE/kustomization.yaml
但是文件中指定的名称值不是群集中使用的名称值。根据设计kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称,只需运行 kustomize 但是文件中指定的名称值不是群集中使用的名称值。根据设计kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称,只需运行 kustomize
<!-- @grepStagingName @testAgainstLatestRelease --> <!-- @grepStagingName @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging |\ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
@@ -141,7 +150,8 @@ kustomize build $OVERLAYS/staging |\
configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下,名称后缀是 _5276h4th55_ configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下,名称后缀是 _5276h4th55_
<!-- @grepStagingHash --> <!-- @grepStagingHash @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging | grep 5276h4th55 kustomize build $OVERLAYS/staging | grep 5276h4th55
``` ```
@@ -149,6 +159,7 @@ kustomize build $OVERLAYS/staging | grep 5276h4th55
现在修改 map patch ,更改该服务将使用的问候消息: 现在修改 map patch ,更改该服务将使用的问候消息:
<!-- @changeMap @testAgainstLatestRelease --> <!-- @changeMap @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
``` ```
@@ -163,6 +174,7 @@ kustomize build $OVERLAYS/staging |\
再次运行 kustomize 查看新的 configMap 名称: 再次运行 kustomize 查看新的 configMap 名称:
<!-- @grepStagingName @testAgainstLatestRelease --> <!-- @grepStagingName @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging |\ kustomize build $OVERLAYS/staging |\
grep -B 8 -A 1 staging-the-map grep -B 8 -A 1 staging-the-map
@@ -170,7 +182,8 @@ kustomize build $OVERLAYS/staging |\
确认 configMap 内容的更改将会生成以 _c2g8fcbf88_ 结尾的三个新名称 - 一个在 configMap 的名称中,另两个在使用 ConfigMap 的 deployment 中: 确认 configMap 内容的更改将会生成以 _c2g8fcbf88_ 结尾的三个新名称 - 一个在 configMap 的名称中,另两个在使用 ConfigMap 的 deployment 中:
<!-- @countHashes --> <!-- @countHashes @testAgainstLatestRelease -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \ $(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \

View File

@@ -89,7 +89,7 @@ cat kustomization.yaml
1. 通过 patch 添加一个环境变量 1. 通过 patch 添加一个环境变量
2. 将文件添加到 ConfigMap 中 2. 将文件添加到 ConfigMap 中
<!-- @customizeConfigMap @testAgainstLatestRelease --> <!-- @customizeConfigMap -->
``` ```
cat <<EOF >$DEMO_HOME/patch.yaml cat <<EOF >$DEMO_HOME/patch.yaml
apiVersion: apps/v1 apiVersion: apps/v1
@@ -257,7 +257,7 @@ cat $DEMO_HOME/healthcheck_patch.yaml
将这些 patch 添加到 `kustomization.yaml` 中: 将这些 patch 添加到 `kustomization.yaml` 中:
<!-- @addPatch @testAgainstLatestRelease --> <!-- @addPatch -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1 kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1