Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Lavorare con una modernizzazione continua

Gestione delle fonti

Usa atx ct source i comandi per connettere i repository. Provider supportati: GitHub GitLab, Bitbucket, local.

GitHub organizzazioni

Token: token di accesso personale (classico) con repo ambito. Read-only per l'analisi, repository completo per la correzione.

atx ct source add --name name --provider github --org org --token pat

GitLab gruppi e utenti

Token: token di accesso personale con api ambito.

atx ct source add --name name --provider gitlab --org group-or-user --token pat
# Self-hosted:
atx ct source add --name name --provider gitlab --org group-or-user --token pat --url https://gitlab.example.com

Spazi di lavoro e progetti Bitbucket

Bitbucket Cloud — ambiti:,,,. read:repository:bitbucket write:repository:bitbucket read:pullrequest:bitbucket write:pullrequest:bitbucket Inoltre ha bisogno di e. --email --username

atx ct source add --name name --provider bitbucket --org workspace --token api-token --email email --username username

Centro dati Bitbucket:

atx ct source add --name name --provider bitbucket --org project-key --token http-access-token --url https://bitbucket.example.com

Archivi locali

atx ct source add --name name --provider local --path parent-directory

Convenzioni relative ai repository

I repository possono applicare regole che rifiutano un push al termine di una correzione: un formato di messaggio di commit richiesto (regole GitLab push, hook di commit di Bitbucket, set di regole), un GitHub namespace di branch con restrizioni o un autore di commit noto. Registra queste convenzioni sul codice sorgente in modo che i commit di correzione e i rami dei risultati siano scritti nella forma richiesta dai repository. Ogni opzione è disponibile su entrambi i sistemi. atx ct source add atx ct source update

# Commit message format ({PLACEHOLDER} is replaced with a description of each change)
atx ct source update --name name --commit-message-template "fix: {PLACEHOLDER}"

# Branch namespace ({PLACEHOLDER} is replaced with the branch name AWS Transform generates)
atx ct source update --name name --branch-name-template "customized/{PLACEHOLDER}"

# Git committer identity (both options are required together)
atx ct source update --name name --git-committer-name "ATX Automation" --git-committer-email atx-automation@example.com

Passa una stringa vuota per rimuovere un modello o per cancellare la coppia di committer. Le opzioni si applicano alle misure correttive relative alla sicurezza e alla trasformazione e alle fonti locali i cui repository vengono inseriti manualmente.

Gestione delle fonti

atx ct source list
atx ct source update --name name --token new-token
atx ct source remove --name name

atx ct source updateaccetta qualsiasi combinazione delle opzioni --token di convenzione del repository di cui sopra; non passare alcuna opzione è un errore. È possibile aggiornare una fonte da qualsiasi macchina, non solo dall'host in esecuzione. atx ct source add

Individuazione e gestione dei repository

atx ct discovery scan --source name
atx ct discovery status --source name
atx ct discovery scan --source name --path new-directory

Dopo la scoperta:

atx ct repository list
atx ct repository list --source name
atx ct repository list --labels "team:frontend,priority:high"
atx ct repository update --source name --repo "source::repo" --labels "team:frontend,priority:high"
atx ct repository update --source name --labels "migration:wave-1"

Analisi in corso

Il --type flag specifica il tipo di analisi da eseguire:

atx ct analysis run --type type --source name [--repo source::repo] [--wait]
atx ct analysis get --id id --json
atx ct analysis list --json
atx ct analysis list --status pending|running|complete|cancelled|failed --json
atx ct analysis list --type type --json
atx ct analysis cancel --id id
atx ct analysis delete --id id [--cascade-findings]

Se si omette--repo, il comando analizza ogni repository contenuto in. --source Per indirizzare l'esecuzione a repository specifici, inserite --repo (separati da virgole), ciascuno con un nome completosource:: o un semplice nome utilizzato con. repo --source

