Proxying a PCF App with Apigee Edge

Page last updated:

This topic describes how to push a sample app to Pivotal Cloud Foundry (PCF), create an Apigee Edge service instance, and bind the application to it. After binding the application to the Apigee Edge service instance, requests to the app will be forwarded to an Apigee Edge API proxy for management.

Before performing the procedures in this topic, you must install and configure the Apigee Edge Service Broker for PCF tile.

Step 1: Push the Sample App

Perform the following steps to push a sample application to PCF.

  1. Clone the Apigee Edge GitHub repo:

    $ git clone https://github.com/apigee/pivotal-cf-apigee.git

  2. Change into the sample-api directory of the cloned repo:

    $ cd pivotal-cf-apigee/sample-api

  3. In the sample-api directory, open manifest.yml.

  4. Edit manifest.yml to change the name and host properties to values specific to your deployment. See the following example:

    applications: 
    - name: sample-api 
      memory: 128M 
      instances: 1 
      host: sample-api-apigee 
      path: . 
      buildpack: nodejs_buildpack
    
  5. Save the edited file.

  6. Set your API endpoint to the Cloud Controller of your deployment.

    $ cf api api.YOUR-SYSTEM-DOMAIN
    Setting api endpoint to api.YOUR-SYSTEM-DOMAIN...
    OK
    API endpoint:  https://api.YOUR-SYSTEM-DOMAIN (API version: 2.59.0)
    Not logged in. Use 'cf login' to log in.
    

  7. Log in to your deployment and select an org and a space.

    $ cf login
    API endpoint: https://api.YOUR-SYSTEM-DOMAIN
    Email> user@example.com
    Password>
    

  8. Push the sample app to PCF:

    $ cf push YOUR-SAMPLE-APP

  9. Use curl to send a test request to the app you pushed:

    $ curl YOUR-SAMPLE-APP.YOUR-SYSTEM-DOMAIN
    {"hello":"hello from cf app"} 
    
    If you receive the above response, the sample app is running successfully.

Step 2: Create a Service Instance

Perform the following steps to create an instance of the Apigee Edge service:

  1. List the Marketplace services and locate the Apigee Edge service:

    $ cf marketplace
    Getting services from marketplace in org example / space development as user@example.com...
    OK
    
    service          plans                     description
    apigee-edge      org, microgateway         Apigee Edge API Platform
    
  2. Create an instance of the Apigee Edge service. Select either the org or microgateway service plan.

    • Use the org plan when proxying through Apigee Edge Cloud.
    • Use the microgateway plan when proxying through Apigee Edge Microgateway. The example below uses the org plan:
    $ cf create-service apigee-edge org YOUR-SERVICE-INSTANCE
  3. Use the cf service command to display information about the service instance:

    $ cf service apigee-service
    
    Service instance: apigee-service
    Service: apigee-edge
    Bound apps:
    Tags:
    Plan: org
    Description: Apigee Edge API Platform
    Documentation url: http://apigee.com/docs/
    Dashboard: https://enterprise.apigee.com/platform/#/
    
    Last Operation
    Status: create succeeded
    Message:
    Started: 2016-10-27T20:47:43Z
    Updated:
    

Step 3: Bind the App Route to the Service Instance

Perform the following steps to bind the route of your app to your Apigee Edge service instance.

  1. Download the Apigee Edge scripts:
    $ curl https://login.apigee.com/resources/scripts/sso-cli/ssocli-bundle.zip -o "ssocli-bundle.zip"
  2. Unzip the ssocli-bundle.zip file. This includes get_token, a script that gets or updates a token that you use to authenticate with your Apigee Edge organization. You need this token to bind the Apigee Edge route service to your
    $ tar xvf ssocli-bundle.zip
  3. Create a .sso-cli directory in your user directory:
    $ mkdir ~/.sso-cli
  4. Use the get_token script to create a token. When prompted, enter the Apigee Edge username and password you use to log in to your organization.

    $ ./get_token

    The get_token script writes the token file into ~/.sso-cli. For more about get_token, see the Apigee documentation.

  5. Use the bind-route-service command to create an Apigee Edge API proxy and bind your Cloud Foundry app to the proxy. This tells the Gorouter to redirect requests to the Apigee Edge proxy before sending them to the Cloud Foundry application.

    $ cf bind-route-service cfapps.pivotal.io APIGEE-SERVICE --hostname SAMPLE-APP-APIGEE -c '{"org":"myedgeorg","env":"myedgeenv", "bearer":"'$(cat ~/.sso-cli/valid_token.dat)'", "action":"proxy bind"}'
    Binding route sample-api-apigee.cfapps.pivotal.io to service instance apigee-service in org apigee / space test as admin...
    OK
    

    • For APIGEE-SERVICE, use the name of the Apigee Edge service instance you created earlier
    • For SAMPLE-APP-APIGEE, use the name of the host you specified in your manifest.yml

The output from bind-route-services should confirm that you have bound the route of your app to your Apigee Edge service instance.

Step 4: Test the Binding

Once you’ve bound your app’s path to the Apigee service (creating an Apigee proxy in the process), you can try it out with the sample app you invoked earlier.

  1. Open the Apigee Edge management console.
  2. In the management console, under APIs > API proxies, locate the name of the proxy you just created with bind-route-service. It’s likely to have a name that ends with your domain value, such as cfapps.pivotal.io.
  3. Click the new proxy’s name to view its Overview page.
  4. Click the Trace tab, then click the Start Trace Session button.
  5. Back at the command line, run the curl command you ran earlier to make a request to your Cloud Foundry app you pushed, such as:

    $ curl https://sample-api-apigee.cfapps.pivotal.io 
    {"hello":"hello from cf app"} 
    
    As before, the console outputs the app’s response.

  6. Return to the Apigee Edge management console to see that your request has now been routed through the Edge proxy you created.

The new proxy is just a pass-through, but it is now ready for you or someone on your team to add policies to define security, traffic management, and more.

Was this helpful?
What can we do to improve?
Create a pull request or raise an issue on the source for this page in GitHub