1) Да это не проблема… Но трудно коллегам преподнести. На таком уровне пока больше возни с этим всем чем пользы, покрайней мере при первых попатках показалось
Спасибо за статью. Очень интересно…
Я в плотную работаюс Докером, но в основнон на старых, достаточно монилтных проектах, которые регулярно патчатся но перерефакторитьих на микросервицы или нет время или нет смысла…
Однако по 2-5 контейнеров на аппликушечку набирается…
Пока хватает Docker-Compose на одной двух машинах, но тема с CoreOS очень интересна…
Мозехте просветить с вашим опытом по паре вопросов…
1) Стоит ли заморачиватся с CoreOS если сервисов пока 2-5 на аппликуху и 2, 3 виртуальных машин хватает.
2) Есть ли у вас опыт с Kubernetes который предлагхает гугл в своем опыте, мы поигрались, конечно это для наших задачь церезчур мощнан и динамическая среда… Но на рост в полне, однако мои мене опытные коллеги испугались (Инфраструктуры боятся)…
3) Есть ли у вас опыт со стэком Rancher? Воспринимается ли это как конкуренция CoreOS?
Может у вас есть общего плана совет для проектов с таким начальным количеством контейнеров и достаточно медленным их ростом, что-бы не не сильно вкладываться в инфраструктуру (в смысле майтенненса)
ни иметь по возможности максимум контроля?
Я очень рад, но мне лично это «по барабану» — можете кофе назвать. Как правильно я знаю…
Если вам интересно, у меня немецкий контекст. Я транслитом пишу тут… И унас это буква «j» читается и произносится так как я написал. Надеюсь это никого не оскорбило…
10 лет в яве…
Считаю это плохой и весьма бесполезной штукой.
Ява всегда была легкой для новичков, начинаем вводить новый класс лупых ошобок для них и делать все немнго сложнее…
Зачем портить хороший язык…
Напишите новый под ВМ как остальные…
Я так понимаю OAuth не о том…
Представим что после успешной аутентикации мы отдаем клиенту JWT токем в котором уж есть все что нужно для последующей авторизации…
например браузерному приложению которое общается с бекэндом
при этом бэкэнд состоит из 5 микросервисев. В случае с JWT микросервицы сами смогут проверить даныные из JWT больше никуда не обращаясь в свою очередь…
Это очень очень круто.
Потому что их штуки часто не понятно с первого раза
видим поэтому они пытаются их так описать сравнив с чем-то более попнятным и сказать что «наш тул не про то а про то»
Идея в том, что аутентификация и проверка токена это не есть непосредственная задача микросервиса.
Ну это понятно, но какой-то boilerplate есть всегда темболее что в данном случае это решает какая-нибудь либа.
Утрировано проблема лишней строчки кода помоему не страшно…
Далее не всем сервисам нужда аутентикация/авторизация в принципе… но тем которым нужна нужна скорее всего достаточно псецифически (именно авторизация). Так что куда-то делегироваТь эту задачу мене кажется далеко не суперской идеей.
Кроме того конкретному микросервису как правило нужно очень мало информации о клиенте, ID в принципе для большинства задач хватит, но не хочется это все в токене хранить, не всегда это нужно пользователю знать
Это не факт есть сервисы которым вообще ничего о пользователе знать не надо а есь те которым, надо знать.
И год рождения и департамент, роль, групу и т.д. и какраз если положить все это в токен то можно отлично передавать этот токен с каждым реквестом от сервиса к сервису (общий секрет) не дергая никаких центральных сервисов авторизации…
Какраз в этом то я и вижу фишку…
И не понятно причем тут то, что видноко клиенту… Можете не показывать ему вовсе содержимое, если не нужно… просто пусть носит ссобой шифрованый токен.
Может я конечно не совсем верно понял JWT, но помеомеу о идеален именно для это-го
Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея
Немоглибы пояснить почему?
как я понимяю JWT это был-бы иделаьный варинат для микросервисов… А дополнительная валидация в nginx какрыз костыль…
Ну да… все эти риски понятны.
1) хакнуть баговый сервис смотрящий в сеть конечно возможно. Это не проблема докера в принципе и не достоинство это ортогональная проблема… И в 99% случает криворукие программеры вашей конторы…
Тоесть чинится релизом и деплоэмнеотм одного контейнера.
2) Вы только что описали приимущества дополнительной изоляци между контенерами.
Да проникнув в контейнер (да еще по вине сторонней библиотеки, не преспроисив себя зачем она там и точно нужна..) теоритически можно получить доступ ко всему что видит контейнер.
Но это все еще меньше чем сценарий проникновения в монилит, в которм злоумышленик увидит все.
Технологий контейнеров не избавит конечно от проблем и то что вы говорите валидно… Контейнеры без микросервисной архитектуры ИМХО достаточно бесполезны…
Но если её использовать, то можна даже увеличить безопасноть. Локализировать наиболле уязвимые сервисы или те что занимаются наиболее трепетными данными… И занятся в плотнуе их бзопасностью…
Что даже не зависимо ото контейнеров хороший паттерн и даст безопасноти больше, чем параноидальная слежка за последней версией баш на всех компах… — это.
Безопасность это комплексная проблема а не прсто пару паттернов… привычек или евристик. Она начинается с заказа, проходит через архитектуру и заканчивается конечно админами с их актуальными версиями…
По поводу имиджей, если параноить, вполне видел где-то в сети как чуваки терли все из базового имиджа… Я лично этим не занимаюсь, в моем юскейсе это лишние усилия, мои сервисы изолированы друг от друга очень основательно…
Да риск есть что в яве найдут такие баги, что кто-то то через http rest получит доступ в контейнере… (сложно представимо) но теоритически, я срочно кинусь апдейтить яву… ок.
Дыра в bash? Ок, через недельку буду развивать свой сервис пропатчу и bash а пока она никак не касается моего сервиса ибо bash не задействован.
Именно так, взвешивать и понимать риски… Разделение сситемы на сервисы помогает какраз выделить те блоки которые в опасности и не трогать остальные
1) С версии 1.10 можно докер в юзерспейсе запустить…
http://162.242.237.67/docker-blog/2016/02/docker-engine-1-10-security/
2) Я не уверен что правильно понята идея Контейнеров+микросервисов
«Hardened Gentoo лежащий в основе всех образов микросервисов.» зачем?
Реально если ваше приложение распилино нормально на сервисы которые предоставляют наружу четко ограниченое АПИ (например порт 80) то какай вам разница бежит ваш сервис внутри контейнера на Hardened Gentoo или альпине? Какая потенциальная угроза?
Какраз докер минимизирует угрозу, так как изолирует как минимум логически вашу апликуху на сервисы которые специфичны…
Например в моем случае вообще побарабану что за версия openssl.
Её там просто нет… она там не нужна… Она нужна один раз на уровни виртуалки… также там нет обычно ничего друго-го критического молжноидаже баш убрать
Тоесь и обновлять постоянно ничего не надо, достаточно нормального цикла разработки совершенно, все критическое в основном на самой виртуалке.
Наверно найдутся конечно контейнеры которые должны быть особо защиещены но тогда дайти им правильный базовый имидж, отелите их от остльного дерева…
Помоему надуманная проблемность… И да докер не панацея… Докер отлицно подходит под архитектуры основаны на микросервисах, и отлично подходит в динамическую инфраструктуру.
Но потенциал докера не реализуется если не подумать обо всем, например о среде в которй будут запускаться контейнры…
Скажите, собирайть все в одно место это замечательно а как из этой информаци автоматически насторить некий мониторинг?
Ну например процессор уже 5 минут под 95% или там место на диске мало (скажем из логов видно), или ожидаемый лог перестал писаться или неожиданное в нем. и тд. и тп.
Как на такие events автоматически реагировать? Дополнительные утилиты?
Да в том то и дело что нафиг вам в такой компании работать…
Я также лет 10 назад проходил собоседование, ко мне докопались с английским, так как в школе у меня был немецкий…
Реально за 6 лет рыботы в этом концерне мне мой английский потом (который в полне на уровне) нафиг не пригодился…
И когда он мне пару рз понадобился в разговоре с килентом, то проблема была не во мен ав клиенте, который хреного говорил по английски…
И так всю дорогу… Компабния часто решала несуществующие проблемы, а существующие игнорировала.
Да этот крате мне давно приглянулся… Но всеже джоины как-то пугают ;)
Мне все трудно понять где его ниша…
НедоCassndra
НедоSQL
Проще варится чем Mongo, и вроде на чтении скалирует так-же…
Дадите немного инфы про то в чем фишка по вашему мнению?
Может у нас разные определения ДевОпс…
Но у нас от проекта зависит гит или шмидт… Ну технологии и методы…
К примеру я джавист много лет, но нынче вот к примеру конфигурировал Firewalls в продакшене длйнашего продукта… и мне нравится вся эта аджайл тема…
Уже не хочется вспоминать как я работл по всяким там ITIL. Я не хочу это все как-то в плохом свете предствлять…
В тех орг. структурах в которых я был раньше это наверно было лучшее… (Опыт не Российский)
3)
Можете как-то осветить отличия?
Я в плотную работаюс Докером, но в основнон на старых, достаточно монилтных проектах, которые регулярно патчатся но перерефакторитьих на микросервицы или нет время или нет смысла…
Однако по 2-5 контейнеров на аппликушечку набирается…
Пока хватает Docker-Compose на одной двух машинах, но тема с CoreOS очень интересна…
Мозехте просветить с вашим опытом по паре вопросов…
1) Стоит ли заморачиватся с CoreOS если сервисов пока 2-5 на аппликуху и 2, 3 виртуальных машин хватает.
2) Есть ли у вас опыт с Kubernetes который предлагхает гугл в своем опыте, мы поигрались, конечно это для наших задачь церезчур мощнан и динамическая среда… Но на рост в полне, однако мои мене опытные коллеги испугались (Инфраструктуры боятся)…
3) Есть ли у вас опыт со стэком Rancher? Воспринимается ли это как конкуренция CoreOS?
Может у вас есть общего плана совет для проектов с таким начальным количеством контейнеров и достаточно медленным их ростом, что-бы не не сильно вкладываться в инфраструктуру (в смысле майтенненса)
ни иметь по возможности максимум контроля?
IV не секретная информация он передается не шифрованым
Если вам интересно, у меня немецкий контекст. Я транслитом пишу тут… И унас это буква «j» читается и произносится так как я написал. Надеюсь это никого не оскорбило…
Считаю это плохой и весьма бесполезной штукой.
Ява всегда была легкой для новичков, начинаем вводить новый класс лупых ошобок для них и делать все немнго сложнее…
Зачем портить хороший язык…
Напишите новый под ВМ как остальные…
Представим что после успешной аутентикации мы отдаем клиенту JWT токем в котором уж есть все что нужно для последующей авторизации…
например браузерному приложению которое общается с бекэндом
при этом бэкэнд состоит из 5 микросервисев. В случае с JWT микросервицы сами смогут проверить даныные из JWT больше никуда не обращаясь в свою очередь…
Это очень очень круто.
видим поэтому они пытаются их так описать сравнив с чем-то более попнятным и сказать что «наш тул не про то а про то»
да это примерно то что я иммел ввиду
Ну это понятно, но какой-то boilerplate есть всегда темболее что в данном случае это решает какая-нибудь либа.
Утрировано проблема лишней строчки кода помоему не страшно…
Далее не всем сервисам нужда аутентикация/авторизация в принципе… но тем которым нужна нужна скорее всего достаточно псецифически (именно авторизация). Так что куда-то делегироваТь эту задачу мене кажется далеко не суперской идеей.
Это не факт есть сервисы которым вообще ничего о пользователе знать не надо а есь те которым, надо знать.
И год рождения и департамент, роль, групу и т.д. и какраз если положить все это в токен то можно отлично передавать этот токен с каждым реквестом от сервиса к сервису (общий секрет) не дергая никаких центральных сервисов авторизации…
Какраз в этом то я и вижу фишку…
И не понятно причем тут то, что видноко клиенту… Можете не показывать ему вовсе содержимое, если не нужно… просто пусть носит ссобой шифрованый токен.
Может я конечно не совсем верно понял JWT, но помеомеу о идеален именно для это-го
Немоглибы пояснить почему?
как я понимяю JWT это был-бы иделаьный варинат для микросервисов… А дополнительная валидация в nginx какрыз костыль…
1) хакнуть баговый сервис смотрящий в сеть конечно возможно. Это не проблема докера в принципе и не достоинство это ортогональная проблема… И в 99% случает криворукие программеры вашей конторы…
Тоесть чинится релизом и деплоэмнеотм одного контейнера.
2) Вы только что описали приимущества дополнительной изоляци между контенерами.
Да проникнув в контейнер (да еще по вине сторонней библиотеки, не преспроисив себя зачем она там и точно нужна..) теоритически можно получить доступ ко всему что видит контейнер.
Но это все еще меньше чем сценарий проникновения в монилит, в которм злоумышленик увидит все.
Технологий контейнеров не избавит конечно от проблем и то что вы говорите валидно… Контейнеры без микросервисной архитектуры ИМХО достаточно бесполезны…
Но если её использовать, то можна даже увеличить безопасноть. Локализировать наиболле уязвимые сервисы или те что занимаются наиболее трепетными данными… И занятся в плотнуе их бзопасностью…
Что даже не зависимо ото контейнеров хороший паттерн и даст безопасноти больше, чем параноидальная слежка за последней версией баш на всех компах… — это.
Безопасность это комплексная проблема а не прсто пару паттернов… привычек или евристик. Она начинается с заказа, проходит через архитектуру и заканчивается конечно админами с их актуальными версиями…
По поводу имиджей, если параноить, вполне видел где-то в сети как чуваки терли все из базового имиджа… Я лично этим не занимаюсь, в моем юскейсе это лишние усилия, мои сервисы изолированы друг от друга очень основательно…
Да риск есть что в яве найдут такие баги, что кто-то то через http rest получит доступ в контейнере… (сложно представимо) но теоритически, я срочно кинусь апдейтить яву… ок.
Дыра в bash? Ок, через недельку буду развивать свой сервис пропатчу и bash а пока она никак не касается моего сервиса ибо bash не задействован.
Именно так, взвешивать и понимать риски… Разделение сситемы на сервисы помогает какраз выделить те блоки которые в опасности и не трогать остальные
http://162.242.237.67/docker-blog/2016/02/docker-engine-1-10-security/
2) Я не уверен что правильно понята идея Контейнеров+микросервисов
«Hardened Gentoo лежащий в основе всех образов микросервисов.» зачем?
Реально если ваше приложение распилино нормально на сервисы которые предоставляют наружу четко ограниченое АПИ (например порт 80) то какай вам разница бежит ваш сервис внутри контейнера на Hardened Gentoo или альпине? Какая потенциальная угроза?
Какраз докер минимизирует угрозу, так как изолирует как минимум логически вашу апликуху на сервисы которые специфичны…
Например в моем случае вообще побарабану что за версия openssl.
Её там просто нет… она там не нужна… Она нужна один раз на уровни виртуалки… также там нет обычно ничего друго-го критического молжноидаже баш убрать
Тоесь и обновлять постоянно ничего не надо, достаточно нормального цикла разработки совершенно, все критическое в основном на самой виртуалке.
Наверно найдутся конечно контейнеры которые должны быть особо защиещены но тогда дайти им правильный базовый имидж, отелите их от остльного дерева…
Помоему надуманная проблемность… И да докер не панацея… Докер отлицно подходит под архитектуры основаны на микросервисах, и отлично подходит в динамическую инфраструктуру.
Но потенциал докера не реализуется если не подумать обо всем, например о среде в которй будут запускаться контейнры…
Ну например процессор уже 5 минут под 95% или там место на диске мало (скажем из логов видно), или ожидаемый лог перестал писаться или неожиданное в нем. и тд. и тп.
Как на такие events автоматически реагировать? Дополнительные утилиты?
Я также лет 10 назад проходил собоседование, ко мне докопались с английским, так как в школе у меня был немецкий…
Реально за 6 лет рыботы в этом концерне мне мой английский потом (который в полне на уровне) нафиг не пригодился…
И когда он мне пару рз понадобился в разговоре с килентом, то проблема была не во мен ав клиенте, который хреного говорил по английски…
И так всю дорогу… Компабния часто решала несуществующие проблемы, а существующие игнорировала.
Я ищу удобный и не перегруженый стартет для Angular JS 2.0
Мне все трудно понять где его ниша…
НедоCassndra
НедоSQL
Проще варится чем Mongo, и вроде на чтении скалирует так-же…
Дадите немного инфы про то в чем фишка по вашему мнению?
Но у нас от проекта зависит гит или шмидт… Ну технологии и методы…
К примеру я джавист много лет, но нынче вот к примеру конфигурировал Firewalls в продакшене длйнашего продукта… и мне нравится вся эта аджайл тема…
Уже не хочется вспоминать как я работл по всяким там ITIL. Я не хочу это все как-то в плохом свете предствлять…
В тех орг. структурах в которых я был раньше это наверно было лучшее… (Опыт не Российский)
DevOps рулит.