Per etichettare una corsa in modo che sia facile trovarla in un secondo momento, passa o. --display-name "name" atx ct analysis run atx ct remote analysis Il nome è mostrato in atx ct analysis list eatx ct analysis get.

Analisi personalizzata

Un'analisi personalizzata esegue una delle vostre definizioni di trasformazione sui vostri repository per individuare i problemi che vi interessano. Per eseguirne una:

atx ct analysis run --type custom --transformation-name name --source source --repo source::repo --wait

Configurazione con -g flag: key-value, JSON o percorso del file.

Se il comando fallisce perché la definizione della trasformazione non è stata trovata, controlla il nome con. atx custom def list Le definizioni di trasformazione sono specifiche per un AWS account e una regione. Se fallisce a causa della categoria della definizione di trasformazione, pubblicala di nuovo con--category analysis.

Gestione degli esiti

atx ct findings list --json
atx ct findings list --repo source::repo --source name --severity high|medium|low --type analysis-type --status open|dismissed|obsolete|change_ready --analysis-id id --fix-transform transform-name --json

Individuazione degli stati

atx ct findings update --id id --status dismissed --reason "reason"
atx ct findings update --id id --status open
atx ct findings batch-update --ids id1,id2 --status dismissed --reason "reason"
atx ct findings get --id id
atx ct findings delete --id id

Trovare l'obsolescenza

Re-analysis contrassegna i risultati risolti come obsoleti. Non può essere riaperto. Conservato per l'audit.

Creazione di soluzioni correttive

Tre modalità: basata sui risultati, TD override, TD diretto. Con--transformation-name, utilizza una delle tue definizioni di trasformazione con la remediation categoria o una trasformazione AWS gestita (vedi). Categorie di definizione delle trasformazioni

atx ct remediation create --ids id1,id2 --name "name"
atx ct remediation create --ids id1,id2 --transformation-name TD
atx ct remediation create --transformation-name TD --repo source::repo

Risultati per fornitore: GitHub PR, GitLab MR, Bitbucket PR, filiale locale.

Esecuzione locale con --local flag.

atx ct remediation create --transformation-name TD --repo source::repo -g "additionalPlanContext=Upgrade to Node.js 22"
atx ct remediation list
atx ct remediation status --id id
atx ct remediation retry --id id
atx ct remediation cancel --id id
atx ct remediation delete --id id

Esecuzione remota

Per impostazione predefinita, le analisi e le riparazioni vengono eseguite sul computer locale. Per portafogli più ampi, puoi delegare il lavoro all'infrastruttura remota. È possibile eseguire l'esecuzione su AWS Transform-managed un'infrastruttura senza alcun tipo di provisioning (solo analisi) oppure su un'infrastruttura fornita e gestita tramite Account AWS un'istanza Amazon EC2 persistente o AWS processi Batch (Fargate). I atx ct remote comandi forniscono, eseguono, monitorano e smantellano l'infrastruttura gestita dal cliente. Indipendentemente da dove avviene l'esecuzione, sei tu a creare tutte le risorse in tuo possesso Account AWS e il codice sorgente rimane sotto il tuo controllo.

Con i comandi di atx ct remote analisi e correzione, puoi scegliere quali repository elaborare utilizzando --sources e --repos (entrambi separati da virgole). --sourcesseleziona ogni repository nelle fonti denominate. --reposseleziona repository specifici, ciascuno scritto come::. source repo Se fornite entrambi, il comando elabora l'unione dei due set: ogni repository nelle sorgenti denominate, più i repository denominati. Per definire l'ambito di una corsa a repository specifici, passa solo. --repos

In esecuzione su AWS Transform-managed infrastruttura (nessun approvvigionamento)

Per eseguire un'analisi in remoto senza effettuare il provisioning di nulla, usa. --mode aws-managed L'invio va a AWS Transform, che esegue l'analisi sull'infrastruttura. AWS Transform-managed Non c'è nessuno stack da fornire, nessuna rete da configurare e nessuna credenziale da archiviare in AWS Secrets Manager. L'invio è la corsa. Scegli la AWS regione in cui viene eseguito il carico di lavoro. --region

