Skip to main contentIBM Garage for Cloud

Configure Account

Set up the account so the environment can be installed

Configure IBM Cloud account

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

  • A public/private pair of VLANs
  • A resource group
  • A pair of access groups for the admin and users

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

Upgrade the image registry

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

  • Set the registry plan

    ibmcloud cr plan-upgrade standard

Now we can store more container images.

Prepare to run scripts

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 Developer Environment.)

  • Clone the ibm-garage-iteration-zero Git repository to your local filesystem

    git clone git@github.com:ibm-garage-cloud/ibm-garage-iteration-zero.git
  • Switch to the cloned directory

    cd ibm-garage-iteration-zero

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.

  • Log in to the IBM Cloud CLI
    ibmcloud login -a cloud.ibm.com -r <region>

Data center

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

  • Region — A geography such as us-south or eu-gb
  • Zone — A data center in the region such as dal10 or lon02

Public and private VLANs

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.

  • Use the IGC CLI’s igc vlan command to select two existing VLANs and generate the properties to use for the installation scripts

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:

Resource group

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.

Kubernetes service API key

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:

Access group for environment administrators

Seventh, create an access group to grant the necessary permissions for installing a Developer 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:

  • Create a new access group, name it something like <resource_group>-ADMIN (all capital letters)
  • Run the script ./terraform/scripts/acp-admin.sh, which adds the necessary policies to the access group
  • Add the environment administrator(s) to the group

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

  • Permission to create clusters
  • Permission to manage the IBM Cloud Container Registry (used as the environment’s image registry)
  • Permission to create service instances

Access group for environment users

Eighth, create an access group to enable users (e.g. developers, data scientists, etc.) to access the resources in the Developer 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:

  • Create a new access group, name it something like <resource_group>-USER (all capital letters)
  • Run the script ./terraform/scripts/acp-user.sh, which adds the necessary policies to the access group
  • Add the users to the group

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

  • Access to the resource group
  • Access to the cluster
  • Access to the image registry
  • Access to each of the services in the resource group

Cluster for the environment (optional)

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:

  • Run the script ./terraform/scripts/rbac.sh, which configures RBAC inside the cluster

Configuration settings

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

  • The region for the environment
  • The resource group for the environment

If the cluster already exists:

  • Cluster type (Kubernetes or Red Hat OpenShift)
  • Cluster name

If the environment administrator will create the cluster:

  • For the public/private VLAN pair: the region, data center, and VLAN IDs

Conclusion

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.