LINUX.ORG.RU

Переоценен ли K8S/Docker с некоммерческой точки зрения?

 , , , ,


3

3

Привет всем,

Работаю с Docker/K8S еще с 2018 года. Примерно с того времени, все проекты как правило вертятся в рамках Kubernetes. Неважно как:

  • в виде managed-сервисов в облоках (GKE, AWS EKS)
  • в виде unmanaged на приватных bare-metal (через kubeadm)

Да, удобно. И прошу не закидывать данный сабж общими словами на тему:

  • Докер, это новый стандарт и удобный инструмент для сборки образов
  • что К8С удобен для быстрого поднятия сред и оркестрации приложений
  • что можно лимиты ставить, и решать проблемы зависимостей системных либ

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

Речь немного у другом. Я прочел недавно пост: https://lwn.net/Articles/676831/

И некоторые слова зацепили, как:

According to Walsh’s presentation, the root cause of the conflict is that the Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux. These include initialization, service activation, security, and logging. «In a lot of ways Docker wants to be systemd,» he claimed. "It dreams of being systemd."

Сейчас, я выражу непопулярную точкую зрения :) и возможно, даже «мамонтовскую» :) но лезут такие мысли в голову:

  1. Докер действительно вызывает малость ощущения systemd-wanna be в опреденном аспекте, касаемо управления приложений (не берем аспект формирования образов)
  2. Формировать лимиты по RAM, CPU и др., вполне можно через тот же systemd
  3. Для проблемы эмуляции файловой ОС, совсем необяз. залезать в Docker, есть systemd nspawn и возможность дергать Linux namespaces напрямую
  4. честно говоря совсем банальная мысль :) а чем вам сама ОС не является крутым оркестратором для приложений?

Что мне лично еще не нравится при работе с Докером и К8С:

  1. Есть ощущения излишних слоев абстракций и user mode виртуализаций. С учетом того, что большинство приложений сидит на Java, Python, NodeJS … Спрашивается, а такая ли в этом необходимость? Куда ни шло, если речь про C++ проекты, где возня с headers/линковой либ и др., где действительно есть «головная боль» в ряде моментов… Но, на Жабке или Питоне-то? Сомнительно…

  2. Учет GAPов, если вы админите условный OpenStack с виртуалками и чудо-менеджер туда еще сует Докер, то создаются впечатления, что я занимаюсь больше обслуживанием абстракций, нежели реально проектом и реальной необходимости бизнесу

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

  4. Народ, как будто бы, разучился работать со stateful-сервисами и понимать проблематику больших баз и пр. Появилось много хомячков, кто трындит про A/B, удобное перекидывание контейнеров между нодами, но очень забавно было наблюдать :) как условные хомячки пытаются юзать Postgres в рамках контейнеров, а под капотом юзать Ceph (да еще в добавок на вирт. машинах), а потом удивляться, что кластер РСУБД не может быстро работать :) Уйму слоев виртуализаций построили, хранилища - дистрибутивные, проблему синхронизаций stateful-сервисов не решают, IOPS падает :) но зато «в облачке и поды по нодам». Понятно, что в облаках накинули 1000 баксов, и проблемы производительности могут улетучатся, ну или вообще увести базы в отдельные managed-сервисы. Но, очень забавляют картины, когда пытаются решать вопросы high load на приватных серверах через призму огромного слоя виртуализаций.

P.S. повторюсь, что сказал в начале. Спасибо Докеру и К8С за работу/деньги. Но, персонально есть ощущения какой-то лабуды. Как по мне, вполне себе можно было бы даже в условном systemd вращать многие приложения без огромной прослойки виртуализаций. Иногда кажется, что лучше быть не хайповым и вне моды.



Последнее исправление: twinpeaks (всего исправлений: 1)

Интересный вопрос. А есть и другой интересный вопрос: Переоценен ли systemd с некоммерческой точки зрения?

ugoday ★★★★★
()

Пункт 3. Я, как жабобыдло, ищу работу в других сферах какраз из-за этого. Уж лучше с++ чем это.

Кстати, рассмотрю предложения, если кому нужен.

anonymous
()

