DevOps on Cloud Foundry Platform

Goals

To deploy and configure sample application, leverage the platform for monitoring & management of the microservice, and do a blue green deployment with zero downtime.

Prerequisites

Git from github.com
Cloud Foundry CLI from CF CLI Releases
Pivotal Web Services Account.

Pre-work

Read Presentation The developer experience
Download link:https://github.com/shinji62/todo-apps-php-cf [Todo Application]

Steps

In this workshop we are going to follow these steps to deploy apps on Cloud foundry and manage the lifecycle of the application.

PART 1: Introduction to CF, Push an App.

Use cf help and/or cf <command> --help for details on each of the commands below.

Review the docs: http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/deploy-app.html
Login to the Pivotal Cloud Foundry.

// Assuming you are using PWS, your system domain is run.pivotal.io and Use the interactive prompts to login in.
$ cf login -a https://api.run.pivotal.io

+

$nano env.sh

 export CF_SYSTEM_DOMAIN=     //CF_SYSTEM_DOMAIN will look similar to run.pivotal.io
 export CF_APPS_DOMAIN=       //CF_APPS_DOMAIN will look similar to cfapps.io
 export CF_USER=              //CF_USER is the user account to sign into Pivotal Cloud Foundry, which is usually your email address.
 export CF_ORG=               //CF_ORG is the name of the Organization within Pivotal Cloud Foundry where you want to deploy your applications.
 export CF_SPACE=             //CF_SPACE is the name of the Space within the above Organization where you want your application deployed.

+

$ source ./env
$ cf login -a https://api.$CF_SYSTEM_DOMAIN -u $CF_USER -o $CF_ORG -s $CF_SPACE

+

Note	add `--skip-ssl-validation` if you are pointing to CF installation which is using self signed certificates.

+ . Verify you are logged in with your own userid (not admin) and targeted to your PCF instance:

+

$ cf target

Push the app

Push the todo-application+

//GO to the directory where the application is
$ cd path/todo-apps-php-cf/
//Rename the manifest file
$ mv manifest.yml manifest.service
$ cf push <first-initial><last-initial>-todo

// This will give an output which is similar to this

requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: ge-todo.cfapps.io
last uploaded: Mon Jun 15 14:53:10 UTC 2015
stack: cflinuxfs2

Open the app url
When you push the apps, it will give the url route to the app.
Walk through the App Console and the Ops Manager

Recap: Part 1

Discussion: Part 1

Note	How do you push an app to the cloud today? How does the cloud platform understand which runtime to use to run the app?

PART 2: Push, Bind, Monitor and Scale an App.

The todo-php-mongo app requires a database service to store and fetch todo info.

Create a Database Service from Marketplace

Review the docs on Services:
- Adding a Service
- Managing Services
Create a mongoLab (mongodb) service instance, name it as todo-mongo-db-<first-initial><last-initial> You can create the service from the cli or launch the App Manager http://console.run.pivotal.io and login. Navigate to the marketplace and see the available services. Here you will create the service using the CLI.
```
$ cf marketplace // check if mongoLab service is available
$ cf create-service mongolab sandbox todo-mongo-db-<first-initial><last-initial>
```
Launch the DB console via the Manage link in the App Manager.
Check the logs to learn more about why the application is failling
```
$ cf logs <first-initial><last-initial>-todo --recent
```

Manually Binding the Service Instance

Review the docs on Binding a Service Instance
Bind the mongodb instance todo-mongo-db-<first-initial><last-initial> to your app todo You can bind from the App Manager or from the cli
```
$ cf bind-service <first-initial><last-initial>-todo todo-mongo-db-<first-initial><last-initial>
```
Restage your todo application to inject the new database.
```
$ cf restage first-initial><last-initial>-todo
```

Notice that the application is now running.

Check the Env variables to see if the service is bound. You can do it from App Manager or from the cli
```
$ cf env <first-initial><last-initial>-todo
```

Binding Services via the Manifest

Next, let’s push the todo app with a manifest to help automate deployment.

Review the documentation: http://docs.pivotal.io/pivotalcf/devguide/deploy-apps/manifest.html
Edit the application manifest manifest.service in your todo
```
$ nano manifest.service
```
Set the name of the app, the amount of memory, the number of instances, and the path to the .jar file. Be sure to name your application '<first-initial><last-initial>-todo' and use this as the host value.
Add the services binding todo-mongo-db-<first-initial><last-initial> to your deployment manifest for todo .

