Плюсы докера

Всё, что от облака надо это kubernetes, managed database, object storage, с которыми можно переехать на другое облако в разумные сроки или вообще изначально строить архитектуру на нескольких облаках. И даже managed database нынче не особо нужно, базы в кубере замечательно работают. Вряд ли в мире много идиотов, которые будут пользоваться AWS-специфичными (или GCP-специфичными и тд) сервисами, с которых не переехать никуда. Конечно создателям этих облаков хотелось бы привязать к себе клиентов покрепче, чтобы потом впаривать им вычислительные ресурсы не то, что втридорога, а втримиллионадорога. Но кто-ж им позволит.

Нет там повторяемости. docker run --rm -it ubuntu:12.04 apt-get update уже не работает, хотя всего 13 лет прошло. А эта команда в любом докерфайле первая стоит.

из неконтролируемых

сделай from scratch

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

Вы не сказали за счет чего у докера можно «добиться повторяемой сборки»

Подними свой registry, свои зеркала нужных реп и хоть обповторяйся. Кому надо, так все и делают.

куча шаред хостингов на FreeBSD

firstvds!

докер это васян сборка

Это инструмент. Его нужно по назначению применять.

Расскажи, когда применять облака оправданно?

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

Если кратко, то линуксовые контейнеры сделаны через неймспейсы, без как минимум pid-namespace никак, а дальше для каждого ограничения нужен ещё какой-то. В случае конкретно докера ещё хуже - они все используются в обязательном порядке, независимо от того нужны ли они тебе. В фрибсд же контейнеры прекрасно обходятся без неймспейсов, там просто указываются ограничения. Хотя опционально можно отдельную сеть сделать (примерно так же как сетевой неймспейс с линуксе), но этим пользуются, наверно, только те, кто роутеры в контейнере хостит, для просто приложений оно не нужно. Как результат:

1) ты сам выбираешь что тебе надо ограничивать, а что нет;

2) pid процессов прозрачно видны внутри/снаружи, хост может посылать им сигналы обычным kill например или ещё что-то с ними делать, да может показаться крутым что в линуксе эмулируется собственный init(pid1) для каждого контейнера, но на практике это штука бесполезная, а иногда и мешающая

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

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

Что-то скорее всего забыл.

Ну дык. Ты обломал весь кайф. Если всё самому делать, то нафига этот докер.

centos_install.iso + kickstart

и всё развернулось и работает

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

centos_install.iso + kickstart

Если все стоящие перед вами задачи решаются с помощью одной-единственной конфигурации centos, то, вполне вероятно, docker вам низачем не пригодится

Это как? Кто отвечать на коннекты будет?

одной-единственной конфигурации centos

как ты пришёл к выводу об «одной-единственной конфигурации»?

разные kickstart не рассматриваются?

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

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

как ты пришёл к выводу об «одной-единственной конфигурации»?

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

разные kickstart не рассматриваются?

Почему бы и не рассмотреть. Давай рассмотрим, например, как ты будешь использовать разные kickstart с ubuntu-server.iso или с alpine-standard.iso

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

да, но по сути это просто опции в ядре.

1. ты сам выбираешь что тебе надо ограничивать, а что нет;

аналогично

#например чтобы ограничить права на изменение системного времени
lxc.cap.drop = sys_time
#чтобы ограничить права на все хостовые устройства
# lxc.cgroup.devices.deny = a
#чтобы дать права на некоторые блочные устройства 
lxc.cgroup.devices.allow = b 8:* rwm

2. pid процессов прозрачно видны внутри/снаружи, хост может посылать им сигналы обычным kill например или ещё что-то с ними делать

в lxc аналогично снаружи видны процессы контейнера, и им можно посылать сигналы. Изнутри - не проверял.

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

если это chroot, то какая разница? Или ты про service jails ? (https://docs.freebsd.org/en/books/handbook/jails/#service-jails)

вся сеть настраивается на хосте в одном месте, контейнерам только указываются доступные айпи-адреса, никаких виртуальных интерфейсов,

ну в общем-то разницы почти никакой

lxc.network.type = veth
lxc.network.link = br1

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

ip-адреса тоже можно указать в конфиге контейнера, но я предпочитаю это делать средствами содержимого контейнера (аналога thick jail). То что, там разные сетевые пространства имен никакой доп. нагрузки в администрировании не дает.

Ну к примеру я хочу запустить два вордпресса на одном сервере. Один должен отвечать на production.com второй на test.com. С идентичной конфигурацией (но разными базами, конечно, и вообще всем разным). А завтра ещё захочу stage.com добавить. И не заниматься port management-ом. В докере каждый сервис запускается в своей виртуалке, а если всё на хост биндится, будет куча гемора. Не говоря уже о том, что требуется, чтобы целевой сервис давал конфигурировать свой порт, что далеко не всегда есть.

ОК, давайте придираться к словам. dockerfile тоже был в единственном числе. у вас один докер на всех :-)

