так у меня этот контейнер же завершается, exec относится только к действующим контейнерам

Значит надо разобраться почему он завершается. Когда он завершается, а потом ты делаешь run он запускается вне docker compose, соответственно без подгрузки .env

так у меня этот контейнер же завершается, exec относится только к действующим контейнерам

переопредели command, чтобы не падало и посмотри execом env

Значит надо разобраться почему он завершается. Когда он завершается, а потом ты делаешь run он запускается вне docker compose, соответственно без подгрузки .env

завершается потому что нужные переменные окружения не попадают в контейнер, там по умолчанию development окружение, пума настроена только для production окружения, пума завершается и контейнер соответсвенно тоже завершается

переопредели command, чтобы не падало и посмотри execом env

не понял, что за command?

завершается потому что нужные переменные окружения не попадают в контейнер, там по умолчанию development окружение, пума настроена только для production окружения, пума завершается и контейнер соответсвенно тоже завершается

Как ты определил, что они не попадают?

Запустил новый контейнер и не увидел их там?

Естественно их там не будет

Как ты определил, что они не попадают?

docker logs app [1] Puma starting in cluster mode... [1] * Version 3.12.0 (ruby 2.5.1-p57), codename: Llamas in Pajamas [1] * Min threads: 8, max threads: 32 [1] * Environment: development <======================== [1] * Process workers: 4 [1] * Preloading application [1] * Listening on tcp://0.0.0.0:3000 [1] ! WARNING: Detected 1 Thread(s) started in app boot: [1] ! #<Thread:0x00005646e821c9d0@/usr/local/bundle/gems/activerecord-5.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:297 sleep> - /usr/local/bundle/gems/activerecord-5.2.1/lib/active_record/connection_adapters/abstract/connection_pool.rb:299:in `sleep' [1] Use Ctrl-C to stop

Посмотри логи контейнера, после того как он упал

Ок, а если явно указать значение в докер композе?

не понял, что за command?

COMMAND в докерфайле

Ок, а если явно указать значение в докер композе?

Вот здесь странность, явно указываю - эти переменные все равно не попадают в контейнер. Пробовал по разному переписывать docker-compose.yml вдруг там отступы или лишние строки невидимые влияют - все так же, не помогает

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

Сделай как предложили выше, знамени команд на какой-нибудь sh и проверь переменные

Сделай как предложили выше, знамени команд на какой-нибудь sh и проверь переменные

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

COMMAND в докерфайле

спасибо, продвинулся

потому что это пидарская софтина, при каждом ребилде сжирает дисковое пространство - непонятно куда оно его девает

Давай ты будешь свои "неосилил" в культурной форме выражать?

спасибо, продвинулся

?

всем привет, подскажите пожалуйста, можно ли сделать docker-compose файл, в котором будет 2 сервиса использующий один и тот же порт(суть в том что это 2 сервиса которые одновременно никогда не должны работать, но один основной, а второй будет приходить на замену первому не на долго по рассписанию, например что то типа заглушки на время тех работ)

всем привет, подскажите пожалуйста, можно ли сделать docker-compose файл, в котором будет 2 сервиса использующий один и тот же порт(суть в том что это 2 сервиса которые одновременно никогда не должны работать, но один основной, а второй будет приходить на замену первому не на долго по рассписанию, например что то типа заглушки на время тех работ)

Может лучше сделать энтрипойнт в контейнере?

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

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

Тогда, может повесить их на разные порты, а трафик разруливать выше?

так причем тут докер? логика будет на уровне этих сервисов, поведение от наличия докера никак не сменится

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

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

а на счет 2 порта одновременно это понятно

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

Compose описывает конечное состояние системы

еще раз, докер тут не при чем

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

Почему с помощью скрипта нельзя класть разные компоузы?

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

а вообще если есть такая логика, то делать это на основании двух разных демонов не очень

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

А разруливать трафик наверху совсем не хочется?

возьми пример всяких 404/500 ошибок в вебсерверах, оно отдается самим основным сервисом

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

возьми пример всяких 404/500 ошибок в вебсерверах, оно отдается самим основным сервисом

Не обязательно, может быть фоллбэк на статику

А разруливать трафик наверху совсем не хочется?

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

Вопрос в первую очеред в тех возможности, а не альтернативных подходах

ещё вопрос на счет того что композер-"описание конечного состояния системы", если в нем описать сервис который не является демоном, его же можно поднять для выполнения какой-то логики не меняя состояния при этом остальных сервисов одного композа?

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

Ну смотрите, изначально Compose предназначен для описания конечного состояния системы, то есть подразумевается, что оба контейнера будут подняты. В вашем случае, предполагается некий костыль чтобы это обойти. Из наименьших костылей я могу предложить: один контейнер на два сервиса с энтрипойнтом; указание портов каждому контейнеру(чтобы в нужный момент контейнер оказывался на нужном порту); кастомную шаблонизацию(рендерить компоуз на лету с нужными параметрами)

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

Ох, налетели советчики)). Нет, он при старте сразу все сервисы (контейнеры) захочет юзать и их порты, но ты можешь менять порт между контейнерами и делать обновление на лету переключая порт

