WEBVTT 00:00:00.274 --> 00:00:03.741 [컨테이너 채널] 00:00:03.741 --> 00:00:07.446 [컨테이너의 기초 Hyper-V 컨테이너] 00:00:07.446 --> 00:00:08.839 [컨테이너의 기초 Hyper-V 컨테이너 컨테이너 채널 Microsoft] >> 안녕하세요, 컨테이너 채널의 또 다른 00:00:08.839 --> 00:00:09.963 [Matt McSpirit 기술 전도사 컨테이너 채널 Microsoft] 에피소드입니다. 00:00:09.963 --> 00:00:12.862 [Matt McSpirit 기술 전도사 컨테이너 채널 Microsoft] 저는 Microsoft의 모든 데이터 센터 관련 사항에 대한 기술 전도사 Matt McSpirit입니다. 00:00:12.862 --> 00:00:14.460 [Matt McSpirit 기술 전도사 컨테이너 채널 Microsoft] Neil Peterson 씨가 다시 나오셨습니다. 00:00:14.460 --> 00:00:17.285 [컨테이너 채널 Microsoft Neil Peterson 수석 콘텐츠 개발자] Neil Peterson 씨는 Microsoft 컨테이너 공간의 콘텐츠 개발자십니다. 00:00:17.285 --> 00:00:20.285 [컨테이너 채널 Microsoft Neil Peterson 수석 콘텐츠 개발자] 컨테이너 기초에 대한 시리즈에 이어 00:00:20.285 --> 00:00:26.018 [컨테이너 기초 Hyper-V 컨테이너] 이번에는 Hyper-V 컨테이너에 대한 이 특별 에피소드에 초점을 맞춤으로써 이 시리즈를 00:00:26.018 --> 00:00:27.680 [컨테이너의 기초 Hyper-V 컨테이너 컨테이너 채널 Microsoft] 계속하려 합니다. 00:00:27.680 --> 00:00:30.245 [컨테이너의 기초 Hyper-V 컨테이너 컨테이너 채널 Microsoft] 그럼, Hyper-V 컨테이너와 우리가 알아야 00:00:30.245 --> 00:00:32.307 [컨테이너의 기초 Hyper-V 컨테이너 컨테이너 채널 Microsoft] 할 사항에 대해 말씀해 주시죠. 00:00:32.307 --> 00:00:34.071 [컨테이너 채널 Microsoft] >> 네. 감사합니다. 00:00:34.072 --> 00:00:35.072 [컨테이너 채널 Microsoft] 00:00:36.972 --> 00:00:40.022 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 여기서는 Hyper-V 컨테이너가 무엇인지 살펴보겠습니다. 00:00:40.022 --> 00:00:41.341 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 데모를 시작하기 전에 00:00:41.341 --> 00:00:44.234 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 몇 가지 간단한 안내를 하겠습니다. 00:00:44.234 --> 00:00:47.633 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] TP3에서는 Windows Server 컨테이너를 실현해 보았습니다. 00:00:47.633 --> 00:00:51.575 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] Windows Server 컨테이너는 00:00:51.575 --> 00:00:53.899 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 기본적으로 커널을 00:00:53.899 --> 00:00:55.086 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 컨테이너 호스트와 공유합니다. 00:00:55.086 --> 00:00:56.149 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] >> 네. 00:00:56.149 --> 00:00:57.168 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] >> 격리는 일련의 프로세스, 00:00:57.168 --> 00:01:00.418 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 네임스페이스 및 네트워크 격리 기술을 00:01:00.418 --> 00:01:03.915 [Hyper-v 컨테이너 Windows Server 컨테이너 - 프로세스, 네임스페이스 및 네트워크 격리 기술을 통한 격리.] 통해 이루어집니다. 00:01:03.915 --> 00:01:06.258 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] TP4에서 출시된 Hyper-V 컨테이너는 00:01:06.258 --> 00:01:09.392 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 고도로 최적화된 가상 컴퓨터에서 00:01:09.392 --> 00:01:10.543 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 컨테이너를 본질적으로 캡슐화함으로써 00:01:10.543 --> 00:01:13.516 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 추가적인 격리 레이어를 제공하여 Windows 00:01:13.516 --> 00:01:17.225 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] Server 컨테이너와 관련하여 우리가 00:01:17.562 --> 00:01:19.912 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 보유한 기능을 확장합니다. 00:01:19.912 --> 00:01:20.937 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] >> 네. 00:01:20.937 --> 00:01:22.102 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] >> 그런 이유로 Hyper-V 컨테이너죠. 00:01:22.102 --> 00:01:23.119 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 네, 그러니까, 전에 언급했을 때, 00:01:23.119 --> 00:01:24.826 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 말씀하셨던 컨테이너 00:01:24.826 --> 00:01:25.856 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 호스트는 본질적으로 00:01:25.856 --> 00:01:26.963 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 이러한 모든 서로 다른 00:01:26.963 --> 00:01:27.973 [Hyper-V 컨테이너 - 격리는 각 컨테이너를 고도로 최적화된 가상 컴퓨터에 배치함으로써 확장됩니다.] 컨테이너를 지원 및 00:01:27.973 --> 00:01:30.168 [컨테이너 채널 Microsoft] 실행하는 OS로서 실제 00:01:30.168 --> 00:01:33.537 [컨테이너 채널] 컴퓨터이거나 가상 컴퓨터일 수도 있는 거죠. 00:01:33.537 --> 00:01:34.744 [컨테이너 채널 Microsoft] >> 네. 그렇습니다. >> 좋습니다. 00:01:34.744 --> 00:01:37.529 [컨테이너 채널 Microsoft] 이렇게 두 가지 컨테이너 유형을 설명했습니다. 그중 하나는 Windows Server 컨테이너로, 00:01:37.529 --> 00:01:40.034 [컨테이너 채널 Microsoft] Windows Server 2016용 Technical Preview 3이고, 00:01:40.034 --> 00:01:43.846 [컨테이너 채널] 나머지 하나는 Hyper-V 컨테이너로, 2016용 Technical Preview 4입니다. 00:01:43.846 --> 00:01:44.848 [컨테이너 채널 Microsoft] >> 네. >> 그렇군요. 알겠습니다. 00:01:44.848 --> 00:01:45.848 [컨테이너 채널 Microsoft] >> 네. 00:01:45.848 --> 00:01:48.954 [컨테이너 채널 Microsoft] Windows Server 컨테이너와 Hyper-V 컨테이너가 무엇인지에 00:01:48.954 --> 00:01:52.456 [컨테이너 채널 Microsoft] 대한 아주 간단한 설명이었습니다. 00:01:52.456 --> 00:01:56.067 [컨테이너 채널] 제가 하려는 일은 일단 시작하여 그 두 유형을 살펴보고 비교 및 00:01:56.067 --> 00:01:57.188 [컨테이너 채널] 대조하는 것입니다. 00:01:57.188 --> 00:01:58.729 [컨테이너 채널 Microsoft] >> 그거 좋겠네요. 살펴보도록 하죠. 00:01:58.729 --> 00:01:59.783 [컨테이너 채널 Microsoft] >> 네. 00:01:59.783 --> 00:02:02.377 [컨테이너 채널 Microsoft] 우리가 살펴볼 데모는 기본적으로 세 개이며, 간단합니다. 00:02:02.377 --> 00:02:04.947 [Hyper-V 컨테이너 데모] 첫 번째로 수행할 것은 Windows Server 컨테이너를 만들고 00:02:04.947 --> 00:02:07.681 [Hyper-V 컨테이너 데모] 거의 진짜 컨테이너 호스트 관점에서 보고, 00:02:07.681 --> 00:02:10.217 [Hyper-V 컨테이너 데모] 호스트에서 실행되고 있는 프로세스를 살펴보고 00:02:10.217 --> 00:02:13.042 [Hyper-V 컨테이너 데모] 이것들을 다시 컨테이너 자체에 관련시키는 것입니다. 00:02:13.042 --> 00:02:15.487 [Hyper-V 컨테이너 데모] 그런 다음, 우리는 Hyper-V 컨테이너로 정확히 동일한 일을 수행하고 00:02:15.487 --> 00:02:16.639 [Hyper-V 컨테이너 데모] 그 차이를 살펴볼 것입니다. 00:02:16.639 --> 00:02:17.647 [Hyper-V 컨테이너 데모]>> 네. 00:02:21.013 --> 00:02:23.666 [Hyper-V 컨테이너 데모] 하지만, 이 PowerShell과 Docker를 확인하겠습니다. 00:02:23.666 --> 00:02:28.617 [Hyper-V 컨테이너 데모] 그런 다음 마지막으로, Windows Server 컨테이너를 만들고 00:02:28.617 --> 00:02:31.375 [Hyper-V 컨테이너 데모] 이 컨테이너를 Hyper-V 컨테이너로 변환하는 작업을 간단히 살펴보겠습니다. 00:02:31.375 --> 00:02:34.822 [Hyper-V 컨테이너 데모] >> 그러니까, 잠깐 말씀하셨듯이 PowerShell로 몇 가지 작업을 수행한 다음 00:02:34.822 --> 00:02:37.644 [Hyper-V 컨테이너 데모] >> Docker로도 몇 가지 작업을 수행하게 되는군요. 00:02:37.644 --> 00:02:39.738 [Hyper-V 컨테이너 데모] 에피소드와 관련한 질문 중 하나가, 00:02:39.738 --> 00:02:41.094 [Hyper-V 컨테이너 데모] 난처하게 하려는 것은 아니지만... 00:02:43.568 --> 00:02:45.329 [Hyper-V 컨테이너 데모] "각각은 언제 사용해야 하나요, 00:02:45.329 --> 00:02:47.234 [Hyper-V 컨테이너 데모] 그 결정은 내가 내려야 하는 것인가요. 00:02:47.234 --> 00:02:48.297 [Hyper-V 컨테이너 데모] 사람들이 생각을 해야 하는 00:02:48.297 --> 00:02:51.935 [Hyper-V 컨테이너 데모] 사항에 대해 아주 대략적으로라도 알려주실 수 있을까요? 00:02:51.935 --> 00:02:53.545 [Hyper-V 컨테이너 데모] PowerShell을 사용해야 할까요, Docker를 사용해야 할까요?" 뭐 이런 것입니다. 00:02:53.545 --> 00:02:55.781 [Hyper-V 컨테이너 데모] >> 알겠습니다. 그렇게 하겠습니다. 최선을 다해 보죠. 00:02:55.781 --> 00:02:57.161 [Hyper-V 컨테이너 데모] >> 예. >> 아직은 여전히 시기상조입니다. 00:02:57.161 --> 00:03:00.103 [Hyper-V 컨테이너 데모] 그러니까 아직 미리 보기지만, 아시다시피 00:03:00.103 --> 00:03:02.935 [Hyper-V 컨테이너 데모] 컨테이너와 PowerShell로 작업하면 그런 PowerShell 경험을 갖게 됩니다. 00:03:02.935 --> 00:03:05.987 [컨테이너 채널 Microsoft] 사실 여기에서는 스크립트를 작성하여 여러 컨테이너에 대해 00:03:05.987 --> 00:03:08.347 [컨테이너 채널] 일종의 스핀업을 수행한 많은 부분을 확인하고, 00:03:08.347 --> 00:03:13.308 [컨테이너 채널] 제게 익숙한 언어를 사용하여 이 컨테이너에 대해 원하는 작업을 수행하게 될 것입니다. 00:03:13.308 --> 00:03:16.178 [컨테이너 채널] Windows 사용자로서, 저는 PowerShell 관련 배경이 있으며, 00:03:16.178 --> 00:03:17.209 [컨테이너 채널] 이것은 제게는 거의 자연스러운 일입니다. 00:03:17.209 --> 00:03:18.217 [컨테이너 채널] >> 그렇죠. 00:03:18.217 --> 00:03:22.150 [컨테이너 채널] >> 그리고 또, 아시다시피 Docker는 오랫동안 존재해왔으며, 00:03:22.150 --> 00:03:27.880 [컨테이너 채널] 컨테이너를 관리하고 매우 면밀하게 만들어진 도구가 있습니다. 00:03:27.880 --> 00:03:31.882 [컨테이너 채널] 우리에겐 Windows Server와 Hyper-V 컨테이너와 관련해서도 이러한 기능을 가지고 있습니다. 00:03:31.882 --> 00:03:34.760 [컨테이너 채널] 그러니까 제 말은 사용자에게 00:03:34.760 --> 00:03:37.788 [컨테이너 채널] 가장 적합한 관리 환경을 선택하는 문제라는 것입니다. 00:03:37.788 --> 00:03:40.308 [컨테이너 채널] >> 그럼 아마도 사용자가 전체 바닐라에서 00:03:40.308 --> 00:03:42.592 [컨테이너 채널 Microsoft] 이것에 접근하는 경우, 전 Docker는 사용해 본 적이 없습니다만, 00:03:42.592 --> 00:03:45.791 [컨테이너 채널] 사용자는 PowerShell에서 사용자가 필요로 하는 것을 제공하지만, 그때 Docker 도구 집합은 00:03:45.791 --> 00:03:48.898 [컨테이너 채널] 말씀하신 대로 약간 더 성숙하겠군요. 현재 특히 Linux와 00:03:48.898 --> 00:03:52.288 [컨테이너 채널] 관련하여 우리가 PowerShell에서 제공할 수 있는 것 이상의 추가 범위에 적용할 수 있군요. 00:03:52.288 --> 00:03:54.256 [컨테이너 채널] 따라서 사용자는 더 많은 작업을 할 수도 있지만 00:03:54.256 --> 00:03:57.019 [컨테이너 채널] Windows Server 컨테이너의 경우 너무 멀리 떨어지진 않습니다. 00:03:57.019 --> 00:03:58.306 [컨테이너 채널] >> 그렇습니다. >> 그러면 많은 일을 할 수 있겠군요. 00:03:58.306 --> 00:03:59.352 [컨테이너 채널] >> 그렇죠. 00:03:59.352 --> 00:04:00.932 [컨테이너 채널] >> 그러면 Neil이 데모를 수행할 때에도 진행함에 따라 00:04:00.932 --> 00:04:02.837 [컨테이너 채널] 몇 가지 미묘한 차이가 있는 것을 확인할 수 있겠군요. 00:04:02.837 --> 00:04:05.329 [컨테이너 채널] 우린 이전의 일부 데모에서도 이것을 확인했습니다. 00:04:05.329 --> 00:04:08.005 [컨테이너 채널] 그럼, 그 첫 번째 데모를 보여주세요. 00:04:08.005 --> 00:04:09.371 여기에서 우리가 보고 있는 것이 뭐죠? 00:04:09.371 --> 00:04:13.136 >> 예. 이제 제가 수행할 작업은 Windows Server 컨테이너를 만드는 것입니다. 00:04:13.136 --> 00:04:16.546 사실, PowerShell을 사용할 준비가 모두 되었습니다. 00:04:16.546 --> 00:04:17.568 >> 예. 00:04:17.568 --> 00:04:20.446 >> 그럼, Windows Server 주요 이미지를 위한 새 컨테이너를 만들어 보겠습니다. 00:04:20.446 --> 00:04:21.511 >> 예. 00:04:21.511 --> 00:04:23.202 >> 그리고 사용자는 이전 비디오에서 일반 Windows Server 컨테이너 만들기를 00:04:23.202 --> 00:04:25.626 수행했으므로 이것에 익숙해져 있을 거고요. 00:04:25.626 --> 00:04:26.657 >> 네. 네. 그렇습니다. 00:04:26.657 --> 00:04:29.598 여기서 많은 세부 사항을 일일이 다루지는 않겠습니다. 00:04:29.598 --> 00:04:32.193 하지만 이전 비디오의 일부 사항에 대해서는 짚고 넘어간 00:04:32.193 --> 00:04:34.440 다음 컨테이너를 시작하겠습니다. 00:04:34.440 --> 00:04:37.571 그런 다음, 컨테이너에 대해 invoke command를 00:04:37.571 --> 00:04:38.580 실행하고 기본적으로 ping local host를 00:04:38.580 --> 00:04:41.936 수행할 수 있도록 해당 컨테이너 내에서 00:04:41.936 --> 00:04:44.053 프로세스를 시작하는 것입니다. 00:04:44.053 --> 00:04:45.078 >> 그렇군요. 00:04:45.078 --> 00:04:48.237 >> 그럼, 실행 상태를 유지하는 ping 프로세스를 시작하도록 하겠습니다. 00:04:48.237 --> 00:04:49.768 >> 예, 저것은 어떤 것이든 될 수 있죠. 00:04:49.768 --> 00:04:52.300 고급 스크립트가 될 수도 있고, 어떤 것이든 시작해야 하는 00:04:52.300 --> 00:04:53.674 어떤 서비스 종류가 될 수도 있죠. 00:04:53.674 --> 00:04:56.472 >> 예. 그렇습니다. 00:04:56.472 --> 00:05:01.547 그럼 시작되는 동안 컨텍스트에서 00:05:01.547 --> 00:05:03.860 저는 컨테이너 호스트에 대해 여기에서 작업 중입니다. 00:05:03.860 --> 00:05:06.817 따라서 지금 당장 우리는 컨테이너 호스트에 있습니다. 00:05:06.817 --> 00:05:09.921 작업 중인 호스트에서 컨테이너를 시작했습니다. 00:05:09.921 --> 00:05:11.002 >> 네. 00:05:11.002 --> 00:05:14.750 >> 그럼 이제 계속해서 이것을 최소화하고 호스트를 확인하고, 00:05:14.750 --> 00:05:18.917 여기를 쭉 스크롤 하면 프로세스를 보면 00:05:18.917 --> 00:05:20.084 ping.exe 프로세스가 실행되는 것을 보게 됩니다. 00:05:20.084 --> 00:05:21.098 >> 네. 00:05:21.098 --> 00:05:22.892 >>우리는 컨테이너 호스트에서 이 프로세스를 보고 있는 것입니다. 00:05:22.892 --> 00:05:25.550 >> 예. >> 또 수행할 작업은... 00:05:25.550 --> 00:05:27.248 >> 컨테이너 내에서 실행 중이더라도요. 00:05:27.248 --> 00:05:28.257 >> 컨테이너 내에서도요. >> 네. 00:05:28.257 --> 00:05:30.422 >> 네. 그리고 여기에서 그 차이를 확인하게 될 것입니다. 00:05:30.422 --> 00:05:33.100 제 말은 Windows Server 컨테이너와 Hyper-V 컨테이너 간에 00:05:33.100 --> 00:05:34.619 매우 분명한 차이가 있다는 것입니다. 00:05:34.619 --> 00:05:39.219 >> 실제로 이 컨테이너 내 세션에 들어가겠습니다. 00:05:45.131 --> 00:05:48.358 그럼 여기서 볼 수 있습니다. 제가 컨테이너 내부에 원격 00:05:48.358 --> 00:05:49.388 PowerShell 세션을 가지고 있습니다. 00:05:49.388 --> 00:05:51.736 >> 그리고 여기 ping이 있는 이유는 컨테이너를 호출했기 때문이죠. 00:05:51.736 --> 00:05:53.109 >> 예, 제가 container ping을 호출했기 때문이죠. 00:05:53.109 --> 00:05:55.805 >> 예. 00:05:55.805 --> 00:05:57.900 >> 그리고 get process를 실행하면, 00:06:00.690 --> 00:06:04.370 시간이 좀 걸리고 있네요. 00:06:04.370 --> 00:06:06.377 >> 가끔 저렇게 되더군요. PowerShell을 완료하는 것이 쉽지 않습니다. 00:06:06.377 --> 00:06:07.405 >> 됐네요. >> 네. 00:06:07.405 --> 00:06:09.338 >> 충분히 기다렸습니다. 00:06:09.338 --> 00:06:10.354 >> 네. 00:06:10.354 --> 00:06:16.639 이제, 컨테이너의 보기 내에서 프로세스 ping도 볼 수 있습니다. 00:06:16.639 --> 00:06:20.165 여기 프로세스 ID가 4556인 것이 보이는데요. 00:06:20.165 --> 00:06:22.558 이 ID는 우리가 호스트의 보기에서 보고 있는 00:06:22.558 --> 00:06:23.740 프로세스 ID와 일치합니다. 00:06:23.740 --> 00:06:26.196 실제로 여기 호스트 보기에서 볼 수 있습니다. 00:06:26.196 --> 00:06:29.900 [작업 관리자] 이 프로세스를 중단합니다. 삭제되고... 00:06:29.900 --> 00:06:32.410 네. 그런 다음 다시 get process를 수행하면, 00:06:32.410 --> 00:06:33.480 >> 없어졌습니다. >> 없어졌습니다. 00:06:33.480 --> 00:06:34.638 >> 여기 있네요. 00:06:34.638 --> 00:06:38.025 >> 그럼, 여기 해당 공유 커널이 보입니다. 00:06:38.025 --> 00:06:40.847 즉, 여기에서는 격리가 이루어지고 있지만, 여전히 우린 00:06:40.847 --> 00:06:44.460 일부 작업을 컨테이너 호스트에 노출시키고 있는 것입니다. 00:06:44.460 --> 00:06:45.501 그러니까... 00:06:47.038 --> 00:06:50.948 Hyper-V 컨테이너에 대해 말했듯이, 이것에 상당한 변화를 줍니다. 00:06:50.948 --> 00:06:56.058 그러면 공유 커널 아키텍처를 갖는 대신, 00:06:56.058 --> 00:06:59.849 이제 우리는 가상 컴퓨터 내부에 컨테이너를 놓게 됩니다. 00:06:59.849 --> 00:07:01.237 최적화 수준이 매우 높은 가상 컴퓨터 내부에 말이죠. 00:07:01.237 --> 00:07:05.202 >> 하지만 이것은 저나 Peterson 씨가 아니라 관리자가 수행해야 할 일이죠. 00:07:05.202 --> 00:07:06.820 아시다시피, 제가 Hyper-V 관리자에게 가서 00:07:06.820 --> 00:07:12.497 특별 VM을 만들고 로드하여 부팅한 다음, 새 VM 내에서 캡슐화되는 00:07:12.497 --> 00:07:15.221 컨테이너를 그 내부에서 만드는 등의 작업을 할 필요가 없습니다. 00:07:15.221 --> 00:07:16.271 그런 것을 걱정할 필요가 없죠. 00:07:16.271 --> 00:07:18.782 >> 네, 그렇죠. 그 점이 훌륭한 점이죠. 00:07:18.782 --> 00:07:22.173 사실 관리 환경은 동일합니다. 00:07:22.173 --> 00:07:23.750 >> 맞습니다. 00:07:23.750 --> 00:07:26.091 >> 작은 스위치가 하나 빠졌네요. 여기에서 살펴보겠습니다. 00:07:26.091 --> 00:07:27.112 >> 네. 좋습니다. 00:07:27.112 --> 00:07:29.082 >> 그럼, 저는 실제로 계속해서 이것을 작동시킨 다음, 00:07:29.082 --> 00:07:30.742 여기에서 할 작업에 대해 설명하겠습니다. 00:07:30.742 --> 00:07:33.310 물론 그렇게 많은 차이가 없는지 여부도 확인하게 될 것입니다. 00:07:33.310 --> 00:07:34.969 그럼 다시 새 컨테이너를 실행합니다. 00:07:34.969 --> 00:07:38.429 여기 컨테이너 이름을 hypv로 지정합니다. 00:07:38.429 --> 00:07:41.300 컨테이너 이미지를 선택하면 여기에서 Nano Server 00:07:41.300 --> 00:07:42.974 이미지가 선택된 것을 알 수 있습니다. 00:07:42.974 --> 00:07:44.387 >> 이 컨테이너에 대한 기본 이미지군요. 00:07:44.387 --> 00:07:47.985 >> 이 컨테이너에 대한 기본 이미지이므로 TP4 Hyper-V 컨테이너에서는 00:07:47.985 --> 00:07:49.854 Nano Server의 이미지를 실행 중이어야 합니다. 00:07:49.854 --> 00:07:52.771 >> 네. 좋습니다. 00:07:52.771 --> 00:07:56.655 >> 여기 Hyper-V 컨테이너임을 나타내는 00:07:56.655 --> 00:08:00.577 스위치가 있으므로 우린 런타임 Hyper-V를 선택합니다. 00:08:00.577 --> 00:08:03.302 이건 기본적으로, 즉 바로 여기에서 큰 차이가 있는 거죠. 00:08:03.302 --> 00:08:04.785 Windows server 컨테이너와 Hyper-V 컨테이너 간의 00:08:04.785 --> 00:08:06.865 큰 차이는 런타임을 선택하는 것입니다. 00:08:06.865 --> 00:08:08.437 >> 적어도 배포 관점에서 말이죠. 00:08:08.437 --> 00:08:09.468 >> 네. 네. 그렇습니다. 00:08:09.468 --> 00:08:11.125 >> 예. 00:08:11.125 --> 00:08:13.852 >> 그런 다음 볼 수 있듯이 컨테이너를 시작한 다음 00:08:13.852 --> 00:08:15.484 정확히 동일한 작업을 수행했습니다. 00:08:15.484 --> 00:08:18.843 명령 ping local host -t를 호출하여 00:08:18.843 --> 00:08:20.983 해당 프로세스를 계속 실행했습니다. 00:08:20.983 --> 00:08:22.142 >> 네. 00:08:22.142 --> 00:08:25.575 >> 그럼, 같은 작업을 수행하겠습니다. 여기 호스트로 이동합니다. 00:08:25.575 --> 00:08:29.259 그리고 이제는 ping 프로세스가 표시되지 않는 것을 보게 됩니다. 00:08:29.259 --> 00:08:30.278 >> 네. 00:08:30.278 --> 00:08:33.716 >> 해당 컨테이너가 저렇게 높은 수준으로 최적화된 00:08:33.716 --> 00:08:36.904 가상 컴퓨터에서 캡슐화되어 있으므로 모두 그 내부에 있습니다. 00:08:36.904 --> 00:08:37.947 >> 네. 00:08:37.947 --> 00:08:39.663 >> 우리가 알 수 있는 사항이 두 가지 있는데요. 00:08:39.663 --> 00:08:42.712 get container...select 별표를 실행하면 00:08:47.628 --> 00:08:51.167 여기에 컨테이너 ID가 표시됩니다. 00:08:52.694 --> 00:08:57.054 호스트에서 여기 아래로 스크롤 하면 프로세스 목록에 00:08:57.054 --> 00:08:59.223 VM 작업자 프로세스가 있습니다. 00:08:59.223 --> 00:09:03.913 이것이 가상 컴퓨터를 나타내는 Hyper-V 프로세스입니다. 00:09:03.913 --> 00:09:06.863 사용자 이름을 보면 이 VM 작업자 프로세스상의 00:09:06.863 --> 00:09:12.051 사용자 이름이 컨테이너의 ID와 일치하는 것을 볼 수 있습니다. 00:09:12.051 --> 00:09:15.469 즉, 내 Hyper-V 컨테이너에 호스트 상의 프로세스와의 상관관계를 00:09:15.469 --> 00:09:18.204 지정하는 방법이 있습니다. 하지만, 우리가 컨테이너 내에서 00:09:18.204 --> 00:09:20.273 실행하는 프로세스를 확인하지는 않습니다. 00:09:20.273 --> 00:09:22.138 >> 게다가, Hyper-V 관리자에서도 00:09:22.138 --> 00:09:23.777 이것을 확인하지 않을 것 같군요. 00:09:23.777 --> 00:09:25.258 >> 않습니다. >> VM이더라도 말이죠. 00:09:25.258 --> 00:09:27.894 >> 예. 그렇습니다. 예. 거기에서 그렇습니다. 00:09:27.894 --> 00:09:30.130 이제 컨테이너 자체로 이동하는 경우... 00:09:36.052 --> 00:09:38.874 컨테이너에 들어가 보면 00:09:38.874 --> 00:09:40.288 ping 프로세스가 실행 중일 것입니다. 00:09:40.288 --> 00:09:41.436 >> 네. 00:09:48.116 --> 00:09:50.914 >> 여기 있습니다. 00:09:50.914 --> 00:09:53.366 Windows Server 컨테이너를 보고 00:09:53.366 --> 00:09:55.632 [컨테이너 채널 Microsoft] Hyper-V 컨테이너를 보고, 00:09:55.632 --> 00:09:58.315 [컨테이너 채널 Microsoft] 이것들이 호스트 관점에서 어떻게 다른지를 00:09:58.315 --> 00:09:59.519 [컨테이너 채널 Microsoft] 보는 간단한 예입니다. 00:09:59.519 --> 00:10:02.969 [컨테이너 채널 Microsoft] >> 그러니까 예를 들어 서비스 공급자이거나, 00:10:02.969 --> 00:10:07.505 [컨테이너 채널] 컨테이너에서 작업을 실행하는 것에 대해 걱정이 있을 경우, 00:10:07.505 --> 00:10:09.581 [컨테이너 채널] 여기에서 큰 이점 있군요. 아마도 작업이 ping보다 거의 중요할 수 있는 00:10:09.581 --> 00:10:13.336 [컨테이너 채널] 공유 또는 다중 테넌트 환경이고요. 00:10:13.336 --> 00:10:17.427 [컨테이너 채널] Hyper-V 컨테이너를 사용하면 VM을 통해 제공되는 하드웨어 격리와 00:10:17.427 --> 00:10:19.607 [컨테이너 채널] 같은 추가적인 격리와 동시에 컨테이너 자체의 이점과 00:10:19.607 --> 00:10:22.376 [컨테이너 채널] 이식성도 여전히 제공하는군요. 00:10:22.376 --> 00:10:23.461 [컨테이너 채널] >> 네. 그렇습니다. 00:10:23.461 --> 00:10:25.168 [컨테이너 채널] >> 그리고, 꼭 관리해야 할 필요도 없고요. 00:10:25.168 --> 00:10:28.498 [컨테이너 채널] 우리가 수행했던 그 스위치 하나와는 다르게 말이죠. 00:10:28.498 --> 00:10:29.857 [컨테이너 채널 Microsoft] >> 네. 그렇습니다. 00:10:29.857 --> 00:10:35.763 [컨테이너 채널 Microsoft] 그리고 여기까지가 PowerShell로 그러한 작업을 수행하는 예였습니다. 00:10:35.763 --> 00:10:37.963 Docker로 동일한 기능을 사용할 수 있습니다. 00:10:39.152 --> 00:10:44.858 이것을 사용하겠습니다. 00:10:44.858 --> 00:10:48.186 그러면 여기에서 표준 Docker 실행 명령을 사용합니다. 00:10:48.186 --> 00:10:49.209 >> 예. 00:10:49.209 --> 00:10:52.780 >> docker run -it은 대화형 세션을 시작합니다. 00:10:52.780 --> 00:10:53.833 >> 예. 00:10:53.833 --> 00:10:56.085 >>여기에 스위치가 있는 것을 볼 수 있습니다. 00:10:56.085 --> 00:10:58.526 따라서 isolation은 Hyper-V와 같습니다. 00:10:58.526 --> 00:10:59.629 >> 네. 00:10:59.629 --> 00:11:03.250 >> 그런 다음 실행하려는 이미지의 ID를 가져왔습니다. 이 이미지는 Nano Server 이미지입니다. 00:11:03.250 --> 00:11:05.127 그런 다음 명령 셸을 시작합니다. 00:11:07.534 --> 00:11:09.683 이것을 실행하면, 다시 다른 VM 작업자 프로세스가 00:11:09.683 --> 00:11:12.826 시작된 것을 실제로 볼 수 있습니다. 00:11:12.826 --> 00:11:13.999 >> 네. 00:11:13.999 --> 00:11:16.457 >> Hyper-V 컨테이너가 생성되도록 말이죠. 00:11:16.457 --> 00:11:17.626 >> 네. 00:11:17.626 --> 00:11:20.527 따라서 Docker를 통해 수행했든 PowerShell을 통해 수행했든 관계없이 00:11:20.527 --> 00:11:22.655 최종 결과는 여전히 동일합니다. 00:11:22.655 --> 00:11:24.445 >> 아시다시피 여기에 차이점이 하나 있는 것 같군요. 00:11:24.445 --> 00:11:27.130 처음 시작할 때 지정한 명령이었으므로 00:11:27.130 --> 00:11:30.609 여기 Docker에서 명령줄 보기가 표시되었습니다. 00:11:30.609 --> 00:11:31.831 멋지네요. 00:11:31.831 --> 00:11:36.260 >> 이제 Windows Server 컨테이너와 Hyper-V 컨테이너에 대해 정리하는 마지막 한 가지가 있습니다. 00:11:36.260 --> 00:11:39.183 둘 간에 동일한 관리 환경에 대해 이야기 했었죠. 00:11:39.183 --> 00:11:42.074 정말 그렇습니다. 00:11:42.074 --> 00:11:44.003 하지만, 이 시점에서 00:11:44.003 --> 00:11:46.546 [컨테이너 채널 Microsoft] 우리는 Windows Server 컨테이너를 가져와서 00:11:46.546 --> 00:11:50.705 [컨테이너 채널 Microsoft] 개발하고 작동시키고, 실제로 이것을 00:11:50.705 --> 00:11:52.037 [컨테이너 채널 Microsoft] Hyper-V 컨테이너로 변환할 수 있습니다. 00:11:52.037 --> 00:11:54.107 [컨테이너 채널 Microsoft] >> 그럼, 제가 개발자이고 컨테이너에서 패키지로 넣을 00:11:54.107 --> 00:11:57.372 [컨테이너 채널 Microsoft] 응용 프로그램을 만들고 있다면 Windows 서버에서 실행하겠군요. 00:11:57.372 --> 00:11:58.733 [컨테이너 채널] 아마도 테스트 환경에서 말이죠. 00:11:58.733 --> 00:12:01.725 [컨테이너 채널] 황야의 고립된 환경에서 살아야 한다면, 00:12:01.725 --> 00:12:03.566 [컨테이너 채널] 응용 프로그램을 변경해야 하고요. 00:12:03.566 --> 00:12:04.850 [컨테이너 채널] >> 그렇죠. >> 알겠습니다. 멋지네요. 00:12:04.850 --> 00:12:05.920 [컨테이너 채널 Microsoft] >> 그럼 그 예를 살펴보겠습니다. 00:12:05.920 --> 00:12:07.239 그럼, 여기에 있는 것은 00:12:07.239 --> 00:12:09.557 [사용자 이름: 암호: 도메인:] Nano Server 컨테이너 호스트입니다. 00:12:17.686 --> 00:12:19.830 [Nano Server 복구 콘솔] 여기 IP 주소가 보이죠. 00:12:19.830 --> 00:12:23.944 [Nano Server 복구 콘솔] 그리고 알고 있듯이 우리는 Nano Server에 로컬 로그를 보유하고 있지 않습니다. 00:12:23.944 --> 00:12:26.533 [Nano Server 복구 콘솔] 따라서 제 랩톱에서 저 Nano Server 컨테이너 호스트로 만든 두 개의 00:12:26.533 --> 00:12:29.273 PowerShell 세션을 가져왔습니다. 00:12:29.273 --> 00:12:31.139 >> 네. 00:12:31.139 --> 00:12:37.072 >> 전에 했던 것처럼, 이를 위해 이미 작성한 스크립트를 좀 가져왔습니다. 00:12:41.540 --> 00:12:45.712 첫 번째 스크립트에서는 컨테이너를 만들겠습니다. 00:12:45.712 --> 00:12:49.830 그러면 새로운 컨테이너 이름은 ping이고, 컨테이너 이미지 Nano Server, 스위치 이름... 00:12:49.830 --> 00:12:51.486 스위치에 할당합니다. 00:12:51.486 --> 00:12:54.124 >> 예. >> ping 프로세스를 시작하겠습니다. 00:12:55.130 --> 00:12:56.524 죄송합니다. 컨테이너를 시작한 다음, 00:12:56.524 --> 00:13:01.104 전에 본 것처럼 ping 프로세스를 실행하겠습니다. 00:13:01.104 --> 00:13:04.810 다시, Nano Server 호스트에서 Windows Server 컨테이너를 만듭니다. 00:13:08.981 --> 00:13:11.941 이제 컨테이너를 시작합니다. 00:13:11.941 --> 00:13:13.023 >> 그러니까... 00:13:13.023 --> 00:13:14.345 Windows Server 컨테이너라 하더라도 00:13:14.345 --> 00:13:16.313 여전히 Nano 기반의 Windows Server 컨테이너인 거죠. 00:13:16.313 --> 00:13:17.396 >> 예, 여전히 Nano 기반 이미지입니다. 00:13:17.396 --> 00:13:20.647 TP4에는 어떤 기본 OS 이미지가 어떤 호스트에서 00:13:20.647 --> 00:13:23.727 실행될 수 있는지 등에 대한 제한이 있습니다. 00:13:23.727 --> 00:13:25.950 >> 예. 00:13:25.950 --> 00:13:30.060 >> 호스트에서 get process를 실행하면 00:13:30.060 --> 00:13:35.734 ping 프로세스가 있어서 Windows Server 컨테이너 프로세스가 00:13:35.734 --> 00:13:37.101 호스트에 노출되는 것을 볼 수 있습니다. 00:13:37.101 --> 00:13:38.104 >> 예. 00:13:38.104 --> 00:13:42.860 >> 그럼 이제 이 컨테이너를 해제하여 새 컨테이너를 만드는 대신 00:13:42.860 --> 00:13:47.377 똑같은 컨테이너를 가져오겠습니다. 00:13:47.377 --> 00:13:51.316 get container를 수행하면, 여기 제 컨테이너가 있죠. 00:13:51.316 --> 00:13:52.414 이름이 ping이었죠. 00:13:52.414 --> 00:13:56.021 >> 예. 00:13:56.021 --> 00:13:58.352 >> 여기 또 다른 스크립트인 데모 2가 있습니다. 00:13:58.352 --> 00:14:02.445 화면에 스크립트의 텍스트를 반환하는 type을 실행 중입니다. 00:14:02.445 --> 00:14:03.471 >> 예. 00:14:03.471 --> 00:14:05.493 >> 컨테이너를 중지하겠습니다. 00:14:05.493 --> 00:14:08.876 이제 set container ping 명령을 실행하고, 00:14:08.876 --> 00:14:11.333 런타임을 Hyper-V로 설정합니다. 00:14:11.333 --> 00:14:12.842 >> ping이 컨테이너의 이름이 되죠... 00:14:12.842 --> 00:14:15.289 >> ping이 컨테이너의 이름이 되죠. 네, 그렇습니다. 00:14:15.289 --> 00:14:18.368 컨테이너를 시작한 다음, 다시 똑같은 작업을 수행하겠습니다. 00:14:18.368 --> 00:14:20.895 명령을 호출하고 ping 프로세스를 다시 시작합니다. 00:14:20.895 --> 00:14:24.459 >> 모든 것이 정상적으로 작동하면 오른쪽에는 다음으로 프로세스를 진행하면 ping이 사라지는 것을 보게 되겠죠. 00:14:24.459 --> 00:14:26.829 다음 프로세스를 단계별로 실행할 때 해당 ping이 사라집니다. 00:14:26.829 --> 00:14:27.841 >> 예. 00:14:27.841 --> 00:14:29.471 >> 실행 중이었던 컨테이너를 중단했으므로, 00:14:29.471 --> 00:14:32.020 이제는 Hyper-V 컨테이너 내부에 캡슐화되어 있는 것이 00:14:32.020 --> 00:14:33.323 보이지 않습니다. 00:14:33.323 --> 00:14:36.392 >> 그뿐만 아니라 VM 작업자 프로세스 시작이 보입니다. 00:14:36.392 --> 00:14:37.904 >> 예. 됐습니다. 00:14:37.904 --> 00:14:39.745 >> 그리고 여기서 보고 있는 것이 호스트의 00:14:39.745 --> 00:14:43.178 프로세스와 실행 중인 컨테이너의 프로세스이므로, 00:14:43.178 --> 00:14:45.909 사실 우리가 보게 되는 것은 이 프로세스 목록이 많이 줄어드는 것입니다. 00:14:45.909 --> 00:14:47.014 >> 네. 00:14:48.570 --> 00:14:52.629 >> 그럼 계속해서 이 스크립트를 실행하여 이것을 중지시켰다가, 00:14:52.629 --> 00:14:54.362 변환을 수행하고 다시 실행시키는 데 사용하겠습니다. 00:15:04.281 --> 00:15:05.436 프로세스를 가져옵니다. 00:15:05.436 --> 00:15:08.534 목록이 많이 감소한 것을 볼 수 있습니다. 00:15:08.534 --> 00:15:13.915 해당 VM 작업자 프로세스가 시작되었죠. 다 되었습니다. 00:15:13.915 --> 00:15:15.362 >> 멋지네요. 00:15:15.362 --> 00:15:20.482 그럼 Nano에 상관없이 일반적인 Windows Server 컨테이너 간에 00:15:20.482 --> 00:15:24.051 [Hyper-V 컨테이너 데모 클릭하여 메모 추가] 얼마나 쉽게 트래버스할 수 있는지를 이 사례에서 보았습니다. 00:15:24.051 --> 00:15:26.533 [Hyper-V 컨테이너 데모 클릭하여 메모 추가] Nano 컨테이너와 Hyper-V 컨테이너 간에, 00:15:26.533 --> 00:15:32.514 [컨테이너 채널 Microsoft] 우리는 Windows Server 컨테이너와 새로운 Hyper-V 기반 컨테이너를 만드는 것이 얼마나 쉬운지를 보였습니다. 00:15:32.514 --> 00:15:33.514 [컨테이너 채널 Microsoft] 00:15:33.514 --> 00:15:36.423 [컨테이너 채널 Microsoft] 어렵지 않습니다. 모든 것이 설명서에 있어서 쉽게 배울 수도 있습니다. 00:15:36.423 --> 00:15:37.431 [리소스 읽기 컨테이너 설명서 Microsoft와 Docker 파트너 관계 Docker 시작] >> 예. 그렇습니다. 00:15:37.431 --> 00:15:40.190 [리소스 읽기 컨테이너 설명서 Microsoft와 Docker 파트너 관계 Docker 시작] >> 예. 그럼 이것으로 컨테이너 기초를 위한 컨테이너 채널의 00:15:40.190 --> 00:15:42.995 [컨테이너 채널 Microsoft] 이 특별 에피소드를 마무리합니다. 00:15:42.995 --> 00:15:44.151 [컨테이너 채널 Microsoft] 즐거운 시간이었기를 바랍니다. 00:15:44.151 --> 00:15:46.196 [컨테이너 채널 Microsoft] 리소스를 확인하시면 훨씬 더 자세한 정보를 얻을 수 있습니다. 00:15:46.196 --> 00:15:49.043 [컨테이너 채널 Microsoft] 기술 미리 보기를 다운로드하여 직접 수행해 보세요. 00:15:49.043 --> 00:15:50.723 [컨테이너 채널 Microsoft] Azure에서도 실행할 수 있습니다. 00:15:50.723 --> 00:15:53.568 [컨테이너 채널 Microsoft] Azure에는 배울 것이 많습니다. 컨테이너 채널에 대한 또 다른 에피소드를 00:15:53.568 --> 00:15:55.348 [컨테이너 채널 Microsoft] 보려면 차후에 다시 함께해 주세요. 00:15:55.348 --> 00:15:56.434 [컨테이너 채널 Microsoft] 감사합니다. 00:15:56.434 --> 00:15:57.502 [컨테이너 채널 Microsoft] >> 감사합니다. 00:15:57.502 --> 00:16:02.397 [리소스 다운로드 Windows Server 2016 기술 미리 보기 컨테이너 설명서 읽기 Microsoft와 Docker 파트너 관계 Docker 시작] 00:16:02.397 --> 00:16:07.277 [컨테이너 채널] 00:16:10.058 --> 00:16:12.915 [9 channel9.msdn.com]