# Run an analysis on AWS Transform-managed infrastructure
atx ct remote analysis --type type --mode aws-managed --sources name [--repos repo1,repo2] [--region region]

# Poll the submission (there is no remote status command in this mode)
atx ct analysis get --id id --json

Questa modalità esegue solo analisi. Non supporta la correzione, il tipo di custom analisi o le fonti locali. Poiché non esiste uno stack, le --batch-name opzioni--stack-name, --tags--existing-instance, e non sono applicabili. Un singolo invio copre fino a 100 repository. Per coprire ambiti più ampi, suddividili su più invii con. --repos A differenza delle esecuzioni di Amazon EC2 e Batch, è possibile monitorare i progressi con atx ct analysis get anziché. atx ct remote status

Rete

L'elaborazione remota deve essere eseguita in sottoreti private. Scopri le reti esistenti o crea un nuovo VPC prima di effettuare il provisioning:

# List VPCs, private subnets, and security groups in the current account and Region
atx ct remote network discover
atx ct remote network discover --vpc vpc-id --json

# Create a new VPC with private subnets, a NAT gateway, and a security group
atx ct remote network create --cidr 10.1.0.0/16 --ack

--cidrè facoltativo e l'impostazione predefinita è. 10.1.0.0/16

Che si utilizzi la propria rete o la si utilizzinetwork create, questa deve soddisfare i seguenti requisiti:

Dimensionamento delle sottoreti e concorrenza

Prima di effettuare il provisioning dell'infrastruttura AWS Batch per un ampio parco di repository, dimensionate le sottoreti private in base al numero di job eseguiti in parallelo. Una sottorete troppo piccola è la causa più comune di errori nei processi di grandi dimensioni.

Ogni processo AWS Batch viene eseguito come un'unica attività Fargate, che richiede un'interfaccia di rete elastica e quindi un indirizzo IPv4 privato. L'assegnazione di indirizzi IP pubblici è disabilitata, quindi è necessario un indirizzo privato: un processo non può iniziare senza uno. AWS Batch non mette in coda un lavoro che non può inserire, ma non riesce a completare il lavoro.

Verifica degli indirizzi gratuiti prima di effettuare il provisioning

Il provisioning non verifica la capacità della sottorete per conto dell'utente. Controllatelo voi stessi con --json i report availableIpCount per ogni sottorete. L'output predefinito della tabella non include questo valore. Confronta il conteggio minimo con il limite di concorrenza per il tipo di analisi che intendi eseguire.

atx ct remote network discover --vpc vpc-id --json

Limiti di concorrenza per ogni tipo di analisi

AWS Transform limita il numero di lavori remoti eseguiti contemporaneamente in una regione Account AWS and. Il limite dipende dal tipo di analisi. Questi limiti sono condivisi tra tutti gli utenti dell'account e tra entrambe le modalità di elaborazione e limitano il numero di indirizzi che una corsa può consumare. Per richiedere una modifica, contatta il AWS Supporto.

Dimensione minima della sottorete

Amazon VPC riserva cinque indirizzi in ogni sottorete, quindi il numero utilizzabile è cinque in meno rispetto alla dimensione della sottorete: a /28 ha 11 indirizzi utilizzabili e a ne ha 251. /24 Per i dettagli, consulta i blocchi Subnet CIDR nella Amazon VPC User Guide.

Gli indirizzi di cui ogni sottorete ha bisogno sono i lavori simultanei di picco, più uno o più per ogni endpoint di interfaccia in quella sottorete, più eventuali altre interfacce di rete che condividono la sottorete. Il picco dei job simultanei è il numero minore tra il numero di repository nell'invio e il limite di concorrenza per il tipo di analisi. Poiché il limite è limitato al totale, un parco di 1.000 repository non necessita di più indirizzi di uno di 128 repository.