Now, manually unbind the service and re-push your app using the manifest.

$ cf unbind-service <first-initial><last-initial>-todo todo-mongo-db-<first-initial><last-initial>

Test your manifest by re-pushing your app with no parameters:
```
$ cf push -f manifest.service
```
Notice that using a manifest, you have moved the command line parameters (number of instances, memory, etc) into the manifest.
Verify you can access your application via a curl request:

$ curl -i http://<first-initial><last-initial>-todo.cfapps.io

We must be able to access your application at https://<first-initial><last-initial>-todo.cfapps.io for the next steps to work properly.

Note	The default manifest file for an app is `manifest.yml` and it if is present, it is automatically picked without specifying the manifest file option. In this exercise we have used a different naming convention.

Health, logging & events via the CLI

Learning about how your application is performing is critical to help you diagnose and troubleshoot potential issues. Cloud Foundry gives you options for viewing the logs.

To tail the logs of your application perform this command:

$ cf logs <first-initial><last-initial>-todo

Use the following curl command to see the application working:

$ curl -i http://<first-initial><last-initial>-todo.cfapps.io/

For other ways of viewing logs check out the documentation here: Streaming Logs

To view recent events, including application crashes, and error codes, you can see them from the App Manager or from the cli.

$ cf events <first-initial><last-initial>-todo

To view the health of the application you can see from the App Manager or from the cli:

$ cf app <first-initial><last-initial>-todo

You will get detailed output of the health

Showing health and status for app todo in org  / space development as...
OK

requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: todo.cfapps.io
last uploaded: Wed May 27 15:53:32 UTC 2015
stack: cflinuxfs2

     state     since                    cpu    memory           disk           details
#0   running   2015-05-27 12:17:55 PM   0.1%   434.5M of 512M   145.4M of 1G

Environment variables

View the environment variable and explanation of VCAP Env

$ cf env <first-initial><last-initial>-todo

You will get the output similar to this on your terminal

Getting env variables for app ge-todo in org jp-POC / space development as [email protected]...
OK

System-Provided:
{
 "VCAP_SERVICES": {
  "mongolab": [
   {
    "credentials": {
     "uri": "mongodb://CloudFoundry_uXXXXXx:[email protected]:33489/CloudFoundry_XXXXXX"
    },
    "label": "mongolab",
    "name": "todo-mongo-db-ge",
    "plan": "sandbox",
    "tags": [
     "Data Store",
     "document",
     "mongodb"
    ]
   }
  ]
 }
}

{
 "VCAP_APPLICATION": {
  "application_id": "eXXXXXX",
  "application_name": "ge-todo",
  "application_uris": [
   "ge-todo.cfapps.io"
  ],
  "application_version": "32712532-6c-ccf83d685b03",
  "limits": {
   "disk": 1024,
   "fds": 16384,
   "mem": 512
  },
  "name": "ge-todo",
  "space_id": "d1028f61-78be-7bc945",
  "space_name": "development",
  "uris": [
   "ge-todo.cfapps.io"
  ],
  "users": null,
  "version": "32712532-86f2d685b03"
 }
}

No user-defined env variables have been set

No running env variables have been set

No staging env variables have been set

Scaling apps

Applications can be scaled via the command line or the console. When we talk about scale, there are two different types of scale: Vertical and Horizontal. Read this doc on more details on scaling applications.

When you vertically scale your application, you are increasing the amount of memory made available to your application. You would vertically scale your application while profiling your app, do performance tuning and to find the best memory settings before you deploy it in production. Scaling your application horizontally means that you are adding application instances to increase your application throughput and performance under load.

Let’s vertically scale the application to 1 GB of RAM.

$ cf scale <first-initial><last-initial>-todo -m 1G

Now scale your application down to 512 MB.

Next, let’s scale up your application to 2 instances

$ cf scale <first-initial><last-initial>-todo -i 2

To check the status of your applications you can check from the command line to see how many instances your app is running and their current state

$ cf app <first-initial><last-initial>-todo

Once the second instance as started, scale the app back down to one instance.

Verify the app from the Console

To verify that the application is running, use the following curl commands to retrieve data from the service or use a browser to access the URL:

$ curl -i http://<first-initial><last-initial>-todo.cfapps.io

$ curl -i http://<first-initial><last-initial>-todo.cfapps.io

$ curl -i http://<first-initial><last-initial>-todo.cfapps.io

Discussion: Part 2

