DongHyeonkaandClaude Opus 5
5f10b791d3
Snapshot of the in-flight state that already existed, identically, in both this worktree and the main checkout before this session began: the initial HTTP Client platform implementation (previously untracked), the redis-lab removal, and the JPA / object-storage / notification integration work. Kept separate from this session's HTTP Client review response, which lands in the following commit, so the two bodies of work stay reviewable apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
79 lines
2.7 KiB
YAML
79 lines
2.7 KiB
YAML
# TLS lane for the Redis SDK topology tests.
|
|
#
|
|
# Standalone in shape, but the point is the transport: the SDK's TLS settings — enabled, hostname
|
|
# verification, trust material, client certificate — are configuration nothing else exercises, and
|
|
# a TLS path that has never carried a command is a claim rather than a capability.
|
|
#
|
|
# The certificates are generated at start-up rather than checked in. A checked-in key is a secret in
|
|
# the repository however loudly the file is named "test", and a lane that regenerates its own
|
|
# material also proves the trust configuration actually matters: point the client at the wrong CA
|
|
# and it fails, which is what the qualification has to show.
|
|
services:
|
|
certs:
|
|
# The redis image carries no openssl, so certificate generation gets an image that does. The
|
|
# alternative — checking the material in — puts a private key in the repository.
|
|
image: alpine/openssl:latest
|
|
user: root
|
|
volumes:
|
|
- tls:/tls
|
|
entrypoint:
|
|
- /bin/sh
|
|
- -c
|
|
- |
|
|
set -e
|
|
if [ -f /tls/redis.crt ]; then exit 0; fi
|
|
openssl genrsa -out /tls/ca.key 2048
|
|
openssl req -x509 -new -nodes -key /tls/ca.key -sha256 -days 1 \
|
|
-subj "/CN=ca-skeleton-test-ca" -out /tls/ca.crt
|
|
openssl genrsa -out /tls/redis.key 2048
|
|
openssl req -new -key /tls/redis.key -subj "/CN=localhost" -out /tls/redis.csr
|
|
printf 'subjectAltName=DNS:localhost,IP:127.0.0.1' > /tls/redis.ext
|
|
openssl x509 -req -in /tls/redis.csr -CA /tls/ca.crt -CAkey /tls/ca.key \
|
|
-CAcreateserial -out /tls/redis.crt -days 1 -sha256 -extfile /tls/redis.ext
|
|
chmod 644 /tls/redis.key /tls/ca.key
|
|
|
|
redis:
|
|
image: "redis:${REDIS_VERSION:-7.4}"
|
|
depends_on:
|
|
certs:
|
|
condition: service_completed_successfully
|
|
volumes:
|
|
- ../acl:/etc/redis/acl:ro
|
|
- tls:/tls:ro
|
|
command:
|
|
- redis-server
|
|
# Plaintext is off entirely. A lane that accepts both proves nothing about the TLS path,
|
|
# because a misconfigured client would quietly fall back and still pass.
|
|
- --port
|
|
- "0"
|
|
- --tls-port
|
|
- "6379"
|
|
- --tls-cert-file
|
|
- /tls/redis.crt
|
|
- --tls-key-file
|
|
- /tls/redis.key
|
|
- --tls-ca-cert-file
|
|
- /tls/ca.crt
|
|
- --tls-auth-clients
|
|
- "no"
|
|
- --appendonly
|
|
- "no"
|
|
- --save
|
|
- ""
|
|
- --aclfile
|
|
- /etc/redis/acl/all-accounts.acl
|
|
ports:
|
|
- "${REDIS_PORT:-6390}:6379"
|
|
healthcheck:
|
|
test:
|
|
- CMD-SHELL
|
|
- >-
|
|
[ "$$(redis-cli --tls --cacert /tls/ca.crt
|
|
--user ca-skeleton-application --pass fixture-application --no-auth-warning ping)" = PONG ]
|
|
interval: 2s
|
|
timeout: 3s
|
|
retries: 20
|
|
|
|
volumes:
|
|
tls:
|