Облачные Linux-боксы на Dockup: 7 вариантов дистрибутивов

Облачные Linux-боксы предоставляют среду операционной системы, которую вы настраиваете через SSH. Они подходят для экспериментов, устаревшего ПО, пользовательских системных сервисов, build-хостов и задач, жизненный цикл которых не связан напрямую с Git-репозиторием или образом контейнера.

Dockup поддерживает семь вариантов образов: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 и Rocky Linux 9.

Когда Linux-бокс лучше контейнерного сервиса?

Выбирайте бокс, если задаче нужен контроль над операционной системой, а не только над процессом приложения.

Подходящие примеры:

• Установка нескольких системных daemon'ов.
• Интерактивное тестирование пакетов операционной системы.
• Запуск устаревшего приложения с ручной настройкой.
• Поддержка build- или automation-хоста.
• Воспроизведение Linux-окружения клиента.
• Запуск долгоживущих инструментов, не организованных как Git-деплой.
• Создание временного изолированного SSH-окружения.

Выбирайте сервис Dockup, если задача представляет собой воспроизводимое приложение с репозиторием, build-командой, start-командой, health endpoint и потребностью в горизонтальном масштабировании.

Требование	Linux-бокс	Контейнерный сервис
Кастомизация ОС на уровне root	Отличный вариант	Изменения нужно добавить в Dockerfile
Администрирование по SSH	Нативная поддержка	Interactive shell — PRO
Автоматический деплой через Git push	Настраивается вручную	Встроен
Blue-green health gate	Проектируется вручную	Встроен
Воспроизводимый образ	Нужны runbook или script	Dockerfile/Nixpacks
Autoscaling	Не предусмотрен моделью бокса	Доступен вариант с Kubernetes
Быстрое тестирование дистрибутивов	Отличный вариант	Может быть достаточно базового образа

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

Какие семь дистрибутивов Linux доступны?

Запросите текущий список образов:

dockup box images --json

Образ	Экосистема пакетов	Типичная причина выбора
ubuntu-22.04	APT	Долгосрочная совместимость
ubuntu-24.04	APT	Более новая база Ubuntu LTS
debian-12	APT	Консервативный универсальный сервер
alpine-3.20	apk	Небольшая среда на базе musl
fedora-40	DNF	Более новые Linux-инструменты
almalinux-9	DNF	Совместимость с Enterprise Linux
rockylinux-9	DNF	Совместимость с Enterprise Linux

Подбирайте дистрибутив в соответствии с поддерживаемой средой, указанной поставщиком ПО. Alpine использует musl вместо glibc, что может повлиять на работу предварительно собранных нативных бинарных файлов. Дистрибутивы Enterprise Linux подходят, когда ПО ожидает соответствующую экосистему пакетов.

Запишите точный slug образа. Названия «Ubuntu» недостаточно, поскольку версии пакетов и сроки поддержки для 22.04 и 24.04 различаются.

Как создать облачный Linux-бокс?

Создайте бокс, указав образ, имя, объём памяти и CPU:

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

В этом примере запрашиваются 2 048 МБ RAM и 1 vCPU. Начните с измеренных требований и корректируйте параметры на основе фактической нагрузки. Использование CPU, RAM и диска вычитается из баланса тарифа с поминутным учётом.

Тариф Free стоит $0 в месяц и включает стартовый кредит $10, одно workspace, три базы данных и три деплоя. Платные тарифы позволяют использовать неограниченное количество ресурсов, однако фактическое потребление вычислительных ресурсов по-прежнему списывается из включённого баланса. Рекомендуемый тариф Pro стоит $20 в месяц и включает кредит $20 на использование.

Созданный бокс становится ресурсом проекта со стабильным target, например production/build-host. Сохраните этот target в runbook.

Как получить и защитить доступ по SSH?

Запросите данные для подключения:

dockup box ssh production/build-host --json

В ответе содержатся host, port, user и password. Относитесь к password как к конфиденциальным данным. Храните его в одобренном password manager, не выводите в ответе агента и меняйте или заменяйте доступ в соответствии с политикой организации.

Перед подключением:

1. Проверьте project и slug бокса.
2. Убедитесь, что оператор имеет необходимые права.
3. Зафиксируйте цель сессии.
4. Не копируйте production-секреты на временный бокс.
5. Не допускайте появления credentials в истории команд и логах.
6. Закройте неиспользуемые пути доступа и сессии.

Доступ по SSH даёт широкие полномочия внутри бокса. Coding agent с этими credentials может устанавливать пакеты, изменять сервисы, открывать порты или удалять файлы. Предоставляйте агенту доступ только для проверенной узкой задачи и сохраняйте audit record за пределами shell.

В статье Production guardrails для AI-агентов описана модель автономности.

Как запускать SSH-задачу на Linux-боксе?

Получив доступ по SSH, настройте запуск процесса с помощью поддерживаемых инструментов операционной системы. В Ubuntu, Debian, Fedora, AlmaLinux и Rocky Linux обычно используется systemd; Alpine применяет собственные правила управления сервисами.

В конфигурации запуска нужно указать executable, рабочий каталог, runtime user, необходимые environment variables, restart policy и место назначения логов. Храните credentials за пределами unit file или startup script и используйте абсолютные пути, чтобы поведение не зависело от interactive shell.

Проверьте следующее:

• Задача запускается после перезагрузки без входа оператора в систему.
• Необходимое окружение доступно без exports, заданных только в shell.
• Для логов определено известное расположение.
• Процесс работает от имени нужного пользователя.
• Отказы можно обнаружить.
• Обновления не заменяют зависимости незаметно.

