This blog is part of a series of tutorials explaining the usage of SAP Cloud Platform Backend service in detail.

Quicklinks: manifest.yml Deployment Sample 2

In today’s tutorial, we take the next step: We take the app which we created in the previous tutorial and deploy it to Cloud Foundry. More precisely: SAP Cloud Platform, Cloud Foundry Environment This tutorial doesn’t contain any special and even no interesting content – it is meant for those of you who have never deployed a node.js application to SAP Cloud Platform, Cloud Foundry Environment

Goal

Write a simple application with node.js It should have these 2 features: – It should run in the cloud – It should call an API created in Backend service

Prerequisites

You have successfully run the application in the previous tutorial You have some memory quota in your subaccount for deploying one little application How to check? Go to your sub account, click on Spaces and check your space info: There should be enough quota for one more app and one more route

Preparation

Our goal is to write a simple node.js application which runs in Cloud Foundry I think the below description is the easiest possible way. We just reuse the simple app.js file from previous tutorial. Absolutely no change to the code required As such, in this blog we learn only how to cloudify it

Make sure that you have the artifacts of the previous tutorial at hand: We need the app.js file and the node_modules folder

Note: You can also use the enhanced sample code

Cloudify the app

Create a new folder for this tutorial:

C:\tmp_bsnode_cf

Step into this folder. Create another folder with name:

\appfolder

Step into this folder We’re now inside the folder

C:\tmp_bsnode_cf\appfolder

Copy the app.js file from previous blog and paste it into this folder Copy the node_modules folder from previous blog and paste into this folder

Note: Of course, you can also install the node packages with npm as described in previous blog

The archive file

Still inside the same folder, compress all the content into an archive called appfolder.zip (select the file and the folder, open context menu and choose "Add to appfolder.zip") Now the content of the folder looks like this:

Note: We create the zip file because it is needed for deployment from cockpit. When using the command line client for deployment, zipping is not required However, for the beginning it is easier to use the cloud cockpit

The manifest file

Now we step out of this folder and move one level higher. We’re now in the folder

C:\tmp_bsnode_cf

Create a file with name

manifest.yml

Note: This is not a name of your choice. Make sure it is written correctly

Now the folder looks like this:

Open the manifest.yml file with notepad and paste the following content:

Note: The Open the yml format is very sensitive, so make sure that you don’t miss any blank or CR That’s why it is a good idea to use Notepad, because other editors might add invisible characters which would break the file and cause errors during deployment

Note: The Open the manifest.yml file is like a deployment descriptor, containing metadata about the deployed app and the environment

Explanation of attributes:

applications: We’re deploying one app, but there could be more apps deployed with one descriptor

name: A name of your choice for your app. This name will appear in the cloud cockpit

host: A name of your choice for your host. This attribute is optional, the default host name is the application name The host name will end up as prefix in the final URL of our application. A final URL looks like this: https://myhost.cfapps.eu10.hana.ondemand.com/ As you can see, myhost has to be unique, there’s no personal specific account information in the URL Note: You really SHOULD change this name, as it must be unique. Yes, millions of enthusiastic fans of my blogs will deploy applications… so they will clash if everybody uses the same host

path: The relative path to the folder which contains the app. Relative path means relative to the manifest.yml location

command: In case of a node application, the Cloud Foundry buildpack (node.js) needs to know how the application should be started. For that purpose, we add the start-command attribute Note: There are other ways of specifying the start command. Furthermore, there are also defaults. But let’s use this way: it makes things clear, no hidden magic

memory: With this attribute we can tell Cloud Foundry that we don’t need more memory than 64MB. Otherwise, the platform would assume we need the maximum, which is 1 GB It is an optional attribute

buildpack: If not specified, the platform tries to guess the correct buildpack. An indicator would be the package.json file, (which we’re still ignoring) Let’s add this attribute as well, it helps to make magic things visible

Note: See here for full reference of attributes

After creating a manifest and zipping the content, we’re ready to deploy the node.js application to the cloud.

Deploy

In this description we’re using the SAP Cloud Platform cockpit for deployment It is less cool…. But easier, because it doesn’t require installation of the command line tool (see here)

The "Deploy" button can be found in the "applications" screen: Go to your Subaccount ( that one, where the Backend service is subscribed) Go to your Space There it is:

Press the button. In the "Deploy Application" dialog, enter the path to the zip file and to the manifest.yml file

Press "Deploy" The deployment process is triggered. Don’t wait until the "State" gets green.

Click on the app name to go into the application details screen

Don’t wonder that the application state is "Starting" and also "crashed". And don’t click on the "Application Route", as it doesn’t work for us

Result