Docker

종속성 문제

애플리케이션을 다른 컴퓨터나 환경으로 옮기면 설정이나 종속성 문제가 발생할 수 있다. 이때, 종속성 문제란 개발 시에 다른 소프트웨어나 라이브러리에 의존하는 상황을 의미한다. 이는 특정 버전의 라이브러리나 프레임워크를 사용해야 할 때 해당 라이브러리나 프레임워크가 다른 요소들과 충돌하거나 호환되지 않는 경우에 발생한다. 가령, 개발자 A가 로컬 윈도우 컴퓨터에서 애플리케이션을 개발할 때 특정 버전의 라이브러리를 사용했지만, 개발자 B가 동일한 애플리케이션을 다른 환경에서 실행하려고 할 때 해당 버전의 라이브러리를 찾을 수 없거나 이전 버전의 라이브러리를 사용해야 할 수 있다.

Docker의 필요성

도커는 이런 종속성 문제를 해결함으로써 소프트웨어 개발 및 배포를 더 쉽고 효율적으로 만들어준다. 도커는 개발자들이 다른 운영체제나 환경에서 작업하더라도 동일한 환경에서 애플리케이션을 실행할 수 있도록 한다. 즉, 도커를 사용하면 각각의 환경에서 동일한 실행 환경을 보장할 수 있고, 따라서 호환성 문제를 해결한다. 그럼 어떻게 동일한 환경을 제공할까? 바로 docker image와 conatiner를 통해서다.

Docker Image & Container

도커는 애플리케이션에 필요한 모든 것(코드, 환경 설정, 라이브러리 등)을 '상자' 안에 담는다. 상자는 가상 실행 환경을 정의한 것이라고 생각하면 되며, 애플리케이션을 실행하는 데 있어 필요한 모든 것을 담고 있기에 어떤 환경에서 실행하든 동일한 실행 환경을 제공한다.

Docker Image

여기서 상자는 docker image이다. 도커 이미지는 애플리케이션 실행에 필요한 모든 것을 포함한 패키지로, 정적인 파일이다. 이미지는 읽기 전용이며 애플리케이션을 실행하기 위한 환경 템플릿이라고 생각하면 된다. 이를 실행한 것을 docker container라고 부른다.

Docker Container

도커 컨테이너는 더 구체적으로 정의하자면 이미지의 인스턴스로, 실행 중인 프로세스이다. 이미지에 정의된 설정들을 바탕으로 컨테이너라는 실행 환경을 생성하고, 그 환경에서 애플리케이션을 실행시키는 것이다. 이때, 이미지를 통해 여러 개의 컨테이너를 만들 수 있는데, 각 컨테이너는 독립적인 파일 시스템과 네트워크를 가지고 있다. 즉, 컨테이너들은 각각 다른 데이터를 저장 및 관리하며, 각 컨테이너는 독립된 네트워크 환경을 가지기에 한 컨테이너에서 발생한 트래픽이 다른 컨테이너로 전달되지 않는다는 것이다. 한편, 컨테이너는 실행 중이므로 애플리케이션의 상태 변경이 가능하다.

요약하자면 이미지는 애플리케이션과 실행 환경을 정의하고, 컨테이너는 이미지를 인스턴스화하여 애플리케이션을 실행 및 관리한다. 이미지는 가상 실행 환경을 정의한 것, 컨테이너는 실행하고 있는 가상 실행 환경이다.

Docker Container VS Virtual Machine

여기서 의문이 들 수 있다. 도커 컨테이너는 가상 실행 환경인데, 그럼 도커는 가상 머신인가? 도커 컨테이너와 가상 머신 모두 애플리케이션을 격리된 가상 환경에서 실행할 수 있도록 도와주는 기술이지만 차이점이 존재한다.

Virtual Machine

가상 머신은 호스트 운영체제 위에서 완전한 운영체제를 에뮬레이트하는 방식으로 동작한다. 즉, 하드웨어 단계에서의 가상화를 통해 완전한 운영체제를 가상으로 실행한다. 각 가상 머신은 독립적인 운영체제, 커널, 파일 시스템 등을 가지고 있으며, 가상화된 하드웨어 자원을 사용한다. 이는 호스트 운영체제 위에서 게스트 운영체제를 실행하는 것이기 때문에 상대적으로 무겁고 느린 성능을 가지고 있다

Docker Container

한편, 도커 컨테이너는 호스트 운영체제의 커널을 공유하면서 애플리케이션 단계에서의 가상화를 통해 격리된 환경에서 애플리케이션을 실행한다. 그래서 가상 머신보다 훨씬 가볍고 빠르게 실행되며, 더 빠르게 배포 및 확장할 수 있다.

Amazon ECR (Elastic Container Registry)

컨테이너 이미지를 레지스트리에 저장하는 이유

• 이미지 공유
  • 여러 개발자가 동일한 이미지를 사용해야 하는 경우가 많은데, 레지스트로리르 통해 이미지를 공유할 수 있다. 여러 사용자가 동일한 이미지를 가져와 사용하 룻 있으며, 이는 개발 및 배포 과정을 효율적으로 만든다.
• 이미지 버전 관리
  • 레지스트리는 이미지의 버전을 관리하고 업데이트할 수 있다.
  • 새로운 버전이 나오면 이전 버전과 비교하여 변경 사항을 파악하고 필요에 따라 업데이트할 수 있다.
• 보안
  • 레지스트리를 사용하면 이미지를 안전하게 저장하고 액세스 권한을 관리할 수 있다.
  • 암호화된 연결을 통해 이미지를 전송하고, 접근 제어 정책을 설정함으로써 민감한 이미지에 대한 접근을 제한할 수 있다.
