I have this workflow setup for Atlassian Bitbucket and Bamboo, but the concepts will apply to whatever tools you are using.
I create a custom docker-compose and rancher-compose for my “stack”, I store those in a Bitbucket project for my stack. They contain the info about my service, link to my container reg, and the LB I want created.
Create an api key for each Rancher env you want to deploy to.
I deploy the stack from a job in Bamboo that is configured to hit the Rancher server endpoint for the env I want the stack in (I only do this to get the initial stack created)
Whenever the service needs to be updated (regardless of the env - dev/qa/stag/prod) we simply hit the “upgrade” button for the service in the stack in Rancher (we have “always pull” on, and update the image tag if needed to install a specific image - myreg/myservice:custombuild-0.1.1-test)
As for scheduling, i use host labels that are mapped in the stack config (env=dev, app1=dev-api, app2=dev-api2, etc)
Examples -
docker-compose
`dev-api:
environment:
DATABASE_URL: postgis://youwish.rds.amazonaws.com/?
CENSUS_URL: postgis://goodluck.rds.amazonaws.com/?
SECRET_KEY: it’s a secret!
CONTAINER: lighting_dev
jwt_verify_expiration: false
DJANGO_SETTINGS_MODULE: lightning.settings
CACHE_URL: nicetry.cache.amazonaws.com:11211
ENV: dev
ALLOWED_HOSTS: '*'
PORT: '6969’
log_driver: ''
labels:
io.rancher.container.pull_image: always
io.rancher.scheduler.global: 'true’
io.rancher.scheduler.affinity:host_label: env=dev
tty: true
log_opt: {}
image: myreg.dkr.ecr.us-east-1.amazonaws.com/myimg:trythis-0.0.1
stdin_open: true
dev-lb-lightning:
ports:
- 6969:80
tty: true
image: rancher/load-balancer-service
links:
- dev-api:dev-api
stdin_open: true`
rancher-compose
dev-api: scale: 1 dev-lb-lightning: scale: 1 load_balancer_config: haproxy_config: {} health_check: port: 42 interval: 2000 unhealthy_threshold: 3 healthy_threshold: 2 response_timeout: 2000
In my Bamboo deploy project -
- grab compose files from Bitbucket project
- run this script on deployment server (or somewhere you can reference the rancher-compose binary) -
/usr/local/bin/rancher-compose \ -r rancher-compose.yml \ -f docker-compose.yml \ -p lightning-api --debug \ up -d --force-upgrade --pull --batch-size "1"
Env variable to map to the correct Rancher env -
RANCHER_URL=http://nothappening:8080/v1/projects/1a9 RANCHER_ACCESS_KEY=xxx RANCHER_SECRET_KEY=xxx
You will then have a full stack created with your service and an LB if needed, again, after that simply hit the upgrade button on the service to pull and deploy the updated image. Let me know if you need any more info.
Edit: I forgot to mention that for completely “automated” deployment, we have enabled a trigger on the Bamboo deployment that can detect that a new image has been built and runs the deployment automatically. I’m not a huge fan of this simply because i don’t like blowing away and re-building the stack (in dev, this would happen around 30+ times/day), I prefer to just update the service within the running stack.
Phillip