Virtually all HTTP clients support making calls through an intermediate proxy. Traditionally, this was used to operate in firewalled environments where connections to the external world were restricted. However, since Linkerd functions as an HTTP proxy, and since using a proxy can often be accomplished without code changes, this approach also offers an easy integration path for applications that use HTTP.
Linkerd as an HTTP proxy
Linkerd can act as an HTTP proxy without any additional configuration, providing key features such as load balancing, service discovery and dynamic request routing at no extra cost. By default Linkerd routes HTTP requests based on the HTTP host that is sent as part of the request. For example, suppose that Linkerd is running locally on port 4140, and that it has been configured to route requests to instances of the “hello” service running elsewhere. In that scenario, you could take advantage of Linkerd’s proxy integration and make a curl request to the “hello” service with:
$ http_proxy=localhost:4140 curl http://hello/
http_proxy variable set, curl will send the proxy request directly to
Linkerd, without actually looking up “hello” in DNS. Linkerd will in turn look
up the “hello” service in whichever backend it is configured to use for service
discovery, and it will route the request accordingly.
Using an HTTP proxy
Configuring your application to use an HTTP proxy can often be done without code changes. However, the specifics of this configuration are language-dependent. Here are some examples for common setups:
C, Go, Python, Ruby, Perl, PHP, curl, wget, Node.js’ request package: these languages and utilities support an
http_proxyenvironment variable, which sets a global HTTP proxy across all requests. Simply set the variable and you’re good to go.
Java, Scala, Clojure, and JVM languages: the JVM can be configured to use an HTTP proxy by setting the
http.proxyPortenvironment variables, (e.g.
java -Dhttp.proxyHost=127.0.0.1 -Dhttp.proxyPort=4140 ...).
In principle, Linkerd can route on any component of the request, from incoming
port to payload content. In practice, for HTTP calls, it is most natural to
route on the host (using the default
methodAndHost identifier) or on the URL path (using the
If a global HTTP proxy approach is not possible, any mechanism that allows
setting the host or URL path while connecting to Linkerd will also work. For
example, proxy settings can often be configured directly in the HTTP client on
a per-request basis. Alternatively, connecting directly to Linkerd and setting
Host: header as part of the request will allow Linkerd to route
on that host just as the proxy approach would.
Another alternative if you are running on Kubernetes is using transparent proxying via iptables rules.