Plan the container infrastructure

Determine which software to use to build an infrastructure that can support the containers running the WebSphere Commerce application.

Note: IBM is not responsible for our infrastructure. Use the following high-level information as a guide to decide how to build your infrastructure to suit your unique business requirements. The following image is a representation of the components to consider when deciding how to build the container platform.

    1 Determine where to host and run the containers for production. We can host WebSphere Commerce...

    • On a bare metal machine

    • In the Cloud

    • In virtual machines

    2 Determine which network configuration to use for containers to communicate with each other.

    3 Determine the security configuration and certificates.

    4 Determine which tools to use to persist important data as containers are destroyed and created.

    • Communication between containers requires specific configurations and access to sensitive information such as API keys, passwords, and certificates.

      Determine which data management system to use to securely store and access this data. Create a strategy to update container configurations as containers are created and destroyed or when new Docker hosts are added to the environment.

      Some software examples for data management include Vault, Consul, and ETCD.

    • As search-app containers are destroyed or created, you need to persist the search index data to the new containers because the store relies on the search index. Determine which remote storage system to use to store the search index for the search master and repeater nodes.

      Some examples for remote storage include GlusterFS, ScaleIO, or Ceph.

    5 Create a strategy to monitor the health of your entire system to prevent outages from occurring or minimizing the impact of unexpected failures. Logs for WebSphere Commerce are captured inside the containers so you need determine how to collect log entries across all the containers. Determine how to display the information in an organized, readable structure and how to search these logs to support troubleshooting issues.

    Some software examples for logging and monitoring include Graylog, ELK, or Prometheus.

    6, 7 The WebSphere Commerce application runs in separated Docker containers. We can cluster these containers to achieve redundancy. As business demands increase, we might need to deploy more Docker hosts and more container clusters. Determine which Docker orchestration tool to use to manage the container lifecycle to update, replace, scale up, or scale down as needed.

    Some software examples for orchestration tools include DC/OS, Kubernetes, or Docker Swarm.

    8 At this point, your application works within the internal network but you also need to integrate with third party systems and expose the containers to external traffic. Determine an appropriate load balancing solution that incorporates service registry and discovery automatically. While setting up load balancing, you also need to consider support for running multiple versions of your application at the same time to prevent dropped connections or routing traffic to the wrong version during maintenance upgrades or customization deployment.

    Some software examples to achieve load balancing and service registry and discovery include NGINX, DC/OS VIP, or Marathon-LB.

    Important: Because the Docker container platform can be set up based on varied technologies, the information provided in this table is only for reference. Adjust the solutions or adopt other solutions based on your business needs in the production environment.


    Reference solutions for applications on the Docker container platform

    Platform layer Function Applications/Reference solutions
    DC/OS Kubernetes
    Load balance layer Load balance (external/internal) Marathon-LB Reference white paper Ingress Reference white paper
    Application layer Applications WebSphere Commerce WebSphere Commerce
    Control layer Service registry and discovery Internal DNS Reference white paper Internal DNS Reference white paper
    Scaling DC/OS capability Kubernetes capability WebSphere Commerce deployment utilities2
    Docker orchestration /Scheduling DC/OS capability Reference white paper Kubernetes capability Reference white paper
    Deployment orchestration (Deployment pipeline) Jenkins Reference white paper Jenkins WebSphere Commerce deployment utilities 2
    Application catalog N/A1 N/A1
    Operation layer Logging N/A1 ELK
    Monitoring (alert, health check, etc) N/A1 Prometheus Reference white paper
    Persistence layer Storage Gluster FS Reference white paper Gluster FS Reference white paper
    Configuration Consul/Vault Reference white paper Consul/Vault Reference white paper
    Foundation layer Security scan N/A1 N/A1
    Certificate management Vault Reference white paper Vault Reference white paper
    Network layer Networking N/A1 N/A1
    Hypervisor layer Container OS CentOS or Redhat CentOS or Redhat
    Hypervisor (internal/virtual machine/bare metal) ESX ESX

    1IBM does not provide reference white paper for these solutions. However, we can apply any existing solutions in the industry based on your business needs.

    2This tool chain is available within GitHub and is provided for reference purposes only. IBM does not provide support for the usage of the tool chain.


    See

    1. Docker Home