The OpenShift web console provides a convenient method for quickly interacting with and viewing the state of applications you have deployed using OpenShift. Not everything you may want to do can be done through the web console. You will therefore also need to be familiar with using the OpenShift command line tool oc.

In this course the embedded Terminal provided to you already has oc installed so you do not need to download and install the oc client.

If you were using a different OpenShift cluster and did not already have the oc command line tool, you can download it by following the links in the Command Line Tools menu option of the web console.

A link to details on where to get the command line tools was also shown on the initial welcome page when you first accessed the cluster when there were no projects.

Once you get to the list of downloads, you would need to download the archive specific to your platform, extract the oc binary and install it.

To login to the OpenShift cluster used for this course run in the terminal:

oc login -u developer -p developer

You should see output similar to:

Authentication required for https://openshift:6443 (openshift)
Login successful.

You don't have any projects. You can try to create a new project, by running

    oc new-project <projectname>

Next, create a new project namespace:

oc new-project myproject

You can list all the projects you currently have access to by running:

oc get projects

Once logged in, you can verify what user you are logged in by running:

oc whoami

You can verify which server you are logged into by running:

oc whoami --show-server

In the case of an external authentication service being used as the identity provider, the required steps are a bit different.

If you login using oc login on the command line you will be presented with an error message similar to:

Login failed (401 Unauthorized)
You must obtain an API token by visiting
  https://api.starter-us-east-1.openshift.com/oauth/token/request

You would visit the link given, logging in first via the separate authentication service if necessary. You will then be redirected to a page which will give details of the login command to use. This will include an access token to authenticate you for the session.

Even in the case where user authentication is managed by the OpenShift cluster and user credentials are accepted, you can opt to instead use an access token. You can retrieve the command to run by manually entering the /oauth/token/request path against the URL for the cluster access endpoint.

If you are already logged into the web console, you can also retrieve the details of the login command and access token by accessing the Copy Login Command menu option under your login name.

Whichever mechanism you use to login from the command line using oc login, the login will periodically expire and you will need to login again. The expiration period is typically 24 hours.

Working alone can be lots of fun, but as your application grows you may want to get others to help. This is no problem with OpenShift as it is built to be multi tenant. This means it can support many different users, each working on their own applications. To support collaboration on the same project, you can also grant other users access to any of your projects. Access can be granted at varying levels depending on what they need to be able to do in your project.

To test out how users can collaborate, we need another user.

Login from the command line as the user user1 by running:

oc login --username user1 --password user1

This is the first time this user has logged in, so if you run:

oc get projects

you should see that the user has access to no projects.

To grant this user access to your project, go to the list of projects in the web console and select on the drop down menu to the right of the project name and select on Edit Project.

When the project details are displayed, select on the Role Bindings tab.

You will see that only the developer user is a member of the project at this point, with the user having admin access.

Click on Create Binding to grant an additional user access to the project.

For the name of the role binding use user1-edit.

Ensure that the myproject namespace is selected, and with the role name as edit.

Finally enter user1 as the subject name.

Click on Create.

The user user1 is now a member of the project. Back in the Terminal run again the command:

oc get projects

This should show that user1 now has access to the project created by the developer user.

In this case you gave user1 the role type edit in the project. This allows the user to perform most tasks within the project, with the exception of tasks related to administration of the project. The user therefore cannot make changes to project membership or delete the project.

Other roles you might instead assign to a collaborator are view, which means they can look at everything in the project, but not change anything, or admin, which gives them equal rights as the owner of the project, including editing project membership or deleting the project.

Making changes to project membership can also be done from the command line using oc.

As user1 has no projects at this point, create one by running:

oc new-project mysecrets

Then add the ability for developer to also view that project by running:

oc adm policy add-role-to-user view developer -n mysecrets

Return to the main page in the web console where the list of projects is shown for developer and you should see mysecrets listed.

When using the oc command line tool, you can only interact with one OpenShift cluster at a time. It is not possible to open a separate shell on the same computer, as the same local user, and work on a different OpenShift cluster at the same time. This is because state about the current login session is stored in the home directory of the local user running the oc command.

If you do need to work against multiple OpenShift clusters, or even as different users on the same OpenShift cluster, you will need to remember to switch between them.

In this course you originally logged in from the command line using oc login as the developer user. You then subsequently logged in as the user1 user.

At this point you are still logged in and have an active session token for both users, but are currently operating as the user1 user.

To switch back to the developer user run:

oc login --username developer

Because you had already provided a password for the developer user, you will not be prompted to supply it again. The only time you would be prompted again to provide the password, or supply a new session token, when switching users, is if the active session had expired.

You can validate that you are now the developer user by running:

oc whoami

If you are working against multiple OpenShift clusters, to switch between them, you again use oc login, but supply just the URL for the OpenShift cluster. For example, if you had an account with the OpenShift Online free starter tier, and had been assigned to the us-east-1 cluster, you could run:

oc login https://api.starter-us-east-1.openshift.com

When switching between OpenShift clusters, if you do not explicitly say which user to use, it will use whatever was the last user you were logged in as with that cluster. You can still provide --username if required.

Switching, without needing to supply the password or register with a token is possible as details for each are saved away separately in what is called a context. You can see what the current context is by running:

oc whoami --show-context

You can get a list of all OpenShift clusters you have ever logged into by running:

oc config get-clusters

You can get a list of all contexts which have ever been created, indicating what users on those clusters you have logged in as, and which projects you have worked on, by running:

oc config get-contexts