Files
shankar0123 1279172e9b loadtest: close Phase 8 SCALE-H2 — add scale-tier scenarios
Phase 8 of the certctl architecture diligence remediation closes
SCALE-H2 by adding three new k6 scenarios that exercise the scale-
relevant load surfaces the API tier + connector tier left uncovered:
fleet-scale bulk renewal, ACME enrollment burst, and agent heartbeat
storm.

Audit miscount + path correction (live-grep at Phase 8 audit time)
==================================================================
- The Phase 8 prompt referenced both `deploy/test/load/` and
  `deploy/test/loadtest/`. Repo truth: the existing harness lives at
  `deploy/test/loadtest/`. New scenarios land there.
- The audit's prior framing "k6 covers the API tier at 50 req/s
  only" omitted Bundle 10 (2026-05-02) which added four connector-
  tier handshake scenarios (nginx/apache/haproxy/f5) at 100 conns/min
  each, plus the Phase 5 ACME directory/nonce/ARI scenario at 100 VUs
  in `k6/acme_flow.js`. Phase 8 appends to what's there rather than
  rewriting.

What ships
==========

Three new k6 scenario files under deploy/test/loadtest/k6/:

  bulk_renewal.js — 10K-cert seed + 5 req/s POST /bulk-renew × 5min
                    p99 < 5s, p95 < 2s, errors < 1%
  acme_burst.js   — 200 VU sustained × directory/nonce/ARI × 5min
                    directory p95 < 500ms, nonce p95 < 300ms,
                    renewal-info p95 < 800ms, 5xx-only < 0.1%
                    Pins RFC 7807 rate-limit response shape via
                    acme_rate_limit_shape_ok Counter.
  agent_storm.js  — 5K-agent seed + 167 req/s POST /heartbeat × 5min
                    p99 < 1s, p95 < 500ms, errors < 0.1%

Two seed SQL fixtures under deploy/test/loadtest/seed/:

  01_bulk_renewal_certs.sql — 10,000 managed_certificates rows
    linked to seed_demo.sql FKs (iss-local, o-alice, t-platform,
    rp-standard). status='active', expires_at distributed across
    next 30 days, name prefix `loadtest-bulk-` so the scenario
    can scope its criteria. Idempotent via
    ON CONFLICT (name) DO NOTHING.

  02_agent_fleet.sql — 5,000 agents rows with name prefix
    `loadtest-agent-`. status='Online', last_heartbeat_at
    staggered across prior 60s, OS distribution 80%/10%/10%
    linux/windows/darwin. Idempotent via
    ON CONFLICT (id) DO NOTHING.

Plus seed/README.md documenting the opt-in profile + when these
run vs the default `make loadtest` fast path.

Compose + Makefile + CI wiring
==============================

