Expand description
A floci.io cloud emulator — one native Quarkus image per cloud
provider, each speaking that provider’s REST APIs against an in-memory backing
store. One module type covers all three variants; pick one with the
FlociContainer::aws/FlociContainer::azure/FlociContainer::gcp factory
functions rather than a bare constructor — each factory pins the provider’s own
image and guest port.
§Readiness — /health works uniformly, unlike the AWS-flavored /_localstack/health
The AWS variant ships a LocalStack-compatible /_localstack/health endpoint (spec
hypothesis confirmed), but the Azure and GCP variants do not carry that path (Azure:
501; GCP: 404). All three, however, answer a plain GET /health with 200
and a small JSON status body the moment the embedded Quarkus HTTP listener is up —
verified directly against real boots of floci/floci:1.5.30,
floci/floci-az:0.8.0, and floci/floci-gcp:0.4.0. /health is pinned as the one
wait path that works across all three variants; no log-wait fallback was needed.
§No signing needed — verified against the AWS variant’s S3 surface
The AWS variant’s S3-shaped REST endpoints accept unsigned requests with no
Authorization header at all: PUT /<bucket>, PUT /<bucket>/<key>, and GET /<bucket>/<key> all round-trip successfully with a bare HTTP client call — no
SigV4, no AWS SDK dependency required. This module’s IT exercises that plain-REST
path rather than pulling in an AWS SDK.
§Memory — tiny, no ladder needed
All three images are native (GraalVM) Quarkus binaries; a real boot settles at
roughly 11-27 MiB RSS (docker stats), and each variant boots and answers
/health under msb’s default microVM RAM with no with_memory_limit override.
No control characters were found in any of the three images’ baked env (checked
via docker image inspect).
Structs§
- Floci
Container - A floci.io cloud emulator container — one AWS/Azure/GCP variant, picked via
FlociContainer::aws/FlociContainer::azure/FlociContainer::gcp. - Floci
Guard - The running guard for a
FlociContainer.