LFCA: 컨테이너 사용의 기본 개념 배우기 – 22부

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

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

현재 Google, Amazon, Microsoft 및 Red Hat과 같은 모든 거대 기술 기업은 몇 군데만 언급하면 이러한 추세에 뛰어들었습니다.

왜 컨테이너인가?

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

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

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

컨테이너란 무엇입니까?

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

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

컨테이너는 기본 운영 체제와 완전히 격리되어 실행되며 컨테이너화된 애플리케이션은 컴퓨팅 환경이나 인프라에 관계없이 항상 일관되게 실행됩니다. 이러한 이유로 개발자는 이 랩톱에서 편안하게 애플리케이션을 개발하고 서버에 쉽게 배포할 수 있습니다.

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

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

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

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

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

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

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

[ 당신은 또한 좋아할 수도 있습니다: CentOS/RHEL 8에 KVM을 설치하는 방법 ]

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

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

효율성 때문에 Type 1 하이퍼바이저는 대부분 엔터프라이즈 환경에서 사용됩니다. 유형 1 하이퍼바이저 공급업체에는 VMware Esxi 및 KVM이 있습니다.

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

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

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

컨테이너

가상 머신과 달리 컨테이너에는 하이퍼바이저가 필요하지 않습니다. 컨테이너는 물리적 서버와 해당 운영 체제 위에 위치하며 라이브러리 및 바이너리와 같은 다른 것들 사이에서 OS와 동일한 커널을 공유합니다. 여러 컨테이너가 동일한 시스템에서 실행될 수 있으며, 각각은 나머지에서 고유한 응용 프로그램 및 프로세스 집합을 실행합니다. 인기 있는 컨테이너 플랫폼에는 Docker 및 Podman이 있습니다.

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

컨테이너는 온프레미스 또는 클라우드에 상관없이 PC에서 프로덕션 환경으로 바로 애플리케이션을 설계, 테스트 및 배포하는 편리한 방법을 제공합니다. 다음은 컨테이너화된 애플리케이션 사용의 이점 중 일부입니다.

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

이러한 방식으로 개발 팀은 응용 프로그램이 서로 상호 작용하는 방식과 관련하여 주요 수정 사항이 없는 한 응용 프로그램의 다양한 부분에서 협업할 수 있습니다.

이것이 마이크로서비스의 개념이 기반으로 하는 것입니다.

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

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

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

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

컨테이너는 DevOps 팀에 어떤 이점이 있습니까?

컨테이너는 DevOps에서 핵심적인 역할을 하며 컨테이너화된 애플리케이션이 없으면 상황이 어떻게 될지 상상할 수 없습니다. "그렇다면 컨테이너는 무엇을 테이블로 가져옵니까?

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

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

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

DevOps에서 성숙도를 달성하려는 조직은 민첩하고 원활한 배포를 위해 컨테이너의 힘을 활용하는 것을 고려해야 합니다. 문제는 구성, 보안 및 여러 환경에 원활하게 배포하는 방법을 아는 데 있습니다.