Running Jenkins in a hybrid mode
One of the upcoming patterns of usage with Jenkins is where an on-premise Jenkins master has a mix of slaves on-premise and in the cloud. The Amazon EC2 plugin is a good example of it. However the issue with the plugin is that you end up paying for an hour regardless of the usage. The CloudBees Cloud Connector plugin lets users use CloudBees DEV@cloud slaves seamlessly from their Jenkins masters and since CloudBees bills by the minute, you pay for what you use.
Too many jobs, not enough slaves...
If you're already a user of the CloudBees Free plugins, then you're probably already familiar with our "Wasted Minutes" plugin:
It's a plugin that simply tracks how much time a job spends waiting in a queue for an available executor. If your jobs are consistently racking up a lot of queue time, then that's a sign that your master needs a few more executors.
However, many organizations simply don't have enough resources to allocate additional build machines. Instead of suffering an inefficient master, these organizations will now have the option to offload certain jobs to a CloudBees-managed slave pool.
How Jenkins cloud bursting works
CloudBees is offering an open-source Jenkins plugin that allows both open-source Jenkins and Jenkins Enterprise installations to "rent" slaves on-demand from DEV@cloud . This slave pool is comprised of Linux and OSX/iOS slaves.
While some organizations can use this plugin to simply offload some of their build and test jobs to our Linux slaves, others can automate their mobile development with our virtualized iOS/OSX cloud. Our cloud slaves use virtualized containers (LXC) to multi-tenant applications on our infrastructure:
For a tutorial on how to use slaves in the cloud with on-premise Jenkins, check out the guide in the CloudBees Developer Wiki.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.