🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлые года: 2023 и 2024.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.
📌 Больше всего пересылок:
◽️Скрипт для проверки доступности ресурсов через VPS (600)
◽️Тренажёр для изучения регулярных выражений (489)
◽️Обучающая платформа для сисадминов и девопсов (440)
📌 Больше всего комментариев:
◽️Очередная заметка про проверку бэкапов (285)
◽️Бесплатные системы виртуализации (234)
◽️Обсуждение поссийских дистрибутивов Linux (175)
📌 Больше всего реакций:
◽️Пожелания в день сисадмина (337)
◽️Скрипт для проверки доступности ресурсов через VPS (232)
◽️Построение схемы инфраструктуры на основе DNS записей (226)
📌 Больше всего просмотров:
◽️ Песня НТР - Хуяк, хуяк и в продакшн (11826)
◽️ Sudo в Windows (10025)
◽️ Опросы на тему операционных систем (9667)
Мне понравилась идея с опросами. Планирую теперь каждый месяц проводить какой-нибудь опрос на тему использования it-специалистами тех или иных инструментов и технологий. Подобрал уже несколько тем для ближайших опросов. Если у вас есть какие-то пожелания по этой теме, то предлагайте в комментариях. Пока на очереди системы виртуализации, системы мониторинга, веб сервера, текстовые редакторы, оконные менеджеры.
#топ
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.
📌 Больше всего пересылок:
◽️Скрипт для проверки доступности ресурсов через VPS (600)
◽️Тренажёр для изучения регулярных выражений (489)
◽️Обучающая платформа для сисадминов и девопсов (440)
📌 Больше всего комментариев:
◽️Очередная заметка про проверку бэкапов (285)
◽️Бесплатные системы виртуализации (234)
◽️Обсуждение поссийских дистрибутивов Linux (175)
📌 Больше всего реакций:
◽️Пожелания в день сисадмина (337)
◽️Скрипт для проверки доступности ресурсов через VPS (232)
◽️Построение схемы инфраструктуры на основе DNS записей (226)
📌 Больше всего просмотров:
◽️ Песня НТР - Хуяк, хуяк и в продакшн (11826)
◽️ Sudo в Windows (10025)
◽️ Опросы на тему операционных систем (9667)
Мне понравилась идея с опросами. Планирую теперь каждый месяц проводить какой-нибудь опрос на тему использования it-специалистами тех или иных инструментов и технологий. Подобрал уже несколько тем для ближайших опросов. Если у вас есть какие-то пожелания по этой теме, то предлагайте в комментариях. Пока на очереди системы виртуализации, системы мониторинга, веб сервера, текстовые редакторы, оконные менеджеры.
#топ
Telegram
ServerAdmin.ru
🎄🔝 Под конец года имеет смысл подвести некоторые итоги. В повседневной жизни я не привык это делать. Обычно только доходы/расходы анализирую. А вот в разрезе канала было интересно посмотреть итоги.
Я подготовил ТОП публикаций за прошедший год. Это было…
Я подготовил ТОП публикаций за прошедший год. Это было…
👍30👎2
В свете недавних обсуждений гипервизоров вспомнил, как я начинал изучение KVM. До него работал с Xen и Hyper-V. Первым делом стал разбирать вопрос бэкапа виртуальных машин наживую, без их остановки. Это было более 10-ти лет назад и простых решений не существовало. Proxmox не помню, был уже тогда или нет, но я про него не знал. Использовал всё это в консоли с помощью virsh, и в GUI с помощью virt-manager.
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
Вы должны увидеть строки с упоминанием файла
Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Я изучил вопрос и разобрался, как делать снепшоты при использовании файлов qcow2 для дисков виртуальных машин, и как снимать с них бэкапы. Всё это обернул в очень простой скрипт без каких-то дополнительных проверок. Оформил всё это в статью.
Уже не помню, в чём там был нюанс, но при некотором стечении обстоятельств можно было потерять образы дисков. Вроде бы если по какой-то причине не создался снепшот, то скрипт, не найдя его, удалял сам образ машины. Лично с таким не сталкивался, потому что очень внимательно проверял работу до того, как включал реальное удаление. А вот в комментариях отписались люди, которые диски потеряли, хотя я обо всём этом предупреждал в статье. Сначала всё тщательно проверяем - потом включаем удаление.
Напомню один важный нюанс. Если вы случайно удалили образы VM, а сами машины до сих пор работают, то восстановить всё это относительно просто. Я видел отзывы, когда люди только через неделю или две замечали, что удалили диски VM, а сами машины при этом работали. Покажу на примере, как это выглядит.
Допустим, у нас работает виртуальная машина с диском в виде файла
vm-109-disk-0.qcow2 и этот файл по какой-то причине был удалён в момент работы VM. То есть машина работает, а файла уже нет. Поверяем, реально ли файл удалён, но всё ещё открыт его дескриптор:# lsof | grep '(deleted)'kvm 402083 root 14u REG 0,39 21478375424 17 /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Вы должны увидеть строки с упоминанием файла
/var/lib/vz/images/109/vm-109-disk-0.qcow2. Значит, он реально ещё не удалён. Его держит процесс с пидом 402083. Проверяем это:# ls -l /proc/402083/fd | grep deletedlrwx------ 1 root root 64 Aug 3 21:16 14 -> /var/lib/vz/images/109/vm-109-disk-0.qcow2 (deleted)Да, файловый дескриптор на месте и имеет номер 14. Скопируем из него данные обратно в файл:
# cp /proc/402083/fd/14 /var/lib/vz/images/109/vm-109-disk-0.qcow2Какое-то время будет длиться копирование. После этого файл будет возвращён на место. Так как копирование не моментальное, диск виртуальной машины может немного пострадать. Если там есть СУБД, то может нарушиться целостность базы, но не обязательно. Большую часть ошибок сможет починить обычный fsck. По сравнению с полной потерей виртуалки это будут небольшие трудности.
Пример универсальный и будет актуален для любых ситуаций, когда удалён файл, который открыт каким-то процессом. Пока процесс запущен и держит этот файл, его можно без проблем восстановить. Вот если завершить процесс, то задача сильно усложниться и шансов восстановить информацию будет уже значительно меньше, хотя в некоторых случаях тоже будет реально.
❗️Сохраните заметку в закладки, может пригодиться в самом неожиданном случае. У меня бывало, что по ошибке удалял конфиг работающей программы. Казалось бы, вот он только что был, ты его грохнул, а как сразу же вернуть, не знаешь, надо вспоминать.
#restore #linux #terminal
Server Admin
Бэкап виртуальных машин KVM без остановки VM
Описание различных подходов к бэкапу виртуальных машин в kvm в зависимости от типа дисков. Представлен скрипт для автоматического бэкапа.
5👍142👎4
Хорошего DevOps-инженера непросто найти, трудно недооценить и ещё сложнее — заменить. Спрос на специалистов стабильно превышает предложение, а зарплаты — в числе самых высоких в IT.
Если хотите развиваться в профессии с высоким потенциалом, начните с курса Нетологии «DevOps-инженер с нуля». Уже через 6 месяцев вы сможете трудоустроиться сисадмином, параллельно осваивая навыки DevOps.
В результате научитесь:
👉 работать с Docker, Kubernetes, Jenkins и Git;
👉 настраивать CI/CD и мониторинг инфраструктуры;
👉 администрировать Linux, Windows и базы данных;
👉 использовать облачные технологии и микросервисы.
Вас ждут минимум 4 проекта в портфолио, бесплатный доступ к Yandex Cloud и 10 QA-сессий с экспертами из Alibaba Group, ВКонтакте и Ozon, где сможете задать любые вопросы о профессии.
А чтобы быть ещё конкурентоспособнее, вы подтянете английский и познакомитесь с основами Python.
Сейчас на курс действует скидка 40% — записывайтесь 💡
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5yvgeLR
Если хотите развиваться в профессии с высоким потенциалом, начните с курса Нетологии «DevOps-инженер с нуля». Уже через 6 месяцев вы сможете трудоустроиться сисадмином, параллельно осваивая навыки DevOps.
В результате научитесь:
👉 работать с Docker, Kubernetes, Jenkins и Git;
👉 настраивать CI/CD и мониторинг инфраструктуры;
👉 администрировать Linux, Windows и базы данных;
👉 использовать облачные технологии и микросервисы.
Вас ждут минимум 4 проекта в портфолио, бесплатный доступ к Yandex Cloud и 10 QA-сессий с экспертами из Alibaba Group, ВКонтакте и Ozon, где сможете задать любые вопросы о профессии.
А чтобы быть ещё конкурентоспособнее, вы подтянете английский и познакомитесь с основами Python.
Сейчас на курс действует скидка 40% — записывайтесь 💡
Реклама. ООО "Нетология". ИНН 7726464125 Erid 2VSb5yvgeLR
👎30👍7
На днях в очередной раз настраивал Proxmox Backup Server (PBS) в режиме синхронизации бэкапов между двумя разнесёнными хранилищами. Там есть некоторые нюансы с правами пользователей, которые приходится уточнять в документации, так что решил написать пошаговую инструкцию. Плюс, поделиться информацией для тех, кто ещё не настраивал подобное, либо вообще не знает о такой возможности.
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
1️⃣ На pbs-remote идём в Configuration -> Access Control и создаём пользователя, под которым будет подключаться pbs-local. Велик соблазн везде использовать root и полные права, но не рекомендую так делать. Тут же в разделе Permissions добавляем новому пользователю следующие права:
{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
2️⃣ На pbs-local идём в Configuration -> Remotes и добавляем pbs-remote, используя созданную выше учётную запись.
3️⃣ На pbs-local в разделе Configuration -> Access Control -> Permissions для пользователей локальных Datastore, которые будут синхронизироваться, добавьте права:
4️⃣ На pbs-local идём в Datastore, выбираем тот, что хотим синхронизировать. Переходим в раздел Sync Jobs и добавляем задачу Add Push Sync Job. Выбираем добавленный на шаге 2 remote и выбираем остальные параметры, в том числе расписание синхронизации.
На этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
Path: /datastore/{store}Role: DatastoreBackup{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
Path: /remoteRole: RemoteSyncPushOperatorНа этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
13👍202👎2
На днях обновились два продукта Proxmox, которые я активно использую: Virtual Environment 9.0 и Backup Server 4.0. Прежде чем перейти к содержанию обновлений, сделаю предупреждение. Не торопитесь обновлять свои сервера. У Proxmox есть некоторый шанс получить проблемы после обновления, особенно для большого обновления со сменой релиза Debian. Я сам лично много раз сталкивался с ними. Делал тут по этому поводу заметки. Плюс, опыт других людей говорит о том же.
Расскажу про своё отношение к обновлению гипервизоров. Если рядом нет подменного сервера, на который можно быстро восстановить работу виртуальных машин, то я его не обновляю без веских оснований. Процесс этот откладываю на максимально комфортное время, когда это можно сделать. Обычно какие-то длинные праздники, типа майских или новогодних. То же самое для кластера. Обновлять надо очень аккуратно и понимать, что ты будешь делать, если он вдруг не переживёт обновление. Уронить прод от неаккуратного обновления гораздо проще, чем получить проблемы от каких-то уязвимостей, которых во-первых, не так много, чтобы это было опасно в закрытом контуре, во-вторых, обновления приходят регулярно и если постоянно обновляться по мере их выхода, то частота этого процесса сама по себе по теории вероятности принесёт рано или поздно проблемы.
Соответственно, вы либо держите тестовый контур, там всё проверяете и регулярно обновляетесь, либо изыскиваете какие-то другие подходы к этому процессу, более безопасные и растянутые во времени. Опять же, если нет чего-то срочного и критичного. Для Proxmox вообще такого не припоминаю. В интернет они у меня никогда не смотрят, и доступ к ним ограничен. Ещё раз подчеркну, что этот подход используется только для гипервизоров. Не для виртуальных машин с рабочей нагрузкой. Их можно относительно безопасно обновлять, так как масштаб бедствия несоизмерим, если что-то пойдёт не так.
📌Ключевые обновления Proxmox VE:
🔥Обычные LVM тома, не Thin, теперь поддерживают снэпшоты. У меня это самый популярный формат хранения. Из-за того, что он не поддерживал снепшоты, иногда приходилось использовать qcow2 диски, но они не очень удобны из-за ряда особенностей. В описании указано, что хранилища типа Directory, NFS, и CIFS тоже получили такую функциональность. Но по описанию я не очень понял, относится ли это, к примеру, к RAW дискам, расположенным в директории. Из описания вроде бы да (Directory, NFS, and CIFS storages also gain additional support for snapshots as volume chains), но я не понимаю, как это технически реализовано. Надо будет на практике проверять. Вроде бы автоматически создаётся qcow2 файл для накопления изменений относительно базового диска.
◽️Добавлена функциональность SDN Fabric для построения отказоустойчивых управляемых и динамически маршрутизируемых сетей. У меня таких вообще нет, так что попробовать не придётся. Это в основном актуально для больших кластеров.
◽️Дополнительные графики с метриками. Будет полезно. Я частенько их смотрю для беглой оценки работы VM.
◽️Новый мобильный веб интерфейс. Лично я им вообще не пользуюсь. Заходил очень редко в исключительных ситуациях. Не знаю, зачем он нужен. Изредка можно и версию для ПК открыть.
Из основного это всё. Как я понимаю, триггером для релиза был переход на Debian 13, поэтому непосредственно в функциональности изменений немного.
📌 Ключевые обновления Proxmox BS:
🔥Поддержка S3-совместимых хранилищ. Этого реально не хватало. Подобные хранилища очень популярны и относительно дёшевы. Теперь можно спокойно брать дедики с небольшими локальными дисками и подключать более дешёвые S3 хранилища.
◽️Автоматический запуск синхронизации при подключении съёмного хранилища. Можно руками подключить внешний диск или подключить скриптами и бэкап на него будет автоматически синхронизирован. Потом его можно отмонтировать.
◽️Много мелких исправлений в интерфейсе, в уведомлениях, в очистке старых данных и некоторых других моментах.
Я наверное первые обновления сделаю, когда выйдут версии 9.1 и 4.1.
#proxmox
Расскажу про своё отношение к обновлению гипервизоров. Если рядом нет подменного сервера, на который можно быстро восстановить работу виртуальных машин, то я его не обновляю без веских оснований. Процесс этот откладываю на максимально комфортное время, когда это можно сделать. Обычно какие-то длинные праздники, типа майских или новогодних. То же самое для кластера. Обновлять надо очень аккуратно и понимать, что ты будешь делать, если он вдруг не переживёт обновление. Уронить прод от неаккуратного обновления гораздо проще, чем получить проблемы от каких-то уязвимостей, которых во-первых, не так много, чтобы это было опасно в закрытом контуре, во-вторых, обновления приходят регулярно и если постоянно обновляться по мере их выхода, то частота этого процесса сама по себе по теории вероятности принесёт рано или поздно проблемы.
Соответственно, вы либо держите тестовый контур, там всё проверяете и регулярно обновляетесь, либо изыскиваете какие-то другие подходы к этому процессу, более безопасные и растянутые во времени. Опять же, если нет чего-то срочного и критичного. Для Proxmox вообще такого не припоминаю. В интернет они у меня никогда не смотрят, и доступ к ним ограничен. Ещё раз подчеркну, что этот подход используется только для гипервизоров. Не для виртуальных машин с рабочей нагрузкой. Их можно относительно безопасно обновлять, так как масштаб бедствия несоизмерим, если что-то пойдёт не так.
📌Ключевые обновления Proxmox VE:
🔥Обычные LVM тома, не Thin, теперь поддерживают снэпшоты. У меня это самый популярный формат хранения. Из-за того, что он не поддерживал снепшоты, иногда приходилось использовать qcow2 диски, но они не очень удобны из-за ряда особенностей. В описании указано, что хранилища типа Directory, NFS, и CIFS тоже получили такую функциональность. Но по описанию я не очень понял, относится ли это, к примеру, к RAW дискам, расположенным в директории. Из описания вроде бы да (Directory, NFS, and CIFS storages also gain additional support for snapshots as volume chains), но я не понимаю, как это технически реализовано. Надо будет на практике проверять. Вроде бы автоматически создаётся qcow2 файл для накопления изменений относительно базового диска.
◽️Добавлена функциональность SDN Fabric для построения отказоустойчивых управляемых и динамически маршрутизируемых сетей. У меня таких вообще нет, так что попробовать не придётся. Это в основном актуально для больших кластеров.
◽️Дополнительные графики с метриками. Будет полезно. Я частенько их смотрю для беглой оценки работы VM.
◽️Новый мобильный веб интерфейс. Лично я им вообще не пользуюсь. Заходил очень редко в исключительных ситуациях. Не знаю, зачем он нужен. Изредка можно и версию для ПК открыть.
Из основного это всё. Как я понимаю, триггером для релиза был переход на Debian 13, поэтому непосредственно в функциональности изменений немного.
📌 Ключевые обновления Proxmox BS:
🔥Поддержка S3-совместимых хранилищ. Этого реально не хватало. Подобные хранилища очень популярны и относительно дёшевы. Теперь можно спокойно брать дедики с небольшими локальными дисками и подключать более дешёвые S3 хранилища.
◽️Автоматический запуск синхронизации при подключении съёмного хранилища. Можно руками подключить внешний диск или подключить скриптами и бэкап на него будет автоматически синхронизирован. Потом его можно отмонтировать.
◽️Много мелких исправлений в интерфейсе, в уведомлениях, в очистке старых данных и некоторых других моментах.
Я наверное первые обновления сделаю, когда выйдут версии 9.1 и 4.1.
#proxmox
6👍89👎1
Главные по контейнеризации в России приглашают на второй митап Deckhouse User Community.
21 августа | Москва
Приходите, если работаете с Kubernetes или планируете начать. Разберём три практических кейса:
→ как DKP управляет узлами кластера — от создания до вывода из кластера;
→ как построить платформу обучения на Community Edition быстрее ванильного Kubernetes;
→ как автоматизировать контроль архитектуры с помощью фитнес-функций.
Будет полезно инженерам эксплуатации, платформенным разработчикам и всем, кто хочет прокачать навыки работы с современными подходами в DevOps.
Только офлайн. Пицца и нетворкинг в программе. Регистрируйтесь!
21 августа | Москва
Приходите, если работаете с Kubernetes или планируете начать. Разберём три практических кейса:
→ как DKP управляет узлами кластера — от создания до вывода из кластера;
→ как построить платформу обучения на Community Edition быстрее ванильного Kubernetes;
→ как автоматизировать контроль архитектуры с помощью фитнес-функций.
Будет полезно инженерам эксплуатации, платформенным разработчикам и всем, кто хочет прокачать навыки работы с современными подходами в DevOps.
Только офлайн. Пицца и нетворкинг в программе. Регистрируйтесь!
👍13👎7