Інфраструктура онлайн ігри

image
Привіт, мене звуть Олександр Зеленін я на дуді грець веб-розробник. Півтора року тому я розповідав про розробку онлайн ігри. Так ось, вона трохи розрослася… Сумарний обсяг вихідного коду перевищив «Війну і мир» вдвічі. Однак у даній статті я хочу розповісти не про коді, а про організацію інфраструктури проекту.
Зміст
  1. Я хочу спати спокійно!
    1.1. Планування стабільної архітектури
    1.2. Вибір сервера/дата-центру
    1.3. Балансування навантаження
    1.4. Моніторинг всього і вся
    1.5. Зв'язаний проект — окремий сервер
    1.6. Вибір сервісу служби підтримки
  2. Як перестати турбуватися і почати розробляти
    2.1. Де зберігати фотографії?
    2.2. Налаштування домашньої мережі
    2.3. Стратегія резервного копіювання та архівації
    2.4. Свій dropbox
    2.5. Віртуальні машини
    2.6. Jira — Confluence — Bitbucket — Bamboo
  3. Що в підсумку?
  4. А що там з грою?
Зміст не відображає хронологію, хоч де-то вона і буде збігатися. Це не how-to, не мануал і подібне. Це оглядова стаття, покликана дати уявлення про те, що ж криється за невеликим проектом.
Практично кожен з пунктів має під собою досить велику історію (я навмисно сильно скорочував все) і тягне на окрему повноцінну статтю.
У разі, якщо ця стаття виявиться затребуваною — поступово напишу цикл, що розповідає, як вибирати і настроювати ті чи інші інструменти.
Читати можна в довільному порядку.
Важливими факторами кінцевої інфраструктури були: надійність та вартість підтримки.
Забезпечення всього цього нам обходиться менше ніж у 15 тисяч рублів на місяць, більшу частину з яких з'їдає VPC. А якщо пожертвувати стабільністю самого продукту і використовувати більш дешевий дата-центр, то можна було б вкластися в 3 тисячі. Дані цифри враховують амортизацію і заміну несправних елементів.

Я хочу спати спокійно
Після чергового падіння проекту в 2 години ночі і відновлення працездатності до ранку стало зрозуміло, що так тривати більше не може. І це розповідь про правій частині схеми.
image

Планування стабільної архітектури
Хотілося зробити так, щоб незалежно від того, що станеться, можна було спокійно спати і не хвилюватися, що проект раптом стане недоступний з будь-якої причини, а потім вже в спокійній обстановці неспішно все лагодити. Принагідно хотілося б додати можливість вільного горизонтального масштабування.
Класичний рецепт — це запускати кілька екземплярів програми на різних серверах і на рівні вище направляти користувача на працююче. Точкою синхронізації є база даних, так що вона повинна володіти не меншою стабільністю, ніж сам додаток.
1) База даних: MongoDB
Запускається мінімум на двох різних фізичних серверах. Одна є основною, інші — вторинними.
Т. к. бази і програми запускаються на різних серверах і є шанс довільній недоступності, необхідно при відновленні зв'язку досягти повної коректної синхронізації даних. Для цього у MongoDB є спеціальний механізм — для обрання сервера як основного необхідна зв'язок як мінімум 50% + 1 сервера. Також ми хочемо, щоб у цьому голосуванні брали участь ще і сервера з додатками — внаслідок того, що спочатку планується всього 2 сервера бази (50% + 1 від 2 це ті ж самі два, тобто недостатньо для голосування). Для цього у MongoDB є спеціальний спосіб запуску екземпляра БД без самих даних, а тільки в режимі голосування (Arbiter). На кожен сервер з додатком додатково ставиться такий Arbiter.
Додатковий Arbiter запускається на сервері резервного копіювання, розташований поза дата-центру.
Разом маємо 2 сервера БД онлайн, і 5 арбітрів (сервер БД теж їм є).
Тепер будь-який примірник БД не відвалився — інший стає основним, а відвалився переходить в read-only до відновлення зв'язку. Після відновлення зв'язку та повної синхронізації він знову стає основним. Якщо з якоїсь причини відвалюються другий сервер і сервер резервного копіювання — всі бази переходять в режим read-only.
Також необхідний моніторинг (спостереження за працездатністю кластера): що він доступний, що дані на місці, що резервна копія в порядку, і так далі.
2) Додаток, Nodejs
Аналогічно попередньому — мінімум два різних фізичних сервера. Всі додатки рівноправні, т. к. точкою синхронізації є дані.
Цього вдається домогтися, т. к. програми самі по собі не зберігають жодних стану, так що навіть якщо один користувач приєднається до різних екземплярів, це ні на що не вплине.
На кожному сервері знаходяться мінімум 2 примірника програми, які моніторяться і балансуються за допомогою pm2 & nginx.
Зверху цього — моніторинг працездатності.

