Collaboration tooling has historically been one of OpenShift’s most-requested features. Last year the platform released functionality to allow users to work in a team environment with domain group membership and user management. There are people who use these features on a daily basis, but there is not a lot of information describing how the functionality is used. So, I am taking this opportunity to write a blog post to give you a better idea of what’s possible.
Domains? Do I have to register and pay for it?
In OpenShift terms, a domain name or what you might casually call “a domain” is referred to as an “alias”. If you register a domain name with your registrar of choice, you can set up an alias for your OpenShift application for this domain name, so that you can point to your application from a custom URL. However, “domains” in OpenShift-speak are different from aliases and domain names.
On OpenShift, a domain (sometimes also referred to as a namespace) is an environment where applications live. The application source can only be accessed and modified by OpenShift accounts that are listed as members of that domain. On OpenShift online, the domain/namespace can be seen in the application URL, which will have the form -.rhcloud.com.
In this blog post I will use OpenShift Online as my instance, however, what I will tell you will be pretty much the same if you use OpenShift Origin or OpenShift Enterprise deployed on-premise or as a service from some other entity.
There are two entry points to domain management. Firstly, you can work from the application list, where you should see domain management on the right side of the list of your applications.
Alternatively, you can navigate to your account settings and there you will see a section titled “Domains”.
By default, every OpenShift user has at least one domain. This domain is set up either at account creation time or at latest when your first application is deployed. This domain is a private environment for the user to deploy applications to. This domain is not (usually) used for collaboration. To collaborate with users, you should create a new account, set access accordingly, and deploy your applications there.
On both screens there is a link to create a new domain. When you do use it, you will be taken to a screen where you will be asked to choose a name for your new domain.
Once you choose your name and you confirm it by clicking the button, the domain will be created and you will be redirected to your account settings. You should then see the list of your domains with the new one included.
If you click the domain name, you will be taken to the domain. The list of applications is empty as the domain is brand new and you have not yet deployed any applications there.
Voilà, you now have a new domain and you may start using it.
When you are on the domain overview page, you will see management controls on the right-hand side.
There you can control which gear sizes the users in the domain are allowed to use. This helps you to provide resources in a targeted and controlled way, allowing your users just enough to get their work done, without sacrificing your whole budget.
Below the gear sizes, you can expand user and permission management. This is the most complex part.
Let me recap what the controls look like with a picture
You can see there is one member by default, and that’s me, as a domain owner. You can add other users that will be able to utilize the domain for their work. Every member is restricted with permissions, that allow the user to execute actions in that particular domain.
With the view permission you can see the domain and applications, but you are not allowed to push new code or change anything. Your QA guys may use this permission.
Your developers have this kind of permission. They can access the applications as with the View permission, however, on top of that they can provision new gears and can deploy code into them.
On top of application management, this role provides administration functions for the domain. These can be assigned to project managers or to somebody who is responsible for management of the domain.
Now you fill in the details regarding the application. In this step, you choose your application name and domain. Next to the text box for name, there is a select box where you can choose from the domains where you are allowed to deploy applications. You can change the other parameters as well, but I will go with the defaults and will confirm the creation. Once the application is created you will see this page:
From here, you can go straight to the application overview, using the link at the top of the page.
Now you can work with the application as with any other application you have already deployed to OpenShift using your private domain. The only difference is that you can share that application with other people.
Cool, isn’t it?
When you do not need the domain anymore, you can simply delete it.
To do this, there must be no applications in the domain. Delete all the applications first, and then delete the domain. This is for safety, as deleting the whole domain with all the applications could be pretty costly.
Of course all of these tasks can be accomplished with the rhc command line tool. The domain management is concentrated around the rhc domain command.
List of Actions configure Change one or more configuration settings on the domain create Create a new container for applications. delete Delete a domain leave Leave a domain (remove your membership) list Display all domains you have access to rename Rename a domain (will change application urls) show Display a domain and its applications
For example, to create a domain and delete it again, we could do the following:
rhc domain create mjelend rhc domain delete mjelend
To manage members and permissions, there is the rhc member command:
List of Actions add Add or update a member on a domain list List members of a domain or application remove Remove a member from a domain
Again as an example, let’s add two new members to a domain mjelend with view permissions.
Finally, to create an application, you will use the command line tool as usual, but will specify the domain name. Let’s create a new application called demo with the PHP cartridge in the domain mjelend:
rhc app create demo php-5.4 -n mjelend
Working as a team on OpenShift is extremely easy and provides you with a solid foundation for allocating and controlling your resources and thus your costs. I encourage you to try it and gain your own experience. We are always looking for feedback, so do not hesitate and let us know if you find something you do see differently.