/var/log/messages
클라우드와 온 프라미스 환경에서의 DevOps와 컨테이너 본문
클라우드와 온프레미스 간의 논쟁은 오래된 논쟁입니다. 클라우드가 처음 등장했을 때 사람들이 워크로드를 온프레미스 데이터센터에 유지할지 클라우드 호스트로 마이그레이션할지 결정하려던 시절로 거슬러 올라갑니다. 하지만 Docker 혁명은 이 논쟁에 새로운 차원을 도입했습니다. 점점 더 많은 조직이 컨테이너를 채택함에 따라 이제 컨테이너를 호스팅하기에 가장 적합한 장소가 온프레미스인지 클라우드인지 스스로에게 질문하고 있습니다. 아시다시피 모든 사람에게 맞는 정답은 없습니다. 이 글에서는 클라우드와 온프레미스 컨테이너 배포의 장단점을 살펴보고, 어떤 요소가 조직에 적합한 선택이 될 수 있는지 살펴보겠습니다.
데브옵스, 컨테이너, 클라우드
먼저 DevOps, 컨테이너, 클라우드의 기본적인 관계에 대해 간단히 살펴보겠습니다.
기본적인 관계를 간단히 살펴보겠습니다. 여러 가지 면에서 데브옵스와 컨테이너의 조합은 클라우드에서 IT를 수행하는 기본 방식은 아니더라도 클라우드에서 IT를 수행하는 한 가지 방법으로 볼 수 있습니다. 결국, 컨테이너는
확장성과 유연성, 즉 데브옵스 운동의 핵심 목표인 많은 사람들이 클라우드로 마이그레이션하는 주요 이유는 말할 것도 없고요. 클라우드로 마이그레이션하는 주된 이유이기도 합니다. 가상화 및 연속 배포와 같은 것들은
배포와 같은 것들은 클라우드(또는 클라우드와 유사한 환경)에 완벽하게 적합한 것처럼 보이며, DevOps가 애자일 세계에서 시작되었다면 애자일 세계에서 자연스럽게 발전했을 것입니다. 자연스럽게 발전했을 가능성이 높습니다.
데브옵스와 온프레미스
그렇다고 컨테이너화, DevOps, 지속적 배포가 온프레미스 배포에 적합하지 않거나 심지어 이질적이라는 뜻일까요?
그렇지 않습니다. 온프레미스 배포는 이제 고도의 가상화, 추상화를 통한 하드웨어 제약으로부터의 상대적 독립성 등 클라우드의 많은 특성을 가지고 있습니다. 오늘날의 온프레미스 시스템은 일반적으로 '프라이빗 클라우드'의 정의에 부합하며, DevOps의 핵심인 자동화된 개발 및 운영 주기에 잘 맞습니다. 실제로 AWS와 Docker를 비롯한 데브옵스/컨테이너 분야의 주요 업체들은 온프레미스 배포를 강력하게 지원하며, Rancher와 같은 정교한 컨테이너 관리 도구는 퍼블릭/프라이빗 클라우드 경계를 넘어 원활하게 작동하도록 설계되었습니다. 이제 컨테이너는 클라우드만큼이나 온프레미스 환경의 네이티브라고 해도 과언이 아닙니다.
왜 On-Premies 인가?
온프레미스에 컨테이너를 배포하려는 이유는 무엇인가요? 로컬 리소스 가장 분명한 이유는 스토리지 또는 프로세서와 같은 하드웨어 기능에 직접 액세스하고 사용해야 하기 때문일 것입니다. 스토리지 또는 프로세서별 작업과 같은 하드웨어 기능에 직접 액세스하고 사용해야 하기 때문입니다.
예를 들어, 행렬 집약적인 연산에 그래픽 칩 배열을 사용하는 경우 매트릭스 집약적인 계산을 위해 그래픽 칩 배열을 사용하는 경우 로컬 하드웨어. 컨테이너는 가상 머신과 마찬가지로 항상 어느 정도의 추상화가 필요합니다. 어느 정도의 추상화가 필요하지만, 온프레미스에서 컨테이너를 실행하면 컨테이너와 컨테이너 사이의
애플리케이션과 기본 메탈 사이의 추상화 레이어 수를 최소로 줄입니다. 컨테이너에서 기본 OS의 하드웨어로 바로 이동할 수 있습니다. 어느 정도 직접 액세스할 수 있는데, 이는 VM에서는 실용적이지 않습니다. 또는 퍼블릭 클라우드의 컨테이너에서는 실용적이지 않습니다. 로컬 모니터링 비슷한 맥락에서, 로컬 디바이스를 모니터링, 제어하고 관리하기 위해 컨테이너가 필요할 수도 있습니다. 이는 산업 환경이나 산업 환경이나 연구 시설에서 중요한 고려 사항일 수 있습니다. 예를 들어 물론 모니터링 및 제어 기능을 보다 전통적인 유형의 소프트웨어인 모니터링 및 제어 기능을 수행할 수도 있습니다. 그러나 컨테이너화 및 지속적 배포를 함께 사용하면 제조 공정이나 연구 절차의 변화에 대응하여 소프트웨어를 업데이트하고 조정할 수 있습니다. 신속하게 업데이트할 수 있습니다. 보안에 대한 로컬 제어 온프레미스에 컨테이너를 배포할 때 보안도 주요 고려 사항일 수 있습니다.
온프레미스에 컨테이너를 배포할 때에도 보안을 고려해야 합니다. 컨테이너는 기본 OS에서 리소스에 액세스하기 때문에 기본 OS의 리소스에 액세스하므로 잠재적인 보안 취약점이 있습니다. 컨테이너를 안전하게 보호하려면 컨테이너 시스템에 보안 기능을 추가하는 보안 기능을 추가하는 적극적인 조치를 취해야 합니다. 대부분의 컨테이너 배포 시스템에는 보안 기능이 내장되어 있습니다. 온프레미스 배포, 는 보안 계층을 추가하는 데 유용한 전략이 될 수 있습니다.
물리적 시설에 대한 액세스 제어와 함께 제공되는 추가 보안 기능 외에도 물리적 시설에 대한 액세스 제어와 함께 제공되는 추가 보안 외에도 온프레미스 컨테이너 배포는 다음을 수행할 수 있습니다. 기본 하드웨어에 내장된 보안 기능을 활용할 수 있습니다. 레거시 인프라 및 클라우드 마이그레이션 기존 온프레미스 인프라를 포기할 수 있는 기존 온프레미스 인프라를 포기할 수 없다면 어떻게 해야 할까요? 회사에서 하드웨어에 상당한 금액을 투자했거나, 단순히 대규모의 복잡한 레거시 애플리케이션을 모두 마이그레이션할 의향이 없거나 상호 연결된 레거시 애플리케이션을 한꺼번에 마이그레이션할 의향이 없거나 마이그레이션할 수 없다면 당분간 온 프레미스에 머무르는 것이 가장 실용적인 (또는 가장 정치적으로 신중한) 단기 및 중기적 선택일 수 있습니다. 온프레미스에 컨테이너(및 데브옵스 관행)을 온프레미스에 도입함으로써, 점진적으로 온프레미스로 마이그레이션할 수 있는 비교적 간편한 점진적으로 클라우드로 마이그레이션하는 경로를 마련할 수 있습니다. 로컬에서 테스트, 클라우드에 배포 클라우드 컨테이너화된 애플리케이션을 로컬에서 개발 및 테스트한 다음
로컬에서 개발 및 테스트한 후 클라우드에 배포할 수도 있습니다. 온-프레미스 개발을 통해 다음을 수행할 수 있습니다. 소프트웨어와 배포 간의 상호 작용을 면밀히 모니터링하고 플랫폼 간의 상호 작용을 면밀히 모니터링하고 제어된 조건에서 작동을 관찰할 수 있습니다. 이 다음과 같은 방법으로 배포 후 예상치 못한 문제를 더 쉽게 격리할 수 있습니다.
클라우드에서 애플리케이션의 동작을 알려진 제어 환경에서의 동작과 비교하여 비교하여 배포 후 예상치 못한 문제를 쉽게 격리할 수 있습니다. 또한 컨테이너 기반 소프트웨어를 배포하고 테스트할 수 있습니다. 컨테이너 기반 소프트웨어를 배포하고 테스트할 수 있습니다.
새로운 기능이나 기능에 대한 정보가 경쟁사에 유출되지 않을 것이라는 유출되지 않을 것이라는 확신을 가질 수 있습니다.
퍼블릭/프라이빗 하이브리드
클라우드와 온프레미스 컨테이너 배포를 비교할 때 고려해야 할 또 다른 사항은 다음과 같습니다. 온프레미스 컨테이너 배포: 퍼블릭 및 프라이빗 클라우드 배포 은 근본적으로 호환되지 않으며, 여러 면에서 퍼블릭 클라우드와 프라이빗 클라우드 사이에는 명확하게 구분할 수 없습니다. 물론 이는 전통적인 모놀리식 애플리케이션(예를 들어, 프라이빗 서버에 상주하면서 원격 사용자가 액세스할 수 있는 서버에 상주하면서 클라우드 기반 인터페이스를 통해 원격 사용자가 액세스할 수 있는
인터페이스)에도 해당되지만, 컨테이너를 사용하면 퍼블릭과 프라이빗의 경계를 더욱 유동적이고 불분명하게 만들 수 있습니다.
할 수 있습니다, 예를 들어, 애플리케이션을 주로 퍼블릭 클라우드에 컨테이너를 사용하여 배포하고 퍼블릭 클라우드에 애플리케이션을 배포하고 일부 기능은 온프레미스 컨테이너에서 실행할 수 있습니다.
이렇게 하면 보안 또는 로컬 디바이스 액세스 로컬 디바이스 액세스와 같은 것들을 세밀하게 제어할 수 있는 동시에 퍼블릭 클라우드 배포의 유연성, 광범위한 범위, 비용 이점을 활용할 수 있습니다. 퍼블릭 클라우드 배포.
조직에 적합한 조합
어떤 유형의 배포가 회사에 더 적합할까요? 일반적으로 하드웨어와 긴밀하게 연결할 필요가 없는 스타트업 및 중소규모 기업은 하드웨어와 긴밀하게 연결할 필요가 없는 스타트업과 중소기업은 클라우드로 쉽게 이동하거나 시작할 수 있습니다.
클라우드. 대기업(즉, 엔터프라이즈 규모)과 로컬 하드웨어 리소스를 관리하고 제어해야 하는 기업은 로컬 하드웨어 리소스를 관리하고 제어해야 하는 기업일수록 온프레미스 인프라를 선호할 가능성이 높습니다. 엔터프라이즈의 경우, 온-프레미스 컨테이너 배포는 전체 퍼블릭 클라우드로의 가교 역할을 할 수 있습니다. 배포 또는 하이브리드 프라이빗/퍼블릭 배포를 위한 가교 역할을 할 수 있습니다. 결론은 퍼블릭 클라우드와 온프레미스 중 어느 쪽을 선택해야 하는지에 대한 답은
에 대한 답은 비즈니스의 구체적인 요구사항에 따라 달라집니다. 어떤 조직도 조직은 모두 다르며 소프트웨어 배포도 모두 같지 않습니다. 소프트웨어/IT 목표가 무엇이든, 어떤 방식으로 달성할 계획이든 온프레미스 배포와 퍼블릭 클라우드 배포 사이에는 온프레미스 배포와 퍼블릭 클라우드 배포 사이에는 계획을 실현할 수 있는 충분한 유연성이 있습니다.
'Rancher' 카테고리의 다른 글
SLES 15SP4에서 docker 기반 Rancher(랜처) 2.7v 설치하기 (0) | 2023.06.05 |
---|---|
컨테이너와 쿠버네티스 소개: 도커와 오케스트레이션 (0) | 2023.05.31 |
컨테이너 vs 가상화 (0) | 2023.05.15 |
쿠버네티스란? (0) | 2023.05.07 |
컨테이너와 도커란? (0) | 2023.04.29 |