VPS на Gcore можно запустить двумя путями. Первый путь, классический виртуальный сервер в разделе Hosting, подходит тем, кому нужен простой тариф, оплата и готовый сервер без гибкой сетевой схемы. Второй путь, Virtual Machine в Gcore Cloud, дает больше контроля над регионом, дисками, публичными и приватными сетями, firewall и floating IP.
Ниже разберем именно Gcore Cloud Virtual Machine. Для большинства задач вроде сайта, API, бота, тестового стенда, reverse proxy или небольшого Docker-хоста такой вариант удобнее: сервер создается из панели, подключается по SSH, дальше настраивается как обычная Linux-машина.
Материал предназначен для легального и ответственного администрирования собственных серверов. Соблюдайте законы своей страны, особенно России, правила Gcore и правила сервисов, к которым подключаете VPS. Не используйте сервер для несанкционированного доступа, слежки, взлома, рассылок, атак, сканирования чужих систем без разрешения или незаконного обхода блокировок.
Что подготовить до создания VPS
До входа в панель Gcore лучше решить четыре вещи: где будут пользователи сервиса, какая ОС нужна, нужен ли публичный IP сразу и как вы будете входить на сервер.
Регион выбирайте ближе к аудитории, но не только по карте. Для российских пользователей часто тестируют маршруты до европейских и ближневосточных локаций, но реальная задержка зависит от провайдера, магистралей и времени суток. Если сервер нужен под продакшен, поднимите минимальную машину, проверьте ping, traceroute и скорость, а потом выбирайте постоянную конфигурацию.
Для первого Linux VPS берите x86-64 и Ubuntu LTS. ARM может быть дешевле или энергоэффективнее в отдельных сценариях, но не каждый пакет, Docker-образ или проприетарный агент одинаково хорошо работает на ARM. Для обычного сайта, VPN-сервера в легальном сценарии, бота или API разумнее начинать с x86-64.
Сразу создайте SSH-ключ на своем компьютере. Парольный вход удобен, но ключ безопаснее и лучше подходит для долгой эксплуатации.
ssh-keygen -t ed25519 -C "gcore-vps" -f ~/.ssh/gcore_vps
Если панель или старый клиент не принимает ed25519, используйте RSA, такой вариант описан в официальной документации Gcore по SSH-ключам.
ssh-keygen -t rsa -b 2048 -f ~/.ssh/gcore_vps
Публичный ключ лежит в файле ~/.ssh/gcore_vps.pub. Приватный ключ ~/.ssh/gcore_vps никому не отправляйте и не вставляйте в панели сайтов. В Gcore добавляют именно публичный ключ.
Пошагово создаем VPS в Gcore Cloud
Шаг 1. Зайдите в Cloud и создайте Virtual Machine
Откройте Gcore Customer Portal, перейдите в Cloud, затем в Virtual Instances или Instances и нажмите Create Instance. Официальный порядок шагов есть в документации Gcore по созданию VM, но в реальной работе главные решения принимаются на этапах региона, образа, сети и доступа.
Если в аккаунте еще нет проекта, платежного метода или пополненного баланса, панель попросит закрыть эти вопросы до запуска. Не создавайте тестовую машину с дорогими дисками, GPU или Windows-лицензией, если задача пока сводится к проверке панели и SSH.
Шаг 2. Выберите регион
Gcore делит регионы на Core и Edge. Core обычно рассчитаны на более свежую инфраструктуру и масштабирование, Edge часто дешевле, но с более ограниченной гибкостью. Для одного небольшого VPS разница может быть не критичной, а вот для кластера, миграций и роста нагрузки Core чаще выглядит безопаснее.
Практический критерий простой: для сайта выбирайте регион ближе к пользователям, для внутренних задач выбирайте регион ближе к внешним API, базе данных или CDN-узлам, с которыми сервер будет чаще обмениваться данными.
Шаг 3. Выберите образ и архитектуру
Для первого VPS выбирайте x86-64 и Ubuntu LTS. Debian тоже хороший вариант, если нужен минимализм и предсказуемость. Windows берите только под задачи, где действительно нужен RDP, Windows-софт или .NET-стек с жесткой привязкой к Windows, потому что лицензия обычно увеличивает стоимость.
Не ставьте экзотический образ только из интереса. Чем стандартнее система, тем проще найти инструкции, обновления, Docker-образы и решения типовых ошибок.
Шаг 4. Выберите тип VM и размер
Для небольшого сайта, Nginx, Node.js-приложения, Python API, Telegram-бота или тестового Docker-хоста хватит конфигурации уровня 1-2 vCPU, 1-2 GiB RAM и 20-30 GiB диска. Если планируете PostgreSQL, Elasticsearch, тяжелый Java-сервис или несколько контейнеров, начинайте с 2-4 GiB RAM и следите за метриками.
| Сценарий | Стартовая конфигурация | На что смотреть |
|---|---|---|
| Лендинг, Nginx, статический сайт | 1 vCPU, 1 GiB RAM | CPU, сетевые лимиты, кэширование |
| Небольшой API или бот | 1-2 vCPU, 2 GiB RAM | Память, логи, лимиты внешних API |
| Docker с несколькими сервисами | 2 vCPU, 4 GiB RAM | RAM, диск, автозапуск контейнеров |
| База данных на том же сервере | 2-4 vCPU, 4-8 GiB RAM | IOPS, бэкапы, отдельный диск |
Shared-конфигурации могут подойти для слабой нагрузки, но не ждите стабильной производительности под тяжелыми задачами. Для продакшена лучше начинать со Standard, а потом увеличивать ресурсы по метрикам.
Шаг 5. Настройте диск
Для обычного VPS выбирайте стандартный SSD-диск. High IOPS нужен базам данных, очередям, индексам и сервисам, где задержка диска влияет на работу приложения. Для лендинга или бота дорогой диск обычно не даст заметной пользы.
Размер диска выбирайте с запасом под логи, Docker-образы, бэкапы и временные файлы. Частая ошибка, поставить 10-20 GiB, потом через месяц получить упавший сервис из-за переполненного /var/log или Docker cache.
Шаг 6. Настройте сеть
Для первого сервера проще выбрать Public network с IPv4. Так VPS сразу получит адрес, к которому можно подключиться по SSH. Если строите более аккуратную схему, используйте Private network и floating IP. Floating IP удобен, когда публичный адрес нужно быстро перенести на другую VM или не хочется давать виртуальной машине прямой публичный интерфейс.
У floating IP есть нюанс: адрес привязан к конкретной локации и не переносится произвольно между разными регионами. Для одной VM без планов на быстрый failover обычный публичный IP проще.
Шаг 7. Настройте firewall
Не оставляйте firewall «на потом». Минимальный набор для Linux-сервера: SSH только с вашего IP, HTTP 80 и HTTPS 443 только если сервер будет принимать веб-трафик. Все лишнее закрывайте.
В Gcore есть default firewall. По документации он разрешает входящие SSH, RDP и ICMP, а исходящие подключения разрешены. Для Linux VPS RDP обычно не нужен, поэтому лучше создать свой firewall и не держать порт 3389 открытым без причины.
На старте безопасная схема выглядит так:
- TCP 22, только ваш внешний IP или доверенная подсеть
- TCP 80, если нужен выпуск Let's Encrypt или обычный HTTP
- TCP 443, если будет HTTPS
- ICMP, если нужен ping и диагностика
Не включайте одновременно сложные правила в cloud firewall и UFW внутри ОС, пока не проверили доступ. Новички часто закрывают себе SSH двумя разными firewall и потом заходят только через web console.
Шаг 8. Добавьте SSH-ключ
В блоке Authentication выберите Select SSH key, Add a new SSH key или Generate SSH key. Если вы создали ключ локально, откройте файл ~/.ssh/gcore_vps.pub и вставьте содержимое в поле публичного ключа.
cat ~/.ssh/gcore_vps.pub
Пароль для Linux VM можно задать через User data или отдельные настройки, но для нормальной эксплуатации лучше входить по ключу. Пароль нужен разве что для аварийного входа через консоль, и даже в таком случае пароль должен быть уникальным и длинным.
Шаг 9. Проверьте стоимость и создайте VM
Перед кнопкой Create virtual machine проверьте регион, тип VM, диск, IP-адреса, Windows-лицензию, snapshots и дополнительные ресурсы. У Gcore виртуальные машины тарифицируются с момента создания до полной остановки, а диски, snapshots и IP-адреса могут тарифицироваться отдельно. Актуальные ставки лучше смотреть на странице Cloud Pricing, потому что цены зависят от региона и конфигурации.
После создания VM перейдет в статус Building, затем в Power on. Когда в карточке появится публичный IP и логин, можно подключаться.
Подключение к VPS по SSH
В карточке VM найдите логин и IP. Обычно логин совпадает с дистрибутивом, например ubuntu для Ubuntu. Подключение с Linux, macOS или Windows с OpenSSH выглядит так:
chmod 600 ~/.ssh/gcore_vps
ssh -i ~/.ssh/gcore_vps ubuntu@YOUR_SERVER_IP
При первом подключении SSH спросит, доверяете ли вы host key. Если IP только что выдали вашей VM и адрес совпадает с панелью Gcore, отвечайте yes.
Если подключение не проходит, проверьте четыре вещи: VM включена, IP указан верно, firewall разрешает TCP 22 с вашего адреса, публичный ключ добавлен именно в эту VM. При private-only схеме нужен floating IP или другой путь доступа, иначе SSH из интернета просто не дойдет до сервера.
Базовая настройка после первого входа
Первый вход на сервер не означает, что VPS готов к работе. Минимум, который стоит сделать сразу: обновить систему, создать рабочего пользователя, проверить SSH, настроить firewall и включить автообновления безопасности.
sudo apt update && sudo apt -y upgrade
sudo reboot
После перезагрузки зайдите снова и создайте отдельного пользователя. Не работайте постоянно из-под root, даже если root-доступ включен.
sudo adduser deploy
sudo usermod -aG sudo deploy
Скопируйте ключи новому пользователю:
sudo mkdir -p /home/deploy/.ssh
sudo cp ~/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
Проверьте вход новым пользователем в отдельном окне терминала, не закрывая старую SSH-сессию:
ssh -i ~/.ssh/gcore_vps deploy@YOUR_SERVER_IP
Если новый вход работает, можно ужесточить SSH. Создайте отдельный конфиг:
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf
Добавьте настройки:
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
Проверьте конфигурацию и перезапустите SSH:
sudo sshd -t
sudo systemctl reload ssh
Не закрывайте текущую сессию, пока не убедились, что новый вход по ключу работает. Такая привычка спасает от лишних аварийных заходов через web console.
Если нужен веб-сервер
Для простого Nginx-сервера установите пакет и откройте нужные порты в cloud firewall. Внутри Ubuntu можно включить UFW, но сначала убедитесь, что cloud firewall уже не блокирует нужный трафик.
sudo apt install -y nginx
systemctl status nginx
Если используете UFW внутри ОС, сначала разрешите SSH, иначе можно потерять доступ:
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status
После этого откройте в браузере http://YOUR_SERVER_IP. Если страница Nginx не открылась, проверяйте не Nginx в первую очередь, а firewall, маршрут, публичный IP и статус сервиса.
Типичные ошибки при запуске VPS на Gcore
- Выбрали private network без floating IP и ждут SSH из интернета. Для внешнего подключения нужен публичный путь до VM.
- Оставили default firewall с RDP для Linux-сервера. Лишние порты расширяют поверхность атаки.
- Добавили приватный SSH-ключ вместо публичного. В панель вставляют содержимое файла с расширением .pub.
- Закрыли SSH через UFW до проверки правил. Всегда держите открытую сессию, пока тестируете новый вход.
- Не учитывают отдельную тарификацию дисков, snapshots и IP. Остановленная VM не всегда означает нулевой счет за все связанные ресурсы.
- Ставят слишком маленький диск под Docker. Образы, volumes и логи быстро занимают место.
Когда Gcore VPS может быть не лучшим выбором
Gcore хорош, когда нужны разные регионы, облачные сети, управляемые IP и инфраструктурная гибкость. Но для совсем простого WordPress-сайта без администрирования дешевле и спокойнее может оказаться managed-хостинг. VPS требует обновлений, мониторинга, резервных копий и реакции на инциденты.
Если нужен production-сервис с базой данных, не храните все на одной VM без бэкапов. Минимальный набор для серьезной эксплуатации: snapshots или внешние бэкапы, мониторинг диска и памяти, алерты, отдельный пользователь для деплоя, закрытый SSH, HTTPS и понятный план восстановления.
FAQ
Можно ли поднять VPS на Gcore без SSH-ключа?
Можно, если задать пароль и разрешить парольную аутентификацию, но такой вариант хуже для постоянной эксплуатации. SSH-ключ снижает риск подбора пароля и лучше подходит для автоматизации.
Что выбрать, public IP или floating IP?
Для одного простого VPS выбирайте public IP. Floating IP берите, когда адрес нужно переносить между VM, когда сервер находится в приватной сети или когда строите схему с отказоустойчивостью.
Какой регион Gcore выбрать для сайта?
Выбирайте регион ближе к основной аудитории и проверяйте задержку с реальных сетей. Географически близкий регион не всегда быстрее из-за маршрутизации провайдеров.
Нужно ли включать UFW, если есть cloud firewall?
Для новичка лучше начать с cloud firewall и простых правил. UFW можно добавить позже, когда понятна схема доступа. Два firewall одновременно дают больше контроля, но повышают риск случайно закрыть SSH.
С чего начать, чтобы VPS не стал проблемой
Чтобы поднять VPS на Gcore без лишнего риска, идите по короткому маршруту: Gcore Cloud, Virtual Machine, ближайший регион, x86-64, Ubuntu LTS, Standard VM, SSD-диск, public IPv4, свой firewall, SSH-ключ. После первого входа обновите систему, создайте отдельного пользователя, отключите парольный вход и root-login, проверьте правила firewall и настройте бэкапы.
Не усложняйте стартовую схему floating IP, приватными подсетями, несколькими firewall и кастомными образами, если поднимаете первый сервер. Сначала получите рабочий и защищенный VPS, потом добавляйте Docker, домен, HTTPS, мониторинг и автоматизацию. Главные риски на старте не в Gcore, а в открытых портах, слабой SSH-настройке, отсутствии бэкапов и забытых платных ресурсах.
