Documentation

Architecture

This tutorial outlines architecture of Operator Service for Jenkins®. In most cases, the default configuration should be enough, however, for more advanced topics, like peering with customer’s network, reading this document might be beneficial.

High-Level Architecture

The design incorporates the following concepts:

  • Utilize Kubernetes capabilities for Jenkins (autoscaling, self-healing, security).
  • Deployment via PowerShell script run on VM Extension.
  • Operator Service for Jenkins manages Jenkins life-cycle and configuration.
  • Backups are stored in Azure Storage Account (File Share).
  • Customer access via kubectl port-forward (we are planning to improve it in the near future).

Networking

The design incorporates the following concepts:

  • Operator Service for Jenkins creates Virtual Network (VNet) and Subnet (secured by Network Security Groups).
  • Deployment VM and Kubernetes share the same Subnet.
  • Peering with the customer’s network is possible additionally if needed.
  • Kubernetes with Azure CNI plugin.

Network peering prerequisites:

  • The address space of two VNets cannot overlap.
  • The role assignment on scope: Microsoft.Network/virtualNetworks/virtualNetworkPeerings/* (Network Contributor role).

Access Control

The design incorporates the following concepts:

  • Operator Service for Jenkins (Managed Application) creates Resource Group within customer’s Azure subscription.
  • VirtusLab support team has read/write access to Operator Service for Jenkins Resource Group in case of troubleshooting activities.
  • Customer’s access control model is based on allowed actions.

Customer allowed actions (in addition to default read/*):

1
2
3
4
Microsoft.Network/virtualNetworks/virtualNetworkPeerings/*
Microsoft.ContainerService/managedClusters/read
Microsoft.ContainerService/managedClusters/listClusterUserCredential/action
Microsoft.Network/virtualNetworks/peer/action