CN2 Pipelines
SUMMARY Juniper Cloud-Native Contrail Networking (CN2) Pipelines is a CI/CD tool to enable GitOps-based workflows to automate CN2 configuration, testing, and qualification. CN2 Pipelines runs alongside CN2 clusters starting with CN2 Release 23.1.
CN2 Pipelines Overview
GitOps is a deployment methodology centralized around a Git repository, where the GitOps workflow pushes a configuration through testing, staging, and production. Many customers run a staging environment or staging cluster. The GitOps process supports automatic configuration to deploy and test CN2 network configurations using test case YAML files.
After you (the administrator) configure the CN2 Pipelines and GitOps, CN2 Pipelines will:
-
Sync with the GitOps repository and auto-provision CN2 configurations to the Kubernetes cluster.
-
Provision CN2 configurations with the capability to test and verify the deployed CN2 configurations in each Kubernetes cluster.
-
Provide auto-revision monitoring and updates.
CN2 Configuration
CN2 uses Kubernetes Custom Resource Definitions (CRDs) configurations written in YAML or JSON format. These CRDs are stored and managed in the Git repository, which makes the Git repository the source of truth for all of the network configurations.
GitOps
"GitOps is a paradigm or a set of practices that empowers developers to perform tasks which typically fall under the purview of IT operations. GitOps requires us to describe and observe systems with declarative specifications that eventually form the basis of continuous everything." Quote is from CloudBees.
To achieve the GitOps mode of operation, the Argo CD application is used. The CN2 Git repository is configured to be used as the Argo CD application. Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. See Figure 1.
The GitOps engine also runs a repository server that caches all of the application files from the Git repository. These files are verified and monitored for any CN2 configuration changes received to the Git repository.
CN2 and GitOps
The primary benefit of supporting GitOps for CN2 is to achieve automatic configuration deployment and testing of CN2 network configurations. CN2 configurations are custom resource definitions (CRDs) which are maintained in a Git repository. These CRDs are applied to the CN2 cluster whenever there is a change to the CN2 configurations in the Git repository. To test and apply these changes, the GitOps applications Argo CD and Argo Workflows are utilized.
CN2 Pipelines Configuration Flow
Your CN2 configurations are maintained in the CN2 Git repository. The CN2 Git repository is configured to be used as the Argo CD application. The CN2 Pipelines configuration flow is as follows:
- CN2 configurations are initially pushed to the staging repository by you (the administrator).
-
Any changes to the configurations in the repository triggers a Git synchronization to the GitOps server.
-
The GitOps server looks for any changes by comparing the current configuration and the new configuration fetched from the CN2 Git repository.
-
If any new changes are pushed, the GitOps server applies these changes to the CN2 environment.
GitOps Server
The GitOps server confirms that the configuration in the CN2 environment is always synchronized with the Git repository. CN2 Pipelines supports two branches:
- One for the staging environment.
- One for the production environment.
Many customers run a staging environment or staging cluster. The staging branch is where you (the administrator) push any configurations required to be pushed to the staging CN2 cluster. These configurations are then tested by the workflow engine before the configurations are merged to the production branch.
Workflow and Tests
The GitOps server pushes all configuration changes to your CN2 setup as follows:
-
This push triggers the workflow cycle to run test cases. These test cases validate and verify the CN2 setup against the configuration you applied in the staging setup.
-
If the test cases are successful, you are notified about the test completion and a merge request is presented to the production branch.
-
Next, you need to validate the changes in the merge request and approve the changes to be merged to the production branch.
-
After the new configurations are merged to the production branch, the GitOps server synchronizes the configurations and applies the configurations to the CN2 production cluster.
Prerequisites
Before you install CN2 Pipelines, verify you have the following:
-
Management Kubernetes cluster (where you will install CN2 Pipelines)
-
CN2 Kubernetes cluster
-
Connectivity from the management Kubernetes cluster to the CN2 cluster
-
GitLab repository with CN2 configuration folder with sample ConfigMap file
-
MountPath folder
- Connectivity from the management Kubernetes cluster to outside, needed to access Argo CD, Argo Workflows, and test results
-
Notes:
-
If you are using Red Hat OpenShift with CN2 Pipelines, install ingress from the files /ingress/openshift/public on the OpenShift cluster
-
CN2 Pipelines needs GitLab or GitLab for Open Source as an event source
-
CN2 pipeline requires a separate GitLab project per CN2 cluster. So, each CN2 cluster requires a separate GitLab project to be created for storing the CN2 configuration (
config
). -
In the case of file deletion, if the commit-processing workflow fails, you are required to do a dummy commit.
-
CN2 Pipelines Installation and Setup
Components
CN2 Pipelines installs and configures the following components:
-
Argo CD
-
Argo Workflows
-
Argo Events
-
CN2 Pipelines services
-
Configure, upload and trigger CN2 testing workflows
-
Supports customer container network functions (CNFs)
CN2 Components
All CN2 Pipelines components are installed and configured as part of the CN2 Pipelines Helm chart installation. Argo CD is one of the components in CN2 Pipelines and it is installed in the management cluster.
Argo CD is configured with the following details during the initial setup:
-
CN2 cluster environment details
-
Git repository access details
-
CN2 GitOps engine application configuration
Kubernetes
You can use any native Kubernetes or Red Hat OpenShift with CN2 or another Container Network Interface (CNI) to provision CN2 Pipelines.