Editor's Note: This post was originally published by author Ken Moni of Fierce Software.
If you’ve had a look at our line card then you can probably deduce that we like Open-Source, yeah that one’s easy. We’ve partnered with some of the biggest open source leaders and really enjoy and value the relationships we’ve built over time. In fact, we just recently were awarded Public Sector Partner of the Year by the kind folk over at CloudBees !
With all the hub-bub around DevOps, I thought it only proper to shine a light on why we love CloudBees and their solutions. There are numerous reasons why we think CloudBees is great, to keep things quaint, I’ll give a few reasons why CloudBees Core is the definitive way to go when deploying Jenkins:
Turn-key deployment. Are you running a self-administered Kubernetes cluster? EKS/AKS/GKS in the cloud? Red Hat OpenShift (ooh! that’s us!)? No problem, deploying a tested and supported enterprise Jenkins platform takes only a few steps and can be done in no time flat.
Management and security. Ever wish Jenkins came with interoperability and security tested plugins? What about RBAC, built in SSL through the whole stack, and tools to manage your environments? All first-class passengers in CloudBees Core.
Container orchestration and team controllers. Break away from the massive monolithic Jenkins controller, give each team their own easy to manage the environment and have each team controller deployment live in its own container pod.
There are way too many reasons why CloudBees is the way to go when rolling Jenkins, but before we go too deep down that rabbit hole I think it best to show just how easy it is to deploy a new CloudBees Core environment on a Red Hat OpenShift Container Platform cluster! Then we’ll jump into creating a team controller and deploying a simple pipeline. I think Elvis said it best, “a little less conversation, a little action” so without further adieu, let’s jump in!
Nurse, I need 9 EC2s of Kubernetes! Stat!
We’ll be relying on the tried, tested, and trusted of Red Hat OpenShift Container Platform that is built on the security and stability of Red Hat Enterprise Linux. The OpenShift cluster will be deployed on a public cloud service, Amazon Web Service and it’s one of the easiest steps since we’ll be using the AWS OpenShift QuickStart . This is an AWS CloudFormation template that was developed as a collaboration between Amazon and Red Hat engineers and it works rather well and is properly engineered into 3 availability zones. The process takes about an hour and a half so maybe do it over lunch.
Architecture of the OpenShift Container Platform cluster in a new AWS VPS.
We’ll be deploying it into a new VPC and if you’re planning on doing the same here are a few things you’ll need in addition:
An AWS Account
A FQDN or Fully Qualified Domain Name in AWS Route 53
A Red Hat Network account with a few Red Hat OpenShift Container Platform subscriptions, which is important to know since all the documentation says is “You need an account and subscription” and not what or how many. Request a quote today .
CloudBees Core in the cloud
Now that we have a rock-solid Red Hat OpenShift cluster running across 3 AZs in AWS, let’s get to using it. We’ll be deploying CloudBees Core, front and center.
Where and how
In case you’re not familiar with CloudBees and their product catalog, they vend their solutions as many industry leaders do and that’s via subscriptions. This gives many advantages such as a lower CapEx, prevents lengthy vendor lock-in, and ensures you get the latest versions without being charged for upgrades. You can request a 30-day trial of many of their products including CloudBees Core, otherwise you know where to get the goods. Once your subscription is settled, head on over to go.cloudbees.com and grab the OpenShift installer template .
Once you’ve procured the package, you’ll need to make sure you have a few things set up on the OpenShift side of the house. You’ll need the oc command line application installed locally (or on your remote bastion host), a persistent volume available to your OpenShift cluster, and a domain in Route 53. Those requirements and the steps to install CloudBees Core on OpenShift are detailed and available in their wonderful documentation.
Client controllers, managed controllers and team controllers! Oh my!
With an enterprise-ready Jenkins deployment using CloudBees Core, we’re moving away from the large and lumbering monolithic Jenkins installs that break when you update a single plugin because it was incompatible with some other plugin that you forgot about and didn’t test for. Now, you can still use your external and previously deployed controllers and connect them to CloudBees Core. These connected controllers are called client controllers, a controller running on Windows is an example of a client controller.
Managed controllers come with many options, tools, and configuration settings if you want to get down in the weeds of setting up your Jenkins environment. This delivers a lot of flexibility and value, however, maybe you don’t want to spend the time administering your managed controllers then there’s team controllers.
An example setup of how you can plan team controllers
Team controllers make it to where every team has their own Jenkins controller which makes it even easier to create and manage continuous delivery. Team controllers allow teams to work independently and still have all the power of CloudBees Core. This means enterprise-grade security, on-demand provisioning, resilient infrastructure and easy management are all standard parts of CloudBees Core.
We’ve got this steam engine built and on the tracks, where do we go from here? This is probably one of the greatest questions in beginning CI/CD as there are endless directions you can take your DevOps platform, especially when it’s powered by Red Hat OpenShift and CloudBees Core.
There are many steps involved when building your DevOps pipeline. Bringing your developers and operations team onto the same level playing field is paramount as successful DevOps practices are part of a culture shift. Then you have to analyze your resources, catalog your applications, plan your build processes together, so on and so forth.
Once you’ve got things planned out, it’s time to get your hands dirty. Go out there, grab the trials and start testing , or ask your VAR partner (I know of a good one …) to set up a proof of concept demo and walk you through. We, in fact, can provide specially catered workshops almost anywhere, provide professional services when needed, in addition to getting you all the right solutions your organization needs so don’t hesitate to contact us !