Перейти к содержимому
Catshredia
…
← К блогу

Цикл «сервер на VPS»: настройка конфигурации VPS

linuxit technologiesvps_serverlinuxdocker

Настройка конфигурации сервера

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

В этой статье мы пошагово разберём процесс подготовки «чистого» Linux-сервера к деплою: от первого подключения по SSH и создания пользователя до установки Docker Engine и настройки firewall.

Материал ориентирован на разработчиков, которые хотят самостоятельно контролировать инфраструктуру своего проекта, а не полагаться на готовые PaaS-решения.

Для того, чтобы выложить в публичный доступ сайт нужно приобрести следующие вещи:

  • сервер с установленным linux и статичным IP (обычно можно сразу при покупке задать);
  • доменное имя;

Данный цикл описывает работу в Ubuntu, команды в других дистрибутивах linux могут быть другими.

После инициализации сервера вы получите ID сервера: XXX.XX.XXX.XXX и root-пароль.

Можно подключиться к серверу по SSH протоколу, для этого в среде с ssh (например терминал git bash). В нем выполняем все дальнейшие программы:

Подключение к серверу

ssh root@ID_Server

Обновление существующих пакетов через пакетный менеджер: apt

apt update && apt upgrade -y

Настройка SSH ключей для быстрого входа

  1. Создание локального SSH ключа
ssh-keygen -t ed25519 -C "name"
  1. Просмотр публичного ключа
cat ~/.ssh/id_ed25519.pub
  1. Копирование ключа на сервер
ssh-copy-id root@IP_СЕРВЕРА

Создание нового пользователя

(для безопасности лучше не работать в root пользователе):

# 1. Создать пользователя
useradd -m -s /bin/bash deploy
# 2. Дать права sudo
usermod -aG sudo deploy        
# 3. Настроить SSH-ключи
mkdir -p /home/deploy/.ssh
cat /root/.ssh/id_ed25519.pub >> /home/deploy/.ssh/authorized_keys # именно добавление ключей, а не копирование
# или скопировать через nano

# 4. Исправить права
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

# 5. Проверить вход (в новом окне!)
ssh deploy@ID_Server

отключим вход по паролю:

  • перед отключением проверить возможность входа под пользователем deploy:
ssh deploy@ID_Server
  • редактируем файл через nano: nano /etc/ssh/sshd_config
  • в нем меняем:
PermitRootLogin no
PasswordAuthentication no

не забыть перезапустить конфигурацию:

sudo systemctl restart ssh
Настройка git ssh ключей

Для получения кода из приватных репозиториев, нужно настроить SSH ключи. Далее пример с github.com:

  1. на сервере создаем ключ:
ssh-keygen -t ed25519 -C "vps-deploy" -f ~/.ssh/id_ed25519_github
cat ~/.ssh/id_ed25519_github.pub
  1. в github переходим: Settings --> Deploy Keys
  2. создаем ключ , указывая там его текстом (берем результат cat ~/.ssh/id_ed25519_github.pub)
  3. дополним конфигурацию, заходим в файл nano ~/.ssh/config, добавляем:
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/название_ключа
  IdentitiesOnly yes
  1. в конце добавляем чтение ключей и из поддиректорий
if [ -z "$SSH_AUTH_SOCK" ]; then
  eval "$(ssh-agent -s)" >/dev/null
  ssh-add ~/.ssh/id_ed25519_github 2>/dev/null
fi
  1. проверяем результат
# проверяем наличие ключа
ls -la ~/.ssh/
git clone репозиторий # приватный репозиторий

Настройка Firewall на сервере

Необходимо настроить порты и адреса, с которых могут приходить запросы на сервер. В нашем случае нам необходимы следующие порты:

  • 22/TCP - SSH подключение, через него мы подключаемся к серверу [добавить ссылку];
  • 443/TCP - HTTPS, защищенный веб-трафик, запросы от браузера клиента;
  • 80/TCP - HTTP, обычный веб-трафик, часто происходит редирект на защищенный протокол HTTTPS.

Это можно сделать через графический интерфейс провайдера (где покупали сервер) или через консольную утилиту ufw (выбрать только один вариант).

  • Через графический интерфейс (пример: timeweb cloud): выбираем сервер --> сеть --> Firewall --> настроить --> создаем новое правило --> добавляем порты с протоколом TCP, должно получиться следующее:

Screenshot_10 Также стоит проверить привязку правила к корректному серверу.

  • Через ufw: Важно: перед включением UFW убедись, что правило для порта 22 уже добавлено, иначе можешь потерять доступ к серверу по SSH.
# Включение UFW и настройка политик по умолчанию
sudo ufw default deny incoming   # Запретить весь входящий трафик
sudo ufw default allow outgoing  # Разрешить весь исходящий трафик

# Разрешение необходимых портов
sudo ufw allow 22/tcp comment 'SSH'      # Удалённое управление
sudo ufw allow 80/tcp comment 'HTTP'     # Веб-трафик
sudo ufw allow 443/tcp comment 'HTTPS'   # Защищённый веб-трафик

# Активация фаервола
sudo ufw enable

# Проверка статуса и правил
sudo ufw status verbose

