Cloud-init для VPS: как автоматически готовить сервер после создания

Новый VPS похож на пустую квартиру после получения ключей: стены есть, электричество работает, но жить и работать там ещё рано. Нужно закрыть двери, настроить доступ, занести инструменты, поставить базовую защиту и убедиться, что всё не развалится в первый же вечер. Обычно это делают вручную: подключились по SSH, обновили пакеты, создали пользователя, включили firewall, поставили Docker, проверили логи. Один раз - терпимо. Десять раз - уже рутина, которая съедает время и легко приводит к ошибкам. Cloud-init решает эту проблему красиво: сервер сам выполняет стартовую настройку при первом запуске. Вы заранее описываете, каким должен быть VPS после создания, а cloud-init превращает чистую систему в подготовленную рабочую площадку. В этой статье разберём практический сценарий для VPS: SSH-ключи, отдельный пользователь, firewall, базовые пакеты, Docker, monitoring-ready настройка и аккуратный hardening. В конце будет готовый шаблон, который можно адаптировать под свои проекты.

Что такое cloud-init и почему он полезен на VPS

Cloud-init - это механизм первичной инициализации Linux-сервера. Он запускается при первом старте системы и выполняет инструкции из специального конфигурационного файла, который обычно называют user-data. Проще говоря, cloud-init отвечает на вопрос: “Что должен сделать сервер сразу после создания?”

Например

• добавить SSH-ключ администратора

• создать пользователя deploy

• отключить вход по паролю

• обновить пакеты

• включить firewall

• установить Docker

• добавить базовые инструменты диагностики

• подготовить конфиги безопасности

• выполнить свои команды.

Представьте, что у вас есть чек-лист настройки VPS. Cloud-init превращает этот чек-лист в исполняемый рецепт. Вы не кликаете и не вводите команды вручную - сервер сам проходит по списку. Это особенно удобно, если вы часто поднимаете тестовые окружения, staging, небольшие production-серверы, VPN-ноды, прокси-инфраструктуру, Docker-хосты или однотипные VPS под клиентские проекты.

Где cloud-init особенно экономит время

Ручная настройка кажется быстрой только до тех пор, пока она одна. Создали VPS, подключились, выполнили 20 команд, сохранили пару конфигов - вроде ничего страшного. Но через неделю появляется второй сервер, потом третий, потом нужно повторить всё на другой версии Ubuntu, потом кто-то забыл включить firewall. Cloud-init помогает убрать человеческий фактор.

Пример из практики

Допустим, команда запускает несколько VPS под разные окружения: dev, staging и production. На каждом сервере нужен один и тот же базовый набор: пользователь без прямого root-доступа; авторизация только по SSH-ключу; закрытые входящие порты; Docker и Docker Compose plugin; fail2ban; автоматические security updates; базовые утилиты для диагностики. Без cloud-init это набор ручных действий. С cloud-init - один файл, который можно хранить в Git, проверять, улучшать и использовать повторно. Такой подход особенно хорошо ложится на инфраструктуру как код. Сервер перестаёт быть “ручной снежинкой” и становится предсказуемым ресурсом.

Что важно подготовить до запуска

Перед тем как писать конфиг, стоит определиться с несколькими вещами. Cloud-init не любит неопределённость: чем точнее вы опишете желаемое состояние сервера, тем меньше сюрпризов получите после первого запуска.

1. SSH-ключ

Парольный вход на новый VPS - удобная, но слабая привычка. Лучше сразу использовать SSH-ключи. Публичный ключ выглядит примерно так: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExamplePublicKey user@laptop Именно публичный ключ добавляется на сервер. Приватный ключ остаётся только у вас на компьютере. Это как замок и ключ: замок можно поставить на дверь, но сам ключ нельзя оставлять в подъезде. Для нового ключа можно использовать команду: ssh-keygen -t ed25519 -C "admin@example.com" После этого публичный ключ обычно лежит в файле: ~/.ssh/id_ed25519.pub

2. Имя основного пользователя

Не стоит работать под root каждый день. Лучше создать отдельного пользователя, например deploy или admin, добавить его в sudo и заходить на сервер через него. В примерах ниже используется пользователь deploy. Его можно заменить на имя, которое принято в вашей команде.

3. Список открытых портов

