Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

Windows Server 컨테이너 - DockerMsftProvider 모듈을 이용한 docker 설치

윈도우의 경우 Linux가 아닌 탓에 Container 지원 기술이 좀 복잡해졌는데요, 우선 현재 기준으로 (Linux Container가 아닌) 윈도우 컨테이너는 다음의 글에 따라,

Get started: Prep Windows for containers
; https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server

PowerShell에서 2가지 명령어만 실행해 설치할 수 있습니다.

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider

[설치 후 재시작 필요: "Restart-Computer -Force"]

사실 이게 새로운 것이라기보다는 예전에 설명했던,

Windows 10에서 경험해 보는 Windows Containers와 docker
; https://www.sysnet.pe.kr/2/0/11013

글에서 "Containers" 구성 요소 설치와 "docker-latest.zip"을 별도로 설치하던 것을 하나로 합친 것에 불과합니다. 실제로 위의 Install-Package 수행 시 로컬에는 "C:\Program Files\docker" 폴더가 생성되고, Full 버전의 "Docker Desktop for Windows"로 설치한 경우와 비교해 리눅스 환경을 고려하지 않아도 되므로 "Windows Containers"를 "docker.exe" 명령어로 운영할 수 있는 최소한의 실행 파일만 위치합니다.

참고로, 이런 식으로 설치되는 구성 요소를 docker hub에는 "Docker Enterprise"라는 이름으로 올려져 있습니다.

Docker Enterprise (Windows Server 2019 and 2016)
; https://hub.docker.com/editions/enterprise/docker-ee-server-windows




그런데 재미있군요, "Docker Engine"이 NT 서비스로 등록은 되는데 실행이 안됩니다.

Windows could not start the Docker Engine service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.

그래서 docker 명령어도 전혀 동작을 하지 않습니다.

C:\Windows\System32> docker info
Client:
 Debug Mode: false
 Plugins:
  cluster: Manage Docker clusters (Docker Inc., v1.2.0)

Server:
ERROR: error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.40/info: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows, the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.
errors pretty printing info

하지만, cmd.exe 명령행 창에서 "net start docker"로 실행하면 정상적으로 ^^; 서비스가 시작 상태로 바뀝니다. 어쨌든, 서비스 구동은 되었으니 dockerd.exe는 윈도우 컨테이너의 동작 환경을 "C:\ProgramData\docker" 폴더에 구성하고, "//./pipe/docker_engine" named pipe를 열어 docker.exe의 요청을 처리하게 됩니다.

혹시 C 드라이브의 용량이 간당간당하다면, dockerd.exe가 "C:\ProgramData\docker"에 docker 이미지들을 보관하는 것에 부담을 느낄 수 있는데요. 그럴 때는 원하는 drive에, 예를 들어 D 드라이브에 "D:\docker_win" 폴더를 만들고, 다시 그 하위의 "config" 폴더를 만든 후 daemon.json을 다음과 같이 구성해 줍니다.

[D:\docker_win\config\daemon.json]
{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false,
  "data-root": "d:\\docker_win"
}

그다음, "Docker Engine" 서비스의 실행 설정을 다음과 같이 변경하면 됩니다.

c:\temp> sc config docker binpath= "\"C:\Program Files\docker\dockerd.exe\" --run-service --config-file D:\docker_win\config\daemon.json"

이후, 서비스를 재시작하면 "D:\Docker_Win" 폴더에 Windows Containers가 동작하기 위한 기반 폴더들이 초기화/구성됩니다.




설치 제거는 다음의 글에서 잘 설명하고 있습니다.

Uninstall Docker Engine - Enterprise
; https://docs.docker.com/ee/docker-ee/windows/docker-ee/#uninstall-docker-engine---enterprise

docker swarm leave --force
docker rm -f $(docker ps --all --quiet)
docker system prune --all --volumes

Uninstall-Package -Name docker -ProviderName DockerMsftProvider
Uninstall-Module -Name DockerMsftProvider

Get-HNSNetwork | Remove-HNSNetwork
Remove-Item -Path "C:\ProgramData\Docker" -Recurse -Force

"Uninstall-Package" 패키지 단계에서 "Docker Engine" 서비스 및 "C:\Program Files\docker" 폴더가 삭제되므로 "docker.exe" 명령을 수행할 것들이 있다면 그전에 완료해야 합니다. 만약 Uninstall-Package를 먼저 수행해 그 전의 작업을 생략했다면 "C:\ProgramData\Docker" 폴더를 수작업으로 직접 삭제해서는 안 됩니다. 그런 경우에는 다음의 글을 참고하세요.

docker - c:programdatadockerwindowsfilter 폴더 정리하는 방법
; https://www.sysnet.pe.kr/2/0/11051




DockerMsftProvider가 설치하는 docker 패키지는 "Windows Containers"라는 점에 유의해야 합니다. 즉, "Linux Containers"를 구동하고 싶다면 별도로 "Docker Desktop for Windows" 버전을 설치해야 합니다.

그런데, 문제는 "Docker Desktop for Windows" 이름에서도 알 수 있듯이 "Server"가 아닌 "Desktop" 제품이라는 점입니다. 실제로 제품 설명에 봐도,

