8000 Symfony's capability to run on read-only out of the box · Issue #21 · brefphp/symfony-bridge · GitHub
[go: up one dir, main page]

Skip to content
Symfony's capability to run on read-only out of the box #21
@Nemo64

Description

@Nemo64

I kind of started this library by positing my code which copies cache files.

But #17 (comment) made me check again and realise that symfony (4.4) works without modifications if the cache is properly warmed and configured.

So I investigated.

setup

I use a symfony multipage application which i'm not totally comfortable to share (it is a real project) but its a symfony 4.4 skeleton with doctrine/orm and a user entity in a crud for user as well as some email handling

I changed the following files for logging:

# config/prod/monolog.yml
monolog:
    handlers:
        main:
            type: stream
            path: "%env(resolve:LOG_FILE)%"
            level: debug
        console:
            type: console
            process_psr_3_messages: false
            channels: ["!event", "!doctrine"]
# .env
# this is for local development as usual
LOG_FILE=%kernel.logs_dir%/%kernel.environment%.log
# serverless.yaml
provider:
  # [...]
  environment:
    LOG_FILE: php://stderr

And for completeness I changed the cache directory:

# config/packages/cache.yaml
framework:
    cache:
        directory: '/tmp/pools'

It's important that the directory option only changes the directory of the cache.adapter.filesystem (defined here) and not the cache.adapter.system which is the cache we warm.

I also note that I test using symfony 4.4.7 with php 7.3 so not the newest setup but a realistic one.

result

It seems to work ok.

I have a lot of warnings in the log from not being able to write like these:

[2020-04-12T21:30:21.967332+02:00] cache.WARNING: Failed to save key "isWritable.a%3A3%3A%7Bi%3A0%3Bs%3A50%3A%22Symfony%5CComponent%5CSecurity%5CCore%5CUser%5CUserInterface%22%3Bi%3A1%3Bs%3A5%3A%22roles%22%3Bi%3A2%3Ba%3A0%3A%7B%7D%7D" of type boolean: file_put_contents(/var/task/var/cache/prod/pools/nkosAA2WOE/5e936c4de02108.84920836): failed to open stream: Read-only file system {"key":"isWritable.a%3A3%3A%7Bi%3A0%3Bs%3A50%3A%22Symfony%5CComponent%5CSecurity%5CCore%5CUser%5CUserInterface%22%3Bi%3A1%3Bs%3A5%3A%22roles%22%3Bi%3A2%3Ba%3A0%3A%7B%7D%7D","exception":"[object] (ErrorException(code: 0): file_put_contents(/var/task/var/cache/prod/pools/
6271
nkosAA2WOE/5e936c4de02108.84920836): failed to open stream: Read-only file system at /var/task/vendor/symfony/cache/Traits/FilesystemCommonTrait.php:96)"} []

These warnings appear when a form is accessing an Entity. I found this issue talking about it.

Other than that I can't find any immediate issues. The console works fine too.

So what's are we doing here?

When I started using symfony I could not get my project to work on a read-only filesystem (I don't know why anymore). I used the documentation which had the rewriting to the /tmp folder in it but that was too slow for my taste so I started to copying the cache to tmp with some exception wich is the state this library is at right now.

Now that I know that symfony almost works out-of-the-box I would probably choose a different path.
One could overwrite/decorate the cache.adapter.system service (maybe even in a normal bundle) to include overlay logic and to my current knowledge it would work perfectly.

Now there are still advantages to the copy approach here: It works in every case, even when the cache isn't warmed or isn't properly warmed. It even works in dev mode with profiler as long as you didn't deploy the profiler folder. Even though you will get problems when multiple lambda instances are running there. The question is if that is important enough.

  • If you don't plan to build cache or plan on debugging in dev mode, the simple "put everything in tmp" is simple and fine (you monster).
  • If you do plan on warming the cache then you probably have a CI to help you so the incomplete cache isn't really a problem. In that case it might be a much more elegant idea to patch the system and filesystem cache and not copy anything. This would also be possible in a normal bundle, maybe something general like a read-only-bundle which writes to sys_get_temp_dir.

Opinions? Did I overlook something?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0