kubernetes-sigs/kustomize
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/kustomize.git synced 2026-07-17 17:52:12 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Test examples against HEAD as well as against latest release.

Browse Source
This commit is contained in:
Jeffrey Regan
2019-08-20 13:51:45 -07:00
parent 2b6a406dc7
commit 423a8a6e0d
26 changed files with 244 additions and 223 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/INSTALL.md
View File

@@ -25,7 +25,7 @@ chmod u+x kustomize
Requires [Go] v1.12 or higher: Requires [Go] v1.12 or higher:
<!-- @installkustomize @test --> <!-- @installkustomize @testAgainstLatestRelease -->
``` ```
go install sigs.k8s.io/kustomize/v3/cmd/kustomize go install sigs.k8s.io/kustomize/v3/cmd/kustomize
``` ```

2
docs/zh/INSTALL.md
View File

@@ -33,7 +33,7 @@ chmod u+x kustomize
使用 [Go] v1.10.1 或更高版本安装（如果可以访问 [golang.org]）： 使用 [Go] v1.10.1 或更高版本安装（如果可以访问 [golang.org]）：
<!-- @installkustomize @test --> <!-- @installkustomize @testAgainstLatestRelease -->
``` ```
go install sigs.k8s.io/kustomize/v3/cmd/kustomize go install sigs.k8s.io/kustomize/v3/cmd/kustomize
``` ```

14
examples/README.md
View File

