Docker Container

Docker Compose VS Docker Swarm ?? docker compose -> 동일 호스트에서 두 개 이상의 컨테이너를 운영 docker swarm -> 여러 호스트에서 다수의 컨테이너들을 운영(orchestrate), 필요에 따라 컨테이너의 수를 늘이고 줄이는 auto-scaling 기능을 수행 구체적으로 docker swarm이 무슨 일을 하는 걸까? -> 컨테이너들을 cluster하고 schedule하여 전체 컨테이너 클러스터를 하나의 가상 단일 컨테이너로 관리하고, 각 컨테이너의 상태를 모니터링하여 컨테이너 수를 각 호스트에서 늘리거나 줄이며(auto-scaling) 운영하는 도구 But, 지금은 docker swarm 보다는 구글의 쿠버네티스가 더 많이 쓰인다고 한다. [ Swar..

Monolithic App VS Microservices 본격적으로 docker compose에 대해 설명하기에 앞서 Monolithic App과 Microservices 두 가지 소프트웨어 모델을 서로 비교해 보도록 하겠다. Monolithic App (모놀리식 애플리케이션) : 모든 기능이 단일 프로그램 안에 구현된 애플리케이션 모놀리식 애플리케이션의 특징은 다음과 같다. 비현실적, 비효율, 매우 낮은 생산성 app의 크기가 커지고, app의 일부분만 업데이트 해도 전체 app이 재배포 되어야 함 bug가 발생하면 전체 app에 영향을 미침 새로운 기술을 채택하기 어려움 ==> 통합된 구조로 인해 많은 단점을 갖고 있기 때문에 소프트웨어공학적으로 좋지 않은 모델이다. 이러한 단점을 해소시키기 위해 등..

컨테이너들은 다른 컨테이너의 OS와 별도의 자신만의 자원(DRAM 영역), CPU시간을 사용하도록 되어 있으며, 디스크와 같은 persistent storage를 사용하지 않고 기본적인 in-memory 파일시스템을 사용한다. 컨테이너가 run 명령에 의해 시작된 뒤에 우리가 작업을 하며 만들어지는 파일들은 우리에게 익숙한 persistent 장치(디스크)에 저장되는 것처럼 사용되지만 실제로는 in-memory 파일시스템에 쓰여지고 있는 것이기 때문에 컨테이너가 종료되면 같이 사라진다. 그래서 동일한 이미지로부터 컨테이너를 다시 만들어보면 이전에 저장했다고 생각한 데이터가 없게 된다. 컨테이너 볼륨 (Container volume) 이러한 단점을 해소하기 위해 제공되는 기능이 컨테이너 볼륨 (Contai..

Dockerfile(도커 파일)? -> 도커 이미지를 만들기 위해 실행되는 명령들을 모아 둔 텍스트 파일 앞에서 공부했던 도커 컨테이너 작업 과정은 image --run--> container --(exec)--> 컨테이너 내부로 들어옴 --(작업)--> exit --> commit --> 컨테이너 이미지 생성 의 순으로 이루어졌다. 이 명령들을 dockerfile에 기재하여 저장함으로써 컨테이너 이미지를 생성하는 일련의 과정을 자동화할 수 있다. ==> 명령어들을 하나하나 입력해가며 컨테이너를 수동으로 생성하는 방법 대신 dockerfile을 작성하고 build 커맨드만 사용하여 컨테이너를 생성함으로써 훨씬 간편하게 컨테이너 사용이 가능해진다. @@다시 한 번 정리하면 Dockerfile은 docker..

도커 (Docker) 앞서 설명한 컨테이너 엔진(Container engine)을 만든 대표적인 회사로서 우리가 일반적으로 말하는 도커(docker)는 docker 사의 컨테이너 엔진을 지칭하는 것이다. (=>컨테이너를 실행시키는 플랫폼) 컨테이너 엔진 (Container Engine)? -> '컨테이너' 라고 불리는 소프트웨어 패키지 들을 배포하기 위해 OS 레벨에서의 가상화를 제공해주는 서비스 플랫폼이라고 생각하면 되겠다. 우리는 텍스트파일 형식의 도커 파일을 빌드하여 컨테이너 이미지(Container Image)를 만들 수 있고, 컨테이너는 컨테이너 이미지를 통해 실행될 수 있다. 이 컨테이너 이미지를 Docker Hub로부터 pull 할 수도 있고, Docker Hub로 push할 수도 있다. D..

컨테이너화 (Containerized) 현재 전 지구적으로 서비스되는 소프트웨어들은 거의 100%가 모두 컨테이너화(Containerized) 되어 있는 프로세스가 실행 중에 있는 것이라고 봐도 무방하다. 소프트웨어의 개발 및 운영(DevOps)에 있어서 몇 가지 issues가 있었다. 개발(Dev) 환경과 운영(Ops) 환경의 불일치 가볍게 실행 가능한 SW 패키지의 필요성 기존의 가상 머신(Virtual Machine)은 Infrastructure 전체를 추상화한 것이었고, 같은 OS의 가상 머신들 간에도 app에 따라 다른 라이브러리와 의존성을 갖게 되었다. 가상 머신 이미지들은 너무 무겁고 메모리 사용량이 많았기 때문에 단위 시간 내에 많은 수의 프로세스 실행이 가능한 시스템의 필요성을 느끼게 되..