Microservice architectures are quite popular nowadays. A typical application may consist of 10, 50, or even more than 100 microservices. Although it is relatively easy to run five microservices locally on your laptop, it’s not as easy to run 20 or 50 of them. And it’s not because of lack of computing power, but because it is just very tedious to set up. Services tend to use databases, cloud services, some 3rd party APIs, etc. You need to set all of this up in order to use all of them locally. Because of that, I often find myself running just one or two services locally and using the rest of them from the staging environment. It is also somewhat annoying to set up because we need to rewire everything manually. Let's explain the idea better using this diagram: Here we have a media streaming app example, which consists of a few services, two of which we want to run and debug locally (recommendation and notifications services, marked with red arrows). To do that, we’d need to change two URLs in the frontend configuration, to point to our local services, and one URL in the notifications service. So three changes in total. But what if we wanted to run 5 of them locally? What if we needed to work on another feature and forgot to undo some of our changes? Depending on the communication patterns between those services, it may become very messy soon enough. So we came up with the idea of the local router. At , we help teams that build distributed services troubleshoot their microservices. And since our daily work with microservices became way easier once we started using the local router, we wanted to share with you how it’s done. Aspecto Local router The plan is to route all the local traffic through a reverse-proxy server and rewire everything in its configuration file. We call it “the local router”. Here’s another simple diagram to illustrate the idea: Instead of making changes in the configuration of each service (and most likely restarting it afterward), we just update the router’s config file and it immediately switches the target for us. No service or router restart is needed. Here's how you can actually do that. Configuration We are going to use reverse proxy because it supports dynamic configuration reload. traefik We could also use nginx or HAProxy, however, we decided on traefik because of its simplicity. Also, it is worth mentioning that we’re going to use version 2.2. There’re two types of configuration in traefik: static and dynamic. The difference is that dynamic configuration can be changed in the runtime, whilst static can’t. Let’s create a static configuration file and call it static.config.yml: entryPoints: web: address: : providers: file: filename: dynamic.config.yml api: dashboard: insecure: log: level: INFO 80 /config/ true true As you can see, we specify an entrypoint, HTTP port 80, and a path to the dynamic config file. Nothing too complicated. Let’s now create a dynamic configuration file (dynamic.config.yml): http: routers: recommendation: rule: Host( ) service: recommendation auth: rule: Host( ) service: auth email: rule: Host( ) service: email notifications: rule: Host( ) service: notifications dashboard: rule: >- Host( ) && (PathPrefix( ) || PathPrefix( )) service: api@internal services: auth: loadBalancer: passHostHeader: servers: - url: email: loadBalancer: passHostHeader: servers: - url: notifications: loadBalancer: passHostHeader: servers: - url: recommendation: loadBalancer: passHostHeader: servers: - url: `recommendation.some-domain.localhost` `auth.some-domain.localhost` `email.some-domain.localhost` `notifications.some-domain.localhost` `traefik.some-domain.localhost` `/api` `/dashboard` false "https://stg-auth.some-domain.io/" false "https://stg-email.some-domain.io/" false "http://localhost:8089/" false "http://localhost:8088/" The file consists of a single HTTP section that contains definitions of routers and services. If you’re not familiar with traefik documentation, make sure to check . https://doc.traefik.io/traefik/routing/overview/ The configuration specifies that for each request to localhost port 80, traefik inspects the Host header and, depending on its value, passes the traffic to a corresponding URL. For example, a request to will be proxied to . TLS termination will be handled by traefik automatically (which is also pretty cool). http://auth.some-domain.localhost:80/ https://stg-auth.some-domain.io/ Because we’re using .localhost as a root domain, it should work even without modifying the file, but in practice, some services may not work. We had such issues with socket.io, for example, so to make it more reliable, let’s also add the following records to : /etc/hosts /etc/hosts recommendations.some-domain.localhost auth.some-domain.localhost notifications.some-domain.localhost email.some-domain.localhost 127.0 .0 .1 127.0 .0 .1 127.0 .0 .1 127.0 .0 .1 Also, in our services, we need to update the local config to use instead of staging URLs everywhere. some-domain.localhost Dockerfile We can run traefik on a host machine, but usually, it’s easier to spin a docker container. We’ll create a dockerfile: FROM traefik:v2 RUN mkdir -p /config CMD traefik --configFile= .config.yml .2 /config/ static This is how the folder structure should look like to make it work: router ├─ Dockerfile └─ config ├─ dynamic.config.yml └─ .config.yml static Now, in the router folder run: docker build -t -router . local And then docker run -p : local-router 80 80 Now we can use two local services and two staging services, without changing anything in the configuration of the services themselves. When we want to switch to the staging version of, let’s say recommendation service, all we need to do is to change a corresponding record in traefik’s dynamic config, specifically the URL. From this: recommendation: loadBalancer: passHostHeader: servers: - url: false "http://localhost:8088/" to this: recommendation: loadBalancer: passHostHeader: servers: - url: false "https://stg-recommendation.some-domain.io" And save the config file. From this point, all calls to will be proxied to staging. http://recommendations.some-domain.localhost It simplifies things a lot because now we have a single file with all the configuration and we don’t need to restart our services. Summary There are many ways to improve this setup. For example, we can create a config generator, that will allow us to change the configuration by flipping a boolean value. And then run it along with traefik in docker compose (that’s what we actually did). Or maybe you want to run your local services with docker instead of host machine. It all depends on your use case. Our hopes are that local router will be useful for some of you, or maybe inspire you to do something even better. Give this one a go and if you find it helpful, share this blog post with your team. We are always happy to receive feedback – . let us know Developed by with ❤️ Aspecto Previously published at https://www.aspecto.io/blog/easy-way-to-route-traffic-between-microservices-during-development/