Вибір сервера/дата-центру
Перед вибором необхідно визначити, скільки ж ресурсів споживає наш додаток.
оскільки я використовую Meteor, то вибір тестування навантаження упав на MeteorDown. Перевіряти буду на домашньому сервері, виділивши 100% ресурсів під програму.
Сервер: Intel® Xeon® CPU E5-1620 v2 @ 3.70 GHz (6 ядер), 32гб ECC DRR3 пам'яті.
Тестувати він буде сам себе, тобто мережа не враховується. Так, все це дає спотворення, але прийнятні.
Пишуться сценарії поведінки користувачів, генеруються набори даних. Запуск! Навантаження поступово зростає, але при цьому час відповіді на методи тримається стабільним. Тисяча онлайн, дві, три, п'ять, шість. Поступово починає рости час відповіді. Сім — час відповіді перевищує півсекунди. Вісім — час відповіді стає неприйнятно великим (10+ секунд). Вперлися в CPU.
Шість тисяч — це було в десять разів вище, ніж піковий онлайн. Значить, орієнтуємося на в 2-4 рази менші параметри, але закладаємо масштабування.
1) Закінчення закритого бета-тесту
Під час бета-тесту реєстрація була обмежена, відповідно, і онлайн теж. Архітектура, описана вище, ще навіть не було в проекті, оскільки до цього моменту все було досить стабільно. У цей час усі додаток працювало на одній KVM VPS'ке (4 ядра 2.2 GHz, 4 гб пам'яті).
До старту бети було вирішено переїхати (у них же) на «Резервний сервер» з вартістю в два з половиною рази вище за аналогічні характеристики, але ніби як купою гарантій, що воно все суперстабильно і круто.
З запуском відкритого бета-тесту ми почали приймати платежі, так що обязательва наші зросли і простоїв не можна було допускати.
2) ОБТ
Запуск був цілком успішний, і ніби як навіть все працювало непогано. Як раптом через пару тижнів, вдень мені дзвонить друг і повідомляє, що сайт недоступний. Окей, біжу додому. Бачу, що VPS'ка лежить від слова зовсім. Намагаюся перезапустити — безуспішно. Пишу в техпідтримку — мені відповідають: крашнулся диск відновлення через пару годин.
ШТА? У сраном описі «резервний сервер» мене запевняли, що у них сервер і СГД розташовуються окремо, там все супер дублюється і що буде 100% доступність.
Уточнюю дані моменти і мені кажуть, що компенсують (та-да-да) 30 рублів! За 6 годин простою. Відмінно.
Окей, припустимо, мені реально не пощастило і сталося якась екстраординарна подія. Уточнюю частоту подібних подій і шанси виникнення в майбутньому — запевняють, що все буде відмінно. Через два дні — падіння в 4 години ночі. Крашнулся диск, але в цей раз ще й з втратою даних :-)
3) Перший переїзд
Спасибі бекапам, втрата склала добу (на той момент був бекап раз на добу), а за рахунок історії транзакцій у партнера відновити платежі не склало праці. Терміново шукаю альтернативу. Знаходжу, проплачиваю і переїжджаю.
Через три тижні — ситуація практично аналогічна. М-да. Дуже нетривіальна ситуація була для мене.
4) Tier 3, DataLine
Вивчаю тему глибше: як же дорослі дядьки вирішують такі питання? Відчуваю, і нам настав час подорослішати.
Проробляю схему вище, шукаю максимально надійних хостерів і приходжу до того, що вибір в РФ не такий великий. З маленькими проектами взагалі майже ніхто з великих гравців працювати не зацікавлений, крім DataLine з їх спрощеним варіантом CloudLite.
Домовляюся з підтримкою про тестовому періоді і розгортаю все як задумав. Переносимо домен.
image
Фух, начебто працює. Але якось повільно. Запити повертаються близько 300мс. Але при цьому не було ніяких стрибків навантаження, тобто це було стабільні 300мс.
Вирішено було залишити так і поспостерігати кілька днів. Загалом стабільність радувала, але ось загальмованість дратувала.
Почав розбиратися в чому справа, і відразу стало видно, що вузьким місцем є диск — у нас дуже ретельно записується активність користувача чергу запису була завжди. Виявилося, що в рамках CloudLite надається тільки VSAN диски і переїзд на SSD для усунення проблеми не можливий.
Альтернативою було запустити inmemory версію mongo з реплікацією вже на диск, але тут було кілька але: mongo надають повноцінну версію in-memory тільки для ентерпрайз (па-ба-ба), 15 тисяч доларів в рік за один сервер. У моєму випадку це було зовсім невиправдано, особливо в порівнянні з альтернативними рішеннями для поточного рівня (переїзд на SSD). Ще був хитрий варіант із створенням memory розділу в linux і розгортанні БД туди, але я не любитель такого роду хаків, а прорахувати можливі проблеми подібного підходу було проблематично.
загалом, треба було переїжджати на SSD. У DataLine це доступно тільки вже з укладенням договору і на іншій платформі.
На ній мені також надали тестовий період. Розгорнув там все заново, в цей раз задокументировав всі кроки для подальшої автоматизації. Повторний перенесення домену… Ура! Все працює швидко і як треба.
Постфактум хочу сказати, що дуже радий цьому переїзду, т. к. жодного простою з вини DataLine не було (більше 8 місяців).
Був один цікавий простій через глюка DNS (майстер зону я хостил все ще у першого хостера, т. к. там жили всякі інші дрібні проекти), який раптово відкотився на кілька місяців. Ну тобто просто став DNS повертати адреси старого сервера і все.
Відловити цю помилку було дуже складно, тому що у кого-то працювало, а у кого-то немає (у мене спочатку працювало). Але після скидання кешей DNS на роутері відразу стало все видно.
У підсумку домен теж був перенесений на DataLine і поки (тьфу-тьфу!) працює без проблем.

