Wykorzystanie DevOps Automation do wdrażania Lambda API na kontach i środowiskach
Ponieważ coraz więcej przedsiębiorstw adoptuje technologie bezserwerowe, aby dostarczać swoje możliwości biznesowe w bardziej elastyczny sposób, konieczne jest zautomatyzowanie procesów wdrażania.
Wiele kont AWS jest potrzebnych do oddzielania i izolowania workloadów w środowiskach produkcyjnych i nieprodukcyjnych. Automatyzacja wdrożeń staje się krytyczna, gdy masz wiele jednostek biznesowych w przedsiębiorstwie, z których każda składa się z wielu kont AWS, które są stale wdrażane w środowiskach produkcyjnych i nieprodukcyjnych.
Zgodnie z dobrymi praktykami DevOps, zespół DevOps odpowiedzialny za wdrażanie w środowisku nieprodukcyjnym nie powinien wdrażać aplikacji i kodu infrastruktury zarówno w środowiskach nieprodukcyjnych, jak i produkcyjnych. Grozi to wprowadzeniem błędów we wdrożeniach aplikacji i infrastruktury w środowiskach produkcyjnych. To z kolei skutkuje znacznymi przeróbkami i opóźnieniami w wydaniach. Wdrażanie kodu w sposób powtarzalny przy jednoczesnym zmniejszeniu liczby błędów ręcznych wymaga zautomatyzowania całego procesu wdrażania. W tym wpisie pokazujemy, jak można zbudować pipeline kodu dla wielu kont, który automatyzuje wdrożenia w różnych środowiskach przy użyciu szablonów AWS CloudFormation i dostępu do wielu kont AWS.
Pipeline kodu dla wielu kont umożliwia użytkownikowi usługi AWS Identity & Access Management (IAM) przejęcie roli produkcyjnej IAM przy użyciu AWS Secure Token Service (Managing AWS STS in an AWS Region – AWS Identity and Access Management) w celu przełączania się między wdrożeniami nieprodukcyjymi i produkcyjnymi, w zależności od potrzeb. Zautomatyzowany pipeline wdrażania przechodzi przez wszystkie etapy wdrażania od źródła, do kompilacji, wdrożenia, na nieprodukcyjnym koncie AWS, a następnie wywołuje interfejs API STS Assume Role (dostęp między kontami), aby uzyskać tymczasowy token i dostęp do konta produkcyjnego AWS w celu wdrożenia. Jest to zgodne z modelem minimalnych uprawnień w celu przyznawania dostępu opartego na rolach za pomocą polityk IAM, co zapewnia bezpieczną automatyzację wdrożenia pipeline’u produkcyjnego.
Podgląd rozwiązania
W tym wpisie pokażemy, w jaki sposób można użyć roli IAM obejmującej wiele kont, do wdrożenia kodu AWS Lambda Serverless API w środowiskach przedprodukcyjnych i produkcyjnych. Opieramy się na procesie opisanym w tym poście: Building a CI/CD pipeline for cross-account deployment of an AWS Lambda API with the Serverless Framework poprzez programową automatyzację wdrażania Amazon API Gateway przy użyciu szablonów CloudFormation. W tym przypadku użycia zakładamy jednego klienta tenant z oddzielnymi kontami AWS, aby odizolować workloady przedprodukcyjne i produkcyjne. Na rysunku 1 przedstawiliśmy schematycznie workflow pipeline’u kodu dla naszego przypadku użycia.
Rysunek 1. AWS CodePipeline dla obciążeń produkcyjnych i nieprodukcyjnych.
Poniżej szczegółowo opisaliśmy worflow pipeline’u kodu dla każdego kroku odnotowanego na poprzednim diagramie:
- Użytkownik IAM należący do zespołu DevOps loguje się do interfejsu AWS Command-line Interface (AWS CLI) z komputera lokalnego przy użyciu tajnego klucza dostępu IAM.
- Następnie użytkownik IAM przejmuje rolę IAM do odpowiednich działań – – AWS Code Commit, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline Execution i wdraża kod do preprodukcji.
- Typowy AWS CodePipeline składa się z etapów budowania, testowania i wdrażania. Na etapie kompilacji usługa AWS CodeBuild generuje stos szablonów Cloudformation (template-export.yaml) do Amazon S3.
- Na etapie wdrażania AWS CodePipeline wykorzystuje szablon CloudFormation template (plik yaml) do wdrożenia kodu z bucket’u S3 zawierającego punkty końcowe API aplikacji za pośrednictwem Amazon API Gateway w środowisku przedprodukcyjnym.
- Ostatnim krokiem jest wdrożenie zmian w kodzie aplikacji w środowisku produkcyjnym poprzez przejęcie roli produkcyjnej STS IAM.
Ponieważ AWS CodePipeline jest w pełni zautomatyzowany, możemy korzystać z tego samego pipeline’u, przełączając się między kontami przedprodukcyjnymi i produkcyjnymi. Konta te przyjmują rolę uprawnień IAM odpowiednią dla środowiska docelowego i wdrażają sprawdzoną kompilację w tym środowisku przy użyciu szablonów CloudFormation.
Wymagania wstępne
Oto wymagania wstępne przed rozpoczęciem wdrażania.
- Użytkownik z odpowiednimi uprawnieniami (na przykład: Project Admin) na produkcyjnym koncie AWS.
- Użytkownik z odpowiednimi uprawnieniami (na przykład: Developer Lead) na przedprodukcyjnym koncie AWS, takim jak development.
- Szablon CloudFormation do wdrażania infrastruktury na koncie przedprodukcyjnym.
- Upewnij się, że na komputerze lokalnym jest zainstalowany i skonfigurowany interfejs AWS CLI.
Proces implementacji
W tej sekcji pokazujemy, jak wykorzystać AWS CodePipeline, aby w bezpieczny sposób udostępnić bezserwerowe API w środowiskach przedprodukcyjnych i produkcyjnych. Logowanie AWS CloudWatch będzie wykorzystywane do monitorowania zdarzeń w AWS CodePipeline.
1. Utworzenie zasobów na koncie przedprodukcyjnym.
W tym kroku tworzymy wymagane zasoby, takie jak repozytorium kodu, bucket S3 i klucz KMS w środowisku przedprodukcyjnym.
- Sklonuj repozytorium kodu do swojego CodeCommit. Wprowadź niezbędne zmiany w index.js i upewnij się, że plik buildspec.yaml jest dostępny do tworzenia artefaktów.
- Używając codebase (lambda API) jako danych wejściowych, wyprowadzasz szablon CloudFormation i konfiguracyjne pliki JSON środowiska (używane do konfigurowania środowiska produkcyjnego i innych środowisk nieprodukcyjnych, takich jak dev, test). Artefakty kompilacji są pakowane przy użyciu modelu AWS Serverless Application Model do pliku zip i przesyłane do bukcet’u S3 utworzonego do przechowywania artefaktów. Zanotuj nazwę repozytorium, ponieważ będzie ona wymagana później.
- Utwórz bucket S3 w regionie (na przykład: us-east-2). Ten bucket będzie używany przez pipeline do pobierania (get) i umieszczania (put) artefaktów. Zanotuj nazwę bucket’u.
- Upewnij się, że edytujesz polityki bucket’u, tak aby zawierały identyfikator konta produkcyjnego i nazwę bucket’u. Zapoznaj się z dokumentacją polityk bucketu AWS S3, aby wprowadzić zmiany w politykach i uprawnieniach bucketu Amazon S3.
- Przejdź do usługi AWS Key Management Service (KMS) i utwórz klucz symetryczny.
- Następnie utwórz nowy sekret, skonfiguruj klucz KMS i zapewnij dostęp do konta deweloperskiego i produkcyjnego. Zanotuj ARN dla klucza.
2. Utwórz role uprawnień IAM na koncie produkcyjnym i wymagane polityki.
W tym kroku tworzymy role i polityki wymagane do wdrożenia kodu.
- Utwórz rolę uprawnień dostępu IAM dla wielu kont (CodePipelineCrossAccountRole) na koncie produkcyjnym.
- Utwórz politykę odczytu/zapisu, aby uzyskać dostęp do bucketu S3 zawierającego artefakty zasobów.
- Utwórz politykę, która nada dostęp do kluczy KMS do konta AWS Production.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:DescribeKey",
"kms:GenerateDataKey*",
"kms:Encrypt",
"kms:ReEncrypt*",
"kms:Decrypt"
],
"Resource": [
"Your KMS Key ARN you created in Development Account"
]
}
]
}
Po utworzeniu obu polityk, dołącz je do utworzonej wcześniej roli dla wielu kont.
3. Utwórz role wdrożenia CloudFormation.
W tym kroku musisz utworzyć kolejną rolę uprawnień IAM „CloudFormationDeploymentRole” do wdrażania aplikacji. Następnie dołącz do niego następujące cztery polityki.
Polityka 1: Aby Cloudformation wdrożył aplikację na koncie produkcyjnym:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"cloudformation:DetectStackDrift",
"cloudformation:CancelUpdateStack",
"cloudformation:DescribeStackResource",
"cloudformation:CreateChangeSet",
"cloudformation:ContinueUpdateRollback",
"cloudformation:DetectStackResourceDrift",
"cloudformation:DescribeStackEvents",
"cloudformation:UpdateStack",
"cloudformation:DescribeChangeSet",
"cloudformation:ExecuteChangeSet",
"cloudformation:ListStackResources",
"cloudformation:SetStackPolicy",
"cloudformation:ListStacks",
"cloudformation:DescribeStackResources",
"cloudformation:DescribePublisher",
"cloudformation:GetTemplateSummary",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackResourceDrifts",
"cloudformation:CreateStack",
"cloudformation:GetTemplate",
"cloudformation:DeleteStack",
"cloudformation:TagResource",
"cloudformation:UntagResource",
"cloudformation:ListChangeSets",
"cloudformation:ValidateTemplate"
],
"Resource": "arn:aws:cloudformation:us-east-2:940679525002:stack/DevOps-Automation-API*/*" }
]
}
Polityka 2: Aby Cloudformation wykonywał wymagane działania dotyczące uprawnień IAM:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:GetPolicy",
"iam:TagRole",
"iam:DeletePolicy",
"iam:CreateRole",
"iam:DeleteRole",
"iam:AttachRolePolicy",
"iam:PutRolePolicy",
"iam:TagPolicy",
"iam:CreatePolicy",
"iam:PassRole",
"iam:DetachRolePolicy",
"iam:DeleteRolePolicy"
],
"Resource": "*"
}
]
}
Polityka 3: Polityka wywołania usługi funkcji lambda:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionCode",
"lambda:AddPermission",
"lambda:InvokeFunction",
"lambda:GetFunction",
"lambda:DeleteFunction",
"lambda:PublishVersion",
"lambda:CreateAlias"
],
"Resource": "arn:aws:lambda:us-east-2:Your_Production_AccountID:function:SampleApplication*"
}
]
}
Polityka 4: Polityka wywołania usługi API Gateway:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"apigateway:DELETE",
"apigateway:PATCH",
"apigateway:POST",
"apigateway:GET"
],
"Resource": [
"arn:aws:apigateway:*::/restapis/*/deployments/*",
"arn:aws:apigateway:*::/restapis/*/stages/*",
"arn:aws:apigateway:*::/clientcertificates",
"arn:aws:apigateway:*::/restapis/*/models",
"arn:aws:apigateway:*::/restapis/*/resources/*",
"arn:aws:apigateway:*::/restapis/*/models/*",
"arn:aws:apigateway:*::/restapis/*/gatewayresponses/*",
"arn:aws:apigateway:*::/restapis/*/stages",
"arn:aws:apigateway:*::/restapis/*/resources",
"arn:aws:apigateway:*::/restapis/*/gatewayresponses",
"arn:aws:apigateway:*::/clientcertificates/*",
"arn:aws:apigateway:*::/account",
"arn:aws:apigateway:*::/restapis/*/deployments",
"arn:aws:apigateway:*::/restapis"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"apigateway:DELETE",
"apigateway:PATCH",
"apigateway:POST",
"apigateway:GET"
],
"Resource": "arn:aws:apigateway:*::/restapis/*/resources/*/methods/*/responses/*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"apigateway:DELETE",
"apigateway:PATCH",
"apigateway:GET"
],
"Resource": "arn:aws:apigateway:*::/restapis/*"
},
{
"Sid": "VisualEditor3",
"Effect": "Allow",
"Action": [
"apigateway:DELETE",
"apigateway:PATCH",
"apigateway:GET"
],
"Resource": "arn:aws:apigateway:*::/restapis/*/resources/*/methods/*"
}
]
}
Upewnij się, że dołączasz również polityki dostępu do odczytu/zapisu S3 i polityki KMS utworzone w kroku 2 do roli CloudFormationDeploymentRole.
4. Skonfiguruj i uruchom CodePipeline.
Możesz uruchomić CodePipeline ręcznie w konsoli AWS za pomocą „Launch Stack” lub programowo za pomocą wiersza poleceń w CLI.
Na komputerze lokalnym przejdź do terminala/ wiersza poleceń i uruchom to polecenie:
aws cloudformation deploy –template-file <Path to pipeline.yaml> –region us-east-2 –stack-name <Name_Of_Your_Stack> –capabilities CAPABILITY_IAM –parameter-overrides ArtifactBucketName=<Your_Artifact_Bucket_Name> ArtifactEncryptionKeyArn=<Your_KMS_Key_ARN> ProductionAccountId=<Your_Production_Account_ID> ApplicationRepositoryName=<Your_Repository_Name> RepositoryBranch=master
Jeśli skonfigurowałeś profil w AWS CLI, wskaż ten profil podczas wykonywania polecenia:
–profile <your_profile_name>
Po uruchomieniu pipeline’u, Twój bezserwerowy interfejs API zostanie wdrożony w fazie przedprodukcyjnej, a także na kontach produkcyjnych. Możesz sprawdzić wdrożenie swojego interfejsu API na koncie produkcyjnym lub przedprodukcyjnym, przechodząc do API Gateway w konsoli AWS i szukając go w regionie, w którym został wdrożony.
Rysunek 2. Sprawdź swoje wdrożenie w środowisku przedprodukcyjnym/produkcyjnym.
Następnie wybierz swój interfejs API i przejdź do stages, aby wyświetlić opublikowany interfejs API z punktem końcowym. Następnie zweryfikuj swoją odpowiedź API, wybierając API link.
Rysunek 3. Sprawdź, czy Twój interfejs API jest publikowany w środowisku przedprodukcyjnym/produkcyjnym.
Alternatywnie możesz również przejść do swoich interfejsów API, przechodząc przez stos wdrożonej aplikacji CloudFormation i wybierając łącze do interfejsu API na zakładce Resources.
Czynności końcowe
Jeśli wypróbowujesz to na swoich kontach AWS, usuń wszystkie zasoby utworzone podczas tego ćwiczenia, aby uniknąć ponoszenia jakichkolwiek opłat za AWS.
Podsumowanie
W tym poście pokazaliśmy, jak zbudować pipeline kodu dla wielu kont, aby zautomatyzować wdrożenia/wydania w różnych środowiskach przy użyciu szablonów AWS CloudFormation i AWS Cross Account Access.
Dowiedziałeś się również, jak bezpiecznie wdrażać bezserwerowe interfejsy API na kontach przedprodukcyjnych i produkcyjnych. Pomaga to przedsiębiorstwom zautomatyzować wdrożenia wydań w sposób powtarzalny i elastyczny, a także zmniejszyć liczbę błędów wykonywanych ręcznie i szybciej dostarczać możliwości biznesowe.
źródło: AWS