Validated Patterns

Deploying the Medical Diagnosis pattern

Prerequisites

  • An OpenShift cluster

  • A GitHub account and a token for it with repositories permissions, to read from and write to your forks.

  • An S3-capable Storage set up in your public or private cloud for the x-ray images

  • The Helm binary, see Installing Helm For installation tooling dependencies, see Patterns quick start.

The Medical Diagnosis pattern does not have a dedicated hub or edge cluster.

Setting up an S3 Bucket for the xray-images

An S3 bucket is required for image processing. For information about creating a bucket in AWS S3, see the Utilities section.

For information about creating the buckets on other cloud providers, see the following links:

Utilities

To use the utilities that are available, export some environment variables for your cloud provider.

Example for AWS. Ensure that you replace values with your keys:
export AWS_ACCESS_KEY_ID=AKXXXXXXXXXXXXX
export AWS_SECRET_ACCESS_KEY=gkXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Create the S3 bucket and copy over the data from the validated patterns public bucket to the created bucket for your demo. You can do this on the cloud providers console or you can use the scripts that are provided in utilities repository.

$ python s3-create.py -b mytest-bucket -r us-west-2 -p
$ python s3-sync-buckets.py -s validated-patterns-md-xray -t mytest-bucket -r us-west-2
Example output

Bucket setup

Note the name and URL for the bucket for further pattern configuration. For example, you must update these values in a values-global.yaml file, where there is a section for s3:

Preparing for deployment

Procedure

  1. Fork the medical-diagnosis repository on GitHub. You must fork the repository because your fork will be updated as part of the GitOps and DevOps processes.

  2. Clone the forked copy of this repository.

    $ git clone git@github.com:<your-username>/medical-diagnosis.git

  3. Create a local copy of the Helm values file that can safely include credentials.

    Do not commit this file. You do not want to push personal credentials to GitHub.

    Run the following commands:

    $ cp values-secret.yaml.template ~/values-secret-medical-diagnosis.yaml
$ vi ~/values-secret-medical-diagnosis.yaml
    Example values-secret.yaml file
    version "2.0"
secrets:
  # NEVER COMMIT THESE VALUES TO GIT

  # Database login credentials and configuration
  - name: xraylab
    fields:
    - name: database-user
      value: xraylab
    - name: database-host
      value: xraylabdb
    - name: database-db
      value: xraylabdb
    - name: database-master-user
      value: xraylab
    - name: database-password
      onMissingValue: generate
      vaultPolicy: validatedPatternDefaultPolicy
    - name: database-root-password
      onMissingValue: generate
      vaultPolicy: validatedPatternDefaultPolicy
    - name: database-master-password
      onMissingValue: generate
      vaultPolicy: validatedPatternDefaultPolicy

  # Grafana Dashboard admin user/password
  - name: grafana
    fields:
      - name: GF_SECURITY_ADMIN_USER:
        value: root
      - name: GF_SECURITY_ADMIN_PASSWORD:
        onMissingValue: generate
        vaultPolicy: validatedPatternDefaultPolicy

    By default, Vault password policy generates the passwords for you. However, you can create your own passwords.

    When defining a custom password for the database users, avoid using the $ special character as it gets interpreted by the shell and will ultimately set the incorrect desired password.

  4. To customize the deployment for your cluster, update the values-global.yaml file by running the following commands:

    $ git checkout -b my-branch
$ vi values-global.yaml

    Replace instances of PROVIDE_ with your specific configuration

       ...omitted
   datacenter:
     cloudProvider: PROVIDE_CLOUD_PROVIDER #AWS, AZURE, GCP
     storageClassName: PROVIDE_STORAGECLASS_NAME #gp3-csi
     region: PROVIDE_CLOUD_REGION #us-east-2
     clustername: PROVIDE_CLUSTER_NAME #OpenShift clusterName
     domain: PROVIDE_DNS_DOMAIN #example.com

   s3:
     # Values for S3 bucket access
     # Replace <region> with AWS region where S3 bucket was created
     # Replace <cluster-name> and <domain> with your OpenShift cluster values
     # bucketSource: "https://s3.<region>.amazonaws.com/<s3_bucket_name>"
     bucketSource: PROVIDE_BUCKET_SOURCE #validated-patterns-md-xray
     # Bucket base name used for xray images
     bucketBaseName: "xray-source"
    $ git add values-global.yaml
$ git commit values-global.yaml
$ git push origin my-branch

  5. To deploy the pattern, you can use the Validated Patterns Operator. If you do use the Operator, skip to validating the environment.

  6. To preview the changes that will be implemented to the Helm charts, run the following command:

    $ ./pattern.sh make show

  7. Login to your cluster by running the following command:

    $ oc login

    Optional: Set the KUBECONFIG variable for the kubeconfig file path:

     export KUBECONFIG=~/<path_to_kubeconfig>

Check the values files before deployment

To ensure that you have the required variables to deploy the Medical Diagnosis pattern, run the ./pattern.sh make predeploy command. You can review your values and make updates, if required.

You must review the following values files before deploying the Medical Diagnosis pattern:

