AWS codeBuild/codePipeline mit Serverless Framework

Question

Ich versuche zu automatisieren Deployment Pipeline für meine Anwendung. Hier ist die Automatisierungsarchitektur, kam ich mit:

Wie Sie sehen, ich bin mit codePipeline und codeBuild meiner Bereitstellung zu automatisieren. Mein Backend basiert auf Serverless Framework, die Lambda-Funktionen beim Auslösen des Befehls sls deploy bereitstellt. Aus diesem Grund habe ich codeDeploy nicht verwendet, um die traditionelle Bereitstellung durchzuführen. buildspec.yml Datei sieht wie folgt aus:

version: 0.1 

phases: 
    install: 
    commands: 
     – apt-get -y update 
     – npm install -g serverless@1.9.0 
    build: 
    commands: 
     – cd nj2jp/serverless && npm install 
    post_build: 
    commands: 
     – serverless deploy –verbose 

artifacts: 
    files: 
    – serverless.yml 
    discard-paths: yes 

Jetzt habe ich 3 Fragen in Bezug auf CodeBuild und Serverless:

Frage 1: Der Befehl sls deploy auf eine Datei hängt genannt config.yml Das enthält Geheimnisse wie db password. Diese Datei wird nicht in git eingecheckt. Was denkst du, ist die beste Möglichkeit, config.yml in codeBuild einzuschließen?

Frage 2:Rollbacks können mit AWS durchgeführt werden, wenn wir traditionelle EC2-Anwendungen mit codeDeploy bereitstellen müssen. Im Falle von Serverless verwenden wir nicht codeDeploy und Serverless unterstützt auch Rollback Funktionen. Wie nutzen wir Serverless Rollback innerhalb der codePipeline?

Frage 3: Auslösen von CodePipeline, wenn ein Pull Request passiert. Ich habe einige Posts gesehen, die sagen, dass es von codePipeline nicht unterstützt wird. Aber diese Posts waren vom letzten Jahr, wird Pull Request jetzt von codePipeline unterstützt?

Hack Antworten (nicht richtig, aber Werke von Ihnen bessere Antworten benötigen..)

Antwort 1: Die config.yml Datei kann in einem privaten S3 Eimer gespeichert und kann zu codeBuild gezogen werden als Teil von pre-build Setup oder Wir können alle Geheimnisse zu CodeBuilds Env-Variablen hinzufügen. Ich mag die zweite Option nicht, da ich in allen Umgebungen konsistent sein möchte. Gibt es bessere Lösungen für dieses Problem?

Antwort 2: Ich kann nicht an einen Hack für diesen denken. Suchen Sie nach Antworten von Ihnen.

Antwort 3: ich auf einige Blog-Beiträge kamen die [APIGateway + Lambda + S3] verwenden codePipeline für Pull-Anforderungen auszulösen. Aber ich fühle, dass diese Funktion als eine Out-of-Box bereitgestellt werden muss. Gibt es Updates für die codePipeline für diese Funktion?

Answer 1

Frage 1

Wenn Sie die einzige Möglichkeit, bleiben möchten mit Ihrem config.yml, dann ist es Arbeit zu machen durch Hacks ähnlich dem, was Sie bereits tun, da es nicht versionsgesteuert ist.

Ich würde vorschlagen, dass Ihre Umgebungsvariablen im EC2 Parameter Store gespeichert sind, auf die Sie in Ihrem CodeBuild buildspec.yml verweisen können. Auf diese Variablen können Sie in Ihrer serverless.yml mit ${env:VARIABLE_NAME} zugreifen.

Für die lokale Entwicklung sollten Sie auch echte Umgebungsvariablen verwenden, statt sie in zu speichern. Tools wie direnv sind gut darin.

Frage 2

Sie können den vorherigen CodeBuild Job durch erneutes Ausführen manuelle Rollbacks tun. Ich kann mir keinen einfachen Weg vorstellen, wie CodeDeploy automatisch funktioniert. Möglicherweise kann eine Lambda-Funktion einen Post-Deploy-Test durchführen. Sollte dies fehlschlagen, kann dies dazu führen, dass der vorherige CodeBuild-Job erneut ausgeführt wird.

Frage 3

CodePipelines an einen einzigen Zweig gebunden so, um es auf PR Filialen funktioniert, haben Sie Hacks wie der Artikel, den Sie erwähnt zu tun. Ich habe mit API-Gateway zurückgegriffen + Lambda + CodeBuild (No CodePipeline), dies zu tun.