Open josmo opened 6 years ago
Any updates on this?
@loxy Not yet. I was expecting 2.0 to be out a while ago. I know beta-2 just came out a few days ago and I'm just starting to have a staging server to be able to get started. I also haven't really looked at how the new structure looks, so if you have any suggestions on how the plugin show map to deploying services feel free to comment
Was just attempting set up a test build with rancher 2.0 and got the error below... Does this plugin currently support 2.0?
time="2018-04-26T21:06:24Z" level=info msg="Drone Rancher Plugin built"
time="2018-04-26T21:06:24Z" level=fatal msg="Failed to list rancher environments: Unknown schema type [stack]"
@smiller393 yeah the current plugin doesn't support Rancher 2. I'm definitely open to any PRs that will allow it. I'm going to start moving my environment to 2.0 pretty soon so I imagine I'll put time aside to update this plugin then.
One thing I would mention until this is figured out and is worth the question... Since rancher2 uses k8s for everything. Is the http://plugins.drone.io/mactynow/drone-kubernetes/ good enough to full replace what this plugin did
Thanks for the response @josmo. I definitely plan on trying the drone-kubernetes plugin and will report back if I get it to work.
@smiller393 I just used it a few minutes ago and it worked pretty well. I think there would need to be questions around "stop first" rolling deployment equiv and everything else. But probably works for current testing scenarios.
Hey @josmo, For mine the build step is succeeding but the deployment doesn't seem to update. I'm assuming I'm using the wrong values in my drone config. Do these seem right to you??
Here is what I'm trying to use:
kubernetes: image: quay.io/honestbee/drone-kubernetes kubernetes_server: (cluster url that I got from the yml config in rancher) kubernetes_token: (full bearer token from the key that I created) namespace: default deployment: (name of the workload I need to redeploy) repo: (customRepoUrlAndPort/repoNamespace/imageName) container: (name of the workload I need to redeploy) tag: dev when: branch: dev
Hum I used the token from the user in the kubeconfig . Not sure if the token you created is the same. Are you getting any log information?
I think it's better to use something like this: https://github.com/ipedrazas/drone-helm
yeah if you have helm charts for your deployments that makes sense. Although I could see having unique deployments in staging and then helm config for what goes to prod and gets published
If you have none, you should create some 😉, especially when using rancher. Helm is already included.
true.. But I can see the value in having both depending on your environment and delivery lifecycle :)
@smiller393 did you end up with success. It looks like the drone k8s plugins haven't been touched in a while. So there's not really great notification is something fails (although helm does have some updates, but creating charts is a bit of overhead depending on the complexity of what you're deploying). It's looking more and more like the drone-rancher plugin is going to be only for 1.6 and I'll move to finding a k8s native way of deploying for 2x unless someone can give a good reason to try to keep this around.
@josmo The regular k8 plugin has been working fine for us so far luckily! (fingers crossed it stays that way). I haven't done anything with helm yet so I really can't speak to that.
@smiller393 glad to hear. I'm going to take a stab at a golang version of the bash plugin. Just so that it'll have better feedback on failures, retry's, rolling deployments, etc - If we can get parity that way it will sunset this plugin for 2.x. I'll post here when I have something concrete
@smiller393 ok I've created https://github.com/josmo/drone-k8s-deployment which is a simple implementation in golang to upgrade a deployment. image is peloton/drone-k8s-deployment. Over the next bit I'm going to look at the different configuration options for k8s deployments and what makes sense to make configurable. I haven't had time to really test it, but feel free to try it out.
Ok couple more updates since moving to 2.0, I haven't really found reasons to updates this plugin (let me know if there are any requests for rancher 2.0) however I will probably deprecate this plugin pretty soon!
I've published https://github.com/josmo/drone-k8s-job dockerhub-> peloton/drone-k8s-job (allows you to run tests inside k8s even if there are no external ingress options)
https://github.com/josmo/drone-helm dockerhub-> peloton/drone-helm (fork of the drone-helm repo) that has fixes to the upstream and I'm going to keep updates published till the upstream publishes again @loxy you might like that ;)
https://github.com/josmo/drone-k8s-deployment (this might change to look a bit more like the drone-k8s-job repo so that it can have more flexibility for knowing if it's successful and what not as well as templating)
Nice!
Thanks for the plugin @josmo , is this plugin currently supports Rancher 1.x? What if I use Rancher 2.0? Should I try https://github.com/josmo/drone-k8s-deployment?
Hi @shinebayar-g, yep currently this only supports Rancher 1.x. Feel free to try out drone-k8s-deployment and submit issues or PRs. Right now it's probably the closest feature match to the rancher plugin. I haven't really found a good use case for the Rancher plugin in 2.x since it's really k8s centric. Another good option it the helm plugin (although creating helms charts can be a bit more involved).
Also, https://github.com/kontena/mortar might be worth taking a look at, but I think it's still too early to tell how it will go :)
This only Rancher v.1.x?
Error:
2 | time="2019-03-15T08:29:18Z" level=fatal msg="Failed to list rancher environments: Unknown schema type [stack]"
@aleksey005 as of now yes. Since Rancher 2.0 is really all k8s based, I haven't found a good set of features that the Rancher plugin could do that helm or other plugins don't already do
@josmo Thank you. Api rancher makes sense to use when there are several clusters and rancher serves as a single entry point.
@aleksey005 Do you have any use cases? I can't really think of any scenario where it would save time/effort since rancher is just proxying kubectl with auth to the clusters anyways where you need to know the cluster you're deploying to. I guess a scenario where you want to deploy the same workload to clusters in different regions, but that brings about tons of other questions on partial failed deployments and what to do which would seem to be better handled in a different way ;)
I'm totally down to add 2.x capabilities here if it makes sense (and definitely accept any PRs). I just haven't seen any specific reason to yet.
@josmo It seems to me that the infrastructure of the rancher is developing and those who learn it are very easy to install the application. The drone is in the rancher app and it works out of the box, if the plugin worked, for people who have little understanding it would be easier to learn. Of course, I understand that it is not possible to do everything, but additional opportunities will never be in the way.
@josmo I'm using drone-k8s-deployment now in our tests with R2, but one big feature I'm missing vs what this plugin provides is the feedback loop on failures. Right now it seems as long as k8s accepts the update, it goes through but doesn't wait to see if there are any issues with the update itself.
As an example: a bad image goes out that causes the pods not start, in drone-rancher it would ultimately fail (since it couldn’t finish the upgrade), but in drone-k8s-deployment as far as I can tell, there isn't anything analogous.
Had the same problem that Kubernetes takes time to delete a resource (always different), maybe it's clumsy, but it works like a sleep 60 in pipeline step busybox image. Of course, it’s correct to use helm-chart to update the applications, but it takes so much preparation and time.
pipeline:
docker:
image: plugins/docker
repo: docker-registry.xxxx/test/test
registry: docker-registry.xxxx
dockerfile: Dockerfile
secrets: [ docker_username, docker_password ]
kubectl-delete:
image: komljen/drone-kubectl-helm
secrets: [ kubernetes_server, kubernetes_cert, kubernetes_token ]
kubectl: "delete -f kubernetes.yml"
sleep-60:
image: busybox:latest
commands:
- sleep 60
kubectl-apply:
image: komljen/drone-kubectl-helm
secrets: [ kubernetes_server, kubernetes_cert, kubernetes_token ]
kubectl: "create -f kubernetes.yml"
notyfy:
image: plugins/slack
webhook: https://hooks.slack.com/services/-----------
channel: monitoring
template: >
{{#success build.status}}
build {{build.number}} succeeded. Good job.
{{else}}
build {{build.number}} failed. Fix me please.
{{/success}}
@shnhrrsn I think you're correct (although I've been mostly using the helm plugin lately since I usually also need ingresses and other types as part of the deployment), When I get a chance I can try to make it work more like the job plugin where it would fail in the scenario you're talking about, which would definitely be better (Or I would totally accept a PR into that repo, if you want to make an update)
@aleksey005 Yeah, I ended up just bitting the bullet and using helm (but with local charts in the repo) that way you don't have all the overhead of hosting and publishing the helm charts. Might be a good compromise.
this plugin is not available for rancher2.X?
2 | time="2019-04-12T17:19:21Z" level=fatal msg="Eek: Must have url, key, secret, and service definied"
@zexliu Right now there isn't a clear set of feature that the plugin could do that isn't already done with the helm/deployments plugin. So this plugin is currently 1.x only
Rancher 2.0 is moving away from cattle and using k8s for everything. We should research how this will impact the drone-plugin.
If someone is testing 2.0 feel free to comment here. Otherwise I'll get around to it in the next month or so.