До включения firewall нужно решить, какие сервисы будут доступны извне.

Минимальный набор для типичного web-сервера

• 22/tcp - SSH

• 80/tcp - HTTP

• 443/tcp - HTTPS.

Если приложение работает только через reverse proxy, лишние порты наружу открывать не нужно. Чем меньше дверей в доме, тем проще за ними следить.

4. Набор пакетов

Для базовой подготовки VPS обычно хватает

• curl

• wget

• git

• htop

• unzip

• ca-certificates

• gnupg

• ufw

• fail2ban

• unattended-upgrades

• prometheus-node-exporter или другой агент мониторинга.

Не нужно превращать cloud-init в установщик всего на свете. Хороший стартовый шаблон делает сервер безопасным и удобным, но не перегружает его случайными инструментами.

Базовая логика cloud-init файла

Cloud-init конфиг начинается со строки: #cloud-config Это маркер, по которому система понимает формат файла. Дальше идут секции: пользователи, пакеты, файлы, команды. Типовая структура выглядит так: #cloud-configusers: - name: deploy ...package_update: truepackage_upgrade: truepackages: - curl - git - ufwwrite_files: - path: /etc/example.conf content: | example=trueruncmd: - echo "Server is ready" Секция users управляет пользователями и SSH-ключами.packages устанавливает пакеты.write_files создаёт файлы с нужным содержимым.runcmd выполняет команды в конце настройки. Логика простая: сначала создаём основу, потом кладём конфиги, потом запускаем команды, которые должны применить изменения.

SSH-ключи и пользователи: закрываем главный вход

Первое, что стоит сделать на VPS, - настроить безопасный доступ. Если оставить вход по паролю, сервер будет постоянно видеть попытки подбора. Это не повод для паники, но и не то, что хочется наблюдать на новой машине. Cloud-init может сразу создать пользователя и добавить ему SSH-ключ. Пример: users: - default - name: deploy gecos: Deploy User groups: - sudo sudo: - ALL=(ALL) NOPASSWD:ALL shell: /bin/bash lock_passwd: true ssh_authorized_keys: - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIReplaceWithYourPublicKey admin@example.comssh_pwauth: falsedisable_root: true

Что здесь происходит:

создаётся пользователь deploy; пользователь получает sudo-права; пароль для него заблокирован; вход возможен только по SSH-ключу; парольная SSH-авторизация отключается; прямой root-доступ отключается. Мини-пример из жизни: если сервером пользуются два администратора, не стоит давать всем один root-доступ. Лучше создать отдельных пользователей или хотя бы отдельные ключи. Когда кто-то уйдёт из проекта, ключ можно удалить без полной пересборки доступа.

SSH hardening: немного строже, но без фанатизма

Отключить парольный вход - уже хороший шаг. Но SSH можно чуть усилить через отдельный конфиг в /etc/ssh/sshd_config.d/. Cloud-init умеет создавать такие файлы через write_files: write_files: - path: /etc/ssh/sshd_config.d/99-hardening.conf owner: root:root permissions: '0644' content: | PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yes KbdInteractiveAuthentication no X11Forwarding no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2 После этого SSH нужно перезагрузить: runcmd: - systemctl reload ssh || systemctl reload sshd Здесь важно не переусердствовать. Например, перенос SSH на нестандартный порт может уменьшить шум в логах, но сам по себе не является серьёзной защитой. А вот закрытие парольного входа, ограничение root-доступа и работа через ключи - практичный фундамент. Перед применением такого шаблона убедитесь, что публичный ключ указан правильно. Ошибка в одной строке может оставить вас без доступа к серверу.

Firewall: сначала SSH, потом всё остальное

Firewall на VPS - как входная группа в здании. Если её нет, любой сервис, который слушает внешний интерфейс, может оказаться доступным из интернета. Для Ubuntu часто используют UFW. Он удобен тем, что позволяет быстро описать базовые правила. Минимальная логика такая: ufw default deny incomingufw default allow outgoingufw allow OpenSSHufw allow 80/tcpufw allow 443/tcpufw --force enable В cloud-init это можно поместить в runcmd: runcmd: - ufw default deny incoming - ufw default allow outgoing - ufw allow OpenSSH - ufw allow 80/tcp - ufw allow 443/tcp - ufw --force enable Главное правило: не включайте firewall до того, как разрешили SSH. Иначе можно получить классическую ситуацию “сервер работает, но войти нельзя”. Если вы используете нестандартный SSH-порт, например 2222, правило должно быть другим: ufw allow 2222/tcp Для Docker-хостов есть отдельный нюанс: Docker активно работает с iptables. Поэтому в production лучше дополнительно продумывать правила в цепочке DOCKER-USER, особенно если контейнеры публикуют порты наружу. Для простого старта достаточно не публиковать лишние порты и не открывать сервисы без необходимости.

Пакеты: ставим только то, что нужно на старте

Cloud-init может обновить индекс пакетов, выполнить upgrade и поставить базовые инструменты: package_update: truepackage_upgrade: truepackages: - ca-certificates - curl - gnupg - lsb-release - git - htop - unzip - ufw - fail2ban - unattended-upgrades - prometheus-node-exporter Это хороший стартовый набор для администратора. Он не превращает VPS в тяжёлый комбайн, но даёт всё нужное для первых действий. Короткая аналогия: базовые пакеты - это набор инструментов в машине. Вам не нужен весь гараж, но домкрат, ключи и фонарик должны быть под рукой.

Что можно добавить под конкретный проект

• nginx или caddy для reverse proxy

• postgresql-client или mysql-client для работы с БД

• jq для обработки JSON

• make для сборочных сценариев

• rsync для копирования данных.

Что лучше не добавлять без причины

• лишние языковые runtimes

• панели администрирования

• тяжёлые агенты

• сервисы, которые сразу открывают порты наружу.

Чем меньше лишнего на сервере, тем проще обновлять, мониторить и защищать систему.

Docker: готовим VPS под контейнеры

Docker часто ставят почти на каждый новый VPS. Это удобно: приложение, база, reverse proxy, worker и monitoring-agent могут жить в контейнерах, а окружение легче переносить между серверами. Но Docker лучше ставить аккуратно, через официальный репозиторий, а не случайной командой из старой инструкции. В cloud-init можно добавить установку Docker в runcmd: runcmd: - install -m 0755 -d /etc/apt/keyrings - curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc - chmod a+r /etc/apt/keyrings/docker.asc - . /etc/os-release && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu ${VERSION_CODENAME} stable" > /etc/apt/sources.list.d/docker.list - apt-get update - apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin - systemctl enable --now docker - usermod -aG docker deploy После этого пользователь deploy сможет работать с Docker без sudo после нового входа в систему. Пример проверки: docker versiondocker compose versiondocker run --rm hello-world Важный момент: добавление пользователя в группу docker фактически даёт ему высокий уровень доступа к системе. Это удобно для администратора или CI-пользователя, но не стоит добавлять туда всех подряд. Группа docker - не “обычная пользовательская группа”, а почти ключ от серверной комнаты.

Автоматические обновления безопасности

Сервер, который не обновляется, постепенно превращается в музей старых уязвимостей. При этом вручную проверять security updates на каждом VPS неудобно. Для базового уровня можно включить unattended-upgrades: write_files: - path: /etc/apt/apt.conf.d/20auto-upgrades owner: root:root permissions: '0644' content: | APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7"; И затем убедиться, что сервис работает: runcmd: - systemctl enable --now unattended-upgrades Для небольших VPS это особенно полезно: сервер может месяцами выполнять одну задачу, и владелец вспоминает о нём только когда что-то ломается. Автоматические security updates не заменяют полноценное обслуживание, но хорошо закрывают базовую гигиену. В production стоит отдельно решить вопрос с автоматической перезагрузкой после обновлений ядра. Для критичных проектов лучше использовать плановое окно обслуживания, а не внезапный reboot в середине дня.

Fail2ban: меньше шума от грубого подбора

