Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Improvement] Blue/Green deployment #914
Hey guys !
What about an API route to update the constraints of a local Traefik instance ?
# erase old constraints $ curl -X PUT' /api/providers/consulCatalog/constraints' -d '["tag==api-us-east", "tag!=api-blue"]' # set/erase one constraint $ curl -X PATCH '/api/providers/consulCatalog/constraints' -d 'tag!=api-blue' # remove one constraint $ curl -X DELETE '/api/providers/consulCatalog/constraints/tag!=api-blue' # flush constraints $ curl -X DELETE '/api/providers/consulCatalog/constraints'
I would be even better to have a custom flag in provider configuration, dedicated to blue/green deployment:
Support for Blue/Green deployments would be great. We have to support many stateful legacy applications, meaning we also need Traefik's support of sticky sessions. It would be great if there was a way with Traefik to (assuming old version is 'blue'):
I would not be surprised if there are lots of teams who have to support stateful applications, who would really like to be using blue/green deployments.
I am requesting a feature to support blue/green deployment when using Docker swarm mode as its backend configuration.
The idea is to support a label for source IP address(es), IP address range or subnet (or geolocation perhaps) and forward the users' traffic to a backend server intended for the green deployment. Let's say serviceA is running version 1.0.0 in the blue environment (active) at overlay network A then another serviceA is also running but this time it is on version 1.0.1 in the green environment attached to both overlay networks A and B but for selected users only whose IP addresses matches to the label.
Thank you in advance.
In Docker swarm mode backend, ServiceA and ServiceB are basically the same applications with different Docker image tags/versions but ServiceB comes maybe with additional feature and/or minor fixes.
The Nomad project has support for blue/green + canary deployments. However, it is not stated there how they are going to decide whose traffic will be forwarded to the canary version or maybe I'm not yet aware of it. I hope that in Traefik using Docker swarm mode backend, the source IP address(es), source network and/or source geolocation will be supported to decide whose traffic will be forwarded to the canary version.
I managed to come close to a workaround, while the feature is being worked on.
So far I am using a combination of Consul and File endpoint but lacks of auto-reloading,
(2. could be automated via a CI's job)
version: '2' services: consul: image: consul:latest container_name: consul networks: - discovery ports: - "8400:8400" - "8500:8500" - "172.17.0.1:53:8600/udp" labels: SERVICE_IGNORE: "true" registrator: image: gliderlabs/registrator:latest container_name: registrator privileged: true networks: - discovery depends_on: - consul command: -internal=true consul://consul:8500 volumes: - /var/run/docker.sock:/tmp/docker.sock labels: SERVICE_IGNORE: "true" proxy: image: traefik container_name: proxy command: --web --file --consul --consul.endpoint=consul:8500 --consulcatalog.endpoint=consul:8500 --logLevel=DEBUG networks: - internet-gateway - discovery - proxy ports: - "80:80" - "443:433" - "8080:8080" depends_on: - consul volumes: - /var/run/docker.sock:/var/run/docker.sock - $PWD/config.toml:/traefik.toml labels: SERVICE_IGNORE: "true" app-blue: image: emilevauge/whoami networks: - proxy expose: - 80 labels: SERVICE_NAME: "blue" SERVICE_TAGS: "traefik.frontend.rule=Host:blue.service.consul" app-green: image: emilevauge/whoami networks: - proxy expose: - 80 labels: SERVICE_NAME: "green" SERVICE_TAGS: "traefik.frontend.rule=Host:green.service.consul" networks: discovery: internet-gateway: proxy:
[file] watch = true [backends] [backends.production] [backends.production.servers.server1] url = "http://<app-blue_ip>:80" [backends.preproduction] [backends.preproduction.servers.server1] url = "http://<app_green_ip>:80" [frontends] [frontends.production] backend = "production" [frontends.production.routes.route-host-production] rule = "Host:production.myapp.local" [frontends.preproduction] backend = "preproduction" [frontends.preproduction.routes.route-host-preproduction] rule = "Host:preproduction.myapp.local"
I implemented Blue/Green deployment in my setup. It’s almost perfect.
BEFORE I had a downtime of 90 seconds. With my Blue/Green deployment setup, I got two little downtime of 5 seconds.
Here is how I do it:
How much time does Traefik need to actively learn that a service has disappeared ?
IMHO, a possible solution is that we need to be able to force Traefik to re-asset available services for
I've reviewed all the blue-green implementations in docker swarm. The crucial difference is how the switch between blue and green happens. It all seems to fall into 3 categories:
Here are my comments:
So let's focus on 3rd approach.
The problem is that you have to run
Unfortunately it doesn't work since
So here's an idea on improvement: dump all the option into a
Alternatively, if we don't want to go to that rabbit hole, we might use traefik API to change configuration instead of changing services and waiting for traefik to pickup those changes.
blue/green is supported by nomad and consul catalog using tags. You define different tags for the blue servers and the green servers. Unfortunately, Traefik does not make this distinction and blue and green are grouped together on a single backend, see #3882