Articoli
Tutorial
Guide interattive
Distribuzione di ImageLabeller con GitLab
.png?cdnVersion=2391)
Warren Marusiak
Senior Technical Evangelist
Per fornire una dimostrazione di come sviluppare, distribuire e gestire applicazioni utilizzando Jira Software e vari strumenti connessi, il nostro team ha creato ImageLabeller, una semplice applicazione demo basata su AWS che utilizza l'apprendimento automatico per applicare etichette alle immagini.
In questa pagina viene spiegato come distribuire ImageLabeller con GitLab. Prima di iniziare, ti consigliamo di leggere le pagine sull'architettura di ImageLabeller e sulla configurazione di AWS SageMaker per contestualizzare i contenuti.
Prerequisiti
Se non disponi già di un gruppo GitLab, segui i passaggi di questa guida GitLab per crearne una da zero.
Repository GitHub pubblici con codice ImageLabeller
Video demo dell'integrazione con Jira GitLab
Integrazione di Jira e GitLab
In Jira clicca su Board, quindi su App e infine su GitLab.
Clicca su Get it now (Installa ora).
Clicca su App, quindi su Gestisci le app.
Espandi GitLab for Jira.
Clicca su Add namespace (Aggiungi spazio dei nomi).
Seleziona lo spazio dei nomi esistente e clicca su Link. Questa guida presuppone che tu disponga già un account GitLab e di un gruppo GitLab esistenti.
Aggiunta della chiave SSH a GitLab
Clicca sull'icona del tuo profilo nell'angolo in alto a destra, quindi clicca su Preferences (Preferenze).
Clicca su SSH Keys (Chiavi SSH) e segui le istruzioni per generare una nuova chiave SSH o utilizzare una chiave SSH esistente.
Creazione di un repository per l'infrastruttura AWS S3
In un ciclo di sviluppo standard, uno sviluppatore generalmente sposta un task da Jira nel lavoro in corso e poi si occupa dell'attività di sviluppo. L'ID del ticket Jira è la chiave che collega l'attività di sviluppo al ticket Jira. È il componente di integrazione principale tra i due sistemi.
Vai su Jira e crea un nuovo ticket per aggiungere un repository di infrastruttura AWS S3 a GitLab. Prendi nota dell'ID del ticket, che in questo esempio è IM-5.
Vai su GitLab e clicca su New project (Nuovo progetto).
Clicca su Create blank project (Crea progetto vuoto).
Aggiungi un nome per il progetto in Project name (Nome progetto) e scegli il gruppo appropriato in Project URL (URL progetto). Clicca su Create project (Crea progetto) per procedere.
Nel terminale utilizzato, vai al repository s3_infra ed esegui i comandi riportati di seguito per effettuare il push del file AWS CloudFormation template.yml a 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 mainlineAggiunta della chiave di accesso AWS
Clicca su Settings (Impostazioni), quindi su CI/CD. Scorri verso il basso ed espandi la voce Variables (Variabili). Clicca su Add variable (Aggiungi variabile).
Crea due variabili, uno per l'ID della chiave di accesso AWS e uno per la chiave di accesso segreta AWS.
Proteggi le variabili in modo che vengano utilizzate solo dalle pipeline in esecuzione su branch e tag protetti. Fornisci la chiave di accesso AWS AdministratorAccess all'utente IAM associato. Puoi anche decidere di utilizzare un controllo degli accessi più granulare scegliendo le policy di accesso AWS individuali.
Configurazione dei branch protetti per l'accesso alle variabili protette
Clicca su Settings (Impostazioni), quindi su Repository. Scorri verso il basso ed espandi Protected branches (Branch protetti).
Inserisci il prefisso dell'ID del ticket Jira e un asterisco (*).
In questo esempio, gli ID dei ticket Jira sono IM-5 e IM-6; il prefisso è, dunque, IM-.
Inserisci IM-* e clicca su Protect (Proteggi).
La mainline e IM-* vengono visualizzati come branch protetti.
Configurazione di ambienti di distribuzione
Clicca su Deployments (Distribuzioni), quindi su Environments (Ambienti). Clicca su New environment (Nuovo ambiente) per aggiungere nuovi ambienti. In questo esempio sono presenti ambienti di test in US-WEST-1 e US-EAST-2, e ambienti di produzione in US-WEST-2, US-EAST-1 e CA-CENTRAL-1.
.gitlab-ci.yml per la distribuzione in AWS
Vai al repository s3_infra nel terminale utilizzato e crea un branch che abbia lo stesso nome dell'ID del ticket Jira.
git checkout -b IM-5Crea un file .gitlab-ci.yml con il seguente yaml. Viene definito un flusso di lavoro di distribuzione per gli ambienti di test, staging e produzione.
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 OpenDevOpsS3InfraComprendere un file .gitlab-ci.yml
Fasi
Aggiungi un blocco stages (fasi) per definire l'ordine di esecuzione della pipeline GitLab. Le fasi vengono eseguite nell'ordine in cui sono presentate all'interno del blocco. I processi associati a una fase vengono eseguiti in parallelo.
stages:
- merge-request
- test-us-west-1
- test-us-east-2
- production-us-west-2
- production-us-east-1
- production-ca-central-1Processi
I processi sono associati a una fase e possono essere associati a un ambiente. Le regole controllano se un determinato processo verrà eseguito o meno. La regola di questo esempio verifica se il branch della pipeline non è il branch predefinito e se la pipeline non viene eseguita automaticamente come parte di una richiesta di merge.
Puoi specificare un'immagine diversa per ogni processo e configurare le immagini con gli strumenti necessari per gli script dei processi. La sezione script definisce la serie di passaggi che vengono eseguiti durante l'esecuzione del processo.
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 delle richieste di merge
Una pipeline viene eseguita automaticamente da GitLab quando viene approvata una richiesta di merge. Puoi creare un processo per questa pipeline aggiungendo una regola. In questo esempio il processo ha sempre esito positivo.
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 truePush di un branch di funzioni
Esegui lo script seguente dalla riga di comando per effettuare il push delle modifiche al branch IM-5 del repository s3_infra. Includi l'ID del ticket Jira nei messaggi di commit e i nomi dei branch per abilitare l'integrazione di Jira GitLab e tenere traccia di ciò che sta accadendo nel progetto.
git add --all
git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
git push -u origin IM-5Clicca su CI/CD, quindi su Pipelines per vedere la pipeline in esecuzione.
Clicca sull'ID della pipeline in esecuzione.
Clicca su un processo per vedere maggiori dettagli.
Creazione di una richiesta di merge
Per creare una richiesta di merge, clicca su Merge requests (Richieste di merge), quindi su Create merge request (Crea richiesta di merge).
Scegli il tuo branch di riferimento come branch di origine, quindi clicca su Compare branches and continue (Confronta branch e continua).
Scegli un assegnatario in Assignee e un revisore in Reviewer.
Clicca su Create pull request (Crea pull request).
Rivedi le modifiche al codice, quindi clicca su Approve (Approva).
Clicca su CI/CD, quindi su Pipelines per vedere la pipeline delle richieste di merge in esecuzione.
Clicca sull'ID della pipeline. Come puoi notare, merge-request-pipeline-job è l'unico processo che è stato eseguito.
Torna alla richiesta di merge cliccando su Merge requests (Richieste di merge), quindi sulla richiesta di merge attiva e clicca su Merge. Viene così avviata un'altra pipeline.
Clicca su CI/CD, quindi su Pipelines. Clicca sull'ID della pipeline.
Creazione di un repository per SystemTests
Vai su Jira e crea un ticket Jira per aggiungere un repository SystemTests a GitLab. Prendi nota dell'ID del ticket Jira, che in questo esempio è IM-7.
Aggiungi un nome per il progetto in Project name (Nome progetto) e scegli il gruppo appropriato in Project URL (URL progetto). Clicca su Create project (Crea progetto) per procedere.
Nel terminale utilizzato, vai al repository SystemTests ed esegui lo script seguente per effettuare il push del codice a 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 mainlineIl repository SystemTests non richiede un file .gitlab-ci.yml. Non dispone di una pipeline propria poiché fornisce i test per l'esecuzione di altre pipeline. Prendi nota dell'URL remoto del repository SystemTests. Le pipeline CI/CD di SubmitImage, GetImageLabel e InvokeLabeller cloneranno il repository SystemTests durante i passaggi di test. Dovrai aggiornare il file gitlab-ci.yml dei repository successivi con l'URL corretto.
Aggiunta di un token di distribuzione
Devi aggiungere un token di distribuzione per clonare questo repository durante l'esecuzione di altre pipeline. Clicca su Settings (Impostazioni), quindi su Repository. Scorri verso il basso ed espandi la voce Deploy tokens (Distribuisci token).
Inserisci un nome, seleziona read_repository e clicca su Create deploy token (Crea token di distribuzione).
Il nome utente del token di distribuzione è generato automaticamente. La password del token di distribuzione viene fornita una volta al momento della creazione. Aggiungila a uno strumento di gestione dei segreti in modo da potervi fare riferimento in seguito. Più avanti in questa guida il nome utente del token di distribuzione è indicato come gitlab_deploy_token e la password del token di distribuzione è indicata come gitlab_deploy_password.
Creazione di un repository per l'AWS Lambda SubmitImage
Vai su Jira e crea un nuovo ticket per aggiungere un repository AWS Lambda SubmitImage a GitLab. Prendi nota dell'ID del ticket, che in questo esempio è IM-8.
Vai su GitLab e clicca su New project (Nuovo progetto), quindi su Create blank project (Crea progetto vuoto). Aggiungi un nome per il progetto in Project name (Nome progetto) e scegli il gruppo appropriato in Project URL (URL progetto). Clicca su Create project (Crea progetto) per procedere.
Nel terminale utilizzato, vai al repository SubmitImage ed esegui i comandi seguenti per effettuare il push del codice a 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 mainlineDevi aggiungere le chiavi di accesso AWS, configurare i branch protetti e configurare gli ambienti di distribuzione.
Quindi, aggiungi le chiavi di distribuzione dal tuo repository SystemTests per abilitare il download della pipeline GitLab SubmitImage ed esegui SystemTests.
Infine, aggiungi l'ID dell'account AWS come variabile CI/CD.
.gitlab-ci.yml per la distribuzione in AWS
Vai al repository SubmitImage nel terminale utilizzato e crea un branch che abbia lo stesso nome dell'ID del ticket Jira.
git checkout -b IM-8Crea un file .gitlab-ci.yml con il seguente yaml. Viene definito un flusso di lavoro di distribuzione per gli ambienti di test, staging e produzione. Devi aggiornare la riga git clone affinché SystemTests sia il tuo repository 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-1L'esecuzione dei test di integrazione è commentata per ora. I test di sistema passeranno solo quando viene distribuita l'intera applicazione. Decommenta i passaggi dei test di integrazione nel repository ed effettua un altro push per eseguire la pipeline di distribuzione dopo che tutti i componenti di ImageLabeller sono stati distribuiti. Devi aggiornare la riga git clone affinché SystemTests sia il tuo repository SystemTests.
Comprendere un file .gitlab-ci.yml
In questo passaggio vengono eseguiti test unitari che fanno parte del repository 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/...In questo passaggio l'AWS Lambda SubmitImage viene distribuito utilizzando AWS SAM. Osserva la sezione before_script. Questo passaggio viene eseguito prima della sezione script e può essere utilizzato per installare dipendenze e configurare vari strumenti.
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-changesetQuesto passaggio consente di scaricare ed eseguire i test di integrazione nel repository SystemTests. Devi aggiornare la riga git clone affinché SystemTests sia il tuo repository 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-1Il token di distribuzione creato in precedenza è indicato nella riga git clone.
- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.gitPush di un branch di funzioni
Esegui lo script seguente dalla riga di comando per effettuare il push delle modifiche al branch IM-8 del repository SubmitImage. Includi l'ID del ticket Jira nei messaggi di commit e i nomi dei branch per abilitare l'integrazione di Jira GitLab e tenere traccia di ciò che sta accadendo nel progetto.
git add --all
git commit -m "IM-8 add .gitlab-ci.yml to SubmitImage"
git push -u origin IM-8Clicca su CI/CD, quindi su Pipelines per vedere la pipeline in esecuzione.
Creazione di una richiesta di merge
Crea una richiesta di merge da distribuire negli ambienti di produzione dopo la distribuzione di GitLab negli ambienti di test. Scegli il branch IM-8.
Clicca su CI/CD, quindi su Pipelines per vedere la pipeline di richiesta di merge in esecuzione.
Effettua il merge delle modifiche alla mainline dopo il completamento della pipeline delle richieste di merge. Clicca su CI/CD, quindi su Pipelines per vedere la pipeline di produzione in corso.
Creazione di un repository per l'AWS Lambda InvokeLabeller
Vai su Jira e crea un nuovo ticket per aggiungere un repository InvokeLabeller AWS Lambda a GitLab. Prendi nota dell'ID del ticket, che in questo esempio è IM-10.
Vai su GitLab e clicca su New project (Nuovo progetto), quindi su Create blank project (Crea progetto vuoto). Aggiungi un nome per il progetto in Project name (Nome progetto) e scegli il gruppo appropriato in Project URL (URL progetto). Clicca su Create project (Crea progetto) per procedere.
Nel terminale utilizzato, vai al repository InvokeLabeller ed esegui i comandi seguenti per effettuare il push del codice a 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 mainlineDevi aggiungere le chiavi di accesso AWS, configurare i branch protetti e configurare gli ambienti di distribuzione.
Quindi, aggiungi le chiavi di distribuzione dal tuo repository SystemTests per abilitare il download della pipeline GitLab InvokeLabeller ed esegui SystemTests.
Infine, aggiungi l'ID dell'account AWS come variabile CI/CD.
.gitlab-ci.yml per la distribuzione in AWS
Vai al repository InvokeLabeller nel terminale utilizzato e crea un branch che abbia lo stesso nome dell'ID del ticket Jira.
git checkout -b IM-10Crea un file .gitlab-ci.yml con il seguente yaml. Viene definito un flusso di lavoro di distribuzione per gli ambienti di test, staging e produzione. Devi aggiornare la riga git clone affinché SystemTests sia il tuo repository 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-1L'esecuzione dei test di integrazione è commentata per ora. I test di sistema passeranno solo quando viene distribuita l'intera applicazione. Decommenta i passaggi dei test di integrazione nel repository ed effettua un altro push per eseguire la pipeline di distribuzione dopo che tutti i componenti di ImageLabeller sono stati distribuiti. Devi aggiornare la riga git clone affinché SystemTests sia il tuo repository SystemTests.
Aggiornamento di src/app.py con l'endpoint AWS SageMaker
Apri il file src/app.py di InvokeLabeller e cerca query_endpoint. Modifica la voce endpoint_name e la voce region_name del client in modo che corrispondano al notebook AWS SageMaker utilizzato.
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_predictionsPush di un branch di funzioni
Esegui lo script seguente dalla riga di comando per effettuare il push delle modifiche al branch IM-10 del repository InvokeLabeller. Includi l'ID del ticket Jira nei messaggi di commit e i nomi dei branch per abilitare l'integrazione di Jira GitLab e tenere traccia di ciò che sta accadendo nel progetto.
git add --all
git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
git push -u origin IM-10Clicca su CI/CD, quindi su Pipelines per vedere la pipeline in esecuzione.
Creazione di una richiesta di merge
Crea una richiesta di merge da distribuire negli ambienti di produzione dopo la distribuzione di GitLab negli ambienti di test. Scegli il branch IM-10.
Effettua il merge delle modifiche alla mainline dopo il completamento della pipeline delle richieste di merge. Clicca su CI/CD, quindi su Pipelines per vedere la pipeline di produzione in corso.
Congratulazioni! Hai appena distribuito ImageLabeller. Il passaggio successivo prevede la configurazione del monitoraggio di ImageLabeller con Opsgenie.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Community DevOps
Percorso di apprendimento DevOps
