containers microservices network network_security Pivotal Cloud Foundry Spring

Building Spring Microservices with Cloud Foundry’s New Container Networking Stack

We’re excited to announce two new beta features for Pivotal Web Services (PWS)! Spring Cloud Services and Cloud Foundry's new container networking stack are now available.

First, Spring Cloud Services (SCS) is available as a beta in the PWS marketplace. SCS is an essential tool for building microservices architectures with Pivotal Cloud Foundry that is now available to any PWS user.

Second, the new Cloud Foundry container networking stack is available, also as a beta. This feature supports container-to-container networking. Using container networking, you can configure network policies for app-to-app interactions, and tailor efficient routes between containers to boost security and reduce latency. [UPDATE: As of July 2017: Container Networking is now generally available for all PWS users. This blog has been modified slightly to reflect this change.]

We've coupled the beta programs for these features because they work well together. Container networking and the Service Registry combine to boost efficiency in client communications. Further, developers can control how services access each other, boosting security.

Ready to use these new features together? Read on, and see how easy it is to connect application clients and their dependent services!

What You’ll Need

To use Service Registry with container networking in your Spring applications, you’ll need the following setup in your development environment:

Now, verify that you have SCS in your PWS marketplace, along with container networking support. Log in and run the following commands using the Cloud Foundry CLI:

$ cf marketplace | grep Spring
…
p-circuit-breaker-dashboard standard Circuit Breaker Dashboard for Spring Cloud Applications
p-config-server standard Config Server for Spring Cloud Applications
p-service-registry standard Service Registry for Spring Cloud Applications
…

$ cf network-policies
...
Source        Destination    Protocol    Port
...

An Example

The SCS development team has created example applications; you can find them in the “Who is Home?” repository on Github. The client application is named visitor. The visitor application knocks at the homeowner application’s virtual door, a REST API, to have a conversation. These applications show how clients and services use container networking through the service registry.

Deploy these applications and the dependent SCS Service Registry by following the instructions in the repository README.

Enabling Direct Access to Services

With Spring Cloud Services (SCS), an application registering itself in the service registry typically uses the route registration method. This is the default method when using the Spring Cloud Services Connector for Service Registry.

If you want to use direct container-to-container networking, you’ll use the direct registration method instead. Here’s the configuration block to add into the application configuration (such as application.yml) for the registering application:

spring:
 cloud:
   services:
     registrationMethod: direct

At the time of this writing, you must also use Spring Cloud OSS and SCS dependencies that add the ability to use direct container networking. An example build file using Gradle would add the following Maven BOM dependencies:

dependencyManagement {
   imports {
       mavenBom "org.springframework.cloud:spring-cloud-dependencies:Camden.SR4"
       mavenBom "io.pivotal.spring.cloud:spring-cloud-services-dependencies:1.4.1.RELEASE"
   }
}

Or using Maven:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.pivotal.spring.cloud</groupId>
            <artifactId>spring-cloud-services-dependencies</artifactId>
            <version>1.4.1.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Camden.SR4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Now that our registering application is configured to use direct container networking, there is no need for Cloud Foundry to generate an external route when it is deployed.

For an application named homeowner, Cloud Foundry would usually generate a route with a URL such as https://homeowner.cf-app-domain.com. In this case, we don’t want to expose our service externally. Therefore, our setup should tell PWS not to create a route for this application. This can be accomplished by adding the –no-route cf CLI option when pushing the application to PWS, or by setting no-route: true in the application’s manifest.yml.

Testing Direct Container Networking

If you just deployed your client and service applications for the first time, you probably don’t have any networking policies set up. Verify this by running the `cf network-policies`. If you go to the client application’s URL, the visitor application (in the “Who is Home?” sample), you will receive a message that the visitor application is not able to communicate with the registered service homeowner. Although the service registry provides the internal IP address and port for the service to connect to, there is no network policy allowing this communication. Communication is blocked by default.

To enable communication between the client and service applications, you can add a network policy. For example, to allow visitor to communicate with homeowner, use the following command:

$ cf add-network-policy visitor --destination-app homeowner --protocol tcp --port 8080

The add-network-policy command sets up a network route from visitor to homeowner using a TCP protocol on port 8080. Once this network policy has been added successfully, the visitor application can communicate with the homeowner application. And most importantly, it is not using an externally available route to do so: it is using direct container networking with an IP address and port for the service application. When we list the network policies we now see the following:

$ cf network-policies
...
SourceDestinationProtocolPort
visitorhomeownertcp8080

Summary

Direct container-to-container networking enables many new scenarios for applications deployed to Pivotal Cloud Foundry. One of those use cases: the ability to register applications using the direct registration method with a Spring Cloud Services Service Registry. Now, a registered service no longer needs an externally routable URL, and instead you can control communication with the service using network policies!

Set up an account on Pivotal Web Services to try out Spring Cloud Services, Container Networking, and much more.

[UPDATE: This blog post was updated with new CLI commands for container networking in November 2017.]

Related Articles