deploy/test/loadtest/docker-compose.yml gains four new services,
all gated behind the `scale` compose profile so the default
`make loadtest` is unchanged:

  scale-seed       — one-shot postgres:16-alpine container that runs
                     every ./seed/*.sql in lexical order against the
                     same postgres the server uses. Depends on
                     postgres healthy + certctl-server healthy (so
                     migrations + seed_demo.sql have already run).
  k6-scale-bulk    — grafana/k6:0.54.0 driver running bulk_renewal.js
  k6-scale-acme    — grafana/k6:0.54.0 driver running acme_burst.js
  k6-scale-agent   — grafana/k6:0.54.0 driver running agent_storm.js

Each driver depends_on scale-seed completed_successfully so the
scenarios never run against an unseeded DB (the acme scenario
doesn't need the seed itself but uses the same dependency chain for
ordering predictability).

Makefile gains four new phony targets:

  loadtest-scale-bulk   - runs bulk_renewal.js via compose --profile scale
  loadtest-scale-acme   - runs acme_burst.js
  loadtest-scale-agent  - runs agent_storm.js
  loadtest-scale        - all three serially

.github/workflows/loadtest.yml gains a new k6-scale matrix job that
runs after the existing k6 job (needs: k6) with a matrix on the
three scenarios — fail-fast: false so a regression in one scenario
doesn't cancel the others. Same workflow_dispatch + weekly cron
cadence as the existing API + connector tier job.

Documentation
=============

docs/operator/scale.md gains a new "Scale-tier scenarios (SCALE-H2,
Phase 8)" section between the cursor-pagination subsection and the
profiling-production subsection. Documents:
  - Scenario + seed + sustained load table
  - Threshold contract (regression guards, NOT measured baselines)
  - Measured-baseline table with TBD placeholders + the canonical-
    hardware capture procedure
  - How to run the scale tier locally
  - Four documented limitations (JWS-signed ACME, scheduler renewal
    scan throughput, production-sized Postgres, pull-only deployment
    model)

deploy/test/loadtest/README.md gains a short "Scale tier (Phase 8
SCALE-H2, 2026-05-14)" section pointing at scale.md as the canonical
operator-facing baseline source. Avoids duplication; the README
remains the harness-mechanics doc.

Deliberate deviations from the prompt
======================================

The Phase 8 prompt's "concrete deliverables" section referenced
`deploy/test/load/` (no -test) for the new k6 files. The actual
harness lives at `deploy/test/loadtest/` — the new files land there
to match existing convention. The prompt's audit-questions section
also referenced `deploy/test/loadtest/` so the prompt was internally
inconsistent on this; repo truth wins.

The prompt described the ACME burst as "200 concurrent ACME orders
against /acme/profile/<id>/new-order ... pin the rate-limit response
shape." new-order is JWS-signed (RFC 8555 §7.4 requires JWS for
every POST except newAccount-pre-account-key flows). k6 doesn't
ship JWS and bundling a signer (e.g. lego) into the k6 container
would obscure the server-side latency the scenario is trying to
measure. Same trade-off the existing Phase 5 acme_flow.js made.
Phase 8's acme_burst.js measures the unauthenticated
directory + nonce + ARI surface at burst rate AND pins the 429
rate-limit response shape via a custom Counter that increments only
when the response is `application/problem+json` with the
`urn:ietf:params:acme:error:rateLimited` type. End-to-end JWS
conformance under load remains a follow-up; the canonical JWS
correctness gate is `make acme-rfc-conformance-test` (lego-based,
non-load).

Deferred (operator-side, not engineering)
==========================================

Canonical-hardware baseline capture. The TBD placeholders in
docs/operator/scale.md's measured-baseline table are intentional —
sandbox-captured numbers from a developer laptop are misleading
(same anti-pattern the original loadtest README guards against).
Operator triggers loadtest.yml from the Actions tab, waits for the
k6-scale matrix jobs to complete, downloads the per-scenario
summary artifacts, copies p50/p95/p99 into the table, commits the
captured numbers alongside the date + commit SHA.

Files changed (10):
  .github/workflows/loadtest.yml                            (+72 -1)
  Makefile                                                  (+47 -1)
  deploy/test/loadtest/README.md                            (+28 -1)
  deploy/test/loadtest/docker-compose.yml                   (+108 -1)
  deploy/test/loadtest/k6/bulk_renewal.js                   (new, 106 lines)
  deploy/test/loadtest/k6/acme_burst.js                     (new, 192 lines)
  deploy/test/loadtest/k6/agent_storm.js                    (new, 124 lines)
  deploy/test/loadtest/seed/01_bulk_renewal_certs.sql       (new, 95 lines)
  deploy/test/loadtest/seed/02_agent_fleet.sql              (new, 92 lines)
  deploy/test/loadtest/seed/README.md                       (new, 86 lines)
  docs/operator/scale.md                                    (+109 -0)

Verification (sandbox-runnable):
  python3 -c 'import yaml; yaml.safe_load(open("deploy/test/loadtest/docker-compose.yml"))'
    → compose YAML OK
  python3 -c 'import yaml; yaml.safe_load(open(".github/workflows/loadtest.yml"))'
    → workflow YAML OK
  grep -E 'bulk_renewal|acme_burst|agent_storm' deploy/test/loadtest/k6/*.js
    → all three scenarios + tags present
  grep loadtest-scale Makefile
    → 4 new targets registered in .PHONY + 3 recipes + 1 aggregate

Runtime verification (deferred — requires docker on canonical hardware):
  make loadtest-scale-bulk    # 10K cert fixture + 5 req/s × 5min
  make loadtest-scale-acme    # 200 VU × 5min
  make loadtest-scale-agent   # 5K agent fixture + 167 req/s × 5min
  make loadtest-scale         # all three serially

Closes: cowork/certctl-architecture-diligence-audit.html#fix-SCALE-H2
2026-05-14 03:25:15 +00:00

479 lines
20 KiB
YAML

# =============================================================================
# certctl Load-Test Harness — Docker Compose
# =============================================================================
#
# Spins up a minimal certctl stack and runs a k6 driver against it to capture
# p50 / p95 / p99 latency for the certificate-management API hot path AND
# (Bundle 10 of the 2026-05-02 deployment-target audit) per-target-type
# TCP+TLS handshake throughput against four target sidecars (nginx, apache,
# haproxy, f5-mock).
#
# Stack:
# 1. postgres — empty database (server runs migrations + seeds at boot)
# 2. certctl-tls-init — one-shot init container; writes self-signed
# server.crt/.key/ca.crt into ./certs (bind
# mount, host-readable so the k6 container
# can pin against it via volumes)
# 3. certctl-server — HTTPS API on :8443, demo-seed enabled so
# the k6 script has iss-local + an operator
# + a team ready to reference in
# CreateCertificate payloads
# 4. target-tls-init — Bundle 10: shared starter cert+key for the
# four target sidecars (nginx, apache,
# haproxy, f5-mock). Each daemon boots with
# this cert; the loadtest scenarios connect
# at sustained rates to measure handshake
# latency tagged by target_type.
# 5. nginx-target — Bundle 10: HTTPS on internal :443.
# 6. apache-target — Bundle 10: HTTPS on internal :443.
# 7. haproxy-target — Bundle 10: HTTPS on internal :443.
# 8. f5-mock-target — Bundle 10: iControl REST on internal :443
# + plaintext HTTP on internal :8080. Runs
# the in-tree f5-mock-icontrol image
# (deploy/test/f5-mock-icontrol/).
# 9. k6 — runs k6.js once and exits with the
# threshold-driven exit code (zero on green,
# non-zero on any threshold breach so
# `make loadtest` surfaces regressions as a
# failed shell command).
#
# Out of scope for v1 of the connector-tier harness (Bundle 10):
# - Kubernetes target via kind-in-docker. kind requires `privileged: true`
# and Docker-in-Docker semantics that are operationally fragile in CI;
# the K8s connector loadtest is a follow-up that needs Bundle 2's real
# k8s.io/client-go to land first.
# - Full agent-driven deploy poll loop (POST cert → poll deployments →
# verify served cert matches what was deployed). The harness measures
# handshake throughput against the target sidecars directly — that's
# enough to validate the sidecars are operational under load and gives
# procurement a per-target latency number that doesn't depend on the
# agent registration + target-binding API surface being plumbed
# end-to-end in the loadtest stack.
#
# Usage: make loadtest (from the repo root)
# Manual: cd deploy/test/loadtest && docker compose up --abort-on-container-exit --exit-code-from k6
#
# Audit reference (API tier): 2026-05-01 issuer coverage audit fix #8.
# Audit reference (connector tier): 2026-05-02 deployment-target audit Bundle 10.
# =============================================================================
services:
# ---------------------------------------------------------------------------
# Self-signed TLS bootstrap. Mirrors the deploy/docker-compose.test.yml
# tls-init pattern exactly: bind-mount instead of named volume so the host
# (and the sibling k6 container) can read ca.crt without a chown dance.
# See deploy/docker-compose.test.yml::certctl-tls-init for the full rationale.
# ---------------------------------------------------------------------------
certctl-tls-init:
image: alpine/openssl:latest
container_name: certctl-loadtest-tls-init
restart: "no"
entrypoint: /bin/sh
command:
- -c
- |
set -eu
CERT=/etc/certctl/tls/server.crt
KEY=/etc/certctl/tls/server.key
CA=/etc/certctl/tls/ca.crt
if [ -f "$$CERT" ] && [ -f "$$KEY" ] && [ -f "$$CA" ]; then
echo "TLS cert already present — skipping generation"
else
mkdir -p /etc/certctl/tls
openssl req -x509 -newkey ec \
-pkeyopt ec_paramgen_curve:P-256 \
-nodes \
-keyout "$$KEY" \
-out "$$CERT" \
-days 3650 \
-subj "/CN=certctl-server" \
-addext "subjectAltName=DNS:certctl-server,DNS:localhost,IP:127.0.0.1"
cp "$$CERT" "$$CA"
echo "Generated self-signed TLS cert (ECDSA-P256, 3650d, CN=certctl-server)"
fi
chmod 0644 "$$CERT" "$$CA"
chmod 0600 "$$KEY"
volumes:
- ./certs:/etc/certctl/tls
# ---------------------------------------------------------------------------
# Database. The server runs migrations + seed.sql + (because
# CERTCTL_DEMO_SEED=true below) seed_demo.sql at boot — so the load-test
# k6 script can reference iss-local, o-alice, t-platform, and rp-default
# without a separate seed step.
# ---------------------------------------------------------------------------
postgres:
image: postgres:16-alpine
container_name: certctl-loadtest-postgres
environment:
POSTGRES_DB: certctl
POSTGRES_USER: certctl
POSTGRES_PASSWORD: loadtestpass
healthcheck:
test: ["CMD-SHELL", "pg_isready -U certctl"]
interval: 5s
timeout: 3s
retries: 10
start_period: 30s
# ---------------------------------------------------------------------------
# certctl server. Built from the repo root Dockerfile (same as production).
# Demo seed is enabled so referenced FK rows exist when the k6 script
# POSTs CreateCertificate payloads. Auth is api-key with a deterministic
# token the k6 script knows.
# ---------------------------------------------------------------------------
certctl-server:
build:
context: ../../..
dockerfile: Dockerfile
args:
HTTP_PROXY: ${HTTP_PROXY:-}
HTTPS_PROXY: ${HTTPS_PROXY:-}
NO_PROXY: ${NO_PROXY:-}
container_name: certctl-loadtest-server
depends_on:
postgres:
condition: service_healthy
certctl-tls-init:
condition: service_completed_successfully
environment:
CERTCTL_DATABASE_URL: postgres://certctl:loadtestpass@postgres:5432/certctl?sslmode=disable
CERTCTL_SERVER_HOST: 0.0.0.0
CERTCTL_SERVER_PORT: 8443
CERTCTL_SERVER_TLS_CERT_PATH: /etc/certctl/tls/server.crt
CERTCTL_SERVER_TLS_KEY_PATH: /etc/certctl/tls/server.key
CERTCTL_LOG_LEVEL: warn
CERTCTL_AUTH_TYPE: api-key
CERTCTL_AUTH_SECRET: load-test-token
CERTCTL_KEYGEN_MODE: agent
# CERTCTL_DEMO_SEED=true triggers seed_demo.sql which creates iss-local,
# o-alice, t-platform, rp-standard so CreateCertificate FK validation
# has rows to bind to.
CERTCTL_DEMO_SEED: "true"
# Bigger body limit so listing 100s of certs in the GET scenario
# doesn't 413 once the harness has been running for a few minutes.
CERTCTL_MAX_BODY_SIZE: "10485760"
# Encryption key (≥32 bytes per H-1 floor — the test compose's
# documented value).
CERTCTL_CONFIG_ENCRYPTION_KEY: "loadtest-key-must-be-32-bytes-long-yes"
volumes:
- ./certs:/etc/certctl/tls:ro
healthcheck:
# /healthz is unauthenticated. -k because the cert is self-signed.
test: ["CMD-SHELL", "wget -q --no-check-certificate -O- https://localhost:8443/healthz || exit 1"]
interval: 5s
timeout: 3s
retries: 30
start_period: 60s
# ---------------------------------------------------------------------------
# Bundle 10: target-side TLS bootstrap. Mints a single ECDSA-P256 self-
# signed cert + key into a shared ./fixtures/target-certs/ volume that the
# four target sidecars (nginx, apache, haproxy) mount read-only. f5-mock
# generates its own self-signed cert at startup (see
# deploy/test/f5-mock-icontrol/tls.go) so it doesn't need this volume.
#
# The loadtest scenarios don't care which cert the target serves — only
# that the daemon is up and completing TLS handshakes at the configured
# rate. The starter cert exists so each daemon boots green; once Bundle 2
# (real K8s client) + agent-driven deploy poll is plumbed in v2 of the
# harness, deploys would overwrite this cert.
# ---------------------------------------------------------------------------
target-tls-init:
image: alpine/openssl:latest
container_name: certctl-loadtest-target-tls-init
restart: "no"
entrypoint: /bin/sh
command:
- -c
- |
set -eu
CERT=/certs/target.crt
KEY=/certs/target.key
PEM=/certs/target.pem
if [ -f "$$CERT" ] && [ -f "$$KEY" ] && [ -f "$$PEM" ]; then
echo "Target TLS cert already present — skipping generation"
else
mkdir -p /certs
openssl req -x509 -newkey ec \
-pkeyopt ec_paramgen_curve:P-256 \
-nodes \
-keyout "$$KEY" \
-out "$$CERT" \
-days 365 \
-subj "/CN=loadtest-target" \
-addext "subjectAltName=DNS:nginx-target,DNS:apache-target,DNS:haproxy-target,DNS:f5-mock-target,DNS:localhost,IP:127.0.0.1"
# HAProxy expects cert+key concatenated into a single PEM file
# at the path supplied to `bind ... ssl crt <path>`. Build it
# alongside the cert/key pair so the haproxy-target's mount
# works without a per-daemon ENTRYPOINT shim.
cat "$$CERT" "$$KEY" > "$$PEM"
echo "Generated target starter cert (ECDSA-P256, 365d, multi-SAN)"
fi
# World-readable so non-root container users (haproxy uses uid 99,
# apache uses uid 1) can read the key. This is fine for a load-test
# starter cert; production wouldn't do this.
chmod 0644 "$$CERT" "$$KEY" "$$PEM"
volumes:
- ./fixtures/target-certs:/certs
# ---------------------------------------------------------------------------
# nginx-target. Listens on internal :443 with the starter cert. The
# k6 nginx_handshake scenario connects at 100 conns/min for 5 minutes.
# ---------------------------------------------------------------------------
nginx-target:
image: nginx:1.27-alpine
container_name: certctl-loadtest-nginx
depends_on:
target-tls-init:
condition: service_completed_successfully
volumes:
- ./fixtures/target-certs:/etc/nginx/certs:ro
- ./fixtures/nginx.conf:/etc/nginx/nginx.conf:ro
healthcheck:
test: ["CMD-SHELL", "wget -q --no-check-certificate -O- https://localhost:443/ || exit 1"]
interval: 5s
timeout: 3s
retries: 20
start_period: 15s
# ---------------------------------------------------------------------------
# apache-target. Listens on internal :443. The bundled httpd.conf loads
# the minimum module set + a single SSL-terminated vhost.
# ---------------------------------------------------------------------------
apache-target:
image: httpd:2.4-alpine
container_name: certctl-loadtest-apache
depends_on:
target-tls-init:
condition: service_completed_successfully
volumes:
- ./fixtures/target-certs:/usr/local/apache2/conf/certs:ro
- ./fixtures/httpd.conf:/usr/local/apache2/conf/httpd.conf:ro
healthcheck:
test: ["CMD-SHELL", "wget -q --no-check-certificate -O- https://localhost:443/ || exit 1"]
interval: 5s
timeout: 3s
retries: 20
start_period: 15s
# ---------------------------------------------------------------------------
# haproxy-target. Listens on internal :443 with SSL termination. The
# haproxy.cfg references /usr/local/etc/haproxy/certs/target.pem which
# target-tls-init writes (cert + key concatenated).
# ---------------------------------------------------------------------------
haproxy-target:
image: haproxy:2.9-alpine
container_name: certctl-loadtest-haproxy
depends_on:
target-tls-init:
condition: service_completed_successfully
volumes:
- ./fixtures/target-certs:/usr/local/etc/haproxy/certs:ro
- ./fixtures/haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
healthcheck:
# HAProxy doesn't ship with wget/curl; use the openssl-based handshake
# check instead. The /dev/null redirect drops the response body so
# large logs don't accumulate over the run.
test: ["CMD-SHELL", "echo Q | openssl s_client -connect localhost:443 -servername localhost 2>/dev/null | grep -q 'BEGIN CERTIFICATE'"]
interval: 5s
timeout: 3s
retries: 20
start_period: 15s
# ---------------------------------------------------------------------------
# f5-mock target. Re-uses the in-tree f5-mock-icontrol image (already
# used by the deploy-vendor-e2e CI job). Generates its own self-signed
# cert at startup; listens on internal :443 (HTTPS, iControl REST) and
# :8080 (plaintext HTTP). The k6 f5_handshake scenario hits the
# /healthz endpoint.
# ---------------------------------------------------------------------------
f5-mock-target:
# Long-form build to match docker-compose.test.yml: the Dockerfile
# has `COPY deploy/test/f5-mock-icontrol/ ./` which assumes the
# build context is the REPO ROOT. The previous shorthand form
# `build: ../f5-mock-icontrol` set the context to the
# f5-mock-icontrol directory itself, breaking the COPY at CI build
# time (run #25305811340: "deploy/test/f5-mock-icontrol: not found").
build:
context: ../../..
dockerfile: deploy/test/f5-mock-icontrol/Dockerfile
container_name: certctl-loadtest-f5-mock
healthcheck:
test: ["CMD-SHELL", "wget -q -O- http://localhost:8080/healthz || exit 1"]
interval: 5s
timeout: 3s
retries: 20
start_period: 15s
# ---------------------------------------------------------------------------
# k6 driver. Pinned to a specific version so threshold expressions stay
# stable across runs. --insecure-skip-tls-verify because the server cert is
# self-signed; the load test isn't a TLS conformance test. The k6 process
# exits non-zero if any threshold is breached, which the parent
# `docker compose up --exit-code-from k6` propagates as the compose exit
# code, which `make loadtest` then surfaces as the make-target exit code.
# ---------------------------------------------------------------------------
k6:
image: grafana/k6:0.54.0
container_name: certctl-loadtest-k6
depends_on:
certctl-server:
condition: service_healthy
# Bundle 10: wait for the four target sidecars to be healthy before
# firing the connector-tier scenarios. Saves the operator from
# spurious "connection refused" errors during the first ~15s of the
# run while target daemons are coming up.
nginx-target:
condition: service_healthy
apache-target:
condition: service_healthy
haproxy-target:
condition: service_healthy
f5-mock-target:
condition: service_healthy
environment:
CERTCTL_BASE: https://certctl-server:8443
CERTCTL_TOKEN: load-test-token
K6_INSECURE_SKIP_TLS_VERIFY: "true"
# Bundle 10: per-target sidecar URLs the connector-tier scenarios
# connect to. Internal docker-compose DNS — k6 resolves these via
# the default user network's resolver.
NGINX_TARGET_URL: https://nginx-target:443
APACHE_TARGET_URL: https://apache-target:443
HAPROXY_TARGET_URL: https://haproxy-target:443
F5_TARGET_URL: https://f5-mock-target:443
volumes:
- ./k6.js:/scripts/k6.js:ro
- ./results:/results
command:
- run
- --summary-export=/results/summary.json
- /scripts/k6.js
# ===========================================================================
# Phase 8 SCALE-H2 — scale-tier scenarios (opt-in via `--profile scale`).
#
# The default `make loadtest` path runs the API tier + connector tier
# scenarios above against the demo-scale seed. The Phase 8 scenarios are
# heavier (10K cert + 5K agent fixtures) and would slow the default path
# without serving the per-PR signal the existing run targets, so they live
# behind a separate compose profile.
#
# Three components, all profile-gated:
# 1. scale-seed — one-shot init that runs ./seed/*.sql against the
# same postgres the server uses. Idempotent.
# 2. k6-scale-bulk / k6-scale-acme / k6-scale-agent — one driver each
# for the three Phase 8 scenarios. The matrix dispatch
# in .github/workflows/loadtest.yml picks one per job.
#
# Run a single scale scenario locally:
# docker compose --profile scale up \
# --abort-on-container-exit --exit-code-from k6-scale-bulk \
# scale-seed k6-scale-bulk
# ===========================================================================
scale-seed:
# postgres:16-alpine bundles psql; no extra image needed.
image: postgres:16-alpine
container_name: certctl-loadtest-scale-seed
restart: "no"
profiles: ["scale"]
depends_on:
postgres:
condition: service_healthy
# Wait for certctl-server to be healthy — the server runs schema
# migrations + seed_demo.sql at boot. The Phase 8 seeds reference
# FKs (iss-local, o-alice, t-platform, rp-standard) that
# seed_demo.sql creates, so the order MUST be:
# postgres up → server runs migrations + seed_demo.sql → scale-seed runs
certctl-server:
condition: service_healthy
environment:
PGHOST: postgres
PGUSER: certctl
PGPASSWORD: loadtestpass
PGDATABASE: certctl
volumes:
- ./seed:/seed:ro
entrypoint: /bin/sh
command:
- -c
- |
set -eu
echo "==> Phase 8 scale-seed: running SQL fixtures (lexical order)"
for f in /seed/*.sql; do
echo "----> $$f"
psql -v ON_ERROR_STOP=1 -f "$$f"
done
echo "==> Phase 8 scale-seed: complete"
k6-scale-bulk:
image: grafana/k6:0.54.0
container_name: certctl-loadtest-k6-bulk
profiles: ["scale"]
depends_on:
certctl-server:
condition: service_healthy
scale-seed:
condition: service_completed_successfully
environment:
CERTCTL_BASE: https://certctl-server:8443
CERTCTL_TOKEN: load-test-token
K6_INSECURE_SKIP_TLS_VERIFY: "true"
volumes:
- ./k6/bulk_renewal.js:/scripts/bulk_renewal.js:ro
- ./results:/results
command:
- run
- --summary-export=/results/summary-bulk-renewal.json
- /scripts/bulk_renewal.js
k6-scale-acme:
image: grafana/k6:0.54.0
container_name: certctl-loadtest-k6-acme
profiles: ["scale"]
depends_on:
certctl-server:
condition: service_healthy
# ACME scenario doesn't depend on the SQL seeds (it hits the
# unauthenticated directory + nonce + ARI surface) but routing
# it through the same dependency chain keeps the compose
# ordering predictable across the three scale jobs.
scale-seed:
condition: service_completed_successfully
environment:
CERTCTL_ACME_DIRECTORY: https://certctl-server:8443/acme/profile/prof-test/directory
K6_INSECURE_SKIP_TLS_VERIFY: "true"
volumes:
- ./k6/acme_burst.js:/scripts/acme_burst.js:ro
- ./results:/results
command:
- run
- --summary-export=/results/summary-acme-burst.json
- /scripts/acme_burst.js
k6-scale-agent:
image: grafana/k6:0.54.0
container_name: certctl-loadtest-k6-agent
profiles: ["scale"]
depends_on:
certctl-server:
condition: service_healthy
scale-seed:
condition: service_completed_successfully
environment:
CERTCTL_BASE: https://certctl-server:8443
CERTCTL_TOKEN: load-test-token
K6_INSECURE_SKIP_TLS_VERIFY: "true"
# Match the seed's 5K-agent fleet.
K6_AGENT_FLEET: "5000"
volumes:
- ./k6/agent_storm.js:/scripts/agent_storm.js:ro
- ./results:/results
command:
- run
- --summary-export=/results/summary-agent-storm.json
- /scripts/agent_storm.js