Artykuły
Samouczki
Interaktywne przewodniki
Wdrażanie aplikacji ImageLabeller za pomocą GitLab
.png?cdnVersion=2302)
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.
Kliknij przycisk Pobierz teraz.
Kliknij Aplikacje, a następnie Zarządzaj aplikacjami.
Rozwiń pozycję GitLab for Jira.
Kliknij przycisk Dodaj przestrzeń nazw.
Wybierz istniejącą przestrzeń nazw i kliknij przycisk Połącz. Ten przewodnik zakłada, że masz już istniejące konto GitLab i grupę GitLab.
Dodawanie klucza SSH do GitLab
Kliknij ikonę profilu w prawym górnym rogu, a następnie wybierz opcję Preferences (Preferencje).
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.
Przejdź do GitLab i kliknij przycisk New project (Nowy projekt).
Kliknij opcję 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ć.
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 mainlineDodawanie 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ą).
Utwórz dwie zmienne. Jedną dla identyfikatora klucza dostępu AWS, a drugą dla tajnego klucza dostępu AWS.
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.
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ń).
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.
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-5Utwó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 OpenDevOpsS3InfraInformacje 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-1Zadania
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 OpenDevOpsS3InfraPipeline 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 trueWypychanie 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-5Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
Kliknij identyfikator uruchomionego pipeline'u.
Kliknij zadanie, aby zobaczyć więcej szczegółów.
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).
Wybierz gałąź funkcji jako gałąź źródłową, a następnie kliknij przycisk Compare branches and continue (Porównaj gałęzie i kontynuuj).
Wybierz odpowiednie osoby w sekcjach Assignee (Osoba przypisana) i Reviewer (Recenzent).
Kliknij przycisk Create merge request (Utwórz wniosek o scalenie).
Przejrzyj zmiany kodu, a następnie kliknij przycisk Approve (Zatwierdź).
Kliknij opcję CI/CD, a następnie opcję Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u wniosku o scalenie.
Kliknij identyfikator pipeline'u. Zwróć uwagę, że zadanie merge-request-pipeline-job jest jedynym uruchomionym zadaniem.
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.
Kliknij kolejno opcje CI/CD i Pipelines (Pipeline'y). Kliknij identyfikator pipeline'u.
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.
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ć.
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 mainlineRepozytorium 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).
Wprowadź nazwę, zaznacz pozycję read_repository i kliknij przycisk Create deploy token (Utwórz token wdrożenia).
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.
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.
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ć.
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 mainlineMusisz 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.
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-8Utwó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-1Wykonanie 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-changesetTen 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-1Wiersz 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.gitWypychanie 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-8Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
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.
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić uruchomiony pipeline wniosku o scalenie.
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.
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.
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ć.
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 mainlineMusisz 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.
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-10Utwó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-1Wykonanie 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_predictionsWypychanie 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-10Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
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.
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.
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.
Społeczność DevOps
Ścieżka szkoleniowa DevOps
