각 도커 이미지에 JDK를 포함해야 합니까?

각 도커 이미지에 JDK를 포함해야 합니까?

도커는 처음입니다질문의 맥락을 설명하겠습니다.

1. 10~20개의 Spring Boot 마이크로 서비스 애플리케이션이 로컬머신의 다른 포트로 실행되고 있습니다.

2. 그러나 도커로 이행할 경우 신속하게 도입 또는 복사본을 작성하기 위해 각 서비스가 다른 도커 컨테이너에 포함되어 있어야 합니다.

3. 도커 컨테이너마다 새로운 도커 이미지를 작성해야 합니다.

4. 스프링 부트 애플리케이션을 실행하려면 각 도커 이미지에 JRE가 포함되어 있어야 합니다.최대 약 200MB입니다.즉, 각 도커 이미지는 최대 350MB입니다.한편, 로컬 PC에서는 200 MB의 JRE가 1개밖에 없고, 각 애플리케이션은 몇 MB의 공간밖에 차지하지 않습니다.

5. 이를 바탕으로 로컬 시스템에서 600MB가 필요한데 도커 이미지에는 모두 7GB가 필요합니다.

이 방법이 올바른가요?Docker Hub의 "Open JDK"를 각 이미지에 추가해야 합니까?

타깃 PC에 이미 JDK가 있는데 이미지 크기가 큰 이유는 무엇입니까?

당신의 이해는 올바르지 않습니다.

도커 이미지는 레이어로 형성됩니다.다음 그림을 참조해 주십시오.

할 때 이 "JRE"라고 91e54dfb1179다음 사진에서는 디스크를 차지하게 됩니다.

것을 를 들어 다른 서비스 씬 R레이어에 는 를 합니다.91e54dfb1179n*m의

가능한 한 모든 Java 응용 프로그램에 동일한 기본 이미지를 사용하고 씬 R/W 계층에 다른 항목을 추가해야 합니다.

다른 답변은 Docker 계층화에 대해 매우 잘 다루므로 질문을 위해 세부 사항을 추가하겠습니다.

이 방법이 올바른가요?Docker Hub의 "Open JDK"를 각 이미지에 추가해야 합니까?

네. 이미지에 없으면 컨테이너에 안 들어가요.그러나 가능한 한 많은 계층을 재사용하여 디스크 공간을 절약할 수 있습니다.따라서 Docker 파일을 "변경 가능성이 가장 낮음"에서 "변경 가능성이 가장 높음"으로 작성해 보십시오.따라서 이미지를 빌드할 때 "캐시 사용"이 자주 표시될수록 좋습니다.

타깃 PC에 이미 JDK가 있는데 이미지 크기가 큰 이유는 무엇입니까?

Docker는 가능한 한 호스트와의 관계를 피하고 싶어 합니다.도커는 숙주를 상대하고 싶지도 않아요첫 번째 작업은 숨길 VM을 만드는 것입니다.도커 이미지에서는 호스트에서 제공되는 것은 빈 RAM, 디스크 및 CPU뿐이라고 가정합니다.따라서 각 도커 이미지에는 자체 OS/커널도 포함되어 있어야 합니다.(처음 FROM에서 사용하는 기본 OS 이미지를 선택합니다) 최종 이미지 크기는 OS + 도구 + 앱입니다.이미지 사이즈는 이미지 전체에서 재사용되는 모든 레이어의 합계이기 때문에 약간 오해의 소지가 있습니다.

(표시)각 앱/마이크로 서비스를 자체 컨테이너에 넣어야 합니까?

이상적으로는 그렇죠앱을 격리된 모듈로 변환함으로써 모듈을 쉽게 교체/로드 밸런싱할 수 있습니다.

실제로는 아닐지도 모른다.스프링 부트는 가벼운 프레임워크가 아닙니다.실제로는 코드를 모듈로 변환하기 위한 프레임워크입니다(모듈 제어 시스템 내에서 모듈 제어 시스템을 효과적으로 실행).그런데 이제 10~20명을 호스트 하겠다는 거야?이것은 단일 서버에서는 실행할 수 없을 것입니다.Docker는 Spring Boot을 어플리케이션별로 메모리에 강제로 로드합니다.또한 오브젝트를 모듈 전체에서 재사용할 수 없기 때문에 이들 오브젝트도 멀티 인스턴스화해야 합니다.또, 1대의 실가동 서버로 한정되어 있는 경우는, 수평 확장이 불가합니다.(스프링 부트당 최대 1GB의 HIP(RAM)가 필요합니다.코드에 따라 주행거리가 달라집니다).또한 10~20개의 어플리케이션에서는 Docker 도입을 위해 어플리케이션을 경량화하는 리팩터링은 예산 내에서 실현 불가능할 수 있습니다.테스트용 최소한의 셋업(RAM 부족)을 로컬에서 실행할 수 없는 경우는, 한층 더 「재미」를 얻을 수 있습니다.