Балансування навантаження
Отже, тепер у нас кілька серверів і ще більше примірників додатків і треба якось більш-менш рівномірно розподіляти користувачів по ним, щоб досягти максимальної продуктивності.
Задача розбивається на два кроки — балансування до сервера і балансування в межах сервера.
1) Балансування до сервера
Вирішується на рівні дата-центру. Всі сервера з додатками заносяться в пул, вибір же самого сервера йде за двома параметрами: перше — це cookie, а якщо їх немає, то IP hash. Ідея в тому, щоб запити від одного користувача йшли завжди на один і той же сервер, так кешування буде працювати більш ефективно.
image
оскільки всі сервера програми рівноправні, то і вага ставиться однаковий. Додаємо перевірку доступності 5 секунд.
Готове.
Тепер запити користувачів досить добре розподіляються на сервера, а в разі, якщо один із серверів перестає бути доступний, то в течії 5 секунд користувача переводять на інший.
2) Балансування в межах сервера
Тут є кілька варіантів. Т. к. я використовую pm2 для запуску nodejs процесів, то можливий варіант запуску необхідної кількості примірників програми (по числу ядер) в cluster режимі, який вже буде разруливаться нодою. Мінус цього підходу в тому, що механізм sticky sessions не працює, але оскільки ми тримаємо socket підключення, то переключення на інший екземпляр програми можливо тільки у випадку обриву. В нашому випадку це не доставляє проблем.
Другий варіант — це запуск додатків в fork режимі на різних портах і проксіювання на них через nginx. Плюсом тут є те, що nginx може ще і статику роздавати, так SSL сертифікат (SSL досі не підключив, до речі, але скоро дійдуть руки).
Прописуємо в конфіги порти додатків, готово.
3) Перевіряємо
Перевіряю навантаження на серверах і бачу, що вона рівномірно розподілилася. Відмінно!

