<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>

CC BY-SA 4.0
2018-05-29T18:47:48.107Z
2018-05-29T18:47:48.107Z
Levi
<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>

CC BY-SA 3.0
2018-04-26T20:22:46.767Z
2018-04-26T20:36:52.340Z
2018-04-26T20:36:52.340Z
030
<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>

CC BY-SA 4.0
2019-12-23T08:47:38.527Z
Could you indicate whether you solved the issue?
030
<kubernetes><microservices><architecture><nginx><ingress>
How to add rules to Kubernetes NGINX Ingress controller from different yml definitions?
hofnarwillie
# 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.
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
              }
            }
          ]
        }
      }
    ]
  }
}

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.


---

### 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:
  
  
  and so on and so on

and run kubectl replace -f once the snippet of a microservice has been deployed.


---

