Docker는 현재 매우 인기가 있으며 컨테이너 기술은 전능 한 것으로 보이지만 실제로는 오해입니다. 과대 광고 거품에 매료되지 마십시오. 이 기사는 과대 광고를 버리고 Docker의 장점과 문제를 더 잘 이해하는 데 도움이되는 Java 프로그래머의 관점에서 Docker의 현재 5 가지 오해를 합리적으로 나열합니다.
미디어와 제조업체의 과대 광고를 제쳐두고 Docker는 어떻게 더 나은 합리적으로 사용할 수 있습니까?
Docker는 최근에 많은 관심을 끌었으며 그 이유는 분명합니다. 코드를 성공적으로 전달하는 방법은 항상 모든 사람에게 어려움을 겪었습니다. 전통적인 컨테이너 기술은 많은 요구와 템플릿 중에서 혼란 스럽습니다. Docker는 컨테이너를 간단하고 반복적으로 만들 수 있습니다. Docker를 사용하면 다른 컨테이너보다 빠르고 자연스러운 코드 전달이 가능합니다. Duang, Docker는 인기가 있습니다! 몇 가지 오해와 오해도 있습니다. Docker가 사용하기 쉬운지 아닌지 다른 사람들을 믿지 마십시오. Docker에 대해 합리적으로 그리고 포괄적으로 생각하면 실제로 필요한지 여부를 진정으로 이해하는 데 도움이됩니다.
이 기사에는 Java 관점에서 5 개의 주요 Docker Misreadings가 나와 있습니다. 그러나 먼저 배경 지식을 소개합니다. Docker를 더 잘 이해하기 위해, 우리는 광범위한 Docker 경험을 가지고 있으며 Devops Days Conference의 주최자 인 Avishai Ish-Shalom의 Avishai Ish-Shalom과 상담했습니다. 우리는 이러한 오해를 그와 나열했습니다.
주요 오해
1. Docker는 가벼운 가상 머신입니다
이것은 초보자 Docker 일 때 주요 오해입니다. 이 오해는 이해할 수 있습니다. Docker는 가상 머신처럼 보입니다. 어떤 사람들은 Docker 웹 사이트에서 Docker와 Virtual Machines의 차이를 비교합니다. 그러나 Docker는 실제로 가벼운 가상 머신이 아니라 LXC (Linux 컨테이너 개선)입니다. Docker와 Virtual Machines는 완전히 다릅니다. Docker 컨테이너를 가벼운 가상 머신으로 사용하면 많은 문제가 발생합니다.
Docker를 사용하기 전에 Docker 컨테이너와 가상 머신 사이에는 많은 필수 차이가 있음을 이해해야합니다.
자원 격리 : Docker는 가상 머신이 제공 할 수있는 자원 격리 수준에 도달 할 수 없습니다. 가상 머신의 리소스는 고도로 분리되어 있으며 Docker는 처음부터 일부 리소스를 공유해야했습니다. 이러한 리소스는 Page Cache 및 Kernel Entropy Pool과 같은 Docker에 의해 분리 및 보호 할 수 없습니다. (참고 : 커널 엔트로피 풀은 흥미롭고 시스템 작업에 의해 생성 된 임의 비트를 수집하고 저장합니다. 기계는 암호 관련과 같이 무작위 배정해야 할 때이 풀을 사용합니다.) Docker 컨테이너가 이러한 공유 리소스를 차지하면 다른 프로세스는 이러한 리소스가 해제되기 전에만 기다릴 수 있습니다.
오버 헤드 : 대부분의 사람들은 가상 머신의 CPU 및 RAM이 물리적 기계와 같은 성능을 제공 할 수 있지만 추가 IO 오버 헤드가 많이 있습니다. 가상 머신의 게스트 OS가 포기되기 때문에 Docker의 패키지는 더 작으며 가상 머신보다 저장된 오버 헤드가 적습니다. 그러나 이것이 Docker가 오버 헤드 문제가 없다는 것을 의미하지는 않습니다. 도커 컨테이너는 여전히 IO 오버 헤드에주의를 기울여야하지만 가상 머신만큼 심각하지는 않습니다.
커널 사용 : Docker 컨테이너 및 가상 머신은 커널 사용에서 완전히 다릅니다. 각 가상 머신은 하나의 커널을 사용합니다. 도커 컨테이너는 모든 컨테이너 중에서 커널을 공유합니다. 공유 커널은 효율성을 높이지만 고 가용성과 중복성을 희생시킵니다. 가상 머신에서 커널 충돌이 발생하면이 커널의 가상 시스템 만 영향을받습니다. Docker 컨테이너의 커널이 충돌하면 모든 컨테이너가 영향을받습니다.
2. Docker는 응용 프로그램을 확장 가능하게 만듭니다
Docker는 매우 짧은 시간 안에 여러 서버에 코드를 배포 할 수 있기 때문에 당연히 일부 사람들은 Docker가 응용 프로그램 자체를 확장 할 수 있다고 생각할 것입니다. 불행히도 이것은 잘못되었습니다. 코드는 응용 프로그램의 초석이며 Docker는 코드를 다시 작성하지 않습니다. 응용 프로그램의 확장 성은 여전히 프로그래머에 따라 다릅니다. Docker를 사용하면 코드를 쉽게 확장 할 수 없으며 서버 전체에 쉽게 배포 할 수 있습니다.
3. Docker는 생산 환경에서 널리 사용됩니다
Docker가 본격적으로 진행되기 때문에 많은 사람들은 Docker가 생산 환경에서 대규모로 사용할 수 있다고 생각합니다. 사실, 이것은 옳지 않습니다. Docker는 여전히 매우 새로운 기술, 미성숙하고 성장하는데, 이는 여전히 많은 성가신 버그와 기능을 개선해야한다는 것을 의미합니다. 새로운 기술에 관심이 있다는 것은 사실이지만 올바른 사용 시나리오와주의를 기울여야 할 사항을 파악하는 것이 가장 좋습니다. 이제 Docker는 개발 환경에 쉽게 적용 할 수 있습니다. Docker를 사용하면 다양한 환경을 쉽게 만들 수 있습니다 (적어도 사람들은 사람들이 다른 환경을 만들 수 있다는 느낌을줍니다). 이는 개발에 매우 유용합니다.
생산 환경에서 Docker의 미숙함과 불완전 성도 사용 시나리오를 제한합니다. 예를 들어 Docker는 여러 기계의 네트워크 및 리소스 모니터링을 직접 지원하지 않으므로 생산 환경에서 사용하는 것이 거의 불가능합니다. 물론 개발 환경에서 생산 환경에 이르기까지 동일한 패키지를 직접 배포하는 것과 같은 많은 잠재적 영역이 있습니다. 생산 환경에도 유용한 Docker 런타임 기능도 있습니다. 그러나 일반적으로 생산 환경에서는 현재 장점보다 더 큰 장점이 없습니다. 이것은 생산 환경에 성공적으로 적용 할 수 없다는 것을 의미하지는 않지만 이제는 한 번에 성숙하고 완벽 할 것으로 예상 할 수 없습니다.
4. Docker는 Cross-OS입니다
또 다른 오해는 Docker가 모든 운영 체제 및 환경에서 일한다는 것입니다. 이는 상품을 적재하고 언로드하기위한 컨테이너의 비유에서 비롯 될 수 있지만 소프트웨어와 운영 체제의 관계는 선박의 위치만큼 간단하고 직접적이지 않습니다.
실제로 Docker는 Linux의 기술 일뿐입니다. 또한 Docker는 특정 커널 기능에 의존하며 최신 버전의 커널이 있어야합니다. 다른 OS의 차이를 기반으로 OS에서 가장 낮은 공통 기능을 사용하지 않으면 많은 번거로운 문제가 발생합니다. 이러한 문제는 1% 만 발생할 수 있지만 여러 서버에 배포하면 1%도 치명적입니다.
Docker는 Linux에서만 실행되지만 OS X 또는 Windows에서도 사용할 수도 있습니다. Boot2Docker를 사용하면 OS X 또는 Windows 시스템에서 Linux 가상 머신을 실행하므로 Docker는이 가상 시스템에서 실행될 수 있습니다.
5. Docker는 응용 프로그램 보안을 향상시킵니다
Docker가 코드 및 전달 프로세스의 보안을 향상시킬 수 있다는 것은 또한 오해입니다. 이것은 또한 실제 컨테이너와 소프트웨어의 컨테이너의 차이입니다. Docker는 오케스트레이션 방법을 추가하는 컨테이너화 기술입니다. 그러나 Linux 컨테이너에는 공격을받을 수있는 보안 취약점이 있습니다. Docker는 이러한 취약점에 보안 계층이나 패치를 추가하지 않습니다. 응용 프로그램을 보호 할 수있는 바지 셔츠가 아닙니다.
자바 관점에서
일부 Java 개발자는 Docker를 사용하기 시작했습니다. Docker의 기능 중 일부는 확장 가능한 컨텍스트를 쉽게 구축 할 수 있도록합니다. Uber-Jar와 달리 Docker는 모든 의존성 (JVM 포함)을 즉시 방출 할 수있는 이미지에 포장하는 데 도움을 줄 수 있습니다. 이것은 또한 개발자의 Docker에서 가장 매력적인 것입니다. 그러나 이것은 또한 숨겨진 위험을 초래할 것입니다. 일반적으로 프로그래머는 다양한 방식으로 모니터링하고 코드를 디버깅하고 연결하고 연결해야합니다. Docker를 사용하면 추가 작업이 필요합니다.
예를 들어 JMX는 RMI를 사용하기 위해 네트워크가 필요하기 때문에 JMX 기능에 의존하는 JCONSOLE을 사용하려고합니다. Docker를 사용하는 경우 직접적인 것은 아니며 필요한 포트를 열려면 약간의 기술이 필요합니다. 우리는 처음에 Takipi에 대한 Docker 응용 프로그램을 구축하고 싶을 때 컨테이너의 JVM 외부에서 배경 프로그램을 실행해야한다는 문제가 있음을 발견했습니다. Github의 상세한 솔루션.
또 다른 심각한 문제는 Docker 컨테이너의 성능 조정이 매우 어렵다는 것입니다. 컨테이너를 사용할 때는 각 컨테이너가 할당 할 메모리의 양을 알 수 없습니다. 20 개의 컨테이너가있는 경우 메모리가 불확실한 방식으로 메모리에 할당됩니다. 파라미터 -xmx로 힙을 조정하려는 경우 Docker 컨테이너에서 JVM의 처리가 컨테이너에 할당 된 메모리를 자동으로 얻는 능력에 따라 달라지기가 어렵습니다. 메모리가 얼마나 할당되었는지 모르는 경우 성능 튜닝은 거의 불가능합니다.
결론적으로
Docker는 매우 흥미로운 기술이며 실제적이고 효과적인 사용 시나리오를 가지고 있습니다. 신흥 기술로서 누락 된 기능과 알려진 버그를 해결하는 데 많은 시간이 걸립니다. 그러나 지금이 분야에는 실제로 많은 과대 광고가 있습니다. 그러나 과대 광고는 성공하지 못한다는 것을 기억하십시오 ~
읽어 주셔서 감사합니다. 도움이되기를 바랍니다. 이 사이트를 지원 해주셔서 감사합니다!