웹사이트 검색

LFCA: 컨테이너 사용의 기본 개념 알아보기 - 22부


시간이 지남에 따라 비즈니스 주기가 빨라지고 애플리케이션의 신속한 테스트 및 배포에 대한 수요가 증가함에 따라 조직은 빠르게 변화하는 비즈니스 환경을 따라잡기 위해 혁신을 강요받았습니다.

애플리케이션을 현대화하고 새로운 애플리케이션을 구축하여 민첩한 워크플로를 생성하려는 탐구에서 컨테이너 사용이라는 개념이 탄생했습니다. 컨테이너화 기술은 가상화만큼 오래되었습니다. 그러나 2013년에 Docker가 폭발적으로 등장하여 개발자와 기타 IT 전문가들 사이에서 열광적인 관심을 불러일으키기 전까지 컨테이너는 큰 관심을 불러일으키지 못했습니다.

현재 Google, Amazon, MicrosoftRed Hat과 같은 모든 거대 기술 기업에서는 몇 가지를 언급하고 있습니다. 대세에 올랐습니다.

왜 컨테이너인가?

개발자가 직면한 과제 중 하나는 소프트웨어 개발의 모든 단계에서 컴퓨팅 환경의 차이입니다. 소프트웨어 환경이 단계마다 다를 때 문제가 발생합니다.

예를 들어 애플리케이션은 Python 3.6 실행을 사용하여 테스트 환경에서 원활하게 실행될 수 있습니다. 그러나 Python 3.9를 실행하는 프로덕션 환경으로 포팅할 때 애플리케이션이 이상하게 동작하고 일부 오류를 반환하거나 완전히 충돌합니다.

컨테이너는 이러한 과제를 해결하고 개발자의 PC에서 프로덕션 환경에 이르기까지 소프트웨어 개발의 모든 단계에서 하나의 컴퓨팅 환경에서 다음 컴퓨팅 환경으로 이동할 때 애플리케이션이 안정적으로 실행되도록 보장하기 위해 등장했습니다. 그리고 이러한 불일치를 초래할 수 있는 것은 소프트웨어 환경뿐만 아니라 네트워크 토폴로지 및 보안 정책의 차이이기도 합니다.

컨테이너란 무엇입니까?

컨테이너는 애플리케이션이 하나의 컴퓨팅 환경에서 이식될 때 원활하게 실행될 수 있도록 모든 바이너리 코드, 라이브러리, 실행 파일, 종속성 및 구성 파일을 단일 패키지로 압축하는 격리된 소프트웨어 단위입니다. 다른 사람에게. 가볍고 쉽게 휴대할 수 있는 운영 체제 이미지가 함께 제공되지 않습니다.

컨테이너 이미지는 애플리케이션을 실행하는 데 필요한 모든 것을 번들로 묶는 독립형의 경량 실행 가능한 패키지입니다. 런타임 시 컨테이너 이미지는 컨테이너로 변환됩니다. 예를 들어 Docker의 경우 Docker 이미지는 Docker 엔진에서 실행될 때 Docker 컨테이너가 됩니다. Docker는 컨테이너화된 애플리케이션을 구축하는 데 사용되는 런타임 환경입니다.

컨테이너는 기본 운영 체제와 완전히 분리되어 실행되며 컨테이너화된 애플리케이션은 컴퓨팅 환경이나 인프라에 관계없이 항상 일관되게 실행됩니다. 개발자가 이 노트북을 사용하여 편안하게 애플리케이션을 개발하고 서버에 쉽게 배포할 수 있는 이유가 바로 이 때문입니다.

실행 중인 컨테이너의 일관성과 안정성 덕분에 개발자는 애플리케이션이 배포된 위치에 관계없이 예상대로 실행된다는 사실을 알고 안심할 수 있습니다.

컨테이너는 가상 머신과 어떻게 다릅니까?

