Привет всем! столкнулся с проблемой: docker-compose не видит env файл в другой директории. Структура проекта такая: -docker-compose.yaml -/app —/api —- .env подскажите плс что делать:)

а с чего ты решил что он должен видеть его ?

в доке же есть примеры похожие

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

Если что пиши на прошлой неделе переносили могу с 3.4 на 6

привет. Не ловили проблему с exit code 51? Что-то Монге в путях не хватает. mongod —fork ... отваливается с 139ой ошибкой. (попытка залезть в недоступную память)

привет. Не ловили проблему с exit code 51? Что-то Монге в путях не хватает. mongod —fork ... отваливается с 139ой ошибкой. (попытка залезть в недоступную память)

Нет

тут сисадмины помогли. В среде старый докер был (v19), и образ поэтому не мог завестись. Сообщения об ошибках только всех с толку сбили.

тут сисадмины помогли. В среде старый докер был (v19), и образ поэтому не мог завестись. Сообщения об ошибках только всех с толку сбили.

Подскажите как определенным контейнерам можно запретить доступ к определенному ip. Поковырял iptables на машине, что хостит контейнеры. Методом тыка вывел вот такое правило: iptables -I DOCKER-USER -p tcp -d 192.168.10.0/24 -s 172.17.0.4,172.17.0.5 -j DROP Однако из моей практики лучше к ip внутренний сети докера (172.17.0.4) ничего не привязывать, ибо они завтра могут поменятся, если контейнеры стартануть в другом порядке. Нужно одному контейнеру разрешить, двум другим заблочить.

как запускаете и почему именно так ?

Не совсем понял вопроса.

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

я бы создал две сети, одна external, другая internal. интернал на всех 3ёх контейнерах и на одном который может обращаться к серверу, ему добавить ещё одну которая external

Запущено все сейчас с docker run. А запретить хочется некоторым контейнерам доступ к домашней сети, что по wg подключена к серверу с докером.

ну, создать сеть и запретить ей доступ к сети wg

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

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

потом при docker run image container_name указать ещё --network

ну, создать сеть и запретить ей доступ к сети wg

А блокируем доступ новой сети к wg через iptables?

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

Всем привет. Можете подсказать, пожалуйста, как можно правильно разделить dockerfile & docker-compose & env_files для разных сред? Я несколько запутался в том, как это должно выглядеть без особых костылей: Например, у меня 3 разных билда: dev, test, prod и 3 разных докер-композ файла. Докер-композ файл тоже свой для разных сред (хоть и похожи между собой сильно). Мне, получается, нужно что-то вроде такой структуры делать? ├───deploy │ ├───dev │ │ dev.dockerfile │ │ docker-compose.dev.yml │ │ │ ├───prod │ │ docker-compose.prod.yml │ │ prod.dockerfile │ │ │ └───test │ docker-compose.test.yml │ test.dockerfile │ └───environments common.env service1.env service2.env

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

Ну а с зависимостями как быть? Они же разные.

Для дев окружения (то что используется на машине разработчика) допустимо иметь девелоперский образ, обвешанный дев зависимостями. В теории можно его же использовать на CI для прогона автоматизированных тестов. На test и prod выкатывать production-версию образа. Использовать multistage build. Вначале собирается дев образ со всеми дев зависимостями, затем на его основе собирается production образ, в который попадает только собранное приложение и прод зависимости.

Ок, согласен. А насчет компоуз-файлов тогда как?

Свой compose на каждое окружение - норм. Выносить отдельно .env - имхо излишне, там один к одному с окружениями, можно все вшивать в compose. Файл common.env - в печь: если эти параметры не отличаются на разных окружениях то это должно быть захардкожено в само приложение, если могут в будущем отличаться - должно быть продублировано во всех compose.

Свой compose на каждое окружение - норм. Выносить отдельно .env - имхо излишне, там один к одному с окружениями, можно все вшивать в compose. Файл common.env - в печь: если эти параметры не отличаются на разных окружениях то это должно быть захардкожено в само приложение, если могут в будущем отличаться - должно быть продублировано во всех compose.

Не понял с .env. Что значит "захардкожено"? db_user условно хардкодить?

в случае с db_user лучше продублировать

Немножко запутался. Т.е. у меня, выходит, должна быть такая структура: ├───deploy │ ├───dev │ │ docker-compose.dev.yml │ │ │ ├───prod │ │ docker-compose.prod.yml │ │ │ └───test │ docker-compose.test.yml │ ├───environments │ service1.env │ service2.env │ └───multistage.dockerfile

multistage.dockerfile docker-compose.dev.yml docker-compose.test.yml docker-compose.prod.yml либо multistage.dockerfile docker-compose.yml dev.env test.env prod.env

У меня нельзя юзать один докер композ, там разный состав сервисов.( А разные env файлы для разных сервисов. Т.е. в условном сеовисе1 юзается енв файл с переменными только для сервиса1 и т.п.(

Ну тогда первый вариант. Вся конфигурация окружения (сервисы и их настройки) в одном docker-compose файле этого окружения. И не нужно будет ломать голову сопоставлять определенный сервис из определенного docker-compose с определенным .env

Ну енв файлики все равно же будут. Не буду же я хардкодить db user и т.п.

а, типа чтобы секреты не коммитить

Всем привет. Можете подсказать, пожалуйста, как можно правильно разделить dockerfile & docker-compose & env_files для разных сред? Я несколько запутался в том, как это должно выглядеть без особых костылей: Например, у меня 3 разных билда: dev, test, prod и 3 разных докер-композ файла. Докер-композ файл тоже свой для разных сред (хоть и похожи между собой сильно). Мне, получается, нужно что-то вроде такой структуры делать? ├───deploy │ ├───dev │ │ dev.dockerfile │ │ docker-compose.dev.yml │ │ │ ├───prod │ │ docker-compose.prod.yml │ │ prod.dockerfile │ │ │ └───test │ docker-compose.test.yml │ test.dockerfile │ └───environments common.env service1.env service2.env

у докера нет задач разделять параметры по разным средам

у докера нет задач разделять параметры по разным средам

например у тебя есть сервис app который работает с бд mysql, redis, и имеет несколько oauth приложений (гугл яндекс), есть и s3 хранилище вот под каждый параметр можно задать разное значение а не создававать TYPE=staging|dev|prod и потом по имени этого сервиса уже грузить параметры <- это не очень путь тогда имея сервисы и набор параметров, можно хранение делигировать в другое место например

Здравствуйте, помогитее пожалуйста, у меня докер пишет, что не найден модуль на эти импорты, как мне исправить? import CalendarMonthOutlinedIcon from "@mui/icons-material/CalendarMonthOutlined"; (пиздец, это же просто иконка, у меня таких 50 штук, но на эту ругается) import { DayPicker } from "react-day-picker"; тут тоже хз что делать

У меня нельзя юзать один докер композ, там разный состав сервисов.( А разные env файлы для разных сервисов. Т.е. в условном сеовисе1 юзается енв файл с переменными только для сервиса1 и т.п.(

Хардкодить порты в докер-композ - это норм или плохая практика?

Хардкодить порты в докер-композ - это норм или плохая практика?

в .env лучше хранить их

Хардкодить порты в докер-композ - это норм или плохая практика?

Лучшая практика не использовать #компост

Эм, а как?

А вот так :) деплой в кубер ;) а разрабы локально пусть страдают сами

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