Thank you to everyone who joined us for the webinar. You can view a recording of the webinar here.
Below are the questions we received from the Q&A:
Q: Should Jenkins-Puppet comm be sync or async mode? How to configure both modes? In async, how does Jenkins know which environment Puppet deployed?
A: Mostly sync. The best strategy is to have the Puppet master(s) be Jenkins slave nodes. Jenkins can issue commands from there such as r10k runs or command and control tasks such as triggering puppet agent runs.
Q: How does puppet integrate with central authentication (such as Active Directory)?
A: Puppet Enterprise includes Active Directory support for RBAC and user management.
Q: When you say “delivering infra services” do you include the underlying baremetal infra or just the apps built on top?
A: We focus on underlying OS (network, NTP, SSH, auth, etc) and middleware application (Apache, Oracle DB, ISS, etc). While Puppet Enterprise can be used to deploy application artifacts, we find we’re not commonly used for that purpose. In the future, we will be releasing application management features in Puppet Enterprise that are intended to resolve common challenges of using Puppet Enterprise for application deployments.
Q: How to test puppet configuration through Continuous Delivery pipeline?
A: We highly recommend using Beaker, our acceptance testing framework.
Q: Where can I find info about the Puppet & Jenkins HA?
A: You can find more about Jenkins HA here.
Q: We’re a windows shop, can you cover Puppet on Windows servers?
A: Yes. We have extensive Windows coverage to manage everything to system reboots, Registry keys, IIS, MSSQL Server, DSC, and more.
Q: Is there any other technology that can replace puppet in future?
A: It’s unlikely. While there are many ways to manage application deployments such as containers, for example, there will always be the need for stateful management of the infrastructure including persistent user data stores, networking, and base OS management.
Q: Can we use puppet & CloudBees to manage application specifics settings?
A: Yes. Puppet’s built for managing any configuration for any compute systems. Puppet Enterprise can easily configure a service and ensure it’s running based on assigned roles and site specific data. Our Hiera tool and Node Classifier application make the management of application specific configuration easy and manageable by those unfamiliar with Puppet.
A2: Cloud Features.
Q: Is packaging needed for deploying build artifacts to servers?
A: It depends on what is being deployed. If its a java application, then yes but if its scripting languages, you may not need packaging.
Q: Functionality on windows seems to be limited (wikipedia). What are the restrictions?
A: That’s out of date. Puppet Enterprise’s Windows support has grown tremendously over the past year and a half. Puppet Labs takes Windows very seriously and have a dedicated team focused on continuously improving the resources we manage on Windows.
Q: How does continuous delivery work?
A: Continuous delivery is about proving any change is deployable to production when the business is ready by deploying the change to a production like environment. Automation is relied upon heavily to minimize human error as much as possible. It is an extension of the continuous integration movement. CI is about automating the testing of software builds as often as technologically possible. The next natural step is automate the deployment of the builds to a production like environment to prove the build not only functions in QA, but continues to function when deployed to its end state. This final step requires automation to manage the bits-on-disk configuration, which is where Puppet Enterprise comes in.
Q: How do you use Cloud Bees and Puppet to deploy in place to clustered servers without having downtime or version mismatch concerns?
A: We have a tool called MCollective that can be used for running puppet on cluster nodes, but restrict puppet to running on a percentage based subset at a time.
Q: How do you make the best use of these tools in today’s DevOps scenario?
A: By managing each Puppet module individually, any team within a given organization can contribute to the Puppet code and management. We recommend using Git for version control with each change utilizing the pull request method for peer review prior to inclusion in the main code base. Combined with automated testing with Beaker, teams can have early visibility when a change they introduce breaks other Puppet code. This inclusion and visibility promote a cross team management effort, enforcing a DevOps culture.
Q: How do you integrate Puppet code testing with Beaker and Jenkins?
A: Beaker provides the rspec-beaker gem, which means Jenkins can run Beaker tests just like any other set of rspec tests.
Q: I need to know more about Infrastructure as Code and the scripting languages used to make it happen.
A: The Puppet DSL is anti-scripting. It’s not a programming language as much as a configuration language. Luke Kanies, the author of Puppet and CEO of Puppet Labs, wrote a nice piece on it a few years ago: https://puppetlabs.com/blog/why-puppet-has-its-own-configuration-language
A2: Other than the Puppet DSL, we often utilize Ruby for custom types and providers in Puppet, as well as custom functions to be used in our DSL. Further, the Beaker testing framework uses ruby with rspec.
Q: Implementing a DevOps culture, how do I make the transformation?
A: I highly recommend “The Phoenix Project” book to understand the what, why and how of DevOps.
Q: What is the on-prem model pricing for enterprise Jenkins?
A: Pricing is generally based on number of Jenkins Masters and executors. Please contact firstname.lastname@example.org for further information.
Q: What are the differences between Open Source and enterprise versions?
A: You can learn more about it here
Q: What type of applications can be used to automation the deployment process. e.g. Java, nodejs, etc.?
A: Jenkins support deploying any type of applications including Java, C, C++, .NET, NodeJS etc. The automation and deployment process for each of these language varies and Jenkins provides integration with a variety of these through plugins.
Q: What are the start and End points of CI/CD?
A: CI usually starts when a developer commits code and involves additional steps such as build, unit test, code coverage and integration tests.
A2: CD builds on CI and takes the automation further adding additional stages such as functional testing, performance testing etc… and each of these stages prove certain level of code quality which eventually could be deployed to production (but not always).
Q: Will this be available offline?
Q: I would like to understand Git, Jenkins and Puppet Integration.
A: Git is fully supported as an SCM within Jenkins.
Q: Can it be integrated with JOC?
A: Jenkins Enterprise is fully integrated with JOC.
Q: How do we configure Puppet to report back to Jenkins?
A: Yes. Jenkins typically is responsible for build and promoting code from lower environments to high environments while proving certain level of code quality and puppet could take the artifacts generated and deploy it to different environments.
Q: How does puppet manage tracking of events started though puppet (logs for example)?
A: You can find more about it here
Q: How do you achieve deployment and rollback of services using puppet?
A: We don’t talk in terms of rollback, but roll forward. There are several types of changes in infrastructure that are not possible to rollback to a previous state. Instead, it’s important to understand how the process of changing something to a previous state differs than the process of changing something to a new state.
Q: How do you upgrade the version of Jenkins without downtime?
A: Using Jenkins Enterprise HA plugin its possible to upgrade with minimum downtime. You can find more information about the HA plugin here
Q: What are the differences between standalone and master/node?
A: Using a central Puppet master is important to gain visability into reporting in addition to having central inventory and node management functionality with Node Manager and PuppetDB in Puppet Enterprise.
Q: What will be difference between if I say Jenkins and Enterprise Jenkins?
A: Jenkins usually refers to the Jenkins Open source version where as Jenkins Enterprise refers to the CloudBees Jenkins Enterprise.
Q: Can I use Enterprise Jenkins freely without taking any subscription?
A: Jenkins Enterprise requires subscription but trials are available up on request.
Q: For CI I am using Jenkins. For CD should I use Enterprise Jenkins?
A: Jenkins Open Source has several plugins that can help you achieve CD as well. Jenkins Enterprise provide additional capabilities that let you scale, manage, optimize and secure your implementations.
Q: Can I use opensource Jenkins for CD?
A: Yes. There are a lot of plugins, like workflow, in the community that can help in building CD.
Q: Can I use Enterprise Jenkins without Puppet lab?
A: Yes, but if you’re doing continuous delivery of infrastructure configuration, you MUST use a configuration management tool. Puppet is de facto configuration management tool.
Q: Also, how do you integrate Xebia into this setup?
A: XebiaLabs has a plugin to Jenkins you can utilize.
Q: Is GIT the default Puppet repo?
A: r10k, our code management tool, works with SVN or git, but we find git tends to be used more successfully in customer environments.
Q: How does CloudBees keep up with the frequent Jenkins releases?
A: CloudBees Jenkins Enterprise is based on LTS release and support the same for a year.
Q: I can use Enterprise Jenkins freely but for Support do I need to pay?
A: Jenkins Enterprise requires a license to use.
Q: How do you integrate rspec testing? Is that more of a component module testing framework?
A: We highly recommend using the Puppet Labs Beaker acceptance testing framework for module testing.
— Udaypal Aarkoti
Udaypal is the Solutions Architect Director at CloudBees.
Carl is the Technical Marketing Manager at Puppet Labs, Inc.