A domain represents a unique name for each user within which each user application must exist. OpenShift users cannot create an application until they have a valid domain. The domain name becomes a part of the application URL. For example, if your domain name is foo and your application name is bar, the application URL will be http://bar-foo.rhcloud.com. Every OpenShift account must have at least one domain associated with it. The OpenShift Online free tier does not allow a user to create more than one domain, but you can create more than one domain in paid tiers. The domains make it possible for users to choose any valid name for their application. They allow two or more users to have the same name for their applications. For example, user A can have an application named bar in domain foo, and similarly, user B can also have an application named bar in domain test. Once a user has a valid domain, he/she can use any valid name for their application.

Team collaboration is one...

In the Creating OpenShift domains using the web console recipe of Chapter 1, Getting Started with OpenShift, you learned how to create a domain using the web console. In this recipe, you will learn how to create a domain using the rhc command line.

$ rhc delete-domain <domain_name...

Following the creation of a domain, you might need to rename it. Let's suppose you want to rename your existing name to reflect its environment. For instance, you may rename the osbook domain name to devosbook in order to indicate devosbook as your development environment.

$ rhc rename-domain <old_domain_name> <new_domain_name>

In this recipe, you will learn how to view the details associated with a domain.

$ rhc show-domain --namespace <your domain name>

$ rhc show-domain --namespace devosbook...

Let's suppose you are a system administrator of your organization, where your job is to make sure all the production applications are running smoothly. Ideally, you would not want all the developers in your organization to have access to the production environment. Giving everyone access to the production environment is waiting for the inevitable to happen. What you should remember is that you can have different domains for different environments. The domain corresponding to the production deployment will be controlled by system administrators rather than developers. OpenShift allows you to give different access levels to a different group of people. You, along with other system administrators, can enjoy admin access to the production domain, whereas developers can only have viewer access, if required. Developers will be added to the production domain in the read-only mode. They can view the information about it and its applications, but they cannot...

Imagine that you are leading a software development team that uses OpenShift for development. During development, you would like all the developers in your team to be able to create, delete, push, or even SSH into application gear. However, you would not want users to rename or delete a domain, as this might impact other developers in your team or other teams. Another thing you would not like is to allow developers to change gear sizes. You can restrict development domains to only use small gears to save money. In this scenario, you will give developers an editor role that gives them the freedom to work with applications but not domains.

Consider a situation where a new system administrator joins your team. As the new system admin is also responsible for making sure your production apps are running smoothly, you would like to add the new system admin as an administrator. You can do this by giving the new user an admin role.

$ rhc add-member openshift.cookbook...