Provision Supporting Infrastructure · CloudOps for Kubernetes

Several pieces of infrastructure need to be provisioned before Account Management can be deployed. This includes a MySQL database and an ActiveMQ service.

Account Management can use the same ActiveMQ service provisioned for Self Managed Commerce. If you deploy Self Managed Commerce outside of the Kubernetes cluster you must run the Jenkins register-external-activemq-service job. This job ensures that the Account Management containers have access to a Kubernetes Secret that contains access information about the ActiveMQ service.

Account Management can also use the database instance provisioned for Self Managed Commerce. If you deploy Self Managed Commerce outside of the Kubernetes cluster you must run the Jenkins create-or-delete-database-and-user-in-external-database-instance job. This job creates a schema and user in the external database instance. It ensures that the Account Management containers can access a Kubernetes Secret containing access information about the schema.

Provision a MySQL Database

There are two options for provisioning a MySQL database:

Review Option 1 to create a MySQL container for Account Management.

Review Option 2 to register an external database instance for Account Management.

Option 1: Create a MySQL container for Account Management

Run the Jenkins job create-or-delete-account-management-mysql-container. This job takes several parameters. For more information, see the Jenkins job parameters section.

This job creates a MySQL Pod in the Kubernetes cluster that has a schema and user for the Account Management stack. This job must be run with the same Kubernetes nickname that is used when deploying the Account Management stack. This is to ensure that the Account Management stack can read the Kubernetes Secret containing access information about the MySQL service.

Jenkins job parameters

The following parameters are available in the Jenkins job create-or-delete-account-management-mysql-container:

`plan_mode`

If plan_mode is set, the Jenkins build plans the Terraform changes. The job pauses until you confirm that you want to proceed with the changes. You can run the job in plan mode when both applying and destroying resources.

`destroy_mode`

If destroy_mode is set, Terraform runs in destroy mode. Destroy mode also deletes the Terraform workspace and Kubernetes namespace if these are empty.

`TF_VAR_kubernetes_nickname`

The namespace in the Kubernetes cluster where to deploy the MySQL container.

Ensure that this nickname matches the nickname that is used when deploying the Account Management stack. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cluster_name`

The name of the Kubernetes cluster where to deploy the MySQL container.

Ensure this cluster matches the cluster where the Account Management stack will be deployed. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cloudops_for_kubernetes_branch`

The CloudOps for Kubernetes branch to use for the job to clone the Jenkinsfile and Terraform configuration. This defines how to deploy the infrastructure.

Option 2: Register an external Mysql database instance

If there is a database instance available, run the Jenkins job create-or-delete-database-and-user-in-external-database-instance. This job must be run with the same Kubernetes nickname that will be used when deploying the Account Management stack. This creates a Kubernetes secret from the external database instance and a schema and user for the Account Management stack to use. This job takes several parameters. For more information, see the Jenkins job parameters section.

Jenkins job parameters

The following parameters are available in the Jenkins job create-or-delete-database-and-user-in-external-database-instance:

`deleteDatabase`

When checked, this deletes the database instead of creating it. Must be run with values in TF_VAR_database_name, TF_VAR_database_username, and TF_VAR_database_password.

`TF_VAR_use_existing_schema`

When checked, if the external database instance has an existing schema, the job will not create a new schema and user. The job instead uses the values provided in TF_VAR_database_name, TF_VAR_database_username, and TF_VAR_database_password.

`TF_VAR_database_name`

The name of the schema in the external database. For an Account Management deployment TF_VAR_use_existing_schema should be false. The job creates a schema with this name. In this case, it can also be left blank and the job generates a schema name.

If TF_VAR_use_existing_schema is true, the schema name provided must already exist and have valid user credentials. These values are used in this job instead of creating new ones.

`TF_VAR_root_username`

The root username of the external database instance. This can be found in the Kubernetes secret created by the create-or-delete-mysql-server job or in the CloudOps for AWS Consul config store.

`TF_VAR_root_password`

The root password of the external database instance. This can be found in the Kubernetes secret created by the create-or-delete-mysql-server job or in the CloudOps for AWS Consul config store.

`TF_VAR_database_hostname`

The name of the external database instance. Use the serverName parameter if created by the job create-or-delete-mysql-server or the DB cluster id of an RDS instance if created by a CloudOps for AWS Author and Live environment.

`TF_VAR_database_server_url`

The hostname of the server to connect to. Find the hostname in the Amazon RDS web console. The format is similar to sample-database.cluster-asdf.us-west-2.rds.amazonaws.com.

`TF_VAR_database_username`

The username of the MySQL database created by this job. The username is automatically created if there is no value given or the given username does not exist in the database instance. Do not use the same value as TF_VAR_root_username.

