Cloud Foundry CLI Detailed Tutorial

This article will provide details and practical usage of cloud foundry command line interface including its installation and usage. We will also see the usage of commands in a step by step approach. We will not cover details of the platform itself and it is assumed that viewer already has some experience with cloud foundry or is already using it in the projects.

Important to know is that earlier Cloud foundry (and pivotal cloud foundry) use to support CF platform installation on a local development machine. But now this support has been officially stopped and required package is no longer available to download and install. You can find some reference in Installing PCF Dev on Microsoft Windows 10 | VMware Tanzu Docs (pivotal.io). CF CLI can be installed on any platform and machine but in that case dev machine need to connect to remove environment where Cloud Foundry has been installed . CLI is available on PCF CLI OR we can also install it from cloudfoundry.org using this link available under Installing the cf CLI | Cloud Foundry Docs.

Due to above constraint, we will be covering CLI commands and their details but running them will not be feasible on dev machine.

Summary of all CLI Commands in an order

Log into the CF instance

cf login –sso https://yourCFAPIEndPointURL -skip-ssl-validation

cf login

Above command expects that CF is already installed and there is a backend api end point that is made available to us to login. Moreover, all developer account will be added to CF instance by the CF operations team and only then they will be able to login. Based on the authentication mechanism setup by the organization, developers should expect the authentication.

After running above command, we should expect an output where it should show logged in user account and the api endpoint.

Target a workspace in CF

cf target -o yourOrganizationNameInCF -s yourspaceNameUnderCFOrganization

cf target

Developers are always added in CF under an organization and in a workspace under a specific organization. This is because CF platform will be used to host large number of applications and services and hence teams need to have their own containers and isolated spaces to manage their apps and services. In order to use above command, developers need to know their CF organization and space as a pre-requisite.

After running above command, we should expect to see specified organization and space in console output.

View all the Organizations available in CF for the logged in user

cf org

cf org

We should see list of organizations where the logged in user is mapped to.

View all the workspaces/cf spaces available in CF for the logged in user.

cf t

cf target

We should see list of all the spaces available under the targeted organization.

View all the existing applications hosted under a targeted org and space.

cf apps

cf apps

We should expect to see names and associated URL routes of the applications in the output.

View all the URL routes available in a given cf space

cf routes

cf routes

We should expect to see alot of details as part of the routes like the host name, domain name under which the hostnames are mapped. protocol and port details and the application to which the route is mapped.

example: https://myApp.apps.cfenvName.xyz.com – myApp is the hostname, apps.cfenvName.xyz.com is the domain name and https is the protocol.

To see help documentation for any Cf CLI command

cf commandName –help

Create a new route in CF space

cf create-route CFDomainName –hostname ApplicationName [–path ExtraURLPathValue]

cf create-route

Running the above command will create a route ApplicationName.CFDomainName/ExtraURLPathValue in the targeted cf space. Please note, at this point this URL/route is an independent resource not associated to any application. Mapping of the cf application with the route can be done at a later stage as well. Also important to note is that the path parameter is optional and not mandatory and this is useful when we want to map same base URL with multiple applications based on the path difference. More parameters can also passed to this command and we can use –help flag to now more.

Important note on CF Domains – CF domain is the domain name that is mapped to the CF installation in an organization. This is the domain that is registered in DNS servers as well. All the routes that are created using this domain have nothing to do with the DNS server and they are not registered in there. These application level routes are internal to the cloud foundry platform and are used to identify the applications and make them callable. Moreover, single instance of CF can have multiple domains associated to it as well.

Add a new Url Route to an existing application

cf map-route ApplicationName CFDomainName –hostname myapp –path additionalPath

cf map-route

Once we run this command, we should expect a route added to our application and it will be myapp.CFDomainName/additionalPath

Scaling an existing application in CF space

cf scale ApplicationName -i 2 -m 1G

cf scale

Once we run above command, we should be able to see application level details along with the number of instances and their state and memory allocation details in the output.

Read all the service broker services available in CF organization

cf m [-s ServiceBrokerServiceName]

cf marketplace

In cloud foundry there are a set of services that are available as part of the platform itself and these are service broker services. We can also implement our own custom Service brokers as well but that is beyond the scope of this topic.

Show all the environment variables used by any existing application

cf env ApplicationName

cf env

We should expect to see two kind of sections in the output with first called VCAP_SERVICES and this hold all the custom environment settings for any services we have mapped/bound to our application. Another is called VCAP_APPLICATION and this will contain application level settings like application ID associated to our application and URLs/routes mapped to our application etc. Lastly it will also have a second called User-provider and this will hold any custom environment settings we have added to our application as part of its deployment process. These are used in the application to control our application flow and logic.

Setting an environment variable for an existing application

cf set-env ApplicationName settingName SettingValue

cf set-env

These will be added to User_Provided section as explained above.

Create a new Application in cloud foundry

>> move to the base directory in your machine where project’s build/compile out is stored.

>> cf push ApplicationNameInCF [–no-route] [–no-restart]

cf push

This is one of the most important command in CF since this is used to deploy applications to CF space. A lot of its parameters are optional and work with default values but some of them are important to understand and explained below. This command push the application with all the latest environment settings and also restart/restage the application and this way application will be associated to all the underlying changes in environment settings, service binding changes etc.

  • Build Pack – platform support many buildpacks and keep updating them as technologies evolve. These packs consists of the runtime requirements needed to compile and run our applications in the containers inside the platform. There are buildpacks available for most of the technologies in the market. Please note that CF as a platform runs over linux and hence most of the cross platform technologies are supported including .Net Standard, Python, Java/Kotlin and many more. If we dont specify the buildpack then platform itself try to do its best to understand the technology of the code and determine what buildpack best suits the requirements.
  • no-route, random-route – if we either do not want to add a route to our application once it is deployed or when we want a random route to be assigned to it, then we can use these parameters/flags. If we do not specify any of them, then platform will automatically create and map a route with applicationName.CFDomainname
  • -f flag for specifying manifest file – CF as a standard and best practice expect a YML based manifest file that should specify all the required settings for the application. This include the application Name, routes, number of instances and memory requirements , any service broker services we want to bind to our application during deployment etc. All these settings can also be specified in the command line but that becomes messy and less maintainable for obvious reasons.
