несколько виртуальных машин уже на самом OpenStack
Для полного счастья надо было ещё внутри докер запустить.
У нас облако на OpenStack, поэтому Vagrant и не используем, зато внутри крутятся gitlab-runner`ы и docker. Так что в принципе мы недалеко от «матрёшки» ушли. Но для локальной разработки используем только tox+virtalenv.
как по мне — плох тот разработчик, который не понимает как его код запускается. это как писать приложения без знаний что такое JMM. да и курить бамбук со словами «я жду пока мне настроят» как минимум стыдно.
Полностью согласен! Это если говорить о небольших проектах с относительно небольшим функционалом.
Если говорить о проектах побольше, посложнее и помудрёнее, то там всё не так однозначно и по большому счёту каждому знать как разворачивается продукт было бы лишней информацией. Зачем верстальщику интерфейса знать как разворачивается Django через uwsgi или mod_wsgi? (риторический вопрос)
некоторым разработчикам банально страшно давать доступ к критическим ресурсам, а доступ может быть необходим.
Как показывает практика — название профессии на это не влияет. И чаще всего разработчик который делающий «rm -rf /» и код пишет соответствующий.
Как по мне, то devops-инженер это либо руководитель проекта, имеющий достаточную компетенцию, либо это что-то вроде fool-stuck`ов в команде до 3-4х человек работающих над маленьким продуктом.
Лучшее решение автор вопроса сам предложил: зарегистрировать оба адреса на один mac.
Дело не в дополнительной обработке пакетов, а в том, что микротик будет ядром пакеты перерабатывать даже когда это не нужно. Если даже просто два интерфейса между собой мостом соединить, то при 100мб/с процессор только и будет заниматься пакетами этого моста.
Хуже всего то, что они их называют (почему-то) devops-инженерами, даже не понимая что это значит. Раньше их называли админами локахоста и избегали, а теперь ищут…
Интересное решение. Однако при большой передаче процессор будет напрягать все свои ресурсы из-за использования моста.
Мне всегда казалось, что это какая-то архитектурная ошибка такое городить. Может кто-нибудь подскажет когда подобный подход будет единственным верным решением?
Сервисов типа S3 или Glacier нет, но ничто не мешает вам развернуть тот же ceph и использовать его S3-совместимый API.
решил почитать про OpenNebula.
Мне тогда не совсем понятно, почему автор сравнивает OpenStack «в полном обмундировании» с OpenNebula — у последней конечно же будет меньше сервисов за счёт функционала.
Автор просто выбрал изначально неподходящий под свои задачи продукт и винит в этом сам продукт.
Отличное сравнение привёл fessoga5 с BMW, но я дополню: когда берёшь такой автомобиль, то ты ничего не хочешь в нём менять — ты хочешь ездить с комфортом. Ты приезжаешь в сервис для ремонта и тех.обслуживания. В BMW конечно можно воткнуть японский двигатель, но это будет форменным извращением, ну и возиться потом со всей электроникой не хочется. Зато Лада…
Он чересчур комплексный
Вы в курсе, что можно ставить только то, что нужно, а не всё сразу? Это конструктор.
Спасибо, OpenStack, благодаря тебе я возненавидел Python и все что с ним связано.
А это прям вообще странно! Какая связь? Это всё равно что сказать «ненавижу животных, потому что я однажды обнял ёжика и он меня уколол».
Он ломается. От релиза к релизу.
Вспоминаю как мои коллеги в офисе обновлялись с Ubuntu 14.04 на 16.04 — они обычно не матерятся…
А переход с CentOS 6 на 7 так вообще расстройство — целую тучу скриптов пришлось переписывать.
На то он и релиз, что отличается от предыдущих (минорные релизы не в счёт).
Лучше даже на всякий случай хосты не перезагружать, а то вдруг оно больше не поднимется?
Блин, да как вы вообще так его поднимаете/настраиваете?!
У нас на тестовом облаке, которое работает в офисе одна беда — электричество. Его просто выключают когда вздумается. ИБП хватает, но не надолго. Поэтому частые перезагрузки хоста для нас простые будни. За всё время ни разу не было проблем после перезагрузки. Это уже второе «облако» и у него всё в порядке.
Коллеги из США тоже никогда с такой проблемой не сталкиваются. Может вы просто на почве гнева начинаете искать проблемы, вместо того чтобы найти свои ошибки?
Т.е. ну вот вы наконец-то запилили инфраструктуру своей мечты, все худо-бедно работает как рассчитывали, но не хватает одной мааааленькой детали. А в новом релизе она есть. Ну по крайней мере по Release Notes.
Окей гугл, давай обновим наш OpenStack. И тут выясняется, что функционал, который вы с радостью использовали — выпилили.
«Херак-херак и в продакшн» — а потом OpenStack виноват, что вы сначала обновляетесь, а потому думаете.
С таким подходом вас вообще нельзя допускать к «боевым» серверам.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов. «Этот продукт плохой, потому что я сначала делаю, потом думаю/потому что я не умею выбирать продукт согласно своим нуждам/потому что мне он не нравится/потому что меня поцарапал кот...»
В наших школах свободное мышление не особо любят. Я помню у меня в журналах всегда было два вида оценок: 2 и 5 — и так до конца школы. Либо мы сходились во мнениях с преподавателем, либо нет — и не важно, что говорят авторитетные источники.
А «вычислителей в уме» они вообще ненавидят, потому что «этим ты не показываешь своё понимания предмета» (они как зазубрили эту фразу). И с одной стороны они правы, т.к. их задача научить. Но с другой стороны, если все ответы верны, и ученик способен показать один раз способ решения, то тут имеет смысл проявить гибкость, ведь навык решать задачи быстро в уме действительно полезен в жизни.
Вот как раз питона слушать стоит. Он мудрый, как его батя — Гвидо и компания (сообщество).
А те, кто привык размахивать «своим ручным питоном» и не слушать рекомендации, чаще всего пишут как раз код, прицеливаясь в ногу с гранатомёта.
Поддерживаю предыдущего оратора: по опыту Питон действительно помогает меньше заморачивать учеников типизацией и больше делать упор на алгоритмы. Правда о типах всё равно обязательно следует рассказать.
В Вашем комментарии вы не написали изначально, что речь о персональных данных.
Прошу прощения, забыл уточнить.
И даже с ними не всё так плохо...
К сожалению, это только выглядит так просто. На практике при достаточно больших объёмах (а у банков, сотовых операторов именно много данных) очень тяжело всё это работает.
Выдержка из ч. 5 ст. 18 ФЗ “О персональных данных”
«При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети Интернет, оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4, 8 части 1 статьи 6 настоящего Федерального закона» (ч. 5 ст. 18 ФЗ “О персональных данных”)»
Там нет уточнения какие именно ПД должны быть. Есть хорошая статья на эту тему.
Теоретически, можно «поиграться» со словами закона, но это больше добавит проблем, чем преимуществ. К тому же не за горами (просто «вангую») дополнения к закону…
Заметили такую особенность — Ruby медленно работает на SPARC архитектуре.
А тогда вопрос возникает: зачем тогда Chef взяли, если нужно было на странные архитектуры заходить? Взяли бы Ansible — ему агент не нужен. С него можно даже (при помощи определённой магии) команды на свитчах выполнять через telnet. Хотя мне Chef нравится написанием рецептов на Ruby, всё же на практике пришлось уйти к анзиблю, чтобы не зависеть от ОС обслуживаемых хостов.
Поддерживаю! Спокойно уже полтора года как вернулся к Calculate Linux Desktop (KDE) дома и в августе будет год как перешёл на CLD на работе. Работается комфортно, но я не привередлив)) Смотрю я на своего сотрудника в офисе: он был на Ubuntu (Unity), Suse (кажется там был Gnome) и сейчас перешёл на Calculate. У него везде проблемы)))
У нас облако на OpenStack, поэтому Vagrant и не используем, зато внутри крутятся gitlab-runner`ы и docker. Так что в принципе мы недалеко от «матрёшки» ушли. Но для локальной разработки используем только tox+virtalenv.
Классика
кровавого энтерпрайзапараноидального менеджмента.Так может тогда Docker лишний?
Яйцо в утке, утка в зайце, заяц в шоке…
Docker работает и под Windows, зачем ещё прослойка? Да и что мешает использовать virtualenv?
Полностью согласен! Это если говорить о небольших проектах с относительно небольшим функционалом.
Если говорить о проектах побольше, посложнее и помудрёнее, то там всё не так однозначно и по большому счёту каждому знать как разворачивается продукт было бы лишней информацией. Зачем верстальщику интерфейса знать как разворачивается Django через uwsgi или mod_wsgi? (риторический вопрос)
Как показывает практика — название профессии на это не влияет. И чаще всего разработчик который делающий «rm -rf /» и код пишет соответствующий.
Как по мне, то devops-инженер это либо руководитель проекта, имеющий достаточную компетенцию, либо это что-то вроде fool-stuck`ов в команде до 3-4х человек работающих над маленьким продуктом.
Дело не в дополнительной обработке пакетов, а в том, что микротик будет ядром пакеты перерабатывать даже когда это не нужно. Если даже просто два интерфейса между собой мостом соединить, то при 100мб/с процессор только и будет заниматься пакетами этого моста.
Мне всегда казалось, что это какая-то архитектурная ошибка такое городить. Может кто-нибудь подскажет когда подобный подход будет единственным верным решением?
решил почитать про OpenNebula.
Мне тогда не совсем понятно, почему автор сравнивает OpenStack «в полном обмундировании» с OpenNebula — у последней конечно же будет меньше сервисов за счёт функционала.
Автор просто выбрал изначально неподходящий под свои задачи продукт и винит в этом сам продукт.
Отличное сравнение привёл fessoga5 с BMW, но я дополню: когда берёшь такой автомобиль, то ты ничего не хочешь в нём менять — ты хочешь ездить с комфортом. Ты приезжаешь в сервис для ремонта и тех.обслуживания. В BMW конечно можно воткнуть японский двигатель, но это будет форменным извращением, ну и возиться потом со всей электроникой не хочется. Зато Лада…
Вы в курсе, что можно ставить только то, что нужно, а не всё сразу? Это конструктор.
А это прям вообще странно! Какая связь? Это всё равно что сказать «ненавижу животных, потому что я однажды обнял ёжика и он меня уколол».
Вспоминаю как мои коллеги в офисе обновлялись с Ubuntu 14.04 на 16.04 — они обычно не матерятся…
А переход с CentOS 6 на 7 так вообще расстройство — целую тучу скриптов пришлось переписывать.
На то он и релиз, что отличается от предыдущих (минорные релизы не в счёт).
Блин, да как вы вообще так его поднимаете/настраиваете?!
У нас на тестовом облаке, которое работает в офисе одна беда — электричество. Его просто выключают когда вздумается. ИБП хватает, но не надолго. Поэтому частые перезагрузки хоста для нас простые будни. За всё время ни разу не было проблем после перезагрузки. Это уже второе «облако» и у него всё в порядке.
Коллеги из США тоже никогда с такой проблемой не сталкиваются. Может вы просто на почве гнева начинаете искать проблемы, вместо того чтобы найти свои ошибки?
«Херак-херак и в продакшн» — а потом OpenStack виноват, что вы сначала обновляетесь, а потому думаете.
С таким подходом вас вообще нельзя допускать к «боевым» серверам.
Вообще мне становится действительно грустно, когда я вижу на хабре подобные статьи с кучей плюсов. «Этот продукт плохой, потому что я сначала делаю, потом думаю/потому что я не умею выбирать продукт согласно своим нуждам/потому что мне он не нравится/потому что меня поцарапал кот...»
А «вычислителей в уме» они вообще ненавидят, потому что «этим ты не показываешь своё понимания предмета» (они как зазубрили эту фразу). И с одной стороны они правы, т.к. их задача научить. Но с другой стороны, если все ответы верны, и ученик способен показать один раз способ решения, то тут имеет смысл проявить гибкость, ведь навык решать задачи быстро в уме действительно полезен в жизни.
А те, кто привык размахивать «своим ручным питоном» и не слушать рекомендации, чаще всего пишут как раз код, прицеливаясь в ногу с гранатомёта.
Прошу прощения, забыл уточнить.
К сожалению, это только выглядит так просто. На практике при достаточно больших объёмах (а у банков, сотовых операторов именно много данных) очень тяжело всё это работает.
Там нет уточнения какие именно ПД должны быть. Есть хорошая статья на эту тему.
Теоретически, можно «поиграться» со словами закона, но это больше добавит проблем, чем преимуществ. К тому же не за горами (просто «вангую») дополнения к закону…
А тогда вопрос возникает: зачем тогда Chef взяли, если нужно было на странные архитектуры заходить? Взяли бы Ansible — ему агент не нужен. С него можно даже (при помощи определённой магии) команды на свитчах выполнять через telnet. Хотя мне Chef нравится написанием рецептов на Ruby, всё же на практике пришлось уйти к анзиблю, чтобы не зависеть от ОС обслуживаемых хостов.
Так что всё бинарное. Здесь они сообщают о 5к бинарников.
1. Очень тяжело регламенты соблюсти в облаке;
2. Законодательно данные должны быть на территории РФ.