Service Registry sample

Message Generation and Greeter are example applications demonstrating the use of Service Registry for Tanzu. (For information on the Service Registry product in Tanzu Application Service, please see the documentation.)

The main branch is using spring-boot 4.x and the Tanzu Spring SDK 1.2.0. Check spring-boot-2.7 branch for older versions.

Dependencies

Both applications import the Tanzu Spring SDK BOM (com.vmware.tanzu.spring:tanzu-spring-sdk-dependencies, version 1.2.0). The BOM manages the version of application-services-starter-service-registry, which provides the Service Registry client, so the starter is declared without a version.

Maven sets the SDK version and imports the BOM in the root pom.xml:

<properties>
  <tanzu-spring-sdk.version>1.2.0</tanzu-spring-sdk.version>
</properties>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.vmware.tanzu.spring</groupId>
      <artifactId>tanzu-spring-sdk-dependencies</artifactId>
      <version>${tanzu-spring-sdk.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Each application declares the starter in its own pom.xml:

<dependencies>
  <dependency>
    <groupId>com.vmware.tanzu.spring.applicationservices</groupId>
    <artifactId>application-services-starter-service-registry</artifactId>
  </dependency>
</dependencies>

Gradle sets the SDK version for both applications in the root build.gradle:

subprojects {
    ext {
        set('tanzuSpringSdkVersion', '1.2.0')
    }
}

Each application imports the BOM and declares the starter in its own build.gradle:

dependencyManagement {
    imports {
        mavenBom "com.vmware.tanzu.spring:tanzu-spring-sdk-dependencies:${tanzuSpringSdkVersion}"
    }
}

dependencies {
    implementation("com.vmware.tanzu.spring.applicationservices:application-services-starter-service-registry")
}

To use a different SDK release, change tanzu-spring-sdk.version in the root pom.xml and tanzuSpringSdkVersion in the root build.gradle. Use the same version in both files.

Authentication Setup

Both builds use the Spring Enterprise repository (https://packages.broadcom.com/artifactory/spring-enterprise), which requires credentials. For repository configuration, see Spring Enterprise Repository for Artifact Repository Administrators.

1. Set Environment Variables (Recommended)

Set these environment variables before you build:

export SEC_ARTIFACTORY_USERNAME=your_username
export SEC_ARTIFACTORY_PASSWORD=your_access_token

2. Build Tool Specific Configuration

For Gradle:

Gradle reads the environment variables above. You can also set the credentials in ~/.gradle/gradle.properties:

secArtifactoryUsername=your_username
secArtifactoryPassword=your_access_token

For Maven:

Add the spring-enterprise server to ~/.m2/settings.xml. This configuration reads the environment variables from step 1. If the file already has a servers element, add the server entry to it.

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>spring-enterprise</id>
      <username>${env.SEC_ARTIFACTORY_USERNAME}</username>
      <password>${env.SEC_ARTIFACTORY_PASSWORD}</password>
    </server>
  </servers>
</settings>

Building and Deploying on Tanzu Application Platform (TAP)

Greeting with Service Registry on TAP has the following deployment architecture:

The eureka-controller manages a StatefulSet of eureka servers and connection Secrets that Greeter and Greeter Messages use to connect to discover each other.

1. Create a EurekaServer resource with two replicas using the provided YAML definition:

   kubectl apply -f tap/eurekaserver.yaml

2. Check the status of the EurekaServer:

   kubectl describe eurekaservers.service-registry.spring.apps.tanzu.vmware.com eurekaserver-sample -n my-apps

   For example:

    k describe eurekaservers.service-registry.spring.apps.tanzu.vmware.com eurekaserver-sample
   Name:         eurekaserver-sample
   Namespace:    my-apps
   Labels:       <none>
   Annotations:  <none>
   API Version:  service-registry.spring.apps.tanzu.vmware.com/v1alpha1
   Kind:         EurekaServer
   Metadata:
     Creation Timestamp:  2023-10-20T13:53:51Z
     Generation:          1
     Resource Version:    1727487
     UID:                 1c411573-281a-4ec1-b81e-65f746404ac8
   Spec:
     Replicas:  2
   Status:
     Binding:
       Name:  eureka-eurekaserver-sample-client-binding-z5tmh
     Conditions:
       Last Transition Time:  2023-10-20T13:53:57Z
       Message:               EurekaServer reconciled
       Observed Generation:   1
       Reason:                EurekaServerReconciled
       Status:                True
       Type:                  Ready
     Observed Generation:     1
     Server Binding:
       Name:  eureka-eurekaserver-sample-server-binding-m946r
   Events:    <none>

   A successful EurekaServer resource has a Ready condition set to true and a status.binding.name field pointing to a secret containing connection information.

3. Claim credentials using the Tanzu CLI:

   tanzu service resource-claim create -n my-apps eurekaserver-sample \
       --resource-name eurekaserver-sample \
       --resource-kind EurekaServer \
       --resource-api-version service-registry.spring.apps.tanzu.vmware.com/v1alpha1 \
       --resource-namespace my-apps

   Note	Alternatively the provided ResourceClaim yaml definition can be used: kubectl apply -f tap/resource-claim.yaml

4. Create workloads for both greeter and greeter-messages using the Tanzu CLI:

   tanzu apps workload create -f tap/greeter-messages.yaml --yes
   tanzu apps workload create -f tap/greeter.yaml --yes

Trying it Out

1. Retrieve the ingress route associated with the Greeter application using the tanzu cli:

   tanzu apps workload get greeter

   For example:

   $ tanzu apps workload get greeter
   
   # other output...
   
   🚢 Knative Services
      NAME      READY   URL
      greeter   Ready   https://greeter.my-apps.tap
   
   To see logs: "tanzu apps workload tail greeter --timestamp --since 1h"

   Where https://greeter.my-apps.tap is the accessible ingress route to the greeter application

2. Visit [ROUTE]/hello, where [ROUTE] is the ingress route you just retrieved. The Greeter application will use the Service Registry to look up the Message Generation application and get a greeting message, which (to begin with) should be “Hello, Bob!”

3. You can see what the Message Generation application is sending back by viewing its logs, using tanzu apps workload tail greeter-messages:

   $ tanzu apps workload tail greeter-messages
   
   greeter-messages-579d67c498-bf6zl[workload] 2023-10-20T17:52:17.001Z  INFO 1 --- [nio-8080-exec-3] messages.MessagesController              : Now saying "Hi" to John

4. To get a different greeting message, you can provide salutation and name parameters, as in [ROUTE]/hello?salutation=Hi&name=John. The Greeter application will send those parameters to the Message Generation application and the resulting greeting will be customized to match.

For more information about the Service Registry and its use in a client application, see the Service Registry documentation.

Building and Deploying on Tanzu Application Service (TAS)

1. Build the two projects from the root (greeting) directory. If using Maven, run:

   $ mvn package

   If using Gradle, run ./gradlew build (OS X, Linux) or gradlew.bat build (Windows).

   $ ./gradlew build

2. Run the deployment script (if you used Maven, scripts/deploy_mvn.sh or scripts/deploy_mvn.bat; if you used Gradle, scripts/deploy_gradle.sh or scripts/deploy_gradle.bat).

   $ ./scripts/deploy_gradle.sh

   The script will create a Service Registry service instance and then push the applications and bind them to the service.

Note	By default, the Application Services Starter for Service Registry causes all application endpoints to be secured by HTTP Basic authentication. For more information or if you wish to disable this, see the documentation. (HTTP Basic authentication is disabled in these sample applications.)

Trying It Out

1. Visit [ROUTE]/hello, where [ROUTE] is the route bound to the Greeter application. The Greeter application will use the Service Registry to look up the Message Generation application and get a greeting message, which (to begin with) should be “Hello, Bob!”

   

2. You can see what the Message Generation application is sending back by viewing its logs. Run cf logs greeter-messages.

   $ cf logs greeter-messages
   Connected, tailing logs for app greeter-messages in org myorg / space development as user...
   
   2015-07-16T13:07:35.86-0500 [App/0]      OUT 2015-07-16 18:07:35.861  INFO 29 ---
                        [o-61612-exec-10] greeter-messages.MessageGenerationApplication
                                                     : Now saying "Hello" to Bob
   2015-07-16T13:07:35.87-0500 [RTR/0]      OUT greeter-messages.wise.com:80 -
                        [16/07/2015:18:07:35 +0000]
                        "GET /greeting?salutation=Hello&name=Bob HTTP/1.1" 200
                        31 "-" "Apache-HttpClient/4.3.6 (java 1.5)" 10.68.204.250:39929
                        x_forwarded_for:"10.68.204.43, 10.68.204.250"
                        vcap_request_id:66b782b6-9953-45b3-52ab-da369ad81f44
                        response_time:0.016146581
                        app_id:bd594ad5-2653-4949-afc6-e5f1ae568259

3. To get a different greeting message, you can provide salutation and name parameters, as in [ROUTE]/hello?salutation=Hi&name=John. The Greeter application will send those parameters to the Message Generation application and the resulting greeting will be customized to match.

   

For more information about the Service Registry and its use in a client application, see the Service Registry documentation.

Building and Deploying on Tanzu Platform (TP)

1. Build the two projects from the root directory with:

   mkdir -p ./build/tanzu
   tanzu build --output-dir ./build/tanzu

2. Deploy both applications together with a EurekaServer:

   tanzu deploy --yes --from-build ./build/tanzu/

3. Eventually delete the applications and the EurekaServer:

   export KUBECONFIG=~/.config/tanzu/kube/config
   kapp delete -y -c -a $(yq .configuration.id <tanzu.yml)