Deployment

The main use-case for fabio is to distribute incoming HTTP(S) requests from the internet to frontend (FE) services which can handle these requests. In this scenario the FE services then use the service discovery feature in consul to find backend (BE) services they need in order to serve the request.

That means that fabio is currently not used as an FE-BE or BE-BE router to route traffic among the services themselves since the service discovery of consul already solves that problem. Having said that, there is nothing that inherently prevents fabio from being used that way. It just means that we are not doing it.

Direct

In the following setup fabio is configured to listen on the public ip(s) where it can optionally terminate SSL traffic for one or more domains - one ip per domain.

                                           +--> service-a
                                           |
internet -- HTTP/HTTPS --> fabio -- HTTP --+--> service-b
                                           |
                                           +--> service-c

To scale fabio you can deploy it together with the frontend services which provides high-availability and distributes the network bandwidth.

           +- HTTP/HTTPS -> fabio -+- HTTP -> service-a (host-a)
           |                       |
internet --+- HTTP/HTTPS -> fabio -+- HTTP -> service-b (host-b)
           |                       |
           +- HTTP/HTTPS -> fabio -+- HTTP -> service-c (host-c)

Behind an existing LB/Gateway

In the following setup fabio is configured receive all incoming traffic from an existing gateway which also terminates SSL for one or more domains.

                                                          +--> service-a
                                                          |
internet -- HTTP/HTTPS --> LB -- HTTP --> fabio -- HTTP --+--> service-b
                                                          |
                                                          +--> service-c

Again, to scale fabio you can deploy it together with the frontend services which provides high-availability and distributes the network bandwidth.

                               +- HTTP -> fabio -+-> service-a (host-a)
                               |                 |
internet -- HTTP/HTTPS --> LB -+- HTTP -> fabio -+-> service-b (host-b)
                               |                 |
                               +- HTTP -> fabio -+-> service-c (host-c)

Amazon ELB

You can deploy fabio behind an Amazon ELB and enable PROXY protocol support to get the remote address and port of the client.

                                +- HTTP w/PROXY proto -> fabio -+-> service-a (host-a)
                                |                               |
internet -- HTTP/HTTPS --> ELB -+- HTTP w/PROXY proto -> fabio -+-> service-b (host-b)
                                |                               |
                                +- HTTP w/PROXY proto -> fabio -+-> service-c (host-c)

Amazon API Gateway

You can deploy fabio as the target of an Amazon API Gateway.

internet -- HTTP/HTTPS --> API GW -+- HTTP -> fabio -+-> service-b (host-b)

or behind an ELB with PROXY protocol support:

                                           +- HTTP w/PROXY -> fabio -+-> service-a (host-a)
                                           |                         |
internet -- HTTP/HTTPS --> API GW --> ELB -+- HTTP w/PROXY -> fabio -+-> service-b (host-b)
                                           |                         |
                                           +- HTTP w/PROXY -> fabio -+-> service-c (host-c)

You can authenticate calls from the API Gateway with a client certificate. This requires that you configure an HTTPS listener on fabio with a valid certificate.

internet -- HTTPS --> API GW -+- HTTPS w/client cert -> fabio -+-> service

To enable fabio to validate the Amazon generated certificate you need to configure the aws.apigw.cert.cn as follows:

proxy.addr = 1.2.3.4:9999;your/cert.pem;your/key.pem;api-gw-cert.pem
aws.apigw.cert.cn = ApiGateway

api-gw-cert.pem is the certificate generated in the AWS Management Console. your/cert.pem and your/key.pem is the certificate/key pair for the HTTPS certificate. Since the Amazon API Gateway certificates don't have the CA flag set fabio needs to trust them for the client certificate authentication to work. Otherwise, you will get an TLS handshake error: failed to verify client's certificate. See Issue 108 for details.

Note: The aws.apigw.cert.cn parameter will not be supported in the upcoming 1.2 release which supports dynamic certificate sources. You will have to add the caupgcn=ApiGateway parameter to the certificate source configuration instead. See Certificate Stores for more detail.