Fortress on Ymir

[calvinalkan]

This discussion will be a work-in-progress to discuss the optimal Fortress configuration on Ymir.

The purpose is to later merge this into a "Guide" in the Ymir Docs.

[calvinalkan]

Configuration Cache and Log Files.

Fortress cannot build its cached configuration file on Ymir since it's read-only.

This will throw an exception, since Fortress expected the log/cache directory to be existing and writable.

There are three ways to handle this:

1. Use /tmp as a log/cache directory | doesn't work

$_SERVER['SNICCO_FORTRESS_CACHE_DIR'] = '/tmp'
$_SERVER['SNICCO_FORTRESS_LOG_DIR'] = '/tmp'

/tmp is the only writable directory on lambda.

Downsides:

• The cache is rebuilt for each new lambda instance (might not be relevant).
• Possible file name conflicts with existing files in /tmp (unlikely)

2. Use /tmp/fortress as a log/cache directory

if(!is_dir('/tmp/fortress')) {
   mkdir('/tmp/fortress/cache', 0755, true);
   mkdir('/tmp/fortress/log', 0755, true);

} 

$_SERVER['SNICCO_FORTRESS_CACHE_DIR'] = '/tmp/fortress/cache'
$_SERVER['SNICCO_FORTRESS_LOG_DIR'] = '/tmp/fortress/log'

Downsides:

• The cache is rebuilt for each new lambda instance (might not be relevant).
• One additional "is_dir" check for each request (unless Ymir can bake this into the docker runtime).

3. Deploy cached configuration files

Lastly, it's possible to deploy a cached configuration that was built locally.

There are currently no env (db, server, filesystem) related configuration settings in Fortress; a local configuration should always be reproducible remotely.

This would mean the Fortress configuration cache must be put into version control and included in the Ymir deployment.

The build step should include the following:

id: 1
name: project-name
type: wordpress
environments:
  environment-name:
    build:
      - 'composer install'  # Install Fortress via composer
      - 'wp snicco/fortress cache:clear && wp snicco/fortress config:test --reload-on-success' # Clear current cache & rebuilt sources

$_SERVER['SNICCO_FORTRESS_LOG_DIR'] = '/tmp'

Downsides:

• The cache directory is directly accessible from the webroot in wp-content/mu-plugins/snicco-fortress/var/cache/

[pmgarman]

This code is 48 microseconds

if(!is_dir(Config::get('SNICCO_FORTRESS_CACHE_DIR'))) {
	mkdir(Config::get('SNICCO_FORTRESS_CACHE_DIR'), 0755, true);
}

if(!is_dir(Config::get('SNICCO_FORTRESS_LOG_DIR'))) {
	mkdir(Config::get('SNICCO_FORTRESS_LOG_DIR'), 0755, true);
}

This code is 480microseconds

mkdir(Config::get('SNICCO_FORTRESS_CACHE_DIR'), 0755, true);
mkdir(Config::get('SNICCO_FORTRESS_LOG_DIR'), 0755, true);

mkdir will succeed even if the directory already exists, so I figured I'd check if it was any more efficient to just let it roll, but it's a lot slower.

[pmgarman]

Re: the docker image. The ymir runtime just uploads the application ZIP, I don't know that it can create directories in /tmp on boot. Though it's possible for sites to move to a container on Lambda via Ymir... in which case they absolutely can do anything they want.

[calvinalkan]

The ymir runtime just uploads the application ZIP, I don't know that it can create directories in /tmp on boot.

I think Carl could add that upstream in Ymir. Might be wrong. @carlalexander

so I figured I'd check if it was any more efficient to just let it roll, but it's a lot slower.

That's odd, but hey.

I think what's more relevant is how long it takes to "build" Fortress's cached configuration(s).

Right now, it's very fast because we only perform syntax validation, but I'm working on deep semantic validation of all values right now, which is built with the assumption that the configuration is NOT rebuilt on every request.

Before we go down this path further, @carlalexander Can you give insight on how requests/second correlate to "clean" lambda invocations?

How often would we get a clean filesystem?

[calvinalkan]

Worst case, I can add an abstraction for the cached config storage/retrieval, allowing either Filesytem or Redis.

[carlalexander]

@pmgarman You should use container image as a default. It's just flat out better. I don't make default because:

1. Didn't exist at first so to maintain BC I keep zip default
2. WordPress devs and Docker 🫠

@calvinalkan It really depends. It's not a request per second thing. It's the maximum # of invocation per lambda. So could take you a minute or two to hit it or a hour or never because the lambda gets destroyed. By default, the maximum # of invocations is 100. But it can be changed via an environment variable. This is also useful with Relay since you lose the in-memory cache whenever the lambda gets destroyed. So I had a customer ask to be able to change it.

[calvinalkan]

Fortress Secrets

Fortress's Secrets should be Ymir ENV secrets.

Fortress secrets can be generated to stdout by running:

php /path-to-fortress-locally/bin/prod/generate-secrets.php

The output of this command can then be piped (with some xargs magic) to ymir environment:secret:change

Secrets must be generated per ymir environment before Fortress is deployed.

Secrets must never be changed after creating them in one env.

[calvinalkan]

@carlalexander

Also, I don't know how people currently use different Ymir ENVs regarding staging => production workflows.

But if there ever is a scenario where somebody pushes staging DB => prod DB, the secrets must be the same on both sites.

Otherwise 💣

[carlalexander]

That's a more challenging issue because secrets are kinda one way. I can't get them back for you. They'd probably need to keep copies somewhere safe (e.g. 1password) to make sure they can add them to new environments if they create some after the fact.

[calvinalkan]

@carlalexander

Right, either store them somewhere safe or generate them once for all environments you forsee using.

That said, is that workflow even a thing on Ymir?

Pushing staging DB to prod DB?

[carlalexander]

Not right now, but it will one day 🥹

[calvinalkan]

Sounds like a problem for future carl and calvin.

I can always create a secrets:list CLI command if needed.

[pmgarman]

Static Assets

When ymir deploys your site, it by default strips out any non php assets, including JSON files.

NOTICE: PHP message: PHP Fatal error:  Uncaught RuntimeException: Cant read file contents of file [/var/task/web/app/mu-plugins/snicco-fortress/vendor/snicco/psr7-error-handler/resources/en_US.error.json] in /var/task/web/app/mu-plugins/snicco-fortress/vendor/snicco/psr7-error-handler/src/Information/InformationProviderWithTransformation.php:49

In the ymir.yml adding something like this seems to resolve it. There are multiple json files in Fortress that are required to exist for the plugin to function. Examples, the JSON file from above, as well as the manifest file snicco-fortress/public/manifest.json - I'm not sure all the files, some come from vendors, so just requiring the whole plugin while a sledge hammer approach, likely solves for all cases...

environments:
  staging:
    build:
      include:
        - web/app/mu-plugins/snicco-fortress

[calvinalkan]

Yea, there are some non PHP files in Fortress, and some in vendor.

[calvinalkan]

Also, make sure you include your custom configuration file.