ServerAdmin.ru
28.9K subscribers
304 photos
35 videos
13 files
2.63K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​До появления Proxmox Backup Server я часто отдавал предпочтение при выборе гипервизора Hyper-V из-за того, что для Proxmox VE не было функционального инструмента для бэкапов VM, кроме его встроенного средства, которое делало только полные бэкапы.

С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.

Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.

Сразу перечислю основные ограничения этого клиента:

бэкап только на уровне файлов или образов дисков, не системы целиком;
официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.

Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.

Ставим Proxmox Backup Client на Debian:

# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
# mcedit /etc/apt/sources.list.d/pbs-client.list
Вставляем туда для Debian 12
deb http://download.proxmox.com/debian/pbs-client bookworm main
Для Debian 11:
deb http://download.proxmox.com/debian/pbs-client bullseye main
Для Debian 10:
deb http://download.proxmox.com/debian/pbs-client buster main
Ставим клиента:
# apt update && apt install proxmox-backup-client

Теперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:

# proxmox-backup-client backup root.pxar:/ --repository 10.20.1.47:main

Здесь мы указали:
root.pxar - имя архива в формате pbs
/ - бэкапим корень системы
10.20.1.47 - адрес pbs сервера
main - имя datastore

По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория: user01@pbs@10.20.1.47. То есть мы указали созданного вручную пользователя user01@pbs.

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

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

# proxmox-backup-client snapshot list --repository 10.20.1.47:main
# proxmox-backup-client mount host/debian12-vm/2024-02-06T19:19:12Z root.pxar --repository 10.20.1.47:main /mnt/backup

Очень быстро и удобно. При желании бэкапы можно шифровать.

#proxmox #backup
Посмотрел вчера видео на тему проброса видеокарты в Proxmox:

▶️ Проброс видео карты в Proxmox

Я сам ни разу этого не делал, так как не было нужды. Вообще не припомню в своём управлении ни одного сервера с видеокартой. Для проброса видеокарты нужно:

1️⃣ Отредактировать параметры ядра хоста, отключить некоторые стандартные драйвера видеокарты.
2️⃣ Пересобрать initramfs хоста, перегрузить его.
3️⃣ Выбрать особые настройки VM, отключить у неё экран.
4️⃣ После этого добавить в неё видеокарту.

Меня удивила немного неочевидная настройка всего этого дела. А особенно отсутствие потом возможности подключиться к консоли VM с проброшенной видеокартой. Это типичная история для проброса видеокарты, или частный случай автора? Прямого доступа к консоли виртуалки с проброшенной картой реально не будет? Это неудобно. И не понятно, почему так получается.

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

p.s. Рекомендую канал и сайт автора. Там есть интересные и полезные материалы.

#proxmox
​​У браузера Firefox и всех остальных, что созданы на его основе, есть отличительная особенность, которая кому-то нравится, кому-то нет. Всё зависит от ситуации. У этого браузера своё собственное хранилище сертификатов, куда можно добавлять доверенные центры сертификации, минуя системное хранилище ОС. Для централизованного управления это скорее минус, а для индивидуального использования больше плюс.

Благодаря этому можно выделить отдельный портабельный браузер под какие-то прикладные задачи. Например, ходить на гипервизоры Proxmox без надоедливых предупреждений браузера о том, что нет доверия сертификатов.

Уже предвещаю комментарии на тему того, что надо настраивать ACME, создавать доменные имена и получать валидные сертификаты. Либо использовать какой-то обратный прокси для получения сертификатов и проксирования запросов.

Всё это можно сделать. Но, к примеру, у меня наберётся с десяток одиночных гипервизоров, где я не буду всего этого делать, потому что нет смысла. Доступ из интернета к ним открывать не буду. Я работаю с ними один, к ним нет доступа из интернета. Они принадлежат разным проектам и не объединены между собой. Мне проще забрать с этих гипервизоров pve-root-ca.pem, добавить в браузер, чтобы не засорять систему и сохранить учётки для быстрого входа. Доступ к ним всё равно закрыт списками IP адресов на файрволе.

Для того, чтобы настроить доверие для самоподписанного сертификата Proxmox, который создаётся во время установки гипервизора, надо зайти в веб интерфейсе в раздел System ⇨ Certificates. Выбрать сертификат pve-root-ca.pem, открыть его исходный текст. Скопировать и сохранить его в любой текстовый файл, указав ему расширение .crt.

Далее идём в браузер на основе Firefox. Я использую портированный LibreWolf. Переходим в Settings ⇨ Privacy & Security ⇨ Certificates ⇨ View Certificates. Там делаем Import сохранённого сертификата. Теперь из этого браузера при входе на веб интерфейс Proxmox не будет предупреждения. У вас появится возможность сохранить данные аутентификации.

