а нужны ли мне эти ваши docker-контейнеры?

а нужны ли мне эти ваши docker-контейнеры?

если не понимаешь зачем, то нет

Docker - это серебряная пуля или стрельба из пушки по воробьям?

Docker это инструмент. Контейнеров у тебя не куча, это всё, включая их сборку, можно удобно описать в docker-compose.

Docker хорош для установки программ, которые требуют установки и настройки рантайма, в котором лениво разбираться. Если со стеком знаком, то в контейнерах смысла становится мало, по крайней мере до тех пор, пока не хочется использовать условные кубернетесы.

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

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

Спасибо!

4+5 можно заменить на traefik. на нем же можно построить некое подобие api gateway для зоопарка 2+6+7

Если ты один работаешь, то делай как удобней. Если в команде, лучше докер. Одним скриптом развернуть все сервисы под любой ОС. Лично мне неприятно ставить всякие постгресы на свой компьютер. Контейнер удобней. Не захламляет систему. Поэтому я всегда пользуюсь докером.

Я тоже сначала подумывал сделать контейнеры более жирными. Даже рассматривал вариант сделать из всего один супер-контейнер, однако быстро передумал, так как появляются проблемы с UID:GID разных расшаренных каталогов, которые используются внутри контейнера разными сервисами с разными UID. К тому же, если шинковать не мелко, то усложняется сам контейнер и смысл в использовании Docker значительно снижается. Докер же как раз про то, что один сервис - один контейнер. Да, это все должно быть закинуто на VDS и, казалось бы, логично было бы использовать докер. Но для меня это, пока, ЕДИНСТВЕННЫЙ, аргумент в его пользу

для разработки на своей уютной Fedora я вообще использую VirtualBox с нужным окружением под каждый проект. Вот на макбук с M1 приходится извращаться и использовать Docker, так как нормальных виртуалок я на него не нашел

не слышал про него. 6 и 7 недоступны снаружи. С 6 работает только 2, а с 7 работает только 6. Наружу смотрит только 2 и 3

docker-compose, если попроще. Если хипстер, то разворачивай в кластере kubernetes.

SQL-сервер

Если нагрузка на него большая, то лучше не пихать его в контейнер. Там проблемы с I/O могут быть.

для разработки на своей уютной Fedora я вообще использую VirtualBox с нужным окружением под каждый проект

Можно и так, конечно, хотя по-мне докер удобней такого подхода.

Вот на макбук с M1 приходится извращаться и использовать Docker, так как нормальных виртуалок я на него не нашел

Fusion, Parallels, UTM. qemu в конце концов?

Спасибо. Об этом не знал

Если нагрузка на него большая, то лучше не пихать его в контейнер. Там проблемы с I/O могут быть.

Какие проблемы? Маунтишь папку с хоста и всё.

У тебя каждый сервис развёрнут ровно 1 раз и ты не собираешься развёртывать ещё уйму для покрытия других регионов, стейджинга, бетатестеров и прочих нужд? Тебе скорее всего не нужен докер.

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

Нет, докер тут не нужен.

В моем случае, я вижу в использовании Docker только усложнение конфигурации и лишнюю точку отказа. Прав ли я?

Всё верно.

Как вы думаете: Docker - это серебряная пуля или стрельба из пушки по воробьям?

Докер это кривой костыль от начала до конца. Используется нубами для компенсации своего нубства. Разумеется, неудачно, но (у них) лучше чем ничего.

Просто не используй его нигде, если на то нет конкретного заказа от твоих клиентов. Докер-советчиков шли нафиг.

Одним скриптом развернуть все сервисы под любой ОС

Не скрипты для ОС а ОС для скриптов. А проблемы компа разработчика никак не должны отражаться на прод-архитектуре.

https://doc.traefik.io/traefik/ а конкретнее, https://doc.traefik.io/traefik/https/acme/

Вот на макбук с M1 приходится извращаться и использовать Docker, так как нормальных виртуалок я на него не нашел

Он и есть виртуалка везде кроме линукса. Только не пойму зачем тебе разворачивать окружение на больше чем одном устройстве. Есть рабочее место, там и сделай всё, остальной бардак следует устранить.

https://doc.traefik.io/traefik/

