Я пытаюсь развернуть свое приложение Laravel на Elastic Beanstalk в режиме разработки. Чтобы приложение работало в режиме разработки, а не в производстве, я сделал следующее в своем /bootstrap/start.php
файл:
$env = $app->detectEnvironment(function() {
return $_ENV['ENV_NAME'];
});
Чтобы создать переменную среды, я создал .config
файл по следующему пути: /.ebextensions/00environmentVariables.config
с этим содержанием:
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: ENV_NAME
value: development
- option_name: DB_HOST
value: [redacted]
- option_name: DB_PORT
value: [redacted]
- option_name: DB_NAME
value: [redacted]
- option_name: DB_USER
value: [redacted]
- option_name: DB_PASS
value: [redacted]
Когда я бегу eb start
из командной строки он раскручивает экземпляр EC2 и пытается его подготовить, и в этот момент он сообщает мне, что произошел сбой. и проверить логи. В журналах я вижу эти записи:
Уведомление PHP: неопределенный индекс: ENV_NAME в
/var/app/ondeck/bootstrap/start.php в строке 28Примечание: неопределенный индекс: ENV_NAME в /var/app/ondeck/bootstrap/start.php в строке 28
По какой-то причине ENV_NAME
Переменная окружения не существует, хотя я указал ее в 00environmentVariables.config
, Что еще страннее, я вижу переменную среды делает существуют в настройках конфигурации программного обеспечения среды EB:
Подвести итоги:
ENV_NAME
eixstsENV_NAME
как в .config
файл и в моих настройках Elastic Beanstalk для этой средыИтак, я выяснил, что переменные среды работают правильно при обслуживании приложения через HTTP-сервер Apache, но переменные среды не существуют при запуске PHP CLI.
В вышеприведенных логах жалуется на ENV_NAME
не существует при запуске /usr/bin/composer.phar install
,
Так что по какой-то причине мои переменные окружения не существуют в PHP CLI, но они работают нормально при работе через Apache.
Таким образом, я подключился к экземпляру EC2, на котором размещено мое приложение Laravel на Elastic Beanstalk, и могу видеть правильные переменные среды, когда использую команду « printenv`:
ENV_NAME=development
Однако, если я сделаю die(var_dump($_SERVER));
и запустить PHP CLI, я не вижу переменные среды, которые я определил. Та же история с $_ENV
а также getenv()
,
Почему я не могу получить доступ к своим переменным среды в PHP CLI, когда я могу получить к ним доступ, когда Apache обрабатывает мои PHP-скрипты?
я сделал test.php
файл в одну строку: die(var_dump($_ENV));
,
Когда я запускаю это с помощью php test.php
Я успешно получаю свои собственные переменные окружения, так что это похоже на проблему только для композитора, а не на PHP CLI.
Я использую сценарий YAML, который устанавливает переменные окружения для пользователя root из существующих переменных, установленных для ec2-user. Добавьте это к вашему .ebextensions
папка с .config
расширение.
Оттуда вы можете запустить PHP Cli и он увидит правильные переменные среды
commands:
create_post_dir:
command: "mkdir /opt/elasticbeanstalk/hooks/appdeploy/post"ignoreErrors: true
files:
"/opt/elasticbeanstalk/hooks/appdeploy/post/job_after_deploy.sh":
mode: "000755"owner: root
group: root
content: |
#!/usr/bin/env bash
source /opt/elasticbeanstalk/support/envvars
# Run PHP scripts here. #
От ответа XuDing к этот вопрос а также этот ответ
Я создал работу, которая создает файл .env каждые 5 минут.
Добавьте следующее в ваши .ebextensions
"/opt/elasticbeanstalk/hooks/appdeploy/post/91_set_create_app_env_file_job.sh":
mode: "000755"owner: root
group: root
content: |
#!/usr/bin/env bash
echo "Removing any existing CRON jobs..."crontab -r
APP_ENV=/var/app/current/.env
EB_ENVVARS=/opt/elasticbeanstalk/support/envvars
CONSTANTS=/var/app/current/.constants
CRON_CMD="grep -oE '[^ ]+$' $EB_ENVVARS > $APP_ENV; cat $CONSTANTS >> $APP_ENV"
echo "Creating .env file...."eval $CRON_CMD
echo "Scheduling .env file updater job to run every 5 minutes..."(crontab -l 2>/dev/null; echo "*/5 * * * * $CRON_CMD")| crontab -
Причина, по которой я сделал это, заключается в том, что вы можете обновить переменные среды через консоль интерфейса пользователя AWS.
Это лучшее решение на мой взгляд.