• 배포
  • 레지스트리는 컨테이너 이미지를 저장하고 배포하는 중앙 집중식 저장소로 기능을 한다.
  • 애플리케이션을 개발한 후에는 해당 애플리케이션을 이미지로 빌드하여 레지스토리에 업로드한다. 이렇게 하면 어디서든 이 이미지를 가져와 실행할 수 있게 된다.
  • 즉, 클러스터, 호스트 또는 개발 환경에서 해당 이미지를 사용하여 애플리케이션을 실행할 수 있다.

ECR

ECR는 AWS에서 제공하는 완전관리형 도커 컨테이너 이미지 저장소 서비스이다. ECR를 사용하면 다음과 같은 기능을 사용할 수 있다.

• 이미지 저장
  • 도커 이미지, Open Container Initiative (OCI) 이미지 및 OCI 호환 아티팩트를 리포지토리에 저장 가능
• 정책 관리
  • AWS IAM을 통해 리포지토리 정책을 정의하고, 리포지토리 및 리포지토리 내 콘텐츠에 대한 접근 제어 및 권한 관리가 가능하다
• 이미지 사용
  • Amazon ECS 태스크 정의 및 Amazon EKS 포드 사양에서 이미지 사용 가능

Amazon EKS (Elastic Kubernetes Service)

Kubernetes

Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장, 그리고 관리를 자동화하기 위한 오픈 소스 플랫폼이다. 이를 통해 개발자는 애플리케이션을 클라우드 환경에서 쉽게 배포하고 관리할 수 있다. Kubernetes는 컨테이너 오케스트레이션 기능을 제공하여 애플리케이션을 여러 호스트에서 실행하고, 스케일링, 로드 밸런싱, 자동 복구 등을 수행한다. 즉, kubernetes는 컨테이너로 이루어진 워크로드를 자동화하거나 관리하기 위한 기술이다. 예시를 들면 내가 만든 웹 앱을 Kubernetes로 배포하면, 자동으로 여러 대의 서버에 분산되어 실행되며, 사용자가 증가하면 자동으로 서버를 늘릴 수 있다.

특징

1. 스펙 (Spec) VS 상태 (Status)
   • 상태: 현재 상태(current state)를 나타낸 것
   • 스펙: 원하는 상태(desired state)를 명시한 것
2. 명령형 접근법 VS 선언형 접근법
   • 명령형 접근법: "A에다가 +a를 해줘"
   • 선언형 접근 법: “내가 원하는 건 B야.” -> Kubernetes는 스펙에 적힌 상태를 만들어준다
3. 컨트롤 플레인
   • Kubernetes는 스펙에 평시된 '원하는 상태'와 '현 상태'를 일치시키려고 한다. 그러기 위해 Kubernetes는 현재의 상태와 원하는 상태를 비교한다. 만약 둘이 일치하지 않으면 컨트롤 플레인이 이 상황을 해결한다.
   • 컨트롤 플레인은 현재의 상태와 원하는 상태가 일치할 때까지 현재 상태 수정 및 원하는 상태와의 비교를 반복한다.
   • 한마디로 컨트롤 플레인은 클러스터의 상태를 추적하고 원하는 상태를 유지하기 위해 계속해서 작업을 수행합니다.

     

Pod

Pod는 Kubernetes의 기본 실행 단위로, 한 개 이상의 컨테이너로 구성된 그룹이다. 이 그룹 안의 컨테이너들은 같은 호스트에서 실행되며, 네트워크와 스토리지, 리소스 등을 공유한다. Pod 안에 있는 컨테이너들은 보통 서로 연관된 역할을 수행하거나 함께 동작해야 할 때 함께 그룹화된다. 예를 들어 웹 서버와 데이터베이스를 함께 실행하는 경우 각각을 담은 컨테니어들을 하나의 Pod로 묶어서 kubernetes에서 관리할 수 있다. 이렇게 함께 실행되는 서비스는 하나의 pod로 그룹화하면 관리가 간편해지고 유지보수가 쉬워진다.

Kubernetes 아키텍쳐

Kubernetes는 Master Node와 Worker Node로 구성된다.

마스터 노드는 Kubernetes 클러스터를 제어하고 관리하는 중앙 관리자이다. 이 노드에는 다양한 컨트롤 플레인 구성 요소가 있다. 이 구성 요소는 API 서버, 스케줄러 및 컨트롤러 매니저로 구성되어 있다.

• API 서버는 클러스터의 상태를 확인하고 변경하는 데 사용되며
• 스케줄러는 파드를 노드에 할당하여 실행 위치를 결정한다.
• 컨트롤러 매니저는 클러스터 상태를 확인하고 원하는 상태를 유지하기 위해 작업을 수행한다.

워커 노드는 실제로 애플리케이션을 실행하는 데 사용된다. 각 워커 노드에는 파드가 실행되는 공간인 런타임 환경이 있다.

간단히 말해, 마스터 노드는 클러스터를 관리하고 지시하는 역할을 하고, 워커 노드는 실제 애플리케이션을 실행하고 관리하는 역할을 한다.

EKS

EKS는 AWS에서 제공하는 관리형 Kubernetes 서비스이다.

• 서비스 통합
  • EKS는 다른 AWS 서비스와 통합되어, 컨테이너화된 애플리케이션을 배하고 관리하기 위한 포괄적인 플랫폼을 제공 가능
• 규모 조정
  • EKS는 애플리케이션의 작동량이 증가 또는 감소할 때 클러스터 크기를 자동으로 조정해준다. 이와 같은 수평 pod 자동 규모 조정은 CPU 사용량 또는 사용자가 지정한 기타 지표를 기반으로 이루어진다.
  • 한편, 전체 워크로드 수요를 기반으로 클러스터 규모를 자동적으로 조정가능하다.