Kod AWSBuild/codePipeline with serverless framework

Question

Próbuję zautomatyzować wdrożenie Pipeline dla mojej aplikacji. Oto architektura automatyka, wymyśliłem:

Jak widać używam codePipeline i codeBuild zautomatyzować moje wdrożenia. Mój backend jest oparty na Serverless Framework, który uruchamia funkcje lambda na komendzie wypalania sls deploy. Z tego powodu nie użyłem kodu codeDeploy do wykonania tradycyjnego. buildspec.yml plik wygląda tak:

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 

Teraz mam 3 pytania w odniesieniu do CodeBuild i Serverless:

Pytanie 1: Komenda sls deploy zależy od pliku o nazwie config.yml który zawiera sekrety takie jak hasło db. Ten plik nie zostanie sprawdzony w git. Jak myślisz, co jest najlepszym sposobem na włączenie config.yml w codeBuild?

Pytanie 2:cofanie można zrobić z AWS, jeśli musimy wdrożyć tradycyjne aplikacje EC2 za pomocą codeDeploy. W przypadku serwera bez serwera nie używamy kodu codeDeploy, a serwer obsługuje również funkcje wycofywania. W jaki sposób możemy wykorzystać wycofywanie bez obsługi serwera w ramach usługi codePipeline?

Pytanie 3: Wyzwalanie codePipeline gdy Pull Zapytanie dzieje. Widziałem kilka postów mówiących, że nie jest obsługiwane przez codePipeline. Ale te posty pochodziły z zeszłego roku, czy żądanie Pull teraz jest obsługiwane przez codePipeline?

Hack odpowiedzi (nie jest poprawne, ale prace potrzebujemy lepszej odpowiedzi od ciebie.).

Odpowiedź 1: Plik config.yml mogą być zapisywane w prywatnym S3 wiadra i można pociągnąć do codeBuild w ramach konfiguracji pre-build lub Możemy dodać wszystkie sekrety do zmiennych Env Code's Env. Nie podoba mi się druga opcja, ponieważ chcę mieć spójność we wszystkich środowiskach. Jakieś lepsze rozwiązania tego problemu?

Odpowiedź 2: Nie mogę wymyślić hack na to. Szukasz odpowiedzi od Ciebie.

Odpowiedź 3: natknąłem niektórych blogach, które używają [APIGateway + Lambda + S3] wywołać codePipeline żądań ciągnąć. Ale czuję, że ta funkcja musi być dostarczona jako gotowa. Czy są jakieś aktualizacje na linii kodu dla tej funkcji?

Answer 1

Pytanie 1

Jeśli chcesz trzymać się config.yml, to jedynym sposobem, aby to działało jest poprzez hacki podobnych do tego, co już robisz, ponieważ nie jest wersja kontrolowane.

Proponuję, aby twoje zmienne środowiskowe były przechowywane w składnicy parametrów EC2, do której możesz się odwoływać w swoim CodeBuild buildspec.yml. Te zmienne są dostępne w twoim serverless.yml przy użyciu ${env:VARIABLE_NAME}.

Do rozwoju lokalnego należy również używać zmiennych środowiskowych w porównaniu do przechowywania w config.yml. Narzędzia takie jak direnv są w tym świetne.

Pytanie 2

Można to zrobić ręcznie staczania się poprzez ponowne uruchomienie poprzednią pracę CodeBuild. Nie mogę wymyślić łatwego sposobu na zrobienie tego automatycznie, tak jak robi to CodeDeploy. Może funkcja Lambda może wykonać test po wdrożeniu, a jeśli się nie powiedzie, może spowodować ponowne uruchomienie poprzedniego zadania CodeBuild.

Pytanie 3

CodePipelines są przypisane do jednej gałęzi tak, aby pracować na oddziałach PR, trzeba zrobić hacki jak artykule pan wspomniał. I uciekają się do korzystania API bramy + Lambda + CodeBuild (Nie CodePipeline), aby to zrobić.