So what exactly is php artisan serve doing? I currently have a site up and running on apache and I am trying to get a websocket framework up for real time chat. The websocket is a php daemon that runs in the background and listens for events, see the package here.
So I am using the command
php artisan serve brainsocket:start --port=8080
to start the server and everything works great, however this only works while I have the terminal open and I have read in 3-4 SO posts that artisan serve is NOT to be used in production. So how can I run the laravel package start function on port 8080 without php artisan serve, and so that it will be persistent after I close the terminal?
I'm surprised this hasn't been answered yet.
In production you want to run a real web server like Apache or Nginx.
With Nginx you would use php-fpm as your runtime and you would proxy requests to it.
Here's an example from Nginx's website.
https://www.nginx.com/resources/wiki/start/topics/examples/phpfcgi/
Related
I make a simple server using Laravel for websocket purposes using Laravel-Websocket
The server managed to run well on Laravel Forge, it's just that I can't execute the php artisan websockets:serve command on deamon.
The error message I found is
Is there anything I miss in this case?
Thank you
I installed laravel-angular project according to its documentation.
I run php artisan serve command which is supposed to run the server. That is what happened.
But then I wanted to kill this server because I think it messed up with my existing apache configuration. And I found it problematic because there is no command for killing it. All the resource in the internet says that all you have to do is to CTRL + C to kill the process but I don't have it opened in my console any more.
It runs even after restarting my computer.
I removed the project sources from my disk hoping it will help. It didn't
Then I thought that probably artisan is running internal PHP dev server. I searched for it but this server also does not have any shutdown command - All you have to do is to CTRL + C the proccess in console. It didn't help.
Okay so I though I will look for process id somewhere - using netstat or task manager in windows. I did not find anything listening on :8000 port or any process that can be responsible for serving it.
Last try I had was to manually run php -s localhost:8000 - seems like it succeded to start. I added some file to current directory and I was able to run it through localhost:8000/filename.php
However when I killed it (I see this process everywhere - in task manager, in netstat etc), localhost:8000/filename.php does not work anymore but localhost:8000 (which is then redirected to localhost:8000/#/) still works.
It looks like it's not the server running but some redirection is added to my machine.
I would like to resolve the problem - get rid of this and have my apache working as expected.
It's because laravel-angular has service worker. Check in Network tab in Chrome shows that response for network requests came from service worker.
You may read more about them here - http://www.html5rocks.com/en/tutorials/service-worker/introduction/
I have an application which uses queues in order to send emails.
In a production environment, should I run the queue:listen command in the same application server where the application resides? Or should I do outsorcing?
So far,I've been in a dev environment working with two command lines, one for the php artisan serve command in order to get the application running and the other for the php artisan queue:listen command. If outsorcing is better for production environment, would I have to modify my code so I can work with Beanstalkd, Amazon SQS or another?
Reference Link ::
http://laravelcoding.com/blog/laravel-5-beauty-sending-mail-and-using-queues#14-about-queues
Helped me with my approach for sending notification message to gcm and to the registered mobiles.
I have a php codebase running in a vagrant vm running on a mac (OS X 10.10). I am trying to execute shell commands with exec(). The commands are evidently executed by the vm shell, but I would like the mac's shell to run it. How if possible could I achieve this? I know the other option is to run the php codebase directly onto the mac, but I was wondering.
Additional information somewhat relevant: The php codebase is Laravel 5 and the vm is Homestead. The reasons why I want to do this is to call an apple script from the mac's terminal in order to start a specific software.
Just share/mount a folder between the Host and the VM, and then you could create a cron job on the Host to read and run the commands from the VM.
First you write to a file from the VM any commands you have that need to be ran on the host. Then just create a cron job on the Host (Mac) that runs every few minutes or seconds checking the file to see if there are any new commands to run. The host acts like a listener, checking and waiting to pick up any commands from the VM, to run in the host environment.
I now have a stable Beanstalkd and Laravel 4 Queue setup running on one machine. My question is, how can I install the Laravel 4 workers on a second machine and make them listen to my Beanstalkd? Maybe a very obvious question to some but I can't figure it out. I noticed there was a connection field in the php artisan queue:listen command. Do I have to use that?
how can I install the Laravel 4 workers on a second machine and make them listen to my Beanstalkd?
You'll need to have a working instance of your laravel application on the same server as the listener/workers.
This means deploying your application both to the web server and to server that is listening for jobs.
Then, on the listening server, you can call php artisan queue:listen in order to listen for new jobs and create a worker to handle the job.
I noticed there was a connection field in the php artisan queue:listen command. Do I have to use that?
On top of the above question, and similar to most artisan commands, you will likely also need to define which environment the queue:listen command should use:
$ php artisan queue:listen --env=production
In this way, your laravel app that is used to handle the workers (the app on the listening server) will know what configurations to use, including knowing what database credentials to use. This also likely means that both the web server and your job/listening server needs to have access to your database.
Lastly, you could also create 2 separate Laravel applications - One for your web application and one purely to handle processing job. Then they could each have their own configuration, and you'll have 2 (probably smaller?) code bases. But still, you'll have 2 code bases instead of 1.
In that regard, do whatever works best for your situation.