Pivotal/Cloud Foundry/Apps
Cloud Foundry | Cloud Foundry CLI | Apps | Tasks | Logs | OpsManager
App Deployment Overview
This is just a quick overview of what happens during app deployment. The steps were obtained by using TRACE during an app deployment and then reviewing the corresponding log file.
~$CF_TRACE=/Users/User/web-app/trace.log cf push web-app
1: HTTP request for json info
Simple HTTP request for json info to the server. Server will reply back with information such as:
- api version and minimum requirement
- addresses for services
2: Login
Next up is to log into the CF Service. Submit another HTTP request for json data pertaining to login services. This will provide login information such as:
- login URL
- forgot password link
- registration
3: Check if the application exists
We want to see if the application already exists in the environment. This will determine whether we are pushing an update or if we are pushing a whole new app.
Get a list of all the shared domains that are available to us.
5: Get list of private domains
Get a list of all the private domains that are available to us
6: Push the app package
If the app is not deployed already, we will push what i'm calling the "package". it is essentially the settings defined in the app manifest to begin prepping CF for the app. CF will respond back with a ton of information regarding the app settings and package configuration.
7: Push the app route
Push the app route, if specified, otherwise the server will create a random route and reply back with the details and settings.
8: Update the app route
With the information provided in the last step, we can make updates and finalize the route.
9: Update Resources (?)
The next step was brief for me, although it appears to be a function to update resources and match their requirements to the app.
10: application update (?)
An application update, very brief, not sure what its for other than to get the current package build status, but unsure why it would be a PUT request instead of a GET request. Seems like something is being updated.
11: GET job status
Determine what the current job status is, probably to determine the build status. In my case, the response came back queued.
12: Another GET job status
Same as above, most likely a looped function to check on status until it returns a Finished result. Mine now finished.
13: Start the application
It seems we are now ready to start the application! We will also get back alot of information regarding the application, however, the next (3) steps may complete before the response is returned. We will get back a response stated STARTED
14: Request an access token (?)
I assume this is an access token for the application, not quite sure what its used for yet.
15: perform a websocket upgrade request
This appears to be where we upgrade the connection protocol to SSL/TLS
16: GET app data/status
quick looped GET request to obtain current app status, we are looking for a change from PENDING to STAGED. Appears to loop every 2-3 seconds.
17: GET app instance(s) status
get instance(s) details, such as the state, uptime, and beginning start time ("since"). Loop every 2-3 seconds until state changes from STARTING to RUNNING.
18: GET app details
get the app details again
19: GET app stats
GET app stats like hardware, urls, etc.
20: GET app instances again
get app instance data again
GET app routes again
get app routes again==
get app shared domains again==
GET Stacks (?)
get stack details like file system used and metadata related to it.