`TF_VAR_database_password`

The password of the MySQL database user created by this job. The password is automatically created if the given username does not exist in the database instance. Do not use the same value as TF_VAR_root_password.

`TF_VAR_kubernetes_nickname`

The namespace in the Kubernetes cluster where to deploy the MySQL container.

Ensure that this nickname is used when deploying the Account Management stack. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cluster_name`

The name of the Kubernetes cluster where to deploy the MySQL container.

Ensure this cluster matches the cluster where you will deploy the Account Management stack. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cloudops_for_kubernetes_branch`

The CloudOps for Kubernetes branch to use for the job to clone the Jenkinsfile and Terraform configuration. This defines how to deploy the infrastructure.

Provision an ActiveMQ Service

There are two options for provisioning an ActiveMQ service:

Review Option 1 if Self Managed Commerce and Account Management are deployed in the same Kubernetes cluster.

Review Option 2 if Self Managed Commerce will not be deployed in the same Kubernetes cluster.

Option 1: Provision service inside the Kubernetes cluster

Use this option when you are deploying Self Managed Commerce and Account Management in the same Kubernetes cluster.

Ensure that the ActiveMQ service and Account Management are deployed with the same Kubernetes nickname parameter.

To create an ActiveMQ container using CloudOps for Kubernetes, run the create-or-delete-account-management-activemq-container job in Jenkins. It requires the following parameters:

`deleteContainer`

When this parameter is selected, the specified ActiveMQ service and resources, including the container, will be deleted instead of created.

`cloudOpsForKubernetesRepoURL`

The URL to your hosted copy of the cloudops-for-kubernetes Git repository.

`cloudOpsForKubernetesBranch`

The branch of the cloudops-for-kubernetes Git repository to use during the deployment.

`kubernetesNickname`

The Kubernetes namespace into which the ActiveMQ service is to be deployed. This nickname must match the nickname of the Account Management stack deployment.

`activeMQAdminConsoleAllowedCIDR`

The network CIDR allowed to access the ActiveMQ admin console.

`allowOpenAccess`

Verification that you are deploying the Elastic Path Account Management ActiveMQ service with the Jenkins job parameter activeMQAdminConsoleAllowedCIDR set with the CIDR 0.0.0.0/0. Set this parameter to true to acknowledge that you allow the Elastic Path Account Management ActiveMQ admin console to be accessible by the open internet.

`imageTag`

The tag of the ActiveMQ Docker image to be deployed.

`clusterName`

The name of the kubernetes cluster to deploy the ActiveMQ container into.

`dnsZoneName`

The same domainName that was originally set in the docker-compose.yml file used during bootstrap. You can override the DNS zone name if you have manually configured the DNS settings for the domain.

The job creates a container within the given namespace of the Kubernetes cluster.

The ActiveMQ Admin Console has a different URL format from the Account Management URLs.

For example, if clusterName = jDoeCluster, dnsZoneName = epcloud.mycompany.com and kubernetesNickname = dev. The ActiveMQ Admin Console URL will be:

am-activemqdev.centraljDoeCluster.epcloud.mycompany.com/admin

Option 2: Register service outside the Kubernetes cluster

Use this option when you are deploying Self Managed Commerce outside of the Kubernetes cluster Account Management is deployed to. Register the ActiveMQ endpoint created for the Self Managed Commerce deployment before you can complete the Account Management deployment.

note

This workflow assumes the ActiveMQ endpoint is accessible from within the Kubernetes cluster. Additional work may be necessary to allow access to the endpoint from within the cluster.

To register an external ActiveMQ service for Account Management, run the Jenkins job register-external-activemq-service. This job takes several parameters, described below.

Jenkins job parameters

The following parameters are available in the Jenkins job register-external-activemq-service:

`plan_mode`

`destroy_mode`

If destroy_mode is set, Terraform runs in destroy mode. Destroy mode also deletes the Terraform workspace and Kubernetes namespace if these are empty.

`TF_VAR_jms_url`

The JMS URL of the ActiveMQ service.

Ensure the endpoint is accessible from within the Kubernetes cluster. You can test this by attempting to connect to the endpoint from a container inside the cluster.

`TF_VAR_kubernetes_nickname`

The namespace in the Kubernetes cluster to create the Kubernetes Secret in.

Ensure that this nickname is used when deploying the Account Management stack. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cluster_name`

The name of the Kubernetes cluster to create the Kubernetes Secret in.

Ensure this cluster matches the cluster where the Account Management stack will be deployed. This job creates a Kubernetes Secret that the Account Management stack will need access to.

`cloudops_for_kubernetes_branch`

The CloudOps for Kubernetes branch to use for the job to clone the Jenkinsfile and Terraform configuration. This defines how to deploy the infrastructure.