Skip to main content
Version: 3.7.x

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:

ApplicationExample URL
Information Pagedev1.commercehub.epcloud.mycompany.com
Cortexdev1.commercehub.epcloud.mycompany.com/cortex
Cortex Studiodev1.commercehub.epcloud.mycompany.com/studio
Commerce Managerdev1.commercehub.epcloud.mycompany.com/cm/
Integration Serverdev1.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 Database Server Options. 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.