Какая большая концентрация всяких модных слов. Ещё и на go. Типичное поделие докер-модников, я бы держался подальше.

Не скрипты для ОС а ОС для скриптов.

Не понял.

А проблемы компа разработчика никак не должны отражаться на прод-архитектуре.

Ну в проде уже давно у всех докер и кубер, тут даже разговаривать не о чем.

Не нужны. Есть же NixOS

Не понял.

Это значит что приложение не должно париться о поддержке разных ОС, у него должна быть спецификация того, что ему НУЖНО, и, условно говоря, ОС должна париться о том, чтобы этим требованиям соответствовать.

А ситуация когда скрипты занимаются вопросами всяких совместимостей приемлема разве что для шаред-хостингов, где ты вынужден «жрать что дают».

Если у разработчика, желающего локально развернуть приложение на своём компе, туда установлена несовместимая с приложением ОС - то это его проблемы, и они никак не повод добавлять в приложение поддержку того, чего не нужно в проде (любые ОС кроме штатной).

Хм. Я правильно понял, что это HTTP-прокси с балансировкой нагрузки и встроенным клиентом Let’s Encrypt?

Хм. Я правильно понял, что это HTTP-прокси с балансировкой нагрузки и встроенным клиентом Let’s Encrypt?

да, но не только http – есть поддержка чистых tcp/udp

да

«один докер == один сервис» полностью согласен, но не «один докер == одна программа» это уже дрыгоножество и рукомашество.

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

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

Тема из серии «вот хочу Yesterday послушать, но говорят что попса что банально и слащаво, а может что упускаю, как-никак самая исполняемая песня! Напойте пожалуйста, особенно призываются в тред Рабиновичи!».

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

В моем случае, я вижу в использовании Docker только усложнение конфигурации и лишнюю точку отказа.

Нет

Прав ли я?

Нет

Может я просто устал и упускаю что-то?

Да

Как вы думаете: Docker - это серебряная пуля или стрельба из пушки по воробьям?

Да, но нет.

тот же сертбот от https потребителя отрывать нет смысла.

я бы сказал, что нет смысла об этом вообще думать. Думать надо о своем приложении, которое кодишь. Раскидывать его на микросервисы или нет, резать по разным докерам или нет и тп. А думать о том, где будет ingress, а где let’s encrypt не надо, это НЕ относится к сервису.Есть готовые решения, если на собираем на коленке в тесте в докер-композ, то https://hub.docker.com/r/jwilder/nginx-proxy к нему же letsencrypt. все забирается с переменных в окружении и все, можно сосредоточится на основной задаче, а не заниматься херней. Ну и с кубами это будет настолько еще проще, что даже писать нечего об этом.

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

дыкыть теория теорией, а %тс% настало время думать об шинковке системы на сервисы, админ он, девопс али «ко всякой дырке затычка» смысла обсуждать нет. у %тс% вполне полноценный по параметрам запрос.

Это значит что приложение не должно париться о поддержке разных ОС, у него должна быть спецификация того, что ему НУЖНО, и, условно говоря, ОС должна париться о том, чтобы этим требованиям соответствовать.

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

Если у разработчика, желающего локально развернуть приложение на своём компе, туда установлена несовместимая с приложением ОС - то это его проблемы, и они никак не повод добавлять в приложение поддержку того, чего не нужно в проде (любые ОС кроме штатной).

Нет, это не его проблемы. Это проблемы твои, как работодателя. Потому, что ты будешь платить за то время, которое он потратит, мудохаясь с тем, чтобы запустить всё это. И ты будешь платить +50% по рынку, чтобы от тебя не убегали на адекватные технологии.

ну я к тому, что ему не надо думать о базе, сертификатах и nginx. Ему надо думать о своем приложении, о том как доставлять трафик пусть думает клиент. Если открыть почти любой проект, то там всегда на выбор дают примеры, вот типа как это запустить в docker-compose, или вот вам helm. или просто вот докер запустите на коленке, чтобы потыкать палочкой.

Основная мысль, что есть готовые решения , надо их взять и все.

P.S. база данных как сервис тоже к приложению не относится. Надо давать возможность цеплять внешнюю базу данных. Так как выбор где и как онп бдет запущена должен быть на стороне заказщика/пользователя. Если это высоко нагруженная штука, то никто не будет запускать ее в докере, ее подключат сбоку. А если это недобаза, чтобы сохранить туда пару-тройку переменных, тогда можно и в докере.

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

