Це ілюстративний сценарій планування для незалежного розробника, а не історія клієнта чи виміряний результат потужності. Застосунок обліковує позичання обладнання для невеликого клубу: автентифікований учасник може бачити доступні предмети, створити позичання та повернути його. Запис важливіший за вишукану діаграму розгортання, тож перший дизайн має робити невдалі записи та втрачені дані легкими для розслідування.
Виберіть мінімальну корисну архітектуру
Використовуйте один процес API, одну базу даних і зворотний проксі для публічної кінцевої точки HTTPS. Тримайте базу даних доступною лише через призначений локальний або приватний шлях. Надайте застосунку власну ідентичність операційної системи з доступом до потрібних йому файлів. Тримайте файли розгортання окремо від постійних даних, щоб випуск не замінював базу даних чи завантаження.
Спільне використання екземпляра робить конфігурацію та розслідування керованими для першого розгортання. Воно також прив'язує компоненти до тієї самої межі перезапуску, диска та відмови. Прийміть цей компроміс свідомо. Якщо застосунок вимагає незалежного відновлення або база даних постійно конкурує з API, розгляньте їх розділення перед тим, як збільшувати все одразу.
Бюджет на піковий момент
Не розраховуйте розмір лише для неактивного процесу. Наведений нижче робочий аркуш використовує вигадані планувальні запаси, щоб продемонструвати розрахунок. Вони не є вимірюваннями цього застосунку, бенчмарками чи мінімальними вимогами. Замініть їх спостереженнями зі свого середовища виконання та бази даних, включно з репрезентативним розгортанням.
| Робота зі спільним використанням екземпляра | Планувальний запас | Що спостерігати |
|---|---|---|
| Операційна система та проксі | 300 МіБ | Звичайна фонова активність і журналювання |
| Процес API | 350 МіБ | Репрезентативні запити, не лише запуск |
| База даних | 400 МіБ | З'єднання, запити та робота з обслуговування |
| Запас на розгортання | 450 МіБ | Будь-який процес або крок збірки, що перекривається |
| Об'єднаний планувальний обсяг | 1,500 МіБ | Порівняйте з фактично доступною пам'яттю |
The Початковий план Build наразі вказує 2 vCPU, 2 GB RAM і 50 GB SSD. Ці цифри роблять його конфігурацією для дослідження в цьому робочому аркуші, а не доказом, що стек підходить. Каталожні ГБ і показники МіБ інструмента — це різні одиниці; перевірте фактичні загальні показники системи. Оцінка доступної пам'яті Linux враховує відповідну reclaimable memory, тож сама лише низька вільна пам'ять не є вердиктом щодо розміру. Див. пояснення ядра щодо MemAvailable та посібник з вимірювання.
CPU та диск потребують окремих рішень. Записуйте тривалість запитів і очікування бази даних перед додаванням vCPU. Бюджетуйте диск для операційної системи, збережених випусків, зростання бази даних, журналів і тимчасової роботи з відновлення. Функція завантаження створює іншу проблему зі сховищем, ніж невеликий структурований запис; дайте їй обмеження розміру та рішення щодо збереження.
Знайте початкову вартість
Наведений нижче приклад використовує Build з його типовими ресурсами та без доданих повторюваних опцій. Його місячний проміжний підсумок становить $14.00 USD. Значення генеруються з поточного каталогу конфігуратора, тож таблиця цін відповідає оформленню замовлення.
| Період обслуговування | Перед збереженням | Збережено | Оплатити одноразово |
|---|---|---|---|
| 1 місяць | $14.00 | $0.00 (0%) | $14.00 USD |
| 3 місяців | $42.00 | $0.00 (0%) | $42.00 USD |
| 6 місяців | $84.00 | $23.52 (28%) | $60.48 USD |
| 12 місяців | $168.00 | $84.00 (50%) | $84.00 USD |
Шестимісячний або річний період знижує початкову загальну суму цього каталогу порівняно з оплатою недисконтованого місячного проміжного підсумку за ту саму кількість місяців. Це не додає ресурсів, не встановлює ціну поновлення й не робить неперевірену архітектуру придатною. Виберіть період, до якого можете зобов'язатися, перегляньте деталі послуги та оплати, і окремо передбачте кошти на домен, будь-які зовнішні послуги та мережеві збори.
Перевірте один повний запит
Перед відкриттям застосунку для його передбачених користувачів підтвердьте доступ до сервера та доступ для відновлення, встановіть підтримуване середовище виконання й запишіть випуск, який розгортаєте. Визначення служби має вказувати виконуваний файл, робочий каталог і користувача середовища виконання. Systemd Restart= параметр керує заданою поведінкою при збої; цикл перезапуску все одно потребує діагностики. Див. посібник зі служб та покрокового посібника з розгортання.
Спочатку перевірте локально, потім через справжнє ім'я HTTPS з іншого з'єднання. У Caddy автоматичне керування сертифікатами залежить від правильної конфігурації імені та робочого методу перевірки; звичайні HTTP- та TLS-ALPN-виклики потребують доступних вхідних портів 80 та 443 відповідно. Див. передумови Caddy HTTPS. Локальний успіх не може виключити проблему DNS або проксі, як пояснює посібник зі шляху запиту .
Зробіть перевірку програми конкретною: створіть одноразовий елемент обладнання, позичте його, переконайтеся, що другий запит бачить збережений результат, потім поверніть його. Перевірте авторизацію, а також просту кінцеву точку працездатності. Запишіть очікувані відповіді перед тестуванням і не додавайте облікові дані та дані учасників до журналів, якими ділитеся для усунення несправностей.
Доведіть невелике відновлення
Створіть резервну копію бази даних методом, що відповідає рушію та меті відновлення. PostgreSQL документує окремі логічні, файлові та безперервні архівні підходи; правильний вибір залежить від того, як вам потрібно відновлюватися. Див. її огляд резервного копіювання. Якщо завантажуються фотографії предметів, включіть ці файли та зв'язок з їхніми записами в базі даних.
Виконайте вправу з відновлення в окремій тестовій базі даних і каталозі. Знайдіть відомий елемент і відповідний файл, потім перевірте, чи програма може читати обидва. Запишіть обраний резервний метод, часову мітку даних, необхідні кроки та фактичний результат. перший посібник з відновлення розвиває цю вправу. Необов'язковий вибір резервного копіювання каталогу не доводить, що це відновлення на рівні програми працює.
Ухваліть наступне рішення на основі доказів
Дотримуйтеся простої конструкції, поки її виміряна поведінка та вимоги до відновлення відповідають. Дослідіть зупинену програму або попередження про ресурси перш ніж припускати, що більший план є відповіддю. Виберіть Малайзію, Румунію або Швейцарію для сервера, потім підтвердьте розподіл ресурсів, місце резервного копіювання та обсяг послуг. Цей сценарій не встановлює жодних зручностей, пропускної здатності запитів або часу доставки.
Налаштуйте Build і перегляньте кожну опцію. Посилання відкриває початковий план; перевірте вибраний період і будь-які збережені вибори перед продовженням. Отримання платіжних даних не встановлює програму позики обладнання.
Використана документація
Основні посилання для цієї сторінки. Перевірте документацію для версії, встановленої у вашому середовищі.