Cloud Foundry has always had one goal: to help developers push code to production as fast as possible. Development teams have a new tool to assist them in this mission: the cf CLI v7.
The new CLI, like previous versions, abstracts away the nuances of the Cloud Foundry API into a command-line interface that’s easy to use. Developers can use the CLI to enter simple commands and perform complex tasks atop Cloud Foundry.
We’d like to thank the broader Cloud Foundry community for their efforts to reach this milestone. The cf CLI v7 is the result of tremendous work by a diverse, distributed set of contributors around the world.
In fact, because v7 integrates with CAPI’s modern v3 API endpoint, we’re pleased to share that the v7 CLI will be the version the Cloud Foundry community carries forward into the world of Kubernetes. (Expect to hear more about our progress on this front at the virtual Cloud Foundry Summit, happening this week.)
Five highlights of the cf CLI v7
Prior versions of the CLI have made the complex operations far easier. And so it goes with v7. In this release, contributors focused on simplifying sophisticated development and deployment techniques. We also give you more granular control over said techniques. Here’s a list of our favorite enhancements.
1. Rolling app deployments: push new updates without downtime
Rolling app deployments (aka zero downtime app updates) are “table stakes” for teams balancing business continuity with high-velocity feature development. While it has been possible to execute zero downtime app updates using a combination of several CLI commands (as detailed in this documentation), doing so required developers to carefully orchestrate several steps and it was difficult to recover in the event that anything went wrong in the process. The community told us it was too complex and error prone; zero downtime app updates should just work natively.
So with the v7 CLI, you can now apply the –strategy rolling flag/value to execute a zero downtime update in a single command, gracefully, and if the updated app fails to become healthy, it automatically cancels the deployment without applying the update across the app instances. Just enter this command, and you’re rolling! (See what I did there?)
cf push APP-NAME –strategy rolling
The rolling strategy can also be applied to cf restart and cf restage in the GA release. See the rolling app deployments documentation for more details.
In a future release, we’re considering adding the rolling strategy to the flavors of cf scale that require app restarts (scaling memory or disk)
2. Running cf push substep commands: exercise granular control over the cf push process
It’s been said that cf push is the most powerful command in the cloud. While this may be true, the command actually executes multiple sub-commands to achieve its goal. We’ve learned that there are situations where running only a subset of the commands bundled as part of cf push is needed. Running cf push sub-step commands solves this scenario. When a developer executes a cf push, Cloud Foundry:
- Uploads your code to the system
- Detects and installs required runtime and middleware
- Containerizes your app, packaged with dependencies
- Sets up a route or URL
- Creates a load balancing entry
- Creates SSL termination
- Creates health monitoring and logging subsystems
- Starts your app in a healthy state, with the desired number of instances
- Binds specified backing services
This is a magical experience for first-time users especially if you’re accustomed to slogging through oodles of YAML. It’s also magical when you’re using Cloud Foundry at scale. But there are cases where you want a little more control over the push process.
For example, highly regulated firms may want to inspect the build artifact (a “droplet”) before the app goes live. This intervention can help meet compliance requirements; it provides a window into what was previously a “black box” process.
There are many other possibilities here, especially when the sub-steps are injected to your deployment pipeline. For example, use the cf set-droplet command for the app to use a previous droplet, and then do cf restart on the app with the rolling strategy to roll back to that droplet without downtime.
Keep in mind, this is just one of many workflows that can be implemented. The possibilities are endless! We look forward to hearing how you’ve used this new command to create customized workflows and address a range of use cases. The documentation explains how.
3. Use a single command to push apps that run multiple processes
Sounds simple. So when would you want to use this?
Consider a web app with a UI process and a worker process. It’s usually desirable to push updates to the two processes at the same time. (It is a single web app, after all.) Yet, the processes may need to scale independently. With the new CLI, you can tackle this complexity with a single command. Once again, the documentation shows you how.
This is especially useful for applications where you don’t want all of the complexity of microservices, but still desire the ability to “scale independently.”
4. The “sidecar pattern”: run additional processes in the same container as your app
This isn’t the platform-managed sidecars with something like Envoy; it refers to user-provided sidecars. As the CAPI team explains when this scenario is useful:
You might be wondering how using sidecar processes differs from just pushing separate apps as microservices. While it’s true that these use cases overlap, the ability of the sidecar process to run in the same container as its main app grants us several affordances. For example, you may want to use sidecar processes if you have two processes that:
- need to communicate over a unix socket or via localhost.
- need to share the same filesystem.
- need to be scaled and placed together.
- need to have fast interprocess communication.
The APIs for this have existed for some time; now they are officially supported as part of the v7 CLI. Also, you can now enjoy greater visibility into sidecar processes running as part of your app.
5. Add metadata to Cloud Foundry objects like spaces and apps
Your typical Cloud Foundry deployment starts with a few apps, then scales to several hundred. When you’re running huge chunks of an organization’s application estate, it’s handy to understand little bits of information about each application. That’s what this feature is all about: you can now use the CLI to add metadata to resources within Cloud Foundry.
Use this feature to help operate, monitor, and audit a massive deployment of Cloud Foundry. Here are a few sample questions to illustrate just how handy this feature can be:
- Who is the application owner? What’s their email address?
- Is this app in alpha, beta, or production readiness?
- Which department is in charge of the app?
- Who gets billed for the resources consumed for a given app?
- What was the commit SHA associated with the latest release?
All the details of your Cloud Foundry deployment are now more searchable and accessible than ever before!
Two more highlights sure to delight power users
First, we have much closer alignment of the CLI and CAPI with respect to Cloud Foundry v3 API adoption. Long-time Cloud Foundry users know that the CAPI team has used v3 for quite some time. Prior versions of the CLI were stubbornly behind. Now, the v7 brings the CLI much closer to CAPI’s level of v3 API usage. This coherence will serve the community well in the future.
Second, the new CLI introduces server-side processing for app manifests. This solves the case when there are gaps in v3 API support between CAPI and the CLI. If you’d like to use new features of CAPI, you can simply plug those instructions into the app manifest. Just upgrade to the newest version of CAPI, update your manifest, and you’re ready to go! (Meanwhile the CLI will remain on an independent release cadence.)
Other notes on the cf CLI v7
The v7 CLI does introduce some breaking changes. But fear not, there are simple things you can do to mitigate this. Simply pin your processes to v6, update your scripts to be compatible with v7, and then unpin the v6. The method for pinning, as soon as it’s available, will be published here.
How will your particular Cloud Foundry deployment be affected? Review the complete list of differences between the v6 and v7 commands. This comparison table may also help your upgrade plans.
One other item: we plan to publish a fast-follow release in the weeks ahead that will smooth out some rough edges. These two items in particular will be part of this update:
- Existing plugins are compatible with the v7 API but they’re still backed by the v2 API. Plugins will be backed by the v3 API in our next, fast follow, major release.
- Keep an eye out for updates in the project’s GitHub repo.
The Road Ahead
Software products are never done, just shipped. Here’s a look at what’s next for the CLI team:
-
-
- cf-for-k8s support. We will be working with the Release Integration team to get the v7 CLI ready to support the cf-for-k8s project. (New to cf-for-k8s? Get caught up.)
- Updated support model. The world of open source moves at a good clip. To help underscore the need for velocity, we’ll be updating the support model for the CLI. Look for more details on this shortly.
- Update the legacy plug-ins. We’ll systematically enhance these to use the v3 API endpoints.
- Additional capabilities for app revisions and rollback. There’s much more we plan to do for this scenario.
- cf scale APP-NAME –strategy rolling. A logical next step rolling updates.
- You tell us! We’re eager to hear your ideas for the CLI. Find us on GitHub and in the #cli channel.
-
The world of open source is converging on Kubernetes as a center of gravity in the years to come. Armed with this new CLI, the Cloud Foundry community is well-positioned to take advantage of the new and evolving features available in the Kubernetes ecosystem.
