kedgeproject / kedge

Kedge : Simple, Concise & Declarative Kubernetes Applications
Apache License 2.0
298 stars 41 forks source link

Start using kedge in fabric8 pipelines #332

Open surajssd opened 7 years ago

surajssd commented 7 years ago

Since now we have support to do builds using kedge like @jstrachan suggested. Also we have support for doing parameterization in the kedge file.

Now what are the next steps, to make sure kedge is used in fabric8 pipelines?

jstrachan commented 7 years ago

great stuff ;)

probably the best place to start is creating a fork of a quickstart - such as for .Net or go:

then adding a sample pipeline:

then trying to import it into a fabric8 installation on minikube/minishift via the import UI.

Then we'll have the pipeline usable inside fabric8 but without kedge. From there we can then experiment on the Jenkinsfile and the associated pipeline library (we could fork that too and refer to the fork in the first line of the Jenkinsfile) to gradually move it to kedge. When thats all done we can submit the Jenkinsfile back to https://github.com/fabric8io/fabric8-jenkinsfile-library/ and submit any changes required to the https://github.com/fabric8io/fabric8-pipeline-library/ - then kedge will be integrated into fabric8's distro ;)

To build we're currently using a function called performCanaryRelease e.g. https://github.com/fabric8io/fabric8-jenkinsfile-library/blob/master/dotnet/ReleaseStageApproveAndPromote/Jenkinsfile#L19

we could update that implementation to invoke kedge instead - or add a new function which is similar but builds via kedge?

Right now we're trying to figure that out in the pipeline library and delegate to docker or oc binaries https://github.com/fabric8io/fabric8-pipeline-library/blob/master/vars/performCanaryRelease.groovy#L21

But using kedge might be a nicer way to put all that build-technology integration code (docker / s2i binary builds / openshift docker builds / google container builds) in one simple CLI using a ConfigMap / env var to switch between them.

Then there's the applying of the kubernetes YAML to Stage or Run environments; thats where we'd take the kedge YAML and use the kedge CLI to apply it to an environment.

Right now the pipeline library uses a kubernetesApply() function https://github.com/fabric8io/fabric8-jenkinsfile-library/blob/master/dotnet/ReleaseStageApproveAndPromote/Jenkinsfile#L30 which tries to find a local YAML and if not generates one from the current docker image. Here we'd want to use a kedge yaml file if its there or a vanilla k8s YAML if not etc.

We've a few options here on the implementation side of things; we could make kubernetesApply() detect kedge files and then invoke the kedge binary to generate/post process the YAML before applying it; or delegate completely to kedge for the generation + apply.

One thing kubernetesApply() does right now is also invoke exposecontroller via this code which annotates Services with their external URL (which is handy for consoles and tools like '(gofabric8|minishift) service foo' - but it also can be used to inject into ConfigMaps the real runtime public URLs of services (e.g. so a git providing service can tell users what URL to clone from, or to point services at the public keycloak endpoint or whatnot).

We could get the kubernetes-pipeline-plugin to add a separate exposecontroller step in the pipeline so that we don't have to reuse exposecontroller inside kedge; or just put that logic into kedge? Or maybe its simplest for kedge to just invoke exposecontroller as part of its apply (if its on the PATH)? Thats kinda all we do in the pipeline step https://github.com/jenkinsci/kubernetes-pipeline-plugin/blob/master/devops-steps/src/main/java/io/fabric8/kubernetes/pipeline/devops/ApplyStepExecution.java#L328

One other pending issue we have is the kubernetesApply() is meant to wait X millis for the new deployment versions to be deployed and then fail the build if not - with a nice error message of why the build failed. e.g. if you are out of quota or there's a missing ConfigMap / Volume / Secret or whatnot - or the environment variables are messed up so that the pod terminates on startup etc. Again this might be something we want to add to kedge since its got a good idea on what the app is - plus kedge can do its best to pre-validate environment specific dependencies exist before it tries to apply something. There's also the possibility for kedge to roll back changes if a new apply/promote fails? By exporting the resources to files on disk first before updating them. e.g. so if a new version fails to run, it just reverts the resources to their previous resources.

pradeepto commented 7 years ago

Linking https://github.com/kedgeproject/kedge/issues/223 because it seems related.