Architecture and Design

This document describes the architecture and design of Carthago Operator for Jenkins and the Custom Resources it uses.

Carthago Operator for Jenkins is a Kubernetes Operator.

Once deployed, it watches specified Namespaces for changes in Custom Resources (CRs) related to Jenkins, and makes sure that the state of these resources matches the desired state, as specified by the user in CR manifests when creating the resources.

CR manifests are the central place in code in which you can configure Jenkins and other resources.

Below you can find the list of CRs that you can use with Carthago Operator for Jenkins:

  • Jenkins

    • allows you to control options specific to the Jenkins Controller (Jenkins Master) as well as Kubernetes-specific options such as Roles or PodSpec,
    • it uses an InitContainer to ensure initial configuration,
    • it provides a mechanism for caching plugins, so when the pod restarts, it won’t have to download them again,
    • it uses a Persistent Volume for Jenkins home to preserve build history and artifacts. But, because Carthago Operator for Jenkins is built upon the idea of an immutable state, the Jenkins state is being cleared on restart.
  • JenkinsAuthentication

    • allows you to set up how Jenkins users are going to authenticate to it,
    • offers built-in integration with plugins handling various authentication protocols and identity providers.
  • JenkinsAuthorization

    • allows you to control permissions of users and groups of users,
    • offers built-in integration with Matrix plugin and Role-Based Authorization strategy.
  • JenkinsKubernetesAgent

    • allows you to control options specific to the Jenkins Agents as well as Kubernetes-specific options such as Roles or PodSpec,
    • allows you to define agents using custom images,
    • a seedJob agent is required when using JenkinsSeedJobs, if it isn’t present, one will be created by Operator.
  • JenkinsSeedJob

    • uses Jenkins Job DSL plugin,
    • it is a recommended way to define your jobs,
    • jobs defined as JenkinsSeedJobs will be recreated on Jenkins restart.
  • JenkinsConfigurationAsCode

    • uses Jenkins Configuration as Code plugin,
    • allows you to control the Jenkins' state directly. This will be re-applied when Jenkins restarts.
  • JenkinsGroovyScript

    • allows you to control the Jenkins' state directly. This will be re-applied on Jenkins restart,
    • if your scripts need to be executed in a particular order, you can use the DependsOn field in Custom Resource,
    • JenkinsGroovyscripts are executed after JenkinsConfigurationAsCode.