Multiple workloads can be deployed that have a dependency on one another. By default, workloads are hardened and don't allow any access. Using the firewall configuration, rules can be set to allow the minimum allowed access. This quick start will focus on allowing internal service-to-service calls between workloads.
This quick start will demonstrate how to:
A sample image for this quick start is available from Docker Hub that will display the following:
url
query string parameter)copycplnquickstarts/service-to-service-quick-start:1.0
When creating the workload:
Serves Traffic
switch on and set the port to 8080
.Options
step, set the Timeout Seconds
to 30.Firewall
step, turn the All Inbound Requests Allowed
switch on so you can call the application from the Internet.Workload Health
shows Healthy
, click on the Open
link next to the Global Endpoint
.
A new browser tab will open and display the following:copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAMEResponse from URL:No URL in querystring
The source code for the sample application can be downloaded from here.
Click on Workloads
in the left menu and click the New
button.
Create another workload just like the workload in step 1 (but using a different name) with the same image. Remember to set the
serves traffic switch, set the port to 8080, set the timeout to 30, and set the All Inbound Requests Allowed
switch to on in the firewall setting.
After creating the new workload, once the Workload Health
shows Healthy
, click on the Open
link next to the Global Endpoint
.
A new browser tab will open and display the output similar to step 1, but showing the new workload name.
The sample application can call another URL endpoint by using the url
query string parameter.
From the new browser tab, test the call to the first service call by browsing to (since the workloads are in the same GVC, the
GVC_ALIAS will be the same from the response in step 1):
copyhttps://GLOBAL_ENDPOINT_SECOND_WORKLOAD/?url=http://FIRST_WORKLOAD_NAME.GVC_NAME.cpln.local
Since we haven't changed the internal firewall rules, the response from the sample application will display the following:
copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAMEResponse from URL:Request failed with status code 503
In this step, we will grant inbound access to the first workload from any workload in the same GVC.
Workloads
and select the workload created in step 1. The summary page will be displayed.Firewall Config
.Inbound Allow Type
dropdown under the Internal
section, and select Same GVC
.
Click Save
. The updated firewall rule will be active within a minute and a new deployment of the workload will be queued. Please
wait a few minutes before going to the next step.In this step, we will call the first service from the second service.
copyHello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/SECOND_WORKLOAD_NAMEResponse from URL:Hello! Version: 1.0GVC Name: /org/ORG_NAME/gvc/GVC_NAMEGVC Alias: GVC_ALIASWorkload Name: /org/ORG_NAME/gvc/GVC_NAME/workload/FIRST_WORKLOAD_NAMEResponse from URL:No URL in querystring
In step 3, the internal firewall rule for the first workload was set to allow access from any workload in the same GVC. We could also set the rule to allow access from any workloads within the org, crossing GVC boundaries.
Another available setting is to specify exactly which workloads can access the workload. The workloads shown are selectable and only from the same GVC. You cannot allow workloads from other GVCs using this setting. There is also a switch that can be set to allow a workload to access itself using the Service Endpoint Syntax.
Feel free to test out the other settings using the sample application to verify that the internal firewall rules are enforced. Remember that any changes to the firewall will be updated within a minute and a deployment of the workload will be queued. Please allow a few minutes between tests.
Using a sample application that can call endpoints from within a workload, we were able to demonstrate that a workload is locked down by default and will not accept any requests internally. By setting the internal firewall rule, workloads can allow different types of internal traffic from other workloads. Depending on the use case, multiple workloads can be deployed within your org and call each other internally without having to access the public Internet.