#proxmox
​​На днях вышло обновление Proxmox 8.2, в котором появилось несколько интересных нововведений. Самое полезное на мой взгляд - импорт виртуальных машин из VMware ESXi. Я не сразу понял, как это реализовано. Обновил тестовый гипервизор, всё там пересмотрел и не нашёл импорт. Полез в документацию.

1️⃣ Работает он следующим образом. В списке Storage, доступных для добавления, появился новый тип - ESXi. Для добавления нужно указать его адрес и рутовую учётку. После этого в списке этого хранилища будут отображаться виртуальные машины хоста ESXi, откуда можно быстро выполнить импорт. Сделано удобно с минимум необходимых телодвижений. Жду, когда то же самое появится для Hyper-V. Лично для меня это более актуально.

2️⃣ Второе значительное изменение - появилась возможность в качестве встроенного файрвола использовать nftables, а не iptables. Пока это надо явно включить. Переход на nftables только прорабатывают, собирают обратную связь. В будущих релизах он заменит iptables окончательно. Так что можно потихоньку переползать. Кто не знаком с nftables, у меня есть небольшая статья по базовым правилам.

3️⃣ Третье важное дополнение. В настройках встроенных бэкапов появилась новая вкладка Advanced с дополнительными настройками процесса снятия бэкапов. Туда переехали настройки по ограничению ширины канала при бэкапе. А также добавилась новая настройка Backup fleecing, которая включает режим буферизации на локальный диск. Перед передачей на внешнее хранилище, бэкап работающей машины может кэшироваться на отдельном локальном storage, который можно выбрать из подключенных. Это снизит нагрузку на работающую VM во время снятия бэкапа и в целом ускорит процесс, так как кэшировать можно на наиболее ненагруженное хранилище. Возможно будет иметь смысл выделить отдельное хранилище под это дело.

Остальные изменения не такие существенные, поэтому перечислю их кратко:
появилась утилита proxmox-auto-install-assistant для подготовки установочного образа с готовыми настройками для установки без участия человека;
в веб интерфейс добавлена возможность настройки проброса устройств в lxc контейнеры;
в настройках ACME можно добавить любой другой удостоверяющий центр, отличный от Let's Encrypt;
изменились некоторые настройки веб интерфейса: не активируется режим редактирования полей при попытке скопировать данные оттуда, актуально, к примеру, для поля Notes с описанием VM, также изменилось положение кнопки с отменой введённых настроек.

Посмотреть, как все изменения выглядят в веб интерфейсе, можно вот в этом видео:

▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/whats-new-in-proxmox-ve-8-2

Нравится, как команда Proxmox оформляет все свои обновления. Максимально подробно и текстом, и в виде роликов. Другим компаниям бы брать пример.

#proxmox
​​Пока прошлые статьи писал про сертификаты и Proxmox, возник вопрос. А как добавить в доверенные сертификат от Proxmox Backup Server, чтобы браузер не ругался? У него почему-то нет CA сертификата в веб интерфейсе, как в VE, который можно добавить в доверенные.

Немного поискал информацию и нашёл в официальной wiki на эту тему отдельную статью. Меня в ней привлекло вот что. В самом конце рассматривается случай, когда PBS и VE стоят на одной машине (Using Certificates from Proxmox VE). Авторы предлагают для PBS использовать тот же сертификат, что и для VE.

Меня удивило, что сами разработчики допускают использование обоих продуктов на одном железе. Я слышал, что так можно сделать, но не думал, что это может быть рекомендованная комбинация. Но, судя по всему, разработчики вполне допускают такое использование этих двух продуктов. Я лично PBS запускаю в виртуалке на том же гипервизоре, когда мне это нужно. Не рискую ставить рядом на ту же систему, что и гипервизор. Опасаюсь каких-то подводных камней от такого использования.

Пошёл смотреть документацию по установке PBS. Там есть отдельный раздел Install Proxmox Backup Server on Proxmox VE. Так что технически никаких проблем нет. Можно ставить PBS на хост виртуализации. Есть единственное предупреждение:

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

Предупреждение очевидное. Надо это понимать. Лично мне локальные копии нужны, чтобы в случае чего оперативно восстановить виртуальную машину из локального бэкапа. Само собой, он не единственный.

В целом, я бы всё же не рекомендовал ставить на один хост и PBS, и VE. Мне кажется, лучше в виртуалке (или в lxc) поднимать. Я не сторонник что-то настраивать на самих гипервизорах. Тогда они становятся невзаимозаменяемыми. Если есть возможность, лучше всё переносить в виртуальные машины. Если умрёт сервер, то простое восстановление виртуальных машин из бэкапа вернёт всю функциональность. А если что-то на гипервизоре настроено, то надо восстанавливать, и предварительно бэкапить, его настройки. Где-то это может быть оправдано, где-то нет.

Я если что-то и делаю на гипервизоре, так это только iptables настраиваю с nat. Все настройки - это единственный конфиг для iptables. Нетрудно сохранить.

