Day-15 'It Works on My Machine'에서 자동화로: Jenkins와 Docker 학습

Source: Dev.to

Introduction

오늘은 내 DevOps 학습 여정에서 중요한 날이었다. 수동 프로세스를 벗어나 자동화의 세계를 탐구하기 시작했다. 이번 학습의 초점은 CI/CD 뒤에 있는 왜를 이해하고, Jenkins가 작업을 어떻게 조율하는지 살펴보며, Docker의 핵심 개념을 다시 검토해 가상 머신과 근본적으로 어떻게 다른지 파악하는 것이었다.

아래는 오늘 배운 내용의 정리이다.

Why CI/CD? (Continuous Integration / Continuous Deployment)

도구에 들어가기 전에 CI/CD가 현대 소프트웨어 개발의 기반인 이유를 배웠다.

• The Problem: 과거에는 개발자들이 몇 주씩 코드를 독립적으로 작성했다. 변경 사항을 병합하려고 할 때마다 “통합 지옥”에 빠졌고, 충돌이 곳곳에 발생하며 빌드가 깨졌다.
• The Solution (CI): 지속적 통합은 개발자들이 코드를 중앙 저장소에 자주 병합하도록 한다. 자동화된 빌드와 테스트가 즉시 실행되어 버그를 조기에 잡아낸다.
• The Delivery (CD): 지속적 배포/전달은 코드 변경이 자동으로 프로덕션 릴리스 준비가 되도록 보장한다.

Key Takeaway: CI/CD는 단순히 속도만을 위한 것이 아니라 신뢰성을 위한 것이다. “내 머신에서는 동작한다”는 변명을 없애준다.

How Jenkins Works

Jenkins는 오픈‑소스 자동화 서버이며, 흔히 DevOps의 “집사”라고 불린다. 빌드, 테스트, 배포와 관련된 소프트웨어 개발의 여러 부분을 자동화한다.

Architecture

• Jenkins Master: 두뇌 역할을 한다. 설정을 보관하고, 작업을 스케줄링하며, 전체 프로세스를 모니터링하고, 사용자에게 GUI를 제공한다.
• Jenkins Agents (Nodes): 작업자 역할을 한다. 마스터가 에이전트에 명령을 보내고, 에이전트가 실제 빌드 단계(예: Java 코드 컴파일 또는 Python 스크립트 실행)를 수행한다.

Jenkins는 pipelines(Jenkinsfile에 정의) 를 사용해 배포 과정의 단계를 스크립트화한다.

Docker Revisited: Images vs. Containers

두 개념을 혼동하기 쉬우니, 나에게 도움이 된 비유를 소개한다:

• Docker Image: 레시피 (또는 프로그래밍의 클래스) 라고 생각하면 된다. 애플리케이션 코드, 라이브러리, 실행에 필요한 의존성을 포함한 읽기 전용 템플릿이다.
• Docker Container: 케이크 (또는 프로그래밍의 객체) 라고 생각하면 된다. 이미지의 실행 가능한 인스턴스로, 하나의 레시피(이미지)로 여러 개의 케이크(컨테이너)를 만들 수 있다.

Docker Containers vs. Virtual Machines (VMs)

Virtual Machines

• 무겁다.
• 각 VM마다 전체 게스트 운영체제(OS)가 필요하다.
• 부팅하는 데 몇 분이 걸린다.

Docker Containers

• 가볍다.
• 호스트 OS 커널을 공유하므로 각 애플리케이션마다 전체 OS가 필요하지 않다.
• 밀리초 단위로 시작한다.

Verdict: 컨테이너는 전체 컴퓨터 하드웨어와 OS를 시뮬레이션하는 오버헤드 없이 애플리케이션 프로세스를 격리하기 때문에 더 효율적이다.

Conclusion

오늘은 자동화에 대한 탄탄한 이론적 기반을 마련해 주었다. Jenkins의 아키텍처와 Docker 컨테이너의 효율성을 이해함으로써 왜 이 도구들이 업계 표준이 되는지 명확해졌다. 이제 직접 손을 더럽히며 첫 Jenkins 파이프라인을 구축해 보는 것이 기대된다!