Моніторинг всього і вся
Як і у всіх завданнях спершу намагаємося зрозуміти, які дані ми хочемо збирати:
  1. Дані про працездатність програми, навантаження на нього, помилки і так далі.
  2. Дані про працездатність бази даних, розмір даних, реплікація, лад і так далі.
  3. Дані про користувачів, пристрої входу, дозволу екрану, джерела переходів та інше.
  4. Дані про дії в грі.
1) Kadira.io
По-перше, хочу відзначити, що цей сервіс, на жаль, скоро припинить своє існування — він виявився нерентабельним. Але розробник обіцяв видати вихідні коди і інформацію, як розгорнути все це у себе. Так що, мабуть, інфраструктура проекту очікує поповнення.
image
нема чого Винаходити велосипед, коли є чудові готові інструменти. Інтеграція з додатком представляє з себе лише встановлення модуля з пакету і прописування двох рядків в конфіги. На виході отримуємо моніторинг ресурсів, профілювання важких запитів, монітор поточної активності, аналізатор помилок і ще купу всього.
2) MongoDB Cloud
image
Інтеграція не набагато складніше, але ставиться на сервера БД, а не програми, відповідно. Ставимо модуль, запускаємо watch'ег.
Тут же на місці моніторимо ресурси сервера БД, бачимо час запитів, лаги реплікації, поради оновити БД.
Досить крута штука тут — це моментальне інформування у разі недоступності БД на пошту.
3) Яндекс метрика
image
Інтеграція трохи складніше, ніж Kadira, тому що крім установки модуля необхідно модифікувати додаток, щоб воно інформувало скрипт метрики про переходи по сторінках (в SPA не завжди зрозуміло, які монітори треба моніторити, бо зроблено так). Додаємо потрібний код в роутер, і готово: стать, вік, переходи, відвідування, пристрої і так далі. Все в одному місці. Зручно!
4) Дії в грі
Записуються в базу даних програми, само собою. Згодом можна налаштувати, щоб старі дані, необхідні лише для аналізу, переносилися на окремий сервер. Для подібного у монги теж є інструменти.

Зв'язаний проект — окремий сервер
З часом проект обростає різними доповненнями. Наприклад, у нас була газета, яку зробили самі користувачі. Спочатку вона була створена і розміщена десь у себе одним з гравців, але потім різко зачинилися і гравець пропав. Було вирішено розгорнути в себе аналог на wordpress і дати можливість модераторам публікувати там статті на околоигровые теми.
image
Само собою, на наявному сервері можна запускати подібне хоча б з міркувань безпеки.
Другорядні сервера було вирішено розмішати у більш дешевого провайдера, т. к. їх доступність некритична.
Хоча все одно був обраний хостер, який орендує потужності в тир 3 дата-центрі.

Вибір сервісу служби підтримки
Необхідно також публічне місце для збору інформації про помилки. Оптимальним варіантом бачилася можливість збору пропозицій від гравців і голосування по них. Зовсім опціонально — публікація логів змін тут же. Дуже бажана була можливість безкоштовного розміщення для маленьких компаній або до будь-якого ліміту.
Я перепробував близько трьох десятків систем і в підсумку зупинився на helprace.
image
Прямо ніби під запит зроблено. Взагалі, у них є інтеграція з зовнішніми логіном, але тільки в платній версії. Оскільки однією з цілей було заощадити на вартості утримання, реєстрацію у нас система вимагає окремо.
Аудиторія завжди дуже радує — сотні повідомлень про помилки, гори пропозицій та побажань. Іноді навіть проскакує стримана похвала грі і розробникам :-)

Як перестати турбуватися і почати розробляти
А це розповідь про лівій частині схеми.
image

