Does InfluxDB's Docker init mode skip setup when the volume already has data?
0 reputation · 16 Apr 2023, 02:27 UTC
Goal
I want repeatable integration tests against InfluxDB OSS in Docker (assuming the 2.7.x image line) where the container is provisioned automatically, without production credentials, and can be torn down and restarted against a persistent volume between test runs.
Constraint and uncertainty
The image supports DOCKER_INFLUXDB_INIT_MODE=setup with the related DOCKER_INFLUXDB_INIT_* variables, and the /api/v2/setup endpoint offers a programmatic alternative. What is unclear is what exactly tells the init path that setup has already happened: the presence of the bolt file, the engine directory, or something else. If a second setup attempt runs, it is not obvious whether it fails cleanly, silently succeeds, or creates an additional operator token alongside the one pre-seeded via DOCKER_INFLUXDB_INIT_ADMIN_TOKEN. Since /api/v2/setup is unauthenticated, I would also like to understand the risk of leaving it reachable in a shared CI network.
Questions
- Which on-disk state does the 2.7.x image check to decide whether to skip init-mode setup on restart?
- If
/api/v2/setupis called again on an initialized instance, what status and token behavior should I expect? - Is checking
/healthor/api/v2/bucketsbefore invoking setup the recommended idempotency pattern, or is there a supported built-in one?