Deploy applications in Cloud Foundry using manifest

Updated: Aug 1, 2021

In my previous post “How to deploy an application in Cloud Foundry - the naive way” I have written how we can deploy an application in cloud foundry. This is mainly for beginners who are learning Cloud Foundry and want to try out. The clever and matured approach is using a manifest file.

 

Contents

  1. What is manifest.yml ?

  2. Why use manifest to deploy applications in Cloud Foundry ?

  3. What does a manifest look like?

  4. How to deploy applications in Cloud Foundry using manifest ?

 

What is manifest.yml ?

A manifest(e.g. manifest.yml) is a declarative and human readable way to define the recipe for an application's deployment information. It's a descriptive way to specify the parameters and configurations of an application that is required to deploy the application. It's written in YAML format and thus the extension is .yml. We can also write the recipe for multiple applications in the same manifest file. All the options that can be used in cf push command or other commands like cf bind-service, cf set env etc. can be written in this file in a descriptive form. The manifest can be reused for deployment. The default name of the manifest file is manifest.yml but we can give any name to it as long as the file extension is the same.



Why use manifest to deploy applications in Cloud Foundry ?

In cloud native application building we also need to think from the operational perspective. There will be a bunch of applications that will run together and need to communicate with one another. Together these applications build the backend of a cloud product. There will be new releases and the same application(s) needs to be redeployed using the new version. Each application has its own routes dependent reusable services e.g. database, the number of instances, the memory and disk requirements etc. It's better that we write down that information in a way that can be readily used to deploy the applications. This is done using a manifest file.


If a change is needed, for example for an application we need to increase the memory we can do it via command line using cf push but if we change the manifest file for that application then the same updated configuration is saved for future, we just can use the manifest when we deploy the next time.


What does a manifest look like?

Let's start with an example. Here is an example of a manifest that can have recipes for multiple applications.

---
applications:
- name: <appname: ex: myapp>
instances: <#of_instance>
memory: 2G
disk_quota: 256M 
host: <sometimes same as app name: ex: myapp>
path: <path_of_war_or_jar_from_current_directory, ex: cf/target/myapp.war>
env:
  LOGGING_LEVEL: debug
routes:
 -<route_1>
 -<route_2>
buildpacks:
 -java_buildpack
services:
- service 1
- service 2

--- is a comment. The keyword applications says below this line the deployment time configuration of the applications are written. In the next line the name keyword states that it's an application name and the name of the application has to be specified there (e.g myapp) . All other descriptions below belong to this application. The next five lines describe how many instances of the application will be deployed, how much maximum memory is allocated, how much disk space is needed, what will be the host name of the application and what is the path of the jar/war that will be deployed. The env sub element specifies all the variables mentioned below this will be injected as environment variables.


Under routes all the routes of an application need to be specified. Note that there can be multiple routes for an application. Also if we don't specify a route then the domain is derived from the settings done by the admin. The name is added in the beginning of the domain to form a unique route.


We can also define a build pack that we want to use to deploy the application under buildpacks. Buildpacks are the executable that are used to deploy the application file. There are buildpacks for different types of applications based on which programming language or framework they are written. For example, there are separate buildpacks for java, spring, nodejs, python and many more. Cloud Foundry is intelligent enough to determine from the files specified under path to determine that using which language the application is written and it will use the appropriate buildpack to deploy the applications.


The next part services specified the name of the services this application has to be bound to. The platform will take care of binding the services provided that they are available to be bound. If a service is already bound to an application and the application is redeployed using manifest the binding is not done from scratch, only the pointers are re-assigned to the new instance of the application.


When we specify multiple application definitions, the structure will look like below.

applications:
- name: myapp1
..
..
- name: myapp2
..
..

There are a lot of other things that can be specified in manifest. A concrete example is given here:

applications:
-name: my-app-1
 memory: 1G
 path: ./
 env:
  LOGGING_LEVEL: debug
routes:
-route: my-app-1.mysuffix.mydomain1.mydomain2.com 
services:
-serviceA
-serviceB

The above manifest tells the Cloud Foundry’s Cloud Controller which is responsible for deploying the application that this manifest has one application definition in it and the name of the application is my-app-1 . It requires 1 GB of memory to run. The Path of the executable jar or war file in the local machine is the current directory. Under the env parameter we can provide the environment variable required at application startup. It also says the application has to be bound to two reusable service instances named serviceA and serviceB. If we don't specify any elements the default is assumed. As we have not specified the instances by default one instance will be deployed. Note we can assign more than one route under routes for an application.


How to deploy applications in Cloud Foundry using manifest ?

If the manifest file has the default name manifest.yml is in the current directory only the below command is sufficient to deploy an application and other tasks like service binding, environment variable initialization, route creation etc will be taken care of by the cloud controller. if there are other manifests with different extension(ex: manifest-app1.yml) those will not be considered.

$ cf push

To specify a specific manifest file to be used for deployment the below command can be used. Using this command we can use any name for the manifest. Example manifest-myapp.ym, myapp.yml etc.

$ cf push -f <file path>

That was quite a detail on manifest file and deployment for more details on manifest and its parameters you can look into the documentation.





114 views0 comments

Recent Posts

See All