I know a lot of you are using Rancher in production already, and we’re getting close to doing that too. One thing I’m interested in though, is how you’re handling the CI/CD pipeline with builds and Rancher.
We use Jenkins, and ideally I’d like to be able to control Rancher via a CLI inside a Jenkins job, but I’ve not actually gone as far as to do this yet. How do you do it? Do you use Jenkins or do you have another tool you prefer? Why do you prefer it? Do you talk to Docker directly on machines or do you talk to Rancher and let that handle containers for you? Are you talking via the Rancher API?
I’m really interested to know how you approach builds, from code being ready to deploy, through to the deployment and service upgrade. Looking forward to seeing some great responses!
For me, we use Wercker as a CI service. I like it because its designed with docker in mind, but has some small issues from time to time. Anyways, not trying to sell you on wercker.
I have a “wercker step” which deploys my services to rancher using the rancher API, and the CLI for rolling upgrade.
If you dont want to use wercker, just look at the bash script in “run.sh”
Thanks! That script is gold! Really appreciate the response and interesting to see your choice of CI service. I did consider a container-oriented CI but it didn’t seem to fit with our other needs.
The script does provide a great look at how you do the deploys though so thanks for that!
Drone is a great fit for this. It has a Rancher plugin for deployments, I’ve been using it very successfully.
I’ve also just started integrating another build into Rancher. That one runs on Jenkins. We use Gradle as our build tool since we are Java/Groovy/Scala apps.
For now, I just hand spun some client libraries using Retrofit to communicate with the Rancher API, however, I’ve been slowly working on this as well - https://github.com/objectpartners/rancher-java-sdk
Thanks folks, I came up with a solution for Jenkins. It’s a deployment bash script which calls into the API, and doesn’t need any *-compose.yml files. It’s still a bit rough but once I’ve had a chance to tidy it up, I’ll pop it in here for others.
Appreciate all the feedback and of course the effort of the team for giving us Rancher in the first place!
Hi,
just wanna say we’re usin gocd as cd and just adding rancher cli to agents running deployment pipelines.
We are also having rancher compose files as material in scm either separate or within project (depending on strategy) so its easy redeploying a complete new environment.
Otherwise I went bit further and have whole environments each in own git repository with one directory per stack with {docker,rancher}-compose.yml files.
It has logic for filtering environment variables per stack.
That way I can have everything provided on build (stored in GitLab Build Variables) and versioned.
For development environment I have second script that lists services images they use and forces pull for services with matching images. Services reference images by branch (master, feature-*) or more broad version (2, 2.2) so environment stack configs does not have to be updated so frequently.
It works ok-ish currently I’m thinking if or how to implement update strategies, automated deployments on created/updated images in docker repository or if to throw it away and use Kubernetes deployments instead. But for now all environments run on Rancher .
@adamkdean Hi. Your script is golden! The only issue I’ve come across is that the custom catalog gets updated in the git repo, but I don’t know how to get Rancher to refresh it before performing the actual upgrade. I’ve seen references to “v1/activesettings/1as!catalog.refresh.interval.seconds” but I’m not sure sure how we can call the API to do the refresh before we make the API call for the upgrade.
Do you have any suggestions? How do you refresh the custom catalog?
Rather than opening a new ticket i think this is still valid. I am interested in updating rancher using the CLI with the purpose to use the yml files as the sole source of truth. Every commit would potentially trigger a deployment command
$ rancher up --stack StackName --upgrade --force-upgrade
The problem i see with this approach is that some external dependencies and changes might not be handled. for instance i am getting at the moment
INFO[0000] Existing volume template found for stack-elk-data
FATA[0000] Volume “stack-data” needs to be recreated - driver has changed
This is because i want this volume to use rancher-nfs when it was not doing it before. I also have added another external volume in the stack so i can feed files to the service.
If I had to use docker-compose locally I would not get usually any problems doing this. So what am I missing? What do I need to understand about Rancher CLI to achive a real CI/CD process? I dont think the API is fit for purpose for this as I would need to write something custom and I am always happy with the lazy/consistent way (CLI) if it really works.