Если его рассматривать как слой совместимости несовместимых компов с приложением - может быть (хотя есть и другие варианты). А вот на проде это как раз то, что я указал как лишнее: некая лишняя прослойка совместимости между приложением и ОС, вместо того чтобы совместимой была сама ОС сразу.

В моем случае, я вижу в использовании Docker только усложнение конфигурации

А как ты собрался это все запускать, руками по одному? Писать скрипт, который будет это все запускать?

Нет, это не его проблемы. Это проблемы твои, как работодателя. Потому, что ты будешь платить за то время, которое он потратит, мудохаясь с тем, чтобы запустить всё это. И ты будешь платить +50% по рынку, чтобы от тебя не убегали на адекватные технологии.

Все так, подтверждаю

да хоть systemd юниты, путей много

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

Ок, предположим я отделил БД от докера и крутится она у меня локально. Есть ли адекватные способы прокинуть локальный порт в докер-контейнер? То о чем я читал - какая-то дичь: либо использовать net-host, но это размывает идею контейнеризации, либо проброс порта через SSH в контейнер, но это медленно и как-то нелепо

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

предположим я отделил БД от докера и крутится она у меня локально. Есть ли адекватные способы прокинуть локальный порт в докер-контейнер? То о чем я читал - какая-то дичь: либо использовать net-host, но это размывает идею контейнеризации

А крутить БД на хосте и обращаться к ней из контейнера - это не дичь?

вот теперь подумываю, может и правда 3, 4, 5 - в один контейнер, 2, 6, 7 в другой и 1 в третий. Так, действительно, сложность значительно снизится

и это в том числе

Я не понял ответ, но если не дичь, то и net-host - тоже не дичь.

это дичь. Я писал про net-host, отвечая на это:

P.S. база данных как сервис тоже к приложению не относится. Надо давать возможность цеплять внешнюю базу данных. Так как выбор где и как онп бдет запущена должен быть на стороне заказщика/пользователя. Если это высоко нагруженная штука, то никто не будет запускать ее в докере, ее подключат сбоку. А если это недобаза, чтобы сохранить туда пару-тройку переменных, тогда можно и в докере.

вот теперь подумываю, может и правда

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

Общий ресурс для всех приложений, в данном случае БД - тоже в свой контейнер.

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

Надо давать возможность цеплять внешнюю базу данных.

Это не значит «обязательно» выносить БД на хост, это значит БД может быть где угодно и приложению нужен только DSN для подключения.

Ок, предположим я отделил БД от докера и крутится она у меня локально. Есть ли адекватные способы прокинуть локальный порт в докер-контейнер? То о чем я читал - какая-то дичь: либо использовать net-host, но это размывает идею контейнеризации, либо проброс порта через SSH в контейнер, но это медленно и как-то нелепо

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

Если ты постгрес забиндишь на 127.0.0.1, тогда я не знаю, как это решить. Наверное --net=host поможет, но я не пробовал.

А так - ты в постгресе пишешь в конфиге, чтобы он биндился на 0.0.0.0, обязательно убеждаешься, что внешние соединения блокируются фаерволом. После этого ты в докер-композ добавляешь extra_hosts: [ "host-gateway:host-gateway" ] (не помню, как в командной строке это прописать, но можно и без композа, конечно, сделать) и прописываешь адрес БД как host-gateway. Это будет что–то вроде 172.17.0.1, т.е. это внутренний адрес хоста в сети для докер-контейнера. Ну и всё должно работать.

Но вообще я советую сначала попробовать запустить постгрес в докере. У нас на проде работает несколько баз в докере, проблем нет. Просто сделай volume в локальную папку. Тогда всё ещё проще будет.

Просто не используй его нигде, если на то нет конкретного заказа от твоих клиентов. Докер-советчиков шли нафиг.

У тебя есть опыт разработки web-сервисов? Хотя не важно. Как без докера ты сможешь гарантировать, что у тебя тестовое окружение соответствует prod'у? Или как ты изолировать будешь сервисы?

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

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

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

и тебе не надо чтобы это работало 24/7?