There're some Drone plugins for integration with K8S:
Drone-Kubernetes: upgrade a Kubernetes deployment with a newer version of an image.
Do as kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Drone-Kube: apply a Kubernetes manifest file.
Do as kubectl apply -f deployment.yaml
Helm: install or upgrade a helm release.
Do as helm upgrade --install RELEASE CHART
Kubernetes CD Plugins: Similar to kubectl apply
ElasticBox Jenkins Kubernetes CI/CD Plug-in: deploy & delete Helm charts
they provide support for kubectl set image
, kubectl apply
, helm upgrade/delete
We can provide the following functionalities by adding more step types to do deployment on K8S:
- Upgrade workload images (similar to
kubectl set image
) - Apply(create or upgrade) workloads
- Apply(create or upgrade) loadBalancers (similar to
kubectl apply
) - Upgrade Helm/compose catalog( Hold on now untill related part is implemented)
For consistent user experience, other than reading some yaml config files from the repo( it can be an advanced option though), in step settings we use the same UI as workload/catalog deploy/edit pages.
Prototype images are shown in the following link:
https://4kmzpd.axshare.com/#g=1&p=new-pipeline , password: rancher@123
- Use selectors to choose workloads to upgrade
- Specify image to upgrade
- Similar UI of
Deploy Workload
page - Can choose an existing workload as the template or start from scratch.
- Similar UI of
Add Ingress
page - Can choose an existing ingress as the template or start from scratch.
- similar UI of
Launch App
page - Can choose an existing Helm release as the template or start from scratch.
- A pipeline can do deployment to its own project namespaces.
- What resources can be deployed should be in accord with the pipeline creator's project permissions. For example, a pipeline can upgrade workload images or workloads if the creator has
Manage Workload
Project permission.
-
Do we need to provide support to split CI and CD workflow?
Say, team A setup a CI pipeline , team B setup a CD pipeline that is not triggered by github webhook(some generic webhooks maybe). For now, everything starts from the source code repo.
-
Need to investigate more to see how the same set of agents respects for different permissions of the pipelines.
question number 4.1 I would say, yes at some point. It would be nice if a docker hub image push or something could trigger a deployment. I wonder though if thats more of just a webhook type that watches a deployment. Similar to 1.6