Skip to content
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

Add command to restart node after the build #468

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

apfelbox
Copy link

Hi,

right now the Next.js process starts with the outdated build and will fail in production (like not being able to load the assets).
That is why you need to restart Next.js at the end of the deployment once.

@apfelbox
Copy link
Author

The whole handle_mounts script can be updated to just a few way simpler lines in the hooks. Also you should add a separate mount for the next image cache, that is then linked into .next/, so that you don't wipe your generated images cache after every deployment (as regenerating the images is really CPU intensive).

Would you be open for a PR restructuring it a bit?

@achton
Copy link

achton commented May 16, 2024

@apfelbox Is this a better way to restart than what is in #82 ?

Regarding the handle_mounts.sh script, we have found the same issue, but for .next/cache/fetch-cache. I am contemplating separate mounts as you outline. Do you have a suggested approach or example?

Also, I don't think PSH follows these repos, so it may be better to just share our solutions here 😶

@apfelbox
Copy link
Author

apfelbox commented May 16, 2024

@achton, yes this case is much better than #82, because the other one has a race condition:

Platform.sh starts up Next.js and then runs the deploy hook. However, Next.js has a bootup time and doesn't immediately listen to the port (depending on your application this is shorter or longer), so you might run into a case where lsof -t -i:$PORT just returns nothing, as Next.js is not up yet.

We had this case very reliably in one of our applications. Using systemctl is way more robust, as it works in any case.
Also directly using systemctl might make it in general marginally safer and faster, as it doesn't have to detect that the process was killed.

On your mounts question, we always have this setup, which is basically just the inlined calls. They are small enough:

mounts:
    '/.next':
        source: local
        source_path: 'next'
    '/.next-image-cache':
        source: local
        source_path: 'next-image-cache'

And then

build: |
    # ...

    # Keep build files out of reach
    mkdir -p .build/.next
    mv .next/* .build/.next

deploy: |
    set -x -e

    # Move stored files back
    rm -rf .next/*
    cp -r .build/.next/* .next

    # relink image cache dir
    rm -f .next/cache/images
    ln -s ../../.next-image-cache .next/cache/images

    # restart node
    systemctl --user restart app

The deploy hook is actually exactly the same as in all of our applications.
This setup is pretty simpel and works really well for us.

If you need to add more caches (like the fetch cache), you might need to adapt either the mount or add some more. In our case & architecture it's fine to start with a clean slate when deploying, but YMMV.

@achton
Copy link

achton commented May 17, 2024

@apfelbox Thanks for your input. we also did not use the lsof-based approach, but did this: kill -15 $(pgrep next-server | head -n1) .. in the post-deploy hook. 😂
Will give your approach a go.

We have also ditched the handle_mounts.sh script and symlink the relevant .next/cache subfolders as per your suggestion, thanks 👍🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants