Cloud Foundry Application Basics¶
Cloud Foundry is a platform as a service (PaaS) providing a development and deployment environment within MindSphere. This platform enables you to create everything from a simple cloud-based IoT dashboards to sophisticated enterprise applications.
This section covers the basics for developing a Cloud Foundry application for MindSphere. The following points summarize the most import aspects:
- All Cloud Foundry applications that form a MindSphere application must be deployed within the same Cloud Foundry Space.
- You are required to use a single Cloud Foundry Manifest file for your MindSphere application.
- Use the following scheme for Cloud Foundry host names:
<appname>-<tenantname>or random routes.
- Cloud Foundry routes are not internet exposed. It is necessary to register your application in the Developer Cockpit before you can access it via the internet.
- You must run at least 2 or more instances to avoid downtimes of your Cloud Foundry application.
Cloud Foundry supports MindSphere applications that consist of one or more micro services. Each micro service is represented by a Cloud Foundry application that all must be run within a single Cloud Foundry Space.
Currently, MindSphere only supports Cloud Foundry applications that have a single Cloud Foundry Manifest configuration. You are required to use the following scheme for Cloud Foundry hosts
<appname>-<tenantname> in Cloud Foundry Manifest files.
To deploy an application to Cloud Foundry you need to run a
cf push command from the Cloud Foundry Command Line Interface (cf CLI). Between the time that you run
cf push and the time that the application is successfully deployed, Cloud Foundry performs the following tasks:
- Uploading and storing application files (see Prepare to Deploy Hints)
- Examining and storing app metadata (see Cloud Foundry Manifest)
- Creating a
droplet(the Cloud Foundry unit of execution; comparable to a container) for the application
- Selecting an appropriate Diego cell to run the droplet (a Diego cell is a virtual machine for executing droplets)
- Starting the application
Applications that use services, such as a database, messaging, or email server, are not fully functional until you provision the service and, if required, bind the service to the applications.
Buildpacks provide framework and runtime support for applications. Buildpacks try to examine your applications to determine what dependencies to download and how to configure the applications to communicate with bound services (Backing Services).
When you push an application, Cloud Foundry automatically detects an appropriate buildpack for it. This buildpack is then used to compile or prepare your application for deployment and launch. However, you can also specify the buildpack explicitly in the Cloud Foundry Manifest.
Cloud Foundry by MindSphere currently supports the following buildpacks:
Java: Grails, Play, Spring, or any other JVM-based language or framework
.NET Core: .NET Core applications
A Backing Service is any service an app may consume over the network as part of its normal operation. Examples include data stores (such as PostgreSQL), messaging/queuing systems (e.g. RabbitMQ), caching systems (such as Redis) and logging services. A Backing Service can be also described as a factory which produces Service Instances based on Service Plans.
For more information about the supported Backing Services see section Backing Services.
Run multiple instances to increase availability of your application. You must run at least 2 or more instances of your application in Cloud Foundry to avoid any downtimes during updates. Cloud Foundry automatically distributes those instances across the three availability zones and on multiple virtual machines.
In cases one of the application instances crashes Cloud Foundry automatically routes the traffic to another one and tries to restart your crashed application. Besides, if we update Cloud Foundry it might happen that one of your application instances is shortly unavailable as we update the underlying virtual machine.
Cloud Foundry applications are automatically monitored by continually checking the status via a health endpoint. If the application crashes, Cloud Foundry automatically tries to restart it.
You can configure a health check for your application using the Cloud Foundry Command Line Interface (cf CLI) or by specifying the
health-check-type fields in the Cloud Foundry Manifest.
In Cloud Foundry the most important metric for computing resources is the memory. Cloud Foundry utilizes multiple virtual machines that provide an environment for executing applications. To manage this huge amount of memory Cloud Foundry uses logical separations:
- Orgs that represent a complete organization like a company.
- Spaces which are an environment for a number of micro services that form an application.
- Applications for running a process with a specified amount of memory.
In the Cloud Foundry Manifest or using a CLI command it is possible to configure the maximum amount of memory an application can consume. As every application is run within a container, it is not possible to assign a specific CPU to an application. Instead, the CPU power will be limited according to the memory requested for your application. For example, if the underlying virtual machine offers 32GB of memory and your application is limited to 8GB, the application gets at least 25% of the currently available CPU power.
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.