컨테이너와 가상 머신의 공통점은 가상화된 환경에서 작동한다는 것입니다. 어떤 의미에서 컨테이너화는 가상화 기술의 한 형태입니다. 그러나 컨테이너는 여러 면에서 가상 머신과 다릅니다.

가상 머신

가상 인스턴스 또는 간단히 VM이라고도 하는 가상 머신은 물리적 서버나 PC를 에뮬레이션한 것입니다. 가상화는 가상 머신을 생성할 수 있게 해주는 기술입니다. 가상화의 개념은 1970년대 초로 거슬러 올라가며 1세대 클라우드 기술의 토대를 마련했습니다.

가상화에서는 베어메탈 서버나 컴퓨터 하드웨어 위에 추상화 계층이 생성됩니다. 이를 통해 단일 서버의 하드웨어 리소스를 여러 가상 머신에서 공유할 수 있습니다.

추상화 계층을 만드는 데 사용되는 소프트웨어를 하이퍼바이저라고 합니다. 하이퍼바이저는 실제 베어메탈 또는 컴퓨터 하드웨어에서 가상 머신과 게스트 OS를 추상화합니다. 따라서 가상 머신은 추상화 계층 덕분에 하드웨어 리소스를 사용할 수 있게 만드는 하이퍼바이저 위에 위치합니다.

가상 머신은 하이퍼바이저가 설치된 기본 운영 체제(호스트 OS)와 독립적인 완전한 운영 체제(게스트 OS)를 실행합니다. 그런 다음 게스트 OS는 라이브러리 및 바이너리와 함께 애플리케이션을 구축, 테스트 및 배포할 수 있는 플랫폼을 제공합니다.

하이퍼바이저에는 두 가지 유형이 있습니다.

유형 1 하이퍼바이저(베어메탈 하이퍼바이저)

하이퍼바이저는 물리적 서버나 기본 하드웨어에 직접 설치됩니다. 하이퍼바이저와 컴퓨터 하드웨어 사이에 운영 체제가 없으므로 태그 이름은 베어메탈 하이퍼바이저입니다. 리소스가 호스트 운영 체제와 공유되지 않기 때문에 탁월한 지원을 제공합니다.

효율성으로 인해 Type 1 하이퍼바이저는 주로 기업 환경에서 사용됩니다. 유형 1 하이퍼바이저 공급업체에는 VMware EsxiKVM이 포함됩니다.

유형 2 하이퍼바이저:

이는 호스팅된 하이퍼바이저로도 간주됩니다. 이는 호스트 운영 체제 위에 설치되며 기본 하드웨어 리소스를 호스트 OS와 공유합니다.

유형 2 하이퍼바이저는 소규모 컴퓨팅 환경에 이상적이며 주로 운영 체제 테스트 및 연구에 사용됩니다. 유형 2 하이퍼바이저 공급업체에는 Oracle VirtualBox 및 VMware Workstation Pro가 포함됩니다.

가상 머신의 단점

가상 머신은 크기가 크고(수 GB를 차지할 수 있음) 시작 및 중지 속도가 느리고 많은 시스템 리소스를 소모하여 제한된 리소스로 인해 중단 및 성능 저하를 초래하는 경향이 있습니다. 따라서 가상 머신은 부피가 큰 것으로 간주되며 높은 간접비와 관련됩니다.

컨테이너

가상 머신과 달리 컨테이너에는 하이퍼바이저가 필요하지 않습니다. 컨테이너는 물리적 서버와 운영 체제 위에 위치하며 라이브러리, 바이너리 등 OS와 동일한 커널을 공유합니다. 여러 컨테이너가 동일한 시스템에서 실행될 수 있으며, 각 컨테이너는 나머지에서 자체 애플리케이션 및 프로세스 세트를 실행합니다. 인기 있는 컨테이너 플랫폼으로는 Docker와 Podman이 있습니다.

가상 머신과 달리 컨테이너는 기본 운영 체제와 완전히 분리되어 실행됩니다. 컨테이너는 매우 가벼워서(단 몇 메가바이트) 공간을 덜 차지하고 리소스 친화적입니다. 시작 및 중지가 쉽고 가상 머신보다 더 많은 애플리케이션을 처리할 수 있습니다.

