PCF 2.6 Feature - App Revisions
Become more familiar with this Pivotal Cloud Foundry feature that will let you roll back and deploy a previously versioned application.
Join the DZone community and get the full member experience.
Join For FreeOverview
Developers, who have been using Pivotal Cloud Foundry (PCF) have been asking the question of how they know which version of Application PCF is running. We used to check this in on-premise by going to that VM and checking the jar version. Also, performing a rollback smoothly for PCF deployments at the 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:
> cf curl /v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions
{
"pagination": {
"total_results": 3,
"total_pages": 1,
"first": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions?page=1&per_page=50"
},
"last": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions?page=1&per_page=50"
},
"next": null,
"previous": null
},
"resources": [
{
"guid": "7d09b0f7-afdc-4f41-9359-05ba6aff9b6f",
"version": 1,
"droplet": {
"guid": "8d853248-e7ae-4436-bda1-acad9f680132"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "Initial revision.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T01:14:46Z",
"updated_at": "2019-07-16T01:14:46Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/7d09b0f7-afdc-4f41-9359-05ba6aff9b6f"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/7d09b0f7-afdc-4f41-9359-05ba6aff9b6f/environment_variables"
}
},
"metadata": {
"labels": {},
"annotations": {}
}
},
{
"guid": "db0945e4-aba8-48e0-99aa-46b6076c2cb0",
"version": 2,
"droplet": {
"guid": "8965df19-3642-4e25-86bc-aa729e53101d"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "New droplet deployed. Process type 'task' removed.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T01:15:45Z",
"updated_at": "2019-07-16T01:15:45Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/db0945e4-aba8-48e0-99aa-46b6076c2cb0"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/db0945e4-aba8-48e0-99aa-46b6076c2cb0/environment_variables"
}
},
"metadata": {
"labels": {},
"annotations": {}
}
},
{
"guid": "55089a42-190e-4faa-8225-935d3d9c1411",
"version": 3,
"droplet": {
"guid": "8d853248-e7ae-4436-bda1-acad9f680132"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "Rolled back to revision 1.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T01:28:44Z",
"updated_at": "2019-07-16T01:28:44Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/55089a42-190e-4faa-8225-935d3d9c1411"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/55089a42-190e-4faa-8225-935d3d9c1411/environment_variables"
}
},
"metadata": {
"labels": {},
"annotations": {}
}
}
]
}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 says that it is the "Initial revision" 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. Here are the events which will trigger the new revision:
- A new droplet is created, which happens when you do
cf pushafter 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 the cf push command.
Step 2: Now, get the GUID of the running app by executing this command:
cf app APP-NAME --guid
e.g. cf app spring-cloud-gateway --guidStep 3: Run this command to enable the revision for this app:
cf curl /v3/apps/GUID/features/revisions -X PATCH -d '{ "enabled": true }'
//for linux
e.g. cf curl /v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/features/revisions -X PATCH -d '{ "enabled": true }'
// for windows follow this
e.g. cf curl /v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/features/revisions -X PATCH -d "{\"enabled\": true }"
Step 4: Let's check the current revision for this deployed application. You will notice an "Initial revision" as a description for the first revision after enabling it:
cf curl /v3/apps/APP_GUID/revisions/deployed
>cf curl /v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions/deployed
{
"pagination": {
"total_results": 1,
"total_pages": 1,
"first": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions/deployed?page=1&per_page=50"
},
"last": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions/deployed?page=1&per_page=50"
},
"next": null,
"previous": null
},
"resources": [
{
"guid": "512c1df6-ae8b-45e7-b115-41bf079e528f",
"version": 1,
"droplet": {
"guid": "c5c1ea11-bef0-49b2-a43a-aa404c71d778"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "Initial revision.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T05:39:05Z",
"updated_at": "2019-07-16T05:39:05Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/512c1df6-ae8b-45e7-b115-41bf079e528f"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/512c1df6-ae8b-45e7-b115-41bf079e528f/environment_variables"
}
},
"metadata": {
"labels": {},
"annotations": {}
}
}
]
}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 the below command and then restage the application to reflect the changes:
cf set-env APP_NAME key_name key_value
e.g. cf set-env spring-cloud-gateway key_name revisiontest
cf restage APP_NAME
e.g cf restage spring-cloud-gatewayStep 6: Let's check whether 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." :
> cf curl /v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0/revisions
{
-------------------------Initial Revison details---------commented it for readibility perspective-------
},
{
"guid": "00f958b1-9c7d-48ae-bb28-157d3f661ba9",
"version": 2,
"droplet": {
"guid": "688cd4ef-b90d-4ab8-a353-a6ca6c7d7297"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "New droplet deployed. New environment variables deployed.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T05:20:00Z",
"updated_at": "2019-07-16T05:20:00Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/00f958b1-9c7d-48ae-bb28-157d3f661ba9"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/00f958b1-9c7d-48ae-bb28-157d3f661ba9/environment_variables"
}
},
"metadata": {
"labels": {},
"annotations": {}
}
},That's the way it keeps creating new revisions for each event mentioned above in the article.
Step 7 - If we observe, we'll see 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" types of events. How would we be able to recognize the particular revision? To overcome this, we need to tag each revision with the 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:
cf curl v3/revisions/REVISIONS_GUID -X PATCH -d "{ \"metadata\": { \"labels\": { \"Key_name\": \"key_value\" } } }"
e.g. cf curl v3/revisions/512c1df6-ae8b-45e7-b115-41bf079e528f -X PATCH -d "{ \"metadata\": { \"labels\": { \"ReleaseVersion\": \"1.0\", \"ReleaseDesc\": \"Sprint\" } } }"You will see an output like below:
{
"guid": "512c1df6-ae8b-45e7-b115-41bf079e528f",
"version": 1,
"droplet": {
"guid": "c5c1ea11-bef0-49b2-a43a-aa404c71d778"
},
"processes": {
"task": {
"command": null
},
"web": {
"command": null
}
},
"description": "New droplet deployed. New environment variables deployed.",
"relationships": {
"app": {
"data": {
"guid": "1066210a-acb5-476f-b201-9c0a73d852c0"
}
}
},
"created_at": "2019-07-16T05:39:05Z",
"updated_at": "2019-07-16T05:39:05Z",
"links": {
"self": {
"href": "https://x.com/v3/revisions/512c1df6-ae8b-45e7-b115-41bf079e528f"
},
"app": {
"href": "https://x.com/v3/apps/1066210a-acb5-476f-b201-9c0a73d852c0"
},
"environment_variables": {
"href": "https://x.com/v3/revisions/512c1df6-ae8b-45e7-b115-41bf079e528f/environment_variables"
}
},
"metadata": {
"labels": {
"ReleaseVersion": "1.0",
"ReleaseDesc": "Sprint9A"
},
"annotations": {}
}
},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 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:
cf curl v3/deployments \
-X POST \
-d '{
"revision": {
"guid": "REVISION-GUID"
},
"relationships": {
"app": {
"data": {
"guid": "APP-GUID"
}
}
}
}'
//For windows, i have put like this:
cf curl v3/deployments -X POST -d "{ \"revision\": { \"guid\": \"512c1df6-ae8b-45e7-b115-41bf079e528f\" }, \"relationships\": { \"app\": { \"data\": { \"guid\": \"1066210a-acb5-476f-b201-9c0a73d852c0\" } } } }"We should now be able to see the new revision with the application pointing to the revision configured in the command. You can run below command to check the current revision:
cf curl /v3/apps/APP_GUID/revisions/deployedFindings
- If an environment variable is added in the manifest file and pushed to PCF using
cf push, it will create two revisions, one with "New environment variables deployed" and a second with "New Droplet Deployed" description. This may create confusion while doing a rollback. To overcome this issue, we can set the environment variable using thecf set-envcommand and then restage the application. This will create only one revision with the "New droplet deployed. New environment variables deployed." description. - If you try to roll back to the current version itself, it will not throw any errors 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 two instances. It will first spin up one new instance with a 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 one 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 five 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 a maximum of 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.
Opinions expressed by DZone contributors are their own.
Comments