Выкладываю второй доклад с нашего первого митапа, который провели в сентябре. В прошлый раз можно было почитать (и посмотреть) про использование Consul для масштабирования stateful-сервисов от Ивана Бубнова из BIT.GAMES, а сегодня поговорим про CICD. Точнее расскажет об этом наш системный администратор Егор Панов, который отвечает за доступность инфраструктуры и сервисов в Pixonic. Под катом — расшифровка выступления.

22 сентября провели наш первый нестандартный митап для разработчиков высоконагруженных систем. Было очень круто, много позитивного фидбека по докладам и поэтому решил не только их выложить, но и расшифровать для Хабра. Сегодня публикуем выступление Ивана Бубнова, DevOps из компании BIT.GAMES. Он рассказал о внедрении дискавери-сервиса Consul в уже рабочий высоконагруженный проект для возможности быстрого масштабирования и failover`а stateful-сервисов. А также об организации гибкого пространства имен для бэкэнд-приложения и подводных камнях. Теперь слово Ивану.


Я администрирую продакшн-инфраструктуру в студии BIT.GAMES и расскажу историю внедрения консула от Hashicorp в наш проект «Гильдия Героев» — fantasy RPG с асинхронным pvp для мобильных устройств. Выпускаемся на Google Play, App Store, Samsung, Amazon. DAU около 100 000, online от 10 до 13 тысяч. Игру делаем на Unity, поэтому клиент пишем на С# и используем свой собственный скриптовый язык BHL для игровой логики. Серверную часть пишем на Golang (перешли на него с PHP). Дальше — схематичная архитектура нашего проекта.

Рассказывать о новых проектах это, конечно, хорошо, но не всегда всё получается, как мы хотим.

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

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

В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.

В мае вместе с CTO Pixonic Сергеем Ждановым (я — слева, он — справа) посетили Google I/O 2018 в Калифорнии. Хотелось посмотреть на тренды, технологии, пообщаться с разработчиками (я еще собирался поучаствовать в Codelabs, а то в прошлый раз не удалось туда попасть). В целом, если сравнивать с прошлым годом, Keynote был не такой впечатляющий, но все равно есть о чем рассказать по итогам конференции.

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

Год назад у нас в компании был один проект — мобильный шутер War Robots с относительно медленными, но красочными и напряженными боями. Игра продолжает развиваться, у нее десятки миллионов установок и игроков по всему миру, постоянно выходят апдейты. В какой-то момент мы захотели сделать динамичный шутер на Unity со скоростями, сравнимыми с Overwatch, CS:GO или Quake. Но реализовать задуманное для мобильных платформ (в первую очередь iOS и Android) на основе War Robots при текущих архитектуре и подходах было практически нереально.

Мы понимали, как это сделать в теории — есть много статей, презентаций на YouTube, детально рассказывающих о том, как написать шутер, как работать с сетью, какие возникают проблемы и как их решать. Здесь нет Rocket Science, все эти подходы придумали еще 30 лет назад и за это время они особо не поменялись. НО: у нас не было практики.

Забегая вперед, скажу — нам удалось реализовать задуманное. Мы создали для мобильных платформ динамичный быстрый шутер, который сейчас находится в бета-тестировании и активно дорабатывается. И мне очень хотелось бы всем этим поделиться. Это первая, обзорная статья с перечислением и кратким описанием практически всего того, что мы используем (прошу не путать с другим нашим проектом в разработке, технологии и подходы в котором похожие, но отличаются в деталях).

Я лид команды в Pixonic, где работаю уже год. О старте и развитии одного из наших новых проектов я ранее написал статью на Хабре. По ходу дальнейшего производства, спустя еще полгода, у меня накопилось большое количество интересного опыта, которым хотел опять поделиться. На этот раз речь пойдет о процессе наращивания функционала в мобильном клиенте и поддержании кода в гибком состоянии.

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

Когда делаешь на Unity игры для мобильных платформ, рано или поздно придется писать часть функционала на нативном языке платформы, будь то iOS (Objective C или Swift) или Android (Java, Kotlin). Это может быть свой код или интеграция сторонней библиотеки, сама установка может заключаться в копировании файлов или распаковки unitypackage, не суть. Итог этой интеграции всегда один: добавляются библиотеки с нативным кодом (.jar, .aar, .framework, .a, .mm), скрипты на C# (для фасада к нативному коду) и Game Object со специфичным MonoBehavior для отлавливания событий движка и взаимодействия со сценой. А еще часто требуется включать библиотеки зависимостей, которые нужны для работы нативной части.

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

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

Месяц назад Apple предупредила всех разработчиков, что с апреля все приложения, которые заливаются в App Store, должны быть собраны с использованием последнего iOS 11 SDK. О том, как правильно позиционировать контент, используя новый API, уже давно можно почитать в официальной документации и Human Interface Guidelines. А хорошими и подробными статьями об адаптации игр на Unity ни на русском, ни на английском языке нас не радуют. А так как в War Robots поддержка нового UI появилась с февральским релизом версии 3.6.0, я решил написать собственный гайд со скриптами и скриншотами.

Появилась необходимость сменить основной домен компании в G Suite с .ru на .com с сохранением всех данных, календарей, псевдонимов и доступов на сторонние ресурсы. Информации о переезде в интернете не очень много, а точнее, кроме справки самого Google, вообще ничего не нашлось, что и стало причиной создания этого how-to. Будет полезно, если кто-то решит повторить подобное.

Дело в том, что изначально в компании использовался домен pixonic.ru. Затем был добавлен псевдоним pixonic.com, но везде по умолчанию стояла почта в зоне .ru. А так как многие сотрудники компании ведут переписку с зарубежными коллегами и клиентами, было желание использовать международный формат. Для этого им приходилось заходить в настройки аккаунта, самостоятельно менять основной почтовый адрес и приводить подпись в соответствие с корпоративным шаблоном. Не все это делали (или делали, но через раз) и можно представить, какой беспорядок и путаница творились в ветках сообщений. Для внешних партнеров это выглядело еще менее презентабельно из-за разных подписей.

В общем, настал момент, когда было решено — вся переписка должна вестись с использованием почты pixonic.com. Задача упала на нас — системных администраторов.

В конце статьи есть ссылка на весь скрипт, поэтому в тексте будут лишь его куски.

— А у тебя какая идея игры?
— Хочу, чтобы все офигели, передать ощущение скорости, которая нарастает, пока у тебя мясо от костей не начнёт отлетать, и ты уже не понимаешь, сможешь ли с ней совладать, но все равно продолжаешь пушить как сумасшедший!
— Матч-3 что ли?
— Ага.

Из разговоров на PixJam.

Провели внутри компании первый Jam по созданию концепций новых игр и хотим поделиться впечатлениями. Идея заключалась в том, чтобы раздвинуть рамки и «заразить» креативом как можно больше сотрудников (в независимости от скилла в программировании или гейм-дизайне). Идея провести подобное мероприятие в формате Jam'a возникла у Игоря Клюкина — нашего СОО. Как показывает практика, такой формат в целом хорошо подходит для решения креативных задач.

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

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

Пару лет назад мы располагались в самом cost-effective (читай: «дешевом») дата-центре в Германии. Чтобы вы понимали условия — роутинг мог сбоить от стойки к стойке или внутри неё; свитч в стойке перегружался или зависал; сам дата-центр постоянно ддосили; жесткие диски выходили из строя; материнские платы и сетевые карты сгорали; сервера произвольно выключались, перезагружались, а сетевые кабели выпадали как осенние листья во время урагана.

Периодически, когда приходило время скейлиться горизонтально, в ДЦ еще и место заканчивалось, и нам предлагали другую локацию, в другом городе, что для наших условий (ограничения схемы данных, топология кластера и критичность времени ожидания клиента) было неприемлемо.

Наступила точка кипения и мы решили переезжать. Хотя в какой-то момент даже казалось, что дешевле нанять больше обслуживающего персонала, чтобы менеджерить ситуации в вышеупомянутом ДЦ. Но в итоге, чтобы «стало более лучше жить» — мы выбрали стабильность.
Выбор остановился на дата-центре в Голландии, в Амстердаме. А вот тут самое интересное: к тому времени у игры уже был приличный DAU, переезд нужно было осуществить онлайн, без даунтаймов, одновременно на обе платформы (Android и iOS). Мало того, мы получили фичеринг на Google Play, маркетинг еще и запустил рекламную кампанию. Как понимаете, дополнительного трафика стало очень и очень много.

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

HackerRank в этом месяце предоставили интересную аналитику на основе опроса 39 441 разработчика. В опросе поднимается много актуальных вопросов про состояние IT-рынка, востребованные качества среди разработчиков и то, что ищут программисты среди потенциальных работодателей. Отчет получился интересным, многим может быть полезно.

Под катом очень много картинок.

1. Пролог

Hello world

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

Мы запустили HackerRank в конце 2012, чтобы помогать разработчикам найти работу, которая будет им по душе. За эти годы мы сильно выросли — сейчас в нашем сообществе 3,2 млн человек и 2% всех новых наймов разработчиков в прошлом году были сделаны с нашей помощью.

И сейчас мы впервые провели опрос среди нашего сообщества разработчиков, чтобы разобраться в том, как именно они работают и как они этому научились: когда они впервые запушили код в репозиторий, как они научились кодить, расспросили о любимых языках программирования и фреймворках, узнали, чего они хотят от работодателей. А еще мы спросили HR-менеджеров о том, что именно они ищут в кандидатах на позиции разработчиков и о многом другом. Мы опросили 39 441 человека и готовы поделиться знаниями, которые получили в результате.

Вы знали, что 1 из 4 разработчиков научился кодить до того, как получил водительские права?

Надеемся, что наш доклад будет для вас полезным.

Вивек Равинскар, Co-founder/CEO HackerRank

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

Во-первых, от неудачной идеи будет не так жалко отказаться. А во-вторых, в погоне за перфекционизмом можно забыть о потребностях конечных пользователей или никогда не закончить работу даже над альфа-версией. Но что, если в вашу «глиняную» повозку стало набираться так много людей, что перестраивать её на ходу уже не кажется такой привлекательной идеей? Примерно это с нами и случилось.

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.

В марте 2017 года мы собрали небольшую команду и взялись за разработку нового перспективного проекта. Без особых деталей могу сказать, что задача стояла интересная и соблазнительная — мобильный, синхронный, командный PvP. Спустя 7 месяцев активной разработки мне захотелось рассказать коллегам из других проектов и отделов Pixonic технические детали и я подготовил для них презентацию, которая в дальнейшем превратилась в эту статью.

Как техлид команды, я расскажу, с какими задачами и проблемами мы успели столкнуться, как их решаем и почему. Мы используем итеративный подход добавления функционала в проект и в данный момент у нас реализованы: PvP на iOS и Android (обе платформы играют на одних серверах); набор персонажей, три десятка игровых механик, боты; матчмейкинг; набор мета-фич (кастомизация персонажей, прокачка и другие); решена задача масштабируемости на весь мир.

Итак, поехали.

Несколько лет назад появился прототип игры War Robots (тогда она еще называлась Walking War Robots). Это был первый опыт Pixonic в жанре тактического PvP, поэтому многие будущие проблемы были заложены в коде изначально. Но несмотря на ряд трудностей (популярность проекта стремительно росла, небольшая команда не могла полностью изменить архитектуру игры в краткие сроки), нам в итоге удалось свести к минимуму количество читеров, а также исправить другие недостатки оригинального кода. Расскажу немного подробнее.

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

Напомню, кластер будет размещаться на площадке хостера, логи будут собираться со всего мира по TCP, а среднее количество логов — около 1,2 Тб/день при нормальных условиях.

В настоящее время мы используем CentOS 7 и Graylog 2.2, поэтому все конфигурации и опции будут описываться исключительно для этих версий (в Graylog 2.2 и Graylog 2.3 ряд опций отличается).