мне комфортно с centos там механизм kickstart’а уже встроен. в убунту iso надо его добавить. ищи «ubuntu unattended installation»

или любой нормальный дистр + ansible

Ну дык. Ты обломал весь кайф. Если всё самому делать, то нафига этот докер.

Поднять registry в докере, не?)

centos_install.iso + kickstart

Всё так, кроме того, что 30 сервисов ты устанешь саппортить вручную.

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

да, но по сути это просто опции в ядре.

Я не про то как они называются, а про то как они работают. Вот на примере изоляции процессов. Задача: сделать чтобы хостовые процессы были недоступны для контейнерных. Хорошее решение (фрибсд): вставим в код проверки доступа условие «процесс, который хочет доступ, должен быть либо в том же контейнере, либо снаружи от процесса, к которому он обращается». Плохое решение (линукс): давайте введём разные пространства идентификаторов процессов, лишим pid универсальности, добавим специальную логику для контейнеризованного pid1, и как побочный эффект от всего этого - контейнерные процессы перестанут видеть хостовые. И так везде.

в lxc аналогично снаружи видны процессы контейнера, и им можно посылать сигналы. Изнутри - не проверял.

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

если это chroot, то какая разница?

Всмысле какая разница? В том и дело, что в докере не chroot а mount namespace, из-за которого чтоб добраться до файлов контейнера надо пачку костылей применить, и вообще сходу непонятно где что расположено. Да, это недостаток именно докера а не линукса. Линуксовый контейнер можно и через chroot сделать, хотя возможно без mount namespace там будут проблемы безопасности.

ну в общем-то разницы почти никакой

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

аналога thick jail

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

То что, там разные сетевые пространства имен никакой доп. нагрузки в администрировании не дает.

Создаёт, конечно. Вот смотри, я ввожу команду

jail / x 1.2.3.4 csh

Ты всё-таки не объяснил что ты хочешь. Домены это абстракция верхнего уровня, на слушание портов они не влияют. У сервера есть несколько айпи-адресов для этих разных доменов? Тогда назначь их контейнерам. Или айпи-адрес один, а эти домены - виртуальные http? Тогда нужно установить nginx который рассортирует входящие запросы по контейнерам в зависимости от домена. Не вижу каким образом это всё касается сравнения разных контейнеров.

У меня нет разных айпи адресов. В докере я запускаю контейнер и он доступен по http://containername/. Я же говорю - задача - запустить два приложения, которые биндятся на один порт. Или двести двадцать два приложения. Докер это умеет делать. Каждому контейнеру назначается внутренний виртуальный IP-адрес и конфигурируется внутренний DNS-сервер. Самое главное тут - что контейнер никак не надо менять, всё просто работает автоматически.

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

Каждому контейнеру назначается внутренний виртуальный IP-адрес и конфигурируется внутренний DNS-сервер. Самое главное тут - что контейнер никак не надо менять, всё просто работает автоматически.

Твой внутренний сервер виден только внутри, на запросы снаружи он не влияет. А соединения, пришедшие на твой один ip-адрес, кто-то должен пробросить на приватный адрес контейнера, перед этим как минимум распарсив TLS ClientHello. Обычно этим занимается nginx. Возможно, в докере такая штука тоже есть в упрощщённом виде, но причём тут контейнеры? Это всё равно внешнее по отношению к ним реверс-прокси.

Ты не про то вообще говоришь. Как коннекты принимать и раскидывать это к делу не относится. Да, в третьем контейнере запускается caddy и там всё раскидывается, или через любой другой реверс-прокси, это всё понятно.

Вопрос был конкретный - как запустить два контейнера, которые биндятся на один порт.

Судя по тому, что ответа нет - в FreeBSD это сделать нельзя принципиально. В докере можно.

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

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

мне комфортно с centos там механизм kickstart’а уже встроен.

Ну так я об этом и говорил. CentOS/kickstart позволяет вам решать ваши задачи комфорным для вас образом и в docker’e в вашем случае нет никакой необходимости

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