@@ -2,15 +2,11 @@ English | [简体中文](zh/README.md)
# Examples # Examples
These examples assume that `kustomize` is on your `$PATH`. To run these examples, your `$PATH` must contain `kustomize`.
See the [installation instructions](../docs/INSTALL.md).
They are covered by [pre-commit](../travis/pre-commit.sh) These examples are [tested](../travis/pre-commit.sh)
tests, and should work with HEAD to work with the latest _released_ version of kustomize.
<!-- @installkustomize @test -->
```
go get sigs.k8s.io/kustomize/v3/cmd/kustomize
```
Basic Usage Basic Usage
@@ -71,4 +67,4 @@ Multi Variant Examples
* [breakfast](breakfast.md) - Customize breakfast for * [breakfast](breakfast.md) - Customize breakfast for
Alice and Bob. Alice and Bob.
* [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base. * [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base.

18
examples/breakfast.md
View File

@@ -6,14 +6,14 @@
Define a place to work: Define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
Make a place to put the base breakfast configuration: Make a place to put the base breakfast configuration:
<!-- @baseDir @test --> <!-- @baseDir @testAgainstLatestRelease -->
``` ```
mkdir -p $DEMO_HOME/breakfast/base mkdir -p $DEMO_HOME/breakfast/base
``` ```
@@ -21,7 +21,7 @@ mkdir -p $DEMO_HOME/breakfast/base
Make a `kustomization` to define what goes into Make a `kustomization` to define what goes into
breakfast. This breakfast has coffee and pancakes: breakfast. This breakfast has coffee and pancakes:
<!-- @baseKustomization @test --> <!-- @baseKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/breakfast/base/kustomization.yaml cat <<EOF >$DEMO_HOME/breakfast/base/kustomization.yaml
resources: resources:
@@ -34,7 +34,7 @@ Here's a _coffee_ type. Give it a `kind` and `metdata/name` field
to conform to [kubernetes API object style]; no other to conform to [kubernetes API object style]; no other
file or definition is needed: file or definition is needed:
<!-- @coffee @test --> <!-- @coffee @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/breakfast/base/coffee.yaml cat <<EOF >$DEMO_HOME/breakfast/base/coffee.yaml
kind: Coffee kind: Coffee
@@ -50,7 +50,7 @@ The `name` field merely distinguishes this instance of
coffee from others (if there were any). coffee from others (if there were any).
Likewise, define _pancakes_: Likewise, define _pancakes_:
<!-- @pancakes @test --> <!-- @pancakes @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/breakfast/base/pancakes.yaml cat <<EOF >$DEMO_HOME/breakfast/base/pancakes.yaml
kind: Pancakes kind: Pancakes
@@ -64,7 +64,7 @@ EOF
Make a custom [variant] of breakfast for Alice, who Make a custom [variant] of breakfast for Alice, who
likes her coffee hot: likes her coffee hot:
<!-- @aliceOverlay @test --> <!-- @aliceOverlay @testAgainstLatestRelease -->
``` ```
mkdir -p $DEMO_HOME/breakfast/overlays/alice mkdir -p $DEMO_HOME/breakfast/overlays/alice
@@ -87,7 +87,7 @@ EOF
And likewise a [variant] for Bob, who wants _five_ pancakes, with strawberries: And likewise a [variant] for Bob, who wants _five_ pancakes, with strawberries:
<!-- @bobOverlay @test --> <!-- @bobOverlay @testAgainstLatestRelease -->
``` ```
mkdir -p $DEMO_HOME/breakfast/overlays/bob mkdir -p $DEMO_HOME/breakfast/overlays/bob
@@ -111,14 +111,14 @@ EOF
One can now generate the configs for Alice’s breakfast: One can now generate the configs for Alice’s breakfast:
<!-- @generateAlice @test --> <!-- @generateAlice @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME/breakfast/overlays/alice kustomize build $DEMO_HOME/breakfast/overlays/alice
``` ```
Likewise for Bob: Likewise for Bob:
<!-- @generateBob @test --> <!-- @generateBob @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME/breakfast/overlays/bob kustomize build $DEMO_HOME/breakfast/overlays/bob
``` ```

16
examples/combineConfigs.md
View File

@@ -128,7 +128,7 @@ defined in the [helloworld] demo.
It will all live in this work directory: It will all live in this work directory:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -139,7 +139,7 @@ DEMO_HOME=$(mktemp -d)
Make a place to put the base configuration: Make a place to put the base configuration:
<!-- @baseDir @test --> <!-- @baseDir @testAgainstLatestRelease -->
``` ```
mkdir -p $DEMO_HOME/base mkdir -p $DEMO_HOME/base
``` ```
@@ -150,7 +150,7 @@ environments. Here we're only defining a java
properties file, and a `kustomization` file that properties file, and a `kustomization` file that
references it. references it.
<!-- @baseKustomization @test --> <!-- @baseKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/base/common.properties cat <<EOF >$DEMO_HOME/base/common.properties
color=blue color=blue
@@ -171,14 +171,14 @@ EOF
Make an abbreviation for the parent of the overlay Make an abbreviation for the parent of the overlay
directories: directories:
<!-- @overlays @test --> <!-- @overlays @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
``` ```
Create the files that define the _development_ overlay: Create the files that define the _development_ overlay:
<!-- @developmentFiles @test --> <!-- @developmentFiles @testAgainstLatestRelease -->
``` ```
mkdir -p $OVERLAYS/development mkdir -p $OVERLAYS/development
@@ -206,7 +206,7 @@ EOF
One can now generate the configMaps for development: One can now generate the configMaps for development:
<!-- @runDev @test --> <!-- @runDev @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/development kustomize build $OVERLAYS/development
``` ```
@@ -260,7 +260,7 @@ deletes unused configMaps.
Next, create the files for the _production_ overlay: Next, create the files for the _production_ overlay:
<!-- @productionFiles @test --> <!-- @productionFiles @testAgainstLatestRelease -->
``` ```
mkdir -p $OVERLAYS/production mkdir -p $OVERLAYS/production
@@ -287,7 +287,7 @@ EOF
One can now generate the configMaps for production: One can now generate the configMaps for production:
<!-- @runProd @test --> <!-- @runProd @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/production kustomize build $OVERLAYS/production
``` ```

20
examples/configGeneration.md
View File

@@ -26,7 +26,7 @@ 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 @test --> <!-- @establishBase @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -53,7 +53,7 @@ EOF
``` ```
Establish the staging with a patch applied to the ConfigMap Establish the staging with a patch applied to the ConfigMap
<!-- @establishStaging @test --> <!-- @establishStaging @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -91,7 +91,7 @@ configured with data from a configMap.
The deployment refers to this map by name: The deployment refers to this map by name:
<!-- @showDeployment @test --> <!-- @showDeployment @testAgainstLatestRelease -->
``` ```
grep -C 2 configMapKeyRef $BASE/deployment.yaml grep -C 2 configMapKeyRef $BASE/deployment.yaml
``` ```
@@ -117,7 +117,7 @@ collected](https://github.com/kubernetes-sigs/kustomize/issues/242).
The _staging_ [variant] here has a configMap [patch]: The _staging_ [variant] here has a configMap [patch]:
<!-- @showMapPatch @test --> <!-- @showMapPatch @testAgainstLatestRelease -->
``` ```
cat $OVERLAYS/staging/map.yaml cat $OVERLAYS/staging/map.yaml
``` ```
@@ -128,7 +128,7 @@ resource spec.
The ConfigMap it modifies is declared from a configMapGenerator. The ConfigMap it modifies is declared from a configMapGenerator.
<!-- @showMapBase @test --> <!-- @showMapBase @testAgainstLatestRelease -->
``` ```
grep -C 4 configMapGenerator $BASE/kustomization.yaml grep -C 4 configMapGenerator $BASE/kustomization.yaml
``` ```
@@ -141,7 +141,7 @@ _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 @test --> <!-- @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
@@ -159,7 +159,7 @@ 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 _k25m8k5k5m_: is _k25m8k5k5m_:
<!-- @grepStagingHash @test --> <!-- @grepStagingHash @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging | grep k25m8k5k5m kustomize build $OVERLAYS/staging | grep k25m8k5k5m
``` ```
@@ -167,7 +167,7 @@ kustomize build $OVERLAYS/staging | grep k25m8k5k5m
Now modify the map patch, to change the greeting Now modify the map patch, to change the greeting
the server will use: the server will use:
<!-- @changeMap @test --> <!-- @changeMap @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
``` ```
@@ -181,7 +181,7 @@ kustomize build $OVERLAYS/staging |\
Run kustomize again to see the new configMap names: Run kustomize again to see the new configMap names:
<!-- @grepStagingName @test --> <!-- @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
@@ -192,7 +192,7 @@ in three new names ending in _cd7kdh48fd_ - 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 @test --> <!-- @countHashes @testAgainstLatestRelease -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \ $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \

6
examples/generatorOptions.md
View File

@@ -13,7 +13,7 @@ DEMO_HOME=$(mktemp -d)
Create a kustomization and add a ConfigMap generator to it. Create a kustomization and add a ConfigMap generator to it.
<!-- @createCMGenerator @test --> <!-- @createCMGenerator @testAgainstLatestRelease -->
``` ```
cat > $DEMO_HOME/kustomization.yaml << EOF cat > $DEMO_HOME/kustomization.yaml << EOF
configMapGenerator: configMapGenerator:
@@ -25,7 +25,7 @@ EOF
``` ```
Add following generatorOptions Add following generatorOptions
<!-- @addGeneratorOptions @test --> <!-- @addGeneratorOptions @testAgainstLatestRelease -->
``` ```
cat >> $DEMO_HOME/kustomization.yaml << EOF cat >> $DEMO_HOME/kustomization.yaml << EOF
generatorOptions: generatorOptions:
@@ -39,7 +39,7 @@ EOF
Run `kustomize build` and make sure that the generated ConfigMap Run `kustomize build` and make sure that the generated ConfigMap
- doesn't have name suffix - doesn't have name suffix
<!-- @verify @test --> <!-- @verify @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "name: my-configmap$" | wc -l); \ $(kustomize build $DEMO_HOME | grep "name: my-configmap$" | wc -l); \

30
examples/helloWorld/README.md
View File

@@ -22,7 +22,7 @@ Steps:
First define a place to work: First define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -44,7 +44,7 @@ To keep this document shorter, the base resources are
off in a supplemental data directory rather than off in a supplemental data directory rather than
declared here as HERE documents. Download them: declared here as HERE documents. Download them:
<!-- @downloadBase @test --> <!-- @downloadBase @testAgainstLatestRelease -->
``` ```
BASE=$DEMO_HOME/base BASE=$DEMO_HOME/base
mkdir -p $BASE mkdir -p $BASE
@@ -57,7 +57,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\
Look at the directory: Look at the directory:
<!-- @runTree @test --> <!-- @runTree @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -88,7 +88,7 @@ would only recognize the resource files.
The `base` directory has a [kustomization] file: The `base` directory has a [kustomization] file:
<!-- @showKustomization @test --> <!-- @showKustomization @testAgainstLatestRelease -->
``` ```
more $BASE/kustomization.yaml more $BASE/kustomization.yaml
``` ```
@@ -96,7 +96,7 @@ more $BASE/kustomization.yaml
Optionally, run `kustomize` on the base to emit Optionally, run `kustomize` on the base to emit
customized resources to `stdout`: customized resources to `stdout`:
<!-- @buildBase @test --> <!-- @buildBase @testAgainstLatestRelease -->
``` ```
kustomize build $BASE kustomize build $BASE
``` ```
@@ -106,14 +106,14 @@ kustomize build $BASE
A first customization step could be to change the _app A first customization step could be to change the _app
label_ applied to all resources: label_ applied to all resources:
<!-- @addLabel @test --> <!-- @addLabel @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/app: hello/app: my-hello/' \ sed -i.bak 's/app: hello/app: my-hello/' \
$BASE/kustomization.yaml $BASE/kustomization.yaml
``` ```
See the effect: See the effect:
<!-- @checkLabel @test --> <!-- @checkLabel @testAgainstLatestRelease -->
``` ```
kustomize build $BASE | grep -C 3 app: kustomize build $BASE | grep -C 3 app:
``` ```
@@ -127,7 +127,7 @@ Create a _staging_ and _production_ [overlay]:
* Web server greetings from these cluster * Web server greetings from these cluster
[variants] will differ from each other. [variants] will differ from each other.
<!-- @overlayDirectories @test --> <!-- @overlayDirectories @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -139,7 +139,7 @@ mkdir -p $OVERLAYS/production
In the `staging` directory, make a kustomization In the `staging` directory, make a kustomization
defining a new name prefix, and some different labels. defining a new name prefix, and some different labels.
<!-- @makeStagingKustomization @test --> <!-- @makeStagingKustomization @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
namePrefix: staging- namePrefix: staging-
@@ -162,7 +162,7 @@ greeting from _Good Morning!_ to _Have a pineapple!_
Also, enable the _risky_ flag. Also, enable the _risky_ flag.
<!-- @stagingMap @test --> <!-- @stagingMap @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/staging/map.yaml cat <<EOF >$OVERLAYS/staging/map.yaml
apiVersion: v1 apiVersion: v1
@@ -180,7 +180,7 @@ EOF
In the production directory, make a kustomization In the production directory, make a kustomization
with a different name prefix and labels. with a different name prefix and labels.
<!-- @makeProductionKustomization @test --> <!-- @makeProductionKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/production/kustomization.yaml cat <<EOF >$OVERLAYS/production/kustomization.yaml
namePrefix: production- namePrefix: production-
@@ -202,7 +202,7 @@ EOF
Make a production patch that increases the replica Make a production patch that increases the replica
count (because production takes more traffic). count (because production takes more traffic).
<!-- @productionDeployment @test --> <!-- @productionDeployment @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/production/deployment.yaml cat <<EOF >$OVERLAYS/production/deployment.yaml
apiVersion: apps/v1 apiVersion: apps/v1
@@ -228,7 +228,7 @@ EOF
Review the directory structure and differences: Review the directory structure and differences:
<!-- @listFiles @test --> <!-- @listFiles @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -288,12 +288,12 @@ something like
The individual resource sets are: The individual resource sets are:
<!-- @buildStaging @test --> <!-- @buildStaging @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging kustomize build $OVERLAYS/staging
``` ```
<!-- @buildProduction @test --> <!-- @buildProduction @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/production kustomize build $OVERLAYS/production
``` ```

12
examples/image.md
View File

@@ -3,14 +3,14 @@
Define a place to work: Define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
Make a `kustomization` containing a pod resource Make a `kustomization` containing a pod resource
<!-- @createKustomization @test --> <!-- @createKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/kustomization.yaml cat <<EOF >$DEMO_HOME/kustomization.yaml
resources: resources:
@@ -20,7 +20,7 @@ EOF
Declare the pod resource Declare the pod resource
<!-- @createDeployment @test --> <!-- @createDeployment @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/pod.yaml cat <<EOF >$DEMO_HOME/pod.yaml
apiVersion: v1 apiVersion: v1
@@ -46,7 +46,7 @@ The image `busybox` and tag `1.29.0` can be changed by adding `images` in `kusto
Add `images`: Add `images`:
<!-- @addImages @test --> <!-- @addImages @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
kustomize edit set image busybox=alpine:3.6 kustomize edit set image busybox=alpine:3.6
@@ -61,14 +61,14 @@ The following `images` will be added to `kustomization.yaml`:
> ``` > ```
Now build this `kustomization` Now build this `kustomization`
<!-- @kustomizeBuild @test --> <!-- @kustomizeBuild @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME kustomize build $DEMO_HOME
``` ```
Confirm that this replaces _both_ busybox images and tags for `alpine:3.6`: Confirm that this replaces _both_ busybox images and tags for `alpine:3.6`:
<!-- @confirmImages @test --> <!-- @confirmImages @testAgainstLatestRelease -->
``` ```
test 2 = \ test 2 = \
$(kustomize build $DEMO_HOME | grep alpine:3.6 | wc -l); \ $(kustomize build $DEMO_HOME | grep alpine:3.6 | wc -l); \

16
examples/jsonpatch.md
View File

@@ -6,7 +6,7 @@ The example below modifies an `Ingress` object with such a patch.
Make a `kustomization` containing an ingress resource. Make a `kustomization` containing an ingress resource.
<!-- @createIngress @test --> <!-- @createIngress @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -36,7 +36,7 @@ Declare a JSON patch file to update two fields of the Ingress object:
- change host from `foo.bar.com` to `foo.bar.io` - change host from `foo.bar.com` to `foo.bar.io`
- change servicePort from `80` to `8080` - change servicePort from `80` to `8080`
<!-- @addJsonPatch @test --> <!-- @addJsonPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/ingress_patch.json cat <<EOF >$DEMO_HOME/ingress_patch.json
[ [
@@ -48,7 +48,7 @@ EOF
You can also write the patch in YAML format. This example also shows the "add" operation: You can also write the patch in YAML format. This example also shows the "add" operation:
<!-- @addYamlPatch @test --> <!-- @addYamlPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/ingress_patch.yaml cat <<EOF >$DEMO_HOME/ingress_patch.yaml
- op: replace - op: replace
@@ -67,7 +67,7 @@ EOF
Apply the patch by adding _patchesJson6902_ field in kustomization.yaml Apply the patch by adding _patchesJson6902_ field in kustomization.yaml
<!-- @applyJsonPatch @test --> <!-- @applyJsonPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
patchesJson6902: patchesJson6902:
@@ -81,14 +81,14 @@ EOF
``` ```
Running `kustomize build $DEMO_HOME`, in the output confirm that host has been updated correctly. Running `kustomize build $DEMO_HOME`, in the output confirm that host has been updated correctly.
<!-- @confirmHost @test --> <!-- @confirmHost @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \ $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
echo $? echo $?
``` ```
Running `kustomize build $DEMO_HOME`, in the output confirm that the servicePort has been updated correctly. Running `kustomize build $DEMO_HOME`, in the output confirm that the servicePort has been updated correctly.
<!-- @confirmServicePort @test --> <!-- @confirmServicePort @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "servicePort: 8080" | wc -l); \ $(kustomize build $DEMO_HOME | grep "servicePort: 8080" | wc -l); \
@@ -97,7 +97,7 @@ test 1 == \
If the patch is YAML-formatted, it will be parsed correctly: If the patch is YAML-formatted, it will be parsed correctly:
<!-- @applyYamlPatch @test --> <!-- @applyYamlPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
patchesJson6902: patchesJson6902:
@@ -110,7 +110,7 @@ patchesJson6902:
EOF EOF
``` ```
<!-- @confirmYamlPatch @test --> <!-- @confirmYamlPatch @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \ $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \

26
examples/ldap/README.md
View File

@@ -18,7 +18,7 @@ Steps:
First define a place to work: First define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -38,7 +38,7 @@ To keep this document shorter, the base resources are
off in a supplemental data directory rather than off in a supplemental data directory rather than
declared here as HERE documents. Download them: declared here as HERE documents. Download them:
<!-- @downloadBase @test --> <!-- @downloadBase @testAgainstLatestRelease -->
``` ```
BASE=$DEMO_HOME/base BASE=$DEMO_HOME/base
mkdir -p $BASE mkdir -p $BASE
@@ -53,7 +53,7 @@ curl -s -o "$BASE/#1" "$CONTENT/base\
Look at the directory: Look at the directory:
<!-- @runTree @test --> <!-- @runTree @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -84,7 +84,7 @@ would only recognize the resource files.
The `base` directory has a [kustomization] file: The `base` directory has a [kustomization] file:
<!-- @showKustomization @test --> <!-- @showKustomization @testAgainstLatestRelease -->
``` ```
more $BASE/kustomization.yaml more $BASE/kustomization.yaml
``` ```
@@ -92,7 +92,7 @@ more $BASE/kustomization.yaml
Optionally, run `kustomize` on the base to emit Optionally, run `kustomize` on the base to emit
customized resources to `stdout`: customized resources to `stdout`:
<!-- @buildBase @test --> <!-- @buildBase @testAgainstLatestRelease -->
``` ```
kustomize build $BASE kustomize build $BASE
``` ```
@@ -101,14 +101,14 @@ kustomize build $BASE
A first customization step could be to set the name prefix to all resources: A first customization step could be to set the name prefix to all resources:
<!-- @namePrefix @test --> <!-- @namePrefix @testAgainstLatestRelease -->
``` ```
cd $BASE cd $BASE
kustomize edit set nameprefix "my-" kustomize edit set nameprefix "my-"
``` ```
See the effect: See the effect:
<!-- @checkNameprefix @test --> <!-- @checkNameprefix @testAgainstLatestRelease -->
``` ```
kustomize build $BASE | grep -C 3 "my-" kustomize build $BASE | grep -C 3 "my-"
``` ```
@@ -121,7 +121,7 @@ Create a _staging_ and _production_ [overlay]:
* _Production_ has a higher replica count and a persistent disk. * _Production_ has a higher replica count and a persistent disk.
* [variants] will differ from each other. * [variants] will differ from each other.
<!-- @overlayDirectories @test --> <!-- @overlayDirectories @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -132,7 +132,7 @@ mkdir -p $OVERLAYS/production
Download the staging customization and patch. Download the staging customization and patch.
<!-- @downloadStagingKustomization @test --> <!-- @downloadStagingKustomization @testAgainstLatestRelease -->
``` ```
curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\ curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\
/{config.env,deployment.yaml,kustomization.yaml}" /{config.env,deployment.yaml,kustomization.yaml}"
@@ -159,7 +159,7 @@ as well as 2 replica
#### Production Kustomization #### Production Kustomization
Download the production customization and patch. Download the production customization and patch.
<!-- @downloadProductionKustomization @test --> <!-- @downloadProductionKustomization @testAgainstLatestRelease -->
``` ```
curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\ curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\
/{deployment.yaml,kustomization.yaml}" /{deployment.yaml,kustomization.yaml}"
@@ -196,7 +196,7 @@ The production customization adds 6 replica as well as a consistent disk.
Review the directory structure and differences: Review the directory structure and differences:
<!-- @listFiles @test --> <!-- @listFiles @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -258,12 +258,12 @@ The difference output should look something like
The individual resource sets are: The individual resource sets are:
<!-- @buildStaging @test --> <!-- @buildStaging @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging kustomize build $OVERLAYS/staging
``` ```
<!-- @buildProduction @test --> <!-- @buildProduction @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/production kustomize build $OVERLAYS/production
``` ```

14
examples/multibases/README.md
View File

@@ -20,13 +20,13 @@ that is just a single pod.
Define a place to work: Define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
Define a common base: Define a common base:
<!-- @makeBase @test --> <!-- @makeBase @testAgainstLatestRelease -->
``` ```
BASE=$DEMO_HOME/base BASE=$DEMO_HOME/base
mkdir $BASE mkdir $BASE
@@ -51,7 +51,7 @@ EOF
``` ```
Define a dev variant overlaying base: Define a dev variant overlaying base:
<!-- @makeDev @test --> <!-- @makeDev @testAgainstLatestRelease -->
``` ```
DEV=$DEMO_HOME/dev DEV=$DEMO_HOME/dev
mkdir $DEV mkdir $DEV
@@ -64,7 +64,7 @@ EOF
``` ```
Define a staging variant overlaying base: Define a staging variant overlaying base:
<!-- @makeStaging @test --> <!-- @makeStaging @testAgainstLatestRelease -->
``` ```
STAG=$DEMO_HOME/staging STAG=$DEMO_HOME/staging
mkdir $STAG mkdir $STAG
@@ -77,7 +77,7 @@ EOF
``` ```
Define a production variant overlaying base: Define a production variant overlaying base:
<!-- @makeProd @test --> <!-- @makeProd @testAgainstLatestRelease -->
``` ```
PROD=$DEMO_HOME/production PROD=$DEMO_HOME/production
mkdir $PROD mkdir $PROD
@@ -90,7 +90,7 @@ EOF
``` ```
Then define a _Kustomization_ composing three variants together: Then define a _Kustomization_ composing three variants together:
<!-- @makeTopLayer @test --> <!-- @makeTopLayer @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/kustomization.yaml cat <<EOF >$DEMO_HOME/kustomization.yaml
resources: resources:
@@ -119,7 +119,7 @@ Now the workspace has following directories
Confirm that the `kustomize build` output contains three pod objects from dev, staging and production variants. Confirm that the `kustomize build` output contains three pod objects from dev, staging and production variants.
<!-- @confirmVariants @test --> <!-- @confirmVariants @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep cluster-a-dev-myapp-pod | wc -l); \ $(kustomize build $DEMO_HOME | grep cluster-a-dev-myapp-pod | wc -l); \

12
examples/multibases/multi-namespace.md
View File

@@ -8,13 +8,13 @@ following demonstrates this using a base that's just one pod.
Define a place to work: Define a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
Define a common base: Define a common base:
<!-- @makeBase @test --> <!-- @makeBase @testAgainstLatestRelease -->
``` ```
BASE=$DEMO_HOME/base BASE=$DEMO_HOME/base
mkdir $BASE mkdir $BASE
@@ -39,7 +39,7 @@ EOF
``` ```
Define a variant in namespace-a overlaying base: Define a variant in namespace-a overlaying base:
<!-- @makeNamespaceA @test --> <!-- @makeNamespaceA @testAgainstLatestRelease -->
``` ```
NSA=$DEMO_HOME/namespace-a NSA=$DEMO_HOME/namespace-a
mkdir $NSA mkdir $NSA
@@ -60,7 +60,7 @@ EOF
``` ```
Define a variant in namespace-b overlaying base: Define a variant in namespace-b overlaying base:
<!-- @makeNamespaceB @test --> <!-- @makeNamespaceB @testAgainstLatestRelease -->
``` ```
NSB=$DEMO_HOME/namespace-b NSB=$DEMO_HOME/namespace-b
mkdir $NSB mkdir $NSB
@@ -81,7 +81,7 @@ EOF
``` ```
Then define a _Kustomization_ composing two variants together: Then define a _Kustomization_ composing two variants together:
<!-- @makeTopLayer @test --> <!-- @makeTopLayer @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/kustomization.yaml cat <<EOF >$DEMO_HOME/kustomization.yaml
resources: resources:
@@ -107,7 +107,7 @@ Now the workspace has following directories
Confirm that the `kustomize build` output contains two pod objects from namespace-a and namespace-b. Confirm that the `kustomize build` output contains two pod objects from namespace-a and namespace-b.
<!-- @confirmVariants @test --> <!-- @confirmVariants @testAgainstLatestRelease -->
``` ```
test 2 == \ test 2 == \
$(kustomize build $DEMO_HOME| grep -B 4 "namespace: namespace-[ab]" | grep "name: myapp-pod" | wc -l); \ $(kustomize build $DEMO_HOME| grep -B 4 "namespace: namespace-[ab]" | grep "name: myapp-pod" | wc -l); \

20
examples/mySql/README.md
View File

@@ -11,7 +11,7 @@ In the production environment we want:
- MySQL to use persistent disk for storing data. - MySQL to use persistent disk for storing data.
First make a place to work: First make a place to work:
<!-- @makeDemoHome @test --> <!-- @makeDemoHome @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -25,7 +25,7 @@ as HERE documents.
Download them: Download them:
<!-- @downloadResources @test --> <!-- @downloadResources @testAgainstLatestRelease -->
``` ```
curl -s -o "$DEMO_HOME/#1.yaml" "https://raw.githubusercontent.com\ curl -s -o "$DEMO_HOME/#1.yaml" "https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\ /kubernetes-sigs/kustomize\
@@ -40,14 +40,14 @@ a file called `kustomization.yaml`.
Start this file: Start this file:
<!-- @kustomizeYaml @test --> <!-- @kustomizeYaml @testAgainstLatestRelease -->
``` ```
touch $DEMO_HOME/kustomization.yaml touch $DEMO_HOME/kustomization.yaml
``` ```
### Add the resources ### Add the resources
<!-- @addResources @test --> <!-- @addResources @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
@@ -73,7 +73,7 @@ Arrange for the MySQL resources to begin with prefix
_prod-_ (since they are meant for the _production_ _prod-_ (since they are meant for the _production_
environment): environment):
<!-- @customizeLabel @test --> <!-- @customizeLabel @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
@@ -91,7 +91,7 @@ cat kustomization.yaml
This `namePrefix` directive adds _prod-_ to all This `namePrefix` directive adds _prod-_ to all
resource names. resource names.
<!-- @genNamePrefixConfig @test --> <!-- @genNamePrefixConfig @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME kustomize build $DEMO_HOME
``` ```
@@ -134,7 +134,7 @@ selector.
`kustomize` does not have `edit set label` command to add `kustomize` does not have `edit set label` command to add
a label, but one can always edit `kustomization.yaml` directly: a label, but one can always edit `kustomization.yaml` directly:
<!-- @customizeLabels @test --> <!-- @customizeLabels @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/app: helloworld/app: prod/' \ sed -i.bak 's/app: helloworld/app: prod/' \
$DEMO_HOME/kustomization.yaml $DEMO_HOME/kustomization.yaml
@@ -153,7 +153,7 @@ environment. So we want to use Persistent Disk in
production. kustomize lets you apply `patchesStrategicMerge` to the production. kustomize lets you apply `patchesStrategicMerge` to the
resources. resources.
<!-- @createPatchFile @test --> <!-- @createPatchFile @testAgainstLatestRelease -->
``` ```
cat <<'EOF' > $DEMO_HOME/persistent-disk.yaml cat <<'EOF' > $DEMO_HOME/persistent-disk.yaml
apiVersion: apps/v1beta2 # for versions before 1.9.0 use apps/v1beta2 apiVersion: apps/v1beta2 # for versions before 1.9.0 use apps/v1beta2
@@ -173,7 +173,7 @@ EOF
Add the patch file to `kustomization.yaml`: Add the patch file to `kustomization.yaml`:
<!-- @specifyPatch @test --> <!-- @specifyPatch @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >> $DEMO_HOME/kustomization.yaml cat <<'EOF' >> $DEMO_HOME/kustomization.yaml
patchesStrategicMerge: patchesStrategicMerge:
@@ -199,7 +199,7 @@ The output of the following command can now be applied
to the cluster (i.e. piped to `kubectl apply`) to to the cluster (i.e. piped to `kubectl apply`) to
create the production environment. create the production environment.
<!-- @finalInflation @test --> <!-- @finalInflation @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME # | kubectl apply -f - kustomize build $DEMO_HOME # | kubectl apply -f -
``` ```

8
examples/patchMultipleObjects.md
View File

@@ -29,7 +29,7 @@ The example below shows how to inject a sidecar container for all deployment res
Make a `kustomization` containing a Deployment resource. Make a `kustomization` containing a Deployment resource.
<!-- @createDeployment @test --> <!-- @createDeployment @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -74,7 +74,7 @@ EOF
Declare a Strategic Merge Patch file to inject a sidecar container: Declare a Strategic Merge Patch file to inject a sidecar container:
<!-- @addPatch @test --> <!-- @addPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/patch.yaml cat <<EOF >$DEMO_HOME/patch.yaml
apiVersion: apps/v1 apiVersion: apps/v1
@@ -95,7 +95,7 @@ EOF
Apply the patch by adding _patches_ field in kustomization.yaml Apply the patch by adding _patches_ field in kustomization.yaml
<!-- @applyPatch @test --> <!-- @applyPatch @testAgainstLatestRelease -->
``` ```
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
patches: patches:
@@ -107,7 +107,7 @@ EOF
Running `kustomize build $DEMO_HOME`, in the output confirm that both Deployment resources are patched correctly. Running `kustomize build $DEMO_HOME`, in the output confirm that both Deployment resources are patched correctly.
<!-- @confirmPatch @test --> <!-- @confirmPatch @testAgainstLatestRelease -->
``` ```
test 2 == \ test 2 == \
$(kustomize build $DEMO_HOME | grep "image: docker.io/istio/proxyv2" | wc -l); \ $(kustomize build $DEMO_HOME | grep "image: docker.io/istio/proxyv2" | wc -l); \

8
examples/remoteBuild.md
View File

@@ -11,7 +11,7 @@ To try this immediately, run a build against the kustomization
in the [multibases](multibases/README.md) example. There's in the [multibases](multibases/README.md) example. There's
one pod in the output: one pod in the output:
<!-- @remoteOverlayBuild @test --> <!-- @remoteOverlayBuild @testAgainstLatestRelease -->
``` ```
target="github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6" target="github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6"
@@ -24,7 +24,7 @@ Run against the overlay in that example to get three pods
(the overlay combines the dev, staging and prod bases for (the overlay combines the dev, staging and prod bases for
someone who wants to send them all at the same time): someone who wants to send them all at the same time):
<!-- @remoteBuild @test --> <!-- @remoteBuild @testAgainstLatestRelease -->
``` ```
target="https://github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6" target="https://github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6"
test 3 == \ test 3 == \
@@ -34,7 +34,7 @@ test 3 == \
A base can be a URL: A base can be a URL:
<!-- @createOverlay @test --> <!-- @createOverlay @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -48,7 +48,7 @@ EOF
Build this to confirm that all three pods from the base Build this to confirm that all three pods from the base
have the `remote-` prefix. have the `remote-` prefix.
<!-- @remoteBases @test --> <!-- @remoteBases @testAgainstLatestRelease -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $DEMO_HOME | grep remote-.*-myapp-pod | wc -l); \ $(kustomize build $DEMO_HOME | grep remote-.*-myapp-pod | wc -l); \

16
examples/secretGeneratorPlugin.md
View File

@@ -25,7 +25,7 @@ etc.
## Make a place to work ## Make a place to work
<!-- @establishBase @test --> <!-- @establishBase @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -43,7 +43,7 @@ Here's an example combining all three methods:
Make an env file with some short secrets: Make an env file with some short secrets:
<!-- @makeEnvFile @test --> <!-- @makeEnvFile @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/foo.env cat <<'EOF' >$DEMO_HOME/foo.env
ROUTER_PASSWORD=admin ROUTER_PASSWORD=admin
@@ -53,7 +53,7 @@ EOF
Make a text file with a long secret: Make a text file with a long secret:
<!-- @makeLongSecretFile @test --> <!-- @makeLongSecretFile @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/longsecret.txt cat <<'EOF' >$DEMO_HOME/longsecret.txt
Lorem ipsum dolor sit amet, Lorem ipsum dolor sit amet,
@@ -67,7 +67,7 @@ And make a kustomization file referring to the
above and _additionally_ defining some literal KV above and _additionally_ defining some literal KV
pairs in line: pairs in line:
<!-- @makeKustomization1 @test --> <!-- @makeKustomization1 @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/kustomization.yaml cat <<'EOF' >$DEMO_HOME/kustomization.yaml
secretGenerator: secretGenerator:
@@ -84,7 +84,7 @@ EOF
Now generate the Secret: Now generate the Secret:
<!-- @build1 @test --> <!-- @build1 @testAgainstLatestRelease -->
``` ```
result=$(kustomize build $DEMO_HOME) result=$(kustomize build $DEMO_HOME)
echo "$result" echo "$result"
@@ -141,7 +141,7 @@ from a database.
Download it Download it
<!-- @copyPlugin @test --> <!-- @copyPlugin @testAgainstLatestRelease -->
``` ```
repo=https://raw.githubusercontent.com/kubernetes-sigs/kustomize repo=https://raw.githubusercontent.com/kubernetes-sigs/kustomize
pPath=plugin/someteam.example.com/v1/secretsfromdatabase pPath=plugin/someteam.example.com/v1/secretsfromdatabase
@@ -165,7 +165,7 @@ go build -buildmode plugin \
Create a configuration file for it: Create a configuration file for it:
<!-- @makeConfiguration @test --> <!-- @makeConfiguration @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/secretFromDb.yaml cat <<'EOF' >$DEMO_HOME/secretFromDb.yaml
apiVersion: someteam.example.com/v1 apiVersion: someteam.example.com/v1
@@ -183,7 +183,7 @@ EOF
Create a new kustomization file Create a new kustomization file
referencing this plugin: referencing this plugin:
<!-- @makeKustomization2 @test --> <!-- @makeKustomization2 @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/kustomization.yaml cat <<'EOF' >$DEMO_HOME/kustomization.yaml
generators: generators:

28
examples/springboot/README.md
View File

@@ -13,7 +13,7 @@ In the production environment we want to customize the following:
- health check and readiness check. - health check and readiness check.
First make a place to work: First make a place to work:
<!-- @makeDemoHome @test --> <!-- @makeDemoHome @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -27,7 +27,7 @@ as HERE documents.
Download them: Download them:
<!-- @downloadResources @test --> <!-- @downloadResources @testAgainstLatestRelease -->
``` ```
CONTENT="https://raw.githubusercontent.com\ CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\ /kubernetes-sigs/kustomize\
@@ -44,14 +44,14 @@ a file called `kustomization.yaml`.
Start this file: Start this file:
<!-- @kustomizeYaml @test --> <!-- @kustomizeYaml @testAgainstLatestRelease -->
``` ```
touch $DEMO_HOME/kustomization.yaml touch $DEMO_HOME/kustomization.yaml
``` ```
### Add the resources ### Add the resources
<!-- @addResources @test --> <!-- @addResources @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
@@ -71,7 +71,7 @@ cat kustomization.yaml
### Add configMap generator ### Add configMap generator
<!-- @addConfigMap @test --> <!-- @addConfigMap @testAgainstLatestRelease -->
``` ```
echo "app.name=Kustomize Demo" >$DEMO_HOME/application.properties echo "app.name=Kustomize Demo" >$DEMO_HOME/application.properties
@@ -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 @test --> <!-- @customizeConfigMap @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/patch.yaml cat <<EOF >$DEMO_HOME/patch.yaml
apiVersion: apps/v1beta2 apiVersion: apps/v1beta2
@@ -149,7 +149,7 @@ Arrange for the resources to begin with prefix
_prod-_ (since they are meant for the _production_ _prod-_ (since they are meant for the _production_
environment): environment):
<!-- @customizeLabel @test --> <!-- @customizeLabel @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
kustomize edit set nameprefix 'prod-' kustomize edit set nameprefix 'prod-'
@@ -165,7 +165,7 @@ This `namePrefix` directive adds _prod-_ to all
resource names, as can be seen by building the resource names, as can be seen by building the
resources: resources:
<!-- @build1 @test --> <!-- @build1 @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME | grep prod- kustomize build $DEMO_HOME | grep prod-
``` ```
@@ -180,7 +180,7 @@ selector.
add a label, but one can always edit add a label, but one can always edit
`kustomization.yaml` directly: `kustomization.yaml` directly:
<!-- @customizeLabels @test --> <!-- @customizeLabels @testAgainstLatestRelease -->
``` ```
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
commonLabels: commonLabels:
@@ -191,7 +191,7 @@ EOF
Confirm that the resources now all have names prefixed Confirm that the resources now all have names prefixed
by `prod-` and the label tuple `env:prod`: by `prod-` and the label tuple `env:prod`:
<!-- @build2 @test --> <!-- @build2 @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME | grep -C 3 env kustomize build $DEMO_HOME | grep -C 3 env
``` ```
@@ -205,7 +205,7 @@ set JVM options accordingly.
Download the patch `memorylimit_patch.yaml`. It contains the memory limits setup. Download the patch `memorylimit_patch.yaml`. It contains the memory limits setup.
<!-- @downloadPatch @test --> <!-- @downloadPatch @testAgainstLatestRelease -->
``` ```
curl -s -o "$DEMO_HOME/#1.yaml" \ curl -s -o "$DEMO_HOME/#1.yaml" \
"$CONTENT/overlays/production/{memorylimit_patch}.yaml" "$CONTENT/overlays/production/{memorylimit_patch}.yaml"
@@ -243,7 +243,7 @@ has end points such as `/actuator/health` for this. We can customize the k8s dep
Download the patch `healthcheck_patch.yaml`. It contains the liveness probes and readyness probes. Download the patch `healthcheck_patch.yaml`. It contains the liveness probes and readyness probes.
<!-- @downloadPatch @test --> <!-- @downloadPatch @testAgainstLatestRelease -->
``` ```
curl -s -o "$DEMO_HOME/#1.yaml" \ curl -s -o "$DEMO_HOME/#1.yaml" \
"$CONTENT/overlays/production/{healthcheck_patch}.yaml" "$CONTENT/overlays/production/{healthcheck_patch}.yaml"
@@ -281,7 +281,7 @@ The output contains
Add these patches to the kustomization: Add these patches to the kustomization:
<!-- @addPatch @test --> <!-- @addPatch @testAgainstLatestRelease -->
``` ```
cd $DEMO_HOME cd $DEMO_HOME
kustomize edit add patch memorylimit_patch.yaml kustomize edit add patch memorylimit_patch.yaml
@@ -301,7 +301,7 @@ The output of the following command can now be applied
to the cluster (i.e. piped to `kubectl apply`) to to the cluster (i.e. piped to `kubectl apply`) to
create the production environment. create the production environment.
<!-- @finalBuild @test --> <!-- @finalBuild @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME # | kubectl apply -f - kustomize build $DEMO_HOME # | kubectl apply -f -
``` ```

14
examples/transformerconfigs/crd/README.md
View File

@@ -3,7 +3,7 @@
This tutorial shows how to add transformer configurations to support a custom resource. This tutorial shows how to add transformer configurations to support a custom resource.
Create a workspace by Create a workspace by
<!-- @createws @test --> <!-- @createws @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -17,7 +17,7 @@ Consider a CRD of kind `MyKind` with fields
- `.spec.selectors` as the label selectors - `.spec.selectors` as the label selectors
Add the following file to configure the transformers for the above fields Add the following file to configure the transformers for the above fields
<!-- @addConfig @test --> <!-- @addConfig @testAgainstLatestRelease -->
``` ```
mkdir $DEMO_HOME/kustomizeconfig mkdir $DEMO_HOME/kustomizeconfig
cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -51,7 +51,7 @@ EOF
Create a file with some resources that Create a file with some resources that
includes an instance of `MyKind`: includes an instance of `MyKind`:
<!-- @createResource @test --> <!-- @createResource @testAgainstLatestRelease -->
``` ```
cat > $DEMO_HOME/resources.yaml << EOF cat > $DEMO_HOME/resources.yaml << EOF
apiVersion: v1 apiVersion: v1
@@ -88,7 +88,7 @@ EOF
Create a kustomization referring to it: Create a kustomization referring to it:
<!-- @createKustomization @test --> <!-- @createKustomization @testAgainstLatestRelease -->
``` ```
cat > $DEMO_HOME/kustomization.yaml << EOF cat > $DEMO_HOME/kustomization.yaml << EOF
resources: resources:
@@ -112,7 +112,7 @@ EOF
Use the customized transformer configurations by specifying them Use the customized transformer configurations by specifying them
in the kustomization file: in the kustomization file:
<!-- @addTransformerConfigs @test --> <!-- @addTransformerConfigs @testAgainstLatestRelease -->
``` ```
cat >> $DEMO_HOME/kustomization.yaml << EOF cat >> $DEMO_HOME/kustomization.yaml << EOF
configurations: configurations:
@@ -122,7 +122,7 @@ EOF
Run `kustomize build` and verify that the namereference is correctly resolved. Run `kustomize build` and verify that the namereference is correctly resolved.
<!-- @build @test --> <!-- @build @testAgainstLatestRelease -->
``` ```
test 2 == \ test 2 == \
$(kustomize build $DEMO_HOME | grep -A 2 ".*Ref" | grep "test-" | wc -l); \ $(kustomize build $DEMO_HOME | grep -A 2 ".*Ref" | grep "test-" | wc -l); \
@@ -131,7 +131,7 @@ echo $?
Run `kustomize build` and verify that the vars correctly resolved. Run `kustomize build` and verify that the vars correctly resolved.
<!-- @verify @test --> <!-- @verify @testAgainstLatestRelease -->
``` ```
test 0 == \ test 0 == \
$(kustomize build $DEMO_HOME | grep "BEE_ACTION" | wc -l); \ $(kustomize build $DEMO_HOME | grep "BEE_ACTION" | wc -l); \

18
examples/transformerconfigs/images/README.md
View File

@@ -3,7 +3,7 @@
This tutorial shows how to modify images in resources, and create a custom images transformer configuration. This tutorial shows how to modify images in resources, and create a custom images transformer configuration.
Create a workspace by Create a workspace by
<!-- @createws @test --> <!-- @createws @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -15,7 +15,7 @@ Consider a Custom Resource Definition(CRD) of kind `MyKind` with field
Add the following file to configure the images transformer for the CRD: Add the following file to configure the images transformer for the CRD:
<!-- @addConfig @test --> <!-- @addConfig @testAgainstLatestRelease -->
``` ```
mkdir $DEMO_HOME/kustomizeconfig mkdir $DEMO_HOME/kustomizeconfig
cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -30,7 +30,7 @@ EOF
Create a file with some resources that includes an instance of `MyKind`: Create a file with some resources that includes an instance of `MyKind`:
<!-- @createResource @test --> <!-- @createResource @testAgainstLatestRelease -->
``` ```
cat > $DEMO_HOME/resources.yaml << EOF cat > $DEMO_HOME/resources.yaml << EOF
@@ -66,7 +66,7 @@ EOF
Create a kustomization.yaml referring to it: Create a kustomization.yaml referring to it:
<!-- @createKustomization @test --> <!-- @createKustomization @testAgainstLatestRelease -->
``` ```
cat > $DEMO_HOME/kustomization.yaml << EOF cat > $DEMO_HOME/kustomization.yaml << EOF
resources: resources:
@@ -90,7 +90,7 @@ EOF
Use the customized transformer configurations by specifying them Use the customized transformer configurations by specifying them
in the kustomization file: in the kustomization file:
<!-- @addTransformerConfigs @test --> <!-- @addTransformerConfigs @testAgainstLatestRelease -->
``` ```
cat >> $DEMO_HOME/kustomization.yaml << EOF cat >> $DEMO_HOME/kustomization.yaml << EOF
configurations: configurations:
@@ -100,27 +100,27 @@ EOF
Run `kustomize build` and verify that the images have been updated. Run `kustomize build` and verify that the images have been updated.
<!-- @build @test --> <!-- @build @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-crd-image:new-v1-tag" | wc -l); \ $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-crd-image:new-v1-tag" | wc -l); \
echo $? echo $?
``` ```
<!-- @build @test --> <!-- @build @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-app-1:MYNEWTAG-1" | wc -l); \ $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-app-1:MYNEWTAG-1" | wc -l); \
echo $? echo $?
``` ```
<!-- @build @test --> <!-- @build @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "my-docker2@sha" | wc -l); \ $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "my-docker2@sha" | wc -l); \
echo $? echo $?
``` ```
<!-- @build @test --> <!-- @build @testAgainstLatestRelease -->
``` ```
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "prod-mysql:v3" | wc -l); \ $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "prod-mysql:v3" | wc -l); \

16
examples/validationTransformer/README.md
View File

@@ -24,7 +24,7 @@ loaded by Kustomize.
Make a place to work: Make a place to work:
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
mkdir -p $DEMO_HOME/valid mkdir -p $DEMO_HOME/valid
@@ -38,7 +38,7 @@ mkdir -p $PLUGINDIR
Download the [kubeval] binary depending on the operating system Download the [kubeval] binary depending on the operating system
and add it to $PATH. and add it to $PATH.
<!-- @downloadKubeval @test --> <!-- @downloadKubeval @testAgainstLatestRelease -->
``` ```
OS=`uname | sed -e 's/Linux/linux/' -e 's/Darwin/darwin/'` OS=`uname | sed -e 's/Linux/linux/' -e 's/Darwin/darwin/'`
wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-${OS}-amd64.tar.gz wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-${OS}-amd64.tar.gz
@@ -60,7 +60,7 @@ A transformer plugin for the validation can be written as a
bash script, which execute the [kubeval] binary and return proper bash script, which execute the [kubeval] binary and return proper
output and exit code. output and exit code.
<!-- @writePlugin @test --> <!-- @writePlugin @testAgainstLatestRelease -->
``` ```
cat <<'EOF' > $PLUGINDIR/Validator cat <<'EOF' > $PLUGINDIR/Validator
#!/bin/bash #!/bin/bash
@@ -95,7 +95,7 @@ chmod +x $PLUGINDIR/Validator
Define a kustomization containing a valid ConfigMap Define a kustomization containing a valid ConfigMap
and the transformer plugin. and the transformer plugin.
<!-- @writeKustomization @test --> <!-- @writeKustomization @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/valid/configmap.yaml cat <<'EOF' >$DEMO_HOME/valid/configmap.yaml
apiVersion: v1 apiVersion: v1
@@ -125,7 +125,7 @@ EOF
Define a kustomization containing an invalid ConfigMap Define a kustomization containing an invalid ConfigMap
and the transformer plugin. and the transformer plugin.
<!-- @writeKustomization @test --> <!-- @writeKustomization @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$DEMO_HOME/invalid/configmap.yaml cat <<'EOF' >$DEMO_HOME/invalid/configmap.yaml
apiVersion: v1 apiVersion: v1
@@ -175,7 +175,7 @@ The directory structure is as the following:
Define a helper function to run kustomize with the Define a helper function to run kustomize with the
correct environment and flags for plugins: correct environment and flags for plugins:
<!-- @defineKustomizeBd @test --> <!-- @defineKustomizeBd @testAgainstLatestRelease -->
``` ```
function kustomizeBd { function kustomizeBd {
XDG_CONFIG_HOME=$DEMO_HOME \ XDG_CONFIG_HOME=$DEMO_HOME \
@@ -187,7 +187,7 @@ function kustomizeBd {
Build the valid variant Build the valid variant
<!-- @buildValid @test --> <!-- @buildValid @testAgainstLatestRelease -->
``` ```
kustomizeBd valid kustomizeBd valid
``` ```
@@ -215,7 +215,7 @@ data: Invalid type. Expected: object, given: array
## cleanup ## cleanup
<!-- @cleanup @test --> <!-- @cleanup @testAgainstLatestRelease -->
```shell ```shell
rm -rf $DEMO_HOME rm -rf $DEMO_HOME
``` ```

14
examples/wordpress/README.md
View File

@@ -8,7 +8,7 @@ To run WordPress, it's necessary to
- access the service name of MySQL database from WordPress container - access the service name of MySQL database from WordPress container
First make a place to work: First make a place to work:
<!-- @makeDemoHome @test --> <!-- @makeDemoHome @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
MYSQL_HOME=$DEMO_HOME/mysql MYSQL_HOME=$DEMO_HOME/mysql
@@ -21,7 +21,7 @@ mkdir -p $WORDPRESS_HOME
Download the resources and `kustomization.yaml` for WordPress. Download the resources and `kustomization.yaml` for WordPress.
<!-- @downloadResources @test --> <!-- @downloadResources @testAgainstLatestRelease -->
``` ```
CONTENT="https://raw.githubusercontent.com\ CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\ /kubernetes-sigs/kustomize\
@@ -33,7 +33,7 @@ curl -s -o "$WORDPRESS_HOME/#1.yaml" \
Download the resources and `kustomization.yaml` for MySQL. Download the resources and `kustomization.yaml` for MySQL.
<!-- @downloadResources @test --> <!-- @downloadResources @testAgainstLatestRelease -->
``` ```
CONTENT="https://raw.githubusercontent.com\ CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\ /kubernetes-sigs/kustomize\
@@ -48,7 +48,7 @@ curl -s -o "$MYSQL_HOME/#1.yaml" \
Create a new kustomization with two bases, Create a new kustomization with two bases,
`wordpress` and `mysql`: `wordpress` and `mysql`:
<!-- @createKustomization @test --> <!-- @createKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$DEMO_HOME/kustomization.yaml cat <<EOF >$DEMO_HOME/kustomization.yaml
resources: resources:
@@ -65,7 +65,7 @@ In the new kustomization, apply a patch for wordpress deployment. The patch does
- Add an initial container to show the mysql service name - Add an initial container to show the mysql service name
- Add environment variable that allow wordpress to find the mysql database - Add environment variable that allow wordpress to find the mysql database
<!-- @downloadPatch @test --> <!-- @downloadPatch @testAgainstLatestRelease -->
``` ```
CONTENT="https://raw.githubusercontent.com\ CONTENT="https://raw.githubusercontent.com\
/kubernetes-sigs/kustomize\ /kubernetes-sigs/kustomize\
@@ -105,7 +105,7 @@ $(WORDPRESS_SERVICE) and $(MYSQL_SERVICE).
### Bind the Variables to k8s Object Fields ### Bind the Variables to k8s Object Fields
<!-- @addVarRef @test --> <!-- @addVarRef @testAgainstLatestRelease -->
``` ```
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
vars: vars:
@@ -128,7 +128,7 @@ EOF
### Substitution ### Substitution
Confirm the variable substitution: Confirm the variable substitution:
<!-- @kustomizeBuild @test --> <!-- @kustomizeBuild @testAgainstLatestRelease -->
``` ```
kustomize build $DEMO_HOME kustomize build $DEMO_HOME
``` ```

20
examples/zh/configGeneration.md
View File

@@ -30,7 +30,7 @@ kustomize 提供了两种添加 ConfigMap 的方法：
### 建立 base 和 staging ### 建立 base 和 staging
使用 configMapGenerator 建立 base 使用 configMapGenerator 建立 base
<!-- @establishBase @test --> <!-- @establishBase @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -57,7 +57,7 @@ EOF
``` ```
通过应用 ConfigMap patch 的方式建立 staging 通过应用 ConfigMap patch 的方式建立 staging
<!-- @establishStaging @test --> <!-- @establishStaging @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -93,7 +93,7 @@ EOF
deployment 按照名称引用此 ConfigMap ： deployment 按照名称引用此 ConfigMap ：
<!-- @showDeployment @test --> <!-- @showDeployment @testAgainstLatestRelease -->
``` ```
grep -C 2 configMapKeyRef $BASE/deployment.yaml grep -C 2 configMapKeyRef $BASE/deployment.yaml
``` ```
@@ -111,7 +111,7 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml
_staging_ 的 [variant] 包含一个 configMap 的 [patch]： _staging_ 的 [variant] 包含一个 configMap 的 [patch]：
<!-- @showMapPatch @test --> <!-- @showMapPatch @testAgainstLatestRelease -->
``` ```
cat $OVERLAYS/staging/map.yaml cat $OVERLAYS/staging/map.yaml
``` ```
@@ -120,7 +120,7 @@ cat $OVERLAYS/staging/map.yaml
在 ConfigMapGenerator 中声明 ConfigMap 的修改。 在 ConfigMapGenerator 中声明 ConfigMap 的修改。
<!-- @showMapBase @test --> <!-- @showMapBase @testAgainstLatestRelease -->
``` ```
grep -C 4 configMapGenerator $BASE/kustomization.yaml grep -C 4 configMapGenerator $BASE/kustomization.yaml
``` ```
@@ -129,7 +129,7 @@ grep -C 4 configMapGenerator $BASE/kustomization.yaml
但是，文件中指定的名称值不是群集中使用的名称值。根据设计，kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称，只需运行 kustomize： 但是，文件中指定的名称值不是群集中使用的名称值。根据设计，kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称，只需运行 kustomize：
<!-- @grepStagingName @test --> <!-- @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,14 +141,14 @@ kustomize build $OVERLAYS/staging |\
configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下，名称后缀是 _k25m8k5k5m_ ： configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下，名称后缀是 _k25m8k5k5m_ ：
<!-- @grepStagingHash @test --> <!-- @grepStagingHash @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging | grep k25m8k5k5m kustomize build $OVERLAYS/staging | grep k25m8k5k5m
``` ```
现在修改 map patch ，更改该服务将使用的问候消息： 现在修改 map patch ，更改该服务将使用的问候消息：
<!-- @changeMap @test --> <!-- @changeMap @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
``` ```
@@ -162,7 +162,7 @@ kustomize build $OVERLAYS/staging |\
再次运行 kustomize 查看新的 configMap 名称： 再次运行 kustomize 查看新的 configMap 名称：
<!-- @grepStagingName @test --> <!-- @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 +170,7 @@ kustomize build $OVERLAYS/staging |\
确认 configMap 内容的更改将会生成以 _cd7kdh48fd_ 结尾的三个新名称 - 一个在 configMap 的名称中，另两个在使用 ConfigMap 的 deployment 中： 确认 configMap 内容的更改将会生成以 _cd7kdh48fd_ 结尾的三个新名称 - 一个在 configMap 的名称中，另两个在使用 ConfigMap 的 deployment 中：
<!-- @countHashes @test --> <!-- @countHashes @testAgainstLatestRelease -->
``` ```
test 3 == \ test 3 == \
$(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \ $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \

30
examples/zh/helloWorld.md
View File

@@ -21,7 +21,7 @@
首先创建一个工作空间： 首先创建一个工作空间：
<!-- @makeWorkplace @test --> <!-- @makeWorkplace @testAgainstLatestRelease -->
``` ```
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
``` ```
@@ -38,7 +38,7 @@ DEMO_HOME=$(mktemp -d)
为了使本文档保持简洁，base 的资源位于补充目录中，并不在此处，请按照下面的方法下载它们： 为了使本文档保持简洁，base 的资源位于补充目录中，并不在此处，请按照下面的方法下载它们：
<!-- @downloadBase @test --> <!-- @downloadBase @testAgainstLatestRelease -->
``` ```
BASE=$DEMO_HOME/base BASE=$DEMO_HOME/base
mkdir -p $BASE mkdir -p $BASE
@@ -51,7 +51,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\
观察该目录： 观察该目录：
<!-- @runTree @test --> <!-- @runTree @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -80,14 +80,14 @@ tree $DEMO_HOME
`base` 目录中包含一个 [kustomization] 文件： `base` 目录中包含一个 [kustomization] 文件：
<!-- @showKustomization @test --> <!-- @showKustomization @testAgainstLatestRelease -->
``` ```
more $BASE/kustomization.yaml more $BASE/kustomization.yaml
``` ```
（可选）在 base 目录上运行 `kustomize` 将定制过的 resources 打印到标准输出： （可选）在 base 目录上运行 `kustomize` 将定制过的 resources 打印到标准输出：
<!-- @buildBase @test --> <!-- @buildBase @testAgainstLatestRelease -->
``` ```
kustomize build $BASE kustomize build $BASE
``` ```
@@ -96,14 +96,14 @@ kustomize build $BASE
定制 _app label_ 并应用于所有的 resources ： 定制 _app label_ 并应用于所有的 resources ：
<!-- @addLabel @test --> <!-- @addLabel @testAgainstLatestRelease -->
``` ```
sed -i.bak 's/app: hello/app: my-hello/' \ sed -i.bak 's/app: hello/app: my-hello/' \
$BASE/kustomization.yaml $BASE/kustomization.yaml
``` ```
查看效果： 查看效果：
<!-- @checkLabel @test --> <!-- @checkLabel @testAgainstLatestRelease -->
``` ```
kustomize build $BASE | grep -C 3 app: kustomize build $BASE | grep -C 3 app:
``` ```
@@ -116,7 +116,7 @@ kustomize build $BASE | grep -C 3 app:
* _Production_ 包含更多的副本数。 * _Production_ 包含更多的副本数。
* 来自这些集群 [variants] 的问候消息将与来自其他集群的不同。 * 来自这些集群 [variants] 的问候消息将与来自其他集群的不同。
<!-- @overlayDirectories @test --> <!-- @overlayDirectories @testAgainstLatestRelease -->
``` ```
OVERLAYS=$DEMO_HOME/overlays OVERLAYS=$DEMO_HOME/overlays
mkdir -p $OVERLAYS/staging mkdir -p $OVERLAYS/staging
@@ -127,7 +127,7 @@ mkdir -p $OVERLAYS/production
在 `staging` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和一些不同的 labels 。 在 `staging` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和一些不同的 labels 。
<!-- @makeStagingKustomization @test --> <!-- @makeStagingKustomization @testAgainstLatestRelease -->
``` ```
cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
namePrefix: staging- namePrefix: staging-
@@ -149,7 +149,7 @@ EOF
同时，将 _risky_ 标记设置为 true 。 同时，将 _risky_ 标记设置为 true 。
<!-- @stagingMap @test --> <!-- @stagingMap @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/staging/map.yaml cat <<EOF >$OVERLAYS/staging/map.yaml
apiVersion: v1 apiVersion: v1
@@ -166,7 +166,7 @@ EOF
在 `production` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和 labels 。 在 `production` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和 labels 。
<!-- @makeProductionKustomization @test --> <!-- @makeProductionKustomization @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/production/kustomization.yaml cat <<EOF >$OVERLAYS/production/kustomization.yaml
namePrefix: production- namePrefix: production-
@@ -187,7 +187,7 @@ EOF
因为生产环境需要处理更多的流量，新建一个 production patch 来增加副本数。 因为生产环境需要处理更多的流量，新建一个 production patch 来增加副本数。
<!-- @productionDeployment @test --> <!-- @productionDeployment @testAgainstLatestRelease -->
``` ```
cat <<EOF >$OVERLAYS/production/deployment.yaml cat <<EOF >$OVERLAYS/production/deployment.yaml
apiVersion: apps/v1 apiVersion: apps/v1
@@ -210,7 +210,7 @@ EOF
查看目录结构和差异： 查看目录结构和差异：
<!-- @listFiles @test --> <!-- @listFiles @testAgainstLatestRelease -->
``` ```
tree $DEMO_HOME tree $DEMO_HOME
``` ```
@@ -268,12 +268,12 @@ diff \
输出不同 _overlys_ 的配置： 输出不同 _overlys_ 的配置：
<!-- @buildStaging @test --> <!-- @buildStaging @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/staging kustomize build $OVERLAYS/staging
``` ```
<!-- @buildProduction @test --> <!-- @buildProduction @testAgainstLatestRelease -->
``` ```
kustomize build $OVERLAYS/production kustomize build $OVERLAYS/production
``` ```

16
examples/zh/jsonpatch.md
View File

@@ -6,7 +6,7 @@ kustomization文件支持通过[JSON patches](https://tools.ietf.org/html/rfc690
首先，创建一个包含`ingress`的`kustomization`文件. 首先，创建一个包含`ingress`的`kustomization`文件.
<!-- @createIngress @test --> <!-- @createIngress @testAgainstLatestRelease -->
```bash ```bash
DEMO_HOME=$(mktemp -d) DEMO_HOME=$(mktemp -d)
@@ -36,7 +36,7 @@ EOF
- 把 host 从 `foo.bar.com` 改为 `foo.bar.io` - 把 host 从 `foo.bar.com` 改为 `foo.bar.io`
- 把 servicePort 从 `80` 改为 `8080` - 把 servicePort 从 `80` 改为 `8080`
<!-- @addJsonPatch @test --> <!-- @addJsonPatch @testAgainstLatestRelease -->
```bash ```bash
cat <<EOF >$DEMO_HOME/ingress_patch.json cat <<EOF >$DEMO_HOME/ingress_patch.json
[ [
@@ -48,7 +48,7 @@ EOF
JSON patch 也可以写成 YAML 的格式.该例子顺便展示了“添加”操作： JSON patch 也可以写成 YAML 的格式.该例子顺便展示了“添加”操作：
<!-- @addYamlPatch @test --> <!-- @addYamlPatch @testAgainstLatestRelease -->
```bash ```bash
cat <<EOF >$DEMO_HOME/ingress_patch.yaml cat <<EOF >$DEMO_HOME/ingress_patch.yaml
- op: replace - op: replace
@@ -67,7 +67,7 @@ EOF
在kustomization.yaml文件中增加 _patchesJson6902_ 字段，以应用该补丁 在kustomization.yaml文件中增加 _patchesJson6902_ 字段，以应用该补丁
<!-- @applyJsonPatch @test --> <!-- @applyJsonPatch @testAgainstLatestRelease -->
```bash ```bash
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
patchesJson6902: patchesJson6902:
@@ -82,7 +82,7 @@ EOF
运行 `kustomize build $DEMO_HOME`, 在输出那里确认 host 已经被正确更新. 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 host 已经被正确更新.
<!-- @confirmHost @test --> <!-- @confirmHost @testAgainstLatestRelease -->
```bash ```bash
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \ $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
@@ -91,7 +91,7 @@ test 1 == \
运行 `kustomize build $DEMO_HOME`, 在输出那里确认 servicePort 已经被正确更新. 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 servicePort 已经被正确更新.
<!-- @confirmServicePort @test --> <!-- @confirmServicePort @testAgainstLatestRelease -->
```bash ```bash
test 1 == \ test 1 == \
@@ -101,7 +101,7 @@ test 1 == \
如果 patch 是YAML格式的，就能正确解析: 如果 patch 是YAML格式的，就能正确解析:
<!-- @applyYamlPatch @test --> <!-- @applyYamlPatch @testAgainstLatestRelease -->
```bash ```bash
cat <<EOF >>$DEMO_HOME/kustomization.yaml cat <<EOF >>$DEMO_HOME/kustomization.yaml
patchesJson6902: patchesJson6902:
@@ -116,7 +116,7 @@ EOF
运行 `kustomize build $DEMO_HOME`, 在输出那里确认有 `/test` 这个路径. 运行 `kustomize build $DEMO_HOME`, 在输出那里确认有 `/test` 这个路径.
<!-- @confirmYamlPatch @test --> <!-- @confirmYamlPatch @testAgainstLatestRelease -->
```bash ```bash
test 1 == \ test 1 == \
$(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \ $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \

71
travis/pre-commit.sh
View File

@@ -21,33 +21,64 @@ function runFunc {
if [ $code -ne 0 ]; then if [ $code -ne 0 ]; then
result="FAILURE" result="FAILURE"
fi fi
printf "============== end %s : %s code=%d\n\n\n" "$name" "$result" $code printf "============== end %s : %s; exit code=%d\n\n\n" "$name" "$result" $code
} }
function testGoLangCILint { function testGoLangCILint {
golangci-lint run ./... golangci-lint run ./...
} }
function testGoTest { function testGoTests {
go test -v ./... go test -v ./...
}
# These tests require the helm program, and at the moment if [ -z ${TRAVIS+x} ]; then
# we're not asking travis to install helm. echo " "
function testNoTravisGoTest { echo Not on travis, so running the notravis Go tests
go test -v sigs.k8s.io/kustomize/v3/pkg/target \ echo " "
# Requires helm.
# At the moment not asking travis to install it.
go test -v sigs.k8s.io/kustomize/v3/pkg/target \
-run TestChartInflatorPlugin -tags=notravis -run TestChartInflatorPlugin -tags=notravis
go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \ go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \
-run TestChartInflator -tags=notravis -run TestChartInflator -tags=notravis
mdrip --mode test --label helmtest README.md ./examples/chart.md
go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \ # Requires kubeeval.
# At the moment not asking travis to install it.
go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
-run TestValidatorHappy -tags=notravis -run TestValidatorHappy -tags=notravis
go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \ go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
-run TestValidatorUnHappy -tags=notravis -run TestValidatorUnHappy -tags=notravis
fi
} }
function testExamples { function testExamplesAgainstLatestRelease {
mdrip --mode test --label test README.md ./examples /bin/rm -f $HOME/go/bin/kustomize
# Install latest release.
go get sigs.k8s.io/kustomize/v3/cmd/kustomize
PATH=$HOME/go/bin:$PATH \
mdrip --mode test --label testAgainstLatestRelease ./examples
if [ -z ${TRAVIS+x} ]; then
echo " "
echo Not on travis, so running the notravis example tests
echo " "
# Requires helm. At the moment not asking travis to install it.
PATH=$HOME/go/bin:$PATH \
mdrip --mode test --label helmtest README.md ./examples/chart.md
fi
}
function testExamplesAgainstHead {
/bin/rm -f $HOME/go/bin/kustomize
# Install from head.
go install sigs.k8s.io/kustomize/v3/cmd/kustomize
# To test examples of unreleased features, add
# examples with code blocks annotated with some
# label _other than_ @testAgainstLatestRelease.
PATH=$HOME/go/bin:$PATH \
mdrip --mode test --label testAgainstLatestRelease ./examples
} }
function generateCode { function generateCode {
@@ -100,15 +131,9 @@ echo "Working..."
runFunc generateCode runFunc generateCode
runFunc testGoLangCILint runFunc testGoLangCILint
runFunc testGoTest runFunc testGoTests
runFunc testExamplesAgainstLatestRelease
if [ -z ${TRAVIS+x} ]; then runFunc testExamplesAgainstHead
echo Not on travis, so running the notravis tests
runFunc testNoTravisGoTest
fi
PATH=$HOME/go/bin:$PATH
runFunc testExamples
if [ $rc -eq 0 ]; then if [ $rc -eq 0 ]; then
echo "SUCCESS!" echo "SUCCESS!"