I requisiti minimi sopra indicati includono un margine di manovra per gli endpoint di interfaccia e per le riserve di indirizzi. AWS Aumenta le dimensioni se altri carichi di lavoro condividono la sottorete. A non /25 è sufficiente per 128 lavori simultanei: fornisce 128 indirizzi ma solo 123 indirizzi utilizzabili.

Si consiglia di dedicare le sottoreti all'esecuzione remota. AWS Transform ammette i lavori fino all'ultimo indirizzo disponibile e non può tenere conto di altri carichi di lavoro che richiedono indirizzi nella stessa sottorete.

Gestione di flotte di grandi dimensioni

Sull'infrastruttura Amazon EC2 e Batch di cui effettui il provisioning, un singolo invio copre fino a 1.000 repository (le AWS Transform-managed esecuzioni sono limitate a 100). Gli invii superiori al limite vengono rifiutati prima dell'inizio di qualsiasi lavoro. Per coprire flotte più grandi, suddividile con --repos ed elenca i repository in un sorgente con. atx ct repository list --source name --json

La suddivisione di una flotta non riduce gli indirizzi necessari. Gli invii eseguiti contemporaneamente provengono dalle stesse sottoreti, fino al limite di concorrenza previsto per il tipo di analisi.

Non esiste alcuna opzione che limiti il numero di repository scansionati contemporaneamente. La CLI invia tutti i lavori in un invio e AWS Transform rilascia i lavori fino al limite di concorrenza per il tipo di analisi e conserva il resto. Per gestire una flotta di grandi dimensioni, dimensiona le sottoreti in base a quel limite o inviale in gruppi più piccoli.

La CLI limita il numero di connessioni simultanee che apre al servizio di analisi. In un invio molto ampio, potresti vedere socket usage at capacity su stderr: quel messaggio è informativo, non un errore. Se il limite di file aperti della shell è pari o inferiore al limite, la CLI avvisa una volta all'avvio; aumenta il limite (ulimit -n 4096ad esempio) o abbassa il limite con ATX_MAX_SOCKETS la variabile di ambiente.

Scegliere Amazon EC2 per reti con vincoli

Amazon EC2 utilizza un indirizzo IP privato in totale, nella prima sottorete che passi, indipendentemente dal numero di worker eseguiti dall'istanza. Se gli indirizzi gratuiti scarseggiano, Amazon EC2 evita completamente il problema.

Il compromesso è la concorrenza: --workers accetta da 1 a 5, quindi un'istanza Amazon EC2 esegue al massimo 5 repository in parallelo. Per le flotte che hanno bisogno di più, usa AWS Batch. Per security l'analisi, anche il limite dell'account è 5, quindi AWS Batch non offre concorrenza aggiuntiva per quel tipo.

Dimensioni --workers --instance-type e --volume-size tempi di fornitura. La memoria dell'istanza deve essere di almeno 2 GB per ogni worker più 4 GB per il sistema operativo. atx ct remote updatemantiene questi valori; la loro modifica richiede lo smontaggio e il rifornimento, che sostituiscono l'istanza e ne eliminano il volume.

Provisioning dell'infrastruttura

Implementa lo stack Amazon EC2 o AWS Batch. Ometti di visualizzare --execute in anteprima il modello o il changeset; aggiungi per applicare. --execute

Il provisioning crea lo stack di calcolo per la modalità scelta, oltre agli stack dispatcher e scheduler:

Per impostazione predefinita, gli stack di Amazon EC2 sono denominati e gli stack atx-runner AWS Batch sono denominati. AtxInfrastructureStack Per eseguire più di uno stack della stessa modalità, assegna a ciascuno un nome distinto al momento del provisioning: use --stack-name (solo Amazon EC2; il nome deve iniziare atx-runner con) --suffix o aggiungere un suffisso a tutti i nomi di risorse. Per le analisi o le riparazioni remote updatedetect, passa --stack-name a target uno stack con nome personalizzato. Se lo ometti, usano il nome predefinito (atx-runnerper Amazon EC2, AtxInfrastructureStack per AWS Batch). teardownrichiede sempre. --stack-name Su Amazon EC2, --workers imposta il numero di container di lavoro paralleli (1-5, impostazione predefinita 5) e dimensiona l'istanza.