컨테이너 사용의 이점

컨테이너는 PC에서 온프레미스나 클라우드 등 프로덕션 환경으로 애플리케이션을 설계, 테스트 및 배포하는 편리한 방법을 제공합니다. 컨테이너화된 애플리케이션을 사용하면 얻을 수 있는 몇 가지 이점은 다음과 같습니다.

1. 더 큰 모듈성

컨테이너 이전에는 프런트엔드와 백엔드 구성 요소로 구성된 전체 애플리케이션을 단일 패키지로 묶는 구식 모놀리식 모델이 있었습니다. 컨테이너를 사용하면 애플리케이션을 서로 통신할 수 있는 여러 개별 구성 요소로 분할할 수 있습니다.

이러한 방식으로 개발 팀은 애플리케이션이 서로 상호 작용하는 방식에 대해 큰 수정이 이루어지지 않은 경우 애플리케이션의 다양한 부분에 대해 협업할 수 있습니다.

이것이 마이크로서비스의 개념의 기초입니다.

2. 생산성 향상

모듈성이 높을수록 개발자는 애플리케이션의 개별 구성 요소에 대해 작업하고 이전보다 훨씬 빠르게 오류를 디버그할 수 있으므로 생산성이 높아집니다.

3. 간접비 절감

가상 머신 및 기타 기존 컴퓨팅 환경과 비교할 때 컨테이너는 운영 체제를 포함하지 않기 때문에 더 적은 시스템 리소스를 사용합니다. 이는 애플리케이션을 구축하고 테스트하기 위해 고가의 서버를 조달하는 데 불필요한 지출을 방지합니다.

4. 휴대성 향상

컨테이너화된 애플리케이션은 설치 공간이 작기 때문에 여러 컴퓨팅 환경/운영 체제에 쉽게 배포됩니다.

5. 효율성 및 유연성 향상

컨테이너를 사용하면 애플리케이션을 빠르게 배포하고 확장할 수 있습니다. 또한 여러 소프트웨어 환경에 애플리케이션을 배포하는 데 꼭 필요한 유연성을 제공합니다.

컨테이너는 DevOps 팀에 어떤 이점을 제공합니까?

컨테이너는 DevOps에서 핵심적인 역할을 하며 컨테이너화된 애플리케이션이 없었다면 상황이 어땠을지 상상하기가 불가능합니다. 그렇다면 컨테이너는 무엇을 제공할까요?

첫째, 컨테이너는 마이크로서비스 아키텍처를 뒷받침하므로 전체 애플리케이션의 빌딩 블록을 독립적으로 개발, 배포 및 확장할 수 있습니다. 앞서 언급한 바와 같이 이는 협업을 강화하고 애플리케이션의 신속한 배포를 가능하게 합니다.

또한 컨테이너화는 애플리케이션 구축을 위한 제어되고 일관된 환경을 제공함으로써 CI/CD 파이프라인을 촉진하는 데 중요한 역할을 합니다. 더 빠르고 쉬운 배포를 위해 모든 라이브러리와 종속성이 코드와 함께 하나의 단일 단위로 패키징됩니다. 테스트된 애플리케이션은 프로덕션 환경에 배포될 정확한 소프트웨어입니다.

또한 컨테이너는 애플리케이션이 여러 마이크로서비스로 분할될 때 각각 별도의 컨테이너에 있는 패치 및 업데이트의 롤아웃을 향상시킵니다. 나머지 애플리케이션을 중단하지 않고 개별 컨테이너를 검사하고, 패치하고, 다시 시작할 수 있습니다.

결론

DevOps의 성숙도를 높이려는 모든 조직은 민첩하고 원활한 배포를 위해 컨테이너의 기능을 활용하는 것을 고려해야 합니다. 문제는 이를 구성하고 보호하며 여러 환경에 원활하게 배포하는 방법을 아는 것입니다.