The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в Docker, связанная с предоставление доступа к /p..., opennews (??), 20-Авг-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


70. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +2 +/
Сообщение от пох (?), 20-Авг-18, 20:21 
1. а можно вместо этого один раз выпороть пять разработчиков, чтобы они не требовали ненужной херни?
2. в редчайших случаях (когда переходный период, когда мержатся разные проекты и не хватает мощностей) - мы, не поверите, держали две версии и glibc, и пихона, и пехепе. И оно у нас работало без всяких докеров. Вы не умеете? Значит вы безграмотны и криворуки, см пункт 1.
Работало бы и по пять, но см пункт 1. Зоопарк версий в продакшн - ненужно. Ни в контейнере, ни без него. В том числе и потому, что генитальный разработчик не собирается отвечать за баги и нестабильность в не своем коде.

И нет, ни один разработчик не уволился потому, что "у вас надо программировать на php5.6, а я хочу 7.2"

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

Часть этих проблем кое-как затыкают ненужные "системы оркестрации", притаскивая взамен еще миллион своих собственных.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

74. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от Gemorroj (ok), 20-Авг-18, 21:03 
если я правильно понял, то разрабам из-за жопорукости админа приходиться кодить на пхп5.6 без возможности обновиться до 7.2 (ненужная херня, на сколько я понял)?
это тогда причина не разрабам увольняться, а уволить админа.
Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  –1 +/
Сообщение от DevOps (?), 20-Авг-18, 23:57 
Уволить задним числом заранее кинув на последнюю зарплату и без возможности восстановления.
Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от пох (?), 21-Авг-18, 20:39 
разрабам предлагается объяснить, письменно, какие бенефиты компании принесет переход на другую версию. С графиком разработки в руках - "вот тут мы копались столько, а с новой прекрасной версией все это заняло бы столько, правда вот там и вон там у нас <? и в ем код который еще php4 помнит, его пришлось бы переписать вот за столько". Админам это неинтересно и они в этом даже и участвовать не будут (мы же помним, что у нас - админы, и они поставят новую версию, ничего не сломав в системе, а не будут городить докер на докере в докере, потому что вместе с новым пехепе приехала новая версия дистрибутива, а в ней нет старого пихона, на котором, ой, внезапно, ключевой кусок написан, да еще с какими-то бинарными so от которых уже никто не помнит где правильная версия исходника - все равно его планировалось переделать сто лет назад)

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

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

Докер используется по назначению - как средство деплоймента фиксированных окружений, слишком замороченных, чтобы обойтись скриптами для пакетного менеджера. В этом качестве даже и можно пользоваться - хотя временами кажется, что во времена bsd'шных jail'ов с unionfs проблем было поменьше в разы.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

79. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +3 +/
Сообщение от ALex_hha (ok), 21-Авг-18, 00:07 
Если у вас на локалхосте используется одна версия, то это ещё не значит, что и в реальном мире будет так же. А в реальном мире есть понятие легаси. И никто вам не выделит пару лет, чтобы перевести бекэнд с руби 1.8 на 1.9. Вот так и живем.

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

Покажите мне пример запуска 3х версий php как модуля апача, а то я может что то пропустил

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

80. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от DevOps (?), 21-Авг-18, 00:11 
lsPHP умеет вроде.
Ответить | Правка | Наверх | Cообщить модератору

86. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от пох (?), 21-Авг-18, 07:44 
выделили. Переводят. Именно со словами "поддерживать старый хлам - слишком дорого для нашей компании".
Причем в "реальном мире" нет никакой задачи сочетать бэкэнд на старой версии с куском кода на новой - не то что в рамках одного хоста, а часто даже в рамках одного кластера - мощностей всегда не хватает, это у локалхостера они в избытке.

> Та можно и 10 версий держать, вопрос лишь удобства и докер справляется с этой задачей на отлично.

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

> Покажите мне пример запуска 3х версий php как модуля апача, а то я может что то пропустил

"production", "реальный мир"... php как модуль апача. Опаньки. Знаете, вы еще очень многое пропустили, нет смысла на вас время тратить.

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

90. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от ALex_hha (ok), 21-Авг-18, 11:00 
> слишком дорого для нашей компании".

оно и понятно, в "рога и копыта" на локалхосте такого и не нужно. Дальше можно не продолжать

Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от пох (?), 21-Авг-18, 20:07 
модули апача - это именно уровень ваших рогов и копыт. fpm ниасилен, понятен.

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  –4 +/
Сообщение от ALex_hha (ok), 21-Авг-18, 11:02 
> а ответственность за стабильность, безопасность и контролируемость - переложена на никого?(с)

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

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

114. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от пох (?), 21-Авг-18, 20:21 
> в нормальных фирмах она переложена на devops

это и есть никто. Админы-недоучки, для которых, о ужас, две версии пехепе на одном хосте - неразрешимая проблема, apt-get install так не могёт. Зато они знают докер, къебенетес и много других страшных слов и, самые продвинутые, умеют писать скрипт для ansible.