Де зберігати фотографії?
Трохи дивний заголовок в рамках даної статті, але саме це питання спричинило за собою поява домашнього сервера.
Перед поїздкою до Індії прямо в останній день смикнув мене чорт сходити почистити матрицю на Canon D350 в авторизований центр. Там «майстер» брудної хреновиной подряпав матрицю в непотріб. До літака було менше 8 годин, так що часу на розборки не було, треба щось вирішувати. За відгуками знайшли гарну крапку на вокзалі, приїхали туди, віддали майстрам (втрачати вже нічого). Хлопці покрутили, запитали: «що з матрицею сталося :-)»?.. Почистили якось хитро і начебто стало навіть прийнятно (фотографії з Індії зроблені саме на цю камеру), за що їм спасибі.
Але ось по приїзду додому знімати я став мало, т. к. всякі неприємні плями на фотографіях були і псували навіть дуже вдалі кадри.
Настав час брати нову камеру, та вже по-серйозному відразу — FullFrame. Спочатку вибір припав на Nikon D800. 37 мегапікселів… Мамо, це ж скільки raw важити буде? 50-100 мегабайт! (В результаті, до речі, взяв D750 з набагато більш приємним вагою raw'ок.)
Мені подобається зберігати архів (видаляючи тільки дублі і зовсім невдалі кадри), і з часом стало ясно, що просто домашнього компа мало. При такій вазі це 12000 фоток на терабайт. Здається, що це багато, але насправді це кілька років не дуже активної зйомки. Для розуміння — за минулі роки архів перевалив за 50 тисяч фотографій. І так, іноді для деяких завдань я повертаюся до свого фотоархіву, щоб знайти потрібну.
Трохи погугливши, я зрозумів, що NAS придумані саме для цього. Потім натрапив на ZFS і зрозумів, що він чудово виявляє проблеми, які у мене вже відбувалися кілька разів:
image
(Забавно, що картинку з помилкою завантажити так і не вдалося, довелося робити скріншот і вирізати.)
Відстежити такі проблеми важко. Вони ще цілком успішно могли полетіти в бекап і продублироваться в рейді.
Мене врятувало те, що NASы ніфіга не були доступні в моєму місті (Калінінград), хоча зараз ситуація вже трохи краще.
Після дуже довгого аналізу (в цілому на рішення завдання в заголовку пішло більше 200 годин) було вирішено зібрати свій сервер і поставити туди FreeNAS.
image
загалом-то, збирав відразу надовго, і потенційно система розширюється до петабайта сховищ і половині терабайта оперативки. На поточний момент там усього 12 терабайт місця і 32гб пам'яті. Загальна вартість вийшла порівнянно або дешевше готових NAS рішень (від 4 дисків), при цьому гнучкість і потенціал набагато вище.

Налаштування домашньої мережі
Тут же відразу стало очевидно, що старенький dir-300 просто не дозволить мені комфортно працювати з сервером. Навіть якщо взяв і пішов трохи пофоткать, зняв 200 кадрів і почав скидати (200 * ~75) 15гб, то сам процес копіювання зайняв би близько 20 хвилин! Подумаємо, яка швидкість нам потрібна? Судячи з тестів, диски в планованої СГД WD Red видають 100-150 мегабайт в секунду, значить, гігабітного каналу нам вистачить при ексклюзивному використанні. А якщо відразу два користувача? Наприклад, хтось із родини вирішить фільм в HD 4k подивитися (з іншого фізичного диска)? Значить, до сервера повинно йти мінімум 2 каналу.
Після аналізу ринку стало ясно, що треба брати MikroTik. Вибір припав на CRS109-8G-1S-2HnD — вісім гігабітних портів і неймовірна можливість конфігурування.
Безперервність доступу
Мене дуже засмучувало, коли недоступність мережі з вини провайдера (Привіт, Білайн!) позбавляла мене можливості працювати. (Ну так, є ще мобільний інтернет, але це взагалі навіть близько не комфортна робота, особливо при тому, що він тут ніфіга не ловить і теж вимагає окремого рішення у вигляді зовнішньої антени.)
image
У нашому під'їзді працюють два провайдера — Білайн і Ростелеком. Спершу необхідно було налаштувати їх окремо, з чого я й почав.
Ох вже ці танці підключення Білайну на роутерах микротик! З бубном і танцями вдалося підключити, але нервів і часу з'їло багато. Плюс таки потрібно іноді ручна донастройка, т. к. рішення з постійно запущеним скриптом на роутері мені не подобалася від слова зовсім. Білайн в під'їзді, до речі, теж з микротика все роздає, що було дуже дивно.
А Ростелеком тягне оптоволокно до квартири (Вила цьому маркетологу!), так що без додаткового роутера не обійтися. Ну а роутер пов'язати з микротиком взагалі проблем не склало, оскільки, по суті, це просто мережу.
У Білайну за додаткову плату був придбаний (ще давно) зовнішній IP, який я завжди використовував в якості одного із засобів авторизації для доступу до внутрішніх ресурсів.
А ось для того, щоб це все запрацювало разом і одночасно, довелося підтягнути знання мереж і пакетів. Для більш-менш простий налаштування і розуміння, що відбувається, раджу ознайомитися з презентацією Bandwidth-based load-balancing with failover. The easy way.
Публічний доступ до внутрішніх ресурсів
На сервері будуть якісь ресурси, доступні з зовнішньої мережі. Як цього домогтися? Як згадував вище, у мене є зовнішній IP. На зовнішній IP посилається універсальний піддомен виду *.home.domain
Є кілька варіантів розв'язання: layer 7 або по порту.
Спочатку я налаштовував його з використанням layer 7 на роутері, перевіряючи що ж там за зірочкою і направляючи куди треба, але швидко з'ясувалося, що подібне використання дуже сильно навантажує процесор роутера. З урахуванням того, що ресурси будуть використовуватися лише невеликим колом осіб, вирішено було використати дешевшу адресацію по портах.
image
Прописуємо правило в фаєрволі, що дозволяє підключення на певні порти на зовнішній IP, додаємо в NAT правило-зв'язок з внутрішнім ip та портом… Працює! (До речі, при роботі двох підключень необхідно, щоб відповідь йшов через того ж провайдера, на який прийшов запит. Це називається sticky connections і описано в тій самій презентації.)
Повний доступ
Припустимо, що ми їдемо на якийсь час в іншу країну. Як отримати повний доступ, як ніби я перебуваю всередині мережі? Звичайно ж, потрібен VPN.
На роутері запускаємо сервер VPN, додаємо його в bridge, створюємо користувача — готово. Без якого-небудь додаткового ПЗ створюється підключення.
image

Стратегія резервного копіювання та архівації
Почнемо з поділу цінності збереженої інформації. Виділимо три градації:
1) Легко відновлювана інформація (музика, фільми).
2) Некритична, але неприємно втрачати (фотографії).
3) Важлива незамінна інформація (робочі файли, резервні копії).
Спочатку я брав 4 диска якраз під різні типи: часто використовувана інформація (media), фото (photo), робочі файли (work), бекап (backup).
Перший шар:
Налаштовуємо створення щоденних знімків для розділів work і деяких підрозділів media.
Створюємо реплікації знімків на розділ backup в окремі підрозділи.
Для розділу photo тимчасово використовуємо схожу стратегію, поки диск backup заповнений менш ніж на 50%. Після заповнення диска стратегія буде переглянута на користь перенесення тільки повнорозмірних jpg для економії місця. У цьому випадку фотографії залишаються, але втрачається можливість повноцінної постобробки.
Для більшої частини media резервне копіювання не настроюється, т. до. все відновлюється з відкритих джерел.
Другий шар:
Створюємо jail, даємо йому read-only доступ до розділу backup. Налаштовуємо програму для копіювання Amazon Glaicer на збереження знімків work та інших важливих, а також на збереження jpg'ів фотографій раз на тиждень.
Третій шар:
Раз в місяць робиться повне копіювання на зовнішній жорсткий диск, після чого останній кладеться на полицю в далекій від сервера кімнаті квартири. Всього таких диска два — вони чергуються. Тобто в архіві я зберігаю тільки два останніх місяці. Архів, у даному випадку, використовується тільки в разі втрати інформації.
Що маємо в підсумку? Щоб втратити важливий дані, треба дуже постаратися. Файли зберігаються мінімум в 5 примірниках: оригінал, бекап, глейсер і два архіву.
При цьому фактично займається не багато місця, тому що ми грамотно вибрали, що саме зберігати.

