In my last post, I introduced you to some of the new features we are rolling out with the new cloud controller. For reference, I’ve included a block diagram of the new structure to refresh your memory.
In the previous post, the focus was on introducing the objects and briefly discussing how they are used for operational collaboration. In this post, I want to show you how the objects are used for resource accounting, how to navigate around the objects using the Cloud Foundry Command Line Interface (VMC), and then briefly show how features like custom domains use these objects as their foundation.
From the diagram above, you can see how the organization (a.k.a., org) object acts as the root object holding a collection of spaces. Each space contains a number of applications and service instances. From a resource tracking perspective, what this means is that we can easily account for memory and services in aggregate at both the space and organization level.
If you used an org to represent a project, and then used spaces to hold your production apps, your staging playground, and a playground for each developer, you might end up with a structure that looks something like this:
org: mhlsoft spaces: - name: production - apps: - name: pds - name: staging - apps: - name: pds - name: markl - apps: - name: pds_ng_node - name: pds - name: patb - apps: - name: pds_ng_go
With this structure in place, Cloud Foundry is able to tell you the resource consumption of each space and the aggregate consumption across the entire org.
Suppose your Cloud Foundry provider sold you 16GB of RAM for $380/mo. It would be nice to know how much memory you are using in aggregate, how much is being spent on your production facing apps, and how much is being used for internally facing playgrounds.
The next generation cloud controller is designed to support exactly this scenario. This allows Cloud Foundry tooling to show an organization summary like this:
The same tooling could also show a space summary, for each space, that might look something like this:
From this small description, you can see how the next generation system is designed to support the resource accounting and quota enforcement requirements of a wide variety of commercial systems based on Cloud Foundry.
Navigation with VMC
Enough of the system is working now where we can run the next generation cloud controller alongside the existing cloud controller. Given where we are with the work, I thought it would be a good idea to show you how to navigate around the system using the next generation VMC while targeting a next generation cloud controller.
The first thing to note is that we have extended the “vmc target” command to accept an optional org and space switch:
$ vmc help target Set or display the current target cloud Usage: target [URL] Options: --url URL Target URL to switch to -i, --interactive Interactively select organization/space -o, --organization, --org ORGANIZATION Organization -s, --space SPACE Space
The new -o and -s switches allow you to select an org and space within the target cloud. In one of my test clouds, I have two orgs set up, and in one org have a few spaces, in the other, just a single space. Watch as I navigate around using “vmc target”:
# show my current context (cloud, org, and space) $ vmc target target: https://api.fakedomain.com organization: pds space: production # switch to the staging space $ vmc target -s staging Switching to space staging... OK target: https://api.fakedomain.com organization: pds space: staging # switch to my other org $ vmc target -o mhlsoft Switching to organization mhlsoft... OK Switching to space blaster... OK target: https://api.fakedomain.com organization: mhlsoft space: blaster
The new “vmc orgs” command and “vmc spaces” command are simple enumeration commands that display the orgs that the current user belongs to and that she can target, and the spaces within that org:
# enumerate the orgs that are available to be within this cloud $ vmc orgs Getting organizations... OK pds mhlsoft # enumerate the spaces within the current org $ vmc spaces Getting spaces in pds... OK markl production qa staging # enumerate the spaces within my other org $ vmc spaces -o mhlsoft Getting spaces in mhlsoft... OK blaster
The next new command to note is “vmc org”. This command lets you take a look at an org and see its spaces and options.
$ vmc help org Show organization information Usage: org [ORGANIZATION] Options: --full Show full information for an org -o, --organization, --org ORGANIZATION Organization to show # show the current org $ vmc org pds: domains: none spaces: markl, production, qa, staging # show another org $ vmc org mhlsoft mhlsoft: domains: none spaces: blaster
As a peer to the “vmc org” command, there is the new “vmc space” command. This command lets you take a look at a space and see its org, its apps, its services, and its options:
$ vmc help space Show space information Usage: space [SPACE] Options: --full Show full information --space SPACE Space to show -o, --organization, --org ORGANIZATION Space's organization # show the current space $ vmc space production: organization: pds apps: pds-mgmt, pds services: redis, rabbitmq, redis-stats # show a different space $ vmc space staging staging: organization: pds apps: stress, pds, pds-mgmt services: postgres, redis-e6ebd, rabbitmq-e1a06, redis-stats
As discussed in the previous post, the app names and service names are scoped to a space. This means that you can re-use app names across spaces. To see this from a different command’s perspective, take a look at the enhanced “vmc apps” command:
$ vmc help apps List your applications Usage: apps Options: --framework FRAMEWORK Filter by framework --name NAME Filter by name --runtime RUNTIME Filter by runtime --space SPACE Show apps in a given space --url URL Filter by url # list apps in the current space $ vmc apps Getting applications in production... OK pds-mgmt: started platform: sinatra on ruby19 usage: 256M × 8 instances services: rabbitmq, redis-stats, redis pds: started platform: node on node06 usage: 256M × 16 instances services: redis, redis-stats # list only node apps in the staging space $ vmc apps --space staging --runtime node* Getting applications in production... OK stress: started platform: node on node06 usage: 256M × 1 instances services: rabbitmq-e1a06 pds: started platform: node on node06 usage: 256M × 1 instances services: redis-e6ebd, redis-stats
Hopefully this will give you a good feel for how to use VMC to navigate around the system, how you can segregate apps into spaces, and how these new features will help with basic operational collaboration. All of the code that backs this system is being developed in the open, so poke around the vmc and cloud controller repos if you are curious, or better yet, come on in and help us out!
Organizations, Spaces, and Custom Domains
Finally, some of you very careful readers might have noticed that in the “vmc org” output, there is a row for “domains:”. This code is still under development, part of this phase’s work stream. This is the first step in rolling out official, integrated support for custom domains. We will talk more about this feature as it starts to take form. The short story is simple: an org can be assigned one or more domains or wild-card domains. This same capability extends into spaces with the restriction that a space may only attach to a domain enabled for the org. Once a space is enabled for a domain, then apps within that space can use that domain. Semi-fake output is included below to illustrate this point.
# show the current org, note that # it's enabled for *.cloudfoundry.com as well # as a custom wildcard domain $ vmc org pds: domains: *.cloudfoundry.com, *.mydomain.com spaces: markl, production, qa, staging # show the production space # note that it is ONLY enabled for # the custom domain, production apps # can not accidentally live on *.cloudfoundry.com $ vmc space production production: organization: pds domains: *.mydomain.com apps: pds-mgmt, pds services: redis, rabbitmq, redis-stats # show the staging space # note that it is ONLY enabled for *.cloudfoundry.com # staging apps can not accidentally live on *.mydomain.com $ vmc space staging staging: organization: pds domains: *.cloudfoundry.com apps: pds-mgmt, pds services: redis, rabbitmq, redis-stats # list apps in production. note their URLs $ vmc apps --space production Getting applications in production... OK pds-mgmt: started platform: sinatra on ruby19 usage: 256M × 8 instances urls: manage.mydomain.com services: rabbitmq, redis-stats, redis pds: started platform: node on node06 usage: 256M × 16 instances urls: www.mydomain.com, mydomain.com, pds.mydomain.com services: redis, redis-stats
The next generation cloud controller introduces the new organization and space objects. These objects provide the foundation for a wide range of commercial class features including operational collaboration, advanced quota management and control, custom domains, etc. While the code speaks for itself, I will continue to provide added color and commentary in these blog posts.
-markl Mark Lucovsky, VP of Engineering – Cloud Foundry
About the AuthorMore Content by Mark Lucovsky