Переоценен ли K8S/Docker

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

Почему «понимание» в кавычках, а потому что это некая самоуспокоенность и иллюзия, которая на самом деле просто добавляет комфорта, не больше.

Это как соскочить с винды на линукс, потому что он «более логичен и более понимаем by design». Что точно так же даёт иллюзию контроля над системой.

Поэтому, нет не переоценён. Называйте это комфорт или «бег по кругу» или снятие отвественности за принятие решения, оно того стоит. Популярность, я имею в виду.

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

Как-будто бы это умение когда-либо было базовым. Нет, всё как всегда, ничего не меняется.

vvn_black ★★★★★
()

ты начал что-то подозревать

Harald ★★★★★
()
Ответ на: комментарий от vvn_black

vvn_black ★★★★★ (05.09.21 22:43:07) Как-будто бы это умение когда-либо было базовым. Нет, всё как всегда, ничего не меняется.

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

  • SQL
  • мьютексов/семафоров
  • понимания того, как юзать реплики

Не говоря про то, что обслуживание реплик - это не рабочая обязанность программистов, а скорее к Sysadmin/DBA. К чему это я?

Да, по-моему, ранее было базовым. Ранее, народ как-то учитывал:

  • скорость догонки реплик
  • как быстро чинить реплики на больших базах
  • если базы большие под несколько терабайт, думали о методах real-time репликации и как добиться всего этого наиболее оптимальным методом

Что сейчас вижу? Программисты не знают основ SQL, могут даже банальный INNER JOIN не построить. Новое поколение админов думает сугубо через призму Докера, и может порой обосраться с подготовкой systemd шаблона.

Вот, был один персонаж у меня на фирме. Деплоил PgSQL через Patroni. Было у него задание - сделать синхронную-потоковую реплику вручную без Докеров и К8С, оказалось что он совсем не умеет анализировать проблемы Postgres, и не очень понимает даже разницы между логической и физической репликой. И это ужасает… Зато, docker run/docker stop, облока, деплой через готовые Ansible playbooks/Terraform…

twinpeaks
() автор топика

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

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

В кой-то веки соглашусь. Без изоляции, с костылями, исключительно от отчаяния от импотентности ПМ. Но не делать же по уму, право слово.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от Legioner

Legioner ★★★★★ (05.09.21 23:00:02) Людям понравилось крутить образы, которые по сто лет не обновляются, и делать вид, что все хорошо.

Более интересно, почему таким людям не нравится юзать обычные виртуальные машины :)

Я-то знаю про разницу контейнеров и ВМ, но подчеркну именно «таких людей». Ибо понимаю, про что Вы говорите. Зачастую «такие люди», под капот не лезут и могут юзать Докер так, чтобы лучше бы они юзали виртуалки :)

Помню, когда я работал в Luxoft в 2018ом, там были умники, которые таскали внутрь Докер-образов embedded базы по 10 Гб. Даже, не додумались через volume отдельный подрубать, влепали прямо в образ. Но зато, они были в первых рядах, кто кукарекал про Докер и облака :)

twinpeaks
() автор топика

Когда проекты состоят из множества составляющих, нагрузка непредсказуемо растет, программисты работают как заменяемые юниты — кластерные системы как K8s просто незаменимы.

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

Про базы/хайлоад не совсем в тему. Оно друг другу никак не мешает, запускайте stateful вне кластеров/докера если это проще. Все по потребности

MaZy ★★★★★
()
Ответ на: комментарий от twinpeaks

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

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

…обосраться с подготовкой systemd шаблона

Ну не всем он нужен, может он привык к другой системе инициализации ?

Samamy ★★★
()
Ответ на: комментарий от MaZy

Про базы/хайлоад не совсем в тему. Оно друг другу никак не мешает, запускайте stateful вне кластеров/докера если это проще. Все по потребности

Сугубо Ваше мнение :) Я считаю в тему, ибо вижу реальность. Очень многие пытаются юзать Helm-чарты в К8С и верят в сказку, что можно все вертеть в К8С, в real-time и все будет тип-топ.