Свій dropbox
Зібравши таку махину, було б недоглядом не надати доступ близьким і друзям для безпечного складування файлів. Само собою, одне з застосувань — це робота з колегами над проектом. Owncloud — наше рішення.
image
Створюємо jail і встановлюємо по інструкції. Пробрасываем в jail зовнішній розділ для зберігання файлів резервної копії мета-інформації. Налаштовуємо резервне копіювання owncloud в проброшенный розділ.
Додаємо правила в роутер для доступу ззовні. Створюємо користувачів. Збереження файлів гарантуємо схемою вище.

Віртуальні машини
Потрібна можливість легко розгортати тестові оточення, робочі простору, різні інструменти.
Virtualbox — простий і знайомий усім інструмент відмінно підходить. А ще встановлюється в кілька кліків, т. к. готовий шаблон для jail phpvirtualbox вже вшитий під FreeNAS.
Пробрасываем кілька робочих розділів в virtualbox так, щоб вони були доступні як мережевий ресурс від freenas, а не від машин окремо, для зручності роботи.
Створюємо першу машину, на яку встановлюємо ту ж саму ОС, що і буде на бойовому сервері, намагаючись налаштувати максимально схоже. Ставимо туди git, nodejs та інше, що необхідно для функціонування проекту. Розгортаємо проект, запускаємо, перевіряємо роботу. Все ок? Зупиняємо машину, створюємо образ — тепер ми можемо його використовувати, щоб швидко створювати додаткові тестові оточення для нас або співробітників в один клік.
Тут можна розповісти про чудовий Docker, але в мене як-то історично склався суто негативний досвід роботи з ним. Сам жодного разу не налаштовував, але щоразу, коли приходив у проект і говорили: «У нас тут Docker, розгорнути оточення — справа півгодини», в результаті все затягувалося в кращому випадку дня на три, а потім і самі розробники зізнавалися, що докер у них ніколи не працював. Повторюся — ймовірно мені просто не щастило в цьому плані, і рано чи пізно хтось мене таки вразить його використанням, але поки що у мене і так реально розгортка в 1 клік :-)

