Jenkins 에이전트 — 전체 DevOps 강의
Source: Dev.to
Source: …
우리가 해결하려는 문제는 무엇인가요?
실제 시스템에서는 빌드가 무겁고, 다양하며, 병렬로 진행됩니다. 하나의 Jenkins 인스턴스가 모든 작업을 혼자 안전하고 효율적으로 수행할 수 없습니다.
에이전트는 Jenkins가 규모를 확장하고, 격리하며, 프로덕션에서 살아남게 하는 방법입니다.
1) Jenkins 에이전트란?
Jenkins에는 두 가지 역할이 있습니다:
Controller (이전 명칭 “master”)
- UI, 작업 정의
- 스케줄링 및 오케스트레이션
- 자격 증명 및 설정
Agent (worker/node)
- 실제 작업을 실행합니다:
git clonenpm installdocker buildterraform apply- 테스트, 스캔, 패키징
핵심 규칙: Controller는 무엇을 실행할지 결정하고, Agent는 어디서, 어떻게 실행할지를 결정합니다.
2) DevOps가 Jenkins 에이전트를 필요로 하는 이유
이유 1 — 성능 및 확장성
모든 작업을 Controller에서 실행하면:
- CPU 급증
- 빌드 지연
- Jenkins 불안정
에이전트를 사용하면:
- 여러 빌드를 병렬로 실행
- 하나의 대형 서버를 업그레이드하는 대신 워커를 추가
DevOps 원칙: 수직 확장보다 수평 확장.
이유 2 — 격리 및 안전성
빌드는 위험할 수 있습니다:
- 신뢰할 수 없는 코드
- 임의 스크립트
- Docker 데몬 접근
- 클라우드 자격 증명 사용
에이전트는:
- 실패를 격리
- 잘못된 빌드가 Jenkins를 다운시키는 것을 방지
- 일회용 환경 제공
이유 3 — 다양한 환경
실제 파이프라인은 다음이 필요합니다:
- Linux 에이전트
- Windows 에이전트
- macOS 에이전트
- ARM vs x86
- 서로 다른 툴체인
에이전트를 사용하면: 올바른 작업 → 올바른 머신.
이유 4 — 보안 및 규정 준수
베스트 프랙티스:
- Controller에 Docker 없음
- Controller에 클라우드 관리자 키 없음
- Controller가 아티팩트를 빌드하지 않음
에이전트는:
- 최소 권한만 부여
- 회전하거나 파기됨
- 최소 권한 원칙 적용
3) 고수준 아키텍처
흐름:
- 개발자가 코드를 푸시
- Jenkins Controller가 이벤트를 수신
- Controller가 라벨로 에이전트를 선택
- 에이전트가 파이프라인 단계 실행
- 결과가 Controller에 반환
4) 에이전트가 사용되는 곳 (실제 DevOps 시나리오)
시나리오 1 — 마이크로서비스 CI
- 각 서비스가 독립적으로 빌드
- 에이전트가 유닛 테스트와 Docker 이미지 빌드 수행
- 다수의 에이전트 = 더 빠른 CI
시나리오 2 — 인프라스트럭처 as Code (Terraform)
- 에이전트에 Terraform, AWS CLI, IAM 역할이 설치
- Controller는 직접 AWS에 접근하지 않음
시나리오 3 — Docker & Kubernetes
- Docker 빌드
Source: …
on Docker‑enabled agents
- Kubernetes agents run inside the cluster
- Ephemeral pods for every pipeline run
Scenario 4 — Security Scanning
Dedicated agents for:
- SAST
- Dependency scanning
- Image scanning
Isolated from prod builds
Scenario 5 — Multi‑OS Testing
- Windows agent → .NET build
- Linux agent → backend services
- macOS agent → iOS build
5) Types of Jenkins Agents (DevOps View)
1️⃣ Static / Permanent Agents
- Long‑running VMs
- SSH or local connection
Good for:
- Legacy systems
- Stable workloads
2️⃣ Docker Agents
- Agent = container
- Created per build
- Destroyed after job
Why DevOps loves this:
- Clean environment
- No dependency conflicts
- Easy version control
3️⃣ Cloud VM Agents (EC2, GCE, Azure)
- Auto‑scale based on demand
- Shut down when idle
- Cost‑efficient
4️⃣ Kubernetes Agents (Modern Standard)
- Agent = Kubernetes pod
- Dynamically provisioned per build
- Leverages cluster scheduling & resource isolation
에이전트 유형
- 완전 일시적 – 마이크로‑서비스에 최적
- 대규모 조직을 위한 산업 표준
Jenkins가 에이전트를 선택하는 방법
라벨 (가장 중요)
에이전트는 다음과 같은 라벨을 가집니다:
linux
docker
terraform
k8s
mac파이프라인 예시
pipeline {
agent { label 'docker' }
stages {
stage('Build') {
steps {
sh 'docker build -t app .'
}
}
}
}번역: “Docker 빌드를 수행할 수 있는 에이전트에서만 이 작업을 실행합니다.”
에이전트가 Jenkins에 연결되는 방법
옵션 A — WebSocket (추천)
- 아웃바운드 연결만
- 인바운드 포트 없음 → 방화벽 친화적
- 최신 기본값
사용 상황: 기업 네트워크, 로컬 데모, NAT 뒤에 있는 클라우드 에이전트.
옵션 B — SSH
- Jenkins가 에이전트에 연결을 시작함
- EC2 인스턴스에서 일반적
사용 상황: 안정적인 VM, 전통적인 인프라.
옵션 C — Kubernetes 플러그인
- Jenkins가 포드를 요청하고, 포드가 에이전트로 등록됨
- 작업이 끝난 후 포드가 종료됨
사용 상황: 클라우드 네이티브 파이프라인, GitOps 환경.
에이전트 수명 주기 (DevOps 사고)
| 유형 | 수명 주기 |
|---|---|
| Static VM | 항상 실행 |
| Docker agent | 작업당 |
| Kubernetes pod | 작업당 |
| Cloud VM | 자동 확장 |
추세: 일시적 > 영구적
DevOps가 따라야 할 모범 사례
- ❌ 컨트롤러에서 빌드를 실행하지 마세요
- ✅ 라벨을 올바르게 사용하세요
- ✅ 일시적인 에이전트를 선호하세요 (Docker, Kubernetes)
- ✅ 빌드, 테스트, 배포 에이전트를 분리하세요
- ✅ 사용 후 에이전트를 교체하거나 파기하세요
- ✅ 에이전트당 최소 권한만 부여하세요
- ✅ 에이전트 상태를 모니터링하세요
일반적인 실수 (면접 함정)
- “Everything runs on Jenkins master” ❌
- “Agents are optional” ❌
- “One agent is enough” ❌
- “Controller can run Docker builds” ❌
올바른 사고방식: 에이전트가 없는 Jenkins는 프로덕션에 적합하지 않다.
Interview‑Ready Summary (Memorize)
“Jenkins 에이전트는 파이프라인 단계를 실행하는 워커 노드입니다. 우리는 이를 CI/CD를 확장하고, 빌드를 격리하며, 여러 환경을 지원하고, 보안을 향상시키기 위해 사용합니다. 현대 DevOps에서는 에이전트가 ephemeral—대개 Docker 또는 Kubernetes 기반이며—Jenkinsfile에서 labels를 통해 선택됩니다.”