다중 FROM - 의미

다중 FROM - 의미

Neo4j 데이터베이스와 Node.js를 모두 실행해야 하는 도커 이미지를 구축하고 싶습니다.

저의 첫 번째 접근 방법은 Neo4j를 포함한 제 이미지의 기본 이미지를 선언하는 것이었습니다.참조 문서는 유용한 방법으로 "기본 이미지"를 정의하지 않습니다.

기본 이미지:부모가 없는 이미지는 기본 이미지입니다.

그 이미지 자체에 기본 이미지가 없는 경우에만 기본 이미지를 가질 수 있다고 읽었습니다.

하지만 기본 이미지란 무엇일까요?만약 내가 from 지시문으로 neo4j/neo4j를 선언하면, 내 이미지가 실행되면 neo 데이터베이스가 자동으로 실행되어 포트 7474의 컨테이너 내에서 사용할 수 있게 된다는 뜻입니까?

도커 참조를 읽다 보면 다음과 같습니다.

FROM은 여러 이미지를 만들기 위해 하나의 도커 파일 내에 여러 번 나타날 수 있습니다.각 새 FROM 명령 전에 커밋에 의해 출력된 마지막 이미지 ID를 메모하기만 하면 됩니다.

여러 개의 이미지를 생성해야 합니까?제가 원하는 것은 neo4j와 node.js와 같은 다른 이미지의 내용이 포함된 하나의 이미지를 원하는 것 같습니다.

참조 매뉴얼에서 의존 관계를 선언하는 지침을 찾을 수 없었습니다.제 이미지를 실행하려면 먼저 호출 컨텍스트가 필요한 이미지를 설치해야 하는 RPM과 같은 의존 관계가 없습니까?

의 2017년 5FROMs는 단일 도커 파일에서 사용할 수 있습니다.
"빌더 패턴 대" 참조. 도커의 다단계 빌드"(알렉스 엘리스 작)와 티 õ니스 티이지 작 PR 31257.

일반적인 구문은 다음을 추가하는 것을 포함합니다.FROM 내의 간 중 ) -간FROMstatement는입니다. 및 하려면 다음을 합니다.COPY --from=<base_image_number>.

FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app    .
CMD ["./app"]  

결과적으로 두 개의 이미지(하나는 빌드용, 하나는 결과 앱만 사용)가 됩니다.

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

multi               latest              bcbbf69a9b59        6 minutes ago       10.3MB  
golang              1.7.3               ef15416724f6        4 months ago        672MB  

---

기본 이미지란 무엇입니까?

파일 집합과 'd 포트', 그리고.
하고 새다를 으로 새 할 수 .Dockerfile터부터 FROM시 ::FROM는 새 이미지의 "기본 이미지"입니다.

말은 neo4j/neo4j일순간에FROM내 이미지가 실행되면 neo 데이터베이스가 자동으로 실행되어 포트 7474의 컨테이너 내에서 사용할 수 있다는 지시?

하지 CMD그리고.ENTRYPOINT.
. 당신은 a를 사용할 것입니다.FROM neo4j/neo4j을 추가해야 합니다.neo4j이 특정한 할 수 있습니다.neo4j.

질문과 답변에 대한 이해를 정리해 보겠습니다. 다른 사람들에게 도움이 되길 바랍니다.

질문:제가 사과, 바나나, 오렌지 이렇게 세 개의 이미지를 가지고 있다고 가정해 보겠습니다.도커 파일을 받을 수 있을까요?FROM apple,FROM banana그리고.FROM orange도커에게 마법처럼 세 개의 응용 프로그램을 하나의 이미지(세 개의 개별 응용 프로그램을 포함)로 병합하도록 지시할 수 있으며, 이를 스무디라고 부를 수 있습니까?

정답: 아니요, 안 됩니다.그렇게 하면 네 개의 이미지, 네 개의 과일 이미지, 그리고 마지막을 기준으로 한 새로운 이미지가 완성됩니다.FROM를 들어 image. 예를 들면,FROM orange도커 파일에서 아무것도 추가되지 않은 마지막 문장이었습니다. 스무디 이미지는 오렌지 이미지의 복제품일 뿐입니다.

그들은 왜 합병되지 않습니까?정말 갖고 싶어요

일반적인 도커 이미지는 애플리케이션이 실행하는 데 필요한 거의 모든 것(커널 제외)을 포함합니다. 이는 일반적으로 선택한 운영 체제와 특정 버전 또는 배포 환경을 위한 기본 이미지로 구축된다는 것을 의미합니다.

