#90DaysOfDevOps - The Big Picture: Containers - Day 42

큰 그림: 컨테이너

이제 다음 섹션을 시작하겠습니다. 이번 섹션에서는 컨테이너, 특히 컨테이너에 대해 더 많이 이해하기 위해 몇 가지 핵심 영역에 대해 살펴보는 Docker를 중점적으로 다룰 것입니다.

또한 이 섹션뿐만 아니라 챌린지 후반부의 다음 섹션에서도 사용할 수 있는 컨테이너를 만들기 위한 실습도 해보려고 합니다.

언제나 그렇듯이 이번 첫 번째 포스팅에서는 우리가 어떻게 여기까지 왔는지, 그리고 이 모든 것이 무엇을 의미하는지에 대한 큰 그림에 초점을 맞출 것입니다.

플랫폼 및 애플리케이션 개발의 역사 가상화 및 컨테이너화에 대해 이야기하고 싶습니다.

왜 애플리케이션을 실행하는 다른 방법일까요?

가장 먼저 살펴봐야 할 것은 소프트웨어나 애플리케이션을 실행하는 다른 방법이 필요한 이유입니다. 다양한 형태로 애플리케이션을 실행할 수 있기 때문입니다. 물리적 하드웨어에 운영 체제와 단일 애플리케이션이 배포된 애플리케이션을 볼 수도 있고, 가상 머신 또는 클라우드 기반 IaaS 인스턴스가 애플리케이션을 실행한 다음 다시 가상 머신의 데이터베이스에 통합되거나 퍼블릭 클라우드의 PaaS 제품으로 통합되는 것을 볼 수도 있습니다. 또는 애플리케이션이 컨테이너에서 실행되는 것을 볼 수도 있습니다.

위의 옵션 중 어느 것도 틀린 것도, 옳은 것도 아니지만 각 옵션이 존재해야 하는 이유가 있으며, 저는 이 중 어느 것도 사라지지 않을 것이라고 굳게 믿습니다. 컨테이너와 가상 머신을 비교하는 콘텐츠를 많이 봤는데, 이는 사과와 배를 비교하는 것과 같이 둘 다 과일(애플리케이션을 실행하는 방법)이지만 같은 과일이 아니기 때문에 논쟁을 해서는 안 됩니다.

또한 애플리케이션을 개발 중이라면 나중에 이러한 영역 중 일부를 다루겠지만 효율성, 속도 및 크기에 관한 것이므로 컨테이너에 기대야 한다고 말씀드리고 싶습니다. 하지만 여기에는 대가가 따르는데, 컨테이너에 대해 전혀 모른다면 그 이유를 이해하고 그 사고방식에 익숙해지려면 학습 곡선을 밟아야 할 것입니다. 애플리케이션을 특정 방식으로 개발했거나 그린필드 환경이 아니라면 컨테이너를 고려하기 전에 해결해야 할 문제가 더 많을 수 있습니다.

특정 소프트웨어를 다운로드할 때 사용할 수 있는 운영 체제가 다양하기 때문에 선택의 폭이 넓어집니다. 그리고 애플리케이션을 설치하기 위해 수행해야 하는 작업에 대한 구체적인 지침도 있습니다.

최근에는 예전에는 전체 서버 OS, 가상 머신, 물리적 또는 클라우드 인스턴스가 필요했던 애플리케이션이 이제 컨테이너 기반 버전의 소프트웨어를 출시하는 경우가 점점 더 많아지고 있습니다. 이는 애플리케이션 개발자에게만 초점을 맞추는 것이 아니라 모든 사람에게 컨테이너와 쿠버네티스의 세계를 열어준다는 점에서 흥미롭습니다.

앞서 말씀드렸듯이, 저는 컨테이너가 정답이라고 주장하지는 않겠습니다. 하지만 애플리케이션을 배포할 때 고려해야 할 또 다른 옵션이 컨테이너라는 점을 말씀드리고 싶습니다.

최근 10년 동안, 특히 지난 5년간 컨테이너 기술이 인기를 얻은 이유는 무엇일까요? 이미 수십 년 동안 컨테이너 기술이 존재해 왔습니다. 이 문제는 컨테이너와 이미지라는 용어를 두고, 소프트웨어 배포 방식의 도전 과제로 귀결됩니다. 만약 단순히 컨테이너 기술만을 가지고 있다면, 여전히 소프트웨어 관리에 있어서 겪었던 여러 문제들이 계속 발생할 것입니다.

