はじめに: DevOps 用の MCP
最新の DevOps にはコンテナ オーケストレーション、アプリケーション ログの継続的な分析が必要です CI/CD パイプラインの監視。これらの作業は手作業で行われるため、貴重な時間が費やされます エラーが発生する可能性があります。と モデルコンテキストプロトコル、自動化できます これらの操作は、ターミナルと GitHub ダッシュボードの間でコンテキストを変更せずに、IDE から直接実行できます。 アクションと Web インターフェイスの監視。
この記事では、次のカテゴリの 3 つの MCP サーバーを分析します。 DevOps プロジェクトの
テックMCP:
docker-compose Docker スタックの管理用、 log-analyzer のために
ログファイルの自動分析 cicd-monitor 監視用
GitHub アクション パイプライン。
この記事で学べること
- サーバーのように
docker-composeYAML を解析し、Dockerfile を解析してベスト プラクティスを実現する - として
log-analyzerログ形式を自動的に検出し、エラーパターンをグループ化します。 - として
cicd-monitorCLI を介して GitHub Actions と統合しますgh - 各ツールのパラメータを検証するための Zod スキーム
- イベント
cicd:pipeline-completedecicd:build-failedイベントバスで公開 - 3 つの DevOps サーバー間の補完的な相互作用
1. docker-compose サーバー: Docker スタック管理
サーバー ドッカー構成 解析、分析、監視のためのツールを提供します
Docker Compose 構成を生成します。それが解決する問題は複雑さの増大である
ファイルの docker-compose.yml そして神々 Dockerfile、構成エラー、
悪い習慣や標準化の欠如は、実稼働環境で問題を引き起こす可能性があります。
サーバーアーキテクチャ
サーバーは、YAML ファイルを読み取るファイルシステムと Dockerfile という 2 つの主要なチャネルで動作します。
そしてそのプロセス child_process Docker コマンドを実行するためのものです。発行も購読もしない
イベント バス上のイベント: すべての操作はステートレスでオンデマンドです。
+------------------------------------------------------------+
| docker-compose server |
| |
| +-------------------------------------------------------+ |
| | Tool Layer | |
| | | |
| | parse-compose analyze-dockerfile | |
| | list-services generate-compose | |
| +-------------------------------------------------------+ |
| | | |
| v v |
| +------------+ +------------------+ |
| | fs | | child_process | |
| | readFile | | execSync | |
| | (YAML/ | | (docker compose | |
| | Docker) | | ps --format | |
| +------------+ | json) | |
| +------------------+ |
+------------------------------------------------------------+
ツールテーブル
docker-compose サーバー ツール
| ツール | 説明 | パラメータ |
|---|---|---|
parse-compose |
docker-compose.yml ファイルを解析して検証し、サービス、ネットワーク、ボリューム、問題を抽出します | filePath （弦） |
analyze-dockerfile |
ベスト プラクティス、セキュリティ、最適化のために Dockerfile を分析する | filePath （弦） |
list-services |
実行中の Docker サービスをリストします。Compose プロジェクトによるオプションのフィルタリングも可能です。 | composePath? （弦） |
generate-compose |
サービス定義の配列から docker-compose.yml ファイルを生成する | services (オブジェクトの配列) |
Zod パターン: 解析-作成
ツール parse-compose 単一のパラメータを受け入れます filePath それは
解析する docker-compose.yml ファイルへのパス。内部パーサーは行ベースではなく、
外部 YAML ライブラリに依存します。
// Schema Zod per parse-compose
const ParseComposeSchema = z.object({
filePath: z.string().describe("Percorso al file docker-compose.yml")
});
行ベースの YAML パーサー
パーサーはファイルを 1 行ずつ分析し、最上位セクションを識別します。
(services, networks, volumes）および各サービスごとに
プロパティを抽出します。 image, build, ports,
environment e volumes。パーサーは自動検証も実行します。
- 特定のタグのない画像 (例:
nginxそれなし:1.25-alpine) - の使用
privileged: true(セキュリティリスク) - の使用
network_mode: host(すべてのポートを公開します) - なしのサービス
imagenebuild定義済み - フィールドの存在感
version廃止された
リクエストとレスポンスの例:
// Richiesta
{
"tool": "parse-compose",
"arguments": {
"filePath": "/home/user/project/docker-compose.yml"
}
}
// Risposta
{
"filePath": "/home/user/project/docker-compose.yml",
"services": ["web", "db", "redis"],
"serviceCount": 3,
"networks": ["backend"],
"volumes": ["db_data"],
"validationIssues": [
"Service \"web\" uses image \"nginx\" without a specific tag."
],
"hasIssues": true
}
Zod スキーマ:analyze-dockerfile
ツール analyze-dockerfile 一連のルールを適用して Dockerfile を検査します
3 つの重大度レベルのベスト プラクティス: error, warning
e info.
// Schema Zod per analyze-dockerfile
const AnalyzeDockerfileSchema = z.object({
filePath: z.string().describe("Percorso al Dockerfile da analizzare")
});
Dockerfile 分析ルール
| ルール | 重大度 | 説明 |
|---|---|---|
no-latest-tag |
警告 | タグ付けされたベース画像 :latest |
no-tag |
警告 | 明示的なタグのないベースイメージ |
large-base-image |
情報 | 完全なディストリビューション (ubuntu、debian、centos) の使用 |
consecutive-run |
警告 | 層を増やす連続した RUN ステートメント |
apt-no-recommends |
情報 | apt-get install それなし --no-install-recommends |
apt-update-alone |
警告 | apt-get update 同じ RUN 内にインストールせずに |
pipe-to-shell |
警告 | シェルにパイプされたcurl/wgetでダウンロード |
use-copy-over-add |
情報 | COPY で十分な場合に ADD を使用する |
missing-healthcheck |
情報 | HEALTHCHECK ステートメントが存在しません |
running-as-root |
警告 | USER ステートメントなし (コンテナは root として実行) |
Dockerfile の解析からの応答の例:
{
"filePath": "/home/user/project/Dockerfile",
"baseImage": "node:latest",
"stages": 1,
"totalInstructions": 12,
"issues": [
{
"line": 1,
"severity": "warning",
"rule": "no-latest-tag",
"message": "Base image \"node:latest\" uses the :latest tag.",
"suggestion": "Pin to a specific version tag (e.g., node:20-alpine)."
},
{
"line": 0,
"severity": "warning",
"rule": "running-as-root",
"message": "No USER instruction found.",
"suggestion": "Add a USER instruction to run as non-root."
}
],
"summary": { "errors": 0, "warnings": 2, "info": 1 }
}
Zod スキーマ: 生成-構成
ツール generate-compose サービス定義の配列を受け取り、生成します
ファイル docker-compose.yml 有効。自動的に追加します
restart: unless-stopped 各サービスに対して、名前付きボリュームを宣言します。
セクション volumes:.
// Schema Zod per generate-compose
const GenerateComposeSchema = z.object({
services: z.array(z.object({
name: z.string().describe("Nome del servizio"),
image: z.string().describe("Immagine Docker da utilizzare"),
ports: z.array(z.string()).optional()
.describe("Array di mapping porte (es. '3000:3000')"),
environment: z.record(z.string()).optional()
.describe("Variabili d'ambiente come coppie chiave-valore"),
volumes: z.array(z.string()).optional()
.describe("Array di mount (bind mount o named volume)")
})).describe("Array di definizioni servizio")
});
生成例：
// Richiesta
{
"tool": "generate-compose",
"arguments": {
"services": [
{
"name": "api",
"image": "node:20-alpine",
"ports": ["3000:3000"],
"environment": { "NODE_ENV": "production" },
"volumes": ["./src:/app/src"]
},
{
"name": "postgres",
"image": "postgres:16-alpine",
"ports": ["5432:5432"],
"environment": { "POSTGRES_PASSWORD": "secret" },
"volumes": ["pg_data:/var/lib/postgresql/data"]
}
]
}
}
# Output generato
services:
api:
image: node:20-alpine
ports:
- "3000:3000"
environment:
NODE_ENV: "production"
volumes:
- ./src:/app/src
restart: unless-stopped
postgres:
image: postgres:16-alpine
ports:
- "5432:5432"
environment:
POSTGRES_PASSWORD: "secret"
volumes:
- pg_data:/var/lib/postgresql/data
restart: unless-stopped
volumes:
pg_data:
Zod スキーマ: list-services
ツール list-services 実行中の Docker サービスをリストします。内部的に
実行する docker compose ps --format json そして、失敗した場合は試してみてください
従来のコマンドを使用した場合 docker-compose ps --format json.
// Schema Zod per list-services
const ListServicesSchema = z.object({
composePath: z.string().optional()
.describe("Percorso opzionale al docker-compose.yml per filtrare")
});
// Formato risposta
interface ServiceInfo {
name: string;
status: string;
image: string;
ports: string;
}
2. サーバーログアナライザー: 自動ログ分析
サーバー ログアナライザー ログファイルという普遍的な問題に対処します それらは急速に成長し、何千行も含まれ、エラー パターンや異常を識別します。 またはトレンドには時間と特別なスキルが必要です。このサーバーは分析を自動化します。 プレーン テキスト ログと JSON (NDJSON) 形式の構造化ログの両方をサポートします。
サーバーアーキテクチャ
として docker-compose、 また log-analyzer そしてステートレスサーバー
イベントの発行もサブスクライブも行いません。ファイルシステム上で直接動作します。
fs/promises.
+------------------------------------------------------------+
| log-analyzer server |
| |
| +-------------------------------------------------------+ |
| | Tool Layer | |
| | | |
| | analyze-log-file find-error-patterns | |
| | tail-log generate-summary | |
| +-------------------------------------------------------+ |
| | |
| v |
| +-------------------------------------------------------+ |
| | fs/promises (readFile) | |
| | | |
| | Formati supportati: | |
| | - Plain text (syslog, Apache, custom) | |
| | - JSON lines (NDJSON, structured logging) | |
| | - Auto-detection basata su campionamento | |
| +-------------------------------------------------------+ |
+------------------------------------------------------------+
ツールテーブル
サーバーログ分析ツール
| ツール | 説明 | パラメータ |
|---|---|---|
analyze-log-file |
ログ ファイルの分析: レベルごとのカウント、エラー抽出、時間範囲 | filePath （弦）; format? (自動 | json | プレーン) |
find-error-patterns |
類似したメッセージをグループ化して、再発するエラーのパターンを見つける | filePath （弦）; minCount? (数値、デフォルト: 2) |
tail-log |
オプションのフィルタリングを使用して、ログ ファイルの最後の N 行を返します。 | filePath （弦）; lines? (数値、デフォルト: 50); filter? （弦） |
generate-summary |
カウント、ヘルスインジケーター、上位エラーを含む読みやすい概要を生成します | filePath （弦） |
フォーマットの自動検出
サーバーはファイルの最初の 10 行をサンプリングして、ログが
JSON またはプレーンテキスト形式で。各行が次で始まる場合 { そしてそれは解析されます
JSON として正しく設定されている場合、形式は次のように設定されます。 json。それ以外の場合は、
サーバーは正規表現を使用してログ レベルとタイムスタンプを抽出します。
サポートされているタイムスタンプ パターン
| 形式 | Esempio |
|---|---|
| ISO8601 | 2024-01-15T10:30:00.000Z |
| 共通ログ形式 | 15/Jan/2024:10:30:00 +0000 |
| シスログ | Jan 15 10:30:00 |
| 一般的な日付/時刻 | 2024-01-15 10:30:00 |
認識されるログ レベルは次のとおりです。 ERROR, WARN （警告）、
INFO, DEBUG, TRACE, FATAL,
CRITICAL e NOTICE.
Zod スキーマ: 分析ログファイル
// Schema Zod per analyze-log-file
const AnalyzeLogFileSchema = z.object({
filePath: z.string().describe("Percorso al file di log"),
format: z.enum(["auto", "json", "plain"]).optional()
.default("auto")
.describe("Formato del log: auto-detect, JSON lines o plain text")
});
回答例:
{
"totalLines": 5420,
"levels": {
"INFO": 5100,
"WARN": 250,
"ERROR": 65,
"DEBUG": 5
},
"topErrors": [
{ "message": "Connection refused to redis:6379", "count": 30 },
{ "message": "Request timeout after 30000ms", "count": 20 }
],
"timeRange": {
"earliest": "2024-06-15T08:00:01.234Z",
"latest": "2024-06-15T18:45:30.567Z"
}
}
Zod パターン: find-error-patterns
ツール find-error-patterns エラーメッセージをグループに正規化する
異なるデータで同じ問題が発生する場合。 UUID、IP アドレス、番号、URL、パス
は汎用のプレースホルダーに置き換えられます。
// Schema Zod per find-error-patterns
const FindErrorPatternsSchema = z.object({
filePath: z.string().describe("Percorso al file di log"),
minCount: z.number().optional().default(2)
.describe("Numero minimo di occorrenze per considerare un pattern")
});
エラーパターンの正規化
| 要素 | 交換 | Esempio |
|---|---|---|
| タイムスタンプ | <TIMESTAMP> |
2024-01-15T10:30:00Z になる <TIMESTAMP> |
| UUID | <UUID> |
550e8400-e29b-... になる <UUID> |
| 16進数のハッシュ | <HEX> |
a1b2c3d4e5f6 になる <HEX> |
| IPアドレス | <IP> |
192.168.1.1:3000 になる <IP> |
| URL | <URL> |
https://api.example.com/v1 になる <URL> |
| パスファイル | <PATH> |
/var/log/app/error.log になる <PATH> |
| 数字 | <NUM> |
42, 1024 彼らはなる <NUM> |
| 引用符で囲まれた文字列 | "<STR>" |
"user not found" になる "<STR>" |
正規化されたパターンによる応答の例:
{
"totalPatternsFound": 4,
"minCount": 3,
"patterns": [
{
"pattern": "Connection refused to <IP>",
"count": 30,
"examples": [
"Connection refused to 10.0.0.5:6379",
"Connection refused to 10.0.0.5:6380"
]
},
{
"pattern": "Request timeout after <NUM>ms for <URL>",
"count": 20,
"examples": [
"Request timeout after 30000ms for https://api.external.com/v1/users"
]
}
]
}
Zod スキーム: テールログ
// Schema Zod per tail-log
const TailLogSchema = z.object({
filePath: z.string().describe("Percorso al file di log"),
lines: z.number().optional().default(50)
.describe("Numero di righe da restituire dalla fine del file"),
filter: z.string().optional()
.describe("Stringa di filtro per selezionare solo le righe corrispondenti")
});
エラーフィルターを使用した例:
// Richiesta
{
"tool": "tail-log",
"arguments": {
"filePath": "/var/log/app/application.log",
"lines": 20,
"filter": "ERROR"
}
}
// Risposta
"2024-06-15T18:30:00Z ERROR Connection refused to redis:6379\n
2024-06-15T18:35:12Z ERROR Request timeout after 30000ms\n
..."
Zod スキーマ: 生成-概要
ツール generate-summary 以下を含む包括的なテキスト レポートを作成します。
レベルごとのカウント、時間範囲、ヘルスインジケーター (エラー率、警告率)
頻度別の上位 5 件のエラー。
// Schema Zod per generate-summary
const GenerateSummarySchema = z.object({
filePath: z.string().describe("Percorso al file di log da riassumere")
});
フォーマットされた出力の例:
Log File Summary: /path/to/file.log
==================================================
Total lines: 15234
Log Level Breakdown:
ERROR: 42 (0.3%)
WARN: 156 (1.0%)
INFO: 14836 (97.4%)
DEBUG: 200 (1.3%)
Time Range:
Earliest: 2024-01-15T00:00:01Z
Latest: 2024-01-15T23:59:58Z
Health Indicators:
Error rate: 0.3%
Warning rate: 1.0%
Top Error Messages:
1. [15x] Connection timeout to database
2. [12x] Failed to parse request body
3. [8x] Authentication token expired
3. cicd-monitor サーバー: CI/CD パイプライン監視
サーバー cicd-モニター MCP スイートとパイプライン間のブリッジ
継続的インテグレーションと継続的デプロイメント。ネイティブに統合されます
GitHub アクション CLI経由 ghを監視できるようになります。
ワークフローを実行し、ビルドログを表示し、問題のないテストを特定します。
開発環境を終了します。
cicd-monitor の前提条件
- GitHub CLI (
gh) でインストールされ、認証されましたgh auth login - ターゲット GitHub リポジトリへのアクセス (所有者または寄稿者)
サーバーアーキテクチャ
前の 2 つのサーバーとは異なり、 cicd-monitor イベントを公開する
イベントバスにて。ツールのとき get-pipeline-status 完了したワークフローを検出します
または失敗した場合は、他のサーバーが消費できる対応するイベントを発行します。
どうやって standup-notes e agile-metrics.
+------------------------------------------------------------+
| cicd-monitor server |
| |
| +-------------------------------------------------------+ |
| | Tool Layer | |
| | | |
| | list-pipelines get-pipeline-status | |
| | get-build-logs get-flaky-tests | |
| +-------------------------------------------------------+ |
| | |
| v |
| +-------------------------------------------------------+ |
| | child_process.execSync | |
| | Comandi: gh run list / gh run view | |
| +-------------------------------------------------------+ |
| | |
| v |
| +-------------------------------------------------------+ |
| | Event Bus | |
| | cicd:pipeline-completed | |
| | cicd:build-failed | |
| +-------------------------------------------------------+ |
+------------------------------------------------------------+
ツールテーブル
cicd-monitor サーバー ツール
| ツール | 説明 | パラメータ |
|---|---|---|
list-pipelines |
最近の GitHub Actions ワークフロー実行をリストします。 | repo? (文字列、所有者/リポジトリ); limit (数値、デフォルト: 10) |
get-pipeline-status |
ジョブとステップで実行される特定のワークフローの詳細 | runId （弦）; repo? （弦） |
get-build-logs |
ワークフロー実行の最後の N ログ行をダウンロードする | runId （弦）; repo? （弦）; lines (数値、デフォルト: 100) |
get-flaky-tests |
最近の実行を分析して、断続的に合格または失敗するテストを見つける | repo? （弦）; branch? （弦）; runs (数値、デフォルト: 20) |
Zod スキーム: リストパイプライン
// Schema Zod per list-pipelines
const ListPipelinesSchema = z.object({
repo: z.string().optional()
.describe("Repository nel formato owner/repo"),
limit: z.number().optional().default(10)
.describe("Numero massimo di run da restituire")
});
ツールは内部的にコマンドを実行します
gh run list --json databaseId,displayTitle,headBranch,event,status,conclusion,createdAt,updatedAt,url,workflowName
そして結果を簡略化された形式にマッピングします。
// Risposta
{
"total": 5,
"runs": [
{
"id": 12345678,
"title": "feat: add user authentication",
"branch": "feature/auth",
"event": "push",
"status": "completed",
"conclusion": "success",
"workflow": "CI",
"createdAt": "2024-06-15T10:00:00Z",
"url": "https://github.com/my-org/my-project/actions/runs/12345678"
}
]
}
Zod スキーム: get-pipeline-status
ツール get-pipeline-status そしてサーバーの中で最も重要なのは、それだけではありません。
ワークフロー実行の詳細だけでなく、公開のトリガーも提供します。
イベントバスのイベントの様子。
// Schema Zod per get-pipeline-status
const GetPipelineStatusSchema = z.object({
runId: z.string().describe("ID del workflow run di GitHub Actions"),
repo: z.string().optional()
.describe("Repository nel formato owner/repo")
});
このツールは 2 つのコマンドを実行します gh 順番: 1 つは実行の詳細用、もう 1 つは実行の詳細用
ジョブとステップ用。結果に基づいて、適切なイベントを公開します。
- Se
conclusion == 'success'： 公開cicd:pipeline-completedステータス付きsuccess - Se
conclusion == 'failure': 両方を公開しますcicd:pipeline-completedステータス付きfailedsiacicd:build-failed失敗したジョブの名前を付けて
// Risposta con dettaglio job e step
{
"id": 12345678,
"title": "feat: add user authentication",
"branch": "feature/auth",
"sha": "abc123def456",
"conclusion": "failure",
"jobs": [
{
"name": "build",
"conclusion": "success",
"steps": [
{ "name": "Checkout", "conclusion": "success", "number": 1 },
{ "name": "Install", "conclusion": "success", "number": 2 },
{ "name": "Build", "conclusion": "success", "number": 3 }
]
},
{
"name": "test",
"conclusion": "failure",
"steps": [
{ "name": "Run tests", "conclusion": "failure", "number": 1 }
]
}
]
}
Zod スキーマ: get-build-logs
// Schema Zod per get-build-logs
const GetBuildLogsSchema = z.object({
runId: z.string().describe("ID del workflow run"),
repo: z.string().optional()
.describe("Repository nel formato owner/repo"),
lines: z.number().optional().default(100)
.describe("Numero di righe di log da restituire")
});
ツールが実行される gh run view <id> --log 60秒のタイムアウト付き
(ログは 10MB に達する可能性があるため、他のコマンドよりも大きくなります)
最後の N 行。
Zod スキーム: get-flaky-tests
不安定なテストの検出は、最も複雑なサーバー操作です。アルゴリズム 過去 N 回の実行を分析し、ブランチとワークフローごとにグループ化し、ステップを特定します 成功と失敗の両方があります。
// Schema Zod per get-flaky-tests
const GetFlakyTestsSchema = z.object({
repo: z.string().optional()
.describe("Repository nel formato owner/repo"),
branch: z.string().optional()
.describe("Branch specifico da analizzare"),
runs: z.number().optional().default(20)
.describe("Numero di run recenti da analizzare")
});
不安定なテスト検出アルゴリズム
- 最新の N 回の実行 (デフォルトは 20) を取得します。
gh run list - グループ化
branch + workflow - 結果が混在する各グループ (成功 + 失敗): 最大 5 回の実行までサンプルを作成します。
- サンプリングされた実行ごとに、次の方法でジョブとステップを取得します。
gh run view - ステップごとに、合格/不合格数を追跡します。
- 手順を特定するには 両方
passCount > 0efailCount > 0 - を計算します。 剥離率:
min(passCount, failCount) / totalRuns * 100 - 剥離率が低い順に並べ替えます
// Risposta get-flaky-tests
{
"analyzedRuns": 20,
"branchesAnalyzed": 1,
"flakyStepsFound": 2,
"flaky": [
{
"branch": "main",
"workflow": "CI",
"job": "test",
"step": "Run integration tests",
"passCount": 3,
"failCount": 2,
"totalRuns": 5,
"flakinessRate": 40.0
}
]
}
イベントバスでのイベント
3 つの DevOps サーバーのうち、 cicd-monitor イベント バス上でイベントを公開します。
サーバー docker-compose e log-analyzer 彼らは完全に無国籍です
イベント システムと対話しないでください。
cicd-monitor によって発行されたイベント
| イベント | 発行者 | ペイロード | 状態 |
|---|---|---|---|
cicd:pipeline-completed |
get-pipeline-status |
{ pipelineId, status, branch, duration } |
常に、実行の詳細を取得した後 |
cicd:build-failed |
get-pipeline-status |
{ pipelineId, error, stage, branch } |
場合のみ conclusion == 'failure' |
パイプラインの継続時間は、次の間のミリ秒単位の差として計算されます。
updatedAt e createdAt。イベントが消費される
主に:
- スタンドアップノート: 完了したビルドと失敗したビルドの通知を受け取り、自動日次レポートを生成します
- アジャイルメトリクス: プロジェクト ダッシュボードのパイプライン速度と障害率のメトリクスを集計します。
DevOpsサーバー間の相互作用
3 つの DevOps サーバーは、補完的に動作するように設計されています。それぞれですが、 は独立して動作でき、3 つの組み合わせは DevOps サイクル全体をカバーします。
統合されたワークフロー
- ドッカー構成 デプロイ前に Docker 構成を検証する
- cicd-モニター Docker ビルドを含むパイプラインの実行を監視する
- ログアナライザー デプロイ後にコンテナログを分析します
- Se
cicd-monitor失敗を検出すると、ビルド ログがダウンロードされます。get-build-logsで分析できますlog-analyzer
相互作用マトリックス
| サーバ | と対話します | タイプ | 説明 |
|---|---|---|---|
docker-compose |
log-analyzer |
補完的 | Dockerコンテナのログを分析できる |
docker-compose |
cicd-monitor |
補完的 | パイプラインの一部として追跡された Docker ビルド |
cicd-monitor |
log-analyzer |
補完的 | ビルドログをダウンロードして詳細に分析 |
cicd-monitor |
standup-notes |
イベントバス経由 | 完了/失敗したビルドをレポート用に通知する |
cicd-monitor |
agile-metrics |
イベントバス経由 | パイプラインの速度と障害率のメトリクス |
クロードのデスクトップ構成
Claude Desktop で 3 つの DevOps サーバーを使用するには、次のエントリを追加します。 設定ファイルに以下を追加します。
{
"mcpServers": {
"docker-compose": {
"command": "node",
"args": ["path/to/Tech-MCP/servers/docker-compose/dist/index.js"],
"env": {}
},
"log-analyzer": {
"command": "node",
"args": ["path/to/Tech-MCP/servers/log-analyzer/dist/index.js"],
"env": {}
},
"cicd-monitor": {
"command": "node",
"args": ["path/to/Tech-MCP/servers/cicd-monitor/dist/index.js"],
"env": {}
}
}
}
今後の展開
DevOps サーバーのロードマップには、次のような大幅な改善が含まれています。
- ドッカー構成: Docker Swarm サポート、ネットワーク検証、多段階 Dockerfile 分析、共通スタック用テンプレート (LAMP、MEAN)、コンテナーの開始/停止/クラッシュ イベントのイベント バス統合
- ログアナライザー: リアルタイムストリーミング
fs.watch、複数ファイルの関連付け、異常検出、圧縮ファイルのサポート.gze.bz2、ASCII ヒストグラムで出力 - cicd-モニター: マルチプラットフォームのサポート (GitLab CI、Bitbucket Pipelines、Jenkins)、インテリジェントなキャッシュ、履歴傾向分析、DORA メトリクス (リード タイム、サイクル タイム、デプロイメント頻度)
結論
Tech-MCP の 3 つの DevOps サーバーは自動化の中核的なニーズをカバーします
DevOps: docker-compose Docker 構成の品質を保証します
YAML 解析と Dockerfile 解析を使用すると、 log-analyzer 分析を自動化する
フォーマットの自動検出とエラー パターンの正規化を備えたアプリケーション ログ、
e cicd-monitor GitHub Actions パイプライン監視を直接実現
IDE で不安定なテストを自動検出します。
最も興味深い点は、 相補性: ダウンロードされたビルド ログ
から cicd-monitor で分析できます log-analyzer、一方
検証された Docker 構成 docker-compose パイプラインにフィードする
によって監視されています cicd-monitor。イベントバスコネクトに掲載されたイベント
DevOps サイクルからプロジェクト管理までのサイクルが終了します。
次の記事では、サーバーを分析します。 データベースとテスト:
db-schema-explorer パターンを探索するために、 data-mock-generator
テストデータを生成するため、 test-generator 自動作成用
テストと performance-profiler パフォーマンスプロファイリング用。
すべてのサーバーの完全なコードはリポジトリで入手できます GitHub 上の Tech-MCP.