Bereitstellen von ImageLabeller mit GitLab
.png?cdnVersion=2569)
Warren Marusiak
Senior Technical Evangelist
Um zu demonstrieren, wie Anwendungen mit Jira Software und verschiedenen verbundenen Tools entwickelt, bereitgestellt und verwaltet werden können, hat unser Team ImageLabeller entwickelt. Dabei handelt es sich um eine einfache Demo-Anwendung, die auf AWS basiert und maschinelles Lernen nutzt, um Images mit Stichwörtern zu versehen.
Auf dieser Seite wird das Bereitstellen von ImageLabeller mit GitLab behandelt. Wir empfehlen dir, vorab die Seiten zur ImageLabeller-Architektur und zur AWS SageMaker-Einrichtung zu lesen, um mehr über den Kontext zu erfahren.
Voraussetzungen
Falls du noch keine GitLab-Organisation hast, befolge die Schritte in diesem GitLab-Leitfaden, um eine neue Organisation zu erstellen.
Öffentlich zugängliche GitHub-Repositorys mit ImageLabeller-Code
Demo-Video zur Integration zwischen Jira und GitLab
Integrieren von Jira und GitLab
Klicke in Jira auf Board, dann auf Apps und dann auf GitLab.
Klicke auf Jetzt herunterladen.
Klicke auf Apps und dann auf Apps verwalten.
Erweitere den Eintrag "GitLab for Jira".
Klicke auf Add namespace (Namespace hinzufügen).
Wähle deinen bestehenden Namespace aus, und klicke auf Verknüpfen. In dieser Anleitung wird davon ausgegangen, dass du bereits ein GitLab-Konto und eine GitLab-Gruppe hast.
Hinzufügen des SSH-Schlüssels zu GitLab
Klicke oben rechts auf dein Profilsymbol und dann auf Einstellungen.
Klicke auf SSH-Schlüssel und befolge die Anweisungen, um einen neuen SSH-Schlüssel zu generieren oder einen vorhandenen SSH-Schlüssel zu verwenden.
Erstellen eines Repositorys für die AWS S3-Infrastruktur
In einem standardmäßigen Entwicklungszyklus wählen Entwickler normalerweise Tasks aus Jira aus, verschieben sie in den Bearbeitungsstatus und erledigen dann die Entwicklungsarbeit. Die Jira-Vorgangs-ID ist der Schlüssel, der die Entwicklungsarbeit mit dem Jira-Vorgang verbindet. Er ist die zentrale Integrationskomponente zwischen den beiden Systemen.
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines AWS S3-Infrastruktur-Repositorys zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-5".
Klicke in GitLab auf Neues Projekt.
Klicke auf Create blank project (Leeres Projekt erstellen).
Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum Repository "s3_infra" und führe den folgenden Befehl aus, um deine AWS CloudFormation-Datei "template.yml" an GitLab zu pushen.
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 mainlineHinzufügen des AWS-Zugriffsschlüssels
Klicke auf Einstellungen und dann auf CI/CD. Scrolle nach unten und erweitere den Punkt Variablen. Klicke auf Add variable (Variable hinzufügen).
Erstelle zwei Variablen: eine für deine AWS-Zugangsschlüssel-ID und eine für deinen geheimen AWS-Zugriffsschlüssel.
Schütze die Variablen so, dass sie nur von Pipelines verwendet werden können, die auf geschützte Branches und Tags zurückgreifen. Gewähre dem mit dem AWS-Zugriffsschlüssel verknüpften IAM-Benutzer Administratorzugriff. Du kannst dich auch für eine detailliertere Zugriffskontrolle entscheiden, indem du individuelle AWS-Zugriffsrichtlinien auswählst.
Konfigurieren von geschützten Branches für den Zugriff auf geschützte Variablen
Klicke auf Einstellungen und dann auf Repository. Scrolle nach unten, und erweitere den Punkt Protected branches (Geschützte Branches).
Gib dein Jira-Vorgangs-ID-Präfix und ein Sternchen (*) ein.
Die Jira-Vorgangs-IDs ähneln "IM-5" und "IM-6" in diesem Beispiel: Das Präfix lautet "IM-".
Gib "IM-*" ein, und klicke auf Protect (Schützen).
Als geschützte Branches werden "mainline" und "IM-*" angezeigt.
Einrichten von Deployment-Umgebungen
Klicke auf Deployments und dann auf Umgebungen. Klicke auf New environment (Neue Umgebung), um neue Umgebungen hinzuzufügen. In diesem Beispiel gibt es in US-WEST-1 und US-EAST-2 Testumgebungen sowie in US-WEST-2, US-EAST-1 und CA-CENTRAL-1 Produktionsumgebungen.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum Repository "s3_infra" und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
git checkout -b IM-5Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen.
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 OpenDevOpsS3InfraErläuterungen zur Datei ".gitlab-ci.yml"
Phasen
Füge einen stages-Block (Phasen-Block) hinzu, um die Ausführungsreihenfolge deiner GitLab-Pipeline zu definieren. Phasen werden in der Reihenfolge ausgeführt, in der sie im "stages"-Block angegeben sind. Jobs, die derselben Phase zugeordnet sind, werden parallel ausgeführt.
stages:
- merge-request
- test-us-west-1
- test-us-east-2
- production-us-west-2
- production-us-east-1
- production-ca-central-1Stellenangebote
Jobs sind jeweils einer Phase zugeordnet und können einer Umgebung zugeordnet werden. Regeln steuern, ob ein bestimmter Job ausgeführt wird oder nicht. Mit der Regel in diesem Beispiel wird überprüft, ob der Pipeline-Branch nicht der Standard-Branch ist und ob die Pipeline nicht automatisch als Teil eines Merge-Requests ausgeführt wird.
Du kannst für jeden Job ein anderes Image angeben. Du kannst Images mit den Tools einrichten, die für deine Job-Skripte erforderlich sind. Im Abschnitt script (Skript) wird festgelegt, welche Schritte bei Ausführung des Jobs durchgeführt werden sollen.
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 OpenDevOpsS3InfraMerge-Request-Pipeline
Eine Pipeline wird von GitLab automatisch ausgeführt, wenn ein Merge-Request genehmigt wird. Du kannst einen Job für diese Pipeline erstellen, indem du eine Regel hinzufügst. In diesem Beispiel verläuft der Job immer erfolgreich.
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 truePushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-5" deines Repositorys "s3_infra" zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
git add --all
git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
git push -u origin IM-5Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Klicke auf die Pipeline-ID der laufenden Pipeline.
Klicke auf einen Job, um weitere Details anzuzeigen.
Erstellen eines Merge-Requests
Um einen Merge-Request zu erstellen, klicke auf Merge requests (Merge-Requests) und dann auf Create merge request (Merge-Request erstellen).
Wähle deinen Feature Branch als Quell-Branch aus, und klicke dann auf Compare branches and continue (Branches vergleichen und fortfahren).
Wähle eine zugewiesene Person und einen Prüfer aus.
Klicke auf Create merge request (Merge-Request erstellen).
Überprüfe die Code-Änderungen, und klicke dann auf Genehmigen.
Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Merge-Request-Pipeline anzuzeigen
Klicke auf die Pipeline-ID. Du wirst bemerken, dass "merge-request-pipeline-job" der einzige Job ist, der ausgeführt wurde.
Wechsle zurück zum Merge-Request, indem du auf Merge requests (Merge-Requests) klickst, dann auf den aktiven Merge-Request und dann auf Merge (Merge durchführen). Damit wird eine weitere Pipeline gestartet.
Klicke auf CI/CD und dann auf Pipelines. Klicke auf die Pipeline-ID.
Erstellen eines Repositorys für SystemTests
Erstelle in Jira einen Jira-Vorgang für das Hinzufügen eines SystemTests-Repositorys zu GitLab. Notiere die Jira-Vorgangs-ID. In diesem Beispiel lautet sie "IM-7".
Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum SystemTests-Repository und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDas SystemTests-Repository erfordert keine Datei "gitlab-ci.yml". Es hat keine eigene Pipeline, da es Tests für andere Pipelines bereitstellt. Notiere die SystemTests-Remote-URL. Die CI/CD-Pipelines von SubmitImage, GetImageLabel und InvokeLabeller klonen das SystemTests-Repository während der Testschritte. Du musst "gitlab-ci.yml" für spätere Repositorys mit der richtigen URL aktualisieren.
Hinzufügen eines Deploy-Tokens
Du musst ein Deploy-Token hinzufügen, um dieses Repository während der Ausführung anderer Pipelines zu klonen. Klicke auf Einstellungen und dann auf Repository. Scrolle nach unten und erweitere den Punkt Deploy tokens (Deploy-Token).
Gib einen Namen ein, aktiviere das Kontrollkästchen read_repository und klicke dann auf Create deploy token (Deploy-Token erstellen).
Der Benutzername für das Deploy-Token wird automatisch generiert. Das Deploy-Token-Passwort wird einmal bei der Erstellung angegeben. Füge es zu einem Tool zur Verwaltung geheimer Schlüssel hinzu, damit später darauf zurückgegriffen werden kann. Im weiteren Verlauf dieses Leitfadens wird der Benutzername für das Deploy-Token als gitlab_deploy_token referenziert und das Deploy-Token-Passwort als gitlab_deploy_password.
Erstellen eines Repositorys für das AWS Lambda SubmitImage
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines Repositorys für das AWS Lambda SubmitImage zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-8".
Klicke in GitLab auf Neues Projekt und dann auf Create blank project (Leeres Projekt erstellen). Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum Repository "SubmitImage" und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDu musst AWS-Zugriffsschlüssel hinzufügen, geschützte Branches konfigurieren und Deployment-Umgebungen einrichten.
Füge dann die Deployment-Schlüssel aus deinem Repository "SystemTests" hinzu, damit die SubmitImage-GitLab-Pipeline heruntergeladen werden kann, und führe SystemTests aus.
Füge abschließend deine AWS-Konto-ID als CI/CD-Variable hinzu.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum Repository "SubmitImage" und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
git checkout -b IM-8Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1Die Durchführung der Integrationstests wird vorerst auskommentiert. Die Systemtests werden erst bestanden, wenn die gesamte Anwendung bereitgestellt wurde. Kommentiere die Integrationstestschritte in deinem Repository ein und führe einen weiteren Push durch, um die Deployment-Pipeline auszuführen, nachdem alle Komponenten von ImageLabeller bereitgestellt wurden. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
Erläuterungen zur Datei ".gitlab-ci.yml"
In diesem Schritt werden Unit-Tests ausgeführt, die Teil des Repositorys "SubmitImage" sind.
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/...In diesem Schritt wird das AWS Lambda SubmitImage mithilfe von AWS SAM bereitgestellt. Beachte den Abschnitt before_script. Dieser Schritt wird vor dem script-Abschnitt ausgeführt und kann verwendet werden, um Abhängigkeiten zu implementieren und verschiedene Tools einzurichten.
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-changesetIn diesem Schritt werden die Integrationstests im SystemTests-Repository heruntergeladen und ausgeführt. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1In der "git clone"-Zeile wird auf das zuvor erstellte Deploy-Token verwiesen.
- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.gitPushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-8" des Repositorys "SubmitImage" zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
git add --all
git commit -m "IM-8 add .gitlab-ci.yml to SubmitImage"
git push -u origin IM-8Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Erstellen eines Merge-Requests
Erstelle einen Merge-Request zum Bereitstellen in deinen Produktionsumgebungen nach dem GitLab-Deployment in deinen Testumgebungen. Wähle den Branch "IM-8" aus.
Klicke auf CI/CD und dann auf Pipelines, um die laufende Merge-Request-Pipeline anzuzeigen.
Merge die Änderungen nach Abschluss der Merge-Request-Pipeline in "mainline". Klicke auf CI/CD und dann auf Pipelines, um die laufende Produktionspipeline anzuzeigen.
Erstellen eines Repositorys für das AWS Lambda InvokeLabeller
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines Repositorys für das AWS Lambda InvokeLabeller zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-10".
Klicke in GitLab auf Neues Projekt und dann auf Create blank project (Leeres Projekt erstellen). Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum InvokeLabeller-Repository und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDu musst AWS-Zugriffsschlüssel hinzufügen, geschützte Branches konfigurieren und Deployment-Umgebungen einrichten.
Füge dann die Deployment-Schlüssel aus deinem Repository "SystemTests" hinzu, damit die InvokeLabeller-GitLab-Pipeline heruntergeladen werden kann, und führe SystemTests aus.
Füge abschließend deine AWS-Konto-ID als CI/CD-Variable hinzu.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum InvokeLabeller-Repository und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
git checkout -b IM-10Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1Die Durchführung der Integrationstests wird vorerst auskommentiert. Die Systemtests werden erst bestanden, wenn die gesamte Anwendung bereitgestellt wurde. Kommentiere die Integrationstestschritte in deinem Repository ein und führe einen weiteren Push durch, um die Deployment-Pipeline auszuführen, nachdem alle Komponenten von ImageLabeller bereitgestellt wurden. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
Aktualisieren von "src/app.py" mit dem AWS SageMaker-Endpunkt
Öffne die InvokeLabeller-Datei "src/app.py" und suche nach "query_endpoint". Ändere die Einträge unter "endpoint_name" (Endpunktname) und "client region_name" (Client-Regionsname) so, dass sie zu deinem AWS SageMaker-Notebook passen.
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_predictionsPushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-10" des InvokeLabeller-Repositorys zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
git add --all
git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
git push -u origin IM-10Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Erstellen eines Merge-Requests
Erstelle einen Merge-Request zum Bereitstellen in deinen Produktionsumgebungen nach dem GitLab-Deployment in deinen Testumgebungen. Wähle den Branch "IM-10" aus.
Merge die Änderungen nach Abschluss der Merge-Request-Pipeline in "mainline". Klicke auf CI/CD und dann auf Pipelines, um die laufende Produktionspipeline anzuzeigen.
Wenn du es bis hierher geschafft hast, herzlichen Glückwunsch! Du hast gerade ImageLabeller bereitgestellt. Der nächste Schritt ist das Einrichten der ImageLabeller-Überwachung mit Opsgenie.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
DevOps-Lernpfad
