Cloud Foundry Manifests and multi-instance deployments

In a previous post we saw the basic usage of "cf push" to bring your Python script to Pivotal Cloud Foundry and running it. The only parameter we used at the time was the application name. If for example we did:

cf push pretty_app1

This meant that our app would be accessible with "http://pretty_app1.cfapps.io". Not to be confused with the name of the actual Python script, ex: "app.py"

When we run this we got an instance with a certain default characteristics, ie  1GB RAM and 1GB of disk. Given that Pivotal bills you based on the memory used by your apps, you might want to be more specific about that, specially in our "hello world" app which requires little resources. You can see the health of your app as follows. In my case we can see it only requires 17MB of RAM, so 1GB is a huge waste.

Luckily the "cf" cli tool has lots of options. You can explore them by simply typing "cf --help" or to see the options for the push command "cf push --help"

So for example if we want to be more specific and push our app with only 64MB of RAM, 256MB of disk and scaled to 2 instances, we would have to do something like this:

cf push piperhw -m 64M -k 256M -i 2

Which yields:

This is great but as you can see our "cf push" command can get very complicated very quickly and we haven't even started specifying services, environment variables, etc. Luckily there is another way: "manifest.yml" files. These are text files written with YAML (Yet Another Markup Language) syntax. Let's see an example that accomplishes the same thing as before:

# With this file present in the directory
# you only type "cf push"
applications:
- name: piperhw
  memory: 64M
  disk_quota: 256M
  instances: 2

The difference is that from now on, in order to push our app we have to simply type:

The "cf" cli utility is smart enough that to realize that there is a "manifest.yml" file present in the directory and it takes all the attributes from it, including the app name.

Another strength of manifest files is that they allow you to push an app consisting of multiple different microservices. For the following example you can download the contents of the following Github repository.
https://github.com/cermegno/ManifestExample

---
# this manifest deploys two applications
# apps are in vote and res subdirectories
# the manifest file lives in the parent directory
# cf push should be run from the parent directory
applications:
- name: vote2wpp
  memory: 64M
  disk_quota: 256M
  instances: 1
  path: ./vote/
  services:
  - newRedis
- name: res2wpp
  memory: 64M
  disk_quota: 256M
  instances: 1
  path: ./res/
  services:
  - newRedis

This manifest file is requesting "cf" to push two different applications "vote2wpp" (which creates a survey) and "res2wpp" (which shows the results of the survey). The "path" attribute specify the directory the contains the app to run on each microservice as well as its individual "requirements.txt". It also specifies other details such as RAM, disk, instances, services, etc.

NOTE: In order for this exercise to work you will have to add a Redis service from the Marketplace and call it "newRedis" as seen in the Redis post of this blog

In our example the "manifest.yml" file does include two microservices, but you don't need to push them both all the time. So, let's say you have made some improvements to your "res2wpp" microservice and we want to push that one only, then we would do:

cf push res2wpp

Manifest files can include a few other attributes like the routes, domains or environment variables. For a more detailed reference about what's available you can visit Pivotal's official documentation

https://docs.pivotal.io/pivotalcf/1-7/devguide/deploy-apps/manifest.html