Jira — Confluence — Bitbucket — Bamboo
Спочатку для планування і простого взаємодії ми використовували RealtimeBoard, але він досить швидко розрісся. Необхідна була платформа для постановки і ведення завдань.
Спершу у нас з'явився GitLab, в якому є можливість ведення завдань. Через якийсь час стало ясно, що банально станів завдання недостатньо для зручної асинхронної роботи та взаємодії один з одним без постійного смикання.
Я завжди думав, що Jira і весь пакет коштує якихось там тисяч доларів, і витрачати такі суми для ще незапущенного проекту в мої плани ніяк не входило. Але абсолютно випадково натрапив на те, що для команд до 10 осіб, кожен з продуктів коштує всього 10$. У результаті всього за 60$ був узятий повний комплект інструментів.
Jira
І в цей момент я зрозумів, що не дарма у великих компаніях є окрема посада — «жировод».
Для конфігурації запиту необхідно прописати хрінову купу параметрів на більш ніж 20 екранах.
Запит — це коли ви тиснете «Створити нове завдання». І ось для типу, наприклад, «Помилка»:
image
1) Створюємо бізнес-процес, називаємо його «Помилка».
2) Створюємо 6 статусів всередині: Відкритий, В процесі, Не відтворюється, Перевірка коду, Очікує вливання в майстер (попадання в майстер у нас означає выкатку на продакшн), Готово.
3) Кожному статусу проставляється одна з категорій: Зробити В процесі, Виконано.
4) Створюються необхідні переходи між статусами. Перехід може мати: окремий екран (з'являється, коли ініціюємо його вручну), властивості, тригери, умови, валідатори, post-функції. В даному прикладі 10 переходів.
5) Більшість переходів мають свій екран: при створенні завдання заповнюється інформація про завдання, коли завдання береться в роботу, можна проставити оцінку часу і доповнити інформацією, якщо не вдалося відтворити — пояснюються умови або причина (наприклад, вже виправлено в іншому місці).
6) На деякі переходи налаштовуються права, щоб тільки тимлид проекту міг їх робити (наприклад, влити в майстер).
7) Деякі переходи тільки автоматичні. Наприклад, «вмерджено в dev» ініціюється через тригер від bitbucket, коли гілка, в якій був отримати з тегом поточної задачі, вмерджена в dev. Для переходу в статус «перевірка коду» необхідно створення pull request'а в bitbucket'е з гілки з потрібним комітом.
8) Створюється тип запиту — «Помилка».
9) Тип запиту «Помилка» поміщається в схему типів запиту.
10) Створюється схема бізнес-процесу, наприклад, «Розробка ПЗ».
11) Бізнес-процес «Помилка» поміщається в схему бізнес-процесу зі зв'язком з типом запиту «Помилка».
12)…
13) ???
999) Profit!
Я написав тільки частина етапів. Насправді їх набагато більше :-) Хоча результат, у підсумку, того коштує. Правельна система прав, автоматичні переходи і економія часу.
Confluence
Ось тут все відчутно простіше. Єдине, що програму треба було пов'язати з основним сервером Jira, щоб звідти і управляти всіма правами.
У цілому це досить затишний текстовий редактор, інтегрований з Jira. Безліч дій викликає автоматичне створення сторінок в ньому з купою інформації. Наприклад, при закритті спринту в Jira автоматом створюється ретроспектива з інформацією по закритим завдань і витрачених ресурсів. Зручно!
image
Також використовується для ведення документації проекту.
Bitbucket
Git репозиторій, Код рев'ю і все в такому дусі.
Встановлюємо, інтегруємо з Jira, пов'язуємо з відповідним проектом.
Налаштовуємо protected гілки master і dev. Забороняємо force в них, забороняємо вливши без перевірки коду мінімум 1 учасником проекту. Вливати в майстер може тільки власник проекту. Улиття заборонено, якщо не пройдені тести.
image
Bamboo
Після Gitlab CI відчуття було приблизно таке ж, як при переході на Jira — ніби сів у зореліт.
Купа непотрібних, на перший погляд, налаштувань, але, по факту, після установки цей інструмент стає ультимативною.
Наприклад, тепер з допомогою нього я можу з нуля розгорнути ще один інстанси програми або бази даних в 1 клік, вказавши логін і пароль від цільового сервера.
Налаштовуємо необхідні тригери: на пуш будь-якої гілки запускаємо тестування коду, на пуш в dev запускаємо додатково деплой на stage сервер і проганяємо додаткові тести, при пуше в master запускаємо деплой в продакшен, тести, перевіряємо, що деплой успішний, а в разі провалу випробовуємо до попередньої версії. Задоволений :)
Інтеграція Slack
Ми в команді використовуємо Slack для спілкування з робочих питань, т. к. він цілком зручний для подібних завдань і надає багато різних зручних інструментів.
Однією з його фішок є інтеграція зі сторонніми сервісами. Хочеться, щоб важлива інформація лилася в окремий канал, інформація по билдам — ще один. Нотифікацію каналах відключаємо, щоб не відволікало зазря. Запушили код, глянули в слак → бачимо результати тестів. Зручно. Откомментили твоє завдання? Слакбот вже стукає до тебе.
image
Звичайно ж, вся важлива інформація приходить на пошту, але можливість подивитися всі комплексно за день в одному місці економить якийсь час.

