Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.

И снова здравствуйте. Несколько дней назад началось обучение в новой группе по курсу «Архитектор ПО», а сегодня мы хотели бы поделиться статьей, которую написал один из студентов курса — Плешаков Антон (руководитель направления разработки в компании «Программная логистика» и co-founder в Clusterra).

---

В настоящее время распределенные микросервисные системы стали фактически промышленным стандартом, причем не только в мире энтерпрайза. Преимущества использования распределенных систем описывались и обсуждались уже неоднократно. Плюсы микросервисов всем давно известны: технологии под задачу, composability, scalability, масштабирование разработки, снижение TTM и так далее. Очевидно что разработка распределенных приложений дает больше опций для своевременной реакции на растущие запросы бизнеса и цифровизацию всего вокруг.

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

Нет худа без добра! В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 80% и не думает останавливаться. Трафик попёр настолько сильно, что в нескольких странах Netflix, Youtube и прочие стриминговые сервисы сначала просили ограничить, а теперь им фактически запрещают передачу контента в HD качестве. Ибо пользователи настолько активно взялись за работу из дома, что места для развлечений в каналах у операторов просто не осталось.

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

И вот тут стоит задать себе вопрос — а в чём же сложность взять и организовать удобный VPN-сервис, а затем просто поддерживать его? Технология придумана далеко не вчера, все варианты давно известны, так почему же вокруг неё столько разговоров?

Но дабы не писать миллион первую статью про тонкости настройки OpenVPN, IPSec и прочих, давайте подойдём с другой стороны — а бывает так, что VPN делается быстро, удобно и бесплатно? Вот чтобы действительно десяток кликов — и работает как часы. И site-to-site, чтобы офисы связать, и site-to-point, чтобы удалёнщикам было быстро и удобно.

Спойлер — бывает.

Пруфы и рассуждения — под катом.

Привет, друг.

Как известно, каждый уважаемый кодер рано или поздно пишет свой логер, парсер json и язык программирования. Поскольку первое и второе мы уже написали, то нам ничего не остаётся, как представить наши наработки по новому инновационному языку программирования karasic.

Отдадим должное игре, ставшей прародительницей целого жанра. Имя ей Rogue.

Распространённость игр Roguelike росла на протяжении всех 40 лет существования жанра, даже несмотря на то, что в нём реализованы идеи, кажущиеся «анафемой» для популярности: высокая степень случайности, ASCII-графика, перманентная смерть (permadeath), огромная сложность и многое другое. Тем не менее, сегодня шагу нельзя ступить, не наткнувшись на игру, на которую по крайней мере не повлияли roguelike.

В духе историй об игровых жанрах (мы уже рассказывали о стратегиях реального времени [перевод], градостроительных играх, шутерах от первого лица [перевод], симуляторах [перевод: первая и вторая части], графических адвенчурах [перевод], гонках на картах и играх с открытым миром [перевод]) давайте теперь начнём разбираться, как мы к этому пришли и что это всё означает. Мы совершим экскурсию по дереву эволюции roguelike, начав с самой Rogue и пройдя весь путь до современных игр с «элементами roguelike».

Но для начала нам нужно ответить на важный вопрос.

Что такое «roguelike»?

Невозможно подобрать точное определение этому термину, кроме его буквального значения («игра наподобие Rogue»). Можно сказать, что roguelike — это путешествия по рандомизированным подземельям почти без сюжета или с полным его отсутствием; игрок сражается и с самим подземельем, и с монстрами внутри, бесконечно повторяя этот процесс, чтобы освоить схемы, содержание и системы, определяющие природу игры, пока не умрёт и не начнёт заново.

Но кое-кто пытался сузить это определение. Можно взять для примера «факторы высокого значения» Берлинской интерпретации, которые были приняты на Международной конференции по разработке roguelike 2008 года (International Roguelike Development Conference 2008). (Да, ежегодно проводится конференция для разработчиков roguelike, а также ещё одна для игроков.)

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



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

Хабр, это снова я, Алексей Рак (фото не мое). В прошлом году, помимо основной работы, мне довелось стать одним из авторов задач для кандидатов в Яндекс. Сегодня наша команда впервые за долгое время публикует на Хабре реальные задачи для разработчиков, которые устраиваются в компанию. Эти задачи использовались до февраля 2020 года при отборе на стажировку для бэкендеров. Решения проверял компьютер. Сейчас кандидатам достаются похожие задания.