Уже видел, чем заканчиваются эти картины, какими фейлами и тормозами оканчиваются попытки крутить условный Postgres в рамках К8С.

Более того, если Вы внимательнее прочтете меня, я и сам в 1-ом сообщении сказал про отдельные managed-сервисы для РСУБД, в самом конце.

Соль того, и почему в тему - потому что, с Докером/К8С образовалась «розовая мечта» у многих. Вертеть все подряд в контейнерах, запихнуть всё обслуживание в контексте оркестрации приложений (не важно каких stateless или statful) под К8С.

И желательно для подобных фанатов - заюзать дистрибутивный storage-кластер в виде Ceph или GlusterFS/Heketi ради dynamic prov. PV/PVC, куда и пытаются засунуть хранение многих stateful-сервисов.

И почему «в тему?» Потому что, строив кластера Postres или Elasticsearch в стиле:

  1. в виртуалке
  2. а в этой виртуалке докер
  3. а в этом докере - управление postgres
  4. а под капотом ceph, где данные postgres распределены по pg/osd

Желать realtime обслуживания и отсуствия проблем - может только наркоман и человек, который верит в эльфов. И именно из-за этого хайпа вокруго Докеров-helm charts-K8S происходит потеря причинно-следственной связи у многих людей.

И посему, повторюсь желать real-time обслуживание по патеррну из 4-ых пунктов выше, может реальный нарик только. PS: да, персональное мнение.

twinpeaks
() автор топика

Есть ощущения излишних слоев абстракций и user mode виртуализаций.

And we need to go deeper.

devl547 ★★★★★
()

Docker daemon is designed to take over a lot of the functions that systemd also performs for Linux

Одно для системных сервисов, другое для абстрактной прикладухи, всё в порядке.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

WitcherGeralt ★★ (06.09.21 00:20:47)

Одно для системных сервисов, другое для абстрактной прикладухи, всё в порядке.

Что есть системный сервис в Вашем понимании?

  • dbus.service
  • polkit.service
  • NetworkManager.service ?

Если они, то ок. Можно отнести к категории «системный сервис». А, PostgresSQL куда отнесете? Если к «прикладным», то поясните пожалуйста, какие мне дает преимущества вращения Постгреса в Докере, нежели чем в обычном systemd. Спасибо.

twinpeaks
() автор топика

Докер действительно вызывает малость ощущения systemd-wanna be в опреденном аспекте, касаемо управления приложений (не берем аспект формирования образов)

Это меня очень пугает в Docker и ужасает в Kubernetes (по сути кубику лучше запускаться в специализированной системе, чтобы ему никто не мешал).

Чуть более здоровой альтернативой является Podman, способный генерировать systemd-юниты с зависимостями для управления контейнерами.

commagray ★★★★★
()

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

Harald ★★★★★
()

Хороший наброс, годный!

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

Потому как среднестатистической конторе найти одмина, который осиливал был сам, все труднее с каждым годом.

Не?

anonymous
()
Ответ на: комментарий от Harald

В дистрибутивах Линукса слишком много трудноуправляемого глобального состояния. Контейнеры же не зависят от состояния ОС (установленные пакеты, конфиги и т.п.).

X512 ★★★★★
()
Ответ на: комментарий от twinpeaks

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

Уже высказывался по данному вопросу: Прозрение Штульмана (комментарий)

WitcherGeralt ★★
()
Ответ на: комментарий от X512

X512 ★★ (06.09.21 00:49:24) Контейнеры же не зависят от состояния ОС (установленные пакеты, конфиги и т.п.).

С учетом того, что контейнеры - single shared kernel, то таки зависят :) Хотя, что Вы под «зависят» понимаете. То, что Вы в скобках перечислили - вполне себе и без Докер-контейнеров можно добиться в OS.

X512 ★★ (06.09.21 00:49:24) В дистрибутивах Линукса слишком много трудноуправляемого глобального состояния

Это, к примеру про какое «глолбальное состояние» речь идет? Скажите, пожалуйста.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

Это, к примеру про какое «глолбальное состояние» речь идет?

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

X512 ★★★★★
()
Ответ на: комментарий от WitcherGeralt

