Да ладно, Jail вполне соотносится идеологически с контейнерами.
Из цитаты:
позволяет ограничивать доступ к сети, общей памяти, переменным ядра sysctl и ограничивать видимость процессов вне jail.
И в этом (на мой взгляд) изначальное различие: в контейнерах по умолчанию «всё запрещено что не разрешено». Разрешили контейнеру доступ в сеть — есть сеть, нет — значит идёт лесом. Сложно (сложнее) сломать хост-систему если софт понятия не имеет что есть какая-то хост-система.
Точно не следующей — слишком мало у меня материала.
Как вы сами пишите — надо просто взять кусочки того что есть и не обрезать:
Практически каждый из пунктов имеет под собой довольно обширную историю (я намеренно сильно сокращал всё) и тянет на отдельную полноценную статью.
К сожалению, моя речь касалась совершенно не наших компаний :-)
Тогда почему «К сожалению»? :) На самом деле под «нашими» я подразумевал «компании в которых мы работаем». Я работал много где (и много кем) но «война… война никогда не меняется». Везде есть «эффективные менеджеры», которыми самими надо управлять для достижения результатов…
Я предпочитаю использовать виртуальные машины хоть в каких то проявлениях. Но даже это не всегда спасает.
Например, jail, это те же самые контейнера, на самом деле. У меня в jail стоит virtualbox.
Я подумал что у меня подводит память (jail и freebsd в частности пользовался последний раз лет 5 назад), но оказалось что нет:
В основу FreeBSD Jail вошёл системный вызов chroot(2), при котором для текущего процесса и всех его потомков, корневой каталог переносится в определённое место на файловой системе
К контейнеризации это относится слабо, вы просто говорите процессу что «вот эта папка — корень системы и выше ничего нет», то есть вы засунули виртуалку в папку и сказали ей «сиди тут». В контейнере же у вас полноценная ОСь, окукленная в оперативке, по сути. Если не накосячить с подключением чего-либо с хост-машины (например — монтирование папок в контейнер) то очень сложно вообще что-либо сломать. Но если прям происходит какая-то жесть — в дело вступает система оркестрации, например kubernetes, которая быстро, решительно объясняет контейнеру или даже целому поду что они не правы. Такой сетап используется гуглом уже лет 15, я думаю они могли бы в своё время просто заюзать jail и не париться, но похоже что это не одно и то же…
Мало сделать решение — его надо ещё поддерживать. Своевременно обновлять и так далее
Окей, мы можем проблему вынести в другую плоскость — «любое решение требует поддержки»
Если не поддерживать — совершенно всё равно какие технологии и в каком кол-ве применять. Рано или поздно всё нужно обновлять и переделывать.
А я бы кстати не против был бы что-то обсудить в этой плоскости, может быть — это не плохая тема для вашей следующей статьи? :) Буду ждать, удачи!
Ну на самом деле всё объясняется просто. Дла того чтоб разобраться с какой-то технологией — надо посидеть, подумать, почитать документацию, поэксперементировать… При условии того что мы знаем как в наших компаниях происходит работа (давай, быстрей, нужен релиз, сейчас!!!11) — ничего удивительного что не получается внедрить толком что-то новое. Я этим всем спокойно занимался в перерывах между работами в компаниях, изучил, попробовал, применил на своих проектах, набил шишек и написал пару скриптов. Так же стоит отметить проблему с документацией что у докера что у кубурнетес, нужно реально захотеть в этом разобраться чтоб чего-то добиться, ну и навык гугления должен быть минимум 4 уровня :). Вспомнить хотя бы этот новомодный миникуб, которым заменили кубернетес разворачиваемый в докере, который разворачивает кубернетес в виртуалке и куда не подключить hostPath без танцев с бубном, но в документации уже всё выпилили.
Сейчас пришёл в новую компанию, увидел что они всё ещё деплоят прям на железо (причём у разработчика стоял nginx, а на проде apache) и ужаснулся. Достал свои скрипты, допилил под нужды командной разработки и обучил разработчиков. У меня конечно не «полста человек», а всего лишь 4 разработчика, но судя по тому с какой лёгкостью мы подключаем новых людей — не должно быть проблем с расширением, просто будем постепенно допиливать решение (скрипты).
Минусы и неудобство перекрываютс плюсами с головой, по крайней мере с точки зрения людей которые работают с конечным сетапом. Разработка вернулась на локальный комп и при этом — окружение идентичное тесту/проду, этож просто чудо какое-то…
Интересно, спасибо. Надо будет почитать внимательно (а не после рабочего дня), но в любом случае — пишите ещё!
P.S.: С докером может быть помочь чем? Пользуюсь год, разворачиваю на kubernetes на локалке (для разработки) и в GCE. Всего полтора велосипеда написал под это дело…
Drop fxp composer plugin. Describe how to use bower (or phpbower), npm in official docs.
А можно в меня кинуть информацией на эту тему? Что-то не гуглится вопрос. Хочу избавиться от fxp/composer-asset-plugin (так как его похоже и не собираются интегрировать с composer), но не понимаю как приделать на замену bower и npm, чтоб у меня зависимости не поломались.
Вы просто влезли в середину разговора, не разобравшись о чём вообще речь. Лично у меня кластер kubernetes, о чём написано в посте, так что да, я в курсе что за консоль и что меня касается. Я пользуюсь платными услугами GCE, так что…
Не совсем понял комментарий. Я пишу о том что аккаунт гугл-плея и аккаунт почты привязывается к аккаунту гугла. Если с аккаунтом почты что-то случится — ничего не случится со всеми остальными. По крайней мере мне так кажется…
Всё содержимое письма, за исключением подписей и синей кнопки «службу поддержки Google Cloud» (цитата) выложено в посте. Пришло от «CloudPlatform-noreply@google.com», на мой адрес gmail так что не думаю что это какой-то скам, который gmail не смог опознать. Вам возможно не пришло потому что вы итак ИП, для вас ничего не меняется. Я вот как частно лицо зарегистрирован.
Покупки, насколько я понимаю, привязываются к аккаунту самого магазина, то есть к пользователю гугла, а не к почте (которая в свою очередь сама привязана к пользователю, как и другие сервисы гугла). В любом случае, не думаю что будут какие-то проблемы с этим.
Насколько я понимаю вы говорите про «APP ENGINE», который является частью Google Cloud Platform https://cloud.google.com/products/ Предложите свой заголовок.
Про докер я тоже хочу! :)
Так я же и не против, просто предположил что некоторых проблем можно было бы избежать используя, например, докер.
И это — самое главное.
Из цитаты:
И в этом (на мой взгляд) изначальное различие: в контейнерах по умолчанию «всё запрещено что не разрешено». Разрешили контейнеру доступ в сеть — есть сеть, нет — значит идёт лесом. Сложно (сложнее) сломать хост-систему если софт понятия не имеет что есть какая-то хост-система.
Как вы сами пишите — надо просто взять кусочки того что есть и не обрезать:
Тогда почему «К сожалению»? :) На самом деле под «нашими» я подразумевал «компании в которых мы работаем». Я работал много где (и много кем) но «война… война никогда не меняется». Везде есть «эффективные менеджеры», которыми самими надо управлять для достижения результатов…
Я подумал что у меня подводит память (jail и freebsd в частности пользовался последний раз лет 5 назад), но оказалось что нет:
К контейнеризации это относится слабо, вы просто говорите процессу что «вот эта папка — корень системы и выше ничего нет», то есть вы засунули виртуалку в папку и сказали ей «сиди тут». В контейнере же у вас полноценная ОСь, окукленная в оперативке, по сути. Если не накосячить с подключением чего-либо с хост-машины (например — монтирование папок в контейнер) то очень сложно вообще что-либо сломать. Но если прям происходит какая-то жесть — в дело вступает система оркестрации, например kubernetes, которая быстро, решительно объясняет контейнеру или даже целому поду что они не правы. Такой сетап используется гуглом уже лет 15, я думаю они могли бы в своё время просто заюзать jail и не париться, но похоже что это не одно и то же…
Если не поддерживать — совершенно всё равно какие технологии и в каком кол-ве применять. Рано или поздно всё нужно обновлять и переделывать.
А я бы кстати не против был бы что-то обсудить в этой плоскости, может быть — это не плохая тема для вашей следующей статьи? :) Буду ждать, удачи!
Сейчас пришёл в новую компанию, увидел что они всё ещё деплоят прям на железо (причём у разработчика стоял nginx, а на проде apache) и ужаснулся. Достал свои скрипты, допилил под нужды командной разработки и обучил разработчиков. У меня конечно не «полста человек», а всего лишь 4 разработчика, но судя по тому с какой лёгкостью мы подключаем новых людей — не должно быть проблем с расширением, просто будем постепенно допиливать решение (скрипты).
Минусы и неудобство перекрываютс плюсами с головой, по крайней мере с точки зрения людей которые работают с конечным сетапом. Разработка вернулась на локальный комп и при этом — окружение идентичное тесту/проду, этож просто чудо какое-то…
P.S.: С докером может быть помочь чем? Пользуюсь год, разворачиваю на kubernetes на локалке (для разработки) и в GCE. Всего полтора велосипеда написал под это дело…
А можно в меня кинуть информацией на эту тему? Что-то не гуглится вопрос. Хочу избавиться от fxp/composer-asset-plugin (так как его похоже и не собираются интегрировать с composer), но не понимаю как приделать на замену bower и npm, чтоб у меня зависимости не поломались.
Давайте уже прекратим бессмысленные споры.
Таким образом — всё равно часть Google Cloud.