Artykuły
Samouczki
Interaktywne przewodniki
Wdrażanie aplikacji ImageLabeller za pomocą GitLab
![Warren Marusiak — zdjęcie portretowe](https://wac-cdn.atlassian.com/dam/jcr:7509aefb-43e8-401d-90fe-0850cbe6bb13/wmarusiak_headshot%20(1).png?cdnVersion=1880)
Warren Marusiak
Starszy propagator techniczny
Aby zademonstrować sposób opracowywania i wdrażania aplikacji oraz zarządzania nimi przy użyciu Jira Software oraz różnych połączonych narzędzi, nasz zespół utworzył ImageLabeller, prostą aplikację demonstracyjną opartą na usłudze AWS, która wykorzystuje uczenie maszynowe do oznaczania etykietami obrazów.
Na tej stronie opisano, jak wdrożyć aplikację ImageLabeller za pomocą GitLab. Przed rozpoczęciem najlepiej zapoznać się ze stronami na temat architektury aplikacji ImageLabeller oraz konfiguracji AWS SageMaker, aby uzyskać kontekst.
Wymagania wstępne
Jeśli nie masz jeszcze grupy GitLab, utwórz ją od podstaw, wykonując procedurę opisaną w tym przewodniku GitLab.
Publiczne repozytoria GitHub z kodem aplikacji ImageLabeller
Film z demonstracją integracji systemu Jira z GitLab
Integracja systemu Jira z GitLab
W systemie Jira kliknij kolejno opcje Tablica, Aplikacje, a następnie GitLab.
![Zrzut ekranu menu rozwijanego w Jira Software umożliwiającego przejście do GitLab](https://wac-cdn.atlassian.com/dam/jcr:233af7c0-b3a2-46fd-ad94-facbc7611a9f/screenshot_jsw_appsdropdownmenugitlab.png?cdnVersion=1880)
Kliknij przycisk Pobierz teraz.
![Okno modalne aplikacji GitLab w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:e1c978e6-347f-44e1-bfc1-a36237028ea1/screenshot_jsw_gitlabapp.png?cdnVersion=1880)
Kliknij Aplikacje, a następnie Zarządzaj aplikacjami.
![Okno modalne aplikacji GitLab w Jira Software z menu rozwijanym](https://wac-cdn.atlassian.com/dam/jcr:5ac45ad7-f8cc-4ee9-ab8e-cbfb6c967709/screenshot_jsw_appsdropdownmenumanage.png?cdnVersion=1880)
Rozwiń pozycję GitLab for Jira.
![Rozwinięcie obszaru GitLab na ekranie zarządzania aplikacjami w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:3cf62621-d30a-4736-be56-ceaf0096a422/screenshot_jsw_manageappsgitlab.png?cdnVersion=1880)
Kliknij przycisk Dodaj przestrzeń nazw.
![Ekran dodawania przestrzeni nazw do konfiguracji GitLab w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:69aad4ef-ff26-422d-8953-23e4d21b79d1/screenshot_jsw_gitlabconfiguration.png?cdnVersion=1880)
Wybierz istniejącą przestrzeń nazw i kliknij przycisk Połącz. Ten przewodnik zakłada, że masz już istniejące konto GitLab i grupę GitLab.
![Łączenie z przestrzenią nazw GitLab w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:24dff71f-6c9e-45a7-8da9-1dce709e8e11/screenshot_jsw_manageappslinknamespace.png?cdnVersion=1880)
Dodawanie klucza SSH do GitLab
Kliknij ikonę profilu w prawym górnym rogu, a następnie wybierz opcję Preferences (Preferencje).
![Przechodzenie do preferencji za pomocą menu rozwijanego w GitLab](https://wac-cdn.atlassian.com/dam/jcr:dbccc133-4c4c-422c-8009-f7d0f6c30053/screenshot_jsw_sshkeygitlab.png?cdnVersion=1880)
Kliknij opcję SSH Keys (Klucze SSH) i wykonaj instrukcje, aby wygenerować nowy klucz SSH lub użyć istniejącego klucza SSH.
Utworzenie repozytorium dla infrastruktury AWS S3
Standardowa pętla pracy programisty polega zazwyczaj na pobraniu przez programistę zadania z systemu Jira, przeniesieniu go do kolumny prac w toku, a następnie przystąpieniu do prac programistycznych. Identyfikator zgłoszenia Jira jest kluczem łączącym pracę programisty ze zgłoszeniem Jira. Jest on podstawowym składnikiem integracji między dwoma systemami.
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium infrastruktury AWS S3 do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-5.
![Tworzenie nowego zgłoszenia na tablicy w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:6e6bf187-8e99-4a02-814d-9eaa13d22ce6/screenshot_jsw_createissues3infragitlab.png?cdnVersion=1880)
Przejdź do GitLab i kliknij przycisk New project (Nowy projekt).
![Przechodzenie do tworzenia nowego projektu w GitLab](https://wac-cdn.atlassian.com/dam/jcr:2d21e5c9-67ce-48df-b183-6d8dda26ea2b/screenshot_gitlab_newproject.png?cdnVersion=1880)
Kliknij opcję Create blank project (Utwórz pusty projekt).
![Tworzenie nowego projektu w GitLab](https://wac-cdn.atlassian.com/dam/jcr:a6eccbb5-024c-43cd-bcc3-a26896d473f8/screenshot_gitlab_createnewproject.png?cdnVersion=1880)
Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
![Tworzenie nowego projektu — szczegółowy widok ekranu w GitLab](https://wac-cdn.atlassian.com/dam/jcr:9d941c88-2136-4235-b063-61a63dea9296/screenshot_gitlab_createnewprojectdetails.png?cdnVersion=1880)
W terminalu przejdź do repozytorium s3_infra i uruchom poniższe polecenie, aby wypchnąć plik template.yml AWS CloudFormation do GitLab.
git add --all
git commit -m "IM-5 add s3_infra repository to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/s3_infra.git
git branch -m mainline
git push -u origin mainline
Dodawanie klucza dostępu AWS
Kliknij opcję Settings (Ustawienia), a następnie pozycję CI/CD. Przewiń w dół i rozwiń obszar Variables (Zmienne). Kliknij przycisk Add variable (Dodaj zmienną).
![Strona ustawień CI/CD w GitLab](https://wac-cdn.atlassian.com/dam/jcr:1e0cd540-9715-4fd9-ae2f-3aa8d478f882/screenshot_gitlab_awskeys.png?cdnVersion=1880)
Utwórz dwie zmienne. Jedną dla identyfikatora klucza dostępu AWS, a drugą dla tajnego klucza dostępu AWS.
![Okno modalne dodawania zmiennej pozwalające dodać klucze AWS w GitLab](https://wac-cdn.atlassian.com/dam/jcr:d71599c4-5ee0-4d45-bf49-225c0a5dbb39/screenshot_gitlab_addvariables.png?cdnVersion=1880)
Zabezpiecz zmienne tak, aby były używane jedynie przez pipeline'y uruchamiane na chronionych gałęziach i tagach. Przyznaj użytkownikowi IAM powiązanemu z kluczem dostępu AWS dostęp administratora. Możesz również zdecydować się na użycie bardziej szczegółowych ustawień kontroli dostępu, wybierając poszczególne zasady dostępu AWS.
![Klucze AWS wymienione w sekcji zmiennych na stronie ustawień CI/CD w GitLab](https://wac-cdn.atlassian.com/dam/jcr:91899e7a-10f8-4ece-9c15-6545236b3ffa/screenshot_gitlab_moreaccesscontrols.png?cdnVersion=1880)
Konfiguracja chronionych gałęzi w celu uzyskania dostępu do chronionych zmiennych
Kliknij opcję Settings (Ustawienia), a następnie Repository (Repozytorium). Przewiń w dół i rozwiń obszar Protected branches (Gałęzie chronione).
Wprowadź przedrostek identyfikatora zgłoszenia Jira oraz symbol *.
W tym przykładzie, gdzie identyfikatory zgłoszeń Jira mają postać IM-5, IM-6 itp., przedrostkiem jest IM-.
Wprowadź IM-* i kliknij przycisk Protect (Chroń).
![Konfigurowanie gałęzi chronionych w GitLab](https://wac-cdn.atlassian.com/dam/jcr:81267f5a-f6a1-42a1-8997-9b662b33e44c/screenshot_gitlab_congfigureprotectedbranches.png?cdnVersion=1880)
Gałąź mainline oraz gałęzie IM-* zostaną wyświetlone jako gałęzie chronione.
Konfiguracja środowisk wdrożeniowych
Kliknij kolejno opcje Deployments (Wdrożenia), a następnie Environments (Środowiska). Kliknij przycisk New environment (Nowe środowisko), aby dodać nowe środowiska. W tym przykładzie występują środowiska testowe w regionach US-WEST-1 i US-EAST-2 oraz trzy środowiska produkcyjne w regionach US-WEST-2, US-EAST-1 i CA-CENTRAL-1.
![Konfigurowanie środowisk wdrożeniowych w GitLab](https://wac-cdn.atlassian.com/dam/jcr:abdad29f-4810-45c3-97b9-4a4e7cc33686/screenshot_gitlab_deploymentenvironments.png?cdnVersion=1880)
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium s3_infra w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
git checkout -b IM-5
Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego.
stages:
- merge-request
- test-us-west-1
- test-us-east-2
- production-us-west-2
- production-us-east-1
- production-ca-central-1
merge-request-pipeline-job:
stage: merge-request
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
script:
- echo "This pipeline always succeeds and enables merges during merge requests"
- echo true
deploy-test-us-west-1:
stage: test-us-west-1
environment: test-us-west-1
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
deploy-test-us-east-2:
stage: test-us-east-2
environment: test-us-east-2
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region us-east-2 --template-file template.yml --stack-name OpenDevOpsS3Infra
deploy-production-us-west-2:
stage: production-us-west-2
environment: production-us-west-2
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region us-west-2 --template-file template.yml --stack-name OpenDevOpsS3Infra
deploy-production-us-east-1:
stage: production-us-east-1
environment: production-us-east-1
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region us-east-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
deploy-production-ca-central-1:
stage: production-ca-central-1
environment: production-ca-central-1
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region ca-central-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
Informacje o pliku .gitlab-ci.yml
Etapy
Dodaj blok stages, aby zdefiniować kolejność wykonywania pipeline'u w GitLab. Etapy są wykonywane w kolejności, w której zostały zdefiniowane w bloku stages. Zadania powiązane z danym etapem są wykonywane równolegle.
stages:
- merge-request
- test-us-west-1
- test-us-east-2
- production-us-west-2
- production-us-east-1
- production-ca-central-1
Zadania
Zadania są powiązane z etapem i mogą być powiązane ze środowiskiem. Reguły określają, czy konkretne zadanie będzie wykonywane. Reguła w tym przykładzie sprawdza, czy gałąź pipeline'u nie jest gałęzią domyślną oraz czy pipeline nie jest uruchamiany automatycznie w ramach wniosku o scalenie.
Dla każdego zadania można zdefiniować inny obraz. Obrazy można skonfigurować za pomocą narzędzi niezbędnych do tworzenia skryptów zadań. Sekcja script definiuje zestaw kroków uruchamianych podczas wykonywania zadania.
deploy-test-us-west-1:
stage: test-us-west-1
environment: test-us-west-1
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
Pipeline wniosku o scalenie
Pipeline jest uruchamiany automatycznie przez GitLab po zatwierdzeniu wniosku o scalenie. Zadanie można utworzyć dla tego pipeline'u przez dodanie reguły. W tym przykładzie zadanie zawsze przebiega pomyślnie.
merge-request-pipeline-job:
stage: merge-request
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
script:
- echo "This pipeline always succeeds and enables merges during merge requests"
- echo true
Wypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-5 repozytorium s3_infra. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
git add --all
git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
git push -u origin IM-5
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
![Ekran pipeline'ów CI/CD w GitLab](https://wac-cdn.atlassian.com/dam/jcr:82e3a1fc-6a33-4dc7-88e5-5a1d7650ce26/screenshot_gitlab_runningworkflows.png?cdnVersion=1880)
Kliknij identyfikator uruchomionego pipeline'u.
![Identyfikator uruchomionego pipeline'u w GitLab](https://wac-cdn.atlassian.com/dam/jcr:444f2984-262a-4386-8009-d7a248fb5d8e/screenshot_gitlab_pipelineID1.png?cdnVersion=1880)
Kliknij zadanie, aby zobaczyć więcej szczegółów.
![Ekran szczegółów zadania dla pipeline'u uruchomionego w GitLab](https://wac-cdn.atlassian.com/dam/jcr:2c69708d-2d3b-443b-887a-57b20b6c2119/screenshot_gitlab_job.png?cdnVersion=1880)
Tworzenie wniosku o scalenie
Aby utworzyć wniosek o scalenie, kliknij opcję Merge requests (Wnioski o scalenie), a następnie przycisk Create merge request (Utwórz wniosek o scalenie).
![Ekran wniosków o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:a6ea4df4-88e6-4d41-bd61-99f17f241520/screenshot_gitlab_mergerequest.png?cdnVersion=1880)
Wybierz gałąź funkcji jako gałąź źródłową, a następnie kliknij przycisk Compare branches and continue (Porównaj gałęzie i kontynuuj).
![Porównanie gałęzi źródłowej i gałęzi docelowej w GitLab](https://wac-cdn.atlassian.com/dam/jcr:f3567b59-ee5e-42b3-87b3-f47b494383c5/screenshot_gitlab_newmergerequest.png?cdnVersion=1880)
Wybierz odpowiednie osoby w sekcjach Assignee (Osoba przypisana) i Reviewer (Recenzent).
![Wybór recenzenta wniosku o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:668196dc-188e-4e9b-a24b-0f751a2b296e/screenshot_gitlab_choosereviewer.png?cdnVersion=1880)
Kliknij przycisk Create merge request (Utwórz wniosek o scalenie).
![Kliknięcie przycisku utworzenia wniosku o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:0f7c8d33-0df5-4843-b32f-297a9bc955c9/screenshot_gitlab_createmergerequest.png?cdnVersion=1880)
Przejrzyj zmiany kodu, a następnie kliknij przycisk Approve (Zatwierdź).
![Ekran szczegółów wniosku o scalenie w GitLab, na którym można przeglądać zmiany](https://wac-cdn.atlassian.com/dam/jcr:7afdc633-e428-4bb5-ac06-4b1daa5cdf98/screenshot_gitlab_reviewmerge.png?cdnVersion=1880)
Kliknij opcję CI/CD, a następnie opcję Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u wniosku o scalenie.
![Przechodzenie do ekranu pipeline'ów w GitLab w celu przejrzenia uruchomionych wniosków o scalenie](https://wac-cdn.atlassian.com/dam/jcr:b75761e8-0f3e-48b4-8826-0e92ee7bebe3/screenshot_gitlab_pipelines.png?cdnVersion=1880)
Kliknij identyfikator pipeline'u. Zwróć uwagę, że zadanie merge-request-pipeline-job jest jedynym uruchomionym zadaniem.
![Strona ze szczegółami pipeline'u przedstawiająca tylko zadanie merge-request-pipeline-job uruchomione w GitLab](https://wac-cdn.atlassian.com/dam/jcr:0d4ba1f1-4192-435e-9eed-033f13fe94a2/screenshot_gitlab_pipelineran.png?cdnVersion=1880)
Wróć do wniosku o scalenie, klikając opcję Merge requests (Wnioski o scalenie), a następnie kliknij aktywny wniosek o scalenie i przycisk Merge (Scal). To spowoduje zainicjowanie kolejnego pipeline'u.
![Scalanie aktywnego wniosku o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:2e2aa09f-fd1f-4af5-bb7f-4ff24db04934/screenshot_gitlab_mergerequests.png?cdnVersion=1880)
Kliknij kolejno opcje CI/CD i Pipelines (Pipeline'y). Kliknij identyfikator pipeline'u.
![Strona ze szczegółami pipeline'u w GitLab przedstawiająca scalenie gałęzi IM-5 z gałęzią mainline](https://wac-cdn.atlassian.com/dam/jcr:0ae790e4-8cd3-48ea-86e2-d2f71b26a6a9/screenshot_gitlab_pipelineID2.png?cdnVersion=1880)
Utworzenie repozytorium SystemTests
Przejdź do systemu Jira i utwórz zgłoszenie Jira dotyczące dodania repozytorium SystemTests do GitLab. Zanotuj identyfikator tego zgłoszenia Jira. W tym przykładzie jest to IM-7.
![Tworzenie zgłoszenia o dodanie repozytorium GitLab dla funkcji AWS Lambda SubmitImage w Jira Software](https://wac-cdn.atlassian.com/dam/jcr:8b8cd7a2-3a69-4d5d-87a9-5ed5b42767fc/screenshot_jsw_createissueaddgitlabreposystemtest.png?cdnVersion=1880)
Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
![Wypełnianie szczegółów projektu podczas tworzenia nowego projektu w GitLab](https://wac-cdn.atlassian.com/dam/jcr:d0ce901f-13d5-4f3d-b2a3-67fe9867c92e/screenshot_gitlab_createnewprojectsubmitiamge.png?cdnVersion=1880)
W terminalu przejdź do repozytorium SystemTests i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
git add --all
git commit -m "IM-7 add SystemTests repository to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/systemtests.git
git branch -m mainline
git push -u origin mainline
Repozytorium SystemTests nie wymaga pliku .gitlab-ci.yml. Nie ma własnych pipeline'ów, ponieważ udostępnia testy do uruchomienia w innych pipeline'ach. Zwróć uwagę na zdalny adres URL repozytorium SystemTests. Pipeline'y CI/CD SubmitImage, GetImageLabel i InvokeLabeller będą klonować repozytorium SystemTests podczas poszczególnych kroków testów. Konieczne będzie zaktualizowanie plików gitlab-ci.yml utworzonych później repozytoriów o poprawny adres URL.
Dodawanie tokena wdrożenia
Musisz dodać token wdrożenia, aby sklonować to repozytorium podczas wykonywania innych pipeline'ów. Kliknij opcję Settings (Ustawienia), a następnie Repository (Repozytorium). Przewiń w dół i rozwiń obszar Deploy tokens (Tokeny wdrożenia).
![Wprowadzanie przykładowej nazwy „cloneMe” w obszarze tokenów wdrożenia w GitLab](https://wac-cdn.atlassian.com/dam/jcr:9d40815a-f855-4f4f-ac01-81619b6740a5/screenshot_gitlab_deploytoken.png?cdnVersion=1880)
Wprowadź nazwę, zaznacz pozycję read_repository i kliknij przycisk Create deploy token (Utwórz token wdrożenia).
![Zaznaczanie pola wyboru „read_repository” na stronie ustawień tokenów wdrożenia w GitLab](https://wac-cdn.atlassian.com/dam/jcr:968e49e7-2165-4903-8da9-220d3cb2ef08/screenshot_gitlab_createdeploytokenmodal.png?cdnVersion=1880)
Nazwa użytkownika tokena wdrożenia jest generowana automatycznie. Hasło tokena wdrożenia podaje się jeden raz podczas jego tworzenia. Dodaj token do narzędzia zarządzania tajnymi kluczami, aby można było się do niego później odwołać. W dalszej części tego przewodnika odniesieniem do nazwy użytkownika tokena wdrożenia będzie gitlab_deploy_token, a odniesieniem do hasła tokena wdrożenia — gitlab_deploy_password.
![Ekran tokenów wdrożenia w GitLab przedstawiający nazwę użytkownika i hasło tokena wdrożenia](https://wac-cdn.atlassian.com/dam/jcr:ee87828c-8430-46d6-a576-b581aff8d6a8/screenshot_GitLabDeployTokenCreation.png?cdnVersion=1880)
Utworzenie repozytorium dla funkcji AWS Lambda SubmitImage
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium funkcji AWS Lambda SubmitImage do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-8.
![Tablica aplikacji ImageLabeller w Jira Software — wyróżnienie zgłoszenia IM-8 o dodanie repozytorium GitLab dla funkcji AWS Lambda SubmitImage](https://wac-cdn.atlassian.com/dam/jcr:63278d8a-9f7f-47af-9b14-c9e2fa24b874/screenshot_jsw_issueaddissuecreatereposubmitimage.png?cdnVersion=1880)
Przejdź do GitLab, a następnie kliknij kolejno opcje New project (Nowy projekt) i Create blank project (Utwórz pusty projekt). Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
![Zrzut ekranu tworzenia nowego projektu „SubmitImage” w GitLab](https://wac-cdn.atlassian.com/dam/jcr:d0ce901f-13d5-4f3d-b2a3-67fe9867c92e/screenshot_gitlab_createnewprojectsubmitiamge.png?cdnVersion=1880)
W terminalu przejdź do repozytorium SumbitImage i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
git add --all
git commit -m "IM-8 add SubmitImage to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/submitimage.git
git branch -m mainline
git push -u origin mainline
Musisz dodać klucze dostępu AWS, skonfigurować gałęzie chronione i skonfigurować środowiska wdrożeniowe.
Następnie dodaj klucze wdrożenia z repozytorium SystemTests, aby umożliwić pobranie pipeline'u GitLab SubmitImage i uruchom SystemTests.
Na końcu dodaj swój identyfikator konta AWS jako zmienną CI/CD.
![Zrzut ekranu zmiennych w GitLab](https://wac-cdn.atlassian.com/dam/jcr:e7d826c0-bc7f-4bf8-9849-ac456fe5a3af/screenshot_gitlab_variables.png?cdnVersion=1880)
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium SubmitImage w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
git checkout -b IM-8
Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
stages:
- merge-request
- run-unit-tests
#US-WEST-1
- deploy-us-west-1
- test-us-west-1
#US-EAST-2
- deploy-us-east-2
- test-us-east-2
#US-WEST-2
- deploy-us-west-2
- test-us-west-2
#US-EAST-1
- deploy-us-east-1
- test-us-east-1
#CA-CENTRAL-1
- deploy-ca-central-1
- test-ca-central-1
merge-request-pipeline-job:
stage: merge-request
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
script:
- echo "This pipeline always succeeds and enables merge"
- echo true
run-unit-tests:
stage: run-unit-tests
image: golang:buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
script:
- cd submitImage
- go test ./opendevopslambda/...
#US-WEST-1
deploy-us-west-1:
stage: deploy-us-west-1
environment: test-us-west-1
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset
#test-us-west-1:
# stage: test-us-west-1
# environment: test-us-west-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-west-1
#US-EAST-2
deploy-us-east-2:
stage: deploy-us-east-2
environment: test-us-east-2
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset
#test-us-east-2:
# stage: test-us-east-2
# environment: test-us-east-2
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-east-2
#US-WEST-2
deploy-us-west-2:
stage: deploy-us-west-2
environment: production-us-west-2
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset
#test-us-west-2:
# stage: test-us-west-2
# environment: production-us-west-2
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-west-2
#US-EAST-1
deploy-us-east-1:
stage: deploy-us-east-1
environment: production-us-east-1
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset
#test-us-east-1:
# stage: test-us-east-1
# environment: production-us-east-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-east-1
#CA-CENTRAL-1
deploy-central-1:
stage: deploy-ca-central-1
environment: production-ca-central-1
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset
#test-central-1:
# stage: test-ca-central-1
# environment: production-ca-central-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=ca-central-1
Wykonanie testów integracyjnych jest na ten moment ujęte w komentarz. Testy systemowe zakończą się powodzeniem tylko wówczas, gdy cała aplikacja zostanie wdrożona. Po wdrożeniu wszystkich komponentów aplikacji ImageLabeller usuń oznaczenie komentarzem kroki testów integracyjnych w swoim repozytorium i wykonaj kolejne wypchnięcie, aby uruchomić pipeline wdrożenia. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
Informacje o pliku .gitlab-ci.yml
Ten krok wykonuje testy jednostkowe będące częścią repozytorium SubmitImage.
unit-test-us-west-1:
stage: unit-test-us-west-1
environment: test-us-west-1
image: golang:buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
script:
- cd submitImage
- go test ./opendevopslambda/...
To zadanie wykorzystuje AWS SAM do wdrożenia funkcji AWS Lambda SubmitImage. Zwróć uwagę na sekcję before_script. Ten krok jest uruchamiany przed sekcją script i można go używać do instalowania zależności i konfigurowania różnych narzędzi.
deploy-us-west-1:
stage: deploy-us-west-1
environment: test-us-west-1
image: python:latest
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
- wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
- rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
- export PATH=$PATH:/usr/local/go/bin
- go version
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
- sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset
Ten krok pobiera i uruchamia testy integracyjne w repozytorium SystemTests. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
test-us-west-1:
stage: test-us-west-1
environment: test-us-west-1
image: golang:buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
- cd systemtests
- go test -v ./... -aws_region=us-west-1
Wiersz git clone zawiera odwołanie do utworzonego wcześniej tokena wdrożenia.
- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
Wypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-8 repozytorium SubmitImage. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
git add --all
git commit -m "IM-8 add .gitlab-ci.yml to SubmitImage"
git push -u origin IM-8
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
![Zrzut ekranu przebiegu pipeline'u w GitLab](https://wac-cdn.atlassian.com/dam/jcr:9bef95c2-61b6-4b89-8aaa-3683083605dc/screenshot_gitlab_pipelinerun.png?cdnVersion=1880)
Tworzenie wniosku o scalenie
Utwórz wniosek o scalenie, aby dokonać wdrożenia w środowiskach produkcyjnych po tym, jak GitLab przeprowadzi wdrożenia w środowiskach testowych. Wybierz gałąź IM-8.
![Zrzut ekranu wniosków o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:e6915a7c-00f3-4ee4-b1af-df7d936033a5/screenshot_gitlab_mergerequestssubmitimage.png?cdnVersion=1880)
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić uruchomiony pipeline wniosku o scalenie.
![Zrzut ekranu uruchamiania wniosku o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:edec3e6b-830e-4fe8-af86-f67178bd83ba/screenshot_gitlab_runningmergerequest.png?cdnVersion=1880)
Po zakończeniu pipeline'u wniosku o scalenie scal zmiany z gałęzią mainline. Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić uruchomiony pipeline produkcyjny.
![Zrzut ekranu uruchamiania pipeline'u produkcyjnego w GitLab](https://wac-cdn.atlassian.com/dam/jcr:29153944-0768-448a-8cdb-6c9e8f2989b1/screenshot_gitlab_runningproductionpipeline.png?cdnVersion=1880)
Utworzenie repozytorium dla funkcji AWS Lambda InvokeLabeller
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium funkcji AWS Lambda InvokeLabeller do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-10.
![Zrzut ekranu zgłoszenia jira o utworzenie repozytorium „InvokeLabeller” w GitLab](https://wac-cdn.atlassian.com/dam/jcr:2917371c-fe94-4059-add8-2ca8d5739908/screenshot_jsw_createissuerepoinvokelabellergitlab.png?cdnVersion=1880)
Przejdź do GitLab, a następnie kliknij kolejno opcje New project (Nowy projekt) i Create blank project (Utwórz pusty projekt). Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
![Zrzut ekranu tworzenia nowego projektu „InvokeLabeller” w GitLab](https://wac-cdn.atlassian.com/dam/jcr:f8c18f79-7ac0-4c55-81f2-b877981bdeba/screenshot_gitlab_createprojectinvokelabeller.png?cdnVersion=1880)
W terminalu przejdź do repozytorium InvokeLabeller i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
git add --all
git commit -m "IM-10 add InvokeLabeller to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/invokelabeller.git
git branch -m mainline
git push -u origin mainline
Musisz dodać klucze dostępu AWS, skonfigurować gałęzie chronione i skonfigurować środowiska wdrożeniowe.
Następnie dodaj klucze wdrożenia z repozytorium SystemTests, aby umożliwić pobranie pipeline'u GitLab InvokeLabeller i uruchom SystemTests.
Na końcu dodaj swój identyfikator konta AWS jako zmienną CI/CD.
![Zrzut ekranu strony zmiennych w GitLab](https://wac-cdn.atlassian.com/dam/jcr:e958bb2f-019a-417e-88b6-a9fa33c082be/screenshot_gitlab_variables2.png?cdnVersion=1880)
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium InvokeLabeller w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
git checkout -b IM-10
Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
stages:
- merge-request
- run-unit-tests
#US-WEST-1
- deploy-us-west-1
- test-us-west-1
#US-EAST-2
- deploy-us-east-2
- test-us-east-2
#US-WEST-2
- deploy-us-west-2
- test-us-west-2
#US-EAST-1
- deploy-us-east-1
- test-us-east-1
#CA-CENTRAL-1
- deploy-ca-central-1
- test-ca-central-1
merge-request-pipeline-job:
stage: merge-request
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
script:
- echo "This pipeline always succeeds and enables merge"
- echo true
run-unit-tests:
stage: run-unit-tests
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install pytest
- pip3 install moto
- pip3 install -r tst/requirements.txt --user
script:
- python3 -m pytest -v tst/unit --junitxml=test-reports/report.xml
#US-WEST-1
deploy-us-west-1:
stage: deploy-us-west-1
environment: test-us-west-1
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
- sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset
#test-us-west-1:
# stage: test-us-west-1
# environment: test-us-west-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-west-1
#US-EAST-2
deploy-us-east-2:
stage: deploy-us-east-2
environment: test-us-east-2
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
- sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset
#test-us-east-2:
# stage: test-us-east-2
# environment: test-us-east-2
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-east-2
#US-WEST-2
deploy-us-west-2:
stage: deploy-us-west-2
environment: production-us-west-2
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
- sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset
#test-us-west-2:
# stage: test-us-west-2
# environment: production-us-west-2
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-west-2
#US-EAST-1
deploy-us-east-1:
stage: deploy-us-east-1
environment: production-us-east-1
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
- sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset
#test-us-east-1:
# stage: test-us-east-1
# environment: production-us-east-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=us-east-1
#CA-CENTRAL-1
deploy-central-1:
stage: deploy-ca-central-1
environment: production-ca-central-1
image: python:3.8-buster
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
before_script:
- pip3 install awscli --upgrade
- pip3 install aws-sam-cli --upgrade
script:
- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
- sam build
- sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
- sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset
#test-central-1:
# stage: test-ca-central-1
# environment: production-ca-central-1
# image: golang:buster
# rules:
# - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
# script:
# - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
# - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
# - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
# - cd systemtests
# - go test -v ./... -aws_region=ca-central-1
Wykonanie testów integracyjnych jest na ten moment ujęte w komentarz. Testy systemowe zakończą się powodzeniem tylko wówczas, gdy cała aplikacja zostanie wdrożona. Po wdrożeniu wszystkich komponentów aplikacji ImageLabeller usuń oznaczenie komentarzem kroki testów integracyjnych w swoim repozytorium i wykonaj kolejne wypchnięcie, aby uruchomić pipeline wdrożenia. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
Aktualizacja pliku src/app.py o punkt końcowy AWS SageMager
Otwórz plik src/app.py w repozytorium InvokeLabeller i wyszukaj pozycję query_endpoint. Zmień wartości endpoint_name i client region_name zgodnie z notesem AWS SageMaker.
def query_endpoint(img):
endpoint_name = 'jumpstart-dft-image-labeller-endpoint'
client = boto3.client(service_name='runtime.sagemaker', region_name='us-west-1')
response = client.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/x-image', Body=img)
model_predictions = json.loads(response['Body'].read())['predictions'][0]
return model_predictions
Wypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-10 repozytorium InvokeLabeller. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
git add --all
git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
git push -u origin IM-10
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
![Zrzut ekranu uruchamiania pipeline'u w GitLab](https://wac-cdn.atlassian.com/dam/jcr:06f6da58-4877-422c-a2cc-22873f81ae59/screenshot_gitlab_pipelinerunninginvokelabeller.png?cdnVersion=1880)
Tworzenie wniosku o scalenie
Utwórz wniosek o scalenie, aby dokonać wdrożenia w środowiskach produkcyjnych po tym, jak GitLab przeprowadzi wdrożenia w środowiskach testowych. Wybierz gałąź IM-10.
![Zrzut ekranu tworzenia wniosku o scalenie w GitLab](https://wac-cdn.atlassian.com/dam/jcr:46a6d6b8-6086-4ce3-81e6-4f2e84ea90db/screenshot_gitlab_createmergerequestinvokelabeller.png?cdnVersion=1880)
Po zakończeniu pipeline'u wniosku o scalenie scal zmiany z gałęzią mainline. Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić uruchomiony pipeline produkcyjny.
![Zrzut ekranu uruchamiania pipeline'u produkcyjnego w GitLab](https://wac-cdn.atlassian.com/dam/jcr:221f4820-b1f9-455b-bf5c-b64dba9b64f5/screenshot_gitlab_runningproductionpipelineinvokelabeller.png?cdnVersion=1880)
Jeśli udało Ci się dotrzeć aż tutaj, to gratuluję! Aplikacja ImageLabeller została wdrożona. Kolejnym krokiem będzie skonfigurowanie monitorowania aplikacji ImageLabeller przy użyciu Opsgenie.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
![Ilustracja DevOps](https://wac-cdn.atlassian.com/dam/jcr:bd9d8b2c-ca36-444f-8595-719cb1990e64/Devops-community.png?cdnVersion=1880)
Społeczność DevOps
![Ilustracja DevOps](https://wac-cdn.atlassian.com/dam/jcr:297108ea-d232-4368-af51-b53af230c4fe/Simulation-workshop.png?cdnVersion=1880)
Ścieżka szkoleniowa DevOps
![Ilustracja przedstawiająca mapę](https://wac-cdn.atlassian.com/dam/jcr:25f6330a-4191-408f-a4e5-2e24bfba67b4/Maturity-model.png?cdnVersion=1880)