Stworzyłem zestaw przykładowych plików, aby przejść do poniższego przewodnika. Pliki te są dostępne pod następującym linkiem: https://gitlab.com/autronix/gitlabci-ec2-deployment-samples-guide/

Zakres

Ten przewodnik zakłada następujące]}

Projekt Gitlab EE hosted - może pracować na prywatnych instancjach CE/EE (nie testowany)]}
• Gitlab jako repozytorium wersjonujące GIT
• Gitlab-Ci jako ciągła Integracja Silnik
• istniejące konto AWS
[[82]}AWS EC2 jako docelowy system produkcyjny lub stagingowy dla wdrożenia
• instancja AWS EC2 z systemem Amazon Linux AMI
• AWS S3 jako miejsce przechowywania plików wdrożeniowych
[[82]}AWS CodeDeploy jako silnik wdrożeniowy dla projektu
• AWS CodePipeline jako rurociąg do wdrożenia

Dostarczona Próbka .gitlab-ci.yml jest oparta na projekcie Java / Scala + Gradle. Skrypt jest dostarczany jako rodzajowy przykład i będzie musiał być dostosowany do konkretnych potrzeb podczas wdrażania ciągłej realizacji za pomocą tej metody.

Poradnik zakłada, że użytkownik posiada podstawową wiedzę na temat usług AWS i sposobu wykonywania niezbędnych zadań.

Uwaga: przewodnik podany w tym przykładzie wykorzystuje konsolę AWS do wykonywania zadań. Chociaż istnieją prawdopodobnie odpowiedniki CLI dla zadań wykonywanych tutaj, nie będą one omawiane w całym przewodniku.

Motywacja

Motywacja do tworzenia tych skryptów i przewodnika wdrożenia wynikała z braku odpowiedniego samouczka pokazującego jak zaimplementować Continuous Delivery używając Gitlab i AWS EC2. Gitlab wprowadził swój swobodnie dostępny silnik CI poprzez współpracę z Digital Ocean, który umożliwia repozytoriom użytkowników korzystanie z dobrej jakości CI za darmo.

Jedną z głównych zalet korzystania z Gitlab jest to, że zapewniają wbudowaną ciągłą integrację kontenery do przechodzenia przez różne etapy i walidacji kompilacji. Niestety, Gitblab ani AWS zapewniają integrację, która pozwoliłaby na wykonywanie ciągłego dostarczania po przejściu kompilacji.

Ten poradnik i skrypty ( https://gitlab.com/autronix/gitlabci-ec2-deployment-samples-guide / ) podaj uproszczoną wersję kroków, które podjąłem w celu uzyskania udanego CI i CD przy użyciu Gitlab i AWS EC2, które mogą pomóc innym w rozpoczęciu tego rodzaj realizacji.

Tworzenie środowiska na AWS

Pierwszym krokiem w zapewnieniu pomyślnego procesu ciągłej realizacji jest skonfigurowanie niezbędnych obiektów w AWS, aby proces wdrażania zakończył się sukcesem.

AWS IAM User

Https://console.aws.amazon.com/iam/home?#users

1. Utwórz użytkownika

2. Załącz następujące uprawnienia:

   • CodePipelineFullAccess
   • AmazonEC2FullAccess
   • AmazonS3FullAccess
   • AWSCodeDeployFullAccess
   • Inline Policy: { "Wersja": "2012-10-17", "Oświadczenie": [ { "Effect": "Pozwolić", "Akcja": [ "autoskalowanie: ", "codedeploy: ", "ec2: ", "elasticloadbalancing: ", "iam: AddRoleToInstanceProfile", "iam:CreateInstanceProfile", "iam: CreateRole", "iam: DeleteInstanceProfile", "iam: DeleteRole", "iam: Deleterolepolityka", "iam:GetInstanceProfile", "iam: GetRole", "iam:Getrolepolityka", "iam: Listinstanceprofiles Forrole", "iam: Listrolepolityka", "iam: ListRoles", "iam: PassRole", "iam: Putrolepolityka", "iam: RemoveRoleFromInstanceProfile", "s3: " ], "Zasoby": "" } ] }

3. Generowanie poświadczeń bezpieczeństwa

Uwaga: zasady wymienione powyżej mają bardzo szeroki zakres. Możesz dostosować się do swoich wymagań, tworząc niestandardowe zasady, które ograniczają dostęp tylko do niektórych zasobów.

Uwaga : Proszę przechowywać te poświadczenia w bezpiecznym miejscu. Będziesz ich potrzebować w późniejszym etapie.

AWS EC2 instancja i rola

Przykładowa rola dla CodeDeploy

Https://console.aws.amazon.com/iam/home?region=us-east-1#roles

Utwórz nową rolę, która zostanie przypisana do Twojej instancji EC2 w celu uzyskania dostępu do S3,

1. Ustaw nazwę zgodnie z konwencjami nazewnictwa (np. MyDeploymentAppRole)
Aby umożliwić EC2 uruchamianie innych usług AWS, należy wybrać opcję
2. .]}
3. Attache następujący Polityka:
   • AmazonEC2FullAccess
   • AmazonS3FullAccess
   • Amazoncodedeployrol

