Written by xi-jjun
on 

Container 란?

Container 공부 시작!

배포를 할 때에 AWS ECS서비스를 자주 이용하는 편인데, 이유는 로컬에서 매번 docker로 container환경에서 빌드를 하고 있기 때문이다. 평소 사용하는 기술에 대한 deep dive를 하기 위해서 시작하는 바이다.


개요

container 환경에서 어플리케이션을 실행하고 있으나, 관련 지식이 부족한 듯하여 container deep dive가 필요하다고 생각이 됐고, 회사 내에서 필요에 의해 특정 서비스의 로컬 개발환경을 container로 구성하려고 하기에 관련된 리서치를 하기 위한 목적이다.

docker roadmap을 따라서 하나씩 정리할 예정이다.


컨테이너란?

소프트웨어 공학에서 컨테이너화란 SW 유형이나 vendor 혹은 클라우드 환경인지도 상관없이 container 라고 불리는 독립된 유저 공간에서 실행될 수 있도록 여러 네트워크 리소스에 대한 OS level에서의 가상화 또는 application level에서의 가상화이다. - 출처: wikipedia

컨테이너화에 대한 정의를 위키를 통해 알아봤는데, container에 대해서는 아래와 같이 설명하고 있다.

container는 어플리케이션을 둘러싸고 있으며, 다른 환경에 영향받지 않고 독립적으로 유지될 수 있는 이식성 높은 클라우드 또는 비클라우드 환경이다. - 출처: wikipedia

containerization, container 둘 다 중요한 부분은, “다른 환경에 영향받지 않는 독립된 환경” 이라는 말이 들어가는데 이 점이 바로 핵심이라고 생각한다.

음.. 그래도 조금 더 와닿는 설명을 아틀라시안 블로그에서 찾았다.

소프트웨어 실행에 필요한 모든 의존성들을 포함하고 있는 가벼운 소프트웨어 패키지를 뜻한다. - 출처 - atlassian 블로그

다른 환경에 영향을 받지 않으면서 우리의 어플리케이션을 실행하기 위해 ‘실행에 필요한 모든 의존성을 갖고있는 소프트웨어 패키지’라는 설명까지 추가되니, container에 대해 더욱 명확히 알 수 있는 느낌이 든다.


왜 독립된 환경이 필요할까? - 개인적인 경험

그렇다면 왜 우리는 다른 환경에 영향받지 않는 독립된 환경이 필요했던 것일까?

사실 이 질문에 대한 대답은 굳이 검색을 하지 않더라도, 개발을 해본 사람들이라면 어느정도 답변을 할 수 있으리라 생각한다. 나도 이러한 환경이 필요했을 때가 여럿 있었는데, MySQL 로컬 개발환경 셋팅 때가 가장 절실했고 이 때 가장 많이 컨테이너 덕을 본 것 같다.

현재 내 컴퓨터에는 사이드 프로젝트에 의해 MySQL 서버 2개가 필요했다. 하나의 로컬 MySQL서버에 database를 나눠서 진행해도 상관없으나, 기본적으로 모든 곳에서 동일하게 셋팅되어야할 개발환경인데, 어떤 사람은 database만 나눠서 셋팅하고, 어떤 사람은 새로 MySQL 설치해서 사용하고… 하는 방식이 좋아보이지는 않았아서 3307, 3308, 3309… 등 port 번호를 바꿔가며 여러개의 MySQL서버 container 로컬에서 띄워서 해결했었다.

잘못셋팅해도 그냥 container를 날리고 다시 이미지를 빌드하여 container로 띄우면 초기화도 쉽다. 평소에 쓰면서도 아주 강력한 기능인 것이 느껴졌는데, 과연 내가 이러한 기술에 대해서는 잘 모른다는게 느껴져서… 깊게 공부할 필요가 있다고 느껴졌던 것이다.


Virtual Machine vs Container

그렇다면 독립된 환경을 제공할 수 있는게 오직 container 하나일까?라는 물음에는 ‘그렇지 않다’이다. 아직까지도 사랑받고 잘 사용되고 있는 Virtual Machine 또한 독립된 환경을 제공할 수 있는데, 이러한 점에서 Virtual Machine과 Container의 비교에 대한 이야기는 항상 가상화 관련된 글에서 나오는 것 같다.

