Configuring Container-to-Container Networking
Page last updated:
Warning: Pivotal Cloud Foundry (PCF) v2.3 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
This topic describes how to configure the Container-to-Container Networking feature, which allows direct network traffic between apps. For an overview of how Container-to-Container Networking works, see the Container-to-Container Networking topic.
Container-to-Container Networking enables PCF to generate logs whenever containers communicate or attempt to communicate with each other. See App Traffic Logging for how to manage app traffic logging.
Configure the Overlay Network
Container-to-Container Networking uses an overlay network to manage communication between app instances.
By default, each Diego cell in the overlay network is allocated a /24 range that supports 254 containers per cell, one container for each of the usable IP addresses, .1
through .254
.
For more information about the overlay network, see Overlay Network in Container-to-Container Networking.
Configure the Number of Diego Cells
If you want to modify the number of Diego cells supported by the overlay network, follow the steps below:
- In Ops Manager, select the PAS tile.
- Select Networking.
- Under Overlay Subnet, enter an IP range for the overlay network. By default, Ops Manager uses
10.255.0.0/16
. Modifying the subnet range allocated to the overlay network changes the number of Diego cells supported in your deployment. Use the table below as a reference.
Overlay subnet mask | Number of cells | Containers per cell |
---|---|---|
/20 | 15 | 254 |
/16 | 255 | 254 |
/12 | 4,095 | 254 |
Warning: The overlay network IP address range must not conflict with any other IP addresses in the network. If a conflict exists, Diego cells cannot reach any endpoint that has a conflicting IP address.
Create and Manage Networking Policies
This section describes how to create and modify Container-to-Container Networking policies using the Cloud Foundry Command Line Interface (cf CLI). The cf CLI only supports configuring policies for apps within the same space. To configure policies for apps in different orgs and spaces, use the Policy Server External API.
Note: You can also create and modify container-to-container networking policies using Apps Manager. For more information, see Create Container-to-Container Networking Policies.
Note: With the NSX-T integration, container networking policies and ASGs continue to work as normal. Advanced ASG logging is not supported with NSX-T.
Prerequisites
- Ensure that you are using cf CLI v6.30 or higher:
$ cf version
For more information about updating the cf CLI, see the Installing the cf CLI topic.
Grant Permissions
CF admins use the following UAA scopes to grant specific users or groups permissions to configure network policies:
UAA Scope | Suitable for… | Allows users to create policies… |
---|---|---|
network.admin |
operators | for any apps in the CF deployment |
network.write |
space developers | for apps in spaces that they can access |
If you are a CF admin, you already have the network.admin
scope. An admin can also grant the network.admin
scope to a space developer.
For more information, see Creating and Managing Users with the UAA CLI (UAAC) and Orgs, Spaces, Roles, and Permissions.
To grant all Space Developers permissions to configure network policies, open the Application Developer Controls pane in your PAS tile and enable the Allow Space Developers to manage network policies checkbox.
Add a Network Policy
To add a policy that allows direct network traffic from one app to another, run the following command:
cf add-network-policy SOURCE_APP --destination-app DESTINATION_APP --protocol (tcp | udp) --port RANGE
Replace the placeholders in the above command as follows:
SOURCE_APP
is the name of the app that sends traffic.DESTINATION_APP
is the name of the app that will receive traffic.PROTOCOL
is one of the following:tcp
orudp
.RANGE
are the ports at which to connect to the destination app. The allowed range is from1
to65535
. You can specify a single port, such as8080
, or a range of ports, such as8080-8090
.
The following example command allows access from the frontend
app to the backend
app over TCP at port 8080:
$ cf add-network-policy frontend --destination-app backend --protocol tcp --port 8080 Adding network policy to app frontend in org my-org / space dev as admin... OK
List Policies
You can list all the policies in your space, or just the policies for which a single app is the source:
To list the all the policies in your space, run
cf network-policies
.$ cf network-policies
To list the policies for an app, run
cf network-policies --source MY-APP
. ReplaceMY-APP
with the name of your app.$ cf network-policies --source example-app
The following example command lists policies for the app
frontend
:$ cf network-policies --source frontend Listing network policies in org my-org / space dev as admin... source destination protocol ports frontend backend tcp 8080
Remove a Network Policy
To remove a policy that allows direct network traffic from an app, run the following command:
cf remove-network-policy SOURCE_APP --destination-app DESTINATION_APP --protocol PROTOCOL --port RANGE
Replace the placeholders in the above command to match an existing policy, as follows:
SOURCE_APP
is the name of the app that sends traffic.DESTINATION_APP
is the name of the app that receives traffic.PROTOCOL
is eithertcp
orudp
.PORTS
are the ports connecting the apps. The allowed range is from1
to65535
. You can specify a single port, such as8080
, or a range of ports, such as8080-8090
.
The following command deletes the policy that allowed the frontend
app to communicate with the backend
app over TCP on port 8080:
$ cf remove-network-policy frontend --destination-app backend --protocol tcp --port 8080 Removing network policy to app frontend in org my-org / space dev as admin... OK
App Service Discovery
With app service discovery, apps pushed to Pivotal Application Service can establish container-to-container communications through a known route served by internal BOSH DNS. This allows front end apps to easily connect with back end apps.
Note: The internal domain used for service discovery is apps.internal
by default. Operators can modify this value in Application Developer Controls pane of the PAS tile.
To establish container-to-container communications between a front end and back end app, a developer:
- Launches a back end app that publishes a local endpoint.
- Maps a named route to the endpoint.
- Creates a network policy that allows direct traffic from the front end to the back end app.
- Launches the front end app.
See Cats and Dogs with Service Discovery in GitHub for an example, written in Go, that demonstrates communication between front end and back end apps.