Overview
Developers, who have been using PCF, have always been asking this question that how do we know which version is running on PCF. We used to check this in on-premise by going to that VM and check the jar version. Also, how to do rollback smoothly for PCF deployments as doing it at SCM (Github) or CI/CD level is painful and risk-prone. It involves verification, approval and other deployment processes.
With PCF 2.6, Pivotal has come up with a feature called "App Revisions". Using this feature, we can rollback the deployment for an application very easily. In this article, we will try to understand this feature and walk through the steps for rollback.
What is App Revisions -
A revision represents code and configuration used by an app at a specific time. In PCF terms, it is an object which will contain references to a droplet, environment variables, and custom start command. Have a look at a simple example below:
In the sample above, we have retrieved all the revisions for an application based on it's GUID using PCF CAPI. In line 15, it has a "resources" object. This object contains all the revisions for an application. Resources will have an array of objects and each object will have a guid which represents a revision. The "description" node will provide a PCF configured description of the revision. For example, in this case, the first revision description at line 30 tells that it is the "Initial version" which got deployed for this application.
Now, whenever there is a change in the application deployment, it will create a new revision with a new GUID. Following are the events which will trigger the new revision:
- A new droplet is created which happens when you do "cf push" after making a change to the code.
- An environment variable is added or changed for the application.
- A custom start command is added or changed in the manifest file.
- An app rolls back to a previous version.
Steps to Follow to Enable, View, and Rollback Revisions -
Step 1 - Take an application that can run on PCF. Deploy it on PCF using cf push command.
Step 2 - Now, get the guid of the running app by executing this command:
Step 3 - Run this command to enable the revision for this app:
Step 4 - Let's check what is the current revision for this deployed application. You will notice an "Initial revision" as a description for the first revision after enabling it:
Step 5 - Now, we will use the environment variable event to trigger the new revision for this example. Add an environment variable to the application using below command and then restage the application to reflect the changes:
Step 6 - Lets, check if there is any new revision that has been added for the application. You will notice a new guid is added in the resources node with a description "New droplet deployed. New environment variables deployed.":
That's the way it keep creating new revisions for each event mentioned above in the article.
Step 7 - If we observe that the description node of the revision is predefined text configured by PCF. We don't have control to change it. Let's suppose we do multiple "New Droplet deployed" type of events. How would we be able to recognize the particular revision? To overcome this, we need to tag each revision with a proper Release version and description. We can use the "metadata" object for this purpose. PCF v3 CAPI provides access to revisions to update the metadata object using the CAPI PATCH request. See the example below:
You will see output like below:
It has been observed that the key_value under metadata does not accept space. It should be Alphanumeric characters only. Though, Empty values are allowed.
Step 8 - Let's set up one more env variable to create one more revision so that we can try to rollback.
Step 9 - Let's now see how to rollback the changes and go back to a previous revision. Going back to the previous version is very easy and can be done with one command:
Step 9 - Let's now see how to rollback the changes and go back to a previous revision. Going back to the previous version is very easy and can be done with one command:
Findings -
- If an environment variable is added in the manifest file and pushed to PCF using "cf push", it will create 2 revisions. One with "New environment variables deployed" and second with "New Droplet Deployed" description. This may create confusion while doing rollback.
To overcome this issue, we can set the environment variable using the "cf set-env" command and then restage the application. This will create only one revision with "New droplet deployed. New environment variables deployed." description. - If you try to roll back to the current version itself, it will not throw any error and create a new revision with a new GUID. This should be raised as a bug to PCF.
- When you do roll back to the previous version, it ensures that it has a currently configured number of instances running. For example, if your application has 2 instances. it will first spin up 1 new instance with revised revision and then destroy the existing instance containers. So, It is ensuring that there is no downtime caused while doing the rollback. However, we need to ensure the capacity for 1 new instance is considered before doing this activity. Also, Users may experience different behavior of the application momentarily as both an old and new version of the apps will be live for a very small period.
- While doing a rollback, keep in mind that by default, PCF retains only the 5 most recent staged droplets in its droplets bucket. So, it cannot go back until this value is increased. Please note every revision does not mean a change in the droplet. PCF retains max 100 revisions by default.
Conclusion
In this article, we have seen how the App Revision feature works and how we can use this feature to do a rollback. I believe, it will further smoothen the process of deployments in PCF. I would recommend to put all these above commands in your CI/CD pipeline and use this feature to tag your deployments in PCF.
No comments: