Planning Infrastructure

Sizing Considerations

This section describes the memory sizing guidelines for Solution Designer on Oracle Linux. It also includes general sizing guidelines applicable to any solution type. These guidelines are intended to assist in estimating the total Solution Designer system requirements. These guidelines do not contain express or implied warranties of any kind. This is a guideline for cluster sizing and altering as needed based on the values used in the instance.yaml file.

The default memory limits defined for the deployment in the Kubernetes cluster:

Table 5-1 Memory Sizing

Component	Memory Limit
initiative-manager	4Gi
workspace-manager	1Gi
landing-page-api	1Gi
unifieddesigner-ui	1Gi
ocscd-router	512Mi
uim-participant	1Gi + 2Gi

The default settings that get used for instance.yaml are as follows:

initiative-manager:      
    resources:    
        limits:      
            memory: 4Gi
workspace-manager:   
    resources:    
        limits:      
            memory: 1Gi
landing-page-api:   
    resources:    
        limits:              
            memory: 1Gi
unifieddesigner-ui:   
    resources:    
        limits:          
            memory: 1Gi
ocscd-router:   
    resources:    
        limits:      
            memory: 1Gi
uim-participant:  
    resources:    
        limits:      
            memory: 1Gi  
    builder:    
        resources:      
            limits:        
                memory: 2Gi

Note:

As the usage of OpenSearch and Kafka for Solution Designer is very minimal, the memory size allocation can be minimal.

Managing Configuration as Code

Managing Configuration as Code involves the following tasks:

Creating Source Control Repository
Setting the Repository Path During Instance Creation

Creating Source Control Repository

Managing Configuration as Code (CAC) is a central tenet of using Solution Designer cloud native. You must create a source control repository to store all configuration that is necessary to re-create a Solution Designer instance (or database ) if it is lost. This does not include the toolkit scripts.

Setting the Repository Path During Instance Creation

To offer flexibility in how the repository directory structure develops, the create-instance script takes as input, the path to the specification files.

The -s specPath parameter is mandatory in create-instance.sh and can point to several directories at once (directories are separated by a colon).

Setting Up Automation

This section describes the complete sequence of activities for setting up a Solution Designer environment with the aim of grouping repeatable steps into high-level categories. You should start to plan the steps that you can automate to some degree.

Note:

These steps exclude any one-time setup activities. For details on one-time setup activities, see the tasks you must do before creating an instance in "Creating a Solution Designer Cloud Native Instance".

The toolkit provides sample scripts for this purpose. However, they are not pipeline-friendly. The scripts should be used for creating an instance manually and quickly, but not for any automated process for creating instances. The scripts also illustrate both the naming of the secret and the layout of the data within the secret that Solution Designer cloud native requires. You must create secrets prior to running the install-db.sh or create-instance.sh scripts.

Configuring Code for Creating a Solution Designer Instance

To configure code for creating an instance, you assemble the instance configuration. While some of these activities could be automated, much of the work is manual in nature.

Assemble the configuration.
To assemble the configuration for an instance:

To assemble the configuration for an instance, copy $OCSCD_CNTK/samples/instance.yaml to your file repository and rename to align with your instance naming decisions made earlier (for example, instance.yaml).
Create the required secrets for Solution Designer DB access, OIDC, and so on.
```
$SCD_CNTK/scripts/manage-instance-credentials.sh -i ocscd create db,kafka,ocscd-oidc,s3
```
Note:
Passwords and other secret input must adhere to the rules specified of the corresponding component.

After the configuration and the input are available, the remaining activities are focused on Continuous Delivery, which can be automated.

Create one Solution Designer PDB or ADB per instance.

Create the instance.

$OCSCD_CNTK/scripts/install-db.sh -i ocscd -s $SPEC_PATH -c 4
$OCSCD_CNTK/scripts/create-instance.sh -i ocscd -s $SPEC_PATH

Deleting an Instance

This section describes the sequence of activities for deleting and cleaning up various aspects of the Solution Designer environment.

To delete the application instance:

Run the following command:

$OCSCD_CNTK/scripts/delete-instance.sh -i ocscd

To clean up the database, drop PDB or ADB.

To clean up the configuration as code:

Delete the Solution Designer instance and the database instance specification files.

Delete the secrets:

$OCSCD_CNTK/scripts/manage-instance-credentials.sh -i ocscd delete db,kafka,ocscd-oidc,s3

Securing Operations in Kubernetes Cluster

This section describes how to secure the operations of Solution Designer cloud native users in a Kubernetes cluster. A well organized deployment of Solution Designer cloud native ensures that individual users have specific privileges that are limited to the requirements for their approved actions. The Kubernetes objects concerned are service accounts, roles, and container registry secrets.

Service Accounts

The Solution Designer application requires a Kubernetes service account to manage Secrets. Solution Designer uses Kubernetes Secrets to store connection credentials to other systems. Solution Designer requires a namespace service account in the namespace. This namespace service account need not be a cluster role.

kubectl -n ocscd apply -f $OCSCD_CNTK/samples/rbac/secrets-admin.yaml

Roles

Assign the appropriate role or cluster role for the service accounts based on:

The deployment choice for OpenSearch and Kafka.
Whether the deployment uses a Kubernetes operator.

The Service Catalog Administrator's RBAC can be much more limited. For a start, it would be limited to only that instance's namespace. Further, it would be limited to the set of actions and objects that the instance-related scripts manipulate when run by the Administrator. This set of actions and objects is documented in the Service Catalog and Design toolkit sample located in the samples/rbac directory.

There are many ways to structure permissions within a Kubernetes cluster. There are clustering applications and platforms that add their own management and control of these permissions. Given this, the Service Catalog and Design toolkit provides a set of RBAC files as a sample.

These samples are in samples/rbac directory within the toolkit. The key files are scd-admin-role.yaml and scd-admin-rolebinding.yaml. These files govern the basic RBAC for a Service Catalog Administrator.

Container Registry Secrets

You must protect the container registries using authentication. Before deploying Solution Designer, create a kubernetes.io/dockerconfigjson secret with your credentials. After you create the secret, reference that secret name in the instance specification file. The following is an example for the initiative manager.

initiative-manager:  
    image:        
        pullSecrets:      
            - name: my-regcred

Managing Logs

Solution Designer uses the Kubernetes architecture for collecting logs. Kubernetes captures logs from each container in a running Pod. Solution Designer logs the data to the stdout(standard output) stream from the container it is running in. A log collection infrastructure can be used to collect the logs from the Kubernetes Cluster. You can use any log collection tool such as OpenSearch, fluentd and so on. After the logs are collected, you can use any dashboard to view the logs.

For OpenSearch, use the following container images:

opensearchproject/opensearch
opensearchproject/opensearch-dashboards

For using Fluentd to collect logs and push to OpenSearch, use the following container image:

fluent/fluentd-kubernetes-daemonset:v1-debian-opensearch

An optional example pattern for the logs using Fluentd is shown for the body of the log message:

/^(?<time_stamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3})\s+\[(?<thread>[^\]]*)\]\s(?<severity>\w*)\s+(?<class>[^\s]*)\s-\s(?<messagebody>.*)$/m

The CNTK provides a sample implementation for Fluentd which is located at $OCSCD_CNTK/ logging/fluentd.