- [Cameron McKenzie] Hi, I'm Cameron McKenzie.
I'm the editor in chief over at the service-side.com.
And I wanted to help you answer 10 of the toughest
Jenkins interview questions you might encounter.
question number one,
what are the software prerequisites for installing Jenkins?
The answer to that question is the JDK.
The only thing you need to run Jenkins is the JDK.
Since version 2.5.4, I believe it is the JDK version 1.8
or newer, but fundamentally the only thing you need
in order to run Jenkins is the JDK.
Now Jenkins is web based as a web based interface.
So there is sort of a requirement for a Servlet engine.
So if you want to take the Jenkins war file
and deploy it, you need a Tomcat server or Wildfly server,
but the war file that you can download from Jenkins
actually has the jetty server embedded inside of it.
So really if you're just using the Jenkins war file,
you don't even need a pre-existing Servlet engine
cause that's already embedded inside of the
Jenkins distribution package.
So fundamentally the only thing you need is the JDK.
But a Servlet engine certainly helps you along the way.
Question number two,
what is the syntax Jenkins uses to schedule items?
well Jenkins uses a Cron job syntax
that is four Stars,
five Asterixis.
with each ax Strix separated by a space
and those stars asterixis can be replaced by a number.
And depending on the order,
I think, what is it,
The first star represents the number of minutes.
The second is the hours,
the third, the day of the month,
the fourth, the month itself,
and the fifth day of the week.
So for example, if you wanted to schedule something
to run at 5:30, every Friday,
you would use a Cron job syntax
it looks something like
30 17 * * 4,
and that would end up running every Friday 5:30.
So name a Jenkins environment, variable you may have used?
well, there's a whole bunch of Jenkins environment variables
that are available to your script jobs.
Some items such as job name, node name, workspace,
build URL, job URL.
Those are all valid
environment variables that you'll see
inside of your Jenkins jobs.
So let just be familiar with some of those
and maybe exactly what they do,
and that'll get you through question number.
Question number four.
Name the various security mechanisms that Jenkins uses?
Jenkins has a couple of options for authenticating users.
The first is an internal database,
which it sets up automatically right when you install it.
The second is authentication against an LDAP server.
So there's an LDAP server configuration page
inside of Jenkins.
And finally, if you deploy your Jenkins war file
to a Tomcat server or a web server application server,
and that server is already configured
with an authentication mechanism,
maybe that goes to eldap
or it even uses a custom user registry,
Jenkins can piggyback off that configuration as well.
Question number five, describe the standard process
to configure and use third party tools within Jenkins?
In general.
This is the process that you would follow
if you want it to use a third-party tool,
such as no JS or sonarqube something along those lines.
So first of all,
you installed the tool.
So if you want to use sonarqube,
you have to have installed somewhere.
If you wanna use Maven,
you have to have it installed somewhere.
So make sure the product is installed.
Step number two, download the plugin.
So find the sonarqube plugin,
find the node JS plugin,
but download the plugin inside of Jenkins.
The third step is then configuring the tool.
So inside Jenkins,
there is an option to configure third-party tools.
I think it's just under managed Jenkins configure tools.
And if you've installed the tool and installed the plugin,
you usually go into that area
and point the tool to where it's installed,
or maybe the URL that you'll connect to
in order to access that resource
with some plugins, like the sonarqube plugin,
you actually do it in the system configuration option,
but basically you have to tell Jenkins where that tool is,
can be found, where it's installed
after that you then go in and you go into your bill jobs
and you actually use the plugin, maybe a checkbox
or drop down option will appear in your bill jobs.
but you can then start using those plugins.
Now there's some exceptions to that.
So for example, if you're using Checkstyle or PMD,
and you're doing a Maven build,
Maven can automatically download those products.
So you don't have to go in and do that configuration step,
but overall the four steps are download the product
and install it,
add the plugin for that particular product,
configure that product as a tool
inside of Jenkins, if that's necessary.
And then finally just use it in your builds.
Those are those four steps
in order to use a third-party tool with Jenkins.
Question number six, named two ways of Jenkins node agent
can be configured to communicate back
with the Jenkins server?
One option is just to go to the node machine,
launch a browser, and then launch the Jenkins node agent
from a browser using JNLP.
The other option is to actually just go in
and use the command line.
you can download the agent.jar file
and you can do a little Java-jar
agent.jar command
and specify the JNLP URL for the master server.
But those are the two ways to configure a node agent
to link back to the master,
launch it from a browser window,
or use the command line interface,
Question number seven.
How do you take a backup of your Jenkins build jobs
in order to prepare for disaster recovery?
And maybe that's not just disaster recovery,
but you might want to just a history of your jobs
and how they've changed
in order to do that.
All you have to do is go into the jobs folder
in Jenkins home,
copy that jobs folder.
And when you copy that jobs folder,
you'll have the configuration for all of the build jobs
that are configured inside of your environment.
So it's that jobs folder,
copy it back it up from time to time,
not a bad idea to maybe even check that
into store's code repository.
Now, the only other thing I had mentioned
is that job folder also keeps a history
of the jobs that have run.
And you may not want to back that up.
I mean, you might, it's not a bad idea
to have a history of all your Jenkins jobs.
but if you're purely looking at configuration,
you just want the XML files
in the jobs directory
under the folders whose names mapped
to the various Jenkins jobs that you have.
You may not want the whole history of the jobs
cause that's really external to the configuration,
but the answer to that question
is you back up that jobs folder
in the Jenkins home directory,
Question eight,
named three steps or stages,
a typical Jenkins pipeline might include?
a typical Jenkins pipeline would probably include
build, test and then deploy.
And so that's, you know, a fairly easy
use Maven to build the project,
run your project through a variety of
bug tests, static code analysis,
maybe some performance testing,
and then finally deploy it maybe to a Tomcat server,
maybe to a Docker container,
maybe even to a nexus Maven repository.
And of course you can even break that down further.
So, you know, there might be environment validation,
there might be user acceptance testing,
there might be a deployment to alternate server.
So you might go to nexus repository first,
and then after that go to a Tomcat server.
So there's a variety of different things
that you can include in a pipeline,
but three build, test and deploy.
That's probably the most important ones.
Question nine, how can you temperately turn off
Jenkins security if there is a problem
with the administers locking themselves out?
well, that's a fairly easy to do.
Just go in and find the config that XML file
under your Jenkins home directory,
open that up with notepad.
And you'll find a setting called use security.
If you set that to false, security gets turned off
and then you can log in in an unauthenticated manner.
Of course, don't do that too often.
(chuckles)
Don't lock yourself out.
more importantly, if you do have to use that little trick,
make sure you turn security back on
after you've fixed your security problems.
And question number 10.
Pulling a get repository for new commits
is considered an anti-pattern.
what is a better alternative to polling your repository?
yeah, we don't like to constantly be polling
the source code repository and saying,
Hey, is there a new commit?
Is there a new commit?
it's a, just a, a waste of resources
I mean, it's as simple as that.
So a better option to doing that
is instead of having Jenkins poll source code repository,
what you do is you install something called
a post commit hook on your source code repository
and your get server or your get hub installation.
And any time a commit happens to a branch
that you're interested in building
that particular commit after it's done
it then triggers the Jenkins build
probably by invoking the build URL
and triggering the bill that way.
But yeah, that's a, an anti-pattern
we don't like to constantly
pull our source code repositories
instead have the source code repository kickoff the build
when a new commit has happened to that particular branch.
And there you go,
those are 10 tough Jenkins interview questions.
Make sure you can put those answers into your own words,
if you disagree with some of my answers,
make sure you know why you disagree
and you can articulate that.
And if you can do I have no doubt
that you'll land that new important Jenkins devops job.