Ты не про то вообще говоришь. Как коннекты принимать и раскидывать это к делу не относится. Да, в третьем контейнере запускается caddy и там всё раскидывается, или через любой другой реверс-прокси, это всё понятно.
Вопрос был конкретный - как запустить два контейнера, которые биндятся на один порт.
Судя по тому, что ответа нет - в FreeBSD это сделать нельзя принципиально. В докере можно.

А, такое можно конечно. Тогда это не «один порт», а одинаковые порты на разных айпи. Слушаешь ими 80 порт, выдаёшь разным контейнерам разные приватные адреса - в итоге они слушают например 192.168.150.1:80, 192.168.150.2:80, 192.168.150.3:80, но каждый считает его либо 0.0.0.0 либо локалхостом (оба адреса jail заворачивает на адрес контейнера). Можешь и одинаковые адреса сделать через виртуальную сеть, но, повторюсь, это лишнее усложнение, а в данном случае ещё и путаница будет если у всех контейнеров одинаковые айпи-адреса.

Всмысле какая разница? В том и дело, что в докере не chroot а mount namespace, из-за которого чтоб добраться до файлов контейнера надо пачку костылей применить, и вообще сходу непонятно где что расположено.

mount_namespaces ? но это для изоляции списка примонтированных ФС. На доступ к файлам контейнера из хоста никак не влияет. Опция lxc.rootfs является аналогом опции path в freebsd jail

Да, это недостаток именно докера а не линукса.

возможно так. Как оно сделано в docker - не знаю.

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

можно указать lxc.network.type = none

none: will cause the container to share the host's network namespace. This means the host network devices are usable in the container.

Или lxc.network.type = phys и пробросить конкретный сетевой интерфейс хоста в контейнер. Просто с мостами на мой взгляд работать удобнее, если использовать контейнеры как легковесные VM, а не как средство изоляции процессов

jail / x 1.2.3.4 csh