что отслеживают проблемы безопасности в давно протухших "пяти версиях libc" и способны пересобрать пакет вручную, сбэкпортив патчи - это вряд ли, те кто на это способны, обычно как раз понимают, что это и бесполезно, и времени не хватит на полезную деятельность. Ждут ебилдов, а если че - "это не мы, это вот пакет гнилой, или в докере s stands for security"...

Ответить | Правка | Наверх | Cообщить модератору

124. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от ALex_hha (ok), 21-Авг-18, 23:53 
Э как бомбануло у админа :D
Ответить | Правка | Наверх | Cообщить модератору

123. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 21-Авг-18, 23:38 
>> ответственность
> devops

И в чём же она выражается?

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

129. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от ALex_hha (ok), 22-Авг-18, 09:02 
> И в чём же она выражается?

да во всем том же, в чем и у обычных сисадминов. В отслеживании уязвимостей и устранении их. А вот каким способом, это уже вопрос другой. Если обычный сисадмин, условно, сделает yum update и /или наложит патч и соберет новый rpm, то девопс по сути сделает тоже самое, просто запустит соотв джобу в CI/CD, которая сделает тоже самое, только внутри докера ;)

Очень давно был проект на php 4, который просто работал и все, естественно перевести на 5ку его не реально, там по сути заново надо было бы все переписать, так и работал в докере и отлично себя чувствовал.

А совсем недавно был у меня проект на ruby 1.8, который был в докере, ибо там такое легаси, что туда лучше не смотреть. Но как тут рассказывают некоторые сказочники локалхостов, что всех разработчиков таких систем надо уволить и переписать на современные версии, в том случае это было не реально, от слова совсем. При этом это был один из крупнейших сервисов америки по продажам gift карточек, а там крутится много много денег. И все отлично работало и работает, насколько я знаю, проблем с безопасностью не было.

Так что реальный мир он такой и немного отличается от розовых фантазий :)

Ответить | Правка | Наверх | Cообщить модератору

131. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от anonymous (??), 22-Авг-18, 12:01 
> да во всем том же, в чем и у обычных сисадминов. В отслеживании уязвимостей и устранении их.

За исключением того что у них (девопсов этих ваших) как правило нет для этого ни знаний, ни умений.

Ответить | Правка | Наверх | Cообщить модератору

133. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от Alex_hha (?), 22-Авг-18, 13:52 
> За исключением того что у них (девопсов этих ваших) как правило нет
> для этого ни знаний, ни умений.

с какого перепуга? Я вот проработал 10 лет сисадмином, последние 3 года работаю девопс. Никаких проблем не испытываю. Возвращаться к скучной работе сисдамина нет никакого желания :)

P.S.
вы ведь понимаете, что devops это лишь методология разработки и доставки продукта, а не какая то новая чудо специальность? Но тут стоит учитывать, что многие админы локалхостов, которые хоть раз в жизни запускали docker и установили nginx через ansible на две виртуалки, гордо бьют себя в грудь и кричат, что они devops инженеры. А потом ты начинаешь их собеседовать, а там полный мрак.

Ответить | Правка | Наверх | Cообщить модератору

134. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +1 +/
Сообщение от angra (ok), 22-Авг-18, 23:45 
> Я вот проработал 10 лет сисадмином, последние 3 года работаю девопс.

И за всё это время не сталкивался с chroot, jail, vserver, openvz, lxc, а также kvm и xen? Только с появлением docker смог решить задачу запуска в изолированном окружении?

Ответить | Правка | Наверх | Cообщить модератору

136. "Уязвимость в Docker, связанная с предоставление доступа к /p..."  +/
Сообщение от ALex_hha (ok), 23-Авг-18, 12:22 
> И за всё это время не сталкивался с chroot, jail, vserver, openvz, lxc, а также kvm и xen?

Конечно сталкивался, просто в докере это на порядок удобнее. Я вот посмотрел бы, сколько у вас ушло времени на поднятие elk стека в chroot/jail/openvz. А в докере это одна команда и минута времени. И таких примеров очень много. При этом я не утверждаю, что docker это панацея и всем срочно надо на него переходить. Но во многих моментах разработки - он очень здорово облегчает жизнь.

Так и представляю ситуацию - выходит к вам новый qa/developer/devops, ему надо поднять у себя на машине тестовое окружения, чтобы понять что и как, или что то проверить. А вы ему такие - ставь себе  openvz/kvm/xen, потом ставь и настраивай 100500 программ, в лучшем случае будет bash скрипт для сборки всего этого добра. Ведь тут некоторые кричали, что ansible это новомодная хипстерская подделка девопсов и не нужна от слова совсем, так что только хардкор, только bash скрипты.

В моем случае, я даю человеку docker-compose файл и через 5-15 минут у него уже готовое окружение. И у нас не бывает случаев - "а у меня на машине все работает" :D Единственный случай, когда в докере реально могут быть различия, это когда ваш софт сильно завязан на версию ядра, тогда могут быть проблемы.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру