Answers: <p>Kubernetes ingress is implemented by changing the configuration of another container or the cloud load balancer to route traffic to the service port/ip. Docker by itself is fairly lightweight, only runs the containers you start, and does not have external dependencies on things like your cloud load balancer. The solutions to setup a reverse proxy inside a container are almost identical to the kubernetes nginx based ingress controllers, with the key difference being the configuration of that reverse proxy.</p>
  
  <p>There are a variety of docker based reverse proxies that configure themselves, including docker-flow-proxy, nginx-proxy, and Docker-EE ships with interlock that configures HA proxy. Probably the easies solution I've seen to implement is traefik which can be configured to monitor the docker socket for changes and automatically reconfigure based on labels set on your containers.</p>
  
  <p>One important difference from Kubernetes is that docker networks are not flat, you will need to explicitly place the proxy container on the same docker network as your application in order for them to be able to route traffic between each other.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-04-17T12:33:12.130Z
Answers: 2019-04-17T12:33:12.130Z
Answers: BMitch
Answers: <p><a href="https://github.com/nginx-proxy/nginx-proxy/issues/1783" rel="nofollow noreferrer"><code>jwilder/nginx-proxy</code></a> image simulates that excatly.
  Use VIRTUAL_HOST &amp; VIRTUAL_PATH env vars in the backend containers.</p>
  <p>example:</p>
  <pre><code>version: '3.4'
  
  services:
    ingress:
      image: jwilder/nginx-proxy
      ports:
        - &quot;80:80&quot;
      volumes:
        - /var/run/docker.sock:/tmp/docker.sock:ro
  
    frontend:
      image: nginx:1.16
      ports:
        - &quot;81:80&quot;
      environment:
        - VIRTUAL_HOST=test.com
  
    api:
      image: nginx:1.16
      ports:
        - &quot;82:80&quot;
      environment:
        - VIRTUAL_HOST=api.test.com
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-07T11:02:23.810Z
Answers: 2022-01-07T11:02:23.810Z
Answers: Abdennour TOUMI
Answers: <p>I ended up using <a href="http://mageddo.github.io/dns-proxy-server/latest/en/" rel="nofollow noreferrer"><code>dns-proxy-server</code></a> in combination with nginx reverse proxy (serving as an ingress) on the host using a docker bridge network (not the default one). I wrote Ansible roles and playbooks to run Docker containers in that one network.</p>
  <p>In this formation, dns-proxy-server would act as a DNS server for anything running on the host trying to connect to a Docker container (including nginx acting as an ingress). This setup helped with the requirement where you'd wanna have nginx blocks as mentioned in the question.</p>
  <p>I have since moved to k3s on a single node for all my container needs.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-07T15:40:03.267Z
Answers: 2022-01-07T15:40:03.267Z
Answers: SaadKnight
Answers: <p>Not a lot of difference between setting up a backend in nginx or an ingress in kubernetes. They work essentially the same way and that's commonly known as reverse proxying, as you said.</p>
  <p>What you need in that case is not just a reverse proxy, but an API gateway. We can spend days arguing about your application design, I'm more of a subdomain instead of /prefix guy. But regardless of the decision making, you need something to handle that.</p>
  <p>Option 1 Kong Gateway:</p>
  <p><a href="https://konghq.com/install/#kong-community" rel="nofollow noreferrer">https://konghq.com/install/#kong-community</a></p>
  <p>Option 2 Traefik:</p>
  <p><a href="https://doc.traefik.io/traefik/" rel="nofollow noreferrer">https://doc.traefik.io/traefik/</a></p>
  <p>Both work in compose and kubernetes, both are reverse proxies with API gateways capabilities and both have their own kubernetes ingress controllers.</p>
  <p>There are loads more, those are the ones I know, trust and have used in production with no awkward surprises.</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-01-08T19:14:08.210Z
