System overview

Background

Using the local:docker runner of Testground enables you to test distributed/p2p systems on your local machine with precisely the same build artifacts as the cluster:k8s runner. The use of Docker images as a build target ensures plans are built the same way with the same build environment even when built on a different machine or a different OS.
The overall performance of the local:docker runner depends highly on the machine running the tests, though we are frequently able to run tests with 100+ instances without issue using commonly-available laptops or desktop computers.

Dependencies

Aside from the sidecar, which is built separately, any auxiliary Docker images are downloaded if needed. This is what you need to get started:
  • A laptop or desktop with reasonable hardware specs. To be able run simulations of a reasonable size, we recommend at least the following:
    • 8GB memory
    • 50GB available storage
  • The following software setup is required:
    • Docker daemon
    • a non-root account with write access to the Docker socket.
    • Sidecar container installation. See installation instructions in Getting Started

Testground-supplied containers

When Testground runs its first plan, several additional containers will be downloaded and started. Here is an overview of everything Testground adds to your system
  • Docker networks:
    • testground-build
      • This network is used only during the build phase.
      • Test plan containers are not attached to this network.
    • testground-control
      • This network is used by test plan containers to communicate with the sync service and the host.
      • Though this is a public-facing network, plan containers cannot access the internet through this network because routes are removed.
    • testground-data
      • Plan containers communicate with each other over this network.
      • This is the network used for testing.
      • The sidecar modifies the link quality and performance to simulate real-world conditions.
  • Docker containers:
    • goproxy
      • This container is attached to the build network.
      • It speeds up Go builds.
      • It is optional.
    • redis
      • This is the backend database of the Testground sync service.
    • grafana
      • Visualisation software that Testground uses for its dashboards.
    • influxdb
      • Time-series database that Testground uses for various diagnostics and events.
Last modified 1yr ago