Это иллюстративный сценарий планирования для независимого разработчика, а не история клиента или измеренный результат по ёмкости. Приложение ведёт учёт выдачи оборудования для небольшого клуба: аутентифицированный участник может видеть доступные предметы, создать выдачу и вернуть её. Запись важнее нарядной схемы развёртывания, поэтому первый дизайн должен делать неудачные записи и потерянные данные легко расследуемыми.
Выберите минимально полезную архитектуру
Используйте один процесс API, одну базу данных и обратный прокси для публичной конечной точки HTTPS. Держите базу данных доступной только через предусмотренный локальный или частный путь. Дайте приложению собственную идентичность в операционной системе с доступом к нужным ему файлам. Держите файлы развёртывания отдельно от постоянных данных, чтобы выпуск не заменял базу данных или загрузки.
Совместное использование одного экземпляра упрощает конфигурацию и расследование для первого развёртывания. Оно также привязывает компоненты к одной границе перезапуска, диска и отказа. Примите этот компромисс осознанно. Если приложению требуется независимое восстановление или база данных постоянно конкурирует с API, рассмотрите их разделение до того, как увеличивать всё сразу.
Заложите бюджет на пиковый момент
Не рассчитывайте размеры только для простаивающего процесса. Приведённый ниже рабочий лист использует вымышленные плановые допуски, чтобы продемонстрировать расчёт. Они не являются измерениями этого приложения, бенчмарками или минимальными требованиями. Замените их наблюдениями из вашей среды выполнения и базы данных, включая репрезентативное развёртывание.
| Совместное использование экземпляра | Плановый допуск | Что наблюдать |
|---|---|---|
| Операционная система и прокси | 300 МиБ | Обычная фоновая активность и журналирование |
| Процесс API | 350 МиБ | Репрезентативные запросы, а не только запуск |
| База данных | 400 МиБ | Соединения, запросы и работы по обслуживанию |
| Запас для развёртывания | 450 МиБ | Любой пересекающийся процесс или шаг сборки |
| Совокупный плановый конверт | 1,500 МиБ | Сравните с фактической доступной памятью |
The Начальный план сборки в настоящее время указывает 2 vCPU, 2 GB RAM и 50 GB SSD. Эти цифры делают его конфигурацией для изучения в этом рабочем листе, а не доказательством того, что стек поместится. ГБ в каталоге и показания МиБ в инструменте — разные единицы; проверьте фактические итоги системы. Оценка доступной памяти в Linux учитывает соответствующую высвобождаемую память, поэтому одного лишь низкого значения свободной памяти недостаточно для вывода о размере. См. объяснение ядра о 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 описывает отдельные логический, файловый и непрерывный архивный подходы; правильный выбор зависит от того, как вам нужно восстанавливаться. См. его обзор резервного копирования. Если загружаются фотографии предметов, включите эти файлы и связь с их записями в базе данных.
Выполните упражнение по восстановлению в отдельную тестовую базу данных и каталог. Найдите известный предмет и соответствующий ему файл, затем проверьте, что приложение может прочитать оба. Запишите выбранную резервную копию, временную метку данных, необходимые шаги и фактический результат. первое руководство по восстановлению развивает это упражнение. Необязательный выбор резервного копирования каталога не доказывает, что это восстановление на уровне приложения работает.
Примите следующее решение на основе фактов
Придерживайтесь простого дизайна, пока его измеренное поведение и требования к восстановлению подходят. Исследуйте остановленное приложение или предупреждения о ресурсах прежде чем предполагать, что больший план — это ответ. Выберите Малайзию, Румынию или Швейцарию для сервера, затем подтвердите распределение ресурсов, расположение резервных копий и объём услуг. Этот сценарий не устанавливает ни объекта, ни пропускной способности запросов, ни времени доставки.
Настройте сборку и просмотрите все параметры. Ссылка открывает стартовый план; проверьте выбранный период и любые сохранённые варианты перед продолжением. Получение платёжных данных не устанавливает приложение для выдачи оборудования.
Использованная документация
Основные ссылки для этой страницы. Проверьте документацию для версии, установленной в вашей среде.