WitcherGeralt ★★ (06.09.21 00:51:41) Есть cloud-native хранилища, их нужно пускать в докере

А если не cloud-native хранилища, то не нужно? :D Не очень понял, кстати что есть cloud native. Ceph к примеру используются и в публичных облаках, а может и на приватном хозяйстве.

Потом, Вы таки не ответили явно на вопрос, а какие преимущества дает Докер против systemd для управления PostgreSQL?

И, давайте не брать тематику облаков, ибо там все в managed-сервисах, там смысла разбирать - нет. Там, Вы отдали на откуп в условный CloudSQL, где попу подтирает Ops-команда GCP.

Сейчас, с облаками и так понятно все. Там-то из-за размеров Ops-команды, количества вычислительных возможностей они могут позволить себе «виртуализацию в виртуализации», да и с их размерами дата-центров такие решения - оправданы. Но, это только касается тех, кто поддерживает данные облака (если вы часть Ops-команды AWS или GCP).

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от X512

X512 ★★ (06.09.21 01:00:27) Установленные пакеты, конфиги, разные файлы, devfs. Всё это может влиять на работоспособность программ непредсказуемым образом.

И что мешает юзать Linux namespaces напрямую для решения задач по изоляции fs? Для этого надо обязательно Докер ставить? :)

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

И что мешает юзать Linux namespaces напрямую

Есть ли готовые решения сравнимые с Docker по удобству использования?

X512 ★★★★★
()
Ответ на: комментарий от X512

Есть ли готовые решения сравнимые с Docker по удобству использования?

Podman.

Papant
()

С учетом того, что большинство приложений сидит на Java, Python, NodeJS … Спрашивается, а такая ли в этом необходимость?

Сдается мне «сам ты не сварщик». В бубунте по дефолту мтоит убогий python 3.7.3, его можно заменить, сломав систему, либо поставить pyenv и кучу зависимостей чтобы скомпилить петухона… А потом еще компилить… А тут докер контейнер с готовым бинарником и места все занимает не больше чем исходники питона + места необходимое для компиляции + готовый бинарник

tz4678 ★★
()
Ответ на: комментарий от tz4678

Сдается мне «сам ты не сварщик». В бубунте по дефолту мтоит убогий python 3.7.3, его можно заменить, сломав систему, либо поставить pyenv и кучу зависимостей чтобы скомпилить петухона… А потом еще компилить… А тут докер контейнер с готовым бинарником и места все занимает не больше чем исходники питона + места необходимое для компиляции + готовый бинарник

Сдается мне, Вы не использовали Conda. И часто Вы компилите «петухон», как Вы выразились в рабочих задачах?

twinpeaks
() автор топика
Ответ на: комментарий от tz4678

по дефолту мтоит убогий python 3.7.3, его можно заменить, сломав систему

DEB: defective by design.

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от twinpeaks

конда - это для выпускников винфака. я ею в последний раз 10 лет назад пользовался

tz4678 ★★
()
Ответ на: комментарий от twinpeaks

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

WitcherGeralt ★★
()
Ответ на: комментарий от X512

X512 ★★ (06.09.21 01:16:19) Есть ли готовые решения сравнимые с Docker по удобству использования?

В контексте чего именно?

  1. fs? можно nspawn-systemd хоть юзать:

debootstrap –arch=amd64 jessie /var/lib/machines/container1/ systemd-nspawn -D /var/lib/machines/container1/ –machine test_container

  1. в плане SDN/виртуальных сетей? ip-netns, хотя бы, но я бы призадумался не выстрелит это проблемой при обслуживании… опять не берем облака, где все за вас сделали и, где от Вас нужен только OCI-образ для какого-нибудь условного ECS… поэтому, проблематик того, как CNI могут провалиться и стать огромной задницей в обслуживании, к примеру поюзав Flanel CNI условный - Вы можете не прочувствовать

  2. в плане лимитов для CPU, RAM? У systemd полно возможностей по лимитам: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html