Values FileDescription

values-secret.yaml

Values file that includes the secret parameters required by the pattern

values-global.yaml

File that contains all the global values used by Helm to deploy the pattern

Before you run the ./pattern.msh make install command, ensure that you have the correct values for:

- domain
- clusterName
- cloudProvider
- storageClassName
- region
- bucketSource

Deploy

  1. To apply the changes to your cluster, run the following command:

    $ ./pattern.sh make install

    If the installation fails, you can go over the instructions and make updates, if required. To continue the installation, run the following command:

    $ ./pattern.sh make update

    This step might take some time, especially for the OpenShift Data Foundation Operator components to install and synchronize. The ./pattern.sh make install command provides some progress updates during the installation process. It can take up to twenty minutes. Compare your ./pattern.sh make install run progress with the following video that shows a successful installation.

    xray deployment

  2. Verify that the Operators have been installed.

    1. To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.

    2. Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded. Ensure that OpenShift Data Foundation is listed in the list of installed Operators.

Using OpenShift GitOps to check on Application progress

To check the various applications that are being deployed, you can view the progress of the OpenShift GitOps Operator.

  1. Obtain the ArgoCD URLs and passwords.

    The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.

    Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:

    ARGO_CMD=`oc get secrets -A -o jsonpath='{range .items[*]}{"oc get -n "}{.metadata.namespace}{" routes; oc -n "}{.metadata.namespace}{" extract secrets/"}{.metadata.name}{" --to=-\\n"}{end}' | grep gitops-cluster`
CMD=`echo $ARGO_CMD | sed 's|- oc|-;oc|g'`
eval $CMD
    Example output
    NAME                       HOST/PORT                                                                                      PATH   SERVICES                   PORT    TERMINATION            WILDCARD
hub-gitops-server   hub-gitops-server-medical-diagnosis-hub.apps.wh-medctr.blueprints.rhecoeng.com          hub-gitops-server   https   passthrough/Redirect   None
# admin.password
xsyYU6eSWtwniEk1X3jL0c2TGfQgVpDH
NAME                      HOST/PORT                                                                         PATH   SERVICES                  PORT    TERMINATION            WILDCARD
cluster                   cluster-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com                          cluster                   8080    reencrypt/Allow        None
kam                       kam-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com                              kam                       8443    passthrough/None       None
openshift-gitops-server   openshift-gitops-server-openshift-gitops.apps.wh-medctr.blueprints.rhecoeng.com          openshift-gitops-server   https   passthrough/Redirect   None
# admin.password
FdGgWHsBYkeqOczE3PuRpU1jLn7C2fD6

    Examine the medical-diagnosis-hub ArgoCD instance. You can track all the applications for the pattern in this instance.

  2. Check that all applications are synchronized. There are thirteen different ArgoCD applications that are deployed as part of this pattern.

Viewing the Grafana based dashboard

  1. Accept the SSL certificates on the browser for the dashboard. In the OpenShift Container Platform web console, go to the Routes for project openshift-storage`. Click the URL for the s3-rgw.

    storage route

    Ensure that you see some XML and not the access denied error message.

    storage rgw route

  2. While still looking at Routes, change the project to xraylab-1. Click the URL for the image-server. Ensure that you do not see an access denied error message. You must to see a Hello World message.

    grafana routes

  3. Turn on the image file flow. There are three ways to go about this.

    You can go to the command-line (make sure you have KUBECONFIG set, or are logged into the cluster.

    $ oc scale deploymentconfig/image-generator --replicas=1 -n xraylab-1

    Or you can go to the OpenShift UI and change the view from Administrator to Developer and select Topology. From there select the xraylab-1 project.

    dev topology

    Right-click on the image-generator pod icon and select Edit Pod count.

    dev topology menu

    Up the pod count from 0 to 1 and save.

    dev topology pod count

    Alternatively, you can have the same outcome on the Administrator console.

    Go to the OpenShift UI under Workloads, select Deploymentconfigs for Project xraylab-1. Click image-generator and increase the pod count to 1.

    start image flow

Making some changes on the dashboard

You can change some of the parameters and watch how the changes effect the dashboard.

  1. You can increase or decrease the number of image generators.

    $ oc scale deploymentconfig/image-generator --replicas=2

    Check the dashboard.

    $ oc scale deploymentconfig/image-generator --replicas=0

    Watch the dashboard stop processing images.

  2. You can also simulate the change of the AI model version - as it’s only an environment variable in the Serverless Service configuration.

    $ oc patch service.serving.knative.dev/risk-assessment --type=json -p '[{"op":"replace","path":"/spec/template/metadata/annotations/revisionTimestamp","value":"'"$(date +%F_%T)"'"},{"op":"replace","path":"/spec/template/spec/containers/0/env/0/value","value":"v2"}]'

    This changes the model version value, and the revisionTimestamp in the annotations, which triggers a redeployment of the service.

QUICKLINKS

CONTRIBUTE

STAY IN TOUCH

Validated Patterns

Validated Patterns are an evolution of how you deploy applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.