확장 아키텍처

확장 아키텍처 (Extension architecture)

Docker 확장이 어떻게 구성되고, 프론트엔드·백엔드·실행 파일의 역할을 설명하는 문서예요.

출처: 문서

본문

확장(extensions)은 Docker Desktop 안에서 실행되는 애플리케이션이에요. Docker 이미지로 패키징되어 Docker Hub를 통해 배포되며, 사용자는 Docker Desktop Dashboard 내의 Marketplace 또는 Docker Extensions CLI를 통해 확장을 설치해요.

확장은 세 가지(선택적) 구성 요소로 이루어질 수 있어요:

  • 프론트엔드(또는 사용자 인터페이스): Docker Desktop의 Dashboard 탭에 표시되는 웹 애플리케이션
  • 백엔드: Docker Desktop VM에서 실행되는 하나 이상의 컨테이너화된 서비스
  • 실행 파일(Executables): 확장을 설치할 때 Docker Desktop이 호스트에 복사하는 셸 스크립트 또는 바이너리

확장이 반드시 이 모든 구성 요소를 가질 필요는 없지만, 확장 기능에 따라 최소한 하나는 있어야 해요.

이러한 구성 요소를 구성하고 실행하기 위해 Docker Desktop은 metadata.json 파일을 사용해요. 자세한 내용은 metadata 섹션을 참조하세요.

프론트엔드 (The frontend)

프론트엔드는 기본적으로 HTML, JavaScript, CSS로 만든 웹 애플리케이션이에요. 간단한 HTML 파일, 약간의 vanilla JavaScript 또는 React, Vue.js 같은 프런트엔드 프레임워크로 빌드할 수 있어요.

Docker Desktop이 확장을 설치하면 metadata.json의 ui 섹션에서 정의한 대로 확장 이미지에서 UI 폴더를 추출해요. 자세한 내용은 ui metadata 섹션을 참조하세요.

사용자가 Extensions 탭을 클릭할 때마다 Docker Desktop은 처음인 것처럼 확장의 UI를 초기화해요. 사용자가 탭을 벗어나면 UI 자체와 UI가 시작한 모든 하위 프로세스(있는 경우)가 종료돼요.

프론트엔드는 Extensions SDK를 통해 docker 명령을 호출하고, 확장 백엔드와 통신하거나, 호스트에 배포된 확장 실행 파일을 호출할 수 있어요.

팁: docker extension init은 React 기반 확장을 생성해요. 하지만 그것을 자신의 확장을 위한 시작점으로 사용하고 Vue, Angular, Svelte 같은 다른 프론트엔드 프레임워크나 vanilla JavaScript를 사용해도 돼요.

확장을 위한 프론트엔드 빌드에 대해 자세히 알아보세요.

백엔드 (The backend)

프론트엔드 애플리케이션과 함께 확장은 하나 이상의 백엔드 서비스를 포함할 수도 있어요. 대부분의 경우 확장이 백엔드를 필요로 하지 않고, SDK를 통해 docker 명령을 호출하는 것만으로 기능을 구현할 수 있어요. 하지만 확장이 백엔드 서비스를 요구하는 몇 가지 경우가 있어요, 예를 들면:

  • 프론트엔드보다 오래 실행되어야 하는 장기 실행 프로세스를 실행할 때
  • 로컬 데이터베이스에 데이터를 저장하고 REST API로 다시 제공할 때
  • 버튼이 장기 실행 프로세스를 시작할 때처럼 확장 상태를 저장해서, 확장에서 벗어났다가 돌아와도 프론트엔드가 중단된 지점부터 이어받을 수 있게 할 때
  • compose 파일에서 폴더를 마운트하는 등 Docker Desktop VM의 특정 리소스에 접근할 때

팁: docker extension init은 Go 백엔드를 생성해요. 하지만 그것을 시작점으로 사용하고 Node.js, Python, Java, .Net 또는 다른 언어와 프레임워크를 사용해도 돼요.

일반적으로 백엔드는 Docker Desktop VM 안에서 실행되는 하나의 컨테이너로 만들어져요. 내부적으로 Docker Desktop은 Docker Compose 프로젝트를 만들고, metadata.json의 vm 섹션의 image 옵션에서 컨테이너를 생성해 Compose 프로젝트에 연결해요. 자세한 내용은 vm metadata 섹션을 참조하세요.

어떤 경우에는 image 대신 compose.yaml 파일을 사용할 수 있어요. 이것은 백엔드 컨테이너가 볼륨 마운트나 기능 요청 같이 Docker 이미지로만 표현할 수 없는 더 구체적인 옵션이 필요할 때 유용해요. compose.yaml 파일은 데이터베이스나 메시지 브로커 같은 확장에 필요한 여러 컨테이너를 추가하는 데도 사용할 수 있어요.

Compose 파일이 많은 서비스를 정의하면 SDK는 그 중 첫 번째 서비스에만 접근할 수 있다는 점에 유의하세요.

참고: 어떤 경우에는 백엔드에서도 Docker Engine과 상호작용하는 것이 유용해요. 백엔드에서 Docker 소켓 사용하는 방법을 참조하세요.

백엔드와 통신하기 위해 Extension SDK는 프론트엔드에서 GET, POST, PUT, HEAD, DELETE 요청을 하는 함수를 제공해요. 내부적으로 통신은 운영 체제에 따라 소켓 또는 named pipe를 통해 이루어져요. 백엔드가 포트에서 수신했다면 호스트나 컨테이너에서 실행되는 다른 애플리케이션과의 충돌을 막기 어려웠을 거예요. 또한 일부 사용자는 머신에서 포트를 열 수 없는 제한된 환경에서 Docker Desktop을 실행하고 있어요.

마지막으로 백엔드는 컨테이너에서 실행되고 소켓에서 수신할 수만 있으면 어떤 기술로도 빌드할 수 있어요.

확장에 백엔드 추가에 대해 자세히 알아보세요.

실행 파일 (Executables)

프론트엔드와 백엔드에 더해 확장은 실행 파일도 포함할 수 있어요. 실행 파일은 확장을 설치할 때 호스트에 설치되는 바이너리 또는 셸 스크립트예요. 프론트엔드는 확장 SDK로 이를 호출할 수 있어요.

이 실행 파일들은 확장이 AWS, kubectl 같은 타사 CLI 도구와 상호작용해야 할 때 유용해요. 확장과 함께 이런 실행 파일을 배포하면 사용자 머신에 해당 CLI 도구가 항상 올바른 버전으로 제공된다는 것을 보장해요.

Docker Desktop이 확장을 설치하면 metadata.json의 host 섹션에서 정의한 대로 실행 파일을 호스트에 복사해요. 자세한 내용은 host metadata 섹션을 참조하세요.

다만 실행 파일은 사용자 머신에서 실행되므로, 실행되는 플랫폼에서 사용할 수 있어야 해요. 예를 들어 kubectl 실행 파일을 배포하려면 Windows, Mac, Linux용 각각 다른 버전을 제공해야 해요. Multi-arch 이미지에도 올바른 아키텍처(AMD/ARM)용으로 빌드된 바이너리를 포함해야 해요. 자세한 내용은 host metadata 섹션을 참조하세요.

호스트 바이너리 호출하는 방법을 알아보세요.

더 알아보기 (Learn more)