In this part of the workshop we created a database service from the marketplace, pushed an app, bound it to the database service, monitored the health of the app and scaled the app.

Note	How does the app get the database info today vs. VCAP_SERVICES? How do you horizontally scale your applications?

PART 4: Deploy Version 2 of the App

In this section we are going to do a green-blue deployment using a shell script. The same can be done by executing the commands one at a time.

Delete the unversioned app and the route

cf delete <first-initial><last-initial>-todo
cf delete-route cfapps.io -n <first-initial><last-initial>-todo

Push Version 2 and Delete the Old Route using the script

We are going to deploy the next version of the cities-ui app. The deployment typically is automated using a CD pipeline built with Jenkins or any CD automation tool, but in this workshop we will walk through a simple version number change in the deployment manifest.

Edit the manifest.blue-green with the following variables
```
---
 VERSION: TODO_1_0
---
```

Edit and source the env file from the cities-ui folder with the following variables

---
export CF_SYSTEM_DOMAIN=     //CF_SYSTEM_DOMAIN will look similar to run.pivotal.io
export CF_APPS_DOMAIN=       //CF_APPS_DOMAIN will look similar to cfapps.io
export CF_USER=              //CF_USER is the user account to sign into Pivotal Cloud Foundry, which is usually your email address.
export CF_ORG=               //CF_ORG is the name of the Organization within Pivotal Cloud Foundry where you want to deploy your applications.
export CF_SPACE=             //CF_SPACE is the name of the Space within the above Organization where you want your application deployed.
export CF_APP=<first-initial><last-initial>-todo
export CF_MANIFEST=manifest.blue-green
export BUILD_NUMBER=1001
---

Note: Be sure to change the CF_APP name to match your application and add the BUILD_NUMBER to the env file. Add the Version number in the manifest.blue-green

First deploy the blue v1 of the app.

// Push the new version of the app, with the version number and route
$cf push "$CF_APP-$BUILD_NUMBER" -n "$CF_APP-$BUILD_NUMBER" -d $CF_APPS_DOMAIN -f $CF_MANIFEST

Next, increment the BUILD_NUMBER in the env file and source it. Change the VERSION number in the manifest.blue-green
```
....
export BUILD_NUMBER=2001

$nano manifest.yml
....
VERSION: TODO_APP_2_0
```

Deploy the green v2 and delete the blue v1 of the app.

// Push the new version of the app, with the version number and route
$cf push "$CF_APP-$BUILD_NUMBER" -n "$CF_APP-$BUILD_NUMBER" -d $CF_APPS_DOMAIN  -f $CF_MANIFEST

// Map the route to point to the new app
$cf map-route "$CF_APP-${BUILD_NUMBER}" $CF_APPS_DOMAIN -n $CF_APP

// Get the deployed version of the app
$export DEPLOYED_VERSION=`cf apps | grep $CF_APP- | cut -d" " -f1`

// Un-map an existing routes and delete the app / routes

$cf unmap-route "$DEPLOYED_VERSION" $CF_APPS_DOMAIN -n $CF_APP
$cf delete "$DEPLOYED_VERSION" -f
$cf delete-route $CF_APPS_DOMAIN -n "$DEPLOYED_VERSION" -f

Alternatively, use the bash script blue-green.sh in the cities-ui directory, deploy the green v2 and delete the blue v1 of the app.
If you are using the script make sure you increment the BUILD_NUMBER in the env file and change the VERSION number in the manifest.blue-green.

$ cat blue-green.sh

source env
cf login -a https://api.$CF_SYSTEM_DOMAIN -u $CF_USER -o $CF_ORG -s $CF_SPACE --skip-ssl-validation

DEPLOYED_VERSION_CMD=$(CF_COLOR=false cf apps | grep $CF_APP- | cut -d" " -f1)
DEPLOYED_VERSION="$DEPLOYED_VERSION_CMD"
ROUTE_VERSION=$(echo "${BUILD_NUMBER}" | cut -d"." -f1-3 | tr '.' '-')
echo "Deployed Version: $DEPLOYED_VERSION"
echo "Route Version: $ROUTE_VERSION"

# push a new version and map the route
cf push "$CF_APP-$BUILD_NUMBER" -n "$CF_APP-$ROUTE_VERSION" -d $CF_APPS_DOMAIN -f $CF_MANIFEST
cf map-route "$CF_APP-${BUILD_NUMBER}" $CF_APPS_DOMAIN -n $CF_APP

