This guide will walk you through the steps necessary to download and run Linkerd locally.
In order to run Linkerd locally, you must have Java 8 installed. You can check your Java version by running:
$ java -version java version "1.8.0_66"
Linkerd works with both Oracle and OpenJDK. If you need to install Java 8, you can download either one.
First, download the latest binary release of Linkerd.
Once you’ve downloaded the release, extract it:
$ tar -xzf linkerd-1.6.1.tgz $ cd linkerd-1.6.1
The release will contain these files:
config/linkerd.yaml— config file defining routers, servers, protocols, and ports
disco/— file-based service discovery config
linkerd-1.6.1-exec— Linkerd executable
logs/— default location where Linkerd logs are written
Once you have extracted the release, you can start and stop Linkerd by using
To start Linkerd, run:
$ ./linkerd-1.6.1-exec config/linkerd.yaml
You can validate that Linkerd works by sending some HTTP traffic through it.
Out of the box, Linkerd is configured to listen on port 4140, and to route any
HTTP calls with a
Host header set to “web” to a service listening on port
You can test this by running a simple service on port 9999:
$ echo 'It works!' > index.html $ python -m SimpleHTTPServer 9999
This will be our destination server, and will respond to any HTTP request with a friendly response. We can send traffic to this destination by connecting to Linkerd and specifying the appropriate host header:
$ curl -H "Host: web" http://localhost:4140/ It works!
Because we’ve asked Linkerd to proxy the “web” host, our request is routed to the server on port 9999, and the response is proxied to the client. It works!
Note that if you don’t provide a Host header that matches the name of one of the routable services, Linkerd will fail the request:
$ curl -I -H "Host: foo" http://localhost:4140/ HTTP/1.1 502 Bad Gateway
Of course, there’s a lot more to naming services than this! In the next section, we’ll see where the service information used above is specified.
Under the configuration shipped with Linkerd, the first place it looks when it
needs to resolve a service endpoints is the
(See the configuration guide for more on how this simple file-based service
discovery system works.)
With this configuration, Linkerd looks for files with names corresponding to
the concrete name of a destination, and it expects these files to contain
a newline-delimited list of addresses in
host port form.
The default configuration looks like this:
$ head disco/* ==> disco/thrift-buffered <== 127.0.0.1 9997 ==> disco/thrift-framed <== 127.0.0.1 9998 ==> disco/web <== 127.0.0.1 9999
As you can see, there is a destination called “web” that is backed by a single
127.0.0.1 9999, as well as a thrift framed destination that is backed
127.0.0.1 9998, and a thrift buffered destination that is backed by
127.0.0.1 9997. Note that, just as it does with all service discovery
endpoints, Linkerd monitors this directory for changes, so feel free to add,
remove, and edit files at any point—no restarting required.
The routing configuration that is shipped with Linkerd is very simple, and
routes directly to the concrete names specified in this directory. In other
words, asking Linkerd for the “web” service, as we did above, will result in it
connecting to one of the endpoints in the
This routing configuration is good for demonstrating basic functionality, but Linkerd is capable of a lot more, including multiple service discovery endpoints, per-request routing rules, debug proxy injection, service failover, and more. See the Routing page for details on Linkerd’s routing capabilities.