Follow

Один из клиентов нанял чувака, работающего с Докером.

Он ему уже захерачил пучок сервисов за пару дней.

Чувствую себя динозавром, смотрящим прямо навстречу метеориту.

· · Web · 2 · 1 · 5

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

@ky39i Я пытаюсь, но я все еще не могу просто врубиться - у меня мозг просто не думает в режиме "хуяк контейнер (со своей опреационкой и с единственным демоном), рядом еще хуяк контейнер (со своей операционкой и одним единственным демоном), все они постоянно ребилдятся, влезть к ним внутрь можно - но бессмысленно (ведь они все постоянно ребилдятся), данные хранятся в каких-то непонятных местах, и т.д., и т.п".

Не, то есть теоретически понимаю, как все это работает - но меня просто бесит потеря контроля, я не могу просто *не думать*, что там внутри, и как это все починить, если сломается.

Ну то есть, да, я понимаю, "ребилднуть контейнер" - но по мне это дикость на уровне "переустановить Windows"

@drq угу. Я еще это все представляю в масштабе чего-то федерального уровня на 1000+ клиентов, гору соединений и вот этого всего. А в сетях поменьше - ну типа я сам знаю чего где и как происходит и карту и регламент для отдела напишу.

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

@ky39i Проблема в том, что сейчас это становится режимом работы по умолчанию. Это быстро, а значит дешево - и к черту подробности.

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

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

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

@vae Я в курсе, что это не совсем виртуалка (а точнее - совсем не виртуалка), легче не становится.

@ky39i

@drq по моим прикидкам - год/два и придется. Потому что или идти вместе с технологиями, или эникей в ип сидоров.

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

Курсов, кстати, адекватных чет невстречал

@drq @ky39i Мне вот подход к хранению данных наоборот нравится, тут как раз предельно понятно что, где и зачем лежит. А если что-то оказалось непонятно, то при следующем запуске это проявится.

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

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

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

@shuro @drq раскаленными кирпичами была бы уложена дорога в светлое будущее без фатал ерроров. А тут отладка через "наташа мы все уронили" - метод работы. Пугает как-то...

@shuro @drq @ky39i

> И, вроде, всё там у них круто, но смотришь в мониторинг и видишь как у них там за день по ...дцать раз то место на разделах в ноль кончается

Непонятно только какое это отношение к контейнерам имеет. Это достигается и без них.

> А в традиционной схеме админы бы выкладывали раскалённые кирпичи и делали бы всё, чтобы такое не повторялось никогда

Тут тоже можно выкладывать кирпичи. Контейнеры никак не виноваты, что сотрудникам похуй.

@drq @skobkin @ky39i Можно, конечно. Но уже не так обязательно :)

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

Я пробовал, сделать это нормально мне показалось достаточно нетривиальным процессом. А ещё поддерживать ведь надо, пересобирать.

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

@shuro
Ведь суть любого контейнера (что в гипервизоре, что в докер-подобном) - плюшки при работе с самим принципом "контейнера". Просто мне не совсем понятно, чем именно плох Докер? Просто, к примеру, Proxmox это, допустим, Debian, а Докер - Linux Mint. Но плюшки и минусы что у того, что у другого примерно одинаковые. Да, я понимаю что Proxmox гипервизор и все такое, и какого хера типа я сравниваю его с Докером каким-то. Но я сравниваю именно принцип КОНТЕЙНЕРИЗАЦИИ в обоих случаях.
@drq @ky39i

@Kill2BlooD
> Просто, к примеру, Proxmox это, допустим, Debian, а Докер - Linux Mint

ВООБЩЕ мимо.

@shuro @ky39i

@Kill2BlooD Докер и Proxmox они, конечно, используют одну и ту же подсистему, но они очень сильно про разное.

@shuro @ky39i

@drq @Kill2BlooD @shuro @ky39i
Докер по большей части напрямую базируется функционале ядра а proxmox работает через lxc и kvm.

@drq @shuro @ky39i

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

@drq @Kill2BlooD @ky39i Суть контейнера - некий образ-конфигурация, который не постоянен и каждый раз заново создаётся при запуске. Сломалось? Перезапуск и он снова новый. Надо второй такой же? Готово! А на другой машине? Да не вопрос! Но при этом он в общем случае не так уж изолирован от компьютера, на котором работает.

Гипервизор же запускает полноценные виртуальные машины, они вполне себе постоянны. Поменял (или сломал) ты что-то внутри ВМ - изменения там останутся.

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

