@coder_ex будет жить. Поприветствуем!

1ns1ght будет жить. Поприветствуем!

есть кто по docker может помочь?

если не использовать -v, то библиотеки доступны кто может разъяснить в чем проблема?

Docker version 18.06.1-ce, build e68fc7a хостовая ОС - Linux

Не уверен на 100%, но вероятно потому что node_modules складываются в /var/www/html. А так как при подключении вольюма докер не мержит содержимое двух директорий, а оставляет только содержимое директории с хостовой системы, папка node_modules исчезает

Removed msg from Konstantin. Reason: new user + external link

так и есть, но как тогда может работать пример отсюда https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f

у меня он начинает работать, когда я внутри контейнера по новой ставлю пакеты

по идее я хочу накатить GULP в контейнер и сделать автообновление проекта, что бы на хостовой машине были исходники, я их на ней правил, а библиотеки лежали бы в контейнере

Если честно, я бы тогда монтировал src в конкретную папку, лежащую внутри той, что с node_modules - тогда и модули не сотрутся, и исходный код с хостовой машины менять удобнее

К примеру в /var/www/html ставятся модули, в /var/www/html/src монтируется папка с исходниками, и nodemon смотрит за src/server.js

К примеру в /var/www/html ставятся модули, в /var/www/html/src монтируется папка с исходниками, и nodemon смотрит за src/server.js

так в итоге это и получается, но мне приходится из контейнера эти модули ставить может есть какое другое решение, я уже в ступоре если честно

Я только завтра за ноутом буду, смогу скинуть примерно как я себе это представляю, ок? Если конечно никто другой не придумает более красивого варианта решения проблемы)

Буду признателен

с утра встал, смонтировал каталог src, в Dockerfile указал путь к исходнику в CMD CMD [ "nodemon", "src/server.js" ] и модули теперь видны в контейнере, все обновляется при изменении, спс за подсказку, но все равно жду от вас вашего примера, а то в docker я пока нуб и нужно смотреть как делают знающие )))

200$

Фамилия говорящая

Многообещающая)

с утра встал, смонтировал каталог src, в Dockerfile указал путь к исходнику в CMD CMD [ "nodemon", "src/server.js" ] и модули теперь видны в контейнере, все обновляется при изменении, спс за подсказку, но все равно жду от вас вашего примера, а то в docker я пока нуб и нужно смотреть как делают знающие )))

просто внутри контейнера ставьте все модули как -g и не парьтесь над их местоположением

у вас же всё равно 1 контейнер - 1 апп

у вас же всё равно 1 контейнер - 1 апп

ну в принципе да, а это нормальная практика создать контейнер, в него поставить все что нужно и на его основе создать образ, а в процессе кодинга, просто брать нужный образ и работать?

а еще интересен один момент, контейнер когда создается, где он распологается - диск либо память?

ну в принципе да, а это нормальная практика создать контейнер, в него поставить все что нужно и на его основе создать образ, а в процессе кодинга, просто брать нужный образ и работать?

ну как бы это и есть один из основных юзкейсов, и вам не нужно гемороится с пакетами окружения и их конфликтами.

а еще интересен один момент, контейнер когда создается, где он распологается - диск либо память?

контейнер запускается из имидж

имидж на диске.

всё что контейнер изменяет, он изменяет в "виртуальной" фс, и после остановки контейнера это всё исчезнет.

а что мешает сделать контейнер с нужными модулями npm, а потом юзать его в мультистейдже? Докидывая в /var/www/html (или куда то еще) свой проект?

вы можете промаунтить на хост диру в которую контейнер что то сохраняет и тогда оно будет сохраняться между заапусками

а что мешает сделать контейнер с нужными модулями npm, а потом юзать его в мультистейдже? Докидывая в /var/www/html (или куда то еще) свой проект?

а как тут мультистейдж поможет ? копипастить модули из слоя ? зачем ? )