Во-первых, как следует из man (https://man.freebsd.org/cgi/man.cgi?query=jail&sektion=8&manpath=FreeBSD+7.4-RELEASE) эта команда требует предварительной настройки хоста (иначе как он узнает, на какой сетевой интерфейс назначать ip alias).

ifconfig ed0 inet alias 192.0.2.100/32
mount -t procfs proc /data/jail/192.0.2.100/proc
jail /data/jail/192.0.2.100 testhostname 192.0.2.100 /bin/sh /etc/rc

И не забыть про:

Since  jail is implemented using IP aliases, one of the first things to do is to disable IP services on the host system that listen on all local IP addresses for a service. 

Во-вторых этот синтаксис устарел и современный (после freebsd 7.4) синтаксис очень похож на lxc-execute

jail path=/data/jail/192.0.2.100 host.hostname=testhostname ip4.addr=192.0.2.100 command=/bin/sh /etc/rc

А сам выше?

И какое именно из моих высказыванием вас смущает?

А, ну то есть виртуальная сеть таки есть, два контейнера могут слушать 0.0.0.0:80 и быть доступными с хоста или из других контейнеров под своими виртуальными IP. Ну тогда осталось только DNS прикрутить, чтобы IP не хардкодить, но это ладно, это уже мелочи. Тогда пригодно. А я думал это просто chroot. Если это всё ещё и работает без костылей вроде линуксового iptables, а какими-то встроенными средствами ядра, то совсем шикарно. Ибо докер в этом плане реально бесит.

Ну ты про LXC пишешь. LXC лучше чем докер, да.

Насчёт остального:

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

Монтировать что-то не обязательно (часто нужен devfs но и тут бывают проги которые к нему не обращаются, proc точно не нужен, впрочем контейнеры тут ни при чём).

Назначение айпи-адресов на интерфейсы никак не связано с контейнером, jail только фильтрует сисколлы чтобы контейнер не смог забиндить себе не тот адрес (и заворачивает вилдкарды и локалхосты на правильный). Ты вполне можешь создать контейнер с адресом, которого у ОС нет, работать такая сеть конечно не будет (контейнер его разрешит, но основное ядро ОС уже нет) но суть в том что jail-ам всё равно - они не занимаются менеджментом сети. Можно ещё и создать 10 контейнеров на одном айпи-адресе и всё будет работать (правило про запрет бинда одного и того же ip:port двумя прогами никуда конечно не денется, но выдача адреса контейнеру никакие порты сама по себе не захватывает). По-моему такая схема работы покрывает 99% всех сетевых контейнерных нужд, и при этом она в разы проще неймспейсов.

Это не виртуальная сеть, просто jail им 0.0.0.0 завернёт на назначенные контейнерам хостовые айпи-адреса на каком-то хостовом сетевом интерфейсе. Все аспекты видимости этих айпи-адресов из других мест управляются обычным сетевым конфигом хоста (интерфейсы, роутинг, файрволл). Если выдашь приватные айпи - будут видны только внутри, выдашь публичные - будут видны и с других хостов, на поведение внутри контейнера это не повлияет.

Если это всё ещё и работает без костылей вроде линуксового iptables

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

Но виртуальная сеть тоже есть (называется VIMAGE), но ей почти никто не пользуется т.к. это лишние сложности ради непонятно чего.

Про следующий пожар в AWS.

Удобно, если сервер новый настраивать, быстро.

Этого достаточно. Юникс вей же. Одна огромная мегараспиаренная система для выполнения одной маленькой функции.

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

Просто из быстро гугла случай «всякого» https://habr.com/ru/articles/262043/

А его не будет?

В он-прем он будет с гораздо более высокой вероятностью и более серьёзными последствиями. Тут к Ванге ходить не надо.

Просто из быстро гугла случай «всякого» https://habr.com/ru/articles/262043/

Пришлось аж на 10 лет назад гуглить, понимаю. Вообще, отказ по железу, на любом хостинге может случиться. В чем проблема поднять из бекапа? Ах, не делал бекап? Ну тогда ССЗБ.

Как будто просто установить ubuntu 12.04 сейчас и сделать apt-get update будет работать. Или любой другой подход к повторяемости сборок, он тоже гарантирует архив всего интернета на 100 лет?

Любой подход к повторяемости сборок гарантирует повторяемость сборки через 100 лет и независимость её от существования Интернета в принципе.

docker build не даёт никаких инструментов для повторяемости сборки. Это тупо замена шеллскрипту. Последовательность команд.

Думаю, что если очень постараться, можно и повторяемую сборку с докером сделать. Но это явно не то, как пишут 99% докерфайлов и докер тут особо не поможет.

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

Для обычных разработчиков достаточно шеллскрипта в dockerfile и простого compose. Это достаточно повторяемо, решает 99% возможных проблем.

В основном ещё заморачиваются с lock файлами (само собой, это не сам докер), пинят конкретные версии базовых образов, или даже забирают исходные билдфайлы себе. Это добавляет ещё одну-две девятки.

Для бинарного прям сходства нужно делать docker pull вместо повсеместного запуска docker build. Здесь уже 100% повторяемость, которая нужна в основном для деплоя, а не для разработки. У безопасников естественно свои реалии, но не сомневаюсь что с докерфайлом им работать проще, чем ходить на сервера и руками/скриптами проверять что там не так.

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

Вряд ли в мире много идиотов, которые будут пользоваться AWS-специфичными (или GCP-специфичными и тд) сервисами, с которых не переехать никуда

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

достаточно шеллскрипта в dockerfile и простого compose. Это достаточно повторяемо, решает 99%

Это добавляет ещё одну-две девятки.

оптимистично. к 70% если только добавляет девятки

в главном докерном дистре в репо удаляют пакеты минорных версий

В он-прем он будет с гораздо более высокой вероятностью

А вот про вероятности это вы зря, на предприятии с повышенной пожароопасностью вероятность таки выше.

Пришлось аж на 10 лет назад гуглить, понимаю.

А вы это только для сиюминутных поделок предлагаете использовать?

А вы это только для сиюминутных поделок предлагаете использовать?

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

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

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

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

Да что за дерьмо у тебя в голове?! Docker — это набор утилит для работы с контейнерами. Можно создать образ в Docker, потом разместить в Amazon ECR и запустить эту радость в Amazon ECS. Docker вообще ни в одном месте не конкурирует с вашим ненаглядным AWS.

Т.е. с тем что облака могут погореть вы уже согласны. Ок. Теперь про бэкапы. Представьте ситуацию: В облаке горят ваши данные, их восстанавливают из бэкапа, но за время прошедшее между последним бэкапом и пожаром вы внесли какие-то очень важные изменения и считаете что они у вас сохранены. Потом вы вносите изменения и ещё изменения, но эти изменения внесены в более старую копию, но вы об этом не вкурсе.
Разница между колокейшином/другим физ. оборудованием и облаков в том, что «пожар» в первом случае вы заметите.