Comments 57
В примере с docker compose сеть app-network не нужна, уберите ее совсем и docker compose создаст сеть по умолчанию.
Можно. Но хорошим тоном будет всегда указывать сети явно. Например, если на сервере работает не один проект, а два и больше.
Хорошим тоном будет не создавать лишних сетей. Сеть default создаётся всегда, и "создавая сеть явно" вы удваиваете число создаваемых сетей на проект. Зачем?
А почему удваивается?
Не совсем всегда, а когда есть хотя бы один контейнер без кастомной сети. В данном примере будет создана только одна сеть app-network, но если хотя бы в одном из 3 контейнеров закомментировать networks, то дополнительно создастся XXX_default.
Смотрите, про хороший тон я не знаю, однако объясню вам логику, которая может быть.
Итак, есть некий компоуз. В общем случае он действительно может запускаться где угодно и иметь дефолтную подсеть. Однако бывают случаи, когда мы не совсем знаем, где придётся его развернуть и толгда подсеть будет уже и не дефолтная.
Опять же, в общем случае это как бы и не проблема - ну, а какая разница? Сервисы изолированы там, порты биндятся, всё круто, так? Так, но не совсем. БЫвают случаи, когда в компоузе указываются все имеющиеся сервисы, а после создаются профили. Например сервер или кластер СУБД может быть вынесен во вне. Или быть на хосте. Или ещё как-то. Почему так? Да в целом не ажно - так бывает. А ещё там может быть фаеволл. А ещё приложение может быть составным - ну, например, разные микросервисы, которые общаются друг с другом по API. Опять же, не спрашивайте, почему такое может быть. И да, может это не совсем нормальная ситуация, но жизнь вообще не идеально.
Следовательно, мы не хотим годать, что там на хосте и в какую подсеть попадёт то или иное. Мы ведь докер зачем используем? Чтобы получать ожидаемые результаты, верно? Вот мы как бы и пишем сеть, что бы покрыть не самый удачный вариант и не гадать, каким сетян надо открыть доступы, куда стучаться, ну и вот это вот всё.
Что нам это даёт? ДА банально экономию времени, как бы отсекая потенциальный траблшутинг. Перестраховка это? Да. Надо делать нормально и лучше контролировать ситуацию? Да. Но иногда это невозможно и написание нескольких строчек впрок создаёт меньше головняка, чем 1 лишняя сеть на хосте.
А потом появляется привычка просто сразу закладывать риски, даже маловероятные.
Ну и какая во всех перечисленных вами случаях разница, дефолтная сеть используется контейнером или не дефолтная? Они ж отличаются только названием, и то если им название не указали явно...
Положим у вас один их контейнеров - БД MySQL. В ней созданы пользователи, у пользователей есть привязка к сетям, с которых они имеют доступ. С точки зрения безопасности лучше явно указать IP сете например это IP сетей контейнеров, взаимодействующих с БД. А еще, например, нужен доступ с хостовой машины для удобства администрирования БД. Для этого в docker -compose в секции networks: явно указываются эти сети.
Не вижу смысла настраивать ограничение по сетям для СУБД, упакованной в контейнер и запрятанной в полу-изолированную сеть.
Ну и даже если IP-адреса всё же нужны, я всё ещё не виду разницы между дефолтная сетью и недефолтной.
Далеко не всегда контейнер работает только в изолированной среде, например к той же БД нужен доступ с других машин, а значит крайне желательно настроить ограничение по IP.
> Ну и даже если IP-адреса всё же нужны, я всё ещё не виду разницы между дефолтная сетью и недефолтной.
Разница в том, что в дефолтной сети вы не контролируете выдачу IP. И неизвестно какие IP выделены контейнерам/группе контейнеров. Более того вам вообще неизвестно какие адреса в дефолтной сети.
Ну вот никак не контролирую выдачу IP? Правда?
networks:
default:
ipam:
config:
- subnet: 10.0.0.0/24
Так всё-таки, в чём разница-то?
Когда вы определяете таким образом сеть, то создается уже новая кастомная network со всеми своими параметрами, отличная от дефолтной "bridge". Посмотрите на выводы docker network ls, docker network inspect.
С каких пор в docker compose дефолтная сеть называется "bridge"?
Посмотрите на выводы docker network ls, docker network inspect.
Вот такие сети создаются по умолчанию (если файл docker-scompose.yaml лежит в директории mayorovp):
4ce9cc4dff78 bridge bridge local
50ceb1b2f232 host host local
dc009365d16e mayorovp_default bridge local
922a51b1e953 none null local
А вот такие - если сконфигурировать default:
4ce9cc4dff78 bridge bridge local
50ceb1b2f232 host host local
3689ab569368 mayorovp_default bridge local
922a51b1e953 none null local
В чём, блин, разница?
А что если у меня десятки мелких баз данных и я хотел бы установить один сервер mysql на хосте для использования в разных проектах. Понятно что не тру, будет работать?
я хотел бы установить один сервер mysql на хосте для использования в разных проектах
Зачем на хосте?
можно и в докере. будет сильно проще?
В общем-то всё, что нужно – чтобы до сервера mysql был доступ из проектов. И тут даже неважно, docker или не docker, важно как настроена сеть и т.п.
Может у вас все проекты в одной внутренней сети докера крутятся с mysql, тогда конечно проще.
Или у вас отдельный хост конкретно под mysql, и тогда для проектов вообще не важно, как именно он развёрнут, они с ним будут работать как с чёрным ящиком.
Тогда вопрос уже в том, важны ли накладные расходы, которые создаёт docker, на производительность диска, например.
ну вот например есть сервис в контейнере который хочет подключиться в БД. какой хост указать в настройках сервиса чтобы он мог достучаться до mysql установленной на основном хосте? контейнеру сервиса надо добавлять сеть bridge ?
"Кошерный" путь – использовать особую магию докера. Добавить опцию host.docker.internal:host-gateway
В compose-файле это будет выглядить как дополнительная запись в настройках сервиса:
extra_hosts:
- "host.docker.internal:host-gateway"
После этого нужно будет настроить сервер mysql, чтобы он слушал сеть докера. И это при условии, что сервис поднят в сети докера по-умолчанию...
В общем, не знаю, шаманство какое-то, сам таким не пользовался. Проще и правда поднять mysql в контейнере в той же сети, что и сервис.
P.S. Более простой путь – выбрать тип сети host для контейнера с сервисом. Тогда он сможет дойти до mysql просто по localhost. Но это не секьюрно.
Вообще, mysql может работать через линукс-сокеты, это надо и mysql и клиента подключить к одинаковой директории вроде
volumes:
- /var/run/mysqld/:/var/run/mysqld/
Если я правильно понял, у вас на одной и той же машине БД не в контейнере и сервис в контейнере? Если так, то из внутренней сети контейнера IP-адрес хоста - это всегда 172.17.0.1.
Но как тут уже сказали, лучше БД тоже поместить в контейнер, этот контейнер добавить в сеть сервиса, и тогда у БД внутри этой сети будет hostname, совпадающий с именем сервиса БД, который указан в docker-compose.yml.
Да хоть 50 баз данных, причем при необходимости можно даже разные версии ставить на одной хост машине
Понятно что не тру, будет работать?
А почему не должно работать? Вам надо будет лишь в проектах задавать один и тот же адрес и указывать корректное имя базы. А в случае, если запустите в контейнере - просто следить, чтобы контейнер работал.
Вопрос только в том, что это не так уж и гибко.
Будет, если поднять mysql как отдельный контейнер с пробросом порта на гостевую машину, все остальные контейнеры смогут взаимодействовать с ним по сети
Раз уж упомянут Golang и многоэтапная сборка, то неплохо бы упомянуть замечательную возможность golang - делать бинарики независимыми ни отчего вообще (ну на самом деле зависимость остается только от загрузчика программ ОС). Тогда образ второй фазы будет содержать только Go-шный бинарик.
FROM golang:1.16 AS build
WORKDIR /go/src/app
COPY . .
RUN go build -o myapp
CGO_ENABLED=0 go build -o myapp
FROM scratch
WORKDIR /root/
COPY --from=build /go/src/app/myapp .
CMD ["./myapp"]
Эта фишка доступна любому статически компилируемому языку, не только лишь Go.
В других языках не всегда так просто отказаться от динамической линковки. Был болезненный опыт с C++... деталей уже не вспомню, давно было.
А в Go всё собирается статически в 99% случаев.
Кстати, а много вообще таких достаточно популярных языков, которые собирают код в статический бинарь и не тянут за собой тяжёлый рантайм?
Ну вот например, можно ли как-то наколдовать "легковесную яву" в докере? У меня в своё время не получилось, но не могу сказать, что я сильно пытался.
В чём плюс этого подхода? У вас все зависимости просто зашитиы в бинарник, и теперь их нужно перекомпилёвывать и загружать в докер каждый раз заново, в то время как одна из главных особенностей докера - отделение зависимостей в отдельные слои, чтобы их каждый раз не качать.
Я понимаю, если бы приходилось вручную деплоить экзешник на разные системы с разными установленными пакетами и потенциально без админских прав - тогда это безусловно было бы плюсом, а так не вижу преимуществ.
Если вы уже пишите на Go, то отказаться от статической линковки — задача нетривиальная. А если что так, что эдак, зависимости зашиваются в бинарник, то нет причин не уменьшить размер итогового образа.
Вы вероятно не совсем поняли суть, которая тут происходит.
У нас имеется образ с компилятором golang (это может быть любой образ, может вы собираете ffmpeg, там огромное количество всего вам понадобится). Этот образ, условно, пусть будет весить 600мб
Компилируем бинарник (если это будет ffmpeg, то например компилируете его в один статичный бинарник, пусть на выходе это будет около 50мб)
За конечный образ берете например alpine, т.к. у вас нет никакой линковки, то бинарник будет просто запускаться. Итог: конечный готовый образ у вас будет 60мб (условно), т.е. 50мб ffmpeg + OS alpine.
Та часть dockerfile где мы компилировали мы можем выкинуть уже из системы.
Аналогично делается сборка например веб приложений - собираем фронт в образе ноды, бинарник сервера в образе чего-либо, в конечный образ копируем результаты сборки фронта и бэка в любой легкий образ.
Адекватно неписано, хотя про базовые образы и как их создавать самому хотелось бы почитать подробнее.
Почти все, что вы хотели бы знать про Docker
- Создавать и делиться собственными изображениями;
Фоточки можно хранить?
может еще кто подскажет как в докере запускать ui-приложения с открытием окна этого приложения в виндувсе
без докера, но запустить gui приложение на сервере и пробросить иксы на винду умеет из коробки https://mobaxterm.mobatek.net/
К сожалению, после того как полностью прикрыли возможность использовать Docker бесплатно для бизнеса, санкции практически закрыли возможность оплачивать лицензию, а в России так и не разрешили официально пиратить буржуйское ПО, есть большие сомнения по поводу целесообразности использования Docker в серьезных проектах. А также есть опасения что и дальше будут расти лицензионные ограничения. По сути это теперь не open source, хотя они пока и заявляют обратное.
использовать Docker бесплатно для бизнес
Мне кажется вы щас смешиваете три раздельные вещи:
Исходники под открытой лицензией и совершенно бесплатны
Качать образы с докерхаба можно совершенно бесплатно
Аплоадить свои образы на докерхаб... Ну я бы очень подумал хорошо ли это с т.з. безопасности.
Качать образы с докерхаба можно совершенно бесплатно
но есть лимиты
Исходники под открытой лицензией и совершенно бесплатны
ну тут скорее речь об docker desktop и иже с ними. Мы вот были вынуждены перейти на rancher desktop. Это просто боль и страдания после docker desktop
но есть лимиты
Поднять у себя в контуре кэширующую прокси полезно в любом случае на случай "докерхаб упал"/"кому-нибудь в очередной раз моча в голову ударила и заблокировали сетевую связь или с той или с этой стороны".
Мы вот были вынуждены перейти на rancher desktop. Это просто боль и страдания после docker desktop
А можете развернуть мысль? А то я тоже перешёл на rancher desktop и... Всё отлично работает.
И про какую операционку на хост-машине речь? А то если там линукс, то польза от всех этих *desktop очень быстро стремится к нулю.
И про какую операционку на хост-машине речь? А то если там линукс, то
польза от всех этих *desktop очень быстро стремится к нулю.
macos intel/arm
А можете развернуть мысль?
когда в организации 1000+ пользователей то это боль. Начиная от ui, но это мелочи, и заканчивая непонятными вылетами. Еще была куча проблем со встроенным кубиком. И таких ошибок вагон и маленькая тележка.
последнее что нашел в слеке
% sudo launchctl load /Library/LaunchAgents/se.ivankrizsan.socat_launcher.plist
Warning: Expecting a LaunchDaemons path since the command was ran as root. Got LaunchAgents instead.
`launchctl bootstrap` is a recommended alternative.
Load failed: 5: Input/output error
Try running `launchctl bootstrap` as root for richer errors.
А то я тоже перешёл на rancher desktop и... Всё отлично работает.
у меня такая же нога и не болит ( с )
у меня такая же нога и не болит ( с )
Очевидно что не такая же, я потому и спросил в чём разница. Из вашего ответа стало понятно, разница в том что вы используете для серверной разработки наименее подходящую для этого операционку (а уж в arm исполнении там ещё больше приколов вылезает). А зачем вы это делаете?
Из вашего ответа стало понятно, разница в том что вы используете для
серверной разработки
что за серверная разработка )))
а уж в arm исполнении там ещё больше приколов вылезает
а пацаны то и не знали, оказывается arm фуфло ))) Просветите об этом всех облачных провайдеров, а то они тоже не в курсе по ходу. Проблемы были только с ранчером, с docker desktop особых проблем не было. Отсюда делаем вывод - что дело не в ОС
наименее подходящую для этого операционку
потому что в крупных организациях MacOS это отраслевой стандарт. Всякие windows/linux идут лесом
В стиле статьи чувствуется запах ChatGPT.
Насколько я понимаю, главное назначение докера - это не возиться с несовместимостями между версиями питона в пакете Open Lane. Правильно?
Главное назначение — обеспечить порядок в проектах, дать каждому приложению, развернутому в контейнере, свою, подходящую среду. Докер сам контролирует ресурсы между контерами, упрощает деплой и поддержку проектов.
Также есть вытекающие ништяки в виде упрощения ввода нового члена команды в работу на проекте и удобное управление версиями артефактов в виде образов.
Я таких расплывчатых слов не понимаю. Что такое "порядок", "среда", "ресурсы", "образы"? Входят ли в "среду" следующее:
Существование и содержимое файла /etc/udev/rules.d/90-intel-fpga.rules
Версия tclsh, bash, prython3, make, gcc?
Установленые пакеты для питона и тикля?
Нахождение юзера в группе dialout для доступа к устройству /dev/ttyUSB0?
Что еще?
"Всё что нужно знать"
Мне не хватило
1) почему ничего не написано про macvlan драйвер чтобы контейнеры получали IP как виртуальные машины от роутера и были доступны по IP из любого компьютера в твоей локальной сети
2) как реализовать версионность образов. и тема как обновлять запущенные контейнеры на новые версии образов не коснулись в статье
Версионность осуществляется с помощью тегов. Обновляется просто — обновляешь версию образа, пересоздаешь контейнер.
как реализовать версионность образов. и тема как обновлять запущенные контейнеры на новые версии образов не коснулись в статье
это уже больше про ci/cd и Docker Swarm. Докер, как таковой, к этому особого отношения не имеет
Спасибо большое за статью! Когда искал пару месяцев назад подобную статью, не нашёл ничего подобного. Сутки потратил на создание простого Docker Compose файла для своего проекта.
Почти все, что вы хотели бы знать про Docker