PS: единственное, где удобен Докер-подобное, это сборка образа. Чтобы быстро собрать что-то и поднять env для тестов. Но, тут сильно зависит от того, где Вы работаете. Если Ваша компания все делает в облаках, то да кроме правильной сборки образов - голову можно ни чем не занимать. Если же, у Вас контора где облака нельзя использовать, то тут можно много «прелестей» увидеть.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

PS: единственное, где удобен Докер-подобное, это сборка образа

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

tz4678 ★★
()
Ответ на: комментарий от WitcherGeralt

WitcherGeralt ★★ (06.09.21 01:42:38) Извини, но у тебя проблемы со чтением. Я ответил хоть и не полно, но максимально доходчиво, а более полно было по ссылке. Если ты не смог прочитать, то не вижу никакого смысла распинаться далее, ты так же вряд ли сможешь это прочитать.

Извини, но нет :) Я прочел, ты вообще ничего не привел. Проблем с чтением, у меня - нет. Извини, но это самое просто «уйти от ответа» и обкидываться ссылками.

P.S. Прочел я твое якобы «крутое» сообщение из того трэда:

А если будешь хранить данные в вольюмах, как и задумано, добавишь дополнительную точку отказа, к тому же не сможешь в репликацию на уровне ФС.

Видимо, ты не работал с разными уровнями изоляции РСУБД (Read Committed/Repeatable Read) под высокой нагрузкой и не знаешь, что разные виды реплик на уровне ФС нуждаются в ряде проверок, что данные «правильно реплицировались». Вот тут, кстати докер-фаны и просираются знатно, когда просралась потоковакая реплика и некорректно заsync’алась, и речь не про базы уровня 10-20 Гб, а про терабайтные базы, которые еще требуются быстро и четко обслуживать. Вот, тут и самый угар, когда docker/k8s fans обсираются знатно с перекидванием контейнеров между нодами. Внезапно оказывается нужно уметь реплики делать, а не дрочить на Докер )))

twinpeaks
() автор топика
Последнее исправление: twinpeaks (всего исправлений: 1)
Ответ на: комментарий от twinpeaks

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

И тут ты опять спрашиваешь:

Потом, Вы таки не ответили явно на вопрос, а какие преимущества дает Докер против systemd для управления PostgreSQL?

Феерический тупак.

WitcherGeralt ★★
()
Ответ на: комментарий от twinpeaks

Помню, когда я работал в Luxoft в 2018ом, там были умники, которые таскали внутрь Докер-образов embedded базы по 10 Гб.

Сильно.

Twissel ★★★★★
()
Ответ на: комментарий от Harald

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

Смысл контейнеров в том, что приложения говно дырявое.

untitl3d
()

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

vtVitus ★★★★★
()
Ответ на: комментарий от untitl3d

Когда кулхацкир ломает твой сервис, ты компрометируешь всю систему и остальные сервисы тоже.

Каким образом взлом сервиса работающего под выделенным сервисным пользователем, компрометирует всю систему?

vtVitus ★★★★★
()
Ответ на: комментарий от untitl3d

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

vtVitus ★★★★★
()

systemd-wanna-be

Рекомендую podman, который писался специально под systemd и таким не страдает, при этом старается быть во всем совместимым с докером.

Siborgium ★★★★★
()
Ответ на: комментарий от WitcherGeralt

WitcherGeralt ★★ (06.09.21 02:01:00) Барашек, тебе прямым текстом было сказано, что пускать постгрес вне рамок тестового окружения в докере бессмысленно.

Знаешь, я - дважды обшаюсь с фонатом докера/witcher в данном треде. В 1-ый раз - приключение, во 2-ой раз - извращение.

Феерический тупак. Классная logic :)

  • Не можешь констркутивно ответить на вопрос
  • Не отвечаешь про cloud native
  • В том треде на который ты ссылаешься, что-то вякнул про fs репликацию, но я тебе уже сообщем выше пояснил, какие траблы docker boys не вывозят

И что в итоге? :) Надо изрыгнуть какую-то фразу «феерический тупак». Давай помогу дальше, добавь еще «что это было?»

Короче… Ладно, что мне с тобой болтать. Вы Докер-фаны - страненькие в контексте обслуги stateful-сервисов. Анонировать на облака - можно, и именно там в контейнерах. Но почему так - я пояснял опять ранее, про Ops-команды в AWS/GCP и что все суют в managed-сервисы, где вам уже попу подтерли.

