Let this be the central place for this topic.
From what I’ve observed on IRC and github etc. there will be some features coming out soon to help with this process.
For now I’ve been advised that using a service alias is the best practice but I’m having trouble understanding how to implement this (http://docs.rancher.com/rancher/rancher-ui/applications/stacks/adding-service-alias/).
countdown-lb: ports: - 8000:80/tcp tty: true image: rancher/load-balancer-service links: - countdown-v2:countdown-v2 stdin_open: true countdown-v1: ports: - 80/tcp restart: 'no' tty: true image: flaccid/countdown_example:v1 stdin_open: true countdown-v2: ports: - 80/tcp restart: 'no' tty: true image: flaccid/countdown_example:v2 stdin_open: true countdown-demo-alias: image: rancher/dns-service links: - 'countdown-v2:'
countdown-lb: scale: 1 load_balancer_config: name: countdown-lb config countdown-v1: scale: 1 countdown-v2: scale: 1
In this case the service alias isn’t used because I’m not sure how to use it. If I point the LB to the alias instead of one of the container services it doesn’t work (connection refused), but I’m not sure if that is actually what I should be trying.
Currently I change the link on the LB to the new container server e.g.
countdown-v2:countdown-v2 then start rancher-compose again, It switches and we have the new version of the app. Works ok although I did notice sometimes a slight gap in service.
This is of course not the ideal method and I’d like to an example where I can use a service alias. Very open to learning what the best practice is and hopefully we can update documentation for users to get to that easy. The use case here is that the CI tool being used for continuous deployment can run rancher-compose or similar to deploy the new version of the application with zero downtime.