[go: up one dir, main page]
Scribd
Upload
16 views4 pages

Pivotal Cloud Foundry

Uploaded by

saiakkina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
16 views4 pages

Pivotal Cloud Foundry

Uploaded by

saiakkina
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 4

Pivotal Cloud Foundry

Deploying Applications to Cloud Foundry

1. Routing - Load blnacer that distributes the traffic. Entry point to the cloud
environment.
2. Authentication - UAA Service (User Accounts and Authentication)
3. App lifecycle - Cloud controller reposnible for pushing, staging and running
your applications stack (os image) + buildpack (code compiler) + source code ->
droplet (deployment artifact). It also maintains the records of orgs, spaces and
usr roles
4. App Execution - Diego is the container componenet of Cloud Foundry, which is
responsible for executing the application. They run as tasks on Diego Cell VMs
5. Services - Responsible for binding external services (Databases and message
queues) to the application.
6. Messages - Support intra VM communication through HTTP and HTTPS protocols. It
has Consul Server (for long lived data) and Bulletin Board System (for frequently
updated data)
7. Metrics and Logging - Metrics Collector collects statistics and metrics and
Loggregator streams application logs thta can be monitored through Cloud Foundry
CLI

Prepare an Application
PCF gives us cfdev (a lightweight development environment)
> cf
> cf -v
> cf login

org > space > App << Services

> cf target - List the api endpoints (api endpoint, org, space)
> cf orgs - List orgs that you are part of
> cf spaces - Lists the spaces where the apps are deployed
> cf apps - Lists the deployed apps that are part of a space

Deploying a Web Application on Cloud Foundry

https://start.spring.io/

Add a new function and a @GetMapping annotation

Also add a @RestController annotation

> mvn clean install - builds the package


> cf push web_app -p <jar_file_path> - generates the droplet and pushed to cloud
foundry

Cloud Foundry recommends using manifest files(YAML Format)


> cf create-app-manifest web_app

Change the name of the generated file to just manifest.yaml and add the path of the
jar file as path:

> cf push << this command will automatically pull up the manifest file

> cf apps
> cf app web_app

the first line of code in manifest file is applications:


applications:
- name: web_app
disk_quota: 1G
instances: 1
memory: 1G
routes:
- route: web_app.cfapps.io
stack: cflinuxfs3

In case we have multiple processes, the first line will be shown as processes:
instead of applications:

> cf stacks << List all kinds of stacks

CF examines the config files like pom.xml for java project and package.json for
node project and determines the right Buildpack for the application

> cf buildpacks << List all kinds of buildpacks

Error 222 in case the right buildpack is not found

Cloud Foundry provides a special file .cfignore to record the names of all the
files that you do not want to be packaged.

buildpacks - 4 stages

Detection
- At staging phase of deployment
- Checks each buildpacks for compatibility

Supply
- Downloads and installs the dependencies under the directory named as /deps

Finalize
- Prepares the app

Release
- Generates an YAML file to include app type and command to start the
application.

cf push - 4 stages

Updating
- Reads and parses the manifest file and updates the runtime arguments like
memory, disk space and port number.

Staging
- Downloads all the buildpacks.
- Detection of the right buildpack is done in this step. Else error 222
- The buildpack downloads the required dependencies, reads the environment
variables and start the compile process
- Finally an application is packaged to a droplet
- Restage - if there is a change in configuration
- Repush - if there is a change in source code

Uploading
- Uploading the droploet to Cloud Foundry
- Use .cfignore to ignore the unnecessary files as the droplet is a containerized
file and with those unwanted files, the droplet could become huge.

Starting
- Starting the instance or instances in the manifest file at the specified route

Application Container Lifecycle - 4 stages

Deployment
Staging and Uploading - 15 mins
Startup - 60 mins

Crashing
- Restart three times
- Wait for 30s and attempts a restart
- Double the wait time and attempts a restart. This continues until 9th attempt
- From 10th attempt, it uses the same wait time as the 9th and keeps attempting
for 200 times and finally marks application as down

Evacuation
- While application or VM is going through an upgrade process

Shutdown
- cf scale, cf push, cf stop
- CF sends a SIGTERM and waits for 10 seconds and send a SIGKILL

Deploying a Worker Application in Cloud Foundry

Add a new function and a @Scheduled(cron = "*/5 * * * * *") annotation

Also add a @EnableScheduling annotation

> mvn clean install - builds the package


> cf push worker_app -p <jar_file_path> --no-route --health-check-type=process -
generates the droplet and pushed to cloud foundry
> cf logs worker_app
> cf env worker_app
> cf set-env worker_app <var_name> <var_value>

Modify the code and display the System.getenv(name:<var_name>)

> mvn clean install


> cf push
> cf logs worker_app

Move the cron to application settings file as cron_schedule_value="*/5 * * * * *"


and refer the cron from here as below

@Scheduled(cron = "${cron_schedule_value}")

Health Check Types

http
- configure a health-check-http-endpoint
- this is expected to return a 200 response within a second

port
- single or multiple ports
- it is the default health check type
- tries to make a tcp connection
- this is expected to establish a connection within a second

process
- for a worker application where there is no explicit route set to it
- Diego will be moitoring it

Health Check Lifecycle

Similar to that of the Crashing section of the Application Container Lifecycle

> cf plugins

use a scheduler service and bind the app to that service to let only one of the app
instances service the scheduler job

We can use jobs to schedule iterative workloads

We can use tasks to run one-off/ one-time tasks

You might also like