Я помню тот момент, когда подумал «Как же медленно всё работает, что если я распараллелю вызовы?», а спустя 3 дня, взглянув на код, ничего не мог понять в жуткой каше из потоков, синхронизаторов и функций обратного вызова.

Тогда я познакомился с asyncio, и всё изменилось.

Недавно мы писали о забавных, хитрых и странных примерах на JavaScript. Теперь пришла очередь Python. У Python, высокоуровневого и интерпретируемого языка, много удобных свойств. Но иногда результат работы некоторых кусков кода на первый взгляд выглядит неочевидным.

Ниже — забавный проект, в котором собраны примеры неожиданного поведения в Python с обсуждением того, что происходит под капотом. Часть примеров не относятся к категории настоящих WTF?!, но зато они демонстрируют интересные особенности языка, которых вы можете захотеть избегать. Я думаю, это хороший способ изучить внутреннюю работу Python, и надеюсь, вам будет интересно.

Если вы уже опытный программист на Python, то многие примеры могут быть вам знакомы и даже вызовут ностальгию по тем случаям, когда вы ломали над ними голову :)

Apache Mesos — это централизованная отказоустойчивая система управления кластером. Она разработана для распределенных компьютерных сред c целью обеспечения изоляции ресурсов и удобного управления кластерами подчиненных узлов (mesos slaves). Это новый эффективный способ управления серверной инфраструктурой, но и, как любое техническое решение, не "серебряная пуля".

В некотором смысле суть его работы противоположная уже традиционной виртуализации — вместо деления физической машины на кучу виртуальных, Mesos предлагает их объединять в одно целое, в единый виртуальный ресурс.

Mesos распределяет ресурсы CPU и памяти в кластере для задач в похожей манере, как ядро ​​Linux выделяет ресурсы железа между локальными процессами.

Представим себе, что есть необходимость выполнить различные типы задач. Для этого можно выделить отдельные виртуальные машины (отдельный кластер) для каждого типа. Эти виртуальные машины, вероятно, не будут полностью загруженными и некоторое время будут простаивать, то есть не будут работать с максимальной эффективностью. Если же все виртуальные машины для всех задач объединить в единый кластер, мы можем повысить эффективность использования ресурсов и параллельно с тем повысить скорость их выполнения (в случае если задачи краткосрочные или виртуальные машины не загружены полностью все время). Следующий рисунок, надеюсь, прояснит сказанное:



Но это далеко не все. Кластер Mesos (с фреймворком к нему) способен пересоздавать отдельные ресурсы, в случае их падения, масштабировать ресурсы вручную или автоматически при определенных условиях и т.п.

Пройдемся по компонентам Mesos-кластера.

Проблема stateful-приложений в Kubernetes

Конфигурация, запуск и дальнейшее масштабирование приложений и служб осуществляются просто, если речь идёт о случаях, классифицируемых как stateless, т.е. без сохранения данных. Такие сервисы удобно запускать в Kubernetes, пользуясь его стандартными API, потому что всё происходит «из коробки»: по стандартным конфигурациям, без привлечения какой-либо специфики и магии.

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).

На хабре уже писали про Docker swarm mode (режим роя), который является новой фичей версии 1.12. Данная опция внесла небольшую путаницу в головы тех, кто знаком с отдельно стоящей реализацией Docker Swarm имевшей распространение ранее и не отличавшейся удобством настройки и использования. Однако, после добавления Swarm в коробку с Docker все стало намного проще, очевиднее и функциональнее.

Подробнее о том, как устроен новый кластер Docker контейнеров с точки зрения пользователя, а также о простом и удобном способе разворачивания сервисов Docker на произвольной инфраструктуре далее под катом.

История появления

Одной из главных целей команды разработчиков GitHub всегда была высокая производительность. У них даже существует поговорка: «it's not fully shipped until it's fast» (продукт считается готовым только тогда, когда он работает быстро). А как понять, что что-то работает быстро или медленно? Нужно мерять. Измерять правильно, измерять надёжно, измерять всегда. Нужно следить за измерениями, визуализировать всевозможные метрики, держать руку на пульсе, особенно, когда дело имеешь с высоконагруженными онлайн системами, такими как GitHub. Поэтому метрики — это инструмент, позволяющий команде предоставлять столь быстрые и доступные сервисы, почти без даунтаймов.

В своё время GitHub одними из первых внедрили у себя инструмент под названием statsd от разработчиков из Etsy. statsd — это агрегатор метрик, написанный на Node.js. Его суть состояла в том, чтобы собирать всевозможные метрики и агрегировать их в сервере, для последующего сохранения в любом формате, например, в Graphite в виде данных на графике. statsd — это хороший инструмент, построенный на UDP сокетах, удобный в использовании как на основном Rails приложении, так и для сбора простейших метрик, наподобие вызова nc -u. Проблема с ним начала проявляться позже, по мере роста количества серверов и метрик, отправляемых в statsd.

