Complete the steps provided below to deploy the BIG-IP Controller for Cloud Foundry using the default global configuration mode.
If you need to configure BIG-IP objects for individual Routes, you’ll need to register the BIG-IP Controller as a Service Broker. See Deploy the BIG-IP Controller for Cloud Foundry with per-Route Virtual Servers for more information.
|Complete the setup prerequisites|
Add BIG-IP Health Monitors (OPTIONAL)
Apply BIG-IP policies and profiles (OPTIONAL)
|Push the BIG-IP Controller app to Cloud Foundry|
|Verify object creation on the BIG-IP system|
globalmode, this user needs “routing.routes.read” and “routing.router_groups.read” permissions.
service_brokermode, the user needs “routing.routes.read”, “routing.router_groups.read”, and “cloud_controller.read” permissions.
Create a new Application Manifest file containing your desired cf-bigip-ctlr configuration parameters.
Include the following in the
env.BIGIP_CTLR_CFG.bigip section of the manifest:
To support L7 (HTTP) routing, include the
nats section shown in the example manifest.
To support L4 (TCP) routing, define the following sections:
See the cf-bigip-ctlr configuration parameters table for more information.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42
applications: - name: cf-bigip-ctlr health-check-type: http health-check-http-endpoint: /health env: # Provide the desired BIG-IP configurations including partition, load # balancing algorithm, and Self IP address to assign to the virtual server # THE SETTINGS IN THIS SECTION ARE GLOBAL # Set "broker_mode" to "true" to run the BIG-IP Controller as a # Service Broker BIGIP_CTLR_CFG: | bigip: url: https://bigip.example.com user: myBigipUsername pass: myBigipPassword partition: - cf balance: least-connections-node verify_interval: 30 external_addr: 10.100.100.101 # Required if running the Controller in broker mode tier2_ip_range: 255.255.255.0 ssl_profiles: - /Common/my-ssl-policy policies: - /Common/example-ltm-policy profiles: - /Common/example-profile health_monitors: - /Common/tcp_half_open # Required to run the BIG-IP Controller as a Service # Broker (introduced in v1.1.0) broker_mode: true logging: level: info route_mode: all # Required for HTTP routing nats:
In the global
bigip configuration section, you can attach health monitors that already exist on the BIG-IP device. The example below attaches the existing BIG-IP health monitor called “http.get”, which resides in the
BIGIP_CTLR_CFG: | bigip: url: https://bigip.example.com user: myBigipUsername pass: myBigipPassword partition: - cf balance: round-robin verify_interval: 30 external_addr: 192.168.1.1 health-monitors: - /Common/http.get
You can create new health monitors and/or attach existing BIG-IP health monitors for per-Route virtual servers <define per-route vs settings>.
You can apply existing BIG-IP policies and profiles to the virtual server(s) created for your Cloud Foundry Routes. For example: to use the “x-forwarded-for” and “x-forwarded-proto” headers, take the steps below.
Create a BIG-IP local traffic profile with “x-forwarded-for” enabled.
Create a BIG-IP local traffic policy to set the “x-forwarded-proto” header.
Add the profile and policy to the Application Manifest. This will associate the objects with the virtual server when the Controller creates it on the BIG-IP system.
BIGIP_CTLR_CFG: | bigip: url: https://bigip.example.com user: myBigipUsername pass: myBigipPassword partition: - cf balance: round-robin verify_interval: 30 external_addr: 192.168.1.1 profiles: - /Common/x-forwarded-for policies: - /Common/x-forwarded-proto
cf-bigip-ctlr App using the cf push command.
Be sure to use the
-o flag to specify the Docker image and version you want to use.
cf push cf-bigip-ctlr -o f5networks/cf-bigip-ctlr:1.1.0 -f manifest.yaml
The objects created on the BIG-IP system will vary depending on how you set up your Application Manifest.
At minimum, you should see one HTTP virtual server accepting traffic on port 80. If you included an SSL profile in your Manifest, you should also see an HTTPS virtual server accepting traffic on port 443. If you’re using TCP Routes, you should see one virtual server for each Route.