Как стать автором
Обновить
20
Карма
0
Рейтинг

Пользователь

В эту пятницу пройдет 7-я конференция сообществ DevConf 2016

Хоть бы пост-фактум видео на Youtube увидеть..

Celery: лучшие практики

Я не понимаю что вы хотите доказать

Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.

Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя

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

По функционалу — пройдитесь по списку resque плагинов и их описанию. Заодно статья за 2009 год будет полезна почему Github написали свой велосипед, перепробовав кучу других MQ:
highscalability.com/blog/2009/11/6/product-resque-githubs-distrubuted-job-queue.html

Я в корне не согласен с трактовкой что Redis как бэкенд для MQ (пример resque) не подходит для серьезных задач и нагрузок. И по функционалу и по скорости (~100K сообщений/секунду на ядро одинаково достижимы как для resque так и для RabbitMQ) и по надежности (миллионы сообщений в сутки не проблема вообще ни для какой MQ).

Celery: лучшие практики

В Redis-e есть авторизация и он умеет накапливать в очереди.

У рубистов есть Resque, который использует Redis в качестве бэкенда.
Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.

Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).

Security Week 32: Android Stagefright, новые автодыры, Do Not Track 2.0

Security Week — отличный формат!

+1, даже несмотря на субьективно негативное отношение к К.

Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена

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

Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
Соответственно это путь в никуда.

Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена

Во время атаки один из майнинг пулов BitFury (16% от всей системы) так и сделали.
Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:

www.reddit.com/r/Bitcoin/comments/3cnrt8/bitfury_pool_16_of_hashrate_drops_their_max_block

Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена

Две важные ссылки относительно текущей Scalability проблемы и планов BitCoin:

en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap

Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.

Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!

Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена

Две важные ссылки относительно текущей Scalability проблемы и планов BitCoin:

en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap

Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.

Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!

Bitcoin на пределе? Почему криптовалюту ждут тяжелые времена

Visa рассчитана на что-то около 60к транзакций/секунду, при обычной нагрузке в 2к транзакций/секунду.
Можно говорить о том, насколько сеть подготовлена к нагрузке.

Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.

Так что +1,
гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.

Тестирование парольных политик крупнейших веб-сервисов

И другие замечательные вещи, которые нужно долго и правильно настраивать

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

Тестирование парольных политик крупнейших веб-сервисов

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


У меня немного другое мнение. Раздражают сервисы с подобной политикой:
  • ваш пароль должен содержать 8+ символов
  • 8? ок, теперь в пароле должна быть заглавная буква
  • есть заглавная? Теперь добавьте спец-символ
  • добавили? ок, ок, теперь должна быть хотя бы одна цифра
  • прошло 6 месяцев, теперь поменяйте пароль снова

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

Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.

Хорошо работающая система безопасности практически невидима для пользователя!
Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
Очень важно соблюсти баланс.

Ansible и ChatOps или как управлять 100+ серверами из чата

Чтобы лучше понимать ChatOps.
Вот короткое (20 мин.), но очень энергичное видео о ChatOps опыте в GitHub (на английском):

ChatOps: Методология и Философия

Освещает такие вопросы:
  • Преимущества ChatOps
  • Использование в реально большой организации
  • C чего начать
  • Примеры из жизни
  • Вопросы безопасности
  • Что стоит делать с помощью ChatOps, а что нет


Ansible и ChatOps или как управлять 100+ серверами из чата

Update по поводу безопасности:
В англоязычной ветке обсуждения справедливо заметили, что пример у HipChat есть корпоративная версия, те. чат полностью на своем сервере внутри организации.

В Slack enterprise версия «coming soon in 2015».

Скорее всего есть и другие сервисы с hosted версией.

Ansible и ChatOps или как управлять 100+ серверами из чата

Не удивительно, — очень много одинаковых идей но с разной реализацией.
Можно кстати вкратце, какие-то примеры/ссылки, тк. я от электроники отошел лет 6 назад. Совсем не слежу, но интересно.

