- Developer Tools
Troy Topnik, January 20, 2014
An "organization" can be a number of things. In the corporate world it can mean a company, an association, a subsidiary, a deparment, a team, or really any functional grouping of people. A multi-national corporation will have a very different notion of how to group its employees than a ten-person startup. We want Stackato to work for as many of these groupings as possible.
It's also one of the biggest conceptual differences between Stackato 2.10 and 3.0. To get up and running quickly on a new Stackato system, it's helpful to know how this new permission and ownership framework will affect how you work.
I'll cover the major differences between the old and new models, then describe one way you could set up the platform for use in a typical organizational structure.
Users don't have quotas, Orgs do
Stackato 2.10 had Users and Groups, both of which had quotas. Your user account would give you a certain amount of memory and a certain number of applications and service instances. Groups were similar, but the quotas were shared between all members of the groups. You could deploy applications and service instances under your own account, or any group you were a member of.
With Stackato 3.0, users don't have quotas directly associated with their account. They are members of an Organization (org), which in turn is assigned a quota definition. The quota definitions are named sets of memory and service instance quotas (no more app quotas). Everyone in the org shares these quotas.
Apps and service instances belong to Spaces
Apps and service instances used to be owned by users or groups. Access to applications and service credentials was restricted to the user or group which deployed them. This has changed with the introduction of spaces.
Spaces are sub-groups of orgs, and org members can be given access (as a Developer, Manager, or Auditor) to one or more of its spaces. Any member of the space can view apps in the web management console, but only members with the "Developer" role can deploy apps and provision service instances to the space.
Domains: Owned by Orgs, Assigned to Spaces
The new regime for domains and hostnames caught me by surprise when I first started looking into Cloud Foundry v2. Formerly, the system had a base domain and all applications pushed to it would get a virtual hostname on that default domain.
For example, if I pushed an app called "supercms" to an API endpoint of "api.stacka.to", I'd end up with the URL "supercms.stacka.to". It was great because it was simple, but it did mean that my virtual hostname had to be globally unique. If anyone else had pushed an app called "supercms" first, I'd have to choose a different application name (or at least map a unique URL to that app when deploying).
On the bright side, I could (as a regular end user) map my own domain name to the application (if the "Allow non-local URLs" option was enabled) and create a CNAME DNS record to point to the system.
With the new system, domains are controlled at the Admin and Org level, and users cannot map arbitrary URLs to their applications. Org managers configure domains for each org, and space managers map those domains to their spaces. Apps can only have URLs made up of a "route" (basically a virtual hostname - the app name, or another arbitrary string) and one or more of the domains mapped to the space.
Upshot: Admins and org managers have ultimate control of the domains that the system will route. Developers and managers can specify the route portion of the URL, combined with one or more of the space's mapped domains.
Setting up Orgs, Spaces, and Domains
The Stackato VM starts you off with just one org, created when you first log in to the web console. The fully qualified system hostname becomes the domain for this initial org.
For a real production system, you'll need to set things up to allow for a little more flexibility. If you're setting up a system for a company with a number of distinct departments or subsidiaries, you'll probably want to create a number of orgs, with domains for each.
Before we do that though, we should probably modify the quota definitions (Settings > Quota Definitions) to match our system and projected usage. The default "paid" quota definition allots 200GB of memory and 500 service instances.
Avoiding overlapping domains
Next up are the orgs and their domains. Let's say our API endpoint is "api.stacka.to". We want each org to have it's own subdomain (e.g. "webops.stacka.to", "pydev.stacka.to", "systems.stacka.to", etc.). Before we create these domains, we need to remove the "*.stacka.to" domain that was created when we first launched the web interface (under Admin > Domains). We can't have overlapping domains; Stackato disallows this to prevent URL collisions between orgs and apps.
Adding the domain for an org
On creating a new org, you'll be prompted to create at least one space. However, first we're going to add a domain to our org by clicking the "+" on the Domains sidebar.
I've selected "Wildcard" which means any route (e.g. app name) can be added to this domain automatically to make the full URL. You can use this interface to specify full, non-wildcard URLs for specific apps.
So now, instead of having a "*.stacka.to" domain for all orgs on the system, the "webops" org has it's own separate domain.
Setting up Spaces
With a domain in place, we should set up at least one space using the "+ Add Space" button.
There's a Cloud Foundry convention to use spaces called "dev", "test", and "prod" but the choice is yours. The names should signify some logical grouping of apps that suits the team's workflow.
We can now do the same for all of the other orgs we want to add to the system, then add users to each org, assigning the Manager role to at least one of them, which in turn can handle more fine grained configuration specific to the org. These managers can:
- add registered users to the org
- add spaces
- add org members to spaces
- add more domains (including "external" URLs)
- edit or remove any of the above
Notice anything regular end users can't do with the new system? I can think of two:
- map external URLs to their applications
- have personal usage quotas
If I'm running a public PaaS using Stackato, where "regular end users" are paying me directly to host their applications, I need a way to allow them to do these things or my hosting platform will suck.
There's a good way to do this: make each user the Manager of single-user org. Users get their own quota (you can even make different tiered quota definitions just for these) and can map whatever domains they have to applications hosted on the system.
There's an option in the Stackato data import tool to set up orgs like this automatically if you're moving from Stackato 2.10.
Subscribe to ActiveState Blogs by Email
Share this post: