смени endpoint на pchostname:9000

смени endpoint на pchostname:9000

чтобы это у всех разразботчиков работало, нужно что-то типа $(hostname)?

не, не поможет

Добавь link в hasura_console на hasura и исправь endpoint на hasura:9000 без указания http

http там надо 100% указывать

Добавь link в hasura_console на hasura и исправь endpoint на hasura:9000 без указания http

а для чего link нужен?

оно же без них умеет общаться по service name

а для чего link нужен?

он доки не читает, забей

оно же без них умеет общаться по service name

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

он доки не читает, забей

Кинь хотя бы ссылку чтоле, раз такой умный

окей, с --endpoint хоста заработало, возник другой вопрос. Как в docker-compose.yml прокинуть HOSTNAME хоста?)

советуют всякие HOST_HOSTNAME=$HOSTNAME docker-compose up

окей, с --endpoint хоста заработало, возник другой вопрос. Как в docker-compose.yml прокинуть HOSTNAME хоста?)

взять и прокинуть

https://docs.docker.com/compose/environment-variables/

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

нпм же с нодой идет

нпм же с нодой идет

вопрос другой был

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

вообще в образ вендор добавлять лучше

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

нпм же с нодой идет

ну это понятно, т.е. нужно сделать образ ноды + npm

вообще в образ вендор добавлять лучше

в образ вендор? что?)

в образ вендор? что?)

что тебе нужно?

бинарник npm?

бинарник npm?

у меня есть проект. В нем используется связка php + nginx + mysql Как поднять эти три контейнера я знаю. Вопрос встает в сборке с зависимостями. Есть composer и npm, которые используются. Я не знаю куда их впихнуть, чтобы собрать проект. 1. На хост машине можно, НО это требует доп. установки пакетов при развертывания 2. Создать отдельные 2 контейнера под каждый сервис Считаю, что нужно делать 2 вариант

P.S. Только начал изучать докер, поэтому не ругайтесь сильно :)

то что генерит compose\npm\maven\etc - vendors

в Dockerfile это надо тянуть и в образе держать

а если добавят что-нибудь, придется пересобирать образ?

да

а если добавят что-нибудь, придется пересобирать образ?

https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f

даже на русском)

спасиб, но его уже прочитал ахах)

к чему тогда вопросы?

у меня есть проект. В нем используется связка php + nginx + mysql Как поднять эти три контейнера я знаю. Вопрос встает в сборке с зависимостями. Есть composer и npm, которые используются. Я не знаю куда их впихнуть, чтобы собрать проект. 1. На хост машине можно, НО это требует доп. установки пакетов при развертывания 2. Создать отдельные 2 контейнера под каждый сервис Считаю, что нужно делать 2 вариант

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

Все как в той статье выше.

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

ну тут мультистейдж особо ничего не изменит, можно и по классике

а если добавят что-нибудь, придется пересобирать образ?

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

ну тут мультистейдж особо ничего не изменит, можно и по классике

Ну как, вендор и нодмодлс можно закешировать

Ну как, вендор и нодмодлс можно закешировать

он и так кешируется же

он и так кешируется же

Ну если просто в 1 stage то не кешируется.

Хотя если отдельным слоем...

Ну если просто в 1 stage то не кешируется.

да прекрати)

ну да

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

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

делай по статье и не изобретай

Ну тогда надо в образе иметь composer и npm. Такое себе удовольствие

делай по статье и не изобретай

++++

Ну тогда надо в образе иметь composer и npm. Такое себе удовольствие

ну это уже оптимизация, он до неё ещё не дошёл

ну это уже оптимизация, он до неё ещё не дошёл

Поможем парню не создать гигабайтный образ?

нет, для начала и гб образ норм

нет, для начала и гб образ норм

Суровый ты)

ну так будет понятно и наглядно, эдакий hello, world для докера

тут объясняется как поднимать приложение, используя nodemon и serve, вообще впервые слышу про это, ладно, что-нибудь придумаю

тут объясняется как поднимать приложение, используя nodemon и serve, вообще впервые слышу про это, ладно, что-нибудь придумаю

Нееее, там про другое. Ща кароч

тут объясняется как поднимать приложение, используя nodemon и serve, вообще впервые слышу про это, ладно, что-нибудь придумаю

Я не читал её, глянул только dockerfile, вот так тебе и нужно по-сути собирать

Я не читал её, глянул только dockerfile, вот так тебе и нужно по-сути собирать

запускает сервер ноды, мне это не нужно, у меня нжинкс же

в этом докерфайле*

ну да, мне впринципе это нужно, только сервак не запускать и все ахха)

Сложно же как

Мы про вендорс говорили

Сложно же как

для меня ПОКА да, та при чем тут вендорс то?)

вендорс, это папка, где просто хранятся зависимости

запускает сервер ноды, мне это не нужно, у меня нжинкс же

там суть в multistage. В том что ты одним контейнером собираешь, и уже собранное переносишь в итоговый. Таким образом тебе не нужно иметь утилиты для сборки в контейнере приложения. А если у тебя какой-нибудь фронтенд, то вообще можно нехило сэкономить ресурсов

вендорс, это папка, где просто хранятся зависимости

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

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

оке, а для npm'a есть смысл, так как там нужна нода?

оке, а для npm'a есть смысл, так как там нужна нода?

У тебя фронт это статика или nodejs приложение?

в сборке есть команда add serve?

У тебя фронт это статика или nodejs приложение?

я не ебу, я бэк хахах ну а вообще вроде не было

мне фронт говорил писать npm install + npm run build

я не ебу, я бэк хахах ну а вообще вроде не было

у тебя бекенд и фронтенд это один и тот же код или разделено на frontend + api backend?

раздельно, фронт собирается через npm

мне фронт говорил писать npm install + npm run build

А фронт уверено что оно так заработает ? ?

А фронт уверено что оно так заработает ? ?

да, а почему бы и нет :)

крч ладно, пойду попробую, если что-нибудь сломаю, снова буду вас доставать :) Спасиб

да, а почему бы и нет :)

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

крч ладно, пойду попробую, если что-нибудь сломаю, снова буду вас доставать :) Спасиб

Вот докерфайл для сборки фронта который под nginx. Под себя только команды поправить. Он тебе поможет экономить 200-300мб на каждом билде ? # ---- Базовый Node ---- FROM node:8.11-alpine AS builder # Создать директорию app WORKDIR /app # ---- Зависимости ---- FROM builder AS dependencies # Используется символ подстановки для копирования как package.json, так и package-lock.json COPY package*.json ./ # Установить зависимости приложения, включая предназначенные для разработки ('devDependencies') RUN npm install && yarn install # ---- Скопировать файлы/билд ---- FROM dependencies AS build WORKDIR /app COPY . /app # Собрать статические файлы react/vue/angular RUN yarn build && yarn add serve # The production environment FROM nginx:1.14-alpine COPY --from=build /app/build /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]

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

https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f

Имхо в deve добавлять node_modules не как persistence volume это бред, на каждое добавление npm пакета будут переустанавливаться и скачиваться все пакеты заново

Мы часто добавляем, удаляем или обновляем npm пакеты, и это очень много времени занимает, поэтому добавили волум на node_modules и ~/.npm

Такое ощущение что такие статьи пишутся людьми, которые сами это не используют

Вот докерфайл для сборки фронта который под nginx. Под себя только команды поправить. Он тебе поможет экономить 200-300мб на каждом билде ? # ---- Базовый Node ---- FROM node:8.11-alpine AS builder # Создать директорию app WORKDIR /app # ---- Зависимости ---- FROM builder AS dependencies # Используется символ подстановки для копирования как package.json, так и package-lock.json COPY package*.json ./ # Установить зависимости приложения, включая предназначенные для разработки ('devDependencies') RUN npm install && yarn install # ---- Скопировать файлы/билд ---- FROM dependencies AS build WORKDIR /app COPY . /app # Собрать статические файлы react/vue/angular RUN yarn build && yarn add serve # The production environment FROM nginx:1.14-alpine COPY --from=build /app/build /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]

Красиво. А зачем переопределен CMD для nginx?

Команда же идентична той, что в базовом образе, да? =)

Ага, ну бывают такие фэйспалмы, не без этого)

Всегда надо думать самому, а не слепо копировать

Такое ощущение что такие статьи пишутся людьми, которые сами это не используют

Такие статьи пишутся для сборки под продакшен, не для разработки.

Такие статьи пишутся для сборки под продакшен, не для разработки.

Я бы ничего не сказал, если бы там не писали о том, что это подходит и для разработки

Красиво. А зачем переопределен CMD для nginx?

Для очевидности, не более

Нео серебряной пули, это пример, один из

Я бы ничего не сказал, если бы там не писали о том, что это подходит и для разработки

Второй пункт про разработку

Всем привет, ребят.

Compose еще актуален?

Compose еще актуален?

Для дева или прода?

Для дева или прода?

Для прода

Для прода

Некоторые ещё так делают, скажем так :)

Некоторые ещё так делают, скажем так :)

А как правильно?