Overview
This topic discusses options available to deploy a Self Managed Commerce environment using CloudOps for Kubernetes. It covers the prequisites and planning required, and describes the steps that need to be completed.
About a Self Managed Commerce Environment
Each Self Managed Commerce environment that you deploy using CloudOps for Kubernetes is deployed into its own Kubernetes namespace, and consists of the following components:
- An Apache ActiveMQ messaging service, a service set up as a Kubernetes pod.
- A compatible database deployed either as a Kubernetes Pod or using a supported cloud service.
- Kubernetes secrets; a set of configuration details required by the Self Managed Commerce services.
- The Self Managed Commerce stack: a set of containerized Self Managed Commerce application services, each deployed as a Kubernetes pod.
For more information about the services and architecture, see the Elastic Path architecture overview documentation.
note
You can deploy multiple Self Managed Commerce environments, such as separate authoring and live environments, in the same Kubernetes cluster. Select a unique value of kubernetesNickname for each Self Managed Commerce environment and ensure that the Apache ActiveMQ service, MySQL service, data population, and Self Managed Commerce stack deployment steps are all completed using that value of kubernetesNickname.
Before You Begin
Review the Introduction and Project Overview sections to obtain an overview of the CloudOps for Kubernetes solution.
Ensure that you complete the following tasks before proceeding to deploy a Self Managed Commerce environment using CloudOps for Kubernetes:
Initial Setup of CloudOps for Kubernetes
Complete the CloudOps for Kubernetes initial setup process and post-bootstrap tasks. For more information, see the Initial Setup documentation.
Building Elastic Path Container Images
Self Managed Commerce environments are deployed using container images built by provided Jenkins jobs. Those container images must exist before you can deploy a Self Managed Commerce environment.
For more information about building the Elastic Path deployment package and container images, see Overview of Self Managed Commerce Builds.
Options for Deploying Self Managed Commerce Environments
CloudOps for Kubernetes provides several ways to deploy a Self Managed Commerce environment.
Convenience Jobs
Several convenience jobs are available that can simplify the process of building Self Managed Commerce artifacts and deploying Self Managed Commerce environments. These are suitable for short-lived or development environments, and for specific use cases.
The commerce-test-and-deploy Jenkins Job
Use the commerce-test-and-deploy Jenkins job to build the Self Managed Commerce deployment package and container images, and use those to deploy or update a full Self Managed Commerce environment suitable for development. For more information, see the Self Managed Commerce CI Pipelines documentation.
The multi-purpose-commerce-tool Jenkins Job
Use the multi-purpose-commerce-tool Jenkins job to build the Self Managed Commerce deployment package and container images, and use those to deploy or update a full Self Managed Commerce environment. This job exposes many options and provides a lot of flexibility regarding what you want to do and how you want it done. For more information, see the Multi-purpose Commerce Tool documentation.
The commerce-branch-validation Jenkins Job
Use the commerce-branch-validation Jenkins job to build the Self Managed Commerce deployment package and container images, and use those to temporarily deploy a Self Managed Commerce environment while automated tests are run against it. For more information, see the Self Managed Commerce CI Pipelines documentation.
With Full Control
In general, preparing to deploy long-lived Self Managed Commerce environments, epecially those intended for production use, requires additional planning, consideration and control. See the sections below for additional information.
Planning
There are many options available when deploying a Self Managed Commerce environment, and there are important choices you must make before starting the process.
Questions to consider when you plan a deployment include:
- What is an appropriate nickname for the environment?
- Choose a nickname that is meaningful and relevant to the environment’s purpose.
- The nickname is set in the
kubernetesNicknameJenkins parameters and defines the Kubernetes namespace used by the environment and a portion of the DNS domain name used to access the environment. - The nickname must be lower-case and alphanumeric to be compatible with Terraform, Kubernetes workspace, and DNS domain name requirements. For example: dev1, test123, staginglive, productionlive, and so on.
- Should the environment use a containerized database or does it require an AWS RDS or RDS Aurora database? The containerized database services are deployed in the Kubernetes cluster, and their data can be lost when the container is replaced. The AWS databases are high-availability databases with managed backups but have a higher infrastructure cost.
- What hostnames will you use to expose the Self Managed Commerce services? Do you need to prepare a new TLS / SSL certificate to secure the services?
- Which changesets should be populated in the Self Managed Commerce database and which configuration values should be used by the Self Managed Commerce services? This requires identifying the proper Self Managed Commerce environment directory to specify during data-population and stack deployment.
- Will the environment be an authoring environment with a corresponding live environment? An authoring environment is where data changesets are created and validated, after which the changesets are published or synchronized to the live environment.
- Should the Wiremock (
mock) service be included in the Self Managed Commerce stack? The project development team might require Wiremock with development or test environments, to support automated functional testing. For more information about the Wiremock service, see the Self Managed Commerce Git repository, under<ep-commerce>/extensions/http-mock-server. - Does the environment need to be scalable? Environments that should automatically scale based on traffic and load must include Kubernetes Horizontal Pod Autoscalers (HPA).
- Does the environment need to highly available and have improved redundancy?
- How should the Self Managed Commerce environment be sized?
- Which IP ranges will need to be granted access ("allow-listed") to the Self Managed Commerce services on the environment?
Overview of the Steps
At a high level, the steps required to deploy a Self Managed Commerce environment are:
- Deploy the Apache ActiveMQ Service
- Create the Self Managed Commerce Database Service
- Populate the Self Managed Commerce Database
- Deploy the Self Managed Commerce Stack
You perform the above steps using the Jenkins jobs provided with CloudOps for Kubernetes. Jobs are provided to run each individual step, with parameters that offer control over the options and choices. Other jobs are provided that wrap some or all steps together to simplify specific use-cases.
Performing the Steps Individually
The following is a guide to completing each of the individual steps required to deploy a Self Managed Commerce environment.
Deploy the Apache ActiveMQ Service
To deploy the Apache ActiveMQ service see Deploying the Apache ActiveMQ Service.
Create the Self Managed Commerce Database Server
To create a Self Managed Commerce server or service, see Creating a Self Managed Commerce Database Server.
Populate the Self Managed Commerce Database
To populate a Self Managed Commerce database see Populating a Self Managed Commerce Database.
Deploy the Self Managed Commerce Stack
To deploy the Self Managed Commerce stack see Deploying Self Managed Commerce.
Complete the Post-Deployment Steps
To review the Post-Deployment Steps, see Commerce Post Deployment Steps.
Common integrations
- Setting up a connection with the AWS Simple Email Service SMTP Endpoint
- Creating and Managing AWS Simple Queue Service Queues