Разборы и код сознательно спрятаны в спойлеры. Если вы готовитесь к собеседованиям в большие IT-компании, попробуйте решить одну или несколько задач, прежде чем смотреть разбор. Отправить решение для проверки можно на Codeforces — ответ придёт сразу же (ссылка на Codeforces и примечание). Код представлен на Python, C++ и Java. Важно: авторский «олимпиадный» код не предназначен для продакшена, он написан исходя из того, что система будет проверять его автоматически.

„То, что принято без доказательств, может быть отвергнуто без доказательств.“

— Эвклид.

Пост «Коронавирус: почему надо действовать прямо сейчас», как и оригинал перевода собрал много внимания аудитории по вполне понятным причинам. Поскольку всё в мире должно находиться в равновесии, то в рамках этого поста будет дана попытка представить ещё один взгляд на, уже всеобщую, проблему. Задача явным образом опровергнуть или разоблачить вышеприведённый пост не стоит. Каждый самостоятельно может сопоставить противоречащие утверждения.

Действительно, учитывая всё, что происходит с коронавирусом, может оказаться очень сложно принять решение, что делать прямо сейчас. Стоит ли подождать, пока станет больше информации? Надо ли предпринять что-то уже сегодня? Если да, то что?

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

В этом видео со множеством графиков, данных и моделей автор постарается ответить на многие вопросы:

• Какова природа вирусных заболеваний? 3:30
• Каков существующий масштаб ущерба от вирусных заболеваний, когда об этом не было принято повсеместно говорить?
• Какова механика и специфика распостранения острых вирусных респираторных заболеваний и коронавируса в частности? 17:30
• Для кого коронавирус представляет опасность? 23:00
• Как корректно считать и оценивать смертность, летальность и каковы эти значения для коронавирусной инфекции? 30:00
• Какова связь между заразностью и смертностью вирусных инфекций? 35:00
• Про маски. 50:00
• Ретроспективный разбор действий Китая и о пользе карантина. 53:00

В 2010 году у компании Wargaming было 50 серверов и простая сетевая модель: бэкенд, фронтенд и файрвол. Количество серверов росло, модель усложнялась: стейджинги, изолированные VLAN с ACL, потом VPN с VRF, VLAN c ACL на L2, VRF с ACL на L3. Закружилась голова? Дальше будет веселее.

Когда серверов стало 16 000 работать без слез с таким количеством разнородных сегментов стало невозможно. Поэтому придумали другое решение. Взяли стек Netfilter, добавили к нему Consul как источник данных, получился быстрый распределенный файрвол. Им заменили ACL на роутерах и использовали как внешний и внутренний файрвол. Для динамического управления инструментом разработали систему BEFW, которую применили везде: от управления доступом пользователей в продуктовую сеть до изоляции сегментов сети друг от друга.



Как это все работает и почему вам стоит присмотреться к этой системе, расскажет Иван Агарков (annmuor) — руководитель группы инфраструктурной безопасности подразделения Maintenance в Минском центре разработки компании. Иван — фанат SELinux, любит Perl, пишет код. Как руководитель группы ИБ, регулярно работает с логами, бэкапами и R&D, чтобы защищать Wargaming от хакеров и обеспечивать работу всех игровых серверов в компании.

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

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



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

Что такое DDD и какие инструменты в нем есть, мы расскажем в статье на основе доклада Артема Малышева. Подход DDD в Python, инструменты, подводные камни, контрактное программирование и проектирование продукта вокруг решаемой проблемы, а не используемого фреймворка — все это под катом.

Вчера, 18 февраля, в нашем университете НИТУ «МИСиС» прошла публичная лекция главы «Сбербанка» Германа Грефа и гендиректора Cognitive Pilot Ольги Усковой на тему «Нейроэволюция. Как жить и успевать в новых реалиях: HUMAN+AI».

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

Не обманули.



Вот несколько цитат из выступления Германа Оскаровича:

Про дофаминовых алкоголиков:

