Reaper separates generated configuration from its container image

A container can run as an unprivileged user and still require writes into its image filesystem during startup. Reaper 3.6.1 addresses that packaging constraint by moving generated configuration into a dedicated directory that a deployment can mount separately. The base files stay in their original locations, while the entrypoint copies them into the writable configuration location before applying environment-derived settings.

The June 12 release page identifies the change as support for a configuration volume and a read-only root filesystem. The implementing patch supplies the operational detail. Read-only root does not mean the process never writes. It means the writable paths can be made explicit instead of depending on changes to the image's root filesystem.

I am interested in Cassandra where its operating model is necessary, and the surrounding maintenance tools are part of that decision. A container deployment constraint can prevent a useful tool from fitting an otherwise standard platform policy. This release makes the required write boundary more deliberate.

Startup creates the effective configuration

The entrypoint previously worked with /etc/cassandra-reaper/cassandra-reaper.yml directly. Version 3.6.1 copies that base YAML into /etc/cassandra-reaper/config/cassandra-reaper.yml. It similarly copies the base shiro.ini into the new directory. Configuration scripts then append their generated settings to those copied files.

That sequence separates the source of the defaults from the effective runtime file. The base file can come from the image or from an appropriately supplied deployment input. The process needs permission to read it and permission to write the copy, without requiring the two paths to share the same write policy.

The Java server command now reads the YAML from the new config directory. This final step is essential. Moving generated output is only useful if the application consumes that output, rather than continuing to start with the unchanged base file.

The schema-migration path follows the same copy and configuration sequence. A deployment running migrations separately therefore encounters the same new configuration location. The packaging change is broader than only the usual server startup branch.

Every configuration writer has to move

The patch updates persistence configuration, metrics configuration, and JMX credentials to append to the copied YAML. It also updates web UI authentication configuration. Generated Shiro settings move into the new directory, and the YAML reference to the generated shiro.ini changes to match.

That breadth matters because a partial migration can leave a startup script writing to the old read-only path. A server might work with one environment configuration and fail when authentication or metrics are enabled. The release changes the writers together so the effective file has one consistent location.

The patch also preserves an explicit Shiro configuration path supplied through REAPER_SHIRO_INI. A supplied path is different from the file the entrypoint generates for environment-based users. The implementation continues to distinguish those cases while relocating its own output.

I consider this more useful than merely adding a volume declaration to the image. The path used by each producer and consumer has to agree. Otherwise, the deployment can provide a writable directory and still fail because a script writes elsewhere or the server reads another file.

The image declares the new boundary

The released Dockerfile creates /etc/cassandra-reaper/config, assigns ownership to the Reaper user, and declares it as a volume. Existing volume declarations include the data directory and the separate Shiro directory. The image continues to run as the Reaper user.

Directory ownership in the image describes the default files the image supplies. A deployment that mounts another filesystem at that path still needs to provide permissions appropriate to the running user. Mounting a directory replaces what the process sees there, so the mount's permissions remain part of the deployment's contract.

The new directory holds generated configuration rather than a replacement application binary. Its lifetime can therefore be managed according to the startup behavior. The entrypoint copies base files before appending settings, which is relevant when deciding whether a deployment needs persistent storage for those generated files.

Read-only root is a write-placement policy

The change does not establish that configuration is Reaper's only possible runtime write. The Dockerfile also creates data, log, and temporary directories. A deployment using a read-only root filesystem must still account for writes required by its selected configuration and runtime.

That is the practical meaning of the release's support. The generated YAML and authentication file no longer require modification of their original image paths. Other writable locations remain explicit requirements to understand, rather than disappearing because the root filesystem is protected.

The same distinction applies to configuration secrets. Moving generated credential settings into a mounted directory does not remove the fact that the files can contain authentication material. The patch changes where the entrypoint writes those settings. Access to that directory should follow the deployment's existing treatment of its configuration inputs.

For me, the useful result is a container whose startup behavior better matches its filesystem policy. Base configuration can remain readable, generated configuration has a dedicated writable location, and both server and migration commands consume the resulting file. Reaper 3.6.1 makes that relationship visible in its entrypoint and image layout.