RUVDS.com corporate blog
Website development
Virtualization
Node.JS
Comments 22
+4

О господи ru_vds, а что тут профессионального то в описаном? Зашел почитать откровений про опыт использования докера и возможно про оркестрацию, а тут хеллоуворлд для ноды в докерфайле… Статьи 2019 года которые мы заслужили блин… :)

+1
они похоже занялись художественной перепечаткой разной документации. Вот вчера, или позавчера, перепечатали документацию по питоновскому argparse))).
+1
Такие же ощущения.
Еще интересно стало что же значит тогда любительская контейнеризация)
+4
Docker — это инструмент, который позволяет создавать, разворачивать и запускать приложения с использованием контейнеров, независимых от операционной системы, на которой они выполняются. Контейнер включает в себя образ базовой ОС, необходимой для работы приложения, библиотеки, от которых зависит это приложение, и само это приложение. Если на одном компьютере запущено несколько контейнеров, то они пользуются ресурсами этого компьютера совместно.
Первая нормальная статья, где понятно объясняется, что такое Docker и зачем он нужен! Аллилуйя! :) Благодарю!
0
Docker — это инструмент, который позволяет создавать, разворачивать и запускать приложения с использованием контейнеров, независимых от операционной системы, на которой они выполняются. Контейнер включает в себя образ базовой ОС, необходимой для работы приложения, библиотеки, от которых зависит это приложение, и само это приложение.
С созданием образа для Node.js приложения понятно, но непонятно, где и как создаются слои для первых 2-х пунктов: "образ базовой ОС и библиотеки, от которых зависит это приложение"? И нужно ли их создавать отдельно? Что значит фраза: «контейнеры, независимые от операционной системы»? Т.е. образ докера, например, с ОС Linux, можно запускать на машине с Windows или Mac? Или один дистрибутив Linux поверх другого, например, Ubuntu поверх SUSE?
-1
Я как-то объяснил человеку, что Docker, это такой FreeBSD Jail и он сразу всё понял.
0
А что мешает один раз с помощью докера с нодой собрать node_modules, и потом пробрасывать волюмом в дефолтный нодовский контейнер, без строительства и кэшей?

version: '3'
services:
 apptestcontainer:
    image: node:10
    shm_size: '2gb'
    environment:
      MOCHA_FILE: /test-reports/junit-report.xml
    volumes:
      - ../app:/app
      - ./config/config.yml:/app/config.yml
      - ./test-reports:/test-reports
    networks:
      backend: {}
    depends_on:
      - another_app
    working_dir: /app
    command: ["npm", "test"]


Вот тут можно через директивы для docker-compose указать и порты на экспозицию, и модули доставить, и даже дефолтную команду на старт указать.
+2

Обычно мешает то, что контейнеры выполняются в совершенно другом месте и тащить туда весь проект довольно проблематично.
Ну и контейнеры работают не только в docker-compose

0
Dockerfile имеет смысл только в одном случае — при отправке на продакшен. И тогда да — я собираю контейнер, но всё ещё с использованием docker-compose. Просто потому что кучу всего можно и нужно указывать в виде кода, а не ключей для docker build. Но тогда теряется смысл в кэшировании сборки — у меня нет сильных ограничений на время сборки для продакшена — ± 5 минут на node_modules или там nuget — роли не сыграют.

В остальном — локальная разработка, юнит-тестирование, интеграционное тестирование, selenium-тесты — всё это у меня крутится через docker-compose как локально, так и на CI.

А ещё мне просто нравится yaml-разметка, и не нравятся длинные/сложные jenkins-пайплайны.
0

Тут ниже довольно детально уже написали
Общая мысль — кроме локальной разработки существует еще целый зоопарк решений для продакшена и там вольюмы никто никуда таскать не будет и зачастую какие-либо команды выполнять вообще нет возможности

+1
Пример с docker-compose подходит для локальной разработки и всяких CI/CD из говна и палок самописного разлива, он несет с собой ряд ограничений для продакшина:
  • Заметное снижение производительсности в определенных случаях (например, на MacOS) по причине не очень качественной реализации volumes
  • Для работоспособности необходимо рядом держать код. Т.е. его надо дополниельно туда положить и обновлять. В ряде случаев доступа к файловой системе вообще нет.
  • Непонятно, как ставить глобально пакеты, например curl


Поэтому, для разворачивания во всяких k8s и прочих свормах необходим самодостаточный образ без всяких волюмов.

UPD. Пока писал комментарий тут уже ответов понаписали
0
Из нашего опыта: использовали yarn для установки зависимостей в Dockerfile, получался очень большой размер образа.
Оказалось что yarn даже с флагом --production устанавливает dev зависимости, в GitHub вроде даже есть соответствующий issue. Поменяли на npm, размер сократился в 3 раза.
0
RUN mkdir -p ${APP_DIR}
WORKDIR ${APP_DIR}

Здесь mkdir -p лишний, директива WORKDIR сама создает каталог

В теме оптимизации хотелось видеть информацию про образы на основе alpine или debian:*-slim
0
В Рамках статьи про node.js достаточно упомянуть про node:8-alpine и node:8-stretch-slim, указать разницу в размерах и описать накладываемые ограничения.
+1
Лучше бы про кеширование образов рассказали, как шарить те самые node_modules и прочее рассказали.
0
Лишняя запятая в package.json, новичкам может помешать изучить материал
0
Собрал по данной инструкции image, запустил, контейнер стартует и сразу останавливается не давая возможности обратиться через curl. Что я делаю не так?
0
Разобрался, в последней команде CMD [«npm», «run»] вместо run нужно start
0
В коде package.json опечатка: запятая после ''node index.js'' не нужна.
"scripts": {
    "start": "node index.js",
  },
0
Исправили, спасибо. На будущее, для сообщений об опечатках на Хабре есть специальная функция CTRL/CMD+Enter. Прочитать об этом можно здесь.
Only those users with full accounts are able to leave comments. , please.