Skip to content

Change default cache dir to match kamal config #72

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bendangelo opened this issue Oct 5, 2024 · 0 comments
Open

Change default cache dir to match kamal config #72

bendangelo opened this issue Oct 5, 2024 · 0 comments

Comments

@bendangelo
Copy link

By default kamal doesn't allow writing to the public dir. I recommend changing the default dir to something writable when using the default dockerfile and kamal.

  config.action_controller.page_cache_directory = Rails.root.join("tmp", "cached_pages")

Workds better.

High5Apps added a commit to High5Apps/organize-backend that referenced this issue Jan 25, 2025
- Add dependency on actionpack-page_caching
  - https://github.com/rails/actionpack-page_caching
- Needed to `chown` the `public` directory from `root` to `rails` to prevent a permissions error when the page cache attempted to read or write to the cache files
  - `Errno::EACCES (Permission denied @ rb_sysopen - /rails/public/blog.html)`
  - rails/actionpack-page_caching#72
- Despite the wiki below stating that I'd need to update my nginx.conf to serve the cache files, that step was not strictly required, since `config.public_file_server.enabled` is true by default.
  - https://github.com/rails/actionpack-page_caching/wiki#nginx
  - https://guides.rubyonrails.org/configuring.html#config-public-file-server-enabled
  - I confirmed via logging and inspection of the csrf token that the cached pages are successfully served without the rails server recreating the page (after the first time).
  - In a follow-up commit, I will disable the rails public_file_server flag in favor of nginx serving those public files
- I verified that the entire page cache is effectively invalidated on redeployment/recreation of the site container. Since the public folder is not backed up to any named volume, all changes made to it while the container is running (e.g. page cache entries) are blown away when the container is recreated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant