kustomize: are simple variable substitutions supported?

[oliver...@braintribe.com]

I recently discovered the kustomize project, and hope that it could replace our make/sed combination. So far I had success with it for the most part.

One thing that I'm missing (or did not find documentation on) is how to do simple variable substitution. For example, given the following ingress definition:

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

  name: tf-flow

spec:

  rules:

    - host: tf-flow.@@DOMAIN@@

      http:

        paths:

          - backend:

              serviceName: scdf-server

              servicePort: 80

            path: /

At the moment I use sed to replace the @@DOMAIN@@ placeholder with a concrete value, and I would like to utilize kustomize for that. Is that something that can be done with kustomize?

thanks!

[Antoine Pelisse]

Hey Oliver,

Can you tell us more about what you're trying to do? How many instances of this ingress do yo have? What is the reason for using sed rather than hard-coding the specific values?

Thanks,

Antoine

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/32920477-6d1a-4199-a10b-78f713c8e874%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[oliver...@braintribe.com]

Hi Antoine

On Monday, July 9, 2018 at 11:20:40 PM UTC+2, Antoine Pelisse wrote:

Hey Oliver,

Can you tell us more about what you're trying to do? How many instances of this ingress do yo have? What is the reason for using sed rather than hard-coding the specific values?

In general, I wanted to replace my make/sed based approach to generalizing Kubernetes manifests with kustomize. I'm especially happy about the overlay concept, which fits my needs pretty well.

In this particular case, I have a set of manifests that describe a Spring Cloud Data Flow deployment. Those deployments will be per client, and each client can have dev/stage/production stages. The entrypoints are specific URLs which are handled and routed by the ingress, and for each client/stage combination there is a particular URL similar to this:

client1:
  dev: dev.tf-flow.client1.mydomain.com
  test: test.tf-flow.client1.mydomain.com

client2:
  dev: dev.tf-flow.client2.mydomain.com
  test: test.tf-flow.client2.mydomain.com

And the placeholder version of this would look like this:

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

 name: tf-flow

spec:

  rules:

   - host: @@STAGE@@.tf-flow.@@DOMAIN@@

     http:

       paths:

         - backend:

             serviceName: scdf-server

             servicePort: 80

           path: /

I usally have a sed that looks like this

sed 's|@@STAGE@@|$(STAGE)|g' ingress.yaml | sed 's|@@DOMAIN@@|$(DOMAIN)|g' | kubectl apply -f -

In this particular case, of course, it could also just be the full URL:

apiVersion: extensions/v1beta1

kind: Ingress

metadata:

name: tf-flow

spec:

  rules:

  - host: @@HOST@@

    http:

      paths:

        - backend:

            serviceName: scdf-server

            servicePort: 80

          path: /

So, in the snippet above, would that be doable with kustomize?

Thanks!

Oliver 

[Antoine Pelisse]

I don't think kustomize supports templates nor will it ever support

them. How many "clients" do you have? Would it be reasonable to have one

directory for each client/stage? I think the kustomize pattern would be to

"sed and replace/commit/apply" rather than "commit/sed and

replace/apply". It also makes individual client customization

simpler. If it's unreasonable to have one configuration committed

per client (either because the list of clients is coming from a

dynamic-set/database or because you have thousands), then it's 

also reasonable to have ksonnet on top of kustomize.

Hope this helps,

Antoine

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/1f80cf3e-ba02-46cf-a7de-0d14cecb4bd6%40googlegroups.com.

[Daniel Smith]

FWIW I found a similar use case, which is using the same image in multiple containers in a pod. It's a pain to change the image N times in an overlay just to update the version.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/CAL7Ftgvv08UGkMRk%2BTKZXaosO%3DZQTBHo8OtX9YB2w0YMm_0wbA%40mail.gmail.com.

[jingf...@google.com]

Daniel, recently kustomize added a new feature to support changing image tags by adding 

imageTags:

  -name: some/repo/myimage

   newTag: my.new.tag

checkout the example here https://github.com/kubernetes-sigs/kustomize/blob/master/examples/imageTags.md

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cli+unsub...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/1f80cf3e-ba02-46cf-a7de-0d14cecb4bd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cli+unsub...@googlegroups.com.

[Brian Grant]

What about support for digests?

https://github.com/kubernetes/kubernetes/issues/1697#issuecomment-320115359

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/1f80cf3e-ba02-46cf-a7de-0d14cecb4bd6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/CAL7Ftgvv08UGkMRk%2BTKZXaosO%3DZQTBHo8OtX9YB2w0YMm_0wbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.

To post to this group, send email to kubernete...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/93372602-a157-4149-8c8c-9df282c7c417%40googlegroups.com.

[Jingfang Liu]

digests are not supported. We haven't seen requests for that from Kustomize users.

If we need this feature, I can see the format of specifying a new digest should be similar to newTag.

[Brian Grant]

What people have asked for is rolling update at the same tag:

https://github.com/kubernetes/kubernetes/issues/33664

Digest is the right way to support that.

[Jingfang Liu]

Just finished reading the long discussion in the issue https://github.com/kubernetes/kubernetes/issues/33664 and got some understanding of the context.

People who want the rolling update at the same tag seems to have different workarounds. Replacing tags by digests are also provided by some platforms, such as Openshift.

if we want Kustomize to support that, it can be done through an extra transformation with steps as talking to image registry, getting the digest and replacing the tag. However, I am hesitated to go that way. Since it will add external dependency to Kustomize. It will also make the configuration not fully determined until one runs `kustomize build`.  +Jeffrey Regan  What do you think about this?

For the original Ingress sed problem, there is a feature request which can help. https://github.com/kubernetes-sigs/kustomize/issues/169