#proxmox
​​Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.

Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:

# apt install curl
# curl https://get.docker.com | bash -
# docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.

#proxmox #docker
​​Если вам приходится регулярно вручную создавать новые виртуальные машины в Proxmox для различных целей, то могу посоветовать простой и быстрый способ это автоматизировать. Для этого понадобится технология Cloud-Init, которую Proxmox поддерживает по умолчанию.

С помощью Cloud-Init в Proxmox можно автоматически добавить в виртуальную машину:

- пользователей, пароли, ключи для SSH
- настройки DNS
- сетевые настройки
- выполнить принудительное обновление пакетов

Технически это выглядит следующим образом.

1️⃣ Вы настраиваете виртуальную машину так, как вам нужно. Ставите нужные пакеты, настраиваете ПО, если надо. Отдельно устанавливаете пакет с cloud-init:
# apt install cloud-init
Можно использовать готовые образы уже с cloud-init внутри:
https://cloud.debian.org/images/cloud/
https://cloud-images.ubuntu.com/
https://dl.astralinux.ru/ui/native/mg-generic/alse/cloud/
Proxmox поддерживает готовые образы, сформированные для OpenStack.

2️⃣ Из этой виртуальной машины делаете эталонный шаблон средствами Proxmox (пункт меню convert to template).

3️⃣ Создаёте из этого шаблона виртуальную машину. Добавляете к ней отдельное устройство Cloudinit Drive.

4️⃣ В настройках виртуальной машины есть отдельный раздел Cloud-init, где можно индивидуально для конкретной машины задать перечисленные выше настройки.

Без Cloud-Init пришлось бы руками лезть в новую виртуалку и менять эти параметры. А так они аккуратно задаются через интерфейс управления и потом применяются. Работает просто и удобно. Настраивается тоже без проблем.

Описанная выше инструкция с техническими подробностями есть в Wiki Proxmox. Там же FAQ по этой теме:

- Cloud-Init Support
- Cloud-Init FAQ

Каких-то подводных камней в этой настройке нет. Делается всё просто и почти сходу. Я специально проверил после написания заметки. Всё получилось сразу же, как я описал. Шаблон сделал свой, не брал готовый.

#proxmox
​​Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.

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

А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.

То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:

# journalctl --vacuum-size=256M

Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.

Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.

Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.

#proxmox #backup
▶️ Всем хороших тёплых летних выходных. Желательно уже в отпуске в каком-то приятном месте, где можно отдохнуть и позалипать в ютуб. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными.

Установка Opnsense в Proxmox
Обзор популярного программного шлюза OPNsense, аналога pfSense. Практики в видео почти нет, в основном разговоры о самой системе и о софтовых шлюзах. Автор просто выполнил установку и самую начальную настройку.

Best operating system for Servers in 2024
Небольшой обзор современных гипервизоров и систем для решения различных задач. Интересно для расширения кругозора, если с чем-то не знакомы. Автор кратко рассказывает о VMware ESXi, Nutanix AHV, Proxmox VE, XCP-ng, Talos Linux, Flatcar Container Linux, Fedora CoreOS, Windows Server, TrueNAS Scale, Ubuntu, Debian, Qubes OS, Tails OS, Kali Linux.

Установка Kubernetes
Название ролика не соответствует содержанию. Самой установки там нет, но есть содержательная беседа трёх специалистов на тему Кубернетиса. Можно просто послушать, не смотреть, где-то в машине или метро.

Vaultwarden Свой менеджер паролей
Обзор популярного менеджера паролей для совместной работы с ними. Писал про него заметку. По ссылке подборка всех менеджеров паролей, что я обозревал.

The terminal WARS begins! // Warp vs Wave
Какие-то супер навороченные терминалы. Не слышал ни про первый, ни про второй. Да и пользоваться ими не буду. Навскидку, чтобы ими начать пользоваться, надо изучать, как Vim. Они его, кстати, заменяют. Не вижу большого смысла во всём этом для администрирования серверов. Но посмотреть было интересно. Там и шаринг кода, и AI помощник, и общие хранилища, и много всяких других фишек, помимо базовых. Позже выяснил, что их под винду и нет. Сборки только для Linux и MacOS.

Zabbix workshops: Zabbix proxy high-availability and load balancing
Zabbix workshops: New web monitoring features in Zabbix 7.0
Два больших ролика (~по часу) на заданные темы. Показаны практические примеры по настройке. То есть специалист сидит, настраивает на реальном мониторинге и нам рассказывает. Люблю такой формат, потому что тут конкретика. Смотреть просто так смысла нет, но если будете настраивать эти вещи, то видео очень пригодятся.

Meet ChangeDetection - A Self-Hosted Website Change Detector!
Подробный обзор очень интересной бесплатной системы мониторинга за сайтами, их состоянием и контентом. Заинтересовался этой штукой. Запланировал попробовать и написать заметку. Это не просто мониторинг, но и отслеживание изменений контента для различных задач. Например, можно следить за ценами, погодой, курсами и т.д.

