Table of Contents for

Getting Started with OpenShift

One way of enabling another person to make changes to your OpenShift application code is to add her machine’s public SSH key to your OpenShift account. This will enable your collaborator to access the Git repositories of any of your OpenShift applications using standard Git commands. It will not grant that person access to your OpenShift Online account, or enable her to log in to RHC.

This method for code sharing is best suited to situations where the person you wish to grant access to does not have an OpenShift account. If she’s willing to create an OpenShift account or has one already, a better way to give access is to add her to your application’s domain, as explained in the next section.

You can manage the SSH keys for your OpenShift account from the command line with the rhc sshkey command. You can list all your SSH keys with rhc sshkey list, add a key with rhc sshkey add, and remove a key with rhc sshkey remove. To add your collaborator, have her supply you with her public SSH key; typically, this would be her ~/.ssh/id_rsa.pub file (this is the public part of the key pair; the corresponding private key file, id_rsa, should never be shared). Here is an example of adding a new key to an OpenShift account:

[me@localhost ~]$ rhc sshkey add myfriend ~/Downloads/id_rsa.pub
RESULT:
SSH key id_rsa.pub has been added as 'myfriend'

Once the key has been added, give your collaborator the Git URL of the OpenShift application repository you want her to edit (you can view this with rhc apps). She can use this URL with the regular git clone command, and will also be able to access the application gear via ssh. If you want to add more collaborators, simply add more SSH keys.

Adding SSH keys to your OpenShift account is one way of enabling collaboration on application code, but it has limitations; it will not allow your team members to use RHC commands with the shared apps, and it gives everyone you add full access to make changes. A more flexible approach is to add members to your OpenShift domain.

All OpenShift applications must belong to a domain, sometimes referred to as a namespace. This becomes part of the OpenShift Online application URL, which has the form appname-domain.rhcloud.com—this should look familiar by now. Depending on your OpenShift account, you may be able to create multiple domains; users on the free tier of OpenShift Online are limited to one domain.

OpenShift domains can be managed from the command line with the rhc domain command. Use rhc domain list to see which domains you have access to and rhc domain show to display the details of applications in a domain. If you have access to do so, you can create new domains with rhc domain create name.

Domain membership can also be managed from the command line, using the rhc member command. When you add a member to a domain, you can give that member one of three possible roles:

These member permissions apply to all applications within a domain. If you wish to give the same user a different level of access to different applications, you should place them in separate domains.

Here is an example of adding and then removing a member in Insult App’s domain, osbeginnerbook. OpenShift users are referenced by their username, which is usually their email address; rhc account will display the details of the logged-in user:

[me@localhost ~]$ rhc member add phb@redhat.com -n osbeginnerbook --role view
Adding 1 viewer to domain ... done
[me@localhost ~]$ rhc member list -n osbeginnerbook
Login                   Role
----------------------- -------------
TheSteve0@redhat.com    admin (owner)
codemiller@redhat.com   admin
phb@redhat.com          view
[me@localhost ~]$ rhc member remove phb@redhat.com -n osbeginnerbook
Removing 1 member from domain ... done

A domain member can use the command rhc domain leave -n domain if she wishes to remove herself from a domain.

If you have read to this point, you should now have a good idea of how the OpenShift platform works and what features it offers. However, you may still be wondering how to adapt your current team processes to use OpenShift. Every team is different, so we cannot offer a magic formula for this, but here are some points you may want to consider:

Taking into account these items, here are the details of a possible team workflow utilizing OpenShift:

This workflow is not going to suit everyone and does not cover all aspects of the development process, but we hope it sparks some ideas of how OpenShift could become part of your team.