@shuro @drq @Kill2BlooD @ky39i

> не постоянен

Ааа? Лично мне проще тут думать как об атомарных штуках. Как докер, так и NixOS.

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

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

@inexcode Ну то есть, если приводить пример с тем же Мастодонтом - как бы ни старался я исправить лимит символов на 1000 вместо 500 - оно по щучьему велению все равно проебется, потому что разработчик контейнера так сказал.

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

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

@shuro @Kill2BlooD @ky39i

@drq @shuro @Kill2BlooD @ky39i

То, что настраивается конфигом — просто прокидываешь конфиг.

Касаемо мастодона, они не особо говорят о каком-либо официальном образе. И вот мне нужны кастомные темы. С докером или без — нужно компилить слона, и у меня свой образ контейнера.
Захожу в папку с мастодоном и буквально
git pull
docker-compose build .
docker-compose up -d

Процесс сборки описан в докерфайле. Изменения атомарны, возможны откаты.

@drq @shuro @Kill2BlooD @ky39i

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

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

@inexcode @drq @shuro @Kill2BlooD @ky39i
@vae

Я не люблю работать с Docker. Сервис запускается от root пользователя и надо искать корректно настроенный docker-файл, чтобы минимизировать шансы выхода за пределы контейнера.

Сложнее отслеживать ошибки в контейнере.

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

Использую его редко, в основном чтобы посмотреть функциональность какого-либо сервиса.

@inexcode @drq @shuro @Kill2BlooD @ky39i @vae

Предпочитаю настроить сервис напрямую. Легче отслеживать ошибки в работе.
Средствами SystemD можно настроить режим песочницы - получается некая изоляция сервиса средствами cgroups.

@drq так это не проблема – (1) можно примонтировать отдельный файл с хоста, он перекроет файл в контейнере, (2) можно написать докерфайл, который берёт нужный образ и копирует в него ещё один файл с изменениями, (2.а)(не надо) закоммитить изменённый контейнер в новый образ.

А совсем по-хорошему такое надо выставлять "наружу" через env-переменные или параметры командной строки, чтоб указывать в docker run. Чтоб изолировать параметр для удобства портирования на будущие версии.

@drq
Это ты просто влюбился в свой сервак как в собачонку. А сервера в кластере надо разводить как кроликов. Чтобы и под нож нежалко было когда надо.

@inexcode @shuro @Kill2BlooD @ky39i

@drq
Железка какая-нибудь наебнется - не жалко. Выкидываешь эту скотину и запускаешь свою апликуху в другом контейнере. Все конфиги уже наготове, спин ап занимает секунды. Клиент даже не заметит потери бойца.
@inexcode @shuro @Kill2BlooD @ky39i

@shuro А я забил на это всё большой и толстый. У меня вся инфраструктура построена на настоящих KVM-виртуалках, даже контейнеры не люблю.
Вот крутится их сейчас на двух домашних серваках 13 штук. Идеально бэкапятся целиком, у каждой полноценная ОС внутри, делай что хочешь!

@drq @ky39i

@drq @ky39i
> хуяк контейнер (со своей опреационкой

Там нет своей операционки. Скорее набор библиотек. Ядро всё ещё твоё.

> влезть к ним внутрь можно - но бессмысленно

Да, потому, что это нужно только для дебага.

> данные хранятся в каких-то непонятных местах

Да в общем-то нет. В простых случаях это практически те же bind mount, только с хоста в контейнер. Хотя есть более сложные случаи с кластерами, но это уже не про докер, а про кластеры.

> я не могу просто *не думать*, что там внутри, и как это все починить, если сломается

Так тебе ничто и не мешает об этом думать и чинить. Просто ты чинишь код, который описывает контейнер.

> это дикость на уровне "переустановить Windows"

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

@drq @ky39i видимо поэтому мы до сих пор не можем осилить IPv6.

@savely IPv6 он просто тупо неэргономичный.
@ky39i

@drq @ky39i не знаю, на мой взгляд он решает гору проблем IPv4 с которыми мы возимся постоянно.

Привет NAT, его пробивы, протоколы установления сессий, всякие там ICE и прочее говно.

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

@savely Ты не понял. Он, может, и решает проблемы с NAT'ом, пробивами, сессиями и ICE. Но это все становится не важно, когда вместо человекозапоминаемого (немногим длиннее номера телефона) адреса у тебя sfdg:ssdd::dfsd::fgsf. И таких сотни. И зачем-то вместо точек оно разделяется двоеточиями, которые вообще говоря всегда обозначали порт. И поэтому чтобы обозначить порт, надо брать все это в квадратные скобки.

Винту Серфу похоже плохая кислота досталась, когда он придумывал всю залуень.

@ky39i

@drq поэтому обычно выдают /64, где ты можешь спокойно порезать вторую половину. Вот у меня в логах запросов к серверу половина таких: 2607:f598:f001::19

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

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

@ky39i

@drq @ky39i @savely Тут дело в том, что IPv4 ведь пока работает.

Поэтому нежелание использовать менее удобный инструмент без реальной необходимости вполне ожидаемо.

Начнут провайдеры массово переходить на v6 - ситуация будет меняться.

@shuro @drq @ky39i IPv4 уже не работает в эпоху реалтайм приложений.

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

(Привет Телеграм, который отсасывает по стабильности у любого крупного мессенджера, потому что у него нет денег на инфру для инвалидов за NAT).

@drq @ky39i @savely УМВР :)