Сегодня на нашем проекте, помимо монолитного кода, функционируют десятки микросервисов. Каждый из них требует того, чтобы его мониторили. Делать это в таких объемах силами DevOps-инженеров проблематично. Мы разработали систему мониторинга, которая работает как сервис для разработчиков. Они могут самостоятельно писать метрики в систему мониторинга, пользоваться ими, строить на их основании дашборды, прикручивать к ним алерты, которые будут срабатывать при достижении пороговых значений. С DevOps-инженеров — только инфраструктура и документация.

Этот пост — расшифровка моего выступления с нашей секции на РИТ++. Многие просили нас сделать текстовые версии докладов оттуда. Если вы были на конференции или смотрели видео, то не найдете ничего нового. А всем остальным — добро пожаловать под кат. Расскажу, как мы пришли к такой системе, как она работает и как мы планируем её обновлять.

Kubernetes — это предназначенный для контейнерной оркестровки фреймворк с открытым исходным кодом. Он был создан с учетом богатейшего опыта Google в области создания сред управления контейнерами и позволяет выполнять контейнеризованные приложения в готовом к промышленной эксплуатации кластере. В механизме Kubernetes много движущихся частей и способов их настройки — это различные системные компоненты, драйверы сетевого транспорта, утилиты командной строки, не говоря уже о приложениях и рабочих нагрузках.

По ходу этой статьи мы установим Kubernetes 1.6 на реальную (не виртуальную) машину под управлением Ubuntu 16.04 примерно за 10 минут. В результате у вас появится возможность начать изучать взаимодействие с Kubernetes посредством его CLI kubectl.

“Не трудности “ломают” вас, а то, как вы их переносите” —  Lou Holtz

В соавторстве с Emmet O’Grady (основателем NimbleCI и Docker Ninja)

В книге Франца Кафки “Превращение” (“Метаморфозы”) человек просыпается однажды утром и обнаруживает, что он превратился в гигантское насекомоподобное существо. Как у инженеров DevOps, у нас есть такие же сюрреалистические моменты в жизни. Мы находим экзотические ошибки “под ковриком” (скрытые в самых труднодоступных местах) или бываем атакованы червями либо другими опасными сущностями. Если вы занимаетесь этим достаточно долго, у вас рано или поздно появится ужасная история, или даже две (поделитесь ими с нами!). В такой момент мы не можем сидеть и ждать, когда наступит кризис, мы должны действовать быстро. Торопясь исправить это как можно раньше, мы должны развернуть (deploy) новую сущность и выпустить новую версию нашего сервиса, устраняя проблему.

Попытка развенчания мифов об OpenVZ, или VPS на OpenVZ vs Xen/KVM/Hyper-V/etc

По какой-то непонятной для меня причине на Хабрахабре сложилось негативное отношение к технологии OpenVZ вообще, и к OpenVZ хостингу в частности. Этот пост попытка развенчать мифы, касающиеся OpenVZ хостинга, Хотя на мой взгляд, OpenVZ так же едва ли не лучшее решение для разделения моногенных (Linux-only сервисов) внутри предприятия на собственных серверах.

Я не являюсь заинтересованным лицом, пишу пост не от имени своего работодателя, а от самой себя.

Итак, тезис: бюджетные Linux VPS на OpenVZ, как правило, работают быстрее и стабильнее, чем бюджетные VPS, использующие гипервизоры. Дорогие VPS на гипервизорах, в «облаках» или с фиксированным тарифным планом, лучше, чем дорогие VPS на OpenVZ.

Это вторая публикация, созданная по мотивам моих выступлений на конференциях. Первая была общей и посвящена обзору практик Continuous Delivery с Docker. Новая основана на более прикладном докладе «Собираем Docker-образы быстро и удобно», который прозвучал 8 ноября на конференции HighLoad++ 2016 в секции «DevOps и эксплуатация».



Как и в прошлый раз, если у вас есть возможность потратить ~час на видео, рекомендуем посмотреть его полностью (см. в конце статьи). В ином случае — представляем основную суть в текстовом виде.

Что мы хотим от Docker-образов?

6 июня на конференции RootConf 2017, проходившей в рамках фестиваля «Российские интернет-технологии» (РИТ++ 2017), в секции «Непрерывное развертывание и деплой» прозвучал доклад «Наш опыт с Kubernetes в небольших проектах». В нём рассказывалось об устройстве, принципах работы и основных возможностях Kubernetes, а также о нашей практике использования этой системы в небольших проектах.

По традиции мы рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.

Как это часто бывает в первые годы жизни инфраструктурных проектов, стремительно набирающих популярность, пока многие только присматриваются к Kubernetes, оценивая его возможности и зрелость, другие успевают продвинуться дальше, протестировать и запустить в production (полностью или частично), получив свой первый «взрослый» опыт эксплуатации. Эта статья начинает обзорный цикл примеров из мировой практики достаточно известных компаний, использующих Kubernetes в production.



Примечание: все примеры рассказывают об использовании оригинального upstream-дистрибутива Kubernetes, а не его производных вроде OpenShift (Red Hat) и Tectonic (CoreOS).

