검색 결과가 없습니다

검색어와 일치하는 결과가 없습니다.

원하시는 정보를 찾는 데 도움이 되도록 다음을 시도해 보십시오.

  • 검색에 사용하신 키워드의 철자가 올바른지 확인하십시오.
  • 입력한 키워드에 동의어를 사용하십시오. 예를 들어 “소프트웨어” 대신 “애플리케이션”을 사용해 보십시오.
  • 아래에 표시된 인기 검색어 중 하나를 사용해 보십시오.
  • 새로운 검색을 시작하십시오.
인기 질문

Docker 컨테이너 및 컨테이너 클라우드 서비스

컨테이너는 애플리케이션의 모든 코드와 종속성을 컴퓨팅 환경에서 빠르고 안정적으로 실행할 수 있는 표준 형식으로 패키징하는 패키징 형식입니다. Docker 컨테이너는 라이브러리, 시스템 도구, 코드 및 런타임을 포함하여 애플리케이션을 실행하는 데 필요한 모든 것을 포함하는 인기 있는 경량의 독립형 실행 컨테이너입니다. Docker는 개발자가 컨테이너화된 애플리케이션을 빠르게 빌드, 테스트 및 배포할 수 있는 소프트웨어 플랫폼이기도 합니다.

CaaS(Containers as a Service) 또는 컨테이너 서비스는 컨테이너의 수명 주기를 관리하는 관리형 클라우드 서비스입니다. 컨테이너 서비스는 컨테이너의 런타임을 조정(시작, 중지, 확장)하는 데 도움이 됩니다. 컨테이너 서비스를 사용하면 애플리케이션 개발 및 배포 수명 주기를 단순화, 자동화 및 가속화할 수 있습니다.

Docker 및 컨테이너 서비스는 빠르게 채택되었으며 지난 몇 년 동안 엄청난 성공을 거두었습니다. 2013년만 해도 거의 알려지지 않았고 다소 기술적인 오픈 소스 기술이었던 Docker가 이제 많은 Oracle enterprise 제품에 대해 공식적으로 지원되는 표준화된 런타임 환경으로 발전했습니다.

누가 Docker를 사용합니까?

Docker는 DevOps 및 개발자에게 도움이 되도록 설계된 개방형 애플리케이션 개발 프레임워크입니다. 개발자는 Docker를 사용하여 거의 모든 곳에서 실행할 수 있는 경량의 휴대 가능한 자립형 컨테이너로 애플리케이션을 쉽게 빌드, 패키징, 배송 및 실행할 수 있습니다. 컨테이너를 사용하면 개발자가 모든 종속성으로 애플리케이션을 패키징하고 단일 단위로 배포할 수 있습니다. 사전에 구축되고 자체적으로 유지되는 애플리케이션 컨테이너를 제공함으로써 개발자는 기본 운영 체제 또는 배포 시스템을 걱정하지 않고 애플리케이션 코드에 집중하면서 사용할 수 있습니다.

또한 개발자는 이미 Docker 컨테이너 내에서 실행되도록 설계된 수천 개의 오픈 소스 컨테이너 애플리케이션을 활용할 수 있습니다. DevOps 팀의 경우 Docker는 지속적인 통합 및 개발 도구 체인에 적합하며 애플리케이션을 배포하고 관리하기 위한 시스템 아키텍처 내에서 필요한 제약과 복잡성을 줄입니다. 컨테이너 오케스트레이션 클라우드 서비스의 도입으로 모든 개발자는 개발 환경에서 로컬로 컨테이너화된 애플리케이션을 개발한 다음 관리형 Kubernetes 서비스와 같은 클라우드 서비스의 프로덕션에서 컨테이너화된 애플리케이션을 이동하고 실행할 수 있습니다.

Docker와 Kubernetes

Linux 컨테이너는 2008년부터 존재했지만 2013년 Docker 컨테이너가 등장할 때까지 잘 알려지지 않았습니다. Docker 컨테이너가 시작되면서 컨테이너화된 애플리케이션을 개발하고 배포하는 것에 대한 관심이 폭발적으로 증가했습니다. 컨테이너화된 애플리케이션의 수가 여러 서버에 배포된 수백 개의 컨테이너에 걸쳐 증가함에 따라 운영이 더욱 복잡해졌습니다. 수백 개의 컨테이너를 어떻게 조정, 확장, 관리 및 예약해야 할까요? Kubernetes가 도움을 줄 수 있습니다. Kubernetes는 Docker 컨테이너 및 워크로드를 실행할 수 있는 오픈 소스 오케스트레이션 시스템입니다. 여러 서버에 배포된 여러 컨테이너를 확장하기 위해 이동할 때 운영 복잡성을 관리하는 데 도움이 됩니다. Kubernetes 엔진은 컨테이너 수명 주기를 자동으로 조정하여 호스팅 인프라 전체에 애플리케이션 컨테이너를 배포합니다. Kubernetes는 수요에 따라 리소스를 빠르게 확장하거나 축소할 수 있습니다. 컨테이너의 상태를 지속적으로 프로비저닝, 예약, 삭제 및 모니터링합니다.

