1. Testable Enterprise
  2. Docker Compose Installation

Testable Enterprise - Docker Compose

Deploying Testable with Docker Compose provides a way to deploy the full application quickly. We recommend this type of deployment for a proof of concept but not necessarily for a production deployment as it lacks some of the options and scalability of the Kubernetes route.

Prerequisites

System Requirements

  • Testable Services & Storage: Any Linux flavor, 4 vCPU, 16GB RAM, 50GB storage should be sufficient to install all components of Testable system and 1 test runner.
  • Test Runner: Test runners require any Linux flavor, ~100MB RAM, and 5GB storage when not running any tests. Resource utilization per virtual user depends on the scenario type (e.g. OpenFin vs Webdriver.io vs JMeter vs Node.js). The test runner agent will attempt to utilize all resources accessible to it for generating virtual users.

Required Container Images

If your company has its own container registry you will need to pull in the following container images available on Docker Hub:

Testable

Required Dependencies (if not hosted separately)

Installation

Follow these steps to install Testable via Docker Compose:

  1. Download our package (https://testable-onprem.s3.amazonaws.com/testable-onprem-latest.zip).
  2. Unzip it onto a Linux host with at least 4 vCPU, 16GB RAM, and 50GB storage.
  3. Run setup.sh or manually install Docker + Docker Compose. If you ran setup.sh, log out and back in to the shell.
  4. Configure your deployment via the onprem.env.template file. Read the configuration section below for more details or read the instructions in the file itself.
  5. Launch the system by running start.sh. If you need to change the container registry or the name of the test runner region please set the values in your start.sh script first.
  6. Once all containers launch, open http://myhost (or https://myhost if SSL is enabled) in your browser and wait for the system to fully initialize. At this point it will prompt you to configure an administrator account.

Configuration

The Testable environment is configured via the onprem.env.template file provided in our installation package. Each property is documented in the file including whether it is mandatory or not. This includes configuration related to the following:

  • Testable license: A license key for the installation. The license includes an agreed upon number of test runners and an expiration date.
  • Email settings: SMTP settings so that Testable can send various emails like test notifications, user sign up, password resets, etc.
  • SSL settings: Settings related to enabling SSL on your installation.
  • SSO settings: To use Single Sign On, enable SAML authentication for your Testable installation.
  • AWS Cloud settings: Testable can spin up on demand test runners in your AWS VPC if given access. This will not result in any connections back to Testable cloud, only to your own Testable installation.
  • Azure Cloud settings: Testable can spin up on demand test runners in your Azure virtual network if given access. This will not result in any connections back to Testable cloud, only to your own Testable installation.
  • GCP Cloud settings: Testable can spin up on demand test runners in your GCP if given access. This will not result in any connections back to Testable cloud, only to your own Testable installation.
  • Recording proxies: Settings related to recording proxies (HTTP forward proxy and an HTTP reverse proxy) that capture traffic for replaying as a test scenario.
  • Package managers: Add installation wide settings for NPM, Maven, Gradle, etc to ensure that scenarios which build or install modules point at your internal package managers and not the default public ones.

Using Your Own Kafka, Zookeeper, Redis Cluster, MySQL

By default our deployment package includes a self-bundled Kafka cluster, Zookeeper cluster, Redis cluster, and a MySQL database.

If you have these running inside your organization as a shared service you can decide to not include these containers and instead point the Testable installation at your existing services. This is done via the following settings in your onprem.env.template file:

  • TESTABLE_KAFKA_BROKERS: Comma separated list of Kafka brokers
  • TESTABLE_ZOOKEEPER_SERVERS: Comma separated list of Zookeeper servers
  • TESTABLE_REDIS_NODES: Comma separated list of Redis cluster nodes. Note that Testable only works with Redis cluster, not with a single Redis master/slave deployment.
  • MySQL Databases: Testable creates and initializes two databases when initializing for the first time: testable and testable-results. If you want to use an existing MySQL host, make sure both of these databases are created or the mysql user has permissions to create new databases. These two databases can be on different hosts.
    • For the testable database: TESTABLE_DB_MAIN_USERNAME, TESTABLE_DB_MAIN_PASSWORD, TESTABLE_DB_MAIN_HOST, TESTABLE_DB_MAIN_PORT
    • For the testable-results database: TESTABLE_DB_RESULTS_USERNAME, TESTABLE_DB_RESULTS_PASSWORD, TESTABLE_DB_RESULTS_HOST, TESTABLE_DB_RESULTS_PORT

Updates

Run the update.sh script to pull in new versions of container images. Testable will automatically handle applying updates across all components once a new version of the container images have been pulled.

Browser Versions

This section is only relevant if you plan to run browser based tests with a tool like Selenium AND you would like to either:

  1. Use old versions of browsers
  2. Use the latest version of browsers without having to update the test runner container image

Our test runner image comes with the latest version of each browser pre-installed on it as of the time the container is built. Testable will validate new browser releases and then make them available to our customers. The new version, as well as older versions, are available in two ways:

  1. Auto-Update: Testable will download the required version automatically from an AWS S3 bucket into your deployment. This requires the deployed environment to have the ability to make HTTPS requests out to S3. The S3 bucket has browser versions going back many years available.
  2. Via Browsers Cache Container: We also publish a container with the last 10 versions of each browser (testable/browsers-cache). This can be deployed in your environment if you want to avoid any external network requests. Every time a new browser version is available for our customers we will publish a new build of this container image for you to deploy.

Launching More Test Runners

With Docker Swarm

To launch additional test runners in the default region simply run docker-compose scale test-runner=COUNT where COUNT is the number of test runners you want to spin up across your Docker Swarm.

Without Docker Swarm

From the deployment package copy start-runners-only.sh, test-runner-only.yml, and onprem.env (generated when you spun up the main environment with start.sh) to the host where you want to run one or more test runners.

You can then start test runners with:

./start-runners-only.sh [region-name] [server-url]

The arguments are as follows:

  • region-name: The region to which these new test runners will be assigned.
  • server-url: The URL of the coordinator service. Either [website-url]/agents or http[s]://[main-server]:8080.

By default test runners will be available to all users of your Testable installation.

If you prefer it only be available to a particular organization, then do the following:

  1. Login to your Testable web (http://my-website-url)
  2. Switch to the Organization you want to target via the Organizations dropdown at the top
  3. Go to Org Management => API Keys to create a new key or copy an existing key.
  4. Pass this to your test runners using environment variable AGENT_KEY=xxxx.