Як увімкнути кеш-пам'ять npm у службі складання Jenkins, яка працює в docker?


13

У мене є образ Докера, назвемо його frontend.image, який я використовую для рабовласницького складу Дженкінса. Плагін Дженкінса Докера створить контейнер із цього зображення та створить артефакти всередині контейнера. Це все чудово працює. У цьому випадку програма frontend.imageвикористовується для створення програми AngularJs. Частина побудови цього кутового додатка полягає у встановленні npm-пакетів, необхідних додатку.

Цей процес, встановлення npm, здається, займає тривалий час, 3 хвилини, здається, npm завжди встановлює кожен пакет кожен раз.

Тож я додав об'єм для мого раба, це хост, встановлений на хості, плагін Docker буде використовувати цей том щоразу, коли він запускає контейнер frontend:

введіть тут опис зображення

Користувач, який виконує команду, npm install- це jenkins. npm зберігає кеш, який ви можете знайти за допомогою команди, npm config get cacheяка виводить/home/jenkins/.npm

Ось чому у мене об'єм хоста /slaves/volumes/tsl.frontend:/home/jenkinsвстановлений на моєму веб-контейнері.

Я будую свою програму Angular за допомогою проекту Jenkins, не створює жодних проблем, встановлено багато пакетів npm. Якщо ssh у мій хостинг Docker і запустіть cmd, ls /slaves/volumes/tsl.frontendя бачу багато пакетів npm. Це означає, що мій хост-кріплення для холопа працював. введіть тут опис зображення

Тепер я будую проект Jenkins знову, npm встановлює кожен пакет знову, навіть незважаючи на те, що контейнер для складання Slave для Docker використовує кріплення хосту томів. Я навіть можу підтвердити, потрапивши в контейнер для підлеглих з cmd, docker exec -it <some_clever_random_container_id> bashа потім cmd, su jenkinsа потім cmd, у npm cache lsякому перераховано багато пакетів npm, які кешуються. введіть тут опис зображення

Тож, навіть якщо мій об'єм кріплення хоста, який chmod 777, до речі , має дозволи , тому немає дозволів, я не можу отримати npm installкеш.

У моїй конструкції Jenkins, яка закручує контейнер Slave Slave, перший cmd, який я запускаю, npm cache lsі перераховано багато пакунків, чи це не означає, що мій об'єм хоста працює так, як очікувалося, а індекс кеш-пам'яті npm має цілісність, а не пошкоджений?

введіть тут опис зображення

Я спробував звичайний npm installcmd, який під час запуску на моїй локальній машині встановлює всі пакунки вперше і майже не пакує наступного разу. А також кеш-пам'ять npm "хак" npm --cache-min 9999999 install, взята з цієї відповіді ТА так само cmdnpm --skip-installed --cache-min 9999999 install

Пов’язане запитання було розміщено на StackOverflow.


Я б сказав, що індекс кеша не зберігається в межах ~ / .npm відповідно до вашого опису
Tensibai

@Tensibai ви невірні, і я дуже впевнений у цьому, користувач jenkins, тому що це ви говорите по-іншому, тому що я запускаю npm кеш ls як користувач jenkins і перераховує пакети, ви говорите, що npm install є виконується іншим користувачем
Брайан Огден

ні, я кажу, що сам індекс, ймовірно, зберігається в іншому місці, в / usr / local або будь-якому іншому шляху npm, встановленому в або whatelse, я не маю уявлення. Це просто звучить як npm діє так, ніби в кеші нічого не було, тому я думаю, що він не перераховує каталог, а базується на іншому індексі деінде.
Тенсібай

@Tensibai, але конфігурація cmd npm отримує кеш повернення /home/jenkins.npm, оскільки цей шлях не вважаєш, що це підтверджує розташування кешу?
Брайан Огден

Місце кешу так, що не примушує індекс кешу взагалі знаходиться в одному місці. Я б додав a npm cache lsі raw ls ~/.npm/* -alу сам сценарій збірки перед будь-яким іншим кроком збірки лише для того, щоб забезпечити стан контейнера при запуску збірки.
Тенсібай

Відповіді:


5

Я нарешті вирішив це, використовуючи кешування шарів зображень Docker для установки npm, дотримуючись цієї відповіді

Це означає, що я перемістив npm встановити з підлеглого зображення Docker і перетворити насправді на зображення фронту, ось мій остаточний файл Docker, який справді кешує встановлення npm між збірками, якщо package.config не має змін:

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 для роботи. Пропоную скористатися моїм рішенням
Брайан Огден

моя ситуація інша. Кожен раз, коли запускається збірка, раб буде надаватися на k8s. Тому я не можу кешувати на основі процесу збирання докера. Я хочу базуватися на кеш-пам'яті NPM, щоб я міг монтувати постійний об'єм у підлеглий кожен раз, коли це буде передбачено
Нгуен

0

Ще один підхід, який ви можете зробити, - це налаштувати сервер сховища nexus, де ви розміщуєте свої npm-модулі та проксі зовнішні. Це не використовує кеш, але оскільки ресурси знаходяться у вашій локальній мережі або, можливо, в тому ж рої, це не повинно зайняти так довго.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.