Today I will discuss how we can manage an deployed application in Cloud Foundry. Cloud Foundry is a Cloud native application development and hosting platform. After we deploy the application the first time it's just the beginning. We need to monitor the application constantly and update it with new versions as needed.
Before everything else we need to monitor the application's health. Cloud Foundry offers an inbuilt mechanism to monitor your application.
Contents
How to monitor application health in Cloud Foundry ?
Application health check is a very convenient process provided by the platform to monitor the application health constantly. There are different ways an application health check can be configured. They are described here. port is the default health check type. Normally in micro services we use health check type http and specify an http endpoint(generally named as /health) that should return a minimum 200 return code. In the response body anything can be specified. The endpoint should not be protected by any authentication. After deploying the application, the platform will use the health to verify whether the application is running, if yes then it will mark the application as healthy. If the platform does not find the application as healthy at any time, it will register the application instance has crashed and automatically restart the application instance and try to maintain the required number of instances. If I have not mentioned it before, you can specify how many instances of application you want to run at the time of deployment or after deployment you can scale out/down the number of instances.
What is a droplet in Cloud Foundry ?
When a user issues cf push command, the deployment artifacts like jar and war files are also provided. A deployment artifact can also be a whole folder structure with the files. For example for nodeJs applications we provide the route folder of the code base. The platform then takes these files and uses the buildpacks to create executables. All necessary environments are also set along with the executable. A droplet is an executable in Cloud Foundry with the deployment artifacts the application runtime and necessary environment.
How to Start an application in Cloud Foundry ?
You can start a stopped application using this command. Cloud Foundry uses an existing droplet to start your application. The droplet used was created last time when the cf push command was issued for this application.
$ cf start <appname>You can refer to the Cloud Foundry documentation here.
How to Stop an application in Cloud Foundry ?
You can stop an application without deleting it completely. Use the below command to achieve this task. Later you can start the same application. Cloud Foundry does not delete droplets when we stop an application. It will use the existing droplet to start your application.
$ cf stop <appname>You can refer to the Cloud Foundry documentation here.
How to Delete an application in Cloud Foundry ?
You can delete an application by this command
$ cf delete [-r] <appname>The -r option is optional but recommended. Te -r option instructs the platform to delete the route(s) associated with the application also. Otherwise you need to manually delete the routes using cf delete-route command. Remember to delete the service instances bound with the application first using cf delete-service command before deleting the application itself. Cloud Foundry deletes the droplets, files and every information regarding the application when we issue the delete command that is why this command is irreversible. You can refer to the documentation for delete here.
How to Restart application in Cloud Foundry ?
You can manually restart an application by issuing this command.
$ cf restart <appname>It will restart the application and all steps performed by the platform at the time of deployment will be performed. As an example, if you write a spring boot application, the spring boot initialization will start again. Please remember when we issue the restart command the application deployment does not follow rolling updates. Your users will experience a brief downtime till the fresh application instances are available.
Difference between (cf) push and (cf) restart
The difference between push and restart is. When a push is issued cloud foundry creates a droplet and loads the deployment artifact or source code (jar/war/nodejs files etc) in the droplet. Saves the droplet and creates an application instance from the droplet. The droplet has the application runtime in it. The push command will delete an existing droplet(if available) and recreate it again. When restart command is issued application instances are destroyed and recreated using the available droplet. Also when push command is issued cf downloads the available build packs and uses an appropriate build pack to run the application and provide the packages needed to run the application. We can also specify which build pack we need in push command or in a manifest file. If you are wondering what is a manifest file, we have another blog to explain it.
You can refer to the Cloud Foundry documentation for the restart command here.
What is Application Restage in Cloud Foundry ?
In Cloud Foundry when we restage an application the available application files like source code and deployment artifacts like jar or war files of the last time deployment are reused. The platform saves the uploaded deployment artifacts or source code when we issue cf push command. The platform recreates the executable artifact(droplet) from these files and also updates the environment variables. Uses the build pack to create the droplet again. The service bindings are also done afresh. Restage also causes application downtime.
How to Restage application in Cloud Foundry ?
Application owners can manually restage an application using this command.
$cf restage <appname>Difference between (cf) restage and (cf) restart in Cloud Foundry
In restage the droplet is built using the available files (jar,war, project files etc.) the service bindings are done afresh and the VCAP_SERVICES environment variables are updated. The old application instances are deleted and new instances are created from the new droplet. When a service instance needs to propagate new environment variables and values to the application the only way is via the VCAP_SERVICES environment variable. The VCAP_SERVICES environment variable will not be updated with new variables and values(if any) when restarting an application using restart command. If it's not updated the application also can't read the new variables or values from the VCAP_SERVICES required to interact with the service instance. To make that happen we need to restage the application. The restate operation automatically rebinds the service instances with the application and ensures that the latest environment variables and values are injected from the service instance to the VCAP_SERVICES. Application instances are deleted and new application instances are created using the old droplet when we restart an old application. Also, when environment variables are needed by the build pack itself to create a new droplet restate is a must. As an application developer when we want to bind or rebind and are not sure whether restart will be sufficient we always should restage the application to be on the safe side. When we want to update an user provided variable and let the application read it, we can just update the variable value or add a new user provided variable and restart the application. In this case restart is sufficient.
You can refer to the Cloud Foundry documentation for the restage command here.
In this blog we have learned how application developers manage an application in Cloud Foundry using start, stop, delete, restart and restage commands.