# Preview, then deploy an EC2 stack
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b --execute --ack

# Deploy a Batch stack
atx ct remote provision --mode batch --vpc vpc-id --subnets subnet-a,subnet-b --securityGroup sg-id --execute --ack

# Update to the latest template (--stack-name optional; defaults to the standard stack name)
atx ct remote update --mode ec2|batch [--stack-name stack-name] --execute --ack

# Tear down (--stack-name required)
atx ct remote teardown --mode ec2|batch --stack-name stack-name --execute --ack

Immagine del contenitore

Quando si eseguono analisi e riparazioni remote, queste vengono eseguite all'interno di un'immagine del contenitore. Per impostazione predefinita, quando si esegue il provisioning di un ambiente remoto, questo utilizza l'immagine AWS Transform pubblica,. public.ecr.aws/d9h8z6l7/aws-transform:latest AWS Batch lo imposta come immagine di definizione del processo. Amazon EC2 la utilizza come immagine del runner.

Per eseguire un'immagine diversa, ad esempio un'immagine Amazon ECR privata che include linguaggi o strumenti aggiuntivi, passa quando esegui il provisioning: --image-uri

# Batch: provision with a custom image
atx ct remote provision --mode batch --vpc vpc-id --subnets subnet-a,subnet-b --securityGroup sg-id --image-uri account-id.dkr.ecr.region.amazonaws.com/repo:tag --execute --ack

# EC2: provision with a custom image
atx ct remote provision --mode ec2 --vpc vpc-id --subnets subnet-a,subnet-b --image-uri account-id.dkr.ecr.region.amazonaws.com/repo:tag --execute --ack

Memorizzazione delle credenziali di origine

I contenitori remoti clonano i tuoi repository utilizzando i token archiviati in Secrets Manager AWS . Registra un token per ogni fonte SCM prima di eseguire l'analisi o la correzione remota:

atx ct remote credentials --source name --token token
atx ct remote credentials --source name --remove

Esecuzione remota

L'analisi remota esegue un contenitore per ogni repository; la riparazione remota esegue un contenitore per ogni risultato. Utilizza --sources e --labels per controllare il fan-out --stack-name e/o per selezionare lo stack fornito --tags da utilizzare. --repos

# Run analysis across a source on Batch
atx ct remote analysis --type type --mode batch --sources name [--repos repo1,repo2] [--labels "team:frontend"]

# Run remediation for specific findings on EC2
atx ct remote remediation --mode ec2 --ids id1,id2
atx ct remote remediation --mode ec2 --sources name --min-severity high

Monitoraggio e gestione delle esecuzioni

# Check whether infrastructure is deployed
atx ct remote detect --mode ec2|batch

# Track a submission (Batch by batch ID, EC2 by group ID)
atx ct remote status --batch batch-id --stack-name name
atx ct remote status --group ec2-group-id --wait

# Resume a partially-failed Batch run (re-submits only incomplete repos).
# On resume, --batch-name takes the existing batch ID reported by "remote status --batch".
atx ct remote analysis --type type --mode batch --sources name --resume-incomplete --batch-name batch-id

# Cancel a running submission
atx ct remote cancel --mode batch --batch batch-id --stack-name name
atx ct remote cancel --mode ec2 --group ec2-group-id

Pianificazione di analisi ricorrenti

atx ct scheduleDa utilizzare per eseguire analisi automaticamente con una cadenza ricorrente. È possibile pianificare le analisi ma non le riparazioni. Le opzioni di Job si rispecchianoatx ct remote analysis. Le pianificazioni vengono eseguite in remoto, in due modi:

Il --recurrence valore accettadaily, weekly:DAY (ad esempioweekly:MONDAY), o monthly:N dove N è un giorno compreso tra 1 e 28. Le pianificazioni sull' AWS Transform-managed infrastruttura vengono eseguite in UTC.

