Cloudron на сервере: частые ошибки и решения

MAATRIX

Cloudron обещает «поставил и забыл»: панель сама тянет обновления, ставит SSL, гоняет бэкапы и следит за полусотней приложений из своего каталога. На практике первый же час после установки часто уходит на то, чтобы понять, почему домен не резолвится, почта не отправляется, а бэкап падает с невнятной ошибкой S3. Ниже — конкретные причины и то, как их устранить, без пересказа официальной документации.

Установка: с чего начинаются проблемы

Cloudron ставится одной командой на «чистый» сервер:

curl -L https://cloudron.io/cloudron-setup.sh | sudo bash

Ключевое слово — «чистый». Панель забирает себе порты 80 и 443 целиком, разворачивает собственный docker-стек и системные сервисы (mysql, postgres, mail-сервер) прямо на хосте. Если на сервере уже стоит nginx, Apache, другая панель управления (aaPanel, CyberPanel, Plesk) или самостоятельно поднятые контейнеры на 80/443 — установка либо падает на этапе проверки портов, либо стартует, но конфликтует с существующими сервисами непредсказуемо. Правило простое: под Cloudron — отдельный сервер или отдельная VM, без параллельных веб-серверов; общий выбор между панелью и голым сервером разобран в статье панель против чистого сервера.

Второй затык — минимальные требования по железу. Формально установщик стартует и на 1 ГБ RAM, но при установке 3-4 приложений (Nextcloud, почта, wiki) сервер начинает уходить в своп и подвисать. Рабочий минимум — 2 ГБ RAM и 20 ГБ диска, для 5+ приложений комфортнее 4 ГБ и 40-60 ГБ SSD. Если своп не создан заранее, установщик делает файл подкачки сам, но на медленном диске это ощутимо тормозит первые минуты установки.

Третье: нужен root-доступ по SSH и статический IPv4 — сервер за NAT или CGNAT не подойдёт, панель сама прописывает и проверяет DNS-записи.

DNS и wildcard-домен: почему панель не стартует после установки

Это самая частая причина «зависшей» установки. Cloudron требует домен (или поддомен), на который заведён wildcard-A-запись *.yourdomain.com, указывающая на IP сервера, плюс сам корень yourdomain.com. Если вы делаете это вручную у произвольного регистратора, типичные ошибки:

• забыли добавить именно wildcard-запись, а прописали только A yourdomain.com — тогда любое новое приложение на поддомене (nextcloud.yourdomain.com) не резолвится;
• DNS ещё не разошёлся (TTL старой записи), а установщик уже пытается достучаться до my.yourdomain.com — получаем таймаут на этапе первичной настройки;
• домен использует DNSSEC с несовместимыми параметрами у некоторых регистраторов — редко, но встречается.

Проще и надёжнее — доверить DNS самому Cloudron: панель умеет управлять зоной через API у Route53, Cloudflare, DigitalOcean, Gandi, Linode, Hetzner DNS, Vultr, OVH и ряда других провайдеров. Вы выдаёте Cloudron API-токен с правами на зону, и панель сама создаёт нужные A/TXT-записи под каждое приложение и под ACME DNS-01 challenge для SSL — это снимает добрую половину проблем с ручным DNS.

Проверить, что DNS реально смотрит куда надо, до запуска установщика:

dig +short yourdomain.com A
dig +short random-check.yourdomain.com A

Оба должны вернуть IP вашего сервера.

Порты, firewall и блокировка 25-го порта провайдером

Cloudron — это не только веб-панель, но и полноценный почтовый сервер (Postfix + Dovecot) для каждого домена. Список портов, которые должны быть открыты наружу:

Если у вас включён UFW или облачный firewall провайдера, все эти порты нужно открыть заранее — иначе Cloudron поднимется, но почта или ACME-проверка будут молча падать. Пример для UFW:

ufw allow 22,25,80,443,465,587,993,995,4190/tcp
ufw enable

Отдельная и очень частая боль — исходящий 25-й порт. Многие облачные провайдеры блокируют его по умолчанию на новых аккаунтах ради борьбы со спамом, и почта из Cloudron просто не уходит адресату без единой ошибки в логах приложения — письмо застревает в очереди Postfix:

docker exec mail postqueue -p

Если письма копятся, а postqueue -p показывает «connection timed out» на порт 25 удалённого сервера — это почти всегда блокировка на стороне вашего хостера, а не проблема конфигурации Cloudron. Перед установкой панели с собственной почтой стоит уточнить у провайдера, открыт ли исходящий SMTP-25 на тарифе.

Бэкапы: ошибки конфигурации S3-совместимого хранилища

Cloudron умеет бэкапиться локально на диск сервера или удалённо — в S3, Backblaze B2, DigitalOcean Spaces, Wasabi, Minio или по rsync/SFTP. По умолчанию настроен только локальный бэкап, и если забыть подключить внешнее хранилище, диск рано или поздно забивается собственными бэкапами — частая причина «сервер встал колом» через месяц-два эксплуатации.

Проверить занятое бэкапами место:

du -sh /home/yellowtent/backup 2>/dev/null
df -h

При настройке S3-совместимого хранилища через веб-интерфейс Cloudron (Settings → Backups) типичные ошибки:

• SignatureDoesNotMatch — неверный access key/secret key или регион в настройках не совпадает с реальным регионом бакета. Для не-AWS хранилищ (Backblaze, Wasabi, Minio) нужно указать правильный кастомный endpoint, иначе Cloudron стучится в стандартный AWS-эндпоинт;
• AccessDenied / 403 — у ключа нет прав на запись в бакет. Для AWS S3 нужна политика минимум с s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject;
• обрыв на середине большого бэкапа — на слабом аплинке бэкап нескольких GB Nextcloud с фото может не укладываться в таймаут; решение — расписание на ночное время;
• пустой бэкап при заполненном хранилище — обычно значит, что приложение было в состоянии ошибки на момент снятия; смотрите статус приложения в Dashboard перед тем как доверять бэкапу.

