Hier ist mein aktuelles Szenario.

• Ich verwende AWS Elasticbeanstalk zusammen mit den eb cli 3.x-Tools für die Bereitstellung.
• Ich habe 2 Umgebungen erstellt (Entwicklung und Produktion). und ein Branch in meinem Git-Repository für jede Umgebung (dh master , production)
• Ich habe .ebextensions- und .elasticbeanstalk-Ordner in meinem Git-Repository erstellt
• Der Ordner .ebextensions enthält Konfigurationsdateien, die für jede Umgebung spezifisch sind (zB Setups, Dateiänderungen, Umgebungsvariablen . . etc)

Ich möchte an jeder Umgebung in einem eigenen Git-Zweig arbeiten.

Meine Schwierigkeit

wenn ich eine entwicklungsumgebung bereitstellen muss, wird es ganz einfach

// make config changes in master branch
// git add, commit
// eb deploy
// thus development environment is updated

Aber wenn ich in der Produktion bereitstellen muss, beginnt das Problem

git checkout production
git merge master // pulls config that is meant for development environment only
eb deploy 

Ich möchte, dass, wenn ich Änderungen aus dem Master-Zweig zusammenführe, mein gesamter Code mit den neuesten Änderungen aktualisiert wird. Aber die Verzeichnisse .ebextensions und .elasticbeanstalk bleiben unberührt

Wie kann man git anweisen, den gesamten .ebextensions-Ordner beim Zusammenführen in den Produktionszweig zu ignorieren?

Verwenden von EB CLI 3.x

Für diese Version ist es relativ einfach. Beispielsweise:

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

Das spart nicht ENV_NAME irgendwo im lokalen Dateisystem. Die EB-CLI ändert die Live-EB-Instanz direkt. Sie können verwenden eb config save (wie von Nick Humrich vorgeschlagen), um die Umgebungskonfigurationseinstellungen für die aktuelle laufende Umgebung zu speichern .elasticbeanstalk/saved_configs/<env-name>.cfg.yml. Da jede Umgebung ihre eigene Datei hat, sollten keine Konflikte auftreten, es sei denn, Sie ändern eine davon in beiden Zweigen. Eine andere Möglichkeit (siehe Schutz sensibler Informationen) wäre, sie hinzuzufügen .gitignore.

Verwenden von EB CLI 2.x

F: Wie haben Sie Ihre Umgebungen erstellt?

Eine Möglichkeit besteht darin, für jede Umgebung (Zweig) unterschiedliche Optionseinstellungsdateien zu haben. Der EB CLI kann dir dabei helfen 🙂

Lauf eb init aus jedem Zweig (siehe unten) und wählen Sie für jeden einen anderen Umgebungsnamen, sodass Sie am Ende 2 verschiedene . haben .elasticbeanstalk/optionsettings.<env-name> Dateien. Auf diese Weise vermeiden Sie die Konflikte auf .elasticbeanstalk/.

1. Erstellen Sie das Projektverzeichnis

mkdir MyApp
cd MyApp

2. Git-Repository initialisieren

git init .

3. Einrichten der Entwicklungsumgebung (Master-Zweig)

eb init

HINWEIS: Wenn Sie aufgefordert werden, einen Umgebungsnamen anzugeben, wählen Sie einen Namen, der angibt, ob es sich um eine Entwicklungs- oder Produktionsumgebung handelt.

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. Erstellen Sie eine neue Niederlassung für die Produktion

git checkout -b production

5. Richten Sie die Produktionsumgebung ein

eb init

Wiederholen Sie Schritt 3, aber wählen Sie einen anderen Umgebungsnamen aus. Dies wird unterschiedliche .elasticbeanstalk/optionsettings.<env-name> Datei.

F: Was ist mit meinen .ebextensions?

Sie sollten das gleiche verwenden app.config für beide Umgebungen. Das einzige, was zwischen Umgebungen abweichen kann, ist die option_settings Sektion. Aber soweit ich weiß kann man nicht anders option_settings pro Umgebung, also wie können wir das tun?

Nun, dafür habe ich noch keine optimale Lösung, aber ich erzähle Ihnen, wie ich es mache. ich füge alles hinzu option_name‘s brauche und verwende ich Platzhalterwerte, zum Beispiel:

option_settings:
  - option_name: MY_CONFIG
    value: CHANGEME

Später ändere ich ihre Werte manuell über das AWS Elastic Beanstalk-Admin-Panel. Gehe zu Application > Configuration > Software Configuration > Environment Properties.

Eine andere Möglichkeit wäre ein benutzerdefiniertes Skript, das von Ihrem ausgeführt wird container_commands. Dieses Skript könnte die EC2-Instance anhand ihres Hostnamens (oder eines anderen eindeutigen Werts) identifizieren und automatisch die Umgebungsvariablen laden (z source <hostname>.env).

Schutz sensibler Informationen

Die einzige Regel, die Sie befolgen müssen, ist diese: Ihr Repository DARF NICHT enthalten sensible Informationen wie Anmeldeinformationen, es sei denn, es ist Ihnen egal.

Zum Beispiel erwartet eine Anwendung, RDS-Anmeldeinformationen über Umgebungsvariablen zu lesen, also fügen Sie sie ein option_settings. Aber Sie möchten nicht, dass andere Mitwirkende sie sehen, oder? Die von mir vorgeschlagene Lösung mit Platzhaltern ist in dieser Hinsicht praktisch.

Sie können Master mit Produktion und Produktion mit Master zusammenführen. Nach jeder Zusammenführung müssen Sie jedoch den Arbeitsbaum der betreffenden Ordner zurücksetzen. Hier ist, wie Sie dies tun können.

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

Außerdem können Sie nach jeder Zusammenführung vergessen, das Zurücksetzen zu starten. Ich schlage daher vor, dass Sie ein post-merge Haken, um dies nach jedem Merge automatisch für die jeweiligen Zweige zu tun.