#видео
​​Существует известный проект Turnkey Linux, который предлагает готовые преднастроенные образы Linux для решения конкретных задач - файловый сервер, веб сервер, впн сервер и т.д.. Я уже ранее писал про него. Там нет чего-то особенного, что с одной стороны хорошо, а с другой вроде и не надо особо. В основном там используется стандартное open source ПО с веб управлением через webmin. Всё это можно и самому настроить при желании, но тут это уже сделали за вас.

Особо нигде не афишируется, что Turnkey Linux интегрируется с Proxmox. Можно использовать готовые шаблоны LXC контейнеров Turnkey Linux в Proxmox. Для того, чтобы они появились в веб интерфейсе гипервизора, в разделе CT Templates, необходимо в консоли гипервизора выполнить команду:

# pveam update
update successful

После этого заходите в локальное хранилище с Container template и смотрите список доступных шаблонов. Увидите 110 шаблонов turnkeylinux.

Для каких-то тестовых задач или временных виртуалок неплохое решение, так как контейнеры разворачиваются очень быстро и не требуют начальных настроек. В несколько кликов можно запустить контейнер с DokuWiki, Nextcloud, OpenLDAP, Snipe-IT, ownCloud и т.д. И посмотреть на них.

#proxmox
Если вы используете динамический размер дисков под виртуальные машины, то рано или поздно возникнет ситуация, когда реально внутри VM данных будет условно 50 ГБ, а динамический диск размером в 100 ГБ будет занимать эти же 100 ГБ на гипервизоре.

Я раньше решал эту задачу для HyperV и виртуалок с Linux. Сейчас уже не помню точную реализацию, но смысл был в том, что незанятое пространство внутри VM надо было принудительно заполнить нулями и выполнить что-то со стороны гипервизора. Помню виртуалку в 500 ГБ, где реально использовалось 40 ГБ. Она была очень критичная, там был самописный call центр на базе Elastix. Интересно, кто-нибудь помнит его? Хороший был продукт для VOIP. Так вот, эта виртуалка занимала на диске гипервизора реальные 500 ГБ и не получалось её перенести в доступное для этого окно. Call центр почти круглые сутки работал. Ужать по размеру диска её не получилось, но когда она стала занимать реальные 40 ГБ, переносить её стало значительно проще и быстрее.

С Proxmox сейчас стало всё намного проще. Никаких ручных действий. Если у вас в виртуалках динамические диски, а это иногда оправданно для экономии места, когда есть возможность расселять виртуалки, когда на гипервизоре заканчивается место (так делают почти все хостеры VPS), то достаточно выполнить пару простых действий, чтобы виртуалки занимали тот объём, сколько реальных данных там есть.

Для этого можно воспользоваться официальным руководством:

Shrink Qcow2 Disk Files

Достаточно указать тип дискового контроллера Virtio-SCSI, а для самого диска установить параметр Discard. После этого внутри VM с Linux выполнить команду:

# fstrim -av

Все современные дистрибутивы Linux имеют systemd службу с fstrim и таймер для запуска. Диск на самом гипервизоре ужмётся до реального размера данных внутри VM. Проверить это можно так:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 1.32 GiB
cluster_size: 65536

Если внутри витуалки добавить занимаемый объём, то это сразу же будет видно на гипервизоре:

# dd if=/dev/urandom of=testfile bs=1M count=2048

Смотрим ещё раз на файл диска:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 3.32 GiB
cluster_size: 65536

Удаляем в виртуалке файл:

# rm testfile

Смотрим на размер диска:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 3.32 GiB
cluster_size: 65536

Ничего не поменялось. А если сделаем fstrim внутри VM, реальный размер диска уменьшится.

То же самое можно сделать и с уровня гипервизора, но для этого нужно будет выключить виртуальную машину, что неудобно, но иногда тоже может пригодиться. Это можно сделать с помощью утилиты virt-sparsify из комплекта libguests-tools:

# virt-sparsify --in-place vm-100-disk-0.qcow2

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

#proxmox #виртуализация
​​Я не так давно делал заметку про исчерпание свободного места на PBS (Proxmox Backup Server). Напомню, что если у вас закончилось свободное место, то нет штатной возможности освободить его здесь и сейчас, кроме как удалить весь Datastore полностью. Если вы просто удалите ненужные бэкапы, то придётся ждать сутки, когда они реально освободят занимаемое место.

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

Итак, чтобы моментально освободить место, занимаемое ненужными бэкапами, сделайте следующее:

1️⃣ Удалите лишние бэкапы в разделе Datastore ⇨ Content
2️⃣ Перейдите в консоль PBS и выполните там команду:

find /path2pbs-datastore/.chunks -type f -print0 | xargs -0 touch -d "-2 days"