Тестовый прогон бэкапа лучше делать сразу после настройки хранилища, не дожидаясь расписания — кнопка «Backup Now» в интерфейсе, и сразу проверка, что архив реально появился в бакете.

SSL-сертификаты: rate limit и застрявшая проверка

Cloudron автоматически выпускает Let's Encrypt на каждое приложение при установке. Проблема вылезает, когда вы разворачиваете сразу много приложений подряд на одном домене: у Let's Encrypt действует лимит — 50 сертификатов на зарегистрированный домен в неделю и 5 дублирующих сертификатов на одно и то же имя за 7 дней. При частом пересоздании приложений («поставил-снёс-поставил заново тестируя») легко упереться в too many certificates already issued.

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

echo | openssl s_client -connect app.yourdomain.com:443 -servername app.yourdomain.com 2>/dev/null | openssl x509 -noout -issuer -dates

Если issuer — не Let's Encrypt, а самоподписанный «Cloudron temporary» сертификат, значит выпуск не прошёл и Cloudron откатился на временный. Частые причины отказа:

• домен ещё не резолвится в IP сервера (см. раздел про DNS выше) — ACME HTTP-01 challenge стучится на 80-й порт по этому же имени и не получает ответ;
• 80-й порт закрыт firewall'ом или блокируется провайдером;
• при DNS-01 challenge (для wildcard-сертификатов) — неверно указан API-токен DNS-провайдера или у токена не хватает прав на создание TXT-записи.

Повторный выпуск сертификата вручную для конкретного приложения делается через Dashboard → приложение → Certificate → Renew, это не требует пересоздания самого приложения. Если параллельно с Cloudron вы разбираетесь с Let's Encrypt на голом сервере для других проектов — логика rate limit там та же, ограничение общее для домена у Let's Encrypt, а не специфичное для Cloudron.

Приложения падают в ошибку или зависают при обновлении

Каждое приложение в Cloudron — отдельный Docker-контейнер, и «App is in error state» в интерфейсе — самое частое сообщение, с которым сталкиваются на практике. Диагностика начинается не с перезапуска, а с логов:

# список контейнеров приложений
docker ps -a | grep -v cloudron-

# логи конкретного приложения через встроенный CLI (если установлен)
cloudron logs --app <app-id> --lines 200

Либо тот же лог доступен прямо в веб-интерфейсе: Dashboard → приложение → Logs. Типичные причины падения:

• не хватило памяти при старте — особенно у Java- и Node-приложений с фиксированным heap size; в логах будет OOMKilled или exit code 137. Проверка: docker inspect <container> | grep OOMKilled. Решение — либо поднять RAM на сервере, либо (если приложение поддерживает) уменьшить лимиты памяти в его настройках через переменные окружения приложения;
• не хватило места на диске под образ — при обновлении Cloudron сначала тянет новый Docker-образ, а старый ещё не удалён, и на пике может требоваться в 1.5-2 раза больше места, чем занимает сама установка приложения. docker system df покажет, сколько места съедено неиспользуемыми образами;
• зависшая миграция базы данных при мажорном обновлении приложения — если апдейт приложения меняет схему БД и падает на середине, приложение остаётся в промежуточном состоянии. В таком случае откат к бэкапу, снятому непосредственно перед обновлением, обычно надёжнее, чем попытки руками докрутить миграцию;
• конфликт версий после ручного вмешательства в контейнер — если вы заходили в контейнер приложения и что-то правили напрямую (не через панель), следующее автообновление Cloudron может перетереть изменения или споткнуться о несовместимость. Все кастомизации, которые должны пережить обновление, стоит делать только через официально поддерживаемые hooks/env приложения, а не патчингом файлов внутри контейнера.

Если диск подъедается именно докер-слоями, а не бэкапами, пригодится разбор почему Docker занимает всё место на диске — те же команды docker system prune применимы и к хосту с Cloudron, только осторожно, не трогая тома (volumes) самих приложений.

Миграция на другой сервер и что при этом ломается

Рано или поздно встаёт вопрос переезда — с маленького тарифа на побольше или между локациями. У Cloudron есть встроенный механизм миграции: на новом сервере ставится чистый Cloudron, затем через Dashboard → System → Migrate указывается старый сервер, и панель сама переносит все приложения, данные и настройки. По сути это последовательность бэкапа и восстановления, обёрнутая в один процесс.

Что чаще всего идёт не так:

• DNS TTL — если не снизить TTL на A-записях заранее (за сутки-двое до переезда, выставив TTL 300), после переключения IP часть пользователей ещё долго будет попадать на старый сервер по закешированному DNS;
• несовпадение версий Cloudron — миграция между сильно разными версиями панели (например, пропущенными несколько мажорных релизов) может требовать промежуточного апдейта старого сервера перед переносом;
• почтовая репутация IP — при смене IP новый адрес обычно не имеет истории у почтовых провайдеров, и письма первое время чаще улетают в спам, пока не наберётся репутация или не будут донастроены SPF/DKIM/DMARC записи под новый IP.

Если переезд делается не встроенным механизмом, а вручную — через бэкап в S3 и восстановление, важно убедиться, что версия Cloudron на новом сервере совпадает или новее версии, с которой снят бэкап, иначе восстановление может отказать с ошибкой несовместимости формата.

Частые вопросы