도커는 황금 망치가 아니다.한번 시도해 보고, 스스로 장단점을 평가한 후, 그 장점이 여러분과 여러분의 팀에게 단점만큼 가치가 있는지 판단하세요.

Lagom의 답변은 훌륭합니다만, 도커 컨테이너의 사이즈는 가능한 한 작게 해, 운반과 보관이 용이하도록 하고 싶습니다.

따라서 Alpine Linux 디스트리뷰션을 기반으로 한 컨테이너는 매우 적습니다.가능하면 그것들을 사용해 보세요.

또한 컨테이너에 상상할 수 있는 모든 도구를 추가하지 마십시오. 예를 들어 wget 없이 할 수 있는 경우가 많습니다.

이를 바탕으로 로컬 시스템에서 600MB가 필요한데 도커 이미지에는 모두 7GB가 필요합니다.

이 방법이 올바른가요?Docker Hub의 "Open JDK"를 각 이미지에 추가해야 합니까?

그것이 맞아요.JRE로는 충분하지 않은지 궁금할 수도 있지만요.

타깃 PC에 이미 JDK가 있는데 이미지 크기가 큰 이유는 무엇입니까?

비교할 수 없는 것, 즉 로컬 환경(실가동 시스템 제외)과 통합/실가동 환경을 비교합니다.

통합/실가동 환경에서는 애플리케이션 부하가 높을 수 있으며 일반적으로 애플리케이션 간의 분리가 권장됩니다.따라서 애플리케이션 간의 부작용(공유 라이브러리 비호환성, 소프트웨어 업그레이드 부작용, 리소스 부족, 애플리케이션 간의 연쇄 장애 등)을 방지하기 위해 머신(베어, VM 또는 컨테이너)별로 최소한의 애플리케이션(ui/서비스)을 호스트해야 합니다.

로컬 환경에서는 애플리케이션 부하가 상당히 낮으며 애플리케이션 간의 분리는 일반적으로 심각한 문제가 아닙니다.따라서 로컬 머신에서 여러 애플리케이션(ui/services)을 호스트할 수 있으며 OS에서 제공하는 몇 가지 공통 라이브러리/의존 관계도 공유할 수 있습니다.그렇게 할 수 있지만, 모든 것을 로컬에서 혼합하여 공유하는 것이 정말 좋은 방법일까요?그런 건 것 요.
1) 로컬 머신은 휴지통이 아닙니다.하루 종일 작업합니다.깨끗할수록 개발은 효율적입니다.예를 들어 로컬에서 호스팅되는 애플리케이션 간에 JDK/JRE가 다를 수 있습니다.어플리케이션이 사용하는 폴더는 같은 장소, 데이터베이스 버전이 다를 수 있습니다.어플리케이션에는 다른 Java 서버(Tomcat, Netty, Weblogic)가 설치되어 있을 수도 있고 버전이 다를 수도 있습니다.
이치노필요에 따라 모든 것이 설치 및 분리됩니다.

2) 환경(로컬에서 프로드로)은 가능한 한 폐쇄하여 통합-도입 체인 전체를 용이하게 하고 운영 환경뿐만 아니라 문제를 조기에 검출해야 합니다.

참고로 로컬에서 이를 실현하려면 개발자를 위한 실제 기계가 필요합니다.

---

모두 비용이 들지만 실제로는 비싸지 않다.

컨테이너는 격리(하드웨어 및 소프트웨어 리소스) 외에도 신속한 도입/언도입, 확장성 및 페일오버 친화적(예: Kubernetes는 컨테이너에 의존)이라는 다른 이점을 제공합니다.
격리, 고속성, 확장성 및 견고성에는 컨테이너(OS, 라이브러리, JVM 등) 간에 물리적으로 리소스를 공유하지 않는 비용이 수반됩니다.

즉, 어플리케이션에서 정확한 OS, 라이브러리, JVM을 사용하더라도 각 어플리케이션이 이미지에 포함시켜야 합니다.
비용이 많이 드나요?그렇지 않습니다.공식 이미지는 종종 Alpine(Light Linux OS, 제한이 있지만 필요에 따라 커스터마이즈 가능)에 의존하며 비용 면에서는 350MB(견적하신 값)의 이미지를 나타냅니다.
★★★★★★★★★★★★★★★★★★★★★★★★★★통합/운용에서는 모든 서비스가 동일한 머신에서 호스트되지 않을 가능성이 높기 때문에 컨테이너용 350MB를 여러 추가 프로그램이 설치된 완전한 OS를 포함하는 통합/운용용 VM에서 사용되는 리소스와 비교합니다.컨테이너의 자원 소비는 문제가 되지 않는다는 것을 알고 있습니다.그것은 심지어 지역 환경을 뛰어넘는 장점으로 여겨진다.

언급URL : https://stackoverflow.com/questions/52849139/should-each-docker-image-contain-a-jdk