3️⃣ Идём опять в веб интерфейс, выбираем наш Datastore и запускаем Garbage Collect.

Все удалённые бэкапы удалятся окончательно, освободив свободное место.

Поясню, что мы тут сделали. Я уже когда-то описывал возможности утилиты touch. С её помощью можно изменять параметры файла, меняя временные метки. Об этом рассказано тут и тут. Покажу на примере. Создадим файл и изменим дату его изменения на 2 дня назад:

# touch testfile
# stat testfile
# touch -d "-2 days" testfile
# stat testfile

После работы touch с ключом -d метка Modify уехала на 2 дня назад.

Если я всё правильно понимаю, то штатный процесс Garbage Collect удаляет все помеченные на удаление блоки со временем последнего изменения больше суток назад. Соответственно, меняя дату блоков на 2 суток назад, мы гарантированно провоцируем их удаление. Не совсем понимаю, почему нельзя было сделать отдельным пунктом GC удаление помеченных на удаление блоков здесь и сейчас, но как есть, так есть.

❗️Используйте это на свой страх и риск, когда отступать уже некуда. Я не знаю точно, к каким последствиям это может привести, но у меня сработало несколько раз ожидаемо. Я специально проверял по результатам работы GC. Если удалить некоторые бэкапы и сдвинуть дату всех блоков на 2 дня назад, то очередная работа GC удаляет только помеченные на удаление бэкапы. Верификация оставшихся бэкапов проходит нормально.

#proxmox
Как можно закрыть веб интерфейс Proxmox от посторонних глаз? Если, к примеру, вы арендуете одиночный сервер и он смотрит напрямую в интернет. Как вы понимаете, способов тут может быть очень много. Расскажу про самые простые, быстрые в настройке и эффективные. Они все будут проще, чем настроить VPN и организовать доступ через него.

1️⃣ Самый простой способ - настроить ограничение по IP с помощью настроек pveproxy. Я об этом подробно рассказывал в отдельной заметке. Достаточно создать файл /etc/default/pveproxy примерно такого содержимого:

ALLOW_FROM="192.168.13.0/24,1.1.1.1"
DENY_FROM="all"
POLICY="allow"

И после этого перезапустить службу:

# systemctl restart pveproxy.service

2️⃣ С помощью iptables. Если заранее не настроили iptables, то на работающем сервере лучше не пробовать настраивать, если у вас нет прямого доступа к консоли. Если файрвол вообще не настраивали, то в общем случае понадобятся два правила:

/usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
/usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

Первое разрешает подключения из подсети 192.168.13.0/24 и ip адреса 1.1.1.1. Второе правило запрещает все остальные подключения к веб интерфейсу. Правила эти можно сохранить в файл и подгружать во время загрузки сервера или явно прописать в /etc/network/interfaces примерно так:

auto enp5s0
iface enp5s0 inet static
address 5.6.7.8/24
dns-nameservers 188.93.17.19 188.93.16.19
gateway 5.6.7.1
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

Если уже есть другие правила, то их надо увязывать вместе в зависимости от ситуации. Тут нет универсальной подсказки, как поступить. Если не разбираетесь в iptables, не трогайте его. Используйте другие методы.

Я сам всегда использую iptables. Настраиваю его по умолчанию на всех гипервизорах. Примерный набор правил показывал в заметке.

3️⃣ Вы можете установить Nginx прямо на хост с Proxmox, так как по своей сути это почти обычный Debian. У Nginx есть свои способы ограничения доступа по ip через allow/deny в конфигурации, либо по пользователю/паролю через basic auth. Бонусом сюда же идёт настройка TLS сертификатов от Let's Encrypt и доступ по 443 порту, а не стандартному 8006.

Ставим Nginx:

# apt install nginx

Настраиваем базовый конфиг /etc/nginx/sites-available/default:

server {
listen 80 default_server;
server_name _;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
return 301 https://5.6.7.8;
}
server {
listen 443 ssl;
server_name _;
ssl_certificate /etc/pve/local/pve-ssl.pem;
ssl_certificate_key /etc/pve/local/pve-ssl.key;
proxy_redirect off;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://localhost:8006;
proxy_buffering off;
client_max_body_size 0;
}
}

Разрешили подключаться только с указанных адресов. Это пример с использованием стандартных сертификатов. Для Let's Encrypt нужна отдельная настройка, которая выходит за рамки этой заметки. Для того, чтобы закрыть доступ паролем, а не списком IP адресов, необходимо настроить auth_basic. Настройка легко гуглится по ключевым словам nginx auth_basic, не буду об этом рассказывать, так как не умещается в заметку. Там всё просто.

Этот же Nginx сервер можно использовать для проксирования запросов внутрь виртуалок. Удобный и универсальный способ, если вы не используете отдельную виртуалку для управления доступом к внутренним ресурсам.

