Те, що я дізнався під час розгортання виробництва

Розгортання виробництва. Заключний етап кожного проекту. Коли вся напружена робота, яку ви вкладаєте з плином часу, починає використовуватися цільовою аудиторією. Це, звичайно, захоплюючий час, особливо коли ви є частиною процесу налаштування інфраструктури!

Раніше я був частиною процесів розгортання. Але цього разу я повинен був попрацювати над величезною системою з точки зору обсягу, стеку технологій та інфраструктури, що було спокусливою ескападою! Я відчув весь процес із перших вуст, і дізнався досить багато речей.

Ось список моїх знань, які я пам’ятатиму і застосовуватиму протягом своєї кар’єри розробника.

Два стовпи: Підготовка та планування⏱️

Само собою зрозуміло, що підготовка та планування повинні бути частиною будь-чого, що ви робите. Але коли справа стосується розгортання виробництва, це стає правилом. Це даність, імператив . Ви повинні знати тонкощі технологій, над якими ви працювали у своєму проекті. Вам також потрібно подумати про те, яка інфраструктура найкраще підходить для роботи різних типів систем.

Система, яку ми побудували, складалася з nodejs, MongoDB, InfluxDB, redis, asp.net та rabbitMQ як частини свого стеку технологій. Однією з основних вимог системи було обробляти величезний обсяг даних щодня. Таким чином, система мала працювати, маючи на увазі належну карту розгортання, яка чітко зазначала такі речі, як:

  • Яка система / технологія мала працювати на якій машині
  • Специфікації щодо кластеризації систем
  • Як усі ці автономні скриньки збиралися розмовляти між собою безглуздо.

Робити місцеві, мислити глобально?

Ну, це була порада мого архітектора проекту / друга. Я та деякі інші молоді розробники в команді не мали жодного досвіду впровадження такої величезної системи в нашій кар’єрі. Тож наш архітектор порадив нам створити ідентичну виробничу систему локально.

Це означало, що нам потрібно мати практичний досвід у всьому. Від кластерного середовища NodeJS (що складається з 8 кластерів) та налаштування декількох серверів MongoDB з готовою до виробництва інсталяцією Redis , до готових до виробництва конфігурацій pm2 та змінних середовища!

І ми все задокументували. Ми розробили всі виробничі установки на наших місцевих машинах, а потім протестували їх з кінця в кінець. Пізніше ми записали всі кроки, необхідні для досягнення кінцевої робочої інфраструктури локально на наших машинах. Ця практика допомогла нам знайти типові проблеми, що виникають під час налаштування інфраструктури, та способи їх подолання.

Ми записали всі вказівки, уроки та конкретні налаштування, які ми виконували, щоб система працювала. Це підвищило мою впевненість на кілька рівнів, і я відчув себе готовим розширити виробниче середовище для нашого застосування.

Документ, документ та документ !!?

Я знаю, я знаю. Про це вже було сказано багато. Будучи розробником, ви це досить чули. Ви, мабуть, не хочете чергової лекції про важливість документації. Тож я збираюся коротше, просто виділяючи точки:

  • Налаштування виробництва слід задокументувати на біти. Він повинен бути акуратним, надійним і зрозумілим.
  • Він повинен мати усі конфігурації системи, IP-адреси, технічні характеристики системи та інструкції з установки. А також все, що ви вважаєте досить важливим, про що ви або колега-розробник повинні знати.
  • Його потрібно оновлювати, коли і коли вносяться будь-які зміни у виробниче середовище системи.

Будучи людиною, досить часто можна думати так: «О! Я пам’ятаю це! " Повірте мені, ви не будете . Ніхто в історії розробки програмного забезпечення ніколи цього не мав (Гаразд, це може затягнути це занадто далеко, але ти розумієш.?)!

Документуйте всі дані та метадані навколо виробничих налаштувань. Ви пізніше подякуєте собі. Майбутні розробники, які будуть на вашому проекті, згодом подякують вам!

Моніторинг та реєстрація?

Під час розробки проекту порівняно легше боротися з помилками та помилками. Щось не працює? Лемме просто швидко увійдіть у поле розробника та поставте галочку. Ну, цього не відбувається на виробництві. Ви не можете увійти в систему, яка працює, і почати тикати навколо лише тому, що не розумієте, звідки проблема.

Налаштування належної системи моніторингу та реєстрації має важливе значення для забезпечення перевірки стану справної системи. Сьогодні на ринку доступні інтелектуальні системи моніторингу, які можуть надсилати вам звіти про частоту помилок, електронні листи із запланованими перевірками стану здоров’я тощо.

Ми вибрали Sumologic та DataDog як наших супутників при створенні системи реєстрації та моніторингу для нашої програми. Це було майже захоплююче, коли я міг зрозуміти проблему в системі, не роблячи “ssh”.

Декоративна система моніторингу значно сприяє закладенню міцної основи для вашого живого продукту . Не пропустіть це!

Фу! Ну, це обгортання! Які ваші висновки? Не соромтеся ділитися своїми знаннями, порадами чи вказівками в коментарях нижче!