Cloud Foundry - cf push

'cf push' is the command used in Cloud Foundry for uploading the applications to Cloud foundry. You can deploy an application to Cloud Foundry by running a cf push command from the Cloud Foundry command line interface ( cf CLI). I suppose that you have cf CLI tool installed in your machine already. If you need any help, visit my blog post on it.

Onsi Fakhouri during his tech talk in Cloud Foundry Summit 2015, describes cf push in the following way.

cf push :         Here is my source code
                        Run it on the cloud for me
                        I do not care how ...

I feel this is the best explanation for cf push command. Yes it is. I wonder how he has come up with this attractive explanation.

If we analyse deeply, between the time that you run push and the time that the application is available, Cloud Foundry performs the following tasks:

                 - Uploads and stores application files
                 - Examines and stores application metadata
                 - Creates a “droplet” (the Cloud Foundry unit of execution) for the application
                 - Selects an appropriate droplet execution agent (DEA) to run the droplet
                 - Starts the application

That is the process of 'cf push' in brief. Let me explain it further.

1. First you need to target at Cloud Foundry. For example, you can do it as follows. Or else you can point the URL along with cf target command.

$ cf target

API endpoint:   https://api.run.pivotal.io (API version: 2.48.0) 
User:           nanduni@wso2.com   

Org:            nanduni-org   

Space:          development  

So, why do you need to select a target? 

Simply it's because that Cloud Foundry is capable of connecting to any Cloud Foundry instance whether it is at pivotal.io or elsewhere. Selecting a target allows you to use same CLI to interface with multiple Cloud Foundry clouds in the same way.

2. Successfully targeted to the pointed URL. This indicates that cf was able to get a valid response from that specified URL, in my case from pivotal. Moreover it means that what we have targeted is to a valid Cloud Foundry instance.

3. Logging to cf. We can use cf login command for this. Then you are prompted to enter your email address and password. Credentials are passed via cf to Cloud Foundry where they are validated. Cloud Foundry then issues a security token back to Cloud Foundry client. 

4. Successfully logged into the specified URL, in my case api.run.pivotal.io. Once cf client has received the security token, the client is able to issue commands to control instances on Cloud Foundry through cf.  

5. cf push to deploy an application. You can give the command cf push along with your app name. Naming your application like that gives ability to use a simpler, friendly name when referencing the application inside Cloud Foundry. This name can be disconnected from deployed URL where users access application. You can either define a name for your application with cf push command or with manifet.yml file. 

- name: myapp

6. Application deployed URL is where users access your application through the internet or outside of your Cloud Foundry instance. You can define a name for the URL in the manifest.yml file as: 

host: nandy

7. Memory reservation allows you to determine how much memory your app will need. Ensure that you are staying within your quota limits of system. You can define this in the manifest.yml file as : 

memory: 256M

8. cf has created an application locally. That means that all metadata has been created and saved. app metadata makes up manifest and includes app name, URL, framework, run-time, instances needed and memory reservation.

9. Bind services for your application. An application that uses services, such as a database, messaging, or email server, is not fully functional until you provision the service and, if required, bind the service to the application. Binding services offers ability to add capabilities such as Redis, MySQL, other services such as messaging. 

Cloud Foundry offers a marketplace of services, from which users can provision reserved resources on-demand. Examples of such resource services include databases on a shared or dedicated server or accounts on a SaaS application. These resources are known as Service Instances and the systems that deliver and operate these resources are known as Services. Think of a service as a factory that delivers service instances.

User-Provided Service Instances

Cloud Foundry enables users to integrate services that are not available in the marketplace with their applications using a feature called User-Provided Service Instances (UPSI).

10. Preprocessing : Because your application runs remotely, it has to be preprocessed before sending to Cloud Foundry.

11. Checking for available resources is examining metadata and manifest to decide what it needs to send. Metadata, components(eg: gems + libraries + npm) are examined. Manifest is then sent to Cloud Foundry. 

12. App has been successfully packaged. When packaging begins, manifest is sent from Cloud Foundry to cf. Manifest lists files only cf needs, not all of the files that makes the application. This method of only requesting and sending what is needed makes uploading far efficient than if application or code files are sent with each push.

13. cf copies necessary files and compresses them.

14. cf manifest is prepared along with the compressed file containing all the code required by Cloud Foundry.

  

15. File is uploaded to Cloud Foundry.

16. cf uploads application along with manifest and compressed file. If you are re uploading, cf will not upload again. This is to increase upload efficiency, because there are more likely to be files that cf has seen before.

17. Push status returns Ok. Then the app has been received by Cloud Foundry and now it can be staged.  

18. Staging app does not return Ok until Cloud Foundry has successfully allocated resources and environment for the application to run.

19. App starts automatically unless you add -no--start to command line when doing cf push. Starting app will not return Ok until cf receives information from Cloud Foundry that all application instances are healthy and running. 

20. Visit deployed URL.  You can find it easily from the output of successfully terminated cf push command. 

I think this blog post would have been useful to understand the background process of cf push command as well as the process of deploying an application in Cloud Foundry. I will add more posts on new features of Cloud Foundry in the near future.  I am hoping to add a post on "Cloud Foundry with Diego" very soon.