Though its even cooler to use Jenkins X on OpenShift as you get automated CI/CD pipelines + Environments, Preview Environments on Pull Requests and GitOps based Promotion between environments.
even from an OSS goals perspective I'm looking forward to seeing better alignment, reuse and interoperability between Jenkins, Jenkins X & things like CodeShip & Knative Build
BTW we use the kubernetes credentials provider plugin in Jenkins X which exposes Kubernetes Secrets as Jenkins Credentials; then the `credentials` step in the `Jenkinsfile` encrypts them from any build logs
if you are happy to use Kubernetes then if you switch to Jenkins X you never need to configure a Jenkins server or create a groovy based DSL again: https://jenkins-x.io/
Jenkins X can help compete effectively with other tools since it automates your entire CI/CD; from creating the Pipelines, setting up your Environments, creating Preview Environments on each Pull Request and then performing GitOps based promotion through your Environments on each release.
I'm looking forward to seeing the Jenkins ecosystem expand to offer similar automated CI/CD for other platforms too (e.g. Terraform / Ansible / VMs etc)
one solution to the problem, if you are building apps for kubernetes is to use Jenkins X which automates all your CI/CD pipelines: https://jenkins-x.io/
yeah, I see 'plugins' being around for a while but docker steps becoming the more cloud native long term alternative; being more reusable stand alone & not requiring changing a Jenkins Master (or even requiring a Jenkins master for ephemeral build pods)
I think as part of the new Jenkins architecture we should be able to make it much easier to stop at a point in a pipeline & open a terminal/REPL to test out steps.
Also I'm hoping for a nice validated YAML based pipeline syntax that should make editing/validating pipelines easier
OpenShift is Red Hat's supported fork & distribution of Kubernetes - so its another platform we can install and use Jenkins X on.
OpenShift also includes some Jenkins support; e.g. you can add BuildConfig resources via a YAML file in the OpenShift CLI which will create a Jenkins server and a pipeline. But Jenkins X isn't yet integrated into OpenShift - but its easy to add yourself for now :)
If you are pondering which kubernetes cluster to try for developing Spring services: OpenShift is a good option if you are on premise. If you can use the public cloud then GKE on Google is super easy to use; AKS on Azure is getting there & EKS is looking like it will be good if you use AWS.
On the public clouds the managed kubernetes services are looking effectively free; you just pay for your compute + storage etc. So its hard to argue with free + managed + easy to use kubernetes - if you are allowed to use the public cloud!
Jenkins X runs in containers on kubernetes and all the builds are done in containers. You can use whatever pod template (collection of docker images) in your CI/CD pipeline:
http://jenkins-x.io/architecture/pod-templates/
Yes we can support things like parallel steps & tests spinning up separate clusters, namespaces or environments (we do this ourselves to test Jenkins X).
We delegate to an OSS tool called Skaffold to actually build docker containers that gives us the flexibility to use different approaches for docker image creation (e.g. kaniko or Google Container Builder or use the local docker daemon etc)
https://github.com/GoogleContainerTools/skaffold
Using Kubernetes as an engine for orchestrating containers works very well - thats kinda what Kubernetes was designed for. Though you are free to extend & integrate tools like ActiveMQ into Kuberenetes if you think it'll help your use cases.
Each environment is in a separate namespaces. You can add/edit/delete the Environments to use whatever namespaces you wish to use.
Promotion is either automatic or manual. By default Staging is automatic and production is manual. You can manually promote any version to any environment whenever you wish: http://jenkins-x.io/developing/promote/
For promotions we're delegating to the git repository for RBAC; so you can setup whatever roles you want for who is allowed to approve promotions & if you need code reviews etc
The default is to use separate namespaces in kubernetes for each teams developer tools & pipelines, Staging & Production environments (plus Preview Environments). Multiple teams can obviously use the same cluster with different namespaces.
We’d expect ultimately folks may want to use a separate cluster for development & testing to Production. GitOps makes that kind of decoupling pretty easy but we’ve still work to do to automate easily setting up a multi-cluster approach:
https://github.com/jenkins-x/jx/issues/479
Thanks for your feedback. We are trying to make things simpler with Jenkins X by using best of breed tools (git providers, issue trackers, cloud services, service meshes, security & code quality tools etc) with best of breed OSS tools like kubernetes, helm & skaffold to automate CI/CD on the cloud & kubernetes.
One of the big changes to traditional Jenkins is we don’t expect folks to have to configure Jenkins, add/remove/edit plugins or even write Dockerfiles or Jenkinsfiles.
If you really wanna do that Jenkins X won’t stop you - but we are trying to help automate and simplify CI/CD through standard tools, standard file formats (Dockerfile, Jenkinsfile, skaffold, helm etc).
Is the cloud, kubernetes, docker, helm & istio complex? Sure - but our goal is to simplify, automate & avoid folks having to look at all that detail.
It’s still early days and a challenge. Eg even Lambda & the AWS API Gateways is complex. But we hope to keep improving to make things easier to use & to help folks go faster by providing automated CI/CD as a service on any kubernetes cluster / cloud
So we should be able to add a command `jx create cluster do` for using kops on DO - the current `jx create cluster aws` uses kops under the covers to spin up the kubernetes cluster.
Though its even cooler to use Jenkins X on OpenShift as you get automated CI/CD pipelines + Environments, Preview Environments on Pull Requests and GitOps based Promotion between environments.