DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Deployment
  4. Exploring Jenkins X: The Benefits of Encapsulation

Exploring Jenkins X: The Benefits of Encapsulation

Until the new edition of Helm comes out to remove the Tiller component, there's nothing for it but encapsulation.

Nicolas De Loof user avatar by
Nicolas De Loof
·
Feb. 11, 19 · Opinion
Like (1)
Save
Tweet
Share
10.42K Views

Join the DZone community and get the full member experience.

Join For Free

I’m switching to a “Developer Relations” role at CloudBees. In doing so, my main focus will be to help promote Jenkins X and explore new areas of usage.

So, in the past few days, I’ve been experimenting with Jenkins X, creating various configurations (please remind me to submit an expense report with my Google Cloud bill). The primary goal for sure is for me to be able to run demos. However, this is not my way. I need to understand the internal plumbing, so I can understand why things have been done and what architectural idea is behind this code.

So, I’ll probably publish a few more articles on my thoughts, as I discover some stuff, playing with Jenkins X. Today let’s just focus on encapsulation.

Beer also gets encapsulated. This seems to demonstrate this is a must-have pattern, right?

Jenkins X's opinionated approach to CI/CD uses Helm to deploy Kubernetes applications. Not surprisingly, Helm is a highly popular “packaging system” for the Kubernetes ecosystem, hosted by the Cloud Native Computing Foundation (opinionated doesn’t necessarily mean exotic choices!).

So, the deployment pipeline at some point is expected to call the helm install command. Let’s now look at some interesting debates on the Helm architecture.

Helm was initially created as an equivalent for Homebrew (the missing package manager for macOS), targeting Kubernetes applications. It was intended to provide a simple way for an application developer to define the configuration to apply to a Kubernetes cluster, using file templates. The Helm 2 architecture (current release as I’m writing this article) is split into a Helm client (command line) and a cluster-side agent: Tiller. The latter exposes an API to the client, that applies the templates and updates cluster resources accordingly.

The primary issues with this architecture is that the Tiller component is both a single point of failure and a major security threat. In order to do its job, Tiller has to run with privileged API access to the cluster. In the meantime, Kubernetes has evolved to include RBAC and audit capabilities, so Tiller in this context becomes sort of a “kubernetes-sudo” that could act out of control. For this reason, Helm 3 architecture has been revisited to avoid this flaw: Helm 3 will be Tiller-less.

Right, So What?

Should we just wait for Helm 3? If not, how do we avoid being at risk in the meantime?

Jenkins X's answer is to offer a--no-tiller option. The actual implementation is to encapsulate all Helm operations within jx step helm. When run with no-tiller, this step executes Tiller locally so the template is applied client-side, as part of the jxcommand execution.

Back to my point: benefits of encapsulation.

Jenkins X already provides a Pipeline abstraction for application deployment. You don’t have to write a Jenkins pipeline script to use Jenkins X, as build-packs will provide a standard one for you, based on your selected application stack. Jenkins X pipeline mostly relies on jx step … commands. This encapsulation offers an opportunity to change implementation details, integrate with other components, all without the need to update existing Pipelines.

The Helm step for JX, using encapsulation and abstraction of the invocation of the Helm command line, allows Jenkins X to implement the templating client-side, and only run a standard kubectl apply on the resulting configuration files. From a user’s point of view this is fully transparent, but from the cluster point of view, RBAC security checks will apply.

Once Helm 3 is ready for production, Jenkins X will be able to adopt it and the Helm step implementation will be updated without requiring any change to your existing pipelines. Encapsulation also gives Jenkins X the opportunity to offer some to-be-defined options to experiment with the Helm 3 CLI once some release candidates are available, using the exact same pipelines. This will offer a very simple way to verify that Helm 3 does not break existing pipelines, and it gives us as a developer community the chance to report issues to the Helm developers before their final release.

Additionally, this encapsulation offers an option to plug other tools in the templating process. For example, Kustomize could offer some extra templating capabilities.

Generally speaking, Jenkins X is an integration project that assembles many Kubernetes-related projects together, in a pre-configured fashion to offer a full-featured continuous delivery solution. However, a major issue is the dependency on upstream projects to implement the required features. Encapsulation is a very powerful pattern that offers more flexibility, workarounds, and the ability to experiment with new solutions, without impacting the end-user.

Jenkins (software) Encapsulation (networking) Kubernetes Pipeline (software) application cluster Continuous Integration/Deployment Cloud native computing Architecture Package manager

Published at DZone with permission of Nicolas De Loof, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The Enterprise, the Database, the Problem, and the Solution
  • New MacBook Air Beats M1 Max for Java Development
  • Internal Components of Apache ZooKeeper and Their Importance
  • AIOps Being Powered by Robotic Data Automation

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: