PCF Rolling Deployment

In the recent versions of Cloudfoundry, the command cf v3-zdt-push was made available. This is a form of blue green deployment that handles a lot of hassle for you. Previously, you would have to use tools or write script to help you do blue green deploys. Those methods came with their own set of problems. This new command abstracts away the whole process of blue green deployment and seamlessly deploys with zero downtime. However, there are many caveats and flaws to it.

Blue Green Deployment

In my previous article, Blue Green Laravel Deployment to Pivotal Cloudfoundry, I talked about how I used various opensource tools to do deployment. You should give it a read if you’re new to the concept of Blue Green deployment. It also talks about the blobs of issues I encountered when using these tools.

Pros of cf v3-zdt-push

Its just a command and does all the heavy lifting for you. On top of that, it doesn’t remove existing configuration within your application; this applies to the whole new ‘cf v3-push’ method. This means that you’ll no longer need to recreate your PCF scheduler, PCF auto-scaler config, etc. This is a huge improvement over the previous version of cf push. I was really happy about having this issues fixed.

I’ve also not encountered any unexpected issues. This means that it is relatively bug-free.

Flaws of cf v3-zdt-push

As it is still new, there are many caveats to it. These limitations are stated in the documentation page itself. (You’ll need to scroll to the bottom!)

The biggest problem that I have with this command is that it doesn’t care about manifest. Manifest is the most powerful way to document and design the entire state of your application. Manifest can be committed into a version control whereas manual settings configurations cannot be version controlled.

State needs to be version controlled as we need to know the settings of our deployed application. Amount of memory, CPU, etc deployed is not known to other developers unless they have access to the Cloudfoundry. Usually, developers would not have access to Cloudfoundry and we would have a build & deploy bot/user that have access to Cloudfoundry. This is part of infrastructure access control where we don’t want too many users to have direct access to Cloudfoundry.

On top of that, we need to have a single source of truth (manifest) so that we’ll be able to trace back all our settings. If there are multiple sources of ‘truth’ that presents different truths, we won’t know what is correct state. Without manifest, this means that we will not be able to achieve immutable infrastructure.

Other than that, there’s also some side issues. If you want to deploy a Single Page Application, it is difficult to do so without using containers. Because a typical SPA build would result in having files generated in a separate folder like dist/ . With manifest, you could just specify the deploy directory. And since it is not supported yet, this means you’ll have to Change Directory into the dist/ folder and deploy from there.

Conclusion

Overall, I’m happy with the release of this new beta command despite some shortcomings. This is an amazing feature and I look forward to cf v3-zdt-push having support for manifest. Once support for manifest is available, I think that almost everyone will be able to use this amazing feature. I’ll make another post when manifest support is available.

Author: Woo Huiren

Currently a student at National University of Singapore. I contribute to opensource projects - primarily PHP and Angular related. I write about PCF and PWS related stuff too.

Leave a Reply