Настройка домена

Через графический интерфейс все легко (пример: timeweb cloud):

  • Домены и SSL --> Выбираем домен --> DNS --> создаем запись A --> привязываем её к IP и серверу. Через консоль также возможно (пример: Cloudflare):
# Через curl + API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  --data '{"type":"A","name":"example.com","content":"147.45.246.115","ttl":3600,"proxied":false}'

А так для каждого провайдера в документации с большой вероятностью будет указана подробная инструкция по настройке записей домена.

Загрузка Docker Engine

Official Documentation - Installing Docker to Ubuntu

  • онлайн установка:
sudo apt update
sudo apt install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: noble
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

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

Подготовка образов на локальном ПК и перенос их на удаленный сервер

1 Вариант: собранные образы

Переходим по ссылки https://download.docker.com/linux/ubuntu/dists/noble/pool/stable/amd64/ и скачиваем 5 архивов последней стабильной версии (или постарше, но главное совместимые между собой):

  • containerd.io_*.deb
  • docker-ce-cli_*.deb
  • docker-ce_*.deb
  • docker-buildx-plugin_*.deb
  • docker-compose-plugin_*.deb

Перекидываем архивы на сервер:

scp containerd.io_*.deb docker-ce-cli_*.deb docker-ce_*.deb docker-buildx-plugin_*.deb docker-compose-plugin_*.deb deploy@IP_СЕРВЕРА:/home/deploy/

Устанавливаем образы

cd /home/deploy
ls -la *.deb

sudo dpkg -i containerd.io_*.deb
sudo dpkg -i docker-ce-cli_*.deb
sudo dpkg -i docker-ce_*.deb
sudo dpkg -i docker-buildx-plugin_*.deb
sudo dpkg -i docker-compose-plugin_*.deb

sudo apt -f install -y

sudo systemctl enable --now docker
sudo systemctl status docker

Проверка:

# Запустим тестовый образ hello world
sudo docker run hello-world
# Проверим версию
docker compose version
2 Вариант: собираем образы сами с помощью локального Docker Engine

На локальном ПК необходим запущенный Docker Engine: Собираем необходимые образы и отправляем на сервер:

docker pull mcr.microsoft.com/dotnet/sdk:8.0
docker pull mcr.microsoft.com/dotnet/aspnet:8.0
docker pull nginx:stable-alpine

docker save mcr.microsoft.com/dotnet/sdk:8.0 mcr.microsoft.com/dotnet/aspnet:8.0 nginx:stable-alpine -o project-images.tar

# отправка на сервер
scp project-images.tar deploy@IP_СЕРВЕРА:/home/deploy/

на сервере:

sudo docker load -i /home/deploy/project-images.tar
sudo docker images

После того, как docker engine установлен, выдадим права (перезапуск ssh для применения):

sudo usermod -aG docker deploy #выдадим права пользователю на docker

Итог

В результате мы получили полностью подготовленный Linux-сервер: настроены SSH-ключи для безопасного входа, создан непривилегированный пользователь deploy, открыты необходимые порты (22, 80, 443), домен привязан к IP-адресу, а Docker Engine готов к запуску контейнеров. Следующие шаги, которые предстоит реализовать для полноценного запуска сайта:

  • Установка и конфигурация Nginx — в качестве reverse-proxy для маршрутизации трафика между доменом и контейнерами приложения.
  • Написание docker-compose.yml для оркестрации приложения, базы данных и веб-сервера.
  • Автоматизация деплоя — через CI/CD (например, GitHub Actions) или простой bash-скрипт, чтобы обновление сайта происходило в одну команду.

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

Комментарии

  • Ioann Pimenov

    cp /root/.ssh/authorized_keys /home/deploy/.ssh/ — опасный способ. Если в authorized_keys root-а есть другие ключи, они тоже попадут пользователю deploy. Лучше копировать конкретный публичный ключ.

    • Admin

      Верно, хотя инструкция адресована людям создающим первый свой сервер. Так что вполне вероятно у них нет SSH ключей. А так можно использовать: cp /root/.ssh/authorized_keys /home/deploy/.ssh/name_key

      • Ioann Pimenov

        Admin, ты сам написал «Верно», а потом предложил решение, которое проблему не решает. cp /root/.ssh/authorized_keys /home/deploy/.ssh/name_key - это всё равно копирование всех ключей root'а пользователю deploy. Просто под другим именем. Если у root'а несколько ключей (а обычно они есть), deploy получит доступ всеми ними. То, что человек создаёт первый сервер и «у него, возможно, нет ключей» - это слабое оправдание. Инструкция должна учить правильным и безопасным практикам с самого начала, а не «ну сойдёт для нубов». Правильно делать так: Bash# Вариант 1 (рекомендуемый) cat /root/.ssh/id_ed25519.pub >> /home/deploy/.ssh/authorized_keys # Или вариант 2 cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys chown deploy:deploy /home/deploy/.ssh/authorized_keys chmod 600 /home/deploy/.ssh/authorized_keys Копировать весь authorized_keys root'а — плохая практика, даже если «сейчас только один ключ».

        • Admin

          Благодарю за пояснение, исправил момент в статье!

Загрузка…