Strategy for caching config in multi-container deployed apps with blue green deployments?

[macropay-solutions]

This issue #55028 gave us the idea of this question.

Until now we did not found a perfect strategy in using cached configs.

Reasons:

• In blue green deployments, both old and new containers work in parallel for a while so, in that time the configs can't be cached as they could differ from deploy version to deploy version.
• After a deploy is successful and all old containers are killed, if the containers become unhealthy, they will be killed and last working image will be deployed (that could have other configs).
• The cache of all containers must be/is shared to not duplicate the cache N times (and also to allow sticky sessions just as an example).
• Just as a note, if you use elasticsearch logging for example the config will contain callback that can't be cached.

Based on this we evaluate caching the configs impossible in this scenario.

Funny thing is that the community pays attention to the time gained by caching the configs but disregards the time lost by using reflection on each class that supports php attributes, even if they are not used and even suggesting octane as a solution.

So, can anyone present e bulletproof solution for config caching in the above scenario?

Update.

config:cache merges all configs in 1 file and has nothing to do with Cache facade.

[Sophist-UK]

After a deploy is successful and all old containers are killed, if the containers become unhealthy, they will be killed and last working image will be deployed (that could have other configs).

This is your problem - the rest of the deployment process is designed to avoid config mis-matches and this roll-back is what breaks this process.

[macropay-solutions]

Of course it's our problem, that is why we never cache configs to avoid headaches.

[mbabker]

This sounds like you're sharing the result of artisan config:cache between deployments. I wouldn't do this. Anything cached through the artisan optimize command IMO is a deployment-specific cache resource (as the same issue you're describing exists if views change between deployments, or the router) and shouldn't be shared across deployments.

[macropay-solutions]

So you say we should not use the same cache for all containers but use the file cache?
If yes then we might ask: Is laravel designed just for old school shared deploys?

Imagine we spin up 10 containers. How would we setup a separate memcache for each of them when they are supposed to be exact clones of each other , including their envs? (not to mention that not caching the config is easier).

[mbabker]

If you're talking about persistent cache shared across servers/deployments (stored in Memcache, Redis, etc.) then that requires other considerations (and I'll generally just go invalidate the caches when needed for that because we don't have many cases of a deployment breaking persistent cache).

If you're talking about config cache, which is really just a snapshot of the config service with all the env vars resolved, then yeah, that is just local filesystem cache because that data should only need to be read once (when the deployment is provisioned) and the cached output shouldn't be shared with other deployments/instances.

[macropay-solutions]

If the config could be cached in file(in the container) and the Cache facade could work with memcache (shared across all containers) then that could be a solution. If that is the case, can you please share a solution?

[mbabker]

The config:cache command generates a file at bootstrap/cache/config.php, it doesn't use the framework's cache component at all. Caching the config (or any of the caches warmed up through the optimize command) has nothing to do with data cached using the Cache component, think of it more as a "cache this data that shouldn't change over the lifetime of a deployment" warmup step as you push a deployment live.

Where this could cause problems is if you're caching the config at a point before the real values are set, i.e. something's being configured by an env var but those env vars aren't set in your build process; the config:cache command in Laravel is just a simple var_export($config, true) to that file, so it's dumping the fully resolved config. If you're running other *:cache commands (event or route cache) then you already have similarly purposed files in that bootstrap/cache directory.

[macropay-solutions]

@mbabker Thank you. If that is documented somewhere we missed it. If not, then it should.
For us, cache was the same thing until now.

[macropay-solutions]

@mbabker we can't find online the time gained by cashing (merging all config php files into just 1 file) as this is not a cache in memory.

But, if JIT and opcache are used, this "cached" file and/or also the normal config files will be kept in memory by opcache and JIT so, the question is: Is it worth the effort? Valid also for routes.

Update
it was documented

But the File part was missed between the lines.

An ugly code to load all .env variables in config would be:

/config/env.php

<?php

return \array_map(fn(mixed $val): mixed => \array_key_exists($val, $map = [
    'true' => true,
    'false' => false,
    'null' => null,
]) ? $map[$val] : $val, $_ENV);

and then config('env.EXAMPLE_VARIABLE') would be equivalent with env('EXAMPLE_VARIABLE');

[macropay-solutions]

We noticed something when implementing config:cache and route:cache in lumen that is valid also for laravel 12.

\Illuminate\Foundation\Application::normalizeCachePath

    protected function normalizeCachePath($key, $default)
    {
        if (is_null($env = Env::get($key))) {
            return $this->bootstrapPath($default);
        }

        return Str::startsWith($env, $this->absoluteCachePathPrefixes)
            ? $env
            : $this->basePath($env);
    }

The env is called multiple times

and if the configs are cached it will return null making those APP_... envs useless.

First we thought that config:cache should be called last but then we figured out that this is called on each request to check if there are cached files.

This might be considered a bug but, because the config might not be loaded when this function is called, using something like:

Env::get($key) ?? config('env.' . $key)

will not work.

[macropay-solutions]

To answer the question what benefit can bring config and route caching we made a test.

While calling last route out of more than 500 routes in a lumen project:

$router->get('/jahdlkjdkjdlkw[/{id}]', [
    'as' => 'version',
    'uses' => 'VersionController@version',
]);

No db calls involved just printing the version:

public function version(): Response
{
    return \response(\app()->version(), 200)
        ->header('Content-Type', 'text/html');
}

85-109 ms no config or route cache
vs
62-77 ms with cached config and cached route

So 27-29% improvement.