How CloudBees used Containers to Transform Jenkins into a Service
“As the use of Jenkins grows and grows, the ability of administrators and DevOps folks to keep up with that demand is getting out of control,” said André Pino, the vice president of marketing for CloudBees.
On Tuesday, CloudBees unveiled a cloud-based version of its commercial Jenkins. The very fact that this Private SaaS Edition is being delivered “as-a-service” speaks to the large number of use cases within organizations where cloud-based continuous integration/continuous delivery (CI/CD) is not only convenient but feasible. “What this product provides is a way for them to offload a Jenkins delivery environment as-a-service,” Pino continued.
CloudBees customers, said Pino, asked for a way to spin up a Jenkins and spin it back down. Put another way, they wanted CI/CD that was as scalable as the work they’re doing, and they weren’t getting it from the fixed fortification that Jenkins on-site had become.
CloudBees has found that these objectives can be more easily achieved through the use of containers and a microservices architecture.
Under the covers, Jenkins Private SaaS uses Docker containers, explained Dan Juengst, Docker’s senior director of product marketing. “The Mesos orchestration engine to manage all these containers. The front-end is what we call Jenkins Operations Center, and there’s a button on it that says, ‘Create a new master.’ So when the project team pushes the master button, the Mesos orchestration engine will spin up a new Docker container with the Jenkins master installed, and that team can start using it immediately, within minutes.”
Traditionally, CI/CD has been sold to organizations as a top-down, executive-driven ethic that has to be enforced from the upper levels of the corporate hierarchy. Yet many small, agile development teams within the largest of its customers are needing instantaneous, ephemeral CI/CD platforms for individual jobs, rather than end-to-end corporate job control. This is change management from the other end of the organization — what an executive might perceive as “bottom-up” change.
Containers First
In its initial form, Juengst told us, Private SaaS edition will be tailored for OpenStack deployments and Amazon AWS. An environment where first-generation virtual machines are in place is “not an ideal candidate for it,” said Juengst. “But if they can stand up an environment, or take advantage of AWS to run Private SaaS Edition, they can still run their applications and do the rest of their IT work in vSphere and virtual machines. That’s kind of independent from us.”
Azure-based deployments, as well as conventional VMs, are on CloudBees’ “to-do list” for future enhancements, according to Juengst.
“The beauty of containerization is that it provides a level of abstraction from the underlying system,” stated CloudBees VP Pino, “so that we can create an infrastructure utilizing containers that can be easily adapted to multiple underlying configurations. That alleviates a lot of the custom work that previously was required, to adapt it to these configurations.”
Juengst added a bit more detail here: In the existing Jenkins Enterprise Edition, a feature called hot standby lets CI/CD servers fail over to bypass servers without an apparent service interruption. This takes a bit of administration effort and an extra server, but it works. In Private SaaS Edition, which is container-based, an entire redundant standby server becomes unnecessary, because functions are replicated at a more granular level, scaling up and down on-demand.
“Mesos itself has the capability to monitor all the containers that are running in its own environment,” explained Juengst. “And if a container happens to disappear or crash, then it knows to spin that container back up instantly. If a build node is running a job and it crashes, Mesos will generally spin it back up and restart the job, and off it goes.”
Docker is a sponsor of The New Stack.