Docker 기본 사항

Docker의 핵심 개념은 이미지와 컨테이너입니다. Docker 이미지에는 다음과 같이 소프트웨어를 실행하는 데 필요한 모든 것이 포함되어 있습니다. 코드, 런타임(예: Java Virtual Machine(JVM)), 드라이버, 도구, 스크립트, 라이브러리, 배포 등

Docker 컨테이너는 실행 중인 Docker 이미지 인스턴스입니다. 그러나 유형 1 또는 유형 2 하이퍼바이저를 사용하는 기존 가상화와 달리 Docker 컨테이너는 호스트 운영 체제의 커널에서 실행됩니다. Docker 이미지 내에는 그림 1과 같이 별도의 운영 체제가 없습니다.

Docker 기본 이미지
그림 1

격리와 가상화

모든 Docker 컨테이너에는 자체 파일 시스템, 자체 네트워크 스택(따라서 자체 IP 주소), 자체 프로세스 공간, CPU 및 메모리에 정의된 리소스 제한이 있습니다. Docker 컨테이너는 운영 체제를 부팅할 필요가 없기 때문에 즉시 시작됩니다. Docker는 격리, 즉 가상화와 달리 호스트 운영 체제의 리소스를 분리합니다. 즉, 호스트 운영 체제 위에 게스트 운영 체제를 제공합니다.

VM과 Kubernetes - 배포 인프라
증분 파일 시스템 이미지
그림 2

증분 파일 시스템

Docker 이미지의 파일 시스템은 기록 중 복사 의미 체계를 사용하여 계층화됩니다. 이를 통해 상속 및 재사용이 가능하고 디스크의 리소스가 절약되며 증분 이미지를 다운로드할 수 있습니다.

그림 2에 나와 있는 것처럼 WebLogic 배포를 사용하는 Docker 이미지는 Oracle WebLogic Server 도메인이 있는 이미지를 기반으로 할 수 있기 때문에 WebLogic 이미지를 기반으로 할 수 있고, 이는 Java Development Kit(JDK) 이미지를 기반으로 때문에 결과적으로 Oracle Linux 기본 이미지를 기반으로 합니다.

Docker Registry

Docker 이미지는 빌드하기 쉽고 개발자는 Docker 이미지의 단순성과 이식성을 좋아하지만 수천 개의 Docker 이미지를 관리하는 것이 매우 어렵다는 것을 빠르게 발견했습니다. Docker Registry는 이 문제를 해결합니다. Docker Registry는 Docker 이미지를 저장하고 배포하는 표준 방법입니다. 이 Registry는 개방형 Apache 라이선스에 따른 오픈 소스 기반 리포지토리입니다.

또한 Docker Registry는 리포지토리에 저장된 Docker 이미지의 액세스 제어 및 보안을 개선하는 데 도움이 됩니다. 이미지 배포를 관리하고 애플리케이션 개발 워크플로와 통합할 수도 있습니다. 개발자는 고유한 Docker Registry를 설정하거나 Docker Hub, Oracle Container Registry, Azure Container Registry 등과 같은 호스팅된 Docker Registry 서비스를 사용할 수 있습니다.

Docker Hub는 Docker에서 관리하는 호스팅된 Docker 레지스트리입니다. Docker Hub에는 소프트웨어 공급업체, 오픈 소스 프로젝트 및 커뮤니티에서 제공하는 100,000개 이상의 컨테이너 이미지가 있습니다. Docker Hub에는 NGINX, Logstash, Apache HTTP, Grafana, MySQL, Ubuntu 및 Oracle Linux와 같은 공식 리포지토리의 소프트웨어 및 애플리케이션이 포함되어 있습니다.

컨테이너를 시작할 때 Docker는 기본적으로 공용 Docker Hub에서 해당 이미지를 자동으로 가져옵니다(로컬에서 사용할 수 없는 경우). 또한 자체 이미지를 생성하여 Docker Hub에 공용 또는 개인 리포지토리로 푸시할 수도 있습니다.

그림 3: Docker Registry 스크린샷
그림 3

마이크로서비스 런타임 역할을 하는 Docker

