Please enable JavaScript.

Coggle requires JavaScript to display documents.

Docker를 활용한 서버 애플리케이션 배포 - Coggle Diagram

- - - - Docker란?
        
        애플리케이션과 그 종속성을 하나의 표준화된 단위로 패키징하여, 어디에서나 일관되게 실행할 수 있도록 지원하는
        컨테이너 기반의 오픈소스 플랫폼
        
        기존에는 개발-운영 환경이 다를 경우 애플리케이션이 정상적으로 동작하지 않는 경우가 빈번.
        "개발 환경에서는 잘 돌아갔는데, 운영 환경에서는 동작하지 않는다"는 문제를 해결하기 위해 탄생
        
        개발부터 배포까지의 프로세스를 간소화 하고, 애플리케이션의 이식성과 확장성을 향상
      - 구성요소
        
        Docker Engine: 도커의 핵심 요소로, 컨테이너를 생성하고 관리하는 주체.
        자체로도 컨테이너를 제어하는 것이 가능하며, 다양한 Linux 운영체제 및 Windows 서버에서 컨테이너를 지원하는 클라이언트 서버 애플리케이션의 역할을 함.
        
        Docker Daemon: 도커 엔진의 핵심. 클라이언트로부터 명령을 받아, 컨테이너의 생성, 실행, 관리를 담당. 또한, 도커 이미지를 저장하고 컨테이너 간의 통신을 관리.
        
        Docker Host: 도커가 띄워져 있는 서버, 즉 도커 데몬이 실행되고 있는 시스템.
        호스트 운영체제, 네트워크와 상호 작용을 하며, 컨테이너가 실행되는 환경을 제공한다.
        
        Docker Client: 도커 엔진과 상호작용하는 커맨드 라인 인터페이스(CLI)로, 도커 데몬과 통신하여 컨테이너를 생성하고 관리.
        docker build, docker run, docker pull 등의 명령어를 실행해, 도커 이미지를 빌드하고, 컨테이너를 생성하며, 도커 레지스트리에서 이미지를 다운로드 함.
        
        Docker Registry: 외부(remote) 이미지 저장소.
        다른 사용자들이 공유한 이미지를 로컬 도커 호스트에서 pull 받아 사용할 수 있음.
        
        저장소
        
        public 저장소: 공개 이미지 저장소.
        손쉽게 이미지를 pull 받아서 컨테이너에 적용할 수 있다.
        ex) Docker Hub, QUAY
        
        private 저장소: 비공개적으로 구축 가능한 격리된 저장소.
        AWS ECR, Docker Registry를 직접 띄워서 비공개로 사용하는 방법 등이 존재
      - Docker 구조
        
        Docker 엔진
        
        OS
        
        Infrastructure(하드웨어)
        
        bins/libs
        
        bins/libs
        
        App 1
        
        bins/libs
        
        App 3
        
        App 2
      - 핵심 개념
        
        Docker Image
        
        도커 컨테이너를 생성하기 위한 읽기 전용 템플릿으로,
        애플리케이션을 실행하는데 필요한 모든 파일과 설정을 포함
        
        여러 계층으로 구성된 바이너리 파일
        
        변경이 불가능하며, 수정을 원할 경우 새로운 이미지를 생성해야 한다
        
        도커 이미지를 실행하면 해당 이미지의 설정값을 가진 컨테이너가 생성됨
        
        Docker Container
        
        VM과의 차이점
        
        Hypervisor 없이 호스트 OS의 커널을 다른 컨테이너와 공유
        
        장점: VM 보다 가볍고 빠르게 동작 가능
        
        단점: 보안/리소스분리 측면에서 추가적인 관리 필요
        
        하드웨어 가상화를 제공하는 VM과는 달리, 도커 컨테이너는 사용자 공간을 추상화 함으로써 경량의 운영체제 수준의 가상화를 제공
        
        도커 컨테이너의 장점
        
        적은 성능 손실
        가상화된 공간을 생성하기 위해 Linux 자체 기능인 chroot, namespace, cgroup등을 사용하여 성능의 손실이 거의 없음
        
        chroot: 시스템의 파일 시스템을 제한, 자신에게 할당된 디렉토리만 접근 가능하도록 격리.
        
        namespace: 프로세스 격리 기술. PID,사용자, 네트워크 등의 자원을 분리하여 각 프로세스에 독립적인 환경을 제공.
        오버헤드가 적고, 가상 머신에 비해 효율적.
        
        cgroup: 시스템 자원을 할당하고 제어하는 기술. CPU, I/O, 메모리 등의 자원을 제한할 수 있음.
        자원 사용을 최적화하고, 성능 저하 없이 효율적인 컨테이너 실행을 가능하게 함.
        
        작은 배포 이미지 용량
        컨테이너에 필요한 커널을 공유하고, 컨테이너 내부에는 앱 구동에 필요한 라이브러리 및 실행 파일만 존재하기 때문에, 가상 머신에 비해 컨테이너 배포 이미지의 용량이 대폭 감소
        
        빠른 배포
        가벼운 배포 이미지 용량 덕분에 배포 시간 또한 빠르며, 가상화된 공간을 사용할 때의 성능 손실도 거의 없음
        
        주의 및 고려 사항
        
        보안 및 리소스 격리
        namespcae와 cgroup 활용한 컨테이너 간의 격리는 VM의 Hypervisor 수준의 격리보다는 약할 수 있어, 보안이 중요한 환경에서는 추가적인 보안조치 필요
        
        운영 체제 호환성 - 크로스 OS 실행 제한
        도커는 호스트 OS의 커널을 공유하므로, 원칙적으로 동일한 OS 계열에서만 컨테이너를 실행.
        ex) 리눅스 호스트에서는 리눅스 컨테이너를, 윈도우 호스트에서는 윈도우 컨테이너를 실행.
        
        Windows에서는 WSL2 등을 이용해 Linux 컨테이너를 실행할 수 있지만, Linux에서 Windows 컨테이너를 실행하려면 VM을 활용하는 등 번거로운 과정을 거쳐야 한다
        
        멀티 OS 불가능
        도커는 호스트 OS의 커널을 공우하는 컨테이너 방식이므로, 다른 운영체제를 동시에 실행하는 것이 불가능. 즉, Linux 기반의 도커에서는 Windows 애플리케이션을 직접 실행할 수 없는 제한 있음.
        
        코드와 모든 종속성을 패키지화 하여 애플리케이션이 한 환경에서 다른 환경으로 빠르고 안정적으로 실행될 수 있게 해주는 표준 소프트웨어 장치
        
        생성: 도커 이미지로부터 생성되며, 영구적이지 않음.
        호스트/다른 컨테이너와 격리된 시스템 자원 및 네트워크를 사용할 수 있는 독립된 공간(프로세스)
        
        이미지를 통해 컨테이너A와 컨테이너B를 생성 후 컨테이너A를 수정해도 이미지와 컨테이너B는 영향을 받지 않는다
        
        이미지 : 컨테이너 = 1 : N
      - On-Premise 보완
        
        확장성 및 유연성
        도커는 트래픽이 증가할 때 컨테이너를 빠르게 추가할 수 있어 시스템 확장이 용이함
        
        낮은 초기 비용
        기존 서버 자원으로 가상 환경을 구축할 수 있어 상대적으로 초기 비용이 낮음. 물리적인 서버나 고비용 하드웨어를 구매할 필요 X.
        
        간편한 유지보수
        자동화된 배포 및 관리도구가 있어, 서버의 유지보수 및 소프트웨어 업데이트가 간편하고 효율적
        
        자원 효율성
        트래픽이 적을 때는 리소스를 절약하고, 필요 시 필요한 만큼만 자원 확장이 가능
        
        높은 이식성
        다양한 환경에서 동일하게 실행됨. 따라서, 개발/배포/테스트 등에서 애플리케이션의 이식성이 뛰어남
      - CI/CD 통합
        
        Docker는 CI/CD 파이프라인의 핵심 구성 요소로,
        자동화된 빌드 및 배포 과정을 간소화하고, 효율성을 높이며, 일관성을 제공.
        빠른 소프트웨어 배포 및 배포 후 발생할 수 있는 문제의 조기 발견이 가능.
        
        과정
        
        코드 푸시
        
        자동 빌드
        
        자동 테스트
        
        배포
        
        1 more item...
        
        빌드된 이미지를 이용해 코드가 정상적으로 작동하는지 테스트
        
        CI/CD툴(Jenkins, Github Actions 등)은 코드 변경을 감지, 도커에 이미지를 자동 빌드
        
        코드 저장소에 변경 사항 푸시
        
        장점
        
        일관성: 항상 동일한 환경에서 빌드 및 배포 가능
        
        자동화: 반복적인 배포 작업의 자동화로 사람의 개입 없이 신속한 코드 변경 적용
        
        효율성: CI/CD 파이프라인을 통한 빠른 피드백. 안정적인 배포.
    - - 기존의 가상화 기술.
        하이퍼바이저(Hypervisor)를 이용하여 여러 개의 운영체제를 하나의 호스트에 생성하여 사용하는 방식.
        각 VM은 자체 커널과 OS를 가지며, 서로 완전히 독립적인 한경을 제공.
        
        장점
        
        보안적 측면
        컨테이너 기반의 가상화보다 높은 격리 레벨 지원
        
        멀티 OS
        OS의 가상화 커널을 공유하지 않아, 서로 다른 운영체제를 실행할 수 있음
        ex) Linux 위에 Windows
        
        완벽한 운영체제 생성 가능
        
        단점
        
        큰 배포 이미지 용량
        게스트 OS를 사용하기 위한 라이브러리, 커널 등을 전부 포함하므로, 가상 머신을 배포하기 위한 이미지로 만들었을 때의 이미지 크기가 커짐. 수 기가바이트에 달할 수 있으며, 이로 인해 가상머신 이미지를 애플리케이션으로 배포하기에는 부담
        
        성능 손실 가능성
        시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 반드시 하이퍼바이저를 거쳐야 하므로 일반 호스트에 비해 성능상의 손실이 발생할 수 있음
        
        Hypervisor: 믈리적 서버 위에서 여러 개의 가상 머신을 관리하며, 각 가상머신이 독립적인 운영체제를 실행할 수 있도록 돕는 소프트웨어나 펌웨어
      - VM 구조
        
        Hypervisor
        
        Host OS
        
        Infrastructure(하드웨어)
        
        Guest OS
        
        Guest OS
        
        bins/libs
        
        App 3
        
        Guest OS
        
        bins/libs
        
        App 1
        
        bins/libs
        
        App 2
  - - - 높은 초기 비용
        서버 구매, 네트워크 구축 등에 큰 비용 발생
      - 확장성 부족
        트래픽이 증가할 때, 빠르게 서버를 추가하는 것이 어려움
      - 유지보수 부담
        서버의 하드웨어 장애 복구, 소프트웨어 업데이트 등의 직접 관리 필요
      - 비효율적인 자원 활용
        트래픽이 적을 때도 유휴 서버가 그대로 유지되어 낭비가 발생
      - 이식성 부족
        특정 환경에서만 애플리케이션이 동작하는 경우가 많음