翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

継続的なモダナイゼーションの使用

ソース管理

atx ct source コマンドを使用してリポジトリを接続します。サポートされているプロバイダー: GitHub、GitLab、Bitbucket、local。

GitHub 組織

トークン: repoスコープを持つ個人用アクセストークン (クラシック）。分析には読み取り専用、修復には完全なリポジトリ。

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

GitLab グループとユーザー

トークン: apiスコープを持つ個人用アクセストークン。

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

Bitbucket ワークスペースとプロジェクト

Bitbucket Cloud — スコープ: read:repository:bitbucket、write:repository:bitbucket、read:pullrequest:bitbucket、write:pullrequest:bitbucket。また、 --emailと も必要です--username。

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

Bitbucket データセンター:

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

ローカルリポジトリ

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

ソースの管理

atx ct source list
atx ct source remove --name name

リポジトリの検出と管理

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

検出後:

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"

分析の実行

--type フラグは、実行する分析の種類を指定します。

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]

カスタム分析

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

-g フラグ付き設定: key-value、JSON、またはファイルパス。

TDs一覧表示する: atx custom def list

検出結果の管理

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 --analysis-id id --fix-transform transform-name --json

検出結果のステータス

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

廃止の検出

再分析では、解決された検出結果は古いものとしてマークされます。再度開くことはできません。監査のために保持されます。

修復の作成

3 つのモード: 検出結果ベース、TD オーバーライド、直接 TD。

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

プロバイダー別の出力: GitHub PR、GitLab MR、Bitbucket PR、Local ブランチ。

--local フラグ付きのローカル実行。

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

リモート実行