모놀리식 애플리케이션을 더 작은 마이크로서비스 청크로 자르는 아이디어는 요즘 소프트웨어 개발자들 사이에서 많은 관심을 받고 있습니다.

마이크로서비스는 독립적으로 프로세스로 배포되고 경량 프로토콜을 사용하여 서로 통신하며 모든 서비스는 데이터를 소유합니다[7]. 마이크로서비스는 분산형 거버넌스 접근 방식을 따르기 때문에 상당히 많은 양의 인프라 자동화, 자동화된 테스트, 완전 자동화된 CD 파이프라인 및 숙련되고 민첩한 DevOps 팀이 필요합니다.

이 아키텍처 스타일은 여전히 많이 논의되고 있지만 마이크로서비스로 분해된 애플리케이션을 프로세스 집합으로 간단히 운영할 수 있다고 가정하는 것은 순진합니다. 몇 가지 요구 사항만 언급하면 마이크로서비스는 호스트 독립적이고 운영 체제 수준에서 격리되어야 합니다. 리소스 제한 내에서 실행되어야 하고 확장 및 축소되어야 하며 실패한 경우 다시 시작해야 하고 소프트웨어에서 정의한 네트워크 계층을 통해 다른 마이크로서비스를 검색하고 연결해야 합니다.

따라서 Docker 컨테이너에서 마이크로서비스를 실행하면 이러한 목표의 대부분을 달성할 수 있는 탁월한 출발점에 설 수 있습니다.

Docker—두 가지 주요 기준

Docker는 두 가지 기준으로 소프트웨어를 빌드, 제공 및 실행하는 방식을 바꿉니다.

  • 개발에서 생산까지 애플리케이션을 안정적으로 확보할 수 있도록 프로세스를 향상시킵니다.
  • 온프레미스에서 클라우드로 이동할 수 있는 표준 이미지 형식을 제공합니다.

두 기준 모두 다음 단락에서 자세히 설명합니다.

Docker 이미지—개발에서 프로덕션

모든 종속성이 포함된 Docker 이미지를 생성하면 "하지만 내 개발 시스템에서는 효과가 있었습니다"라는 문제가 해결됩니다. 핵심 아이디어는 Docker 이미지가 Git과 같은 소스 코드 리포지토리의 빌드 파이프라인에 의해 자동으로 생성되고 처음에는 개발 환경에서 테스트된다는 것입니다. 이 변경 불가능한 이미지는 Docker 레지스트리에 저장됩니다.

그림 4에 표시된 것처럼 추가 부하 테스트, 통합 테스트, 승인 테스트 등에 동일한 이미지가 사용됩니다. 모든 환경에서 동일한 이미지가 사용됩니다. 프로덕션 데이터베이스의 JDBC URL과 같이 작지만 환경적으로 필요한 특정 차이점은 환경 변수 또는 파일로 컨테이너에 제공될 수 있습니다.

Docker 이미지 스크린샷
그림 4

통계에 따르면 현재 모든 Docker 사용 사례의 65%가 개발 중이고 48%는 지속적인 통합을 위해 Docker를 사용합니다[5].

온프레미스에서 클라우드로

Docker는 퍼블릭 클라우드 채택을 변경했습니다. 반면 Docker 이미지를 사용하면 역사상 처음으로 온프레미스와 모든 주요 클라우드 공급자에서 실행할 수 있는 공통 패키지 형식이 존재합니다. Docker 컨테이너는 오라클 클라우드에서 실행되는 것과 동일한 방식으로 노트북에서 실행됩니다.

반면 Docker 컨테이너는 모든 주요 퍼블릭 클라우드에서 실행되기 때문에 퍼블릭 클라우드에 대해 오랫동안 가져온 편견을 극복하는 데 큰 기여를 합니다. 공급업체 종속성 문제. 모든 주요 클라우드 공급자는 이제 Docker를 PaaS로 제공합니다.

Docker 버전—기본 기술의 성숙도

Docker 릴리스의 속도는 기존 엔터프라이즈 소프트웨어의 릴리스 주기보다 훨씬 빠릅니다. Docker 프로젝트의 새로운 기능과 함께 Docker 릴리스의 빠른 속도로 인해 Docker의 보안 및 안정성에 대한 우려가 제기됩니다.

Docker 및 해당 명령행, Docker 데몬, API 및 Docker Swarm, Docker Machine 및 Docker Compose와 같은 도구는 지난 3년 동안만 발전했지만 거의 10년 동안 모든 Linux 커널에서 기본 커널 기능을 사용할 수 있었습니다.

