Answers: <p>My suggestion is &quot;use <a href="https://kustomize.io" rel="nofollow noreferrer">kustomize</a>&quot;, and then create a development overlay that overrides the images. Using the <a href="https://github.com/kubernetes-sigs/kustomize/blob/master/examples/transformerconfigs/README.md#images-transformer" rel="nofollow noreferrer">image transformer</a>, you would end up with something like:</p>
  <pre><code># This assumes that your deployment manifests are all locaed in the
  # directory ../production. What we're doing here is including all
  # of those manifests and then applying some transformations.
  resources:
    - ../production/
  
  images:
    - name: appimage
      newName: local_repo_url/appimage
  </code></pre>
  <p>This would replace all references to an image named <code>appimage</code> (in Pods, Deployments, Statefulsets, Daemonsets, Jobs, etc) with <code>local_repo_url/appimage</code>. You can also transform the tag, etc.</p>
  <p>I really like working with kustomize (I use it both for work and personal projects), but it does require to be disciplined with respect to how you lay out your manifests.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-01-05T09:27:02.687Z
Answers: Interesting. I'm not very familiar with kustomize, so let me give it a go.
Answers: Software Engineer
Answers: CC BY-SA 4.0
Answers: 2023-01-04T17:46:42.937Z
Answers: 2023-01-04T17:46:42.937Z
Answers: larsks
Body: <p>My teams develop on their laptops (using the wonderful K3D) with a local repo. But, the test and prod environments are in Azure. Locally we configure a docker image repository (using k3d), and in Azure we use ACR. My teams' internet connections are flakey at best, so we cannot all be online all the time.</p>
  <p>Currently, I use an environment variable to manage this. In my k8s config files I use the env-var name template pattern:</p>
  <pre class="lang-yaml prettyprint-override"><code>image: $K8S_REPO_URL/dev/tenants
  </code></pre>
  <p>In my makefile I have this:</p>
  <pre><code>@cat k8s.yaml | envsubst | sed &quot;$$CERT&quot; | kubectl apply -f -
  </code></pre>
  <p>Which substitutes the current variable value into the k8s file before applying it to k8s. I use the same pattern in my azure clusters (with Tekton) where I configure the tekton pod with env-vars that are populated from a config map.</p>
  <p>This means that I can use the local registry when working locally and I can use ACR when running in azure, and the only change is in the environment.</p>
  <p>I think this is quite 'linuxy' and it works, though it does have its flaws (it's quite easy to make a frustrating but non-fatal mistake by not sourcing the correct environment before one begins development). And, the registry isn't the only difference (it's just the one I'm using here); we also have differences with certs (prod is all tls, dev is no tls), and ingress-class (nginx <code>locally</code>, <code>addon-http-application-routing</code> in azure), which has led to some more complex processing before applying my configs in places.</p>
  <p>I'm worried that this is becoming too complicated. It's just about manageable right now, but if I add a couple more environment-based differences it'll start getting out of hand. Does anyone have a better suggestion that isn't &quot;Use Helm&quot;? I'm not opposed to helm at all, it's just that I already know that I should be using helm but it seems like such a heavyweight solution to simply swapping a couple of strings and deleting a line or two.</p>
  
Tags: <kubernetes><environments>
Title: Local dev, online test/prod - best approach?
UserDisplayName: Software Engineer
ThreadText: # Local dev, online test/prod - best approach?
  
  (Asked by: username_0 on 2023-01-02)
  
  My teams develop on their laptops (using the wonderful K3D) with a local repo. But, the test and prod environments are in Azure. Locally we configure a docker image repository (using k3d), and in Azure we use ACR. My teams' internet connections are flakey at best, so we cannot all be online all the time.
  
  Currently, I use an environment variable to manage this. In my k8s config files I use the env-var name template pattern:
  
  ```yaml
  image: $K8S_REPO_URL/dev/tenants
  
  ```
  
  In my makefile I have this:
  
  ```
  @cat k8s.yaml | envsubst | sed "$$CERT" | kubectl apply -f -
  
  ```
  
  Which substitutes the current variable value into the k8s file before applying it to k8s. I use the same pattern in my azure clusters (with Tekton) where I configure the tekton pod with env-vars that are populated from a config map.
  
  This means that I can use the local registry when working locally and I can use ACR when running in azure, and the only change is in the environment.
  
  I think this is quite 'linuxy' and it works, though it does have its flaws (it's quite easy to make a frustrating but non-fatal mistake by not sourcing the correct environment before one begins development). And, the registry isn't the only difference (it's just the one I'm using here); we also have differences with certs (prod is all tls, dev is no tls), and ingress-class (nginx `locally`, `addon-http-application-routing` in azure), which has led to some more complex processing before applying my configs in places.
  
  I'm worried that this is becoming too complicated. It's just about manageable right now, but if I add a couple more environment-based differences it'll start getting out of hand. Does anyone have a better suggestion that isn't "Use Helm"? I'm not opposed to helm at all, it's just that I already know that I should be using helm but it seems like such a heavyweight solution to simply swapping a couple of strings and deleting a line or two.
  
  **Tags:** kubernetes, environments
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-01-04. Score: 0
  
  My suggestion is "use [kustomize](https://kustomize.io)", and then create a development overlay that overrides the images. Using the [image transformer](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/transformerconfigs/README.md#images-transformer), you would end up with something like:
  
  ```
  # This assumes that your deployment manifests are all locaed in the
  # directory ../production. What we're doing here is including all
  # of those manifests and then applying some transformations.
  resources:
    - ../production/
  
  images:
    - name: appimage
      newName: local_repo_url/appimage
  
  ```
  
  This would replace all references to an image named `appimage` (in Pods, Deployments, Statefulsets, Daemonsets, Jobs, etc) with `local_repo_url/appimage`. You can also transform the tag, etc.
  
  I really like working with kustomize (I use it both for work and personal projects), but it does require to be disciplined with respect to how you lay out your manifests.
  
  > **Comments:**
  > **username_0**: Interesting. I'm not very familiar with kustomize, so let me give it a go.  
  
  ---
  
  