デフォルトでは、分析と修復はローカルマシンで実行されます。大規模なポートフォリオでは、リモートインフラストラクチャに作業をオフロードできます。Transform AWS が管理するインフラストラクチャで、プロビジョニングするものがない (分析のみ）、または でプロビジョニングして管理するインフラストラクチャ AWS アカウント、つまり永続的な Amazon EC2 インスタンスまたは AWS バッチ (Fargate) ジョブで を実行できます。atx ct remote コマンドは、カスタマー管理のインフラストラクチャをプロビジョニング、実行、モニタリング、および削除します。実行場所に関係なく、 内のすべてのリソースを作成し AWS アカウント 、ソースコードは制御下に置かれます。

AWS Transform マネージドインフラストラクチャでの実行 (プロビジョニングなし)

何もプロビジョニングせずに分析をリモートで実行するには、 を使用します--mode aws-managed。送信は AWS Transform に送信され、 AWS Transform マネージドインフラストラクチャで分析を実行します。プロビジョニングするスタック、設定するネットワーク、 AWS Secrets Manager に保存する認証情報はありません。送信は実行です。でワークロードを実行する AWS リージョンを選択します--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

このモードは分析のみを実行します。修復、custom分析タイプ、またはローカルソースはサポートされていません。スタックがないため、--stack-name、、--existing-instance、および --tags--batch-nameオプションは適用されません。1 回の送信で最大 100 のリポジトリをカバーします。より大きなスコープをカバーするには、 を使用して複数の送信に分割します--repos。Amazon EC2 やバッチ実行とは異なり、 atx ct analysis getではなく で進行状況をモニタリングしますatx ct remote status。

ネットワーク

リモートコンピューティングはプライベートサブネットで実行する必要があります。プロビジョニングする前に、既存のネットワークを検出するか、新しい VPC を作成します。

# 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

インフラストラクチャーのプロビジョニングをします。

Amazon EC2 または Batch スタックをデプロイします。を省略--executeしてテンプレートまたは変更セットをプレビューし、 を追加して適用--executeします。

プロビジョニングでは、選択したモードのコンピューティングスタックとスケジューラスタックが作成されます。

# 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 an existing stack to the latest template, or tear it down
atx ct remote update --mode ec2|batch --execute --ack
atx ct remote teardown --mode ec2|batch --execute --ack

コンテナイメージ

リモート分析と修復を実行すると、コンテナイメージ内で実行されます。デフォルトでは、リモート環境をプロビジョニングすると、パブリック AWS 変換イメージ が使用されますpublic.ecr.aws/d9h8z6l7/aws-transform:latest。Batch はこれをジョブ定義イメージとして設定します。Amazon EC2 はこれをランナーイメージとして使用します。

追加の言語やツールをバンドルするプライベート Amazon ECR イメージなど、別のイメージを実行するには、プロビジョニング--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

ソース認証情報の保存

リモートコンテナは、 AWS Secrets Manager に保存されているトークンを使用してリポジトリのクローンを作成します。リモート分析または修復を実行する前に、SCM ソースごとにトークンを登録します。

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

リモートでの実行

リモート分析はリポジトリごとに 1 つのコンテナを実行し、リモート修復は検出結果ごとに 1 つのコンテナを実行します。--sources、--repos、および を使用してファンアウト--labelsを制御し、--stack-nameまたは --tags を使用して、使用するプロビジョニングされたスタックを選択します。

# 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

実行のモニタリングと管理

# 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

定期的な分析のスケジューリング

を使用してatx ct schedule、定期的な頻度で分析を自動的に実行します。分析はスケジュールできますが、修復はスケジュールできません。ジョブオプションは をミラーリングしますatx ct remote analysis。スケジュールは、次の 2 つの方法のいずれかでリモートで実行されます。

--recurrence 値は daily、 weekly:DAY (例: weekly:MONDAY)、または を受け入れます。monthly:NN は 1 ～ 28 の日です。 AWS Transform マネージドインフラストラクチャのスケジュールは 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

スケジュールが実行された分析を表示するには、 を使用します。これはatx ct analysis list --schedule-id schedule-id、スケジュールの実行を最新のものから返します。

カスタマー管理のスケジュールで使用されるスケジューラロールとスケジュールグループを削除するには、 を実行しますatx ct schedule teardown --execute。

AWS 変換マネージドスケジュールの実行ロール

で作成されたスケジュールには、スケジュールが実行されるたびに AWS Transform が引き受ける --execution-role ARN --mode aws-managedが必要です。ロールを次のように設定します。

次のインラインポリシーは、スケジュールされた実行がソースクローン認証情報を取得する必要があるアクセスを AWS Secrets Manager に付与します。AWSTransformCustomFullAccess 管理ポリシーとともに実行ロールにアタッチし、region と account-id を、スケジュールが実行される AWS リージョンとアカウントに置き換えます。

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

タグ付けとアクセスコントロール

--tags オプションを使用して、タグ (カンマ区切りのkey=valueペア) をソース、分析、修復に適用できます。タグは、リモートインフラストラクチャ、保存された認証情報、ネットワークリソースでもサポートされています。タグを使用すると、リソースを整理できます。IAM タグ条件と組み合わせると、タグは属性ベースのアクセスコントロール (ABAC) を実装し、チームがタグを持つリソースにのみアクセスできるようにします。

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

デフォルトでは、リソースには で定義したタグが付けられます~/.aws/atx/settings.json。ですべてのリソースに適用するタグを追加するとapplyTags、デフォルトのタグになります。

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

AWS ウェブアプリケーションの変換

AWS 変換ウェブアプリケーションを使用して、分析の作成と実行、結果の確認、修復の作成、コードソース全体で生成されたプルリクエストの追跡を行います。

ウェブアプリケーションを使用する前に、組織はユーザー ID が AWS Transform にアクセスできるようにする必要があります。 AWS 変換の設定の詳細については、AWS 「変換の設定」を参照してください。

サインイン

AWS 変換ウェブアプリケーションにアクセスするには、次の手順を実行します。

インフラストラクチャモード

分析を作成するときは、次のいずれかのインフラストラクチャモードを選択します。

顧客所有のインフラストラクチャを使用するには、設定タブを開きます。 AWS CloudFormation クイック作成リンクを使用して、次のスタックを順番にデプロイします。

CLI ベースのプロビジョニングとネットワーク設定については、「」を参照してくださいリモート実行。

ワークフローの開始方法

とチャットする ウェブアプリケーションから直接 AWS 変換して、分析、検出結果、または修復について質問します。