Open cdrx opened 6 years ago
Since using the docker's so easy in the gitlab-ci.yml
, that's all I've ever used. And since that's completely language agnostic, I'm down for a rewrite 100%. :)
Maybe not quite an answer to your questions, but I would like to be able to use this to deploy after builds from Codefresh.io instead of Gitlab.
Haven't tested it yet - but I think it may work as it is now.
FYI - tested on Codefresh and this works perfectly. Very cool.
I concur with @Morgul : the container packaging makes it easy to use.
Considering rancher 2 runs on kubernetes and gitlab now has support for kubernetes (havent tested it), could it be possible that a rewrite for 2.0 is not needed and gitlab could take over this task? Feedback welcome on my comment, i'm just thinking out loud without actually checking facts ;)
@cdrx Has there been any movement on this? Or am I better off rolling my own?
Try ranchers cli tool, there is a docker image for it. It works great in gitlab.
@samvdb Hi! Currently I use in my .gitlab-ci.yml
docker run --rm -e RANCHER_URL=$RANCHER_URL -e RANCHER_ACCESS_KEY=$RANCHER_ACCESS_KEY -e RANCHER_SECRET_KEY=$RANCHER_SECRET_KEY cdrx/rancher-gitlab-deploy:latest upgrade --finish-upgrade --wait-for-upgrade-to-finish --stack STACK --service SERVICE --new-image NEWIMAGE:NEWTAG
But I have always the error:
Status: Downloaded newer image for cdrx/rancher-gitlab-deploy:latest
Error: The Rancher URL doesn't look right
ERROR: Job failed: exit code 1
Do you have an idea ? You said you use the rancher cli, can you help me about the equivalent comand ?
Thank
@samvdb do you have any working example maybe? I'd like to see it in action still I couldn't find any good API documentation to make it work. So far I've been using my own fork of this repository, customized to use rancher2: https://github.com/kpolszewski/rancher-gitlab-deploy
@kpolszewski
This currently runs on rancher 1.6, i have not tested 2.0 due to lack of time. I switched over to rancher cli tool because v2 uses this. Should make my upgrade smoother in the future.
This is my gitlab config:
deploy-develop:
stage: deploy
dependencies: []
image: tagip/rancher-cli:latest
environment:
name: staging
url: xxx
only:
- develop
services:
- docker:dind
before_script: []
script:
- cd docker
- sh compose.sh
This is my compose.sh file in the docker folder.
#!/bin/bash
export CMD="--env <INSERT ENV HERE> up -d -u --stack <INSERT STACK HERE> --env-file develop.env -f docker-compose-dev.yml --rancher-file rancher-compose.yml"
rancher $CMD --confirm-upgrade --force-upgrade --batch-size 1
I have seperate files to inject environment variables and compose files. I currently dont deploy tags, i guess it could be done by passing arguments to the bash script and then replacing the variables in the compose file to use the newly build tag.
Rancher cli is powered by ENV variables which contain the url, access and secret key. I configured them in the gitlab runner, you could also just configure project variables.
@cdrx thanks for this tool, works like a charm with Gitlab for Rancher 1.x!
I'm wondering if this also works now already with Rancher2
as well?
Here is the simplest solution I could find for re-deploying rancher 2 from gitlab. Perhaps it can be integrated into this project:
deploy_foo:
image: jonaskello/rancher-cli-k8s:v2.0.4
script:
- rancher login $RANCHER2_SERVER_URL --token $RANCHER2_BEARER_TOKEN --context c-xxxxx:p-xxxxx
- rancher kubectl --namespace=foo-ns patch deployment foo -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
To make it fully generic, the --context c-xxxxx:p-xxxxx
, --namespace=foo-ns
and deployment foo
parts should have variables so it becomes --context $CONTEXT
, --namespace=$NAMESPACE
and deployment $DEPLOYMENT
. The image jonaskello/rancher-cli-k8s:v2.0.4
is just the regular rancher 2 cli command with kubectl added.
With Rancher 2.0 not far away, its time to start thinking about supporting the new API version.
I'm considering rewriting this tool in Go, to make it faster / smaller and take advantage of the Rancher API bindings.
Does anyone have any thoughts on that? Will it break your workflow?