В 1991 году издательство «Просвещение» выпустило детскую книгу «Энциклопедия профессора Фортрана». Практически моментально она стала бестселлером и разошлась миллионными тиражами. Это был очень легкий и понятный рассказ о персональных компьютерах, которых в нашей стране еще не было практически ни у кого. Музейный проект DataArt пообщался с авторами книги Андреем Зарецким и Александром Трухановым о том, как два ученых-физика решили стать писателями и придумали профессора Фортрана и Кадабру. В первой части монолога — рождение идеи, ненавистный научпоп, свобода мысли в Черноголовке и чаепитие с Фронтом освобождения Полисарио.

Elasticsearch, вероятно, самая популярная поисковая система на данный момент с развитым сообществом, поддержкой и горой информации в сети. Однако эта информация поступает непоследовательно и дробно.

Самое первое и главное заблуждение — "нужен поиск, так бери эластик!". Но в действительности, если вам нужен шустрый поиск для небольшого или даже вполне себе крупного проекта, вам стоит разобраться в теме поподробней и вы откажетесь от использования именно этой системы.

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

Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.

До недавнего времени весь процесс сборки проводился кем-либо из разработчиков вручную. Что отнимало час, два и больше времени и было, мне кажется, не очень интересным занятием. Теперь же, когда уже почти все готово, релиз из 20 задач, затрагивающий 5 проектов, собирается меньше минуты. Остается, конечно еще разрешение конфликтов, запуск пропущенных тестов и прочее, но даже с учетом этого, времени разработчиков и тестировщиков, вынужденных ждать, пока кто-то и первых освободится и создаст RC, экономится немало.

В общем, приступил я к задаче, и она оказалась очень интересной и увлекательной. А что еще надо для удовольствия от работы, как не увлекательных проектов?

Прим. перев.: В этой статье компания Banzai Cloud делится примером использования её специальных утилит для облегчения эксплуатации Kafka в рамках Kubernetes. Приводимые инструкции иллюстрируют, как можно определить оптимальный размер инфраструктуры и настроить саму Kafka для достижения требуемой пропускной способности.



Apache Kafka — распределённая стриминговая платформа для создания надёжных, масштабируемых и высокопроизводительных потоковых систем реального времени. Её впечатляющие возможности можно расширить с помощью Kubernetes. Для этого мы разработали Open Source-оператор Kafka и инструмент под названием Supertubes. Они позволяют запускать Kafka в Kubernetes и использовать её различные функции, такие как тонкая настройка конфигурации брокера, масштабирование на основе метрик с ребалансировкой, rack awareness (осведомлённость об аппаратных ресурсах), «мягкое» (graceful) выкатывание обновлений и т.д.

Предлагаю ознакомиться с расшифровкой доклада Ивана Пономарёва «Ansible playbooks — это код: проверяем, тестируем, непрерывно интегрируем».

Рефакторинг кода может быть увлекательным, особенно если это код вашей инфраструктуры. К тому же Ansible-роли почему-то имеют тенденцию к быстрому увеличению сложности. И это добавляет «изюминку» в вашу задачу. Иван расскажет, как можно преодолевать сложность Ansible-кода с помощью тестирования. В Docker-контейнерах.
По мере разрастания кодовой базы в Ansible приходят знакомые проблемы: сложность поддержки кода, ошибки и страх изменений. У знакомых проблем есть знакомое решение: автоматическое тестирование и CI. В докладе Иван покажет, как с использованием ряда инструментов решить проблемы «хрупкости» Ansible-кода, выполнить статический анализ, протестировать Ansible-скрипты и настроить CI-системы для публикации ролей в Ansible Galaxy.

После выхода Ubuntu 16.04 (новый LTS релиз), systemd стал реальностью всех основных дистрибутивов Linux, использующихся на серверах. Это означает, что можно закладываться на расширенные возможности systemd, не рискуя оставить часть пользователей приложения «за бортом».

Этот пост о том, как реализовать многоворкерное приложение средствами systemd.

Abstract: Использование шаблонов сервисов и target'ов для запуска нескольких инстансов сервиса (реализация «воркеров»). Зависимость PartOf. Немного про [install] секцию у unit'ов.

Вступление

