This post covers the Cloud Foundry vmc CLI interface and how it interacts with Cloud Foundry. There will be another post covering what Cloud Foundry does on the back-end when clients (such as vmc or STS) connect to it coming soon.
Targeting Cloud Foundry
Step 1 : vmc target api.cloudfoundry.com
When you first install vmc and are ready to start controlling Cloud Foundry, you will need to first select it as a target. Why do you need to select api.cloudfoundry.com ? Because vmc is capable of connecting to any Cloud Foundry instance whether it be at cloudfoundry.com or elsewhere. Selecting a target also allows you to use the same CLI to interface with multiple Cloud Foundry Clouds in the same way.
Step 2 : vmc returns “Successfully targeted to [http://api.cloudfoundry.com]
This indicates that vmc was able to get a valid response from api.cloudfoundry.com, meaning that it is a valid Cloud Foundry instance.
NOTE: The diagram numbers repeat each time a new command is issued through vmc
Logging into Cloud Foundry
Step 1 : vmc login
After typing the command, you will be prompted enter your email address and password. Your credentials are then passed via. vmc to Cloud Foundry where they are validated. Assuming that your credentials are validated, Cloud Foundry then issues a Security Token back to the vmc client.
Step 2 : Successfully logged into [http://api.cloudfoundry.com]
This is displayed once the vmc client has received the Security Token. You are now able to issue commands to control your instances on Cloud Foundry through vmc.
Using vmc push to Deploy an Application
Step 1 : vmc push
The follow on steps go into the details of the Dialog displayed above. Going through what each step is and what it does.
Step 2 : This allows you to select an alternative location for your application. When using vmc push you can add —path /some/location this allows you to stay in a different directory context than the application that you are deploying.
Step 3 : Naming your application gives you the ability to use a simpler friendly name when referencing it inside of vmc. This name can (but doesn’t have to) be disconnected from the Deployed URL where users will access your application.
Step 4 : Application Deployed URL is where users will access your application the internet or outside of your Cloud Foundry instance.
Step 5 : Detecting or Selecting Application Types
vmc attempts to detect the framework that is in use, which allows it do decide what the correct run-time environment that is needed will be. If you are doing something where you want your code treated a specific way or if vmc cannot detect the framework being used, you can manually select the framework and this will cause your code to be treated as code for both this framework and the associated run-time of that framework.
Step 6 : The Memory Reservation is used to allow you to determine how much memory your application will need. The Memory Reservation is part of the manifest which will be described later and it is also used to ensure that you are staying within your quota limits of the system.
Step 7 : vmc has Created the Application LOCALLY, this means that all of the application metadata has been created and saved. Application Metadata makes up the manifest and includes :
- Application Name
- URL
- Framework
- Run-time
- Instances Needed
- Memory Reservation
It is important to realize that no bits have been sent to Cloud Foundry yet.
Step 8 : Binding Services to your Application offers the ability to add capabilities such as Redis (a Key/Value Store), MySQL (a Relational Database), along with other services such as messaging.
Step 9 : Because your application is being run remotely (not on your local OS) it has to be preprocessed before it is sent to Cloud Foundry. The next few steps will walk through the sophisticated process by which vmc and Cloud Foundry work together to find the most efficient way to upload your code.
Step 10 : Checking for available resources is examining the metadata and manifest to decide what it needs to send. The process that vmc follows to decide what it should send to Cloud Foundry follows a multi-stage process, which is described in the next few diagrams.
Step 10a : The Metadata is examined (what resources the application needs, what runtime and framework it is supposed to use, etc.)
Step 10b : Look at Components (Decide what gems, libraries, npms, etc. are used in preparation for the next step.
Step 10c : File based Fingerprinting (This is where a Manifest of files is built along with a SHA-1 hash associated with that file).
Step 10d : The manifest is then sent to Cloud Foundry.
Step 11 : The Application has been successfully packaged, what is packaging? See the next diagram for details (and what happened with the manifest sent in Step 10)
Step 11a : When packing begins, a manifest is sent from Cloud Foundry to vmc. This manifest lists only the files that Cloud Foundry needs, not all of the files that make up the application. This method of only requesting and sending what is needed makes uploading far more efficient than if all code/application files were sent with each push.
Step 11b : vmc copies the necessary files (only those that Cloud Foundry needs) and compresses them
Step 11c : The vmc manifest is prepared along with the compressed file containing all of the code needed by Cloud Foundry.
Step 11d : The file is ready to be uploaded to Cloud Foundry.
Step 12 : vmc Uploads the application (just the manifest and compressed file) to Cloud Foundry. In the above case you could see 0K uploaded if you are deploying an application that someone else has deployed previously. This is because Cloud Foundry doesn’t just look at files that you have sent it, but all files that it has seen previously. By looking at all previous files, the upload efficiency can be increased because there are more likely to be files that Cloud Foundry has seen before.
Step 13 : When Push Status returns OK, the application has been received by Cloud Foundry and can now be used for Staging.
Step 14 : Staging Application does not return okay until Cloud Foundry has successfully allocated the resources and environment for your application to run.
Step 15 : Starting Application is not required but will happen automatically unless you add —no-start to the command line when doing a vmc push. Starting Application will not return OK until vmc receives information from Cloud Foundry that all Application instances are healthy/running.
Once your application has started successfully, you can visit the Deployed URL http://hello.cloudfoundry.com in this case to use the application that was deployed.
The Cloud Foundry Team has made many efforts to make resource usage and efficiency top priorities in the code and the system’s design.
More posts to follow on how Cloud Foundry works.
About the Author
