Skip to content
This repository has been archived by the owner on Jul 19, 2022. It is now read-only.

Latest commit

 

History

History
154 lines (128 loc) · 5.7 KB

lab-ruby.adoc

File metadata and controls

154 lines (128 loc) · 5.7 KB

Lab 1 - From Zero to Pushing Your First Application

Target

  1. If you haven’t already, download the latest release of the Cloud Foundry CLI from https://github.com/cloudfoundry/cli/releases for your operating system and install it.

  2. Set the API target for the CLI: (set appropriate end point for your environment)

    $ cf api https://api.devcloudwest.inbcu.com --skip-ssl-validation

  3. Login to Pivotal Cloudfoundry:

    $ cf login

    Follow the prompts

Push It!

  1. Change to the pcf-autoscale sample application directory:

    $ cd $BOOTCAMP_HOME/pcf-autoscale

  2. Push the application!

    $ cf push

    You should see output similar to the following listing. Take a look at the listing callouts for a play-by-play of what’s happening:

    Using manifest file /Users/phopper/workspace/NBCU-PCF-Workshop-101/pcf-autoscale/manifest.yml (1)

Updating app scale-demo in org TELCO / space hopper as [email protected]...
OK (2)

Creating route scale-nonsynodical-hartal.vert.fe.gopivotal.com...
OK (3)

Binding scale-nonsynodical-hartal.vert.fe.gopivotal.com to scale-demo...
OK (4)

Uploading scale-demo... (5)
Uploading app files from: /Users/phopper/workspace/NBCU-PCF-Workshop-101/pcf-autoscale
Uploading 242.4K, 24 files
Done uploading
OK

Starting app scale-demo in org TELCO / space hopper as [email protected]... (6)
-----> Downloaded app package (2.8M)
-------> Buildpack version 1.3.1
-----> Compiling Ruby/Rack
-----> Using Ruby version: ruby-2.0.0 (7)
-----> Installing dependencies using 1.7.12 (8)
       Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
       Using bundler 1.7.12
       Installing tilt 1.3.3
       Installing rack 1.5.1
       Installing rack-protection 1.3.2
       Installing sinatra 1.3.4
       Your bundle is complete!
       Gems in the groups development and test were not installed.
       It was installed into ./vendor/bundle
       Bundle completed (0.71s)
       Cleaning up the bundler cache.
###### WARNING:
       You have not declared a Ruby version in your Gemfile.
       To set your Ruby version add this line to your Gemfile:
       ruby '2.0.0'
       # See https://devcenter.heroku.com/articles/ruby-versions for more information.
###### WARNING:
       No Procfile detected, using the default web server (webrick)
       https://devcenter.heroku.com/articles/ruby-default-web-server

-----> Uploading droplet (19M) (9)

1 of 1 instances running

App started

OK

App scale-demo was started using this command `bundle exec rackup config.ru -p $PORT` (10)

Showing health and status for app scale-demo in org TELCO / space hopper as [email protected]... (11)
OK

requested state: started
instances: 1/1
usage: 128M x 1 instances
urls: scale-nonsynodical-hartal.vert.fe.gopivotal.com
last uploaded: Thu Sep 24 19:48:08 UTC 2015
stack: cflinuxfs2
buildpack: Ruby

     state     since                    cpu    memory          disk          details
#0   running   2015-09-24 01:48:32 PM   0.0%   48.1M of 128M   71.8M of 1G

    1. The CLI is using a manifest to provide necessary configuration details such as application name, memory to be allocated, and path to the application artifact. Take a look at manifest.yml to see how.

    2. In most cases, the CLI indicates each Cloud Foundry API call as it happens. In this case, the CLI has created an application record for scale-demo in your assigned space.

    3. All HTTP/HTTPS requests to applications will flow through Cloud Foundry’s front-end router called (Go)Router. Here the CLI is creating a route with random word tokens inserted (again, see manifest.yml for a hint!) to prevent route collisions across the default devcloudwest.inbcu.com domain.

    4. Now the CLI is binding the created route to the application. Routes can actually be bound to multiple applications to support techniques such as blue-green deployments.

    5. The CLI finally uploads the application bits to Pivotal Cloud Foundry. Notice that it’s uploading 24 files! This is because Cloud Foundry actually explodes a ZIP artifact before uploading it for caching purposes.

    6. Now we begin the staging process. The Ruby Buildpack is responsible for assembling the runtime components necessary to run the application.

    7. Here we see the version of the Ruby that has been chosen and installed.

    8. And here we see our apps dependencies that have been discovered and installed.

    9. The complete package of your application and all of its necessary runtime components is called a droplet. Here the droplet is being uploaded to Pivotal Cloudfoundry’s internal blobstore so that it can be easily copied to one or more Droplet Execution Agents (DEA’s) for execution.

    10. The CLI tells you exactly what command and argument set was used to start your application.

    11. Finally the CLI reports the current status of your application’s health.

  3. Visit the application in your browser by hitting the route that was generated by the CLI:

    lab ruby

Interact with App from CF CLI

  1. Get information about the currently deployed application using CLI apps command:

    $ cf apps

    Note the application name for next steps

  2. Get information about running instances, memory, CPU, and other statistics using CLI instances command

    $ cf app <<app_name>>

  3. Stop the deployed application using the CLI

    $ cf stop <<app_name>>

  4. Delete the deployed application using the CLI

    $ cf delete <<app_name>>