Jenkins Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 20: Line 20:


An agent, also known as a "build agent", is the runtime that executes the build. An agent can be a host, virtual machine or a container. Agents to execute a [[#Build|build]] may be selected with a [[Jenkins Job Label Expression#Overview|label expression]], specified in the [[#Job|job]] configuration. The agent connects to a [[#Master|master]] and executes tasks when directed by master.
An agent, also known as a "build agent", is the runtime that executes the build. An agent can be a host, virtual machine or a container. Agents to execute a [[#Build|build]] may be selected with a [[Jenkins Job Label Expression#Overview|label expression]], specified in the [[#Job|job]] configuration. The agent connects to a [[#Master|master]] and executes tasks when directed by master.
===Label===
Agents are grouped using labels, which is user-defined text indicating similar functionality or capability. Also see: {{Internal|Jenkins Job Label Expression|Label Expressions}}


==Agent Cloud==
==Agent Cloud==

Revision as of 07:21, 20 December 2019

External

Internal

Artifact

An artifact is an immutable file generated during a build or a pipeline run. The artifact is archived onto the master for later retrieval by users. Usage of artifacts can be tracked globally across multiple pipeline or projects via the artifact's fingerprint.

Node

A machine which is part of the Jenkins environment and capable of executing pipelines or projects. Both the masters and agents are considered to be nodes. To view the list of nodes, go to Manage Jenkins → Manage Nodes. The master(s) and the worker nodes are listed there.

Master

Agent

An agent, also known as a "build agent", is the runtime that executes the build. An agent can be a host, virtual machine or a container. Agents to execute a build may be selected with a label expression, specified in the job configuration. The agent connects to a master and executes tasks when directed by master.

Label

Agents are grouped using labels, which is user-defined text indicating similar functionality or capability. Also see:

Label Expressions

Agent Cloud

A cloud is a system configuration that provides dynamic agent provisioning and allocations. Example of clouds are Amazon EC2 cloud, Amazon EC2 Container Service cloud, Azure VM agents, etc.

Amazon EC2 Cloud

The cloud of agents consists of Amazon EC2 instances, provisioned and managed by the "Amazon EC2" plugin. For more details, see:

Amazon EC2 Plugin

Amazon EC2 Container Service Cloud

The cloud of agents consists of ECS containers, deployed in an ECS cluster. The agent cloud is managed by the (incorrectly named) "Amazon EC2 Container Service" plugin. For more details, see:

Amazon EC2 Container Service plugin

Amazon SpotFleet

Azure VM Agents

Worker

Equivalent with agent, the master needs workers to execute specific parts of a build pipeline.

Docker Plugin Agent

Docker Plugin Agent

Executor

An executor is a slot for execution of work defined by a pipeline or project on a node. A node may have zero or more executors configured which corresponds to how many concurrent projects or pipelines are able to execute on that node. An executor can be thought as a single “process ID” or as the basic unit of resource that Jenkins executes on the node (in most cases the node is an agent) to run a build. An executor allows a build to run on an agent.

Slave

Job

A job is a deprecated term, synonymous with Project. A single execution of a job results in a build.

Jobs can be created from the UI and they show up on the dashboard, in the main table. A job state is maintained in $JENKINS_HOME/jobs/<job-name>. The job directory contains a config.xml and a "builds" subdirectory, which contains build state. The state include links to "lastFailedBuild", "lastStableBuild", "lastSuccessfulBuild", "lastUnstableBuild" and "lastUnsuccessfulBuild".

A job can be configured with Jenkins -> job -> Configure.

A job's configuration contains the following:

  • General Configuration
  • Source Code Management configuration
  • Build Triggers
  • Build Environment
  • Build definition - usually a shell command.
  • Post-build actions.

Each job has its own security context.

Build

A build is the result of a single execution of a project (job). The build belongs to the job.

Items

pipelines, projects and folders are items.

Folder

pipelines and projects can be organized in folders, which is an organizational container for items, similar to folders on a filesystem.

Project (Freestyle Project)

A project is a user-configured description of work which Jenkins should perform, such as building a piece of software, etc. Projects are the same as jobs.

Pipeline

https://jenkins.io/doc/book/pipeline/overview/

Pipeline Overview

A Jenkins Pipeline is a suite of plugins that implement a continuous delivery pipeline. When integrated with OpenShift, the Jenkins Pipeline functionality provides the engine for OpenShift Pipeline builds. More details about OpenShift Jenkins pipeline are available here OpenShift Jenkins Pipelines.

Pipelines are expressed in Jenkins via the Pipeline DSL syntax (see below). The definition is written into a Jenkinsfile, or declared in the Jenkins UI.

The pipeline code defines the entire build process, which typically includes stages for building the application, testing it and delivering it.

A rendering of the pipeline execution is available by navigating to a build then picking "Pipeline Steps" from the left menu.

Jenkinsfile

https://jenkins.io/doc/book/pipeline/jenkinsfile/

Jenkinsfile contain the definition of the pipeline. It is usually committed in the project source code repository - this makes the CD pipeline to be treated as part of the application to be versioned and reviewed like any other code.

A Jenkinsfile can be written with two types of syntax: declarative (newer and recommended) and scripted.

Pipeline Node

A node is a machine. It is part of the Jenkins environment and it is capable of executing a pipeline.

Pipeline Stage

A stage defines a conceptually distinct subset of tasks performed through the pipeline (e.g. "Build", "Test", "Deploy").

Parallel Stage

Pipeline Step

A single task. A steps tells Jenkins what to do at a particular point in time - a step in the process.

Steps can be implemented as Groovy classes.

Pipeline Syntax

Jenkins Pipeline Syntax

Pipeline Execution

Jenkins Pipeline Execution

Writing a Jenkins Pipeline

Writing a Jenkins Pipeline

Downstream Pipeline/Project

A downstream pipeline or project is an pipeline/project that is triggered as part of the execution of a separate pipeline or project.

View

Workspace

Workloads running on a slave node (via the node wrapper) get a fresh/empty workspace directory upon entry into the node wrapper. This may require using (S3-based) stash/unstash for large directories that need to be made available for slave node execution.

Build Environment

OpenShift Jenkins Build Environment

Distributed Build

https://wiki.jenkins.io/display/JENKINS/Distributed+builds

Core

The core (jenkins.war) is the primary Jenkins application that provides the basic web UI, configuration and foundation upon which plugins can be built.

Plugin

https://wiki.jenkins.io/display/JENKINS/Plugin+tutorial

The list of installed plugins can be obtained on the console Jenkins -> Manage Jenkins -> Manage Plugins -> Installed.

Interesting Jenkins Plugins

Server Administration Concepts

Instance State

A Jenkins instance state consists of the following:

  • The WAR file
  • Plugins.
  • Settings
  • Build logs
  • Artifacts archives
  • Jobs
  • Various temporary files associated with running the jobs, including repository clones: "jenkins_home/workspace/test-build/.git/..."

Everything mentioned above is stored under $JENKINS_HOME. It is sufficient to archive this directory to make a back up of the instance. Similarly, restoring the data is just replacing the contents of the JENKINS_HOME directory from a back up.

The WAR file is stored under ${JENKINS_HOME}/war. The location can be overridden with --webroot=<new-location>. The WAR is expanded during the startup sequence.

The plugins are stored under ${JENKINS_HOME}/plugins. The location can be overridden with --pluginroot =<new-location>.

Jenkins on Docker

Running Jenkins as a Docker Container

Running Jenkins as a Docker Container

Running Build Agents as Docker Containers

Jenkins Docker Plugin

CLI

Jenkins CLI

Security

Security Concepts