P.S. надобавок скажу, что я очень люблю лицезрить, где какие феерические тупаки Докер фаны устраивают на приватных площадках. Там уже не прокатывают:

  • helm install
  • docker stop/docker run

Чему я очень рад. Потому что, именно это очень знатно ставит вас, docker boys на место. Вы внеазпно узнаете, что есть туева куча вещей, где ваш говнодокер на хрен не сдался, и вообще может с своим обилием приколов стать - SPOF. Ах да… Забыл, Вы же все в облаках юзаете :) Что бывает с процессами контейнеров, когда родительский Докер процесс умирает, вы небось и не знаете :) Не говоря о кучи других приколов (с багами вокруг volume mounts, сетевой loop из-за багов CNI и пр.)

Короче, диалог не получился с тобой. Давай закончим :) По твоей версии - я дичь несу. По моей - ты.

twinpeaks
() автор топика
Ответ на: комментарий от untitl3d

untitl3d (06.09.21 10:31:14) Когда кулхацкир ломает твой сервис, ты компрометируешь всю систему и остальные сервисы тоже. Когда ломают контейнер, ты просто перезаливаешь контейнер. Всё. Остальные сервисы на той же машине не знают, что что-то ломалось.

Смысл контейнеров в том, что приложения говно дырявое.

Видимо, по этой причине у Докера rootless режим к 20ой версии появился. А еще появились проекты, типа Kata containers.

twinpeaks
() автор топика
Ответ на: комментарий от twinpeaks

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

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

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

WitcherGeralt ★★
()
Последнее исправление: WitcherGeralt (всего исправлений: 2)
Ответ на: комментарий от untitl3d

Вариант фиксить приложения и тщательнее проверять их на дырки конечно же отбрасывается как невозможный

Harald ★★★★★
()
Ответ на: комментарий от X512

А вот это вот трудноуправляемое глобальное состояние внутрь контейнера почти полностью не копируется как будто

Harald ★★★★★
()
Ответ на: комментарий от Harald

Думаешь это кому-то надо?

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

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

(ну и кто мне опять блокирует постинг по ip? какой флейм я провоцирую?)

anonymous
()
Ответ на: комментарий от tz4678

Я может чего-то не понимаю, но что сложного в компиляции Python?

У меня в конторе все приложения написаны на Python, всегда ставим Python через pyenv. Понаставить пару пакетов не проблема, они будут занимать не так много места. А сама компиляция идёт быстро.

Даже playbook подготовлен:

     - block:
       - name: "Install requimenets for install python, pyenv and application"
         yum:
           name:
             - git
             - gcc
             - zlib-devel
             - bzip2
             - bzip2-devel
             - readline-devel
             - sqlite
             - sqlite-devel
             - openssl-devel
             - tk-devel
             - libffi-devel
             - python-virtualenv
             - postgresql-devel
             - libxslt-devel
             - libxml2-devel
             - libtiff-devel
             - libjpeg-devel
             - libzip-devel
             - freetype-devel
             - lcms2-devel
             - libwebp-devel
             - tcl-devel
             - gcc-c++ 
           state: present

       - name: "Install pyenv (clone from repo)"
         git:
           repo: https://github.com/pyenv/pyenv.git
           dest: /opt/pyenv/

       - name: "Modify .bash_profile for pyenv"
         blockinfile:
           path: /root/.bash_profile
           state: present
           block: |
             export PYENV_ROOT=/opt/pyenv/
             export PATH="$PYENV_ROOT/bin:$PATH"

       - name: "Install specific Python version"
         shell: "/opt/pyenv/bin/pyenv install {{ python_version }} -s"
       environment: 
         - "{{ env_vars }}"
         - PYENV_ROOT: "/opt/pyenv/"
       become: yes
       become_user: root

По мне так всё происходит быстро.

iljuase ★★★
()
Последнее исправление: iljuase (всего исправлений: 1)
Ответ на: комментарий от iljuase

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

tz4678 ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.