I have a Laravel Web Application, and it works just fine locally, using a local .env file that references the local database.
I have the same Laravel Web Application deployed in production, where I find a .env, which is different from the one that I use locally.
Both the scenarios work perfectly, but when I wanted to perform a test with the remote database (that I can access from my local IP address), I copied the remote .env and renamed it .env.production.
How can I run the php artisan serve using the .env.production ?
The php artisan serve help states that adding a --env parameter should make the trick, as you can see from the command result below
php artisan serve --help
Description:
Serve the application on the PHP development server
Usage:
serve [options]
Options:
--host[=HOST] The host address to serve the application on [default: "127.0.0.1"]
--port[=PORT] The port to serve the application on
--tries[=TRIES] The max number of ports to attempt to serve from [default: 10]
--no-reload Do not reload the development server on .env file changes
-h, --help Display help for the given command. When no command is given display help for the list command
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
--env[=ENV] The environment the command should run under
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
but the command php artisan serve --env=production still loads the local database.
What am I doing wrong ?
After some tests I found a working solution in a Laracast Forum, giving credits to a Laravel.io post that consists into running the following command:
APP_ENV=production php artisan serve
This causes the .env.production to be loaded and used by the local server, as needed.
I post this here hoping it will be useful to someone in my same condition.
Related
I want to test some Laravel applications on my basic shared host.
Currently I just upload my complete application including the vendor files, however this takes quite long.
Since I do not have ssh access to my host I'd like to know whether there's an option to run composer / artisan commands without this.
I found this link: Use Composer without ssh access to server (Second Answer) which describes how to run composer using http://phpshell.sourceforge.net/
However, I can change folders in the console etc. But I cannot run php commands - I always get internal server error.
Check if your shared hosting provider has console feature in their CP which allows to run shell commands. Maybe you'll be able to run commands from there.
As alternative, you could right your own artisan runner and call artisan commands from the code:
Artisan::call('migrate');
To run composer command from PHP code, use shell_exec:
shell_exec('composer update');
I have a problem with runing Laravel's Artisan. There are most of the commands missing. Everything worked fine till the last composer/code update.
For an example if I write php artisan migrate, I get following error: Command "migrate" is not defined.
Below is an example of output that I get by typing php artisan.
Laravel Framework version Lumen (5.1.6) (Laravel Components 5.1.*)
Usage:
command [options] [arguments]
Options:
-h, --help Display this help message
-q, --quiet Do not output any message
-V, --version Display this application version
--ansi Force ANSI output
--no-ansi Disable ANSI output
-n, --no-interaction Do not ask any interactive question
--env[=ENV] The environment the command should run under.
-v|vv|vvv, --verbose Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug
Available commands:
help Displays help for a command
list Lists commands
serve Serve the application on the PHP development server
schedule
schedule:run Run the scheduled commands
Does anyone have any ideas how to fix this?
It seems there was a problem with composer. Somehow composer.lock got into git ignore list and libraries used on production were different than the ones used in development.
The syntax has changed to php artisan make:migration.
You can see a full list of commands by running php artisan list
For previous versions of Laravel, you can simply download laravel with composer in the root folder of your apache server and type in http://localhost/public/ to see the "You've arrived" homepage.
I know I can use php artisan serve to view the Laravel5 default home page, but it is run on localhost:8000 and I heard that php artisan serve command should not be used in production due to the limit of connection and the bad performance. Is there a way I can see the default home page without using the php artisan serve command?
And it is really frustrating that Laravel is not including such simple thing in their installation documentation....
To run the service on another port you need to pass the port parameter with port numberusing this code on the cmd:
php artisan serve --port=80
To run on port 80, you might need administrator permission.
You may have to use sudo command for admin rights.
sudo php artisan serve --port=80
I have a jenkins build job of my symfony2 project that uses grunt to start the php built in webserver so that casperjs can run functional tests against it.
To start my webserver I'm using the following command:
php app/console server:start --router=" + __dirname + "/app/config/router_test.php --env=test 0.0.0.0:9001"
However the build fails with the following message:
A process is already listening on http://0.0.0.0:9001.
Thus I have SSHed to the jenkins box and run:
netstat -tln | grep 9001
Only to get no results?!
I have restarted the server and killed all php processes, disabled iptables however none of this seems to work.
This build used to work and in the last change, all that was added were more functional tests.
Has anyone got any ideas why this could be happening?
As commented, the fix that worked for me was to change the workspace directory. Seems to have been a permissions issue with the workspace folder that jenkins created yet a chmod 777 didn't resolve it hence the new workspace folder.
I have a Laravel installation and have set up three environments with their own corresponding config directories:
local
staging
production
I use php artisan migrate:make create_users_table etc as described here to create database migrations.
In my local environment I use Vagrant and a simple MySQL server setup, and on staging & production I use AWS RDS.
To configure database access for the staging environment I have a app/config/staging/database.php file with settings like this:
...
"mysql" => array(
"driver" => "mysql",
"host" => $_SERVER["RDS_HOSTNAME"],
"database" => $_SERVER["RDS_DB_NAME"],
"username" => $_SERVER["RDS_USERNAME"],
"password" => $_SERVER["RDS_PASSWORD"],
"charset" => "utf8",
"collaction" => "utf8_unicode_ci",
"prefix" => "",
),
...
I use git to deploy the app with git aws.push as described here.
The question is: How do I run the migration on my staging (and later production) EBS server when deploying?
I solved it by creating a new directory in the root of my project named .ebextensions. In that directory I created a script file my-scripts.config:
.ebextensions/
my-scripts.config
app/
artisan
bootstrap
...
The file my-scripts.config gets executed when EBS deploys, is a YAML file and looks like this:
container_commands:
01-migration:
command: "php /var/app/ondeck/artisan --env=staging migrate"
leader_only: true
Add the directory and file to git, commit, and run git aws.push and it will migrate.
Explanations on how stuff in .ebextensions works can be found here.
The path /var/app/ondeck is where your application lives when your script runs, it will afterwards be copied into /var/app/current.
The artisan option --env=staging is useful for telling artisan what environment it should run in, so that it can find the correct database settings from app/config/staging/database.php
If you need a quick and dirty way to log why the migrate command fails you might want to try out something like "php /var/app/ondeck/artisan --env=staging migrate > /tmp/artisan-migrate.log" so that you can log into your ec2 instance and check the log.
After oskarth answer, some instructions might had been changed in the past few years on how AWS Elastic Beanstalk deploys a new application version. According to the AWS documentation related to the container_commands of .ebextensions, case the "cwd" option is not set, the working directory is the staging directory of the unzipped application. It means that the user under the instance during the deployment process will be positioned at /var/app/staging/, where the extracted source version of the application is. Therefore, the artisan command can be executed either alone or following by var/app/staging/ path instead of /var/app/ondeck/ like this:
container_commands:
01-migration:
command: "php artisan --env=staging migrate"
leader_only: true
or this
container_commands:
01-migration:
command: "php /var/app/staging/artisan --env=staging migrate"
leader_only: true
I have deploy my project using the both configurations above. I discovered that after hours looking at the eb-engine.log file and reading the documentation over and over again. I hope anyone take so long as well after reading that. The logs can be accessed throw the eb logs command on terminal, on the environment console or through the S3 bucket associated to the environment. There is pretty much everything in the documentation explained. I didn't comment it on the oskarth answer I'm not allowed yet!
ps. the /var/app/staging path has no relation with the staging environment in laravel.
Worth mentioning here if people are using a dockerised container to run their application on Beanstalk, you will have to run this inside the container.
files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/98_build_app.sh":
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
echo "Running laravel migrations" >> /var/log/eb-activity.log
docker exec $(docker ps -qf name=php-fpm) sh -c "php artisan --env=staging migrate --force || echo Migrations didnt run" >> /var/log/eb-activity.log 2>&1
The problem is the container name changes each time.
So the docker ps -qf name=php-fpm part is just going to get a container with the container name containing php-fpm. So replace that with something else that matches which container you want to run it on.
Also use --force because otherwise, its going to try and wait for a prompt