Answers: 2022-01-08T19:14:08.210Z
Answers: Magus
Body: <p>I'm more of a software developer than a networking/ops person to give you some context. </p>
  
  <p>I'm currently creating an application that is a standard containerised microservices architecture, where my frontend is some static assets in an nginx container, and my backend APIs are expressjs servers running on node containers. </p>
  
  <p>When my frontend makes a call to a backend endpoint, it's going to look like: </p>
  
  <pre><code>const response = await fetch("/api1/v1/items"); 
  </code></pre>
  
  <p>Because by default the browser is going to make this request to the frontend container, we need  some way of redirecting that traffic to the correct backend container. </p>
  
  <p>One standard way to do this, is that I can setup a reverse-proxy in  the frontend container's <code>nginx.conf</code> to direct all <code>/api1/*</code> traffic to another service. </p>
  
  <p>ie. you would do something like this: </p>
  
  <pre><code>
  location /a {
     proxy_pass         http://api1;
  
  </code></pre>
  
  <p>Where you have defined api1 as a service in your <code>docker-compose.yml</code>. </p>
  
  <p>I'm a bit uncomfortable with this, at the cluster configuration is mixed up with the implementation. </p>
  
  <p>I am aware with <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="noreferrer">Kubernetes ingresses</a>, this routing can be done from outside of the container - where essentially the traffic is routed as it enters the cluster. </p>
  
  <p>This is a much nicer solution in my view. </p>
  
  <p>But the reason I'm using docker-compose is just for simplicity - it's more for running the cluster on your local machine and just getting the whole thing up and running. </p>
  
  <p>Is there a similar configurable ingress concept for docker-compose? </p>
  
Comments: CC BY-SA 4.0
Comments: 2019-04-21T07:02:55.623Z
Comments: you want to run microservices. you want to run on docker alone. you don't want to mix routing concerns into your frontend container. so why not just run a separate routing container that has conf for routes to all the other microservices and the frontend? if you eventually migrate to Kubernetes you would replace the routing component with the built in infrastructure. you can then evaluate different routing tech in the routing container such as openresty if pure nginx isn't smart enough.
Comments: simbo1905
Tags: <docker-compose><microservices><ingress>
Title: Is there an equivilent of a Kubernetes ingress for Docker Compose?
UserDisplayName: dwjohnston
ThreadText: # Is there an equivilent of a Kubernetes ingress for Docker Compose?
  
  (Asked by: username_0 on 2019-04-17)
  
  I'm more of a software developer than a networking/ops person to give you some context.
  
  I'm currently creating an application that is a standard containerised microservices architecture, where my frontend is some static assets in an nginx container, and my backend APIs are expressjs servers running on node containers.
  
  When my frontend makes a call to a backend endpoint, it's going to look like:
  
  ```
  const response = await fetch("/api1/v1/items"); 
  
  ```
  
  Because by default the browser is going to make this request to the frontend container, we need some way of redirecting that traffic to the correct backend container.
  
  One standard way to do this, is that I can setup a reverse-proxy in the frontend container's `nginx.conf` to direct all `/api1/*` traffic to another service.
  
  ie. you would do something like this:
  
  ```
  
  location /a {
     proxy_pass         http://api1;
  
  ```
  
  Where you have defined api1 as a service in your `docker-compose.yml`.
  
  I'm a bit uncomfortable with this, at the cluster configuration is mixed up with the implementation.
  
  I am aware with [Kubernetes ingresses](https://kubernetes.io/docs/concepts/services-networking/ingress/), this routing can be done from outside of the container - where essentially the traffic is routed as it enters the cluster.
  
  This is a much nicer solution in my view.
  
  But the reason I'm using docker-compose is just for simplicity - it's more for running the cluster on your local machine and just getting the whole thing up and running.
  
  Is there a similar configurable ingress concept for docker-compose?
  
  **Tags:** docker-compose, microservices, ingress
  
  > **Comments:**
  > **username_1**: you want to run microservices. you want to run on docker alone. you don't want to mix routing concerns into your frontend container. so why not just run a separate routing container that has conf for routes to all the other microservices and the frontend? if you eventually migrate to Kubernetes you would replace the routing component with the built in infrastructure. you can then evaluate different routing tech in the routing container such as openresty if pure nginx isn't smart enough.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_2 on 2019-04-17. Score: 1
  
  Kubernetes ingress is implemented by changing the configuration of another container or the cloud load balancer to route traffic to the service port/ip. Docker by itself is fairly lightweight, only runs the containers you start, and does not have external dependencies on things like your cloud load balancer. The solutions to setup a reverse proxy inside a container are almost identical to the kubernetes nginx based ingress controllers, with the key difference being the configuration of that reverse proxy.
  
  There are a variety of docker based reverse proxies that configure themselves, including docker-flow-proxy, nginx-proxy, and Docker-EE ships with interlock that configures HA proxy. Probably the easies solution I've seen to implement is traefik which can be configured to monitor the docker socket for changes and automatically reconfigure based on labels set on your containers.
  
  One important difference from Kubernetes is that docker networks are not flat, you will need to explicitly place the proxy container on the same docker network as your application in order for them to be able to route traffic between each other.
  
  
  ---
  
  ### Answer by username_3 on 2022-01-07. Score: 1
  
  [`jwilder/nginx-proxy`](https://github.com/nginx-proxy/nginx-proxy/issues/1783) image simulates that excatly.
  Use VIRTUAL\_HOST & VIRTUAL\_PATH env vars in the backend containers.
  
  example:
  
  ```
  version: '3.4'
  
  services:
    ingress:
      image: jwilder/nginx-proxy
      ports:
        - "80:80"
      volumes:
        - /var/run/docker.sock:/tmp/docker.sock:ro
  
    frontend:
      image: nginx:1.16
      ports:
        - "81:80"
      environment:
        - VIRTUAL_HOST=test.com
  
    api:
      image: nginx:1.16
      ports:
        - "82:80"
      environment:
        - VIRTUAL_HOST=api.test.com
  
  ```
  
  
  ---
  
  ### Answer by username_4 on 2022-01-07. Score: 0
  
  I ended up using [`dns-proxy-server`](http://mageddo.github.io/dns-proxy-server/latest/en/) in combination with nginx reverse proxy (serving as an ingress) on the host using a docker bridge network (not the default one). I wrote Ansible roles and playbooks to run Docker containers in that one network.
  
  In this formation, dns-proxy-server would act as a DNS server for anything running on the host trying to connect to a Docker container (including nginx acting as an ingress). This setup helped with the requirement where you'd wanna have nginx blocks as mentioned in the question.
  
  I have since moved to k3s on a single node for all my container needs.
  
  
  ---
  
  ### Answer by username_5 on 2022-01-08. Score: 0
  
  Not a lot of difference between setting up a backend in nginx or an ingress in kubernetes. They work essentially the same way and that's commonly known as reverse proxying, as you said.
  
  What you need in that case is not just a reverse proxy, but an API gateway. We can spend days arguing about your application design, I'm more of a subdomain instead of /prefix guy. But regardless of the decision making, you need something to handle that.
  
  Option 1 Kong Gateway:
  
  <https://konghq.com/install/#kong-community>
  
  Option 2 Traefik:
  
  <https://doc.traefik.io/traefik/>
  
  Both work in compose and kubernetes, both are reverse proxies with API gateways capabilities and both have their own kubernetes ingress controllers.
  
  There are loads more, those are the ones I know, trust and have used in production with no awkward surprises.
  
  
  ---
  
  