Hi, Denys van Kempen, SAP Welcome back,
you are watching video number three of a short tutorial series where are going to take a
look at how we can develop secure applications in a multi-cloud environment.
In the previous two videos, we introduced the blue print here and started with local
development of our business app.
Created a Docker container and took a look at what’s inside
Very basic hello world sample as we want to focus on all the infrastructure, on all the
plumbing, how it all fits together.
The activities we performed in our local environment and to build a Docker container were
get a runtime, install dependencies,
and run the start command and that is exactly what the Could Foundry
platform as a service can do for us. and all it takes is single command; cf push
Now, for those not familiar with Cloud Foundry, we have posted a blog about how this works
and where it is coming from.
You’ll find a link to the blog in the description below.
This also applies to the SAP Cloud Platform.
There is an onboarding video tutorial series where we explain the concept of global accounts,
trial account, how to setup Cloud Foundry So we are going to skip that part here.
It is very simple but there are couple of things you need to know,.
One of which is that to work with Cloud Foundry from the command line we need the Cloud Foundry
CLI, command-line interface, this you would need to install
Then we need to point the CLI to the Cloud Foundry environment we want to work with.
For this we use the cf api command and then cf logon to connect,
cf target returns the target environment with the Cloud Foundry org and space.
cf apps shows us the apps currently running: and there is nothing there
so let’s push our app into the cloud cf push
requires one attribute, one parameter, the name of the app, say myapp
that is it.
However we need a route to get from the internet to the app
which is hosted inside a container running on a virtual machine somewhere on the platform.
This route needs to be unique.
Now, we can create routes with a virtual host and domain name and then map that to our app
that’s a bit more advanced stuff for now let’s have Cloud Foundry generate
some random route for us, which for development works just fine.
So here I am going to append - - random-route to the command.
That’s it.
Takes 30 seconds, maybe fast forward,
and here we have our app up and running so when we curl the URL using HTTPS
we get the same HTTP 200 with message
we saw in the previous video But what just happened?
Let’s scroll up a bit and read the output Creating app with these attributes
name path, we did not specify any path but by default
the current directory is used and the route, here a random one starting
with the app name, myapp then the random string .cfapps.eu10.hana.ondemand.com and that is
the domain.
We can of course configure custom domains, but that is a more advanced topic and not
relevant for what we want to cover in this tutorial.
Before anything is done, the app is created and the mapped to the route.
That’s just metadata then our business logic is uploaded,
Then the app is staged, and this starts by Cloud Foundry downloading
all the available buildpacks, Buildpacks are used to build the app, as we
did not specify which one to use, Cloud Foundry needs to get them all.
We will see in a minute how we can fix this Then a cell creates a container,
Cloud Foundry cells correspond to a virtual machine,
Without asking, we have received a virtual machine, which has created a container for
us to build the app.
The container is download our package.
It includes a package.json file so it figured out it should use the nodejs buildpack
Installs node (the engine) and npm (the package manager); just as we did locally.
Also installs Yarn, a more recent package manager, the same as with the Docker container.
The runtime environment is created.
We get a PRO TIP to vendor the application dependencies.
This topic we cover in the blog, basically means that with the business logic we ship
the dependencies together as package because here the buildpack has to download them.
For the Alibaba Cloud Foundry environment in China , for example, this is not supported.
Exit with 0; all is well.
An image of the container is made, a droplet, and this droplet is used to run the application.
This is how we can scale our app.
If you need 2 or 200 instances, Cloud Foundry is not going to build your app again, it just
picks the droplet from the BLOB store and runs it.
Very fast.
Ok the container used to build the app is stopped and discarded, we no longer need it.
Then, Cloud Foundry powers up another container with our droplet, that’s what’s happening
while we are waiting for app to start and then we are done.
Should we want to scale our app, we can use the command
cf scale myapp -i for instance cf apps
now we have three or cf app myapp for the details
now as you can see for each instance 1 gigabyte is allocated while we only need 85 megs.
Same for disk.
a bit wasteful, maybe also a bit expensive.
we can scale our apps down with the scale command but we can also specify the amount
of memory our app needs when we deploy our app.
we could append this as attribute on the command line but in the end the command would get
pretty long, easy to make mistakes and difficult to remember exactly what command we used to
deploy our app.
Not what we want, particularly for DevOps, for repeatable automated
deployments, the 12 factor app,
maybe you have heard about it, microservices is one factor,
configuration as code another, so what we need is a configuration file
For this Cloud Foundry uses an application manifest file.
You can give it any name you want but manifest.yml is the name the cf push command is looking
for in the current directory; otherwise you would have to use a -f and provide
the path.
It is a YAML file, not JSON YAML ain’t markup language, as the acronym
goes, which is true.
Unlike XML or HTML it is very picky about formatting, spaces have meaning
However, we can use a hash for comments, something JSON does not like
Here we have included the buildpack, memory, and disk quote attribute
let’s run the command manifest.yml is in the current directory so
a cf push suffices In green we get the new attributes.
Instead of all buildpacks only the nodejs one is downloaded.
and now we are running with 128megs So, that’s where we use the manifest yaml
for What about Python?
Well, that’s the good news.
This works exactly the same.
Here we the manifest file to deploy our business logic in Python, exactly the same, except
for the buildpack, and with cf push we can now deploy a Python
app same steps
get the buildpack get the engine
get the package manager get the dependencies
build the droplet save it and run a copy
OK Now we got some warnings while making the
build Here we have another version where we are
do things slightly different the manifest is the same - that is the Cloud
Foundry part On the Python side, we we have provided with
runtime.txt file with the exact version of the engine
the requirements file also includes all requirements with exact version number
you can easily generate this file with the pip freeze command
we covered this in the previous video and it is the blog as well
we have vendored in the dependencies, so we upload the packages with our source code,
as recommended, and then we use a Procfile to provide the
start command.
So, when we run cf push, we are using a different Python runtime
the dependencies are uploaded with the source code
using a different start command Same result but this is just to show that
there are multiple ways how we can deploy and run apps on Cloud Foundry
Let’s do another one Here we have a Java app
Now the source code is getting a bit more complex,
we are using the spring framework here probably still readable
but then we would first need to build the app using Maven to get a JAR file
In our Cloud Foundry manifest we then point to the JAR
and with cf push deploy the app This time the Java buildpack is used
The start command looks a bit more intimidating as well.
But the end result is the same: we have an app running in the cloud.
So far, we have used buildpacks to build our app into a droplet and then run that droplet
inside a container.
The Cloud Foundry technology has been around for some time, predates Docker and Kubernetes
Today, these technologies have been merged.
So, what we could also do is that instead of creating an image container on the platform
is to upload a container.
In the manifest yaml we indicate where the docker container can be found
Could be Docker Hub, could be Azure, Google container registry,
And then when we push the app, the staging is skipped and the docker container is used
instead.
This works the same way.
Cloud Foundry supports both container technologies.
And in fact when we are running an SAP HANA Cloud database on the Cloud Platform, this
is running a Docker container.
OK, in the next video we return to our blue print and start to bind our business app to
service instances.
I am Denys van Kempen, SAP, Thanks for watching.