Ответ 1

Использование EB CLI 3.x

Для этой версии это относительно просто. Например:

mkdir HelloWorld                 # create new directory for project
cd HelloWorld                    # enter the new directory
git init                         # create git repository
eb init -p PHP                   # create new application

echo "<?php echo getenv("ENV_NAME"); ?>" > index.php
git add .gitignore index.php
git commit -m 'Initial commit.'

eb create dev-env                # create environment named dev-env
eb create prod-env               # create environment named prod-env

eb use dev-env                   # associate dev-env to current branch (master)
eb setenv ENV_NAME=DEV           # set env variable specific to dev-env

git checkout -b production       # create production branch and switch to it
eb use prod-env                  # associate prod-env to the current branch (production)
eb setenv ENV_NAME=PROD          # set env variable specific to prod-env

Это не сохраняет ENV_NAME в локальной файловой системе. EB CLI напрямую изменяет реальный экземпляр EB. Вы можете использовать eb config save (как предложил Ник Хурич), чтобы сохранить настройки конфигурации среды для текущей рабочей среды .elasticbeanstalk/saved_configs/<env-name>.cfg.yml. Поскольку каждая среда имеет свой собственный файл, у вас не должно быть конфликтов, если вы не измените один из них в обеих ветвях. Другой вариант (см. Защита конфиденциальной информации) заключается в том, чтобы добавить их в .gitignore.

Использование EB CLI 2.x

В: Как вы создали среду?

Один из способов состоит в том, чтобы иметь отдельные файлы настроек параметров для каждой среды (ветки). EB CLI может помочь вам в этом: -)

Запустите eb init из каждой ветки (см. ниже) и выберите другое имя среды для каждого из них, так что в итоге вы получите 2 различных файла .elasticbeanstalk/optionsettings.<env-name>. Таким образом, вы избегаете конфликтов на .elasticbeanstalk/.

1. Создайте каталог проекта

mkdir MyApp
cd MyApp

2. Инициализировать репозиторий Git

git init .

3. Настройка среды разработки (главная ветвь)

eb init

ПРИМЕЧАНИЕ. Когда вы попросите указать имя среды, выберите имя, определяющее, является ли оно средой разработки или производства.

Enter your AWS Access Key ID (current value is "<redacted>"): 
Enter your AWS Secret Access Key (current value is "<redacted>"): 
Select an AWS Elastic Beanstalk service region.
Available service regions are:
<redacted>
Select (1 to 8): 1
Enter an AWS Elastic Beanstalk application name
(auto-generated value is "MyApp"): MyApp      
Enter an AWS Elastic Beanstalk environment name
(auto-generated value is "MyApp-env"): MyApp-dev
Select an environment tier.
Available environment tiers are:
1) WebServer::Standard::1.0
2) Worker::SQS/HTTP::1.0
Select (1 to 2): 1
Select a solution stack.
Available solution stacks are:
<redacted>
Select (1 to 59): 32
Select an environment type.
Available environment types are:
1) LoadBalanced
2) SingleInstance
Select (1 to 2): 2
Create an RDS DB Instance? [y/n]: n
Attach an instance profile (current value is "[Create a default instance profile]"):
<redacted>
Select (1 to 5): 4

4. Создать новую ветку для производства

git checkout -b production

5. Настройка рабочей среды

eb init

  Повторите шаг 3, но выберите другое имя среды. Это создаст отдельный файл .elasticbeanstalk/optionsettings.<env-name>.

Q: Как насчет моих .ebextensions?

Вы должны использовать те же app.config для обеих сред. Единственное, что может расходиться между средами, - это раздел option_settings. Но насколько я знаю, у вас не может быть разных option_settings для каждой среды, так как мы можем это сделать?

Хорошо, что у меня еще нет оптимального решения, но я расскажу вам, как я это делаю. Я добавляю все option_name мне нужно и использую значения заполнителя, например:

option_settings:
  - option_name: MY_CONFIG
    value: CHANGEME

Затем я меняю свои значения вручную с помощью панели администрирования AWS Elastic Beanstalk. Перейдите к Application > Configuration > Software Configuration > Environment Properties.

Другая возможность - создать пользовательский script, который запускается вашим container_commands. Этот script может идентифицировать экземпляр EC2 своим именем хоста (или другим уникальным значением) и автоматически загружать переменные среды (например, source <hostname>.env).

Защита конфиденциальной информации

Единственное правило, которому вам нужно подчиняться, следующее: в вашем репозитории НЕ ДОЛЖЕН содержать конфиденциальную информацию, такую ​​как учетные данные, если вам все равно.

Например, приложение ожидает чтения учетных данных RDS через переменные среды, поэтому вы помещаете их в option_settings. Но вы не хотите, чтобы другие участники видели их, не так ли? Решение, которое я предлагаю с использованием заполнителя, удобно в этом аспекте.

Ответ 2

Вы можете объединить мастер в производство и производство для освоения. Однако после каждого слияния вы должны reset работающее дерево соответствующих папок. Вот как вы можете это сделать.

git checkout production
git merge --no-commit --no-ff master
git reset /path/to/[.ebextensions and .elasticbeanstalk]/folders
git commit
git push

Кроме того, вы можете забыть reset после каждого слияния, поэтому я предлагаю вам установить крюк post-merge, чтобы сделать это автоматически для соответствующих ветвей после каждого слияния.