docker를 도구로 생각하면, docker가 성공할 수 있었던 이유는 쉽게 찾고 사용할 수 있는 이미지 에코시스템 때문입니다. 시스템에 설치하고 실행하는 것이 간단합니다. 그중 가장 중요한 부분은 소프트웨어에서 직면하는 다양한 과제에 대한 전체 공간의 일관성입니다. MongoDB든 nodeJS든 상관없이 두 가지를 모두 실행하는 프로세스는 동일합니다. 중단하는 과정도 마찬가지입니다. 이러한 모든 문제는 여전히 존재하겠지만, 좋은 점은 좋은 컨테이너와 이미지 기술을 함께 사용하면 이러한 다양한 문제를 모두 해결하는 데 도움이 되는 단일 도구 세트를 갖게 된다는 것입니다. 이러한 문제 중 일부는 다음과 같습니다:

먼저 인터넷에서 소프트웨어를 찾아야 합니다.
그런 다음, 이 소프트웨어를 다운로드해야 합니다.
소스를 신뢰할 수 있는가?
라이선스가 필요한가요? 어떤 라이선스가 필요한가요?
다른 플랫폼과 호환되는가?
패키지는 무엇인가요? 바이너리인가요? 실행 파일인가요? 패키지 관리자?
소프트웨어를 어떻게 구성하나요?
종속성은 무엇인가요? 전체 다운로드에 포함되어 있나요, 아니면 추가로 필요한가요?
종속성의 종속성?
애플리케이션을 어떻게 시작하나요?
애플리케이션을 어떻게 중지하나요?
자동으로 다시 시작되나요?
부팅 시 시작되나요?
리소스 충돌?
충돌하는 라이브러리?
포트 충돌
소프트웨어 보안?
소프트웨어 업데이트?
소프트웨어를 제거하려면 어떻게 해야 하나요?

위의 내용을 소프트웨어의 복잡성 중 컨테이너와 이미지가 도움이 되는 세 가지 영역으로 나눌 수 있습니다.

Distribution	Installation	Operation
Find	Install	Start
Download	Configuration	Security
License	Uninstall	Ports
Package	Dependencies	Resource Conflicts
Trust	Platform	Auto-Restart
Find	Libraries	Updates

컨테이너와 이미지는 다른 소프트웨어와 애플리케이션에서 겪을 수 있는 이러한 문제 중 일부를 제거하는 데 도움이 될 것입니다.

높은 수준에서 설치와 운영을 동일한 목록으로 옮길 수 있으며, 이미지는 배포 관점에서, 컨테이너는 설치와 운영에 도움이 될 것입니다.

좋아요, 멋지고 흥미진진하게 들리겠지만 컨테이너가 무엇인지 이해할 필요가 있고 이제 이미지를 언급했으니 다음에는 그 부분을 다루겠습니다.

소프트웨어 개발용 컨테이너에 대해 이야기할 때 많이 보셨을 또 다른 것은 선적 컨테이너와 함께 사용되는 비유입니다. 선적 컨테이너는 대형 선박을 사용하여 바다를 가로질러 다양한 물품을 운송하는 데 사용됩니다.

이것이 컨테이너라는 주제와 어떤 관련이 있을까요? 소프트웨어 개발자가 작성하는 코드를 생각해 보세요. 특정 코드를 한 컴퓨터에서 다른 컴퓨터로 어떻게 전송할 수 있을까요?

앞서 소프트웨어 배포, 설치 및 운영에 대해 다룬 내용을 이제 환경 비주얼로 구축하기 시작하면 다음과 같습니다. 여러 애플리케이션을 실행할 하드웨어와 운영 체제가 있습니다. 예를 들어 nodejs에는 특정 종속성이 있고 특정 라이브러리가 필요합니다. 그런 다음 MySQL을 설치하려면 필요한 라이브러리와 종속성이 필요합니다. 각 소프트웨어 애플리케이션에는 해당 라이브러리와 종속성이 있습니다. 운이 좋아서 특정 라이브러리와 종속성이 충돌하여 문제를 일으키는 애플리케이션 간에 충돌이 발생하지 않을 수도 있지만, 애플리케이션이 많을수록 충돌의 가능성이나 위험은 높아집니다. 그러나 소프트웨어 애플리케이션을 모두 수정한 후 업데이트하면 이러한 충돌이 발생할 수도 있습니다.