Пока что IPv6 нужен для клиентского p2p, т.е. на 99% это всякие там войсы и видеочаты.

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

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

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

@shuro @drq @ky39i @savely
Кста. Почему безопасники не любят v6? Только потому-что он течет через v4? Или есть другие угрозы?

@drq @Vincent @ky39i @savely Не знаю, но подозреваю, что многим не нравится как раз пересмотр подхода к построению сетей. В v4 с этим как-то логичнее - есть центральный шлюз, есть NAT, нарезаны подсети по вланам...
@shuro одним не нравится необходимость выставления в мир разных органов оголённых (то бишь принципиальное отношение к NAT-у во имя благих намерений), другим не нравится сложность обслуживания, третьим - сложность контроля, четвёртых и сейчас всё устраивает, ибо работает, пятым просто плевать. Ничего нового; нужное время настанет, и все дружно и почти мгновенно перейдём.

Кстати, в v6 тоже "есть центральный шлюз, есть NAT, нарезаны подсети по вланам". Для дальнейшего изучения данного вопроса могу порекоммендовать начать с модели OSI.

@Vincent @drq @ky39i @savely
@drq @Vincent @ky39i @pret @savely Насчёт "мгновенно" я сомневаюсь. Куда и зачем спешить?

Ещё, кстати, осталась куча техники и софта, которые не могут в IPv6.
@shuro там специально было добавлено слово "почти", ну а ключевое слово в моём том предложении всё же "нужное".
@Vincent @drq @ky39i @savely
@drq @Vincent @ky39i @pret @savely Если под "нужным временем" подразумевается снятие с поддержки основной массы старых решений, то да, согласен. Многие из оставшихся на тот момент перейдут быстро :)
@shuro под "нужным временем" подразумевалось именно что "нужное время" — когда оно настанет, мы всё сразу и узнаем, и о причинах, и о целях, и о средствах, и даже подробнейшие инструкции получим, как решать проблемы всяческие, о которых мы сейчас можем только пространно рассуждать.

Собака лает, караван идёт.

@Vincent @drq @ky39i @savely

@shuro Ехал NAT через NAT…

«Работает» это сильно сказано :blobcatgiggle:

@savely О, а эти прекрасные, удивительное правила сокращения. Теперь вместо одного набора правил, по которым составляются адреса, в голове нужно держать три!

@ky39i

@drq @ky39i ну не смеши. Опустить нули, ведь это так сложно. По-моему подобным правилам учат в начальной школе :)

@drq @savely @ky39i есть вариант записи в десятичной нотации. Лучше бы не было.

@savant
128.91.45.157.220.40.0.0.0.0.252.87.212.200.31.255

🤡

@drq @ky39i

@savely @drq @ky39i ага, эту нотацию почему-то используют в lte модулях. Безудержное веселье иногда.

@drq @savely @ky39i

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

Жалко, что провайдер не предоставляет IPv6 напрямую, приходится использовать туннель.

@drq Ничего, потом всё это навернётся и без динозавров будет уже никак! :blobcatderpy:

Sign in to participate in the conversation
Mastodon.ml

Русская нода социальной сети "Мастодонт", части Fediverse - всемирной федерации социальных сетей. Зона общения, свободная от рекламы и шпионажа, теперь и в России.