Ох, налетели советчики)). Нет, он при старте сразу все сервисы (контейнеры) захочет юзать и их порты, но ты можешь менять порт между контейнерами и делать обновление на лету переключая порт

а вот это похоже именно на то что мне нужно

Ох, налетели советчики)). Нет, он при старте сразу все сервисы (контейнеры) захочет юзать и их порты, но ты можешь менять порт между контейнерами и делать обновление на лету переключая порт

+

Ох, налетели советчики)). Нет, он при старте сразу все сервисы (контейнеры) захочет юзать и их порты, но ты можешь менять порт между контейнерами и делать обновление на лету переключая порт

можно подсказать как это сделать или где про это почитать?

Если делать up -d поверх, то оною просто обновит изменения в ямле

Делаешь одному сервису порт 80:3000, когда надо переключить - меняешь этот порт для другого и еще раз docker-compose up -d

тоесть изменить порт в yaml сделать up -d поработать с этим потом обратно изменить и снова то же самое, и он просто перекинет порт, я правильно понял?

Да, он любые изменения применит

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

Но будет остановка контейнеров

Спасибо теперь понял) Это не повредит, а на будущее буду учитывать рестарт)

Тот сервис который был изменён будет пересоздан

Может какие-то параметры не пересоздают таски, не помню

в смыле контейнер пересоздасться или все таки перезапуститься? (Это не кретично но интересно)

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

в смыле контейнер пересоздасться или все таки перезапуститься? (Это не кретично но интересно)

Пересоздастся

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

Наверное) давно композ не юзал, легко же проверить

согласен но спросить ещё легче)))

спасибо ещё раз)

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

Ну это кривое решение, наколенке

Локально сойдёт точно

Локально сойдёт точно

Звучит как production ready :D

Звучит как production ready :D

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

А у кого-то до сих пор?

Ну так-то да...

сделал образ FROM node:8-alpine WORKDIR /app COPY package.json /app RUN npm install COPY . /app EXPOSE 8080 залил на гитлаб реджестри когда в компос сую и собираю говорит web_1 | npm ERR! enoent ENOENT: no such file or directory, open '/app/package.json' почему?

сделал образ FROM node:8-alpine WORKDIR /app COPY package.json /app RUN npm install COPY . /app EXPOSE 8080 залил на гитлаб реджестри когда в компос сую и собираю говорит web_1 | npm ERR! enoent ENOENT: no such file or directory, open '/app/package.json' почему?

потому что файла нет?

сделал образ FROM node:8-alpine WORKDIR /app COPY package.json /app RUN npm install COPY . /app EXPOSE 8080 залил на гитлаб реджестри когда в компос сую и собираю говорит web_1 | npm ERR! enoent ENOENT: no such file or directory, open '/app/package.json' почему?

у меня так COPY package*.json ./

я же его копирую когда образ собираю

я же его копирую когда образ собираю

Так может его как раз и нет по данному пути в момегт билда?

Так может его как раз и нет по данному пути в момегт билда?

есть лежит рядом с Dockerfile

А... Может права надо еще ему дать?

Можно удалить стргки после копирования и провериьь в собранном образе файл и права

может не в тему, но гугл ничего не говорит. Кто-то знает как убрать тротл в убунте ? или вообще в линуксе. В гугл все перепробовал, камень сейчас завис на 400мг из 3.2ггц. Все потому что у меня снят кулер

А как он чувствует есть ли у вас кулер?

может не в тему, но гугл ничего не говорит. Кто-то знает как убрать тротл в убунте ? или вообще в линуксе. В гугл все перепробовал, камень сейчас завис на 400мг из 3.2ггц. Все потому что у меня снят кулер

интересна логика - с какой стороны тут докер. кде под фрибсд не собирал ?

А как он чувствует есть ли у вас кулер?

Температура же

Современные системы отлично распознают отсутствие куллера и обычно просто не запускаются

сделал образ FROM node:8-alpine WORKDIR /app COPY package.json /app RUN npm install COPY . /app EXPOSE 8080 залил на гитлаб реджестри когда в компос сую и собираю говорит web_1 | npm ERR! enoent ENOENT: no such file or directory, open '/app/package.json' почему?

А зачем при билде делать npm install и потом ещё раз собирать?

А зачем при билде делать npm install и потом ещё раз собирать?

это нода - там так принято. модули нужные поставить.

это нода - там так принято. модули нужные поставить.

Ну блин, не только у ноды)

ща попробую без npm install

Ну блин, не только у ноды)

npm install - только у ноды ?

npm install - только у ноды ?

?

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

если тег в docker-compose изменился, то он должен спулить сам

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

сам на свой вопрос сможешь ответить ?

сам на свой вопрос сможешь ответить ?

смогу наверно просто попробую

если тег в docker-compose изменился, то он должен спулить сам

не менялся

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

По моему надо сделать docker-compose pull

не менялся

тогда надо еще pull сделать

спасибо

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

:latest? Используй какое-то id лучше

Всем привет

Как можно узнать на каком ip работает Docker?)

Прописал в hosts 172.17.255.255, но перехожу на сайт там

Unable to connect