После настройки Nginx, доступ к веб интерфейсу по порту 8006 можно закрыть либо через pveproxy, либо через iptables.

#proxmox
В продуктах Proxmox не так давно появилась возможность использовать сторонние SMTP сервера для отправки уведомлений. Точнее, стало возможно через веб интерфейс настроить аутентификацию на внешнем сервере. В PVE вроде бы с 8-го релиза появилась эта настройка, в PBS не помню точно.

В разделе меню Notification обоих продуктов появился новый тип уведомлений SMTP, где можно указать привычные параметры внешних почтовых серверов. Тем не менее, если для отправки используется бесплатный почтовый сервис типа Yandex, Mail или Gmail, я предпочитаю настраивать по старинке через локальный Postfix, который так же использует внешний SMTP сервер с аутентификацией.

Причина этого в том, что через Postfix отправляются и другие системные сообщение, плюс есть нормальное логирование, где можно сразу понять, если по какой-то причине письма не будут отправляться. У Postfix очень информативный лог. Его и мониторить удобно, и решать возникающие проблемы.

Настройка Postfix простая. Не помню, устанавливается ли он в свежих версиях PVE и PBS по умолчанию, но если нет, то надо поставить:

# apt install postfix

И затем добавить в конфиг /etc/postfix/main.cf, например, для Яндекса:

relayhost = smtp.yandex.ru:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_generic_maps = hash:/etc/postfix/generic


Если эти же параметры где-то выше уже объявлены, то закомментируйте их там. Создаём файл /etc/postfix/sasl_passwd такого содержания:

smtp.yandex.ru user01@yandex.ru:userpass123

Эти данные нужны для аутентификации. Убедитесь, что у файла права 600, чтобы никто, кроме рута, не смог его прочитать.

Создайте файл /etc/postfix/generic:

root@pve user01@yandex.ru

Здесь мы настраиваем, чтобы все письма от локального пользователя root сервера с именем pve отправлялись с заменой адреса отправителя на user01@yandex.ru. Иначе Яндекс не примет письмо к отправке. У других почтовых сервисов может не быть таких ограничений и этот шаг можно будет пропустить.

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать postfix, и перезапускаем его:

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Можно проверять отправку. Проще всего это сделать в веб интерфейсе PVE. Для этого идём в раздел Datacenter ⇨ Notification. Там по умолчанию уже есть способ отправки типа sendmail с указанным Target mail-to-root. Это как раз отправка почты с помощью Postfix на ящик системного пользователя root@pam. Ящик для него можно указать в настройках пользователя: Datacenter ⇨ Permissions ⇨ Users ⇨ root ⇨ E-Mail.

Выбираем способ отправки sendmail и жмём Test. Можно сходить в консоль сервера и проверить лог отправки. Если всё прошло успешно, то в /var/log/mail.log будет примерно следующее:

pve postfix/pickup[941603]: 4C81718E07A1: uid=0 from=<user01@yandex.ru>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<user01@yandex.ru>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<superadmin@yandex.ru>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=0.48, delays=0.03/0.02/0.17/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net 1724185545-jPUEPlgXtGk0-KOiggjh6)
pve postfix/qmgr[941604]: 4C81718E07A1: removed


Сервер успешно использовал relay=smtp.yandex.ru и отправил с его помощью письмо superadmin@yandex.ru, получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

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

#proxmox
Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

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

#sso #nginx
iptables-proxmox.sh
4.8 KB
Поискал по каналу и не нашёл ни одной заметки, где бы я рассказал и показал на практике, как я настраиваю iptables на гипервизорах Proxmox. Я всегда в обязательном порядке это делаю. Не утверждаю, что так, как настраиваю я, правильно и наиболее подходящий вариант. Просто привык делать именно так, проблем с этим не было, поэтому закрепилось. Воспроизвожу из раза в раз эту настройку.

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

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

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

В наборе правил пример с работающего сервера. На основе него можете сформировать свой набор правил. Я там некоторые правила закомментировал, так как нужны они будут не всем. Оставил их для примера.

Формирую набор правил именно в таком виде, потому что он мне кажется удобным и наглядным. Можно быстро оценить все правила, оставить комментарии, что-то добавить.

#proxmox #iptables
В Proxmox 7.3 без особых подробностей завезли обновление со следующим описанием: Framework for remote migration to cluster-external Proxmox VE hosts. По факту добавили экспериментальную возможность по миграции виртуальных машин между гипервизорами (не только кластерами).

Реализована миграция с помощью консольной команды qm remote-migrate. Подробности реализации можно посмотреть в соответствующем коммите в репозитории. Описание команды в документации скудное. Не особо понятен итоговый формат работающей команды.

qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]

Я разобрался, как это работает. У меня получилось выполнить миграцию между разными гипервизорами. Показываю, как это работает. Итоговая работающая команда выглядит следующим образом:

