jstrachan

OpenShift's Jenkins integration is good.

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/

invoke `make` from inside your `Jenkinfile`? :)

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

if you can't use kubernetes or containers then I guess Ansible is a fallback?

OpenShift is a fork of the Kubernetes code base: https://github.com/openshift/origin

I.e. it’s not using the upstream distribution of Kubernetes like the public cloud vendors or Heptio etc.

It’s great it’s a Certified Kubernetes though!

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!

we're using helm for installing/upgrading apps; it takes care of reverting bad versions/releases etc

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.

Agreed! Jenkins X uses Skaffold to do the docker image building so can be configured to use kaniko or Google Container Builder etc https://github.com/GoogleContainerTools/skaffold

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

Thanks! You are free to use any kubernetes cluster and install Jenkins X there: http://jenkins-x.io/getting-started/install-on-cluster/

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

That’s a great point. This blog tries to compare Jenkins X versus Jenkins 2.0: https://dzone.com/articles/jenkins-x-the-good-bad-and-ugly

It’s mostly about automation of install, configuration, environments, pipelines & promotion with GitOps and more feedback.

Just out of interest what kind of demo would you like to see?

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

It should do - in theory - it needs testing though ;).

I notice that kops recently added support for Digital Ocean https://github.com/kubernetes/kops/blob/master/docs/tutorial...

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.

I’ve raised this issue to track it: https://github.com/jenkins-x/jx/issues/705

Btw I’m the author of the above blog post & committer on Jenkins X.

So our focus is currently anyone looking to automate CI/CD on kubernetes, the cloud or any modern platform like OpenShift, Mesos or CloudFoundry which all come with kubernetes support baked in.

You can use just the CI part and do CI & releasing of non-cloud native apps if you want - we use Jenkins X to release jars, plugins & docker images using it - but doing so does miss out all the benefits of automated Continuous Delivery & GitOps promotion across environments

BTW we're hoping to make it easier to 'service link' your Preview Environments to other environments. https://github.com/jenkins-x/jx/issues/573

e.g. so you could deploy just your front end in a Preview Environment but link it to all the back end services running in the Staging or Production environment. Each team can configure their Preview environment helm chart however they wish really.

Using separate namespaces in kubernetes is a great way to keep software isolated and avoids apps interfering with each other; but at the same time its really handy to be able to link services between namespaces too.

Jenkins X creates a Preview Environment per Pull Request yeah; which can be as much or as little as you want it to be. e.g. it could be just 1 pod only or could be a suit of related apps (you may want to test multiple things together).

You can define what a Preview Environment is in the source code of your application - its just a different Helm chart really. You can of course opt out of Preview Environments completely if you wish. http://jenkins-x.io/about/features/#preview-environments

Though I've personally found them to be super useful - especially if you are working on web consoles - it lets you try out changes visually as part of the Pull Request review process before you merge to master.

whoops, great catch thanks. Hoping we can figure out a fix very soon...

The things you gain from switching to Jenkins X:

* automated CI/CD for your kubernetes based applications using Helm Charts & GitOps to manage promotions (manual or automated)

* a single command to create a kubernetes cluster, install Jenkins X and all the associated software all configured for you OOTB (including Jenkins, Nexus, Monocular etc): http://jenkins-x.io/getting-started/create-cluster/ - ditto for upgrading

* a single command to create new apps or import them via build packs to create docker images, pipelines and helm charts with GitOps promotion: http://jenkins-x.io/developing/create-spring/

* automated release notes + change logs with links to github/JIRA issues etc

* feedback on issues as they move from Staging -> Production

i.e. more automation around CI/CD and kubernetes so you can spend more time focussing on building your apps and less time installing/configuring/managing Jenkins + Pipelines

Sorry to hear you're underwhelmed! Did you check out the GitOps features for versioning all changes to all Environments in git with human approval? http://jenkins-x.io/about/features/#promotion

Or the automated feedback on releases to all your issues as they move through Environments: http://jenkins-x.io/about/features/#feedback

Or the automatic publishing of Helm charts to the bundled Monocular for all versions of your apps for your colleagues to easily be able to run via helm?

Or that it works great with GitHub, GitHub Enterprise & JIRA and has awesome integration with Skaffold?

Or easy setup a kubernetes cluster with Jenkins X on any public cloud in one command: http://jenkins-x.io/getting-started/create-cluster/