Uwaga: zasady wymienione powyżej mają bardzo szeroki zakres. Możesz dostosować się do swoich wymagań, tworząc niestandardowe zasady, które ograniczają dostęp tylko do niektórych zasobów.

Instancja Startowa

Https://console.aws.amazon.com/ec2/v2/home?region=us-east-1

Kliknij na Launch Instance i postępuj zgodnie z tymi kroki:

• Wybierz Amazon Linux AMI 2016.03.3 (HVM), SSD Volume Type
• wybierz wymagany typ wystąpienia (t2.domyślnie micro)
  • Następna
• Select IAM Role to be MyDeploymentAppRole (na podstawie nazwy utworzonej w poprzedniej sekcji)
  • Następna
• Wybierz Odpowiedni Magazyn
  • Następna
• oznacz swoją instancję odpowiednią nazwą (np. MyApp-Production-Instance)
  • dodaj dodatkowe znaczniki jako wymagane
  • Następna
• konfiguracja grupy zabezpieczeń w razie potrzeby
  • Następna
• Przejrzyj i uruchom swoją instancję

Otrzymasz możliwość wygenerowania lub użycia kluczy SSH. Proszę wybrać odpowiednią odpowiednią metodę.

Konfigurowanie środowiska instancji

Install CodeDeploy Agent

Zaloguj się do nowo utworzonej instancji EC2 i postępuj zgodnie z Instrukcja:

• http://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-run-agent-install.html

CodeDeploy ważne ścieżki:

• katalog bazowy Codedeploy: /opt/codedeploy-agent/deployment-root/
• CodeDeploy Log file: /var/log/aws/codedeploy-agent/codedeploy-agent.log

Wskazówka : Uruchom tail -f /var/log/aws/codedeploy-agent/codedeploy-agent.log, aby śledzić wdrażanie w czasie rzeczywistym.

Zainstaluj wymagania wstępne projektu Jeśli twój projekt ma jakieś warunki wstępne do uruchomienia, zrób upewnij się, że zainstalowałeś je przed uruchomieniem wdrożenia, w przeciwnym razie skrypt startowy może się nie udać.

Repozytorium AWS S3

Https://console.aws.amazon.com/s3/home?region=us-east-1

W tym kroku musisz utworzyć wiadro S3, które będzie przechowywać pliki wdrażania.

1. Wybierz Create Bucket
   • wybierz nazwę wiadra (tj. my-app-codepipeline-deployment)
   • Wybierz a region
2. w konsoli dla Twojego wiadra wybierz Properties
   • rozwiń menu Versioning
   • wybierz Enable Versioning

AWS CodeDeploy

Https://console.aws.amazon.com/codedeploy/home?region=us-east-1#/applications

