Install CN2 Pipelines

This topic lists the Argo components and configurations that are automated as part of the CN2 Pipelines Helm chart install.

• Argo CD External Service—Creates a Kubernetes service with service type as NodePort or LoadBalancer. This creates the Argo CD external service that provides access to the Argo CD API server and the Argo CD GUI.

• Register Git Repository with CN2 Configurations—Configures repository credentials and connects your Git repository to Argo CD. Argo CD is configured to your Git repository to watch and pull the configuration changes from your Git repository. This Git repository should only contain Kubernetes resources. Argo CD does not understand any other type of YAML or files.

• Register Kubernetes Clusters—Registers a Kubernetes cluster to Argo CD. This process configures Argo CD to provision the Kubernetes resources in any Kubernetes cluster. Multiple Kubernetes clusters can be configured in Argo CD.

• Create an Argo CD Application—Creates an application using the Argo CD GUI. Any application created in Argo CD needs to be associated with a Git repository and one Kubernetes cluster.

After installing the CN2 Pipelines Helm chart, you have access to the Argo Workflow GUI and the Argo CD GUI.

• Access Argo Workflow UI
• Access Argo CD GUI

Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. You can define workflows where each step in the workflow is a container. You can also model multi-step workflows as a sequence of tasks or capture dependencies between tasks using a directed acyclic graph (DAG).

• Why Workflows Are Needed
• How Workflows Work and How CN2 Uses Workflows

The pipeline service listens for notifications from Argo Events for any changes in Kubernetes resources. The pipeline service exposes a service which is used by Argo Events to consume and trigger the service with the data related to the CN2 configuration that you applied. It is the responsibility of the CN2 Pipelines service to identify the test workflow to be triggered for the type of CN2 configuration that you applied. Workflows change dynamically depending on the objects being notified. The CN2 Pipelines listener service invokes the respective workflow dependent on the CN2 configuration that gets applied.

This topic shows examples for the CN2 Pipelines configurations.

• Pipeline Configuration
• Test Workflow Template Parameter Configuration
• Workflow to Kind Map

apiVersion: v1 
data: 
  testcase_trigger_threshold: "10" 
kind: ConfigMap 
  labels: 
    app.kubernetes.io/managed-by: Helm 
  name: cn2pipeline-configs 
  namespace: argo-events

kind: ConfigMap
apiVersion: v1
metadata:
  name: cn2tmpl-to-kind-map
  namespace: argo-events
data:
  kindmap: |
    - workflow: it-cloud
      kind: ['*']
    - workflow: custom-cnf-sample-test
      kind: ['namespace']

You can create custom workflows tests to test your container network functions (CNFs).

To create a custom workflow, you can use the example custom test workflow templates provided with the CN2 Pipelines files. Every workflow has a set of input parameters, volume mounts, container creation, and so on. To understand the workflow template creation see Argo Workflows.

The following example custom test workflow templates are provided:

• Input parameters to workflow

• Mount volumes

• Create Kubernetes resource using workflow (Template name: create-cnf-tf and create-cnf-service-tf)

• Embedded code in workflow (Template name: test-access-tf)

• Pull external code and execute within a container (Template name: test-service-tf)

To automate the inputs to the workflow during the pipeline run, a workflow parameter configuration map is created which has the inputs for the workflow. The configuration map must have the same name as the workflow template.

In the following example, the template name is custom-cnf-sample-test. A configuration map is created automatically with the same name. As a part of the pipeline run, the pipeline service looks for the configuration map with the template name, gets the inputs, which are then automatically added to the workflow when the pipeline triggers the workflow.

Another update that happens in the test case which triggers the custom workflow is to change the configuration map name to <cn2tmpl-to-kind-map>.

    - workflow: custom-cnf-sample-test 
      kind: ['namespace']

The following is an example workflow configuration for the template custom-cnf-sample-test:

apiVersion: argoproj.io/v1alpha1 
kind: WorkflowTemplate                  # new type of k8s spec 
metadata: 
  name: custom-cnf-sample-test     # name of the workflow spec 
  namespace: argo-events 
spec: 
  serviceAccountName: operate-workflow-sa 
  entrypoint: cnf-test-workflow       # invoke the workflows template 
  hostNetwork: true 
  arguments: 
    parameters: 
      - name: image               # the path to a test docker image 
        value: not_provided 
      - name: kubeconfig_secret   # eg: kubeconfig-989348 
        value: not_provided 
      - name: report_dir          # eg: /root/SolutionReports 
        value: not_provided 
  volumes: 
    - name: kubeconfig 
      secret: 
        secretName: "{{ `{{workflow.parameters.kubeconfig_secret}}` }}" 
    - name: reportdir 
      hostPath: 
        path: "{{ `{{workflow.parameters.report_dir}}` }}" 
  templates: 
  - name: create-cnf-tf 
    resource: 
      action: apply 
      #successCondition: status.succeeded > 0 
      #failureCondition: status.failed > 3 
      manifest: | 
        apiVersion: v1 
        kind: Pod 
        metadata: 
          name: webapp-cnf 
          namespace: argo-events 
          labels: 
            app.kubernetes.io/name: proxy 
        spec: 
          containers: 
          - name: nginx 
            image: {{ .Values.global.docker_image_repo }}/nginx:stable 
            ports: 
              - containerPort: 80 
                name: http-web-svc 
  - name: create-cnf-service-tf 
    resource: 
      action: apply 
      #successCondition: status.succeeded > 0 
      #failureCondition: status.failed > 3 
      manifest: | 
        apiVersion: v1 
        kind: Service 
        metadata: 
          name: webapp-service 
          namespace: argo-events 
        spec: 
          selector: 
            app.kubernetes.io/name: proxy 
          ports: 
          - name: webapp-http 
            protocol: TCP 
            port: 80 
            targetPort: http-web-svc 
  - name: test-access-tf 
    script: 
      image: "{{ `{{workflow.parameters.image}}` }}" 
      command: [python] 
      source: | 
        import time 
        print('--Test access to CNF--') 
        url = 'webapp-service.argo-events.svc.cluster.local' 
        retry_max = 3 
        retry_cnt = 0 
        while retry_cnt < retry_max: 
          print('Response status code: {}','200') 
          time.sleep(1) 
          retry_cnt += 1 
          print('Monitoring access count: {}',retry_cnt) 
        print('Completed') 
  - name: test-service-tf 
    inputs: 
      artifacts: 
      - name: pyrunner 
        path: /usr/local/src/cn2_py_runner.py 
        mode: 0755 
        http: 
          url: https://raw.githubusercontent.com/roshpr/argotest/main/cn2-experiments/cn2_py_runner.py 
    script: 
      image: "{{ `{{workflow.parameters.image}}` }}" 
      command: [python] 
      args: ["/usr/local/src/cn2_py_runner.py", "4"] 
  - name: cnf-test-workflow 
    dag: 
      tasks: 
      - name: create-cnf 
        template: create-cnf-tf 
      - name: create-cnf-service 
        template: create-cnf-service-tf 
      - name: test-connectivity 
        template: test-access-tf 
        dependencies: [create-cnf-service] 
      - name: test-load 
        template: test-service-tf 
        dependencies: [create-cnf-service]