Expose services to consumers through private connectivity

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.

1. A provider implements a resilient application supported by multiple virtual servers spread across multiple zones.
2. 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.
3. A Private Path service references the Private Path NLB and specifies the service endpoint used by consumers.
4. 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 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.

1. Go to Schematics to create a new workspace.
2. In the Specify template step:
   1. Set the repository URL to https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/provider.
   2. Make sure to check Use full repository.
   3. Set the Terraform version to terraform_v1.5.
   4. Click Next.
3. In the Workspace details step:
   1. Set the workspace name to pps-provider.
   2. Select a Resource group and Location where to create the workspace. This won't affect the resources created for the tutorial.
   3. Click Next
4. Click Create.

In the workspace Settings, under Variables:

1. Locate the existing_ssh_key_name variable.
   1. Use the menu (︙) to Edit its value.
   2. Set the value to the name of the SSH key you created in the previous section or to an existing SSH key.
   3. Save.
2. Optionally, you can also adjust the values of other variables like region, basename.

Finally create the resources:

1. Click Apply plan.
2. 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.

1. Navigate to Virtual Private Clouds, Subnets and Virtual server instances to review the provisioned resources.
2. Find the Private Path NLB under Load balancers.
3. In Private Path services, select the created Private Path service.
4. 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 custom basename during the workspace configuration. This is the endpoint used by consumers to interact with your application.
5. 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.

1. Go to Schematics to create a new workspace.
2. In the Specify template step:
   1. Set the repository URL to https://github.com/IBM-Cloud/vpc-tutorials/tree/master/vpc-pps-basics/consumer.
   2. Make sure to check Use full repository.
   3. Set the Terraform version to terraform_v1.5.
   4. Click Next.
3. In the Workspace details step:
   1. Set the workspace name to pps-consumer.
   2. Select a Resource group and Location where to create the workspace. This won't affect the resources created for the tutorial.
   3. Click Next
4. Click Create.

In the workspace Settings, in the Variables section:

1. Locate the existing_ssh_key_name variable.
   1. Use the menu (︙) to Edit its value.
   2. Set the value to the name of the SSH key used for this tutorial.
   3. Save.
2. Locate the provider_crn variable
   1. Edit its value.
   2. Set the value to the Private Path service CRN obtained earlier.
   3. Save.
3. Optionally, you can also adjust the values of other variables like region, basename. region should match the value set in the pps-provider workspace.

Finally create the resources:

1. Click Apply plan.
2. 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.

1. Navigate to Virtual server instances to review the provisioned instances.
2. 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,

1. Go to the Private Path services list.

2. Notice the Private Path service you created has pending connection requests to be reviewed.

3. Select the Private Path service.

4. In the Connection requests table, locate the request from the consumer.

5. 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.

6. Click Permit.

Test connectivity from consumer to provider

Acting as the consumer again,

1. Go to Virtual private endpoint gateways and notice that the endpoint gateway has moved to Stable.

2. Make note of the Service endpoint. It should be vpc-pps.example.com unless you specified a custom basename during the workspace configuration.

3. 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 or vpc-pps-consumer-vsi-us-south-2.

4. Open an SSH connection to one of the instance.

   ssh root@<floating-ip>
   

5. 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.

6. 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:

1. Go to Schematics

   1. Select the pps-consumer workspace.
   2. From the Actions..., select Destroy resources.
   3. Type pps-consumer and click Destroy.
   4. Wait for Schematics to complete the job.
   5. Once completed, select Delete workspace from the Actions... menu.
   6. Type pps-consumer and click Delete.

2. 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.