# AWS Transform-managed schedule (no infrastructure; requires an execution role)
atx ct schedule create --name name --mode aws-managed --execution-role role-arn --recurrence daily --type type --sources name [--repos repo1,repo2]

# Customer-managed schedule (EventBridge Scheduler dispatching to your EC2 or Batch stack)
atx ct schedule create --name name --mode ec2|batch --recurrence weekly:MONDAY --type type --sources name [--repos repo1,repo2]

# Manage schedules of either type by their schedule ID (from schedule list)
atx ct schedule list
atx ct schedule get schedule-id
atx ct schedule disable schedule-id
atx ct schedule enable schedule-id
atx ct schedule delete schedule-id

Per visualizzare le analisi eseguite da una pianificazione, utilizzateatx ct analysis list --schedule-id schedule-id, che restituisce le esecuzioni avviate della pianificazione, per prime le più recenti.

Per rimuovere il ruolo di scheduler e il gruppo di pianificazioni utilizzati dalle pianificazioni gestite dal cliente, esegui. atx ct schedule teardown --execute

Ruolo di esecuzione per AWS Transform-managed pianificazioni

Una pianificazione creata con --mode aws-managed richiede un --execution-role ARN che AWS Transform assume ogni volta che viene eseguita la pianificazione. Configura il ruolo come segue:

La seguente politica in linea concede a AWS Secrets Manager l'accesso necessario alle esecuzioni pianificate per recuperare le credenziali del clone di origine. Associala al ruolo di esecuzione insieme alla policy AWSTransformCustomFullAccessgestita, sostituendo region e account-id con la AWS regione e l'account in cui viene eseguita la pianificazione.

{
  "Version": "2012-10-17", 
  "Statement": [
    {
      "Sid": "AtxSourceCredentials",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "arn:aws:secretsmanager:region:account-id:secret:atx/*"
    }
  ]
}

Etichettatura e controllo degli accessi

Puoi applicare tag (key=valuecoppie separate da virgole) a fonti, analisi e correzioni con l'opzione. --tags I tag sono supportati anche sull'infrastruttura remota, sulle credenziali archiviate e sulle risorse di rete. Con i tag, puoi organizzare le risorse. In combinazione con le condizioni dei tag IAM, i tag implementano il controllo degli accessi basato sugli attributi (ABAC) in modo che i team accedano solo alle risorse che contengono i tag.

atx ct source add --name name --provider github --org org --token pat --tags team=platform,env=prod
atx ct analysis run --type type --source name --tags team=platform
atx ct remediation create --ids id1,id2 --tags team=platform

Per impostazione predefinita, le risorse sono etichettate con i tag definiti dall'utente. ~/.aws/atx/settings.json Aggiungi i tag che desideri applicare a ogni risorsa e diventeranno i tag predefiniti. applyTags

{
  "applyTags": [
    { "team": "alpha" }
  ]
}

AWS Trasforma l'applicazione web

Usa l'applicazione web AWS Transform per creare ed eseguire analisi, esaminare i risultati, creare correzioni e tenere traccia delle richieste pull generate tra le tue fonti di codice.

Prima di utilizzare l'applicazione Web, l'organizzazione deve abilitare l'identità utente per accedere AWS a Transform. Per ulteriori informazioni sulla configurazione di AWS Transform, vedere Configurazione di AWS Transform.

Accesso

Per accedere all'applicazione web AWS Transform, completa i seguenti passaggi.

Modalità di infrastruttura

Quando crei un'analisi, scegli una delle seguenti modalità di infrastruttura:

Per utilizzare l'infrastruttura di proprietà del cliente, apri la scheda Impostazioni. Utilizza i link di AWS CloudFormation creazione rapida per distribuire i seguenti stack nell'ordine:

Per la configurazione CLI-based del provisioning e della rete, vedereEsecuzione remota.

Flusso di lavoro introduttivo

Chatta con AWS Transform direttamente dall'applicazione web per porre domande sulle tue analisi, risultati o correzioni.