To help new and experienced users alike, here are the Top 10 Cloud Foundry CLI Tips and Updates we presented at the IBM Index conference on February 20, 2018. View our slides here.
Key Takeaways
- Always use the latest Cloud Foundry CLI version to get bug fixes, new features, and security patches (download here)
- Consider using add-ons (see items 8 and 9 below)
- The Cloud Foundry CLI team welcomes your feedback!
Introduction
$ cf push
$ cf help -a
If you aren’t already familiar with it, the Cloud Foundry Command Line Interface (CF CLI) is an open-source, text-based client for Cloud Foundry. It’s an efficient tool for app developers to quickly deliver their code to users through cf push and other commands. The CF CLI has 191 commands that expose features from many Cloud Foundry components. To see the full list of commands, including the latest experimental commands, use the command cf help -a.
#1: Get Bug Fixes
We often hear from CF CLI users that they’ve encountered a bug. When the bug is on the CF CLI itself (and not a backend component the CLI uses), the most common resolution is to upgrade to the most recent CF CLI version, because many users report the same bugs. You can download the latest CF CLI from our Github downloads page.
In addition to bug fixes, the latest CF CLI will have the newest features and most recent security enhancements. As of February 2018, the CF CLI is backwards compatible to CF 203 / CC API 1.23, from March 2015.
#2: Improved Push
$ cf push
The most important and powerful CF CLI command is cf push, which simplifies many steps for app deployment into one powerful command. We have an improved version of push you should know about.
The biggest benefit is you can now see what is going to change when you push your app as output from the push command, which now begins with a “diff” contrasting the desired and current state. Here’s an example of that output:
Another benefit is that push runs more quickly because we’ve streamlined the file management system. The command no longer makes extra copies of the app bits when packaging them for upload, which could overwhelm local processes like virus monitoring. The CF CLI streams large app bits so it doesn’t need to consume large amounts of memory.
The screenshot below shows a time savings of 700 percent in one case.
Additional benefits of improved push include:
- Simplified app manifest properties by deprecating inheritance and other complicated features in favor of more explicit alternatives
- Supports authenticated Docker images
- Displays errors and warnings to STDERR instead of STDOUT
- General stability improvements and bug fixes
- Extremely well tested (167 integration tests for push as of 2/20/2018)
#3: Cloud Controller V3 Granular Push & Other App Commands (experimental)
We have exposed more Cloud Controller (CC) V3 features in CF CLI commands.
CC V3 Granular Push Commands (Experimental):
v3-create-app -> v3-create-package -> v3-stage -> v3-set-droplet -> v3-start
If you sometimes want finer control of push-related actions, now you can use these granular push commands.
- v3-create-app creates a Cloud Controller V3 application
- v3-create-package updates the underlying app bits for an application that’s already running on Cloud Foundry by uploading a CC V3 package
- v3-stage creates a new droplet for an application
- v3-set-droplet switches to a previously compiled droplet for an application
- v3-start starts an application
Some additional v3 app commands include:
- v3-push can specify multiple buildpacks for a single app
- v3-apps lists all applications in the targeted space
- v3-app displays the health and status for an application
- v3-packages lists the packages of an app
- v3-droplets lists the droplets of an app
- v3-delete deletes a V3 app (opposite of v3-create-app)
- v3-stop stops an application (opposite of v3-start)
- v3-scale change or view the instance count, disk space limit, and memory limit for an application
Again, view these and other commands by running cf help -a.
NOTE: Experimental commands are subject to change without notice.
#4: Service Instance Sharing Commands
share-service, unshare-service, service
With cf CLI v6.35.1 or later, you can share your favorite services between different spaces, in the same or different orgs, instead of creating and configuring a separate service instance in each space.
We’ve also updated the service command to display which spaces a service is shared to or from, when applicable.
To read more about this feature, including settings required to enable service sharing and authorization required to share/unshare services, check out docs.cloudfoundry.org.
#5: Improvements to Plugin Installation Flow
install-plugin, plugins –outdated
We’ve recently made three improvements to plugin installation.
- To save you time when installing a plugin, you can use cf install-plugin MY-PLUGIN to search all registered plugin repositories and install the correct plugin.
- To improve security, the install-plugin command now validates and fails plugin installation from a URL when the checksum doesn’t match.
- Use the plugins command with the new –outdated flag to see which of your installed plugins have more recent versions available.
#6: (bash) Tab Completion
[tab]
You can hit the tab key to complete typing commands, flags, local file paths, and some other items. This CLI feature was modeled after BASH tab completion to save you time when typing and to help you discover more commands and flags.
NOTE: Tab completion only works when installed via Homebrew or with an installer package.
#7: Service Account Authorization (Client Credentials)
auth –client-credentials
Also with CF CLI v6.35.1 or later, your scripts can use a service account to authenticate. This improves security and stability by segmenting service accounts from user accounts as the two types serve different purposes; you don’t want a script to fail because a departed colleague’s account was deactivated.
Here’s the command format:
$ cf auth CLIENT_ID CLIENT_SECRET –client-credentials
#8: Isolation Segments (add-on)
Isolation Segments are an add-on that allow you to separate resources for application deployment within a single Cloud Foundry instance, so you no longer have to create separate Cloud Foundry instances simply to get this separation.
This includes being able to isolate applications into different networks.
You can separate hardware resources by private vs public networks, by operating system, development vs production environments, or any other specifications you may need. Now your apps can run in isolated networks and/or with dedicated resources. It works by letting you tag machines and refer to those tags using the CF CLI.
With the CLI, you can finetune networking permission on an org and space level by specifying:
- Which orgs have access to which isolations segments. This is a many-to-many relationship.
- Which spaces have access to isolation segments, with one isolation segment per space. Users assigned to spaces will only have access to the isolation segments those spaces are assigned to.
Ultimately this means teams can be separated to separate physical machines, and you no longer need multiple Cloud Foundry instances to isolate your apps.
Add-ons require Cloud Foundry configuration settings that vary from the defaults. Talk with your system admin about any add-ons you may want.
#9: Container Networking (add-on)
Another add-on is Container Networking, which reduces latency and improves security by allowing traffic between two applications within a single Cloud Foundry instance.
- Latency is reduced as application traffic no longer has to leave Cloud Foundry, resolve the URL address, re-enter Cloud Foundry, pass through the GoRouter, and finally reach the destination application. This can be a time consuming process.
- Security is improved as apps no longer have to trust all inbound traffic to share information with other applications, because without Container Networking, the destination application is unable to verify whether traffic is from the source application.
Without Container Networking:
With Container Networking:
The CF CLI now enables network policies, which is a defined outbound connection from one application to another. This means that even though a third application may be on the network, without a network policy they will reject communication from one another.
These commands create, remove, and list network policies visible to the Cloud Foundry user:
- add-network-policies
- remove-network-policies
- network-policies
#10: New Lists of Random Hostnames for App Routes
push –random-route
We’ve update the values of random hostnames for app routes. Previously, they were random adjectives and nouns from the dictionary, which sometimes resulted in words that people found offensive. We created our own lists of adjectives and nouns to give us plenty of combinations (over 8,000). For the nouns, we use animals. We considered but didn’t use animals with two-part names. But Dr Nic was sad to hear we took out “tasmanian-devil,” so we’re adding it back soon, without the hyphen. 🙂
Thanks!
Thanks for reading. Again, we welcome your feedback on the Cloud Foundry CLI. Check out the links at the top of this post.
