...
helm repo add moc http://helmcharts.modelop.center --username=<providedbymodelop> --password=<providedbymodelop>
helm repo update
helm pull moc/moc --version=[version] --untar
Bring the ModelOp Center Helm Charts onto the workstation or the operating system with both the kubectl and helm utilities installed, as per the previous section.
...
Despite which method of retrieving the Helm Charts is chosen, the directory helm-installer moc will be created with a number of files and folders inside in the directory where the tar command is executed.
...
Before deploying an instance of ModelOp Center, choices need to be made in specific configuration files related to which services are deployed, which affects how ModelOp utilizes enterprise resources in a variety of fashions. Prior to understanding which files to modify, it is important to understand the directory structure of the Helm Charts, please read through the following items.
The "installermoc" directory contains all of the necessary files for installing using Helm.
Within the "installermoc" directory, the installerscripts/generatePullSecrets.sh script is used to generate secrets within Kubernetes in order to allow the cluster to import images.
The scss/application.yaml file contains certain default settings for a ModelOp Center v.3.0 installation which include SCCS (Spring Cloud Configuration Server) which is used as the backing configuration service for ModelOp services.
The installer/moc directory is a default configuration ModelOp Center deployment, using database pods to support the core application of ModelOp Center. It is suggested that a copy of this directory be made for every release that would need to be deployed. e.g. cp -R installer/moc installer/example-release
This directory can be referred to as an "environment", and each environment directory can be used to deploy any number of Helm "releases", which is the way Helm manages deployed applications to Kubernetes.
Within the copied directory, there are a number of files that are created, but at the root of the environment directory there are two primary files:
sccs/starter/simple.yaml file is intended for use as your initial ‘values override’ file. This file should be copied out of the moc directory and used with later helm install and helm upgrade commands: helm ... -f simple.yaml. This override file should contain the values you want to override from the defaults contained in moc/values.yaml, and should, ideally, be checked into some sort of change management system (like git).
moc/values.yaml contains the majority of the configurations that will need to be modified and made specific to the environment they are targeting. Please find information related to the values file here: https://helm.sh/docs/chart_best_practices/values/ . Again, it is recommended that these values not be modified inside the values.yaml file, and instead, overridden in the aforementioned values override file (simple.yaml).
Chart.yaml contains a description of the chart, it is a place to track details on what is deployed.
The installer/moc/sccs directory contains all of the base yaml files that will be used by Spring Cloud Configuration Server to configure the ModelOp Center application.
Modifying Overriding values in the values.yaml file is necessary to tailor the installation to the targeted environment. The main section of values.yaml that should be modified overridden is moc, which contains a number of key/values that need to be set to adjust the deployment to specific needs. Please refer to the following documentation, with general guidelines on the sections, as well as the in-line comments that are part of the file itself.
...
Please only begin this section after having tailored the your values override file (simple.yaml) file to the specific deployment needs.
...
| Code Block |
|---|
$ ./generatePullSecrets.sh --apply Enter username: modelopdevops Enter password: secret/modelop-regcreds created |
Before triggering an installation, modify your simple.yaml file with the appropriate version and target namespace:
| Code Block |
|---|
moc:
namespace: my-moc-namespace
version: "3.1" |
Then trigger the installation by running the following command from the installer directory inside where the helm-installer directory that was providedchart was un-tarred:
helm install RELEASENAME DIRECTORY --set moc .version=DESIREDVERSION - -namespace TARGETNAMESPACE -f DIRECTORY/scss/applicationf simple.yaml
Whereby:
RELEASENAME = The name given to the release, tracked by Helm, which can be anything relevant to the deployment itself. e.g. "moc-dev-helm1" Please see the following documentation that describes the concept of a Helm Release: https://helm.sh/docs/intro/using_helm/#three-big-concepts
DIRECTORY = The directory in which the targeted Chart.yaml resides, no slashes necessary. e.g. "moc-dev"
DESIREDVERSION = The version of ModelOp Center desired for the Helm deployment. e.g. "3.0"
TARGETNAMESPACE = The namespace into which you would like to deploy ModelOp Center within your current context in Kubernetes.
Example command structure:
helm install moc-test-rel1 moc-test --set moc.version=3.0 --namespace moc-test-1 -f DIRECTORY/scss/application.yaml
This example command assumes the existence of the directory %helm-installer/installer/moc-test which is a copy of the %helm-installer/installer/moc directory with all values changed to what is desired for the environment.
Output will resemble this example:
| Code Block |
|---|
NAME: release
LAST DEPLOYED: Tue Jun 7 08:28:01 2022
NAMESPACE: my-moc-namespace
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
.__ __ _ _ _____ ____ _
| \/ | ___ __| | ___| |/ ____\ _ __ / ___|___ _ __ | |_ ___ _ __
| |\/| |/ _ \ / _` |/ _ \ | / \| '_ \ | | / _ \ '_ \| __/ _ \ '__|
| | | | (_) | (_| | __/ || | |_) | | |__| __/ | | | || __/ |
|_| |_|\___/ \__,_|\___|_|\\____/| .__/ \____\___|_| |_|\__\___|_|
|_| Version3.0
Install complete!
The following services have been installed:
- sccs
- registry
- gateway
- reporting-service
- model-manager
- mlc-manager
- runtimes
- document-service
- minio
App name: modelop-center
Namespace: namespace
Profile: noauth |
...