var/cache and read-only filesystems: is this use case supported?

[mantassimkunas]

The Symfony docs have the following passage:

The var/cache/ directory must be writable by the web server user if you use a filesystem-based cache.

However, there are discussions about supporting read-only filesystems, as well as reproducible builds:

• [Question] Isn't making /var/cache read-only ironic? flex#144
• Add var/tmp / $kernel->getTmpDir() #23354
• [HttpKernel] Add $kernel->getBuildDir() to separate it from the cache directory #36515
• Nondeterministic cache builds (making /var/cache directory contents to stay the same unless it has to change) #39820

To my understanding, one of the indirect benefits of reproducible builds is that you are not required to build the system cache during runtime because you can prebuild the cache in advance, bake it into a Docker image, and then deploy your application without having to warm up the cache during runtime.

The docs referenced above seem to contradict such use cases because they require the web server user to have write access to the var/cache directory. Such wording seems to rule out use cases where a different user precompiles the system cache and container in a build environment, and this prebuilt cache is then used in a read-only filesystem after deployment.

Are the docs out of date?

[mantassimkunas]

As an addendum, I am aware that Symfony supports setting a different build directory for precompiled files, such as annotations, the container, etc.

However, this doesn't include data such as the system cache pool, which is stored under var/cache even though it never expires.

[mbabker]

To my understanding, the goal is to make the Kernel's build directory a path that can be read-only once the environment is warmed up and the cache directory is writable for runtime resources. The kernel continues to default to using var/cache for the build directory, but you can overload this if desired:

class Kernel extends BaseKernel
{
    use MicroKernelTrait;

    public function getBuildDir(): string
    {
        return $this->getProjectDir().'/var/build/'.$this->environment;
    }
}

Symfony 7.1 defaults the router's cache data to use the build directory, and the most recent DoctrineBundle recipe sets the path for the generated proxy files here as well. So if you do overload this, more things will dump to that path by default, but there are still some cache configs that need to be updated (and I know there are some PRs open targeting 7.2 for this).

I'm personally moving forward with the assumption that var/cache should always be writable for any runtime needs (i.e. filesystem-based cache pools, the profiler cache in the dev environment, or other runtime caches from third-party tools) and that anything that can be pre-built should eventually go to the Kernel's build directory (whether that be the default var/cache or an overloaded path that's meant to be read-only like the example above).

[mbabker]

I'd consider every cache pool to be runtime read-write, regardless of its storage location.

It's been a while since I read through some of this, but to my recollection, the system cache pool should be data that is tied to a specific deployment and needs to be re-cached with each deployment. There is some stuff that absolutely can be written to that cache pool at build time, but with the default recipes, there will also be data that gets written there at runtime. One very notable example is the Doctrine query cache (the cache for DQL to SQL transformations) which uses the system cache in production, and cannot be warmed up at build time because there just isn't a sane way to do that.

Generally, stuff written to that cache pool should have no expiration, but only within the context of the current deployment, so it is a write-once type of thing, but still needs to be writable at runtime for those cases where it can't be warmed up sooner.

[mantassimkunas]

When does Doctrine store this data? Does this need to be configured explicitly? I'm currently storing var/cache in a read-only filesystem but I've never had an issue with Doctrine here.

[mbabker]

Do you have a query cache configured? If your config is similar to the recipe, then the query cache should be using the system cache pool for that. On a quick scan in the ORM code, it doesn't look like any issues writing to the cache will trigger a fatal error, so it seems it'll work fine with an unwritable cache but waste CPU cycles constantly trying to write to it and maybe logging those failed writes.

[mantassimkunas]

Thank you, that's enlightening. So it looks like I should be specifying a build directory for all precompiled stuff (e.g. via APP_BUILD_DIR). I imagine that the contents of this directory are generated using the same cache:clear command?

[mbabker]

Correct.