Protobuf uses Guava 30.1.1, so I upgrade it at the same time. It also caused an update to rules_jvm_external and reworking the Bazel build. Protobuf no longer requires bind() so they were dropped. Although Protobuf's protobuf_deps() brings in rules_jvm_external, and so we don't need to define it ourselves, it seems better to define it directly and not depend on transitive deps since we use it directly. Protobuf now has support for maven_install() by exposing PROTOBUF_MAVEN_ARTIFACTS, which required reorganizing the WORKSPACE to use maven_install() after loading protobuf. Protobuf still doesn't define target overrides for itself so we still maintain those. When reorganizing the WORKSPACE I noticed http_archive should ideally be above io_grpc_grpc_java as most users will need it there, so I fixed that since there were lots of other load()-reordering already. |
||
|---|---|---|
| .. | ||
| src/main | ||
| README.md | ||
| build.gradle | ||
| settings.gradle | ||
README.md
gRPC XDS Example
The XDS example consists of a Hello World client and a Hello World server capable of being configured with the XDS management protocol. Out-of-the-box the client behaves the same the hello-world version and the server behaves similar to the example-hostname but with a required dependency on xDS.
XDS support is incomplete and experimental, with limited compatibility. It will be very hard to produce a working environment just by this example. Please refer to documentation specific for your XDS management server and environment.
Build the example
Build the XDS hello-world example client & server. From the grpc-java/examples/examples-xds
directory:
$ ../gradlew installDist
This creates the scripts build/install/example-xds/bin/xds-hello-world-client and
build/install/example-xds/bin/xds-hello-world-server.
Run the example without using XDS Credentials
To use XDS, you should first deploy the XDS management server in your deployment environment
and know its name. You need to set the GRPC_XDS_BOOTSTRAP environment variable (preferred) or if that is not set then
the io.grpc.xds.bootstrap java system property to point to the gRPC XDS bootstrap file (see
gRFC A27 for the
bootstrap format). This is needed by both build/install/example-xds/bin/xds-hello-world-client
and build/install/example-xds/bin/xds-hello-world-server.
- To start the XDS-enabled example server on its default port of 50051, run:
$ export GRPC_XDS_BOOTSTRAP=/path/to/bootstrap.json
$ ./build/install/example-xds/bin/xds-hello-world-server
- In a different terminal window, run the XDS-enabled example client:
$ export GRPC_XDS_BOOTSTRAP=/path/to/bootstrap.json
$ ./build/install/example-xds/bin/xds-hello-world-client "xds world" xds:///yourServersName
The first command line argument (xds world) is the name you wish to include in
the greeting request to the server and the second argument
(xds:///yourServersName) is the target to connect to using the xds: target
scheme.
Run the example with xDS Credentials
The above example used plaintext (insecure) credentials as explicitly provided by the client and server
code. We will now demonstrate how the code can authorize use of xDS provided credentials by using
XdsChannelCredentials on the client side and using XdsServerCredentials on the server side.
This code is enabled by providing an additional command line argument.
- On the server side, add
--xds-credson the command line to authorize use of xDS security:
$ export GRPC_XDS_BOOTSTRAP=/path/to/bootstrap.json
$ ./build/install/example-xds/bin/xds-hello-world-server --xds-creds
- Similarly, add
--xds-credson the command line when you run the xDS client:
$ export GRPC_XDS_BOOTSTRAP=/path/to/bootstrap.json
$ ./build/install/example-xds/bin/xds-hello-world-client --xds-creds "xds world" xds:///yourServersName
In this case, if the xDS management server is configured to provide mTLS credentials (for example) to the client and server, then they will use these credentials to create an mTLS channel to authenticate and encrypt.