Що в підсумку?
У підсумку можна спокійно спати, т. до. у разі різних непередбачених ситуацій всі важливі системи продовжують працювати, а вже якщо щось зовсім незрозуміле станеться, то як мінімум завжди є можливість відновити всі втрачені дані.
У нас є надійне мережеве сховище. Користувачі задоволені стабільністю і швидкістю роботи. Ми знаємо, що відбувається на всіх вузлах системи і можемо їх незалежно покращувати.
У разі необхідності ми можемо швидко нарощувати потужності, просто додаючи сервера в пару кліків.
Ми можемо обслуговувати запити користувачів (помилки, ідеї, пропозиції, питання), і бути впевненими, що нічого не буде втрачено або забуто. Ми бачимо темп нашої роботи і можемо коректно її планувати. Процес розробки влаштований так, що код перевіряється кілька разів, у тому числі і живою людиною.
Ми можемо вводити нових членів команди і бути спокійні — їх дії нічого не зламають.

А що там з грою?
А гра все ще в стадії відкритої бети, і сам геймплей поки далекий від поточних планів, але ми до них рухаємося. То, що виходить, нам дуже подобається. Сподіваємося, що і гравцям теж :) Зараз йде активний редизайн, чому деякі екрани трохи поїхали, зате інші сильно краще того, що було раніше.
image
Чесно кажучи, я думав, що це буде зовсім невелика оглядова стаття, а вийшло ось воно як.
Повторюся — абсолютно кожен з пунктів гідний статті (або навіть циклу) аналогічного об'єму.
Як тільки з'явиться час і відповідний настрій — все оформлю. Прошу вибачити за деякі неточності — багато речей писалися по пам'яті, а часу пройшло вже багато. При підготовці докладних статей вже будуть точності :)
Ну і, якщо дочитали до кінця, то ви — молодець. Спасибі за це.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.