# qm remote-migrate 120 120 'host=10.20.1.65,apitoken=PVEAPIToken=root@pam!token1=0ace469b-9c8d-4f05-ba84-d720414129ee,fingerprint=16:21:AB:AE:A3:06:92:BB:E9:F8:25:C2:A1:53:26:7F:67:29:1B:A9:A9:1C:D1:3B:A7:47:BD:23:9F:E8:7C:6B' --target-bridge vmbr0 --target-storage local-lvm

▪️120 120 - ID виртуалки на исходном гипервизоре и желаемое ID на том, куда переносим. Я оставил одинаковые.
▪️10.20.1.65 - IP адрес принимающего гипервизора
▪️root@pam!token1 - имя токена token1 для пользователя root@pam
▪️0ace469b-9c8d-4f05-ba84-d720414129ee - секрет указанного выше токена
▪️vmbr0 - сетевой бридж на принимающем гипервизоре
▪️local-lvm - хранилище дисков на принимающем гипервизоре
▪️16:21:AB:AE:A3:06:92:BB:E9:F8:25:C2:A1:53:26:7F:67:29:1B:A9:A9:1C:D1:3B:A7:47:BD:23:9F:E8:7C:6B - fingerprint сертификата pve-ssl.pem принимающего гипервизора

Для того, чтобы миграция прошла успешно, нужно на принимающем сервере создать токен. Делается это в разделе Datacenter Permissions API Tokens. После создания вы получите имя в виде root@pam!token1, где root@pam - пользователь, а token1 - указанное имя токена. И само значение секрета этого токена. Далее в разделе Datacenter Permissions нужно добавить API Token Permissions. Я выбрал существующий токен и дал ему полные права. Не разбирался, какие нужны для миграции. Думаю, нужны права на создание виртуалок и дисков в хранилище.

Отпечаток сертификата можно посмотреть в разделе Node System Certificates. Надо выбрать стандартный pve-ssl.pem, два раза кликнуть по нему мышкой и скопировать Fingerprint.

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

Работает всё довольно удобно. Поддерживается миграция из разных типов хранилищ. Я для теста с обычного LVM переехал в LVM-Thin на другой гипервизор. По факту сначала происходит копирование диска, а потом перенос его в нужное хранилище на принимающей стороне через query-disk-import. Отсюда можно сделать вывод, что должен быть запас по доступному месту на принимающем гипервизоре в двойном размере от объёма диска. Это нужно учитывать при переносе.

Если у вас много виртуалок, которые надо перекинуть на другой гипервизор, то можно пользоваться. Один раз настроил и перенёс все виртуалки со всеми настройками и дисками.

После миграции исходная VM будет заблокирована. Если захотите её запустить на старом гипервизоре, то разблокируйте:

# qm unlock 120

#proxmox

🦖 Selectel — дешёвые и не очень дедики с аукционом!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными и полезными.

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

Настройка DNS over HTTPS в OPNsense
Небольшой ролик про DNS over HTTPS для тех, кто не знает, что это такое и как работает. Тут автор кратко рассказал о технологии и на практике показал, как это работает и как настраивается на своём софтовом шлюзе OPNsense.

Netbird Update - How to add the new "Relays" feature to your netbird install.
Рассказ про бесплатную, open source платформу для построения VPN сетей - netbird.io. Вышло крупное обновление продукта. Автор рассказал, как его установить и что в нём нового. Вообще, это интересный продукт. Я видел его обзор у разных блогеров, писал заметку про него. Один из лучших open source проектов из этой области.

Vinchin - Backup система для ВСЕГО!
Обзор системы для бэкапа Vinchin. Автор прошёлся по основным возможностям. Я в своё время примерно то же самое оформил в отдельную статью на сайте. Система, в принципе, неплохая. Мне понравилась.

Building a Low-Power, Fully Loaded Plex Server
Подробное описание сборки сервера под популярный медиасервер Plex для дома. Автор поставил задачу собрать тихий и маломощный в плане потребления электричества сервер на базе Mini ITX. Интересно посмотреть, что у него в итоге получилось.

Администрирование Линукс. Стабильность и безопасность системы
Короткое видео с наглядным примером эксплуатации уязвимости ярда Linux CVE-2024-1086. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.

#видео
Когда только начинал работать с виртуализацией на Linux, очень хотелось сесть за сервер и прямо на нём что-то сделать. Но на тот момент ни XenServer, ни VmWare не позволяли это сделать. На экране сервера был небольшой список простых действий типа настроек сети или перезагрузки. И ничего, что относилось бы к управлению виртуальными машинами. После экспериментов с VMware Workstation и Hyper-V было как-то непривычно и неудобно.

Для управления гипервизором нужно было сесть за какое-то рабочее место, поставить соответствующий клиент и через него подключаться для управления. В Proxmox с этим сейчас попроще, так как управление через браузер. Но тем не менее, он тоже не позволяет локально что-то с ним сделать. В связи этим не возникает проблем в обычной эксплуатации. А вот если вы используете Proxmox в каких-то необычных задачах, то может возникнуть желание подключить к нему монитор и выполнять настройки прямо тут же.

