Warum sollte ich .elastbeanstalk Ordner ignorieren?

Question

Ich habe eine Elastic Beanstalk Python-Anwendung.

So habe ich bereits mein Build-Skript, wo ich eine deploy.zip-Datei generieren, die ich in EB bereitstellen. Es funktioniert genau so, wie es sein soll.

Also nach dem Erstellen meines Skripts zum Erstellen eines Artefakts (meine deploy.zip), das mit EB kompatibel ist, fing ich an, EB cli für die Verwendung von eb deploy in meinem gitlab-ci zu konfigurieren, so wird es auf EB Homologation Server bereitstellen wenn es in der Entwicklungsabteilung und in der EB-Produktion einen Commit gibt, wenn man zum Master wird. (Ich arbeite gerade am Homologation Server).

Also habe ich die Dokumentation gelesen und bemerke, dass eb das Artefakt selbst bauen würde. Aber da ich bereits mein eigenes Build-Skript hatte, habe ich diese Artifact Instead of the Project Folder mit einem .elasticbeanstalk Ordner und einem mit der folgenden Konfiguration implementiert.

deploy: 
    artifact: deploy.zip 

Also habe ich ein eb init, habe alles eingestellt (Region, id, Schlüssel und ausgewählt mein bestehendes Projekt.

Als ich eb deploy tat es funktionierte so wie es anzunehmen. So habe ich den Verdacht, dass eb machte de-artefactory von selbst, also überprüfte ich die config-Datei und bemerkte, dass eb eine Menge anderer Konfig in die Datei hinzugefügt hatte, meine deploy-Konfiguration war da, also habe ich für einen anderen Test meine deploy.zip gelöscht, also tat ich eine eb deploy gescheitert, gerade wie es zu.

Bis zu diesem Punkt lief alles so, wie ich es vorhatte, also machte ich eine git status zur Überprüfung bevor ich den .elasticbeanstalk Ordner in git hinzufügte. Zu meiner Überraschung wurde der Ordner nicht aufgelistet und die Datei .gitignore wurde geändert. Bei der Überprüfung der .gitignore hatte es die .elasticbeanstalk drin.

So habe ich mich darüber informiert, ob ich diesen Ordner in den Git hinzufügen sollte, da das Standardverhalten von eb darin besteht, es in Ignorieren hinzuzufügen.

Ich plante, die eb-Konfigurationen zu committen und die Schlüssel mit Umgebungsvariablen zu setzen, wie es in der Configuration Settings and Precedence Sitzung heißt.

Ich habe versucht, eb deploy10 ohne die Konfigurationen zu laufen, die gerade env vars vor dem Befehl, etwas wie AWSAccessKeyId=<access_key> AWSSecretKey=<secret_key> eb deploy übergeben, aber es sagt, dass ich eb init davor laufen lassen sollte.

Also sollte ich meine eb Konfiguration nicht git? Wenn nicht, wie sollte ich für eine CI-Bereitstellung mit EB fortfahren?

Answer 1

.elasticbeanstalk ist ein Ort, an dem eb cli seine Konfiguration speichert. Wie du geschrieben hast - eine Datei config.yml ist da, also kannst du sie selbst erstellen. Wenn Sie eb init aufrufen, wird Ihre Version mit dem Befehl überschrieben.

Wenn Sie nur eine Umgebung haben oder die Sicherheit kein Problem ist, dann ist es sinnvoll, diese Konfiguration in Ihrem Repository zu haben. Sie legen einige Details wie den SSH-Schlüsselnamen offen, aus Sicherheitsgründen sollten nicht alle es sehen. Bei allem ich Männer öffentlichen Repo. Vielleicht haben sie es deshalb auf .gitignore gesetzt.

Beachten Sie, dass Sie in der Regel test, pre-prod, , Umgebungen - so Konfiguration ist sowieso erforderlich.Der nächste Schritt ist ein separates Konfigurations-Repository für all diese Dinge, und dort können Sie ein Verzeichnis oder eine Verzweigung pro Umgebung haben.

Ich stimme Ihnen zu, dass es seltsam aussieht - .ebextensions sind nicht auf diese Weise gesichert ...

Wenn ich etwas vermissen lassen - Frage, ich Klärung dieser Antwort anhängen werden.