View the available buildpacks in CF

cf buildpacks

We should be able to see buildpacks available for .Net, Java, Ruby, Python, static websites, nodejs, go, php etc. This covers most of the industry standard technology requirements.

Restaging the applications

cf restage

cf restage

Important to know is that when we do cf push, it will push/deploy as well as restage the application. But this command is only to restage the application and is useful if we have added or modified some set of environment settings in the application but have not made any changes to the application itself and hence it is not being redeployed.

Check the details of a specific application

cf app ApplicationName

cf app Appname

We should see if application run status, its associated routes and buildpacks along with infrastructure details like number of instances and memory allocated in the output.

A note on Service Broker Services and User provider Services

Service Broker Services – These are the services made available in the CF marketplace. Services made available by the platform are made available in the marketplace and hence they are all called service broker services. We can also create our own marketplace services and for this we need to follow a standard defined by the platform and implement our own service broker for it. One of the example could be when we want to provide Azure SQL Database service in the marketplace. Once it is made available, team can create instances for themselves by bind this service in their workspace and everyone gets their own database instance in that case. Implementing it is a complex process and out of scope of this article. When service is bound to an application and it need some specific configuration settings like credentials etc, these will be configured under VCAP_SERVICES section in environment settings.

Service Instances – when we bind a broker service to our application, it creates an instance of the broker service and that is called service instance.

User provider Services – When we want to connect some external services to our CF applications, we can implement it as a user provider service. These services will not be available in the marketplace and will only be available in our space. Some scenarios where we can use these are

a. When we have an external database server and we want to connect to it using some credentials. In that case we can create a user provided service and add credentials to it and later bind this service to our application.

example – cf create-user-provided-service DBConnectionService -p ‘{“username”:”admin”, “password”:”hello123$”}’

b. Another example is when we want to send logs from CF to a third party logger like splunk.

example: cf cups LoggerDrainer -l syslog://example.log-aggregator.com. (will need a splunk account and setup splunk instance and then use the details to create the service and bind to our application.

c. One more use case is where we want to route all the requests in the application to a route service for some kind of preprocessing. In this case we need to pass route service URL which should already be in place to handle this command.

example: cf cups RouterServiceToProcessRequests -r https://my-route-service.xyz.com

All the use cases supported can be seen below for this command.

cf cups

Creating a service in our space from a broker service available in marketplace

cf create-service NameInMarketPlace default OurServiceNameInSpace

cf create-service

Important to note above is that service instance generally may expect some credentials or some configuration settings to instantiate correctly and we can specify that either inline OR in a json file. This command will create a service instance in our space but do not connect it to anything.

View all the services in our space

cf services

cf services
Connecting a service instance to our application in cf space.

cf bind-service ApplicationName ServiceInstanceName

cf bind-service

Once service is bound to an application, we should see its configuration details in VCAP_SERVICES section in environment settings of the application (cf env ApplicationName)

Adding an internal route to CF application

cf map-route ApplicationName apps.internal –hostname ApplicationHostName

Here we are adding an internal route to our application and the final route will be ApplicationHostName.apps.internal. This is useful for internal communication where one CF application is going to call another within the CF context. In this case GoRouter is not required to be involved unless there are specific route control and check requirements. This will make connectivity much faster as well.

Check the domains available in the platform

cf domains

we should see both internal and the regular domains. Internal domain will only be shown if administrator has added and allowed the internal domain communication.

Working with Batch Jobs and background processing in Cloud Foundry

Publish an application as a command line process (.exe/.jar etc)

cf push ApplicationName –task

This will publish and deploy an application as a task and that means that it wont have any route and will be in offline state since this is not a web application or web related app.

Run a task based application onetime

example: cf run-task ApplicationName –command “exec dotnet ./mainApp.dll –server.urls http://0.0.0.0:8080 internet” -name OneTimeRunTask

This will create a task with a name OneTimeRunTask and run our command line application

Adding a Job scheduler to command line application or a task based application

This is a multiple step process and explained as below

  • First we need to add a cf scheduler service from the market place ie cf create-service scheduler default MyJobScheduler
  • Bind this service instance to our application ie cf bind-service ApplicationName MyJobScheduler
  • Install a plug in provided by Cloud Foundry . we can check in ckoud foundry docs to see its downloadable and then use it to install it in CF
  • We can download it from Download Scheduler — VMware Tanzu Network (pivotal.io) and then use this command – cf install-plugin C:\..PlugInLocation
  • Create a job from our application to run a command in it example for dotnet execf create-job ApplicationName MyCustomJobName “exec dotnet ./mainApp.dll –server.urls http://0.0.0.0:8080 internet”
  • We should first see if this job runs or not and whether it trigger our task based application to run or not ie cf run-job MyCustomJobName
  • Schedule this job now ie cf schedule-job MyCustomJobName “* * * * *” – we are passing it a cron expression to run it every minute as an example here.
  • We should be able to see our jobs using cf jobs command
  • We can also see our job schedules deployed in our space using cf job-schedules
  • If we want to see our job history , we can use cf job-history

Done for now. Hope this will help our dev community with CLI quick reference and also help you in learning and understanding it more. Thanks for your time.

Do comment if you want to connect or need more information.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.