Я не думаю что мы пооффтопим здесь, речь об автоматизации.
Кстати есть человек который умный дом построил, взяв за контрольный центр st2 (те вся обработка событий построена на этой платформе, что фактически Yaml + Python). Камеры повсюду, сенсоры, админка для доступа извне, https, ключи авторизации (слышал еще пугает заходящих на территорию котов включением автополива газона, что тоже не ново).

Ansible и ChatOps или как управлять 100+ серверами из чата

MS поломали Skype ;(

Ansible и ChatOps или как управлять 100+ серверами из чата

Хороший вопрос.

Отладка ChatOps команд и сценариев вручную:
Тестируем и хорошо проверяем в Vagrant и Docker: st2workroom, st2express ну и Code reviews, как обычно. Благо, благодаря декларативному подходу и вынесению высокоуровневой логики в Yaml файлы — читать и разбираться легче.

Автоматическое тестирование сценариев и команд:
Есть st2tests, дополнительные Acceptance тесты, когда платформа тестирует некоторые части самой себя с помощью самой себя (картинка выше напомнила). К примеру, вот тест, который проверяет процесс установки/удаления паков. Все это поставляется в виде отдельного пака, те тесты могут быть установлены из внешнего репозитория и запущены как обычный пак (плагин/расширение).

^^ Так же можно поступать для собственных сценариев, тестируя их своими же автоматическими тестами.
Итого, если делать все серьезно для продакшна, может получится 2 репозитория/пака: 1 с вашими командами и сценариями и 1 опциональный с тестами.

И последнее,
реальные команды — они чаще всего состоят из цепочек действий и условий (если случилось 1 -> значит делаем 2, потом 3, потом 4), те что-то массивное складывается в единую ChatOps команду. Чаще всего на продакшене таких команд немного, перепутать — трудно. Самое популярное — это деплой/развертывание.
То что указано в примере с uname -a из чата, когда можно выполнить любую shell конструкцию из чата — это только для простоты демонстрации. Обычно мало смысла такое ставить в продакшн.

Ansible и ChatOps или как управлять 100+ серверами из чата

Интересная идея!

Вот более сложный/реальный пример с созданием из чата Autoscaling группы и авто-заменой упавших серверов на живые:
habrahabr.ru/post/260917/#comment_8479121

Ansible и ChatOps или как управлять 100+ серверами из чата

Люди стараются упрощать себе жизнь, и это получается.
Вот более серьезный пример: Autoscaling showcase (можно запустить на Vagrant).

Что происходит:
  • Начинается все с ChatOps команды: !asg create name=test domain=domain.com min_nodes=1 expand_by=1
  • Создается Autoscaling группа с серверами в облаке (тут цепочка действий)
  • Платформа слушает состояние серверов через NewRelic API (заменить на свой мониторинг)
  • Дальше происходит интересное, если какой-то сервер в группе падает:
    • 1. система получает триггер из NewRelic что какой-то из серверов упал
    • 2. убирает сервер из Autoscaling группы
    • 3. заменяет его на другой только что поднятый сервер

  • Система сама себя вылечила, вы спите спокойно. Profit!

Видео на английском (листать на 5 минуту, где начинается интересное).

Кстати человек бывший GitHub-овец. Можно конечно «обидить хужожника» и сказать что GitHub, Rackspace, Puppet labs, Box итд просто фигней занимаются с этим ChatOps, но коммьюнити сейчас делится на тех, кто это использует и тихонько получает c этого выгоду, и всех остальных.

Ansible и ChatOps или как управлять 100+ серверами из чата

Кстати, кто из крупных компаний точно использует ChatOps:

  • Github (сами придумали, — сами и используют)
  • RackSpace Сloud
  • Puppet Labs
  • Box.com
  • HP
  • много средних стартапов вроде 500px.com, Pagerduty, VictorOps итд.

Вероятно много других компаний используют или хотя бы пробуют в различных подразделениях (но не разглашают), потому что когда скорость реакции, производительность команды увеличивается в х3-х10 раз — это огромные для такого уровня бизнеса деньги.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность