Deploy and configure the resources required by the …​doesn’t exist yet: ploigos#57

Deploy and configure a TSSC Platform and Pipeline for the TSSC Quarkus reference app; this includes importing and updating the config of the git repos. You can deploy this using the steps below:

1. Login to an OpenShift cluster (tested on 4.4 or above) as a cluster-admin

2. Create a CatalogSource to import the RedHatGov operator catalog.

   oc apply -f - << EOF
   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: redhatgov-operators
     namespace: openshift-marketplace
   spec:
     sourceType: grpc
     image: quay.io/redhatgov/operator-catalog:latest
     displayName: Red Hat NAPS Community Operators
     publisher: RedHatGov
   EOF

3. Create a project named devsecops for your pipeline tooling to live.

   oc new-project devsecops

4. If you are using an RHPDS-provisioned cluster: delete the limit range for the new project. RHPDS sometimes sets default CPU / memory limits that are too restrictive for certain Pods that the operator will create.

   oc delete limitrange --all -n devsecops

5. In the OpenShift Web Console, navigate to Operators → OperatorHub and search for "Ploigos Software Factory Operator". Select it and click Install

6. Set Installation Mode to A specific namespace on the cluster and set Installed Namespace to devsecops.

7. Leave other options as default and click Install once more.

8. If you’re using an RHPDS-provisioned cluster, you can skip this step, since this secret is created as part of the default provisioning template. Create a .dockerconfigjson secret containing a pull token for registry.redhat.io. It is recommended to generate a new service account before a workshop and delete it after, as this token is available in each of the users' projects (and can be used in the future if the service account isn’t deleted). To get a service account:

   • Go to https://access.redhat.com/terms-based-registry/

   • Login with your Red Hat credentials, then go to Service Accounts (upper right corner) and create a new service account.

   • Click on the name of the service account, go to the 'Docker Configuration' tab, click 'view its contents'

   • Copy the contents and save it ~/.docker/config.json

   • Create the config.json file if not already existed vi ~/.docker/config.json and paste the contents there.

   • Run the below command to create the pull-secret secret in the openshift-config namespace

     oc create secret generic pull-secret --from-file=.dockerconfigjson=</path/to/.docker/config.json> --type=kubernetes.io/dockerconfigjson -n openshift-config

   • Remember to replace </path/to/.docker/config.json> with the location where the config.json file is saved.

9. On the Ploigos Software Factory Operator page, create a new TsscPlatform CustomResource.

10. If you modified the name of your pull secret in Step 7, provide the corresponding values for Tsscplatform → Pull Secret as needed. Otherwise, you can leave this blank.

11. Watch the logs of the tssc-operator-controller-manager pod, and wait for:

    PLAY RECAP *********************************************************************
    �[0;33mlocalhost�[0m                  : �[0;32mok=32  �[0m �[0;33mchanged=10  �[0m unreachable=0    failed=0    �[0;36mskipped=17  �[0m rescued=0    ignored=0

    • This message indicates that the Reconciliation is complete. It should appear within 8-10 minutes.

12. Then create a TsscPipeline instance, which should create and start your pipeline job in Jenkins:

Note

This use case is simply deploying and integrating the services/tooling that is required by the TSSC Pipeline. This platform could be used by a TSSC Pipeline, a workshop, a custom pipeline, or anything the user desires.

This use case does not included the steps required to alter a target git repository(s) to integrate it with TSSC. This use case includes configuration of a TSSC Platform to support a correctly configured pair of git repositories: source code and deploy config.

Note

This CRD is responsible for the service tooling, or platform, required to support a TSSC Pipeline: a TSSC Platform. Each service/tool the CDR supports exposes options at a minimum a boolean to install or not to install it.

Wherever possible we delegate to another operator to create/manage the platform services. For example the gitea-operator happens to also be part of this GitHub org. That allows us to make changes to that operator to fulfill the needs of TSSC. Another example is the rhsso-operator; which is not an operator the TSSC group controls. If you compare the gitea and rhsso roles in this repo you will notice that the gitea role simply subscribes to the operator and applies one or more CRs. The rhsso role includes more tasks as there are gaps between what TSSC needs and what the rhsso-operator fulfills with it’s CRs.

This CRD is responsible for deploying everything needed to run a workshop on top of a TsscPlatform. If the name of a TsscPlatform is not supplied in this CR a TsscPlatform CR will be created with the same name as this CR.

After this operator has completed execution in response to this CR an SA should be able to conduct the workshop without additional deployments or configurations.

Note

This CRD is responsible for configuring the service/tooling deployed by a TsscPlatform CR. If the name of a TsscPlatform is not supplied in this CR a TsscPlatform CR will be created with the same name as this CR.

This operator will not attempt to alter a target git repository(s) to integrate it with TSSC. After this operator has completed execution in response to this CR the only actions that should remain would be to edit contents of the target git repositories.

Note

  tasks:
    - import_role:
        name: gitea
        tasks_from: tssc-platform

    - import_role:
        name: fuzzy-bunny
        tasks_from: tssc-platform

Please note how defaults behave for a CRD and how you must code to create behaviors that don’t surprise the user:

The CRD, if it has defaults set, will cause validation of vars to have their spec fleshed out to include those defaults if they were left out. When the playbook is called, those defaults from the CRD are passed as vars because they now exist in the CR. If you have an optional section in the CRD with no defaults, but the spec is validated, the variables will be passed to the playbook as a literal null value (None in Python).

None provided to a role will not inherit defaults. None filtered with Ansible’s default filter will be override with the default.

This set of conditions means you should apply defaults in the CRD and the playbook; or, rather, maybe an or would be appropriate.

• a validated but undefaulted CRD variable should have a default in the playbook

• a defaulted CRD variable should be expected to be passed into the playbook

This is not well documented, and James discovered this "feature" while working on things.