Я как потомственная гадалка в -1 поколении думаю что кластер метаданных навернулся Интересно просто что я так понял это по всему миру произошло

Кто что думает про сбой ютуба сегодняшний?

Я думаю что @DenisIzmaylov как придёт, даст тебе РО за флуд

Вам не интересно разве из за чего могла упасть такая система как ютуб по всему миру? Не лохи педальные так то делали

Это русские хакеры, инфа сотка

Вам не интересно разве из за чего могла упасть такая система как ютуб по всему миру? Не лохи педальные так то делали

это оффтоп, чего не понятного?

в разных сетях они

в одной же сети. Почему в разных то?

в одной же сети. Почему в разных то?

как ты им сеть указываешь?

это оффтоп, чего не понятного?

а если окажется что это из за того что докер в привелигированном режиме запустил...

как ты им сеть указываешь?

—net=lan2 —ip=10.0.2.xxx при запуске контейнера

—net=lan2 —ip=10.0.2.xxx при запуске контейнера

а че ты их в один композ не впихнешь?

пинг между cont1 и cont2 ходит, между dckr и gw(1.1) ходит, А между dckr и cont1 и dckr и cont2 не ходит.

между cont1 и 1.1 ходит и между cont2 и 1.1 ходит

из LAN пингуются все и dckr и cont1 и cont2

а че ты их в один композ не впихнешь?

это решит мою проблему?

не думаю

а сейчас сеть у них - bridge?

есть ли смысл в твоем случае сделать host?

А вот смотрите, у меня проект на php, но что бы собирать стили нужен gulp и nodejs, как мне лучше его добавить?

А вот смотрите, у меня проект на php, но что бы собирать стили нужен gulp и nodejs, как мне лучше его добавить?

multistage

Или собирать в одном контейнере, а ранить в другом

а сейчас сеть у них - bridge?

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

driver: macvlan

нашел ответ на свой вопрос Mavlan sub-interfaces are not able to directly communicate with the parent interface, i.e. VMs cannot directly communicate with the host. If you require VM-host communication, you should add another macvlan sub-interface and assign it to the host.

Не могу починить [emerg] 1#1: host not found in upstream "php-fpm" in /etc/nginx/conf.d/default.conf:17 Мой docker-compose.yml https://gist.github.com/Lancelot-ONE/69624973251e9c7e3772ff6c4b588647 и nginx.conf https://gist.github.com/Lancelot-ONE/274a4204c0607cab4ab0ef0d359979a4

а если зайти в контейнер с nginx то контейнер php-fpm пингуется?

а если зайти в контейнер php-fpm и проверить - откріт 9000 порт?

Привет. ктото может помочь разобраться в ситуации: есть виртуалка ubuntu в ней лежит .sh - ./ttt.sh установлен docker надо запустить контейнер и в нем запустить этот файлик sudo docker run ubuntu ./ttt.sh чтото не помогает (

через endpoint делается

Или bind mount файла в контейнер сначала

я могу как-то сделать это работать в сворме? docker-machine ssh vm1 "docker stack deploy -c compose.yml zoo" Creating service zoo_zoo2 failed to create service zoo_zoo2: Error response from daemon: rpc error: code = InvalidArgument desc = port '2181' is already in use by service 'zoo_zoo1' () as an ingress port exit status 1 сам компоуз: https://pastebin.com/KPpGrKWt docker-machine ssh vm1 "docker node ls" ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION blah1 * vm1 Ready Active Leader 18.06.1-ce blah2 vm2 Ready Active 18.06.1-ce blah3 vm3 Ready Active 18.06.1-ce blah4 vm4 Ready Active 18.06.1-ce

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

https://docs.docker.com/config/containers/resource_constraints/

По дефолту же итак все жрут

ты не пробовал пойти на работу?

боты не умеют работать

Хочешь присесть на бутылку за отмыв и обналы?)

эти не приседают. они делятся.

а ткните где про вольюмы прочитать. Точнее почему легально volumes: - .:/app - /app/node_modules И как это работает

а ткните где про вольюмы прочитать. Точнее почему легально volumes: - .:/app - /app/node_modules И как это работает

а что в доке докера непонятно ?

а ткните где про вольюмы прочитать. Точнее почему легально volumes: - .:/app - /app/node_modules И как это работает

Работает как линуксовый mount

а что в доке докера непонятно ?

ну мало что, понятно когда прокидываем файлы в контейнер, понятно когда делаем вольюм для данных наших. Но не понятно как работает эта строчка /app/node_modules

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

что-то такое

шарятся файлы в app и папка app/node_modules

шарятся файлы в app и папка app/node_modules

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

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

а цель упражнения-то какая ?

ну вообще была проблема с нодой, контейнер линуксовый, а хост макось. И бинарники с папки нод_модули не работали. В итоге нужно чтобы эта папка была сбилжена с помощью докера

нашел в инете такой метод

но не понял с маунтами