Если для одного web-процесса нужны именно такие возможности, контейнерный сервис на основе Git уже может обеспечивать более подходящий жизненный цикл.

Как эксплуатировать и пересобирать Linux-бокс?

Считайте каждую ручную команду потенциальным конфигурационным дрейфом. Фиксируйте настройку в script или процессе управления конфигурацией:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Этот общий пример не является командой Dockup; он показывает, как сделать конфигурацию бокса воспроизводимой. Если для задачи важна стабильность, фиксируйте версии пакетов или документируйте их.

Runbook бокса должен включать:

• Slug образа.
• Запрошенные CPU и объём памяти.
• Установленные пакеты и репозитории.
• Учётные записи пользователей и SSH policy.
• Расположение файлов в filesystem.
• Startup service, executable и рабочий каталог.
• Открытые сервисы и способы их аутентификации.
• Метод резервного копирования данных.
• Процедуру установки патчей и перезагрузки.
• Шаги пересборки.
• Критерии миграции или вывода из эксплуатации.

Не предполагайте, что filesystem бокса поддерживает тот же workflow создания snapshot, что и volume сервиса Dockup, если этот workflow явно не настроен и не поддерживается для данного ресурса. Проектируйте резервное копирование с учётом фактически запущенных данных и ПО.

Когда задачу следует перенести в контейнер?

Переходите к контейнерному сервису, если:

• Настройка превратилась в стабильный script.
• Основное назначение — один процесс приложения.
• Изменения исходного кода должны деплоиться из Git.
• Нужны релизы без простоя с health gate.
• Для rollback достаточно выбрать предыдущий deployment ID.
• Требуется несколько одинаковых реплик.
• Конфигурация бокса меняется в зависимости от оператора.
• SSH используется только для ручного повторного деплоя.

Перенесите настройку в Dockerfile, задайте порт приложения и health path, а затем сначала разверните preview- или non-production-сервис. Сравните поведение, прежде чем отключать бокс.

Руководство Nixpacks и Dockerfile поможет выбрать новый метод сборки. В статье Kubernetes и Docker объясняются варианты размещения runtime.

Чек-лист выбора Linux-бокса

Надёжное решение об использовании облачных Linux-боксов должно дать ответы на следующие вопросы:

1. Какой из семи slug образов соответствует поддержке поставщика?
2. Почему задаче не подходит обычный сервис?
3. Как защищаются SSH credentials?
4. Как воспроизводится настройка?
5. Где находятся логи и постоянные данные?
6. Как тестируются патчи?
7. Какой процесс должен запускаться автоматически?
8. Какое событие должно привести к контейнеризации или выводу из эксплуатации?

Используйте справочник Dockup CLI, чтобы узнать актуальные команды для боксов и список образов. Для задач, работающих только в Windows, сравните вариант Windows VM с RDP.

Контролируйте доверие к пакетам и репозиториям

Бокс может установить любой пакет, который запросит оператор, поэтому источники пакетов становятся частью границы безопасности. Используйте подписанные репозитории дистрибутива, документируйте сторонние репозитории и не передавайте непроверенные сетевые script напрямую в root shell.

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

Оценивайте, оправдано ли дальнейшее использование бокса

Каждый месяц анализируйте частоту SSH-сессий, количество ручных шагов деплоя, требования к uptime, использование ресурсов и случаи дрейфа конфигурации. Если релизы приложения регулярно выполняются через SSH, это сигнал о необходимости воспроизводимого workflow сервиса.

Проверяйте потребление CPU, RAM и диска боксом в app.dockup.ai и сопоставляйте данные с runbook. Облачные Linux-боксы полезны, когда требуется контроль над ОС; с операционной точки зрения они становятся дорогими, когда лишь скрывают недокументированный деплой приложения.

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

При создании тестового бокса назначьте владельца и дату окончания его использования. Перед выводом из эксплуатации экспортируйте только одобренные постоянные данные, удалите скопированные credentials, сохраните пригодный для повторного использования setup script и убедитесь, что от хоста больше не зависят DNS, scheduled job или командный runbook.

Так короткий эксперимент не превратится в постоянно работающий сервер без патчей.

Назначьте владельца экстренного доступа

Назначьте человека или команду, ответственную за доступ, если обычный оператор SSH недоступен. Резервный владелец должен знать, где хранятся credentials и как проверить точный target, не передавая пароли.

Сохраняйте обоснование

Документируйте, почему облачные Linux-боксы по-прежнему необходимы.

Начните с проверяемого деплоя

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

Начните бесплатно на app.dockup.ai. Тариф Free стоит $0 в месяц, включает стартовый кредит $10, одно workspace, три базы данных и три деплоя.

Часто задаваемые вопросы

Какие дистрибутивы Linux можно использовать в боксах Dockup?

Dockup поддерживает ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 и rockylinux-9.

Как получить SSH credentials для Linux-бокса?

Выполните dockup box ssh с точным target проекта и бокса и параметром --json, затем безопасно сохраните полученные данные для подключения.

Как запускать ПО после настройки SSH?

Настройте запуск с помощью поддерживаемого service manager выбранного дистрибутива и задокументируйте executable, рабочий каталог, runtime user, environment, restart policy и логи.

Когда контейнерный сервис лучше Linux-бокса?

Используйте контейнерный сервис, если задача представляет собой одно воспроизводимое приложение, которому нужны деплой из Git, health gates, rollback и autoscaling.

Как тарифицируются ресурсы Linux-бокса?

Потребление CPU, RAM и диска измеряется поминутно и списывается из баланса тарифа, поэтому отслеживайте фактическое использование и не выделяйте ресурсы с избыточным запасом.