가능한 모든 배포, 파일 시스템, 라이브러리 및 애플리케이션을 고려하지 않고 이미지를 성공적으로 병합하는 것은 도커가 원하는 일이 아닙니다.대신 개발자들은 필요에 따라 서로 대화하는 여러 컨테이너를 실행하면서 마이크로 서비스 패러다임을 수용할 것으로 예상됩니다.

대안이 무엇입니까?

이미지 병합을 위한 하나의 가능한 사용 사례는 Linux 배포판을 우리가 원하는 애플리케이션(예: Ubuntu 및 Node.js)과 혼합하여 일치시키는 것입니다.이것은 해결책이 아닙니다.

FROM ubuntu
FROM node

애플리케이션 이미지가 선택한 Linux 배포판을 고수하지 않으려면 선택한 배포판부터 시작하여 패키지 관리자를 사용하여 애플리케이션을 대신 설치할 수 있습니다.

FROM ubuntu
RUN apt-get update &&\
    apt-get install package1 &&\
    apt-get install package2

하지만 당신은 이미 알고 있었을 겁니다.선택한 배포판에 스냅 또는 패키지가 없거나 원하는 버전이 아니거나, 이미지를 사용하고자 하는 동기가 된 도커 컨테이너에서 제대로 작동하지 않는 경우가 많습니다.제가 아는 한, 유일한 선택지는 그것을 멀리하는 것입니다. 만약 당신이 진정으로 단일적인 접근법을 따르고 싶다면 말이죠.

예를 들어 Node.js의 경우 다음과 같이 최신 버전을 수동으로 설치할 수 있습니다.apt하고를 snap는 Ubuntu 이미지와 함께 제공되지 않습니다.neo4j의 경우 설명서와 라이센스에 따라 패키지를 다운로드하여 수동으로 이미지에 추가해야 할 수도 있습니다.

크기가 중요하지 않은 경우 수동으로 설치하기 가장 어려운 기본 이미지부터 시작하여 나머지를 위에 추가하는 것이 한 가지 전략입니다.

여러 개의 지시어를 사용할 때

개의 를 할 수 도 있습니다.FROM문장과 수동으로 빌드 단계 사이 또는 최종 단계에 내용을 복사할 수 있습니다.즉, 자신이 무엇을 하고 있는지 알고 있다면 이미지를 수동으로 병합할 수 있습니다.문서에 따르면 다음과 같습니다.

으로 를 하여 새 할 수 .AS nameFROM설명. 이름은 이후에 사용할 수 있습니다에서 사용할 수 입니다.FROM그리고.COPY --from=<name>이 단계에서 구축된 이미지를 참조하기 위한 지침

개인적으로, 저는 이 병합 접근 방식을 제 이미지와 함께 사용하거나 애플리케이션 공급업체의 문서를 따르는 것이 편할 뿐이지만, 필요한 경우 또는 운이 좋은 경우에만 사용할 수 있습니다.

그러나 이 접근 방식을 더 잘 적용하는 것은 실제로 다른 이미지의 임시 컨테이너를 사용하여 무언가를 만들거나 수행하고 원하는 출력물을 복사한 후 폐기하고자 할 때입니다.

예

는 가 없는 요.gpgv단지, 그리고 이 유닉스 & 리눅스 답변을 바탕으로, 나는 전체를 설치했습니다.gpg와 함께yum필요한 이진 파일만 최종 이미지에 복사했습니다.

FROM docker.io/photon:latest AS builder
RUN yum install gnupg -y

FROM docker.io/photon:latest
COPY --from=builder /usr/bin/gpgv /usr/bin/
COPY --from=builder /usr/lib/libgcrypt.so.20 /usr/lib/libgpg-error.so.0 /usr/lib/

들은Dockerfile평소와 같이 계속됩니다.

첫 번째 대답은 너무 복잡하고 역사적이며 제 취향에 맞지 않습니다.

---

사실은 간단합니다.도커는 다단계 빌드라는 기능을 제공합니다. 여기서 기본 아이디어는 다음과 같습니다.

• 원하지 않는 것을 수동으로 제거할 필요가 없도록 하고, 원하는 것을 나열하도록 강요함으로써,
• 그렇지 않으면 도커의 구현으로 인해 차지할 수 있는 무료 리소스입니다.