if [ ! -z "$DEPLOYED_VERSION" -a "$DEPLOYED_VERSION" != " " -a "$DEPLOYED_VERSION" != "$CF_APP-${BUILD_NUMBER}" ]; then
  echo "Performing zero-downtime cutover to $BUILD_NUMBER"
  echo "$DEPLOYED_VERSION" | while read line
  do
    if [ ! -z "$line" -a "$line" != " " -a "$line" != "$CF_APP-${BUILD_NUMBER}" ]; then
      echo "Scaling down, unmapping and removing $line"
      # Unmap the route and delete
      cf unmap-route "$line" $CF_APPS_DOMAIN -n $CF_APP
      cf delete "$line" -f
      cf delete-route $CF_APPS_DOMAIN -n "$line" -f
    else
      echo "Skipping $line"
    fi
  done
fi

Repeat the Process

Change the version (in the manifest) and build numbers (in the env file) and run the script to do blue-green deployment. Check the output using curl.

Process of Blue Green Deployment

Review the CF Document for blue green deployment Using Blue-Green Deployment to Reduce Downtime and Risk

In summary Blue-green deployment is a release technique that reduces downtime and risk by running two identical production environments called Blue and Green.

Newsworthy: Automated Blue Green with cf plugin

Cloud Foundry plugin Autopilot does blue green deployment, albeit it takes a different approach to other zero-downtime plugins. It doesn’t perform any complex route re-mappings instead it leans on the manifest feature of the Cloud Foundry CLI. The method also has the advantage of treating a manifest as the source of truth and will converge the state of the system towards that. This makes the plugin ideal for continuous delivery environments.

$ mkdir $HOME/go
$ export GOPATH=$HOME/go
$ export PATH=$PATH:$GOPATH/bin

$ go get github.com/concourse/autopilot
$ cf install-plugin $GOPATH/bin/autopilot
$ cd todos
// Increment the Build
$ cf zero-downtime-push todos \
    -f manifest.blue-green \
    -p build/libs//todo-0.0.1-SNAPSHOT.jar

Discussion: Part 4

In this part of the workshop did deployment using a blue green script without any downtime. This script / methodology can be used in your CD pipeline to build and deploy Cloud Native Apps with zero downtime.

Note	Discussion on how do you do Continous Deployment and Delivery with zero downtime today.

Recap

In this workshop we saw how to build, deploy, bind, scale, monitor apps on Cloud foundry and manage the lifecycle of the application

Name		Name	Last commit message	Last commit date
Latest commit History 57 Commits
images		images
README.adoc		README.adoc
README_ja.adoc		README_ja.adoc

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

DevOps on Cloud Foundry Platform

Goals

Prerequisites

Pre-work

Steps

PART 1: Introduction to CF, Push an App.

Push the app

Recap: Part 1

Discussion: Part 1

PART 2: Push, Bind, Monitor and Scale an App.

Create a Database Service from Marketplace

Manually Binding the Service Instance

Binding Services via the Manifest

Health, logging & events via the CLI

Environment variables

Scaling apps

Verify the app from the Console

Discussion: Part 2

PART 4: Deploy Version 2 of the App

Delete the unversioned app and the route

Push Version 2 and Delete the Old Route using the script

Repeat the Process

Process of Blue Green Deployment

Newsworthy: Automated Blue Green with cf plugin

Discussion: Part 4

Recap

Q/A

About

Releases

Packages

Contributors 3

shinji62/pcf-workshop-ge

Folders and files

Latest commit

History

Repository files navigation

DevOps on Cloud Foundry Platform

Goals

Prerequisites

Pre-work

Steps

PART 1: Introduction to CF, Push an App.

Login to the Cloud Platform

Push the app

Recap: Part 1

Discussion: Part 1

PART 2: Push, Bind, Monitor and Scale an App.

Create a Database Service from Marketplace

Manually Binding the Service Instance

Binding Services via the Manifest

Health, logging & events via the CLI

Environment variables

Scaling apps

Verify the app from the Console

Discussion: Part 2

PART 4: Deploy Version 2 of the App

Delete the unversioned app and the route

Push Version 2 and Delete the Old Route using the script

Repeat the Process

Process of Blue Green Deployment

Newsworthy: Automated Blue Green with cf plugin

Discussion: Part 4

Recap

Q/A

About

Resources

Stars

Watchers

Forks

Releases

Packages 0

Contributors 3

Packages