Первый VPS после покупки: что настроить до запуска сайта

Проверьте доступ и способ восстановления

Убедитесь, что сервер выдан в нужном регионе, с согласованными ресурсами и выбранной операционной системой. Сохраните идентификатор услуги, её назначение и ответственного. Проверьте, кому принадлежит кабинет, кто продлевает аренду и куда приходят уведомления.

До изменения SSH найдите консоль или другой способ восстановления у провайдера. Уточните, как попасть на машину при ошибке сетевых настроек и что делать, если ОС не загрузилась. Возможность переустановки тоже полезна, но переустановка может уничтожить данные и не является первым действием при любой проблеме.

При первом SSH-подключении проверьте ключ сервера доступным у провайдера способом. Если позднее клиент сообщает, что ключ изменился, выясните причину. После согласованной переустановки изменение объяснимо; без ожидаемых работ предупреждение нельзя автоматически игнорировать.

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

Подготовьте операционную систему

Выбирайте поддерживаемую ОС, совместимую с приложением и способом обслуживания. Для панели управления проверьте её собственные требования до установки других компонентов. Если панель ожидает чистую систему, предварительная установка веб-сервера или базы может привести к конфликту.

Проверьте обновления из предусмотренных для выбранной ОС источников. Зафиксируйте исходную версию и выполненные изменения. Не добавляйте случайный репозиторий ради одной инструкции. Если приложение требует другую версию языка, сначала выясните поддерживаемый способ её получения и совместимость зависимостей.

Определите порядок последующих обновлений. Кто получает уведомления, проверяет новую версию на копии, делает резервную точку и согласует перезапуск? Автоматическая установка отдельных обновлений требует понимания её настроек. Наличие такого механизма не означает, что можно забыть об обновлениях приложения и его библиотек.

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

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

Настройте отдельного пользователя и SSH

Для обслуживания подготовьте отдельную учётную запись и ключ. Дайте ей права, достаточные для согласованных работ. Приложение не должно постоянно работать с правами root. Административные команды выполняются отдельно, когда они действительно нужны.

Новую учётную запись проверьте в отдельной SSH-сессии, сохранив исходную открытой. Подтвердите вход по ключу и необходимые административные действия. Простое наличие файла с публичным ключом не доказывает, что вход работает: на него влияют права, имя пользователя и настройки сервера.

После успешной проверки можно отдельно планировать ограничение парольного входа и root-доступа. Перед применением проверьте синтаксис конфигурации и учтите дополнительные файлы настроек. Документация Ubuntu по OpenSSH обращает внимание на проверку конфигурации перед перезапуском службы и риск потери доступа при ошибке.

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

Ограничьте входящие соединения

Составьте список служб, которым нужен вход из интернета. Сначала разрешите фактический способ SSH-доступа, затем проверяйте политику блокировки остальных соединений. Если провайдер имеет собственный сетевой firewall, учитывайте оба уровня.

Для сайта с локальной базой обычно нет причины открывать её порт всем посетителям. Если база находится на другом сервере, разрешения задаются под конкретную сеть и схему защиты. Само наличие пароля не оправдывает ненужное публичное открытие.

Если используете контейнеры, отдельно проверьте опубликованные порты и фактическую обработку их трафика. Нельзя считать доступ закрытым только по одному экрану статуса firewall. Итог проверяется снаружи согласованным способом, включая IPv6, если он используется.

Руководство Ubuntu по firewall описывает UFW и сетевые правила. Команды для своей машины сверяйте с установленной ОС и действующими службами. Не включайте найденный набор правил вслепую на сервере с единственным удалённым доступом.

Выберите способ запуска приложения

Есть несколько подходов: панель управления, установка компонентов напрямую или контейнеры. Выбирайте тот, который команда умеет обслуживать. Не смешивайте инструкции разных способов без понимания: два веб-сервера могут пытаться занять один порт, а две системы обновления менять одно окружение.

Проверьте совместимость точной версии приложения с языком, СУБД и расширениями. Зависимости должны устанавливаться воспроизводимо. Рабочую конфигурацию и секреты храните вне общедоступной директории и Git. Для базы создайте отдельного пользователя с необходимыми правами, без избыточных административных полномочий.

Публичный каталог веб-сервера должен содержать только предназначенные для выдачи файлы. Проверьте недоступность конфигурации, архивов и служебных каталогов через HTTP. Для прав записи выделите конкретные директории загрузок, кеша и журналов. Разрешение записи всем пользователям через 777 создаёт лишний риск.

Предусмотрите запуск и перезапуск приложения штатным механизмом. Ручная команда в открытом SSH-окне не должна быть единственным способом поддерживать сайт в работе. Для фоновых обработчиков нужна понятная служба, наблюдение и защита от лишних параллельных экземпляров.

Перед рабочими данными разверните безопасную копию. Отключите отладочный вывод для публичного запуска, проверьте обработку ошибок и убедитесь, что логи не раскрываются посетителю. Секреты и полные данные клиентов не должны попадать в публичный ответ при исключении.

Подключите домен и HTTPS

Определите основной адрес: с www или без него. Согласуйте DNS для IPv4 и IPv6, подготовьте сертификат на нужные имена и предусмотрите продление. Открытие сайта по IP не подтверждает корректную работу по домену: веб-сервер и приложение могут выбирать конфигурацию по имени.

После выпуска сертификата проверьте переход с HTTP на HTTPS и с дополнительного имени на основное. Путь и параметры запроса должны сохраняться там, где это требуется сайту. Проверьте CSS, JS, изображения, формы, canonical и ссылки в письмах. В них не должны оставаться технический адрес и незашифрованные ресурсы.

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

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

Настройте копии, журналы и наблюдение

Создайте копию и проверьте восстановление в отдельной среде до появления рабочих данных. Определите расписание, срок хранения и место вне сервера. Уведомление об успешном запуске задания не заменяет проверку пригодности результата.

Журналам нужна ротация: ограничение размера или срока, сжатие и разумная очистка. Проверьте журналы приложения, веб-сервера, базы, контейнеров и фоновых задач, если они используются. Один повторяющийся сбой способен быстро занять диск.

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

Определите регламент обновления: предварительная проверка, копия, последовательность действий и критерий возврата. Откат приложения и восстановление базы разделяйте. Если обновление изменило данные, запуск старого кода не гарантирует совместимость.

Состав копии, сценарии потери и пробное восстановление описаны в руководстве по бэкапам сайта и сервера. У владельца должен остаться короткий документ с адресами, ответственными и порядком восстановления.

Проверьте готовность перед рабочим запуском

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

Если один из пунктов не пройден, сначала завершите его на подготовленной площадке. Для подбора ресурсов используйте каталог VPS/VDS и разбор CPU, памяти и диска. Запуск будет проще обслуживать, когда конфигурация соответствует реальным задачам, а порядок работы записан.