DevOps/Docker/converter.md

@@ -1,44 +0,0 @@
----
-title: Конвертация строки в compose
-description: 
-published: true
-date: 2025-06-17T09:20:55.103Z
-tags: docker
-editor: markdown
-dateCreated: 2025-06-17T09:20:07.483Z
----
-
-Я попал на сайт к какому-то девопсу, где были материалы по Playwright. Я немного походил по нему и набрёл на раздел DevTools (https://ray.run/tools). Он там собрал то ли свои, то ли просто open source инструменты для решения простых прикладных задач. Вроде ничего особенного, но некоторые вещи я просто не знал, что вообще существуют. Всегда их делал вручную. 
-
-Покажу сразу на примерах, что мне показалось полезным:
-
-- Docker Run to Docker Compose Converter (https://ray.run/tools/docker-run-to-docker-compose)
-Отправляем в форму однострочник с docker run и получаем файл для docker compose. Вроде мелочь, но я всегда это делал вручную. Не думал, что кому-то придёт в голову написать конвертер.
-
-- Docker Compose to Docker Run Converter (https://ray.run/tools/docker-compose-to-docker-run)
-И соответственно в обратную сторону преобразование из docker compose в однострочник для docker run. Не припоминаю, чтобы мне приходилось такие преобразования делать, но в тему к первому упоминаю.
-
-- Bash Command Formatter (https://ray.run/tools/bash-command-formatter)
-Эта штука тоже очень понравилась. Она длинный однострочник разбивает на строки с переходами через \ То есть вот такую колбасу:
-```
-curl -v --url "smtp://mail.server.ru:25" --mail-from "root@server.ru" --mail-rcpt "user@gmail.com" --user 'root@server.ru:password123' --upload-file ~/mail.txt
-```
-Нарезает на кусочки:
-```
-curl -v \
- --url "smtp://mail.server.ru:25" \
- --mail-from "root@server.ru" \
- --mail-rcpt "user@gmail.com" \
- --user 'root@server.ru:password123' \
- --upload-file ~/mail.txt
-```
-Я тоже всегда это вручную делал, особенно для публикации сюда. Можно упростить себе задачу.
-
-- URL Extractor (https://ray.run/tools/url-extractor)
-Просто кидаешь сюда любой текст, а на выходе получаешь набор ссылок, если они в нём присутствуют.
-
-Там много всяких конвертеров и анализаторов синтаксиса для json, yaml, toml, csv. Не стал обращать на них внимание, так как их существует десятки. Обычно просто в гугле ищут что-то подобное, когда надо преобразовать. Посмотрите список, может вам что-то ещё приглянётся. Меня впечатлили только эти четыре штуки.
-
-![photo_2025-05-16_16-20-53.jpg](/DevOps/attachments/photo_2025-05-16_16-20-53.jpg)
-![photo_2025-05-16_16-20-54.jpg](/DevOps/attachments/photo_2025-05-16_16-20-54.jpg)
-![photo_2025-05-16_16-20-54_(2).jpg](/DevOps/attachments/photo_2025-05-16_16-20-54_(2).jpg)

DevOps/PostgreSQL/instruments.md

@@ -1,82 +0,0 @@
----
-title: Инструменты для обслуживания postgresql
-description: 
-published: true
-date: 2025-06-17T09:33:07.672Z
-tags: postgresql
-editor: markdown
-dateCreated: 2025-06-17T09:33:07.672Z
----
-
-Расскажу про парочку инструментов, которые упростят обслуживание сервера PostgreSQL. Начну с наиболее простого - pgBadger (https://pgbadger.darold.net/examples/sample.html). Это анализатор лога, который на его основе генерирует отчёты в формате html. На выходе получаются одиночные html файлы, которые можно просто открыть в браузере. Сделано всё аккуратно и добротно, легко настраивается, отчёты наглядные и информационные. 
-
-🔹Чтобы было что анализировать, необходимо включить логирование интересующих вас событий. Для разовой отладки это всё можно включать на ходу, либо постоянно через файл конфигурации `postgresql.conf` и перезапуск сервера. Он обычно хорошо прокомментирован. Вас будут интересовать параметры, начинающие с log_*. Они собраны все в отдельном блоке. Для примера я включил почти всё:
-```
-log_min_duration_statement = 0
-log_checkpoints = on
-log_connections = on
-log_disconnections = on
-log_duration = on
-log_line_prefix = '%m [%p] %q%u@%d '
-log_lock_waits = on
-log_temp_files = 0
-log_timezone = 'Europe/Moscow'
-```
-Вся включенная статистика стала писаться в общий лог-файл `/var/log/postgresql/postgresql-17-main.log`. С ним и будем работать. Устанавливаем pgBadger:
-```
-# wget https://github.com/darold/pgbadger/archive/refs/tags/v13.1.tar.gz
-# tar xzvf v13.1.tar.gz
-# cd pgbadger-*
-# apt install make
-# make && make install
-```
-Анализируем лог файл:
-```
-# pgbadger /var/log/postgresql/postgresql-17-main.log
-```
-Тут же в директории, где его запускали, увидите файл out.html. Забирайте его к себе и смотрите. Там будет информация с общей статистикой сервера, информация по запросам и их типам, времени исполнения, подключениям, по пользователям, базам и хостам откуда подключались и много всего остального. 
-
-PgBadger удобен тем, что по сути это одиночный скрипт на Perl. Можно включить логирование в конфигурации, применить её через `SELECT pg_reload_conf();` без перезапуска сервера СУБД. Пособирать некоторое время данные, забрать лог и анализировать его. Логирование отключить и снова перечитать конфиг. В итоге всё будет сделано без перезапуска сервера.
-
-🔹Второй инструмент - PgHero (https://github.com/ankane/pghero), он показывает примерно то же самое, только в режиме реального времени и работает в виде веб сервиса. Для него уже надо создавать пользователя, настраивать доступ, отдельную базу. Немного другой подход. Надо будет дёргать сервер с СУБД.
-
-Надо перейти в консоль и создать необходимые сущности:
-```sql
-# su postgres
-# psql
-> CREATE USER pghero WITH PASSWORD 'pgheropass';
-> CREATE DATABASE pgherodb OWNER pghero;
-> \q
-```
-Разрешаем этому пользователю подключаться. Добавляем в `pg_hba.conf` строку:
-```
-host pgherodb  pghero  172.17.0.0/24  md5
-```
-`172.17.0.0/24` - подсеть, из которой будет подключаться PgHero. В данном случае это Docker контейнер, запущенный на этом же хосте. PostgreSQL должен принимать запросы с локального IP адреса, к которому будет доступ из Docker сети. Можно добавить в конфиг `postgresql.conf` параметр:
-```
-listen_addresses = 'localhost,172.17.0.1'
-```
-Перезапускаем PotgreSQL:
-```
-# systemctl restart postgresql
-```
-Запускаем PgHero в Docker контейнере:
-```
-# docker run -ti -e DATABASE_URL=postgres://pghero:pgheropass@172.17.0.1:5432/pgherodb -p 8080:8080 ankane/pghero
-```
-Идём на порт севера 8080, где запущен контейнер и смотрим информацию о PostgreSQL. Если у вас не настроено расширение **pg_stat_statements**, которое использует PgHero для сбора статистики, то установите его. Для этого в конфигурацию `postgresql.conf` добавьте параметры:
-```
-shared_preload_libraries = 'pg_stat_statements'
-pg_stat_statements.track = all
-pg_stat_statements.max = 10000
-track_activity_query_size = 2048
-```
-Перезапустите Postgresql и выполните в консоли СУБД:
-```sql
-> CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
-> GRANT pg_read_all_stats TO pghero;
-```
-Теперь можно возвращаться в веб интерфейс и смотреть информацию. По умолчанию, пользователь pghero не будет видеть запросы других пользователей, если ему не дать права superuser. Это можно исправить, выдав ему набор прав и ролей из этой инструкции (https://github.com/ankane/pghero/blob/master/guides/Permissions.md).
-
-![photo_2025-05-21_20-48-32.jpg](/DevOps/attachments/photo_2025-05-21_20-48-32.jpg)
-![photo_2025-05-21_20-48-32_(2).jpg](/DevOps/attachments/photo_2025-05-21_20-48-32_(2).jpg)

Hypervisors/Proxmox/Cluster/DestroyCluster.html

@@ -1,20 +0,0 @@
-<!--
-title: Удаление кластера Proxmox
-description: 
-published: true
-date: 2025-05-21T11:31:51.721Z
-tags: proxmox, cluster
-editor: ckeditor
-dateCreated: 2025-05-21T11:31:51.721Z
--->
-
-<p>systemctl&nbsp;stop&nbsp;pve-cluster.service</p>
-<p>systemctl&nbsp;stop&nbsp;corosync.service</p>
-<p>pmxcfs -l</p>
-<p>rm -rf /etc/pve/corosync.conf</p>
-<p>rm -rf /etc/corosync/</p>
-<p>killall pmxcfs</p>
-<p>systemctl&nbsp;restart&nbsp;pve-cluster.service</p>
-<p>cd&nbsp;/etc/pve/nodes</p>
-<p>ls</p>
-<p>rm -rf /etc/pve/nodes/pve-01/</p>

Hypervisors/Proxmox/Cluster/DestroyCluster.md

@@ -1,68 +0,0 @@
----
-title: Как удалить ноду из кластера Proxmox?
-description: 
-published: true
-date: 2025-05-22T09:28:25.522Z
-tags: proxmox, cluster
-editor: markdown
-dateCreated: 2025-05-21T11:31:51.721Z
----
-
-
-Перед удалением ноды важно убедиться в том, что все виртуальные машины и данные безопасно мигрированы или созданы резервные копии, чтобы избежать потери данных и поддерживать целостность кластера.
-1. Остановите службу "pve-cluster" на изолируемой ноде
-```
-systemctl stop pve-cluster.service
-systemctl stop corosync.service
-```
-2. Запустите команду для перевода файловой системы кластера на изолируемой ноде в локальный режим
-```
-pmxcfs -l
-```
-3. Запустите команду для удаления файлов конфигурации Corosync:
-```
-rm -rf /etc/pve/corosync.conf
-rm -rf /etc/corosync/*
-```
-4. Запустите команду для перезапуска службы файловой системы кластера:
-```
-killall pmxcfs
-systemctl start pve-cluster.service
-```
-5. Удалите файлы неисправной ноды:
-```
-cd /etc/pve/nodes
-ls
-rm -rf /etc/pve/nodes/pve2    # Path corresponding to the faulty node
-```
-6. Очистите остаточную информацию о кластере:
-```
-pvecm delnode NodeName
-```
-Здесь приведена информация по устранению распространенных проблем, с которыми вы можете столкнуться.
-
-Нода не отвечает: Если нода, которую вы хотите удалить, не отвечает из-за проблем с сетью или по другим причинам, вы можете использовать опцию Force для принудительного удаления ее из кластера:
-```
-pvecm delnode <NODE_NAME> --force
-```
-Застревание процесса удаления: В случае возникновения проблем с выполнением команды или застревания процесса во время удаления, вы можете диагностировать проблему, просмотрев системный журнал:
-```
-journalctl -xe
-```
-После устранения потенциальной проблемы попробуйте удалить ноду еще раз.
-
-```
-systemctl stop pve-cluster.service
-systemctl stop corosync.service
-pmxcfs -l
-rm -rf /etc/pve/corosync.conf
-rm -rf /etc/corosync/
-killall pmxcfs
-systemctl restart pve-cluster.service
-cd /etc/pve/nodes
-ls
-rm -rf /etc/pve/nodes/pve-01/
-pvecm delnode pve-01
-pvecm delnode pve-01 --force
-systemctl restart corosync.service
-```