Многие языки программирования с плохой или никакой многопоточностью (Python, Ruby, PHP, довольно часто C/C++) используют концепцию «воркера». Вместо того, чтобы городить сложные отношения между тредами внутри приложения, они запускают несколько однопоточных копий приложения, каждое из которых берёт на себя кусок нагрузки. Благодаря опции SO_REUSEPORT есть даже возможность «вместе» слушать на одном и том же порту, что покрывает большинство задач, в которых возникает потребность в воркерах (собственно, обычные серверные приложения, реализующие API или обслуживающие веб-сайт).

Но такой подход требует наличия «супервизора», который отвечает за запуск копий, следит за их состоянием, обрабатывает ошибки, завершает при всякого рода stop/reload и т.д. При кажущейся тривиальности — это совершенно не тривиальная задача, полная нюансов (например, если один из воркеров попал в TASK_UNINTERRUPTIBLE или получил SIGSTOP, то могут возникнуть проблемы при restart у не очень хорошо написанного родителя).

Есть вариант запуска без супервизора, но в этом случае задача reload/restart перекладывается на администратора. При модели «один процесс на ядро» перезапуск сервиса на 24-ядерном сервере становится кандидатом в автоматизацию, которая в свою очередь требует обработки всех тех же самых SIGSTOP и прочих сложных нюансов.

Одним из вариантов решения проблемы является использование шаблонов сервисов systemd вместе с зависимостью от общего target'а.

Abstract: Реальная история из жизни реальных администраторов по отлову идиотского бага.
Поучительная часть: Никогда не недооценивай зависимости зависимостей.

Вступление

Рядовой апгрейд в лаборатории с Openstack Mitaka до Openstack Newton (более новая версия). Несколько deprecated options в файлах конфигурации, keystone переехал с eventlet на WSGI и поломал существующую конфигурацию с haproxy; из-за типового «ipv6 listen» apache не стал конфликтовать с haproxy за одинаковые используемые порты на звезде (один слушал ipv6, другой ipv4 only), так что запросы уходили в haproxy вместо апача, где умирали с 503, т.к. апстрима не было… Впрочем, история не об этом.

После того, как основные проблемы были пофишкены, Nova (одна из компонент Openstack) при запуске начала падать с ошибкой: ConfigFileValueError: Value for option url is not valid: invalid URI: 'http://neutron-server.example.com:21345'.. Это было очень странно. С учётом, что в конфиге поменялось 100500 опций, возникло подозрение, что мы используем устаревшую опцию, которую больше не надо использовать. Однако, документация говорила, что пример опции — url = http://controller:9696.

Отладка

Очевидные шаги отладки:

• Закомментировать опцию — не падает
• Повторить опцию из примера — не падает
• Заменить в опции порт на «наш» — возможно, нельзя использовать слишком большой номер порта — не падает
• Заменить в опции url на наш — падает
• Вернуть «controller» на место — не падает
• Подозрение: не умеет fqdn: заменить controller на controller.dns — не падает
• Подозрение: слишком много точек (у нас в реальном коде было 8 точек в url) — controller.dns1.dns2.dns3.dns4 — не падает
• Оставить из нашего имени только первую часть: http://neutron-server:9696 — падает! гипотеза уже понятна.
• Проверка1: http://neutronserver:9696 — не падает
• Проверка2: http://with-dashes:9696 — падает!

У меня дома используется Debian Sid. Большей частью он весьма и весьма хорош, но местами он слишком Bleeding слишком Edge. Например, когда отгружает пакеты, ломающие работоспособность системы. Вчера приехал wpasupplicant, который сломал мне wifi. Я его откатил, но в процессе я подумал, что многие пользователи не умеют этого делать. Рассказ "как откатить плохой apt-get install/upgrade" — в этом посте.

Ситуация

Мы сделали apt-get install что-то, или apt-get upgrade, или даже apt-get dist-upgrade, и после перезагрузки (или даже сразу же) обнаружили, что так нельзя. Сервис не стартует, убрана важная нам фича, кто-то падает и т.д. Мы хотим откатиться. Но вот, незадача — куда именно мы не знаем, потому что какая была версия до обновления мы не знаем.

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

Мы полагаем, что разработчикам следует изучать исходники программ, оказавших большое влияние, подобно тому, как архитекторы изучают здания, оказавшие влияние на архитектуру (и критикуют их). Чем повторять те же ошибки снова и снова, мы должны изучить большую работу, проделанную до нас, и вынести из неё уроки.