Max’s Adventure in SAP Cloud Platform: Pimp my Cloud Foundry CLI
In this post I explain how I use the “multiapps” plugin for the Cloud Foundry ‘cf’ command line interface, one of many tools I use when working with SAP Cloud Platform on the command line.
This blog post will be followed by some more, where I will give you a short list of the Cloud Foundry CLI plugins I use. Additionally I will recommend some of my frequently used commands that often make it easier for me to work with the SAP Cloud Platform (or Cloud Foundry in general). I’m going to start with the multiapps plugin (for MTA/Multi-Target Applications).
Yes, I have become an absolute fan of command-line tools. And yes, I have often avoided them in the past. Why? Legit question. Probably my perceived entry hurdle was too high. Meanwhile I tend to do as much as possible via the terminal. Because another potential source of error (any UIs) is eliminated and because many individual puzzle pieces can be combined, making the terminal very very powerful.
I have recorded example executions of some commands via asciinema. You could either just click on the screenshots below the commands or see the section asciinema at the end of this blog post, where I have described how to get the replays working directly in your terminal.
But let’s first cover some basics..
What is Cloud Foundry?
What I basically do when I want to shed more light on a topic, and with that I am presumably not the only one in 2020, I google for it. So, Google, what is Cloud Foundry?
“Cloud Foundry is an open source, multi-cloud application platform as a service(PaaS) governed by the Cloud Foundry Foundation […]. Cloud Foundry’s container-based architecture runs apps in any programming language over a variety of cloud service providers. This multi-cloud environment allows developers to use the cloud platform that suits specific application workloads and move those workloads as necessary within minutes with no changes to the application.”, says Wikipedia.
And one of those service providers is SAP with SAP Cloud Platform. Users who are using SAP Cloud Platform for the first time usually do so via the frontend called SAP Cloud Platform Cockpit. However, this is often not enough and does not offer the full range of functions. Therefore, many users prefer to use the command-line based path via the Cloud Foundry CLI.
What is the Cloud Foundry CLI?
The Cloud Foundry CLI (Command Line Interface) basically allows you to connect to different Cloud Foundry environments from the comfort of the command line. This can mean different SAP Cloud Platform environments, or other managed (Pivotal, SUSE, etc.) or unmanaged (e.g. your own Cloud Foundry instance installed locally or at any Cloud Provider) environments.
The Cloud Foundry CLI can be download it via various package managers like Brew for macOS, or Chocolatey for Windows or as commonly used via installer/binary packages. We have a dedicated tutorial about how to do the installation:
After that, you should have ‘cf’ as a command-line option. It is extensive per se, but with expandable potential. The CF CLI is however so open that developers can provide plug-ins to provide more or extended functionality. This is achieved via plugins. CF CLI plugins are usually installed via a so-called repository, which must be registered in your CF CLI:
cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org
Plugins can then be installed and used with the following command:
cf install [plugin_name]
If you later want to check out which plugins are installed and which commands they provide, simply use:
Enough skirmishes, here is the first CF CLI plugin I use.
The plugin developed by SAP is probably my most frequently used plugin. It allows to deploy so-called Multi-Target Applications (more explanations on help.sap.com and thus simplifies the deployment of multiple applications (called modules in the MTA context) together with resources in the cloud foundry space. It combines several manifest.yml files in one descriptor and also ensures that the necessary services (called “resources” in the MTA context) are created in advance if necessary.
Otherwise, the services would have to be created manually, as in the vanilla Cloud Foundry environment, before the applications can be deployed with the manifest file. MTA deployments also have the additional advantage of defining chronological dependencies between individual elements during deployment.
Each MTA deployment / undeployment process will get its own OPERATION_ID which will be printed to the console after your process finished. The OPERATION_ID is required if you want to retry this process or download the according logs.
Install the plugin, after you have registred the CF-Community repository.
cf install-plugin multiapps
Frequently used commands:
So, to test the subsequent commands you would necesarily have to use a Multi-Target Application, right? Here’s a Repository of MTA-Examples, which you could easily use – not only for the commands in this blog post. Downloading / Cloning this repository and build the MTA Archives (with mbt build) is the only step you have to do in order to produce a MTA Archive.
Let’s get started with the first command:
cf deploy [name_mta_archive]
Deploy an MTA archive consisting of modules, mostly stateless microservices/applications and resources, mostly stateful backing services. Resource creation and binding of the services to the modules takes place implicitly. Advantage over classical cloud foundry manifest deployment, where no services can be created on the fly, but must be instantiated manually beforehand.
cf deploy [name_mta_archive] -r [resource_names]
Merely a subset of resource should be considered during the deployment process. Helpful in early development phases, where deployment is often required. -> Faster deployment process
cf deploy [name_mta_archive] -m [module_names]
Merely a subset of modules should be considered during the deployment process. Helpful in early development phases, where deployment is often required. -> Faster deployment process
List of already deployed Multi-Target Applications in a specific Cloud Foundry space. Important to run the following cf undeploy.
cf undeploy [name_mta_archive] --delete-services
One (in my opinion) of the most helpful commands. Where cf deploy has taken care of creating a whole bunch of artifacts in Cloud Foundry, cf undeploy reverts it. Without the –delete-services addition, only the modules (in MTA jargon, or apps in Cloud Foundry jargon) are deleted.
The addition –delete-services has even more advantages, if this is desired at all. In addition, services, their service keys and the routes to the corresponding applications are deleted and the entire MTA is cleaned up. Your space looks again as if the MTA had never been deployed.
cf bg-deploy [name_mta_archive]
Very similar in content to cf deploy, but as you can see from the help for this command, with a blue-green deployment scenario. This means that the plugin makes sure that your new version (GREEN or BLUE, whatever the current color is) of the MTA is not accessible via the live routes, but provides so-called temporary routes for this purpose. This allows you to verify that everything meets your expectations before the old MTA version is overwritten – without the end user on the live routes will be effected anyhow.
The plugin aborts after the updated version (temporary routes) is available. Either, you agree with the new version, then you can finish the deployment with
cf bg-deploy -i [mta_operation_id] -a resume
which makes the new MTA version “productive” and is no longer only accessible via the temporary routes. Or you have determined that the new version should not be set productive, then you can undo the whole process with:
cf bg-deploy -i [mta_operation_id] -a abort
Whatever you do with MTA deployments, your actual operation is registered and will be listed, if it’s not yet successfully finished. If your deployment is still ongoing or aborted, if the blue-greendeployment is waiting for resume/abort. The ID of the operation is always required to retrieve information or trigger the resume/abort the actual deployment.
cf dmol / cf download-mta-op-logs
Once your deployment process fail, you definitely want to check out the root cause and which element was causing the issue. The logs will always end up in a subfolder of your working directory called “mta-op-[OPERATION_ID]”. Each module / service will produce an own log file in this folder. cf dmol is just an alias for the long cf download-mta-op-logs. The OPERATION_ID is usually part of the last log output of your deployment / undeployment process.
cf dmol -i [mta_operation_id]
Since this and the following blog posts will be focused on terminal / command line tools, I’d recommend to install asciinema. With that you can easily start my recordings in your terminal. The command will always be:
asciinema play [LINK]
# Debian / WSL (Windows Subsystem for Linux) sudo apt-get install asciinema # Arch pacman -S asciinema # Mac brew install asciinema
That’s it so far for the multiapps plugin. Let me know if you have any questions. In the next blog post we will have a closer look at monitoring and orchestrating your Cloud Foundry space!