Virtual Machine이란?

VM이란 컴퓨터 시스템의 가상화 또는 에뮬레이션이다. VM은 컴퓨터 구조에 기반하고 컴퓨터의 물리적인 기능들을 제공한다. 따라서 특수한 하드웨어, 소프트웨어 또는 2가지의 조합으로 구성된 케이스로 구현되기도 한다. - 출처 - wikipedis

container와 다른 부분이 있다면, VM은 ‘하드웨어’ 레벨까지의 독립된 환경을 구성할 수 있다는 점이다. 따라서 Hypervisor라는 하드웨어 에뮬레이터의 유무가 container와 VM을 구분짓는 가장 큰 요인이라 할 수 있을 것이다.

container_vs_vms


번외) 어떤 상황에서 무엇을 사용하면 좋을지?

redhat에서 가져온 내용이다.

container를 사용하면 좋을 상황

Virtual Machine을 사용하면 좋을 상황


Container를 사용하면 뭐가 좋을까?

아까 개인적인 경험을 통하여, ‘독립적인 환경’의 필요성에 대해 언급했는데, 그렇다면 그 외의 장점에는 뭐가 있을지 찾아보자. - 출처 - google cloud


책임의 분리

개발자는 어플리케이션 의존성 관리에만 집중이 가능하고, Devops와 같은 팀들은 소프트웨어 버전이나 배포관리 등에 온전히 집중할 수 있도록 해준다.

workload의 protablilty

container는 리눅스, 윈도우, Mac, 가상 시스템 등 어디서든 실행할 수 있다.

어플리케이션 분리

container는 OS level에서 CPU, disk, network 자원들을 가상화해주고, 다른 어플리케이션들과 논리적으로 격리된 OS를 개발자에게 보여준다.

VM에 비해 빠른 실행

container는 OS자체를 실행시킬 필요가 없어서, VM보다 더 가볍고 빠르게 실행될 수 있다.


Linux Container 역사

나는 container == docker 로만 이해하고 있었다. 그러나 좀 더 공부하게 되면서 생각보다 container의 역사는 오래됐음을 알게 됐는데, 필요한 부분만 짧게 요약해보도록 하겠다.

해당 글에 설명이 상세하게 잘 되어 있으니 참고하자.


1979년 UNIX V7

chroot system call이 소개됐던 시기. 각 프로세스별 파일 접근을 분리함으로써 Process 격리의 시작이 됨.

chroot 라는 리눅스 system call이 추가되었다는 부분에서 한번쯤 알아놓으면 좋을 것 같았다.

2000년 FreeBSD Jails

최초의 container 였다는 점에서… 선배님 대우 확실히 하기 위해 적어봤다.

2006년 Process Containers

Control Group(CGroup) 의 선조격 되는 기술이 나온 때이다. container의 리소스를 관리할 수 있도록 해주는 중요한 기술의 하나여서 눈여겨 보고 가자.

2008년 LXC

docker의 아버지..? 쯤 되어 보이는 linux container 기술의 등장. 초기 docker는 LXC를 잘 사용할 수 있도록 해주는 인터페이스였다.

2013년 Docker


docker container가 딱! 하고 나타난줄 알았는데, docker가 탄생하기까지 생각보다 꽤나 오랜 시간동안 컨테이너화의 역사가 있었다는 사실에 놀랐다. 이 기술을 정확히 이해하고 내 것으로 만들기 위해서는 꽤나 많은 노력이 필요할 듯 하다.


Next

이번에는 컨테이너가 무엇이고 어떤 장점을 가지며 VM과는 어떤 차이가 있는지, 그리고 그 발전의 역사에 대해 아주 조금 살펴보았다. 역사가 긴 만큼 알아야할 지식도 많음을 깨달았는데, 오늘 공부한 것을 토대로 어떤 것들을 알아야할지 정리해보자.

  1. linux
    1. Control Group
    2. namespaces
    3. file systems
  2. Docker

생각보다 모르고 있던 알아야할 개념들이 많다. 하나씩 보도록 하자…


references