컨테이너 기술을 조기에 채택한 대표적인 예는 Google입니다. Google은 Docker가 등장하기 전에도 Linux 컨테이너를 사용해 왔습니다. 또한 Google은 모든 것을 컨테이너에서 실행합니다. Google은 매주 20억 개의 컨테이너를 시작하는 것으로 추정됩니다[3].

Cgroup 및 네임스페이스 기록

Docker가 사용하는 기본 Linux 커널 기능은 cgroup 및 네임스페이스입니다. 2008년에 cgroup은 이전에 Google 개발자가 수행한 작업을 기반으로 Linux 커널에 도입되었습니다[1]. Cgroup은 운영 체제 프로세스 집합의 리소스 사용량을 제한하고 설명합니다.

Linux 커널은 네임스페이스를 사용하여 프로세스의 시스템 리소스를 서로 분리합니다. 첫 번째 네임스페이스인 마운트 네임스페이스는 2002년에 도입되었습니다.

컨테이너 클라우드 서비스

이 문서의 첫 번째 부분에서는 몇 가지 중요한 Docker 개념을 설명했습니다. 그러나 프로덕션 환경에서는 Docker 컨테이너에서 애플리케이션을 실행하는 것만으로 충분하지 않습니다.

프로덕션 환경을 설정하고 운영하려면 컨테이너를 실행할 하드웨어가 필요합니다. Docker와 같은 소프트웨어는 리포지토리 및 클러스터 관리자와 함께 설치, 업그레이드 및 패치해야 합니다. 호스트 간에 여러 Docker 컨테이너가 통신하는 경우 네트워크를 생성해야 합니다. 클러스터링된 컨테이너는 실패하면 다시 시작해야 합니다. 또한 서로 연결된 컨테이너 세트는 단일 논리적 애플리케이션 인스턴스처럼 쉽게 배포할 수 있어야 합니다. 예를 들어, 로드 밸런서, 몇 대의 웹 서버, 관리 서버가 있는 일부 Oracle WebLogic Server 인스턴스, 관리 서버 및 데이터베이스가 있습니다. 컨테이너화된 애플리케이션을 대규모로 관리하려면 Kubernetes 또는 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템이 필요합니다. Kubernetes와 같은 오케스트레이션 시스템을 배포, 관리 및 운영하는 것은 어렵고 시간이 많이 소요될 수 있습니다.

개발자가 컨테이너화된 애플리케이션을 더 쉽고 효율적으로 생성할 수 있도록 클라우드 공급자는 컨테이너 클라우드 서비스 또는 CaaS(Containers as a Service)를 제공합니다. 컨테이너 클라우드 서비스는 개발자와 운영 팀이 자동화된 방식으로 컨테이너의 수명 주기를 간소화하고 관리할 수 있도록 지원합니다. 일반적으로 Kubernetes를 사용하여 구축되는 이러한 오케스트레이션 서비스를 통해 DevOps 팀은 컨테이너화된 애플리케이션을 대규모로 쉽게 관리하고 운영할 수 있습니다. Oracle Container Engine for Kubernetes 및 Azure Kubernetes Service는 인기 있는 컨테이너 오케스트레이션 관리형 클라우드 서비스의 두 가지 예입니다.

Oracle Container Engine for Kubernetes는 클라우드에서 컨테이너화된 애플리케이션을 배포하는 데 사용할 수 있는 확장 가능하고 가용성이 높은 완전 관리형 서비스입니다. 개발 팀에서 클라우드 네이티브 애플리케이션을 안정적으로 빌드, 배포 및 관리하려는 경우 Oracle Container Engine for Kubernetes(약어로 OKE라고 부르기도 함)을 사용하십시오.

Oracle의 Docker 이미지—다음은 Oracle 제품용 Docker 이미지를 얻거나 빌드하기 위한 몇 가지 소스입니다. Docker 이미지용 Oracle GitHub 리포지토리에는 Oracle 상용 제품 및 Oracle에서 후원하는 오픈 소스 프로젝트용 Docker 이미지를 빌드하기 위한 Docker 파일 및 샘플이 포함되어 있습니다.

Docker 실습 랩—Docker를 사용한 컨테이너화된 개발

참고 자료

  1. Cgroup(위키피디아)
  2. Linux 네임스페이스(위키피디아)
  3. Google의 모든 것은 컨테이너에서 실행, Jack Clark
  4. Docker Hub, 50억회 사용
  5. 현대 소프트웨어 공급망의 진화, 2016년 Docker 설문 조사
  6. MOS 문서 ID 2216342.1: Oracle DB에 대한 Docker 지원
  7. 마이크로서비스, Martin Fowler
  8. Oracle Container Engine 및 레지스트리 데모(3:13)
  9. Container Engine for Kubernetes 문서