[💡FEATURE REQUEST]: A command to refresh working dir (re-resolve symlink)

[klkvsk]

Is your feature request related to a problem? Please describe. A popular automatic deployment technique is to upload each release in separate folder, then switch symlink that points to latest one, like so:

app/
  releases/
    v1/
    v2/
  current/ -> releases/v2/ 

Switching symlink is "atomic", it helps to prevent problems when you get requests while uploading new release. At this time, roadrunner does not allow that technique, due to symlink being resolved only at startup.

Describe the solution you'd like A new command / signal to reread symlink and update working dir, then restart workers. Or just do this in http:reset.

Describe alternatives you've considered Simply stop-starting it isn't suitable for production. Non-downtime alternative way would be to run multiple instances of rr on multiple ports, using balancer in front, and restarting them one-by-one. Not easy.

[rustatian]

@klkvsk Ok, I see your problem. We will discuss it with @wolfy-j, thanks for the proposal.

[wolfy-j]

@rustatian I think it's a great idea but wonder if it already should be working since the link should be resolved by PHP interpreter at start...

[wolfy-j]

We are going to do something very crazy in 2.0 to solve it.

[make-it-git]

Does it work in some way? Is there any workaround?

[rustatian]

@make-it-git You can restart the server to re-resolve the path.

[make-it-git]

@rustatian But it causes downtime. Hundreds of http requests in my case might be lost.

[rustatian]

Will be resolved after all plugin moved to the RR2. Sorry for the inconvenience.

[rustatian]

@rustatian But it causes downtime. Hundreds of http requests in my case might be lost.

You can use green-blue or canary deployments and the moment to switch w/o downtime.

[make-it-git]

Is there any workaround exist? I use nginx as frontend facing application and looking for solutions based on nginx load balancing features.

[rustatian]

I'm not very familiar with the nginx, but as I mentioned, you may try to use green-blue or canary deployment strategies.

[rustatian]

Also, take into account, that RR1 was deprecated and will not receive future updates.

[rustatian]

Also, I'm not sure, that this feature should be resolved on the server side but not on the DevOps.

[gemini133]

To reload all RoadRunner services:
$ rr reset

hi @rustatian does this command above resolve this problem? and will it cause downtime?

[rustatian]

Hey @gemini133. The command above resets workers (replace old workers with the new). This operation doesn't cause downtime. However, this reloads only workers, but not the configuration (.rr.yaml).

[gemini133]

Hey @gemini133. The command above resets workers (replace old workers with the new). This operation doesn't cause downtime. However, this reloads only workers, but not the configuration (.rr.yaml).

it'll re-resolve the symlink though?

[rustatian]

it'll re-resolve the symlink though?

No, configuration by the symlink won't be re-resolved. So, if you change the worker code by the path specified in the configuration it'll be resolved, but not the configuration itself. To do that, you should restart the RR and that will cause downtime if you don't use blue-green/canary deploy approaches.

[gemini133]

okay, thanks for clarification

[rustatian]

To refresh symlinks, you'll need to restart RR anyway, unfortunately. But since RR supports the SO_REUSEPORT optimization, you may start the second RR instance with the new configuration and stop the first one. In this case, all requests will be redirected by the OS to the second instance while the first one finishing processing the rest and would be then stopped.