첫 번째부터 시작하겠습니다.종종 데비안 같은 것을 보면 알게 될 겁니다.

RUN apt-get update \ 
  && apt-get dist-upgrade \
  && apt-get install <whatever> \
  && apt-get clean

우리는 이 모든 것을 위의 관점에서 설명할 수 있습니다.위의 명령은 함께 연결되므로 중간 이미지가 필요 없는 단일 변경을 나타냅니다.이렇게 썼으면.

RUN apt-get update ;
RUN apt-get dist-upgrade;
RUN apt-get install <whatever>;
RUN apt-get clean;

그러면 3개의 임시 중간 이미지가 더 생성됩니다. 바로다입니다.apt-get clean설치에 사용된 아티팩트를 정리하지 않습니다.이 포함됩니다(예:다조)).pepperflashplugin-nonfree예를 들어).

한 수 있는 을 얻을 수 를 사용하여 에 대한 목록 및으로 허용해야 .COPY --from여기에 문서화된 구문.입니다처럼 예:apt-get clean됩니다.) 됩니다.

참고 항목

• 다단 빌드
• 카피 구문

중 일 것입니다.FROMs,

도커 파일 하나를 원합니다. 단어 하나를 바꾸고 싶습니다. 그 단어를 무엇으로 설정하느냐에 따라 실행할지, 응용 프로그램을 개발할지, 게시할지에 따라 이미지가 달라집니다.

실행 - 앱을 실행하고 싶습니다.

Dev - 코드를 편집하고 앱을 실행하고 싶습니다.

게시 - 운영 중인 앱 실행

우리가 닷넷 환경에서 작업하고 있다고 가정해 보겠습니다.여기 하나의 도커 파일이 있습니다.멀티 스테이지 빌드가 없으면 여러 파일(빌더 패턴)이 생성됩니다.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/runtime:5.0 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["ConsoleApp1/ConsoleApp1.csproj", "ConsoleApp1/"]
RUN dotnet restore "ConsoleApp1/ConsoleApp1.csproj"
COPY . .
WORKDIR "/src/ConsoleApp1"
RUN dotnet build "ConsoleApp1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "ConsoleApp1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ConsoleApp1.dll"]

앱을 실행하시겠습니까?eFROM base AS final현재 위의 도커 파일에 있는 것처럼.

컨테이너에서 소스 코드를 개발하시겠습니까?동일한 줄을 다음으로 변경합니다.FROM build AS final

프로드로 출시하시겠습니까?동일한 줄을 다음으로 변경합니다.FROM publish AS final

이 기능이 도커에게 유용하다는 점에서 OP에 동의합니다.다음은 같은 문제에 대한 다른 견해입니다.

예를 들어 여러 개의 FROM(또는 "FROM"과 "MERGE")이 있는 경우 기본 도커 이미지 및 기타 컨테이너 요소에 도커 레지스트리 버전 시스템을 사용할 수 있으며, 이는 여기서의 성공입니다.저는 .deb 형식으로 존재하지 않는 타사 개발 툴을 가지고 있어서 이 툴들은 반드시 앳볼에서 타겟팅을 해제하여 설치해야 하며, HUGUGE이므로 도커 호스트에 대한 캐싱도 중요하지만 이미지의 버전/변경 제어도 마찬가지로 중요합니다.단순히 "RUN git..."을 사용하면 되고, 도커가 새로운 계층의 캐싱을 처리해 줄 것이고, 이것이 제가 원하는 것입니다. 왜냐하면 다른 컨테이너는 기본 이미지는 같지만 거대한 제3자 도구 집합을 가질 것이기 때문입니다.따라서 기본 이미지와 도구 이미지의 캐싱이 정말 중요합니다(3자 도구 tar는 say ubuntu의 기본 이미지만큼 클 수 있으므로 이들의 캐싱도 정말 중요합니다).(제안된) 기능을 사용하면 이러한 모든 요소를 중앙 레포에서 관리할 수 있습니다.버전 관리 시스템

다른 말로, 우리는 왜 FROM을 사용합니까?"기본 이미지/계층"에 대해 RUN 명령을 사용하여 우분투 이미지를 간단히 git 복제하면 새로운 계층이 생성되고 도커는 어쨌든 이를 캐시할 것입니다.도커 내부 버전 시스템/신택스를 사용하는 것 외에 FROM을 사용하는 것에 차이점/장점이 있습니까?

언급URL : https://stackoverflow.com/questions/33322103/multiple-froms-what-it-means