Configure Account

The account must provide a few resources that will be needed to install and use the environment:

These are the steps an account manager should perform to configure the account.

First, we’ll upgrade the service plan for the image registry so that is has more capacity.

Now we can store more container images.

Second, we’ll use some scripts in the steps below to help create access groups. Here, we’ll download the scripts and prepare to run them. (If you want to use the console to manually configure the access groups, you can skip this step.)

Clone the Git repository with the scripts. (This repo also has the scripts for installing the environment.)

The scripts need you to log into IBM Cloud first. In the terminal you’ll use to run the scripts, log in to IBM Cloud.

Third, decide which IBM Cloud location will host the environment. That will be specified with two settings:

Fourth, create or provide a pair of public and private VLANs for the selected region and zone. These VLANs will implement the public and private networks in the Kubernetes or OpenShift cluster.

These links help explain how to find the VLANs an account has, create more, and how a cluster uses them to implement its network.

Use the console to manage VLANs:

Read the docs on using VLANs:

Fifth, create or provide a resource group. This resource group will control access to the environment’s cluster and service instances. This resource group should typically be named after the development team, its project, or the application it is implementing.

We give our resource groups names like mooc-team-one, garage-dev-tools, gct-showcase, etc.

Sixth, to create clusters in the resource group, the account will need API keys for the container service to create resources in the classic infrastructure. A separate API key is needed for each region and resource group. An account manager should use the account’s functional ID to set the API key(s) for the new resource group.

Create an API key for the resource group and the data center’s region:

Seventh, create an access group to grant the necessary permissions for installing a environment. Do this by running a script, or by using the console to manually perform the steps in the script. Also, add the environment administrator(s) (who is the user who will run the scripts to create the environment) to this group.

To create the access group for the environment administrators:

The script adds policies that allow the user to add resources to the resource group:

Eighth, create an access group to enable users (e.g. developers, data scientists, etc.) to access the resources in the environment. This can be done later, after the environment is created, either by running a script or using the console. Also, add the users who will use the environment (e.g. developers, etc.) to this group.

To create the access group for the environment users:

The script adds policies that allow the user to use resources to the resource group:

Ninth, if the environment administrator will install the environment including creating a new cluster, then skip this step. However, if the environment administrator will install the environment into an existing cluster, then the account manager must create the cluster for the environment administrator.

Create the cluster that the environment will be installed into. Create either a Kubernetes cluster or Red Hat OpenShift cluster as needed. A typical cluster size is single zone, 3 nodes, each 8 vCPUs 32GB RAM.

To configure RBAC security in the cluster:

The account manager needs to pass the following values about the account configuration to the environment administrator:

If the cluster already exists:

If the environment administrator will create the cluster:

The account manager has now configured the account so that the environment administrator can install the environment, and has passed the configuration settings to the environment administrator.