Webinar Q&A: How to Deliver Applications Six (or More) Times Faster with Jenkins and Continuous Delivery as a Service

This webinar was delivered on March 9th, 2016 by Dan Juengst and Kal Vissa. The following are questions we received during the session with answers supplied by several of our engineers who were a big part of the creation of the CloudBees Jenkins Platform - Private SaaS Edition (Carlos Sanchez, Derek Yama-Dang, Kal Vissa, Fabian Donze and Ryan Campbell).

1. FEATURES

Q: Are there any modules to enable Jenkins SSO in the organization with AD?

A: Yes, you can use any Jenkins existing plugins in Private SaaS Edition. CloudBees Jenkins Operations Center provides single sign-on across masters and you can use the Active Directory plugin to connect your cluster with AD.

Q: Can all the configurations of Jenkins Master/slaves have a history? Or, how easy it is to integrate SCM with Jenkins config on this new version?

A: Jenkins does maintain a history of all job configurations. The job configurations are stored under the $JENKINS_HOME directory for each Master (Slaves do not store any “config” data). With the Private SaaS Edition, the $JENKINS_HOME of each Master is automatically backed up (user can decide where to store the backup data - NFS or EBS). SCM integrations are unaffected with the Masters that are created on Private SaaS Edition (meaning, there’s no change in functionality compared to the current CloudBees Jenkins Enterprise Edition).

Q: Do I have to go on each master to see the logs?

A: Logs from the different components of the Private SaaS Edition, Jenkins Master being one, are all consolidated under the “Logs” tab, which is located in the CloudBees Jenkins Operations Center UI. You can select for log entries from various masters here.

Q: Is there a way to see what version of the docker image a master is running (as opposed to the jenkins version)?

A: Yes. This information is in the “Configure” UI, under the “Provisioning” section.

 

Q: Is there a way to ‘template’ a master with some pre-configured items?

A: Yes. This is actually what is being done by Private SaaS Edition, where special Docker images to be used by masters accompany releases.

You can create a Docker image extending the one we provide and add items in the default Jenkins home.

Q: Is there any way to support users requesting their own master without giving them control of all masters?

A: You can use the Role-based Access Control plugin to achieve this. Here is an example.

Q: What if a Jenkins master update fails? Is there a rollback mechanism?

A: Yes. This is done through the use of Docker images.

Yes, the master runs as a Docker container and can easily be rolled back to a previous version. Data is preserved.

2. WINDOWS SUPPORT

Q: Does the Dynamic Agents feature support Windows slaves?

A: Not at this time. However, you can still create Windows shared slaves attached to the CloudBees Jenkins Operations Center in Private SaaS Edition which are shared among Private SaaS Edition-hosted client masters.

3. CLOUD PROVIDERS SUPPORT

Q: Are there plans to support CloudFoundry?

A: We are going to evaluate additional IaaS/PaaS platforms tthat the Private SaaS Edition should be integrated with. 

4. MIGRATION PROCESS

Q: Does this link existing Jenkins masters, or does this migrate them onto the private cloud monitored by the Private SaaS Edition Operations Center?

A: It links to existing Jenkins masters. You can then move or copy items across masters in order to move your workload to the Private SaaS Edition cluster.

5. ARCHITECTURE

Q: If the masters are running as Docker containers, is the JNLP port mapped out so that the CLI and webstart-based slaves can connect?

A: JNLP ports are mapped, SSH ports (required for CLI usage) are not yet available.

Q: How does the configured number of compute instances relate to the automatic spin-up of Mesos agents?

A: Private SaaS Edition infrastructure elements are managed using the CLI. Each compute instance corresponds to a Mesos slave. Jenkins masters and jobs get allocated on worker nodes (==compute instances) based on available resources on those nodes.

Each compute instance (worker) gets a Mesos slave service installed and is used to provision masters or slaves dynamically.

Q: We currently have our Jenkins running inside VPC on AWS, any impact to VPC based installs?

A: Private SaaS Edition can be configured to run in its own VPC on AWS.

Q: Where will Jenkins Operations Center be running if we have Private SaaS Edition?

A: CloudBees Jenkins Operations Center will be running in the same infrastructure that is provisioned by the Private SaaS Edition installation process

Q: Please explain more on failover capability.

A: Each master content (JENKINS_HOME) is persisted to a storage layer on a regular basis. We check the health of each master and if one of them becomes unhealthy, it is reprovisioned automatically with the latest persisted data. If a whole worker in the cluster fails, all the masters running on it are reprovisioned on other nodes in the cluster, provided you have provided enough spare capacity to your cluster. You can add new capacity to the cluster as you need it, the new nodes will be used as soon as new slaves or masters are requested.

Q: What about the underlying instances… does Mesos take care of scaling out?

A: See above answer.

The number of the EC2 instances (workers) is set when you install but new ones can easily be added/removed with a single command initiated by the Private SaaS Edition admin.

Q: Is there an API for provisioning masters? Is that API documented somewhere?

A: There are new commands available through the Jenkins CLI as well as rest endpoints to do these actions.

Q: As far as I know, Docker containers have to be provisioned inside of an EC2 instance on AWS. So, do all masters / agents share a single big EC2 or can I spread them?

A: Some Jenkins masters and jobs share an instance (a worker node). There are many worker nodes in a Private SaaS Edition infrastructure.

The Docker containers are spread among all instances of the cluster (on AWS or Openstack).

6. UNCLASSIFIED

Q: Does DEV@cloud offer the enterprise features as well?

A: No. DEV@cloud provides users with the latest Long Term Support (LTS) version of Jenkins open source.

Q: Is it possible use to Jenkins as a Service on AWS and use it only for continuous integration not continuous delivery?

A: Yes, you can create any types of jobs you want.

Q: What version of the ECS plugin are you using?

A: We don’t use the ECS plugin, we rely on the Mesos plugin to provide build executors on masters.

Q: Are we using built in analytics of CloudBees Jenkins Operations Center or external? What is the performance impact if you are running built-in CloudBees Jenkins Operations Center analytics?

A: CloudBees Jenkins Operations Center analytics in Private SaaS Edition uses Elasticsearch nodes parts of the cluster but not the Elasticsearch embedded in the CloudBees Jenkins Operations Center instance. These Elasticsearch nodes are hosted in the Private SaaS Edition cluster, but are “External Elasticsearch” endpoints from the perspective of CloudBees Jenkins Operations Center.

Q: Is there any option for CloudBees to host, instead of our enterprise doing the hosting?

A: No. We don’t manage the full service. We provide the platform - the Private SaaS Edition. You will need to procure your own OpenStack or AWS accounts. We do, however, have managed services partners we could recommend via our alliances / channel program. Please contact us for more information.

Q: How do you provision plugins?

A: One can use the Cluster Operations to upgrade plugins on all (or some) masters running in the Private SaaS Edition infrastructure.

Q: A main issue is updating Jenkins and the plugins. Is there a concept of updating? Green/blue updates?

A: See above response.

Q: How to avoid master hell? Plugin version hell?

A: Use Folders to manage groupings of masters. Use Cluster Operations to manage plugin versions. Quite painless.

Blog Categories: 

Add new comment