Teraz, gdy podstawowe elementy są ustawione, jesteśmy gotowi do utworzenia aplikacji wdrożeniowej w CodeDeploy

Aby utworzyć aplikację codedeploy deploy wykonaj następujące czynności kroki:

1. Wybierz Create New Application
2. wybierz nazwę aplikacji (np. MyApp-Production )
3. wybierz nazwę grupy wdrożeniowej (np. MyApp-Production-Fleet)
4. Wybierz instancje EC2, na które będzie miało wpływ to wdrożenie - Search by Tags
   • Pod Key Wybierz Name
   • Pod Value Wybierz MyApp-Production-Instance
5. Pod Service Role Wybierz MyDeploymentAppRole
6. Kliknij Create Application

Uwaga: możesz przypisać wdrożenie do dowolnego znacznika, który zastosowane do żądanych wystąpień przeznaczonych do wdrożenia. Dla uproszczenia, do wybrania wcześniej zdefiniowanej instancji użyto tylko znacznika Name.

AWS CodePipeline

Https://console.aws.amazon.com/codepipeline/home?region=us-east-1#/dashboard

Następnym krokiem jest kontynuowanie tworzenia CodePipeline, która jest odpowiedzialna za wykonanie połączenia między kubełkiem S3 a procesem CodeDeploy.

Aby utworzyć Kodepipeline, wykonaj następujące kroki:

1. Kliknij Create Pipeline
2. Nazwij swój rurociąg (tj. MyAppDeploymentPipeline )
   • Następna