так вот и интересует вопрос - контейнер как расположен, если это память с каким то свопом в файл, то вдруг я перегружу хост-систему и тогда все удалится, кроме того видел в примерах, что после работы контейнера его удаляют через rm, отсюда и вопрос, если я образ вижу где расположен, то где контейнер находится не понятно

всё что контейнер изменяет, он изменяет в "виртуальной" фс, и после остановки контейнера это всё исчезнет.

после остановки ничего не теряется. Теряется после удаления

после остановки ничего не теряется. Теряется после удаления

ну как бы зависит

так все таки контейнер как расположен - память или диск?

так все таки контейнер как расположен - память или диск?

контейнер нигде не расположен, это просто изоляция процессов, а в качестве файловой системы overlayfs

контейнер нигде не расположен, это просто изоляция процессов, а в качестве файловой системы overlayfs

ну т.е. это по сути временный объект и значит его после каждой работы нужно удалить, я правильно понимаю?

ну т.е. это по сути временный объект и значит его после каждой работы нужно удалить, я правильно понимаю?

не совсем. Если он тебе не нужен - можешь удалить. Это как с приложениями - если оно тебе вообще не нужно, то ты его удаляешь, если оно тебе сейчас запущенным не нужно - ты его останавливаешь

не совсем. Если он тебе не нужен - можешь удалить. Это как с приложениями - если оно тебе вообще не нужно, то ты его удаляешь, если оно тебе сейчас запущенным не нужно - ты его останавливаешь

а после перезагрузки хостовой систем ни чего не попортится?

а после перезагрузки хостовой систем ни чего не попортится?

а что должно портиться?

ребутнешь хост - контейнеры упадут и при запуске докер их поднимет обратно в том же состоянии что и до падения, ведь docker rm им никто не делал, а значит содержимое сохранено

ну к примеру внутри файловой системы самого контейнера, в процессе работы ведь что то там добавляешь и т.д.

можешь сам проверить ?‍♂️

ребутнешь хост - контейнеры упадут и при запуске докер их поднимет обратно в том же состоянии что и до падения, ведь docker rm им никто не делал, а значит содержимое сохранено

понятно, спс за разъяснения а еще в доках видел API на Python, если его использовать то можно ведь без docker-compose работать тогда?

можно, но зачем?

если все написали уже до тебя

можно, но зачем?

ну это вопрос для понимания

я так понимаю docker-composer это вспомогательный интерфейс, который настраивается конфиг-файлами

если тебе надо взаимодействовать с докером из какого то приложения, то да, API пригодится. А самому руками его дергать через самописные велосипеды это странное занятие, учитывая что есть готовое решение от разработчиков докера

если тебе надо взаимодействовать с докером из какого то приложения, то да, API пригодится. А самому руками его дергать через самописные велосипеды это странное занятие, учитывая что есть готовое решение от разработчиков докера

имете в виду композер?

имете в виду композер?

любое приложение. Может ты хочешь свой оркестратор написать. Или модуль для puppet/ansible. Или еще что то

две недели парился, не додумался сразу найти канал, спасибо большое всем

за две недели можно было документацию докера наизусть выучить ?

за две недели можно было документацию докера наизусть выучить ?

я не такой умный

в любой непонятной ситуации смотри официальную документацию

в любой непонятной ситуации смотри официальную документацию

смотрю всегда, но много не понятного из-за перевода, английский только со словарем

что за хешированные файлы остаются после очистки образов? путь к файлам /var/lib/docker/image/overlay2

что за хешированные файлы остаются после очистки образов? путь к файлам /var/lib/docker/image/overlay2

Образы жеж

Образы жеж

а почему эти файлы не удаляются когда удалешь образы?

если руками почистить подкаталоги то проблем с докером потом не будет?

а почему эти файлы не удаляются когда удалешь образы?

После docker rmi .... по идее ничего не должно оставаться

если руками почистить подкаталоги то проблем с докером потом не будет?

По идее, не дллжно. Но гарнтии дать не могу

остается, поэтому и задал вопрос ))

можешь попробовать через system prune

docker rm $(docker ps -a -q) -f