Access the Commerce Environment

Each Self Managed Commerce environment that you deploy consists of a set of applications and components. Some of those applications are exposed via Kubernetes ingresses, with access controlled via allow-lists. Some components are not exposed and can only be reached through private network connections.

Applications and Application URLs

The Self Managed Commerce application and endpoint URLs can be found in a few locations.

deploy-or-delete-commerce-stack console output

The Jenkins job named deploy-or-delete-commerce-stack is used to deploy, configure and manage Self Managed Commerce environments in CloudOps for Kubernetes. The job prints the application URLs in the console. After deploying a new Self Managed Commerce environment, you can make note of the URLs shown in the job's console output.

Information Page

The Information Page for a given Self Managed Commerce environment includes links to the applications as well as additional information about the environment. It is an optional application that you can include when configuring and deploying a Self Managed Commerce environment. For more information, see Create an Information Page.

warning

The Information Page reveals details that should only be exposed to users with a legitimate business need. We do not recommend including the Information Page with production Self Managed Commerce environments.

Application URL Structure

The Self Managed Commerce environments deployed using CloudOps for Kubernetes use path-based routing to access the application services. The hostname portion of the URL identifies the Self Managed Commerce environment and the path portion of the URL identifies the application. Each Self Managed Commerce environment has a unique hostname that is created by combining values provided when deploying that environment. Specifically, the values of kubernetesNickname, clusterName, and dnsZoneName parameters are combined to create the fully qualified name for that environment such as:

<kubernetesNickname>.commerce<clusterName>.<dnsZoneName>

For example, if the parameters are set as kubernetesNickname = dev1, clusterName = hub and dnsZoneName = epcloud.mycompany.com, then the resulting hostname will be dev1.commercehub.epcloud.mycompany.com. The Commerce application URLs will be:

Application	Example URL
Information Page	dev1.commercehub.epcloud.mycompany.com
Cortex	dev1.commercehub.epcloud.mycompany.com/cortex
Cortex Studio	dev1.commercehub.epcloud.mycompany.com/studio
Commerce Manager	dev1.commercehub.epcloud.mycompany.com/cm/
Integration Server	dev1.commercehub.epcloud.mycompany.com/integration

tip

The default login credentials for Commerce Manager can be found in the Self Managed Commerce documentation, in Starting Commerce Manager. These default credentials are defined in the ep-commerce source code and loaded into the database by the data-population process.

Controlling access with Allow-Lists

The Kubernetes ingress controller uses allow-lists (white lists) to determine whether a request to an application URL should be permitted.

note

When your public IP (egress IP) is not in the appropriate allow-list, you will receive an HTTP 403 error while trying to access a valid application URL.

The allow lists for the Commerce applications are specified in the deploy-or-delete-commerce-stack job as parameters named cortexAllowedCIDRs, integrationAllowedCIDRs studioAllowedCIDRs, and infoAllowedCIDRs. The recommended process to update an allow list is to rerun the deploy-or-delete-commerce-stack job with updated values for those parameters.

Database Connectivity and Credentials

There are several different ways of creating or providing the Self Managed Commerce database, as described in Create a Database Server. All of the methods save the database connectivity information in a Kubernetes secret, in the Kubernetes namepsace associated with the Self Managed Commerce environment. The application containers read the values from that secret at start-up time. This is how the containers know which database to connect to, how to find it, and how to authenticate to it.

About the database secret

Each Self Managed Commerce environment has its own database secret named like ep-<kubernetesNickname>-mysql-secret (for all database types, including PostgreSQL) where <kubernetesNickname> is the Kubernetes namespace associated with the Self Managed Commerce environment in question. The value of the Kubernetes namespace was specified as parameter kubernetesNickname when you set up the Self Managed Commerce environment.

Keys stored in the secret include: EP_DB_NAME EP_DB_SCHEMA_NAME EP_DB_HOSTNAME EP_DB_USER EP_DB_PASS EP_DB_ROOT_USER EP_DB_ROOT_PASS EP_DB_URL EP_DB_JDBC_DRIVER_CLASS EP_DB_CONNECTION_PARAMS.

Extracting the values from the secret

The below information explains one way to obtain the database details for a given environment by inspecting the Kubernetes secret. This approach uses the kubectl command and requires credentials with access to the Kubernetes cluster, namespace and secret.

1. Ensure that you install the kubectl tool and authenticate to the Kubernetes cluster. See Log On To The Kubernetes Cluster.

2. Identify the Kubernetes namespace associated with the Self Managed Commerce environment in question. This was specified as parameter kubernetesNickname when setting up the environment.

   note

   The examples below will use an example namespace named test1. Ensure you substitute the correct namespace for your Self Managed Commerce environment.

3. Confirm the secret name by running the below kubectl command.

   # Ensure you replace `test1` with the correct namespace for your Self Managed Commerce environment.
   kubectl get secrets -n test1
   

   The output should look similar to the below and should confirm the name of the secret.

   NAME                    TYPE     DATA   AGE
   ep-test1-mysql-secret   Opaque   17     5m7s
   

4. Extract data from the secret. Ensure you replace both occurrences of test1 with the correct namespace for your Self Managed Commerce environment.

   # Extract the database name
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_NAME | base64decode}}" && echo
   
   # Extract the database schema name
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_SCHEMA_NAME | base64decode}}" && echo
   
   # Extract the database instance host name
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_HOSTNAME | base64decode}}" && echo
   
   # Extract the database user's username
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_USER | base64decode}}" && echo
   
   # Extract the database user's password
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_PASS | base64decode}}" && echo
   
   # Extract the database root user's username
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_ROOT_USER | base64decode}}" && echo
   
   # Extract the database root user's password
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_ROOT_PASS | base64decode}}" && echo
   
   # Extract the database JDBC URL
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_URL | base64decode}}" && echo
   
   # Extract the database JDBC driver class
   kubectl get secret ep-test1-mysql-secret -n test1 -o go-template="{{.data.EP_DB_JDBC_DRIVER_CLASS | base64decode}}" && echo
   

Connecting to the Database

For security reasons, the database instances and servers created by CloudOps for Kubernetes jobs are not exposed to the Internet. Therefore, you cannot connect directly to these databases from outside of the AWS VPC.

Containerized MySQL databases

One option to connect to a containerized database is to use kubectl to get a shell prompt on the container itself.

1. Confirm the pod name. Run the below command and identify the pod for your database. Ensure you replace test1 with the correct namespace for your Self Managed Commerce environment.

   kubectl get pods -n test1
   

2. Use the kubectl exec command to get an interactive terminal on the container. Ensure you replace test1 with the correct namespace for your Self Managed Commerce environment, and the pod name with the one you found in the previous step.

   kubectl exec -n test1 -it ep-mysql-deployment-8f8b7f585-mv6v4 -- bash
   

3. Interact with MySQL and the database using the mysql command line tool. Use the instructions in the section Extracting the values from the secret above to obtain the database name and credentials. Refer to the MySQL product documentation for information about using the mysql command line tool.

RDS and RDS Aurora Databases

Amazon RDS and RDS Aurora database instances created by CloudOps for Kubernetes are configured to use only private subnets. To connect to those database instances from outside of the VPC, you will need to configure connectivity with the aid of your network engineering team. Options to obtain connectivity include, but are not limited to, VPC peering with your existing corporate AWS VPCs, configuring IPSec VPN tunnels, and deploying a bastion server or jump box in the VPC.

note

CloudOps for Kubernetes includes support for VPC peering as part of the setup process. Refer to the parameter named TF_VAR_aws_remote_peering_vpc_id in the docker-compose.yml file in the cloud-ops-kubernetes Git repository.