3. Ustaw Source Provider na Amazon S3
   • Ustaw Amazon S3 location na adres Twojego bucket i docelowego pliku wdrażania (np. s3://my-app-codepipeline-deployment/myapp.zip )
   • Następna
4. Ustaw Build Provider na None - jest to już obsługiwane przez Gitlab-CI, jak zostanie to omówione później
   • Następna
5. Ustaw Deployment Provider na AWS CodeDeploy
   • zestaw Application Name do nazwy Twojej aplikacji CodeDeploy (tj. MyApp-Production)
   • Ustaw Deployment Group na nazwę grupy wdrożeniowej CodeDeploy (tj. MyApp-Production-Fleet )
   • Następna
6. Utwórz lub wybierz rolę usługi rurociągu
   • Następna
7. Przejrzyj i kliknij Create Pipeline

Konfiguracja środowiska na Gitlab

Teraz, gdy środowisko AWS zostało przygotowane do wdrożenia aplikacji możemy przystąpić do konfiguracji CI środowisko i ustawienia zapewniające, że kod jest budowany i wdrażany do instancji EC2 przy użyciu S3, CodeDeploy i CodePipeline.

Zmienne Gitlab

Aby wdrożenie zadziałało, musimy ustawić kilka zmiennych środowiskowych w repozytorium projektu.

W Twoim projekcie Gitlab, przejdź do obszaru Variables dla Twojego projektu i ustaw następujące zmienne:

• AWS_DEFAULT_REGION => twój region AWS
• AWS_SECRET_ACCESS_KEY => twój użytkownik AWS klucz uwierzytelniający (uzyskany po wygenerowaniu danych uwierzytelniających dla użytkownika) {]}
• Aby uzyskać dostęp do danych uwierzytelniających użytkownika w AWS, należy skontaktować się z Działem obsługi klienta.]}
• AWS_S3_LOCATION = > lokalizacja pliku ZIP wdrożenia (tj. s3://my-app-codepipeline-deployment/my_app.zip )

Te zmienne będą dostępne przez skrypty wykonywane przez kontenery Gitlab-CI.

Skrypt startowy

Dostarczono prosty skrypt startowy (https://gitlab.com/autronix/gitlabci-ec2-deployment-samples-guide/blob/master/deploy/extras/my_app.sh), aby umożliwić wdrożenie do wykonywania następujących zadań:

• Uruchom aplikację i utwórz plik PID
• Sprawdź status aplikacji za pomocą pliku PID
• zatrzymaj aplikację

Możesz znaleźć ten skrypt Pod deploy/extras/my_app.sh

Tworzenie gitlab-ci.yml

Plik gitlab-ci.yml jest odpowiedzialny za wykonanie Zadania ciągłej integracji związane z danym commitem. Działa jako uproszczona Grupa skryptów powłoki, które są zorganizowane w etapach, które odpowiadają różnym fazom w etapach ciągłej integracji.

Aby uzyskać więcej informacji na temat szczegółów i odniesienia, zapoznaj się z następującymi dwoma linki:

• http://docs.gitlab.com/ce/ci/quick_start/README.html
• http://docs.gitlab.com/ce/ci/yaml/README.html

Możesz w dowolnym momencie zweryfikować składnię pliku gitlab-ci.yml za pomocą następującego narzędzia: https://gitlab.com/ci/lint

W celu wdrożenia, będziemy obejmować tylko ostatni kawałek próbki dostarczonej z tym przewodnikiem:

deploy-job:
  # Script to run for deploying application to AWS
  script:
    - apt-get --quiet install --yes python-pip # AWS CLI requires python-pip, python is installed by default
    - pip install -U pip  # pip update
    - pip install awscli  # AWS CLI installation
    - $G build -x test -x distTar # # Build the project with Gradle
    - $G distZip  # creates distribution zip for deployment
    - aws s3 cp $BUNDLE_SRC $AWS_S3_LOCATION # Uploads the zipfile to S3 and expects the AWS Code Pipeline/Code Deploy to pick up
  # requires previous CI stages to succeed in order to execute
  when: on_success
  stage: deploy
  environment: production
  cache:
    key: "$CI_BUILD_NAME/$CI_BUILD_REF_NAME"
    untracked: true
    paths:
        - build/
  # Applies only to tags matching the regex: ie: v1.0.0-My-App-Release
  only:
    - /^v\d+\.\d+\.\d+-.*$/
  except:
    - branches
    - triggers

Ta część przedstawia całą pracę związaną z rozmieszczanie po poprzednich etapach, jeśli takie istnieją, C. I.

Odpowiednia część związana z rozmieszczeniem jest następująca:

# Script to run for deploying application to AWS
script:
  - apt-get --quiet install --yes python-pip # AWS CLI requires python-pip, python is installed by default
  - pip install -U pip  # pip update
  - pip install awscli  # AWS CLI installation
  - $G build -x test -x distTar # # Build the project with Gradle
  - $G distZip  # creates distribution zip for deployment
  - aws s3 cp $BUNDLE_SRC $AWS_S3_LOCATION # Uploads the zipfile to S3 and expects the AWS Code Pipeline/Code Deploy to pick up

Pierwszy krok polega na zainstalowaniu systemu zarządzania pakietami Pythona: pip. Do zainstalowania AWS CLI konieczne jest przesłanie pliku wdrożeniowego do AWS S3.]}

W tym przykładzie używamy Gradle (zdefiniowanego przez zmienną środowiskową $G); Gradle udostępnia moduł do automatycznego zamykania plików wdrażania. W zależności od typu projektu, który wdrażasz, metoda ta będzie różna dla generowania pliku zip dystrybucji my_app.zip.

Polecenie aws s3 cp $BUNDLE_SRC $AWS_S3_LOCATION przesyła plik zip dystrybucji do zdefiniowanej wcześniej lokalizacji Amazon S3. Plik ten jest następnie automatycznie wykrywany przez CodePipeline, przetwarzany i wysyłany do CodeDeploy. Na koniec, CodeDeploy wykonuje niezbędne zadania za pośrednictwem Agenta CodeDeploy, jak określono w pliku appspec.yml.

Tworzenie appspec.yml

appspec.yml definiuje zachowanie, po którym ma nastąpić CodeDeploy po otrzymaniu pliku wdrożenia.

Wraz z tym przewodnikiem dostarczono przykładowy plik wraz z przykładowymi skryptami do wykonania w różnych fazach wdrażania.