Даже если парольный вход отключён, SSH-логи часто заполняются попытками входа от ботов. Fail2ban помогает автоматически блокировать источники, которые слишком настойчиво стучатся в дверь. Минимальный конфиг: write_files: - path: /etc/fail2ban/jail.d/sshd.local owner: root:root permissions: '0644' content: | [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 findtime = 10m bantime = 1h И запуск: runcmd: - systemctl enable --now fail2ban Fail2ban - не броня от всего, но хороший фильтр от мусорного трафика. Как домофон, который не делает квартиру неуязвимой, но отсекает тех, кто просто нажимает все кнопки подряд.

Мониторинг: сервер должен подавать признаки жизни

Подготовить VPS - это не только установить пакеты. Важно понимать, что происходит после запуска: хватает ли памяти, не забился ли диск, не падает ли сервис, нет ли необычной нагрузки. Для базового старта можно поставить prometheus-node-exporter. Он собирает системные метрики: CPU, память, диск, сеть. Сам по себе он не рисует красивые графики, зато его можно подключить к Prometheus, Grafana или внешней системе мониторинга. В cloud-init достаточно добавить пакет: packages: - prometheus-node-exporter И включить сервис: runcmd: - systemctl enable --now prometheus-node-exporter Но не спешите открывать порт node exporter в интернет. Метрики могут содержать чувствительную информацию об инфраструктуре. Лучше ограничить доступ firewall-правилами, VPN, приватной сетью или reverse proxy с авторизацией. Для совсем простого контроля можно добавить небольшой скрипт проверки: write_files: - path: /usr/local/bin/server-health owner: root:root permissions: '0755' content: | #!/usr/bin/env bash echo "Hostname: $(hostname)" echo "Uptime: $(uptime -p)" echo echo "Disk:" df -h / echo echo "Memory:" free -h echo echo "Failed systemd units:" systemctl --failed --no-pager После входа на сервер администратор сможет выполнить: server-health Иногда такой простой инструмент экономит больше времени, чем сложная панель. Особенно в первые минуты после создания VPS.

Базовый hardening: не крепость, но хороший забор

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

Для стартового VPS можно сделать так

• Отключить парольный SSH-вход.

• Запретить прямой root-login.

• Использовать отдельного пользователя с sudo.

• Включить firewall.

• Открывать только нужные порты.

• Установить fail2ban.

• Включить автоматические security updates.

• Не ставить лишние сервисы.

• Следить за логами и метриками.

• Хранить cloud-init шаблон в Git.

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

Готовый cloud-init шаблон для VPS

Ниже - практический шаблон для Ubuntu VPS. Его можно взять за основу и адаптировать под свой проект.

Перед использованием замените

• ssh-ed25519 AAAA... на свой публичный SSH-ключ

• имя пользователя deploy, если нужно другое

• список открытых портов

• набор пакетов

• правила мониторинга

• Docker-блок, если контейнеры не нужны.

#cloud-confighostname: app-vps-01timezone: UTCusers: - default - name: deploy gecos: Deploy User groups: - sudo sudo: - ALL=(ALL) NOPASSWD:ALL shell: /bin/bash lock_passwd: true ssh_authorized_keys: - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIReplaceWithYourPublicKey admin@example.comssh_pwauth: falsedisable_root: truepackage_update: truepackage_upgrade: truepackages: - ca-certificates - curl - gnupg - lsb-release - git - htop - unzip - ufw - fail2ban - unattended-upgrades - prometheus-node-exporterwrite_files: - path: /etc/ssh/sshd_config.d/99-hardening.conf owner: root:root permissions: '0644' content: | PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yes KbdInteractiveAuthentication no X11Forwarding no MaxAuthTries 3 ClientAliveInterval 300 ClientAliveCountMax 2 - path: /etc/fail2ban/jail.d/sshd.local owner: root:root permissions: '0644' content: | [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5 findtime = 10m bantime = 1h - path: /etc/apt/apt.conf.d/20auto-upgrades owner: root:root permissions: '0644' content: | APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Periodic::AutocleanInterval "7"; - path: /usr/local/bin/server-health owner: root:root permissions: '0755' content: | #!/usr/bin/env bash echo "Hostname: $(hostname)" echo "Uptime: $(uptime -p)" echo echo "Disk:" df -h / echo echo "Memory:" free -h echo echo "Failed systemd units:" systemctl --failed --no-pagerruncmd: - systemctl reload ssh || systemctl reload sshd - ufw default deny incoming - ufw default allow outgoing - ufw allow OpenSSH - ufw allow 80/tcp - ufw allow 443/tcp - ufw --force enable - systemctl enable --now fail2ban - systemctl enable --now unattended-upgrades - systemctl enable --now prometheus-node-exporter - install -m 0755 -d /etc/apt/keyrings - curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc - chmod a+r /etc/apt/keyrings/docker.asc - . /etc/os-release && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu ${VERSION_CODENAME} stable" > /etc/apt/sources.list.d/docker.list - apt-get update - apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin - systemctl enable --now docker - usermod -aG docker deploy - echo "Cloud-init setup completed at $(date -Is)" > /var/log/first-boot-ready.logfinal_message: "VPS initial setup completed. Logs: /var/log/cloud-init-output.log" Этот шаблон не пытается решить все задачи сразу. Он делает другое: готовит безопасную и удобную основу, на которую уже можно ставить приложение.

Как проверить, что cloud-init отработал правильно

После создания VPS подключитесь по SSH: ssh deploy@SERVER_IP Если вход прошёл по ключу, первый важный этап уже выполнен. Проверьте статус cloud-init: cloud-init status --wait Посмотрите основной лог: sudo less /var/log/cloud-init-output.log Проверьте firewall: sudo ufw status verbose Проверьте Docker: docker versiondocker compose versiondocker run --rm hello-world Проверьте fail2ban: sudo fail2ban-client status sshd Проверьте базовое состояние сервера: server-health Если что-то пошло не так, начинайте с /var/log/cloud-init-output.log. Там обычно видно, на какой команде возникла ошибка. Cloud-init честно показывает свои следы - нужно только открыть правильный файл.

Частые ошибки при использовании cloud-init

Cloud-init сильно упрощает жизнь, но требует аккуратности. Большинство проблем возникает не из-за самого инструмента, а из-за мелких ошибок в конфиге.

Ошибка 1. Неправильный YAML

YAML чувствителен к отступам. Один лишний пробел может сломать весь блок. Плохая практика - писать большой конфиг прямо в панели без проверки. Лучше хранить файл локально и проверять его перед использованием.

Минимальная привычка

python3 -c 'import yaml,sys; yaml.safe_load(open(sys.argv[1])); print("YAML OK")' cloud-init.yml Если Python-модуль yaml не установлен, можно использовать любой YAML linter в редакторе.

Ошибка 2. Забыли заменить SSH-ключ

Шаблон со строкой ReplaceWithYourPublicKey выглядит очевидно, но в спешке такое забывают. Итог неприятный: парольный вход отключён, root отключён, ключ не работает. Перед созданием сервера проверьте ключ отдельно. Это тот случай, где 30 секунд внимательности спасают от пересоздания VPS.

Ошибка 3. Firewall включили раньше, чем разрешили SSH

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

Ошибка 4. Открыли наружу лишние Docker-порты

Команда вида: docker run -p 0.0.0.0:5432:5432 postgres публикует PostgreSQL наружу. Для теста это может показаться удобным, но для реального сервера лучше так не делать. Если база нужна только приложению на том же VPS, держите её во внутренней Docker-сети. Наружу обычно достаточно открыть 80 и 443 через reverse proxy.

Ошибка 5. Слишком большой cloud-init файл

Иногда в cloud-init пытаются засунуть всё: установку приложения, миграции базы, SSL, cron, деплой, мониторинг, резервное копирование и ещё десяток задач. Такой файл быстро становится хрупким.

Лучше разделить ответственность

• cloud-init готовит сервер

• Ansible, Docker Compose, GitHub Actions или другой инструмент деплоит приложение

• мониторинг и backup живут по отдельным правилам.

Cloud-init хорош как первый слой. Не нужно превращать его во всю инфраструктуру сразу.

Как адаптировать шаблон под разные сценарии

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

VPS под сайт или приложение

Обычно нужны

• 80 и 443 порты

• Docker

• reverse proxy

• автоматические обновления

• мониторинг

• отдельный deploy-пользователь.

Можно добавить установку nginx или caddy, если reverse proxy будет работать не в контейнере.

VPS под backend API

Здесь особенно важно не открывать внутренние порты приложения. Пусть наружу смотрит только reverse proxy, а само приложение слушает localhost или Docker-сеть. Хороший вопрос для проверки: “Может ли случайный человек из интернета подключиться к моему внутреннему сервису напрямую?” Если ответ “да”, конфигурацию стоит пересмотреть.

VPS под staging

Для staging часто хочется скорости, но не стоит полностью отказываться от безопасности. SSH-ключи, firewall и отдельный пользователь нужны даже там. Слабый staging иногда становится мостиком к production: забытый токен, открытая база, старый контейнер. Лучше сразу держать одинаковую базовую дисциплину.

VPS под эксперименты

Для временных серверов cloud-init особенно удобен. Можно быстро поднять VPS, проверить идею и удалить машину без сожаления. Главное - не использовать production-ключи и секреты в шаблоне для экспериментов. Тестовая среда должна быть дешёвой не только по деньгам, но и по рискам.

Где хранить cloud-init шаблоны

Cloud-init файл лучше хранить в Git. Тогда у вас появляется история изменений, review и понятная точка правды.

Пример структуры репозитория:

infra/ cloud-init/ ubuntu-docker-base.yml ubuntu-web-base.yml ubuntu-monitoring-node.yml README.md

В README можно указать

• для каких образов подходит шаблон

• какие порты открывает

• какие пользователи создаются

• какие переменные нужно заменить

• как проверить результат после первого запуска.

Это особенно полезно для командной работы. Через полгода никто не будет вспоминать, почему в шаблоне появился тот или иной пакет. Всё должно быть рядом с кодом.

Что не стоит хранить в cloud-init

Cloud-init часто передают в панель управления, API или Terraform. Поэтому не кладите туда секреты без необходимости.

Не стоит хранить прямо в файле

• приватные SSH-ключи

• токены CI/CD

• пароли баз данных

• API-ключи

• production-секреты приложения.

• Публичный SSH-ключ хранить можно. Он для этого и предназначен. А вот приватные данные лучше передавать через защищённые secret-хранилища, переменные окружения CI/CD или отдельный процесс деплоя.

Простое правило: если файл случайно попадёт в чужие руки, он не должен давать доступ к вашим системам.

Cloud-init и King Servers: удобный сценарий для клиентов VPS

Для клиентов VPS cloud-init полезен тем, что сокращает путь от “сервер создан” до “сервер готов к работе”. Вместо ручной настройки после каждого заказа можно использовать заранее подготовленный шаблон.

Практический сценарий выглядит так

• Вы выбираете подходящий VPS под задачу.

• Используете образ Linux, который поддерживает cloud-init.

• Передаёте user-data при создании сервера, если такая возможность доступна в вашем сценарии управления.

• Сервер запускается и автоматически применяет настройки.

• Вы подключаетесь уже к подготовленной машине.

Для бизнеса это означает меньше ручных операций. Для разработчика - меньше повторяющейся рутины. Для администратора - больше предсказуемости. Если вы поднимаете инфраструктуру регулярно, cloud-init быстро становится не “дополнительной опцией”, а нормальным способом начинать работу с новым VPS.

Финальный чек-лист перед использованием

Перед созданием VPS пройдитесь по короткому списку

• публичный SSH-ключ заменён на ваш

• имя пользователя указано правильно

• парольный вход действительно можно отключать

• SSH-порт разрешён в firewall

• открыты только нужные порты

• Docker нужен именно на этом сервере

• мониторинг не опубликован в интернет без ограничений

• cloud-init файл сохранён в Git

• шаблон проверен на тестовом VPS

• есть план восстановления доступа, если настройка не применится.

Этот чек-лист занимает минуту. Зато он помогает избежать самых неприятных ошибок.

Вывод

Cloud-init - один из тех инструментов, которые быстро становятся привычкой. Сначала он кажется просто способом автоматизировать пару команд, а потом незаметно превращается в основу нормальной серверной дисциплины. Хороший cloud-init шаблон готовит VPS к работе сразу после создания: добавляет SSH-ключи, создаёт пользователя, включает firewall, ставит пакеты, настраивает Docker, запускает мониторинг и закрывает базовые вопросы hardening. Такой сервер проще сопровождать, проще повторять и проще передавать между участниками команды. Начните с небольшого шаблона: доступ, firewall, обновления, Docker и проверка состояния. Потом добавляйте только то, что действительно нужно вашему проекту. Инфраструктура любит спокойную последовательность - и cloud-init отлично помогает её выстроить.