Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
Сделал фс ext4 и смонтировал:
Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
Далее взял fio и прогнал тесты с его помощью:
Линейное чтение:
Линейная запись:
Пиковые IOPS случайной записи:
Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.
Нарезал там LV для хоста:
# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON# lvcreate -L 10G -n test_raid10 raid10Сделал фс ext4 и смонтировал:
# mkfs.ext4 /dev/SSD-RADEON/test_ssd# mkfs.ext4 /dev/raid10/test_raid10# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON# mount /dev/raid10/test_raid10 /mnt/raid10Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:
# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=directДалее взял fio и прогнал тесты с его помощью:
Линейное чтение:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10Линейная запись:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10Пиковые IOPS случайной записи:
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:
▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)
Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.
Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.
Честно говоря думал, что по диску просадка будет больше в виртуальных машинах. А на практике она очень незначительная. Часто выбирают контейнеры, чтобы минимизировать разницу в производительности дисков, так как там хранилище прямо с хоста подключается. Для себя большого смысла не увидел в этом, если это единственный довод в пользу контейнера. Предпочту развернуть нагрузку в VM, как более универсальное решение, если не стоит задача максимальной плотности размещения для утилизации процессора и памяти.
#proxmox #disk #perfomance
Google Docs
Тесты дисков
2👍125👎4
Завершу тему с тестированием дисков информацией про кэширование в Proxmox VE. У него стандартный набор режимов, которые будут плюс-минус такие же и у рейд контроллеров. Сделаю в формате небольшой шпаргалки, а подробности с картинками есть в документации.
▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.
▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.
Железный рейд контроллер без батарейки обычно работает в таком же режиме.
▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.
▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.
Если у вас настроен UPS, сервер корректно завершает работу в случае пропадания питания, и в целом стабильно работает, без проблем и аварийных завершений, то можно использовать этот режим для всех виртуальных машин. Железный рейд контроллер с батарейкой обычно работает в этом же режиме.
▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.
❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.
🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #disk
▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.
▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.
Железный рейд контроллер без батарейки обычно работает в таком же режиме.
▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.
▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.
Если у вас настроен UPS, сервер корректно завершает работу в случае пропадания питания, и в целом стабильно работает, без проблем и аварийных завершений, то можно использовать этот режим для всех виртуальных машин. Железный рейд контроллер с батарейкой обычно работает в этом же режиме.
▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.
❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.
🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #disk
5👍150👎1
За что больше всего люблю дистрибутив Debian, так это за его консерватизм. Много лет назад я написал статью на сайте:
⇨ Как настроить сетевые параметры в Debian
Последние 5 лет вообще её не трогал. А она не потеряла актуальность и популярность. Последние 2 года это самая посещаемая статья сайта. Каждый день по 200-300 посетителей приходят её прочитать. А за всё время её посмотрели сотни тысяч раз. Если прикинуть, то это большой масштаб. И таких статей много. То, что я написал, прочитали уже миллионы людей. Вроде сидишь себе, что-то пишешь. А тебя читает столько народа. В уникальное время живём. Надо это ценить.
Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на
Если вы автор сайта, пишите статьи и хотите, чтобы их читали, пройдите какой-нибудь онлайн курс по SEO. Это поможет вам писать статьи так, чтобы их поисковики ставили в выдачу повыше других. Это не значит, что придётся с чем-то мухлевать или кого-то вводить в заблуждение. Вы просто поймёте, как поисковики видят ваш сайт и статьи на нём, и что надо делать, чтобы поисковые системы ставили вас в выдаче повыше.
Статью можно использовать новичкам как шпаргалку. Там есть вся база:
◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе
Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в
▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.
Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:
То вы не только потеряете все полученные по dhcp настройки, но и статические адреса. Соответственно, вас отключает по ssh. Для меня это было сюрпризом. Такие вещи надо делать осторожно, имея доступ к консоли сервера напрямую.
#debian #network
⇨ Как настроить сетевые параметры в Debian
Последние 5 лет вообще её не трогал. А она не потеряла актуальность и популярность. Последние 2 года это самая посещаемая статья сайта. Каждый день по 200-300 посетителей приходят её прочитать. А за всё время её посмотрели сотни тысяч раз. Если прикинуть, то это большой масштаб. И таких статей много. То, что я написал, прочитали уже миллионы людей. Вроде сидишь себе, что-то пишешь. А тебя читает столько народа. В уникальное время живём. Надо это ценить.
Собрался с силами и переработал статью, актуализировал. Перенёс все настройки на
ip, замерив ifconfig и route. Давно серьёзно не занимался сайтом и контентом нём. Это забирает очень много времени. Нет возможности его выделять. Одна переработка заняла целый день. А если писать с нуля, то нужно ещё больше времени. Для того, чтобы подобная статья вышла в топ поисковиков, приходится работать с SEO, надо это знать. Из-за этого текст выглядит немного косоязычно. Но если этого не сделать, то текст заберут другие сайты, добавят SEO и статья от них уйдёт в ТОП. Так что лучше самому сразу сделать так, как надо. Если вы автор сайта, пишите статьи и хотите, чтобы их читали, пройдите какой-нибудь онлайн курс по SEO. Это поможет вам писать статьи так, чтобы их поисковики ставили в выдачу повыше других. Это не значит, что придётся с чем-то мухлевать или кого-то вводить в заблуждение. Вы просто поймёте, как поисковики видят ваш сайт и статьи на нём, и что надо делать, чтобы поисковые системы ставили вас в выдаче повыше.
Статью можно использовать новичкам как шпаргалку. Там есть вся база:
◽️статические и динамические настройки ip адресов
◽️dns и hostname
◽️статические маршруты
◽️vlan
◽️отключение ipv6
◽️несколько адресов на одном интерфейсе
Узнал для себя некоторые новые вещи, на которые раньше не обращал внимание. Например, 2 типа активации сетевого интерфейса в
/etc/network/interfaces:▪️auto - интерфейс активируется при загрузке системы. Это подходящая настройка для статичного сетевого адаптера.
▪️allow-hotplug - интерфейс поднимается, когда подсистема udev обнаружит его. Это произойдёт и при загрузке системы, как в случае с auto, если сетевая карта будет подключена, и в случае подключения, отключения устройства. Например, если это usb сетевая карта или VPN туннель. Настройка больше подходит для динамических сетевых интерфейсов.
Ещё интересный момент. Если сбросить dhcp lease через консоль соответствующей командой:
# dhclient -rТо вы не только потеряете все полученные по dhcp настройки, но и статические адреса. Соответственно, вас отключает по ssh. Для меня это было сюрпризом. Такие вещи надо делать осторожно, имея доступ к консоли сервера напрямую.
#debian #network
Server Admin
Настройка сети в Debian
Подробное описание настройки сети в Debian - задать ip адрес, dhcp, dns, hostname, отключить ipv6, статические маршруты и др.
👍183👎3
Менеджеры удалённых подключений - очень консервативная тема. Я и по себе сужу, потому что много лет пользуюсь одним и тем же. И по своим знакомым, у которых тоже обычно всё один раз настроено, что и используется много лет.
Для ssh у меня Xshell 5, бесплатная версия от 2017 года. А для rdp - mRemoteNG. Обе программы откровенно устарели, пробовал другие, но не могу сказать, что они были сильно лучше, поэтому окончательно так и не перешёл на что-то другое. Привычки к комбинациям клавиш Xshell меня жёстко держат. Хотя ставил и пользовался XPipe, но некоторые баги и неудобства там так и не исправили. В итоге забросил её. Но идея обёртки над Windows Terminal мне нравится, так как нравится этот терминал. В нём комфортно работать. Он и выглядит симпатично, и работать в нём удобно.
По рекомендации подписчика попробовал SSH/SFTP клиент Snowflake. Поначалу смутило, что он больше не развивается. С другой стороны посмотрел свой Xshell и перестал смущаться. Развивать в подобных программах особо нечего, если реализована базовая функциональность. Программа бесплатная, код открыт. Установил и попробовал. В целом, она мне понравилась. В ней необычный набор возможностей, которые подойдут и будут удобны тем, кто не является большим специалистом по Linux, у кого немного серверов, кто любит править файлы не в консоли. Я, когда только начинал изучать Unix, подключался к серверу по ftp и редактировал текстовые конфиги в Total Commander.
➕ Понравилось в Snowflake:
◽️Удобный файловый менеджер с функциональным поиском файлов. Открывается одновременно с ssh сессией. Такое ощущение, что изначально был разработан именно он, а потом добавилось всё остальное.
◽️Анализ использования диска. Функциональность похожа на ncdu, только запускается в клиенте, в отдельной вкладке.
◽️Список служб systemd с возможностью управления: остановить, запустить, отключить автозапуск и т.д.
◽️Сниппеты с сохранёнными консольными командами, которые можно запускать в ssh сессиях. Можно сохранить что-то типа такого:
Это подсчёт сетевых подключений с каждого ip. И запускать в любом терминале, выбирая из списка сохранённых команд.
◽️Возможность работать в файловом менеджере и редакторе с sudo. Это то, чего лично мне не хватает в WinSCP. Ему нужен сразу пользователь с правами. Он не умеет делать sudo для доступа к файлу.
➖ Минусы:
◽️Если используете пароли для аутентификации, программа их сохраняет в открытом виде. Нет возможности зашифровать с мастер-паролем.
◽️Нет комбинаций клавиш для быстрого переключения между открытыми сессиями. Для меня это сразу приговор программе. Я привык быстро переключаться с использованием хоткеев.
Ещё он умеет запускать графики с основными системными ресурсами. Для меня это ни плюс, ни минус, просто есть. Мне лично не нужны такие возможности.
В целом, менеджер выглядит самобытно и интересно. Есть версия и под Windows, и под Linux. Рекомендую сразу в настройках поменять тему терминала со светлой на тёмную. Мне вообще непривычен светлый терминал. Попробуйте, может вам зайдёт. От терминального менеджера много не требуется. Главное, чтобы удобно лично тебе было.
⇨ Исходники / Обзор от RedOS /▶️ Видеообзор
#менеджеры_подключений
Для ssh у меня Xshell 5, бесплатная версия от 2017 года. А для rdp - mRemoteNG. Обе программы откровенно устарели, пробовал другие, но не могу сказать, что они были сильно лучше, поэтому окончательно так и не перешёл на что-то другое. Привычки к комбинациям клавиш Xshell меня жёстко держат. Хотя ставил и пользовался XPipe, но некоторые баги и неудобства там так и не исправили. В итоге забросил её. Но идея обёртки над Windows Terminal мне нравится, так как нравится этот терминал. В нём комфортно работать. Он и выглядит симпатично, и работать в нём удобно.
По рекомендации подписчика попробовал SSH/SFTP клиент Snowflake. Поначалу смутило, что он больше не развивается. С другой стороны посмотрел свой Xshell и перестал смущаться. Развивать в подобных программах особо нечего, если реализована базовая функциональность. Программа бесплатная, код открыт. Установил и попробовал. В целом, она мне понравилась. В ней необычный набор возможностей, которые подойдут и будут удобны тем, кто не является большим специалистом по Linux, у кого немного серверов, кто любит править файлы не в консоли. Я, когда только начинал изучать Unix, подключался к серверу по ftp и редактировал текстовые конфиги в Total Commander.
➕ Понравилось в Snowflake:
◽️Удобный файловый менеджер с функциональным поиском файлов. Открывается одновременно с ssh сессией. Такое ощущение, что изначально был разработан именно он, а потом добавилось всё остальное.
◽️Анализ использования диска. Функциональность похожа на ncdu, только запускается в клиенте, в отдельной вкладке.
◽️Список служб systemd с возможностью управления: остановить, запустить, отключить автозапуск и т.д.
◽️Сниппеты с сохранёнными консольными командами, которые можно запускать в ssh сессиях. Можно сохранить что-то типа такого:
netstat -ntu | grep -vE "(Address|servers|127.0.0.1)" | awk '{print $5}' | cut -d ':' -f 1 | sort -n | uniq -c | sort -nЭто подсчёт сетевых подключений с каждого ip. И запускать в любом терминале, выбирая из списка сохранённых команд.
◽️Возможность работать в файловом менеджере и редакторе с sudo. Это то, чего лично мне не хватает в WinSCP. Ему нужен сразу пользователь с правами. Он не умеет делать sudo для доступа к файлу.
➖ Минусы:
◽️Если используете пароли для аутентификации, программа их сохраняет в открытом виде. Нет возможности зашифровать с мастер-паролем.
◽️Нет комбинаций клавиш для быстрого переключения между открытыми сессиями. Для меня это сразу приговор программе. Я привык быстро переключаться с использованием хоткеев.
Ещё он умеет запускать графики с основными системными ресурсами. Для меня это ни плюс, ни минус, просто есть. Мне лично не нужны такие возможности.
В целом, менеджер выглядит самобытно и интересно. Есть версия и под Windows, и под Linux. Рекомендую сразу в настройках поменять тему терминала со светлой на тёмную. Мне вообще непривычен светлый терминал. Попробуйте, может вам зайдёт. От терминального менеджера много не требуется. Главное, чтобы удобно лично тебе было.
⇨ Исходники / Обзор от RedOS /
#менеджеры_подключений
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍81👎4
⚠️ На прошлой неделе подписчик поделился жуткой историей с шифровальщиком. Вообще, они все жуткие, но если бэкапы тоже зашифрованы, то это вообще тушите свет. А там такая история, что в городе пострадало много организаций по одной и той же схеме. Кто-то точечно и системно поработал.
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security
Человек предложил мне поделиться своим опытом на этот счёт. Я сам не раз сталкивался с шифровальщиками. Бэкапы не терял, только данные, к которым был доступ у пользователей. Сначала не хотел писать, так как тут чего-то нового или особенного не расскажешь. Подойдут обычные мероприятия по защите от вирусов. Потом всё же решил написать, чтобы лишний раз напомнить о том, что от шифровальщиков никто не застрахован. Лучше лишний раз поразмыслить над тем, что ты будешь делать, если завтра тебе все данные зашифруют.
Я всегда так делаю. Мысленно представляю, что завтра у меня недоступны некоторые или все сервера. Какой план на этот счёт? Чтобы не было всех серверов, сразу отсекаем по максимуму доступ к бэкапам. Я уже много раз писал и рассказывал:
❗️Бэкап-сервера должны сами ходить за данными. У серверов с данными не должно быть полного доступа к бэкапам.
Иногда такую схему трудно организовать, или просто неудобно. Может быть по-другому. Но хоть одна копия бэкапов без доступа с рабочих серверов должна быть. Иначе будет как у автора комментария к заметке, когда все бэкапы были зашифрованы с самих серверов.
Подробно про бэкапы я не так давно рассказывал в отдельных заметках:
⇨ Два принципиально разных подхода к созданию бэкапов
⇨ Проверка бэкапов
По моему мнению надёжные бэкапы - основа спокойной жизни админа. Дальше уже реализуем другие организационные меры:
🔴 Закрываем доступ из интернета к внутренним сервисам. По минимуму выставляем их наружу. Не надо без крайней нужды пробрасывать, к примеру, rdp порт. Меня разок через него шифровали. И хотя чаще всего от этого не будет проблем, но раз в 10 лет обязательно найдётся какая-нибудь уязвимость, которая в обход аутентификации позволит выполнить вредоносный код на сервере.
🔴 Используем антивирусы на пользовательских компах. Если у вас бюджетка или прям совсем бедный бизнес, который не может себе позволить купить антивирус, поставьте бесплатный от Касперского. Базово он защитит от вирусов.
🔴 Не давайте пользователям полные права. Вкупе с антивирусом, это закроет большую часть проблем с их стороны. Хоть и не все.
🔴 Не оставляйте свои рабочие места включенными 24/7. Я сам такое практиковал раньше. Удобно, когда рабочий комп всегда включен и к нему можно удалённо подключиться. Сейчас даже дома не оставляю свой рабочий ноут включённым, когда ухожу из дома или надолго отхожу от рабочего места. Выключаю ноут, когда надо - включаю. RDP тоже на нём отключен.
🔴 Не подключайте к своему рабочему компу бэкапы, не настраивайте беспарольные доступы куда-либо, не назначайте лишние права своей учётке в инфраструктуре. Нередко на компы админов злоумышленники заходят руками и смотрят, к чему есть доступ. Если у вас пароли в KeePass, а файл закрыт надёжным паролем, уже с вашего компа ничего не сделать. Пароли в Winbox и Xshell у меня зашифрованы мастер-паролем, на ключе для ssh тоже пароль.
Если сами страдали от шифровальщиков, расскажите, как они заходили к вам и к каким последствиям это приводило. Ко мне один раз заходили через rdp, один раз через письмо у пользователя. У него, кстати, антивирус не помог. Не распознал шифровальщика. Всё, к чему у пользователя был доступ, зашифровали.
#security
👍139👎7
🔝 ТОП постов за прошедший месяц. Все самые популярные публикации по месяцам можно почитать со соответствующему хэштэгу #топ. Отдельно можно посмотреть ТОП за прошлый год.
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.
Сегодня ТОПчик выпал на пятницу, так что обзор интересных роликов с youtube выйдет завтра. Там есть полезные видео, так что не захотел его пропускать.
📌 Больше всего пересылок:
◽️Топ-10 артефактов Linux для расследования инцидентов (980)
◽️Терминальный сервер на базе Windows 10,11 (806)
◽️Система управления инфраструктурой OpenRPort (686)
📌 Больше всего комментариев:
◽️Как найти работу в ИТ после 45 лет? (288)
◽️Тайная жизнь современных ОС (231)
◽️Новость с исключением русских мэйнтейнеров (208)
📌 Больше всего реакций:
◽️Шпаргалка по tcpdump (351)
◽️Терминальный сервер на базе Windows 10,11 (318)
◽️Настройка default_server в Nginx (279)
📌 Больше всего просмотров:
◽️Топ-10 артефактов Linux для расследования инцидентов (11612)
◽️Бесплатные курсы Yandex Cloud (11265)
◽️Настройка VM в Proxmox с помощью Terraform (10449)
Периодически просматриваю обратные ссылки на свой канал, в том числе из небольших личных каналов отдельных людей. Иногда попадаются такие, как на картинке ниже. Я вот думаю, это успех или строго противоположное от него? 😁
#топ
Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.
Сегодня ТОПчик выпал на пятницу, так что обзор интересных роликов с youtube выйдет завтра. Там есть полезные видео, так что не захотел его пропускать.
📌 Больше всего пересылок:
◽️Топ-10 артефактов Linux для расследования инцидентов (980)
◽️Терминальный сервер на базе Windows 10,11 (806)
◽️Система управления инфраструктурой OpenRPort (686)
📌 Больше всего комментариев:
◽️Как найти работу в ИТ после 45 лет? (288)
◽️Тайная жизнь современных ОС (231)
◽️Новость с исключением русских мэйнтейнеров (208)
📌 Больше всего реакций:
◽️Шпаргалка по tcpdump (351)
◽️Терминальный сервер на базе Windows 10,11 (318)
◽️Настройка default_server в Nginx (279)
📌 Больше всего просмотров:
◽️Топ-10 артефактов Linux для расследования инцидентов (11612)
◽️Бесплатные курсы Yandex Cloud (11265)
◽️Настройка VM в Proxmox с помощью Terraform (10449)
Периодически просматриваю обратные ссылки на свой канал, в том числе из небольших личных каналов отдельных людей. Иногда попадаются такие, как на картинке ниже. Я вот думаю, это успех или строго противоположное от него? 😁
#топ
3👍59👎2
⇨ GitLab CI/CD - Главные Основы создания CI/CD Pipeline
Хорошее обзорное видео с примерами построения CI/CD на базе Gitlab. Автор наглядно на конкретном примере всё показывает и рассказывает. Кто не знаком с этим каналом, рекомендую. Там в прошлом есть обучающие курсы из серии видео для базовых вещей в DevOps.
⇨ Restic - решение для твоих бекапов
Пример использования популярного решения для бэкапов - Restic. Это быстрый, функциональный инструмент для бэкапов, состоящий из одного бинарника на Go. Кто не знаком, рекомендую посмотреть на него. Там снэпшоты, дедупликация, проверка целостности, куча бэкендов в поддержке и т.д.
⇨ Разбор падения Reddit – как крупнейший форум оказался в ауте!
Автор рассказал про одно из крупных падений Reddit из-за неудачного обновления Kubernetes. А отката неудачного обновления там не предусмотрено.
⇨ Docker Container Monitoring Dashboards both Open Source and Netdata!
Автор рассмотрел наиболее популярные инструменты для мониторинга контейнеров: cAdviser, Prometheus, Grafana, Netdata. Нравится этот канал, хорошее качество видео.
⇨ Simple HTTPs for Docker! // Traefik Tutorial (updated)
Большое обзорное виде про Traefik. Не знаю, чем его так любят блогеры, но про этот обратный прокси для веб сайтов больше всего роликов. Этот, получается, самый свежий будет. Тут всё: установка, базовая настройка, динамическая конфигурация, метки для Docker, TLS сертификаты и т.д.
⇨ How To Monitor Windows Services with ZABBIX ( Correct Way )
Любой, кто мониторил Windows хосты с помощью Zabbix знает, как там неудобно реализован мониторинг служб. Будет масса бесполезных уведомлений. Лично я всегда отключаю автообнаружение служб. А если надо что-то мониторить, настраиваю отдельно вручную. Автор показывает, как можно не отключая мониторинг всех служб, сделать исключение для некоторых из них. По мне, так сделано очень неудобно. Но пока других простых решений нет.
⇨ САМОПОДПИСАННЫЕ SSL СЕРТИФИКАТЫ ДЛЯ ДОМА.
Наглядное видео, как создать и использовать самоподписные сертификаты. В видео кратко рассмотрена теория по TLS, что содержат сертификаты, что такое цепочки доверия и т.д. Сертификаты автор выпускал с помощью XCA - локального приложения для управления сертификатами. Краткая инструкция по этой теме была у меня на канале. Рекомендую для быстрого копипаста в консоли.
⇨ Настройки WAF на Cloudflare для домашнего сервера
Обзор WAF на бесплатном тарифе от Cloudflare. Он, на удивление, не вводил никаких санкций и по-прежнему работает. Не знаю, насколько оправданно им сейчас пользоваться. Я буквально пару недель назад последнего пользователя отключил от CF. Просто на всякий случай. Никаких проблем в его работе не было. Хорошее бесплатное решение, чтобы скрыть реальные адреса своего проекта.
⇨ ASUS NUC 14 Pro Review // Best Intel NUC for Home Lab?
Обзор небольших minipc. Лично мне всегда нравились нюки за их компактный размер и хорошую производительность. Мечтаю себе купить 3 таких штуки для домашнего кластера, но всё время откладываю, потому что дома полно старого железа. Большой нужды в них нет, поэтому жалко денег. Их не назвать бюджетными устройствами, так как стоят больше аналогов. На авито много предложений за 70к+ р.
⇨ Нейросеть + 1С. RAG системы для бизнеса
Пример того, как может работать нейросеть в связке с БД интернет-магазина, чтобы отвечать на вопросы пользователей на основе актуальной информации. Смотрю подобные ролики просто из любопытства, чтобы иметь представление, как всё это работает.
#видео
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
GitLab CI/CD - Главные Основы создания CI/CD Pipeline
#devops #gitlab #девопс
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
https://gitlab.com/adv4000/myproject1
Если помог, поддержите парой баксов, даже Канадских :)
Boosty: https://boosty.to/adv-it/donate
PayPal: https://www.paypal.me/DenisAstahov
👍79👎2
Xshell+Xftp.png
1.1 MB
Продолжение темы про менеджеры удалённых подключений. В прошлой заметке в комментариях подсказали, что у программы Xshell, которой я пользуюсь последние лет 8, вновь вернулась бесплатная версия.
Истрия там такая. Последняя бесплатная версия была 5-ой. Причём в одно из последних обновлений этой ветки зашили тайм бомбу. В определённый день она стала писать, что больше не работает и надо обновиться на 6-ю версию. А там ограничение на 10 настроенных подключений, дальше только за деньги. Я нашёл последнюю версию без тайм бомбы и пользовался ей много лет.
Сейчас есть Xshell 8 без каких либо ограничений for Home and School use only. Скачать бесплатную версию можно на отдельной странице. Причём Xshell идёт в связке с бесплатной же Xftp для sftp соединений. Получается очень удобно. Достаточно в Xshell подключиться к серверу и из этой сессии вызвать Xftp для доступа к файлам.
Расскажу, что лично мне нравится в Xshell, что я столько лет ей пользуюсь и не перехожу на что-то другое, хотя пробовал все известные программы из этой области.
🟢 Внешний вид, а именно - возможность убрать всё лишнее. Пошло это со времён ноутбуков с небольшим экраном и удалённой работы. В Xshell можно оставить только окно с терминалом и заголовок (Alt+S). Всё остальное я открываю горячими клавишами. Когда всё настроишь, открывать нужно только список настроенных соединений. В итоге рабочее окно это только терминал.
🟢 Шифрование учётных данных мастер-паролем, который вводишь при старте программы. Без него она тоже запустится, но все пароли придётся вводить вручную.
🟢 Возможность настройки каталога с соединениями в заданной директории. У меня это Яндекс.Диск. В итоге имею возможность из разных рабочих мест использовать настроенные соединения. Креды зашифрованы, поэтому можно не переживать за хранение на облачном диске.
🟢 SSH + RDP соединения в одном клиенте. В 5-й версии RDP не было, теперь есть. Для меня это хорошая новость. Теперь можно исключить mRemoteNG, а использовать только Xshell.
🟢 Возможность ручной и автоматической записи сессий ssh в лог файлы. Для каких-то серверов у меня пишутся логи, для каких-то нет. Есть встроенный просмотрщик логов, который откроет весь лог и покажет его в консоли, как-будто вы просто отключились от сервера, но сохранили вывод консоли.
🟢 Возможность гибко управлять расположением вкладок с соединениями в окне программы. Из-за этого я не пользуюсь возможностями мультиплексоров, типа screen или tmux для открытия нескольких окон в рамках одного соединения. Мне удобнее управлять этим в Xshell.
Это основное, что вспомнил во время написания. В Xshell есть всё, что только можно ожидать от подобной программы. Я даже не придумаю, чего там не хватает. Из того, что есть ещё:
🟡 Возможность распознавать текст в консоли и что-то подсвечивать/подчёркивать в зависимости от содержимого. Можно открыть текстовый файл или вывести лог в консоль и подсветить слова или фразы средствами Xhell.
🟡 Можно сохранять свои быстрые команды или скрипты для запуска. Также есть поддержка сценариев, который можно записать на основе своих действий в консоли.
🟡 Умеет работать через proxy (для каждого соединения может быть свой), запускать X11 Forwarding или обычное перенаправление портов по ssh.
🟡 Огромное количество настроек и режимов терминала. Начиная от шрифтов и их размера, заканчивая VT modes и кодировками. Кто-то спрашивал, какой я использую шрифт в консоли. Обычно Cascadia Mono. Подсмотрел его в Windows Terminal. У меня он там стоял по умолчанию. Сразу понравился.
🟡 Подключения можно объединять в группы и управлять сразу группой. Например, отправить всем какую-то команду в консоль, открыть сразу всю группу и др.
Подводя итог скажу, что программа, на мой взгляд, одна из лучших. Я её называю бесплатной, но, конечно же, это не так. Бесплатна она только для домашнего пользования, хотя никакой проверки нет. Если захотите её купить, то стоит она 100$. На сайте есть список продавцов в РФ.
#менеджеры_подключений
Истрия там такая. Последняя бесплатная версия была 5-ой. Причём в одно из последних обновлений этой ветки зашили тайм бомбу. В определённый день она стала писать, что больше не работает и надо обновиться на 6-ю версию. А там ограничение на 10 настроенных подключений, дальше только за деньги. Я нашёл последнюю версию без тайм бомбы и пользовался ей много лет.
Сейчас есть Xshell 8 без каких либо ограничений for Home and School use only. Скачать бесплатную версию можно на отдельной странице. Причём Xshell идёт в связке с бесплатной же Xftp для sftp соединений. Получается очень удобно. Достаточно в Xshell подключиться к серверу и из этой сессии вызвать Xftp для доступа к файлам.
Расскажу, что лично мне нравится в Xshell, что я столько лет ей пользуюсь и не перехожу на что-то другое, хотя пробовал все известные программы из этой области.
🟢 Внешний вид, а именно - возможность убрать всё лишнее. Пошло это со времён ноутбуков с небольшим экраном и удалённой работы. В Xshell можно оставить только окно с терминалом и заголовок (Alt+S). Всё остальное я открываю горячими клавишами. Когда всё настроишь, открывать нужно только список настроенных соединений. В итоге рабочее окно это только терминал.
🟢 Шифрование учётных данных мастер-паролем, который вводишь при старте программы. Без него она тоже запустится, но все пароли придётся вводить вручную.
🟢 Возможность настройки каталога с соединениями в заданной директории. У меня это Яндекс.Диск. В итоге имею возможность из разных рабочих мест использовать настроенные соединения. Креды зашифрованы, поэтому можно не переживать за хранение на облачном диске.
🟢 SSH + RDP соединения в одном клиенте. В 5-й версии RDP не было, теперь есть. Для меня это хорошая новость. Теперь можно исключить mRemoteNG, а использовать только Xshell.
🟢 Возможность ручной и автоматической записи сессий ssh в лог файлы. Для каких-то серверов у меня пишутся логи, для каких-то нет. Есть встроенный просмотрщик логов, который откроет весь лог и покажет его в консоли, как-будто вы просто отключились от сервера, но сохранили вывод консоли.
🟢 Возможность гибко управлять расположением вкладок с соединениями в окне программы. Из-за этого я не пользуюсь возможностями мультиплексоров, типа screen или tmux для открытия нескольких окон в рамках одного соединения. Мне удобнее управлять этим в Xshell.
Это основное, что вспомнил во время написания. В Xshell есть всё, что только можно ожидать от подобной программы. Я даже не придумаю, чего там не хватает. Из того, что есть ещё:
🟡 Возможность распознавать текст в консоли и что-то подсвечивать/подчёркивать в зависимости от содержимого. Можно открыть текстовый файл или вывести лог в консоль и подсветить слова или фразы средствами Xhell.
🟡 Можно сохранять свои быстрые команды или скрипты для запуска. Также есть поддержка сценариев, который можно записать на основе своих действий в консоли.
🟡 Умеет работать через proxy (для каждого соединения может быть свой), запускать X11 Forwarding или обычное перенаправление портов по ssh.
🟡 Огромное количество настроек и режимов терминала. Начиная от шрифтов и их размера, заканчивая VT modes и кодировками. Кто-то спрашивал, какой я использую шрифт в консоли. Обычно Cascadia Mono. Подсмотрел его в Windows Terminal. У меня он там стоял по умолчанию. Сразу понравился.
🟡 Подключения можно объединять в группы и управлять сразу группой. Например, отправить всем какую-то команду в консоль, открыть сразу всю группу и др.
Подводя итог скажу, что программа, на мой взгляд, одна из лучших. Я её называю бесплатной, но, конечно же, это не так. Бесплатна она только для домашнего пользования, хотя никакой проверки нет. Если захотите её купить, то стоит она 100$. На сайте есть список продавцов в РФ.
#менеджеры_подключений
1👍113👎5
Занимался на днях в очередной раз перенастройкой своих VPN каналов. Честно говоря уже надоело этим заниматься, но внешние обстоятельства постоянно меняются. Хочу рассказать об одной особенности OpenVPN, которую я постоянно использую, и которая видится мне весьма полезной и функциональной.
OpenVPN сервер умеет управлять маршрутами внутри своих VPN сетей. Это получается второй контур маршрутизации поверх системного. Расскажу кратко, как это работает.
Допустим, у вас есть OpenVPN сервер, к которому подключаются разные клиенты. Будь то динамические подключения от удалённых сотрудников, либо другие одиночные сервера, маршрутизаторы своих внутренних подсетей. На сервере у вас указано, что все запросы к подсетям:
Отправляются в VPN сеть, конкретно в tun0 интерфейс. Настроить это можно сразу в конфиге openvpn для туннеля tun0:
OpenVPN сервер при запуске добавляет указанные маршруты в систему. Это можно сделать и вручную. Сервер при старте просто использует
За каждую указанную выше подсеть у нас отвечают разные клиенты VPN. Это может быть указано в его конфигурационном файле. Делается это так:
При подключении клиента с этой настройкой OpenVPN сервер понимает, что весь трафик в эту подсеть стоит адресовать этому клиенту. Если клиент поменяется, то эта настройка может переехать к другому.
Глобально настройки сервера и других VPN клиентов не меняются. Они просто подключаются и получают общую маршрутизацию. А по каким маршрутам внутри VPN побегут пакеты определяют настройки отдельных клиентов, которые выполняют роль маршрутизаторов. И этих клиентов можно легко заменить без необходимости менять какие-либо ещё настройки.
Подробнее об этом можно прочитать в документации. Искать по параметру
Мне пришлось заменить одного клиента на другого, через которого ходил трафик в youtube. Настройки остальных пользователей трогать не пришлось. У меня используется схема с единым OpenVPN сервером в РФ, к которому подключаются все клиенты. А он уже раскидывает трафик в зависимости от потребностей.
Набросал ниже схему, чтобы было понятно, о чём идёт речь.
#openvpn
OpenVPN сервер умеет управлять маршрутами внутри своих VPN сетей. Это получается второй контур маршрутизации поверх системного. Расскажу кратко, как это работает.
Допустим, у вас есть OpenVPN сервер, к которому подключаются разные клиенты. Будь то динамические подключения от удалённых сотрудников, либо другие одиночные сервера, маршрутизаторы своих внутренних подсетей. На сервере у вас указано, что все запросы к подсетям:
10.1.3.0/2410.1.4.0/2410.1.5.0/24Отправляются в VPN сеть, конкретно в tun0 интерфейс. Настроить это можно сразу в конфиге openvpn для туннеля tun0:
route 10.1.3.0 255.255.255.0route 10.1.4.0 255.255.255.0route 10.1.5.0 255.255.255.0OpenVPN сервер при запуске добавляет указанные маршруты в систему. Это можно сделать и вручную. Сервер при старте просто использует
/sbin/ip route add для добавления маршрутов.За каждую указанную выше подсеть у нас отвечают разные клиенты VPN. Это может быть указано в его конфигурационном файле. Делается это так:
iroute 10.1.3.0 255.255.255.0При подключении клиента с этой настройкой OpenVPN сервер понимает, что весь трафик в эту подсеть стоит адресовать этому клиенту. Если клиент поменяется, то эта настройка может переехать к другому.
Глобально настройки сервера и других VPN клиентов не меняются. Они просто подключаются и получают общую маршрутизацию. А по каким маршрутам внутри VPN побегут пакеты определяют настройки отдельных клиентов, которые выполняют роль маршрутизаторов. И этих клиентов можно легко заменить без необходимости менять какие-либо ещё настройки.
Подробнее об этом можно прочитать в документации. Искать по параметру
--iroute для внутренней маршрутизации и --client-config-dir для персональных настроек клиентов. Мне пришлось заменить одного клиента на другого, через которого ходил трафик в youtube. Настройки остальных пользователей трогать не пришлось. У меня используется схема с единым OpenVPN сервером в РФ, к которому подключаются все клиенты. А он уже раскидывает трафик в зависимости от потребностей.
Набросал ниже схему, чтобы было понятно, о чём идёт речь.
#openvpn
1👍96👎5
Я постоянно использую Grafana как в связке с Zabbix Server, так и с Prometheus. У неё довольно часто выходят новые версии, но я обычно не спешу с обновлением, так как нет большой нужды. Смотрю через неё простые дашборды, так что обновления обычно не приносят конкретно мне каких-то необходимых нововведений.
Очень долго использовал 7-ю версию, не обновлялся. Потом собрался с силами и обновился до 10-й. Пришлось повозиться и сделать сначала экспорт всего через API, а потом импортировать уже в новую 10-ю версию. Из-за большой разницы в версиях просто обновиться поверх старой не получилось.
Не так давно вышла очередная версия уже 11-й ветки. Там много изменений. Конкретно меня привлеки улучшения в плане оповещений (alerts), экспорт в pdf, некие действия (actions) в визуализациях. Полный список обновлений 11-й версии и недавней 11.3 смотрите по ссылкам:
⇨ What’s new in Grafana v11.0
⇨ Grafana 11.3 release
Обновление с 10-й версии прошло вообще без проблем. Конкретно у меня это выглядело так:
То есть просто удалил контейнер, обновил образ и запустил контейнер с теми же параметрами, что и предыдущий. Всё обновилось автоматически. По логам видно, что были выполнены все миграции со старой версии. Предварительно сделал снэпшот виртуалки перед обновлением.
Изменений реально много. Тут и алерты, и разные методы аутентификации, и управление пользователями, и ещё что-то. Сразу и не вспомню. Вижу, что меню слева сильно поменялось, но уже не помню, что там раньше было. Не так часто по настройкам лазил.
Если кому интересно, то я использую следующие дашборды в Grafana:
◽️Сводный дашборд активных триггеров со всех серверов Zabbix. Удобно все их открыть на одной странице. Разработчики Zabbix обещают реализовать это в рамках своего сервера, но пока такого нет. Объединить несколько серверов в дашборде Zabbix пока невозможно. Как это выглядит, можно посмотреть в моей статье на сайте. Внешний вид дашборда с триггерами с тех пор вообще не изменился.
◽️Дашборд Node Exporter Full от Prometheus для некоторых серверов
◽️Родной дашборд Angie от разработчиков.
◽️Дашборд от моего шаблона Zabbix для Linux Server.
◽️Мой сводный дашборд с личными метриками - сайты, каналы, статус компов в доме, на даче, электрокотёл, камеры и т.д.
Grafana - удобный универсальный инструмент, который позволил объединить две разнородные системы мониторинга в едином веб интерфейсе. Не приходится идти на компромиссы в выборе системы мониторинга. Какая лучше подходит, ту и используешь. А потом всё это объединяешь.
Изначально заметку планировал по нововведениям Grafana сделать, но там не так просто всё это попробовать. Сходу не нашёл, всё, что хотел. Соответственно и не потестировал ещё. Надо больше времени на это. Если наберётся материала на заметку, сделаю её отдельно. Отмечу только одно важное для меня изменение, которое сразу заметил. Если вкладку с Grafana открыть в фоне, то эта падлюка не подгружает метрики, пока не сделаешь её активной. А некоторые метрики долго подгружаются. Хочется её открыть в фоне, а потом к ней вернуться, когда она уже точно метрики подгрузит. Но не тут то было. Теперь она в таких вкладках из фона быстрее показывает метрики. Видно, что она всё равно что-то подгружает, но делает это быстрее, чем раньше.
#grafana #мониторинг
Очень долго использовал 7-ю версию, не обновлялся. Потом собрался с силами и обновился до 10-й. Пришлось повозиться и сделать сначала экспорт всего через API, а потом импортировать уже в новую 10-ю версию. Из-за большой разницы в версиях просто обновиться поверх старой не получилось.
Не так давно вышла очередная версия уже 11-й ветки. Там много изменений. Конкретно меня привлеки улучшения в плане оповещений (alerts), экспорт в pdf, некие действия (actions) в визуализациях. Полный список обновлений 11-й версии и недавней 11.3 смотрите по ссылкам:
⇨ What’s new in Grafana v11.0
⇨ Grafana 11.3 release
Обновление с 10-й версии прошло вообще без проблем. Конкретно у меня это выглядело так:
# docker stop grafana# docker rm grafana# docker pull grafana/grafana:latest# docker run -d -p 3000:3000 --name=grafana \ -v grafana_data:/var/lib/grafana \ -e "GF_INSTALL_PLUGINS=grafana-clock-panel,grafana-simple-json-datasource,alexanderzobnin-zabbix-app" \ grafana/grafana:latestТо есть просто удалил контейнер, обновил образ и запустил контейнер с теми же параметрами, что и предыдущий. Всё обновилось автоматически. По логам видно, что были выполнены все миграции со старой версии. Предварительно сделал снэпшот виртуалки перед обновлением.
Изменений реально много. Тут и алерты, и разные методы аутентификации, и управление пользователями, и ещё что-то. Сразу и не вспомню. Вижу, что меню слева сильно поменялось, но уже не помню, что там раньше было. Не так часто по настройкам лазил.
Если кому интересно, то я использую следующие дашборды в Grafana:
◽️Сводный дашборд активных триггеров со всех серверов Zabbix. Удобно все их открыть на одной странице. Разработчики Zabbix обещают реализовать это в рамках своего сервера, но пока такого нет. Объединить несколько серверов в дашборде Zabbix пока невозможно. Как это выглядит, можно посмотреть в моей статье на сайте. Внешний вид дашборда с триггерами с тех пор вообще не изменился.
◽️Дашборд Node Exporter Full от Prometheus для некоторых серверов
◽️Родной дашборд Angie от разработчиков.
◽️Дашборд от моего шаблона Zabbix для Linux Server.
◽️Мой сводный дашборд с личными метриками - сайты, каналы, статус компов в доме, на даче, электрокотёл, камеры и т.д.
Grafana - удобный универсальный инструмент, который позволил объединить две разнородные системы мониторинга в едином веб интерфейсе. Не приходится идти на компромиссы в выборе системы мониторинга. Какая лучше подходит, ту и используешь. А потом всё это объединяешь.
Изначально заметку планировал по нововведениям Grafana сделать, но там не так просто всё это попробовать. Сходу не нашёл, всё, что хотел. Соответственно и не потестировал ещё. Надо больше времени на это. Если наберётся материала на заметку, сделаю её отдельно. Отмечу только одно важное для меня изменение, которое сразу заметил. Если вкладку с Grafana открыть в фоне, то эта падлюка не подгружает метрики, пока не сделаешь её активной. А некоторые метрики долго подгружаются. Хочется её открыть в фоне, а потом к ней вернуться, когда она уже точно метрики подгрузит. Но не тут то было. Теперь она в таких вкладках из фона быстрее показывает метрики. Видно, что она всё равно что-то подгружает, но делает это быстрее, чем раньше.
#grafana #мониторинг
2👍99👎1
Вчера в комментариях посоветовали удобную программу для просмотра серверных логов браузером. Сразу попробовал - очень понравилась утилита. Речь пойдёт про logdy. Это одиночный бинарник на Go. Установить можно так:
Скрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
Вообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
Далее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет https://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
Отправляем в него логи:
В веб интерфейс прилетит этот лог. В него можно stdin отправить:
У logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
# curl https://logdy.dev/install.sh | shСкрипт на один экран, который просто определяет версию системы и скачивает скомпилированный бинарник из github. Можно и вручную скачать.
Использовать logdy можно в разных режимах. Самый простой - отправить в него через пайп содержимое лога:
# tail -f /var/log/syslog | logdy --ui-ip=0.0.0.0По умолчанию он стартует на localhost, поэтому я принудительно через ключ запустил его на всех интерфейсах. Если не указать порт, то он запустится на 8080. Можно идти по IP адресу сервера на порт 8080 и смотреть в браузере содержимое лога syslog. Можно то же самое сделать вот так:
# logdy --ui-ip=0.0.0.0 follow /var/log/syslogВообще, эта штука придумана в первую очередь для разработчиков. В блоге авторов есть пример использования во время локальной разработки. Допустим, вы у себя на машине запускаете проект под node.js:
# node app.js | logdyДалее перемещаетесь в VS Code, открываете через консоль команд (Ctrl+Shift+P) "Simple Browser: Show" и там указываете адрес веб интерфейса. Для локальной разработки это будет https://localhost:8080. Таким образом вы в одном месте можете править код, перезапускать приложение и тут же видеть его логи.
То же самое можно делать для Docker контейнеров:
# docker logs 761965fa13b2 --follow | logdy --ui-ip=0.0.0.0И погнали смотреть логи контейнера. Можно объединить разные контейнеры или логи. Делается это следующим образом:
# logdy --ui-ip=0.0.0.0 socket 8123 8124# docker logs d20339949095 --follow | logdy forward 8123# docker logs 761965fa13b2 --follow | logdy forward 8124Запустили logdy в режиме сокетов, на которые он принимает логи и отображает в веб интерфейсе. И отправили каждый контейнер в свой сокет. В веб интерфейсе можно как вместе смотреть эти логи, так и разделять по сокетам.
У logdy даже API есть для отправки туда логов с аутентификацией по токену. Выглядит это примерно так. Запускаем logdy с api:
# logdy --ui-ip=0.0.0.0 --api-key=secrettokenОтправляем в него логи:
curl --location --request POST 'https://1.2.3.4:8080/api/log' \--header 'Authorization: Bearer secrettoken' \--header 'Content-Type: application/json' \--data '{"logs": [{"log": "this is a log message as a string" }],"source":"machine identifier"}'В веб интерфейс прилетит этот лог. В него можно stdin отправить:
# logdy stdinУ logdy хорошая подробная документация, где описаны все ключи CLI и приведены примеры разных режимов работы и использования. Такой небольшой, нишевый, удобный продукт. Через ключи запуска веб интерфейс можно закрыть паролем.
Рекомендую взять на заметку. Иногда хочется открыть какой-то лог или логи в браузере. Через logdy это удобно сделать. Он может не только отобразить логи, но и сразу распарсить их, разбить на колонки, сделать какую-то сортировку и т.д. В документации есть примеры. На картинке ниже показано, как он распарсил лог веб севрера в формате json.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Сайт / Исходники / Demo
#logs #devops
2👍187👎4
Неоднократно видел в комментариях и обсуждениях Ceph упоминание о VitaStor. Автор называет её быстрой и простой распределённой программной СХД. Архитектурно она сильно похожа на Ceph, так что если кто-то с ней знаком, попробовать Vitastor не составит труда. Я где-то за пару часов разобрался, настроил тестовый стенд и проверил в работе.
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
1️⃣ Настраиваем мониторы на основе etcd. Аналог MON в Ceph.
2️⃣ Настраиваем OSD (Object Storage Device). В Ceph так же называется.
3️⃣ Создаём пул.
4️⃣ Создаём образ диска.
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
/dev/vda. Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍101👎2
На днях нужно было вытащить один файл из Docker образа. Не из контейнера, а именно образа, так как не хотелось запускать контейнер. Никак не мог сообразить, как это сделать. Помню, что уже когда-то ломал над этим голову, и там почему-то нет простого решения. По крайней мере я его не знаю.
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
Теперь можно забрать нужный файл:
Либо выгрузить всё содержимое образа:
Заодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
Увидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
Теперь можно просматривать образы так:
Удобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
Решение такое. Образ надо скачать, создать контейнер, но не запускать его.
# docker pull nginx:latest# docker create --name nginx nginx:latestТеперь можно забрать нужный файл:
# docker cp nginx:/docker-entrypoint.d/30-tune-worker-processes.sh ~/Либо выгрузить всё содержимое образа:
# docker export nginx -o ~/nginx-docker.tar.gzЗаодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.
Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:
# docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive nginx:latestУвидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:
alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"Теперь можно просматривать образы так:
# dive nginx:latestУдобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops
2👍207👎4
На прошлой неделе посмотрел видео про современную и функциональную open source платформу для управления веб приложениями, запускаемыми в Docker контейнерах. Речь пойдёт про Coolify. Вот видео, о котором я говорю:
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
▶️ Coolify - deploy services locally, or on remote servers!
Не стал его включать в регулярную подборку, потому что решил развернуть и попробовать систему, а потом отдельно про неё написать. Сейчас это сделаю.
Для того, чтобы сразу было понятно, что такое Coolify, скажу, что это условный аналог известного сервиса Heroku. Конечно, не такой функциональный, но он и появился не так давно. При этом на github у него огромное количество звёзд (34k), много спонсоров, большое сообщество и регулярные обновления. Проект монетизируется за счёт облачной версии.
Поясню своими словами, как работает Coolify. Условно её можно сравнить с панелью управления хостингом или VPS, только тут конечные сущности - приложения, запускаемые в контейнерах.
Вы разворачиваете панель и добавляете в неё следующие объекты:
▪️чистые сервера на базе Linux, которыми coolify управляет по ssh;
▪️s3 хранилища;
▪️git репозитории с вашим кодом;
▪️проекты, которые могут состоять из разных окружений (dev, prod и т.д.)
▪️переменные, ключи и токены;
▪️команды и пользователей
После этого вы идёте в один из проектов и создаёте там новый ресурс в виде вашего приложения, запущенного из готового образа, из Dockerfile или Docker-compose. Связываете это приложение, если необходимо, с соответствующим репозиторием кода, публикуете его на одном из добавленных серверов. Настраиваете к нему доступ по отдельному доменному имени. Для этого Coolify поднимает свой обратный прокси на базе Caddy или Traefik, получает сертификаты от Let's Encrypt.
Вы всем этим управляете из общего веб интерфейса с дашбордами. Все проекты и приложения, соответственно, бьются на команды с разными правами доступа. Помимо ваших приложений, подобным образом можно разворачивать популярные СУБД или преднастроенные сервисы на базе образов от linuxserver.io.
Проект довольно навороченный. Там много всего добавлено. Есть API, аутентификация через различных OAuth провайдеров, публикация ваших приложений через какой-то dyndns сервис, вебхуки, оповещения. Есть возможность подключаться к консоли серверов и контейнеров. Можно не ходить напрямую по ssh, а всем управлять через веб панель.
Даже не знаю, с чем Coolify сравнить. Не припоминаю похожих проектов. Он интересен и для личной инфраструктуры, если у вас большой набор своих сервисов, и для каких-то команд, особенно разработчиков. Можно всё для них автоматизировать и дать доступ. Они и консоли, и логи, и бэкапы своих приложений увидят. Смогут всем этим управлять, к примеру, в dev окружении и только смотреть в prod.
❗️Отдельно подчеркну ещё раз. Всё это только для Docker контейнеров. Деплоить что-то в обычное окружение Linux нельзя. Coolify автоматом на все добавляемые сервера устанавливает Docker.
⇨ 🌐 Сайт (через VPN) / 4️⃣ Исходники / Скриншоты интерфейса
#docker #devops #cicd
2👍74👎1
У меня на сайте есть старенькая игра про системного администратора, написанная ещё на flash. Эту технологию уже давно отовсюду выпилили. В комментариях к игре один человек предложил простой и быстрый способ запуска через специально собранный для этого контейнер:
Можно идти браузером по IP адресу сервера, где запущен контейнер, на порт 8080 и играть в игру. Под капотом там apache guacamole, xrdp и основа в виде контейнера Ubuntu.
Решение, понятное дело, только для разовых задач. Автор какой-то китаец, ничего не обновляется. Если открыть не напрямую сразу swf файл, а только браузер, то он у меня постоянно падал при сёрфинге по сайтам. А если сразу открыть flash, то нормально.
Туда ещё по rdp можно подключаться при желании:
Некоторые подробности есть в репозитории разработчика.
#игра
# docker run --rm -e "STARTUP=firefox https://serveradmin.ru/files/sysadmin.swf" -p 8080:8080 --name play-adobe-flash-after-eol jchprj/play-adobe-flash-after-eolМожно идти браузером по IP адресу сервера, где запущен контейнер, на порт 8080 и играть в игру. Под капотом там apache guacamole, xrdp и основа в виде контейнера Ubuntu.
Решение, понятное дело, только для разовых задач. Автор какой-то китаец, ничего не обновляется. Если открыть не напрямую сразу swf файл, а только браузер, то он у меня постоянно падал при сёрфинге по сайтам. А если сразу открыть flash, то нормально.
Туда ещё по rdp можно подключаться при желании:
# docker run -p 8080:8080 -p 3389:3389 --name play-adobe-flash-after-eol jchprj/play-adobe-flash-after-eolНекоторые подробности есть в репозитории разработчика.
#игра
1👍64👎6
В одном из видео с канала samohosting увидел интересную бесплатную утилиту с открытым исходным кодом XCA для создания и управления собственным удостоверяющим центром для выпуска сертификатов под различные службы. Я уже публиковал видео с этого канала в подборках, а сейчас хочу сделать акцент на нём. Очень качественный контент, различные тематики, подача. Рекомендую. Мне хоть и не все темы оттуда интересны, но стоит отдать должное создателю. Человек старается сделать полезный материал.
Возвращаюсь к XCA. Это кроссплатформенное приложение с GUI под все популярные системы: Windows, Linux, MacOS. Под винду можно как портированную версию скачать, так и установить из магазина.
XCA можно использовать для создания сертификатов для таких служб, как OpenVPN, IPsec, веб и почтовые сервера. Подойдёт для любых служб, которые используют TLS сертификаты. Очевидно, что речь идёт о внутренней инфраструктуре, где вы сможете раздать пользователям свой CA, чтобы софт не выдавал предупреждения о недоверенных сертификатах. Хотя для каких-то служб это не очень актуально. Например, для OpenVPN это некритично. Там сертификат CA обычно идёт вместе с конфигурацией без необходимости отдельной установки в систему.
Приложение очень простое и интуитивно понятное, особенно для тех, кто первый раз сталкивается с этой темой. Есть русский язык. Помню, как для меня было суперсложно и непонятно, когда впервые разбирался со скриптами easy-rsa для настройки своего первого OpenVPN сервера. Делал всё это в консоли, где никаких наглядных связей и привязок, только команды для генерации и ещё более длинные команды на базе openssl для просмотра сертификатов.
С одной стороны это хорошо, так как позволило быстрее вникнуть, напрячь мозги и разобраться с темой. С другой, не всем и не часто приходится этим заниматься, так что для разовых задач может быть проще и быстрее всё сделать в GUI. Если у вас нет дальнейших задач по автоматизации процессов, связанных с выпуском сертификатов, то в GUI по-любому будет быстрее и проще работать с сертификатами.
Работа с XCA выглядит следующим образом:
1️⃣ Создаёте новую зашифрованную базу для хранения приватных ключей.
2️⃣ Создаёте новый удостоверяющий центр (Certification authority - CA) с нужными вам параметрами. Основной - срок действия корневого сертификата. Лучше ставить побольше. На моей практике даже 10-ти летние сертификаты протухали, что приводило к проблемам и дополнительной работе.
3️⃣ По желанию можно выпустить промежуточный сертификат, который сделает более безопасной всю цепочку сертификации. В общем случае можно этого не делать.
4️⃣ Создаёте уже клиентские сертификаты. Делаете экспорт и отдаёте сервисам или пользователям.
То есть всё как обычно при работе со своим CA. У меня были заметки по этой теме, но только для консоли:
▪️openssl - все действия на базе openssl.
▪️step-ca - своя локальная служба для управления CA с простой автоматизацией перевыпуска.
▪️CFSSL - современная одиночная утилита от cloudflare с конфигами в формате json.
Странно, что я впервые услышал об этой программе. Вообще не знал и не использовал ни одну локальную программу по этой теме. Веб интерфейсы видел, пользовался. В pfSense, кстати, удобный веб интерфейс для работы со своим CA.
⇨ 🌐 Сайт / Исходники
#security #tls
Возвращаюсь к XCA. Это кроссплатформенное приложение с GUI под все популярные системы: Windows, Linux, MacOS. Под винду можно как портированную версию скачать, так и установить из магазина.
XCA можно использовать для создания сертификатов для таких служб, как OpenVPN, IPsec, веб и почтовые сервера. Подойдёт для любых служб, которые используют TLS сертификаты. Очевидно, что речь идёт о внутренней инфраструктуре, где вы сможете раздать пользователям свой CA, чтобы софт не выдавал предупреждения о недоверенных сертификатах. Хотя для каких-то служб это не очень актуально. Например, для OpenVPN это некритично. Там сертификат CA обычно идёт вместе с конфигурацией без необходимости отдельной установки в систему.
Приложение очень простое и интуитивно понятное, особенно для тех, кто первый раз сталкивается с этой темой. Есть русский язык. Помню, как для меня было суперсложно и непонятно, когда впервые разбирался со скриптами easy-rsa для настройки своего первого OpenVPN сервера. Делал всё это в консоли, где никаких наглядных связей и привязок, только команды для генерации и ещё более длинные команды на базе openssl для просмотра сертификатов.
С одной стороны это хорошо, так как позволило быстрее вникнуть, напрячь мозги и разобраться с темой. С другой, не всем и не часто приходится этим заниматься, так что для разовых задач может быть проще и быстрее всё сделать в GUI. Если у вас нет дальнейших задач по автоматизации процессов, связанных с выпуском сертификатов, то в GUI по-любому будет быстрее и проще работать с сертификатами.
Работа с XCA выглядит следующим образом:
То есть всё как обычно при работе со своим CA. У меня были заметки по этой теме, но только для консоли:
▪️openssl - все действия на базе openssl.
▪️step-ca - своя локальная служба для управления CA с простой автоматизацией перевыпуска.
▪️CFSSL - современная одиночная утилита от cloudflare с конфигами в формате json.
Странно, что я впервые услышал об этой программе. Вообще не знал и не использовал ни одну локальную программу по этой теме. Веб интерфейсы видел, пользовался. В pfSense, кстати, удобный веб интерфейс для работы со своим CA.
⇨ 🌐 Сайт / Исходники
#security #tls
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍138👎2
Решил по приколу у различных нейросетей поспрашивать шутки про системных администраторов. Отправлял один и тот же запрос:
Придумай шутку про системного администратора.
Вот наиболее прикольные ответы:
- Почему системный администратор всегда спит спокойно?
- Потому что у него всегда есть резервная копия!
- Почему системный администратор никогда не теряет ключи?
- Потому что у него всегда есть бэкапы! 🔑💻🤣
- Почему системный администратор никогда не делает зарядку?
- Потому что ему всегда достаточно просто перезагрузить систему! 😄💻🔄
- Почему системный администратор всегда спокоен?
- Потому что он знает, что если что-то пойдет не так, у него всегда есть "план восстановления"!
Почему-то все шутки получались очень похожими, хотя я использовал разные модели. Когда надоело видеть шутки с "почему", стал спрашивать по-другому:
Придумай шутку про системного администратора без вопроса "почему".
Системный администратор — это человек, который знает, где хранятся все данные, но не помнит, где положил ключи от машины.
Системный администратор заходит в бар, заказывает пиво и говорит: "Надеюсь, у вас есть резервная копия этого напитка!"
- Зачем системный администратор всегда носит с собой лестницу?
- Чтобы подняться на новый уровень безопасности! 😄🔧
Системный администратор так любит свою работу, что даже на отдыхе обсуждает проблемы с маршрутизатором... с местным Wi-Fi! 😄
👆 Вот это было ничего 😂
Системный администратор заходит в аптеку и говорит: "Мне, пожалуйста, что-то от усталости. И чтобы не требовало перезагрузки!"
Почему системный администратор всегда в хорошем настроении? Потому что знает, как перезагрузить свою жизнь! 😄💻
Системный администратор на вечеринке: «У меня есть три состояния — рабочее, загруженное и не отвечаю. Вы находитесь в третьем!» 😄💻
Системный администратор заходит в кафе и говорит: "У вас есть Wi-Fi?" Бариста отвечает: "Да, конечно!" Администратор отвечает: "Отлично, я просто проверю, не упал ли ваш сервер!"
Пока, как я понимаю, юмористы могут спать спокойно. ИИ их не заменит в ближайшее время. А вот переводчикам я бы не позавидовал. Давно уже почти всё читаю и смотрю в автоматическом переводе. Качество среднего текста или видео вполне достойное для нормального восприятия смысла.
#юмор
Придумай шутку про системного администратора.
Вот наиболее прикольные ответы:
- Почему системный администратор всегда спит спокойно?
- Потому что у него всегда есть резервная копия!
- Почему системный администратор никогда не теряет ключи?
- Потому что у него всегда есть бэкапы! 🔑💻🤣
- Почему системный администратор никогда не делает зарядку?
- Потому что ему всегда достаточно просто перезагрузить систему! 😄💻🔄
- Почему системный администратор всегда спокоен?
- Потому что он знает, что если что-то пойдет не так, у него всегда есть "план восстановления"!
Почему-то все шутки получались очень похожими, хотя я использовал разные модели. Когда надоело видеть шутки с "почему", стал спрашивать по-другому:
Придумай шутку про системного администратора без вопроса "почему".
Системный администратор — это человек, который знает, где хранятся все данные, но не помнит, где положил ключи от машины.
Системный администратор заходит в бар, заказывает пиво и говорит: "Надеюсь, у вас есть резервная копия этого напитка!"
- Зачем системный администратор всегда носит с собой лестницу?
- Чтобы подняться на новый уровень безопасности! 😄🔧
Системный администратор так любит свою работу, что даже на отдыхе обсуждает проблемы с маршрутизатором... с местным Wi-Fi! 😄
👆 Вот это было ничего 😂
Системный администратор заходит в аптеку и говорит: "Мне, пожалуйста, что-то от усталости. И чтобы не требовало перезагрузки!"
Почему системный администратор всегда в хорошем настроении? Потому что знает, как перезагрузить свою жизнь! 😄💻
Системный администратор на вечеринке: «У меня есть три состояния — рабочее, загруженное и не отвечаю. Вы находитесь в третьем!» 😄💻
Системный администратор заходит в кафе и говорит: "У вас есть Wi-Fi?" Бариста отвечает: "Да, конечно!" Администратор отвечает: "Отлично, я просто проверю, не упал ли ваш сервер!"
Пока, как я понимаю, юмористы могут спать спокойно. ИИ их не заменит в ближайшее время. А вот переводчикам я бы не позавидовал. Давно уже почти всё читаю и смотрю в автоматическом переводе. Качество среднего текста или видео вполне достойное для нормального восприятия смысла.
#юмор
👍95👎19
🎓 В закладках около года лежала ссылка на плейлист из 14 лекций по SRE на канале T-образование от известного теперь уже T-банка. Решил его “посмотреть”. Понятно, что весь его просмотреть надо много времени. Комментарии к видео по непонятной причине закрыты, что навеяло на мысли о том, что там какая-то ерунда. Чтобы составить своё представление о том, что это, пришлось на скорости x2 прослушать первые две лекции.
Сначала было разочарование, потому что показалось не очень интересным, так как одни слова, никакой конкретики по технологиям и инструментам. То, к чему я сам привык в обучающих видео. Полистал остальной канал и по теме системного администрирования или devops ничего не нашёл. Хотя там много обучающего материала, но в основном для школьников 10-11 классов.
Начал закрывать вкладки с канала и уже в конце заметил название плейлиста: Лекторий по SRE. Тут я понял свою ошибку. Никто и не обещал обучающий курс. Это просто лекции по теме. Потом уже ещё раз пробежался по списку лекций и понял, что зря я его решил убрать в сторону. По теме SRE не так много структурированной информации на русском языке. А лекции эти были записаны в рамках бесплатного курса для опытных DevOps-инженеров и начинающих SRE-специалистов, который уже закрыт.
Так что если вам интересна тема SRE, вы занимаетесь самообразованием, или просто хотите быть в курсе современных направлений в IT, можете послушать эти лекции. Их не обязательно смотреть, можно именно слушать в машине или во время прогулок. Читает лекции Дмитрий Масленников — руководитель центра SRE в Т‑Банке.
▶️ Лекторий по SRE
Не забываем забирать в закладки. Видите, как бывает. Год прошёл, а я не забросил. Все свои списки так или иначе перебираю, хотя новой информации тоже вал идёт.
#обучение
Сначала было разочарование, потому что показалось не очень интересным, так как одни слова, никакой конкретики по технологиям и инструментам. То, к чему я сам привык в обучающих видео. Полистал остальной канал и по теме системного администрирования или devops ничего не нашёл. Хотя там много обучающего материала, но в основном для школьников 10-11 классов.
Начал закрывать вкладки с канала и уже в конце заметил название плейлиста: Лекторий по SRE. Тут я понял свою ошибку. Никто и не обещал обучающий курс. Это просто лекции по теме. Потом уже ещё раз пробежался по списку лекций и понял, что зря я его решил убрать в сторону. По теме SRE не так много структурированной информации на русском языке. А лекции эти были записаны в рамках бесплатного курса для опытных DevOps-инженеров и начинающих SRE-специалистов, который уже закрыт.
Так что если вам интересна тема SRE, вы занимаетесь самообразованием, или просто хотите быть в курсе современных направлений в IT, можете послушать эти лекции. Их не обязательно смотреть, можно именно слушать в машине или во время прогулок. Читает лекции Дмитрий Масленников — руководитель центра SRE в Т‑Банке.
Не забываем забирать в закладки. Видите, как бывает. Год прошёл, а я не забросил. Все свои списки так или иначе перебираю, хотя новой информации тоже вал идёт.
#обучение
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍76👎4
Набираем ИТ специалистов (полная занятость)
У нас растущий стартап с задачами:
1️⃣ Создание и разработка приложения для автоматизации ведения отчетов предприятий РФ в пищевой промышленности, построение сетевой инфраструктуры и контроля в данных предприятиях с целью обеспечения безопасности.
2️⃣ Создание и разработка ИТ решения для системы поиска и контроля персонала пищевых (и не только) предприятий, включая работу системы видеонаблюдения, нейро аналитики, СКУД.
❗️Мы ищем как людей с опытом в своей области, так и новичков, стремящихся расти и развиваться работая в команде с профессионалами. На данный момент требуются:
🔹Специалист пусконаладки и настройки сложных систем видеонаблюдения и аналитики, СКУД, слаботочных систем, проектирования архитектуры безопасности предприятий и объектов.
- Опыт работы с компьютерами и серверами на уровне сборки и установки операционной системы
- Умение работать с сетевым оборудованием и понимание основ сетевой безопасности
- Навыки диагностики и устранения неисправностей аппаратного и программного обеспечения
- Приветствуется опыт работы с ПО DSSL Trasir, Xeoma и другими специализированными решениями в области сетевого видеонаблюдения
Желание учиться и развиваться, следить за новыми технологиями в области ИТ-инфраструктуры
Оба проекта новые и интересные. Мы гарантируем гибкий подход, прекрасный коллектив и достойную оплату по результатам собеседования. ЗП вилка 100 - 150 тыс рублей + премии. Официальное оформление. Мы рады приветствовать новых специалистов, профессионалов и начинающие таланты.
За подробностями пишите в телеграмм @Q_Standard
⇨ https://q-standard.com
У нас растущий стартап с задачами:
1️⃣ Создание и разработка приложения для автоматизации ведения отчетов предприятий РФ в пищевой промышленности, построение сетевой инфраструктуры и контроля в данных предприятиях с целью обеспечения безопасности.
2️⃣ Создание и разработка ИТ решения для системы поиска и контроля персонала пищевых (и не только) предприятий, включая работу системы видеонаблюдения, нейро аналитики, СКУД.
❗️Мы ищем как людей с опытом в своей области, так и новичков, стремящихся расти и развиваться работая в команде с профессионалами. На данный момент требуются:
🔹Специалист пусконаладки и настройки сложных систем видеонаблюдения и аналитики, СКУД, слаботочных систем, проектирования архитектуры безопасности предприятий и объектов.
- Опыт работы с компьютерами и серверами на уровне сборки и установки операционной системы
- Умение работать с сетевым оборудованием и понимание основ сетевой безопасности
- Навыки диагностики и устранения неисправностей аппаратного и программного обеспечения
- Приветствуется опыт работы с ПО DSSL Trasir, Xeoma и другими специализированными решениями в области сетевого видеонаблюдения
Желание учиться и развиваться, следить за новыми технологиями в области ИТ-инфраструктуры
Оба проекта новые и интересные. Мы гарантируем гибкий подход, прекрасный коллектив и достойную оплату по результатам собеседования. ЗП вилка 100 - 150 тыс рублей + премии. Официальное оформление. Мы рады приветствовать новых специалистов, профессионалов и начинающие таланты.
За подробностями пишите в телеграмм @Q_Standard
⇨ https://q-standard.com
Q-Standard
Quality Standard - цифровые решения для вашего производства
Q-VISION - новый уровень контроля на любом предприятии.
Q-CHECK - одно приложение вместо десятков журналов.
Консалтинговые услуги в области управления качеством и контроля безопасности пищевых производств.
Проводим корпоративное и индивидуальное обучение.
Q-CHECK - одно приложение вместо десятков журналов.
Консалтинговые услуги в области управления качеством и контроля безопасности пищевых производств.
Проводим корпоративное и индивидуальное обучение.
👎73👍23
При обновлении кода сайта или веб сервиса легко сделать проверку изменений или выполнить откат в случае каких-то проблем. Задача сильно усложняется, когда обновление затрагивает изменение в структуре базы данных. Если вы накатили изменение, которое затрагивает базу данных, не получится просто откатить всё назад на уровне кода. Нужно откатывать и состояние базы. Для таких ситуация придумали миграции базы данных.
Сразу покажу на примере, как это работает. Существует популярная open source утилита для этих целей - migrate. Она поддерживает все наиболее распространённые СУБД. Миграции можно выполнять с помощью готовой библиотеки на Go, либо в консоли через CLI. Я буду использовать CLI, СУБД PostgreSQL и ОС Debian 12.
Для Migrate собран deb пакет, хотя по своей сути это одиночный бинарник. Можно скачать только его. Для порядка ставим из пакета, который берём в репозитории:
Для удобства добавим строку на подключение к локальной базе данных в переменную:
Я подключаюсь без ssl к базе данных test_migrations под учёткой postgres с паролем pass123. С рабочей базой так делать не надо, чтобы пароль не улетел в history.
Принцип работы migrate в том, что создаются 2 файла с sql командами. Первый файл выполняется, когда мы применяем обновление, а второй - когда мы откатываем. В своём примере я добавлю таблицу test01 с простой структурой, а потом удалю её в случае отката.
В директории были созданы 2 файла. В первый файл с up в имени добавим sql код создания таблицы test01:
А во второй с down - удаление:
Проверим, как это работает:
Смотрим, появилась ли таблица:
Вы должны увидеть структуру таблицы test01. Теперь откатим наше изменение:
Проверяем:
Таблицы нет. Принцип тут простой - пишем SQL код, который исполняем. На деле, конечно, изменения бывают сложные, особенно когда не добавляются или удаляются таблицы, а меняется структура существующих таблиц с данными. Инструменты типа migrate позволяют описать все изменения и проработать процесс обновления/отката в тестовых средах. В простых случаях можно обойтись и своими bash скриптами, но migrate упрощает эту задачу, так как, во-первых поддерживает множество СУБД. Во-вторых, автоматически нумерует миграции и исполняет последовательно. В-третьих, может, к примеру, забирать миграции напрямую из git репозитория.
Для каждой СУБД в репозитории Migrate есть примеры настройки миграций.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Исходники
#postgresql #mysql
Сразу покажу на примере, как это работает. Существует популярная open source утилита для этих целей - migrate. Она поддерживает все наиболее распространённые СУБД. Миграции можно выполнять с помощью готовой библиотеки на Go, либо в консоли через CLI. Я буду использовать CLI, СУБД PostgreSQL и ОС Debian 12.
Для Migrate собран deb пакет, хотя по своей сути это одиночный бинарник. Можно скачать только его. Для порядка ставим из пакета, который берём в репозитории:
# wget https://github.com/golang-migrate/migrate/releases/download/v4.18.1/migrate.linux-amd64.deb# dpkg -i migrate.linux-amd64.debДля удобства добавим строку на подключение к локальной базе данных в переменную:
# export POSTGRESQL_URL='postgres://postgres:pass123@localhost:5432/test_migrations?sslmode=disable'Я подключаюсь без ssl к базе данных test_migrations под учёткой postgres с паролем pass123. С рабочей базой так делать не надо, чтобы пароль не улетел в history.
Принцип работы migrate в том, что создаются 2 файла с sql командами. Первый файл выполняется, когда мы применяем обновление, а второй - когда мы откатываем. В своём примере я добавлю таблицу test01 с простой структурой, а потом удалю её в случае отката.
# cd ~ && mkdir migrations# migrate create -ext sql -dir migrations -seq create_test01_table~/migrations/000001_create_test01_table.up.sql~/migrations/000001_create_test01_table.down.sqlВ директории были созданы 2 файла. В первый файл с up в имени добавим sql код создания таблицы test01:
CREATE TABLE IF NOT EXISTS test01(
user_id serial PRIMARY KEY,
username VARCHAR (50) UNIQUE NOT NULL,
password VARCHAR (50) NOT NULL,
email VARCHAR (300) UNIQUE NOT NULL
);
А во второй с down - удаление:
DROP TABLE IF EXISTS test01;
Проверим, как это работает:
# migrate -database ${POSTGRESQL_URL} -path migrations up1/u create_test01_table (24.160815ms)Смотрим, появилась ли таблица:
# psql ${POSTGRESQL_URL} -c "\d test01"Вы должны увидеть структуру таблицы test01. Теперь откатим наше изменение:
# migrate -database ${POSTGRESQL_URL} -path migrations downAre you sure you want to apply all down migrations? [y/N]yApplying all down migrations1/d create_test01_table (15.851045ms)Проверяем:
# psql ${POSTGRESQL_URL} -c "\d test01"Did not find any relation named "test01".Таблицы нет. Принцип тут простой - пишем SQL код, который исполняем. На деле, конечно, изменения бывают сложные, особенно когда не добавляются или удаляются таблицы, а меняется структура существующих таблиц с данными. Инструменты типа migrate позволяют описать все изменения и проработать процесс обновления/отката в тестовых средах. В простых случаях можно обойтись и своими bash скриптами, но migrate упрощает эту задачу, так как, во-первых поддерживает множество СУБД. Во-вторых, автоматически нумерует миграции и исполняет последовательно. В-третьих, может, к примеру, забирать миграции напрямую из git репозитория.
Для каждой СУБД в репозитории Migrate есть примеры настройки миграций.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
⇨ Исходники
#postgresql #mysql
2👍95👎4