Cloud Foundry CLI plugin

The Cloud Foundry CLI Integration is Deploy integration for CloudFoundry server which makes uses of CF CLI installed in a remote Host.

As of Deploy 10.0, there are 4 deployments tasks and 8 controls tasks for now. We will add more tasks and features to this integration, in the future releases

Instructions Creating the Infrastructure:

Create a overthere host in Infrastructure where CF CLI is installed.

Create a new cf client of type cf.Client under the overthere host created in step 1.

Specify the properties related to the CF CLI client like username, password, apiEndpoint, CLI version, binary home, tls etc.

Now under the cf.Client container created in steps 2 and 3, create a new Org(Organisation) of type of cf.Org.

Specify the properties of the Org like orgName and CI name. You can also created multiple Org container CI if you want to map other orgs in different Deploy’s environments.

Now specify the Org that you want use in the orgToUse property in cf.Client created in steps 2 and 3.

This cf.Org will be the container for deploying Space and Space will be the container for deploying other deployables like Pushed App, routes and services.

Create the environment of the cf.Org created in steps 5 and 6.

Creating the environment:

Create the Environments using one Org. For each new Org you have create a new environment.

cf.Org is the container for cf.SpaceSpec deployable which deploys cf.Space container and cf.Space will be the container for other deploables.

Creating Application and Deploying: There are 4 deploy task that you can perform:

cf.SpaceSpec - Deploys a Space to a Org(Organisation) environment(that has cf.Org container).

cf.PushSpec - Deploys or push a App to a Space environment (env that has cf.Space container deployed by cf.SpaceSpec deployable).

cf.RouteSpec - Deploys a Route to a Space environment.

cf.ServiceSpec - Deploy a Service to a Space environment.

If you have multiple spaces in a single Org, it is advised to create separate Environment which has a container reference to single Space.

Deploying a Space: Create a deployment package and specify the deployable as SpaceSpec.

Specify the properties that you want for the Space.

Select the desired environment containing Org and deploy to it.

After creating a Space, you can verify that the Space and Org are binded to the same environment. This is important as all other deployables are deployed to cf.Space container.

Deploying or Push a App: Create a deployment package and specify the deployable as PushSpec.

Specify the properties that you want for Push.

The properties of Pushing a App in Deploy is similar as mentioned in https://cli.cloudfoundry.org/en-US/v6/push.html and https://cli.cloudfoundry.org/en-US/v7/push.html. Only take care that some properties in PushSpec are specific to v7 of CF CLI. This all info is mentioned in the description of a properties.

The push artifacts such as Zip file of project(-p option) , manifest file(-f option) and variables files(–var-file option) is also supported for PushSpec as children artifacts as types- cf.AppZip, cf.ManifestFile and cf.VarFile.

AppZip is a zip containing the the apps with the corresponding manifest file in root of zip file. The file can be a war, jar, zip or any artifact file. The war file is attached at the end of this session. To deploy this war file to CF create a PushSpec with App name, buildback- https://github.com/cloudfoundry/java-buildpack.git and memory- 1G. Then deploy it to a Space environment.

ManifestFile is the manifest to deploy the artifact in CF(Instead of manifest the Push options in PushSpec can also be given as the option in Manifest and Push Options are same). Please do not specify the app name in manifest.yaml file as it is being supplied from the PushSpec’s property appName. Make sure to not supply different options(specifying the same options in manifest.yaml and Push Options of PushSpec).

VarFile is a file which container the entries for variable substitution for ManifestFile.

The maximum of AppZip and ManifestFile artifacts are limited to 1 where as you can supply as multiple VarFile artifacts.

After the creation of cf.App deployable, you can deploy its package to environments containing Space infrastructure container.

You can also update this deployment and undeploy.

You cannot change the appName of Pushed App as it uniquely identifies the Name of a App during update process.

Java-HelloWorld-Sample-2.0.war 04 Jan 2021, 02:23 pm

Deploying a Route: Create a deployment package with deployable cf.RouteSpec.

Specify the properties of RouteSpec.

Specify a Valid Route Domain. There are special properties which corresponds to routeType http or tcp.

After creation of deployable, you can deploy its package to Space Environment.

Deploy, Update and Undeployment of a Route is supported.

Deploying a Service: Create a deployment package with deployable cf.ServiceSpec.

Specify the properties of ServiceSpec.

Specify service to to used, plan and Service Instance. You can also options like specify broker, configuration(json string) and Service Tags.

There are upgrade specific options under category Update Options also which need to be given only in case of updating a service.

You can not change serviceInstance or service while updating the service as these are the properties which indentifies a service uniquely.

After creation of deployable, you can deploy its package to Space Environment.

Deploy, Update and Undeployment of a Service is supported.

Controls tasks: There are number of control tasks that you can perform using cloudfoundry-cli-integration.

On cf.App deployed: You can perform 4 control task on cf.App deployed:

Restart the App: Restarts the running App in Cloud Foundry Space. There are params you can supply if the deployment is like strategy and no wait. Strategy should be specified if deployment is rolling update.

Stop the App: Stops the running App in Cloud Foundry Space.

Start the App: Starts the stopped App in Cloud Foundry Space.

Scale the App: Scales the current running App on ground of instances, disk limit and memory limit.

On cf.Route deployed: You can perform 1 control task on cf.Route deployed.

Map Route: Maps the current route(deployed) to a instance of an App. Supply the App name in control task parameter and this control task will map the deployed route to an App.

On cf.Org deployed: You can perform 1 control task on cf.Org deployed:

List all Organizations: This control task will list all the organisations in the current CF servers. Supply the space name as a parameter to this control task to support login.

On cf.Service deployed: You can perform 4 control tasks on cf.Service deployed:

bindService: Bind this service instance(deployed) to an app. Supply parameters- App Name, bindingName and conf(configuration in json string) to this control task.

unbindService: Unbind this service instance(deployed) from an app. Supply parameters- App Name to this control task.

bindRouteService: Bind this service instance(deployed) to an HTTP route. Supply parameters- domain, hostname, path and conf(configuration in json string) to this control task.

unbindRouteService: unbind this service instance(deployed) to an HTTP route. Supply parameters- domain, hostname and path to this control task.

NOTE: Please look into the CLI of Cloud Foundry also. Most of these tasks make use of CF CLI only. Link: https://docs.cloudfoundry.org/cf-cli/getting-started.html