Я бы предложил не мучаться с непонятными конструкциями и маунтить docker_volume:/path/on/the/container таким образом node-modules у вас будут линуксовые и сохраняться между запусками. Просто и без изысков.

Альтернатива - забить на node-modules и каждый раз собирать их заново.

покажи dockerfile/docker-compose - и пару слов - чего именно ты хочешь этим добиться.

http://jdlm.info/articles/2016/03/06/lessons-building-node-app-docker.html

The node_modules Volume Trick

The node_modules Volume Trick

Описанный trick - требует одной архитектуры/OS на стороне docker и ОС предлагаю просто замаунтить docker-volume - будет удобно и практично.

The node_modules Volume Trick

то есть написать volumes: - .:/home/app/chat - node_modules:/home/app/chat/node_modules

покажи dockerfile/docker-compose - и пару слов - чего именно ты хочешь этим добиться.

Сори, вклинюсь в беседу. Для меня тож актуально. Суть достаточно проста, надо кешировать директорию node_modules между билдами. Билд может менять эту директорию, главное не качать в нее все зависимости заново при каждом билде. Потому что их обычно ооочень много и качаются они долго. И вот тож сижу, не могу понять, как работает строка - /app/node_modules предполагаю что создает из директории /app/node_modules вольюм и за счет кеша слоев его переиспользует. Но это так, полет фантазии и предположений

Это было бы просто решить, если бы при docker build можно было маунтить вольюмы. Но пока, на сколько я знаю, этого делать нельзя.

Сори, вклинюсь в беседу. Для меня тож актуально. Суть достаточно проста, надо кешировать директорию node_modules между билдами. Билд может менять эту директорию, главное не качать в нее все зависимости заново при каждом билде. Потому что их обычно ооочень много и качаются они долго. И вот тож сижу, не могу понять, как работает строка - /app/node_modules предполагаю что создает из директории /app/node_modules вольюм и за счет кеша слоев его переиспользует. Но это так, полет фантазии и предположений

Я не могу понять зачем он это делает. Это какая-то хрень. У меня делается просто: ADD package*.js* RUN apt* &&\ npm install &&\ apt purge &&\ apt autoremove если package.json не меняется - run не выполняется. решает кучу случаев. хочется замапить node_modules - ради бога.

Я не могу понять зачем он это делает. Это какая-то хрень. У меня делается просто: ADD package*.js* RUN apt* &&\ npm install &&\ apt purge &&\ apt autoremove если package.json не меняется - run не выполняется. решает кучу случаев. хочется замапить node_modules - ради бога.

Скок у тебя сборка идет? Вот этот самый npm install там же качается куча дерьма, долго и уныло. У меня есть проекты где node_modules весит по 300-400мб =\

add применяется для разархивации вроде, зачем его использовать как copy?

Скок у тебя сборка идет? Вот этот самый npm install там же качается куча дерьма, долго и уныло. У меня есть проекты где node_modules весит по 300-400мб =\

сейчас на самом тяжелом проекте, включая 10 npm build - 10 минут а вообще - вот: https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f#3f9b

сейчас на самом тяжелом проекте, включая 10 npm build - 10 минут а вообще - вот: https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f#3f9b

10 минут? А фронты не ноют что долго?)

add применяется для разархивации вроде, зачем его использовать как copy?

да, copy правильнее использовать.

ADD test.tar.gz /add # Will untar the file into the test directory COPY test.tar.gz /copy # Will copy the file directly

10 минут? А фронты не ноют что долго?)

а package.json часто меняется ?

а package.json часто меняется ?

у меня чот да, частенько

локально у них всё быстро, а что там с CI/CD - другая история

локально у них всё быстро, а что там с CI/CD - другая история

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

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

Стоп. локально ты подобрал набор package.json ? всё работает ? залил в ci /

сейчас на самом тяжелом проекте, включая 10 npm build - 10 минут а вообще - вот: https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f#3f9b

в доке тож node_modules перекачиваются каждый раз

ну и какая тебе разница сколько оно выкатывается, если ты всё уже проверил.

ну и какая тебе разница сколько оно выкатывается, если ты всё уже проверил.

То что разрабы проверили у себя на тачке никого особо не волнует. Они должны выкатить это на тест. А для теста должны собрать через CI docker образ.

А на тест они не редко катят например feature бранчу. По этому собирать приходится достаточно часто

То что разрабы проверили у себя на тачке никого особо не волнует. Они должны выкатить это на тест. А для теста должны собрать через CI docker образ.

ну собирается он полчаса. тебе-то какая разница ?

ну собирается он полчаса. тебе-то какая разница ?

ну пока оно собирается, разрабы как процессор ждущий IO. Вроде занят, но ниче не делает 😄

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

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

Чтобы быстрее катить на тест, чтобы быстрее релизить и тд и тп

чем быстрее выкатят на тест, тем быстрее найдут баги, и выкатят правки. Ну кароч, имхо очевидно.

ну хз, у своих я вот частого изменения package.json не вижу. обычно - выкатили фичу - новый p*.js* потом пара багфиксов с тем же p*.js*