В Proxmox решить эту задачу очень просто. Под капотом там обычная система Debian, на которую можно установить графическую оболочку. Более того, как это сделать, рассказано в официальной Wiki проекта. Там это названо так:

Developer Workstations with Proxmox VE and X11

Всё, что вам надо сделать, так это установить туда xfce, браузер и менеджер управления графическими оболочками в системе. Предупреждаю, что делать это на продуктовых серверах - плохая практика.

Выполняем непосредственно гипервизоре:

# apt install xfce4 chromium lightdm

Добавляем пользователя, от имени которого мы будем заходить и подключаться к веб интерфейсу:

# adduser webuser

Запускаем графическую оболочку:

# systemctl start lightdm

Можно подключать монитор к серверу, заходить в систему и подключаться к локальному веб интерфейсу по адресу https://localhost:8006.

Вроде мелочь, а на самом деле удобная возможность. Я одно время хотел дома организовать рабочую станцию, чтобы семейные могли работать локально, а я иногда запускать тестовые виртуальные машины в случае необходимости. Решил в итоге задачу через RDP подключение к системе, даже когда на ней кто-то локально работает. Обычная винда позволяет превратить себя в мини-терминальник. Но это отдельная история.

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox
Для автоматизации установки и настройки виртуальных машин в Proxmox я рассказывал про Cloud-Init. С помощью этой технологии можно создать преднастроенный образ, который включает в себя базовые настройки системы, такие как сеть, пользователи, установка пакетов и некоторые другие.

Если хочется пойти дальше в автоматизации и развернуть сразу набор виртуальных машин определённой конфигурации, то для этого можно воспользоваться Terraform. Для Proxmox есть провайдер (terraform registry доступ через vpn, github). Это самый популярный. Есть ещё один, который очень активно развивается и допиливается - terraform registry и github.

Кратко поясню, для тех, кто не знает, что такое Terraform и для чего он может быть полезен в связке с Proxmox. Terraform был разработан как решение по управлению в стиле IaC (Infrastructure as Code, IaC) - инфраструктура как код. В первую очередь это касается управления ресурсами облачных провайдеров. Вы описываете в Terraform, что хотите получить на выходе, запускаете шаблон и получаете набор виртуальных машин, сетей и прочих облачных ресурсов. Причём вы можете оперативно как развернуть инфраструктуру, так и потушить. Это актуально для динамических сред с плавающей нагрузкой. Часто Terraform работает в связке с Ansible. Первый разворачивает инфраструктуру, второй её настраивает.

Proxmox не является инструментом для построения динамичных облачных инфраструктур. Его область применения - одиночные гипервизоры или небольшие кластеры на несколько серверов. По моим представлениям в проде на базе Proxmox нет большой нужды использовать Terraform. Он может быть актуален для каких-то тестовых задач как по изучению самого Terraform, так и для разворачивания тестового окружения в Proxmox. Можно разом развернуть какую-то лабораторию и потом так же в одно действие от неё избавиться.

Использование Terraform с Proxmox выглядит примерно следующим образом. Это не будет готовой инструкцией, так как в формат заметки не уместить. Все подробности без проблем гуглятся, так как тема живая. В целом, Terraform относительно простой инструмент. Чтобы начать им пользоваться достаточно небольшой инструкции или видео. Можно брать готовые шаблоны из статей или документации и править под себя.

1️⃣ Готовится образ с использованием Cloud-Init, на базе которого будет разворачиваться инфраструктура.
2️⃣ Создаётся отдельный пользователь и токен для него, который будет использовать Terraform.
3️⃣ Устанавливается Terraform или Opentofu (форк).
4️⃣ Создаётся конфигурация с провайдером и планон разворачивания инфраструктуры. Будут 2 файла: provider.tf и vm-debian12.tf. Содержимое прикреплю следующим сообщением. По желанию можно все переменные вынести в отдельный файл.

Пример конфигурации можно посмотреть в репозитории. После подготовки конфигурации, её можно проверить:

# terraform init
# terraform validate

Посмотреть, что будет создано:

# terraform plan

Если всё ОК, то создаём описанное:

# terraform apply

Когда всё это будет не нужно, удаляем:

# terraform destroy

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

Как я уже говорил, инструмент относительно простой. Я быстро во всём разобрался и протестировал. Единственный неприятный нюанс - репозитории terraform и opentofu заблокированы для РФ. Пришлось трафик через VPN пускать. У меня всё автоматизировано для этого. Отправил домены registry.terraform.io, apt.releases.hashicorp.com и registry.opentofu.org через VPN на шлюзе.

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox #iac #terraform
Please open Telegram to view this post
VIEW IN TELEGRAM