この投稿はDockerとArmのコラボレーションによるもので、Docker MCP ToolkitとArm MCP Serverがどのように連携してアーキテクチャの移行を簡素化するかを示しています。
Moving workloads from x86 to Arm64 architecture has become increasingly important. Organizations seek to reduce cloud costs and improve performance. AWS Graviton, Azure Cobalt, and Google Cloud Axion have made Arm-based computing mainstream, promising 20-40% cost savings and better performance for many workloads.
しかし、ここで課題があります:どうやってアプリケーションをArmに移行し、壊さずに済むのでしょうか?
従来の移住アプローチには以下が必要です:
- x86特定の依存関係に対する手動コード解析
- 複数のツールをまたぐ面倒な互換性チェック
- 手動パフォーマンス評価
もしArm移行全体のワークフローを単一のインターフェースからオーケストレーションできたらどうでしょうか?Docker MCP Toolkit がこれを可能にします。
専門的なArm移行ツールをGitHub Copilotに直接接続することで、互換性分析、内在変換、パフォーマンス予測をVS Codeでの自然な会話を通じて自動化できます。
Here’s what that looks like in practice: You ask GitHub Copilot to migrate your legacy C++ application to Arm64. Copilot doesn’t just tell you what needs changing—it actually executes: scanning your code for x86 intrinsics, converting x86 SIMD intrinsics to Arm SIMD intrinsics, updating your Dockerfile, predicting Arm performance improvements, and creating a pull request with all changes. All through natural conversation in VS Code. No manual porting. No up-front architecture expertise required.
プロセスのどのステップでも質問があれば、直接Copilotに問い合わせることができ、Arm MCP Serverナレッジベースツールを呼び出します。ナレッジベースには、learn.arm.com のすべての学習パスから直接取得した情報や、すべてのArmの本質的な知識が含まれており、その情報をまとめてくれるだけでなく、ご自身で閲覧できる具体的なドキュメントへのリンクも提供してくれます。
Now you might ask – “Can’t I just rebuild my Docker image for Arm64?” True, for most applications. But when you hit that one legacy app with hand-optimized x86 assembly, AVX2 intrinsics, or architecture-specific compiler flags? That’s when Docker MCP Toolkit with the Arm MCP Server becomes essential.
By the end of this guide, you’ll migrate a real-world legacy application—a matrix multiplication benchmark written with AVX2 intrinsics for x86—to Arm64 automatically using GitHub Copilot and Docker MCP Toolkit.
通常 5〜7 時間かかる手作業は、 25 分から 30 分程度で済みます。
腕の移動チャレンジ
何を解決しているのか、正確にお見せしましょう。元々x86向けに書かれた行列乗算ベンチマークを考えてみてください。64 AVX2 最適化を施したもので、Arm移行を苦痛にするようなコードです。
Gravitonへの移行時に問題を引き起こすDockerファイルはこちらです:
FROM centos:6
# CentOS 6 reached EOL, need to use vault mirrors
RUN sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Base.repo && \
sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Base.repo
# Install EPEL repository (required for some development tools)
RUN yum install -y epel-release && \
sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/epel.repo && \
sed -i 's|^#baseurl=http://download.fedoraproject.org/pub/epel|baseurl=http://archives.fedoraproject.org/pub/archive/epel|g' /etc/yum.repos.d/epel.repo
# Install Developer Toolset 2 for better C++11 support (GCC 4.8)
RUN yum install -y centos-release-scl && \
sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-SCLo-scl.repo && \
sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo && \
sed -i 's|^# baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-SCLo-scl.repo && \
sed -i 's|^# baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-SCLo-scl-rh.repo
# Install build tools
RUN yum install -y \
devtoolset-2-gcc \
devtoolset-2-gcc-c++ \
devtoolset-2-binutils \
make \
&& yum clean all
WORKDIR /app
COPY *.h *.cpp ./
# AVX2 intrinsics are used in the code
RUN scl enable devtoolset-2 "g++ -O2 -mavx2 -o benchmark \
main.cpp \
matrix_operations.cpp \
-std=c++11"
CMD ["./benchmark"]
なぜこれがArmには効かないのか疑問に思うかもしれません。このDockerfileを見ると、Graviton移行の即時的な障害が2つあります:
- No Arm64 support in base image – The
centos:6image was built for x86 only, so this container won’t even start on Arm hardware. - x86固有コンパイラフラグ –
-mavx2フラグは、ARMプロセッサには存在しないAVX2 ベクター命令を使用するようコンパイラに指示します。
経験豊富な開発者でさえ、大規模なコードベースではこれらの問題を見落としがちです。
ソースコードはベクトル化演算にAVX2 内在解析を使用しています:
#include "matrix_operations.h"
#include <iostream>
#include <random>
#include <chrono>
#include <stdexcept>
#include <immintrin.h> // AVX2 intrinsics
Matrix::Matrix(size_t r, size_t c) : rows(r), cols(c) {
data.resize(rows, std::vector<double>(cols, 0.0));
}
void Matrix::randomize() {
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_real_distribution<> dis(0.0, 10.0);
for (size_t i = 0; i < rows; i++) {
for (size_t j = 0; j < cols; j++) {
data[i][j] = dis(gen);
}
}
}
Matrix Matrix::multiply(const Matrix& other) const {
if (cols != other.rows) {
throw std::runtime_error("Invalid matrix dimensions for multiplication");
}
Matrix result(rows, other.cols);
// x86-64 optimized using AVX2 for double-precision
for (size_t i = 0; i < rows; i++) {
for (size_t j = 0; j < other.cols; j++) {
__m256d sum_vec = _mm256_setzero_pd();
size_t k = 0;
// Process 4 elements at a time with AVX2
for (; k + 3 < cols; k += 4) {
__m256d a_vec = _mm256_loadu_pd(&data[i][k]);
__m256d b_vec = _mm256_set_pd(
other.data[k+3][j],
other.data[k+2][j],
other.data[k+1][j],
other.data[k][j]
);
sum_vec = _mm256_add_pd(sum_vec, _mm256_mul_pd(a_vec, b_vec));
}
// Horizontal add using AVX
__m128d sum_high = _mm256_extractf128_pd(sum_vec, 1);
__m128d sum_low = _mm256_castpd256_pd128(sum_vec);
__m128d sum_128 = _mm_add_pd(sum_low, sum_high);
double sum_arr[2];
_mm_storeu_pd(sum_arr, sum_128);
double sum = sum_arr[0] + sum_arr[1];
// Handle remaining elements
for (; k < cols; k++) {
sum += data[i][k] * other.data[k][j];
}
result.data[i][j] = sum;
}
}
return result;
}
double Matrix::sum() const {
double total = 0.0;
for (size_t i = 0; i < rows; i++) {
for (size_t j = 0; j < cols; j++) {
total += data[i][j];
}
}
return total;
}
void benchmark_matrix_ops() {
std::cout << "\n=== Matrix Multiplication Benchmark ===" << std::endl;
const size_t size = 200;
Matrix a(size, size);
Matrix b(size, size);
a.randomize();
b.randomize();
auto start = std::chrono::high_resolution_clock::now();
Matrix c = a.multiply(b);
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start);
std::cout << "Matrix size: " << size << "x" << size << std::endl;
std::cout << "Time: " << duration.count() << " ms" << std::endl;
std::cout << "Result sum: " << c.sum() << std::endl;
}
以下のコードを見ると、Intel/AMD x86 プロセッサ向けに大幅に最適化されており、Armでは動作しないことがわかるかもしれません。
- x86-excluclynヘッダー –
#include <immintrin.h>xの86 システムにのみ存在します。腕の用途<arm_neon.h>その代わりに。 - AVX2 全体に内在機能 – すべての
_mm256_*機能はIntel固有の機能です: _mm256_setzero_pd()– 256-ビットのゼロベクトルを作成します(Arm NEONは 128-ビットです)_mm256_loadu_pd()– 一度に 4 重を積み込む(NEONが 2を装填)_mm256_set_pd()– セット 4 ダブル(NEONに直接相当するものはない)_mm256_add_pd()/_mm256_mul_pd()– 256ビット演算(NEONは 128ビットを使用)_mm256_extractf128_pd()– 高 128 ビットを抽出(NEONでは不要)
- ベクトル幅の不一致 – AVX2 は1回の操作で 4 倍を処理しますが、Arm NEONは 2処理します。ループ全体の構造を調整しなければなりません。(新しいArmコア(Neoverse V1/V2、Graviton 3/4)のSVE/SVE2は、256ビットまたはより広いベクトル長非依存(VLA)レジスタを提供し、AVX2レジスタと同等またはそれを超える。)
- 水平還元ロジック –
_mm256_extractf128_pdと_mm256_castpd256_pd128を用いた水平増しパターンはx86特有であり、Arm SIMD用に完全に書き直す必要があります。
手動変換には 30+行の内在コードの書き直し、ループのストライド調整、数値精度のテストが必要です。まさにここで自動化された移行ツールが不可欠になります。
これらの問題はそれぞれ異なる形でアームの移行を妨げています。手動移行は、単に内部機器の変換だけでなく、ビルドインフラ全体の近代化、Armの同等物の発見、性能の検証も必要です。大規模なコードベースでは、これは非常に高コストになります。
GitHub CopilotがARM MCPなしでできることとできないこと
Arm MCP ServerをDocker MCP Toolkitに追加した際の変更点を明確にしましょう。
アームなしMCP
You ask GitHub Copilot to migrate your C++ application from x86 to Arm64. Copilot responds with general advice: “Convert AVX2 intrinsics to NEON”, “Update your Dockerfile to use ARM64 base image”, “Change compiler flags”. Then you must manually research NEON equivalents, rewrite hundreds of lines of intrinsic code, update the Dockerfile yourself, hope you got the conversion right, and spend hours debugging compilation errors.
はい、Copilotはコードを書くことができます。しかし、専門的なツールがなければ、具体的な知識ベースのドキュメントや専用ツールを使って実際のアプリケーションアーキテクチャを分析するのではなく、トレーニングデータに基づく推測に過ぎません。
Arm MCP + Docker MCP Toolkit を使った
GitHub Copilotにも同じことを聞いてみてください。数分のうちに、それは:
check_imageツールを使って、ベース画像がARM対応かどうかを検証64- 実際のコードベース上で
migrate_ease_scan動いて、特定のコードを探し86 knowledge_base_searchを使って、各xの本質的変数に対して正しいArm SIMDの等価物を見つける86- アーキテクチャ固有の精度でコードを変換します
- DockerファイルをArm互換のベースイメージで更新します
- すべての変更を含むプルリクエストを作成します。
本物のコードはスキャンされます。本物の本質的なものが変換されます。実際のプルリクエストはリポジトリに表示されます。VS Codeを閉じて明日戻ってきて、移行はテストの準備ができており、すべての変更を説明するドキュメントも完備されています。
違いは?Docker MCP Toolkitは、GitHub CopilotにArmアーキテクチャの一般的な知識だけでなく、実際のArm移行ツールへのアクセスを提供します。
なぜこれが手動移行と異なるのか
手動でArmの移行ツールを使うこともできます。ローカルでユーティリティをインストールし、チェックをし、内部情報を調査し、コードを更新する。そのプロセスは以下の通りです:
手作業のプロセス:
- Armマイグレーションツールをインストールする(415 分)
- 互換性スキャンを実行してください(5 分)
- 各x個を調べてみてください86 内在的相当物(1つあたり30 分)
- 手動でコードを書き直す(2〜3 時間)
- Update Dockerfile(15 分)
- コンパイルエラーの修正(1-2 時間)
- 文書の変更(30 分)
合計:1回の応募で 5〜7 時間
Docker MCP Toolkit + Arm MCPでは:
- GitHub Copilotに移行を依頼する(20 4分)
- 変更の確認と承認(10-20 分)
- マージプルリクエスト
合計:1回の申請で 30〜40 分
Docker MCP ToolkitでVisual Studio Codeを設定する
前提 条件
開始する前に、次のものがあることを確認してください。
- 最低 8 GBのRAM(推奨16GB)のマシン
- 最新のDocker Desktopリリース
- GitHub Copilot拡張機能を使ったVS Code
- 個人アクセストークン付きのGitHubアカウント
ステップ 1。Docker MCP Toolkitを有効にする
Dockerデスクトップを開き、設定からMCP Toolkitを有効にしてください。
以下を可能にする方法:
- Docker Desktop を開く
- ベータ機能→設定へ
- Toggle Docker MCP Toolkit ON
- 「応募」をクリックします
キャプション:Docker Desktop 下のDocker MCP Toolkitを有効にする
カタログから必要なMCPサーバーを追加する
以下のリンクをたどるか、Docker Desktop MCPツールキットの「カタログ」を選択してArm、Sequential Thinking、GitHub Officialを追加してください:
- Arm MCP Server – Arm 移行ツールとアーキテクチャの専門知識
- GitHub MCP Server – リポジトリ操作およびプルリクエスト管理
- シーケンシャルシンキングMCPサーバー – 複雑な問題の分解と計画
キャプション:Docker MCPカタログでArm MCPサーバーを検索
ステップ 2。サーバーの設定
- Arm MCPサーバーの設定
移行イージースキャンおよびMCAツールでローカルコードにアクセスするには、Arm MCPサーバーがローカルコードを指すディレクトリを設定する必要があります。
キャプション:Arm MCPサーバーの設定
「保存」をクリックすると、Arm MCPサーバーがコードの探し場所を把握してくれます。将来的に別のディレクトリへのアクセスを許可したい場合は、このパスを変更する必要があります。
利用可能なアーム移行ツール
ツールをクリックすると、Arm MCP Serverで利用可能な6つのMCPツールすべてが表示されます。
キャプション:Arm MCPサーバーが提供するMCPツール一覧
knowledge_base_search– Arm学習リソース、内在文書、ソフトウェア互換性の意味検索migrate_ease_scan– C++、Python、Go、JavaScript、Javaに対応したコードスキャナー(Arm互換性解析)check_image– Docker image architecture verification (checks if images support Arm64)skopeo– ダウンロード不要の遠隔コンテナ画像検査mca– アセンブリ性能分析およびIPC予測のためのマシンコードアナライザsysreport_instructions– システムアーキテクチャ情報収集
- GitHub MCPサーバーの設定
GitHub MCP Serverは、GitHub Copilotがプルリクエストの作成、課題の管理、変更のコミットを可能にします。
キャプション:GitHub公式MCPサーバーの設定手順
認証の設定:
- GitHub officialを選択してください
- 希望する認証方法を選びましょう
- Personal Access Tokenについては、GitHubの設定>開発者設定>取得する必要があります
キャプション:GitHub MCPサーバーでのパーソナルアクセストークンの設定
- Sequential Thinking MCP サーバーの設定
- 「シーケンシャルシンキング」をクリックしてください
- 設定は不要です
キャプション:シーケンシャルMCPサーバーは設定不要
このサーバーはGitHub Copilotが複雑なArm移行の決定を論理的なステップに分解するのに役立ちます。
ステップ 3。VSコードにサーバーを追加する
Docker MCP Toolkitを使えば、VS Codeのようなクライアント向けにMCPサーバーを非常に簡単に設定できます。
設定するには、「クライアント」をクリックして下にスクロールしてVisual Studio Codeへ行ってください。「接続」ボタンをクリックしてください:
キャプション:Visual Studio CodeをMCPクライアントとして設定する
次にVS Codeを開き、左のツールバーにある「拡張機能」アイコンをクリックしてください:
キャプション:VS Code拡張機能でのMCP_DOCKER設定
MCP_DOCKERのギアをクリックし、「サーバー開始」をクリックしてください:
キャプション:VS CodeでMCPサーバーを起動
これでアームの移行を行う準備ができました!
ステップ 4。接続確認
GitHub Copilot ChatをVS Codeで開いて質問してください:
What Arm migration tools do you have access to?
3つのサーバーすべてのツールがリストに記載されているはずです。彼らを見かけたら、接続は正常です。コードを移行しましょう。
キャプション:GitHub Co-Pilotで遊ぶ
実世界でのデモ:レガシーx86 アプリケーションの移行
GitHub CopilotをDocker MCP Toolkitに接続したところで、先ほど見た行列乗算ベンチマークを移行しましょう。
移行までの時間: 20 分
インフラ:$0 (すべてDockerコンテナで動作)
前提条件:この投稿の前半で示したコード
ワークフロー
Docker MCP Toolkitは、リクエストを専門ツールにルーティングする安全なMCPゲートウェイを通じて移行をオーケストレーションします。Arm MCP Serverはコードをスキャンし、内在的な変換を行い、GitHub MCP Serverはプルリクエストを作成し、Sequential Thinkingは多段階の移行を計画します。各ツールは独立したDockerコンテナ上で動作し、安全で再現可能、そしてあなたの管理下にあります。
ステップ 1。リポジトリのクローン
git clone https://github.com/JoeStech/docker-blog-arm-migration
GitHub Copilotの移行指示を出す
VS Codeでプロジェクトを開きます。GitHub Copilot Chatで、このプロンプトを貼り付けてください:
Your goal is to migrate this codebase from x86 to Arm64. Use the Arm MCP Server tools to help you with this migration.
Steps to follow:
1. Check all Dockerfiles - use check_image and/or skopeo tools to verify Arm compatibility, changing the base image if necessary
2. Scan the codebase - run migrate_ease_scan with the appropriate language scanner and apply the suggested changes
3. Use knowledge_base_search when you need Arm architecture guidance or intrinsic equivalents
4. Update compiler flags and dependencies for Arm64 compatibility
5. **Create a pull request with all changes using GitHub MCP Server**
Important notes:
- Your current working directory is mapped to /workspace on the MCP server
- NEON lane indices must be compile-time constants, not variables
- If you're unsure about Arm equivalents, use knowledge_base_search to find documentation
- Be sure to find out from the user or system what the target machine is, and use the appropriate intrinsics. For instance, if neoverse (Graviton, Axion, Cobalt) is targeted, use the latest SME/SME2.
**After completing the migration:**
- Create a pull request with a detailed description of changes
- Include performance predictions and cost savings in the PR description
- List all tools used and validation steps needed
ステップ 2。Watch Docker MCP Toolkit Execute
GitHub CopilotはDocker MCP Toolkitを使って移行をオーケストレーションします。こういうことが起こる:
フェーズ 1:画像解析
GitHub CopilotはまずArm MCP Serverの skopeo ツールを使ってDockerfileのベースイメージを解析します。
キャプション:GitHub CopilotはArm MCPサーバーのskopeoツールを使ってcentos:6 ベースイメージを解析しています。ツールはこの画像にビルドのARM64 がないと報告しています。これが最初に特定されたブロッカーで、コンテナはArmハードウェアでは起動すらできません。
This immediately identifies that CentOS 6 has no Arm64 builds and must be replaced.
フェーズ 2:コード解析
次に、Copilotはコードベース上でC++スキャナーを使って migrate_ease_scan ツールを実行します。
キャプション:migrate_ease_scanツールはC++のソースコードを分析し、AVX2 イントニシクス、-mavx2 コンパイラフラグ、x86固有ヘッダーを検出します。この自動スキャンは、変換が必要なアーキテクチャ依存のコードをすべて特定します。手動で見つけるのに数時間かかる作業も含めてです。
スキャン結果は、ARM互換性のために何を変えるべきかを正確に示しています。検出された各問題には、ファイルの場所、行番号、修正が必要な特定のコードが含まれています。この正確さにより、推測を排除し、見落としがありません。
フェーズ 3:アーム最適化とベストプラクティス
フェーズ2で見つかる内在通貨86、必要に応じてCopilotはArm MCPサーバーの知識ベースにArm対応のものを問い合わせます。必要に応じて交換を行います。
キャプション:GitHub Copilotはknowledge_base_searchツールを使って、各AVX2 本質的なArm NEON対応モデルを探しています。
ツールは公式のArmドキュメントを返します。変換内容を示す _mm256_loadu_pd() が vld1q_f64()、 _mm256_add_pd() が vaddq_f64()に、という具合です。この知識は learn.arm.com 学習経路や本質的なドキュメントから得られます。
ナレッジベースは変換マッピングだけでなく、アーキテクチャ的な文脈も提供します。AVX2の 256ビットベクトルとNEONの 128ビットベクトルを区別するため、ループ調整が必要です。Copilotはこの情報をもとに行列の乗算符号を正しく書き換えます。
フェーズ 4:GitHubのPRを作成し、まとめる
移行完了後、CopilotはGitHubでPRを作成し、変更内容をまとめます。
変更点は大きくなっています:
- Centos:6 → Ubuntu :22を置き換えました。04、マルチアーチビルド用のTARGETARCH追加
- Added Arm64 detection and -march=armv8-a+simd compiler flag
- AVXをNEONに変換2 →アーキテクチャガード付き
ビルドはよりシンプルでモダン、そしてARM対応になっています。
フェーズ 5:プルリクエストのチェック
プルリクエストの確認は https://github.com/JoeStech/docker-blog-arm-migration/pull/1 /
性能を検証するには、ベンチマークを作成して実行できます:
docker buildx build --platform linux/arm64 -t benchmark:arm64 . --load
docker run --rm benchmark:arm64
出力は以下の通りです:
SIMD Matrix Operations Benchmark
================================
Running on Arm64 architecture with NEON optimizations
=== Matrix Multiplication Benchmark ===
Matrix size: 200x200
Time: 17 ms
Result sum: 1.98888e+08
注意事項
非常に重要な点は、すべてのモデルが同じ結果をもたらすわけではなく、Arm MCP Serverは決定論的なコンテキストを提供しますが、モデル自体は確率的であるということです。最良の結果を得るためには常にフラッグシップの最新世代モデルを使用し、モデルがパフォーマンス向上に関して予測するものは検証してください。
Docker MCP Toolkitが開発に与える変化
Docker MCP Toolkitは、開発者が専門知識や能力とどのように関わるかを変えます。新しいツールを学んだり、依存関係をインストールしたり、認証情報を管理する代わりに、開発者はAIアシスタントを一度接続すれば、すぐにコンテナ化された専門知識にアクセスできます。
その利点はArm移行にとどまらず、
- 一貫性 – すべての開発者で同じツール、同じ結果を得られる
- セキュリティ – コンテナ化された隔離により工具の干渉が防げます
- バージョン管理 – アプリケーションコードで追跡されるMCPサーバーのバージョン
- 再現性 – 移行は環境を越えて同じように振る舞う
- 発見可能性 – Docker MCP Catalog は適切なサーバーの見つけを簡単にします
最も重要なのは、開発者が既存のワークフローを維持していることです。VS Code。GitHub Copilot。行け。外部ツールやダッシュボードにコンテキスト切り替えもありません。
まとめ
You’ve just automated Arm64 migration using Docker MCP Toolkit, the Arm MCP Server, and GitHub Copilot. What used to require architecture expertise, manual intrinsic conversion, and hours of debugging now happens through natural conversation, safely executed in Docker containers.
試してみる準備はできていますか?Docker Desktopを開き、MCPカタログを探索してください。まずはArm MCP Serverから始め、GitHubを追加し、シーケンシャルシンキングを試してみてください。各サーバーは新たな機能をアンロックします。
移行の未来はすべてのアプリケーションを手動で移植することではありません。AIアシスタントが、あなたのスタック全体を安全かつ再現可能に、そして思考の速さで実行できるのです。
詳細情報
- Docker は初めてですか? Docker Desktop をダウンロードする
- MCPカタログを探る: コンテナ化されたセキュリティ強化されたMCPサーバーを発見
- MCP Toolkitの始め方: 公式文書
