Answers: <p>I was able to combine your two example files by first converting them to JSON. </p>
  
  <p><strong>foo.json</strong></p>
  
  <pre><code>{
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "foo.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "foo.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "foo-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "foo-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  </code></pre>
  
  <p><strong>baz.json</strong></p>
  
  <pre><code>{
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "baz.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "baz.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "baz-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "baz-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  </code></pre>
  
  <p>You can then combine the rules for each by using <a href="https://stedolan.github.io/jq/" rel="nofollow noreferrer">jq</a>.</p>
  
  <pre><code>levi@La-Tower:~$ jq 'reduce inputs as $i (.; .spec.rules += $i.spec.rules)' foo.json baz.json
  {
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "foo.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "foo.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "foo-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "foo-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        },
        {
          "host": "baz.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "baz-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "baz-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  </code></pre>
  
  <p>While yaml is more common JSON is perfectly valid for the Kubernetes API. All credit for the jq logic goes to @Jeff Mercado and his <a href="https://stackoverflow.com/questions/42011086/merge-arrays-of-json">answer</a>.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-29T18:47:48.107Z
Answers: 2018-05-29T18:47:48.107Z
Answers: Levi
Answers: <blockquote>
    <p>Could I have these two different definitions which creates a single
    Ingress with two rules (based on having the same name)?</p>
  </blockquote>
  
  <p>Lets investigate whether that would be possible.</p>
  
  <p>According to</p>
  
  <p><a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/ingress/</a></p>
  
  <p>one could update an existing ingress yaml and subsequently run <code>kubectl replace -f</code>. From a microservice perspective, one could store a snippet in every git repo, e.g.:</p>
  
  <pre><code>- host: microservice01.domain.com
    http:
      paths:
      - backend:
          serviceName: ms01
          servicePort: 80
        path: /microservice01
  </code></pre>
  
  <p>and deploy it manually or automatically using ssh and merge it with another ingress file that has already been deployed</p>
  
  <pre><code>spec:
    rules:
    &lt;concatenate snippet1&gt;
    &lt;concatenate snippet2&gt;
    and so on and so on
  </code></pre>
  
  <p>and run <code>kubectl replace -f</code> once the snippet of a microservice has been deployed.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-26T20:22:46.767Z
Answers: 2018-04-26T20:36:52.340Z
Answers: 2018-04-26T20:36:52.340Z
Answers: 030
Body: <p>I'm trying to implement a Kubernetes cluster with a fanout pattern using an NGINX Ingress which routes traffic on multiple different hosts and paths to different microservices. The code for each microservice is hosted in their own Git repo, including the kubernetes definition yml files which deploys the pods (Deployment) and services for each service respectively.</p>
  
  <p>Considering that there will be a single Ingress which routes traffic to all the different Services, where (by convention or industry standard) should the definition file be stored? I would like to keep the Ingress rules related to a single microservice in the git repo where the rest of the code is. I don't particularly want a separate git repo just for the Ingress.</p>
  
  <p>Is it possible to define only a subset of an Ingress' rules in a file which would then get "appended" to the list of rules instead of overwriting them.</p>
  
  <p>For example, could I have these two different definitions which creates a single Ingress with two rules (based on having the same name):</p>
  
  <p><strong>foo-ingress-rules.yml</strong></p>
  
  <pre><code>apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: nginx-ingress
  spec:
    tls:
      - hosts:
        - foo.bar.com
        secretName: tls-secret
    rules:
      - host: foo.bar.com
        http:
          paths:
          - path: /
            backend:
              serviceName: foo-web-svc
              servicePort: 80
          - path: /api
            backend:
              serviceName: foo-rest-svc
              servicePort: 80
  </code></pre>
  
  <p><strong>baz-ingress-rules.yml</strong></p>
  
  <pre><code>apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: nginx-ingress
  spec:
    tls:
      - hosts:
        - baz.bar.com
        secretName: tls-secret
    rules:
      - host: baz.bar.com
        http:
          paths:
          - path: /
            backend:
              serviceName: baz-web-svc
              servicePort: 80
          - path: /api
            backend:
              serviceName: baz-rest-svc
              servicePort: 80
  </code></pre>
  
Comments: CC BY-SA 4.0
Comments: 2019-12-23T08:47:38.527Z
Comments: Could you indicate whether you solved the issue?
Comments: 030
Tags: <kubernetes><microservices><architecture><nginx><ingress>
Title: How to add rules to Kubernetes NGINX Ingress controller from different yml definitions?
UserDisplayName: hofnarwillie
ThreadText: # How to add rules to Kubernetes NGINX Ingress controller from different yml definitions?
  
  (Asked by: username_0 on 2018-04-24)
  
  I'm trying to implement a Kubernetes cluster with a fanout pattern using an NGINX Ingress which routes traffic on multiple different hosts and paths to different microservices. The code for each microservice is hosted in their own Git repo, including the kubernetes definition yml files which deploys the pods (Deployment) and services for each service respectively.
  
  Considering that there will be a single Ingress which routes traffic to all the different Services, where (by convention or industry standard) should the definition file be stored? I would like to keep the Ingress rules related to a single microservice in the git repo where the rest of the code is. I don't particularly want a separate git repo just for the Ingress.
  
  Is it possible to define only a subset of an Ingress' rules in a file which would then get "appended" to the list of rules instead of overwriting them.
  
  For example, could I have these two different definitions which creates a single Ingress with two rules (based on having the same name):
  
  **foo-ingress-rules.yml**
  
  ```
  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: nginx-ingress
  spec:
    tls:
      - hosts:
        - foo.bar.com
        secretName: tls-secret
    rules:
      - host: foo.bar.com
        http:
          paths:
          - path: /
            backend:
              serviceName: foo-web-svc
              servicePort: 80
          - path: /api
            backend:
              serviceName: foo-rest-svc
              servicePort: 80
  
  ```
  
  **baz-ingress-rules.yml**
  
  ```
  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: nginx-ingress
  spec:
    tls:
      - hosts:
        - baz.bar.com
        secretName: tls-secret
    rules:
      - host: baz.bar.com
        http:
          paths:
          - path: /
            backend:
              serviceName: baz-web-svc
              servicePort: 80
          - path: /api
            backend:
              serviceName: baz-rest-svc
              servicePort: 80
  
  ```
  
  **Tags:** kubernetes, microservices, architecture, nginx, ingress
  
  > **Comments:**
  > **username_1**: Could you indicate whether you solved the issue?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-05-29. Score: 2
  
  I was able to combine your two example files by first converting them to JSON.
  
  **foo.json**
  
  ```
  {
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "foo.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "foo.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "foo-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "foo-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  
  ```
  
  **baz.json**
  
  ```
  {
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "baz.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "baz.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "baz-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "baz-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  
  ```
  
  You can then combine the rules for each by using [jq](https://stedolan.github.io/jq/).
  
  ```
  username_2@La-Tower:~$ jq 'reduce inputs as $i (.; .spec.rules += $i.spec.rules)' foo.json baz.json
  {
    "apiVersion": "extensions/v1beta1",
    "kind": "Ingress",
    "metadata": {
      "name": "nginx-ingress"
    },
    "spec": {
      "tls": [
        {
          "hosts": [
            "foo.bar.com"
          ],
          "secretName": "tls-secret"
        }
      ],
      "rules": [
        {
          "host": "foo.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "foo-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "foo-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        },
        {
          "host": "baz.bar.com",
          "http": {
            "paths": [
              {
                "path": "/",
                "backend": {
                  "serviceName": "baz-web-svc",
                  "servicePort": 80
                }
              },
              {
                "path": "/api",
                "backend": {
                  "serviceName": "baz-rest-svc",
                  "servicePort": 80
                }
              }
            ]
          }
        }
      ]
    }
  }
  
  ```
  
  While yaml is more common JSON is perfectly valid for the Kubernetes API. All credit for the jq logic goes to @Jeff Mercado and his [answer](https://stackoverflow.com/questions/42011086/merge-arrays-of-json).
  
  
  ---
  
  ### Answer by username_1 on 2018-04-26. Score: 1
  
  > Could I have these two different definitions which creates a single
  > Ingress with two rules (based on having the same name)?
  
  Lets investigate whether that would be possible.
  
  According to
  
  <https://kubernetes.io/docs/concepts/services-networking/ingress/>
  
  one could update an existing ingress yaml and subsequently run `kubectl replace -f`. From a microservice perspective, one could store a snippet in every git repo, e.g.:
  
  ```
  - host: microservice01.domain.com
    http:
      paths:
      - backend:
          serviceName: ms01
          servicePort: 80
        path: /microservice01
  
  ```
  
  and deploy it manually or automatically using ssh and merge it with another ingress file that has already been deployed
  
  ```
  spec:
    rules:
    <concatenate snippet1>
    <concatenate snippet2>
    and so on and so on
  
  ```
  
  and run `kubectl replace -f` once the snippet of a microservice has been deployed.
  
  
  ---
  
  