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).
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 controllers and you can use the Active Directory plugin to connect your cluster with AD.
Q: Can all the configurations of Jenkins controller/agents 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 controller (agents do not store any “config” data). With the Private SaaS Edition, the $JENKINS_HOME of each controller is automatically backed up (user can decide where to store the backup data - NFS or EBS). SCM integrations are unaffected with the controllers 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 controller to see the logs?
A: Logs from the different components of the Private SaaS Edition, Jenkins controller 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 controllers here.
Q: Is there a way to see what version of the docker image a controller 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 controller 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 controllers 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 controller without giving them control of all controllers?
A: You can use the Role-based Access Control plugin to achieve this. Here is an example.
Q: What if a Jenkins controller update fails? Is there a rollback mechanism?
A: Yes. This is done through the use of Docker images.
Yes, the controller 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 agents?
A: Not at this time. However, you can still create Windows shared agents attached to the CloudBees Jenkins Operations Center in Private SaaS Edition which are shared among Private SaaS Edition-hosted client controllers.
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 controllers, or does this migrate them onto the private cloud monitored by the Private SaaS Edition Operations Center?
A: It links to existing Jenkins controllers. You can then move or copy items across controllers in order to move your workload to the Private SaaS Edition cluster.
Q: If the controllers are running as Docker containers, is the JNLP port mapped out so that the CLI and webstart-based agents 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 agent. Jenkins controllers and jobs get allocated on worker nodes (==compute instances) based on available resources on those nodes.
Each compute instance (worker) gets a Mesos agent service installed and is used to provision controllers or agents 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 controller content (JENKINS_HOME) is persisted to a storage layer on a regular basis. We check the health of each controller 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 controllers 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 agents or controllers 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 controllers? 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 controllers / agents share a single big EC2 or can I spread them?
A: Some Jenkins controllers 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).
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 controllers.
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) controllers 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 controller hell? Plugin version hell?
A: Use Folders to manage groupings of controllers. Use Cluster Operations to manage plugin versions. Quite painless.
Stay up to date
We'll never share your email address and you can opt out at any time, we promise.