Before I used Rancher, I had an HAProxy server that pulled container addresses and server configuration from etcd. Service upgrades were just a matter of restarting the service and upgrading a few etcd keys. Now I’ve migrated my fairly simple setup to Rancher, and while it gives me some great advantages regarding deploying my services easily anywhere and provisioning new infrastructure, I can’t wrap my mind around how to orchestrate service upgrades from my Jenkins CI server.
At this point I’d like to set up non-rolling, immediate upgrades. Basically, a new image gets pulled and the service is restarted with the new image. The load balancer is then tweaked to reference the new IP. It seems that the easiest way to do this is also the ugliest–pull the new image, remove the old service, recreate it so a new container with the latest image is restarted, then remove/recreate the load balancer because the link to the old container went away when it was removed and recreated. Am I missing something?
I’ve looked into service aliases. I suppose it’s possible to configure 2 services for each service, assign them to an alias, then upgrade app1 to app2. I guess this would trigger a recreate of the containers and wouldn’t break my links. The ugly bit here is that I’d have to track if I was on app1 or app2 currently, then periodically “upgrade” from app2 to app1. This seems rather ugly both from configuration and orchestration perspectives.
The most semantically correct way is probably creating a generic service alias, then creating services within that alias keyed to the build number in the CI server. Then I could just upgrade from app_v$BUILD_NUMBER-1 to app_v$BUILD_NUMBER in all cases where $BUILD_NUMBER-1 exists. But I imagine this would require writing a Jenkins plugin to interface with the Rancher API, which is more than I have time for.
Am I missing something? I don’t dispute that this last scenario would be best, but it seems to suppose things that don’t yet exist (the Jenkins plugin.) Is there no way to simply pull and restart a service without breaking its links to the load balancer, or only minimally disrupting these links without requiring that the LB be torn down and recreated?