Expose services to consumers through private connectivity
The beta release of IBM Cloud Private Path services is only available to allowlisted users. Contact your IBM Support representative if you are interested in getting early access to this beta offering.
This tutorial may incur costs. Use the Cost Estimator to generate a cost estimate based on your projected usage.
This tutorial walks you through the steps to set up a Private Path service between a provider and a set of consumers. With Private Path service, consumers access the application or service implemented by the provider through the IBM backbone without traversing the internet.
Objectives
- Understand the basics of Private Path service.
- Deploy an application in one account without exposing any public endpoints.
- Expose the application with Private Path service.
- Access the application from a consumer client through private connectivity only.
- A provider implements a resilient application supported by multiple virtual servers spread across multiple zones.
- The provider creates a Private Path network load balancer (NLB) configured with backend pools pointing to the virtual servers, distributing the load among the servers with the round-robin algorithm.
- A Private Path service references the Private Path NLB and specifies the service endpoint used by consumers.
- Consumers access the provider application by going through virtual private endpoint gateways. All traffic remains private to IBM Cloud.
Before you begin
This tutorial requires:
- One IBM Cloud billable account to host both the provider and the consumer resources.
- A VPC SSH key to connect to the virtual server instances provisioned in the tutorial.
Create a VPC SSH key
When provisioning virtual server instances, an SSH key is injected into the instances so that you can later connect to the servers. This SSH key must be in the same region where you are going to deploy the tutorial resources.
- If you don't have an SSH key configured in IBM Cloud, refer to these instructions for creating a key for VPC.
- Make note of the name you used for the SSH key.
Create the provider resources and application
In this tutorial, you first act as a provider and implement an application. In a second phase, you take the role of the consumer and call the application. The application is a simple nginx
web server.
- Go to Schematics to create a new workspace.
- In the Specify template step:
- Set the repository URL to
https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/provider
. - Make sure to check Use full repository.
- Set the Terraform version to
terraform_v1.5
. - Click Next.
- Set the repository URL to
- In the Workspace details step:
- Set the workspace name to
pps-provider
. - Select a Resource group and Location where to create the workspace. This won't affect the resources created for the tutorial.
- Click Next
- Set the workspace name to
- Click Create.
In the workspace Settings, under Variables:
- Locate the
existing_ssh_key_name
variable.- Use the menu (︙) to Edit its value.
- Set the value to the name of the SSH key you created in the previous section or to an existing SSH key.
- Save.
- Optionally, you can also adjust the values of other variables like
region
,basename
.
Finally create the resources:
- Click Apply plan.
- Wait for Schematics to complete the provisioning of the resources.
Review the provider resources and application
Running Schematics for the provider creates the following resources:
- one virtual private cloud (VPC),
- three subnets, one for each zone,
- a minimum of one virtual server instance in each subnet,
- a Private Path NLB configured with a backend pool including all the virtual server instances,
- and a Private Path service.
- Navigate to Virtual Private Clouds, Subnets and Virtual server instances to review the provisioned resources.
- Find the Private Path NLB under Load balancers.
- In Private Path services, select the created Private Path service.
- In the Private Path service details, notice the Service endpoint set to
vpc-pps.example.com
. Note that it might be different if you specified a custombasename
during the workspace configuration. This is the endpoint used by consumers to interact with your application. - Make note of the CRN as you need to pass this information to consumers. Consumers use the CRN to identify your application when creating virtual private endpoint gateways.
Your Private Path service is almost ready to be shared with consumers. But before publishing the Private Path service, it is recommended to test that it is working as expected.
Create the consumer resources
To verify that the Private Path service is correctly set up, you are going to deploy virtual servers to access the application, just like any consumer of a Private Path service would do.
Until a Private Path service gets published, it can only be accessed within the same account where it is created. It offers a good opportunity to test the service before sharing it with others. This is the reason why, at this stage, the consumer side of this tutorial is provisioned in the same account as the provider application.
- Go to Schematics to create a new workspace.
- In the Specify template step:
- Set the repository URL to
https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/consumer
. - Make sure to check Use full repository.
- Set the Terraform version to
terraform_v1.5
. - Click Next.
- Set the repository URL to
- In the Workspace details step:
- Set the workspace name to
pps-consumer
. - Select a Resource group and Location where to create the workspace. This won't affect the resources created for the tutorial.
- Click Next
- Set the workspace name to
- Click Create.
In the workspace Settings, in the Variables section:
- Locate the
existing_ssh_key_name
variable.- Use the menu (︙) to Edit its value.
- Set the value to the name of the SSH key used for this tutorial.
- Save.
- Locate the
provider_crn
variable- Edit its value.
- Set the value to the Private Path service CRN obtained earlier.
- Save.
- Optionally, you can also adjust the values of other variables like
region
,basename
.region
should match the value set in thepps-provider
workspace.
Finally create the resources:
- Click Apply plan.
- Wait for Schematics to complete the provisioning of the resources.
Review the consumer resources and application
Running Schematics for the consumer creates the following resources:
- one virtual private cloud (VPC),
- two subnets,
- one virtual server instance in each subnet,
- one virtual private endpoint gateway configured with the Private Path service CRN and with one IP address in each subnet.
- Navigate to Virtual server instances to review the provisioned instances.
- Go to Virtual private endpoint gateways and notice that the endpoint gateway is marked as Pending.
At this stage, the consumer is not yet able to access the provider application. It's waiting on the connection request to the Private Path service to be reviewed and permitted.
Approve the consumer request
Acting as the provider of the application,
-
Go to the Private Path services list.
-
Notice the Private Path service you created has pending connection requests to be reviewed.
-
Select the Private Path service.
-
In the Connection requests table, locate the request from the consumer.
-
Use the menu (︙) to Permit the connection.
The Permit connection request dialog gives you an option to create a policy to automatically permit all requests from the same account ID. Leave it unchecked for now. In the future this can speed up the process of consumers requesting connections from this account.
-
Click Permit.
Test connectivity from consumer to provider
Acting as the consumer again,
-
Go to Virtual private endpoint gateways and notice that the endpoint gateway has moved to Stable.
-
Make note of the Service endpoint. It should be
vpc-pps.example.com
unless you specified a custombasename
during the workspace configuration. -
Navigate to Virtual server instances and find the floating IP assigned to one of the consumer instances. The instances are named like
vpc-pps-consumer-vsi-us-south-1
orvpc-pps-consumer-vsi-us-south-2
. -
Open an SSH connection to one of the instance.
ssh root@<floating-ip>
-
Access the provider application by calling the service endpoint.
curl http://vpc-pps.example.com
The output should look like:
Hello world from vpc-pps-provider-vsi-us-south-2
It may takes a few minutes for the domain name to resolve correctly to the virtual server instances.
-
Repeat the
curl
command several times. Notice how it shows a different output as it goes through all the virtual server instances attached to the backend pool of the Private Path NLB.
Congratulations, your Private Path service is working as expected and is ready to be published for others to consume.
Expand the tutorial
This tutorial focuses on the basics of Private Path service with a provider application in one VPC and a consumer in another VPC, all within the same account:
- The next step is to publish the Private Path service. Once published, clients in other IBM Cloud accounts can make a connection request to access the application.
- Communicating connection information to consumers, reviewing connection requests and streamlining the process with account policies are also part of the successful onboarding of consumers.
Remove resources
To remove the resources created for this tutorial:
-
Go to Schematics
- Select the
pps-consumer
workspace. - From the Actions..., select Destroy resources.
- Type
pps-consumer
and click Destroy. - Wait for Schematics to complete the job.
- Once completed, select Delete workspace from the Actions... menu.
- Type
pps-consumer
and click Delete.
- Select the
-
Repeat the same steps with the
pps-provider
workspace.You may need to retry the Destroy resources after a few minutes if the workspace deletion failed because the resource group could not be deleted.
Depending on the resource it might not be deleted immediately, but retained (by default for 7 days). You can reclaim the resource by deleting it permanently or restore it within the retention period. See this document on how to use resource reclamation.