Soy agricultor y evado la transición final a Linux en mi PC de todas las formas posibles, a pesar de todas sus ventajas. Por lo tanto, en los últimos años usé Docker para Windows para crear plataformas locales para proyectos. No quiere decir que la cosa sea súper estable, pero no causó problemas significativos hasta que en un proyecto en Laravel el sitio comenzó a comportarse de manera extraña:
algunas solicitudes (y siempre partes
diferentes ) regresaron con un error. El script no pudo abrir el archivo de caché.
Después de pasar una buena cantidad de tiempo buscando una razón, decidí en este caso abandonar Docker e implementar la plataforma bajo WSL en modo manual.
Como WSL es
casi Linux, es decir - En realidad no, el entorno tiene sus propias características.
Después de instalar MySQL, nginx y php7.2 desde bash, se configuró un servidor virtual en nginx y todo esto se negó a funcionar. Los registros nginx tenían esta entrada:
connect() to unix:/var/run/php/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream
En WSL, que yo sepa, no hay sockets como tales, así que tuve que hacer lo siguiente:
- abra el archivo /etc/php/7.2/fpm/pool.d/www.conf para editarlo y corrija el valor de la directiva de escucha
; listen = /run/php/php7.2-fpm.sock ; old value listen = 127.0.0.1:9000 ; new value
- establecer el mismo valor en la configuración del servidor virtual nginx
location ~ \.php$ { ... fastcgi_pass 127.0.0.1:9000; ... }
Esto dio una especie de servidor de trabajo. Parece porque cada solicitud procesada ooooooooooooooooooooooooooooooooooooooooooooooo Ya en el límite de tiempo más. Para deshacerse de los frenos, como resultó, debe agregar una línea al archivo /etc/nginx/nginx.conf
http { ... fastcgi_buffering off; ... }
Después de eso, el sistema despegó y hasta ahora se siente genial.
→ Las recetas descritas se encontraron
aquíPD : descubrí de alguna manera una
forma de lanzar un montón en los sockets, pero aún no lo he verificado. Y
uno mas .