Начнём с eBay, специалисты которой серьёзно работают с Kubernetes уже более 2 лет и значительно продвинулись в этом…

Решения Ansible гарантируют максимальную гибкость. Это позволяет сообществу находить все новые способы использования модулей Ansible для автоматизации часто выполняемых операций на многих уровнях, в том числе в сочетании с технологиями OpenStack.

В этом блоге мы будем обсуждать многочисленные варианты использования Ansible, самого популярного программного обеспечения (ПО) для автоматизации, совместно с OpenStack, самым популярным ПО для облачной инфраструктуры. Мы поможем вам понять, как и почему вам следует использовать Ansible, чтобы сделать свою жизнь проще с помощью комплексной автоматизации (Full-Stack Automation), как мы любим ее называть.

Прим. Переводчика. Статья может быть интересна архитекторам и разработчикам, планирующим построение решения на основе микросервисов, либо ищущим способы оптимизации текущего решения, особенно если работа идет с большими объемами данных. Перевод сделан на основе части 1 и части 2 цикла статей о микросервисах на Apache Ignite. Предполагается общее знакомство с экосистемой Java (Apache Ignite работает также с .NET, C++, а через REST и с другими языками, но примеры в статье будут апеллировать к Java), рекомендуется наличие базового знания Spring.

Сегодня микросервисная архитектура — это один из наиболее популярных подходов, на основе которого многие компании строят свои решения. Одно из ключевых преимуществ этого подхода — то, что он предполагает разделение решения на набор слабо связанных компонентов — микросервисов, — каждый из которых может иметь собственный жизненный и релизный циклы, команду разработки и т.д. У этих компонентов всегда есть хотя бы один механизм обмена данными, посредством которого микросервисы взаимодействуют друг с другом. Более того они могут создаваться с использованием разных языков и технологий, наиболее подходящих конкретному модулю системы.

Если вы используете решения на основе микросервисной архитектуры там, где есть высокая нагрузка и необходимо работать с активно растущими массивами данных, скорее всего, вы сталкивались или столкнетесь с проблемами классических подходов:

Привет, Хабр! Продолжаю публикацию своей книги о юридических аспектах IT-бизнеса. Сегодня — про налоги и смежные вопросы. Учитывая, что в России налоговая система слабо дифференцирована по видам бизнеса, материал вполне подойдет и для «обычного», то есть нетехнологического предпринимательства.



Книга «Закон стартапа»:

1. Стартапер vs. предприниматель
2. Выбираем форму
3. Регистрация
4. Корпоративное управление
   Как юридически строится компания
5. Текущая работа
   Договоры и как они работают
   Как проверить партнера по открытым источникам
6. Налоги
   Что платит IT-бизнес в России?
7. Государственная поддержка
8. Цикл стартапа
   Как (в общем) работает венчурное инвестирование
9. Венчурные сделки
10. Венчурные фонды
11. Интеллектуальная собственность
12. Офшоры и ВЭД
    Преимущества и подводные камни офшоров

Привет, уважаемые читатели Хабрахабра. В этой статье попробуем разобраться что такое мемоизация и каррирование, и как эти методы реализованы в стандартной библиотеке Python.

Часть первая

Продолжаем

Продолжаем создание кластера, начатое первой части.
На этот раз я расскажу про настройку кластера.

В прошлый раз мы закончили на том, что началась синхронизация DRBD.
Если мы в качестве Primary сервера для обоих ресурсов выбрали один и тот же сервер, то после завершения синхронизации должны в /proc/drbd увидеть примерно такую картину:

# cat /proc/drbd
version: 8.4.3 (api:1/proto:86-101)
GIT-hash: 89a294209144b68adb3ee85a73221f964d3ee515 build by root@debian-service, 2013-04-30 07:43:49
 0: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:190397036 dw:190397036 dr:1400144904 al:0 bm:4942 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate B r-----
    ns:0 nr:720487828 dw:720485956 dr:34275816 al:0 bm:3749 lo:468 pe:0 ua:0 ap:0 ep:1 wo:d oos:0

Самое интересное поле тут ds:UpToDate/UpToDate, означающее что и локальная и удаленная копия актуальны.

После этого переведем ресурсы в secondary режим — дальше ими будет управлять кластер:

# drbdadm secondary VM_STORAGE_1
# drbdadm secondary VM_STORAGE_2

Pacemaker

Итак, менеджер кластера.

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

Здравствуйте! Хочу рассказать про особенности партиционирования в текущей postgresql 9.х и его улучшении с помощью расширения pg_pathman (и вот), созданного парнями из Postgres Professional. Статья предназначена для знакомых с партиционированием разработчиков, которым понадобилось разбить большую БД в postgres, или для тех, кто хочет оценить сложность переноса уже партиционированной не postgres БД на postgres.

Сначала мы создадим схему БД, затем партиционируем её двумя способами(«штатным» и pg_pathman), после чего наполним данными и проверим, как работают запросы по партиционированным таблицам.

Также я расскажу, как это замечательное расширение внедрить в схему данных, уже побитую на партиции «штатным» способом.