1. Ставим docker прямо в PVE
Мы же знаем, что PVE построен поверх debian, а мы же не хотим создавать лишние слои виртуализации, поэтому для docker приложений ставим докер в PVE, можем сразу развернуть runtipi и portainer.
Если потом все упадет потому что закончилось место в корневом разделе, то можно будет просто переустановить PVE с нуля, а при обновлении PVE на новую версию мы скрещиваем пальцы и скрещенными пальцами жмем Enter, это на 99% снижает количество конфликтов
2. Используем для всего, чего только возможно Community Scripts
Мы же доверяем порядочности разработчика, надежности РКН и вере в тех. поддержку этого решения.
- Развернуть фотогалерею или сервис с документами - 5 минут работы helper scripts и вообще не надо ни в чем разбираться
- Ходить по форумам и спрашивать как вернуть потерянные терабаты личных фоток – бесценно
3. Устанавливаем доп. софт на сервер
Мы же помним, что PVE построен на основе debian, значит можно вкорячить туда еще и PBS, менеджер информационной панельки, какие-то левые репозитории и т.д.
Мы же уверены, что никаких конфликтов не будет, все будет замечательно обновляться, а переход с PVE 8 на PVE 9 будет с полпинка, падение, сбитые коленки, вопросы на форуме, переустановку
4. 1 мощный сервер лучше, чем несколько слабых
Proxmox придумали кластеризацию для лохов, настоящие пацаны крутят все на одном сервере, так и администрировать удобней и не надо следить за ресурсами.
А поскольку, у нас настоящий серверный многопоточный xeon, крутой X99 чипсет, который уже у дедов наших в сервере стоял, до того, как его вырезали болгаркой и запаяли газовой горелкой в на нашу супер-пупер материнку от дядюшки Ляо, а все это запитывает супер надежный KCAS, то вероятность потерять все одномоментно стремится к 0, как говорится, “серая причка” это вам “серая птичка”
Ну а если у нас не китайский сервер, а породистый HP/IBM/SuperMicro, то вероятность выхода вообще отрицательная, поэтому держим все яйца в одной корзине
5. Бэкапы это сложно, а PVE - круто
PVE ипользует супер-надежную ZFS, механизмы высокой доступности, миграции виртуализцию, а виртуализация же вообще творит чудеса.
- Поэтому, совсем не обязательно создавать резервные копии наших виртуалок и контейнеров.
- А бэкапирование PVE это вообще сложно, у нас же всего 1 сервер и непонятно куда деать бэкап, будем надеяться, что ничего не сломается
6. Используем плоскую сеть и не включаем фаервол
Виртуализация же защищает от вирусов, брутфорса, зловредов.
Поэтому ограничивать доступ к админке PVE, замыкать виртуалки в отдельной закрытой сети совсем не обязательно, можно даже открыть ssh и веб интерфейс PVE в интернет, чтобы удобно было администрировать нашу систему из любой точки мира
7. Во всю используем LLM и советы блогеров в интернете
Чем больше вы внесете изменений в PVE, тем лучше. Proxmox же не знаю как лучше сделать, поэтому находим какой-нить скрипт в итернете и запускаем под рутом, удаляем local-lvm и переходим на использование local
В общем, нет времени разбираться в работе гипервизора, надо как можно быстрее выполнить пошагово первую поавшуюся инструкцию, поэтому, это у меня последний пункт и я пошел искать чтобы еще накатить
Кстати, установку pve-test внутри pve или вообще pve и pdm в формате docker контейнеров придумали очень странные люди, намного же логичней делать все сразу на боевом сервере!
8. Ansible это сложно
Настраивать свой кластер руками гораздо быстрее, нежели готовить Ansible плейбуки или испоьзовать любые другие инструменты IaC.
Тем более, что мы помним все настройки, которые выполняли на нашем сервере и вслучае его выхода из строя мы без пробем сможем настроить новый сервер буквально за 2 щелчка перчаткой Таноса
9. Отсутствие мониторинга и уведомлений
Уведомления только отвлекают, поэтому, нет мысла настраивать отправку уведомлений самим PVE, не надо ставить сервис мониторинга хоста и сервисов. Когда будет реальная проблема пользователи сами сообщат об этом.
А ZFS вообще работает идеально и можно не следить за SMART метриками дисков
10. RAID для продакшина это слишком сложно
Современные китайские SSD от бренда “серая птичка” настолько надежны, что продолжают работать даже после выхода из строя, поэтому, нет смысла бэкапировать все и вся, а если наш сервер, который использует 1000 пользователей и сломается, то мы всегда сможем развернуть новый и накатить базу данных с компа разработчика
11. RAID надежней бэкапов
Бэкапы имеют определенный лаг по времени, занимают место, в общем, куча недостатков
Хранение виртуалок на RAID0, а пользовательских данных на RAID5 позволяет иметь 100% надежность и отпадает необходимость в бэкапировании, даже rm -rf / перестает работать в виртуалке, которая запушена на RAID0, там специальный флаг выставляется (кажется, но это не точно, но “верь мне” (c))
12. Тестовые контуры для слабаков
Это очень скучно, гораздо удобней и быстрее сразу обновлять весь кластер с PVE8 на PVE9 командой for host in pve-prod-1 pve-prod-2 pve-prod-3 ; do ssh $host apt update; apt upgrade; done
А поскольку, LXC в PVE самые надежные, то можно аналогичным образом сразу обновлять и все контейнеры, а если такой однострочник слишком сложный, то всегда можно добавить в cron соответствующий helper script - лишним для прода точно не будет
13. Достаточно вообще 1 виртуалки
- Ставим PVE
- Ставим Runtipi при помощи helper скрипта
- Получаем готовое решение для установки практически любого сервиса
Храним там все наши фотки, документы - любую важную информацию
В крайнем случае, если все сломается, то можно будет спросить совета как все починить.
И незачем заводить отдельные виртуалки и контейнеры, заниматься этой бесполезной виртуализацией и все такое, главное, не обновлять runtipi очень часто - раз в 1-2 года будет самое то