컨테이너는 이 문제를 해결하는 데 도움이 될 수 있습니다. 컨테이너는 애플리케이션을 구축하고, 애플리케이션을 배송하고, 이러한 애플리케이션을 독립적으로 쉽게 배포하고 확장할 수 있도록 도와줍니다. 아키텍처를 살펴보면 하드웨어와 운영체제가 있고 그 위에 나중에 다룰 docker(docker)와 같은 컨테이너 엔진이 있습니다. 컨테이너 엔진 소프트웨어는 라이브러리와 종속성을 함께 패키징하는 컨테이너를 생성하는 데 도움이 되므로 라이브러리와 종속성이 컨테이너 패키지의 일부로 제공되므로 라이브러리와 종속성에 대한 걱정 없이 이 컨테이너를 한 시스템에서 다른 시스템으로 원활하게 이동할 수 있으므로 이 컨테이너는 애플리케이션이 실행하는 데 필요한 기본 종속성에 대한 걱정 없이 시스템 간에 이동이 가능합니다. 애플리케이션이 실행하는 데 필요한 모든 것이 컨테이너로 패키징되어 있기 때문에 컨테이너로 패키징되어 있기 때문입니다.

컨테이너의 장점

컨테이너는 컨테이너 내의 모든 종속성을 패키징하고 격리할 수 있습니다.
컨테이너를 쉽게 관리할 수 있습니다.
한 시스템에서 다른 시스템으로 이동할 수 있습니다.
컨테이너는 소프트웨어를 패키징하는 데 도움이 되며 중복 작업 없이 쉽게 배포할 수 있습니다.
컨테이너는 쉽게 확장할 수 있습니다.

컨테이너를 사용하면 독립적인 컨테이너를 확장하고 로드 밸런서를 사용할 수 있습니다. 또는 트래픽을 분할하는 데 도움이 되는 서비스를 사용하여 애플리케이션을 수평적으로 확장할 수 있습니다. 컨테이너는 애플리케이션 관리 방식에 있어 많은 유연성과 편의성을 제공합니다.

컨테이너란 무엇인가요?

컴퓨터에서 애플리케이션을 실행할 때 이 글을 읽는 데 사용하고 있는 웹 브라우저나 VScode가 컨테이너일 수 있습니다. 해당 애플리케이션은 프로세스로 실행되거나 프로세스라고 하는 것으로 알려져 있습니다. 노트북이나 시스템에서는 여러 개의 애플리케이션 또는 프로세스를 실행하는 경향이 있습니다. 새 애플리케이션을 열거나 애플리케이션 아이콘을 클릭하면 이 애플리케이션은 우리가 실행하려는 애플리케이션이며, 때로는 이 애플리케이션이 백그라운드에서 실행하려는 서비스일 수도 있으며, 운영 체제는 백그라운드에서 실행되는 서비스로 가득 차 있어 시스템에서 얻을 수 있는 사용자 경험을 제공합니다.

이 애플리케이션 아이콘은 파일 시스템 어딘가에 있는 실행 파일에 대한 링크를 나타내며, 운영 체제는 해당 실행 파일을 메모리에 로드합니다. 흥미롭게도 프로세스에 대해 이야기할 때 이 실행 파일을 이미지라고 부르기도 합니다.

컨테이너는 프로세스로, 컨테이너는 코드와 모든 종속성을 패키징하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 빠르고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위입니다.

컨테이너화된 소프트웨어는 인프라에 관계없이 항상 동일하게 실행됩니다. 컨테이너는 소프트웨어를 환경으로부터 분리하여 개발 환경과 스테이징 환경 간의 차이에도 불구하고 소프트웨어가 균일하게 작동하도록 보장합니다.

지난 섹션에서 컨테이너와 이미지의 결합이 어떻게 그리고 왜 우리 에코시스템에서 컨테이너가 인기를 얻게 되었는지에 관해 이미지를 언급했습니다.

이미지란 무엇인가요?

컨테이너 이미지는 경량의 독립형 실행형 소프트웨어 패키지입니다.

자료

Day 43에서 봐요!