docker에서 실행되는 Jenkins 빌드 슬레이브에서 npm 캐시를 활성화하는 방법은 무엇입니까?


13

frontend.imageJenkins 빌드 슬레이브에 사용 하는 Docker 이미지가 있습니다. Jenkins Docker 플러그인 은이 이미지에서 컨테이너를 회전시키고 컨테이너 내부에 아티팩트를 빌드합니다. 이 모든 것이 잘 작동합니다. 이 경우, frontend.image는 AngularJs 앱을 빌드하는 데 사용됩니다. 이 Angular 앱을 빌드하는 과정에서 앱에 필요한 npm 패키지를 설치해야합니다.

npm install이 프로세스는 시간이 오래 걸리고 3 분이 걸리는 것처럼 보입니다. npm은 항상 모든 패키지를 매번 설치합니다.

따라서 슬레이브에 볼륨을 추가했습니다. 호스트 마운트 볼륨입니다. Docker 플러그인은 프론트 엔드 컨테이너를 실행할 때마다이 볼륨을 사용합니다.

여기에 이미지 설명을 입력하십시오

명령을 실행하는 사용자 npm installjenkins입니다. npm은 npm config get cache출력 하는 명령으로 찾을 수있는 캐시를 유지합니다./home/jenkins/.npm

그래서 /slaves/volumes/tsl.frontend:/home/jenkins웹 컨테이너 슬레이브에 호스트 볼륨을 마운트했습니다.

Jenkins 프로젝트를 사용하여 Angular 앱을 빌드하고 아무런 문제가 없으며 많은 npm 패키지가 설치됩니다. Docker 호스트에 ssh하고 cmd를 실행하면 ls /slaves/volumes/tsl.frontend많은 npm 패키지가 표시됩니다. 이것은 슬레이브의 호스트 볼륨 마운트가 작동했음을 의미합니다. 여기에 이미지 설명을 입력하십시오

Docker 슬레이브 빌드 컨테이너가 볼륨 호스트 마운트를 사용하더라도 npm은 Jenkins 프로젝트를 다시 빌드합니다. npm은 모든 단일 패키지를 다시 설치합니다. 캐시 된 많은 npm 패키지를 나열하는 docker exec -it <some_clever_random_container_id> bashcmd su jenkins, cmd 및 cmd를 사용하여 슬레이브 컨테이너에 bashing하여 확인할 수도 있습니다 npm cache ls. 여기에 이미지 설명을 입력하십시오

따라서 권한 chmod 777이없는 호스트 마운트 볼륨에서도 권한 문제가 없으므로 npm install캐시를 사용할 수 없습니다 .

Docker 슬레이브 컨테이너를 가동시키는 Jenkins 빌드에서 첫 번째 실행 cmd가 npm cache ls있고 많은 패키지가 나열되어 있는데, 이는 호스트 볼륨이 예상대로 작동하고 npm 캐시 색인이 손상되지 않았 음을 의미하지 않습니까?

여기에 이미지 설명을 입력하십시오

나는 npm install로컬 호스트 컴퓨터에서 실행할 때 모든 패키지를 처음으로 설치하고 다음에 거의 패키지를 설치하지 않는 일반 cmd를 시도했습니다 . 또한 이 SO 답변 과 cmd npm --cache-min 9999999 install에서 가져온 npm 캐시 "hack"npm --skip-installed --cache-min 9999999 install

관련 질문 이 StackOverflow에 게시되었습니다.


캐시 인덱스가 설명에 따라 ~ / .npm 내에 저장되지 않을 것입니다.
Tensibai

@ Tensibai 당신이 틀렸고 이것에 대해 매우 확신합니다. 사용자는 jenkins입니다. 왜냐하면 npm 캐시 ls를 jenkins 사용자로 실행하고 패키지를 나열하기 때문에 npm 설치는 다른 사용자에 의해 실행되는
브라이언 오그 덴에게

아니요, 인덱스 자체가 / usr / local 또는 npm이 설치된 경로 또는 다른 경로에 저장되어 있다고 생각합니다. 이것은 npm이 캐시에 아무것도없는 것처럼 작동하는 것처럼 들리므로 디렉토리를 나열하지 않고 다른 종류의 색인을 기반으로한다고 생각합니다.
Tensibai

@ Tensibai 그러나 cmd npm 구성은 캐시의 위치를 ​​확인한다고 생각하지 않는 경로로 /home/jenkins.npm을 반환합니다.
Brian Ogden

캐시 인덱스를 강제하지 않는 캐시의 위치는 동일 위치에 있습니다. 빌드를 시작할 때 컨테이너의 상태를 보장하기 위해 다른 빌드 단계 전에 빌드 스크립트 자체에 a npm cache ls및 raw ls ~/.npm/* -al를 추가했습니다 .
Tensibai

답변:


5

나는 이 대답 에 따라 npm 설치에 Docker 이미지 레이어 캐싱을 사용하여 이것을 해결했습니다.

즉, npm 설치를 Docker 슬레이브 이미지에서 실제로 프런트 엔드 이미지로 옮겼습니다. 여기 내 package.config에 변경 사항이없는 경우 빌드간에 npm 설치를 실제로 캐시하는 최종 Docker 파일이 있습니다.

FROM centos:7
MAINTAINER Brian Ogden

# Not currently being used but may come in handy
ARG ENVIRONMENT
ENV NODE_VERSION 6.11.1

RUN yum -y update && \
    yum clean all && \
    yum -y install http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm \
    yum -y makecache && \
    yum -y install nginx-1.12.0 wget

# Cleanup some default NGINX configuration files we don’t need
RUN rm /etc/nginx/conf.d/default.conf

#############################################
# NodeJs Install
#############################################

#Download NodeJs package
RUN wget -q -O - https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-x64.tar.gz \
    | tar --strip-components=1 -xzf - -C /usr/local

# /programming//a/35774741/1258525
# use changes to package.json to force Docker not to use the cache
# when we change our application's nodejs dependencies:
COPY ./package.json /tmp/package.json
RUN cd /tmp && npm install
RUN mkdir /app && cp -a /tmp/node_modules /app/

WORKDIR /app
COPY . /app

RUN npm run build-$ENVIRONMENT

RUN cd /app && cp -a dist/* /usr/share/nginx/html
COPY ./docker/conf/frontend.conf /etc/nginx/conf.d/frontend.conf
COPY ./docker/conf/nginx.conf /etc/nginx/nginx.conf


EXPOSE 80

CMD ["nginx"]

2
질문에 설명 된 문제를 해결하지 못합니다. 캐시하는 또 다른 방법입니다. 아직 이유를 아십니까? @Brian
An Nguyen

@AnNguyen nope, 그리고 npm 캐시가 작동하도록 많은 시간을 보냈습니다. 난 당신이 내 솔루션을 사용하는 것이 좋습니다
브라이언 오그 덴

내 상황은 다릅니다. 빌드가 트리거 될 때마다 k8에 슬레이브가 프로비저닝됩니다. 따라서 도커 빌드 프로세스를 기반으로 캐시 할 수 없습니다. 프로비저닝 할 때마다 영구 볼륨을 슬레이브에 마운트 할 수 있도록 NPM 캐시를 기반으로하고 싶습니다.
Nguyen Nguyen

0

또 다른 방법은 npm 모듈을 호스팅하고 외부 모듈을 프록시하는 넥서스 저장소 서버를 설정하는 것입니다. 캐시를 활용하지는 않지만 리소스가 로컬 네트워크 내에 있거나 같은 떼에 있기 때문에 오래 걸리지 않아야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.