Proszę zapoznać się ze specyfikacją CodeDeploy AppSpec, aby uzyskać więcej informacji o tym, jak zbudować plik appspec.yml: http://docs.aws.amazon.com/codedeploy/latest/userguide/app-spec-ref.html

Generowanie pliku ZipFile wdrażania

Aby CodeDeploy działało poprawnie, musisz utworzyć odpowiednio wygenerowany plik zip swojej aplikacji.

Plik zip musi zawierać:

• zip root
  • appspec.yml = >instrukcje rozmieszczenia CodeDeploy
  • Skrypty etapu wdrażania
  • pod warunkiem, że próbki zostaną umieszczone w katalogu scripts w plik zip wymagałby dodania skryptu presence my_app.sh do katalogu głównego aplikacji (np. my_app katalog w zip)
  • kod dystrybucji - w naszym przykładzie będzie pod my_app katalog

Narzędzia takie jak Gradle i Maven są w stanie generować dystrybucyjne pliki zip z pewnymi zmianami w procesie generowania zip. Jeśli nie używasz takiego narzędzia, Być może będziesz musiał polecić Gitlab-CI wygenerowanie tego pliku zip w inny sposób; ta metoda jest poza zakresem niniejszego przewodnika.

Wdrażanie aplikacji do EC2

Etapy ciągłej integracji są określone przez reguły określone w gitlab-ci.yml. Przykład podany w tym przewodniku zainicjuje wdrożenie dla dowolnego odniesienia pasującego do następującego wyrażenia regularnego: /^v\d+\.\d+\.\d+-.*$/.

W tym przypadku, przepchnięcie znacznika {[68] } przez git na Twoim pilocie Gitlab zainicjuje proces wdrożenia. Możesz dostosować te zasady w zależności od wymagań projektu.

Podany przykład wykona następujące zadania podczas wykrywania znacznika v1.0.0-My-App-Alpha-Release:

• build job-skompiluj źródła
• test job-uruchom testy jednostkowe
• deploy-job-skompilować źródła, wygenerować zip dystrybucji, przesłać zip do Amazon S3

Po przesłaniu ZIP dystrybucji do Amazon S3, następują następujące kroki:

• CodePipeline wykrywa zmianę w wersji pliku zip S3
• CodePipeline sprawdza poprawność pliku
• CodePipeline wysyła sygnał, że pakiet dla CodeDeploy jest gotowy
• CodeDeploy wykonuje kroki wdrożenia
  • Start-inicjalizacja wdrożenia
  • Application Stop-wykonuje zdefiniowany skrypt dla Hooka
  • DownloadBundle-pobiera plik bundle z repozytorium S3 poprzez CodePipeline
  • BeforeInstall-wykonuje zdefiniowany skrypt dla Hooka
  • Install-kopiuje zawartość do miejsca wdrożenia zdefiniowanego w sekcji files appspec.yml
  • AfterInstall-wykonuje zdefiniowany skrypt dla Hooka
  • ApplicationStart-wykonuje zdefiniowany skrypt dla Hooka
  • ValidateService-wykonuje zdefiniowany skrypt dla Hooka
  • End-sygnalizuje Kodepipeline, że wdrożenie zostało zakończone pomyślnie

Udane zrzuty ekranu wdrożenia:

Referencje

• Gitlab-Ci QuickStart: http://docs.gitlab.com/ce/ci/quick_start/README.html
• Gitlab-CI .gitlab-ci.yml: http://docs.gitlab.com/ce/ci/yaml/README.html
• AWS CodePipeline Walkthrough: http://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html
• Zainstaluj lub Ponownie zainstaluj agenta AWS CodeDeploy: http://docs.aws.amazon.com/codedeploy/latest/userguide/how-to-run-agent-install.html
• AWS CLI Getting Started-Env : http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment
• Appspec Reference: http://docs.aws.amazon.com/codedeploy/latest/userguide/app-spec-ref.html