Docker Desktop for Windows is Docker designed to run on Windows 10. It is a native Windows application that provides an easy-to-use development environment for building, shipping, and running dockerized apps. Docker Desktop for Windows uses Windows-native Hyper-V virtualization and networking and is the fastest and most reliable way to develop Docker apps on Windows. Docker Desktop for Windows supports running both Linux and Windows Docker containers.


"개발 환경"을 위한 제품으로써 Windows 10 개인 PC 환경을 위한 것입니다. 즉 "상용 서비스"를 위한 환경을 제공하는 목적은 아니라는 점입니다. 실제로 "Docker Desktop for Windows"로 실행하는 리눅스 컨테이너는 "DockerDesktopVM" 환경에서 동작하지만, "Windows 10"에서 (컴퓨터 종료가 아닌) "Logout"을 하게 되면 "Docker.Desktop.exe" 프로세스가 종료하면서 "DockerDesktopVM" 가상 머신까지 모두 Stopped 상태로 바뀝니다.

따라서, 설령 "Windows Server" 제품군에 "Docker Desktop for Windows"를 설치해 컨테이너 서비스를 하려면 로그인이 필요하게 됩니다. 정리하면, 리눅스 컨테이너의 경우 개발 자체는 윈도우에서 할 수 있지만 서비스 단계에서는 리눅스를 사용해야 합니다. (검색해 보면, 작업 스케줄러를 이용해 Docker.Desktop.exe 프로세스를 실행하는 식으로의 우회 방법이 있습니다.)

물론, 윈도우 컨테이너를 개발하는 경우라면 "Docker Desktop for Windows" 필요 없이 DockerMsftProvider로 설치한 docker 환경의 윈도우 PC에서 서비스할 수 있고 이때는 당연히 로그인도 필요가 없습니다. 어찌 보면 이것은 올바른 정책입니다. 왜냐하면 분명히 윈도우의 VM에 얹은 리눅스 컨테이너는 성능 면에서 리눅스 전용 머신보다 낮을 것이고 실제 서비스를 그런 환경에서 하고 싶은 경우는 거의 없을 것이기 때문입니다. 반면, 이유야 그렇다고는 하지만 굳이 "Docker.Desktop.exe" 프로세스를 컨테이너 서비스 자체와 강력하게 결합시킬 필요는 없지 않았나... 하는 아쉬움이 남습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/9/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13179정성태12/2/20224353Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/20224854Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20225579오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20224511오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/20226131오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/20224702.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/20225389.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/20225202.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
13171정성태11/25/20224813Windows: 214. 윈도우 - 스레드 스택의 "red zone"
13170정성태11/24/20225117Windows: 213. 윈도우 - 싱글 스레드는 컨텍스트 스위칭이 없을까요?
13169정성태11/23/20225706Windows: 212. 윈도우의 Protected Process (Light) 보안 [1]파일 다운로드2
13168정성태11/22/20224993제니퍼 .NET: 31. 제니퍼 닷넷 적용 사례 (9) - DB 서비스에 부하가 걸렸다?!
13167정성태11/21/20225031.NET Framework: 2070. .NET 7 - Console.ReadKey와 리눅스의 터미널 타입
13166정성태11/20/20224755개발 환경 구성: 651. Windows 사용자 경험으로 WSL 환경에 dotnet 런타임/SDK 설치 방법
13165정성태11/18/20224662개발 환경 구성: 650. Azure - "scm" 프로세스와 엮인 서비스 모음
13164정성태11/18/20225561개발 환경 구성: 649. Azure - 비주얼 스튜디오를 이용한 AppService 원격 디버그 방법
13163정성태11/17/20225499개발 환경 구성: 648. 비주얼 스튜디오에서 안드로이드 기기 인식하는 방법
13162정성태11/15/20226583.NET Framework: 2069. .NET 7 - AOT(ahead-of-time) 컴파일
13161정성태11/14/20225798.NET Framework: 2068. C# - PublishSingleFile로 배포한 이미지의 역어셈블 가능 여부 (난독화 필요성) [4]
13160정성태11/11/20225748.NET Framework: 2067. C# - PublishSingleFile 적용 시 native/managed 모듈 통합 옵션
13159정성태11/10/20228955.NET Framework: 2066. C# - PublishSingleFile과 관련된 옵션 [3]
13158정성태11/9/20225227오류 유형: 826. Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain' [...] conflicts with manifest 'microsoft.net.workload.mono.toolchain.net7'
13157정성태11/8/20225885.NET Framework: 2065. C# - Mutex의 비동기 버전파일 다운로드1
13156정성태11/7/20226790.NET Framework: 2064. C# - Mutex와 Semaphore/SemaphoreSlim 차이점파일 다운로드1
13155정성태11/4/20226290디버깅 기술: 183. TCP 동시 접속 (연결이 아닌) 시도를 1개로 제한한 서버
13154정성태11/3/20225771.NET Framework: 2063. .NET 5+부터 지원되는 GC.GetGCMemoryInfo파일 다운로드1
... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...