What the heck is a dev proxy? To clarify, it’s a term that I’m not sure if I use it correctly, but to my understanding, a dev proxy is simply… a reverse proxy used solely for development purposes.

But why do we need one? As microservices become more and more common (I wanted to say popular but it’s highly opinionated), the need to run multiple services locally while developing a project is more necessary than before. And one of the problems is port conflict, a common convention I usually see with microservices is to use almost identical setup. This means that the port they are using is likely the same port. And microservices usually come hand in hand with docker and obviously you can’t bind the same port twice (even if you don’t use docker I don’t think you can run 2 processes listening in the same ip:port)

A dev proxy is a simple solution to mitigate this problem and makes it more enjoyable to work with microservices. In this blog post, I’m gonna describe my process of setting up a local dev proxy so that I can run multiple services without worrying about their port.

In the previous part, I’ve shown how to set up a simple swarm cluster with 1 master and 2 worker nodes. In this part, I’m gonna continue with how to configure it to work with gitlab and also achieve zero downtime deployment.

Being able to develop an application of any kind and automatically deploy it is the norm nowadays. I have been using dokku in my personal deployment stack for several years now. And at work, we are using Kubernetes. I love the idea of Kubernetes but wanted to try something else, and came across docker swarm mode. In this blog post series, I’m gonna describe the process of setting up a docker swarm cluster, putting traefik in front as a reverse proxy and automatically deploying via gitlab without downtime.