소개: DevOps용 MCP
최신 DevOps에는 컨테이너 오케스트레이션, 애플리케이션 로그의 지속적인 분석이 필요합니다. CI/CD 파이프라인을 모니터링합니다. 수동으로 수행되는 이러한 활동은 귀중한 시간을 소모합니다. 오류가 발생할 수 있습니다. 와 함께 모델 컨텍스트 프로토콜, 우리는 자동화할 수 있습니다 터미널과 GitHub 대시보드 간의 컨텍스트를 변경하지 않고 IDE에서 직접 이러한 작업을 수행합니다. 작업 및 모니터링 웹 인터페이스.
이 기사에서는 카테고리의 세 가지 MCP 서버를 분석합니다. 데브옵스 프로젝트의
Tech-MCP:
docker-compose Docker 스택 관리를 위해 log-analyzer 에 대한
로그 파일의 자동 분석 e cicd-monitor 모니터링을 위해
GitHub Actions 파이프라인.
이 기사에서 배울 내용
- 서버와 마찬가지로
docker-compose모범 사례를 위해 YAML을 구문 분석하고 Dockerfile을 구문 분석합니다. - 처럼
log-analyzer로그 형식을 자동으로 감지하고 오류 패턴을 그룹화합니다. - 처럼
cicd-monitorCLI를 통해 GitHub Actions와 통합gh - 각 도구의 매개변수를 검증하기 위한 Zod 체계
- 이벤트
cicd:pipeline-completedecicd:build-failed이벤트 버스에 게시됨 - 세 개의 DevOps 서버 간의 상호 보완적인 상호 작용
1. docker-compose 서버: Docker 스택 관리
서버 도커 작성 구문 분석, 분석, 모니터링을 위한 도구를 제공합니다.
Docker Compose 구성을 생성합니다. 그것이 해결하는 문제는 복잡성이 증가한다는 것입니다.
파일의 docker-compose.yml 그리고 신들 Dockerfile, 여기서 구성 오류,
나쁜 관행과 표준화 부족으로 인해 생산에 문제가 발생할 수 있습니다.
서버 아키텍처
서버는 두 가지 주요 채널, 즉 YAML 파일을 읽기 위한 파일 시스템과 Dockerfile에서 작동합니다.
그리고 그 과정 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 |
Compose 프로젝트별로 선택적으로 필터링하여 실행 중인 Docker 서비스를 나열합니다. | 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 파서
파서는 파일을 한 줄씩 분석하여 최상위 섹션을 식별합니다.
(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을 검사합니다.
세 가지 심각도 수준의 모범 사례: 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 |
경고 | 컬/wget을 셸로 파이프하여 다운로드 |
use-copy-over-add |
정보 | COPY로 충분할 경우 ADD 사용 |
missing-healthcheck |
정보 | HEALTHCHECK 문이 없습니다. |
running-as-root |
경고 | USER 문 없음(컨테이너는 루트로 실행됨) |
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 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 |
|---|---|
| ISO 8601 | 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 오류 메시지를 그룹으로 정규화
다른 데이터에서 동일한 문제가 발생합니다. 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 구성표: tail-log
// 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 저장소에 대한 액세스(소유자 또는 기여자)
서버 아키텍처
이전 두 서버와는 달리, 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-모니터 서버 도구
| 도구 | 설명 | 매개변수 |
|---|---|---|
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")
});
이 도구는 두 가지 명령을 실행합니다. gh 순서대로: 하나는 실행 세부정보용이고 다른 하나는
작업 및 단계에 대해. 결과에 따라 적절한 이벤트를 게시합니다.
- Se
conclusion == 'success': 게시cicd:pipeline-completed상태와 함께success - Se
conclusion == 'failure': 둘 다 게시cicd:pipeline-completed상태와 함께failed~이다cicd: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 서버 간의 상호 작용
세 개의 DevOps 서버는 상호 보완적으로 작동하도록 설계되었습니다. 비록 각각 독립적으로 작동할 수 있으며 세 가지의 조합이 전체 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에서 세 개의 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의 세 가지 DevOps 서버는 자동화의 핵심 요구 사항을 충족합니다.
데브옵스: docker-compose Docker 구성의 품질을 보장합니다.
YAML 구문 분석 및 Dockerfile 구문 분석을 사용하면 log-analyzer 분석 자동화
오류 패턴의 형식 및 정규화 자동 감지 기능을 갖춘 애플리케이션 로그
전자 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.