Minio - Error has incorrect configuration Expected same MINIO_ environment variables and values across all servers

Thu, 20 Nov 2025 06:20:39 +0600

Сразу скажу, что проблема тут именно в параметрах, например, MINIO_COMPRESS_EXTENSIONS и т.д. Что нужно сделать первым делом? Конечно проверить переменные в файле /etc/default/minio, /etc/sysconfig/minio или в самом systemd файле сервиса MinIO.

Но в моём случае всё казалось одинаковым для человеческого глаза. В моём случае переменные были указаны в файле сервиса MinIO (/usr/lib/systemd/system/minio.service) и моя основная задача была в переносе существующей ноды MinIO на новый сервер с более новой ОС (CentOS 9). Поэтому я уже копировал существующий файл /usr/lib/systemd/system/minio.service со старого сервера на новый и как мне казалось ничего изменится не могло.

Как проверить что в итоге использует приложение?

А вот теперь я покажу что приложение MinIO видит иначе нежели мы. Если переменные передаются сервису в стиле Environment=MINIO_ROOT_USER=storeadmin, то можно посмотреть какие именно значения получает уже само приложение. Для этого выполняем:

sudo cat /proc/$(pidof minio)/environ | tr '\0' '\n' | grep MINIO_

MINIO_ROOT_USER=aaaa
MINIO_ROOT_PASSWORD=aaaa
MINIO_PROMETHEUS_AUTH_TYPE=public
CONSOLE_MINIO_SERVER=https://minio3:9000
MINIO_COMPRESS=on
MINIO_COMPRESS_EXTENSIONS=.txt,.log,.csv,.json,.tar,.xml,.bin,.pdf,.xls,.xlsx,.doc,.docx
MINIO_COMPRESS_MIME_TYPES=text/*,application/json,application/xml,application/pdf

И вроде бы всё нормально, но есть одно, но если выполнить туже команду на другой ноде (CentOS 7) я получу результат:

MINIO_ROOT_USER=aaaa
MINIO_ROOT_PASSWORD=aaaa
MINIO_PROMETHEUS_AUTH_TYPE=public
CONSOLE_MINIO_SERVER=https://minio3:9000
MINIO_COMPRESS="on"
MINIO_COMPRESS_EXTENSIONS=".txt,.log,.csv,.json,.tar,.xml,.bin,.pdf,.xls,.xlsx,.doc,.docx"
MINIO_COMPRESS_MIME_TYPES="text/*,application/json,application/xml,application/pdf"

Решение

Получается, что указанные переменные с двойными кавычками в файле /usr/lib/systemd/system/minio.service передаются приложению уже без них. Решением будет либо убрать все кавычки на всех нодах, либо же добавить знак \ перед кавычками.

Environment=MINIO_COMPRESS=\"on\"
Environment=MINIO_COMPRESS_EXTENSIONS=\".txt,.log,.csv,.json,.tar,.xml,.bin,.pdf,.xls,.xlsx,.doc,.docx\"
Environment=MINIO_COMPRESS_MIME_TYPES=\"text/*,application/json,application/xml,application/pdf\"

Далее я выполнил systemctl daemon-reload и нормально запустил ноду. Да я понимаю, что вариант с указанием переменных в самом systemd файле не совсем правильный, но иногда приходится работать с тем то имеешь. Да и у кого-то может быть такая же ситуация, а решения её в интернете я особо и не нашёл.

Решение 2

Может так оказаться что у вас разные версии MinIO на хостах. В таком случае нужно привести все узлы MinIO к одной версии.

Docker - Минимум что нужно знать для работы с Kubernetes (k8s)

Wed, 15 Oct 2025 06:20:39 +0600

В этой статье я не буду погружаться во все дебри контейнеризации, а лишь рассмотрю, что должен знать любой человек, начинающий работать с Kubernetes (k8s).

Что такое Docker? / Docker build / Docker image / docker pull / docker push / docker run /

Что такое Docker?

Docker — это платформа для контейнеризации, которая позволяет создавать, запускать и управлять приложениями в изолированных контейнерах. Сам Docker уже давно используется (2013 год) и, скорее всего, вы так или иначе с ним сталкивались.

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

Экономия ресурсов и бюджета

Давайте для примера рассмотрим компанию, разрабатывающую софт для нескольких проектов (проект А, проект Б, проект В). И под каждый проект приходится выделять три физических сервера. Почему так? На то много причин, и самая основная, конечно же, в том, что проекты не должны пересекаться, т.е. требуется изоляция каждого проекта от другого.

И в такой реализации следующие минусы: цена, обслуживание серверов, мониторинг состояния серверов.

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

Для начала на физический сервер устанавливается ОС, и потом в ней устанавливается программа контейнеризации (Docker, Podman и т.д.). Уже эта программа отвечает за работу контейнеров, в которых запущены проект А, проект Б, проект В.

Изоляция процессов

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

Быстрая развертываемость

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

При использовании определённого сервера, если необходимо проверить приложение на новой версии Python, что происходит:

Разработчик просит администратора обновить Python
В идеале администратор перед выполнением делает резервную копию сервера
Администратор обновляет Python на сервере, где происходит сборка проекта
Уведомляет о проделанной работе разработчика

А теперь рассмотрим, как это выглядит при использовании контейнеризации:

Разработчик может сам запустить сборку приложения в контейнере с образом новой версии Python. Тут не надо ничего устанавливать — просто меняется версия образа контейнера. ра.

Портативность (переносимость)

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

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

Docker image

Для того чтобы запустить контейнер, нам нужен образ контейнера (Docker image).

О том, что такое сам образ, можно говорить долго, но проще представить, что это очень сильно урезанная ОС с нужными библиотеками и самим кодом для работы вашего приложения.
Docker-образ — это минимальная упакованная система с вашим кодом, которая работает одинаково везде — на ПК, сервере или в облаке.

Например, у вас есть приложение, которое работает на Python. Для работы такого приложения вам понадобится запустить его внутри контейнера с образом Python, который весит около 100 МБ.

Docker build

Для того чтобы сделать образ, используется команда Docker build. Каждый образ состоит из слоёв — простым языком, каждый слой — это выполнение той или иной команды для создания образа.

Для примера рассмотрим следующий Dockerfile, необходимый для создания Docker image.

FROM python:3.11-slim << базовый образ с Dockerhub

COPY script.py /app/script.py << копирование локального файла в образ 
WORKDIR /app << смена основной директории (рабочей)

CMD ["python", "script.py"] << выполнение скрипта

Docker image состоит из слоёв, но не все слои одинаково “видимы” или сохраняются как отдельные файловые изменения. Инструкция CMD не создаёт файловых изменений, а значит, не создаёт отдельного слоя с данными.

Docker image repository

Теперь, когда мы знаем, что существуют образы Docker, встаёт вопрос — где их хранить? Хранят их в репозиториях образов, которые могут быть как приватными, так и публичными. Наиболее распространённый публичный репозиторий — это Docker Hub.

Для того чтобы хранить свои собственные образы внутри компании, не используя публичные репозитории, можно воспользоваться функциями Docker либо же использовать сторонние приложения, например, Sonatype Nexus Repository.

docker pull

Теперь, когда мы знаем, что каждый образ находится в том или ином репозитории, необходимо его скачать. Делается это при помощи команды docker pull.

Команда docker pull используется для скачивания Docker-образа из репозитория (обычно Docker Hub) на ваше локальное устройство.

docker pull ubuntu:latest
docker pull node:18

При выполнении команды docker pull происходит следующее:

Docker-клиент отправляет запрос к реестру репозитория
Если образ найден, он скачивается по слоям (каждый слой образа загружается отдельно)
Образ сохраняется локально и может использоваться для старта контейнеров

Также вы можете опустить выполнение этой команды, просто выполнив docker run.
Дело в том, что если образ ещё не скачан, то Docker под капотом сам выполнит docker pull и скачает необходимый образ.

docker push

Команда docker push используется для загрузки вашего локального Docker-образа (созданного с помощью docker build) в удалённый репозиторий (например, Docker Hub, GitLab Registry и т.д.).

Для загрузки образа в удалённый репозиторий иногда требуется авторизоваться.

docker login myregistry.com
docker push myregistry.com/project/app:latest

docker run

Самая часто используемая команда при работе с Docker. Эта команда создаёт сам контейнер и запускает его.

docker run -d --name myhttpd -p 8080:80 httpd

В команде выше:

-p 8080:80 — сопоставление локального порта 8080 с портом 80 контейнера
httpd — имя образа, с которого создаётся контейнер
-d — продолжать работу в фоне
--name myhttpd — задать имя контейнеру

Linux - Either the superblock or the partition table is likely to be corrupt!

Mon, 13 Oct 2025 04:22:39 +0600

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

Как узнать причину?

Для начала проверяю размер файловой системы с помощью tune2fs (только для ext2/3/4), xfs_info для xfs

sudo tune2fs -l /dev/sda1 | grep 'Block count\|Block size'

Block count:              2883072
Block size:               4096

Умножаю 2883072 на 4096 и получаю размер файловой системы (11Гб)

Проверяю размер раздела на жёстком диске

sudo parted /dev/sda p

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  9000MB  8999MB  ext4         primary

Проверяю доступен ли раздел

sudo e2fsck -f /dev/sda1

The filesystem size (according to the superblock) is 2883072 blocks
The physical size of the device is 2197009 blocks
Either the superblock or the partition table is likely to be corrupt!

sudo mount /dev/sda1 decrease/

mount: /home/admin/decrease: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

Т.е. размер файловой системы у меня больше чем размер раздела на жёстком диске.

Как решить?

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

Удалить другой раздел и освободить место на жёстком диске
Увеличить место на виртуальном жёстком диске (мой случай)
Может быть есть свободное место на диске

В общем в любом случае необходимо найти свободное место на жёстком диске.

sudo parted /dev/sda p

Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 11.8GB << тут 11Гб
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  9000MB  8999MB  ext4         primary << тут 9Гб

Соответственно у меня на диске есть еще 2 Гб свободного места, увеличиваем размер раздела жёсткого диска.
```
sudo parted /dev/sda
```
```
resizepart 1 100%
q
```

Проверяю доступен ли раздел

sudo e2fsck -f /dev/sda1

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 11/720896 files (0.0% non-contiguous), 71892/2883072 blocks

sudo mount /dev/sda1 decrease/

Docker - Первый веб-сервер в контейнере

Tue, 16 Sep 2025 06:20:39 +0600

Отлично, теперь, когда мы знаем, что такое Docker, самое время создать первый контейнер.
А внутри этого контейнера будет стоять Nginx.

docker container run (docker run)

Собственно, для создания контейнера используется команда docker run.
При этом, если образ для контейнера локально еще не загружен, произойдёт сперва его загрузка, а потом уже создание самого контейнера.

docker container run -d --name mynginx -p 80:80 nginx:latest

В итоге при выполненные команды docker container run -d --name mynginx -p 80:80 nginx:latest произошло:

Проверка скачан ли необходимый образ
Скачивание образа контейнера с Docker Hub если образа нет локально
Создание нового контейнера из этого образа с именем mynginx
Выдача виртуального ip-адреса в приватной сети Docker
Проброс локального порта 80 в контейнер (также порт 80).
Т.е. весь трафик на порт 80 сервера перебрасывается на порт 80 контейнера.
Запуск контейнера с выполнением команды CMD

Если вы хотите, чтобы ваш контейнер не работал постоянно в фоновом режиме, а только в интерактивном (пока не нажать CTRL + C), то нужно убрать опцию -d из команды.

docker container ls (docker ps)

Проверяем, что контейнер запущен с помощью команды docker ps,
которая выводит список всех запущенных контейнеров.
Если вдруг docker ps не выведет список контейнеров — добавьте опцию -a,
которая выведет список всех контейнеров (даже не запущенных).

CONTAINER ID   IMAGE         PORTS                               NAMES
39b04287fcf4   nginx:latest  0.0.0.0:80->80/tcp, :::80->80/tcp   mynginx

Теперь, когда контейнер запущен, можно проверить, что Nginx работает и отвечает на запросы.
Для этого локально можно выполнить запрос curl http://127.0.0.1:80 и в ответ получить:

<h1>Welcome to nginx!</h1>

Если же у вас локально стоит браузер, то, перейдя всё по тому же адресу (http://127.0.0.1:80),
в браузере должна открыться стандартная страница Nginx.

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

sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --reload
ip a

172.31.144.9

Далее в браузере открываем url http://172.31.144.9:80

docker container stop (docker stop)

Для остановки работающего контейнера используется команда docker stop.
В качестве аргумента нужно передать имя контейнера или его ID
(можно не писать весь ID), получить которые можно, выполнив команду docker ps.

docker stop mynginx
docker ps -a

CONTAINER ID   STATUS                        NAMES
39b04287fcf4   Exited (0) 14 seconds ago     mynginx

docker container start (docker start)

Для запуска остановленного контейнера используется команда docker start.
В качестве аргумента нужно передать имя контейнера или его ID (можно не писать весь ID), получить которые можно, выполнив команду docker ps.

docker start mynginx
docker ps

CONTAINER ID   STATUS                        NAMES
39b04287fcf4   Up 3 seconds                  mynginx

Не путайте команду docker start с docker run.

случайные имена для контейнеров

Если выполнить команду docker container run с опцией –name mynginx,
то имя у созданного контейнера будет mynginx.
Но это не всегда нужно — точнее, иногда это вообще только мешает.

Дело в том, что бывают ситуации, когда нужно запустить несколько экземпляров контейнера,
при этом не переживая за имена.
Чтобы это выполнить, запускаем команду docker container run без –name.

docker container run -d nginx:latest
docker container run -d nginx:latest
docker ps

CONTAINER ID   STATUS                  NAMES
e68a72f1ec7a   Up 2 seconds            interesting_mclaren
1acc09807f14   Up 3 seconds            fervent_lewin

docker container rm (docker rm)

Теперь настал момент, когда необходимо удалить все созданные контейнеры во время написания этой статьи.
Для удаления контейнера используется команда docker rm, в качестве параметра передаём имя контейнера (может быть несколько).

docker ps -a
docker rm mynginx 1acc f510

1acc
f510
Error response from daemon: cannot remove container "/mynginx": container is running: stop the container before removing or force remove

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

Docker - Что там внутри контейнера?

Tue, 16 Sep 2025 06:20:39 +0600

Отлично, вот вы запустили контейнер и дошли до того, что необходимо проверить, что там вообще происходит внутри этого самого контейнера.

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

docker run --detach --name some-mariadb -e MARIADB_ROOT_PASSWORD=my-secret-pw mariadb:latest

docker run --detach --name some-nginx nginx:latest

Первая команда запускает контейнер с базой MariaDB и назначает пароль пользователю root (my-secret-pw).
Для того, чтобы узнать, какие переменные окружения для чего используются, можно перейти на страницу образа в Docker Hub и почитать о нём немного, например.

docker container ls

CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS          PORTS      NAMES
bdc2d2440db9   nginx:latest     "/docker-entrypoint.…"   5 minutes ago    Up 5 minutes    80/tcp     some-nginx
ca55f6abaa03   mariadb:latest   "docker-entrypoint.s…"   23 minutes ago   Up 23 minutes   3306/tcp   some-mariadb

docker container top (docker top)

docker-container-top.svg

Выполняя docker container top можно проверить запущенные процессы внутри контейнера, по аналогии с top в самой ОС.

docker container top some-nginx

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                1950294             1950274             0                   16:49               ?                   00:00:00            nginx: master process nginx -g daemon off;
101                 1950338             1950294             0                   16:49               ?                   00:00:00            nginx: worker process

Логично, что в контейнере с Nginx запущены процессы с именем nginx. Теперь выполним то же самое для контейнера с MariaDB.

docker container top some-mariadb

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
systemd+            1950081             1950063             0                   16:31               ?                   00:00:00            mariadbd

UID — пользователь, от имени которого запущен процесс внутри контейнера;
PID — PID процесса в хостовой системе (тот, что виден в ps aux на хосте);
PPID — родительский процесс (обычно containerd-shim);
CMD — команда, запущенная внутри контейнера.

Тут довольно интересная графа PID. Дело в том, что в локальной системе, на которой установлен Docker, также создаётся процесс, как и в контейнере.

sudo ps -aux | grep mariadb

systemd+ 1950081  0.0  7.1 1093428 118860 ?      Ssl  16:31   0:00 mariadbd

Также можно отфильтровать поля, которые хочется видеть в выводе.

docker container top some-mariadb -eo pid,ppid,cmd

PID                 PPID                CMD
1950081             1950063             mariadbd

docker container inspect (docker inspect)

docker-container-inspect.svg

После того как контейнер создан, иногда бывает необходимо узнать о нём побольше — про его конфигурацию. Для этого используется команда docker container inspect. Команда docker container inspect — одна из самых полезных для диагностики и анализа контейнеров.

docker container inspect some-mariadb

Но вывод этой команды будет большим и поэтому показывать этот вывод тут не имеет никакого смысла. Она выводит всю внутреннюю информацию о контейнере в формате JSON. Стало быть можно использовать jq для парсинга вывода, но проще сразу использовать --format в самой команде.

Ниже оставлю наиболее популярные шаблоны docker inspect -fкоторые чаще всего используют DevOps-инженеры.

Показать IP контейнера

docker inspect -f '{{ .NetworkSettings.IPAddress }}' some-mariadb

Показать путь к логам

docker inspect -f '{{ .LogPath }}' some-mariadb

Показать порты, проброшенные на хост

docker inspect -f '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}{{ println }}{{ end }}' some-mariadb

Имя образа, из которого запущен контейнер
```
docker inspect -f '{{ .Config.Image }}' some-mariadb
```
Команда, с которой контейнер был запущен
```
docker inspect -f '{{ .Path }} {{ .Args }}' some-mariadb
```

Время запуска контейнера

docker inspect -f '{{ .State.StartedAt }}' some-mariadb

Текущий статус контейнера

docker inspect -f '{{ .State.Status }}' some-mariadb

Показать смонтированные каталоги

docker inspect -f '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}{{ println }}{{ end }}' some-mariadb

docker container stats

docker-container-stats.svg

Теперь перейдём к мониторингу, к вещи о которой все обычно вспоминают когда что-то выполняется настолько долго что уже всем это надоело. Команда docker container stats — это мониторинг в реальном времени. Она показывает ресурсы, которые потребляют контейнеры.

docker stats some-mariadb

CONTAINER ID   NAME           CPU %     MEM USAGE / LIMIT     MEM %     NET I/O       BLOCK I/O     PIDS
ca55f6abaa03   some-mariadb   0.00%     91.44MiB / 3.499GiB   2.55%     1.37kB / 0B   20MB / 53MB   9

CONTAINER ID / NAME - Идентификатор или имя контейнера
CPU % - Средняя загрузка CPU контейнера относительно всех яде
MEM USAGE / LIMIT - Используемая и лимитированная память
MEM % - Процент от лимита
NET I/O - Сетевой ввод/вывод (RX / TX)
BLOCK I/O - Дисковый ввод/вывод (чтение/запись на блочном уровне)
PIDS - Количество процессов внутри контейнера

Можно также выполнить команду docker stats без указания контейнера чтобы получить статистику всех запущенных контейнеров.

Ниже оставлю наиболее популярные шаблоны docker inspect -f которые чаще всего используются.

однократный вывод
```
docker stats --no-stream some-mariadb
```

красивое форматирование

docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}" some-mariadb

только CPU и память всех контейнеров

docker stats --format "{{.Name}}: CPU {{.CPUPerc}} | MEM {{.MemUsage}}"

вывод в формате json

docker stats --no-stream --format "{{json .}}" some-mariadb

docker container logs

docker-container-logs.svg

Ну и еще одна полезная команда docker container logs, которая покажет логи контейнера. Очень часто бывает так что контейнер не стартует после запуска, например если в качестве параметра не передать необходимые переменные.

docker container logs some-mariadb

2025-10-21 10:31:48 0 [Note] Server socket created on IP: '0.0.0.0', port: '3306'.
2025-10-21 10:31:48 0 [Note] Server socket created on IP: '::', port: '3306'.
2025-10-21 10:31:48 0 [Note] mariadbd: Event Scheduler: Loaded 0 events
2025-10-21 10:31:48 0 [Note] mariadbd: ready for connections.

Cледить за логами в реальном времени
```
docker container logs -f some-mariadb
```

Логи за последние 10 минут

docker container logs --since 10m some-mariadb

Последние 100 строк

docker container logs --tail 100 some-mariadb

Linux - Secondary partition table overlaps the last partition by 33 blocks

Thu, 11 Sep 2025 06:20:39 +0600

В этой статье я описывал как изменить MBR на GPT. Но если у вас весь диск занят существующим разделом, то вы получите предупреждение:

Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Если вкратце, то для создания GPT в конце диcка необходимо около 1 MiB свободного дискового пространства, именно неразмеченного. Почему так можете почитать тут.

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

Размер раздела и данные

Конечно же я рекомендую вам скопировать всё данные с диска или сделать резервную копию. Всегда что-то может пойти не так, будьте к этому готовы.
Не выставляйте размер раздела меньше чем весят данные на разделе. Т.е. если на /dev/sda1 у вас лежит 10 Гб данных не уменьшайте размер раздела меньше чем на 11 Гб.

Тип файловой системы XFS

К сожалению, если у вас тип файловой системы на разделе XFS, то уменьшить размер такого раздела у вас не получиться. Проще будет подключить новый диск, создав его как GPT и скопировать туда данные.

Для проверки типа файловой системы можно выполнить:

sudo parted /dev/sda p

Disk Flags:

Number  Start   End     Size    File system  Name              Flags
 1      1049kB  9000MB  8999MB  xfs         Linux filesystem

Тип файловой системы EXT

Если же тип файловой системы EXT4 или EXT3, то тут уже можно поработать.

Проверяем что у нас действительно MBR (msdos) и тип файловой системы EXT4

sudo parted /dev/sda p

Disk /dev/sda: 10.7GB
Partition Table: msdos
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  10.7GB  10.7GB  primary  ext4

Дальше необходимо размонтировать устройство (обязательно)
```
sudo umount /dev/sda1
```
Проверяем целостность структуры файлов ext4. Не должно быть никаких ошибок
```
sudo e2fsck -f /dev/sda1
```
Уменьшаем файловую систему ext4. Обратите внимание что я уменьшаю на целых 2 Гб. Дело в том, что сам размер раздела я собираюсь уменьшить на 1Гб, хотя можно и меньше. А вот размер файловой системы лучше указать меньше чем размер раздела. Размеры в resize2fs (файловая система) и resizepart (сам раздел) измеряются по-разному и округляются в разных единицах. Поэтому, если указать одно и то же число (например, 9G в обоих случаях), на самом деле:
- файловая система получится чуть больше (так как resize2fs считает в GiB — 1024³ байта),
- а раздел — чуть меньше (потому что parted считает в GB — 1000³ байт).
```
sudo resize2fs /dev/sda1 8G
```

Уменьшаем раздел до 9 GB

sudo parted /dev/sda
print
resizepart 1 9G
quit

Конвертируем MBR → GPT, подробнее тут
```
sudo gdisk /dev/sda
w
```

Проверяем таблицу и ФС

sudo parted /dev/sda print
sudo e2fsck -f /dev/sda1

Монтируем и проверяем доступ

sudo mount -a
sudo mount /dev/sda1 decrease/
ls decrease/

Как удалить logrotate и оставить сервер без логов

Thu, 11 Sep 2025 06:20:39 +0600

Сразу скажу, что эту операцию проделал не я (переустановка logrotate), я, лишь зайдя на сервер обнаружил что в /var/log/messages ничего не пишется уже какое-то время, ну и в другие лог файлы тоже.

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

Иду в SIEM дабы проверить кто и что удалял вообще на этом сервере и обнаруживаю что в этот день когда были последние логи человек удалил logrotate. Можно было конечно оставить этот момент, ведь он удалил logrotate, но не rsyslog. Да ещё при этом потом его установил заново.

Но я решая проверить через yum history что же всё-таки там удалилось. И вот я выполняю команду sudo yum history info 11 где в выводе получаю:

Packages Altered:
    Erase logrotate-3.8.6-19.el7.x86_64    
    Erase rsyslog-8.24.0-57.el7_9.3.x86_64

Т.е. помимо logrotate удалился и rsyslog. Хорошо проверяю как был установлен logrotate, для этого выполняю sudo yum history info 12 где в выводе получаю:

Packages Altered:
    Install logrotate-3.8.6-19.el7.x86_64

В итоге получается при удалении logrotate удалился также и rsyslog, но вот при установке logrotate сам rsyslog уже не устанавливался.

Как мне пришлось искать логи сервера в стоге сена.

Thu, 11 Sep 2025 06:20:39 +0600

История собственно о том, как пришлось находить файлы логов приложения, которые были очень важными для нас.

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

Владимир - собственно я
Илья - разработчик, который написал приложение
Олег - администратор
Емельян - ещё один администратор
Эльдар - ещё один администратор
Пользователь – вскоре вы узнаете почему безымянный

Так вот с чего началась вообще вся эта заварушка, некий Пользователь зашёл на наш веб-портал, где воспользовался некой услугой. Во время прохождения всех проверок выполнился запрос к сторонней организации (интеграция с гос бд) для проверки статуса человека. Через какое-то время этот Пользователь об этом узнал и накатал на нас заявление, мол как они могли и так далее. Да, пользовательское соглашение Пользователь конечно же подписал, но какое это имеет значение.

Так вот государственные органы решили нас проверить, т.е. отработать заявление. Как только мы поняли в чем Пользователь нас обвиняет стало понятно, что мы и не запрашивали эту информацию, о которой Пользователь так беспокоился. Илья (разработчик) сказал, что с лёгкостью это докажет, так как полный ответ запроса сохраняется в виде log файла на сервере. Осталось дело за малым, и он пришёл к Эльдару дабы тот нашёл этот файл и показал Илье, ну и проверяющей стороне.

Вот тут всё и начинается. Эльдар, зайдя на сервер обнаруживает что файла то этого нет, нас интересует файл от 24.01.2025. На сервере же нет log файлов (логов) в промежутке с 14.12.2024 до 15.03.2025, с учётом того что есть все файлы с 01.03.2023 по 14.12.2024 и после 15.03.2025, правда какая-то часть на другом сервере.

Дело в том, что файлы эти весят очень много и время от времени мы переносим их на другой сервер. Так вот именно Эльдар не-так давно перенёс все файлы за 2023 и что-то за 2024 на другой сервер. Он обращается за помощью к Емельяну, который считает, что может быть просто этот файл в последнем архиве за 14.12.2024 или в архиве за 15.03.2025. И они его не находят ни там, ни там.

Теория №1️⃣

Тут уже подключаюсь я (Владимир). Эльдар предполагает, что кто-то при переносе этих файлов на другой сервер мог их удалить и каким-то образом их не скопировать. Дело в том, что не только он один этим занимается. Дабы проверить эту теорию я захожу на SIEM систему и штудирую логи на предмет удаления файлов (все команды на сервере записываются). Как и ожидалось никто ничего не удалял, в этом я и не сомневался.

Теория №2️⃣

Появилась идея проверить каким образом эти файлы создаются и архивируются, дело в том, что каждый день создаётся архив с файлами. Мало ли как-то криво сработал cron или ещё что-то. Для этого мне нужно проверить логи системы в период с 14.12.2024 по 15.03.2025. Я захожу на сервер и пытаюсь прочитать содержимое /var/log/messages и тут я в ужасе понимаю, что последняя запись от 21.09.2024. Я тогда конечно подумал, что это конец, у меня нет ничего чтобы понять, что произошло. Собрался с мыслями и решил понять почему нет логов в /var/log/messages. В итоге по тем же логам SIEM я увидел, что 21.09.2024 Емельян удалял пакет logrotate, точнее переустанавливал его. Не буду расписывать чем именно это закончилось, просто скажу, что причину я нашел и починил. Если интересно можно прочитать тут.

Теория №3️⃣

Пока я разбирался с /var/log/messages я понял, что архивированием log файлов занимается само приложение. Появилась мысль что может кто-то из разработчиков случайно выложил что-то коряво и отключил логирование запросов интеграций. Илья пошёл проверять и вернулся с новостью что никто ничего не менял.

Тут я уже готов был сдаться, ведь самих файлов на сервере нет, логов всей системы на сервере нет с 21.09.2024 года. Чем мне собственно оперировать?

Теория №4️⃣

Точнее сказать это и не теория в общем а просто я решил проверить делали ли что-то с этим сервером на виртуализации (это виртуальный сервер). Я захожу на SIEM и вижу, что Олег выключает виртуальную машину (сервер где приложение) 14.12.2024 после создаёт вторую. Для лучшего понимания назовём SRV1 (сервер, который есть у меня сейчас) и SRV1_NEW (сервер, который создал и включил Олег с тем же ip). Соответственно к Олегу возникает вопрос: Зачем ты это сделал? На что Олег отвечает: это был 2024 год, я уже не помню. И вот тут уже сама Теория №4: файлы с 14.12.2024 по 15.03.2025 на сервере SRV1_NEW, осталось только его включить и получить доступ к файлам.

Но вот вопрос ведь сейчас запущен SRV1, почему? Захожу я на систему виртуализации и ищу SRV1_NEW и что вы думаете? Я его не нахожу (

Теория №5️⃣

Сервер SRV1_NEW кто-то дропнул и не видать теперь нам этих файлов. Но надо же удостоверится что его удалили. Снова иду в SIEM проверять логи и вижу только, что SRV1 был включен 15.03.2025 и никаких записей больше про SRV1_NEW, кроме последней где его включили 14.12.2024 (было пару reconfigre позже). Начинаем думать почему включили SRV1 15.03.2025 года и находим запись о том, что в этот день помер сервер виртуализации (померла планка ОЗУ).

Теория №6️⃣

Теперь, когда мы знаем, что помер сервер виртуализации и нет записи о том, что SRV1_NEW кто-то удалил логично предположить, что мы в тот день 15.03.2025 вручную регистрировали виртуальные машины с СХД на другом сервере виртуализации и так как про SRV1_NEW знали не все просто зарегистрировали только SRV1, ведь по сути это полностью рабочий сервер, зачем создали второй так и осталось тайной. Я полез на СХД искать SRV1_NEW и спустя какое-то время нашёл его. После чего я его зарегистрировал в виртуализации и включил, где и нашёл файлы с 14.12.2024 по 15.03.2025. В итоге наши жопы спасены и можно успокоить Пользователя что данные его наша система не получила, по крайней мере о которых он так переживал.

Выводы:

Старайтесь использовать SIEM, т.е. логируйте всё что можно. Логи очень пригодятся для доказательства вашей же невиновности
Конечно же нужно делать резервные копии и хранить как можно больше точек восстановления (но наш сервер весит около 5 ТБ).
Когда удаляешь какой-то пакет проверь что он унесёт вместе с собой

Docker Swarm - Virtual IP сервиса

Sat, 23 Aug 2025 06:20:39 +0600

При создании сервиса в Docker Swarm ему по умолчанию присваивается виртуальный ip-адрес. И при этом не важно сколько контейнеров (task) внутри сервиса, у каждого контейнера также свой ip-адрес.

Встаёт вопрос если у контейнера в сервисе итак есть ip-адрес зачем тогда еще присваивать ip-адрес самому сервису. Ответ очень банален, так как в сервисе может быть куча контейнеров, да и при пересоздании этих контейнеров их ip-адреса могут меняться логичнее будет обращаться к ip-адресу самого сервиса.

Дело в том, что сервис в Docker Swarm сам занимается балансировкой нагрузки. Т.е. запрос, отправленный на ip-адрес или dns имя сервиса автоматически отправляется на один из контейнеров (task) сервиса. При этом каждый следующий запрос уже уходит на другой контейнер. Получается, что при использовании сервиса балансировка более точная чем у dns round robin, который я рассматривал тут. При использовании dns round robin запросы зачастую могут обрабатываться одним и тем же контейнером несколько раз подряд.

Для примера я создам сеть backend_net и запущу в нём сервис web с тремя репликами. Контейнеры из образа nginxdemos/hello при обращении на порт 80 выводят имя контейнера и его ip-адрес, как раз то что необходимо.

docker network create -d overlay backend_net
docker service create --name web --network backend_net nginxdemos/hello
docker service scale replicas=3 web

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

docker service inspect web --format '' | jq

[
  {
    "NetworkID": "vvapjnzz507fpgu0l463purkc",
    "Addr": "10.0.1.2/24"
  }
]

swarm-service-vip.svg

Проверка балансировки

Для того чтобы продемонстрировать работоспособность балансировки сервисом я буду использовать контейнер с образа curlimages/curl. Обращаю внимание что этот контейнер должен быть в той же сети что и сам сервис web, иначе доступа у создаваемого контейнера к сервису не будет.

docker run -it --rm --network backend_net curlimages/curl sh

Но тут я получу ошибку: docker: Error response from daemon: failed to set up container networking: Could not attach to network backend_net: rpc error: code = PermissionDenied desc = network backend_net not manually attachable.

Дело в том что по умолчанию сеть создаваемая для swarm (-d overlay) по умолчанию защищена от добавления в неё контейнеров создаваемых пользователем в ручную. Если вдруг необходимо всё же создать сеть, в которую можно добавить и сервис и свои контейнеры используется опция --attachable, например docker network create -d overlay backend_net --attachable. Но я так делать не рекомендую, поэтому просто создам еще один сервис в сети backend_net. Но я меняю образ curlimages/curl на nginx так как в сервисе одноразовые контейнеры нельзя запустить.

docker service create --name curl --network backend_net nginx
docker serivce ps curl
docker exec -it curl.1.z00ox4hiojz7cd18nuc5bi0dn bash

Теперь находясь внутри контейнера я несколько раз запущу команду curl -s http://web | grep Server.

<p><span>Server&nbsp;address:</span> <span>10.0.1.5:80</span></p>
<p><span>Server&nbsp;name:</span> <span>ed97410e2761</span></p>

<p><span>Server&nbsp;address:</span> <span>10.0.1.6:80</span></p>
<p><span>Server&nbsp;name:</span> <span>443e6d24fa4b</span></p>

<p><span>Server&nbsp;address:</span> <span>10.0.1.3:80</span></p>
<p><span>Server&nbsp;name:</span> <span>e1939cbd1ed6</span></p>

Из вывода видно что каждый контейнер обработал по одному запросу, что доказывает работу балансировки сервисом.

swarm-vip-testing.svg

Важное замечание в отличии от простых контейнеров при использовании сервисов вы не сможете обращаться с физических узлов кластера напрямую к виртуальному ip-адресу сервиса или же самого контейнера (задачи) сервиса. Происходит это потому что для сервисов используется драйвер overlay, а для простых контейнеров bridge. Подробнее тут и тут

Docker Swarm - Обновление сервисов

Sat, 23 Aug 2025 06:20:39 +0600

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

Конечно же если обновляемый сервис представляет из себя простое веб-приложение или обычный статическую веб-страницу, то как правило проблем с обновлением такого сервиса не будет. Но вот обновление таких сервисов как база данных или любое хранилище, где есть важные данные требует особого внимания. Некоторые продукты имеют свои ограничения на обновление, например, с какой версии на какую можно обновиться. Всегда проверяйте такие ограничения заранее, тот факт, что вы используете контейнеризацию, не освобождает вас от таких ограничений. И ещё раз повторюсь перед тем как делать обновление в боевой среде попробуйте сделать это на тестовой среде. Может так произойти что новый контейнер запустится, но работать будет неправильно, и что еще хуже повредит важные данные. Поэтому важно использовать правильный healthcheck.

Отдельной команды для обновления стека в Docker Swarm нету, тут также используется команда docker stack deploy, при выполнении которой демон Docker проверяет были ли изменения в файле конфигурации по сравнению с текущим состоянием сервиса. И если такие есть он их применяет.

swarm-update-best-practices.svg

Обновление стека

Как я уже говорил при обновлении стека всё начинается с изменения файла конфигурации этого стека. После изменения конфигурации выполняется команда docker stack deploy -c conf.yml mystack. Docker используя разные API проверяет необходимо ли что-то обновить в стеке для актуализации стека.

Допустим стек называется full-app, файл full-app.yml я поправил (новый image, env, ports, secrets и т.д.). Команда обновления стека будет выглядеть так: docker stack deploy -c full-app.yml full-app.

docker stack deploy -c full-app.yml full-app
docker service logs -f full-app_api
vim full-app.yml

    ports:
      - "8080:8000"
    deploy:
      replicas: 3

docker stack deploy --detach=false -c full-app.yml full-app

Updating service full-app_api (id: jkpbmz088nsgyvt0fdhyueqhj)
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: ready     [======================================>            ]
Updating service full-app_db (id: veg3bbimuapyqpj5y99s52bq3)

curl http://172.31.144.9:8080/items

[{"created_at":"Fri, 19 Dec 2025 06:19:48 GMT","id":1,"name":"adasdasd"},{"created_at":"Fri, 19 Dec 2025 06:19:50 GMT","id":2,"name":"fadsfasf"}]

swarm-stack-update-process.svg

Пример: обновить secret “правильно” (secrets immutable)

Для этого примера я буду использовать этот файл конфигурации, где по сути тоже самое что и выше, но только с использованием переменных (psql_user, psql_pwd). Моя задача тут поменять пароль, т.е. я создаю новый секрет psql_pwd_v2 и заменяю в файле старый psql_pwd. После чего делаю снова deploy.

printf "NEWPASS" | docker secret create psql_pwd_v2 -
docker secret ls

lbcx1yqjiuwcioorjbwjjdlyf   psql_pwd_v2

docker stack deploy --detach=false -c full-app.yml full-app-2
vim full-app.yml

services:
  api:
    environment:
       DB_PASSWORD_FILE: /run/secrets/psql_pwd_v2
    secrets:
      - psql_pwd_v2
  db:
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/psql_pwd_v2
    secrets:
      - psql_pwd_v2

secrets:
  psql_pwd_v2:
    external: true

docker stack deploy -c stack.yml full-app1

Но нужно понимать что в самой базе данных postgresql пароль не поменяется т поэтому в логах сервиса full-app-2_db я буду видеть ошибки: FATAL: password authentication failed for user "app".

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

docker exec -it full-app-3_db.1.vk23xvu50sy4fgdzrtq6ngvg2 bash
psql -d app -U app

alter user app with password 'NEWPASS';

curl http://172.31.144.9:8000/items

[{"created_at":"Fri, 19 Dec 2025 10:24:46 GMT","id":1,"name":"adsd"},{"created_at":"Fri, 19 Dec 2025 10:24:48 GMT","id":2,"name":"fadfsdf"},{"created_at":"Fri, 19 Dec 2025 10:24:50 GMT","id":3,"name":"fsfsdf"}]

swarm-secret-update-process.svg

Обновление сервиса

В отличии от стека у сервиса есть отдельная команда для обновления, которая выглядит так docker service update. Этой команду в качестве параметров передаётся конфигурация сервиса, которую необходимо поменять. Параметров там немало, поэтому не лишним будет выполнить команду docker service update --help, чтобы получить весь их список и почитать что для сего нужно.

Ниже я рассмотрю пару наиболее часто используемых вариантов обновления сервиса.

swarm-service-update.svg

Обычное обновление образа сервиса

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

docker service create --name web --replicas 4 -p 9090:80 nginx:1.28.0 
docker service ps web

ID             NAME      IMAGE          NODE             DESIRED STATE   CURRENT STATE            ERROR     PORTS
ffi9itlvqvgp   web.1     nginx:1.28.0   c-stream-9-vm8   Running         Running 13 seconds ago
vsmrr3xqisjn   web.2     nginx:1.28.0   c-stream-9-vm9   Running         Running 12 seconds ago
7wo9yat2er2s   web.3     nginx:1.28.0   c-stream-9-vm4   Running         Running 12 seconds ago
t7cag7wk1gni   web.4     nginx:1.28.0   c-stream-9-vm8   Running         Running 13 seconds ago

docker service update --image nginx:1.29.0 web
docker service ps web

isos2i46pwz7   web.1       nginx:1.29.0   c-stream-9-vm8   Running         Running 15 seconds ago
ffi9itlvqvgp    \_ web.1   nginx:1.28.0   c-stream-9-vm8   Shutdown        Shutdown 17 seconds ago

Изменить публикацию портов

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

Для этого придётся использовать два параметра:

--publish-rm - удаляет проброс порта
--publish-add - добавляет проброс порта

docker service update --publish-rm 9090:80 --publish-add 9091:80 web
docker service inspect -f "" web | jq

[
  {
    "Protocol": "tcp",
    "TargetPort": 80,
    "PublishedPort": 9091,
    "PublishMode": "ingress"
  }
]

Если нужно добавить дополнительный проброс порта, то просто используем --publish-add.

docker service update --publish-add 9092:80 web
docker service inspect -f "" web | jq

[
  {
    "Protocol": "tcp",
    "TargetPort": 80,
    "PublishedPort": 9091,
    "PublishMode": "ingress"
  },
  {
    "Protocol": "tcp",
    "TargetPort": 80,
    "PublishedPort": 9092,
    "PublishMode": "ingress"
  }
]

Порядок замены старых контейнеров

По умолчанию при обновление сервиса Docker запускает новые контейнеры (задачи), после чего проверяет их работоспособность (healthcheck). Если всё нормально только после этого останавливается старый контейнер. Таким образом можно избежать простоев (zero-downtime). Но это поведение можно изменить добавив параметр –update-order, который может принимать следующие значения:

start-first - Сначала запускается новый контейнер. Только после того, как он перейдет в состояние running и успешно пройдет проверку здоровья (healthcheck), Docker остановит и удалит старый контейнер.
stop-first - Сначала остановить старый, потом запустить новый. Используется, если нельзя запускать две копии приложения одновременно (например, из-за конфликта доступа к базе данных или портам).

swarm-update-order.svg

docker service update --update-order start-first  --update-parallelism 1  --update-delay 5s  web

Если выполнить команду выше произойдёт следующее:

Docker выбирает один старый контейнер.
Запускает рядом новый контейнер с обновленным образом/конфигурацией (start-first).
Ждет, пока новый контейнер станет «здоров» (healthcheck).
Удаляет старый контейнер.
Выдерживает паузу в 5 секунд (update-delay).
Переходит к следующему контейнеру и повторяет процесс, пока не обновит все реплики по одной (update-parallelism 1).

Откат обновления

Если вдруг после обновления что что-то пошло не так, есть шанс вернуть всё назад. Для этого используется команда docker service rollback, которая немедленно откатит сервис к его предыдущей конфигурации.

В качестве параметров можно использовать все те же параметры что и для команды update выше. Но тут есть один хороший параметр –rollback-monitor, который задаёт время наблюдения за контейнером после отката, чтобы убедиться, что он не помер.

Тут важно понимать что откат приведёт к отмене только последней операции обновления.

Т.е. выполняя все обновления для сервиса web выше у меня в итоге получилось:

Состояние (1): Создание сервиса (nginx:1.28.0, порт 9090).
Состояние (2): Обновление образа на nginx:1.29.0.
Состояние (3): Изменение порта с 9090 на 9091.
Состояние (4): Добавление еще одного порта (9092). Это текущее состояние.

Т.е. выполнив команду docker service rollback web сервис вернётся к Состоянию (3), т.е. отменится только проброс еще одного порта (9092).

docker service rollback web
docker service inspect -f "" web | jq

[
  {
    "Protocol": "tcp",
    "TargetPort": 80,
    "PublishedPort": 9091,
    "PublishMode": "ingress"
  }
]

swarm-service-rollback.svg

docker service update –force

Команда docker service update --force web сделает принудительное обновление сервиса web, даже если нет никаких обновлений. Да, кажется, что выполнении этой команды бессмысленно, но бывают всё же ситуации, когда это необходимо. Команда docker service update --force нужна для принудительно пересоздания всех тасков (контейнеров) сервиса, это “rolling restart” сервиса. Что это даёт на практике:

По очереди останавливает старые контейнеры и поднимает новые (по правилам update_config).
VIP/имя сервиса остаются теми же.

И вот несколько примеров для чего это реально можно использовать:

“Перезапуск” сервиса без простоя. В Swarm нет команды docker service restart, поэтому используется docker service update --force
Подтянуть новый образ. Если вы в качестве тэга образа указали latest (что не есть хорошо), то при пересоздании контейнера ноды кластера могут заново стянуть образ (если он изменился)
Обновить конфиги, которые менялись. Если вдруг вы что-то изменили снаружи сервиса (файлы/конфиги) --force гарантирует пересоздание контейнеров, чтобы они заново прочитали состояние на старте. Контейнеры могут видеть новый файл, но процесс внутри не перечитает, пока не перезапустишь/не сделаешь reload. Самый, наверное, распространенный пример это когда необходимо обновить TLS сертификаты, в идеале это происходит минимум раз в год.
Убить “залипшие” приложения. Утечка памяти, зависшие коннекты, забитый пул, deadlock — проще сделать rolling restart. Семь бед - один ресет.
Переместить задачи (контейнеры). Если вдруг узлы кластера стали недоступны и задачи (контейнеры) пересоздались на других узлах может помочь вернуть нормальную балансировку.

Но не переживайте команда docker service update --force не удаляет volume (данные в томах остаются).

swarm-service-update-force.svg

тут надо показать что с 2 репликами всё отвалится из-за файлов

Для примера я создам сервис с образа nginx:1.28.0 с одной репликой и прокину туда файлы index.html и hello.conf, также проброшу порт 80.

Все файлы можно получить тут.

docker service create   --name hello-service   --publish published=80,target=80 -  --mount type=bind,source=$(pwd)/index.html,target=/usr/share/nginx/html/index.html,readonly   --mount type=bind,source=$(pwd)/hello.conf,target=/etc/nginx/conf.d/default.conf,readonly   nginx:1.28.0

Теперь я проверю что находится внутри файла index.html в самом контейнере (задачи) сервиса, логично что тоже самое что и внутри файла на самом хосте.

docker exec hello-service.1.ov4e9s1k54w156zcm23nr1ies cat /usr/share/nginx/html/index.html

<h1>Hello</h1>

Поменяю строку <h1>Hello</h1> на <h1>Hello Again</h1> и проверю подтянулись ли изменения в сам контейнер сервиса.

vim index.html

<h1>Hello Again</h1>

docker exec hello-service.1.ov4e9s1k54w156zcm23nr1ies cat /usr/share/nginx/html/index.html
```json
<h1>Hello</h1>

Оказалось, что нет, и выходом здесь для меня будет выполнить команду docker service update --force

docker service update --force hello-service
docker exec hello-service.1.qmcb2mqu3mnvvf2siu9ubenna cat /usr/share/nginx/html/index.html

<h1>Hello Again</h1>

Если же говорить про секреты самого Swarm то тут по сути обновления нет, их нельзя нельзя “поменять на месте”. Единственный путь — это создать новый секрет прокинуть его в контейнер, но придётся и приложение переписывать для использования нового секрета.

swarm-force-update-example.svg

Docker - Хранилище образов

Sat, 23 Aug 2025 06:20:39 +0600

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

На что стоит обратить внимание при создании своего локального репозитория:

Всегда используйте ssl для прода. По умолчанию Docker всегда будет пытаться скачать образы с репозитория используя протокол https. Но эта статья носит характер лишь ознакомления с локальным репозиторием, поэтому здесь я буду использовать http.
Удаление старых неиспользуемых образов. Если у вас бывают ситуации что в день происходит сборка или скачивание образов не один раз, то через какое-то время образы могут занимать очень много дискового пространства. Поэтому если эти образы более не используются рекомендуется их удалять.

Вариант 1️⃣: Используем образ registry

Суть идеи в том, что создаётся контейнер, внутри которого репозиторий. Далее вы выкачиваете (pull) образ с DockerHub или любого другого репозитория себе на локальное устройство, можно даже импортировать образ из архива локально. Главное, чтобы локально у вас был тот самый образ, который вы хотите разместить в своём репозитории. После того как образ скачан можно его отправить (push) в локальный репозиторий.

1️⃣ Разворачиваем сам контейнер

Для создания локального репозитория будем использовать образ registry. Но так как это пример я не буду сейчас тонко настраивать этот репозиторий. Я лишь покажу что можно использовать для хранения образов локально и поэтому сейчас не буду настраивать https. Если вдруг это вам необходимо напишите об этом в комментарии.

mkdir /opt/docker-registry
docker run -d -p 5000:5000 -v /opt/docker-registry:/var/lib/registry --name my-registry registry:2
docker ps

b5d2f73cb0aa   registry   "/entrypoint.sh /etc…"   39 seconds ago   Up 38 seconds   0.0.0.0:5000->5000/tcp, [::]:5000->5000/tcp   my-registry

2️⃣Скачиваем образ

Для примера я загружу образ nginx:1.29.4, и после загрузки проверю что локально на моём устройстве он присутствует.

docker pull nginx:1.29.4
docker image ls nginx

nginx:1.29.4 4af177a024eb        161MB             0B

3️⃣Тэгируем скачанный образ

Добавляем новый тэг для загруженного образа. Дело в том, что если вы используете любой другой репозиторий, не DockerHub то и наименование вашего образа должно содержать dns имя этого репозитория, ну или ip-адресс если нет dns имени. Для примера у того же Microsoft есть свой публичный репозиторий и если мы хотим скачать что-то оттуда то имя образа уже будет содержать не только привычное нам имя приложения (nginx) а еще и полный путь образа (mcr.microsoft.com/dotnet/framework/runtime), т.е. при тэгировании образа для репозитория вы должны придерживаться следующему наименованию [HOST[:PORT]/][NAMESPACE/]REPOSITORY[:TAG].

docker tag nginx:1.29.4 172.31.144.9:5000/nginx:1.29.4
docker image ls | grep nginx

172.31.144.9:5000/nginx:1.29.4   4af177a024eb        161MB             0B

Во многих примерах вы можете встретить записи localhost/127.0.0.1 но я рекомендую прописывать сразу локальный ip-адресс хоста, тем более если репозиторий вы развернул на другом устройстве в сети, а push/pull делаете с другого.

4️⃣Загрузка образа в локальный репозиторий

Теперь самое простое, так как по умолчанию нет никакой авторизации для загрузки образа в репозиторий созданный из образа registry мы просто прописываем push.

docker push 172.31.144.9:5000/nginx:1.29.4

Get "https://172.31.144.9:5000/v2/": http: server gave HTTP response to HTTPS client

Но при попытке сделать push я получаю ошибку, потому что по умолчанию Docker пытается использовать https. Для того чтобы он не пытался это делать при обращении к 172.31.144.9, нужно прописать этот ip-адресс в файле /etc/docker/daemon.json.

⚠️ Внимание: Перезапуск Docker daemon остановит все запущенные контейнеры, включая my-registry. После перезапуска нужно запустить контейнер заново.

sudo vim /etc/docker/daemon.json

{
  "insecure-registries": ["172.31.144.9:5000"]
}

sudo systemctl restart docker
docker info
docker start my-registry
docker push 172.31.144.9:5000/nginx:1.29.4

1.29.4: digest: sha256:a6dd519f4cc2f69a8f049f35b56aec2e30b7ddfedee12976c9e289c07b421804 size: 1778

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

sudo tree /opt/docker-registry/docker/registry/v2/repositories/nginx/_manifests

/opt/docker-registry/docker/registry/v2/repositories/
    ├── _manifests
    │   ├── revisions
    │   │   └── sha256
    │   │       └── a6dd519f4cc2f69a8f049f35b56aec2e30b7ddfedee12976c9e289c07b421804
    │   │           └── link
    │   └── tags
    │       └── 1.29.4
    │           ├── current
    │           │   └── link
    │           └── index
    │               └── sha256
    │                   └── a6dd519f4cc2f69a8f049f35b56aec2e30b7ddfedee12976c9e289c07b421804
    │                       └── link

Ну или можно просто перейти по ссылке http://172.31.144.9:5000/v2/_catalog дял того, чтобы проверить какие образы находятся в репозитории.

5️⃣Скачиваем образ уже с локального репозитория

Теперь, когда я захочу загрузить образ не с репозитория DockerHub а с локального репозитория я также выполняя команду docker pull указываю полный путь образа. Но опять же не забываем добавить исключение в daemon.json.

docker pull 172.31.144.9:5000/nginx:1.29.4

docker-registry-setup.svg

6️⃣Создаём кэширующий репозиторий

И теперь представим ситуацию что вдень нужно загрузить около 5-10 образов и каждый раз так выкачивать образы с DockerHub в локальный репозиторий делать вручную проблематично. Поэтому проще сделать кэширующий registry.

sudo vim /opt/docker-registry/config.yml

version: 0.1
log:
  level: info
storage:
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000
proxy:
    remoteurl: https://registry-1.docker.io

docker rm -f my-registry
docker run -d \
--name registry-mirror \
-p 5000:5000 \
-v /opt/docker-registry/config.yml:/etc/docker/registry/config.yml \
-v /opt/docker-registry:/var/lib/registry \
registry:2

Теперь можно делать pull напрямую через registry, он сам перенаправит запрос на https://registry-1.docker.io и выкачает образ себе, после чего отдаст нам. И если при другой компьютер в сети сделает тот же самый pull то registry сперва проверит есть ли какие-то обновления в образе на самом DockerHub и если их нет он отдаст образ, который есть у него локально. Т.е. не будет постоянно заново выкачивать образы при каждом обращении.

docker pull 172.31.144.9:5000/library/nginx:1.28.1-alpine-otel
sudo find /opt/docker-registry/ -name 1.28.1-alpine-otel

/opt/docker-registry/docker/registry/v2/repositories/library/nginx/_manifests/tags/1.28.1-alpine-otel

Также чтобы постоянно не писать полный путь до репозитория (172.31.144.9:5000/library/) при выполнении команды docker pull можно прописать зеркало в файле /etc/docker/daemon.json.

sudo vim /etc/docker/daemon.json

{
  "registry-mirrors": ["http://172.31.144.9:5000"]
}

sudo systemctl restart docker
docker pull library/nginx:1.28-alpine3.23

docker-registry-caching.svg

Вариант 2️⃣: Используем nexus sonatype

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

Для начала создаём контейнер из образа sonatype/nexus3. После того как контейнер поднимется можно переходить в браузере по ссылке http://172.31.144.9:8081/.

docker run -d -p 8081:8081 -v nexus-data:/nexus-data --name nexus sonatype/nexus3

При первом входе необходимо вбить автоматически сгенерированный пароль и после поменять его на свой. имя пользователя admin.

docker exec -it nexus bash
cat /nexus-data/admin.password

25689260-a833-4193-adf5-1b210be3ab30

Далее переходим к настройке, наша основная цель - это создание прокси репозитория для DockerHub и включение возможности анонимного docker pull.

Переходим по ссылке и создаём прокси репозиторий для Docker.
Не забываем включить Enable anonymous access.
Дальше идём http://172.31.144.9:8081/#admin/security/realms и делаем так.

Теперь всё готово для использования только что созданного локального репозитория и магия тут в том, что не нужно ничего выкачивать с DockerHub я напрямую обращусь к локальному репозиторию дальше сам Nexus пойдёт на DockerHub и скачает образ, разместит его у себя и уже после отдаст мне образ с локального репозитория. Т.е. вместо 3 запросов как в примере ранее тут достаточно выполнить один запрос. При этом если образ на DockerHub не менялся, то и при последующем запросе сам Nexus не будет его скачивать заново.

docker pull 172.31.144.9:8081/dockerhub-proxy/nginx:1.28.1-alpine

Если же вам нужно загружать свои образы в репозиторий то необходимо создай другой docker репозиторий (hosted).

nexus-sonatype-setup.svg

Сравнительная таблица: Registry vs Nexus

Docker - Healthchecks

Sat, 23 Aug 2025 06:20:39 +0600

Если используется контейнеризация Docker в боевой среде, настоятельно рекомендуется использовать Healthcheck для сервисов, контейнеров и т.д. Особенно если используется Docker Swarm.

Напомню, что основная цель Docker Swarm это работа приложения без простоя zero-downtime. Если просто запуск сервиса еще можно пережить без Healthcheck, то вот обновление уже сложнее. Дело в том, что при обновлении сервиса Docker Swarm считает контейнер рабочим только если получил от него ответ, по умолчанию ответ - это просто уведомление о том что приложение (nginx, postgresql, custom app) внутри контейнера запустилось и работает.

Согласитесь, тот факт, что приложение внутри контейнера запустилось еще не говорит о том, что это полностью рабочий контейнер. Например, есть контейнер с Nginx, который должен отобразить страницу с тестом Hello. По умолчанию Docker посчитает контейнер рабочим просто потому что внутри стартанул Nginx, при этом он понятия не имеет что получит пользователь при обращении к контейнеру. В идеале я хочу, чтобы пользователь 100% получил страницу с текстом Hello. Вот тут я и могу использовать Healthcheck, настроить его так чтобы видеть действительно ли контейнер отдаёт пользователю то что необходимо.

docker-healthcheck-comprehensive.svg

Как это работает

При создании контейнера Docker выполняет внутри него команду, которую указываю я. И если эта команда возвращает Код выхода (Exit Codes) 0, то контейнер считается рабочим и запускается.

Коды выхода могут быть следующими:

0 (Успех): Контейнер исправен
1 (Сбой): Контейнер неисправен
2 (Резерв): Этот код зарезервирован для Docker и не рекомендуется для использования

В зависимости от ответа контейнер может иметь следующий из статусов:

healthy — всё ок (0)
unhealthy — проверка не проходит (1)
starting — контейнер запущен, но ещё идёт проверка работоспособности (Healthcheck)

При этом важно понимать, что сам Docker не пытается ничего исправить он просто выполняет проверку работоспособности и выставляет статус. Максимум что он может сделать это попытаться перезапустить контейнер, если вы это настроили. А вот Docker Swarm автоматически пересоздаёт unhealthy задачи и исключает их из load balancer.

Основные параметры

Сам Healthcheck можно использовать и в Dockerfile, сервисах, стеках, в docker compose и даже docker run. Вот некоторые самые распространённые параметры для Healthcheck:

interval: Время между попытками проверки (по умолчанию: 30 с). Т.е. если первая проверка прошла неудачно (нет ответа 0), то следующая попытка проверки через этот интервал времени
timeout: Максимально допустимое время для выполнения одной проверки (по умолчанию: 30 секунд). Т.е. ждём ответа от контейнера в течении этого интервала времени.
retries: Количество последовательных сбоев, необходимых для того, чтобы пометить контейнер как неисправный (по умолчанию: 3).
start-period: Льготный период после запуска, в течение которого сбои не учитываются в лимите повторных попыток (по умолчанию: 0 с). Это как ожидание перед первой проверкой. Обратите внимание что если в течении 30 с (interval) контейнер не ответил 0 на Healthcheck, то он будет считаться неисправным. Отсюда вывод что если приложение в контейнере стартует очень долго (дольше 30 с), то этот параметр нужно выставить больше чем 30 секунд. Т.е. если ваше приложение стартует дольше 30 секунд, то вы получите ложное срабатывание неисправного контейнера.

Для примера если контейнер не вернул значение Hello, точнее не вернул код 0 в течении, времени которое занимает на проверку (interval + retries) то статус такого контейнера становится unhealthy и он отключается.

Пример с docker run

docker-healthcheck.svg

Для начала я создам образ c index.html, который выведет текст Hello при обращении к Nginx (nginx.conf). Саму команду HEALTHCHECK я помещу в Dockerfile, чтобы проверка происходила при каждом создании контейнера:

dockerfileFROM nginx:alpine

# Копируем HTML файл
COPY index.html /usr/share/nginx/html/index.html

# Устанавливаем curl для healthcheck
RUN apk add --no-cache curl

# Настраиваем healthcheck
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost/ | grep -q "Hello" || exit 1

EXPOSE 80

Для создания образа я выполню команду docker build -t nginx-health:1.1 .. Заметьте, что тут есть CMD, не путайте это с простым CMD, который выполняет собственно команду внутри контейнера при старте. CMD в файле Dockerfile работает в связке с HEALTHCHECK, т.е. HEALTHCHECK ... CMD ....

Параметры HEALTHCHECK:

--interval=30s - проверка каждые 30 секунд
--timeout=3s - таймаут ответа 3 секунды
--start-period=5s - задержка перед первой проверкой
--retries=3 - количество неудачных попыток до пометки как unhealthy

Сама команда CMD для HEALTHCHECK: 1. curl -f http://localhost/

curl - утилита для HTTP запросов
-f (–fail) - если сервер вернёт ошибку (404, 500 и т.д.), curl завершится с ненулевым кодом
http://localhost/ - адрес для проверки

2. | (pipe)

Передаёт вывод curl в следующую команду (grep)

3. grep -q "Hello"

grep - поиск текста
-q (–quiet) - тихий режим, ничего не выводит, только возвращает код результата
"Hello" - искомый текст
Если найдено → код возврата 0 (успех)
Если НЕ найдено → код возврата 1 (ошибка)

4. || (логическое ИЛИ)

Выполняет команду справа, ТОЛЬКО если команда слева провалилась (код ≠ 0)

5. exit 1

Завершает скрипт с кодом ошибки 1
Для Docker это означает unhealthy

После сборки образа запускаю контейнер и проверяю его статус:

docker run -d -p 8080:80 --name nginx-healthcheck nginx-health:1.1
docker ps
```json
c1a33dd3ee25   nginx-health:1.1  Up 7 seconds (healthy) nginx-healthcheck

curl  http://localhost:8080

   <h1>Hello</h1>

Теперь я изменю файл index.html чтобы валидация HEALTHCHECK завершилась с кодом 1.

vim html/index.html

    <h1>Hell</h1>

docker build -t nginx-health:1.2 .
docker rm -f nginx-healthcheck
docker run -d -p 8080:80 --name nginx-healthcheck nginx-health:1.2
docker ps

c1a33dd3ee25   nginx-health:1.1  Up 7 seconds (unhealthy) nginx-healthcheck

Пример с docker compose

Тут делается тоже самое, поэтому не буду прописывать всё один в один просто приведу пример файла docker-compose.yml.

docker rm -f nginx-healthcheck
docker compose up -d 
docker compose ps

nginx-healthcheck   nginx:alpine   Up 3 minutes (unhealthy)   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp

docker compose down

Пример с docker stack

docker-stack-healthcheck.svg

Для примера буду использовать всё тот же подход с образом nginx и ответом Hello. Но то как ведут себя контейнеры при использовании Healthcheck в docker stack отличается. Как я уже говорил в docker stack самым главным является добиться необходимого статуса REPLICAS, и если статус контейнера не healthy то и контейнер не стартанёт. Особенно полезно использовать этот механизм при обновлении сервисов docker stack.

Для примера представим себе ситуацию:

Я выкладываю сервис, который работает (отдаёт пользователю Hello)
Я вношу правки в сервис и делаю ошибку (меняю на Hell)
Перевыкладываю сервис (снова docker stack deploy)
Проверяю что же произошло (спойлер обновления не будет)

docker stack deploy -c docker-stack.yml nginx-stack
docker stack services nginx-stack

ID             NAME              MODE         REPLICAS   IMAGE          PORTS
jo8itz0b9lou   nginx-stack_web   replicated   2/2        nginx:alpine   *:8080->80/tc

docker stack ps nginx-stack

ID             NAME                IMAGE          NODE             DESIRED STATE   CURRENT STATE           ERROR     PORTS
djvpuz2ls9f3   nginx-stack_web.1   nginx:alpine   c-stream-9-vm4   Running         Running 2 minutes ago
ltcr3vfwz5jm   nginx-stack_web.2   nginx:alpine   c-stream-9-vm9   Running         Running 2 minutes ago

Да и тут есть одно, но, сейчас, когда контейнеры работают статус task самого сервиса Running, т.е. статус Healthy или Unhealthy выставляется только контейнерам (docker container ls). Это особенность Swarm - healthcheck статус скрыт в выводе задач, но активно используется внутри для управления репликами и load balancing.

Теперь я поменяю значение Hello на Hell в файле index.html и сделаю деплой используя файл docker-stack-unhealthy.yml, потому что удалять конфиг docker нельзя если его кто-то использует.

vim html/index.html
docker stack deploy -c docker-stack-unhealthy.yml nginx-stack
docker stack ps nginx-stack

ID             NAME                    IMAGE          NODE             DESIRED STATE   CURRENT STATE             
860d4wee98by   nginx-stack_web.1       nginx:alpine   c-stream-9-vm4   Shutdown        Complete 15 hours ago
djvpuz2ls9f3    \_ nginx-stack_web.1   nginx:alpine   c-stream-9-vm4   Shutdown        Shutdown 15 hours ago
ltcr3vfwz5jm   nginx-stack_web.2       nginx:alpine   c-stream-9-vm9   Running         Running 15 hours ago

docker stack services nginx-stack

jo8itz0b9lou   nginx-stack_web   replicated   1/2        nginx:alpine   *:8080->80/tcp

Как видно из вывода выше обновить Docker попытался только один task и его контейнер. Но так как статус контейнера этого task не Healthy он бросил это дело и оставил один task без изменений, т.е. со старой версией. И это хорошо ведь в итоге сервис всё же работает и отдаёт нормальную страницу с текстом Hello. Но можно сделать еще лучше, используя failure_action: rollback в update_config (файл docker-stack-rollback.yml).

Но сейчас есть одна проблема: у меня теперь живой только один task и мне перед обновлением с rollback нужно оживить второй иначе я просто добьюсь того что оба task будут выключены. Поэтому сперва оживляю существующее:

docker stack deploy -c docker-stack.yml nginx-stack
docker stack ps nginx-stack

55mpr1kzdwm4   nginx-stack_web.1       nginx:alpine   c-stream-9-vm4   Running         Starting 5 seconds ago
wzhycp0w3878    \_ nginx-stack_web.1   nginx:alpine   c-stream-9-vm4   Shutdown        Shutdown 5 seconds ago
0vmpokkln8xi   nginx-stack_web.2       nginx:alpine   c-stream-9-vm9   Running         Running 20 seconds ago
bss08mcndzwa    \_ nginx-stack_web.2   nginx:alpine   c-stream-9-vm9   Shutdown        Complete 40 seconds ago
vn08vas0y1ic    \_ nginx-stack_web.2   nginx:alpine   c-stream-9-vm9   Shutdown        Complete about a minute ago
n0c84gcrvzbi    \_ nginx-stack_web.2   nginx:alpine   c-stream-9-vm9   Shutdown        Complete 3 minutes ago
1io00g1zp6ms    \_ nginx-stack_web.2   nginx:alpine   c-stream-9-vm9   Shutdown        Shutdown 3 minutes ago

Теперь, когда у меня два task работают я могу использовать файл с rollback.

vim html/index.html
docker stack deploy -c docker-stack-rollback.yml --detach=false nginx-stack

Updating service nginx-stack_web (id: 3h9a3wj2p1iigwud3ahb62wbr)
overall progress: rolling back update: 2 out of 2 tasks
1/2: running   [==================================================>]
2/2: running   [==================================================>]
verify: Service 3h9a3wj2p1iigwud3ahb62wbr converged
rollback: rollback completed

Различия

docker-healthcheck-comparison.svg

Я рассмотрел три варианта использования Healthcheck, теперь давайте рассмотрим ключевые отличия.

Функция	docker run	docker-compose	docker stack
Автоматический restart при unhealthy	❌ Нет	❌ Нет	✅ Да
Load balancing исключает unhealthy	❌ Нет LB	❌ Нет LB	✅ Да
Rolling updates учитывают health	❌ Нет	❌ Нет	✅ Да
Видимость статуса (healthy/unhealthy)	`docker ps`	`docker-compose ps`	`docker ps` на нодах
Production-ready	❌ Нет	❌ Нет	✅ Да

Docker - Немного теории про сети

Sun, 17 Aug 2025 06:20:39 +0600

Когда вы устанавливаете Docker по умолчанию создаётся виртуальный сетевой мост docker0. Этот виртуальный сетевой мост объединяет все контейнеры, работающие в режиме bridge (по умолчанию), в одну внутреннюю сеть, и подключает их к хосту через этот мост.

Т.е. по умолчанию все запущенные контейнеры имеют доступ к остальным контейнерам по виртуальной сети, если даже контейнер создавался без флага -p. Отсюда возникает вопрос что преимущества контейнеризации в изоляции а тут общая сеть. Всё так, но только если делать всё по умолчанию. Если же нужно изолировать контейнеры в виртуальной сети, то необходимо просто создать отдельную виртуальную сеть для этих контейнеров. Лучшей практикой считается создавать отдельную виртуальную сеть для каждого приложения.

Конечно тех, кто следует такой практике очень мало и в целом использование сети bridge по умолчанию не приносит никаких видимых проблем а наоборот только упрощает работу. Но при использовании Docker в K8s об этом обязательно нужно знать.

Для начала я создам контейнер с nginx (если не понятно что происходит).

docker container run -d --name some-nginx -p 80:80 nginx:latest

ip-адрес контейнера

Если у каждого контейнера по умолчанию активна виртуальная сеть стало быть должен быть и ip-адрес отличающийся от ip-адреса самого устройства на котором установлен Docker? Да, всё верно и чтобы получить этот виртуальный ip-адрес используется docker container inspect, подробнее тут.

docker inspect -f '{{ .NetworkSettings.IPAddress }}' some-nginx

172.17.0.3

И да по умолчанию само устройство на котором установлен Docker может обращаться к этому ip-адресу контейнера.

telnet 172.17.0.3 80

Обмен трафиком

Теперь когда я знаю что у меня ip-адрес контейнера 172.17.0.3 а локальный ip-адрес устройства на котором установлен Docker 172.31.144.9 встаёт вопрос почему разные подсети и как вообще если подсети разные локальное устройство имеет доступ к контейнеру по сети. По умолчанию при создании виртуальный сетевой мост docker0 получает IP-адрес из подсети 172.17.0.0/16. И DHCP-сервер Docker автоматически выделяет IP контейнерам из этого диапазона.

Самому же виртуальному сетевому мосту docker0 присваивается IP-адрес 172.17.0.1/16. Все сетевые обращения между контейнерами и локальным хостом происходит через этот docker0.

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

Создаёт виртуальную пару интерфейсов veth-pair (eth0, vethXXXX). Оба этих интерфейса принадлежат контейнеру.
Конец на хосте (vethXXXX) подключается к мосту docker0
Контейнер получает IP-адрес (172.17.0.3) eth0
Теперь контейнер может общаться с другими контейнерами в той же сети docker0 и с самим хостом (172.17.0.1)

Когда вы пытаетесь подключиться к контейнеру с локального сервера используется docker0 и в качестве исходящего ip-адреса будет использоваться 172.17.0.1 вместо 172.31.144.9.

docker container logs -f some-nginx

curl http://172.17.0.3

172.17.0.1 - - [23/Oct/2025:12:01:07 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.76.1" "-"
172.17.0.1 - - [23/Oct/2025:12:01:24 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/7.76.1" "-"

При обращении контейнера к другому контейнеру трафик идёт напрямую через docker0.

docker start -ai some-alpine
ip a

172.17.0.2/16

curl http://172.17.0.3

172.17.0.2 - - [23/Oct/2025:12:33:55 +0000] "GET / HTTP/1.1" 200 615 "-" "curl/8.14.1" "-"

При обращении же контейнера к внешней сети и наоборот Docker настраивает NAT-правила через iptables , чтобы пакеты маршрутизировались наружу через хостовый интерфейс (обычно eth0). Т.е. для того чтобы обратится к контейнеру с другого сервера в сети (172.31.144.10) к контейнеру с nginx (172.17.0.3) нужно обращаться на 172.31.144.9.

docker-bridge-network.svg

docker container port

Команда docker container port показывает какие порты контейнера проброшены на хост — то есть какие порты доступны снаружи.

docker container port some-nginx

80/tcp -> 0.0.0.0:80
80/tcp -> [::]:80

Расшифровка того что вывела команда сверху:

80/tcp — внутренний порт внутри контейнера (Nginx).
0.0.0.0:80 — порт хоста, к которому можно обращаться извне (например, в браузере http://localhost)
Нижний вариант это то же самое только по ipv6

Не использовать виртуальную сеть (–net=host)

Но есть возможность не использовать вообще виртуальную сеть, а вместо этого использовать сеть хоста, т.е. использовать ip-адрес хоста (172.31.144.9). Но такой режим работает только на Linux.

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

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

docker-host-network.svg

sudo iptables -t nat -L -n -v --line-numbers

Docker - Пробираемся внутрь контейнера

Mon, 16 Jun 2025 06:20:39 +0600

Каждый уважающий себя админ Linux рано или поздно задумывается о том, как получить shell в контейнере ну или как запустить там команду.

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

docker container ls

CONTAINER ID   IMAGE            COMMAND                  CREATED          STATUS          PORTS      NAMES
bdc2d2440db9   nginx:latest     "/docker-entrypoint.…"   5 minutes ago    Up 5 minutes    80/tcp     some-nginx
ca55f6abaa03   mariadb:latest   "docker-entrypoint.s…"   23 minutes ago   Up 23 minutes   3306/tcp   some-mariadb

docker container run -it (docker run)

Если вы ещё не знаете за что отвечает команда docker container run, то рекомендую к прочтению эту статью.

Команда docker container run -it — это один из самых часто используемых способов запуска контейнера в интерактивном режиме (то есть “с живым терминалом”). Флаги -it расшифровываются как:

-i - Оставляет стандартный ввод (stdin) открытым, чтобы можно было вводить команды (interactive)
-t - Создаёт псевдотерминал (teletype terminal)

Т.е. если я сейчас запущу команду docker run -it --name some-nginx-2 nginx:latest bash то команду выполняемая при старте контейнера по умолчанию сменится на команду bash.

docker run -it --name some-nginx-2 nginx:latest bash
root@57e565dc144f:/# ls

bin   dev                  docker-entrypoint.sh  home  lib64  mnt  proc  run   srv  tmp

Теперь сравним команды, которые выполнились при старте обычно созданного контейнера some-nginx и some-nginx-2.

docker inspect -f '{{ .Path }} {{ .Args }}' some-nginx
docker inspect -f '{{ .Path }} {{ .Args }}' some-nginx-2

/docker-entrypoint.sh [nginx -g daemon off;]
/docker-entrypoint.sh [bash]

Понятное дело, что во втором случаем сам nginx не запустился, а вместо него запустился bash. На это стоит обратить внимание. И так как контейнер работает только пока сама выполняемая команда внутри запущена после выхода из контейнера с bash происходит выход из bash и сам контейнер останавливается.

docker run -it --name some-ubuntu ubuntu:latest bash

root@faf026693bf7:/#
exit

docker ps -a

faf026693bf7   ubuntu:latest    "bash"                   27 seconds ago   Exited (0) 11 seconds ago                some-ubuntu

Поэтому если вам нужно просто запустить временный контейнер лучше воспользоваться командой docker run --rm -it --name some-ubuntu ubuntu:latest bash

ubuntu:latest - в качестве образа для контейнера используем ubuntu
--rm - удаляет автоматически контейнер после выхода из него

### docker container start -ai

Для того чтобы запустить остановленный контейнер с командой bash и сразу попасть в псевдотерминал контейнера можно использовать команду docker container start -ai some-ubuntu.

Даже если контейнер уже запущен также можно использовать эту команду, но лучше будет использовать команду ниже. Дело в том, что тут запускается команда по умолчанию, т.е. если выполнить docker container start -ai some-nginx то вы прост попадёте в консоль с запущенным nginx и при выходе из сессии просто выключите контейнер.

docker container start some-nginx -ai
CTRL+C

2025/10/22 05:33:28 [notice] 1#1: worker process 28 exited with code 0
2025/10/22 05:33:28 [notice] 1#1: exit

### docker container exec

Если контейнер у вас уже запущен и команда там по умолчанию не bash, то используем команду docker container exec -it. Для примера я выполню эту команду для контейнера с nginx и получу доступ к отдельному псевдотерминалу, который никак не повлияет на работу самого nginx внутри контейнера.

docker container exec -it some-nginx bash
root@bdc2d2440db9:/# ls /etc/nginx/conf.d/

default.conf

Если же необходимо просто выполнить команду внутри контейнера, при этом не входя, а него можно выполнить docker exec some-nginx cat /etc/nginx/nginx.conf, т.е. вместо флагов -it прописываем саму команду.

docker exec some-nginx cat /etc/nginx/nginx.conf

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

unable to start container process: exec: “bash”

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

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

docker run -it --name some-alpine alpine:latest sh
/ # curl

sh: curl: not found

/ # apk add curl
/ # curl

curl: try 'curl --help' or 'curl --manual' for more information

Но если вы столкнулись с unable to start container process: exec: "bash" то просто попробуйте сменить bash на sh.

docker run -it --name some-alpine alpine:latest bash

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown.

docker run -it --name some-alpine alpine:latest sh

/ #

Docker - Как работает dns

Fri, 16 May 2025 06:20:39 +0600

Если вдруг вы не знаете что такое DNS, то в двух словах это сервис, благодаря которому происходит преобразование доменных имён в IP-адреса и обратно. Т.е. вместо того чтобы обращаться к серверу по IP-адресу 172.19.0.3, можно обратиться по имени some-nginx. Человеческий мозг так устроен, что проще запоминать имена серверов, чем IP-адреса.

Например, я зайду в контейнер и попытаюсь пропинговать другой контейнер по ip-адресу 172.19.0.3 и по имени контейнера some-nginx.

docker container exec -it my-network1-nginx1 ping 172.19.0.3

PING 172.19.0.3 (172.19.0.3): 56 data bytes
64 bytes from 172.19.0.3: seq=0 ttl=64 time=0.089 ms
64 bytes from 172.19.0.3: seq=1 ttl=64 time=0.109 ms

docker container exec -it my-network1-nginx1 ping some-nginx

PING 172.19.0.3 (172.19.0.3): 56 data bytes
64 bytes from 172.19.0.3: seq=0 ttl=64 time=0.089 ms
64 bytes from 172.19.0.3: seq=1 ttl=64 time=0.109 ms

Т.е. благодаря Docker DNS контейнеры могут обращаться друг к другу по именам контейнеров.

DNS псевдоним (alias)

Если вдруг есть необходимость обращения к контейнеру помимо основного имени по какому-то другому, можно воспользоваться псевдонимами. Т.е. если имя контейнера some-nginx и я добавляю псевдоним mynginx, то обращаться к контейнеру можно по обоим именам.

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

Отключаем контейнер от сети
```
docker network disconnect my-network1 some-nginx
```
Подключаем контейнер к сети и задаём псевдоним
```
docker network connect --alias mynginx my-network1 some-nginx
```

Проверяем что псевдоним есть

docker container inspect -f '' some-nginx

{"my-network1":{"IPAMConfig":{},"Links":null,"Aliases":["mynginx","15efdb23bd4c"],"DNSNames":["some-nginx","mynginx","15efdb23bd4c"]}}

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

docker run -d --name web --network my-net -network-alias my-nginx-alias nginx:latest

И да важное замечание в сети, которая создаётся (docker0) по умолчанию DNS не работает.

DNS round robin

С версии 1.11 Docker engine позволяет назначать нескольким контейнерам одни и те же dns имена (псевдонимы). Использовать это можно для балансировки нагрузки. Т.е. при обращении, например, а страницу http://some-nginx трафик поочерёдно будет уходить то но один контейнер то на другой, стало быть оба контейнера обслуживают запросы клиента.

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

Создаём отдельную сеть
```
docker network create rr-net
```

Создаём 2 контейнера с образа nginxdemos/hello с псевдонимом web

docker run -d --name web1 --network rr-net --network-alias web nginxdemos/hello
docker run -d --name web2 --network rr-net --network-alias web nginxdemos/hello

Стартуем контейнер с alpine и проверяем работу DNS

docker run -it --rm --network rr-net alpine sh
/ # nslookup web

Non-authoritative answer:
Name:   web
Address: 172.20.0.2
Name:   web
Address: 172.20.0.3

/ # apk add curl
/ # for i in $(seq 1 6); do curl -s web | grep "Server"; done

<p><span>Server&nbsp;address:</span> <span>172.20.0.2:80</span></p>
<p><span>Server&nbsp;name:</span> <span>ffc51538bca6</span></p>
<p><span>Server&nbsp;address:</span> <span>172.20.0.2:80</span></p>
<p><span>Server&nbsp;name:</span> <span>ffc51538bca6</span></p>
<p><span>Server&nbsp;address:</span> <span>172.20.0.2:80</span></p>
<p><span>Server&nbsp;name:</span> <span>ffc51538bca6</span></p>
<p><span>Server&nbsp;address:</span> <span>172.20.0.3:80</span></p>
<p><span>Server&nbsp;name:</span> <span>727674b9865f</span></p>
<p><span>Server&nbsp;address:</span> <span>172.20.0.3:80</span></p>
<p><span>Server&nbsp;name:</span> <span>727674b9865f</span></p>
<p><span>Server&nbsp;address:</span> <span>172.20.0.3:80</span></p>
<p><span>Server&nbsp;name:</span> <span>727674b9865f</span></p>

Зачем DNS

Во-первых, как я уже говорил, имена серверов проще запоминать, чем IP-адреса. Но если в вашем случае это не так, то тогда еще один повод, к которому претензий не будет ни у кого: IP-адреса контейнеров могут меняться, и в таком случае, обращаясь по DNS имени, вам не нужно узнавать новый IP-адрес контейнера.

Бонсуом скрипт, который выведет все псевдонимы для всех контейнеров.

docker ps -q | xargs docker inspect \
  | jq -r '
    .[] |
    .Name as $n |
    .NetworkSettings.Networks? |
    if type=="object" then
      to_entries[] |
      "\($n) → \(.key): \(.value.IPAddress) | Aliases: \((.value.Aliases // []) | join(", "))"
    else
      "\($n) → no networks"
    end
  ' \
  | sed -E \
    -e "s/(→)/\x1b[36m\1\x1b[0m/" \
    -e "s/([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/\x1b[32m\1\x1b[0m/g" \
    -e "s/(Aliases: )/\x1b[33m\1\x1b[0m/"

/my-network1-nginx1 → my-network1: 172.19.0.2 | Aliases: 05186ff32ca1
/some-nginx → my-network1: 172.19.0.3 | Aliases: mynginx, 15efdb23bd4c
/some-nginx-2 → bridge: 172.17.0.2 | Aliases:

Docker - Администрирование сетей

Fri, 16 May 2025 06:20:39 +0600

В этой статье я описал теорию которую необходимо знать для дальнейшей работы с сетью в Docker.

Для начала я создам контейнер с nginx (если не понятно что происходит).

docker container run -d --name some-nginx -p 80:80 nginx:latest

Теперь выведу ip-адрес контейнера и ip-адрес хоста где установлен Docker.

docker inspect -f '{{ .NetworkSettings.IPAddress }}' some-nginx

172.17.0.3

ip a

172.31.144.9

Вывести список всех сетей docker в Docker (docker network ls)

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

Для того, чтобы проверить какие вообще виртуальные сети есть в системе используется команда docker network ls, которая выведет список всех виртуальных сетей.

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
6d18af512d4d   bridge    bridge    local
8dd3c0368276   host      host      local
e4ee21b03ff4   hyper     bridge    local
581357de291b   none      null      local

Просмотр информации о сети в Docker (docker network inspect)

Отлично команда выше выдала список всех сетей, но как понять какой контейнер использует ту или иную сеть. Для этого используется команда docker network inspect, где в поле Containers перечисляются контейнеры, которые используют эту сеть.

docker network inspect 6d18af512d4d

			"Containers": {
            "15efdb23bd4ca96be08cd6e4845a941508b231392bc2f3d0ebc57f0facd1e8f0": {
                "Name": "some-nginx",
                "EndpointID": "07b21011ab8e497beabf228c3208c8a77f684ee4725d8ee734fdb9a92806c53a",
                "MacAddress": "02:42:ac:11:00:03",
                "IPv4Address": "172.17.0.3/16",
                "IPv6Address": ""
            }
        }

Как создать сеть в Docker (docker network create)

И вот пришло время создать свою собственную виртуальную сеть в Docker используя команду docker network create.

docker network create my-network1
docker network ls

3dd65f38f672   my-network1   bridge    local

При создании сети я не указывал никаких настроек кроме как название этой сети. Подсеть для этой новой сети Docker задал сам автоматически. Т.е. контейнеры использующие эту сеть (my-network1) будут иметь ip-адреса вида 172.19.0.2.

docker network inspect my-network1

				"IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.19.0.0/16",
                    "Gateway": "172.19.0.1"
                }
            ]
        }

Если же необходимо задать какие-то конкретные значения при создании сети можно использовать следующие опции:

--driver - Тип сети (bridge, overlay, macvlan, host, none)
--subnet - Указать подсеть вручную (--subnet 172.28.0.0/16)
--gateway - Указать шлюз вручную (--gateway 172.28.0.1)
--ip-range - Задать диапазон IP для контейнеров (--ip-range 172.28.5.0/24)

Если вдруг необходимо запретить контейнерам выход в интернет, то необходимо задать опцию --internal при создании новой сети.

Назначить сеть контейнеру

Для того чтобы назначить только что создаю сеть новому контейнеру при выполнении команды создания docker container run необходимо указать сеть при помощи параметра --network.

docker container run -d --name my-network1-nginx1 --network my-network1 nginx:alpine

Для того чтобы подключить уже запущенный контейнер к другой сети используется docker network connect.

docker network connect my-network1 some-nginx
docker network inspect my-network1

					"Containers": {
            "05186ff32ca1fa4f9dd01eede5293f0e7aa8676700155ffc05b7cf3b577bda54": {
                "Name": "my-network1-nginx1",
                "EndpointID": "4eec0b82203370114a7e3d6724f9cedf5e3629996849459b5e8e0801d331df59",
                "MacAddress": "02:42:ac:13:00:02",
                "IPv4Address": "172.19.0.2/16",
                "IPv6Address": ""
            },
            "15efdb23bd4ca96be08cd6e4845a941508b231392bc2f3d0ebc57f0facd1e8f0": {
                "Name": "some-nginx",
                "EndpointID": "08702a00bff2d1b6381720216cd365434e97160e002677dbd91b9f6b579309d9",
                "MacAddress": "02:42:ac:13:00:03",
                "IPv4Address": "172.19.0.3/16",
                "IPv6Address": ""
            }
        },

Теперь, когда в сети my-network1 два контейнера они должны обращаться друг к другу по сети без проблем, но не иметь возможность обратиться к контейнерам из в другой сети.

docker exec -it my-network1-nginx1 sh
ping some-nginx

PING some-nginx (172.19.0.3): 56 data bytes
64 bytes from 172.19.0.3: seq=0 ttl=64 time=0.105 ms
64 bytes from 172.19.0.3: seq=1 ttl=64 time=0.110 ms
64 bytes from 172.19.0.3: seq=2 ttl=64 time=0.131 ms

ping 172.17.0.2

PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: seq=0 ttl=63 time=0.112 ms
64 bytes from 172.17.0.2: seq=1 ttl=63 time=0.101 ms
64 bytes from 172.17.0.2: seq=2 ttl=63 time=0.125 ms

Почему контейнеры из разных сетей видят друг друга

Но как видно из вывода контейнер some-nginx-2, который в сети bridge тоже пингуется. Произошло это потому что я использую ОС CentOS, в которой по умолчанию включен firewalld, который перехватывает управление. А точнее две сети Docker находятся в одной зоне (docker) в firewalld. Поэтому трафик между всеми сетями в одной зоне разрешён. Даже если Docker добавил правила, изолирующие обе сети в iptables приоритет выше у firewalld, который пропускает весь трафик.

Самым простым решением конечно будет просто отключить firewalld в самой системе (не рекомендуется в проде).

sudo systemctl stop firewalld
sudo systemctl disable --now firewalld

И другой вариант если вы хотите сохранить работающий firewalld это исключить Docker-интерфейсы из управления firewall.

Получаем активные зоны

sudo firewall-cmd --get-active-zones

docker
  interfaces: docker0 br-e4ee21b03ff4 br-3dd65f38f672

Удалить все Docker-интерфейсы

sudo firewall-cmd --permanent --remove-interface=docker0
sudo firewall-cmd --permanent --remove-interface=br-e4ee21b03ff4
sudo firewall-cmd --permanent --remove-interface=br-3dd65f38f672

Перечитываем правила
```
sudo firewall-cmd --reload
```
Перезапускаем Docker
```
sudo systemctl restart docker
```

Отключить сеть контейнера

Если нужно отключить сеть у контейнера выполняем команду docker network disconnect.

docker network disconnect bridge some-nginx

TrueNAS - There are 2 disks available that have non-unique serial numbers

Thu, 24 Apr 2025 06:20:39 +0600

Решил попробовать TrueNAS, так как физического сервера не было создал на виртуализации ESXI. При создании pool получил предупреждение There are 2 disks available that have non-unique serial numbers.

Причина

Причина собственно в том, что ESXI не выдаёт уникальные серийные номера при добавлении дисков.

Решение

Выключем вм и на датасторе в ESXI находим директорию с нашей виртуальной машиной, откуда скачиваем файл .vmx. Добавляем туда следующее:

disk.enableUUID = "TRUE"
scsi0:1.serialNumber = "unique-disk-id-1"
scsi0:2.serialNumber = "unique-disk-id-2"

После заменяем файл на датасторе.

Внимание scsi0:1 и scsi0:2 должны совпадать с Virtual Device Node в свойствах виртуальной машины.

Jetty - KeyStores with multiple certificates are not supported

Thu, 17 Apr 2025 06:20:39 +0600

При замене сертификата в хранилище ключей для Geoserver получил следующую ошибку: ERROR [jetty-main-1] *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer - Failed to start java.lang.IllegalStateException: KeyStores with multiple certificates are not supported on the base class org.eclipse.jetty.util.ssl.SslContextFactory.

Решение

В моём случае всё просто я решил при создании сертификата добавить несколько DNS имён для сертификата, что собственно и не понравилось Jetty.

Решением будет просто перевыпустить сертификат с одним DNS именем.

Docker - Слои образа и кэш слоёв

Wed, 16 Apr 2025 06:20:39 +0600

Как уже известно каждый Docker образ состоит из слоёв. Чем больше команд (инструкций) в Dockerfile тем больше слоёв, но не все команды создают слои.

Для примера возьмём Dockerfile который использует ubuntu и ставит nginx, при этом копируя файлы внутрь образа.

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y nginx
COPY index.html /usr/share/nginx/html/
CMD ["nginx", "-g", "daemon off;"]

Если не понимаете что происходит:

№	Инструкция	Что делает	Создаёт слой?
1	FROM ubuntu:22.04	скачивает базовый слой (родительский образ)	да
2	RUN apt-get install -y nginx	установка nginx	да
3	COPY	копирование файла	да
4	CMD	команда запуска	нет (метаданные)

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

docker build . -t mybuild:1.0

=> [1/3] FROM docker.io/library/ubuntu:22.04@sha256:09506232a8004baa32c47d68f1e5c307d648fdd59f5e7eaa42aaf87914100db3
=> [2/3] RUN apt-get update && apt-get install -y nginx
=> [3/3] COPY index.html /usr/share/nginx/html/
 => => writing image sha256:17a8b92dd8073184d570a69167c3862f633c69c90e49fbb5d745c56e870fd6f7

Каждая инструкция (RUN, COPY, ADD, и т.д.) в Dockerfile создаёт слой.

Как хранятся слои в Docker

Каждый слой представляет из себя директорию со сжатыми данными в ОС, где стоит Docker. Путь к этой директории /var/lib/docker/overlay2/.

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

Вывести слои образа

docker inspect --format='' mybuild:1.0 | jq

["sha256:767e56ba346ae714b6e6b816baa839051145ed78cfa0e4524a86cc287b0c4b00",
  "sha256:b3e9f88953eff8bf59b0042d340cbc16daf139665697ebf2ee741edd3c8b3b18",
  "sha256:a04b6207eb080660102f534250f1e473474068e2f41baa0f2624279036ee75b5"]

Выполняем поиск по хэшу слоя

udo grep -rnw /var/lib/docker/image/overlay2/layerdb/sha256/ -e b3e9f88953eff8bf59b0042d340cbc16daf139665697ebf2ee741edd3c8b3b18

/var/lib/docker/image/overlay2/layerdb/sha256/3cf6bc112ebdd32ca7b08b5c40a279e54ec48ae101ccae6e78493293e5862640/diff:

Скорее всего необходимости лезть вручную в эти директории и не будет, но знать где лежат слои физически лишним не будет.

Как работает кэш в Docker

При сборке Docker образа (docker build) Docker сравнивает каждую инструкцию с ранее построенными образами, точнее с их слоями. Если слой не изменился, то используется кэш, т.е. уже существующий слой. Так как у каждого слоя есть хэш, Docker при сборке вычисляет хэш всех изменений инструкции (SHA256) и сравнивает с существующими слоями. Т.е. если другой образ использует тот же слой (т.е. ту же комбинацию базового слоя + команды + контента) **, Docker **возьмёт этот слой из кэша.

Docker считает, что два слоя эквивалентны, если совпадают:

хэш предыдущего слоя (родителя);
команда (RUN, COPY, ADD и её аргументы);
содержимое добавляемых файлов (если есть).

Если всё это совпадает — Docker просто переиспользует существующий слой из другого образа. Т.е. благодаря кэшированию происходит оптимизация использования дискового пространства. Также при наличии кэша нет необходимости скачивать одни и и те же слои с Docker hub или создавать их заново что ускоряет процесс сборки образа.

Для примера я создам два Dockerfile с парочкой одинаковых инструкций и соберу два разных образа.

📜 Dockerfile.1

FROM python:3.11-slim
RUN pip install flask==3.0.0

📜 Dockerfile.2

FROM python:3.11-slim
RUN pip install flask==3.0.0     # <-- точно та же команда
COPY app/ /app/
CMD ["python", "/app/main.py"]

Выполню сборку первого образа с именем cache1:1.0.

docker build --progress=plain -f Dockerfile.1 -t cache1:1.0 .

[1/2] FROM docker.io/library/python:3.11-slim@sha256:8eb5fc663972b871c528fef04be4eaa9ab8ab4539a5316c4b8c133771214a61 DONE 6.3s
[2/2] RUN pip install flask==3.0.0 DONE 5.3s

Выполню сборку второго образа с именем cache2:1.0.

docker build --progress=plain -f Dockerfile.2 -t cache2:1.0 .

[1/3] FROM docker.io/library/python:3.11-slim@sha256:8eb5fc663972b871c528fef04be4eaa9ab8ab4539a5316c4b8c133771214a617 DONE 0.0s
[2/3] RUN pip install flask==3.0.0 CACHED
[3/3] COPY app/ /app/ DONE 0.0s

Из команды выше уже видно, что для сборки использовались 2 слоя из кэша, хотя в первом слое об этом и не написано. Также выполню docker inspect чтобы сравнить слои образа cache2 с cache1.

docker inspect --format='' cache1:1.0 | jq

  "sha256:d7c97cb6f1fe7cae982649e9f55efe201212e8acaa64bd668c083b204e4efd4c",
  "sha256:15eb6aec49b38357916ea069cb57c890841f4e40588c54ebba117f6314911d37",
  "sha256:9ba402f61141e835fb247b8592f61ea2a885de652bbb368fe9cea93cbc8c324a",
  "sha256:235e8192987624c55713750efe67254a8dbfe540c7a59c1d33353f928e42d80d",
  "sha256:556dcdfbcdbc51dab4c5310208f5b09b7a03e7d9a627cd0defc8d2f5052e78d8"

docker inspect --format='' cache2:1.0 | jq

  "sha256:d7c97cb6f1fe7cae982649e9f55efe201212e8acaa64bd668c083b204e4efd4c",
  "sha256:15eb6aec49b38357916ea069cb57c890841f4e40588c54ebba117f6314911d37",
  "sha256:9ba402f61141e835fb247b8592f61ea2a885de652bbb368fe9cea93cbc8c324a",
  "sha256:235e8192987624c55713750efe67254a8dbfe540c7a59c1d33353f928e42d80d",
  "sha256:556dcdfbcdbc51dab4c5310208f5b09b7a03e7d9a627cd0defc8d2f5052e78d8",
  "sha256:0b636ec1d5fad65a1c6d8512c0ce7535824bab1c7700fb0b1c9b473ae54ea594"

Из вывода выше можно отметить что:

При сборке cache1:1.0 все 5 слоёв были созданы с нуля.
При сборке cache2:1.0 Docker проверил каждый шаг сверху вниз:

Слой (sha256)	Новый слой?	Комментарий
d7c97cb6	нет (беру из кэша)	базовый образ `python:3.11-slim`
15eb6aec	нет (беру из кэша)	слой из Python базового образа
9ba402f6	нет (беру из кэша)	слой из Python базового образа
235e8192	нет (беру из кэша)	слой из Python базового образа
556dcdfb	нет (беру из кэша)	слой `RUN pip install flask==3.0.0`
0b636ec1	да (создаю новый)	слой `COPY app/ /app/`

Порядок слоёв и кэш

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

📜 Dockerfile.2

FROM python:3.11-slim
RUN pip install php
RUN pip install flask==3.0.0
COPY app/ /app/
CMD ["python", "/app/main.py"]

Теперь если я соберу снова образ, то из кэша будет использован только один слой (FROM python:3.11-slim).

ocker build -f Dockerfile.2 -t cache2:1.0 .

 => CACHED [1/4] FROM docker.io/library/python:3.11-slim@sha256:8eb  0.0s                                        0.0s
 => [2/4] RUN pip install php                                        3.4s
 => [3/4] RUN pip install flask==3.0.0                               4.3s
 => [4/4] COPY app/ /app/                                            0.2s

Поэтому рекомендуется при написании Dockerfile инструкции, которые могут меняться прописывать максимально низко в файле.

Как собрать образ Docker без использования кэша

Если вдруг необходимо провести сборку образа без использования кэша нужно использовать флаг --no-cache.

docker build --no-cache -f Dockerfile.2 -t cache2:1.0 .

Когда бывает необходимо не использовать кэш:

Когда необходимо обновить пакеты, т.е. получить актуальные версии из репозиториев
Если базовый образ был обновлён и необходимо получить свежий базовый образ
Когда сборка всегда строиться с нуля, независимо от предыдущего состояния (CI/CD)

Но если необходимо просто получить свежий базовый образ лучше использовать флаг --pull.

Слой контейнера

При создании контейнера поверх слоёв с образом создаётся новый слой в статусе read/write, т.е. слой перезаписываемый, в отличии от слоёв образа, которые в статусе read-only.

Т.е. если я создам контейнер, то произойдёт примерно следующее:

image layer 1  (базовый слой)
image layer 2
image layer 3
------------------------------
container layer (read-write)

Этот верхний слой контейнера хранится отдельно в директории /var/lib/docker/overlay2/. Все манипуляции внутри контейнера сохраняются в слое самого контейнера, а не в слоях образа.

docker inspect some-alpnginx | jq '.[0].GraphDriver.Data'

  "LowerDir": "/var/lib/docker/overlay2/b76e86ac1387c177bb70ef2f1c0cdc58b86c228af2b890f474e76d13daf9c803-init/diff:/var/lib/docker/overlay2/a2168b993b381f985089daddef7bfc32fa15eae64575e3661b0e028c7ddf8bcc/diff:/var/lib/docker/overlay2/69e1478c7781777eaec105040d2ee9b8397882ddb8e1f320e399f3a7fbd1230c/diff:/var/lib/docker/overlay2/abb7d7bf0ad7f1b823f223652ccd1dc0f9aecdb5e6a3903a77e3832e1d0342d1/diff:/var/lib/docker/overlay2/2b96faabbd98c4847e4ff63598d11d551eddf829b0902f2fb74153247e95f927/diff:/var/lib/docker/overlay2/5d939a6cb84023566cb2513327474b7f029d69016f57ea4fec8d4f174646dc63/diff:/var/lib/docker/overlay2/d305392fcd4d3f4fa441e7cdb71b7dd41b0b77f767293735b393b9c54404312c/diff:/var/lib/docker/overlay2/c5865d2ecfa2c81b42ffeb09755886e9b907c1ac0b48aa9cd57d4cd2afb07263/diff:/var/lib/docker/overlay2/654377eb111af010abfab1e8293f37b7729584d041fe5e79007fb91293d9a75e/diff",
  "MergedDir": "/var/lib/docker/overlay2/b76e86ac1387c177bb70ef2f1c0cdc58b86c228af2b890f474e76d13daf9c803/merged",
  "UpperDir": "/var/lib/docker/overlay2/b76e86ac1387c177bb70ef2f1c0cdc58b86c228af2b890f474e76d13daf9c803/diff",
  "WorkDir": "/var/lib/docker/overlay2/b76e86ac1387c177bb70ef2f1c0cdc58b86c228af2b890f474e76d13daf9c803/work"

LowerDir - Слои образа (read-only)
UpperDir - Слой контейнера (read-write). Всё, что ты изменяешь внутри контейнера, записывается именно сюда.
MergedDir - Смонтированное объединение всех слоёв
WorkDir - Техническая папка OverlayFS

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

docker exec some-alpnginx sh -c "echo test >> /etc/nginx/1.txt"

Этот файл будет сохранён в директории UpperDir контейнера, проверю что он там:

sudo cat /var/lib/docker/overlay2/b76e86ac1387c177bb70ef2f1c0cdc58b86c228af2b890f474e76d13daf9c803/diff/etc/nginx/1.txt

test

Linux - No suitable authentication method found

Fri, 28 Mar 2025 06:20:39 +0600

В общем на сервере есть приложение, которое подключается к другому серверу по sftp (22) и выкачивает оттуда файлы. Так вот при попытке подключения выходила ошибка: Renci.SshNet.Common.SshAuthenticationException: No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive).

Причина

Дело в том, что скорее всего отключена возможность авторизации по паролю, именно password autentification. Когда вы заходите на сервер по ssh вбивая при этом пароль с клавиатуры используется метод keyboard-interactive.

Решение

Для начала рекомендую поискать где вообще упоминается параметр PasswordAuthentication. Обращаем внимание на файл где значение равно no.

sudo grep -rnw /etc/ssh/ -e PasswordAuthentication

/etc/ssh/sshd_config.d/50-cloud-init.conf:1:PasswordAuthentication no

Просто меняем значение в этом файле на yes

sudo vim /etc/ssh/sshd_config.d/50-cloud-init.conf

PasswordAuthentication yes

sudo systemctl restart sshd

Если вдруг есть что-то что постоянно меняет значение в 50-cloud-init.conf, то проще будет создать новый файл 00-pwd-auth.conf
```
sudo vim /etc/ssh/sshd_config.d/00-pwd-auth.conf
```
```
PasswordAuthentication yes
```
```
sudo systemctl restart sshd
```

Проверка изменений

Для того, чтобы проверить что PasswordAuthentication работает пытаемся подключиться к хосту по ssh с выводом всех логов.

ssh -vvv hostip

В выводе должна быть запись Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,**password**,keyboard-interactive

Linux - shell request failed on channel 0

Thu, 20 Mar 2025 06:20:39 +0600

В какой-то момент пользователь перестал заходить на сервер по SSH. После ввода пароля просто получал shell request failed on channel 0.

В логах самого сервера нашёл строчку: fork failed: Resource temporarily unavailable.

Причина

В моём случае причина оказалось в том, что пользователь превысил лимит по запущенным процессам, значение которого равно 4096. Да и такой лимит можно превысить если отдать сервер разработчикам ПО.

Проверка

Чтобы проверить сколько процессов запущено от пользователя:

sudo bash -c "pstree -up username | grep -o '([0-9]\+)' | wc -l"

Решение

Конечно в идеале нужно решить всё-таки почему разрабатываемое ПО создаёт столько процессов и возможно переписать ПО. Но мы то знаем, что заставить разработчика переписать что работает сродни подвигу железного человека в войне бесконечности.

Так вот самым простым решением будет просто увеличить этот лимит:

Открываем файл 20-nproc.conf или 90-nproc.conf
```
 sudo vim /etc/security/limits.d/20-nproc.conf 
```

Вносим правки и увеличиваем лимит на процессы

# для конкретного пользователя
user       soft    nproc     8096
# для всех
*          soft    nproc     6096

Docker - Имя образа и его тэги

Sun, 16 Mar 2025 06:20:39 +0600

Начнём сначала с наименования образа. По умолчанию наименование Docker образа имеет формат [REGISTRY_HOST[:PORT]/][NAMESPACE/]REPOSITORY[:TAG].

docker image ls

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
cache2       1.0       df2d5fb50b42   19 hours ago   141MB
cache1       1.0       ee7e1bf4cdcd   19 hours ago   141MB
nginx        alpine    d4918ca78576   36 hours ago   52.8MB

Но в выводе выше нет никакого имени репозитория или пользователя.

Дело в том что по умолчанию всё что скачано с Docker hub (nginx:alpine) или создано локально (cache2:1.0, cache1:1.0) не имеет названия репозитория в имени образа.
Также если образ скачан с Docker hub и при этом это официальный образ имени пользователя также не будет в наименовании (nginx:alpine)

Для примера я скачаю другой неофициальный образ okteto/nginx:alpine с Docker hub и при просмотре образа увижу в наименовании и имя пользователя (okteto), который загрузил этот образ на Docker hub.

docker pull okteto/nginx:alpine
docker image ls

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
okteto/nginx   alpine    db009330a860   6 years ago    17.8MB

Если же образ скачивается с приватного репозитория то к логическому имени образа также ещё добавляется этот репозиторий.

docker pull mcr.microsoft.com/mcr/hello-world:latest
docker image ls

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
mcr.microsoft.com/mcr/hello-world   latest    fce289e99eb9   6 years ago    1.84kB

mcr.microsoft.com - REGISTRY_HOST, т.е. URL репозитория (порт 443 опускается)
mcr - пространство пользователя или организации
hello-world - логическое имя образа

Тэги

Теперь, когда понятно каким образом строится наименование образа, перейдём к тэгам. Тэг добавляется к наименованию контейнера, зачастую просто указывает версию образа. Например, человек создаёт образ nginx. На следующий день он добавляет супер функцию, которая нужна не всем пользователям. Отсюда встаёт вопрос как справится с этой ситуацией ведь если он загрузит образ с тем же именем он также обновится у всех пользователей при следующей загрузке образа.

Чтобы таких ситуаций не было как раз и используются тэги. С тэгами эта ситуация решается довольно просто человек создаёт образ nginx:1.0 и на следующий день загружает новый образ, допустим с тэгом 1.1 (nginx:1.1).

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

docker build -t mybuild .
docker image ls

REPOSITORY                          TAG       IMAGE ID       CREATED         SIZE
mybuild                             latest    b3a05bfe8f14   4 seconds ago   124MB

Для того чтобы задать тэг для образа можно использовать 2 варианта:

При создании самого образа, используя флаг -t
```
docker build -t mybuild:1.0 .
```
Используя docker tag для уже созданного образа
```
docker tag mybuild:1.0 mybuild:2.0
```

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

docker image ls

REPOSITORY                          TAG       IMAGE ID       CREATED         SIZE
mybuild                             1.0       b3a05bfe8f14   3 minutes ago   124MB
mybuild                             2.0       b3a05bfe8f14   3 minutes ago   124MB

В качестве тэга можно также использовать буквы не только цифры, например nginx:alpine. Т.е. скачивая образ nginx:alpine я всегда буду получать последний свежий образ nginx на alpine. Но если мне нужен конкретная версия nginx также на alpine я могу использовать тэг вида 1.29-alpine или 1.29.3-alpine3.22.

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

docker pull nginx:latest
docker pull nginx:mainline
docker image ls

REPOSITORY                          TAG       IMAGE ID       CREATED         SIZE
nginx                               latest     9d0e6f6199dc   38 hours ago     152MB
nginx                               mainline   9d0e6f6199dc   38 hours ago     152MB

Т.е. оба образа nginx:latest и nginx:mainline идентичны и имеют один размер и дату обновления и также IMAGE ID.

Docker Swarm - Хранилище секретов

Sun, 16 Mar 2025 06:20:39 +0600

Под секретами подразумеваются: логины, пароли, сертификаты, api ключи, ssh ключи и другие секретные данные. В основном конечно это данные необходимые для подключения к тому или иному сервису.

Конечно на данный момент уже существует куча сервисов сторонних компаний для хранения секретов, например, Hashicorp Vault. Но минус таких сервисов в том, что их еще нужно развернуть и настроить.

С версии Docker 1.13.0 база, которую использует Swarm лежит на диске в зашифрованном виде по умолчанию, которая находится на менеджерах кластера. По умолчанию именно тут хранится вся информация необходимая для коммуникации узлов кластера между собой. Например, tls сертификаты для узлов.

В самом начале необходимо конечно же поместить секреты в саму базу и уже потом передать эти секреты сервисам и соответственно их контейнерам/задачам. Только контейнеры в сервисе могут получить доступ к этим секретам, т.е. контейнеры вне сервиса не смогут получить доступ к ним. Все эти секреты помещаются в оперативную память и доступны внутри контейнера по пути /run/secrets/<имя>. Хранится всё в виде ключ: значение.

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

Также если передавать пароли через переменные при создании сервиса или контейнера, то при выполнении команды docker container inspect эти пароли будут выведены.

swarm-secrets-concept.svg

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

Для того, чтобы добавить новый секрет в кластер Swarm используется команда docker secreat create.

Вариант 1️⃣

Для начала создаётся файл, в который помещается секрет. После используется команда docker secreat create для создания секрета со значением из файла.

vim psql_user.txt

app

docker secret create psql_user psql_user.txt

y5jqu91e43jivxje614br60op

После добавления секрета необходимо удалить файл.

rm psql_user.txt

Вариант 2️⃣

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

set +o history
echo "secret" | docker secreat create psql_pwd
set -o history

swarm-secret-creation.svg

Просмотр секретов

Для того чтобы просмотреть какие секреты есть в базе используется команда docker secret ls.

docker secret ls

ID                          NAME        DRIVER    CREATED          UPDATED
y5jqu91e43jivxje614br60op   psql_user             29 seconds ago   29 seconds ago

После того как секрет был создан я сам уже не смогу получить его содержимое, только сервис (контейнер) может получить к нему доступ.

Передача секретов контейнерам

Для примера я создам сервис с образа postgresql и передам ему секрет psql_user и psql_pwd.

docker service create \
  --name db-key \
  --secret psql_user \
  --secret psql_pwd \
  -e POSTGRES_DB=app \
  -e POSTGRES_PASSWORD_FILE=/run/secrets/psql_pwd \
  -e POSTGRES_USER_FILE=/run/secrets/psql_user \
  postgres:16

Проверю что контейнер сервиса запущен и работает:

docker service ps db-key

ID             NAME       IMAGE         NODE             DESIRED STATE   CURRENT STATE            ERROR     PORTS
sxe1t1rbeew0   db-key.1   postgres:16   c-stream-9-vm4   Running         Running 18 seconds ago

В конфиг файле сервиса это передаётся как:

version: "3.8"

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: app
      POSTGRES_USER_FILE: /run/secrets/psql_user 
      POSTGRES_PASSWORD_FILE: /run/secrets/psql_pwd 
    secrets:
      - psql_pwd 
      - psql_user 
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - backend

secrets:
  psql_pwd:
    external: true   # secret уже создан командой `docker secret create`
  psql_user:
    external: true   # secret уже создан командой `docker secret create`

networks:
  backend:
    driver: overlay

volumes:
  db_data:

Обратите внимание если секреты уже созданы еще до создания самого сервиса необходимо указать параметр external: true, если же секреты еще не созданы, то передаём путь к файлу со значением.

secrets:
  psql_pwd:
    file : ./psql_pwd.txt
	psql_user: 
    file : ./psql_user.txt

Проверка что секреты проброшены

Для проверки я переходу в псевдотерминал контейнера сервиса db и проверяю там файлы в директории /run/secrets.

docker exec -it db-key.1.sxe1t1rbeew0v3yml18zkgfzr bash
ls /run/secrets/

psql_pwd  psql_user

cat /run/secrets/psql_pwd

secret

Теперь если я выполню команду docker container inspect в выводе я не увижу само имя пользователя или пароль в открытом виде.

docker container inspect db-key.1.sxe1t1rbeew0v3yml18zkgfzr

			"Env": [
                "POSTGRES_DB=app",
                "POSTGRES_PASSWORD_FILE=/run/secrets/psql_pwd",
                "POSTGRES_USER_FILE=/run/secrets/psql_user",
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/postgresql/16/bin",
                "GOSU_VERSION=1.19",
                "LANG=en_US.utf8",
                "PG_MAJOR=16",
                "PG_VERSION=16.11-1.pgdg13+1",
                "PGDATA=/var/lib/postgresql/data"
            ],

Docker Swarm - Stacks

Sun, 16 Mar 2025 06:20:39 +0600

Настало время рассмотреть стеки в Docker Swarm. Благодаря стекам можно создавать группы сервисов, пописывая всю конфигурацию в compose-файле.

Stack — это “пакет” (группа) из нескольких сервисов, сетей, томов, описанных в одном compose-файле.

1️⃣ Самый простой compose-файл для Docker Swarm Stack

Ниже самый банальный пример compose-файла для создания “пакета” (группы) сервисов web, api. У каждого сервиса по одной реплике задачи/контейнера.

🗃️ stack1.yml

version: "3.8"

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"
    networks:
      - backend

  api:
    image: tipoit/py-hostname:1.0
    networks:
      - backend

networks:
  backend:
    driver: overlay

Для того, чтобы создать сервисы из файла выше использую команду docker stack deploy -c stack1.yml mystack1. В итоге при выполнении этой команды Swarm создаёт:

сервис mystack_web
сервис mystack_api
сеть mystack1_backend

Данная команда на вид выполнится довольно быстро, но выполнение всех необходимых задач происходит в фоном режиме.

swarm-stack-basics.svg

2️⃣ Просмотр стеков

Когда стек создан можно и проверить что там внутри него. Первым делом выведу список всех стеков в кластере.

docker stack ls

NAME       SERVICES
mystack1   2

3️⃣ Просмотр сервисов стека

Для того чтобы получить список сервисов определённого стека используется команда docker stack services.

docker stack services mystack1

ID             NAME           MODE         REPLICAS   IMAGE                    PORTS
j3n3r4fv6itm   mystack1_api   replicated   1/1        tipoit/py-hostname:1.0
iz5pz1t2p4uz   mystack1_web   replicated   1/1        nginx:latest             *:8080->80/tcp

4️⃣ Просмотр задач/контейнеров стека

Да для этого можно использовать и обычную команду docker service ps, но можно заменить её и на docker stack ps и получить вообще все задачи всех сервисов в стеке.

docker stack ps mystack1

ID             NAME             IMAGE                    NODE             DESIRED STATE   CURRENT STATE            ERROR     PORTS
sutyb5hy2irr   mystack1_api.1   tipoit/py-hostname:1.0   c-stream-9-vm4   Running         Running 39 seconds ago
dnd7kdyct9qa   mystack1_web.1   nginx:latest             c-stream-9-vm8   Running         Running 37 seconds ago

5️⃣ Как связаны `stack` и `service`

Как уже стало понятно из текста выше стек состоит из сервисов, стало быть сервисы из одного стека как-то связанны с ним. Во-первых, все сервисы связанны между собой, так как в примере выше используется только одна сеть mystack1_backend, которая принадлежит стеку mystack1.

Каждый сервис стека после создания имеет следующую структуру имени: _, например, `mystack1_api`.

Также можно использовать docker service inspect для того чтобы узнать к какому стеку принадлежит сервис.

docker service inspect mystack1_web --format ''

{"com.docker.stack.image":"nginx:latest","com.docker.stack.namespace":"mystack1"}

docker service ls --filter label=com.docker.stack.namespace=mystack1

ID             NAME           MODE         REPLICAS   IMAGE                    PORTS
krlkybxksuvk   mystack1_api   replicated   1/1        tipoit/py-hostname:1.0
mkdr6mt164tx   mystack1_web   replicated   1/1        nginx:latest             *:8080->80/tcp

swarm-stack-service-linking.svg

6️⃣ Удаление стека

Как и в случае с удалением других компонентов кластера используется опция rm, т.е. команда удаления стека выглядит так: docker stack rm. Причём тут не надо задавать никакого подтверждения после выполнения этой команды весь стек сервисов будет удалён без единого запроса подтверждения на это, будьте осторожны.

docker stack rm mystack1

Удаление стека также проходит в фоновом режиме. Так что пока стек полностью не удалится не создавайте новый с таким же именем, либо можно использовать --detach=false.

6️⃣ Build не работает

При использовании docker compose в файле можно использовать параметр build, для того чтобы собрать образ для контейнера при создании контейнеров. Но в файле конфигурации для стека build использовать нельзя. При попытке это сделать вы просто получите ошибку services.api.build Additional property build is not allowed выполняя команду docker stack build.

Причина на самом деле проста. Swarm — это кластер. Он может запускать сервисы на любом узле кластера, а build происходит только локально. Значит, собирать образ внутри stack нельзя.

Дело в том, что Docker не может гарантировать:

что образ соберётся одинаково на каждой ноде;
что нода, на которую Swarm поставит сервис, имеет исходники;
что билд-окружение одинаковое.

Поэтому правильнее всего будет сделать так:

Собираешь образ локально или в CI (docker build)
Загрузить его в репозиторий (docker push)
В файле stack.yml указать образ с репозитория

Помимо build в файле конфигурации стека нельзя указывать следующее:

depends_on
container_name
restart
links

swarm-stack-build-forbidden.svg

Grafana - Просмотр Dashboard без авторизации

Wed, 12 Mar 2025 06:20:39 +0600

По умолчанию если вы включили авторизацию в Grafana, то только зарегистрированные пользователи могут просмотреть Dashboard. Но можно это изменить.

Вариант 1

В первом варианте мы включим анонимный доступ к Grafana и зададим роль по умолчанию для анонимных пользователей.

В файле конфигурации grafana.ini включаем анонимный доступ в целом
```
sudo vim /etc/grafana/grafana.ini
```
```
[auth.anonymous]
enabled = true
```
Там же задаем роль для анонимных пользователей
```
[auth.anonymous]
org_role = Viewer
```
Перезапускаем сервис grafana-server
```
sudo systemctl restart grafana-server
```
Переходим в настройки Dashboard и проверяем какие права у роли Viewer во вкладке Permissions
Открываем ссылку Dashboard в новом окне браузера инкогнито

Вариант 2

Пользователь со стажем сразу заметит, что вариант выше по умолчанию даст доступ анонимным пользователем ко всем Dashboard, хоть и только на чтение. Дело в том, что роль Viewer по умолчанию имеет доступ ко всем Dashboard.

Это можно решить либо отбиранием прав у роли Viewer к Dashboard, либо создать свою собственную роль и выдать права на Dashboard этой роли. Но создание своей роли к сожалению, доступно только вGrafana Enterprise.

Так как у меня нет лицензии на Grafana Enterprise я просто оставлю ссылку на оф документации по созданию роли.

Veeam - Политика хранения инкрементных резервных копий (Retention Policy)

Thu, 30 Jan 2025 06:20:39 +0600

Для того чтобы восстановить виртуальную машину из резервной копии вам необходимо иметь полную цепочку резервных копий. Например, если удалить файл полной резервной копии, то восстановить виртуальную машину вы уже не сможете, так как нарушена цепочка резервных копий. Тоже самое касается и инкрементных резервных копий. Если вы удаляете инкрементную резервную копию, то вы сможете восстановиться только на предыдущие резервные копии. Например, у вас одна полная резервная копия и пять инкрементных, и вы решили удалить файл четвёртой инкрементной резервной копии. В таком случае вы максимум сможете восстановить состояние виртуальной машины, которое находится в третьей инкрементной резервной копии.

Поэтому при использовании метода Forward incremental (FI) в какой-то момент вы можете заметить, что у вас больше резервных копий, чем указано в политике хранения. Дело в том, что Veeam Backup & Replication удалит полную цепочку, только когда последняя резервная копия в ней не устареет.

Почему может быть больше точек восстановления, чем указано в политике

Пример:

В политике указано: хранить 4 точки восстановления.
После создания 1 VBK + 3 VIB = 4 точки.
Veeam ещё не может удалить эту цепочку — она единственная.
Создаётся 2-я полная копия, и начинается новая цепочка.
Пока новая цепочка не достигнет 4 точек восстановления, первая цепочка не удаляется.
В этот момент в системе будет 8 точек восстановления (2 цепочки по 4).

🟡 Это нормальное поведение, обеспечивающее гарантированную возможность восстановления, пока новая цепочка не станет полной.

Вывод:

Для восстановления требуется непрерывная цепочка (VBK + все нужные VIB).
Удалять бэкапы вручную нельзя — используйте правила хранения.

Veeam - Вечное пошаговое инкрементное резервное копирование (FFI)

Wed, 29 Jan 2025 06:20:39 +0600

При использовании вечного пошагового инкрементного резервного копирования (Forever forward incremental) вы получаете цепочку резервных копий, состоящую из полной резервной копии (VBK) и группы инкрементальных (VIB).

Процесс создания резервной копии выглядит так:

При первом запуске создания резервной копии Veeam Backup & Replication создаёт полную резервную копию и сохраняет файл в репозитории.
При каждом последующем запуске Veeam Backup & Replication копирует только те данные в VM, которые были изменены после создания последней резервной копии (полной либо инкрементной). Далее эти данные сохраняются в файле инкрементной резервной копии.
И последним шагом Veeam Backup & Replication проверяет все ли инкрементные резервные копии соответствуют политике хранения (retention policy) и если находит резервные копии старше политики хранения, то перемещает их в полную резервную копию. О политике хранения (retention policy) для FFI можно почитать тут.

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

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

В верхнем левом углу выбираем Backup Job > Virtual machine
Во вкладке Virtual machines добавляем виртуальные машины
Во вкладке Storage нажимаем Advanced
Выбираем Incremental и снимаем галочку Create syntetic full backups

Veeam - Сжатие файла полной резервной копии

Fri, 24 Jan 2025 06:20:39 +0600

Некоторые методы создания резервных копий в Veeam Backup & Replication приводят к постоянным изменениям полных резервных копий. И это может привести к неприятным последствиям. Со временем файл полной резервной копии становится слишком большим и фрагментированным. В результате чего мы получаем долгие операции записи и чтения.

Для решения этой проблемы можно воспользоваться встроенной функцией для дефрагментации и сжатия полной резервной копии. В процессе выполнения сжатия Veeam Backup & Replication создаёт новый файл полной резервной копии и копирует все данные со старого файла, переупорядочивает их и сохраняет близко друг к другу. В результате файл дефрагментируется, уменьшается размер и увеличивается скорость записи и чтения.

Чтобы включить эту функцию нужно активировать опцию Дефрагментация и сжатие полного файла резервной копии (Defragment and compact full backup file) в настройках задачи создания резервной копии.

Ограничения

Параметр «Дефрагментация и сжатие полного файла резервной копии» работает для FFI или RI резервного копирования. По этой причине вы не должны планировать активные или синтетические полные резервные копии.

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

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

Удаление данных удаленных виртуальных машин

При сжатии полной резервной копии Veeam Backup & Replication обращает внимание на то удалялись ли какие-то виртуальные машины с задачи создания резервной копии. И если такие виртуальные машины есть, то их данные не будут копироваться в сжатую версию полной резервной копии.

Veeam - Методы (типы) резервных копий

Fri, 24 Jan 2025 06:20:39 +0600

Для создания резервной копии в Veeam Backup & Replication вы можете использовать следующие методы создания резервных копии (бэкапов):

Вечное пошаговое инкрементное продвижение (FFI) / Forever forward incremental (FFI)

При использовании Forever forward incremental (FFI) создаётся цепочка резервных копий, состоящая из первой полной резервной копии (VBK) и группы инкрементных резервных копий (VIBs).

Такой метод считается максимально подходящим, когда нужно сэкономить дисковое пространство, так как вы сохраняете только одну полную резервную копию и только актуальные инкрементные резервные копии. Дело в том, что вы можете настроить срок хранения инкрементных резервных копий, всё что старше определённого периода будет удаленно автоматически. Но перед тем как удалить все старые инкрементные резервные копии Veeam Backup & Replication вставляет все данные с этих резервных копий в файл полной резервной копии. Подобные преобразования могут привести к фрагментации файла полной резервной копии, и вам придется запланировать операцию сжатия файла полной резервной копии, что добавит дополнительную нагрузку ввода-вывода на резервное хранилище.

Восстановление резервной копии происходит быстрее остальных, так как всегда имеется полная резервная копия. Хотя по скорости восстановления можно сопоставить и с Forward incremental (FI).

О том, как создать резервную копию используя метод Forever forward incremental (FFI) можно почитать тут.

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

Инкрементный / Forward incremental (FI)

При использовании метода Forward incremental (FI) создаётся цепочка резервных копий, которая состоит из нескольких полных резервных копий (VBKs) и группы инкрементных (VIBs) после каждой полной резервной копии. Полные резервные копии можно создавать с помощью методов синтетического полного и активного полного резервного копирования. Благодаря нескольким полным резервным копиям этот метод считается наиболее надёжным, так как снижает вероятность полной потери цепочки резервных копий. Хотя, как по мне если всё лежит на одном жёстком диске, то его потеря приведёт к полной потери всего.

Понятное дело, что такой метод требует больше дискового пространства по сравнению с другими. Также Veeam Backup & Replication может хранить больше точек восстановления, чем указано в политике (retention policy) из-за специфики политики хранения FI.

Метод резервного копирования FI обеспечивает наименьшее влияние ввода-вывода на хранилище резервных копий. Однако только не в те дни, когда запланированы активные или синтетические полные резервные копии, что в принципе логично.

Обратный инкрементный / Reverse incremental (RI)

При использовании метода Reverse incremental (RI) создаётся цепочка резервных копий, состоящая из полной резервной копии (VBK) и группы обратных инкрементных резервных копий (VRBs).

При этом полная резервная копия будет всегда одна (только если вы сами периодически не делаете полную рез копию) и также будет являться последней резервной копией. Так как тут используется всего одна полная резервная копия - это приводит к рациональному использованию дискового пространства, т.е. занимает меньше места на диске. Также, как и со всеми остальными типами инкрементные резервные копии периодически удаляются (retention policy).

При использовании этого типа происходит самая большая нагрузка на операции ввода-вывода. Происходит это потому что Veeam Backup & Replication добавляет изменённые данные в полную резервную копию и также создаёт обратные инкрементные резервные копии. Подобные преобразования могут привести к фрагментации файла полной резервной копии, и вам придется запланировать операцию сжатия файла полной резервной копии.

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

Forever forward incremental / Forward incremental / Reverse incremental /

Veeam - Политика хранения инкрементных резервных копий (Forever Forward)

Mon, 20 Jan 2025 06:20:39 +0600

Если количество дней или количество точек восстановления файлов резервных копий, созданных с использованием типа вечное инкрементное резервное копирование превышает лимит, заданный в политике хранения, то Veeam Backup & Replication преобразует цепочку резервного копирования, чтобы освободить место для последней точки восстановления. Для этого используется следующий процесс:

Veeam Backup & Replication создаёт инкрементальную резервную копию и помещает её в цепочку резервных копий и замечает, что количество дней или количество точек восстановления превышает порог, заданный в политике хранения.
Veeam Backup & Replication повторно использует пустые блоки данных в файле полной резервной копии, чтобы включить изменения с файла инкрементальной резервной копии, который следует сразу за полной резервной копией (первый инкрементный после полного). Для этого Veeam Backup & Replication внедряет блоки данных из первого инкрементального файла резервной копии в цепочке в файл полной резервной копии. Т.е. по сути происходит слияние двух файлов.
Теперь, когда данные с инкрементной резервной копии продублированы в полной резервной копии Veeam Backup & Replication удаляет эту резервную копию (инкрементную).

Как узнать таблицу раздела gpt или mbr

Fri, 17 Jan 2025 06:20:39 +0600

parted-linux / gdisk-linux / diskpart-windows / powershell-windows /

Чтобы узнать какая таблица раздела используется можно использовать:

Используя parted (Linux)

Выполняем команду:
```
sudo parted -l
```
В выводе ищем наш диск и получаем таблицу раздела
```
Disk /dev/sdb: 21.5GB
Partition Table: gpt
```

Используя gdisk (Linux)

Выполняем команду, указывая конкретный диск (/dev/sdb):
```
sudo gdisk -l /dv/sdb
```
В выводе получаем таблицу раздела
```
GPT fdisk (gdisk) version 0.8.10
```

Используя DISKPART (Windows)

Запускаем diskpart через командную строку:
```
diskpart
```
Выводим список всех дисков
```
list disk
```

Если под GPT у диска стоит * значит используется GPT, если нет - то MBR

  Диск ###  Состояние      Размер   Свободно Дин  GPT
  --------  -------------  -------  -------  ---  ---
  Диск 0    В сети          465 Gбайт  1024 Kбайт
  Диск 1    В сети          465 Gбайт  3072 Kбайт  *
  Диск 2    В сети         1862 Gбайт  1024 Kбайт  *

Используя PowerShell (Windows)

Выполняем команду:
```
Get-Disk
```

В выводе получаем таблицу раздела (Partition Style)

Number Friendly Name Serial Number                    HealthStatus         Size Partition	Partition Style
------ ------------- -------------                    ------------         - ----------
2      AMD-RAID A... 0000e3dc			              Healthy              1.82TB 			GPT
0      Samsung SS... 0025_				              Healthy              465.76 GB 		MBR
1      Samsung SS... 0025_3854			              Healthy              465.76 GB 		GPT

Docker - Загрузка образа в репозиторий

Thu, 16 Jan 2025 06:20:39 +0600

Для того чтобы загрузить свой образ в репозиторий необходимо иметь логин и пароль на репозиторий. В этой статье я буду рассматривать Docker Hub в качестве репозитория. Первым делом необходимо зарегистрироваться на сайте Docker Hub.

После регистрации необходимо залогиниться на Docker Hub со своего устройства, используя docker login.

docker login

Username: jadqvmirmitclcmwwm
Password:
Login Succeeded

Выполняя команду выше, я не указывал web-адрес репозитория, потому что по умолчанию используется Docker Hub. Если вдруг нужно залогиниться на другом репозитории к самой команде добавляем url репозитория, например, docker login registry.example.com.

После удачной авторизации в системе создаётся файл с вашим логином и токеном для доступа к репозиторию.

sudo cat /home/admin/.docker/config.json

        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "amFkcXZtaXJtaXRjbGNtd3dtOmphZHbUBrdmhydy5jb20="
                }
        }

Поэтому после того как вы выполнили загрузки образа в репозиторий лучше выполнить docker logout.

Одинаковый NAMESPACE

В этой статье я расписывал как происходит наименование образов в Docker. И очень важно знать, что образ, который вы собираетесь отправить в репозиторий должен иметь такой же NAMESPACE, как и ваше имя пользователя в репозитории. Но это не всегда так, некоторые репозитории не привязаны к этому, но Docker Hub требует именно этого.

docker image ls

ynwasg/build12                      1.2               d2a2ec50e235   14 hours ago   124MB

docker push ynwasg/build12

The push refers to repository [docker.io/ynwasg/build12]
tag does not exist: ynwasg/build12:latest

Теперь же я добавлю новый тэг для этого образа и NAMESPACE задам такой же как имя моего пользователя на Docker Hub, после чего попробую еще раз сделать docker push.

docker image tag ynwasg/build12:1.2 jadqvmirmitclcmwwm/build12:1.1
docker image ls

jadqvmirmitclcmwwm/build12          1.1               d2a2ec50e235   15 hours ago   124MB

docker push jadqvmirmitclcmwwm/build12:1.1

The push refers to repository [docker.io/jadqvmirmitclcmwwm/build12]
5b7bc18f2b9b: Pushed
755f21c870f5: Pushed
235e81929876: Mounted from library/python
9ba402f61141: Mounted from library/python
15eb6aec49b3: Mounted from library/python
d7c97cb6f1fe: Mounted from library/python
1.1: digest: sha256:c768e2220b5b0f8e11ab4934577d192776c7e3728e5824b31c06e5cf2bd1979d size: 1573

Теперь, когда имя моего пользователя на Docker Hub и NAMESPACE образа совпадают образ удачно загрузился в репозиторий.

Как работает docker push

При вызове команды docker push происходит следующее:

Проверка залогинен ли пользователь в репозитории
Проверка существующих слоёв в репозитории
Отправка только новых слоёв в репозиторий
Добавление или обновление тэга образа

Veeam - Активное полное резервное копирование

Wed, 15 Jan 2025 06:20:39 +0600

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

Активное полное резервное копирование создаёт полную резервную копию виртуальной машины, таже как при первом запуске задачи создания резервной копии.

При создании полной резервной копии цепочка резервных копий сбрасывается. Т.е. все последующие инкрементные резервные копии будут использовать файл активной полной резервной копии как отправную точку. Предыдущий файл полной резервной копии будет хранится в репозитории пока соответствует политике хранения.

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

Наверное, вы заметили, что в расписании нет времени, когда запускать активное полное резервное копирование. Дело в том, что время запуска берётся из самой задачи создания резервной копии. Если же сама задача создания резервной копии отключена, то и активное полное резервное копирование запущенно не будет.

Если на время запуска активного полного резервного копирования назначен запуск создания инкрементной резервной копии, то будет запущен только процесс создания активного полного резервного копирования.

Важное замечание если расписание вашей основной задачи создания резервной копии не совпадает с активным полным резервным копированием, то активное полное резервное копирование запущенно не будет. Например, сама задача запускается каждый понедельник, а активное полное резервное копирование вы настроили на вторник.

Veeam - Синтетическое полное резервное копирование

Sat, 11 Jan 2025 06:20:39 +0600

Если вы читали мои предыдущие статьи про Veeam, то вы скорее всего знакомы со словами синтетическое полное резервное копирование. Может так произойти что вы хотите создать полную резервную копию, но так как этот процесс занимает много времени вы отказываетесь от этой идеи. В качестве альтернативы можно создавать синтетические полные резервные копии.

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

Когда создается полная резервная копия Veeam Backup & Replication извлекает данные с самого хранилища данных (datastore), далее сжимает и дедуплицирует ее, а затем записывает всё в файл VBK в репозитории резервных копий.
Когда создается синтетическая полная резервная копия Veeam Backup & Replication не извлекает данные с самого хранилища данных (datastore). Вместо этого он обращается к цепочке существующих резервных копий, ведь по сути там те же данные. Первым делом он получает все данные с последней полной резервной копии и дальше из цепочки последующих инкрементных файлов резервных копий в репозитории. После происходит процесс объединения этих данных в новый файл полной резервной копии. В результате вы получаете те же данные что при создании полной резервной копии.

Процесс создания синтетической полной резервной копии имеет некоторые преимущества:

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

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

Чтобы включить создание синтетической полной резервной копии вам необходимо в задачи создания резервной копии активировать галочку Периодически создавайте синтетические полные резервные копии (Create synthetic full backups periodically).

MinIO - Variable MINIO_VOLUMES not set in /etc/default/minio

Thu, 26 Dec 2024 06:20:39 +0600

Ошибка может появится даже если вы всё сделали правильно, а именно:

Добавили MINIO_VOLUMES в файл /etc/default/minio
Дали полные права пользователю minio-user на /etc/default/minio и на директории с данными

Настраиваем selinux

Для начала просто проверим что если отключить selinux, то сервис запустится.

sudo setenforce 0
sudo systemctl start minio
sudo systemctl status minio

Active: active (running)

sudo setenforce 1
sudo systemctl stop minio

Теперь собственно настроим selinux, чтобы этот всемогущий демон дал доступ нашему сервису к файлу /etc/default/minio.

Проверим что у нас есть на minio

sudo cat /var/log/audit/audit.log | grep minio

type=AVC msg=audit(1735194495.552:4448): avc:  denied  { open } for  pid=1 comm="systemd" path="/etc/default/minio" dev="sdb1" ino=457586 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0

Проверим какое правила можно создать

sudo dnf install policycoreutils-python-utils
sudo audit2allow -a

allow init_t user_tmp_t:file open;

Создаём правило и применяем его

sudo grep init_t /var/log/audit/audit.log | sudo audit2allow -M init_t
sudo semodule -i init_t.pp
sudo systemctl start minio
sudo systemctl status minio

Active: active (running)

Docker warm - Что будет если хост в кластере отключился?

Sat, 21 Dec 2024 06:20:39 +0600

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

Для теста я просто выключу хост c-stream-9-vm9 и посмотрю, что произойдёт.

docker node ls

ojbmchzvipwmlwsssx0ctrxyq *   c-stream-9-vm4   Ready     Active         Leader           25.0.3
sho740q9bdze4xcspm7mzv9m9     c-stream-9-vm8   Ready     Active         Reachable        25.0.3
m8hrgh3jdlqlzijvhjdig4lx2     c-stream-9-vm9   Ready     Active         Unreachable      25.0.3

Команда docker node ls ожидаемо показала, что хост c-stream-9-vm9 недоступен. Теперь я проверю что там с контейнерами сервиса web.

swarm-failover-02-node-down.svg

docker service ps web

42iq7g9uwvqk   web.1       nginx:latest   c-stream-9-vm4   Running         Running 2 minutes ago
8yhysu9vqh00   web.2       nginx:latest   c-stream-9-vm8   Running         Running 2 minutes ago
oqv42koox4pe   web.3       nginx:latest   c-stream-9-vm4   Running         Running 9 seconds ago
zig22fjbiaqc    \_ web.3   nginx:latest   c-stream-9-vm9   Shutdown        Running 2 minutes ago

А вот тут возможно для кого-то неожиданный исход. Так как контейнер стал недоступным вместе с хостом Swarm это обнаружил и понял, что сейчас активны только две реплики из трёх, и понял, что нужно создать недостающую третью. В итоге на хосте c-stream-9-vm4 теперь размещаются 2 контейнера.

swarm-failover-03-auto-recovery.svg

Теперь я включу хост c-stream-9-vm9 и проверю что произойдёт.

docker node ls

ojbmchzvipwmlwsssx0ctrxyq *   c-stream-9-vm4   Ready     Active         Leader           25.0.3
sho740q9bdze4xcspm7mzv9m9     c-stream-9-vm8   Ready     Active         Reachable        28.3.3
m8hrgh3jdlqlzijvhjdig4lx2     c-stream-9-vm9   Ready     Active         Reachable        25.0.3

Тут ничего необычного, хост стал доступен. Теперь проверю что там с контейнерами.

docker service ps web

42iq7g9uwvqk   web.1       nginx:latest   c-stream-9-vm4   Running         Running 2 minutes ago
8yhysu9vqh00   web.2       nginx:latest   c-stream-9-vm8   Running         Running 2 minutes ago
oqv42koox4pe   web.3       nginx:latest   c-stream-9-vm4   Running         Running 9 seconds ago
zig22fjbiaqc    \_ web.3   nginx:latest   c-stream-9-vm9   Shutdown        Running 2 minutes ago

А вот тут не совсем очевидный вывод. Да хост стал доступен, но вот контейнер не переехал на восстановленный хост.

swarm-failover-04-node-recovered.svg

Почему контейнер не вернулся на восстановленный хост?

Разберём подробно, почему контейнер (“task”) не “переехал” обратно на восстановившийся хост, и почему это — нормальное, осознанное поведение Swarm.

Сам Swarm работает немного по-другому. Swarm не хранит “привязку” контейнера к конкретному хосту как обязательную. Его главная задача — это поддержание реплики. Когда я отключил хост c-stream-9-vm9 он понял, что реплика 2/3 после чего создал недостающую реплику, статус теперь 3/3. После этого ситуация считается решенной и даже после включения хоста реплика остаётся 3/3, соответственно ничего делать и не нужно.

swarm-failover-05-explanation.svg

Можно ли заставить Swarm “переселить” контейнеры обратно?

Да, но только вручную или при обновлении сервиса:

Способ 1 — форсировать обновление

docker service update --force web
docker service ps web

ID             NAME        IMAGE          NODE             DESIRED STATE   CURRENT STATE             ERROR     PORTS
4kvxwxglflhd   web.1       nginx:latest   c-stream-9-vm9   Running         Running 17 seconds ago
26xg6bxcmp30   web.2       nginx:latest   c-stream-9-vm8   Running         Running 13 seconds ago
0qbkd8pr2c6o   web.3       nginx:latest   c-stream-9-vm4   Running         Running 8 seconds ago

Способ 2 — удалить старый контейнер вручную, Swarm создаст новый — возможно уже на свободной vm9
```
docker rm <container>
```

Docker Swarm - overlay-сети

Sat, 21 Dec 2024 06:20:39 +0600

Overlay-сеть — это виртуальная распределённая сеть (VXLAN), которая соединяет контейнеры между разными хостами Swarm. Как и в обычном Docker по умолчанию создаётся сеть ingress для Swarm, является сетью по умолчанию для всех сервисов. Также создаётся мост docker_gwbridge для Swarm.

docker network ls

60a8d3ab28a9   docker_gwbridge    bridge    local
kj4mqhyy9nji   ingress            overlay   swarm

swarm-network-01-default.svg

То есть контейнеры на хостах vm4, vm8 и vm9 могут видеть друг друга по внутренним IP,
как будто находятся в одной LAN.

Для детального рассмотрения overlay-сетей я создам два сервиса (backend и frontend), подключу их к разным overlay-сетям, и покажу, как между ними происходит взаимодействие.

1️⃣Создание двух overlay-сетей

Для этого используется уже знакомая команда docker network create, только с опцией –driver.

docker network create -d overlay frontend_net
docker network create -d overlay backend_net
docker network ls | grep net

85twu2uuvm3d   backend_net        overlay   swarm
qtgx23jd02zl   frontend_net       overlay   swarm

2️⃣Docker образ приложения api

Пример будет состоять из двух сервисов:

api — простой backend на Python Flask
web — Nginx, который обращается к backend_net через внутреннюю сеть

📜 api.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello from backend via overlay network!\n"

app.run(host="0.0.0.0", port=5000)

📜 Dockerfile.api

FROM python:3.12-alpine
WORKDIR /app
COPY api.py .
RUN pip install flask
CMD ["python", "api.py"]

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

docker build -t myapi:1.0 -f Dockerfile.api .

3️⃣Docker образ web

📜 nginx.conf

events {}
http {
    server {
        listen 80;
        location / {
            proxy_pass http://api:5000;  # имя сервиса api — DNS в overlay
        }
    }
}

📜 Dockerfile.web

FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf

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

docker build -t mynginx:1.0 -f Dockerfile.web .

4️⃣Развёртывание сервиса api

Теперь разверну сервис api из образа myapi:1.0 с двумя репликами, где также укажу созданную ранее сеть backend_net.

docker service create --name api --network backend_net --replicas 2 myapi:1.0

Но тут я получу ошибку 2/2: No such image: myapi:1.0, потому что так как у меня три узла в кластере образ этот должен быть на всех узлах. Поэтому если вы используете в боевой среде Swarm, то заливайте свои образы в репозиторий и скачивайте их оттуда.

swarm-registry-01-problem.svg swarm-registry-02-solution.svg

docker service ps api

zre8g7r64glm   api.1     myapi:1.0   c-stream-9-vm9   Running         Running 23 seconds ago
pgloedqlhxoa   api.2     myapi:1.0   c-stream-9-vm8   Running         Running 25 seconds ago

5️⃣Развёртывание сервиса web

Теперь разверну сервис api из образа mynginx:1.0 с двумя репликами, где также укажу созданную ранее сеть backend_net и frontend_net. Почему сразу две сети? Потому что по умолчанию сеть frontend_net не имеет доступ к сети backend_net. Поэтому если я создам сервис только с сетью frontend_net он не получить доступ к контейнерам сервиса api.

swarm-multinetwork-01-problem.svg swarm-multinetwork-02-solution.svg

docker service create --name web --network frontend_net --network backend_net -p 8080:80 mynginx:1.0
docker service ps web

r669iabwy6b3   web.1     mynginx:1.0   c-stream-9-vm4   Running         Running 12 seconds ago

curl http://127.0.0.1:8080

Hello from backend via overlay network!

6️⃣Проверка DNS внутри сетей

Можно проверить что контейнер сервиса web имеет доступ к контейнеру сервиса api.

docker exec -it $(docker ps | grep web | head -1 | awk '{print $1}') ping api

7️⃣Проверка сети внутри контейнера

Теперь я проверю какая подсеть у каждой overlay сети, которую я создал и как она привязана внутри контейнера.

docker-swarm-overlay-networks.svg

docker network inspect -f "{{.IPAM.Config}}" frontend_net
docker network inspect -f "{{.IPAM.Config}}" backend_net

[{10.0.3.0/24  10.0.3.1 map[]}]
[{10.0.4.0/24  10.0.4.1 map[]}]

Если вывести список всех интерфейсов контейнера для сервиса api у него будет три интерфейса, конкретно сейчас меня интересует интерфейс с ip-адресом в диапазоне 10.0.4.0/24, так как это диапазон сети backend_net и именно это сеть используется для сервиса api.

docker exec api.1.pmo73in1u8ik4lky6xtjtcsqv ifconfig

eth0      Link encap:Ethernet  HWaddr 02:42:0A:00:04:28
          inet addr:10.0.4.40  Bcast:10.0.4.255  Mask:255.255.255.0

docker exec api.2.nsmhjy7akum2w5qkrwkmhfub2 ifconfig

eth0      Link encap:Ethernet  HWaddr 02:42:0A:00:04:29
          inet addr:10.0.4.41  Bcast:10.0.4.255  Mask:255.255.255.0

Получается, что благодаря тому, что сеть backend_net была создана на всех хостах кластера при этом еще и добавлена в каждый контейнер сервиса api все контейнеры внутри этой сети могут общаться друг с другом.

Но у меня еще остался не проверенным контейнер сервиса web, проделаю тоже самое и с ним.

docker exec web.1.vsyyj80munjaa7fce8xowhz6k ifconfig

eth0      Link encap:Ethernet  HWaddr 02:42:0A:00:04:3B
          inet addr:10.0.4.59  Bcast:10.0.4.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 02:42:0A:00:03:D2
          inet addr:10.0.3.210  Bcast:10.0.3.255  Mask:255.255.255.0

Так как у контейнера web помимо сети frontend_net есть еще и backend_net, благодаря чему контейнеры сервиса web могут обращаться к контейнерам сервиса api.

🎱Доступ из вне

Контейнер web.1 размещён на хосте c-stream-9-vm4 с ip-адресом 172.31.144.9. Получается, что я могу обратиться по адресу http://172.31.144.9:8080 и получить ответ от контейнера web.1. Всё так, и тут нет ничего необычного. Но вот что тут необычного я также могу обратиться по любому другому ip-адресу хоста в кластере и также получить доступ к контейнеру web.1, например, http://172.31.144.22:8080.

swarm-ingress-01-concept.svg

Итог

Overlay-сети в Swarm позволяют изолировать и при этом соединять сервисы на разных нодах.
Один сервис может быть в нескольких overlay-сетях и выполнять роль “моста” между ними — как web в моём примере.

swarm-multinetwork-07-summary.svg

Docker Swarm - Твой первый нормальный кластер

Sat, 21 Dec 2024 06:20:39 +0600

В этой статье я рассмотрю, как создать кластер Docker Swarm из трёх хостов. Я буду использовать три виртуальных хоста на CentOS Stream 9. У хостов следующие ip-адреса:

Первым делом необходимо проверить что на всех хостах стоит Docker и самое главное одинаковой версии. В дальнейшем при обновлении Docker старайтесь поддерживать одну и ту же версию на всех хостах кластера. Если Docker не стоит, то устанавливаем по инструкции.

docker info

Активация Swarm

Выполняю команду docker swarm init на c-stream-9-vm4, после выполнения команды хост также станет лидером менеджеров, которые управляют кластером. Т.е. для управления кластером и создания сервисов хост, на котором вы выполняете команды должен быть менеджером кластера.

docker swarm init

Swarm initialized: current node (ojbmchzvipwmlwsssx0ctrxyq) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-1t2rvntthomlpuvdsd7cxckzku6njkei32fyqrxntcmcq119p7-9xhm3uyo5t2uv1tangzn4fc5y 172.31.144.9:2377

Обратите внимание что команды также вывела ip-адрес и порт, по которому другие хосты в кластере будут обращаться к c-stream-9-vm4. Если вдруг у вас несколько ip-адресов, то можно добавить опцию --advertise-addr 192.168.1.1. Соответственно все узлы в кластере должны иметь возможность обращаться друг к другу. Вот минимальный список портов, которые должны быть открыт между хостами кластера:

Поэтому на каждом хосте я выполняю команды для настройки локального файрволла:

sudo firewall-cmd --permanent --add-port=2377/tcp
sudo firewall-cmd --permanent --add-port=7946/tcp
sudo firewall-cmd --permanent --add-port=7946/udp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --reload

Добавление новых узлов в кластер

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

docker swarm join --token SWMTKN-1-1t2rvntthomlpuvdsd7cxckzku6njkei32fyqrxntcmcq119p7-9xhm3uyo5t2uv1tangzn4fc5y 172.31.144.9:2377

This node joined a swarm as a worker.

На менеджере (c-stream-9-vm4) выполняю команду для проверки узлов в кластере:

docker node ls

ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
ojbmchzvipwmlwsssx0ctrxyq *   c-stream-9-vm4   Ready     Active         Leader           25.0.3
sho740q9bdze4xcspm7mzv9m9     c-stream-9-vm8   Ready     Active                          25.0.3
m8hrgh3jdlqlzijvhjdig4lx2     c-stream-9-vm9   Ready     Active                          25.0.3

Из вывода видно, что сейчас только один MANAGER в кластере и если я попытаюсь выполнить ту же команду на другом узле я получу ошибку: This node is not a swarm manager.

Смена роли с Worker на Manager

Логично что иметь кластер всего с одним Manager не очень-то и безопасно, поэтому я изменю роль оставшимся двум узлам с просто Worker на Manager.

Для этого на Manager узле я выполняю:

docker node update --role manager c-stream-9-vm8
docker node update --role manager c-stream-9-vm9
docker node ls

ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
ojbmchzvipwmlwsssx0ctrxyq *   c-stream-9-vm4   Ready     Active         Leader           25.0.3
sho740q9bdze4xcspm7mzv9m9     c-stream-9-vm8   Ready     Active         Reachable        28.3.3
m8hrgh3jdlqlzijvhjdig4lx2     c-stream-9-vm9   Ready     Active         Reachable        25.0.3

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

docker swarm join-token manager

To add a manager to this swarm, run the following command:
docker swarm join --token SWMTKN-1-1t2rvntthomlpuvdsd7cxckzku6njkei32fyqrxntcmcq119p7-26ztp5rlpq6byyvymgp447g8u 172.31.144.9:2377

Как работает выбор лидера

Swarm использует алгоритм Raft для консенсуса между менеджерами:

Создание Service

Теперь всё готов для того, чтобы я создал первый сервис в кластере. Я создам веб сервис из образа Nginx и укажу три реплики. Так как у меня три хоста в кластере, каждый хост будет размещать по одному контейнеру. В таком случае при неисправности какого-то хоста мой веб сервис будет продолжать работать.

docker  service  create  --replicas  3  --name  web  -p  80:80  nginx

overall progress: 3 out of 3 tasks
1/3: running   [==================================================>]
2/3: running   [==================================================>]
3/3: running   [==================================================>]
verify: Service converged

docker service ps web

ID             NAME      IMAGE          NODE             DESIRED STATE   CURRENT STATE            ERROR     PORTS
42iq7g9uwvqk   web.1     nginx:latest   c-stream-9-vm4   Running         Running 28 seconds ago
8yhysu9vqh00   web.2     nginx:latest   c-stream-9-vm8   Running         Running 29 seconds ago
zig22fjbiaqc   web.3     nginx:latest   c-stream-9-vm9   Running         Running 28 seconds ago

Из вывода команд видно, что при создании сервиса Docker Swarm создал по одном контейнеру на каждом хосте кластера.

Docker - Активация Swarm

Sat, 21 Dec 2024 06:20:39 +0600

Первое что необходимо сделать при использовании Swarm с Docker это активировать Swarm, после установки самого Docker конечно.

Для начала проверяем активирован ли Swarm (по умолчанию отключен) выполнив команду:

docker info

Swarm: inactive

Для активации выполняем команду docker swarm init. Вывод команды должен быть следующий:

Swarm initialized: current node (uzypzuxnb5bwte8y34crmsm7n) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join --token SWMTKN-1-422oqh6omvvsbjwdt2r9qxiyufm5zxa768sxow5qkmxcc4wgt3-1sbq1lijyrnryn3n3xdqzncnd 172.31.144.9:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.

Зачем docker swarm init

docker swarm init — это первая команда, с которой начинается развёртывание кластерной оркестрации Docker Swarm.

Команда docker swarm init запускает демон Swarm Mode на текущем Docker-хосте
и делает его менеджером (Manager Node). Manager Node может управлять кластером и запускать контейнеры.

Помимо это для этого менеджера выпускается сертификат и токен, который может быть использован в будущем для кластера (несколько Docker Swarm). Используя токен вы можете подключать другие узлы в кластер Docker Swarm.

Также создаётся новая сеть Swarm (internal), благодаря которой контейнеры, размещённые на разных хостах, могут общаться друг с другом.

Помимо всего этого Manager Node создаёт встроенную распределённую базу данных
на основе алгоритма Raft consensus. Это база хранит всё состояние кластера, автоматически синхронизируется с другими узлами Manager Node, обеспечивая консистентность (согласованность) данных. При этом не используется ни etcd, ни Consul, и конечно же эта база шифруется.

Однонодовый Docker Swarm

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

Сперва проверю какие хосты (node) вообще сейчас в кластере. Лидер в кластере может быть только один

docker node ls

ID                            HOSTNAME         STATUS    AVAILABILITY   MANAGER STATUS   ENGINE VERSION
uzypzuxnb5bwte8y34crmsm7n *   c-stream-9-vm4   Ready     Active         Leader           25.0.3

Как я и сказал кластер будет с одним хостом, который у меня также является менеджером. Когда есть хоть один хост в кластере я могу начинать разворачивать сервисы (контейнеры).

Создание сервиса с одной репликой

В Docker Swarm сервис (service) — это основной объект кластера, описывающий что запустить и в каком количестве. По сути это тот же контейнер, но только не один, а группа контейнеров, управляемая Docker Swarm.

Для примера я создам сервис web с образа nginx, команда создания будет очень напоминать команду создания контейнера.

docker service create --name web -p 80:80 nginx

После выполнения команды проверяю что сервис создался и контейнер запущен.

docker service ls

ID             NAME      MODE         REPLICAS   IMAGE          PORTS
lebyjs6me1wq   web       replicated   1/1        nginx:latest   *:80->80/tcp

Важная колонка в выводе выше это REPLICAS, которая у меня равно 1/1. Как я писал выше сервис — это группа контейнеров и задача Docker Swarm в том, чтобы активных контейнеров было столько сколько требуется, и, если что-то происходит с контейнеров Docker Swarm сам пересоздаёт его чтобы добиться установленного количества запущенных контейнеров. Да пример с одним контейнером может и не очень вписывается, но сейчас про базовый минимум, дальше больше.

Команда docker service ls выводит только сервисы, но не контейнеры чтобы просмотреть контейнеры используется docker service ps servicename.

docker service ps web

ID             NAME      IMAGE          NODE             DESIRED STATE   CURRENT STATE            ERROR     PORTS
po9wm3t0jopd   web.1     nginx:latest   c-stream-9-vm4   Running         Running 21 minutes ago

🔍 Разбор колонок

Колонка	Значение
ID	Уникальный идентификатор task внутри Swarm. Это не ID контейнера, а объект уровня оркестрации. Например: `po9wm3t0jopd`.
NAME	Имя задачи в формате `<service>.<replica>`. Здесь `web.1` означает первую реплику сервиса `web`. Если бы `docker service scale web=3`, появились бы `web.2`, `web.3`.
IMAGE	Образ, из которого создаётся контейнер `nginx:latest`.
NODE	Имя узла (нодa), где запущен этот task - `c-stream-9-vm4`, то есть менеджерская (или воркерская) нода кластера.
DESIRED STATE	Желаемое состояние (desired state), которое Swarm хранит в своей Raft-базе. Обычно бывает: • `Running` — контейнер должен работать; • `Shutdown` — контейнер должен быть остановлен.
CURRENT STATE	Фактическое состояние на данный момент. Например: `Running 21 minutes ago`, `Preparing`, `Starting`, `Shutdown`, `Failed`, и т.д. Swarm сам старается привести `CURRENT STATE` к `DESIRED STATE`.
ERROR	Сообщение об ошибке, если задача не смогла стартовать (например, ошибка сети, образа, volume и т.д.). Если пусто, значит всё хорошо.
PORTS	Показывает, какие порты опубликованы (для ingress load balancer).

Создание сервиса с несколькими репликами

Если необходимо создать новый сервис с несколькими репликами, то используется уже знакомая команда docker service create, только с опцией –replicas

docker service create --replicas 3 --name web -p 80:80 nginx

Но в моём случае сервис уже создан и мне необходимо обновить его конфигурацию используя команду docker service scale.

docker service scale web=3
docker service ls

ID             NAME      MODE         REPLICAS   IMAGE          PORTS
lebyjs6me1wq   web       replicated   3/3        nginx:latest   *:80->80/tcp

docker service ps web

ek9stzbp8o5f   web.1       nginx:latest   c-stream-9-vm4   Running         Running 15 minutes ago
mmnfk0ju6zfp   web.2       nginx:latest   c-stream-9-vm4   Running         Running 10 seconds ago
2vya3bqgkmn0   web.3       nginx:latest   c-stream-9-vm4   Running         Running 10 seconds ago

Из вывода видно, что помимо существующего web.1 создались еще два контейнера web.2 и web.3, благодаря чему достигнут необходимый минимум 3/3.

Также можно воспользоваться другой командой docker service update web --replicas 4.

Также выполняя команду docker service scale можно уменьшить количество контейнеров.

Что если удалить контейнер сервиса Docker Swarm

Я рассмотрел, что будет если увеличить количество контейнеров в сервисе, но что произойдёт если удалить контейнер в обход Docker Swarm? Ответ простой: Docker Swarm просто его пересоздаст чтобы выполнить требуемые REPLICAS.

docker ps
docker container rm -f web.2.mmnfk0ju6zfp0ochr6rm474ga
docker service ps web

rf6nnxv6zh03   web.2       nginx:latest   c-stream-9-vm4   Running         Running 24 seconds ago
mmnfk0ju6zfp    \_ web.2   nginx:latest   c-stream-9-vm4   Shutdown        Failed 30 seconds ago     "task: non-zero exit (137)"

Удаление сервиса

Как не трудно догадаться удаление выполняется командой docker service rm.

docker service rm web
docker service ls
docker service ps web

no such service: web

Инфографика

Swarm или Docker Swarm

Thu, 19 Dec 2024 06:20:39 +0600

Если вы уже давно интересуетесь DevOps то вы скорее всего слышали про обычный Swarm, который ставился отдельно и не был частью Docker. Это был отдельный внешний проект (до 2016 г.), представлявший собой менеджер, который соединяет несколько Docker-демонов в кластер. Т.е. это был отдельный бинарник swarm, который управлял демонами Docker через API. Также требовалось внешнее хранилище (Consul, etcd, Zookeeper) для хранения конфигурации. Сейчас обычный Swarm уже не используется и официально переехал в сам продукт Docker.

Docker Swarm mode (или просто Docker Swarm)

Начиная с Docker 1.12 (2016 г.), Swarm встроили прямо в Docker Engine, что упростило использование и конфигурацию Swarm для конечного пользователя.

Было	Стало
Отдельный бинарник `swarm`	Встроено в `dockerd`
Внешний KV-store (etcd/Consul)	Встроенная Raft-база
Простое объединение демонов	Полноценная оркестрация (services, tasks, scaling)
Без встроенной безопасности	Автоматические TLS-сертификаты между нодами
Нет встроенной сети	Overlay-сети, load-balancing и secrets из коробки

Зачем мне Docker Swarm?

Docker Swarm — это встроенная в Docker система оркестрации контейнеров, то есть инструмент, который управляет запуском, масштабированием и отказоустойчивостью множества контейнеров, работающих на нескольких хостах (нодах).

При использовании обычного Docker вы получаете всего один хост с контейнерами, что приводит к потере всего при потере хоста с контейнерами. Docker Swarm — это кластер из многих хостов, действующих как один большой сервер. Соответственно при потере одного из хостов вы не теряете свои контейнеры и приложение продолжает свою работу.

Ключевые задачи, которые решает Docker Swarm:

Veeam - Проверка восстановления (SureBackup)

Tue, 03 Dec 2024 06:20:39 +0600

Первая задача, о которой необходимо задуматься после настройки резервных копий - это настройка проверки восстановления этих резервных копий.

Представим, что вы настроили создание резервных копий, а в час Х оказалось, что восстановить VM из резервной копии не удаётся. Согласитесь, что это будет неприятный сюрприз. И чтобы такого не было необходимо настраивать проверку восстановления. В Veeam Backup & Replication для этого используется # SureBackup.

Задача SureBackup может работать в двух различных режимах:

Полное тестирование восстановления: Veeam Backup & Replication запускает виртуальные машины из резервной копии в изолированной виртуальной среде, для дальнейших тестов проверки работоспособности VM.
Только проверка резервных копий и сканирование содержимого: Veeam Backup & Replication выполняет проверку целостности резервной копии и анализ ее содержимого для обнаружения следов вредоносного ПО или любых других нежелательных или конфиденциальных данных.

Полное тестирование восстановления

В процессе проверки восстановления происходит следующее:

Если настроено задание SureBackup, то будет выполнено сканирование резервных копий на наличие вредоносного ПО с помощью антивирусного ПО.
Veeam Backup & Replication публикует VM из резервной копии в виртуальной изолированной среде — виртуальной лаборатории. VM запускаются напрямую из сжатых и дедуплицированных файлов резервных копий, которые находятся в репозитории резервных копий. Для этого Veeam Backup & Replication использует службу Veeam vPower NFS.
Veeam Backup & Replication выполняет ряд тестов, такие как тест heartbeat, тест ping и тест приложения.
Если задание SureBackup настроено на проверку файлов резервных копий, Veeam Backup & Replication выполняет циклическую проверку избыточности для файла резервной копии, с которого запускается проверяемая машина, и, опционально, для файлов резервной копии, с которых запускаются машины в группе приложений. Проверка файла резервной копии выполняется после завершения всех проверочных тестов
После завершения процесса проверки Veeam Backup & Replication отменяет публикацию VM в изолированной среде и отправляет отчет о процессе по почте администратору резервного копирования.

VMware - Missing dependency vibs error

Mon, 25 Nov 2024 06:20:39 +0600

При обновлении ESXI 6.7 до версии 7.0 получил ошибку Missing dependency vibs error: Found=[‘VMware_bootbank_scsi-qla2xxx_902.k1.1-12vmw.550.3.68.3029944’].

Суть ошибки в том, что в установщике установщик ESXI не может найти дополнительные пакеты для обновления. И рекомендует нам удалить пакет, если он не нужен.

В моём случае пакет VMware_bootbank_scsi-qla2xxx мне действительно не нужен, поэтому я его просто удалю, используя команды:

esxcli software vib list | grep scsi
esxcli software vib remove --vibname=scsi-qla2xxx

Removal Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed:
   VIBs Removed: VMware_bootbank_scsi-qla2xxx_902.k1.1-12vmw.550.3.68.3029944
   VIBs Skipped:

Veeam - Обратное инкрементальное резервное копирование

Mon, 25 Nov 2024 06:20:39 +0600

Метод обратного инкрементального резервного копирования (Reverse Incremental Backup) создаёт цепочку из последней полной резервной копии (VBK) и группы обратных инкрементных резервных копий (VRB).

Процесс создания обратной инкрементной резервной копии выглядит так:

При первом запуске задачи создания резервной копии Veeam Backup & Replication создаёт полную резервную копию (VBK) в репозитории резервных копий
При каждом последующем запуске Veeam Backup & Replication копирует только данные VM, которые были изменены с момента последней резервной копии. Veeam Backup & Replication помещает эти данные в полную резервную копию, чтобы получилась актуальная полная резервная копия. Также эти измененные данные помещаются в файл обратной инкрементальной резервной копии, и добавляет этот файл обратной инкрементальной резервной копии перед файлом полной резервной копии.
После добавления инкрементальной резервной копии в цепочку резервных копий Veeam Backup & Replication проверяет политику хранения и удаляет старые резервные копии, не соответствующие этой политике.

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

Такой подход позволяет вам быстро восстановить актуальное состояние VM без дополнительной обработки, поскольку последняя точка восстановления представляет собой полный файл резервной копии. Если вам необходимо восстановить виртуальную машину на определенный момент времени, Veeam Backup & Replication применяет необходимые файлы VRB к файлу VBK, чтобы получить требуемую точку восстановления.

Чтобы создать задачу создания Обратной инкрементальной резервной копии при создании задачи в расширенных настройках тип резервной копии выбираем Reverse incremental.

VMware - Перенос образа виртуальный машины (VMware vCenter Converter Standalone)

Fri, 22 Nov 2024 06:20:39 +0600

Каким образом вы переносите образы виртуальных машин или сами виртуальные машины с одного сервера Vcenter в другой? Если вы всё делаете вручную, то у меня отличная новость, можно использовать VMware vCenter Converter Standalone.

Установка VMware vCenter Converter Standalone

Качаем установщик с официального сайта по ссылке и устанавливаем. Сам процесс установки расписывать не буду, так как там ничего необычного.

Возможности VMware vCenter Converter Standalone

Используя VMware vCenter Converter Standalone вы можете создать:

образ локальной системы для переноса физического хоста в виртуализацию
конвертировать образ VMware Workstation в образ VMware Vsphere
клонировать виртуальную машину в другой vCenter

Меня интересует именно третий вариант, кстати ещё одно преимущество использования VMware vCenter Converter Standalone - это возможность изменить версию совместимости для клонируемой виртуальной машины.

Клонирование виртуальной машины

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

Запускаем VMware vCenter Converter Standalone и выполняем следующее шаг за шагом:

В левом верхнем углу нажимаем на Convert machine
В открывшемся окне выбираем VMware Infrastructure virtual machine
В том же окне вбиваем параметры доступа к vCenter или ESXI, где находится искомый образ и нажимаем NEXT
Если подключение установлено, то в следующем окне будет список всех VM, где выбираем необходимую VM
В окне Destination system выбираем vCenter или ESXI, куда необходимо склонировать образ (если учетка ограниченная, может не сработать)
В следующем окне выбираем на какой хост, клонировать VM и нажимаем NEXT
В следующем окне выбираем хранилище и также можем указать версию совместимости VM, таблицу можно найти тут
Жмём Next и после нажатия FINISH запускается процесс клонирования

Linux - Аудит sudo команд

Fri, 22 Nov 2024 06:20:39 +0600

По умолчанию все команды, выполненные от sudo записываются в /var/log/secure, помимо sudo в этот файл пишется еще немало других событий. Логично что найти потом кто и что выполнил в куче логов не так просто. Поэтому сконфигурируем ОС так, чтобы логи писались в другой файл, например, /var/log/sudo.

Укажем в какой файл писать события

Для этого отредактируем файл /ets/sudoers и добавим переменную logfile.

sudo visudo

Defaults  logfile=/var/log/sudo

Для выходи из visudo выполните :wq, или нажмите дважды CRTL+Z.

Логирование в одну строку

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

sudo visudo

Defaults  loglinelen=0

Для выходи из visudo выполните :wq, или нажмите дважды CRTL+Z.

Проверка

Теперь, когда всё настроено просто выполняем sudo команду и проверяем что появилось об этом событие в файле /var/log/sudo.

cat /var/log/sudo

Nov 21 10:44:35 : user1 : TTY=pts/0 ; PWD=/home/user1 ; USER=root ; COMMAND=/bin/ls

Настройка filebeat

В качестве агента для отправки событий в elasticsearch я буду использовать filebeat. Писать о том, как его установить я не буду, так как там ничего необычного.

Добавим новый input для filebeat:

sudo vim /etc/filebeat/filebeat.yml

filebeat.inputs:
- type: filestream
 id: "sudo"
 enabled: true
 paths:
 - /var/log/sudo
 fields:
 tag: sudo

sudo systemctl restart filebeat

Grok для pipeline

Для того чтобы разбить событие на поля в Elasticsearch можно воспользоваться pipeline, для этого можно использовать следующий Pattern для Grok:

%{SYSLOGTIMESTAMP:system.syslog.timestamp} : %{USERNAME:sudo.user} : TTY=%{NOTSPACE:sudo.tty} ; PWD=%{NOTSPACE:sudo.pwd} ; USER=%{USERNAME:sudo.userbecome} ; COMMAND=%{GREEDYDATA:sudo.command}|%{SYSLOGTIMESTAMP:system.syslog.timestamp} : %{USERNAME:sudo.user} : %{GREEDYDATA:sudo.allow} ; TTY=%{NOTSPACE:sudo.tty} ; PWD=%{NOTSPACE:sudo.pwd} ; USER=%{USERNAME:sudo.userbecome} ; COMMAND=%{GREEDYDATA:sudo.command}

FreeIpa - Мониторинг действий пользователя

Fri, 22 Nov 2024 06:20:39 +0600

В моём случае я использую связку filebeat + elasticsearch. Все события, связанные с действиями пользователей я беру в файле /var/log/httpd/error_log.

В этом файле очень много событий, но меня интересовали события содержащие слова:

user_add - добавление пользователя
user_mod - редактирование пользователя
passwd - изменение пароля
sudorule_add_user - добавление пользователя в группу sudo
user_del - удаление пользователя
group_add - создание группы
group_mod - редактирование группы
group_del - удаление группы
group_add_member - добавление пользователя в группу
session_logout - выход
whoami - по умолчанию не нашёл события для входа и использую это слово
Unauthorized - неудачные попытки входа

Конфигурация filebeat

На сервере где стоит FreeIpa редактируем файл конфигурации filebeat и добавляем новый input. Установку самого filebeat я опущу так как там ничего необычного.

sudo vim /etc/filebeat/filebeat.yml

filebeat.inputs:
- type: filestream
  id: "ipaamd"
  enabled: true
  paths:                                                                                                                                             - /var/log/httpd/error_log                                                                                                                     fields:                                                                                                                                            tag: ipaamd                                                                                                                              include_lines: ['user_add', 'user_find', 'user_mod', 'passwd', 'sudorule_add_user', 'user_del', 'group_add', 'group_find', 'group_mod', 'group_del', 'group_add_member', 'session_logout', 'whoami', 'Unauthorized']

sudo systemctl restart filebeat

Veeam - Vcenter the remote certificate is invalid according to the validation procedure

Thu, 07 Nov 2024 06:20:39 +0600

Ошибка может появиться если вы обновили сертификат на Vcenter. Когда мы добавляем Vcenter в Veeam он импортирует этот сертификат себе. Соответственно нового сертификата у него нет, и нам нужно заставить Veeam его получить.

Решение

Просто переходим в Inventory, нажимаем правой кнопкой на необходимом Vcenter и выбираем Properties.
Просто жмём везде Next, и во время запроса о сертификате нажимаем Import

Vcenter - Создаём свой собственный образ

Thu, 07 Nov 2024 06:20:39 +0600

Время от времени приходится обновлять esxi со старой версии на более новую и бывает, что в новом образе нет того или иного пакета. Например, в моём случае я наткнулся на ошибку: The upgrade has VIBs that are missing dependencies: EMU_bootbank_scsi-be2iscsi_12.0.1108.0-1OEM.600.0.0.2494585.

Включаем Auto Deploy и Image Builder

Авторизуемся в Vcenter и переходим в Auto Deploy, где нажимаем Enable Auto Deploy and Image Builder.

Добавляем наш образ

Важное замечание что мы добавляем не iso образ, а архив с пакетами (Offline Bundle), обычно он доступен к загрузке там же где и основной образ. Для этого переходим в Auto Deploy и во вкладке Software Depot выбираем Import.

Добавляем необходимый пакет

Для начала конечно же нужно найти необходимый пакет, в моём случае я его нашёл тут. Всё классно, но вот добавить я могу только архив в Software Depot.

Первое что я сделал это конечно просто запаковал пакет в архив, но при импорте получил ошибку. Потом я попробовал добавить пакет в существующий архив (который импортировал выше), но при импорте снова получил ошибку.

В итоге по url ссылке я понял что пакет EMU_bootbank_scsi-be2iscsi находится в образу esxi 6.0 от HP. Я выкачал VMware-ESXi-6.0.0-Update1-3073146-HP-600.9.4.34-Nov2015-depot и также импортировал его как описывал выше.

В итоге в Software Depot у меня:

Lenovo_ESXi6.5a_20170217 - тот что я хочу поставить на хост
HP-ESXi-6.0.0-Update1-600.9.4.34 - отсюда мне нужен только пакет EMU_bootbank_scsi-be2iscsi

Создаём свой профиль образа

Для этого в Software Depot создаём новый Depot (NEW>Custom Depot)
Выбираем Software Depot созданный в самом начале и нажимаем CLONE
Выбираем наш Software depot
Дополнительно ставим галочки для пакетов, которые нужно дополнительно добавить
Нажимаем FINISH
Можно сравнить количество пакетов в обоих образах

Экспортируем образ

Далее выбираем наш профиль образа и нажимаем EXPORT.

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

Vcenter - Создание vm из шаблона зависает на 94%

Wed, 23 Oct 2024 06:20:39 +0600

Проблема скорее всего в том, что у вас просрочен пароль на root пользователя. Как вариант пробуем зайти по ssh и обновить пароль, не лишним будет перезагрузить Vcenter.

В логах /var/log/vmware/vsm/vsm.log будут записи:

`YYYY-MM-DDTHH:mm:ss INFO [Thread-4] ServiceUtil.java 142 - Password expired. Resetting service account password`

`YYYY-MM-DDTHH:mm:ss ERROR VsmActivationValidator.java 267 - Failed to validate user: only vpxd-svc-acct requests allowed and not`

Также чтобы в будущем такого не случалось обновляемся до vCenter 8.0 U2b.

Ещё одна возможная причина это просроченный сертификат.

Vagrant - Разворачиваем виртуальные сервера на VirtualBox

Mon, 14 Oct 2024 06:20:39 +0600

Используя Vagrant вы ускоряете процесс создания виртуальных машин на многих платформах виртуализации, например Hyper-V, Virtualbox и т.д.

Установка / Провайдер / Создание VM / Файл конфигурации / Запуск VM / Подключение по ssh / Обновление конфигурации / Удаление VM / Копирование файлов / Запуск скриптов /

Установка Vagrant

По ссылке всегда можно получить свежую информацию о установке на различные ОС.

#Centos
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install vagrant

#Ubuntu
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install vagrant

Для Windows как обычно качаем файл установки и устанавливаем.

После установки проверяем что Vagrant работает:

vagrant --version

Vagrant 2.4.1

Провайдер по умолчанию

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

Делается это несложно просто через переменную VAGRANT_DEFAULT_PROVIDER указываем какой провайдер использовать. Либо можно при вызове команд передавать провайдера через опцию --provider.

И ещё одно замечание на момент написания статьи Vagrant не работает с VirtualBox 7.1.0.

The box you’re attempting to add doesn’t support the provider you requested

Если вы видите эту ошибку значит вы хотите использовать образ, предназначенный для другого провайдера, например, VirtualBox вместо Hyper-V. Чтобы такого не было при поиске образа сортируйте их по провайдерам.

Создание виртуальной машины с помощью Vagrant

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

Также можно выкачать шаблон по любой доступной ссылке в интернете:

Vagrant.configure("2") do |config|
  config.vm.box =  "centos/9"
  config.vm.box_url =  "https://cloud.centos.org/centos/9-stream/x86_64/images/CentOS-Stream-Vagrant-9-latest.x86_64.vagrant-virtualbox.box"
end

Для начала необходимо создать файл конфигурации, т.е. Vagrant файл, где уже необходимо описать всю конфигурацию виртуального сервера. Я буду использовать образ centos/stream9.

vagrant.exe init roboxes/centos9s

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

Весь конфиг помещается внутри блока Vagrant.configure("2") do |config|, эта строка означает старт файла конфигурации.

Базовый файл конфигурации

Вот примерный файл конфигурации:

Vagrant.configure("2") do |config|
  config.vm.box =  "roboxes/centos9s"
  config.vm.hostname =  "just-for-test-centos"
  config.vm.box_check_update = false
  config.vbguest.auto_update =  false
  config.vm.provider "virtualbox" do |vb|
	vb.name =  "just_test"
	vb.cpus =  "4"
	vb.memory =  "4096"
  end
end

config.vm.box - тут собственно указываем шаблон для VM
vb.name - имя VM (в самом VirtualBox)
vb.cpus - сколько cpu выдать для VM
vb.memory - сколько выдать ОЗУ для VM (в мб)
config.vm.hostname - имя сервера, в самой ОС
config.vm.box_check_update - при создании VM по умолчанию происходит установка обновлений, если стоит true
config.vbguest.auto_update - устанавливать гостевые дополнения Virtualbox или нет

Старт VM

Для запуска процесса создания нужно выполнить vagrant up. Если вы выполняете команду впервые, то потребуется какое-то время для скачивания образа.

Эта команда создаёт и настраивает будущую виртуальную машину, приводя её к тому состоянию, которое описано в файле конфигурации.

Для применения дальнейших изменений можно использовать vagrant reload, о которой чуть ниже.

Подключение по ssh

По умолчанию создаётся пара, открытого и закрытого ключей для авторизации по ssh. И самым простым вариантом для авторизации на виртуальной машине будет использовать команду vagrant ssh.

Если у вас несколько виртуальных машин в файле конфигурации, то необходимо передать имя.

Обновление конфигурации VM

Если необходимо что-то изменить на уже созданной VM используется команда vagrant reload.

Vagrant.configure("2") do |config|
  config.vm.box =  "roboxes/centos9s"
  config.vm.hostname =  "just-for-test"
  config.vm.box_check_update = false
  config.vm.provider "virtualbox" do |vb|
	vb.name =  "just_test"
	vb.cpus =  "2"
	vb.memory =  "4096"
  end
end

vagrant reload

Команда vagrant reload может принимать дополнительную опцию, одну из:

–provision - когда мы делаем reload применяются не все изменение в файле Vagrantfile. Чтобы применились все изменения нужно добавить --provision (скрипты и т.д.)
–no-provision - применить только некоторые параметры конфигурации, такие как сетевые настройки, конфигурация VM (скрипты запускаются только если стоит always)
–provision-with - указывает какой именно тип запускать, например shell или file

Удаление VM

Чтобы удалить уже созданную VM используется команда vagrant destroy.

Копирование файлов в VM

Можно скопировать файлы в будущую VM добавив файл Vagrantfile одну из следующих строк:

config.vm.provision "file", source: "./scripts/copy.txt ", destination: "/tmp/copy.txt" #one file
config.vm.provision "file", source: "./scripts ", destination: "/tmp/remote" #folder

==> default: Running provisioner: file...
    default: ./scripts  => /tmp/remote

Если нужно скопировать файлы в уже созданную VM используем vagrant upload.

vagrant upload .\scripts\copy.txt /tmp/copy.txt

Uploading .\scripts\copy.txt to /tmp/copy.txt
Upload has completed successfully!

  Source: .\scripts\copy.txt
  Destination: /tmp/copy.txt

Но обратите внимание если по каким-то причинам у вас не установились гостевые дополнения Virtualbox первый вариант может не сработать.

Запуск скриптов внутри VM

Если нужно запустить скрипты при создании VM используем provision.

Vagrant.configure("2") do |config|
  config.vm.provision "shell", path: "./scripts/just_test.sh"
  config.vm.provision "shell", path: "./scripts/just_test2.sh", run: 'always'
end

Первый скрипт just_test.sh выполнится только при создании VM (up или reload –provision), второй будет выполнятся даже если запустить reload без provision.

Если нужно запустить только скрипты можно также воспользоваться vagrant reload --provision-with shell.

Linux - Восстановление удалённого раздела

Mon, 07 Oct 2024 06:20:39 +0600

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

Так вот для начала нам необходимо установить TestDisk.

sudo apt-get install testdisk   # Debian/Ubuntu
sudo yum install epel-release	# CentOS/RHEL
sudo yum install testdisk       # CentOS/RHEL

wget https://www.cgsecurity.org/testdisk-7.3-WIP.linux26-x86_64.tar.bz2

После установки запускаем утилиту и передаём наш диск, где удалили раздел.

sudo testdisk /dev/sdb

Нажимаем Enter
Выбираем тип таблицы разделов, как правило это Intel или EFI GPT (sudo fdisk -l /dev/sdb)
Выбираем Analyse и нажимаем Enter
Снова нажимаем Enter для быстрого сканирования (Quick Search)
После сканирования у нас появляется наш удалённый раздел, выбираем его и снова нажимаем Enter
Выбираем Write и нажимаем Enter

Проверяем что раздел появился

sudo fdisk -l /dev/sdb

Device     Start      End  Sectors Size Type
/dev/sdb1   2048 41940991 41938944  20G Linux filesystem

Перезагружаемся, как было рекомендовано

MinIO - Загружаем файл используя dotnet

Wed, 25 Sep 2024 06:20:39 +0600

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

Так вот я решил накатать простое приложение, которое просто загрузит файл в корзину на его глазах и соответственно я могу отправить его смотреть свой код.

Установка dotnet

Для windows:

 winget install Microsoft.DotNet.SDK.8
 winget install Microsoft.DotNet.AspNetCore.8
 winget install Microsoft.DotNet.DesktopRuntime.8

Подготовка

dotnet new console -n FileUploader
dotnet add package Minio

Меняем содержимое файла Program.cs на:

using Minio;
using Minio.Exceptions;
using Minio.DataModel.Args;

namespace FileUploader
{
    class FileUpload
    {
        static void Main(string[] args)
        {
            var endpoint  = "minio-host";
            var accessKey = "user";
            var secretKey = "pwd";
            try
            {
                var minio = new MinioClient()
                                    .WithEndpoint(endpoint)
                                    .WithCredentials(accessKey, secretKey)
                                    .WithSSL()
                                    .Build();
                FileUpload.Run(minio).Wait();
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }
            Console.ReadLine();
        }

        // File uploader task.
        private async static Task Run(IMinioClient minio)
        {
            var bucketName = "bucket";
            var objectName = "noPmem.log";
            var filePath = "C:\\Users\\user\\Downloads\\noPmem.log"; // Change this path
            var contentType = "application/zip";

            try
            {
                // Make a bucket on the server, if not already present.
                var beArgs = new BucketExistsArgs()
                    .WithBucket(bucketName);
                bool found = await minio.BucketExistsAsync(beArgs).ConfigureAwait(false);
                if (!found)
                {
                    var mbArgs = new MakeBucketArgs()
                        .WithBucket(bucketName);
                    await minio.MakeBucketAsync(mbArgs).ConfigureAwait(false);
                }
                // Upload a file to bucket.
                var putObjectArgs = new PutObjectArgs()
                    .WithBucket(bucketName)
                    .WithObject(objectName)
                    .WithFileName(filePath)
                    .WithContentType(contentType);
                await minio.PutObjectAsync(putObjectArgs).ConfigureAwait(false);
                Console.WriteLine("Successfully uploaded " + objectName);
            }
            catch (MinioException e)
            {
                Console.WriteLine("File Upload Error: {0}", e.Message);
            }
        }
    }
}

Запуск

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

dotnet build
dotnet run

Successfully uploaded noPmem.log

K8s - Сборка docker образа

Wed, 18 Sep 2024 06:20:39 +0600

Docker образ используется для создания контейнеров в контейнеризации, включает в себя легковесную ОС и необходимые файлы для работы конкретного приложения. Каждый созданный кем-либо контейнер использует тот или иной Docker образ. По сути Docker образ — это снимок ОС с вшитыми библиотеками, необходимыми для работы конкретного приложения. Например, вы хотите развернуть приложение, работающее на python. Соответственно вы просто используете Docker образ с python, не тратя особого времени на его установку в основную ОС.

Образы можно хранить и перемещать локально или же использовать репозитории, которые могут быть как публичными, так и приватными. Самый распространённый публичный репозиторий - docker hub.

Структура Docker образа

Давайте разберём из чего состоит Docker образ (Dockerfile):

Самое первое это базовый образ (Base Image), т.е. по сути это ОС, но только урезанная. Например, alpine, ubuntu, python:3.9-slim.
Каждый Docker образ состоит из слоёв. Каждый слой представляет из себя изменения, которые применяются поверх базового образа (Base Image). Т.е. если в образ включить установку нового пакета, которого нет в базовом образе, то установка этого пакета создаст новый слой.
Если мы говорим о контейнеризации в разработке, то конечно же контейнер будет содержать код приложения, написанный разработчиком.
Почти все приложения имеют свои файлы конфигураций, которые также содержатся в самом Docker образе.
Ну и куда же без информации о самом образе, т.е. метаданные образа.

Пример слоев в Docker образе

Как я уже сказал любое изменение в создаваемом образе приведёт к созданию нового слоя. В итоге после создания образа у вас получится большой слоённый бутерброд. Кстати для просмотра слоёв и вообще информации о существующем образе можно воспользоваться утилитой dive.

Когда вы выполняете команду docker build в выводе можно просмотреть сколько в итоге создалось слоёв в вашем образе.

docker build . -t myapp:1.7

=> [1/4] FROM docker.io/library/python:3.9-slim@sha256:2851c06da1fdc3c451784beef8aa31d1a313d8e3fc122e4a1891085a104b7cfb 
CACHED [2/4] WORKDIR /app 
CACHED [3/4] COPY osapp/. .  
CACHED [4/4] RUN pip install -r requirements.txt

Также рекомендую посмотреть слои какого-нибудь готового образа на dockerhub, например nginx:1.27.1-alpine-perl.

Как создать свой собственный Docker образ

Конечно это хорошо просто скачивать уже созданные кем-то Docker образы с публичных репозиториев, но рано или поздно придётся создать свой собственный. Рассмотрим пример создания Docker образа для приложения, написанного на python. Это простенькое приложение, которое пытается получить доступ к сайту и выводит http responce. Скачать все необходимые файлы для воссоздания можно тут.

Для этого я создам файл Dockerfile и впишу следующее:

Как я описывал выше каждый образ начинается с базового образа (Base Image). Также рекомендуется указывать тэг образа, т.е. конкретную версию образа и использовать максимально облегченный образ используя инструкцию FROM.
```
FROM python:3.9-slim
```
Понятное дело, что запускать файлы из корня контейнера не стоит, поэтому мы будем использовать директорию /app внутри образа. Используя инструкцию WORKDIR укажем текущую директорию /app. Т.е. всё что, мы будем выполнять при создании образа дальше будет выполняться в директории /app самого образа.
```
WORKDIR /app
```
Как несложно догадаться если есть файл приложения, то его нужно скопировать в наш новый Docker образ. Поэтому скопируем все файлы с директории osapp в самой хостовой ОС в текущую директорию образа, используя инструкцию COPY. Кстати так как наш базовый образ с добавлением файлов по сути изменился отсюда добавился новый слой.
```
COPY osapp/. .
```
Наш python скрипт использует библиотеку requests, которая по умолчанию не стоит в базовом образе python:3.9-slim. Соответственно нам надо её установить и для этого при создании нового образа должна запуститься команда установки зависимостей pip install -r requirements.txt. В шаге выше мы скопировали все файлы с osapp в корневую директорию /app образа, в том числе requirements.txt.
```
RUN pip install -r /app/requirements.txt
```
Ну и последний шаг это уже запуск нашего приложения, используя инструкцию CMD. Но эта команда уже выполнится, когда мы запустим сам контейнер.
```
CMD ["python","pyfile.py"]
```
После того как файл Dockerfile готов мы можем запускать процесс создания нашего собственного Docker образа.
```
docker build . -t myapp:1.0
```
Для проверки того что у нас получилось пробуем запустить сам контейнер.
```
docker run myapp:1.0
```

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

Чтобы просмотреть какие вообще образы присутствуют в вашей ОС можно воспользоваться командой docker images

Метаданные Docker образа

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

Для этого в файл Dockerfile добавляем, например, такую строку:

LABEL maintainer="main@example.com" \ version="1.0" \ description="This is a Python application that try to access an url and return responce code." \ license="MIT"

Для того чтобы просмотреть метаданные того или иного образа можно воспользоваться командой docker image inspect myapp:1.0 | jq .[0].Config.Labels.

Переменные в Docker образе

Для указания переменных в образе используется 2 инструкции: ARG и ENV. Конечно же если их несколько значит есть отличия.

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

ENV APP_PORT=8080

Инструкция ARG в свою очередь объявляет переменную, которую вы можете использовать только внутри образа, во время его создания.

ARG APP_ARG=production
ENV APP_ENV=$APP_ARG

Если нужно присвоить значение со знаками пробелами, то используем один из следующих вариантов:

ENV APP_ARG="Must be production"
ENV APP_ARG=Must\ be\ production

Команда сборки Docker образа

Как мы уже поняли из текста выше сборка образа осуществляется командой docker build. Через опцию -t мы присваиваем тэг нашему образу, если просто, то это имя и версия нашего образа. Например, чтобы собрать образ с именем nginx и версией 1.0 мы выполняем команду docker build . -t nginx:1.0.

Для того, чтобы выполнить сборку образа в текущей директории должен присутствовать файл Dockerfile, с описанием нашего образа. Если же вы по каким-то причинам не хотите использовать стандартное имя для файла Dockerfile, можете назвать его иначе. Но тогда команда сборки образа будет выглядеть так: docker build --tag myapp:1.1 --file './filename' .

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

docker build . -t myapp:1.1
docker build . -t myapp:1.1
docker images

myapp    1.1       d2daa12adee5   13 minutes ago   125MB
<none>     <none>    f082ea0fb51f   16 minutes ago   125MB

Чтобы удалить все безымянные образы можно воспользоваться командой docker rmi $(docker images -f "dangling=true" -q).

Copy или Add

Для копирования файлов при сборке контейнера можно воспользоваться двумя инструкциями: ADD и COPY, ну и конечно есть в них различия.

Инструкцию ADD рекомендуется использовать если вы хотите скопировать в контейнер файлы по HTTPS или с Github. Также если вы копируете архив, он автоматически будет разархивирован.

В остальных же случаях просто используем инструкцию COPY.

Инструкция для запуска приложения ENTRYPOINT, CMD

В идеале инструкция для запуска приложения помещается в последнюю строку файла Dockerfile. CMD устанавливает команду, которая будет выполняться при запуске контейнера из образа и имеет следующий синтаксис CMD ["executable","param1","param2"]. Если вы вдруг решите использовать несколько CMD в одном Dockerfile, эффект даст только последняя команда.

Инструкция ENTRYPOINT делает по сути тоже самое, но в неё рекомендуется помещать только, те команды, которые не должны меняться, например, контейнер в любом случае должен запустить определённый файл, соответственно можно поместить команду в ENTRYPOINT.

ENTRYPOINT ["python"]
CMD ["--help"]

Используя ENTRYPOINT, вы указываете какой процесс должен запускаться при старте контейнера. CMD же нужен для того, чтобы передать параметры по умолчанию для процесса. Также, когда вы запускаете вы можете передать свои значения для CMD, т.е. заменить параметры по умолчанию, которые прописаны в Dockerfile.

docker run myapp:1.2
docker run myapp:1.2 --version

Инструкция EXPOSE

Конечно если мы говорим об образе для веб-приложения, то нам нужно порт, через который мы сможем получить доступ к приложение из вне. Для того, чтобы указать какой порт будет использоваться в образе используется EXPOSE.

EXPOSE 80/tcp

Инструкция RUN

Мы используем RUN для того, чтобы выполнять команды при сборке образа. Например, установить обновления на базовый образ, или установить новые пакеты в новый образ.

RUN apt-get update && apt-get install -y curl

Инструкция USER

Вы как пользователь Linux уже ни раз слышали, что не стоит запускать сервисы от root, для контейнеров используется тоже правило. Для того чтобы запустить сервис в контейнере от другого пользователя используется инструкция USER.

USER patrick

Многоэтапная сборка Docker образа

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

FROM golang:1.22-alpine3.20 as build
WORKDIR /app
RUN echo "print('Hello')" >> mypython.py

FROM python:3.9-slim
WORKDIR /myapp
COPY --from=build /app/mypython.py .
CMD ["python", "mypython.py"]

docker build . -t mymulti:1.0
docker run --rm mymulti:1.0

Hello

Обновление Docker образа и кэш

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

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

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

docker build . -t mymulti:1.1

CACHED [stage-1 4/4] RUN apt-get update

docker build --no-cache . -t mymulti:1.1

[stage-1 4/4] RUN apt-get update

В итоге

Все инструкции (конфигурации) для будущего образа задаются в файле Dockerfile
Dockerfile начинается с базового образа (from)
Всегда указывайте определённые версии базового образа, пакетов, зависимостей
Старайтесь максимально уменьшить размер вашего образа (повысить время выкладки приложения)
Используйте COPY вместо ADD
Используйте ENTRYPOINT в связке с CMD

Kubernetes - Архитектура

Wed, 18 Sep 2024 06:20:39 +0600

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

Самое первое что нужно запомнить про Kubernetes это то что система считается распределённой, т.е. множество компонентов размещены на разных узлах (устройствах). Эти узлы могут быть как виртуальными, так и физическими, но лучше конечно физические. Всё это вместе называется кластером Kubernetes, который изображён на схеме ниже.

Как вы уже догадались из схемы выше каждый кластер Kubernetes состоит из рабочих узлов (worker nodes) и узлов управления (control plane nodes).

Рассмотрим поподробнее каждый из типов узлов.

Рабочий узел (worker node)

Для начала давайте разберёмся что такое под (pod) в Kubernetes, потому как слышать это слово вы будете часто. Под — это абстрактный объект Kubernetes, представляющий собой группу из одного или нескольких контейнеров приложения.

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

Рабочий узел (worker node) имеет следующие компоненты:

kubelet
Container runtime
kube-proxy

На рабочий узел (worker node) возлагаются следующие функции:

Конечно же самый первый и основной - это запуск контейнеров
Выдача ip адресов
Управление хранилищем данных
Распределение ресурсов

В итоге получается, что Kubernetes запускает ваше приложение помещая контейнеры в поды на рабочих узлах (worker nodes).

Имя рабочего узла (worker node name)

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

Узел управления (control plane node)

Узел управления (control plane node) отвечает за управление контейнерами и также поддерживание рабочего состояния кластера, также может использоваться название Master Node. В кластере может быть несколько узлов управления, и каждый узел управления имеет следующие компоненты:

kube-apiserver
kube-scheduler
kube-controller-manager
etcd
cloud-controller-manager

Компоненты рабочего узла (worker node components)

Конечно же мы просто обязаны теперь рассмотреть все компоненты по порядку.

Kubelet

Kubelet - это агент, который запущен на каждом рабочем узле (worker node) как демон в системе, управляемый systemd. Этот демон отвечает за регистрацию всех рабочих узлов в кластере, используя при этом kube-apiserver. Также, когда говорим о Kubelet стоит упомянуть и о podSpec (спецификация подов). Это YAML или JSON файл, в котором указывается какие контейнеры должны быть запущены на конкретном узле, а также их характеристики, такие как ЦПУ, ОЗУ и т.д. Этот файл в первую очередь рабочие узлы получают от kube-apiserver через нашего героя - Kubelet.

Также Kubelet используется для отслеживания состояния подов и работы с системой контейнеризации, например, скачивание образов, создание или удаление контейнеров.

Вот за что отвечает Kubelet:

Создание, удаление и модификация контейнеров
Отвечает за монтирование томов для подов
Сбор и предоставление данных о состоянии узлов и подов

Помимо kube-apiserver спецификацию подов (podSpec) Kubelet может получить и из файла по HTTP. Используется для статических подов в Kubernetes (Kubernetes static pods). Такие поды контролируются конкретно Kubelet, не с помощью kube-apiserver.

Ещё немного фактов о Kubelet:

Использует CRI (container runtime interface), который используется для работы с контейнеризацией
Использует CSI (container storage interface) для конфигурации блочных томов
Используя протокол HTTP предоставляет возможность трансляции логов
Используя плагин CNI для назначения подам ip-адресов, настройки файрволла и необходимых роутов

После всего изложенного про Kubelet получаем следующую схему:

Kube proxy

Тут будет немного посложнее, для начала давайте разберёмся что такое сервис в Kubernetes . Под сервисом подразумевается какое-то количество подов собранные в одну группу. Также благодаря сервису поды получают внутренний или внешний трафик. Когда вы создаёте сервис он получает виртуальный ip-адрес, также называемый clusterIP. Этот виртуальный ip-адрес доступен только внутри кластера Kubernetes.

Объект Endpoint содержит все IP-адреса и порты подов в рамках объекта Service. Контроллер Endpoint отвечает за ведение списка IP-адресов подов (конечных точек). Контроллер сервиса отвечает за настройку конечных точек службы.

Последнее что еще нужно знать это то, что вы не сможете пропинговать clusterIP, но сможете пропинговать ip-адреса подов.

Теперь наконец-то про Kube proxy. Kube proxy - это демон, который запущен на каждом рабочем узле. Это прокси компонент, благодаря которому возможно использование сервисов Kubernetes. Он в основном проксирует UDP, TCP и SCTP для подов и не понимает HTTP.

Если просто, то благодаря Kube proxy при обращении к сервису (clusterIP) создаются правила, благодаря которым через виртуальный ip-адрес сервиса доступ предоставляется к ip-адресам подов. Поэтому и называется прокси.

Kube proxy обращается к kube-apiserver для получения данных о сервисе (clusterIP) и о ip-адресах, портах для подов. Конечно при изменении этих данных он сразу же применяет их.

Для перенаправления трафика Kube proxy может использовать одну из следующих технологий:

IPTables: Знакомая штука для любителей Linux, которая используется в Kube proxy по умолчанию. Для каждого сервиса создаются свои правила IPTables. Благодаря этим правилам весь трафик приходящий на clusterIP перенаправляется на нужный под. Какому из подов перенаправить трафик выбирается случайным образом. После выбора весь последующий трафик будет перенаправляется именно выбранному поду, пока он не станет недоступным (сам под).
IPVS: Думаю, что использовать этот тип будут не многие, так как его рекомендуется использовать если у вас вдруг в кластере Kubernetes используется более 1000 сервисов.
Kernelspace: Используется только в Windows
nftables: это преемник IPtables, который разработан, чтобы упростить работу и повысить эффективность. Но необходимо проверить вышел ли он из стадии Альфа-функции

Container Runtime

Container Runtime - это программный компонент, необходимый для запуска контейнеров. Этот компонент собственно отвечает за любые манипуляции с контейнерами, например, создание контейнера, скачивание образов и т.д.

В качестве среды контейнеризации может использоваться CRI-O, Docker Engine, containerd, Mirantis Container Runtime. Среда контейнеризации для Kubernetes должна быть совместима с Container Runtime Interface (CRI). Это значит что среда контейнеризации должна иметь интерфейс CRI и поддерживать CRI APIs.

Также мы уже знаем, что благодаря Kubelet есть список того какие контейнеры нам нужно запустить и с каким характеристиками. Этап создания этих контейнеров выглядит так:

Когда поступает запрос на под от kube-apiserver, kubelet обращается к демону среды контейнеризации, чтобы запустить необходимые контейнеры через интерфейс CRI.
Среда контейнеризации запускает эти контейнеры

Компоненты узла управления (control plane node components)

И конечно же рассмотрим все компоненты узла управления.

kube-apiserver

Самый главный компонент в кластере Kubernetes, который предоставляет собственно api для Kubernetes. Считается хорошо масштабируемым и высокопроизводительным одновременно.

Чаще всего к kube-apiserver обращается конечный пользователь и другие компоненты кластера, например, Kubelet. Изредка к нему также могут подключаться разные системы мониторинга, если вы их настроили конечно.

Когда вы используете утилиту kubectl для управления кластера вы по сути работаете с kube-apiserver через HTTP REST APIs, только в удобном для вас виде. Каждая ваша команда, выполняемая через kubectl преобразуется в запросы, которые уже в последствии обрабатывает kube-apiserver.

Дальше сам kube-apiserver обращается к другим компонентом для выполнения команд. Коммуникация между kube-apiserver и другими компонентами происходит через TLS соединения.

Компонент kube-apiserver также имеет свой прокси (apiserver proxy), который используется для доступа к ClusterIP из-за пределов кластера.

Kube-apiserver в кластере Kubernetes отвечает за следующее:

Управление API: выступает в роли шлюза для всех API запросов
Аутентификация и Авторизация: предоставляет услуги аутентификации для всех компонентов в кластере используя сертификаты, токены и HTTP-аутентификацию
Обработка API запросов
Также является единственным компонентом, который обращается к etcd
Занимается координацией всех процессов между компонентами узла управления и компонентами рабочего узла

Кстати у kube-apiserver есть функция которая даёт вам возможность писать свой собственный API, подробнее тут.

Когда вы создайте сервер, на котором будет расположен kube-apiserver задумайтесь о его безопасности, как минимум это не должен быть сервер с доступом к нему из вне. Иначе можете оказаться в таком вот неудачном списке.

etcd

По сути является базой данных в кластере Kubernetes. Так как сам Kubernetes является распределённой системой, что-то общее между узлами всё-таки должно быть. Etcd используется как средство обнаружения служб и база данных.

Сам etcd является open-source приложением, выступающим как хранилище для данных типа ключ-значение.

В Kubernetes он используется потому что обладает следующими функциями:

Гарантированная доставка: Если какое-то обновление выполнено на одному узлу, оно точно будет доставлено всем другим узлам в сети
Раздельность: предназначен для работы на нескольких узлах в виде кластера
Алгоритм raft: etcd использует алгоритм консенсуса raft для обеспечения строгой согласованности и доступности. Для примера компонент orderer в hyperledger fabric тоже использует этот алгоритм.

Когда вы используете kubectl для просмотра каких-то данных в кластере Kubernetes вы по сути вытаскиваете эти данные из etcd. Также, когда вы запускаете новые поды информация о них, помещается и хранится в etcd.

Вот что ещё будет не лишним знать о etcd:

etcd хранит все конфигурации, статусы и метаданные каждого объекта в кластере Kubernetes
когда вы используете метод Watch() через API ответ вы также получаете из данных, которые хранятся в etcd
etcd как и многие сервисы предоставляет свой API для работы с ним, который конечно же использует kube-apiserver
все объекты в кластере etcd по умолчанию хранит в директории /registry

kube-scheduler

kubik-kube-scheduler.drawio.png

Основная задача kube-scheduler является планирование запуска подов на рабочих узлах (worker nodes). При развертывании пода вы указываете требования к процессору, памяти и другим характеристикам пода kube-scheduler обрабатывает ваш запрос и выбирает самый лучший для этого рабочий узел, который соответствует требованиям.

Отсюда возникает логичный вопрос как именно он определяет какой рабочий узел использовать? Для того чтобы выбрать подходящий узел kube-scheduler использует операции фильтрации и оценки.

Используя фильтрацию он находит подходящие узлы, на которых можно разместить поды. Если вдруг у вас несколько подходящих узлов, то он выберет все. Если же нет ни одного подходящего узла, то поды останутся висеть в очереди на размещение.
После фильтрации запускается процесс оценки, в котором оценивается насколько тот или иной узел соответствует характеристикам подов. Если у вас слишком большой кластер, то этот процесс может занять какое-то время. Параметр percentageOfNodesToScore задаёт минимальное количество узлов в кластере для оценки в процентном соотношении. По умолчанию это 50%, но если кластер очень большой, то это значение равняется 5%.
В итоге узел с самым большим рангом будет выбран для размещения подов. Если же найдётся несколько узлов с одинаковыми рангами, то выберется первый случайный.
После выбора узла kube-scheduler создаёт заявку сопоставления узла и подов на kube-apiserver

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

Kube Controller Manager

Kube Controller Manager необходим для мониторинга состояния вашего кластера, является основным компонентом в control plane. Он запускает процессы контроллеров, которые необходимы для выполнения рутинных операций, гарантируя, что текущее состояние кластера соответствует желаемому состоянию, указанному пользователем. Kube Controller Manager также управляется kube-scheduler.

Для того чтобы понять получше необходимость в Kube Controller Manager представим пример, где вы решили развернуть кластер с двумя репликами, одним общим хранилищем и т.д. Встроенный контроллер в Kube Controller Manager (Deployment Controller) гарантирует что будет создано две реплики, и если вдруг вы решите увеличить количество реплик, то он также сделает это ради вас.

Вот список некоторых особо важных контроллеров:

Node Controller: отвечает за процесс мониторинга активности узла. Если вдруг узел не отвечает, то Node Controller оповещает об этом. Если же узел недоступен какое-то время, то запускается процесс пересоздания подов на другом узле.
Replication Controller: собственно, отвечает за соблюдение настроек репликации
Service Account & Token Controllers: Отвечает за учетные записи по умолчанию и токены доступа к API
Deployment Controller: Отвечает за управление жизненным циклом развертываний, обеспечивая соответствие параметрам, заданным пользователем.

Для соблюдения отказоустойчивости в вашем кластере должно быть несколько узлов с компонентом Kube Controller Manager.

Мы также не лишены возможности создавать свои собственные контроллеры, но об этом не в этой статье.

Cloud Controller Manager (CCM)

Вы уже наверняка знаете, что почти все популярные облачные сервисы предоставляют возможность использования Kubernetes, и конечно необходимо управлять кластером в облаке. Возможность управления облачным кластером даёт компонент Cloud Controller Manager (CCM), который выступает как мост между нашим кластеров и API сервисом облачного провайдера.

Cloud Controller Manager (CCM) является компонентом узла управления (control plane node component). Но вы также можете запустить Cloud Controller Manager как надстройку Kubernetes, а не как часть узла управления.

Cloud Controller Manager включает группу контроллеров как и в случае с Kube Controller Manager. Для примера рассмотрим золотую троицу:

Node Controller: используя API провайдера облачного сервиса получает информацию о узлах, такую как имя узла, свободные ресурсы, статус узла и т.д.
Route controller: отвечает за настройку маршрутов в сети благодаря чему разные контейнеры на разных узлах могут обращаться друг к другу по сети. В зависимости от облачного провайдера также может выделять блоки IP-адресов
Service controller: используется для развёртывания узлов балансировки нагрузки, назначения ip адресов, фильтрации сетевых пакетов

Docker - Демонстрация силы Docker Volume

Mon, 16 Sep 2024 06:20:39 +0600

Если не знаете что такое Docker Volume то рекомендую сперва почитать про это тут.

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

Создание контейнера с PostgreSQL

Так как сейчас очень распространён PostgreSQL я буду использовать именно его для примера. Но важное замечание никогда не обновляйте контейнер с базой данных, не прочитав рекомендации и требования на официальном сайте. Например, чтобы перейти с версии 17 на 18 необходимо выполнить pg_upgrade.

Для начала создам Docker Volume
```
docker volume create pg_volume
```

Вторым этапом я создам контейнер с образа postgres:17

docker container run -d -v pg_volume:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword --name some-postgres postgres:17

Сохранение информации

Создаю новую БД

docker exec -it some-postgres psql -U 'postgres' -w -h localhost -c 'CREATE DATABASE TEST;'

Создаю таблицу

docker exec -it some-postgres psql -U 'postgres' -w -h localhost -d test -c 'CREATE TABLE users ( id SERIAL PRIMARY KEY, name TEXT NOT NULL, age INT);`

Вставляю данные

docker exec -it some-postgres psql -U 'postgres' -w -h localhost -d test -c "INSERT INTO users (name, age) VALUES ('Alice', 30), ('Bob', 25);"

Проверяю всё

docker exec -it some-postgres psql -U 'postgres' -w -h localhost -d test -c "SELECT * FROM users;"

Удаление контейнера

Теперь я удаляю существующий контейнер и проверяю что Docker Volume остался.

docker container rm -f some-postgres 
docker volume ls

Создание нового контейнера

Теперь я создаю новый контейнер с версией выше (17.6) используя существующий Docker Volume и проверяю что данные те же, что я записал ранее.

docker container run -d -v pg_volume:/var/lib/postgresql/data -e POSTGRES_PASSWORD=mysecretpassword --name some-postgres2 postgres:17.6
docker exec -it some-postgres2 psql -U 'postgres' -w -h localhost -d test -c "SELECT * FROM users;"

 id | name  | age
----+-------+-----
  1 | Alice |  30
  2 | Bob   |  25
(2 rows)

Docker - Постоянное хранилище

Mon, 16 Sep 2024 06:20:39 +0600

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

Контейнеры в докере вещи эфемерные, получается, что по сути это временная среда. Т.е. всё что находится внутри контейнера исчезнет при его удалении. При выполнении команды docker rm myapp Docker удаляет верхний слой, в котором происходят операции записи и чтения, подробнее про слои.

Запомните контейнер — это не виртуальный сервер, а временная изолированная среда. Главная цель контейнера быстро запуститься и быстро исчезнуть без следов. Так происходит потому что девиз контейнеризации — это не менять конфигурацию контейнера, а каждый раз всё пересоздавать.

Перезапуск или остановка контейнера не приводит к потере данных, только удаление контейнера.

Так что с важными данными?

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

Для того чтобы сохранить важные данные от удаления Docker предоставляет две возможности:

использовать тома (Docker Volume)
монтирование локальной папки (Bind mount)

Docker Volume

Docker Volume - это постоянное хранилище, которым управляет сам Docker. Т.е. созданием этих томов занимается сам Docker. Эти тома хранятся по умолчанию в директории /var/lib/docker/volumes/.

При использовании Docker Volume правами на тома управляет сам Docker, он задаёт владельцев, права и монтирует их только при запуске контейнера.

Docker Volume в Dockerfile

При использовании контейнеров для некоторых типов требуется создавать Docker Volume прямо в образе, например, образ приложений баз данных (mariadb).

VOLUME /var/lib/mysql

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

Для примера я создам контейнер с образа mariadb:latest:

docker run --detach --name some-mariadb -e MARIADB_ROOT_PASSWORD=my-secret-pw mariadb:latest
docker ps

e568132fbaf9   mariadb:latest   "docker-entrypoint.s…"   45 seconds ago   Up 44 seconds   3306/tcp   some-mariadb

Теперь при просмотре конфигурации контейнера у него будет как минимум один существующий тов.

docker inspect -f '{{json .Mounts}}' some-mariadb | jq

{
    "Type": "volume",
    "Name": "ec0302b40bf39f5c983464ebb95c0a3fa8e70f6ecdd5ec28bbeb9d8a271151e7",
    "Source": "/var/lib/docker/volumes/64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70/_data",
    "Destination": "/var/lib/mysql",
    "Driver": "local",
    "Mode": "",
    "RW": true,
    "Propagation": ""
  }

Из вывода команды можно догадаться что файлы хранятся в локальной директории /var/lib/docker/volumes/64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70/_data. Скажу сразу удалить эту директорию на хосте и потерять данные можно, Docker не защищает директорию /var/lib/docker/volumes/ от удаления файлов.

Список Docker Volume

Выше я проверил какой том используется контейнером используя команду docker inspect. Но для управления томами в Docker есть отдельная команда docker volume.

Просмотр всех томов в Docker

docker volume ls

local     64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70

Проверить конфигурацию тома

docker volume inspect 64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70

{
     "CreatedAt": "2025-11-03T13:14:44+06:00",
     "Driver": "local",
     "Labels": {
         "com.docker.volume.anonymous": ""
     },
     "Mountpoint": "/var/lib/docker/volumes/64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70/_data",
     "Name": "64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70",
     "Options": null,
     "Scope": "local"
 }

Docker Volume в Docker run

Я показал, как можно создать том еще на этапе сборки образа, но можно добавить том при создании контейнера. Этот вариант кстати добавит еще и удобочитаемости при выводе результат выполнения команды docker volume ls.

Для того чтобы добавить том в контейнер при его создании используется опция -v.

docker run --detach --name some-mariadb -v some-mariadb-vol1:/var/lib/mysql -e MARIADB_ROOT_PASSWORD=my-secret-pw
mariadb:latest

Теперь, когда я выполню команду docker volume ls я увижу нормальное имя тома а не эти бесконечные буквы и цифры. Да и путь к директории тома в самой ОС будет выглядеть лучше.

docker volume ls

local     some-mariadb-vol1

Для создания Docker Volume можно также использовать команду docker volume create. Но обычно эта команда используется только если нужно указать специфические параметры для тома, которые нельзя указать при выполнении команды docker run.

Общий доступ к Docker Volume

Как нетрудно догадаться если контейнер удалён, а том еще остался то можно добавить этот том в другой контейнер со всеми данными внутри него.

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

Docker Volume для уже созданного и работающего контейнера

К сожалению, тут сделать этого нельзя, только если вы не используете docker-compose.

Для добавления тома к уже существующему контейнеру придётся его удалить и создать заново. Но если вы всё делаете правильно, то такая операция не должна на что-то повлиять. Если же что-то внутри контейнере лежит важное не в Docker Volume или Bind mount сохраните эти файлы.

Удаление Docker Volume

Теперь, когда у меня есть том для контейнера some-mariadb при удалении самого контейнера данные и сам том должны остаться не тронутыми.

docker volume ls
sudo ls /var/lib/docker/volumes/64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70/_data

aria_log.00000001  ddl_recovery.log  ibdata1      ibtmp1

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

docker volume rm 64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70
sudo ls /var/lib/docker/volumes/64165e246eab56a2c5bbd047c07eb2ba68d419a83c51cff1e7a4c8cafa505b70/_data

ls: cannot access

Bind mount

Благодаря Bind mount можно прокинуть локальную папку с хостовой ОС в контейнер. Соответственно даже при удалении контейнера данные остаются внутри директории хоста с Docker.

docker run -d -v $(pwd)/data:/usr/src/app/data myapp:1.0

При выполнении этой команды Docker не создаёт отдельный volume, а просто связывает локальную директорию с директорией внутри контейнера, по сути этакий линк на директорию.

Но при выборе между Bind mount и Docker Volume рекомендуется использовать именно Docker Volume. Потому что одна из идей Docker это изоляция контейнера от файловой системы хоста, но при Bind mount это идея рушится и управляет правами на доступ к файлам уде сама ОС, а не Docker. Также есть некоторые ограничения при использовании Docker в Docker Swarm и Kubernetes.

Основное преимущество тут в том, что можно править файлы, используемые контейнером, не залезая в сам контейнер.

Bind mount невозможно использовать при создании образа, т.е. в Dockerfile. Добавить Bind mount к контейнеру можно только при создании контейнера или при использовании Docker Compose.

Для проброса локальной директории в контейнер при создании самого контейнера используется опция -v.

docker run --detach --name some-mariadb -v /var/lib/mysql:/var/lib/mysql -e 
sudo ls /var/lib/mysql

Veeam Backup & Replication - Прямой доступ к хранилищу

Thu, 15 Aug 2024 06:20:39 +0600

При использовании транспорта прямой доступ к хранилищу Veeam Backup & Replication работает с данными (чтение/запись) напрямую через систему хранения данных, на которой расположены вириальные машины.

Прямой доступ к SAN

Процесс создания резервной копии / Процесс восстановления резервной копии / Требования / Лимиты /

Прямой доступ к SAN рекомендуется к использованию, когда диски виртуальной машины хранятся на SAN устройствах, которые подключены к хосту ESXI посредством FC, FCoE, iSCSI. В режиме Прямой доступ к SAN для прямой передачи данных виртуальной машины из хранилища по протоколам FC, FCoE, iSCSI используется VMware VADP. Данные виртуальной машины передаются по сети SAN, минуя хосты ESXi и локальную сеть. Что позволяет снизить нагрузку на сеть и как правило быстрее выполнить трансфер данных.

Процесс создания резервной копии

В Veeam Backup & Replication запускается процесс создания резервной копии виртуальной машины
Прокси-сервер отправляет запрос хосту ESXI, где расположена ВМ чтобы узнать на каком хранилище находятся данные
ESXI хост выясняет где находятся необходимые данные
Veeam Backup & Replication инициализирует процесс создания снимка ВМ (snapshot) на ESXI хосте
Хост ESXi извлекает метаданные о расположении дисков виртуальной машины в хранилище (физические адреса блоков данных)
Хост ESXi отправляет полученные метаданные прокси-серверу
Прокси-сервер резервного копирования VMware использует метаданные для копирования блоков данных виртуальной машины непосредственно напрямую с хранилища SAN
Резервный прокси-сервер VMware обрабатывает скопированные блоки данных и отправляет их на целевой сервер

Процесс восстановления резервной копии

В Veeam Backup & Replication запускается процесс восстановления виртуальной машины
Прокси-сервер получает данные необходимые для восстановления с репозитория резервных копий
Прокси-сервер отправляет запросы на восстановление данных хосту ESXI
Хост ESXi выделяет место в хранилище данных
Данные записываются на хранилище данных

Требования

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

Настоятельно рекомендуется назначить роль прокси-сервера VMware с прямым доступ к SAN именно физическому серверу, при назначении этой роли виртуальной машине производительность может пострадать. Т.е. подключаете ваш физический прокси-сервер VMware к действующей SAN сети (fc switch) и даёте доступ этому серверу к устройствам хранения.
Как я уже написал выше необходимо также настроить доступ прокси-сервер VMware к системам хранения данных. Если этого не сделать, то прокси-сервер просто не сможет получить доступ к данным. Например, просто подключить FC кабель от сервера в fc коммутатор не получиться, также придётся настраивать сопоставление хоста с LUN в самой СХД.
Тома с СХД также должны быть видны в оснастке управления дисками. Только никогда не делайте инициализацию этих дисков, потому как по умолчанию они находятся в оффлайн режиме чтобы не перезаписать файловую систему на NTFS.
Для восстановления прокси-серверу необходимо иметь права на запись

Лимиты

Обратите внимание на лимиты, так как лично я был немного удивлён:

Режим прямого доступа к SAN может использоваться только для восстановления виртуальных машин с дисками типа thick
Если диски у виртуальной машины раскиданы по нескольким СХД и к какой-то из них у прокси-сервера нет доступа, то резервная корпия не будет создана ни для какого диска.
Если хотя бы один из дисков находится в vVol вы не сможете создать резервную копию
Нет возможности делать резервные копии шаблонов виртуальных машин
Прямой доступ к SAN не подойдёт для инкрементального восстановления из-за ограничений VMware. Либо отключите CBT для виртуальных дисков VM на время процесса восстановления, либо выберите другой транспортный режим для инкрементального восстановления.
Если вы делаете реплику виртуальной машины, то Veeam Backup & Replication будет использовать режим прямого доступа к SAN только для первой сессии. Т.е. все последующие изменения будут реплицироваться в режиме виртуального устройства или сетевого.
Также при репликации обращайте внимание на тип дисков для целевой реплики виртуальной машины. Если будет стоять thin, то опять же будет использоваться режим виртуального устройства или сетевого.
Multipathing (MPIO) для прокси-серверов на базе Linux в транспортном режиме прямого доступа SAN использует только отказоустойчивые пути, а не балансировку нагрузки

Прямой доступ к NFS

Прямой доступ к NFS рекомендуется к использованию в тех случаях, когда виртуальные диски ВМ хранятся на NFS хранилищах, на основе Ethernet.

Режим прямого доступа к NFS представляет собой альтернативу сетевому режиму. Когда Veeam Backup & Replication получает данные ВМ по сетевому режиму он использует VMware VDDK для коммуникации с хостом ESXI, что конечно же добавляет дополнительную нагрузку на хост ESXI.

Прямой доступ к NFS позволяет обойти хост стороной ESXI и получить данные напрямую с хранилища NFS. Для этого Veeam Backup & Replication разворачивает на прокси-сервере свой собственный NFS клиент (настраиваете конечно вы всё сами). Да так как это всё ещё передаются по сети, как и в случае использования простого сетевого транспорта, но уже нет нагрузки на ESXI хост.

Процесс создания резервной копии / Процесс восстановления резервной копии / Требования / Лимиты /

Процесс создания резервной копии

В Veeam Backup & Replication запускается процесс создания резервной копии виртуальной машины
Прокси-сервер отправляет запрос хосту ESXI, где расположена ВМ чтобы узнать на каком NFS хранилище находятся данные
ESXI хост выясняет где находятся необходимые данные
Veeam Backup & Replication инициализирует процесс создания снимка ВМ (snapshot) на ESXI хосте
Хост ESXi извлекает метаданные о расположении дисков виртуальной машины в хранилище (физические адреса блоков данных)
Хост ESXi отправляет полученные метаданные прокси-серверу
Прокси-сервер резервного копирования VMware использует метаданные для копирования блоков данных виртуальной машины с хранилища NFS по сети (ETHERNET)
Резервный прокси-сервер VMware обрабатывает скопированные блоки данных и отправляет их на целевой сервер

Процесс восстановления резервной копии

В Veeam Backup & Replication запускается процесс восстановления виртуальной машины
Прокси-сервер получает данные необходимые для восстановления с репозитория резервных копий
Прокси-сервер отправляет запросы на восстановление данных хосту ESXI
Хост ESXi выделяет место в хранилище данных NFS
Данные записываются на хранилище данных по сети (ETHERNET)

Требования

Можно использовать в средах VMware vSphere (ESXI), работающих под управлением NFS версии 3 и 4.1
Прокси-сервер должен иметь доступ к NFS хранилищу, где лежат данные ВМ
Если хранилище NFS промотированно в ESXI по DNS имени, а не по ip-адрессу то прокси-сервер также должен сопоставлять это DNS имя с ip-адрессом

Лимиты

Режим прямого доступа к NFS не может использоваться для виртуальных машин, имеющих хотя бы один моментальный снимок
При репликации ВМ режим прямого доступа к NFS используется только при первом разе, дальше всё по обычной сети
Если в задаче вы активируете галочку Включить приостановку работы инструментов VMware (Enable VMware tools quiescence) режим прямого доступа к NFS не будет использоваться
Если по каким-то причинам диски ВМ не доступны по NFS будет использоваться обычный сетевой транспорт

Screenity - Отличная утилита для конфиденциальной записи экрана

Wed, 14 Aug 2024 06:20:39 +0600

На самом деле утилит для записи экрана куча, но Screenity меня действительно зацепила. Самое главное это полностью бесплатная утилита и второе преимущество — это то что вы можете заблюрить любой текс на экране просто нажав на него.

Также вы можете сохранять ваши видео сразу на google диск используя встроенный функционал.

Как установить Screenity

К сожалению, установить его как отдельную программу не получится, ставится Screenity как дополнение к chrome.

Переходим по ссылке и добавляем дополнение в chrome
После установки вас перенаправит на страницу настройки, просто выполните что там написано
После настройки справа от строки ввода в chrome появится синий кружочек, который активирует запись экрана

Возможно вы подумали, что если дополнение ставится в веб браузер, то оно работает только пока есть интернет, но это не так. Вы всегда можете использовать Screenity без интернета, только сохранить видео на google диск не получится.

Быстрые клавиши (shortcuts)

Чтобы настроить shortcuts в строке ввода url chrome вбиваем chrome://extensions/shortcuts и нажимаем ENTER.

В списке находим Screenity - Запись экрана & Аннотации и можем задать сочетания клавиш для:

Запись экрана (Alt + Shift + G)
Отмена записи (Alt + Shift + X)
Пауза (Alt + Shift + M)

Собирает ли Screenity какие-либо данные?

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

Настройки Screenity

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

Тут можно изменить качество видео, размер окна.

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

Переходим в настройки
Активируем Создавать резервные копии
Начинаем запись экрана
Указываем директорию, куда сохранять видео

Запись экрана

Нажмите значок Screenity в адресной строке, чтобы открыть всплывающее окно записи
Выберите, что вы хотите записать: экран, область вкладок или видео с камеры
Выберите камеру, если необходимо записывать видео с камеры
Выберите микрофон
Нажмите кнопку Начать запись, чтобы начать создание видео

Как делать заметки или аннотации в Screenity

Если вы хотите делать заметки или аннотации в Screenity, то используйте кнопку с карандашом. Кстати очень полезная функция для создания обучающих роликов.

Тут же можно выбрать стиль карандаша, использовать ластик, вводить текст, добавлять стрелки. Можно даже вставить картинку.

Как скрыть конфиденциальную информацию

И самая крутая функция на мой взгляд это скрытие конфиденциальной информации.

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

VMWare - Миграция ESXI через vSphere Lifecycle Manager

Wed, 17 Jul 2024 06:20:39 +0600

Я уже описывал как обновить хосты ESXI через vSphere Lifecycle Manager в этой статье. Теперь опишу как обновить ESXI с версии 7.0 до версии 8.0.

Импорт образа с ESXI 8.0

Первое что нам необходимо сделать это импортировать ISO образ ESXI версию 8.0 через Lifecycle Manager. Для этого переходим в Lifecycle Manager > Imported ISOs и нажимаем IMPORT ISO.

Также в идеале вы должны установить все необходимые обновления на ESXI 7.0. Для этого можно воспользоваться статьёй.

Создаём Baseline для обновления

Всё также переходим в Lifecycle Manager
Нажимаем на Baselines
Выбираем NEW > Baseline
В новом окне выбираем галочку Upgrade, прописываем понятное вам название
Нажимаем далее и выбираем ранее загруженный ISO образ

Запускаем процесс обновления ESXI с версии 7.0 до версии 8.0

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

Выбираем необходимый нам ESXI хост
Переходим в Updates > Baselines
Снизу нажимаем ATTACH > Attach Baseline or Baseline Group
Выбираем Baseline который создали выше
Нажимаем CHECK COMPLIANCE (Статус смотрим в Recent Tasks)
Если вы вдруг получаете статус Incompatible в Attached Baselines есть смысл скачать кастомный ISO образ от производителя сервера, где будут все необходимые драйвера.
Далее выделяем наш Baseline и нажимаем REMEDIATE
Статус обновления также проверяем в Recent Tasks

Redfish - Примеры использования

Tue, 16 Jul 2024 06:20:39 +0600

Я не буду особо расписывать что такое Redfish. Основная идея — это то, что каждый производитель должен иметь одинаковы API для управления серверами. Собственно, тут я просто оставлю несколько команд, которые возможно пригодятся мне, когда веб-интерфейс управления сервера INTEL снова помрёт.

Узнаём ID системы

Это необходимо для дальнейшего выполнения команд. По сути для нас это выглядит как ID сервера.

curl -u "user:pwd" -k -X GET https://192.168.0.81/redfish/v1/Systems

Перезагружаем сервер используя Redfish

curl -si -u "user:pwd" -k -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"ResetType": "ForceRestart"}' https://192.168.0.81/redfish/v1/Systems/SYSTEMID/Actions/ComputerSystem.Reset

Выключаем сервер используя Redfish

curl -si -u "user:pwd" -k -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"ResetType": "ForceOff"}' https://192.168.0.81/redfish/v1/Systems/SYSTEMID/Actions/ComputerSystem.Reset

Включаем сервер используя Redfish

curl -si -u "user:pwd" -k -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"ResetType": "On"}' https://192.168.0.81/redfish/v1/Systems/SYSTEMID/Actions/ComputerSystem.Reset

Информация о сервере используя Redfish

curl -u "user:pwd" -k -X GET https://192.168.0.81/redfish/v1/Chassis/RackMount

Сброс биоса используя Redfish

curl -si -u "user:pwd" -k -X POST https://192.168.0.81/redfish/v1/Systems/SYSTEMID/Bios/Actions/Bios.ResetBios

Перезапуск BMC используя Redfish

curl -si -u "user:pwd" -k -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"ResetType": "ForceRestart"}' https://192.168.0.81/redfish/v1/Managers/BMC/Actions/Manager.Reset

VMWare - Update Manager Download Service (UMDS)

Fri, 12 Jul 2024 06:20:39 +0600

Устанавливать сервис Update Manager Download Service (UMDS) я буду на CentOS.

С установочного образа Vcenter Server копируем файл VMware-UMDS-8.0.1-build_number.tar.gz в папке umds
Распаковываем архив командой tar -xvzf VMware-UMDS-8.0.1-build_number.tar.gz
Переходим в директорию vmware-umds-distrib и запускаем скрипт для установки командой perl vmware-install.pl
Отвечаем на вопросы, например, я указал другую папку для хранения файлов

Дальше нам необходимо настроить какие именно обновления мы хотим качать

Переходим в директорию /usr/local/vmware-umds/bin
Для просмотра всех версий vSphere, для которых мы можем настроить закачку обновлений выполняем vmware-umds --list-host-platforms
Для того чтоб активировать закачку обновлений для ESXI 7.0 выполняем vmware-umds -S -e embeddedEsx-7.0
Чтобы отключить закачку обновлений для ESXI 6.7 выполняем команду vmware-umds -S -d embeddedEsx-6.7.0
Чтобы запустить процесс скачивания обновлений вручную можно использовать команду vmware-umds -D

Если нужно экспортировать всё скачанное выполняем команду vmware-umds -E --export-store dest_dir

**********************************************
Downloaded 1254 updates, download size: 21364 MB.
**********************************************

Дальше у нас 2 варианта: отдавать пакеты по smb шаре или через web, я выбрал второй вариант так как не особо доверяю сетевым папкам.

Для раздачи пакетов по сети я использовал ngixn, со следующей конфигурацией:

server {
    listen       8086 ;
    server_name  nexus.local.lan;
    add_header Strict-Transport-Security 'max-age=604800'

    # Load configuration files for the default server block.
    include /etc/nginx/default.d/*.conf;

    location / {
        root /nexus/vmware;
        autoindex on;
    }

}

После того как пакеты выкачаны можно настроить vSphere Lifecycle Manager на наш UMDS. Для этого переходим в Lifecycle Manager > Settings > Patch Setup > Change Download Source и прописываем наш URL.

После того как прописали новый источник обновлений запускаем процесс синхронизации ACTIONS > Sync Updates. В итоге в Baselines должны появится новые пакеты обновлений.

VMWare - vSphere Lifecycle Manager (Обновление ESXI)

Fri, 12 Jul 2024 06:20:39 +0600

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

В VMWare за установку, обновление софта в вашем кластере отвечает vSphere Lifecycle Manager. Он отвечает за такие задачи как: установка ESXI и прошивок на новые хосты, обновление версий ESXI и прошивок при необходимости.

При установке Vcenter Server этот сервис включается по умолчанию и не требует никаких дополнительных установок со стороны пользователя. По умолчанию для работы использует также бд на основе PostgreSQL, но вроде сейчас это не является необходимым. По сути vSphere Lifecycle Manager - это замена старого Update Manager. Начиная с версии Vcenter Server 7.0 уже используется vSphere Lifecycle Manager.

Конечно же для скачивания обновлений сервису vSphere Lifecycle Manager необходим доступ в интернет. Если же у вас его вообще нет (на то могут быть свои причины), то можно воспользоваться сервисом Update Manager Download Service (UMDS) для загрузки обновлений вручную. Подробнее о UMDS в этой статье.

Операции vSphere Lifecycle Manager

Для загрузки и проверки удачной установки обновлений используются следующие операции:

Операция	Описание
Compliance Check	Операция сканирования хоста на соответствие заданному уровню. Т.е. просто проверка требуется ли что-то обновить или установить
Remediation Pre-Check	Проверка на то что после установки обновлений не произойдёт сбой
Remediation	Собственно сам процесс обновления
Stage	Режим загрузки обновлений на хост

Безопасное хеширование и проверка подписи в vSphere Lifecycle Manage

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

Используем vSphere Lifecycle Manager

Самое первое что нужно сделать это перейти в панель vSphere Lifecycle Manager, для этого в левом верхнем углы нажимаем на меню > Lifecycle Manager. Тут вы можете импортировать готовые ISO образы, например, новую версию Vsphere для обновления старой.

Настройки vSphere Lifecycle Manager

На вкладке settings мы можем настроить поведение vSphere Lifecycle Manager как нам необходимо, например, можно отключить автоматическую загрузку обновлений, что конечно же делать не рекомендуется.

Меня же конкретно тут интересует возможность скачивания обновлений с другого сервера, в моём контуре. Просто я не могу дать доступ серверу Vcenter в интернет, и тут мне поможет тот самый сервис под названием Update Manager Download Service (UMDS).

О том, как настроить и установить Update Manager Download Service (UMDS) я расписал тут.

Процесс обновления

Для обновления ESXI хостов мы будем использовать Baselines, которые делятся на три типа: предопределенный, рекомендованный, собственный.

Перед тем как запустить процесс обновления необходимо сопоставить Baseline с хостом, кластером или дата-центром.

Выделяем конкретный хост или кластер и переходим в Updates.
Нажимаем Attach > Attach Baseline or Baseline Group (по умолчанию уже добавлены обновления безопасности и критические обновления)

Также перед обновлением необходимо проверить статус соответствия обновлений для хоста. Во время выполнения проверяется какие уже обновления установлены на хосте и необходимо ли установить новые.

Запуск проверки соответствия вручную

Выделяем конкретный хост или кластер и переходим в Updates.
Нажимаем CHECK COMPLIANCE
После проверки вы получите список рекомендованных обновлений
Для того, чтобы посмотреть какие обновления требуются для установки в Attached Baselines выбираем Baseline и внизу выводится статус всех обновлений для хоста

Загрузка обновлений на хост

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

Для загрузки обновлений на хост:

Выделяем конкретный хост или кластер и переходим в Updates.
В Attached Baselines выбираем что надо и нажимаем STAGE
Собственно, выбираем хост, на который нужно закачать обновления, и если хотите посмотреть какие именно обновления можно развернуть Stage ниже
В задачах появится статус выполнения

Установка обновлений на хост

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

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

Выделяем конкретный хост или кластер и переходим в Updates.
Нажимаем PRE-CHECK REMEDIATION
Если ничего нет, то нажимаем DONE
Если есть предупреждения можно рассмотреть их тут

Ну и когда все предупреждения решены или их вовсе нет можно приступать к установке:

Выделяем конкретный хост или кластер и переходим в Updates.
Выбираем Attached Baselines и нажимаем REMEDIATE
Во время установки обновлений хост перейдёт в состояние обслуживания и также будет перезагружен (статус обновления в задачах)
В итоге Compliant должен быть чистым с зелёной галочкой

Vcenter - При редактировании vm пустая страница

Thu, 11 Jul 2024 06:20:39 +0600

Если вы вдруг решили изменить конфигурацию виртуальной машины, но столкнулись с проблемой что выходит просто пустое окно, то вы попали на правильную статью.

Выглядит это так:

Причина

А собственно причина в том, что вы скорее всего обновили сам Vcenter Server, который не совместим с версией ESXI самой виртуальной машины. Например, у меня Vcenter Server 8, а при создании виртуальных машин выбиралась версия совместимости с ESXi 5.0 and later (VM version 8).

Решение

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

Для этого:

Нажимаем правой кнопкой на самой виртуальной машине
Выбираем Compatibility > Shedule VM Compatibility Upgrade
В диалоговом окне выбираем YES
В следующем окне выбираем версию совместимости (например, ESXI 7.0 U2 and later)
Далее необходимо перезагрузить виртуальную машину

Veeam - Предопределенные тесты (SureBackup)

Wed, 03 Jul 2024 06:20:39 +0600

Veeam Backup & Replication может проверять машины с помощью следующих предопределенных тестов:

Тест Heartbeat: При запуске VM выполняется тест Heartbeat. Запущенная VM должна подать сигнал Heartbeat используя VMware Tools, которые должны были быть установлены в VM. Если сигнал поступает регулярно с определенными интервалами времени, тест пройден.
Тест Ping: Veeam Backup & Replication посылает ping запросы в VM от самого сервера, где установлен Veeam. Если VM отвечает на ping, то процесс пройден.
Тест приложений: Veeam Backup & Replication ожидает запуска приложений внутри VM. После запуска используются скрипты для проверки их состояния. Veeam Backup & Replication использует два типа скриптов: – Для DNS-серверов, контроллеров доменов, серверов глобального каталога, почтовых серверов и веб-серверов Veeam Backup & Replication использует скрипт, который проверяет порт, специфичный для приложения. – Для Microsoft SQL Server Veeam Backup & Replication использует скрипт, который пытается подключиться к экземплярам и базам данных на Microsoft SQL Server.

Docker - Файл .dockerignore и Dockerfile

Sun, 16 Jun 2024 06:20:39 +0600

Для того, чтобы создать свой собственный Docker образ необходимо описать все инструкции, которые должны выполняться внутри образа. Для этого необходимо создать файл с инструкциями, который называется Dockerfile. Имя файла конечно же может быть и другим, но как правило чаще всего используется имя Dockerfile.

Для примера возьмём следующий Dockerfile:

# Можно указать версию, digest или alias.
FROM python:3.11-slim

# LABEL — добавляет произвольные метаданные, например автора, версию и описание.
LABEL maintainer="student@example.com" \
      version="1.0" \
      description="Учебный Dockerfile со всеми основными инструкциями."

# ARG — аргументы доступны только во время сборки (build-time).
# Они не сохраняются внутри контейнера.
ARG APP_VERSION=1.0
ARG DEBIAN_FRONTEND=noninteractive

# ENV — сохраняет переменные в образе, они доступны во время запуска.
ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    APP_HOME=/usr/src/app \
    APP_ENV=production

# WORKDIR — задаёт текущую директорию для всех последующих инструкций.
WORKDIR $APP_HOME

# COPY — копирует файлы из контекста сборки (локальной папки) в контейнер.
COPY requirements.txt .
COPY app.py $APP_HOME

# RUN — выполняет команды Linux во время сборки и создаёт новый слой.
# Используется для установки зависимостей и пакетов.
RUN apt-get update && \
    apt-get install -y --no-install-recommends build-essential git curl && \
    pip install --no-cache-dir -r requirements.txt && \
    rm -rf /var/lib/apt/lists/*

# ADD — как COPY, но поддерживает загрузку из URL и распаковку архивов.
ADD . .

# RUN groupadd/useradd — создаёт не-root пользователя для запуска приложения.
RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser

# USER — задаёт пользователя, от имени которого будут выполняться команды в контейнере.
USER appuser

# VOLUME — создаёт точку монтирования (для хранения данных или логов).
# создаёт анонимный том (volume), если нужносохранять данные после удаления контейнера
VOLUME ["/usr/src/app/data"]

# EXPOSE — документирует, какие порты слушает приложение.
# Это не открывает порт наружу, но помогает понять его назначение.
EXPOSE 8000

# ENTRYPOINT — основная команда, которая выполняется при запуске контейнера.
# CMD — аргументы по умолчанию для ENTRYPOINT (можно переопределить в docker run).
ENTRYPOINT ["python"]
CMD ["app.py"]

# HEALTHCHECK — Docker периодически выполняет команду, чтобы убедиться, что контейнер “жив”.
# Если команда завершается с кодом != 0, контейнер считается unhealthy.
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

Сборка образа

Для того чтобы собрать образ используется команда docker build, для задания имени образа и тэга используется опция -t. Точка в конце команды указывает что Dockerfile и другие файлы, необходимые для создания образа нужно искать в текущей директории.

Если же имя файла отличается от Dockerfile необходимо через опцию -f указать имя файла.

docker build -t myapp:1.0 .
docker image ls

В первой команде я указываю имя образа myapp без NAMESPACE потому что я не собираюсь загружать этот образ в репозиторий, подробнее про NAMESPACE.

После удачной сборки осталось запустить контейнер с этого образа и проверить его доступность. Так как в Dockerfile объявлен порт (EXPOSE 8000) прокидываю его на локальный порт 8000 через -p.

docker run --name myapp -d -p 8000:8000 myapp:1.0
curl http://localhost:8000/

Порядок инструкций

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

WORKDIR - тут рабочая директория будет та, которая указана в последней инструкции

📜 Dockerfile.10

FROM python:3.11-slim
WORKDIR /usr/local/bin
WORKDIR /usr/local

docker build -t mypython:1.0 -f Dockerfile10 .
docker run -it mypython:1.0 sh
echo $PWD

/usr/local

CMD - при старте контейнера выполнится последняя команда, указанная в файле

📜 Dockerfile.11

FROM python:3.11-slim
CMD "echo 1 >> /usr/local/2.txt"
CMD "echo 2 >> /usr/local/2.txt"

docker run -it mypython:1.1

/bin/sh: 1: echo 2 >> /usr/local/2.txt: not found

Что делает `.dockerignore`

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

Дело в том что при запуске docker build -t myapp:1.0 . Docker берёт весь контент в текущей директории, т.е. не важно, что в самом Dockerfile вы копируете в образ всего пару файлов. Да, в самом образе не будет ничего лишнего, но вот во время сборки Docker упаковывает всё содержимое в архив и отправляет Docker-демону, который потом вытаскивает оттуда-то что нужно. В следствии чего тратятся лишние ресурсы (CPU, RAM, IO) и время сборки увеличивается.

Для примера у меня в директории с Dockerfile есть файл zerofile.bin объёмом 10 GiB и я попробую собрать образ без файла .dockerignore.

docker build -t myapp:1.0 .

=> => transferring context: 10.74GB
[+] Building 88.5s (11/11) FINISHED

Теперь сделаю тоже самое только с использованием .dockerignore, в котором перечислю файлы, которые нужно пропустить. Файл .dockerignore нужно создать в той же директории где и Dockerfile.

📜 .dockerignore

*.bin

docker build -t myapp:1.0 .

 => => transferring context: 4.20kB 
 [+] Building 2.7s (11/11) FINISHED

Docker - Shell form vs Exec form

Sun, 16 Jun 2024 06:20:39 +0600

Shell form и exec form это по сути два стиля написания команд в Dockerfile.

Форма	Пример
Shell form	RUN apt-get update && apt-get install -y curl	оболочечная (shell)
Exec form	RUN [“apt-get”, “update”, “&&”, “apt-get”, “install”, “-y”, “curl”]	исполняемая (exec)

Как видно из таблицы для человека более приятная форма shell, нет никаких разбивок и проще для написания.

Shell form

RUN apt-get update && apt-get install -y curl

Команда выше выполняется через оболочку, т.е. Docker в тайне от вас выполняет эту команду так /bin/sh -c "apt-get update && apt-get install -y curl".

Благодаря такому преобразованию можно использовать в команде &&, |, переменные, перенаправления (>, >>).

Но при выполнении команды в формате Shell процесс внутри контейнера будет не сама команда а оболочка, которая выполняет её (sh). Т.е. при передаче сигнала SIGTERM его получит сама оболочка, а не команда, вызываемая внутри неё.

🦴Dockerfile.shell

FROM ubuntu
CMD sleep 100

docker build -t shell:1.0 -f Dockerfile.shell .
docker run -it --name shellc shell:1.0

В другом терминале я зайду в контейнер и проверю запущенные процессы в контейнере.

docker exec shellc ps

PID TTY          TIME CMD
1 ?        00:00:00 sh
6 ?        00:00:00 sleep
7 ?        00:00:00 ps

Exec form

Теперь напишу туже самую команду, только в формате Exec.

🦴Dockerfile.exec

FROM ubuntu
CMD ["sleep", "100"]

docker build -t exec:1.0 -f Dockerfile.exec .
docker run -it --name execc exec:1.0

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

docker exec execc ps

PID   USER     TIME  COMMAND
1 root      0:00 sleep 100
6 root      0:00 ps

Из вывода видно, что тут главный процесс PID 1 — это sleep сам по себе, а не sh как в случае с Shell form, потому что напрямую вызывается команда, а не оборачивается в sh.

Где и что использовать?

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

Для RUN просто используйте shell вариант, например, RUN apt-get update. Конечно ничто на мешает записать эту команду в EXEC варианте (RUN [“apt-get”, “update”]), но зачем?
Для ENTRYPOINT наоборот используйте EXEC
Для CMD также используйте EXEC только если только не вынуждены использовать shell
Для ENTRYPOINT + EXEC используйте всегда EXEC

Docker - Entrypoint vs CMD

Sun, 16 Jun 2024 06:20:39 +0600

Инструкция Entrypoint в Dockerfile нужна для того, чтобы задать команду, которая выполнится при старте контейнера. Но для этого также есть и другая команда CMD. Так давайте тут разберёмся в чём собственно разница.

Начнём с того что использовать можно обе инструкции, но работают они немного по-разному.

CMD

Рассмотрим инструкцию CMD, для этого я сделаю следующее:

Создам образ с ubuntu:latest и в качестве команды для CMD укажу date. Когда контейнер запустится выполнится команда date и я увижу результат.
Соберу образ date
Запущу контейнер
Снова запущу контейнер, но только передам новое значение для CMD (df)

🗃️Dockerfile.13

FROM ubuntu:latest
CMD ["date"]

docker build -t date -f Dockerfile.13 .
docker run date

Thu Nov  6 07:53:49 UTC 2025

 docker run date df

 Filesystem          1K-blocks     Used Available Use% Mounted on
overlay              52902668 26803728  26098940  51% /
tmpfs                   65536        0     65536   0% /dev
shm                     65536        0     65536   0% /dev/shm
/dev/mapper/cs-root  52902668 26803756  26098912  51% /etc/hosts
tmpfs                  650128        0    650128   0% /proc/acpi
tmpfs                  650128        0    650128   0% /proc/scsi
tmpfs                  650128        0    650128   0% /sys/firmware

Т.е. используя инструкцию CMD в качестве команды для выполнения при старте контейнера можно передать новое значение для CMD при создании этого контейнера. По умолчанию при старте контейнера выполняется команда date, но ничего мне не мешает выполнить другую команду при создании контейнера, например, df.

ENTRYPOINT

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

🗃️Dockerfile.14

FROM ubuntu:latest
ENTRYPOINT ["date"]

docker build -t date:1.1 -f Dockerfile.14 .
docker run date:1.1

Thu Nov  6 08:04:09 UTC 2025

 docker run date:1.1 df

date: invalid date 'df'

В итоге я получаю ошибку. И вот она разница, используя ENTRYPOINT вы не можете перезаписать команду внутри инструкции ENTRYPOINT пи старте самого контейнера. Всё что вы передаёте в контейнер в качестве команды будет просто добавлено к команде, которая прописана в ENTRYPOINT образа Docker. Т.е. при старте контейнера во втором случае внутри него выполнилась команда date df.

Получается, чтобы команда отработала нормально я должен передать работающие параметры для команды date.

docker run date:1.1 -I

2025-11-06

Но если хочется заменить команду и в ENTRYPOINT, то можно использовать опцию --entrypoint.

docker run --entrypoint df date:1.1

Filesystem          1K-blocks     Used Available Use% Mounted on
overlay              52902668 26804400  26098268  51% /
tmpfs                   65536        0     65536   0% /dev
shm                     65536        0     65536   0% /dev/shm
/dev/mapper/cs-root  52902668 26804400  26098268  51% /etc/hosts
tmpfs                  614288        0    614288   0% /proc/acpi
tmpfs                  614288        0    614288   0% /proc/scsi
tmpfs                  614288        0    614288   0% /sys/firmware

ENTRYPOINT + CMD

Как вы уже догадались можно использовать обе команды в одном файле Dockerfile. Когда вы используете обе команды в одном Dockerfile при старте контейнера Docker объединяет обе команды из инструкций (NTRYPOINT + CMD) и выполняет внутри контейнера что получилось.

Вариант 1

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

🗃️script1.sh

echo "I'm just a script"

🗃️Dockerfile.15

FROM ubuntu:latest

WORKDIR /home/ubuntu
COPY script1.sh .
RUN chmod +x script1.sh

ENTRYPOINT ["sh","script1.sh"]
CMD ["date"]

docker build -t entry:1.0 -f Dockerfile.15 .
docker run entry:1.0

I'm just a script

Но в результате я получил только вывод скрипта, но не вывод команды date. Дело в том, что после объединения команда выглядит так: sh script1.sh /usr/bin/date. И это одна из самых частых ловушек при комбинировании ENTRYPOINT и CMD. Получается команда date передаётся просто как параметр для скрипта script1.sh, который ничего не ожидает и тем более ничего не делает с переданными ему аргументами.

Чтобы избежать такого и добиться выполнения обоих команд нужно использовать exec "$@" в самом скрипте. exec "$@" говорит скрипту о том, что пора бы завершить своё выполнения и передать право запуска другому приложению, которое должно запуститься после него.

🗃️script1.sh

echo "I'm just a script"
exec "$@"

docker build -t entry:1.0 -f Dockerfile.15 .
docker run entry:1.0

I'm just a script
Thu Nov  6 10:29:36 UTC 2025

Либо можно сделать тоже самое в самом Dockerfile:

🗃️Dockerfile.15

FROM ubuntu:latest

WORKDIR /home/ubuntu
COPY script1.sh .
RUN chmod +x script1.sh

ENTRYPOINT ["/bin/sh", "-c", "./script1.sh && exec \"$@\"", "--"]
CMD ["date"]

Вариант 2

Другой вариант — это когда у вас есть основной исполняемый файл, но параметры для него изменяемые, самый простой пример это обычный исполняемый файл curl, которому в качестве параметра передаются разные URL сайтов. При использовании только CMD каждый раз приходилось бы писать что-то вроде curl https://tipoit.kz.

🗃️Dockerfile.16

FROM ubuntu:latest
RUN apt-get update && \
		apt-get install -y --no-install-recommends \
		curl \
		&& rm -rf /var/lib/apt/lists/*
		
ENTRYPOINT ["curl", "-kI"]
CMD ["https://tipoit.kz"]

docker build -t entry:1.1 -f Dockerfile.16 .
docker run entry:1.1
docker run entry:1.1 https://google.com

Получается, что по умолчанию я указал url https://tipoit.kz и при необходимости могу его поменять на любой другой.

Официальные образы

Если вы думаете, что использование одновременно ENTRYPOINT и CMD встречается только в частных сборках вы, ошибаетесь. Даже официальные образы на Docker Hub имеют такие связки, например, уже знакомый mariadb.

MSSql - Типы бэкапов баз данных

Fri, 24 May 2024 06:20:39 +0600

В Microsoft SQL Server для сохранения ваших данных в случае выхода сервера из строя вы можете (обязаны) делать бэкап баз данных. В Microsoft SQL Server существуют следующие типы бэкапов:

Полный бэкап (Full Backup)
Дифференциальный бэкап (Differential Backup)
Бэкап журнала транзакций (Transaction Log Backup)
Бэкап только для копирования (Copy-Only Backup)
Бэкап файлов и файловых групп (File and Filegroup Backup)

Как правило простой обыватель зачастую сталкивается только с первыми тремя типами.

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

Полный бэкап (Full Backup)

При использовании Полного бэкапа (Full Backup) создаётся полная резервная копия базы данных, включающая все данные (mdf) и также весь лог транзакций (ldf). Т.е. для восстановления полностью базы данных вам понадобится только один файл.

Полный бэкап (Full Backup) также является отправной точкой для Дифференциального бэкапа (Differential Backup) и Бэкапа журнала транзакций (Transaction Log Backup). Т.е. чтобы сделать бэкап другого типа вам сперва придётся сделать Полный бэкап (Full Backup).

Используя Полный бэкап (Full Backup) вы упрощаете себе процесс восстановления, так как нужно восстановить один файл. Но нужно понимать, что, если у вас база данных большого объёма будет не выгодно делать Полный бэкап (Full Backup), так как это займёт много времени.

BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Full.bak'
WITH INIT;

RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase_Full.bak';

Дифференциальный бэкап (Differential Backup)

Дифференциальный бэкап (Differential Backup) включает в себя только те данные, которые были записаны в базу данных после создания Полного бэкапа (Full Backup). Зачастую имеет намного меньший размер бэкапа чем Полный бэкап (Full Backup).

Используется для того, чтобы быстрее выполнять повседневный бэкап. Обычно Полный бэкап (Full Backup) выполняется раз в неделю, а Дифференциальный бэкап (Differential Backup) каждый день.

Для восстановления Дифференциального бэкапа (Differential Backup) нужно сперва восстановить Полный бэкап (Full Backup). Причём вы не сможете восстановить Дифференциальный бэкап (Differential Backup), который был создан до Полного бэкапа (Full Backup).

BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Diff.bak'
WITH DIFFERENTIAL, INIT;

RESTORE DATABASE [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Full.bak'  WITH NORECOVERY;
RESTORE DATABASE [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Diff.bak'  WITH RECOVERY;

Бэкап журнала транзакций (Transaction Log Backup)

Этот тип бэкапа включает только резервные копии логов транзакций, в которые записываются все изменения базы данных. Использование Бэкапа журнала транзакций (Transaction Log Backup) даёт вам возможность восстановится на конкретное время. Например, если вы делаете Бэкап журнала транзакций (Transaction Log Backup) каждые пять минуть, то при потере сервера вы максимум потеряете данные за пять минут, что не так уж и плохо.

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

Для того чтобы восстановить Бэкап журнала транзакций (Transaction Log Backup) вам сперва необходимо восстановить Полный бэкап (Full Backup) и самый последний Дифференциальный бэкап (Differential Backup), если он есть.

BACKUP LOG [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Log.trn'
WITH INIT;

RESTORE DATABASE [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Full.bak'  WITH NORECOVERY;
RESTORE DATABASE [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Diff.bak'  WITH NORECOVERY;
RESTORE LOG [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Log.trn'  WITH RECOVERY;

Бэкап только для копирования (Copy-Only Backup)

По сути это такой же Полный бэкап (Full Backup) но только с одним отличием, он ни как не влияет на другие типы бэкапа.

Мы уже говорили, что если вы делаете Полный бэкап (Full Backup) то он становится отправной точкой для всех будущих Дифференциальных бэкапов (Differential Backup) и Бэкапов журнала транзакций (Transaction Log Backup).

Обычно используется для передачи бэкапа другим лицам или просто для проверки восстановления базы данных.

BACKUP DATABASE [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_CopyOnly.bak'
WITH COPY_ONLY, INIT;

RESTORE DATABASE [YourDatabaseName]
FROM DISK = 'C:\Backups\YourDatabase_CopyOnly.bak'
WITH REPLACE;

Бэкап файлов и файловых групп (File and Filegroup Backup)

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

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

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

BACKUP DATABASE [YourDatabaseName] FILEGROUP = 'FG1'
TO DISK = 'C:\Backups\YourDatabase_FG1.bak'
WITH INIT;

BACKUP LOG [YourDatabaseName]
TO DISK = 'C:\Backups\YourDatabase_Log.trn'
WITH INIT;

RESTORE DATABASE [YourDatabaseName] FILEGROUP =  'FG1'  FROM DISK =  'C:\Backups\YourDatabase_FG1.bak'  WITH RECOVERY;

RESTORE LOG [YourDatabaseName] FROM DISK =  'C:\Backups\YourDatabase_Log.trn'  WITH RECOVERY;

PostgreSQL - Логирование действий пользователя (log_statement)

Mon, 20 May 2024 06:20:39 +0600

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

В этой статье мы рассмотрим, как включить аудит/логирование действий пользователя в PostgreSQL. Для осуществления аудита/логирования я буду использовать встроенную функцию логирования в PostgreSQL (log_statement). Также можно воспользоваться расширением pgAudit, который я рассматривал в этой статье.

Что именно логировать?

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

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

none - ничего не логировать (выключено)
ddl - операции CREATE, ALTER и DROP
mod - всё что в ddl плюс операторы изменения данных, такие как INSERT, UPDATE, DELETE, TRUNCATE, COPY FROM, PREPARE, EXECUTE, EXPLAIN ANALYZE
all - все команды

Важно отметить что все записи аудита будут повторять саму команду точь-в-точь, т.е. если log_statement = all и вы выполняете команду установки пароля для пользователя как простой текст, то в логах вы увидите этот пароль. Подробнее я рассматривать такую ситуацию тут.

Подготовка

Перед тем ка приступить к включению аудита подготовим немного наш сервер к этому.

Создадим тестовую бд

sudo -u postgres psql postgres

CREATE DATABASE exampledb;
\c exampledb
CREATE TABLE users (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
age INTEGER,
email VARCHAR(150)
);

Создадим тестового пользователя
```
CREATE  USER test with password '11111111';
```

Выдадим права пользователю

\c exampledb
GRANT CONNECT ON DATABASE exampledb TO test ;
GRANT  SELECT, INSERT, UPDATE, DELETE  ON  ALL TABLES IN SCHEMA public TO test;
GRANT USAGE, SELECT  ON  ALL SEQUENCES IN SCHEMA public TO test;
grant all ON database exampledb to test;
GRANT USAGE ON SCHEMA public TO test ;

Включаем аудит действий

Аудит можно включить, используя несколько методов:

Глобально для всех пользователей в файле postgresql.conf
Для конкретного пользователя используя команду ALTER ROLE user_name SET log_statement TO 'all';
Для конкретной бд, например ALTER DATABASE my_database SET log_statement = 'all';
Для конкретной сессии, например SET log_statement = 'all';

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

sudo vim /etc/postgresql/16/main/postgresql.conf

log_directory =  'pg_log'  -- Где хранить логи
log_filename =  'postgresql-%Y-%m-%d_%H%M%S.log' -- Имя файла с логами
log_statement = mod

sudo systemctl restart postgresql

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

sudo -u postgres psql postgres

alter role test set log_statement to 'all'

Проверяем работу аудита действий

Подключаемся к базе под пользователем test
```
psql -U test -d exampledb
```

Выполняем команду INSERT

INSERT INTO users (name, age, email) VALUES ('John Doe', 30, 'john.doe@example.com');
INSERT INTO users (name, age, email) VALUES ('John Doe', 30, 'john.doe@example.com');

В логах проверяем записи о добавлении этих двух строк

sudo vim /var/log/postgresql/postgresql-16-main.log

2024-05-20 15:31:55.826 +05 [52823] test@exampledb LOG:  statement: INSERT INTO users (name, age, email) VALUES ('John Doe', 30, 'john.doe@example.com');
2024-05-20 15:31:57.369 +05 [52823] test@exampledb LOG:  statement: INSERT INTO users (name, age, email) VALUES ('John Doe', 30, 'john.doe@example.com');

Docker Compose

Sun, 19 May 2024 06:20:39 +0600

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

Еще одно преимущество использования Docker Compose это быстрая изоляция одних контейнеров от других и связь контейнеров по сети. У меня уже есть статьи про сети и про DNS псевдонимы. Используя Docker Compose вы можете автоматически объединить несколько контейнеров в одну общую сеть и обращаться внутри сети по dns именам.

Также используя Docker Compose можно управлять и хранилищем для контейнеров.

И всё это можно получить просто, описав весь конфиг в одном файле. В качестве конфиг-файла используется yaml файл, по умолчанию имя файла docker-compose.yaml. И всё что вам нужно для работы с кучей контейнеров вы можете получить в одном файле, что даёт возможность управлять контейнеризацией быстрее и проще.

Для управление всем этим добром используется утилита docker-compose. Скорее всего вы уже слышали или еще услышите, что docker-compose не рекомендуется к использованию в боевой середе, мол только для разработки или тестов. Говорят, так потому что считается что лучше использовать для боевой среды kubernetes. И я с этим согласен, но что если вам нужно поднять всего с десяток контейнеров? Разве стоит ради этого создавать кластер kubernetes? Как по мне нет и вместо того чтобы вручную создавать каждый контейнер проще использовать docker-compose, ничего страшного я здесь не вижу.

файл docker-compose.yaml

Первое на что стоит обратить при разговоре про файл docker-compose.yaml это версионность. Файл docker-compose.yaml имеет версии, на данный момент это - 1, 2, 2.1, 3.2, 3.8. Каждая версия указывает на то какие ключи вы можете использовать при написании файла и какой синтаксис.

🥶docker-compose.yaml.version

version: '3.9'
services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example

С конца 2021 года Docker объединил Compose V2 и ввёл единый стандарт — Compose Specification. Теперь версию можно вовсе не указывать, пи обращению к файлу Docker сам определяет формат по структуре YAML-файла.

😊docker-compose.yaml

services:
  web:
    image: nginx:latest
    ports:
      - "8080:80"

  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: example

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

docker compose version

Docker Compose version v2.27.0

Если же вдруг в выводе будет версия v1.x, то у меня для вас плохие новости новые версии использовать вы не сможете и придётся указывать версию руками в файле. А вообще сидеть сейчас на старом docker-compose нет никакого смысла.

Имя файла конечно же может быть и другим, но в таком случае при использовании команды docker-compose необходимо передать имя файла используя опцию -f.

Зачастую многие разработчики софта создают уже готовый docker-compose.yaml и размещают его на github. В таком случае конечному пользователю всего лишь необходимо скачать этот файл и создать все необходимые контейнеры для работы приложения, очень удобно и быстро.

файл docker-compose.yaml

Рассмотрим базовый docker-compose.yaml, который создаст два контейнера (app, db) в одной сети backend.

Обратите внимание на отступы, если не соответствовать иерархии (отступам), то при попытке создания контейнеров вы получите ошибку. Лучше использовать редакторы с возможностью анализировать структуру yaml файлов.

🪲docker-compose.yaml

# 📦 Раздел "services" — описывает контейнеры, которые будут запущены.
services:
  app:
    image: python:3.11-slim               # образ контейнера
    container_name: myapp                 # имя контейнера (опционально, dns name)
    build:                                # если хочешь собрать из Dockerfile
      context: .                          # путь к Dockerfile
      dockerfile: Dockerfile
    command: python app.py                # команда, выполняемая при старте
    working_dir: /usr/src/app             # рабочая директория внутри контейнера
    volumes:
      - .:/usr/src/app                    # монтирование локальной папки
      - app_data:/data                    # подключение именованного volume
    ports:
      - "8080:80"                         # проброс портов (host:container)
    environment:                          # переменные окружения
      - DEBUG=True
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
    depends_on:                           # зависимости между контейнерами
      - db
    networks:                             # указание сетей
      - backend

  db:
    image: postgres:15
    restart: always                       # политика перезапуска
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: mydb
    volumes:
      - pg_data:/var/lib/postgresql/data  # подключение именованного volume
    networks:
      - backend

# 🗃️ Раздел "volumes" — хранение постоянных данных (не удаляются при stop).
volumes:
  pg_data:
  app_data:

# 🌐 Раздел "networks" — настройка сетей между контейнерами.
networks:
  backend:
    driver: bridge                        # тип сети (по умолчанию — bridge)

Создание контейнеров с помощью docker compose

Теперь когда есть готовый файл docker-compose.yaml нужно как-то создать контейнеры используя его. Для создания контейнеров используется docker compose, в более старых версиях docker-compose. Если у вас не установлен docker compose, то выполните установку docker-compose-plugin, более подробнее для RHEL и Ubuntu.

Для начала проверим что что можно сделать, используя docker compose вызвав справку ````docker compose –help```. Вот список наиболее часто используемых команд:

down - остановка и удаление контейнеров и сетей
exec - выполнение команды внутри контейнера
logs - просмотр логов контейнера
ps - просмотр списка контейнеров
pull - скачивание образа для контейнера
restart - перезапуск контейнера
start - запуск контейнера
stop - остановка контейнера
top - просмотр процессов
up - создание и запуск контейнеров

Как вы поняли из списка команды выше для создания контейнеров используется команда docker compose up.

Для начала я создам файл docker-compose.yaml с одним контейнером использующим образ nginx и выполню команду создания и запуска контейнеров.

🪲docker-compose.yaml

services:
  mynginx:
    image: nginx: 1.18
    ports: 80:80

docker compose up -d

 ⠼ Network dockerfile_default      Created                                                                                              
 ✔ Container dockerfile-mynginx-1  Started

Теперь я проверю что контейнер действительно запустился. Обратите внимание что docker compose ps и просто docker ps выведут разные списки. Дело в том, что docker compose работает только с контейнерами, которые описаны в файле.

docker compose ps

dockerfile-mynginx-1   nginx:1.18

docker ps

dockerfile-mynginx-1   nginx:1.18
ome-postgresql2				postgres:17.6

Остановка и удаление контейнеров с помощью docker compose

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

docker compose stop

 ✔ Container dockerfile-mynginx-1  Stopped

Если же нужно еще и удалить созданные контейнеры с помощью docker compose используется down, созданные volume при этом не удаляются.

docker compose down

 ✔ Container dockerfile-mynginx-1  Removed
 ✔ Network dockerfile_default      Removed

Linux - Как восстановить потерянные или удалённые данные

Fri, 17 May 2024 06:20:39 +0600

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

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

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

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

Устанавливаем Scalpel

Для восстановления удалённых данных, если они еще не перезаписаны мы будем пользоваться утилитой Scalpel.

sudo apt install scalpel

sudo yum install epel-release
sudo yum install scalpel

sudo pacman -S scalpel

Файл конфигурации

Я думаю стоит обратит отдельное внимание на файл конфигурации (/etc/scalpel.conf), так как в нём прописаны уже предустановленные типы файлов, которые вы можете восстановить. Дело в том, что Scalpel ищет только те файлы, расширение которых подпадает под настройки в файле конфигурации.

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

Для примера возьмём строку jpg y 5:200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9, где:

jpg - Расширение файла
y - Чувствительны ли верхний и нижний колонтитулы к регистру
5:200000000 - Минимальный и максимальный размер файла
\xff\xd8\xff\xe0\x00\x10 - Стандартный заголовок, идентифицирующий начало файла
\xff\xd9 - Стандартный нижний колонтитул, обозначающий конец файла

Восстанавливаем данные

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

Если вы восстанавливаете файлы с расширением, который уже есть в файле конфигурации то проблем по сути возникнуть недолжно. Например, попробуем восстановить удалённые картинки с диска /dev/sda в папку /sdb (отдельный диск).

sudo vim scalpel.conf

jpg y 5:200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9

sudo scalpel -c scalpel.conf -o /sdb/ /dev/sda

Восстанавливаем файлы txt

Вот тут уже немного посложнее, мы уже говорили, что в конфиге также указывается Стандартный заголовок и Стандартный нижний колонтитул. Это значит, что мы каким-то образом сперва должны получить эти значения для удалённого файла. Звучит немного сложно, но давайте попробуем разобраться.

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

echo "just for test" > 111.txt

Теперь получим заголовок используя утилиту head, где считаем первые 4 символов и переведём их в hex.

head --bytes 4 111.txt | hexdump -C

6a 75 73 74

Тоже самое сделаем и с концом файла, чтобы получить нижний колонтитул

tail --bytes -4 111.txt | hexdump -C

65 73 74 0a

Редактируем файл конфигурации

sudo vim scalpel.conf

txt     y       100000  \x6a\x75\x73\x74 \x65\x73\x74\x0a

Запускаем восстановление

sudo scalpel -c scalpel.conf -o /sdb/ /dev/sda

txt with header "\x6a\x75\x73\x74" and footer "\x65\x73\x74\x0a" --> 57845 files

Проверяем что в директорию /sdb восстановились файлы txt, которые начинаются со строки just for test

sudo grep -rnw /sdb1/ -e "just for test"

/sdb1/txt-0-50/00050711.txt:1:just for test

Итог

Утилита хорошая и вроде даже как её называют в интернете одной из лучших для восстановления, но вот если вы хотите восстановить файлы с расширением, которого нет в файле конфигурации и которые имеют нестандартный заголовок, который может меняться то будет немного сложно это осуществить.

Linux - Запись терминала

Sat, 04 May 2024 06:20:39 +0600

Причины для записи конечно у каждого свои, для меня, например, это запись команд для блога. В этой статье будем использовать утилиту asciinema.

Установка asciinema

Самую свежую информацию о установке можно получить на офсайте.

Debian

sudo apt install asciinema

Fedora

sudo dnf install asciinema

Ubuntu

sudo apt install asciinema

С исходников

sudo dnf -y install git
git  clone  https://github.com/asciinema/asciinema.git
cd  asciinema
git  checkout  main
python3  -m  asciinema  --version

Запись терминала

Я устанавливал с исходников, поэтому я запускаю, используя python3. Если вы установили из репозитория то команда будет выглядеть так asciinema rec /tmp/demo.cast.

python3 -m asciinema rec /tmp/demo.cast

asciinema: recording finished
asciinema: asciicast saved to /tmp/demo.cast

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

python3 -m asciinema play /tmp/demo.cast

Печатать во время этой команды ничего не получится, для выхода можно нажать CTRL+C. Это просто воспроизведение, команда не выполнится повторно.

Также можно вывести всё в текстовом виде, используя команду:

python3 -m asciinema cat /tmp/demo.cast

Конвертация

Мне лично удобнее использовать формат gif, поэтому я конвертирую полученную запись в формат gif через docker.

docker run --rm -v /tmp/:/data asciinema2/asciicast2gif -t asciinema demo.cast demo.gif

Vault - Блокировка пользователя

Wed, 03 Apr 2024 06:20:39 +0600

Как и во многих системах в Vault Hashicorp есть встроенный функционал блокировки пользователя после нескольких неудачных попыток входа. Если пользователь заблокировался, то при попытке входа он получит ошибку Authentication failed: permission denied. Как обычно пользователь блокируется на определённое время. После истечения этого времени пользователь снова может авторизоваться, если конечно введёт правильный пароль.

По умолчанию функция блокировка активна и имеет следующие пороговые значения:

количество неудачных авторизаций для блокировки - 5
продолжительность блокировки - 15 минут
сброс счетчика блокировки - 15 минут

Отключение функции блокировки пользователя

Для того чтобы отключить блокировку в целом можно запустить сервис с переменной VAULT_DISABLE_USER_LOCKOUT = true.

Или можно отключить для конкретного метода аутентификации в файле конфигурации самого Vault:

sudo vim /var/vault/config.hcl

user_lockout "userpass" { disable_lockout = "true" }

Изменить продолжительность блокировки

Опять-таки нам понадобиться отредактировать файл конфигурации самого Vault:

sudo vim /var/vault/config.hcl

user_lockout "userpass" { lockout_duration = "5m" }

Изменить количество неудачных авторизаций для блокировки

Опять-таки нам понадобиться отредактировать файл конфигурации самого Vault:

sudo vim /var/vault/config.hcl

user_lockout "userpass" { lockout_threshold  =  "25" }

Изменить значение сброса счетчика блокировки

Опять-таки нам понадобиться отредактировать файл конфигурации самого Vault:

sudo vim /var/vault/config.hcl

user_lockout "userpass" { lockout_counter_reset  =  "10m" }

Изменить значения через vault tune

Помимо редактирования файла конфигурации таже можно воспользоваться командой vault auth tune.

vault auth tune -user-lockout-threshold=25  -user-lockout-duration=5m -user-lockout-counter-reset=10m userpass/

vault read sys/auth/userpass/tune

user_lockout_disable false 
user_lockout_duration 5m 
user_lockout_threshold 25
user_lockout_counter_reset 10m

Разблокировать пользователя

О том как разблокировать пользователя можно почитать тут.

Vault - Разблокировать пользователя

Wed, 03 Apr 2024 06:20:39 +0600

Впервые столкнулся с тем что разработчик не может авторизоваться в vault. При попытке авторизоваться он получал ошибку Authentication failed: permission denied в vault.

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

Просмотр заблокированных пользователей в vault

set history +o
export token=your_token_here

curl \
    --header "X-Vault-Token: $token" \
    --request GET \
    https://vault.example.lan/v1/sys/locked-users

Если в выводе видите пользователей, то значит они заблокированы.

Разблокировать пользователя в vault

set history +o
export token=your_token_here

curl \
    --header "X-Vault-Token: $token" \
    --request POST \
    https://vault.example.lan/v1/sys/locked-users/auth_userpass_e58bede8/unlock/username_here

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

Microsoft SQL Server - Что такое xp_cmdshell

Tue, 02 Apr 2024 06:20:39 +0600

Если частенько сталкивались с бэкапом или восстановлением бд по локальной сети скорее всего вы использовали эту команду. Но использование этой команды крайне не рекомендуется. Да, всё в стиле microsoft использовать мы конечно не рекомендуем, но вот как восстановить бэкап который лежит где-то в сетевой папке и доступ к ней у конкретного пользователя без xp_cmdshell мы рассматривать не будем.

Так вот используя xp_cmdshell мы можем выполнять cmd команды в локальной системе через ms sql server, при этом от учетной записи самого ms sql server. Теперь понимаете почему не рекомендуется включать эту функцию?

Включаем xp_cmdshell

Как я говорил выше по умолчанию эта функция выключена, чтобы включить выполняем от пользователя с правами sysadmin:

-- To allow advanced options to be changed.
EXECUTE sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXECUTE sp_configure 'xp_cmdshell', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
-- To set "show advanced options" back to false
EXECUTE sp_configure 'show advanced options', 0;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO

Учётная запись прокси для xp_cmdshell

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

Если никаких прокси нет, то вы получите ошибку:

Msg 15153, Level 16, State 1, Procedure xp_cmdshell, Line 1 [Batch Start Line 10]
The xp_cmdshell proxy account information cannot be retrieved or is invalid. Verify that the '##xp_cmdshell_proxy_account##' credential exists and contains valid information.

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

EXEC sp_xp_cmdshell_proxy_account 'server\Администратор', 'pwd';

server\Администратор - собственно, пользователь у которого есть права sysadmin и который является также локальным пользователем ОС
pwd - пароль от этого пользователя

Если вдруг нужно удалить прокси:

EXEC sp_xp_cmdshell_proxy_account NULL;

Выдать разрешения на xp_cmdshell

Теперь, когда есть прокси можно разрешить пользователю выполнять команды через xp_cmdshell.

GRANT exec ON xp_cmdshell TO N'<some_user>';

Чтобы проверить что всё работает выполняем команду от пользователя some_user:

EXEC xp_cmdshell 'whoami.exe';

Vcenter - Перевыпуск сертификатов или HTTP Status 500

Mon, 01 Apr 2024 06:20:39 +0600

Если вы вдруг неожиданно получаете ошибку HTTP Status 500 – Internal Server Error vcenter при авторизации в Vcenter Server, то возможно, что причина в просроченных сертификатов.

HTTP Status 500 – Internal Server Error vcenter

Заходим на сервер по ssh и выполняем:

/usr/lib/vmware-vmca/bin/certificate-manager
- Enter proper value for ‘Hostname’ - dns имя сервера
- Enter proper value for VMCA ‘Name’ - тут либо dns имя, либо имя сервера (hostname -f)
- Yes

После выполнения команды все сервисы перезапустятся и после можно пробовать авторизоваться.

Linux - Таймаут sudo

Fri, 29 Mar 2024 06:20:39 +0600

Я использую FreeIpa, на котором подключил OTP. Да это крутая штука и улучшает безопасность в организации, но вот только если всё выполняется через sudo, то постоянно вводить этот OTP надоедает. Здесь выхода только 2:

отключить его на..р, но это не мой вариант
увеличить время запроса пароля, т.е. таймаут сессии sudo

Увеличиваем таймаут сессии sudo

Выполняем команду sudo visudo и выставляем время через переменную timestamp_timeout. Переменная принимает время в минутах, например, 10 или даже 2.5.

Можно дописать к существующей строке:

Defaults env_reset, timestamp_timeout=15

Или добавить ниже новую строку:

Defaults timestamp_timeout=15

Т.е. в итоге после ввода пароля для sudo мы можем в течении 15 минут выполнять команды без запроса пароля.

Пароль для каждой команды sudo

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

sudo visudo

Defaults timestamp_timeout=0

Grafana - Canvas Dashboard Добавляем свои собственные svg иконки

Thu, 28 Mar 2024 06:20:39 +0600

Используя canvas в Grafana можно создавать что-то подобное. Но не так уж и много информации про то, как собственно это делать.

Добавляем свои собственные svg иконки

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

Для того чтобы добавить свою иконку нужно поместить её в любую вложенную папку в директории /usr/share/grafana/public/img/icons/.

Для докера можно примонтировать локальную папку к вложенную папке в директории /usr/share/grafana/public/img/icons/.

vim docker-compose.yml

  grafana:
    volumes:
      - /grafana-bg/ico:/usr/share/grafana/public/img/icons/iot

Свои собственные svg иконки не окрашиваются

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

vim icon.svg

<path
id="path4442"
style="fill:green"  <<<<<< must be deleted
d="m430.88 592.9c6.15-10.03 15.9-17.1 25.17-24.07 0.92-0.69 1.84-1.37 2.75-2.06l0.74 0.87c-0.84 0.77-1.69 1.53-2.53 2.3-8.15 7.6-16.23 15.38-23.33 23.98l-2.8-1.02z"
/>

После этого копируем иконку снова и радуемся жизни.

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

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

Veeam Backup & Replication - WAN-ускорители

Sat, 16 Mar 2024 06:20:39 +0600

WAN-ускоритель (WAN Accelerator) – это компонент Veeam Backup & Replication, предназначенный для оптимизации передачи данных по медленным или загруженным WAN-каналам. Он снижает объем передаваемых данных за счет дедупликации и кэширования.

WAN-ускоритель — это промежуточный компонент между компонентом Veeam Data Mover источника и Veeam Data Mover конечной стороны. Как правило WAN-ускорители используются для работ с резервными копиями между удалёнными дата-центрами.

Самое главное если у вас нет под рукой лицензии Enterprise Plus то использовать этот компонент вы не сможете.

🪚Как работает WAN-ускоритель (WAN Accelerator)

При создании задачи работающей с удаленным хранилищем вы можете выбрать ускоритель в настройках.

File Digest (дайджест файл) – это уникальный хеш-суммарный идентификатор для каждого блока данных в файле резервной копии. Он помогает определить, изменился ли блок данных по сравнению с предыдущими резервными копиями.

Veeam Backup & Replication распаковывает файл резервной копии для анализа его содержимого
Служба Veeam WAN Accelerator Service на сервере с компонентном WAN Accelerator (source) анализирует блоки данных файла, который необходимо передать, и создает дайджест файл для этих блоков данных. Созданный дайджест файл сохраняется в папке VeeamWAN на исходном WAN Accelerator (source)
Veeam Backup & Replication сжимает данные файла резервной копии (для резервной копии) или данные ВМ (для репликации) и копирует их на целевую сторону (target).
В процессе передачи данных служба Veeam WAN Accelerator Service на целевом WAN-акселераторе (target) заполняет глобальное кэш-хранилище блоками данных из скопированного файла
Во время следующего цикла работы служба Veeam WAN Accelerator Service на исходном WAN-акселераторе (source) анализирует блоки данных в файле, которые необходимо передать на этот раз, и создает дайджесты для этих блоков данных.
Служба Veeam WAN Accelerator Service (source) сравнивает созданные дайджесты с дайджестами, которые были ранее сохранены в папке VeeamWAN на исходном WAN-акселераторе . Если обнаружены дублирующиеся блоки данных, фактический блок данных в файле резервной копии не копируется по WAN. Вместо этого он берется из глобального кэша и записывается в точку восстановления в папке резервной копии или на целевом томе данных.

В результате такого подхода Veeam Backup & Replication копирует только новые блоки данных в целевую сторону (target) и используется уже имеющиеся в глобальном кэше.

🛠️ Настройка WAN-ускорителей в Veeam

Для начала необходимо добавить WAN-ускоритель в инфраструктуру:

В Veeam Backup & Replication откройте Backup Infrastructure → WAN Accelerators.
Нажмите Add WAN Accelerator.
Укажите сервер и операционную систему (Windows).
Введите IP-адрес или DNS-имя сервера.
Выберите кэш-диск (нужен SSD или быстрый HDD).
Укажите размер кэша (рекомендуется не менее 100 ГБ).
Подтвердите параметры → Finish.

Теперь когда у нас есть WAN-ускоритель назначим его какому-либо заданию:

В Backup & Replication создайте новое репликационное задание.
В разделе Traffic Rules выберите WAN Accelerator.
Укажите Source WAN Accelerator (на стороне резервного копирования).
Укажите Target WAN Accelerator (на стороне получателя).
Подтвердите параметры и запустите задание.

💡 Рекомендации

Для кэширования лучше использовать SSD накопители
Размещайте WAN Accelerator как можно ближе к репозиторию

Veeam Backup & Replication - vPower NFS

Sat, 16 Mar 2024 06:20:39 +0600

Veeam vPower NFS – это сервис в Veeam Backup & Replication, который позволяет запускать виртуальные машины напрямую из резервных копий пропуская процесс восстановления. Эта технология используется при мгновенном восстановлении ВМ (Instant VM Recovery).

Как работает?

Эмуляция NFS-хранилища - сервер с компонентом vPower NFS создаёт специальную директорию - виртуальное NFS-хранилище, которое в последствии использует целевой ESXI хост
При старте задачи восстановления или проверки восстановления (SureBackup) в эту директорию копируются VMDK файлы ВМ, т.е. виртуальные диски. Эти диски продолжают находится в резервной копии и последующие манипуляции с восстанавливаемой ВМ не влияют на них.
ESXI хост подключается к созданному выше NFS-хранилищу (монтирует) и запускает виртуальную машину прямо из резервной копии. Т.е. по сути создаваемая ВМ в качестве хранилища использует NFS-хранилище.
После того как ВМ запущена пользователь может получить доступ к восстанавливаемым данным

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

Где используется

Сервис Veeam vPower NFS используется при:

Мгновенном восстановлении ВМ (Instant VM Recovery)
Автоматическая проверка целостности резервных копий (SureBackup)
Восстановление данных приложений (Universal Application-Item Recovery)
Создание тестовой среды из резервных копий (On-Demand Sandbox)

Настройка Veeam vPower NFS

Открываем консоль Veeam Backup & Replication
Переходим в Backup Infrastructure → Backup Repositories
На необходимом репозитории наживаем ПКМ → Properties
Переходим на вкладку Mount server
Выбираем директорию, где хранить кеш
Активируем галочку Enable vPower NFS
Применяем настройки и сохраняем

Veeam Backup & Replication - Установка и обновление

Sat, 16 Mar 2024 06:20:39 +0600

Для начала убедитесь что ваш сервер соответствует системным требованиям и также открыты сетевые порты.

Запуск установки

Если все рекомендации соблюдены качаем файл установщика по ссылке и запускаем процесс установки через файл Setup.exe.
В окне выбора компонентов выбираем Install Veeam Backup & Replication
Конечно же соглашаемся со всеми лицензионными соглашениями
В окне лицензирования указываем лицензию либо просто нажимаем NEXT если нет лицензии
На этом шаге установщик проверяет все ли необходимые программы установлены на сервер и ставит их при необходимости
В следующем окне выдаётся информация о настройках по умолчанию, которые вы при необходимости можете изменить. Подробнее о настройках тут.
Если всё готово нажимаем Install
В окне Service account выбираем сервисную учетную запись и нажимаем Next
Далее выбираем какой тип бд использовать и как подключаться к бд
В следующем окне идёт проверка конфигурации
В следующем окне выбираем директории для: - Путь установки - Каталог гостевой файловой системы - Instant recovery write cache - хранится кэш записи для машин, которые запускаются из резервных копий во время проверки восстановления или операций восстановления
В следующем окне можно изменить порты по умолчанию
Далее нажимаем Install и ждём пока всё установится

Запуск обновления

Перед самим обновлением необходимо удостоверится что все системные требования для новой версии соблюдены и что ваша лицензия поддерживает новую версию Veeam Backup & Replication.

Если все рекомендации соблюдены качаем файл установщика по ссылке и запускаем процесс установки через файл Setup.exe.
В окне выбора компонентов выбираем Upgrade Veeam Backup & Replication
Конечно же соглашаемся со всеми лицензионными соглашениями
Проверяем какие компоненты будут обновлены
В окне лицензирования указываем лицензию либо просто нажимаем NEXT если нет лицензии
На этом шаге установщик проверяет все ли необходимые программы установлены на сервер и ставит их при необходимости
В окне Service account выбираем сервисную учетную запись и нажимаем Next
Далее выбираем какой тип бд использовать и как подключаться к бд
В следующем окне идёт проверка конфигурации
Запускаем процесс обновления нажатием Upgrade

Если же вы хотите просто установить какой-то патч не переходя на новую версию, то просто качаете этот патч с сайта. Далее распаковываете архив на сервер с установленным Veeam Backup & Replication и нажимаете Install.

Veeam Backup & Replication - Масштабируемый репозиторий резервного копирования

Sat, 16 Mar 2024 06:20:39 +0600

Если у вас в инфраструктуре для хранения резервных копий используется множество репозиториев то компонент Масштабируемый репозиторий резервного копирования (Scale-out Backup Repository) рекомендован к использованию.

В некоторых случаях для хранения резервных копий используются различные устройства хранения, такие как локальные диски серверов, файловые хранилища, разделы на СХД и т.д. В итоге репозиториев хранения резервных копий может оказаться с несколько десятков, что конечно усложняет работу с репозиториями. например при выборе подходящего для задачи резервного копирования. Также необходимо проверять свободное место на каждом из репозиториев.

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

В итоге принимая все эти проблемы команда разработчик Veeam добавила компонент Scale-out Backup Repository, который объединяет все репозитории в один глобальный репозиторий. Для расширения этого глобального репозитория просто добавляется новый репозиторий, что-то в стиле LVM в Linux.

Также при добавлении обычного репозитория в Scale-out Backup Repository вы можете указать какой тип резервных копий должен хранится на добавляемом репозитории. Например, для инкрементальных бэкапов можно использовать быстрые all-flash хранилища.

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

🔹Примеры использования

Вариант использования	Конфигурация
Быстрое локальное резервное копирование и долгосрочное хранение	Локальные SSD-накопители (уровень производительности) + AWS S3 (емкость)
Высокоскоростное дедуплицированное резервное копирование	Устройства дедупликации (уровень производительности)
Экономичное хранение	Недорогой NAS (производительность) + Локальные диски(емкость)

🔹Ограничения

Стоит обратить внимание на некоторые ограничения при использовании Enterprise лицензии:

Вы можете создать 2 масштабируемых репозитория резервных копий
В каждый масштабируемый репозиторий можно добавить з активных репозитория и один неактивный

Ограничения выше снимаются только если вы используете лицензию Enterprise Plus.

Также вы не сможете добавить обычный репозиторий в Масштабируемый если в процессе добавления репозиторий используется, например, идёт процесс восстановления или резервного копирования.

🔹Создание Scale-out Backup Repository

Первым делом нужно убедится что обычные репозитории, которые вы хотите объединить уже добавлены в Veeam Backup & Replication.

1️⃣ На панели Inventory щелкните правой кнопкой на Scale-out Repositories и выберите Добавить масштабируемый репозиторий резервных копий (Add Scale-out Backup Repository).

2️⃣ Введите имя

3️⃣ В окне Performance Tier выберите репозитории, которые вы хотите объединить

4️⃣ В окне Placement Policy вы можете задать какой тип резервных копий хранить на конкретном репозитории

5️⃣ В окне Capacity Tier вы можете указать блочное хранилище S3 куда можно перемещать либо копировать резервные копии с Масштабируемого репозитория.

6️⃣ Нажимаем Apply и Finish

Veeam Backup & Replication - Сервер монтирования (Mount Server)

Sat, 16 Mar 2024 06:20:39 +0600

Сервер монтирования (Mount Server) - один из компонентов Veeam Backup & Replication, который используется при восстановление данных из резервных копий. Например, когда вы пытаетесь восстановить файлы, приложение или запускаете задачу проверки восстановления (SureBackup).

Сервер монтирования (Mount Server) - это промежуточное звено между репозиторием резервных копий и целевым сервером, куда необходимо восстановить данные. Считается что это помогает оптимизировать траффик. Но самое главная идея как мне кажется это то, что вы можете восстановить конкретный файл из ВМ при этом не восстанавливая полностью ВМ.

Дело в том, что при попытке восстановить файлы или приложения Veeam Backup & Replication монтирует данные с резервной копии на сервере монтирования (vPower NFS), к которым вы дальше можете получить доступ через консоль Veeam Backup & Replication. Только после того как всё смонтировано Veeam Backup & Replication получает доступ к данным и может их восстановить.

Для снижения нагрузки на локальную сеть рекомендуется размещать сервера монтирования ближе к репозиториям резервного копирования.

🅱Ключевые функции

Ускоряет восстановление на уровне файлов и приложений за счет локальной обработки резервных копий вместо передачи данных по сети, если репозиторий на том же сервере
Снижает нагрузку на Veeam Backup Server, если компонент установлен на другом сервере
Возможность восстановить конкретные файлы, не восстанавливая при этом сам ВМ

🚀Развертывание Сервера монтирования

⚡Развернуть компонент Сервер монтирования вы можете на 64-битном Windows сервере.

Для начала необходимо добавить сервер в инфраструктуру Veeam Backup & Replication:

В Backup Infrastructure нажимаем правой кнопкой мыши на Managed Servers и выбираем Add Server
Выбираем Microsoft Windows или Linux
Прописываем DNS имя или IP-адрес сервера для подключения
Указываем данные для подключения к серверу
В окне Review нажимаем Apply
Запустится процесс установки необходимого ПО на добавляемый сервер
Нажимаем Finish

Далее в процессе создания репозитория во вкладке Mount Server выбираем необходимый сервер в одноименном параметре. Если репозиторий уже добавлен, то переходим в его свойства и меняем Mount server.

Veeam Backup & Replication - Сервер шлюза (Gateway Server)

Sat, 16 Mar 2024 06:20:39 +0600

Сервер шлюза (Gateway Server) один из компонентов Veeam Backup & Replication, который используется для обмена трафиком между прокси-серверами и репозиторием резервных копий. По сути Сервер шлюза (Gateway Server) выступает в качестве посредника при передаче данных между прокси-серверами и репозиториями. Если в качестве репозитория вы используете CIFS/SMB сетевую папку или блочное хранилище, то Veeam Backup & Replication будет использовать компонент Сервер шлюза (Gateway Server) для работы с репозиторием.

Плюс использования Сервера шлюза (Gateway Server) в том, что он оптимизирует траффик кэшируя метаданные и эффективно обрабатывая соединения.

Использование компонента Сервер шлюза (Gateway Server) необходимо при использовании одного из следующих типов репозитория:

Репозиторий CIFS/SMB
Масштабируемый репозиторий резервного копирования с SMB репозиторием
Облачное хранилище/Хранилище объектов (AWS, Azure, Wasabi, S3)

📌Процесс взаимодействия

Запуск задачи резервного копирования либо восстановление
Прокси-сервер обращается к ESXI хосту, чтобы понять с каким хранилищем работать
Прокси-сервер обращается к Серверу шлюза (Gateway Server)
Сервер шлюза (Gateway Server) обращается к репозиторию
Чтение/запись метаданных и оптимизирование траффика

🅱️ Рекомендации

Не устанавливайте компонент на слабый сервер (CPU/RAM)
Сервер с компонентом Сервер шлюза (Gateway Server) должен находится максимально близко к репозиторию (одна стойка, одна подсеть и т.д.)
Естественно сервер должен иметь доступ к репозиторию
Используйте несколько Серверов шлюза (Gateway Server) для Масштабируемого репозитория
Если в качестве репозитория используется устройство с встроенной функцией дедупликации рекомендуется расположить Сервер шлюза (Gateway Server) ближе к прокси-серверу

🚀 Развертывание

Для начала необходимо добавить сервер в инфраструктуру Veeam Backup & Replication:

В Backup Infrastructure нажимаем правой кнопкой мыши на Managed Servers и выбираем Add Server
Выбираем Microsoft Windows или Linux
Прописываем DNS имя или IP-адрес сервера для подключения
Указываем данные для подключения к серверу
В окне Review нажимаем Apply
Запустится процесс установки необходимого ПО на добавляемый сервер
Нажимаем Finish

Далее в процессе создания репозитория во вкладке Share выбираем необходимый сервер в Gateway Server. Если репозиторий уже добавлен, то переходим в его свойства и меняем Gateway Server.

Veeam Backup & Replication - Виды транспорта

Fri, 15 Mar 2024 06:20:39 +0600

Транспортный метод - это метод, который использует Veeam Data Mover для того, чтобы доставить данные виртуальной машины источника на целевой хост. И конечно же время, которое необходимо для этого зависит от вида транспорта.

Для Veeam Data Mover в Veeam Backup & Replication предлагается использовать следующие виды транспорта:

Прямой доступ к хранилищу
Виртуальное устройство (HotAdd)
Сеть

Зачастую конечно используется именно сетевой вид транспорта, что не всегда выгодно в плане времени.

Veeam Data Mover, отвечающий за извлечение данных, работает на прокси-сервере VMware. Тип транспорта может быть указан в настройках прокси-сервера, указанного для конкретной задачи резервного копирования.

При настройке прокси-сервера VMware вы можете вручную установить тип транспорта или отдать это право настройки самому Veeam Backup & Replication, который автоматом выберет самый подходящий (или единственный). Для этого Veeam Backup & Replication проверит каким образом прокси-сервер может получить доступ к VMware vSphere и выберет самый оптимальный. Если прокси-сервер имеет доступ по нескольким типам транспорта, то оптимальный выбирается методом:

Прямой доступ к хранилищу
Виртуальное устройство (HotAdd)
Сеть

В таблице перечислены рекомендации по использованию того или иного метода в зависимости от используемого типа хранилища данных.

Тип хранилища данных	Прямой доступ к хранилищу	Виртуальное устройство	Сеть
Оптоволоконный канал (FC) SAN	Установите прокси-сервер VMware на физическом сервере, с доступом к хранилищу по FC	Установите прокси-сервер VMware в виртуальной машине на ESXI хосте имеющем доступ к хранилищу	Рекомендуется использовать только если скорость сети не ниже 10 Gb. Установите прокси-сервер VMware на любом сервере в локальной сети.
iSCSI SAN или NFS Storage	Установите прокси-сервер VMware на физическом сервере или виртуальной машине
Shared SAS	Установите прокси-сервер VMware на физическом сервере, с доступом к SAS
vSAN	Не поддерживается	Установите прокси-сервер VMware в виртуальной машине на ESXI хосте имеющем доступ к хранилищу vSAN
vVol		Установите прокси-сервер VMware в виртуальной машине на ESXI хосте имеющем доступ к хранилищу vVol
Local Storage		Установите прокси-сервер VMware в виртуальной машине на каждом ESXI хосте

Важное замечание если вы используете VMware Cloud в AWS единственный доступный тип - это Виртуальное устройство.

Hyperledger Fabric CA - выдача сертификатов

Mon, 04 Mar 2024 06:20:39 +0600

Для начала прочитайте про MSP и identity.

Теперь, когда мы понимаем, что к чему прейдём к схеме:

Для каждой организации у нас будет по два ЦС: rca и tls-ca
В каждой организации у нас будет по два узла
В каждой организации у нас будут пользователи: admin и user
Также у нас будет пользователь admin для ЦС, чтобы выпускать сертификаты

Установка зависимостей

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

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo dnf -y install go wget vim docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

sudo systemctl enable --now docker
sudo usermod -aG docker $USER

go install github.com/hyperledger/fabric-ca/cmd/...@latest
sudo cp /home/admin/go/bin/fabric-ca-client /usr/local/bin/

Далее в /etc/hosts прописываем dns имена чтобы не обращаться постоянно по ip. В production конечно лучше воспользоваться dns.

sudo vim /etc/hosts

172.31.144.2 rca.ordererOrg1.example.com
172.31.144.2 tls-ca.ordererOrg1.example.com
172.31.144.4 rca.org1.example.com
172.31.144.4 tls-ca.org1.example.com
172.31.144.5 rca.org2.example.com
172.31.144.5 tls-ca.org2.example.com

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

Поднимаем ЦС

В каждой организации мы запускаем контейнер с двумя ЦС.

sudo mkdir -p /usr/local/ordererOrg1 && cd /usr/local/ordererOrg1

sudo vim /usr/local/ordererOrg1/docker-compose.yaml

version: '2'

networks:
  fabric-ordererOrg1-ca:

services:
  tls-ordererOrg1:
    container_name: tls-ordererOrg1
    image: hyperledger/fabric-ca:latest
    command: sh -c 'fabric-ca-server start -d -b tlsadmin:tlspwd --csr.cn tls-ca.ordererOrg1.example.com --csr.hosts tls-ca.ordererOrg1.example.com' 
    environment:
        - FABRIC_CA_SERVER_HOME=/usr/local/hyperledger/fabric-ca/crypto
        - FABRIC_CA_SERVER_TLS_ENABLED=true
        - FABRIC_CA_SERVER_CSR_CN=tls-ordererOrg1
        - FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
        - FABRIC_CA_SERVER_DEBUG=true
        - FABRIC_CA_SERVER_PORT=7052
        - FABRIC_CA_SERVER_OPERATIONS_LISTENADDRESS=0.0.0.0:17054
        - TZ=Asia/Almaty
    volumes:
        - /usr/local/ordererOrg1/tls-ordererOrg1:/usr/local/hyperledger/fabric-ca
    networks:
        - fabric-ordererOrg1-ca
    ports:
        - 7052:7052
        
  rca-ordererOrg1:
    container_name: rca-ordererOrg1
    image: hyperledger/fabric-ca:latest
    command: sh -c 'fabric-ca-server start -d -b rcaadmin:rcapwd --csr.cn rca.ordererOrg1.example.com --csr.hosts rca.ordererOrg1.example.com'
    environment:
        - FABRIC_CA_SERVER_HOME=/usr/local/hyperledger/fabric-ca/crypto
        - FABRIC_CA_SERVER_TLS_ENABLED=true
        - FABRIC_CA_SERVER_CSR_CN=rca-ordererOrg1
        - FABRIC_CA_SERVER_CSR_HOSTS=0.0.0.0
        - FABRIC_CA_SERVER_DEBUG=true
        - FABRIC_CA_SERVER_PORT=7053
        - FABRIC_CA_SERVER_OPERATIONS_LISTENADDRESS=0.0.0.0:17055
        - TZ=Asia/Almaty
    volumes:
        - /usr/local/ordererOrg1/rca-ordererOrg1:/usr/local/hyperledger/fabric-ca
    networks:
        - fabric-ordererOrg1-ca
    ports:
        - 7053:7053

В файле мы также указываем пользователя и пароль, под которым будем выпускать сертификаты (tlsadmin, tlspwd, rcaadmin, rcapwd). Думаю, понятно, что эти значения нужно заменить на свои, также, как и dns имена rca.ordererOrg1.example.com, tls-ca.ordererOrg1.example.com.

После того, как файл создан можем приступать к запуску контейнеров с ЦС.

sudo docker-compose -f /usr/local/ordererOrg1/docker-compose.yaml up -d
sudo docker ps

a2d4c7e94316   hyperledger/fabric-ca:latest 0.0.0.0:7053->7053/tcp, :::7053->7053/tcp, 7054/tcp   rca-ordererOrg1
88810b59d9a8   hyperledger/fabric-ca:latest 0.0.0.0:7052->7052/tcp, :::7052->7052/tcp, 7054/tcp   tls-ordererOrg1

Также мы поступаем и со всеми остальными ЦС, просто меняем пароли и dns имена в файле docker-compose.yaml.

Данные корневого сертификата

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

cd /usr/local/ordererOrg1
sudo vim rca-ordererOrg1/crypto/fabric-ca-server-config.yaml
sudo vim tls-ordererOrg1/crypto/fabric-ca-server-config.yaml

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

'expiry: 8760h' >>>>> 'expiry: 87600h'
'expiry: 43800h' >>>>> 'expiry: 87600h'

Удаляем контейнеры, я добавил volumes а значит важные данные останутся.

sudo docker-compose -f /usr/local/ordererOrg1/docker-compose.yaml down
cd /usr/local/ordererOrg1/tls-ordererOrg1/crypto
sudo rm ca-cert.pem tls-cert.pem

И снова запускаем ЦС, сертификаты пересоздадутся.

sudo docker-compose -f /usr/local/ordererOrg1/docker-compose.yaml up -d
sudo docker ps

openssl x509 -in ca-cert.pem -text -noout | grep 'Not After'

Not After : Feb 25 11:16:00 2039 GMT

Выпускаем сертификат админа ЦС

Помните я говорил о том что в файле docker-compose.yaml задаётся логин и пароль? Так вот используя как раз этот логин и пароль мы получаем сертификат админа ЦС, который дальше будем использовать для генерации сертификатов другим узлам и пользователям в организации.

cd /usr/local/ordererOrg1/tls-ordererOrg1
sudo chown -R admin  /usr/local/ordererOrg1
sudo mkdir admin && cd admin

export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/tls-cert.pem
export FABRIC_CA_CLIENT_HOME=.
fabric-ca-client enroll -d -u https://tlsadmin:tlspwd@tls-ca.ordererOrg1.example.com:7052

ls -la

-rwxr-xr-x. 1 admin admin 7173 Feb 29 17:40 fabric-ca-client-config.yaml
drwx------. 6 admin admin  122 Feb 29 17:40 msp

Тоже самое мы выполняем для rca-ca.ordererOrg1.example.com.

cd /usr/local/ordererOrg1/rca-ordererOrg1
sudo mkdir admin && cd admin
sudo chown -R admin  /usr/local/ordererOrg1

export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=.
fabric-ca-client enroll -d -u https://rcaadmin:rcapwd@rca.ordererOrg1.example.com:7053

ls -la

-rwxr-xr-x. 1 admin admin 7173 Feb 29 17:40 fabric-ca-client-config.yaml
drwx------. 6 admin admin  122 Feb 29 17:40 msp

Для всех остальных организаций (org1, org2) в таком же порядке выпускаем сертификаты для администраторов.

Регистрируем сертификаты

В статье про MSP и identity я писал для чего нужны сертификаты.

rca.ordererOrg1.example.com

Нам понадобятся сертификаты админа ЦС, которые мы выпускали выше поэтому. Каталог, в котором они хранятся передаётся через FABRIC_CA_CLIENT_HOME.

cd /usr/local/ordererOrg1/rca-ordererOrg1/admin

export caUrl=rca.ordererOrg1.example.com:7053
export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=.

fabric-ca-client register -d --id.name orderer1-ordererOrg1 --id.secret orderer1PWD --id.type orderer -u https://$caUrl
fabric-ca-client register -d --id.name orderer2-ordererOrg1 --id.secret orderer2PWD --id.type orderer -u https://$caUrl
fabric-ca-client register -d --id.name admin-ordererOrg1 --id.secret adminPWD --id.type admin -u https://$caUrl

tls-ca.ordererOrg1.example.com

cd /usr/local/ordererOrg1/tls-ordererOrg1/admin/

export caUrl=tls-ca.ordererOrg1.example.com:7052
export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=.

fabric-ca-client register -d --id.name orderer1-ordererOrg1 --id.secret orderer1PWD --id.type orderer -u https://$caUrl
fabric-ca-client register -d --id.name orderer2-ordererOrg1 --id.secret orderer2PWD --id.type orderer -u https://$caUrl
fabric-ca-client register -d --id.name admin-ordererOrg1 --id.secret adminPWD --id.type admin -u https://$caUrl

tls-ca.org1.example.com

Для организации org1 мы делаем тоже самое, только меняем id.type и еще добавляем пользователя user, от которого рекомендуется запускать функции смарт-контракта.

cd /usr/local/org1/tls-org1/admin/

export caUrl=tls-ca.org1.example.com:7052
export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=.

fabric-ca-client register -d --id.name peer1-org1 --id.secret peer1PWD --id.type peer -u https://$caUrl
fabric-ca-client register -d --id.name peer2-org1 --id.secret peer2PWD --id.type peer -u https://$caUrl
fabric-ca-client register -d --id.name admin-org1 --id.secret adminPWD --id.type admin -u https://$caUrl
fabric-ca-client register -d --id.name user-org1 --id.secret userPWD --id.type client -u https://$caUrl

Для организации org2 делаем тоже самое, конечно меняя имя организации с org1 на org2.

rca.org1.example.com

cd /usr/local/org1/rca-org1/admin

export caUrl=rca.org1.example.com:7053
export FABRIC_CA_CLIENT_TLS_CERTFILES=../crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=.

fabric-ca-client register -d --id.name peer1-org1 --id.secret peer1PWD --id.type peer -u https://$caUrl
fabric-ca-client register -d --id.name peer2-org1 --id.secret peer2PWD --id.type peer -u https://$caUrl
fabric-ca-client register -d --id.name admin-org1 --id.secret adminPWD --id.type admin -u https://$caUrl
fabric-ca-client register -d --id.name user-org1 --id.secret userPWD --id.type client -u https://$caUrl

Для организации org2 делаем тоже самое, конечно меняя имя организации с org1 на org2.

Выпускаем сертификаты

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

cd /usr/local/ordererOrg1
mkdir -p msp/{cacerts,tlscacerts} orderers/orderer{1,2} users/admin-ordererOrg1

Сертификаты для orderer

export FABRIC_CA_CLIENT_TLS_CERTFILES=/usr/local/ordererOrg1/tls-ordererOrg1/admin/msp/cacerts/tls-ca-ordererOrg1-example-com-7052.pem
export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/orderers/orderer1.ordererOrg1.example.com
export FABRIC_CA_CLIENT_MSPDIR=tls-msp
export caUrl=tls-ca.ordererOrg1.example.com:7052

fabric-ca-client enroll -d -u https://orderer1-ordererOrg1:orderer1PWD@$caUrl --enrollment.profile tls --csr.hosts orderer1.ordererOrg1.example.com --csr.hosts orderer1.ordererOrg1 --csr.hosts localhost

export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/orderers/orderer2.ordererOrg1.example.com
fabric-ca-client enroll -d -u https://orderer2-ordererOrg1:orderer2PWD@$caUrl --enrollment.profile tls --csr.hosts orderer2.ordererOrg1.example.com --csr.hosts orderer2.ordererOrg1 --csr.hosts localhost

export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/users/admin-ordererOrg1
fabric-ca-client enroll -d -u https://admin-ordererOrg1:adminPWD@$caUrl --enrollment.profile tls

export FABRIC_CA_CLIENT_TLS_CERTFILES=/usr/local/ordererOrg1/rca-ordererOrg1/admin/msp/cacerts/rca-ordererOrg1-example-com-7053.pem
export FABRIC_CA_CLIENT_MSPDIR=msp
export caUrl=rca.ordererOrg1.example.com:7053
export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/orderers/orderer1.ordererOrg1.example.com

fabric-ca-client enroll -d -u https://orderer1-ordererOrg1:orderer1PWD@$caUrl

export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/orderers/orderer2.ordererOrg1.example.com
fabric-ca-client enroll -d -u https://orderer2-ordererOrg1:orderer2PWD@$caUrl

export FABRIC_CA_CLIENT_HOME=/usr/local/ordererOrg1/users/admin-ordererOrg1
fabric-ca-client enroll -d -u https://admin-ordererOrg1:adminPWD@$caUrl

По умолчанию некоторые сертификаты имеют не особо удобочитаемый формат. Поэтому переименуем их для удобства.

cd /usr/local/ordererOrg1
cp orderers/orderer1.ordererOrg1.example.com/tls-msp/tlscacerts/tls-tls-ca-ordererOrg1-example-com-7052.pem orderers/orderer1.ordererOrg1.example.com/tls-msp/tlscacerts/tls-ca-cert.pem
cp orderers/orderer2.ordererOrg1.example.com/tls-msp/tlscacerts/tls-tls-ca-ordererOrg1-example-com-7052.pem orderers/orderer2.ordererOrg1.example.com/tls-msp/tlscacerts/tls-ca-cert.pem

cp orderers/orderer1.ordererOrg1.example.com/tls-msp/keystore/f0b1b8b10a3017a5f5c52a4f0d19bef23f5811036102c61b0c4d19cf36836b88_sk orderers/orderer1.ordererOrg1.example.com/tls-msp/keystore/tls-key.pem
cp orderers/orderer2.ordererOrg1.example.com/tls-msp/keystore/71d960ff3dad8dc1c8148e1d618f41c85474a40135d4886f416631458acf6fea_sk orderers/orderer2.ordererOrg1.example.com/tls-msp/keystore/tls-key.pem

cp orderers/orderer1.ordererOrg1.example.com/msp/cacerts/rca-ordererOrg1-example-com-7053.pem orderers/orderer1.ordererOrg1.example.com/msp/cacerts/ca-cert.pem
cp orderers/orderer2.ordererOrg1.example.com/msp/cacerts/rca-ordererOrg1-example-com-7053.pem orderers/orderer2.ordererOrg1.example.com/msp/cacerts/ca-cert.pem

cp orderers/orderer1.ordererOrg1.example.com/msp/keystore/2806edd93b6fde172553c93a463a3f44e814f3dc6d547cf60d868a71cc16ff7a_sk orderers/orderer1.ordererOrg1.example.com/msp/keystore/key.pem
cp orderers/orderer2.ordererOrg1.example.com/msp/keystore/0e19f9860d55f1de8ae22b72fba32ad43def7a48c22532c86c1c930ab10be3d3_sk orderers/orderer2.ordererOrg1.example.com/msp/keystore/key.pem

Также нужно будет скопировать сертификаты ЦС в одну директорию, msp директорию всех организаций собираются в одном месте чтобы создать нулевой блок канала. Не беспокойтесь там только публичные сертификаты.

cd /usr/local/ordererOrg1
cp orderers/orderer1.ordererOrg1.example.com/msp/cacerts/ca-cert.pem msp/cacerts/ca-cert.pem
cp orderers/orderer1.ordererOrg1.example.com/tls-msp/tlscacerts/tls-ca-cert.pem msp/tlscacerts/tls-ca-cert.pem

Сертификаты для peer

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

Создаём файл config.yaml

Если не понятно зачем он нужен, то можно почитать про MSP.

vim orderers/orderer1.ordererOrg1.example.com/msp/config.yaml

NodeOUs:
  Enable: true
  ClientOUIdentifier:
    Certificate: cacerts/ca-cert.pem
    OrganizationalUnitIdentifier: client
  PeerOUIdentifier:
    Certificate: cacerts/ca-cert.pem
    OrganizationalUnitIdentifier: peer
  AdminOUIdentifier:
    Certificate: cacerts/ca-cert.pem
    OrganizationalUnitIdentifier: admin
  OrdererOUIdentifier:
    Certificate: cacerts/ca-cert.pem
    OrganizationalUnitIdentifier: orderer

cp orderers/orderer1.ordererOrg1.example.com/msp/config.yaml orderers/orderer2.ordererOrg1.example.com/msp/config.yaml
cp orderers/orderer1.ordererOrg1.example.com/msp/config.yaml msp/

Эту процедуру нужно будет сделать и для всех других организаций, например:

cd /usr/local/org1
cp peers/peer1/msp/config.yaml peers/peer2/msp/config.yaml
cp eers/peer1/msp/config.yaml msp/

Теперь всё готово для запуска узлов организаций.

Hyperledger Fabric - что такое Identity (личность)

Thu, 29 Feb 2024 06:20:39 +0600

Блокчейн сеть в Hyperledger включает в себя различных участников: пиры (peers), заказчики (orderers), клиентские приложения, администраторы и т.д. Каждый из этих элементов сети имеет свой собственный цифровой идентификатор - X.509 сертификат. Этот идентификатор очень важен так как благодаря ему понятно какие права есть в сети у того или иного участника сети и действительно ли он тот, за кого себя выдаёт.

Так как это работает?

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

Правило 1: Не важно сколько у вас карт и сколько в общем денег, не все карты одобрены.

Если перевести это правило в Hyperledger:

Центр сертификации PKI выступает в роли поставщика карт (выдает сертификаты множеству узлов, пользователей и т.д.)
MSP - список карт, которыми вы можете оплатить (список организаций)

Что такое PKI?

Инфраструктура открытых ключей (PKI) это набор технологий, который обеспечивает безопасную связь в сети. В частности, благодаря этой PKI появился HTTPS. Благодаря PKI вы можете быть уверены в валидности источника.

Если рассматривать картинку выше тут есть основной центр сертификации, который выдаёт человеку сертификат. Основная идея в том, что это не просто ЦС в локальной сети, а доверенный (например, закреплённый законом). И для того чтобы получить сертификат пользователь ввёл о себе всю необходимую информацию, подтверждая, что это он. И конечно ЦС всё тщательно проверил перед тем как выдать этот сертификат.

Технология блокчейн также опирается на PKI для обеспечения безопасной коммуникации между узлами в сети.

Правило 2: Не всем ЦС можно доверять.

4 основных элемента PKI:

Как мы уже поняли во главе всего стоит центр сертификации
Пара закрытого и открытого ключа (берётся с сертификата)
Сам сертификат, выданный центром сертификации
Списки отзыва сертификатов

В этой статье мы просто бегло пробежимся по всем элементам, просто для понимания как это работает.

Сертификаты (Цифровые сертификаты)

Цифровой сертификат - это цифровой документ, который содержит множество атрибутов, связанных с владельцем. В Hyperledger каждый сертификат соответствует стандарту X.509. Если есть желание поковыряться в стандарте.

Для примера представим ситуацию что Гогиев Гога имеет свой собственный электронный сертификат. При этом он работает в org1, в отделе разработки и живёт в великолепной стране - Казахстан. Так вот при запросе сертификата он обозначил следующие данные: C=KZ, ST=Astana, O=org1, OU=Developers, CN=Гогиев Гога. Конечно он мог написать какую-то чушь, но тогда центр сертификации просто отклонил бы его заявку, и он остался без сертификата.

Всё что он заполнил хранится в сертификате, собственно подтверждая своего владельца. Для просмотра содержимого сертификата можно выполнить openssl x509 -in personal.crt -text -noout

openssl x509 -in personal.crt -text -noout | grep Subject

Subject: C = KZ, ST = Astana, L = Astana, O = org1, OU = Developers, CN = Goga Gogiyev, emailAddress = goga@org1.com

И самое главное подделать этот сертификат не получится, так как присутствует приватный (закрытый) ключ, который использовался для генерации сертификата. Поэтому если вы экспортируете этот приватный ключ желательно его не терять.

Правило 3: Никогда не отдавайте свой сертификат третьим лицам.

Аутентификация, открытые ключи и закрытые ключи

Для того, чтобы обменятся сообщениями узлы в сети должны пройти аутентификацию. Это необходимо чтобы все узлы в сети были уверенны в том, что они коммуницируют с действительно тем узлом. Т.е. узел, который, например, выдаёт себя за peer1.org3 является им. Если же мы продолжаем примера с Гогой, то допустим он отправил вам файл с секретной информацией. И вот чтобы вы не сомневались, что это его сообщение он подписал его своим приватным ключом. Тем самым подтверждая свою личность.

Традиционные механизмы аутентификации основаны на цифровых подписях, которые позволяют узлам (пользователям) подписывать свои сообщения цифровой подписью (приватный ключ). Цифровые подписи также обеспечивают гарантии целостности подписанного сообщения.

Мы уже говорили, что один из основных элементов PKI это закрытый (private) и открытый (public) ключ. Так вот если возвращаться к примеру, то Гога подписал свой файл приватным ключом и отправил файл другому человеку. Человек получив файл должен ещё проверить что файл действительно от Гоги. Для этого ему понадобится публичный сертификат (ключ) Гоги, который Гога ему любезно предоставил ещё ранее.

Гога подписывает файл приватным ключом

echo "Очень секрктая информация" > message.txt
openssl dgst -sha256 -sign goga_private.key -out signature.sha256 message.txt

Вторая сторона, получив файл проверяет что подписано именно Гогой

openssl dgst -sha256 -verify public.pem -signature signature.sha256 message.txt

Verified OK

Хорошо мы проверили что файл действительно от Гоги, но что если его изменили? Для того, чтобы такого не было Гога при подписи создал файл signature.sha256, который был сгенерирован тоже при помощи приватного ключа. Конечно же Гога передал этот файл вместе с секретным файлом. Давайте попробуем внести изменения в файл и снова проверить его.

echo "Кто-то что-то поменял" >> message.txt
openssl dgst -sha256 -verify public.pem -signature signature.sha256 message.txt

Verification Failure

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

Важный момент если кто-то раньше генерировал Hash файла может подумать что это именно он содержится в файле signature.sha256, но это не совсем так. Да там хэш файла, но также подписанный (зашифрованный) приватным ключом.

Правило 4: Никогда не отдавайте свой приватный ключ третьим лицам.

Центр сертификации

Не раз уже упоминал о нём в своих статьях про Hyperledger, так как является основным компонентом. Как вы уже поняли узел или пользователь может коммуницировать с остальными узлами в сети используя цифровой сертификат. Так вот выдают эти сертификаты в Hyperledger именно центры сертификации. Рекомендуется использовать свой центр сертификации для каждой организации, даже по два. Сертификаты, выдаваемые ЦС соответствуют стандарту X.509.

В интернете очень много доверенных ЦС: GeoTrust, DigiCert, GoDaddy, Comodo, Sectigo и т.д. Мы сейчас не будем затрагивать тему кто решил, что они доверенные, об этом писать долго.

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

Корневые центры сертификации, промежуточные центры сертификации и цепочки доверия

Сами ЦС можно разделить на два вида:

Корневой (Root)
Промежуточный (Intermediate)

Представьте себе ситуации что вы владеете ЦС и вам нужно выдать сертификаты миллионам людей. Согласитесь, что для одной организации — это будет слишком сложно? Так вот один из выходов — это найти дочерние организации, выдать им сертификаты от своего ЦС и дать право раздавать сертификаты другим лица. В такой схеме ваш ЦА будет корневым (root) а все дочерние ЦС будут уже промежуточными (Intermediate).

Второй вариант для чего использовать корневой ЦС и промежуточный это безопасность. Идея в том, что вы выпускаете сертификат для промежуточного ЦС используя корневой ЦС. Далее корневой ЦС выключается и включается только по необходимости. Тут вы оберегаете свой корневой ЦС от кибератак, а если вдруг ваш промежуточный взломали вы просто включаете корневой ЦС и отзываете сертификаты промежуточного ЦС, в таком случае все сертификаты выданные промежуточным ЦС станут не валидными. Ну и опять-таки если у вас десятки промежуточных ЦС взломав один злоумышленник получит к 100-1000 сертификатам вместо миллионов.

Fabric CA

Теперь, когда мы понимаем насколько важны цифровые сертификаты и центры сертификации, которые их выдают понятное дело, что не использовать их не получится. Так вот чтобы было проще с выпуском сертификатов конечному пользователю Hyperledger добавил компонент Fabric CA. С помощью него вы легко можете поднять для своей организации ЦС и выдавать сертификаты узлам или пользователем в сети. Но если вы хотите использовать его и для выдачи SSL сертификатов для своего сайта, то не получится.

Списки отзыва сертификатов

Я уже упоминал что сертификаты можно отозвать и отозванный сертификат перестанет быть валидным. Но как конечный пользователь должен понять, что сертификат не валидный? Для этого используется список отзыва сертификатов - по сути просто список с сертификатами, которые отозвал ЦС по разным причинам. Да, причины обычно указываются. Если возвращаться к примеру, с кредитными картами, то можно представить список отзыва сертификатов как список с утерянными или украденными картами.

Теперь как конечный пользователь перед тем как проверить личность используя цифровой сертификат сначала обращается к спискам отзыва сертификатов ЦС, который выдал этот сертификат. Как правило это ссылка в интернете, которая прописана в самом цифровом сертификате. И если сертификат находится в этом списке пользователь получит об этом сообщение.

Правило 4: CRL должен быть доступен для всех пользователей.

Теперь, когда вы прочитали эту статью, рекомендую также к прочтению статью про MSP.

Автор черпал знания с сайта https://hyperledger-fabric.readthedocs.io/.

Openssl - Собираем сертификат pfx из публичного (pem) и приватного сертификата (key)

Wed, 28 Feb 2024 06:20:39 +0600

Для начала проверим что у нас стоит Openssl. В linux он как правило стоит по умолчанию, если используете windows, то можно скачать тут.

Собираем сертификат

Для того чтобы собрать pfx сертификат:

.\openssl.exe pkcs12 -export -out e1.pfx -inkey 1.key -in 1.pem

IIS - Сетевой пароль указан неверно

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

Проверить алгоритмы можно командой:

.\openssl.exe pkcs12 -in .\e1.pfx -info | findstr "PKCS7 Encrypted data"

MAC: sha256, Iteration 2048
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256

Следующая команда скорее всего исправит эту ошибку:

.\openssl.exe pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -out e1.pfx -inkey 1.key -in 1.pem
.\openssl.exe pkcs12 -in .\e1.pfx -info | findstr "PKCS7 Encrypted data"

MAC: sha1, Iteration 2048
PKCS7 Encrypted data: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

Если не помогло, то:

.\openssl.exe pkcs12 -macalg SHA1  -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -out e1.pfx -inkey 1.key -in 1.pem

Linux - Смена часового пояса в Казахстане на UTC +5

Wed, 28 Feb 2024 06:20:39 +0600

В общем в нашей стране, а именно в Казахстане правительство решило, что негоже иметь несколько часовых поясов. Тут сугубо технический блог, не политический поэтому пишу только о том, как попытаться минимизировать проблемы при переходе с UTC +6 на UTC +5.

Определяем текущий часовой пояс

timedatectl

В выдаче вы получите текущий часовой пояс. В моём случае:

Time zone: Asia/Almaty (+06, +0600)

В выводе мы видим +06. Не начинайте паниковать это ещё не значит, что, когда всё переведут на UTC +5 ваши сервера будут впереди на час.

История изменений часового пояса

Следующая команда покажет нам историю изменений часового пояса.

zdump -v Asia/Almaty

Asia/Almaty  Sat Mar 30 20:00:00 2002 UTC = Sun Mar 31 03:00:00 2002 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 26 19:59:59 2002 UTC = Sun Oct 27 02:59:59 2002 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 26 20:00:00 2002 UTC = Sun Oct 27 02:00:00 2002 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 29 19:59:59 2003 UTC = Sun Mar 30 01:59:59 2003 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 29 20:00:00 2003 UTC = Sun Mar 30 03:00:00 2003 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 25 19:59:59 2003 UTC = Sun Oct 26 02:59:59 2003 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 25 20:00:00 2003 UTC = Sun Oct 26 02:00:00 2003 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 27 19:59:59 2004 UTC = Sun Mar 28 01:59:59 2004 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 27 20:00:00 2004 UTC = Sun Mar 28 03:00:00 2004 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 30 19:59:59 2004 UTC = Sun Oct 31 02:59:59 2004 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 30 20:00:00 2004 UTC = Sun Oct 31 02:00:00 2004 +06 isdst=0 gmtoff=21600
Asia/Almaty  Thu Feb 29 17:59:59 2024 UTC = Thu Feb 29 23:59:59 2024 +06 isdst=0 gmtoff=21600

Если вы в конце не видите +05, как в моём случае, то вам всего лишь нужно обновить пакет tzdata.

Обновляем tzdata

Rhel, CentOS, Fedora, AlmaLinux, Rocky

sudo yum -y update tzdata
sudo dnf -y update tzdata

Ubuntu

wget http://archive.ubuntu.com/ubuntu/pool/main/t/tzdata/tzdata_2024a-1ubuntu1_all.deb
sudo dpkg -i tzdata_2024a-1ubuntu1_all.deb

Debian

wget https://ftp.debian.org/debian/pool/main///t/tzdata/tzdata_2024a-1_all.deb
sudo dpkg -i tzdata_2024a-1ubuntu1_all.deb

История изменений часового пояса

Следующая команда покажет нам историю изменений часового пояса.

zdump -v Asia/Almaty

Asia/Almaty  Sat Mar 30 20:00:00 2002 UTC = Sun Mar 31 03:00:00 2002 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 26 19:59:59 2002 UTC = Sun Oct 27 02:59:59 2002 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 26 20:00:00 2002 UTC = Sun Oct 27 02:00:00 2002 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 29 19:59:59 2003 UTC = Sun Mar 30 01:59:59 2003 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 29 20:00:00 2003 UTC = Sun Mar 30 03:00:00 2003 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 25 19:59:59 2003 UTC = Sun Oct 26 02:59:59 2003 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 25 20:00:00 2003 UTC = Sun Oct 26 02:00:00 2003 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 27 19:59:59 2004 UTC = Sun Mar 28 01:59:59 2004 +06 isdst=0 gmtoff=21600
Asia/Almaty  Sat Mar 27 20:00:00 2004 UTC = Sun Mar 28 03:00:00 2004 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 30 19:59:59 2004 UTC = Sun Oct 31 02:59:59 2004 +07 isdst=1 gmtoff=25200
Asia/Almaty  Sat Oct 30 20:00:00 2004 UTC = Sun Oct 31 02:00:00 2004 +06 isdst=0 gmtoff=21600
Asia/Almaty  Thu Feb 29 17:59:59 2024 UTC = Thu Feb 29 23:59:59 2024 +06 isdst=0 gmtoff=21600
Asia/Almaty  Thu Feb 29 18:00:00 2024 UTC = Thu Feb 29 23:00:00 2024 +05 isdst=0 gmtoff=18000

Если в выводе вы видите последнюю строку вы счастливчик и время переведётся автоматом.

Ничего не поменялось

Если у вас совсем старая ОС, то и обновлений скорее под неё уже нет. В таком случае придётся просто выставлять другой регион с UTC +5.

timedatectl set-timezone Asia/Aqtau
timedatectl

Linux - Смена директорий по умолчанию MsSql Server 2022

Fri, 02 Feb 2024 06:20:39 +0600

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

Создаём директории

Я уже привык не хранить важные данные в директориях по умолчанию. Я считаю правильное монтировать отдельные диски и уже там хранить данные.

Поэтому у меня в системе присутствуют три отдельных диска:

/dev/sdj - для файлов бд (/datavolume)
/dev/sdk - для логов (/logvolume)
/dev/sdl - для временных бд (/tempdb)

Для каждого раздела создадим директории в корне.

sudo mkdir -p /datavolume/data /logvolume/log /tempdb/temp
sudo chown mssql:mssql -R /datavolume /logvolume /tempdb
sudo chmod -R 770 /datavolume /logvolume /tempdb
sudo ls -la /datavolume /logvolume /tempdb

Подготовим разделы

Сам Microsoft рекомендует использовать файловую систему xfs. Если не понятно, что я делаю советую почитать.

sudo parted /dev/sdj mklabel gpt
sudo parted /dev/sdk mklabel gpt
sudo parted /dev/sdl mklabel gpt

sudo parted /dev/sdj mkpart primary xfs 0% 100%
sudo parted /dev/sdk mkpart primary xfs 0% 100%
sudo parted /dev/sdl mkpart primary xfs 0% 100%

sudo mkfs.xfs /dev/sdj1 -f -L datavolume
sudo mkfs.xfs /dev/sdk1 -f -L logvolume
sudo mkfs.xfs /dev/sdl1 -f -L tempdb

Также рекомендуется выставить атрибут noatime в fstav. Атрибут noatime не позволяет файловой системе обновлять время доступа (atime) к файлам при каждом их чтении.

sudo vim /etc/fstab

UUID=934660c3---b5af-/datavolume             xfs     rw,attr2,noatime                      0 0
UUID=f57711d6-aaad---/logvolume              xfs     rw,attr2,noatime                      0 0
UUID=-8cbb--9377- /tempdb                 xfs     rw,attr2,noatime                      0 0

sudo mount -a
df -h

Указываем директории для хранения по умолчанию в MsSQL Server 2022

На самом сервере с MsSQL выполняем:

sudo setenforce 0
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /logvolume/log
sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /datavolume/data
sudo setenforce 1
sudo systemctl restart mssql-server

Также можно прописать директории в конфиг файле:

sudo vim /var/opt/mssql/mssql.conf

[filelocation]
defaultdatadir = /datavolume/data
defaultlogdir = /logvolume/log

Пробуем создать бд (да, sa должен быть отключен, но у меня тест)

sqlcmd -S localhost -U sa -C

CREATE DATABASE [dsads] CONTAINMENT = NONE  ON  PRIMARY ( NAME = N'dsads', FILENAME = N'/datavolume/data/dsads.mdf' , SIZE = 8192KB , FILEGROWTH = 65536KB )  LOG ON ( NAME = N'dsads_log', FILENAME = N'/logvolume/log/dsads_log.ldf' , SIZE = 8192KB , FILEGROWTH = 65536KB )
GO

И тут я получил ошибку:

Validation error on setting 'filelocation.defaultdatadir' '/datavolume/data' is not a valid directory

Начинаем искать логи

Естественно идём в /var/log/messages и видим:

Feb  1 10:52:21 gr-db-56-165 sqlservr[32954]: #0152024-02-01 10:52:21.39 spid51      Failed to get the volume information, -1073741772
Feb  1 10:52:21 gr-db-56-165 sqlservr[32954]: #0152024-02-01 10:52:21.39 spid51      Failed to get the volume information, -1073741772
Feb  1 10:52:21 gr-db-56-165 sqlservr[32954]: #0152024-02-01 10:52:21.39 spid51      Error: 5123, Severity: 16, State: 1.
Feb  1 10:52:21 gr-db-56-165 sqlservr[32954]: #0152024-02-01 10:52:21.39 spid51      CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file '/datavolume/data/dsads.mdf'.

Понятное дело, что первым делом нужно отрубить selinux и попробовать еще раз. И если бд создалась, то нужно добавить правило для selinux.

Правило для selinux

Проверим что у нас есть на mssql:

sudo tail -f /var/log/audit/audit.log | grep mssql

type=AVC msg=audit(1706764257.978:13060): avc:  denied  { read } for  pid=34201 comm="Wt-760" name="/" dev="sdj1" ino=128 scontext=system_u:system_r:mssql_server_t:s0

Проверим какое правила можно создать:

sudo dnf install policycoreutils-python-utils
sudo audit2allow -a

#============= mssql_server_t ==============

#!!!! This avc is allowed in the current policy
allow mssql_server_t unlabeled_t:dir { add_name getattr open read remove_name search write };

#!!!! This avc is allowed in the current policy
allow mssql_server_t unlabeled_t:file { create getattr lock open read unlink write };

Создаём правило и применяем его:

sudo grep mssql_server_t /var/log/audit/audit.log | sudo audit2allow -M mssql_server_t
sudo semodule -i mssql_server_t.pp
sudo systemctl restart mssql-server

После этого всё должно работать. Немного подробнее о создании правила для selinux можно почитать тут.

MsSql Server 2022 - Установка на Linux

Fri, 02 Feb 2024 06:20:39 +0600

Рассмотрим как установить MsSql Server 2022 на Linux.

Для начала скажу что это уже официально возможно, не какой-то тестовый вариант, а прям production.

Репозиторий

Для начала добавим репозиторий:

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/8/mssql-server-2022.repo
curl https://packages.microsoft.com/config/rhel/9/prod.repo | sudo tee /etc/yum.repos.d/mssql-release.repo

Установка

Собственно начнем установку MsSql Server 2022:

sudo yum install -y mssql-tools18 unixODBC-devel mssql-server openldap-compat compat-openssl11

Корневая директория

По умолчанию все исполняемые файлы находятся в директории /opt/mssql/bin/. Чтобы каждый раз не искать этот путь можно сразу добавить в PATH.

echo 'export PATH="$PATH:/opt/mssql-tools18/bin"' >> ~/.bashrc
echo 'export PATH="$PATH:/opt/mssql/bin/"' >> ~/.bashrc
source ~/.bashrc

Первоначальная настройка

Для того чтобы стартануть сервис нам необходимо для начала задать тип лицензии и пароль от пользователя sa.

sudo /opt/mssql/bin/mssql-conf setup

В итоге получаем:

Setup has completed successfully. SQL Server is now starting.

Last errno text: Permission denied

Если получаете эту ошибку – то на время установки можно отключить selinux:

sudo setenforce 0
sudo /opt/mssql/bin/mssql-conf setup
sudo setenforce 1

Настраиваем firewall

Чтобы клиент мог подключаться выполняем:

sudo firewall-cmd --zone=public --add-port=1433/tcp --permanent
sudo firewall-cmd --reload

Veeam Backup & Replication - Все методы развертывания

Tue, 30 Jan 2024 06:20:39 +0600

В этой статье распишу о том какие методы развертывания Veeam Backup & Replication можно использовать для своей инфраструктуры. Каждый из них имеет свои преимущества и недостатки.

Простое развертывание

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

Если у вас небольшая инфраструктура, то вы можете воспользоваться методом простого развертывания Veeam Backup & Replication, все службы необходимые для работы с резервными копиями можно установить на одном Windows сервере.

Кстати рекомендуется при использовании метода простого развёртывания использовать виртуальный сервер Windows. Это даёт вам возможность использовать транспортный режим Virtual appliance и, как следствие, передача данных не будет идти по сети.

При простом развёртывании на сервере Veeam Backup & Replication используются следующие сервисы:

Сервер резервных копий, который управляет задачами резервного копирования
Прокси-сервер резервного копирования, который обрабатывает задачи и пересылает трафик резервного копирования
Репозиторий резервных копий по умолчанию. Во время установки Veeam Backup & Replication находит в системе диск с максимально свободным дисковым пространством, и использует его как репозиторий по умолчанию. На этом диске создается директория Backup, где хранятся все файлы резервных копий.
Сервер монтирования, необходимый для восстановления файлов гостевой ОС
Прокси-сервер гостевого взаимодействия, необходимый для работы с приложениями, индексации гостевой файловой системы и обработки журнала транзакций

При использования простого развертывания сразу после установки Veeam Backup & Replication готов для использования, нужно будет лишь добавить целевые хосты для резервного копирования.

При таком подходе все данные резервных копий хранятся на том же сервер где установлен Veeam Backup & Replication. Если же у вас большая инфраструктура, где ресурсов одного сервера Veeam Backup & Replication недостаточно для работы, рекомендуется использовать расширенный сценарий развертывания.

Расширенное развертывание

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

При использовании расширенного сценария развертывания нагрузка перемещается на выделенные сервера для разных компонентов Veeam Backup & Replication. Т.е. тут уже в отличии от простого развертывания используется несколько серверов (виртуальных машин). Сам сервер где установлен Veeam Backup & Replication становится менеджером для всех остальных компонентов.

Расширенное развертывание включает в себя следующие компоненты:

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

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

При использовании нескольких прокси-серверов Veeam Backup & Replication динамически распределяет траффик между ними. Вы конечно можете задать конкретный прокси-сервер для задачи, но тем не менее Veeam Backup & Replication может выбрать сам. Конечно сами прокси-сервера должны иметь доступ к необходимым хостам и также доступ к репозиторию.

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

Чтобы прокси-сервер не брал на себя много можно настроить максимальное количество конкурентных задач для прокси-серверов.

Ну и конечно еще одно преимущество - это то, что при недоступности одного прокси-сервера для задач могут использоваться другие, что в итоге не приведёт к простою.

Распределенное развертывание

Этот метод рекомендуется использовать для большой инфраструктуры, с географически распределёнными дата-центрами. В таком случае на каждой площадке устанавливается Veeam Backup & Replication используя расширенное развертывание или простое развертывание и все сервера Veeam Backup & Replication управляются уже через Veeam Backup Enterprise Manager посредством web-интерфейса.

Veeam Backup Enterprise Manager получает доступ ко всем событиям и данным конкретных узлов Veeam Backup & Replication, что позволяет вам управлять и мониторить все распределённые узлы Veeam Backup & Replication в одном месте, что конечно же удобно в первую очередь. Также это даёт преимущество в поиске резервной копии для конкретного сервера (виртуальной машины) если вы не знаете на каком узле Veeam Backup & Replication была сделана резервная копия. Просто делаете поиск VM в Veeam Backup Enterprise Manager и он сам найдёт его среди всех узлов Veeam Backup & Replication.

Также при использовании Veeam Backup Enterprise Manager нет необходимости ставить лицензии на каждый узел Veeam Backup & Replication, вместо этого вы можете добавить все лицензии в Veeam Backup Enterprise Manager и уже оттуда присвоить эти лицензии узлам Veeam Backup & Replication.

Также устанавливая плагин vSphere Web Client вы получаете возможность мониторить состояние виртуальной инфраструктуры в Veeam Backup Enterprise Manager.

Veeam - Зачем он вообще нужен?

Sat, 20 Jan 2024 06:20:39 +0600

Veeam Backup & Replication - это комплексное решение для защиты данных и восстановления после сбоев. Используя Veeam Backup & Replication вы можете делать резервные копии виртуальных, физических и облачных машин, ну и конечно же восстанавливать их из резервных копий при необходимости. В Veeam Backup & Replication используются технологии, которые оптимизируют передачу данных и потребление ресурсов, что помогает минимизировать затраты на хранение и время восстановления при необходимости.

Также предоставляется единая консоль для управления всеми задачами, такими как резервное копирование, восстановление и т.д. Вы также можете автоматизировать рутинные операции, например, проверка восстановления резервных копий.

Основные функции

Резервное копирование: создание резервных копий на уровне образов виртуальных, физических, облачных машин, а также резервных копий общих файловых ресурсов и репозиториев хранилищ объектов
Восстановление: предоставляется функция восстановления резервных копий в исходное или новое местоположение. Также вы можете восстановить полностью сервер, конкретные файлы, приложения и т.д.
Репликация: функция создания полной копии виртуальной машины в другом месте (хост, дата-центр)
Непрерывная защита данных (CDP): репликация, которая помогает защитить критически важные виртуальные машины и достичь целевой точки восстановления (RPO) с точностью до нескольких секунд
Копирование резервных копий: функция копирования резервных копий в другое место во избежание потери резервных копий
Поддержка систем хранения данных: используя эту функцию вы можете использовать встроенный функционал снимков в системах хранения данных для создания и восстановления резервных копий
Поддержка ленточных устройств: можно хранить резервные копии на ленточных устройствах
Проверка восстановления: перед полным восстановлением можно проверить состояние сервера

С чем работает

С помощью Veeam Backup & Replication вы можете создавать резервные копии и восстанавливать следующие объекты инфраструктуры:

Виртуальные машины:
- VMware vSphere
- Microsoft Hyper-V
- Nutanix AHV
- oVirt
- Proxmox VE
Облачные виртуальные машины:
- AWS EC2
- Microsoft Azure
- Google Cloud
Другое:
- Физические сервера
- Microsoft Entra ID tenant data (Microsoft AD)
- Файловые ресурсы
- MS SQL, PostgreSQL, Oracle, Exchange, OneDrive, SharePoint, Microsoft 365

Набор решений

Совместно с Veeam Backup & Replication вы можете использовать:

Veeam ONE: решение, которое обеспечивает мониторинг в реальном времени, бизнес-документацию и управленческую отчетность для Veeam Backup & Replication, VMware vSphere и Microsoft Hyper-V
Veeam Backup Enterprise Manager: предоставляет возможность управлять множеством узлов Veeam Backup & Replication с одной web консоли
Management Pack for Veeam Backup & Replication: компонент, который интегрирует инфраструктуру, сервисы и задания Veeam Backup & Replication в Microsoft System Center Operations Manager
Veeam Recovery Orchestrator: решение, которое организует процессы аварийного восстановления в средах VMware vSphere, поддерживает восстановление критически важных приложений одним щелчком мыши и предоставляет функции для документирования и тестирования
Veeam App for Splunk: можно мониторить состояние инфраструктуры Veeam в Splunk

MinIo - Bucket replication

Thu, 12 Oct 2023 06:20:39 +0600

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

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

Source vs Target

Давайте сразу определимся с этими понятиями: Source (Источник) - это та корзина (bucket) на которой вы настраиваете репликацию, Target (Цель) - это корзина (bucket) на другом пуле серверов, которая выбрана как место назначения.

Версионность

Крайне рекомендуется использовать одинаковые версии кластеров или пулов MinIO. Т.е. если на Source у вас стоит MinIO v1, то и на Target тоже должен стоять MinIO v1. Да конечно работать будет и с разными версиями, но могут вылезти проблемы, которые придётся решать самому. Для примера у меня были
корзины ( bucket ) с большим количеством ошибок репликации и как только я обновил все пулы серверов до последней версии всё реплицировалось на ура.

Также каждая корзина ( bucket ) должна быть создана с включенной опцией версионности.

Пользователь для репликации

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

Политика для пользователя, под которым будет производится репликация:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:GetBucketLocation",
                "s3:GetBucketVersioning",
                "s3:GetBucketObjectLockConfiguration",
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicationOnBucket"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ReplicateTags",
                "s3:AbortMultipartUpload",
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionTagging",
                "s3:PutObject",
                "s3:PutObjectRetention",
                "s3:PutBucketObjectLockConfiguration",
                "s3:PutObjectLegalHold",
                "s3:DeleteObject",
                "s3:ReplicateObject",
                "s3:ReplicateDelete"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicatingDataIntoBucket"
        }
    ]
}

Чтобы выдать права пользователю для создания правил репликации применяется следующая политика:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "admin:SetBucketTarget",
                "admin:GetBucketTarget"
            ],
            "Effect": "Allow",
            "Sid": "EnableRemoteBucketConfiguration"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetReplicationConfiguration",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:GetBucketLocation",
                "s3:GetBucketVersioning",
                "s3:GetObjectRetention",
                "s3:GetObjectLegalHold",
                "s3:PutReplicationConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::*"
            ],
            "Sid": "EnableReplicationRuleConfiguration"
        }
    ]
}

mcli admin user add minio1 repluser
mcli admin policy create minio1 repluser /tmp/repluser.json
mcli admin policy attach minio1 repluser --user=repluser

Достаточно будет создать на одном сервере ( Source ), но если репликация будет двухсторонней то на обоих пулах серверов.

Server-Side Bucket Replication

Как мы уже поняли для репликации необходимо указать Target. Под Target подразумевается корзина ( bucket ) на другом пуле серверов. При этом имя корзины ( bucket ) может отличаться от имени Source.

При каждой записи объекта в Source корзину MinIO проверяет правила репликации и применяет их. При необходимости можно настроить репликацию уже существующих объектов и также репликацию операций удаления.

Для начала создадим корзины для Source и Target. Напоминаю имеется в виду то что это два разных пула серверов.

mcli mb minio1/testbucketsource
mcli mb minio2/testbuckettarget

На Source пуле выполняем ( !!!! Перед созданием прочтите всю статью до конца ):

mcli replicate add minio1/testbucketsource --remote-bucket 'http://ROOTUSER:CHANGEME123@172.31.144.8:9000/testbucket
target'

Проверяем что обе корзины пусты:

mcli ls minio1/testbucketsource
mcli ls minio2/testbuckettarget

Загрузим файл на Source :

mcli cp /tmp/repluser.json minio1/testbucketsource

Проверяем что файл присутствует на обоих пулах серверов:

mcli ls minio1/testbucketsource
mcli ls minio2/testbuckettarget

[2023-10-11 23:09:29 +06] 1.3KiB STANDARD repluser.json
[2023-10-11 23:09:29 +06] 1.3KiB STANDARD repluser.json

Active-Active (Two-Way) Bucket Replication

На первой схеме видно, что я нарисовал стрелки в обе стороны. Это не ошибка так как одна корзина может быть, как Source так и Target. Соответственно всё что записывается в Server Pool1 попадает и в Server Pool2 и наоборот.

Для того чтобы создать двухстороннюю репликацию делаем всё тоже самое только также выполняем команду mcli replicate и на Target ( !!!! Перед созданием прочтите всю статью до конца ).

mcli replicate add minio1/testbucketsource --remote-bucket 'http://ROOTUSER:CHANGEME123@172.31.144.8:9000/testbuckettarget'

mcli replicate add minio1/testbuckettarget --remote-bucket 'http://ROOTUSER:CHANGEME123@172.31.144.11:9000/testbucketsource'

Ресинхронизация

Если вдруг по, какой-то причине подключение между пулами серверов прервалось и ваши данные не синхронизируются можно воспользоваться командой mc replicate resync bucket.

При использовании данной команды происходит проверка всех объектов в Source, после чего каждый объект помещается в очередь на репликацию не зависимо от того был ли он реплицирован ранее. Но если в Target есть объекты, которые полностью соответствуют объектам в Source включая метаданные, то естественно эти объекты не будут синхронизироваться заново.

mcli replicate export minio1/testbucketsource | grep arn

"Destination":{"Bucket":"arn:minio:replication::ff92a1d3-324b-4e35-a7e6-d7319e51f1d8:testbuckettarget"}

mcli replicate resync start minio1/testbucketsource --remote-bucket "arn:minio:replication::ff92a1d3-324b-4e35-a7e6-d7319e51f1d8:testbuckettarget"
mcli replicate resync status minio1/testbucketsource

Resync status summary:
● arn:minio:replication::ff92a1d3-324b-4e35-a7e6-d7319e51f1d8:testbuckettarget
   Status: Pending
   Replication Status | Size (Bytes)    | Count
   Replicated         | 0 B             | 0
   Failed             | 0 B             | 0

Репликация операций удаления

Как я уже говорил выше есть возможность реплицировать операция удаления. Т.е. если удалить какой-то объект на Source он также удалится и на Target.

По умолчанию эта опция при создании репликации корзин включена. Если мы настраиваем репликацию в графике, то необходимо включать эту опцию руками через nmcli. Но всё зависит ещё и от версии самого сервера MinIO.

mcli replicate add minio1/testbucketsource --remote-bucket 'http://ROOTUSER:CHANGEME123@172.31.144.8:9000/testbuckettarget' --replicate "delete,delete-marker"

Репликация существующих объектов

Также, как и с ситуацией выше Репликация существующих объектов по умолчанию включена.

Для включения используется команда mc replicate add --replicate с опцией existing-objects.

Если же у вас уже настроена репликация, то всегда можно воспользоваться командой mc replicate update --replicate.

mcli replicate add minio1/testbucketsource --remote-bucket 'http://ROOTUSER:CHANGEME123@172.31.144.8:9000/testbuckettarget' --replicate "existing-objects"

Изменение настроек репликации

Если вы уже настроили правило репликации, но вам вдруг понадобилось что-то изменить можно использовать команду mcli replicate export alias.

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

mcli replicate export minio1/testbucketsource > /tmp/repl.json

mcli replicate export minio1/testbucketsource
mcli replicate update minio1/testbucketsource --id ckjdbncv4aqg10tqmbcg --replicate "delete"
mcli replicate export minio1/testbucketsource
mcli replicate update minio1/testbucketsource --id ckjdbncv4aqg10tqmbcg --replicate "delete,delete-marker,existing-objects"

Синхронная и асинхронная репликация

При использовании асинхронной репликации объект помещается в корзину сразу и только потом добавляется в очередь. Т.е. если Target недоступен, то в любом случае объект будет записан.

При использовании синхронной репликации важно чтобы Target всегда был доступен, иначе вы потратите больше времени на загрузку объекта. При синхронной репликации MinIO пытается реплицировать объект до завершения исходной операции PUT. MinIO возвращает успешную операцию PUT независимо от того, были ли успешной попытка репликации. Хотя у меня была ситуация, когда файл не удавалось загрузить из-за того, что на Target не хватало места на HDD.

Рекомендуется использовать асинхронную репликацию. Да есть конечно возможность потерять какие-то количество данных при выходе из строя Source но по крайней мере чаще встречаются обрывы на каналах связи между дата-центрами.

Как проходит репликация

Мы уже ни раз в этой статье затрагивали тему постановки в очередь на репликацию. Если какой-то объект не удаётся реплицировать трижды, то этот объект исключается из очереди. Также через какое-то время при сканировании объектов эти исключенные объекты будут снова помещены в очередь.

mcli replicate status minio1/testbucketsource

  Replication status since 29 minutes
  172.31.144.8:9000
  Replicated:                   1 objects (1.3 KiB)
  Queued:                       ● 0 objects, 0 B (avg: 0 objects, 0 B ; max: 0 objects, 0 B)
  Workers:                      0 (avg: 0; max: 0)
  Transfer Rate:                0 B/s (avg: 0 B/s; max: 0 B/s
  Latency:                      1ms (avg: 1ms; max: 1ms)
  Link:                         ● online (total downtime: 0 seconds)
  Errors:                       0 in last 1 minute; 0 in last 1hr; 0 since uptime

Статусы репликации:

Статус	Описание
PENDING	Это состояние говорит о том, что объект еще не реплицирован. Объекты с этим статусом помещаются в очередь репликации. Также если объект настроен на множественную репликацию, то статус не изменится пока не пройдёт репликация на все Target
COMPLETED	Объект успешно реплицирован
FAILED	Объект не удалось реплицировать. Объекты с этим статусом снова помещаются в очередь при возможности
REPLICA	Объект сам по себе является копией из удаленного источника

Собственно, сам процесс можно разбить на 2 варианта:

PENDING -> COMPLETED
PENDING -> FAILED -> COMPLETED

Также для проверки наличия неудачных попыток можно использовать команду mcli replicate backlog minio1/testbucketsource --full

MinIO - Логирование событий в Elasticsearch

Thu, 12 Oct 2023 06:20:39 +0600

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

Для начала конечно у вас уже должен быть работающий кластер Elasticsearch. Как его ставить в этой статье я рассматривать не буду.

Также о том как поставить MinIO клиент и создать alias вы можете посмотреть тут.

Включаем мониторинг действий с корзиной (bucket)

Самым первым делом нам необходимо добавить узел Elasticsearch, на который будем слать логи.

mc admin config set minio_alias/ notify_elasticsearch:1    url="https://elkhost:9122"    index="minio-index"    format="access"    username="elk_user"    password="elk_pwd"

К сожалению, после добавления узла Elasticsearch необходимо перезапустить весь Server Pool MinIO.

mc admin service restart minio_alias

Далее нам необходимо получить arn для Elasticsearch

mc admin info --json minio_alias | grep sqsARN
mc admin info --json minio_alias | jq  .info.sqsARN

Собственно, настраиваем аудит для корзины (bucket)

mc event add minio_alias/mybucket arn:aws:sqs:us-west-2:444455556666:your-queue
mc event ls minio_alias/mybucket

Можно применить фильтр по маске, например, производит аудит действий только для jpg файлов

mc event add minio_alias/mybucket arn:aws:sqs:us-west-2:444455556666:your-queue --suffix .jpg
mc event ls minio_alias/mybucket

MinIO - Файлы не удаляются с диска

Thu, 05 Oct 2023 06:20:39 +0600

Для того чтобы удалить файлы используется команда mc rm -r --force.

Но может так случиться что после удаления в самом bucket файлов нет, но они всё также лежать на диске в ОС. Может это произойти если вы используете версионность в bucket, чтобы полностью удалить файлы и их версии добавляем опцию --versions

mc rm -r --force --versions alias/bucketname

Linux - Права на файлы

Thu, 21 Sep 2023 02:22:39 +0600

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

Каждый файл имеет три категории по которым можно раздать права на файл:

Владелец файла, обычно тот, кто создал файл
Группа владелец файла, обычно основная группа создателя файла
Остальные пользователя, все кто не вошёл в список первых двух

В иерархии самый большой вес привилегий имеет владелец файла (5), затем идёт группа владелец (6) и уже самый минимальный вес у остальных.

Расшифровка RWX

Существуют три категории доступа к файлам: read, write, execute. При этом они по-разному влияют на файлы и директории. Таблица ниже расшифровывает каждый из них.

Право	Файлы	Директории	Цифра
r (read)	Файл может быть прочитан	Возможен просмотр списка документов в каталоге	4
w	Контент файла может быть изменён	Можно создавать или удалять файлы в каталоге	2
x	Файл может быть исполняемым	Можно переместиться в каталог (cd)	1

На картинке ниже права представлены в цифровом виде:

7 - означает что пользователь имеет все права (rwx)
4 - означает что пользователь имеет права только на чтение файла ( r )
0 - права на файл отсутствуют

Получается у нас есть 2 пользователя и одно группа all. В группе состоит пользователь Ivan. В итоге мы имеем:

Пользователь Ivan имеет полный доступ к файлу FILE1, так как он его владелец и для владельца выставлены максимальные права - цифра 7
Пользователь Valera не имеет прав на FILE1 так как для него действует 3 цифра 0, потому что он входит в категорию остальные пользователи
Пользователь Ivan имеет полный доступ к файлу FILE2, так как он входит в группу владельцев файла - All. А для этой группы выставлены полные права - цифра 7
Пользователь Valera имеет права на чтение файла FILE2 так как для него действует 3 цифра 4, потому что он входит в категорию остальные пользователи
Ни Ivan, ни Valera не имеют никаких прав на FILE3 потому что не являются владельцами файла, а для остальных пользователей права выставлены в 0

Т.е. когда вы видите цифры 740 это и есть обозначение прав на файл, где порядковый номер цифры соответствует категории, которые мы рассматривали в самом начале статьи.

Просмотр прав на файл

Для того чтобы посмотреть какие права выставлены для файла мы можем воспользоваться командой ls -la.

sudo ls -l

drwx------.  2 Ivan  Ivan    19 Nov  3 14:37 folder1
drwxrwxr--.  2 Huan  All     19 Nov  3 14:37 folder2
drwxrwx---.  2 Huan  Huan    19 Nov  3 14:38 folder3

В ОС права представляются в виде букв по три штуки, т.е. полные права обозначаются как rwx или 421. Первая буква d обозначает что это директория.

Рассмотрим подробнее строку drwxrwxr--. 2 Huan All 19 Nov 3 14:37 folder2:

drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - означает что это директория
drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - права для владельца
drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - права для группы владельца
drwxrwxr--. 2 Huan All 19 Nov 3 14:37 folder2 - права для всех остальных
drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - владелец директории
drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - группа владелец директории
drwxrwxr–. 2 Huan All 19 Nov 3 14:37 folder2 - имя директории

Права на файл по умолчанию

Когда вы создаёте файл ему назначаются права по умолчанию, или как их еще называют начальные права.

Когда вы создайте директорию то права по умолчанию у неё выставляются в 0777, а для файла 0666. Права на исполнение файла всегда задаются самим пользователем.

И так если верить теории выше, то сейчас мы создадим файл и права у него будут 666.

touch umask.txt
ls -la umask.txt

-rw-rw-r--. 1 admin admin 0 Nov  7 13:55 umask.txt

Но мы видим, что права у нас 664. Так в чем же дело? Дело в том, что тут вмешался umask.

Демонстрация всего выше описанного

IVAN - FILE1

ls -l

drwx------. 2 Ivan Ivan 19 Nov  3 14:37 folder1
drwxrwxr--. 2 Huan All  19 Nov  3 14:37 folder2
drwxrwx---. 2 Huan Huan 19 Nov  3 14:38 folder3

sudo su - Ivan
ls folder1/
cat folder1/FILE1

FILE1
file1

echo Ivan >> folder1/FILE1
cat folder1/FILE1

file1
Ivan

mv folder1/FILE1 folder1/FILE1-1
ls folder1/

FILE1-1

IVAN - FILE2

ls folder2/

FILE2

cat folder2/FILE2

file2

echo Ivan >> folder2/FILE2

-bash: folder2/FILE2: Permission denied

VALERA - FILE1

sudo su - Valera
ls folder1/
cd folder1/

ls: cannot open directory 'folder1/': Permission denied
-bash: cd: folder1/: Permission denied

VALERA - FILE2

ls folder2/
cd folder2/

ls: cannot access 'folder2/FILE2': Permission denied
FILE2

-bash: cd: folder2/: Permission denied

ls folder2/
cd folder2/

ls: cannot access 'folder2/FILE2': Permission denied
FILE2

-bash: cd: folder2/: Permission denied

ls folder2/
cd folder2/

cat folder2/FILE2

cat: folder2/FILE2: Permission denied

При выводе содержимого файла мы получаем ошибку хотя мы имеем права на чтение файла. Дела в том, что на каталог folder2 у нас права r--. Но для того чтобы открыть файл нам надо попасть в каталог, а для этого нам нужен еще x.

sudo chmod a+x folder2/
ls -l folder2

drwxrwxr-x.  2 Huan  All    19 Nov  3 14:37 folder2

cat folder2/FILE2

file2

echo Valera >> folder2/FILE2

-bash: folder2/FILE2: Permission denied

Linux - Управление паролями пользователей

Wed, 20 Sep 2023 02:22:39 +0600

Как я писал ранее все пароли пользователей, зашифрованные лежат в файле /etc/shadow. Доступ к этому фалу имеет только root.

sudo ls -la /etc/shadow

----------. 1 root root 943 Nov  2 15:36 /etc/shadow

/etc/shadow

Рассмотрим подробнее строку из этого файла.

Имя пользователя
Зашифрованный пароль
День, когда пароль последний раз был изменён. Для того чтобы перевести в наши дни надо добавить эти дни к дате 01.01.1970
Минимальное время в днях которое должно пройти от последней смены пароля для возможности очередной смены пароля
Срок действия пароля
Период уведомлений о необходимости смены пароля. Отнимается от даты смена пароля
Период неактивности пользователя, по истечении которого пользователь будет заблокирован
Период в днях после которого аккаунт заблокируется. Отсчет идёт опять-таки от 01.01.1970
Пустое поле для будущих изысканий RedHat

Формат зашифрованного пароля

Зашифрованный пароль, разбитый на части:

$6 $6q63QkCry59G3VG5 $s.O.Lmx5c.ynqHkuWAqiWfCXnvluw85NKkVjJUeQfTP8M8wecl.wTixpCqqoGoIJfA7lgF2fpDkGjVECgAPr90

Получается, что строка состоит из 3 частей, разделённых знаком $.

Обозначает какой алгоритм хэширования применен. Номер 6 означает что это SHA-512, который используется по умолчанию в RHEL 8. Номер 1 означает MD5, а 5 - SHA-256.
Соль (sault), которая используется для декодирования пароля. Генерируется рандомно.
Хэш пароля пользователя. Хэш и незашифрованный пароль объединяются для создания хэша пароля.

Суть объединения соли с паролем пользователя заключается в защите хэша от всяких переборов пароля по хэшу. Т.е. если у вас пароль 123456 то хэш этого пароля легко найти в интернете, но если у вас добавляется еще моль к этому паролю то найти его уже гораздо сложнее.

Верификация пароля

Когда пользователь пытается залогиниться система проверяет наличие записи для него в файле /etc/shadow, потом объединяет соль с паролем, который ввёл пользователь и шифрует его используя установленный алгоритм. И если полученный результат аналогичен хэшу в файле значит пользователь ввёл правильный пароль и может авторизоваться в ОС. Этот метод позволяет определить, что пользователь вводит правильный или не правильный пароль без хранения пароля в открытом виде.

Устаревание пароля

Мы уже косвенно затрагивали эту тему в ранних статьях и теперь рассмотрим это подробнее. Управление временем жизни пароля осуществляется через команду chage. На картинке ниже рассмотрим весь цикл жизни пароля с опциями для chage.

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

sudo chage -m 0 -M 60 -W 7 -I 30 user20
sudo chage -l user20

Last password change                                    : Nov 02, 2021
Password expires                                        : Jan 01, 2022
Password inactive                                       : Jan 31, 2022
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 60
Number of days of warning before password expires       : 7

Мы видим тут дату последней смены пароля от которой и отчитывается срок действия пароля. И если мы хотим, чтобы пользователь при следующем входе в систему сменил пароль то нужно выставить это значение в 0.

sudo chage -d 0 user20
sudo chage -l user20

Last password change                                    : password must be changed
Password expires                                        : password must be changed
Password inactive                                       : password must be changed

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

date -d '+20 days' +%F
sudo chage -E 2021-11-23 user20
sudo chage -l user20

Account expires                                         : Nov 23, 2021

Глобальные настройки пароля

Конечно если у вас по 20-30 пользователей очень проблематично каждому выставлять руками политику паролей. Поэтому существует файл /etc/login.defs в котором вы можете задать политику паролей для всех пользователей в ОС. Важное замечание политику будут подхватывать только пользователи, созданные после редактирования этого файла. Старым пользователям придётся менять руками командой chage.

PASS_MAX_DAYS - максимальное время жизни пароля
PASS_MIN_DAYS - минимальное время жизни пароля
PASS_MIN_LEN - минимальное количество символов в пароле
PASS_WARN_AGE - время уведомления перед истечением пароля

Блокировка пользователя

Для того чтобы заблокировать пользователя можно воспользоваться командой usermod о которой мы уже говорили тут. Для блокировки используется опция -L, а для разблокировки - -U.

sudo usermod -L user20
sudo usermod -U user20

Linux - Управление пользователями

Sat, 16 Sep 2023 02:22:39 +0600

Создание пользователя

Для добавления пользователя в систему используется команда useradd username или adduser username. Какую именно команду выполнять зависит от ОС. Также при выполнении этой команды создаётся и домашняя директория для пользователя и основная группа пользователя. Для установления пароля пользователя нужно выполнить отдельную команду passwd username. Пока не зададите пароль пользователь не сможет войти в систему.

sudo useradd admin2 || sudo adduser admin2
sudo passwd admin2 
sudo tail /etc/passwd

Также при создании пользователя вы можете использовать опции, которые позволят задать дополнительные параметры.

Добавим описание для пользователя
```
sudo useradd admin2 -c "my test user"
```
Добавим время жизни пользователя
```
sudo useradd admin2 -e 2025-01-01
```
Укажем UID пользователя
```
sudo useradd admin2 -u 1005
```

Редактирование пользователя

Для редактирования уже созданного пользователя используется команда usermod. Ниже рассмотрим основные примеры использования usermod.

Добавим описание для пользователя
```
sudo usermod admin2 -c "my test user"
```
Изменим основную группу пользователя (старая группа затирается)
```
sudo usermod admin2 -g admin
```
Добавим дополнительные группы
```
sudo usermod admin2 -a -G admin,admin2,wheel
```
Заблокируем пользователя
```
sudo usermod admin2 -L
```
Разблокируем пользователя
```
sudo usermod admin2 -U
```
Сменим оболочку shell
```
sudo usermod admin2 -c /bin/zsh
```
Сменим uid пользователя
```
sudo usermod user3 -r 1005
```

Все опции команды вы можете получить выполнив man usermod.

Удаление пользователя

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

Для того чтобы удалить пользователя и его домашнюю директорию выполняем userdel -r username.

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

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

sudo useradd user2
sudo ls -l /home/

drwx------. 2 user2  user2   62 Nov  2 14:56 user2

sudo userdel user2
sudo ls -l /home/

drwx------. 2   1002   1002  62 Nov  2 14:56 user2

sudo useradd user3
sudo ls -l /home/

drwx------. 2 user3  user3   62 Nov  2 14:56 user2
drwx------. 2 user3  user3   62 Nov  2 14:59 user3

Для того чтобы найти все директорию у которых отсутствуют владельцы можно воспользоваться командой sudo find / -nouser -o -nogroup.

Задать uid для пользователя

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

sudo useradd user3 -r 1005

Если пользователь уже создан, то не беда можно использовать usermod.

sudo usermod user3 -r 1005

Задать пароль пользователя

Я уже упоминал что для установки пароля пользователю используется passwd username. Нужно дважды повторить свой пароль.

Верификация

Как вы успели заметить некоторые команды не выводят ничего о итоге выполнения. Так вот чтобы проверить как выполнилась команда можно выполнить echo $?. Выводом будет код результата (exit code), просмотреть что значит exit code можно используя man.

man passwd

EXIT CODE
       The passwd command exits with the following codes:
       0         success
       1         passwd/libuser operation failed
       2         unknown user

UID диапазоны

О том что такое UID можно почитать тут.

В Redhat дистрибутивах для каждого типа пользователей зарезервированы диапазоны выдаваемого UID.

0 - используется для root
1-200 - для системных пользователей (system user) именно для сервисов Redhat
201-999 - для системных пользователей (system user) сторонних приложений
1000+ - для обычных пользователей

Linux - Структура каталогов

Sat, 16 Sep 2023 02:22:39 +0600

/ - Корневой каталог (The Root Directory)

Начнём с самого основного каталога /, который является корнем всех остальных. Все в вашей системе Linux находится в этом каталоге. Да, вы можете возразить что можно ведь создать раздел как в Windows. Но вот в Windows это будет уже диск D, а не C тогда как в Linux это будет новая директория, которая всё еще будет находится в корне, т.е. /.

/bin - Директория для исполняемых файлов

Директория /bin содержит основные пользовательские двоичные файлы (программы). Программы необходимые для работы с ОС находятся в данной директории. Но если пользователь ставит что-то другое, например, браузер то его исполняемые файлы уже помещаются в /usr/bin.

/boot - Каталог для файлов загрузки

Как нетрудно догадаться по названию эта директория связана с загрузкой, а именно там находятся файлы, благодаря которым происходит загрузка ОС. Например, загрузчик GRUB.

/cdrom

Тут в принципе всё понятно по названию, это временное место для компакт-дисков, вставленных в систему. Но вот файлов тут с диска вы не найдёте)

/dev - Файлы устройств

Так как в Linux всё это файл, то и устройства не исключение. Самое часто используемое это, например, жесткие диски. Каждый жёсткий диск будет предоставляться как файл с именем /dev/sd[a-z].

Но помимо физических устройств тут присутствуют и виртуальные. Такие как /dev/random, /dev/null (черная дыра).

/etc - Каталог конфигураций

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

/home - Домашние директории пользователей

Тут вы можете найти домашние директории пользователей, что-то вроде C:/users в Windows. Но в Linux можно создать пользователя без домашней директории, если вдруг хочется.

Когда вы авторизуетесь на сервере ваша директория по умолчании как раз находится тут, например, /home/user.

/lib

Тут собственно библиотеки, которые используют те самые исполняемые файлы с директории /bin.

/media

Если в директории /cdrom нет данных, то они как раз находятся тут) Директория /media содержит подкаталоги, в которых монтируются съемные носители, вставленные в компьютер.

/mnt – временные точки монтирования

Исторически сложилось так, что директория /mnt — это место, куда системные администраторы монтировали временные файловые системы во время их использования. Но некоторые используют его, как и постоянное место монтирования, если можно, то почему нет то)

/opt

Директория /opt содержит подкаталоги для дополнительных пакетов программного обеспечения.

/root

Это у нас корневая директория короля, т.е. пользователя root. Как вы поняли по пути /home/root ничего нет.

/run

Эта директория где программы могут хранить различные временные файлы, например, сокеты. Они не хранят их в /tmp так как эта директория очищается.

/sbin

Каталог /sbin аналогичен каталогу /bin. Он содержит важные двоичные файлы, которые обычно предназначены для запуска пользователем root для системного администрирования.

/selinux

Любите отключать selinux проходят мимо этой директории. Каталог /selinux содержит специальные файлы, используемые для работы SELinux. Может быть не во всех ОС.

/tmp - Временные файлы (Temporary Files)

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

/var/log

Файлы журналов (лог файлы) для системы и приложений хранятся в каталоге /var/log. Также это директория для остальных данных. Например, apache хранит html файлы по пути /var/www.

FreeIpa - Активируем otp в качестве второго фактора аутентификации

Fri, 15 Sep 2023 06:22:39 +0600

Почему важно использовать двухфакторную аутентификацию:

Повышает уровень безопасности: Даже если злоумышленник получит ваш пароль, он не сможет его использовать так как ему нужно еще получить значение второго типа аутентификации, например, одноразовый пароль (otp).
Снижение риска повторного использования пароля: Многие любят использовать один и тот же пароль для нескольких сервисов. Конечно двухфакторная аутентификация не исправит эту проблему, но благодаря ей у вас будут разные otp для разных сервисов. Т.е. кто-то, узнав ваш пароль от одной системы может им воспользоваться для доступа к другой системе, но столкнётся со вторым этапом.
Соответствие требованиям: Многие организации особенно государственные проходят проверки и одна из таких проверок — это соответствие требованиям аутентификации, а именно наличие двухфакторной аутентификации.

Включаем OTP

На самом деле всё очень просто:

На телефон качаем приложение free otp или google authentificator
Добавляем токен OTP для пользователя
Во FreeIpa для конкретного пользователя активируем галочку Двухфакторная аутентификация (пароль + OTP) или глобально

Добавляем токен OTP для пользователя

Для начала пользователь может сам добавить себе токен. Для этого нужно авторизоваться в web интерфейсе и перейти во вкладку Токены OTP.

И второй вариант — это когда администратор добавляет Токены OTP для другого пользователя.

После чего выйдет всплывающее окно с qr кодом, который нужно отсканировать приложением ree otp или google authentificator.

Активируем Двухфакторную аутентификацию (Web)

Редактируем конкретного пользователя и выставляем галочку Двухфакторная аутентификация (пароль + OTP).

Для того, чтобы задать глобально а не для конкретного пользователя переходим в IPA-сервер > Конфигурация.

Активируем Двухфакторную аутентификацию (Cli)

Для конкретного пользователя:

ipa user-mod ivanov --user-auth-type=otp

Для того, чтобы задать глобально:

ipa config-mod --user-auth-type=otp

Linux - Пользователи и группы

Thu, 14 Sep 2023 06:22:39 +0600

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

Пользователи имеют имя пользователя (user name) для идентификации человека, и в идеале должно содержать настоящее имя человека. Внутри ОС ядро идентифицирует пользователя по уникальному идентификатору (unique identificator) - UID. Если пользователь ОС используется человеком, то необходимо также задать пароль пользователя, благодаря которому человек идентифицирует себя.

Аккаунт пользователя — это фундаментальная вещь для обеспечения безопасности ОС. Каждый процесс в системе запускается под своим пользователем, так правильно. Каждый файл имеет своего владельца, что обеспечивает сохранность файла. Процесс запущенный под определённым пользователем будет иметь доступ только к тем файлам, к которым он имеет доступ.

О том как управлять пользователями можно почитать тут. О том как управлять группами можно почитать тут.

Типы пользователей ОС 👨‍💻

Пользователи в основном делятся на 3 основных типа:

Superuser - для администрирования ОС. По умолчанию им является пользователь root с уникальным UID 0. У него все права в ОС которые только существуют, поэтому в идеале не стоит работать под ним и тем более раздавать пароль от него всем подряд.
System user - пользователи, предназначенные для запуска сервисов (daemons). Каждый сервис должен запускаться под своим пользователем, и ни в коем случае не должен быть запущен от root. Также эти пользователи не должны иметь права авторизации в ОС (/sbin/nologin).
Regular user - обычные пользователи ОС, под которыми вы сидите каждый день.

UID 🆔

Для просмотра информации о текущем пользователе используется команда id username. Где мы как раз-таки увидим наш UID, для обычного пользователя UID начинается с 1000.

id admin

uid=1000(admin) gid=1000(admin) groups=1000(admin),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Для того чтобы посмотреть владельца файла можно использовать команду ls -la file, в выводе в 3 колонке будет имя владельца файла.

ls -la /tmp/stderr.txt

-rw-rw-r--. 1 admin admin 42 Nov  1 21:46 /tmp/stderr.txt

Также мы говорили о том, что каждый процесс запускается от своего пользователя, для просмотра этого используется команда ```ps -au``.

ps -au

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         916  0.0  0.0  13656    20 tty1     Ss+  Oct30   0:00 /sbin/agetty -o -p -- \u --noclear tty1 linux
admin     145378  0.0  0.7  24120  2232 pts/0    Ss   Nov01   0:00 -bash
admin     154568  0.0  1.1  55808  3588 pts/0    R+   10:46   0:00 ps -au

В графе USER мы видим пользователя, от которого запущен процесс, т.е. владельца процесса. Но само ядро привязывает пользователя к процессу по UID. Соответственно где-то в системе хранится сопоставление имени пользователя с его UID и находится это в файле /etc/passwd.

/etc/passwd 🔒

Каждая строка хранит информацию о пользователе. Каждая строка разбита на 7 колонок.

Имя пользователя
Пароль пользователя, хранящийся в зашифрованном виде. Хранится в файле /etc/shadow. Это поле всегда имеет значение х.
UID для пользователя
GID - id группы основной
Полное имя пользователя
Домашняя директория пользователя
Оболочка по умолчанию

/etc/shadow 🔑

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

Имя пользователя
Пароль
Через сколько дней можно сменить пароль
Дней до смены пароля
Дней до предупреждения пользователя о смене пароля
Дней до истечения срока действия аккаунта
Зарезервировано для возможного использования в будущем

Среда окружения 🧖🏿

Каждый пользователь может изменять свои настройки по умолчанию. Например, можно задать новый umask или прокинуть какие-то переменные в своё окружение. Для этого пользователь может использовать файл ~/.bash_profile. Символ ~ обозначает домашнюю директорию пользователя /home/user.

Но также системный администратор может выставить настройки для всех пользователей используя директорию /etc/profile.

Также администратор ОС может использовать директорию /etc/skel. Все файлы находящиеся здесь будут скопированы в домашнюю директорию новых пользователей, при их создании.

Теперь немного про группы 👯

Группы — это совокупность пользователей, и служат они в основном для раздачи прав на файлы многим пользователям. Т.е. группа объединяет нескольких пользователей для дальнейших манипуляций.

Как и пользователи группы имеют свой собственный id- GID и также имеют своё имя группы (Group name).

Также, как и пользователи имеют свой файл с сопоставлением имени группы и GID. Этот файл находится по пути /etc/group.

/etc/group 🪄

Имя группы
Пароль группы, всегда имеет значение х
GID - id группы
Список пользователей которые входят в группу разделённых запятыми

Основные и дополнительные группы (Primary and Supplementary) 🧙

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

По умолчанию, когда вы создаёте пользователя также и создаётся основная группа с одноименным названием. Создаваемая группа будет для пользователя основной, и по умолчанию только этот пользователь будет состоять в ней (User Private Group).

Пользователи также могут иметь и дополнительные группы. Кто и в каких дополнительных группах состоит записывается в файле /etc/group.

Для того чтобы посмотреть в каких группах состоит пользователь можно воспользоваться командой id которую мы уже рассматривали выше или groups.

Linux - Sudo vs su

Thu, 14 Sep 2023 06:22:39 +0600

В Linux существуют 3 типа пользователей: root, стандартный пользователи (Regular user) и сервисы (системные).

Большинство ОС имеют своих суперпользователей, т.е. пользователя который наделён максимальными правами в ОС. Во многих ОС семейства Linux этот пользователь root. Для установки приложений, изменения разрешений, создания пользователей, изменения системных файлов пользователи должны повысить свои привилегии до root (sudo).

Пользователь с наивысшими правами у нас root, как Администратор в Windows. Считается дурным тоном заходить на сервер под этим пользователем так как пользователь имеет неограниченные права. По соображения иб лучше заходить под стандартным пользователем. Если пользователь root будет скомпрометированным, то у вас будут очень большие проблемы.

Права стандартного пользователя

Как вы поняли стандартный пользователь не имеет по умолчанию всех прав для администрирования. Тогда логичный вопрос: Как мне управлять сервером? После того как вы зашли под этим пользователем (именная учетная запись) выполняем команду su - root и вводим пароль от root. После чего вы уже не стандартный пользователь, а root. Для того, чтобы проверить кто вы, можно выполнить whoami.

Вы заметили, что я конкретного написал su - root, т.е. мы используем su когда хотим переключится в другого пользователя. Обязательно конечно знать пароль пользователя, но если это делать под root, то не надо.

Но с таким подходом всё ещё остаются несколько проблем:

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

Sudo

И тут есть 2 выхода:

Добавить пользователя в группу wheel, что даст ему возможность выполнять команды с повышением прав. Тут как минимум у вас в логах будет проще отыскать кто именно перезапустил сервис или сервер. Чтобы выполнять команду с повышенными правами нужно будет использовать sudo, например, sudo cat /var/log/secure.
Вторым этапом можно обозначить какие именно команды пользователь может выполнять. Делается это в файле /etc/sudoers, но об этом в другой статье.

Пример

Создадим стандартного пользователя user
Попробуем выполнить что-то
Добавим его в wheel
Попробуем выполнить что-то с использованием sudo

[root@c-stream-9-vm1 ~]# useradd user
[root@c-stream-9-vm1 ~]# passwd user
[root@c-stream-9-vm1 ~]# su - user
[user@c-stream-9-vm1 ~]$ cat /var/log/secure

cat: /var/log/secure: Permission denied

[root@c-stream-9-vm1 ~]# usermod -aG wheel user
[root@c-stream-9-vm1 ~]# su - user
[user@c-stream-9-vm1 ~]$ sudo cat /var/log/secure

Aug 10 17:53:25 c-stream-9-vm1 su[2671889]: pam_unix(su-l:session): session opened for user user by admin(uid=0)

Переключение пользователя

Для переключения пользователя без выхода из системы используется команды su - username, этакая смена пользователя как в Winodws. Если вы делаете это под стандартным пользователем то вам нужно будет ввести пароль нужного вам пользователя, если вы выполняете под root то пароль вводить не надо.

su - root

Password:

Если ввести su без имени пользователя, то по умолчанию вы пытаетесь логиниться под root.

su vs su -

Запомните раз и навсегда что правильно использовать команды su со знаком -. Разница в том, что когда вы используете su - то подгружается окружение конечного пользователя, а просто su оставляет окружение текущего пользователя.

В примере ниже мы переключаемся в пользователя root но при этом остаемся в окружении пользователя admin.

[admin@vm-1 ~]$ su
Password:
su: Authentication failure
[admin@vm-1 ~]$ su
Password:
[root@vm-1 admin]# ls -la
total 24
drwx------. 2 admin admin  115 Nov  2 11:58 .
drwxr-xr-x. 3 root  root    19 Jun 22 11:06 ..
-rw-------. 1 admin admin 3588 Nov  1 23:39 .bash_history
-rw-r--r--. 1 admin admin   18 Jul 21  2020 .bash_logout
-rw-r--r--. 1 admin admin  141 Jul 21  2020 .bash_profile
-rw-r--r--. 1 admin admin  395 Nov  2 11:58 .bashrc
-rw-------. 1 admin admin   51 Nov  2 10:16 .lesshst
-rw-------. 1 admin admin 2612 Nov  2 11:58 .viminfo

В примере ниже мы переключаемся в пользователя root по правильному.

 [admin@vm-1 ~]$ su -
Password:
Last login: Tue Nov  2 12:09:22 +06 2021 on pts/0
[root@vm-1 ~]# ls -la
total 32
dr-xr-x---.  2 root root  151 Oct 30 13:16 .
dr-xr-xr-x. 17 root root  224 Oct 27 18:18 ..
-rw-------.  1 root root 1256 Oct 27 17:43 anaconda-ks.cfg
-rw-------.  1 root root  314 Nov  2 12:09 .bash_history
-rw-r--r--.  1 root root   18 May 11  2019 .bash_logout
-rw-r--r--.  1 root root  176 May 11  2019 .bash_profile
-rw-r--r--.  1 root root  176 May 11  2019 .bashrc
-rw-r--r--.  1 root root  100 May 11  2019 .cshrc
-rw-r--r--.  1 root root  129 May 11  2019 .tcshrc
-rw-------.  1 root root 2296 Oct 30 13:16 .viminfo

Конфигурация sudo

Я говорил о том, что вы можете задавать список разрешённых команд sudo для пользователя. Правило по умолчанию находится в /etc/sudoers и разрешает выполнение всех команд. Делает это строка %wheel ALL=(ALL) ALL.

%wheel ALL=(ALL) ALL - группа к которой применяется правило
%wheel ALL=(ALL) ALL - означает, что данное правило применяется ко всем хостам
%wheel ALL=(ALL) ALL - означает, что пользователь root может запускать команды от лица всех пользователей
%wheel ALL=(ALL) ALL - означает, что данные правила применяются всем командам

Добавление новых правил рекомендуется выполнять добавлением нового файла в директорию /etc/sudoers.d. Например, для добавления прав пользователю admin2:

sudo visudo /etc/sudoers.d/admin2

admin2 ALL=(ALL)       /bin/ls

sudo su - admin2
sudo ls -la

Sudo без пароля

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

sudo visudo /etc/sudoers.d/admin2

admin2 ALL=(ALL)       NOPASSWD:/bin/ls

sudo su - admin2
sudo ls -la

Linux - man, help, документация

Thu, 14 Sep 2023 06:22:39 +0600

Знакомая ситуация, когда вы знаете саму команду, но вот не помните её аргументы? Думаю, вполне распространённая ситуация. В такой ситуации у вас один выход - обратиться к команде man.

Один из источников документации, который встроен в ОС Linux по умолчанию называется system manual pages или man pages. Эти страницы идут совместно с устанавливаемыми пакетами и описывают все возможности приложения. Доступ к этим страницам документации как раз осуществляется при помощи утилиты man.

Команда man всю документацию для той или иной команды. Для того чтобы вывести инструкцию для ls мы вводим man ls.

Обновление инструкций

Рекомендую время от времени выполнять команду sudo mandb, которая обновляет документацию. Особенно если вдруг вы не нашли man для команды.

Разделы документаций

Сами страницы документации произошли из документации разработчиков Linux (Linux Programmer’s Manual), которые были огромными и делились на разделы.

Некоторые команды имеют несколько разделов документаций , номер раздела пишется сверху в скобках рядом с самой командой LS(1). Для того чтобы получить эти номера мы можем выполнить команду man -f command.

Если при выполнении команды вы получаете nothing appropriate выполните sudo mandb.

man -f ip

ip (8) - show / manipulate routing, network devices, interfaces and tunnels

Вот список всех разделов:

# 1👤 : Пользовательские команды
# 2🌌 : Системные команды
# 3📁 : Библиотеки
# 4🧃 : Специальные файлы
# 5📃 : Форматы файлов и соглашения
# 6🎮 : Игры
# 7🗞️ : Разное
# 8🧸 : Команды системного администрирования (обычно только для root)
# 9⚗️ : Подпрограммы ядра

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

man 1 passwd

Для того чтобы вызвать документацию по файлу /etc/passwd нам нужно указать раздел №5.

man 5 passwd

Просмотр по всем категориям

Если вы видите, что у команды несколько категорий и вы хотите просмотреть их сразу все одной командой можно использовать man -a command. Сперва выведется инструкция для первой категории, после выхода вам будет предложено просмотреть следующую категорию (ENTER).

man -a passwd
q

--Man-- next: passwd(1ssl) [ view (return) | skip (Ctrl-D) | quit (Ctrl-C) ]

Поиск по ключевым словам

Если вы хотите узнать какие команды вы можете использовать для своей задачи можно поискать определённое слово в инструкциях man выполнив man -k keyword. Например, я хочу задать пароль пользователя:

man -k pass

lpasswd (1)          - Change group or user password
openssl-passwd (1ssl) - compute password hashes
pam_localuser (8)    - require users to be listed in /etc/passwd
passwd (1)           - update user's authentication tokens

Команда apropos pass выполнить тоже самое, пользуйтесь той которая больше нравится.

Навигация в man ⌨️

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

Команда	Результат
Spacebar (пробел)	Пролистать вниз на одну страницу
PageDown	Пролистать вниз на одну страницу
PageUp	Пролистать вверх на одну страницу
DownArrow	Пролистать вниз на одну линию
UpArrow	Пролистать вверх на одну линию
D	Пролистать вниз на половину страницы
U	Пролистать вверх на половину страницы
/string	Поиск определённого слова (string) по странице ниже. Есть поддержка регулярных выражений
N	Переход к следующему совпадению
Shift+N	Переход к предыдущему совпадению
G	Переход в начало документации
Shift+G	Переход в конец документации
Q	Выход

Структура man

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

Заголовок	Описание
NAME	Имя команды или исполняемого файла
SYNOPSIS	Строка со списком всех возможных атрибутов команды
DESCRIPTION	Описание для чего используется команда
OPTIONS	Описание опций, которая может принимать команда
FILES	Список файлов и директорий, относящихся к команде
BUGS	Собственно известные баги
SEE ALSO	Дополнительные `man pages`
EXAMPLES	Собственно примеры использования команды
AUTHOR	Автор документации

Онлайн документация

Если вам вдруг чем-то не подошёл man, то вы может просмотреть инструкции в интернете.

/usr/share/doc

Еще одно место где вы можете просмотреть информацию о команде это директория /usr/share/doc. В этой директории вы можете найти changelog по команде, узнать кто автор и также почитать инструкцию (FAQ).

find  /usr/share/doc/ -name FAQ

/usr/share/doc/bash/FAQ
/usr/share/doc/zlib/FAQ
/usr/share/doc/curl/FAQ

more /usr/share/doc/curl/FAQ
cat /usr/share/doc/passwd/AUTHORS

Используем help

Также каждая команда имеет атрибут --help, которым вы также можете воспользоваться для просмотра документации.

ls --help | less

whatis

Вы также можете просмотреть для чего именно предназначена та или иная команда, используя whatis command.

whatis ls

ls (1) - list directory contents

Не хватает man?

Есть вторая команда, которая делает всё тоже самое, но только иногда может выдавать немного больше информации, но только иногда. Это команда info.

info passwd

Sonatype Nexus - Прокси для ansible galaxy

Wed, 13 Sep 2023 06:00:39 +0600

Для начала начнём с того, что по умолчанию прокси для ansible нету. Но есть неофициальный плагин по ссылке.

Скачиваем файл с расширением .kar по ссылке
Копируем этот файл в директорию deploy, которая находится в корне директории для nexus
Перезапускаем nexus
Добавляем прокси репозиторий

wget https://github.com/l3ender/nexus-repository-ansiblegalaxy/releases/download/0.3.0/nexus-repository-ansiblegalaxy-0.3.0-bundle.kar
sudo cp nexus-repository-ansiblegalaxy-0.3.0-bundle.kar /var/lib/nexus/deploy
sudo systemctl restart nexus

Установка

Для того, чтобы скачать пакеты через прокси используем опцию -s.

ansible-galaxy collection install community.general -s https://nexus.example.lan:8443/repository/ansible-galaxy/

Или настроить репозиторий глобально:

sudo vim /etc/ansible/ansible.cfg

[galaxy]
server_list = example_lan

[galaxy_server.example_lan]
url=https://nexus.example.lan:8443/repository/ansible-galaxy/

Linux - Что такое LVM

Wed, 13 Sep 2023 06:00:39 +0600

Использование LVM облегчает конфигурирование дискового пространства. Если нужно добавить больше дискового пространства в LVM, достаточно расширить ваш LVM раздел (LVM volume) за счет свободного места в группе LVM (LVM group).

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

Еще один плюс — это возможность объединить большое количество жестких дисков в один. Например, у вас есть 4 диска по 2ТБ и вам надо отдать их все под базы данных при этом гораздо проще будет если бд будут хранится на одном разделе, а не на 4. Вот в такой ситуации вы объединяете все 4 диска и получаете раздел размером в 8 ТБ.

LVM даёт возможность делать snapshots. Что означает что вы можете сделать снимок раздела на определённый момент и уже по необходимости откатится к нему в будущем. Особенно полезно для всяких экспериментов.

Также в LVM реализованы все уровни RAID, но считается что это не совсем прямое предназначение LVM.

PD/Physical devices

Physical devices - это физические устройства, которые предоставляются для LVM group и где хранятся данные. Под Physical devices подразумевается разделы жд, физические жд, RAID массивы, SAN устройства.

Устройства должны быть инициализированы как LVM Physical volume чтобы их можно было использовать в LVM.

PV/Physical volumes (Физические тома)

Physical volumes - это базовое физическое хранилище используемое в LVM. Первым делом нужно инициализировать ваше устройство хранения данных как Physical volume для использования в LVM.

Инструменты LVM сегментируют Physical volumes на физические экстенты (Physical extends) которые представляют из себя небольшие фрагменты данных, которые действуют как минимальный блок хранения.

По сути является специальной файловой системой для LVM, где помимо прочего хранятся метаданные указывающие к какой VG относится устройство.

У каждого Physical volume есть свой супер-блок где хранятся метаданные о VG, который находится в начале диска.

VG/Volume groups (Группа томов)

Volume groups - это пулы хранения (Storage pools), состоящие из одного или множества Physical volume. Т.е. можно сказать что Volume group то же самое что и LUN в схд, или одно общее единое пространство. Один Physical volume может быть назначен только одной Volume group. Может состоять из любого количества Physical Volumes и также расширятся в будущем. Хранит метаданные о том в каком PV находятся Physical extends и в каком Logical Volume находятся Logical extends и сопоставляет их.

Если разбирать преимущества LVM которые я описывал ранее можно сказать что как раз благодаря VG мы и получаем 4 диска объединённые в один, размером 8ТБ.

LV/Logical Volumes (Логические тома)

Logical Volumes - это набор из Logical extends, который соответствует Physical extends и имеют одинаковый размер. Logical extends сопоставляются с Physical extends и хранятся там же и не обязательно что все Logical extends одного LV хранятся на Physical extends одного PV. Также можно расширять LV благодаря наличию свободны Physical extends в PV. Каждый кусок Logical extends можно перенести на другой Physical extends, как раз имеется в виду ситуация с заменой диска не останавливая работу приложений.

Получается при использовании обычных разделов вы не можете создать раздел который начинается в начале диска, потом прерывается на середине и потом снова продолжается в конце. В LVM же благодаря Logical extends и Physical extends такое возможно.

Именно их мы и монтируем в ОС как разделы, создаются они из пространства VG.

Создаём LVM

После всей теории мы наконец переходим к практике.

Подготовка PD

Используя parted, о котором я писал тут создаём новые разделы для LVM. При использовании раздела для LVM тип раздела должен быть Linux LVM.

Выводим список всех дисков
```
sudo parted -l
```
Создаём таблицу разделов и раздел

sudo parted /dev/sdd mklabel gpt
sudo parted /dev/sde mklabel gpt
sudo parted /dev/sdf mklabel gptsudo

sudo parted  /dev/sdd mkpart primary 1049kB 3220MB
sudo parted  /dev/sde mkpart primary 1049kB 3220MB
sudo parted  /dev/sdf mkpart primary 1049kB 3220MB

sudo parted /dev/sdd print

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3220MB  3219MB               primary

sudo parted /dev/sdd set 1 lvm on
sudo parted /dev/sde set 1 lvm on
sudo parted /dev/sdf set 1 lvm on

sudo parted /dev/sdd print

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3220MB  3219MB               primary  lvm

set 1 lvm on - это просто маркер чтобы пользователю ОС было понятно, что это LVM диск. Ядро же понимает, что это LVM благодаря типу раздела в таблице разделов. Например Коды типов разделов для mbr и GUID для gpt. Но при использовании LVM тип раздела прописывается в супер-блоке самого раздела и даже если в MBR или GPT стоит другой тип, то ядро выберет тип, который в супер-блоке, т.е. LVM. Про MBR и GPT я также писал ранее.

Создаём PV

Для этого используем pvcreate и указываем наши PD. Команда pvcreate делит наш PV на Physical extends, по умолчанию блоки по 4Мб.

sudo pvcreate /dev/sdd1 /dev/sde1 /dev/sdf1
sudo pvdisplay

Создаём VG

Для этого используем команду vgcreate где указываем название группы и наши PV. Если делать аналогии, то по сути вы получаете после vgcreate один большой HDD.

sudo vgcreate VG01 /dev/sdd1 /dev/sde1 /dev/sdf1
sudo vgdisplay

  --- Volume group ---
  VG Name               VG01
  System ID
  Format                lvm2
  Metadata Areas        3
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                3
  Act PV                3
  VG Size               <8.99 GiB
  PE Size               4.00 MiB
  Total PE              2301
  Alloc PE / Size       0 / 0
  Free  PE / Size       2301 / <8.99 GiB
  VG UUID               33R3E3-wMFp-5xKi-HdVr-cKir-6efI-Fv2qMH

Команда создаст VG с именем VG01 и размером 6Гб.

Создаём LV

LV создаём используя команду lvcreate и указываем имя LV и его размеры и в конце имя VG. При этом используя опцию -L вы задаёте размер в байтах, а при использовании -l в Physical extends.

sudo lvcreate -n LV01 -l 1000 VG01
sudo lvcreate -n LV02 -L 700M VG01
sudo lvdisplay

 --- Logical volume ---
  LV Path                /dev/VG01/PV01
  LV Name                PV01
  VG Name                VG01
  LV UUID                HAxIpl-uJxf-YxdI-QIvT-3vbK-MHCi-ZmhjY6
  LV Write Access        read/write
  LV Creation host, time mylab-vm-4.dc2.my.local, 2021-10-02 17:12:30 +0600
  LV Status              available
  # open                 0
  LV Size                <3.91 GiB
  Current LE             1000
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:2

  --- Logical volume ---
  LV Path                /dev/VG01/PV02
  LV Name                PV02
  VG Name                VG01
  LV UUID                ic8QE3-bKiB-SMua-OR1c-Ax8a-IrM3-DKdP1M
  LV Write Access        read/write
  LV Creation host, time mylab-vm-4.dc2.my.local, 2021-10-02 17:12:55 +0600
  LV Status              available
  # open                 0
  LV Size                700.00 MiB
  Current LE             175
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3

Создаём файловую систему на LV

Для этого используем уже знакомую нам утилиту mkfs.

sudo mkfs.ext4 /dev/VG01/LV02
sudo mkfs.ext4 /dev/VG01/LV01

Монтируем наш LV

Ну и последним шагом будет монтирование в ОС.

sudo mkdir /my-lvm-01
sudo mkdir /my-lvm-02

sudo vim /etc/fstab

/dev/VG01/LV01  /my-lvm-01 ext4 defaults        0 0
/dev/VG01/LV02  /my-lvm-02 ext4 defaults        0 0

sudo mount -a
df -h

Удаляем LV

Для этого используем команду lvremove и передаём ей полный путь к LV.

sudo umount /my-lvm-01
sudo umount  /my-lvm-02

sudo lvremove /dev/VG01/LV01
sudo lvremove /dev/VG01/LV02

Удаляем VG

Для этого используем команду vgremove и передаём ей имя VG.

sudo vgremove VG01

Удаляем PV

Для этого используем команду pvremove и передаём ей имя PD.

sudo pvremove /dev/sdd1 /dev/sde1 /dev/sdf1

MsSql - Как мониторить действия пользователей

Fri, 01 Sep 2023 06:00:39 +0600

Изображение от vectorpouch на Freepik

Первый способ это создание триггеров и запись значений в таблицу, но мне такое не нравиться и здесь писать об этом я не буду, тем более у меня есть лицензия Enterprise.

Мы же рассмотрим вариант с использованием Server Audit Specifications, но только если у вас лицензия Enterprise.

Аудит в Ms SQL позволяет вам записывать и хранить действия пользователей как на уровне базы так и на уровне самого SQL сервера. Также предоставляется возможность выбрать что именно мониторить, об этом чуть ниже.

SQL Server Audit

Для начала нам потребуется создать объект Audit, вы можете создавать несколько объектов. Чтобы было проще это просто настройка как и где хранить события аудита.

Для того чтобы создать Audit переходим в Security > Audit > New audit.

Queue delay (in milliseconds) - Указывает время в миллисекундах, которое может пройти до принудительной обработки действий аудита. Значение 0 указывает на синхронную доставку. Минимальное значение по умолчанию — 1000 (1 секунда)
On Audit Log Failure - Тут вы указываете что делать если вдруг события аудита не сохраняются.
Audit destination - Тут мы выбираем куда именно сохранять события аудита. Можно выбрать журнал Windows или просто локальную/сетевую директорию. Рекомендуется выбирать вариант с директорией, так как временами слишком много событий, которые будут вам мешать отлавливать другие события. Хотя с помощью прав можно например запретить чистку журнала Windows, что гарантирует сохранность логов.
Maximum file size - максимальный размер файла с событиями (если сохранять в файл)

Либо можно воспользоваться запросом :

USE [master]
GO

CREATE SERVER AUDIT [Test_Server_Audit] --<< [Test_Server_Audit] must be changed
TO FILE 
(	FILEPATH = N'G:\Databases\'  --<< must be changed
	,MAXSIZE = 0 MB
	,MAX_ROLLOVER_FILES = 2147483647
	,RESERVE_DISK_SPACE = OFF
) WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE, AUDIT_GUID = '23758ca3-efb5-4add-97d6-9b099b3c7acf')
ALTER SERVER AUDIT [Test_Server_Audit] WITH (STATE = ON) --<< [Test_Server_Audit] must be changed
GO

Database audit specification

После того как мы создали аудит (где хранить и как) нужно указать что именно мы хотим мониторить. Прямо сейчас мы рассматриваем аудит действий с конкретной БД, действия с сервером рассмотрим ниже.

Для того чтобы создать Database audit specification переходим Databases > db_name > Security > Database Audit Specificationc > New.

Audit - тут выбираем аудит, который мы создали выше.
Audit Action Type- Список что именно нужно включить в аудит. Список групп и их предназначение можно глянуть тут или тут.

Благодаря таким настройкам я могу просмотреть что выполнял пользователи test или любой пользователь с правами sysadmin (dbo) при подключении к бд floob.

Либо можно воспользоваться запросом :

USE master;
GO

CREATE DATABASE AUDIT SPECIFICATION Test_Database_Audit --<< Test_Database_Audit must be changed
    FOR SERVER AUDIT Test_Server_Audit --<< Test_Server_Audit must be changed
    ADD (SELECT, UPDATE, DELETE, INSERT, EXECUTE ON SCHEMA::dbo BY test),
    ADD (SELECT, UPDATE, DELETE, INSERT, EXECUTE ON SCHEMA::dbo BY dbo)
    WITH (STATE = ON);
GO

Как проверить

Во первый нужно от пользователя test выполнить запросы к бд, в моём случае это простой select. После чего в зависимости от того что вы выбрали в качестве хранилища для аудита (файл или журнал Windows) получить эти события.

Если вы храните в файлах, то они будут с расширением .sqlaudit.

Для того чтобы получить доступ к содержимому можно воспользоваться Sql запросом:

SELECT * FROM sys.fn_get_audit_file('G:\Databases\*.sqlaudit', NULL, NULL) where database_name='floob';

2023-08-25 09:38:18.7476766	test	test	0x431B167D6AC2BF4AB13E57F6AD373C65	test		NULL		WIN-OCK9TD7MSK7	floob	SELECT TOP (1000) [x]    FROM [floob].[dbo].[dasdas]		G:\Databases\Test_Server_Audit_8B5A85A9-5B42-4D7A-8B2C-CE807711C928_0_133374297948610000.sqlaudit

Server audit specification

По сути тут всё тоже самое как и в Database audit specification только на уровне сервера.

Для того чтобы создать Server audit specification переходим Security > Server Audit Specificationc > New.

Audit Action Type- Список что именно нужно включить в аудит. Список групп и их предназначение можно глянуть тут или тут.

USE [master]
GO

CREATE SERVER AUDIT SPECIFICATION [Test_Server_Audit] --<< Test_Server_Audit must be changed
FOR SERVER AUDIT [Test_Server_Audit] --<< Test_Server_Audit must be changed
ADD (AUDIT_CHANGE_GROUP)
WITH (STATE = ON)
GO

ALTER DATABASE AUDIT SPECIFICATION Test_Database_Audit
    WITH (STATE = OFF);
GO

SELECT * FROM sys.fn_get_audit_file('G:\Databases\*.sqlaudit', NULL, NULL) where statement like '%AUDIT%' ;
GO

2023-08-25 11:06:57.9158665			Test_Database_Audit	ALTER DATABASE AUDIT SPECIFICATION [Test_Database_Audit]  WITH (STATE = OFF)		G:\Databases\Test_Server_Audit_23758CA3-EFB5-4ADD-97D6-9B099B3C7ACF_0_133374313105990000.sqlaudit

Docker - Настройка часовых поясов в контейнерах

Fri, 01 Sep 2023 06:00:39 +0600

Сразу скажу что я пробую с контейнером Ubuntu 20.04.6 LTS. На самом деле это контейнер hyperledger/fabric-orderer, но не важно.

ENV TZ=”Asia/Almaty”

Если вы можете создать свой собственный образ, то можно добавить строки в Dockerfile:

FROM ubuntu:20.04
RUN apt-get update && \
    apt-get install -yq tzdata
ENV TZ="Asia/Almaty"

Тут устанавливается пакет tzdata, но можно обойтись и без него. Об этом ниже.

TZ=”Asia/Almaty” в docker

По сути нам лишь достаточно передать переменную TZ с нужным значением. И по сути всё должно работать.

docker run  -e TZ='Asia/Almaty' -it hyperledger/fabric-orderer:latest bash

Так а почему не работает?

А не работает потому что как нам известно docker образы обычно урезаны, чтобы не занимать много места и т.д. Так вот всё временные зоны у нас хранятся в директории /usr/share/zoneinfo/, которой в контейнере конечно нет.

Cамым простым будет будет проброс этой директории с хоста в контейнер:

docker run  -e TZ='Asia/Almaty' –volume /usr/share/zoneinfo/Asia:/usr/share/zoneinfo/Asia:ro -it hyperledger/fabric-orderer:latest bash

Docker compose file

services:
 orderer2:
    container_name: orderer2
    environment:
      - TZ=Asia/Almaty
    volumes:
      - /usr/share/zoneinfo/Asia:/usr/share/zoneinfo/Asia:ro

WinlogBeat - WARN EventLog[Security] Open() error. No events will be read from this source. The specified query is invalid.

Fri, 01 Sep 2023 06:00:39 +0600

Для доставки событий из Windows в ELK используется WinlogBeat. В принципе по настройке всё и так есть на офсайте.

WARN EventLog[Security] Open() error. No events will be read from this source. The specified query is invalid

Теперь про саму ошибку, с которой вы столкнётесь если вдруг решите отфильтровать что именно нужно слать.

winlogbeat.event_logs:
  - name: Security
    event_id: 1102,4624,4625,4723,4724,4728,4729,4732,4733,4738,4740,4746,4747,4751,4752,4756,4757,4761,4762,4767,4771,5136,5137,5141,5236

Тут видно, что я указал конкретные события, их количество в общем составляет 25. Но вот у Windows есть ограничение, которое не позволят Winlogbeat читать журнал событий.

Для того, чтобы обойти это ограничение воспользуемся процессом drop_event. Суть работы заключается в следующем:

Winlogbeat получает все события
Уже сам фильтрует что именно отправить

winlogbeat.event_logs:

  - name: Security
    processors:
      - drop_event.when.not.or:
        - equals.winlog.event_id: "1102"
        - equals.winlog.event_id: "4624"
        - equals.winlog.event_id: "4625"
        - equals.winlog.event_id: "4723"
        - equals.winlog.event_id: "4724"
        - equals.winlog.event_id: "4728"
        - equals.winlog.event_id: "4729"
        - equals.winlog.event_id: "4732"
        - equals.winlog.event_id: "4733"
        - equals.winlog.event_id: "4738"
        - equals.winlog.event_id: "4740"
        - equals.winlog.event_id: "4746"
        - equals.winlog.event_id: "4747"
        - equals.winlog.event_id: "4751"
        - equals.winlog.event_id: "4752"
        - equals.winlog.event_id: "4756"
        - equals.winlog.event_id: "4757"
        - equals.winlog.event_id: "4761"
        - equals.winlog.event_id: "4762"
        - equals.winlog.event_id: "4767"
        - equals.winlog.event_id: "4771"
        - equals.winlog.event_id: "5136"
        - equals.winlog.event_id: "5137"
        - equals.winlog.event_id: "5141"
        - equals.winlog.event_id: "5236"

Loki - entry too far behind, oldest acceptable timestamp is

Sun, 20 Aug 2023 06:20:39 +0600

На самом деле тут всё и так понятно из самой ошибки. Т.е. Loki у вас так настроен что нельзя отправлять данные старее определённого времени.

reject_old_samples

По умолчанию Loki не позволяет записывать старые события . Т.е. допустим, что сейчас 18:00, но вот приложение шлёт события с датой 17:30. В таком случае вы получите ошибку о том, что timestamp старый.

Можно вообще отключить проверку timestamp:

limits_config:
  reject_old_samples: false

Можно задать допустимое время:

limits_config:
  reject_old_samples: true
  reject_old_samples_max_age: 1h

max_chunk_age

Может так случится что даже после настройки reject_old_samples вы всё ещё получаете эту ошибку.

Тогда взгляните на параметр max_chunk_age, и установите значение которое будет больше вашего рассинхрона.

ingester:
  max_chunk_age: 2h

Что такое этот наш Linux

Fri, 11 Aug 2023 02:22:39 +0600

Это сейчас мы все говорим про Linux, но было время, когда все говорили о Unix. Это по сути прародитель Linux. В 1991 Линус Торвальдс создал новое Unix-подобное ядро, которое назвал Linux, и распространил под лицензией GPL.

Linux

Linux в последнее время стал весьма важной технологией в сфере IT. И каждый уважающий себя IT специалист обязан уже иметь базовые понятия о Linux. Что уж говорить если даже Microsoft начал выпускать что-то для Linux.

По сути большая часть интернета, которую вы посещаете каждый день так или иначе построена на ОС Linux. И большая часть всех наших умных смарт-телевизоров также построены на Linux.

Вот несколько причин почему вы обязаны узнать немного о Linux:

Бесплатное ПО (Для некоторых стран чуть ли не самый главный пункт)
Microsoft так или иначе уже начал поддерживать Linux сообщество
Большие гиганты облачных услуг используют преимущественно Linux
Andorid, IOT и др. технологии в качестве основной ОС используют Linux
Устройства с Linux часто более высоко производительнее и стабильнее
Linux не так прожорлив по отношению к аппаратным ресурсам

Также большую популярность Linux обрёл благодаря своей **открытости (open source) **, благодаря открытому исходному коду конечно. Не всегда конечно открытый исходный код подразумевает что вы в миг поймёте, как что работает. Но благодаря наличию исходного кода вы можете дописывать что-то своё и любезно этим делится с сообществом.

Основным преимуществом перед Windows является то что в основе лежит CLI интерфейс а не GUI. Особенно вы это почувствуете если вы подключаетесь к ОС с использованием слабого интернет канала. В наши дни это уже не настолько часто происходит, но всё же в определённые моменты — это большой и жирный плюс. Microsoft тоже это признала, когда начала вводить Powershell. Также использование CLI упрощает процесс автоматизации.

Что такое Open Source

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

Исходный код — это набор удобочитаемых инструкций, которые используются для создания программы. После создания исходного кода на него распространяются авторские права, благодаря которым указывается может ли исходный код модифицироваться и распространяться. Это задаётся типом лицензии, которая указана для исходного кода.

Существует тип лицензии при котором менять исходный код могут только разработчики исходного кода. Такой тип исходного кода называется проприетарным (proprietary) или закрытым (closed).

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

Вот несколько критериев выгоды использования Open Source:

Контроль - вы можете сами просматривать исходный код и понимать, что творится внутри приложения
Обучение - вы можете учиться писать правильный код просматривая исходный код
Безопасность - инспектирование исходного кода, а также его доработка без участия разработчика
Стабильность - код может жить и развиваться даже без участия основного разработчика
Бесплатно - кто не любит халяву?

Типы лицензий Open Source

Я уже говорил о том, что использование исходного кода зависит от типа лицензии.

Рассмотрим два основных типа лицензий с открытым исходным кодом:

Copyleft - обеспечение свободы использования (включая все другие права) и предоставления последующим пользователям права изменять, распространять и использовать программное обеспечение по своему усмотрению. Требуется чтобы любой разработчик исходного кода передавал другим право на изменение своего исходного кода. Включают в себя лицензии типа GPL (General Public License) и LGPL (Lesser General Public License).

Требует, чтобы использовалась та же лицензия, что и у исходной работы. Например, если вы пишете какое-то программное обеспечение и выпускаете его под GNU GPL, а затем кто-то другой модифицирует это программное обеспечение и распространяет свою измененную версию, измененная версия также должна быть под лицензией GNU GPL.
Permissive - лицензия на программное обеспечение, иногда также называемая лицензией типа BSD, представляет собой лицензию на программное обеспечение с минимальными ограничениями на использование. Т.е. пользователь всё также может менять что хочет при условии сохранения авторских прав изначального разработчика. И не обязательно чтобы вы выкладывали в открытый доступ ваши изменения, в отличии от лицензии Copyleft.

Дистрибутивы Linux

Так как любой желающий может создать свою собственною версию Linux дистрибутивов в интернете куча. Но мы сконцентрируемся только на ответственных компаниях, которые не бросают свои проекты.

И вот продукты плодов таких компаний:

Fedora Linux (2003 год)
Ubuntu Desktop, Server, Core (2004 год)
Red Hat Enterprise Linux (1994 год)
Linux Mint (2007 год)
Debian (1993 год)
openSUSE (2005 год)

Кто такие RedHat?

В наше время конечно Open Source коммерциализировался, если раньше код писали волонтеры, то сейчас его пишут программисты, которым за это еще и платят.

RedHat является одним из основных лидеров разработки Open Source. Но они как раз-таки платят разработчиком, и для того чтобы получать прибыль они продают подписки. Участвует в разработке многих Open Source решений, иногда совместно с другими гигантами IT.

Основная идея RedHat это найти интересный продукт в сети. Дописать к нему что-то новое и выпускать к нему постоянные обновления по подписке, также включающую поддержку. И также создать нормальную документацию к продукту. Кто сталкивался с документацией по Open Source проекту знает не понаслышке какой это иногда бывает ад.

Veeam - Бэкап PostgreSQL с использованием WAL журналов

Sat, 24 Jun 2023 06:20:39 +0600

Это вторая статья из серии бэкапов PostgreSQL с помощью Veeam. Напомню, что на момент написания первой статьи это были скорее всего костыли чем настоящий бэкап. И вот вышла наконец 12 версия Veeam Backup and Replacion где стало возможным делать бэкап с использованием WAL файлов. Соответственно теперь можно и восстановиться на определённое время.

Для начала обновите Veeam Backup and Replacion до версии 12.

Требования и ограничения

Для начала убедитесь в том, что порт 5432 на устройстве с PostgreSQL доступен с сервера где установлен Veeam
Необходимо иметь версию PostgreSQL не ниже 12 и не выше 15.2 (на момент публикации статьи)
Veeam Backup & Replication не поддерживает резервное копирование кластеров PostgreSQL
Veeam Backup & Replication не поддерживает резервное копирование отдельных баз данных PostgreSQL
Установите параметр archive_mode в режим on (postgresql.conf)
archive_command должно быть пустым (postgresql.conf)
Параметр wal_level должен быть replica или logical
Каталог /tmp должен быть примонтирован с опцией exec

Бэкап отключенного экземпляра

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

Установка Veeam Agent for Linux

Я надеюсь у вас не стоит PostgreSQL на ОС Windows, но если и стоит, то спешу вас расстроить что бэкап PostgreSQL с использованием WAL файлов будет работать только на Linux.

О том, как поставить Veeam Agent for Linux читаем тут. Версия агента должна быть не ниже 6.0.0.1060.

Добавляем задачу в Veeam Backup and Replication

После того как вы установили Veeam Agent for Linux можно приступать к созданию задачи. Для этого:

Переходим в Jobs > Backup > Linux Computer и добавляем новую задачу

Добавляем сервер с PostgreSql

Ставим галочку напротив Enable application-aware processing и настраиваем бэкап PostgreSql, а именно добавляем пользователя для подключения к PostgreSql. И вот тут уже новенькие настройки, которые доступны только начиная с версии 12.

 3.1. Тут просто ставим галочку, которая активирует возможность делать бэкап определённой программы
 3.2 Тут нужно ввести логин и пароль пользователя от ОС (доступ по ssh)
 3.3 Открываем вкладку PostgreSQL
 3.4 Задаём логин (пароль нужен если выбрали первое в 5) для доступа к PostgreSql
 3.5 Тут в зависимости от предпочтений выбираем метод аутентификации
 3.6 Устанавливаем с какой периодичностью делать бэкап WAL файлов
 3.7 Директорию куда именно сперва записывать WAL файлы

Дальше выставляем время запуска и завершаем мастер создания задачи
После запланированного запуска задачи в активных задачах появится вложенная задача, которая будет висеть в фоне и делать бэкап WAL файлов каждые 15 минут (указывается в 3.6)

Восстановление

Для восстановления переходим в Home > Backups > Disk > Your backup > Backup > Application Item > PostgreSQL. В открывшемся окне выбираем нужную точку восстановления.

Далее жмём Next пока не получаем кнопку Browse, которую собственно и нажимаем. Благодаря чему запустится Veeam Explorer for PostgreSQL.

И собственно выбираем куда и как восстанавливать.

Также тут можно применить восстановление на определённое время.

Заключение

К сожалению, на момент написания статьи все ещё нет возможности восстановить определённую БД или таблицу, но возможно в будущем эта возможность появится.

Gitlab - Восстановление утерянной 2FA

Tue, 06 Jun 2023 06:20:39 +0600

В Gitlab можно привязать двухфакторную аутентификацию, как правило это Google Authentificator. Так вот может произойти так что в какой-то момент вы вспомните что потеряли доступ к Google Authentificator, а зайти на Gitlab уж очень нужно.

Вариант 1: Использование кодов восстановления

Самый простой способ просто вбиваете один с кодов в поле pin code и авторизуетесь. Но это только если у вас остались эти коды. Кстати перегенерить их можно по ссылке https://my-gitlab.com/-/profile/two_factor_auth.

Вариант 2: Использование ssh

Если вы до этого авторизовались через ssh, т.е. добавляли свой ключ то можно воспользоваться командой:

ssh git@my-gitlab.com 2fa_recovery_codes

Вариант 3: Использование gitlab-rails

Самый верный вариант, но только если у вас есть доступ к самому серверу по ssh, где установлен Gitlab.

Запускаем консоль gitlab-rails
```
gitlab-rails console
```
Получаем нужного пользователя
```
u = User.find_by_username('user1')
u.attributes
```

Отключаем OTP

u.otp_required_for_login=false
u.encrypted_otp_secret=""

На всякий случай активируем пользователя (вдруг заблокирован)
```
u.state="active"
```
Сохраняем
```
u.save
```
Авторизуемся в Gitlab

Grafana Loki - Multi-tenancy

Tue, 06 Jun 2023 06:20:39 +0600

С определённого времени Grafana Loki является многопользовательской системой, если я правильно перевёл Multi-tenancy) Если объяснять это простым языком, то получается следующее: у вас в одном кластере могут храниться данные нескольких владельцев. Например, у вас есть организация А и организация B. Логично что владелец организации B хотел бы чтобы логи его серверов могли видеть только его сотрудники. И функция Multi-tenancy как раз предназначена для этого.

Чтобы получить доступ к логам организации B вам будет необходимо предоставить orgID (Tenant ID) через X-Scope-OrgID в HTTP-заголовке. Tenant ID (orgID) может содержать буквенно-цифровые символы.

По умолчанию Loki запускается в моде multi-tenant и активируется переменной auth_enabled: true в файле конфигурации Loki. Если auth_enabled стоит в false то по сути у вас всего один Tenant с именем fake. Т.е. никакого разграничения нет, и логи видят все по умолчанию.

На рисунке ниже я предоставил скрин с двумя Tenant ID, так они выглядят в хранилище (S3).

Multi-tenancy запросы (Get)

И логичный вопрос возникает в вашей голове: а как собственно получить доступ к тому или иному Tenant ID. Для примера если вы запустите Loki из примера на github вы по умолчанию получите доступ только к Tenant ID равным docker. Но об этом чуть попозже.

Так вот чтобы получить доступ к tenant A нужно выполнить следующий запрос:

curl --location 'http://loki-gateway:8080/loki/api/v1/labels' --header 'X-Scope-OrgID: A'

Но что делать если вдруг захотелось обратиться сразу к нескольким Tenant ID? Первым делом в файле конфигурации добавляем multi_tenant_queries_enabled: true и в запросе указываем несколько id через |.

curl --location 'http://loki-gateway:8080/loki/api/v1/labels' --header 'X-Scope-OrgID: A|B'

Если же вы выполните запрос без указания Tenant ID, то вы просто на выходе получите no org id.

Multi-tenancy запросы (Post)

Конечно получить значение — это хорошо, но как быть если их еще нет. Т.е. как записать что-либо в Loki используя Multi-tenancy. Для этого выполним самый обычный Post используя curl:

curl --location 'http://127.0.0.1:3100/loki/api/v1/push' \
--header 'X-Scope-OrgID: A' \
--header 'Content-Type: application/json' \
--data '{"streams": [{ "stream": { "foo": "bar2" }, "values": [ [ "1690877832000000000", "fizzbuzz" ] ] }]}'

Обратите на первое значение в values. Тут 1690877832000000000 означает время события, указанное в Unix варианте (мс). Собственно можно воспользоваться онлайн конвертером, но не забудьте еще добавить шесть нулей.

Как указать Tenant ID в Grafana

Мы рассмотрели, как передать Tenant ID в сыром curl запросе, но если вы хотите смотреть логи через Grafana то в data source нужно будет также указать Tenant ID.

Открываем наш data source на редактирование http://grafana:3000/datasources/edit/loki
Добавляем в Custom HTTP наш Tenant ID (Headers X-Scope-OrgID: A)

Или можно также это сделать через yaml (httpHeaderValue1):

apiVersion: 1
datasources:
  - access: proxy
    basicAuth: false
    jsonData:
      httpHeaderName1: "X-Scope-OrgID"
    secureJsonData:
      httpHeaderValue1: "A"
    editable: true
    isDefault: true
    name: loki
    type: loki
    uid: loki
    url: http://loki-gateway
    version: 1

Заключение

Возможно кто-то не согласиться что это решение можно применять для разграничения прав доступа, но в принципе вы можете создать несколько datasources с разными Tenant ID и уже раздавать доступ пользователям к этим datasources. Правда разграничение прав на datasources есть только в Grafana Enterprise и Grafana Cloud Pro and Advanced.

Logstash - Could not load FFI Provider (NotImplementedError) FFI not available

Thu, 25 May 2023 06:20:39 +0600

После установки logstash в логах получаю ошибку Could not load FFI Provider: (NotImplementedError) FFI not available после чего сервис просто перезапускается.

Проблема может быть в том, что у вас нестандартные права на папку /tmp при монтировании, например, в моём случае стояла опция noexec.

Для исправления этой ситуации выполняем:

sudo mount -o remount,exec /tmp
sudo vim /etc/fstab

UUID=5fb /tmp                    xfs     defaults,exec          0 0

Logstash - Unable to configure plugins Couldn't find any output plugin named loki

Thu, 25 May 2023 06:20:39 +0600

Для начала нужно конечно установить сам плагин, в моём случае это плагин logstash-output-loki.

Ставится плагин следующей командой:

/usr/share/logstash/bin/logstash-plugin install logstash-output-loki

Unable to configure plugins: (PluginLoadingError) Couldn’t find any output plugin named ‘loki’

На даже после того как я его поставил я всё равно получаю эту ошибку. А всё дело в том, что сервис logstash запускается от одноименного пользователя, у которого просто нет прав на директорию с файлами плагина. Плагины лежат в директории /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/.

Как не трудно догадаться нужно сделать владельцем директории с плагином пользователя logstash.

sudo chown -R logstash /usr/share/logstash/

sudo systemctl restart logstash
sudo systemctl status logstash

Grafana OnCall - Изменение GRAFANA_API_URL

Thu, 25 May 2023 06:20:39 +0600

При использовании версии с Docker url для связи OnCall с Grafana задаётся в переменной GRAFANA_API_URL. И всё бы ничего, но вот эта переменная задаётся единожды и если вы её поменяли, то она просто так не обновиться.

Как обновить переменную GRAFANA_API_URL

Для начала нужно найти файл с базой данных, по дефолту она лежит тут /var/lib/docker/volumes/loki_oncall_data/_data/oncall.db.

sudo find / -name oncall.db

Далее подключаемся к бд и меняем url в таблице

sqlite3 /var/lib/docker/volumes/loki_oncall_data/_data/oncall.db

select * from user_management_organization;
UPDATE user_management_organization
SET grafana_url = "http://grafana.new:3000"
WHERE
    grafana_url = "https://grafana.old:3000";

Grafana - Устанавливаем плагин без интернета

Thu, 25 May 2023 06:20:39 +0600

Причины отсутствия интернета на сервере разные, начиная от правил ИБ заканчивая национальным сертификатом безопасности, которые не везде возможно добавить в доверенные.

В моём случае именно сертификат по середине был проблемой, так как добавить его в контейнер с Alpine Linux не получилось. Поэтому распишу тут как можно решить обе проблемы.

Где найти плагины?

Переходим по ссылке storage.googleapis.com и ищем интересующий нас плагин, например oncall. В итоге я нашёл следующее grafana-oncall-app/release/v1.2.14/grafana-oncall-app-v1.2.14.zip, добавляю это к https://storage.googleapis.com/plugins-community/ и получаю https://storage.googleapis.com/plugins-community/grafana-oncall-app/release/v1.2.14/grafana-oncall-app-v1.2.14.zip.

Либо второй способ, который более простой. Просто находим плагин на сайте grafana.com и находим там ссылочку скачать, например как тут.

Вариант 1

Первое что можно сделать это скачать по ссылке архив на компьютере, где это возможно и перекинуть на сервер с Grafana.

Скачиваем архив на компьютер и переносим на сервер
Разархивируем всё в папку /var/lib/grafana/plugins/plugin_name
Перезапускаем Grafana

Вариант 2

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

grafana-cli --insecure plugins install grafana-oncall-app

Саму команду установки можно найти на офсайте самого плагина, например, grafana.com.

Вариант 3

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

Создаём прокси репозиторий на url https://storage.googleapis.com

При использовании команды grafana-cli просто указываем сторонний url к файлу

grafana-cli --insecure --pluginUrl https://nexus.example.lan:8443/repository/storage.googleapis.com/plugins-community/grafana-oncall-app/release/v1.2.14/grafana-oncall-app-v1.2.14.zip plugins install oncall

Перезапускаем Grafana

GLPI - Инвентаризация ESXI хостов

Thu, 25 May 2023 06:20:39 +0600

Как правило в GLPI для инвентаризации используют FusionInventory, но мне что-то он не совсем понравился именно при работе с ESXI. Но всё конечно зависит от требований, в моём случае достаточно выполнять сбор информации разово. Поэтому я решил сделать это родным агентом от GLPI.

Включить возможность инвентаризации в GLPI

Делается это галочкой в настройках по ссылке http://glpi.lan/front/inventory.conf.php (Enable inventory).

Установка GLPI Agent

Для начала нужно поставить агент на хост, с которого вы будете подключаться к ESXI хосту или Vceneter. На сам ESXI пакетов нет, и, если только ставить их source. Естественно этот хост должен иметь доступ к ESXI хосту.

Ставим GLPI Agent, инструкция по ссылке.

Сбор информации о ESXI

Для Windows:

.\glpi-esx.bat --host 192.168.61.205 --user dasd --password sadasd --directory C:\Users\dasdas\Downloads

Для Linux:

glpi-esx --host 192.168.61.205 --user dasd --password sadasd --directory /tmp

Отправка в GLPI

Для Windows:

.\glpi-injector.bat -v --file C:\Users\dasdas\Downloads/localhost-2023-05-23-10-45-24.ocs -u http://glpi.lan/

Для Linux:

glpi-injector -v --file /tmp/localhost-2023-05-23-10-45-24.ocs -u http://glpi.lan/

Grafana Loki - Как хранятся данные

Tue, 11 Apr 2023 06:20:39 +0600

В отличии от других систем логирования, которых развелось уже уйма разработчики Loki решили, что он не будет индексировать ваши логи а будет индексировать только их метаданные (labels). Сами данные затем сжимаются и сохраняются фрагментами (chunks) в различных файловых хранилищах, например, таких как S3, GCS или в файловой системе. Индекс имеющий минимальный размер и данные, которые хорошо сжаты упрощают работу и также снижают цену, так как для хранения не нужно много дискового пространства (расскажите это людям с ELK).

Скажу сразу то, что я здесь описываю актуально для версий Loki после Loki 2.0. Там было немного иначе, но смысла описывать я это не вижу так как продукт на рынке недавно и скорее всего вы будете работать с более новой версией, как и я.

Loki 2.0 дал возможность использовать одно единое хранилище для индекса и фрагмента, благодаря механизму под названием boltdb-shipper. Люди близкие к этому творению дали ему имя Single Store Loki.

Индексы и фрагменты

Как мы уже знаем данные хранятся в фрагментах (chunks). Loki принимает логи в отдельных потоках (streams), каждый из которых имеет свой уникальный идентификатор (ID) и его набор меток (labels). Далее всё сжимается в фрагментах (chunks) и записывается в хранилище данных.

Индексы же хранят информацию о наборе меток (labels) и их связях с отдельными фрагментами (chunks).

Table Manager

Table Manager - это один из субкомпонентов в Loki. Loki поддерживает хранение индексов и фрагментов (chunks) в табличных хранилищах данных. Благодаря этому создаётся множество таблиц за определённое время. Каждая такая таблица также называется периодической таблицей, в которой хранятся данные за определённое время. Это время конечно же можно изменить.

По задумке разработчиков благодаря такому типу хранения вы получаете следующие преимущества:

Изменения конфигурации схемы: каждая таблица привязана к конфигурации и версии схемы, благодаря чему вы можете вносить изменения в схему в любой момент. Если проще новые данные принимают новую схему, а старые используют старую, вы просто указываете с какого времени применяется та или иная схема.
Операции удаления происходят гораздо быстрее

Не все типы хранилищ поддерживают использование Table Manager, список поддерживающих можно проверить на офф сайте.

Таблицы и конфигурация схемы

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

schema_config:
  configs:
    - from: 2023-02-23
      store: boltdb-shipper
      object_store: filesystem
      schema: v12
      index:
        prefix: index_
        period: 24h | default = 168h    <<<<<<<<<<<<<<<<
	  chunks:
        prefix: chunk_
	    period: 24h | default = 168h	<<<<<<<<<<<<<<<<

Также раздел schema_config может содержать не только одну конфигурацию схемы, как мы уже и говорили. Всё благодаря from где вы как раз и указываете с какого момента начинает действовать схема. Самая ближняя конфигурация по дате к сегодняшнему числу является активной конфигурацией схемы. Значение period должно быть кратно 24 часам.

Т.е. если мы возьмём промежуток в неделю, то у нас с конфигурацией как выше должно быть 7 таблиц.

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

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

Если вам нужно залить старые данные, то можно изменить конфигурацию:

reject_old_samples: true | default = false
reject_old_samples_max_age: 168h | default = 336h

Создание таблицы

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

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

table_manager:
  creation_grace_period: 20m | default = 10m

Хранение (Retention)

По умолчанию возможность удаления старых логов выключена и понятно почему. Но если вдруг вам это необходимо можно включить эту опцию и задать время хранения данных.

table_manager:
  retention_deletes_enabled: true
  retention_period: 4d

Т.е. при такой конфигурации Table Manager будет хранить только те таблицы, в которых данные не старее 4 дней с сегодняшнего дня. Причём мы помним что удаляется таблица целиком, поэтому не удивляемся если данные за 5 день всё еще присутствуют, если period конечно в schema_config 24h. Нужно дождаться чтобы день закончился полностью.

В целом чтобы узнать за какое время будут сохранены ваши данные можно воспользоваться формулой:

number_of_tables_to_keep = (retention_period / table_period) + 1

Т.е. если брать во внимание все настройки как в этой статье мы получаем 5 дней. Получается что всё старее 5 дней будет удаленно, но не сразу.

5 дней = (4 дня / 1 день) + 1 день

И последняя ремарка значение retention_period должно быть кратно 24 часам как и значение period.

Всё настроено, на индексы не удаляются

Во время тестирования я столкнулся с тем что после истечения времени мои старые индексы не удалялись. Т.е. время жизни индекса превышало number_of_tables_to_keep но сами индексы не удалялись.

И вот я наткнулся на информацию об обновлении где сказано что The single binary no longer runs a table-manager. Т.е. возможно table-manager у меня и не работает?

Но вот при каких условиях он собственно и не работает:

Вы запускаете бинарный файл loki с опцией -target=all
Вы запускаете бинарный файл loki без опции, но по умолчанию значение всё также -target=all
Запуск одного бинарного Loki с любым типом индекса, кроме boltdb-shipper или boltdb
Если вы активировали опции retention_deletes_enabled и retention_period

Первый способ выйти из положения это запустить с -target=all,table-manager, что кстати сами разработчики не рекомендуют делать.

Но суть в в том что в моем случае я и так запускал без -target=all а именно -target=write и -target=read. Но как только я добавил table-manager старые индексы удалились.

И второй способ это отказаться от table-manager и использовать compactor, который кстати работает только с хранилищем boltdb-shipper.

На самом деле тут мне кажется ребята немного перемудрили и это первое что мне не совсем понравилось в этом продукте.

Активные/неактивные таблицы

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

MinIO - Обновление

Tue, 21 Mar 2023 06:20:39 +0600

Перед тем как решится обновить ваш сервер MinIO рекомендуется сперва протестировать новую версию на отдельном тестовом сервере.

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

Checklist

Перед обновлением просмотрите все элементы в следующем контрольном списке:

Тестирование на неважных серверах (staging, test, demo)
Обновляйте только при необходимости MinIO идёт по пути быстрой разработки, при которой в неделю может быть несколько релизов. И не факт что вам нужен этот релиз.
Обновления требуют одновременного перезапуска. Мы уже говорили о том что не рекомендуется перезапускать ноды MinIO по отдельности, и обновление тут не исключение. Нужно делать всё одновременно.

Обновление

1. Обновляем на каждой ноде

Качаем новый пакет и обновляем одним из возможных методом.

Обновление с использованием RPM (RHEL)

wget https://dl.min.io/server/minio/release/linux-amd64/minio-20220519182059.0.0.x86_64.rpm -O minio.rpm
sudo dnf update minio.rpm -y

Обновление с использованием DEB(UBUNTU)

wget https://dl.min.io/server/minio/release/linux-amd64/minio_20220519182059.0.0_amd64.deb -O minio.deb
sudo dpkg -i minio.deb

Обновление бинарный файл

wget https://dl.min.io/server/minio/release/linux-amd64/minio
sudo mv minio /usr/local/bin/
sudo chmod +x /usr/local/bin/minio

2. Перезапуск сервиса на каждой ноде

Выполните systemctl restart minio одновременно на всех узлах развертывания. Опять таки не забываем о том что нужно выполнять одновременно на всех нодах.

Но лучше просто воспользоваться командой mc admin service restart alias, которая сама перезапустить все нода в пуле.

Обновление с помощью клиента

Используя команду mc admin update ALIAS вы также можете обновить все бинарные файлы сервера MinIO перед одновременным перезапуском всех узлов. Т.е. перезапуск всех нод в пуле серверов произойдёт автоматически.

Если вы вдруг хотите выкачать бинарные файлы MinIO по другому URL (например, прокси репозиторий) то можно воспользоваться командой mc admin update ALIAS https://minio-mirror.example.com/minio

Обновление MinIO client

Также вам будет необходимо обновить и сам MinIO client используя команду mc update.

Либо выкачиваем bin файлы по ссылке https://dl.min.io/client/mc/release/linux-amd64/mc и заменяем файл mc на новый.

Решаем ошибку open /usr/local/bin/.minio.check-perm: permission denied

Это ошибка говорит о том, что у пользователя, от которого запущен MinIO нет прав на создание файлов в директории MinIO. Т.е. вам просто нужно добавить права на запись для пользователя MinIO на директорию в которой находится файл minio.

which minio
sudo chmod o+w /usr/local/bin
mc admin update ALIAS
sudo chmod o-w /usr/local/bin

MinIO - Рекомендации

Tue, 21 Mar 2023 06:20:39 +0600

Если хотите узнать, что же нам рекомендуют для установки MinIO то читаем об этом ниже.

Минимальное количество нод

При установке в production среде MinIO рекомендуется минимум 4 ноды по 4 диска на каждой ноде в одном пуле серверов. С таким подходом вы можете продолжать полную работу с пулом даже при потере 4 дисков либо одной ноды полностью.

MinIO – популярный открытый сервер хранилища объектов, совместимый с сервисом облачных хранилищ Amazon S3. Также немаловажным преимуществом проекта является возможность использования его в Kubernetes.

Серверное оборудование

В статье о MinIO в распределенном режиме я уже упоминал что рекомендуется использовать одинаковое железо для всех нод в пуле.

Сам MinIO не зависит от архитектуры сервера. Но, как и везде есть рекомендуемые минимальные требования для серверов, правда если вы используете для хранения больших объёмов данных. На самом официальном сайте не указано что они подразумевают под большим объёмом данных.

Таблица минимальных системных требований:

Тип	Значение
Процессор	Два процессора Intel Xeon Scalable Gold с 8 ядрами на сокет.
Память	128GB для каждой ноды
Сеть	Минимум 25GbE NIC и поддерживающая сетевая инфраструктура между узлами.
Диски	SATA/SAS NVMe/SSD с минимум 8 дисками на сервер. Также рекомендации по дискам вы можете найти в этой статье.

Выделение памяти

Общее хранилище	ОЗУ
До 1 Тебибайта (Ti)	8GiB
До 10 Тэбибайт (Ti)	16GiB
До 100 Тэбибайт (Ti)	32GiB
До 1 Пебибайта (Pi)	64GiB
Больше 1 Пебибайта (Pi)	128GiB

Ansible - Создание пользователя

Sun, 19 Mar 2023 03:22:39 +0600

На самом деле тут ничего такого сложного чтобы об этом писать. Но вот можно по невнимательности наступить на грабли.

Суть в том, что при использовании модуля user пароль задаётся через переменную password. Но есть одно, но, хоть в типе и написано string если вы создаёте пользователя на linux то значение нужно шифровать.

Т.е. если вы просто напишите так, как снизу то работать это не будет.

  - name: Add user 
    user:
      name: user
      password: "123456"

Да, задача выполниться успешно и даже создастся пользователь, но вот зайти в систему под ним вы не сможете. А в логах будет сверкать запись: pam_sss(sshd:auth): received for user : 10 (User not known to the underlying authentication module)

Как правильно?

Правильный вариант создания пользователя с указанием пароля выглядит так (пароль 123456 не безопасный):

  - name: Add user 
    user:
      name: user
      password: "{ {  pwd | password_hash('sha512') } }"
    vars:
	  pwd: "123456"

Типы резервных копий

Thu, 16 Mar 2023 06:20:39 +0600

Я думаю в наше время администраторы уже в курсе что может произойти с данными если не делать резервные копии. Если ваш друг, знакомый еще этого не знает посоветуйте ему начать изучать эту тему. Может это спасёт его ж… от ненужных приключений в будущем.

Вернёмся к теме, и рассмотри три основных типа резервных копий:

Полное резервное копирование (Full Backup)
Дифференциальное резервное копирование (Differential Backup)
Инкрементное резервное копирование (Incremental Backup)

Сравнительная таблица

Тип резервного копирования	Описание	Преимущества	Недостатки	Применимость
Полное (Full Backup)	Создается полная копия всех данных. Каждая новая резервная копия содержит все файлы, т.е. даже те что были обработаны ранее.	Простота восстановления	Создание резервной копии занимает много времени. Занимает много места на хранилище.	Как правило используется при первом резервном копировании, является базовой точкой восстановления
Дифференциальное (Differential Backup)	Сохраняет изменения, произошедшие после последнего полного резервного копирования	Восстановление быстрее, нужны только последнее полное и последнее дифференциальное копии. Используется меньший объем хранилища.	Время выполнения увеличивается с ростом измененных данных	Оптимально для средне-критичных систем, когда необходимо сократить время восстановления, но при этом минимизировать использование хранилища
Инкрементное (Incremental Backup)	Сохраняет только изменения, произошедшие после последнего резервного копирования (любого типа)	Минимальное использование дискового пространства. Резервная копия создаётся быстрее.	Восстановление занимает больше времени. Повышенный риск утери данных	Используется в высоконагруженных системах с частым резервным копированием, когда важна экономия ресурсов хранения.

Теперь же рассмотрим преимущества и недостатки каждого типа подробнее.

Полное резервное копирование (Full Backup)

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

➕Плюсы

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

➖Минусы

Занимает много места на хранилище: Опять же копия включает в себя все данные. При этом каждая последующая резервная копия включает в себя копию данных с прошлой резервной копии.
Создание резервной копии занимает много времени: Так как резервная копия включает в себя все данные с момента существования время создания резервной копии увеличивается.

Дифференциальное резервное копирование (Differential Backup)

Дифференциальная резервная копия зависит от Полной резервной копии и включает в себя только изменённые данные с момента создания последней резервной копии. Каждая последующая Дифференциальная резервная копирования включает данные предыдущей, так что хранить все дифференциальные копии не обязательно.

➕Плюсы

Восстановление быстрее: Если у вас уже восставлена полная резервная копия, то достаточно восстановить только последнюю Дифференциальную резервную копию, созданную после полной резервной копии. Как правило дифференциальная резервная корпия весит меньше и соответственно восстанавливается быстрее.
Используется меньший объем хранилища: Так как сохраняются только измененные данные после полного резервного копирования занимает меньше места на диске, по сравнению с полной резервной копией. Если у вас дифференциальная резервная копия весит столько же сколько, и полная есть смысл пересмотреть стратегию создания резервных копий.

➖Минусы

Время выполнения увеличивается с ростом измененных данных: По мере роста изменённых данных Дифференциальная резервная копия может значительно вырасти в объёме.

Инкрементное резервное копирование (Incremental Backup)

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

➕Плюсы

Минимальное использование дискового пространства: Как правило задача создания Инкрементной резервной копии запускается чаще всех остальных типов, например, каждые 5 минут. Соответственно за 5 минут в принципе не может произойти много изменений.
Резервная копия создаётся быстрее: Так как изменений не так много то и сама резервная копия создаётся быстрее.

➖Минусы

Восстановление занимает больше времени: Так как задача создания резервной копии запускается каждые 5 минут для примера, то и файлов резервных копий может быть сотни. Соответственно, чтобы восстановить актуальное состояние данных придётся поочередно восстановить все эти 100 файлов, помимо полной резервной копии. Поэтому рекомендуется время от времени делать Дифференциальные резервные копии.
Повышенный риск утери данных: Легче потерять один файл из 100. А если вы теряете какой-то файл, то все последующие файлы резервных копий становятся неактуальными.

Veeam Backup & Replication - Что такое Непрерывная защита данных (CDP)

Thu, 16 Mar 2023 06:20:39 +0600

Непрерывная защита данных (Continuous Data Protection) - это технология в Veeam Backup & Replication для защиты критически важных виртуальных машин VMware. CDP предоставляет метод моментального восстановления виртуальной машины при выходит из строя. Т.е. если у вас есть виртуальные машины, недоступность которых не должна превышать секунды (критически важные), то можно для доступности использовать CDP.

Но к сожалению, использовать Непрерывную защиту данных (CDP) вы можете только если у вас есть ицензия Enterprise Plus.

Репликация данных

В самом начале CDP создаёт реплику ВМ и в последствии постоянно обновляет реплику до состояния источника. После создания реплики CDP постоянно реплицирует операции ввода-вывода, выполняемые на виртуальной машине источника. При этом в процессе репликации не используется механизм моментальных снимков ВМ (snapshot), вместо этого используется vSphere API. Это позволяет достичь более низкой целевой точки восстановления (RPO) по сравнению с репликацией на основе моментальных снимков.

Данные об операциях ввода-вывода хранятся в целевом хранилище данных и относятся к краткосрочным точкам восстановления. Краткосрочные точки восстановления позволяют восстановить ВМ до состояния на секунды или минуты назад (в зависимости от указанного вами RPO) в случае необходимости. Информация о краткосрочных точках восстановления хранится в специальном журнале. Этот журнал хранит записи о краткосрочных точках восстановления максимум в течение 24 часов. Если вы хотите восстановить ВМ до более старого состояния, Veeam Backup & Replication позволяет создавать дополнительные точки восстановления, которые содержат состояние ВМ до часов или дней назад. Такие точки восстановления называются долгосрочными точками восстановления.

Восстановление данных

Чтобы восстановить виртуальную машину до краткосрочной или долгосрочной точки восстановления, необходимо выполнить аварийный переход на ее реплику.

При переходе на реплику, реплика берет на себя роль исходной виртуальной машины, т.е. становится главной и обрабатывает все запросы. После того, как исходная виртуальная машина будет восстановлена (та которая вышла из строя), вы можете вернуться на нее и перенести все изменения, произошедшие в реплике, на исходную виртуальную машину. Если исходная виртуальная машина не может быть восстановлена, вы можете выполнить постоянный переход на резерв, то есть навсегда переключиться с исходной виртуальной машины на реплику виртуальной машины и использовать эту реплику в качестве исходной виртуальной машины.

Как работает CDP во время репликации

Рабочий процесс CDP во время репликации делится на две части: настройка компонентов инфраструктуры резервного копирования и передача данных.

Алгоритм конфигурации компонента

Следующие шаги выполняются при первом запуске CDP:

Сервис координатора Veeam CDP считывает параметры политики из базы данных конфигурации и создает список ВМ для обработки. Для каждой ВМ, добавленной в политику CDP, Veeam Backup & Replication создает новую задачу.
Сервис координатора Veeam CDP проверяет доступность необходимых компонентов инфраструктуры резервного копирования
Служба координатора Veeam CDP запрашивает информацию о виртуальных машинах, добавленных в политику CDP, и хостах виртуализации из vCenter Server
Служба координатора Veeam CDP запрашивает у vCenter Server создание на целевом хосте пустых реплик с той же конфигурацией, что и у исходных ВМ, но с пустыми виртуальными дисками. vCenter Server регистрирует созданные реплики
Служба координатора Veeam CDP запрашивает vCenter для применения политики хранения Veeam CDP Replication к виртуальным дискам ВМ на исходных хостах ESXi. Эта политика хранения добавляет компонент, который требуется для CDP и который получает данные всех операций ввода-вывода
Служба координатора Veeam CDP выбирает, какие прокси-серверы VMware CDP будут использоваться для передачи данных, и устанавливает ряд правил для передачи данных, например, правила регулирования сетевого трафика и т. д.
Veeam CDP Coordinator Service отправляет в компоненты инфраструктуры резервного копирования конфигурации, необходимые для CDP. Эта конфигурация включает в себя такую информацию, как RPO, краткосрочные и долгосрочные настройки хранения.

После завершения начальной настройки Veeam Backup & Replication начинает мониторинг инфраструктуры резервного копирования. Если что-то меняется в настройках инфраструктуры или политики CDP, Veeam Backup & Replication перенастраивает компоненты. Например, добавление нового устройства в ВМ источника приведёт к тому же действию на реплике ВМ.

Алгоритм передачи данных

Передача данных начинается сразу после настройки компонента CDP и отличается на этапе начальной и инкрементной синхронизации.

Начальная синхронизация выполняется при первом переносе данных с диска на целевой хост. В этот момент Veeam Backup & Replication отправляет полные копии виртуальных дисков и создает первые точки восстановления.

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

Алгоритм передачи данных во время начальной синхронизации

На исходном хосте фильтр ввода-вывода считывает все данные с дисков виртуальной машины и отправляет их на исходные прокси-серверы VMware CDP
Служба Veeam CDP Proxy на исходных прокси-серверах сжимает полученные данные и отправляет их на целевой прокси-сервер
Служба Veeam CDP Proxy на целевых прокси-серверах распаковывает полученные данные. Затем отправляет данные на целевой хост.
Фильтр ввода-вывода на целевом хосте сохраняет полученные данные на виртуальных дисках. Сохраненные данные относятся к самой первой долгосрочной точке восстановления. Эта точка восстановления устойчива к сбоям.

Алгоритм передачи данных во время инкрементальной синхронизации

На исходном хосте фильтр ввода-вывода перехватывает данные всех операций ввода-вывода и отправляет эти данные на исходные прокси-серверы VMware CDP.
Попав в RPO, Veeam CDP Proxy Service на исходных прокси-серверах подготавливает данные, необходимые для краткосрочной точки восстановления. Для этого Veeam CDP Proxy Service получает последнее состояние данных, накопленных исходными прокси-серверами VMware CDP.
Исходный прокси-сервер Veeam CDP сжимает данные и отправляет их на целевой прокси-сервер.
Целевой Veeam CDP Proxy Service распаковывает полученные данные. Затем отправляет данные на целевой хост.
Фильтр ввода-вывода на целевом хосте сохраняет полученные данные в журналах транзакций.

Статусы политики CDP

В зависимости от рабочего процесса политики CDP могут иметь следующие статусы:

Initial sync - выполняется процесс начальной синхронизации
Syncing - выполняется процесс инкрементальной синхронизации
CBT mode - реплика на целевом хосте неактуальная
Success, Warning or Error - результат выполнения

Veeam Backup & Replication - Цепочка репликации CDP

Thu, 16 Mar 2023 06:20:39 +0600

Цепочка репликации CDP - это последовательность файлов, которые позволяют вам откатить реплику ВМ на определённое время в процессе аварийного переключения между источником и репликой. Veeam Backup & Replication создаёт эти цепочки для каждой ВМ.

Цепочка репликации CDP содержит краткосрочные и долгосрочные точки восстановления. Краткосрочные точки восстановления позволяют откатиться на несколько секунд или минут назад, долгосрочные же на несколько часов или даже дней назад.

Цепочка репликации CDP (те самые файлы) хранятся на том же хранилище, где и целевая ВМ (target), в той же папке что и сама ВМ. Цепочка репликации содержит следующие файлы:

VMX - файл конфигурации ВМ реплики
VMDK - виртуальные диска ВМ реплики VMDK файлы делятся на 4 наименования:
- <disk_name>.vmdk - файл полной копии диска, который создаётся при начальной синхронизации и обозначается как самая первая долгосрочная точка восстановления.
- <disk_name>-<index>.vmdk - файлы, в которых хранится инкрементальные данные, т.е. данные изменённые после создания полной копии диска, также называемые как данные дельта-диска.
- <disk_name>-<index>.tlog.vmdk - файлы журнала транзакций, в которых хранятся инкрементные изменения, внесенные в виртуальные диски в течение RPO, установленного в параметрах политики CDP. Эти файлы относятся к Краткосрочным точкам восстановления. Один файл может содержать данные нескольких точек восстановления. Новый файл транзакции создаётся в следующих случаях:
  - Когда размер файла журнала транзакций составляет 512 ГБ
  - После создания долгосрочной точки восстановления
  - При достижении лимита создания точки восстановления. Например, если установить краткосрочное хранение на 1 час, новый файл журнала транзакций будет создаваться каждый час.
- <disk_name>-interim.vmdk - файлы для защитных виртуальных дисков. При выполнении аварийного переключения изменения, внесенные в виртуальные диски, будут записаны в эти файлы.
VMFD - файлы, хранящие метаданные для дисков
META - файлы, хранящие метаданные для журналов транзакций

Обратите внимание что VMDK выглядят как снимок ВМ, но это не снимки. Эти файлы создаются фильтром ввода-вывода, установленным на целевом хосте ESXI.

Veeam Backup & Replication - Гарантированная доставка CDP

Thu, 16 Mar 2023 06:20:39 +0600

В CDP для доставки данных между двумя площадками (репликация ВМ) используется множество протоколов TCP, не бойтесь мы не будем их рассматривать. Может так произойти что Veeam Backup & Replication по какой-то причине не сможет доставить все измененные данные с ВМ целевой площадки на конечную площадку при репликации. Для примера, если RPO мал, то может не хватить физических ресурсов для поддержания актуальной реплики, или CDP прокси могут быть недоступны. Это делает данные несогласованными и приводит к потере точек восстановления. Т.е. для вас это ничем хорошим не закончится.

Для того чтобы такого не произошло используется специальный механизм, который гарантирует доставку. Гарантированная доставка (Guaranteed Delivery) в Veeam CDP – это механизм, который обеспечивает передачу всех изменений данных на виртуальных машинах в реплику (вторичную площадку) без потерь. Для этого используется специальный драйвер (I/O Filter) на уровне гипервизора ESXI.

Фильтр ввода-вывода на исходном хосте ESXI имеет механизм, который отслеживает измененные блоки данных - отслеживание изменений. Фильтр ввода-вывода удаляет адреса блоков данных из списка измененных блоков только после получения от целевого хоста ESXI (вторичная площадка) подтверждающего сообщения о том, что блоки данных были успешно сохранены в реплике. Кроме того, прокси-серверы VMware CDP также хранят изменения данных до тех пор, пока от целевого хоста не будет получено подтверждающее сообщение.

Использование специального драйвера (I/O Filter) на уровне гипервизора

При включённом CDP Veeam Backup & Replication устанавливает специальный I/O-фильтр (драйвер), интегрированный с VMware vSphere (через VAIO – vSphere API for I/O Filtering). Этот фильтр перехватывает каждый блок данных при записи на диск в режиме реального времени.
Благодаря этому механизму изменённые данные целевой ВМ не смогут пройти незаметно для Veeam Backup & Replication: всё, что записывается на исходный диск ВМ, учитывается драйвером и отправляется на целевой хост ESXi (вторичная площадка) и в последствии сохраняется на хранилище данных.

Проблемы с источником

Если источник не отправляет новые данные из-за большой нагрузки, то Veeam Backup & Replication дожидается пока эта нагрузка спадёт. После спада нагрузки Veeam Backup & Replication получает список измененных блоков данных, считывает эти блоки с диска и отправляет данные на целевой хост ESXI (вторичная площадка). После чего целевой хост сохраняет эти данные в хранилище данных.

Если же из строя выходит CDP прокси на стороне источника Veeam Backup & Replication пытается выбрать другой прокси (если он есть) и выполняет отправку данных.

Проблемы с целевым хостом

Если же из строя выходит CDP прокси на стороне целевой инфраструктуры (вторичная площадка) Veeam Backup & Replication пытается выбрать другой прокси (если он есть) и получает данные с CDP прокси источника.

Если соединение между CDP прокси источника и целевым хостом (вторичная площадка) теряется, то Veeam Backup & Replication проверяет статус хоста. Если вдруг хост находится в режиме обслуживания (Maintenance) или выпал из кластера, то Veeam Backup & Replication начинает запись данных в реплику используя другой ESXI хост, если конечно другой хост имеет доступ к хранилищу, где расположена реплика ВМ. Если же хост просто недоступен из-за проблем с сетью (т.е. отображается в кластере), то Veeam Backup & Replication считает, что это временные проблемы и просто повторяет попытки отправки данных повторно через какое-то время.

Буферизация и транспорт изменений

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

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

Vcenter (ESXI) - invalid operation for device '0'

Thu, 09 Mar 2023 03:22:39 +0600

При попытке увеличить размер диска можно наткнуться на такую ошибку invalid operation for device ‘0’.

На самом сайте vmware я особо ничего полезного не нашёл. Там многие проблемы связывают с сетевым адаптером или с проблемами клонирования виртуальной машины.

Также если у вас старая версия vcenter, то можно попробовать увеличить размер диска через java версию. Но это не мой случай так как с версии vcenter 7 нет поддержки java версии.

Кто-то решает данный вопрос подключением к esxi через vmware worksattion, но мне это не кажется хорошим вариантом, когда есть powershell и powercli.

Установка модуля PowerCLI

Открываем консоль powershell
Выполняем установку модуля

Install-Module -Name VMware.PowerCLI

Подключаемся к Vcenter

Выполняем команду Connect-VIServer, которой передаём адрес Vcenter, пользователя и при желании пароль

 Connect-VIServer -Server 10.23.112.235 -Protocol https -User admin -Password pass

Name                           Port  User
----                           ----  ----
10.23.112.235      			    443   admin

Проверяем диски

Выполняем команду, которая покажет все диски виртуальной машины

Get-HardDisk -vm vm1 | Select Name,CapacityGB,Filename

Name        CapacityGB Filename
----        ---------- --------
Hard disk 1          5 [A] 
Hard disk 2          6 [A] 
Hard disk 3          7 [A]

Изменяем размер диска на виртуальной машине

Выполняем Get-HardDisk только уже необходимого диска передавая параметр -name и меняем размер полученного командой Set-HardDisk.

Get-HardDisk -vm vm1 -name "Hard disk 3" | Set-HardDisk -capacityGB 10

Name        CapacityGB Filename
----        ---------- --------
Hard disk 1          5 [A] 
Hard disk 2          6 [A] 
Hard disk 3          7 [A]

В ответ на предупреждение нажимаем Y.

Grafana Loki - Анонимная статистика (stats.grafana.org/loki-usage-report)

Thu, 02 Mar 2023 03:22:39 +0600

Начнём с того что по умолчанию при использовании Grafana Mimir отправляется анонимная статистика на https://stats.grafana.org. Хотя у меня статистика отправлялась и при использовании Loki. Конечно же ничего плохого туда не отправляется по заверению самих разработчиков Grafana. Подробнее по ссылке.

Но так или иначе всё же мне это не нравится, и я решил это отключить.

Отключаем сбор анонимной статистики в Grafana

Если вы запускаете просто через cli то можно использовать опцию:

-usage-stats.enabled=false

Или добавляем переменную в yml файл настроек:

usage_stats:
  enabled: false

Или задаём настройки в файле конфигурации Grafana:

vim /etc/grafana/grafana.ini

[analytics]
reporting_enabled = false

Отключаем сбор анонимной статистики в Loki

Отключение сбора анонимной статистики в Grafana еще не означает что вы выключили тоже самое и в Loki. Для того чтобы отключить в Loki правим файл конфигурации /etc/loki/config.yaml.

vim loki-config.yaml

analytics:
  reporting_enabled: false

Как настроить сеть в VirtualBox

Thu, 16 Feb 2023 03:22:39 +0600

На сегодняшний день существует уже куча приложений для виртуализации. И VirtualBox один из них, и как правило почти каждая вторая виртуальная машина имеет доступ по сети. У каждой виртуальной машины своё предназначение, например, кому-то нужно просто протестировать ОС или просто запустить приложение, требующее определенную ОС.

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

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

Требования

Для начала убедитесь, что у вас уже установлен сам VirtualBox и создана виртуальная машина.

Типы сетей

В таблице ниже рассмотрим какие типы сетей вы можете использовать в VirtualBox и какие доступы вы будете иметь.

Тип сети	VM > Host	Host > VM	VM1 > VM2	VM > LAN	LAN > VM
NAT	+	Port forwarding	-	+	Port forwarding
Bridged	+	+	+	+	+
Internal	-	-	+	-	-
Host-Only	+	+	+	-	-
NATservice	+	Port forwarding	+	+	Port forwarding

Когда вы создаёте новую виртуальную машину (сервер) ему автоматом добавляется виртуальный сетевой адаптер (1 активный и 3 неактивных). Как правило хватает только одного сетевого активного адаптера. По умолчанию тип адаптера выставлен в NAT.

NAT

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

В таком режиме ваша виртуальная машина при выходе во вне через локальную сеть, например, выход в интернет будет прикидываться вами. Т.е. весь трафик будет идти с вашего локального IP-адреса. И понятное дело, что вы не сможете в таком режиме получить доступ к вашему виртуальному серверу по IP-адресу из подсети 10.0.2.0. Т.е. по сути у вашего виртуального сервера будет только исходящие соединения, но не входящие. Зато не надо ничего настраивать ни на хосте, ни на виртуальной машине.

Т.е. если вам просто нужен доступ в интернет и вас совсем не беспокоит что в итоге весь траффик по сети идёт от вашего локального компьютера то используем NAT.

Также если вам вдруг всё же очень сильно нужен NAT и доступ к виртуальной машине из вне или локальной сети вы можете настроить Port Forwarding. Но в таком случае для доступа к виртуальной машине нужно будет обращаться к IP-адресу хоста.

Если вдруг вам не нравится какие IP-адреса назначаются вашим виртуальным машинам можете изменить это в настройках VirtualBox (Менеджер сетей > NAT).

NATservice

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

Сама сеть настраивается в (Менеджер сетей > NAT).

Также как и в NAT доступен Port Forwarding.

Bridged networking (Сетевой мост)

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

Тут если у вас в сети нет DHCP сервера, то придётся прописывать IP-адрес на виртуальной машине вручную. IP-адрес как правило из той же подсети что и IP-адрес на локальном хосте, с тем же шлюзом.

При использовании такого типа подключения помимо доступа к интернету с виртуального хоста вы еще получаете и входящие подключения по IP-адресу виртуального хоста.

Для примера представим ситуацию что у меня нет DHCP сервера в следствии чего мои настройки будут следующими:

Локальный хост

DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.8.11
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.8.1

Виртуальная машина

DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.8.12
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.8.1

С такими настройками я легко смогу попасть в интернет через виртуальную машину, но также буду иметь доступ по локальной сети к локальному хосту (192.168.8.11) и наоборот, если только не включен файрволл.

Internal networking (Внутренняя сеть)

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

Естественно ни, а какой речи доступа к интернету тут не может идти и речи так как доступа у вириальных машин к вашей сети нету и соответственно наоборот тоже.

Для примера представим мои настройки сети будут следующими:

Локальный хост

DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.8.11
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.8.1

Виртуальная машина

DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.8.12
Маска подсети . . . . . . . . . . : 255.255.255.0

Виртуальная машина 2

DNS-суффикс подключения . . . . . :
IPv4-адрес. . . . . . . . . . . . : 192.168.8.13
Маска подсети . . . . . . . . . . : 255.255.255.0

При таких настройках я с легкостью смогу получить доступ с одной виртуальной машины на другую через локальную сеть, например, запущу ping с 192.168.8.12 на 192.168.8.13 или наоборот. Но я никак не смогу получить доступ с локального хоста (192.168.8.11) до виртуальных машин и наоборот (даже если пропишу шлюз 192.168.8.1).

Host-Only Networking (Виртуальный адаптер хоста)

Виртуальный адаптер хоста можно рассматривать как что-то среднее между Internal networking (Внутренняя сеть) и Bridged networking (Сетевой мост).

Когда используется Host-Only Networking (Виртуальный адаптер хоста) VirtualBox создаёт новый виртуальный адаптер, благодаря которому ваши виртуальные машины соединяются с вашим локальным хостом и наоборот. Только тут отличие в том, что вы должны подключаться не к IP-адресу вашего хоста, а к IP-адресу, который вы должны задать в настройках VirtualBox (Менеджер сетей).

IP-адреса для виртуальных машин будут назначаться DHCP сервером, настройки которого вы можете задать также в настройках VirtualBox (Менеджер сетей).

Veeam Backup & Replication - Репозиторий резервных копий

Tue, 24 Jan 2023 06:20:39 +0600

Репозиторий резервных копий — это место хранения, где Veeam хранит файлы резервных копий, копии виртуальных машин и метаданные для реплицированных виртуальных машин. Является ключевым компонентом.

Локальный репозиторий (Local Backup Repository)

Используется и создаётся по умолчанию во время процесса установки Veeam Backup & Replication. В качестве репозитория используется локальное хранилище, например, внутренние диски сервера или подключенные через USB/Thunderbolt переносные устройства.

Как правило такой тип репозитория предоставляет высокая скорость чтения/записи, но всё конечно зависит от типа дисков.

К недостаткам можно, пожалуй, отнести ограниченный объем и отсутствие защиты от сбоя сервера.

Сетевой репозиторий (Network Attached Storage, NAS)

В качестве репозитория могут использоваться специальные сетевые хранилища данный (CIFS (SMB), NFS), но ничего не мешает использовать SMB шару на сервере.

К преимуществам можно отнести, пожалуй, возможность хранения на удаленных серверах.

К недостаткам же можно отнести зависимость от сети. Т.е. скорость записи или чтения напрямую зависит от пропускной способности сети, а если это ещё и общая сеть (не выделенная) то нагрузка на другие сервера в сети могут также повлиять на скорость записи.

Облачный репозиторий (Cloud Repository)

Облачный репозиторий использует облачное хранилище данных, например, S3, Azure Blob, Google Cloud Storage, Wasabi и др.

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

Минусом является пропускная способность интернет канала. И немаловажным минусом будет ещё большая цена за облачное хранилище.

Ленточный репозиторий (Tape Repository)

При использовании Ленточного репозитория хранение резервных копий происходит на магнитных лентах LTO.

Благодаря большому объему хранения хранить резервные копии можно очень долго.

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

Hyperledger Fabric (Docker) - x509 certificate signed by unknown authority

Sat, 21 Jan 2023 03:22:39 +0600

В моём случае эта ошибка выходила при попытке скачивания go пакетов при установке chaincode. Сразу скажу, что установка сертификатов CA в локальную систему или использование прокси не поможет, так как при установке происходит build нового docker образа и всё выполняется внутри сборки.

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

Debug

Для начала давайте отловим ошибку используя gliderlabs/logspout, о котором я писал тут.

docker run -d --name="logspout" --volume=/var/run/docker.sock:/var/run/docker.sock --publish=127.0.0.1:8000:80 gliderlabs/logspout

curl http://127.0.0.1:8000/logs

В другой сессии сделаем сборку chaincode и собственно произведём его установку.

peer lifecycle chaincode package fabcar.tar.gz --path chaincode/fabcar/ --lang golang --label fabcar_1

peer lifecycle chaincode install fabcar.tar.gz

И тут в логах gliderlabs/logspout мы видим следующую строку:

peer1.org1.exxample.com|/go/pkg/mod/google.golang.org/grpc@v1.48.0/status/status.go:35:2: google.golang.org/genproto@v0.0.0-20220719170305-83ca9fad585f: Get : x509: certificate signed by unknown authority

Т.е. получается, что это peer пытается выкачать все эти пакеты? Не совсем так, потому что выше есть строка, благодаря которой можно понять, что происходит buld нового образа для chaincode используя образ fabric-ccenv (from).

[chaincode.platform.util] DockerBuild -> Docker build failed using options: Image=hyperledger/fabric-ccenv:2.4 Env=[GOPROXY=https://proxy.golang.org] Cmd=

Решение

Теперь мы хоть знаем где именно ломается. И так первый выход — это использование прокси сервера, если у вас он конечно есть (не мой случай), а второй это разрешить ставить пакеты без проверки валидности ssl сертификатов. Но во всех решениях нам будет необходимо собрать свой docker образ, хорошо если вы уже это делали.

Вариант с прокси

Как я уже говорил нужно будет пересобрать образ для hyperledger/fabric-ccenv.

Для начала удаляем существующий образ:

docker image ls | grep ccenv
docker image rm hyperledger/fabric-ccenv:2.4

Теперь создаём Dokcerfile, в котором в поле from указываем тот же образ, который мы удалили.
```
mkdir /tmp/image && cd /tmp/image
vim Dockerfile
```

FROM  hyperledger/fabric-ccenv:2.4

ENV  HTTP_PROXY=http://192.168.0.1:5000
ENV  HTTPS_PROXY=http://192.168.0.1:5000

Создаём образ, где именем образа будет тоже самое что мы удаляли.
```
docker build -t hyperledger/fabric-ccenv:2.4 .
docker image ls | grep ccenv
```

hyperledger/fabric-ccenv 2.4       63b3ecbf2083   16 seconds ago   520MB

Снова выполняем установку chaincode
```
peer lifecycle chaincode install fabcar.tar.gz
```

 Installed remotely: response:<status:200 payload:"\nIfabcar_1:6c333d70725857f3b3d3c5a3a9ce42b968741dc3889b748a2097d7687b91a0e7\022\010fabcar_1" >

Теперь давайте посмотрим, что у нас появился новый образ для chaincode.
```
docker image ls | grep fabcar
```

fabcar_1-6ccad5cf477e6d0ac     latest    d22763d63a89   About a minute ago   23.4MB

Вариант с отключением проверки ssl

Сразу оговорюсь что для этого метода нам также будет необходимо указать версию go самую новую, потому как старые версии не поддерживают переменную GOINSECURE.

Для начала удаляем существующий образ:

docker image ls | grep ccenv
docker image rm hyperledger/fabric-ccenv:2.4

Теперь создаём Dokcerfile, в котором в поле from указываем тот же образ, который мы удалили.
```
mkdir /tmp/image && cd /tmp/image
vim Dockerfile
```

FROM  hyperledger/fabric-ccenv:2.4

ENV GOINSECURE="*"
ENV GONOSUMDB="*"
ENV GOPRIVATE="*"
ENV GOLANG_VERSION=1.19.5

Создаём образ, где именем образа будет тоже самое что мы удаляли.
```
docker build -t hyperledger/fabric-ccenv:2.4 .
docker image ls | grep ccenv
```

hyperledger/fabric-ccenv 2.4       63b3ecbf2083   4 seconds ago   520MB

Снова выполняем установку chaincode
```
peer lifecycle chaincode install fabcar.tar.gz
```

 Installed remotely: response:<status:200 payload:"\nIfabcar_1:6c333d70725857f3b3d3c5a3a9ce42b968741dc3889b748a2097d7687b91a0e7\022\010fabcar_1" >

Теперь давайте посмотрим что у нас появился новый образ для chaincode.
```
docker image ls | grep fabcar
```

fabcar_1-6ccad5cf477e6d0ac     latest    d22763d63a89   About a minute ago   23.4MB

В итоге

Первый метод конечно более безопасный в какой-то степени, но не всегда есть возможность использовать прокси сервер.

Docker - Просмотр логов всех контейнеров

Sat, 21 Jan 2023 03:22:39 +0600

Для просмотра логов контейнера обычно используется встроенная команда docker logs, но есть правда пару минусов, которые конечно решаемые, но не хочется тратить своё время на костыли. Вот несколько из этих минусов:

Иногда нужно получить логи с пересоздаваемых контейнеров, которые могут пересоздаваться очень быстро. В таком случае команда docker logs перестанет выводить логи так как контейнеры пересоздаются.
Временами хочется смотреть все логи в одном терминале, а не в нескольких.

gliderlabs/logspout

Для самого простого решения этих проблем мы можем использовать контейнер gliderlabs/logspout, который подключится к сокету docker и будет выводить абсолютно все логи в одном месте, что кстати очень полезно для debug.

Для запуска выполняем команду:

docker run -d --name="logspout" --volume=/var/run/docker.sock:/var/run/docker.sock --publish=127.0.0.1:8000:80 gliderlabs/logspout

Для просмотра логов используем curl:

curl http://127.0.0.1:8000/logs

Linux - Конвертируем MBR в GPT

Tue, 27 Dec 2022 04:22:39 +0600

Как мы знаем GPT лучше MBR, а почему именно вы можете узнать в этой статье. Но вы скорее всего заинтересовались этой темой потому что упёрлись в ограничение максимального размера раздела MBR.

Но важное замечание: хоть и смена типа таблицы раздела диска не приведёт к потере данных стоит перед выполнением этой операции сделать бэкап всех своих данных.

CentOS

Для того чтобы сконвертировать MBR в GPT нам потребуется утилита gdisk.

sudo yum -y install gdisk

И теперь выбираем нужный нам диск для конвертирования, в моём случае /dev/sdd.

 sudo parted -l

Model: Msft Virtual Disk (scsi)
Disk /dev/sdd: 10.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  10.7GB  10.7GB  primary

Конвертируем MBR в GPT

 sudo gdisk /dev/sdd

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************

Просто вводим w и нажимаем ENTER

The operation has completed successfully.

Ubuntu

Для того чтобы сконвертировать MBR в GPT нам потребуется утилита gdisk.

sudo apt install gdisk

И теперь выбираем нужный нам диск для конвертирования, в моём случае /dev/sdd.

 sudo parted -l

Model: Msft Virtual Disk (scsi)
Disk /dev/sdd: 10.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  10.7GB  10.7GB  primary

Конвертируем MBR в GPT

 sudo gdisk /dev/sdd

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************

Просто вводим w и нажимаем ENTER

The operation has completed successfully.

Warning! Secondary partition table overlaps the last partition by 33 blocks!

Если вы столкнулись с ошибкой Warning! Secondary partition table overlaps the last partition by 33 blocks! то значит на вашем диске нет неразмеченного места. Дело в том, что в отличии от MBR, который использует только сектора в начале GPT еще использует и сектора в конце, для дублирования таблицы разделов.

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

Про сжатие диска можно почитать тут

Linux - MBR vs GPT

Tue, 27 Dec 2022 03:22:39 +0600

Есть 2 типа таблицы разделов:

MBR (Master Boot Record)
GPT (GUID Partition Table)

Если это не загрузочный диск, то для работы с ним годятся оба типа, но вот если загрузочный диск на GPT, то тут нужен UEFI BIOS для нормальной загрузки ОС. Если с MBR, то режим загрузки в BIOS должен быть выставлен как Legacy. Но всё идёт к тому что скоро режим Legacy не будет использоваться вовсе (на новых устройствах).

MBR

Довольно уже старая таблица разделов со многими ограничениями и недостатками которая впервые появилась ещё в 1982 году. Таблица разделов указывает на то как диски будут разбиваться в системе с BIOS.

MBR, загрузочный сектор на жестком диске, который хранит информацию, обеспечивающую правильную загрузку ОС, занимает первые 512 байт жесткого диска и также хранит таблицу разделов (partition table). Также указывает на активный раздел (active partition), благодаря чему грузится именно ОС на активном разделе жесткого диска.

4 основных раздела на жестком диске

MBR поддерживает создание только 4 основных разделов на жестком диске. Основной значит имеет возможность загрузки ОС с него. Если вы хотите больше 4 дисков, то вы должны создать 3 основных раздела (primary partitions), а остальные уже будут логическими (logical partitions). В Linux максимальное количество разделов достигает значения 15.

Информация об основных и расширенных разделах содержится в 64-байтах, расположенных в MBR. Каждая запись в таблице разделов (partition table) имеет длину 16 байтов, поэтому доступно не более четырех записей, т.е. разделов диска.

При этом все логические разделы должны быть в расширенном разделе (extended partition). Т.е. вы должны создать 4 раздел расширенным и на всё оставшееся место на диске. И уже внутри этого раздела создавать логические разделы (logical partitions). Вы конечно можете создать расширенным разделом и третий раздел, но логический раздел будет всё равно начинаться с цифры 5.

Максимальный размер разделов в 2ТБ на диске

Также еще одно плохое ограничение — это максимальный размер разделов в 2ТБ на диске. Т.е. не один раздел, а все вместе общим объёмом не больше 2ТБ.

На диске MBR (основная загрузочная запись) места, где хранятся размеры разделов, имеют длину всего 4 байта. Поскольку это шестнадцатеричное число, наибольшее значение, которое мы можем ввести, - это все буквы F. Таким образом, максимальное значение будет 4 294 967 295 в десятичном виде (FF FF FF FFh = 4294967295d). Этот максимальный размер раздела не в байтах, а в количестве секторов. В свою очередь каждый сектор имеет размер 512 байт мы получаем следующее 4294967295 секторов * 512 байт / сектор = 2199023255040 байт или 2 ТБ.

Если вы всё еще не поняли откуда взялась цифра 4 294 967 295, то это моя последняя попытка. В шестнадцатеричном представлении числа записываются как цифры и буквы. При этом максимальное число 16, как не сложно догадаться. Но так как отсчёт идёт с 0 то максимальное число 15. При этом числа с 0 до 9 записываются также в цифровом представлении, а вот с 10 до 15 уже начиная с буквы A до F. и максимальное значение может быть FFFFFFFF.

Теперь переводим FFFFFFFF шестнадцатеричное в десятичное. Для этого каждое F которое обозначает число 15 умножается на 16 в степени с 0 до 7. И после всё это суммируется.

F1 - 15 × 16^0 = 15
F2 - 15 × 16^1 = 240
F3 - 15 × 16^2 = 3 840
F4 - 15 × 16^3 = 61 440
F5 - 15 × 16^4 = 983 040
F6 - 15 × 16^5 = 15 728 640
F7 - 15 × 16^6 = 251 658 240
F8 - 15 × 16^7 = 4 026 531 840
15 + 240 + 3 840 + 61 440 + 983 040 + 15 728 640 + 251 658 240 + 4 026 531 840 = 4 294 967 295

FFFFFFFF = 4294967295

И еще один минус заключается в том, что MBR хранится без копии и если он вдруг испортиться, то вам придётся восстанавливать его. И вы уже не получите информацию о начале и конце ваших разделов и не загрузите ОС. Для Linux вы можете восстановить MBR с помощью test disk (но это не точно).

Master Boot Code

Master Boot Code выполняет следующие действия:

Сканирует таблицу разделов на наличие активного раздела
Находит начальный сектор активного раздела
Загружает копию загрузочного сектора из активного раздела в память
Передает управление исполняемому коду в загрузочном секторе

Если просто и в двух словах благодаря Master Boot Code у вас грузится ОС после BIOS.

GPT

Intel начал разрабатывать новый формат BIOS - UEFI, и благодаря этому появился новый формат таблицы разделов GPT.

Наличие бэкапа

Самое первое отличие — это то что таблица разделов дублируется в отличии от MBR, что даёт вам возможность продолжать работать если вы каким-то образом повредили запись, т.е. потеряли одну копию.

128 разделов на диск

Второй важный плюс — это то что тут вы уже можете создать столько разделов на диске сколько вам захочется в отличии от 4 в MBR. Но есть, но, некоторые ОС сами ограничивают количество разделов на диске, которые вы можете создавать. В Linux максимальное число 128, по крайней мере у RedHat.

Максимальный размер диска

Ну и еще тут нет этого дурацкого ограничения в 2ТБ, вы можете создать раздел размером около 9 млрд терабайт. Но опять-таки не все ОС вам дадут это сделать, например, Windows ограничивает размер в 256 терабайт, зависит от версии Windows.

Protective MBR

Также GPT в себе имеет и сектор с информацией о MBR - Protective MBR. Сделано это для обратной совместимости чтобы BIOS без UEFI тоже мог загружать систему с диска GPT (но не всегда это работает). Также это сделано для защиты от перезаписи сектора с GPT утилитами, которые работают с MBR.

GUID Partition Entry Array

Массив записей раздела (GUID Partition Entry Array) описывает разделы, используя минимальный размер 128 байт для каждого блока. Первые 16 байтов каждой записи обозначают глобальный уникальный идентификатор (GUID) типа раздела. Например, GUID для системного раздела EFI - C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Вторые 16 байтов - это уникальный идентификатор GUID раздела. Затем следуют начальные и конечные 64-битные LBA, атрибуты раздела и максимум 36-символьное имя раздела.

Итог

Прочитав всё выше написанное можно констатировать:

MBR и GPT позволяют операционной системе получать точную информацию о структуре диска
Если вы повредите сектор с MBR, то вам придётся изрядно попотеть
Используйте только GPT
Можно использовать ПО для создания резервной копии MBR если уж вы его уже используете
Также вы можете использовать ПО для конвертации MBR в GPT (конечно сперва бэкап)
Конечно сперва бэкап - слоган любого вендора, даже если это СХД на 500ТБ

Где хранить seed phrase

Mon, 05 Dec 2022 06:20:39 +0600

Если вы имеете свой крипто-кошелёк, то вы уже знаете, что такое seed phrase (recovery phrase). Но если не знаете, то это последовательность слов, сгенерированных вашим крипто валютным кошельком, которая дает вам доступ к крипто-валюте, связанной с этим кошельком. И если вы вдруг каким-то образом потеряли доступ к кошельку, то имея seed phrase вы легко восстановите этот доступ.

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

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

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

Теперь, когда мы бегло разобрались с тем что такое seed phrase встаёт вопрос где именно хранить эту seed phrase.

Холодное хранение

Холодно хранение подразумевает хранение бэкапа, в нашем случае seed phrase в текстовом варианте, либо qr изображение на устройстве, не подключённом к интернету. Холодное хранение по существу устраняет риск того, что злоумышленник получит ваш ключ удаленно, потому что он не находится в Интернете. Для примера пользователь может скопировать seed phrase на USB накопитель и спрятать сам USB в защищенном месте, у каждого это место своё.

Хранение устройства с seed phrase только дома может привести к его потере если что-то случится с домом, например, пожар либо ограбление. Если вы вдруг нашли супер-место для его хранения вы также можете забыть об этом месте через какое-то время. Возможно хорошей идеей будет хранить эту фразу в банковской ячейке, но это только при условии, что у вас есть деньги, иногда очень много денег. Хорошей идеей будет хранить несколько копий в разных местах, но чем больше мест хранения, тем больше риск несанкционированного доступа. Есть теория что отличным местом хранения является запечатанный конверт у юриста, но тут всё зависит от того какой это юрист и, наверное, это хорошо лишь для того если с вами что-то случится и у вашей родни была возможность получить доступ к вашему кошельку (этакое завещание).

Горячее хранение

Под горячим хранением подразумевается, что ваша seed phrase хранится где-нибудь в облачном сервисе, т.е. где-то в интернете, благодаря чему вы можете получить доступ к seed phrase с любого устройства, имеющего доступ к интернету. Например, можно хранить на google disk, yandex disk и т.д.

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

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

Менеджеры паролей

Вы можете скачать любую утилиту для хранения паролей, например, KeepAss и создать хранилище паролей, база этих паролей будет лежать на вашем устройстве в виде файла. Чтобы получить доступ к хранилищу паролей (seed phrase) необходимо будет ввести пароль, который вы придумываете во время создания хранилища паролей.

Т.е. вы можете скопировать файл с паролями (seed phrase) на тот же USB накопитель, но при этом даже если злоумышленник получит доступ к фалу ему еще нужно будет подобрать пароль к файлу. Главное чтобы вы сами не забыли этот пароль.

Ваша память (мозг)

О да, я предвкушаю как вы сейчас в недоумении задались вопросом как это я могу запомнить порядка 12 слов и при этом постоянно держать их в голове. На самом деле этот метод хранения seed phrase работает не совсем так. Да вам нужна будет ваша память, но вот запоминать нужно будет события в игре. Как вам такой поворот?

Дело в том, что многие из нас обладают фотографической памятью, т.е. таким людям гораздо проще запомнить информацию если они видят это на картинке. Именно для таких людей существуют игры, благодаря которым вы сначала зашифровываете вашу seed phrase проделывая некоторые операции в игре, при этом запоминая их. И логично что для того, чтобы получить seed phrase при необходимости, вам необходимо будет сделать то же самое что вы делали при шифровании. На мой взгляд очень интересный метод, по крайней мере новый для меня.

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

Прикрепляю видео с демонстрацией работы одной из таких игр - seedQuest.

Разделенное горячее хранилище

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

Идея Разделенного горячего хранилища в том, что вы разбиваете seed phrase или любую другую информацию на куски и храните разные куски в разных местах. Например, вы разбили seed phrase на 4 куска, где один вы храните на google диске, другую на yandex, третью ещё где-то и четвертую вообще на хранилище у вашего родственника. Согласитесь, что в такой реализации злоумышленнику будет гораздо сложнее получить полностью вашу seed phrase.

В интернете есть ресурсы, которые разобьют любой текст на группы и при этом еще зашифруют каждую строку. Например, iancoleman.io, passguardian.com. Но насколько безопасно пользоваться ими каждый решает сам для себя.

Postfix - Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery

Wed, 23 Nov 2022 06:20:39 +0600

Суть проблемы в том, что, если у отправителя не статический, а динамический ip-адрес он считается плохим и принять почту от такого почтовика не получится. Срабатывает фильтр и отклоняет письмо такого почтовика.

Для примера Facebook использует динамические ip-адреса для рассылки писем. В моём случае ошибка выглядела так:

Nov 23 11:19:08 mail postfix/smtpd[26902]: NOQUEUE: reject: RCPT from 66-220-155-154.mail-mail.facebook.com[66.220.155.154]: 554 5.7.1 <66-220-155-154.mail-mail.facebook.com>: Helo command rejected: ACCESS DENIED. Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery (66-220-155-154); from=<notification@facebookmail.com> to=<> proto=ESMTP helo=<66-220-155-154.mail-mail.facebook.com>

Решение

Нужно добавить pattern с ip адресом и именем домена (66-220-155-154.mail-mail.facebook.com) в файл /etc/postfix/helo_access.pcre. Благодаря этой строке фильтр будет пропускать почту с facebook.com даже если у почтового сервера динамический ip адрес.

sudo vim /etc/postfix/helo_access.pcre

#просто чтобы понять после чего добавлять
/^\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$/ DUNNO
/^(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.facebook.com$/ DUNNO

sudo systemctl restart postfix dovecot

Наш паттерн ^(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.facebook.com$ как раз и говорит что если в hello будет 66-220-155-154.mail-mail.facebook.com то нужно пропустить письмо.

Чтобы проверить рабочий ли паттерн можно воспользоваться онлайн сервисом.

Blockchain - Смарт контракты

Wed, 16 Nov 2022 06:20:39 +0600

В ранней версии блокчейн (Blockchain ), так называемой Blockchain 1.0 мы не могли никак воздействовать на данные, т.е. мы просто собирали данные и записывали их. Происходило так потому что главная задача была регистрация передачи биткоинов между кошельками (владельцами). Т.е. не было никакой задачи использовать его как платформу для своего приложения.

Но в 2015 появился Ethereum, благодаря которому появилась возможность воздействовать на данные, в следствии чего появился этакий Blockchain 2.0.

В Blockchain 2.0 уже появляется возможность воздействовать на данные благодаря смарт контрактам (smart contract). По-простому смарт контракт (smart contract) - это всё тот же код, только в сети блокчейна (Blockchain ). Пользователи всё также совершают транзакции, но только для обработки транзакций используются правила, описанные в смарт контракте (smart contract). Это усовершенствование теперь позволяет блокчейн-решениям управлять процессами и автоматизировать их, а также записывать их результаты в постоянный, неизменяемый и безопасный реестр, доступный для всех соответствующих сторон.

Сам термин смарт контрактам (smart contract) появился ещё в далёком 1996 году благодаря Nick Szabo (не рискну переводить).

Для примера можно рассмотреть продажу Евгением своего бизнеса Алексею. Но вот Алексей не уверен в успешности его бизнеса и Евгений решает добавить условие что, если в течении года Алексей не получит желаемого дохода он не доплатит Евгению 20% от суммы продажи. Т.е. Алексей платит сейчас 80% а через год 20%, если будет выручка.

Благодаря смарт контракту эту сделку можно зарегистрировать в блокчейн (Blockchain ). Т.е. будет заключён договор с использованием смарт контракта, который вернёт на счёт Алексея 20% если условие не будет соблюдено. При этом Алексей всегда с лёгкостью докажет, что в сделке было такое условие, благодаря открытости сети блокчейн (Blockchain ).

В итоге

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

Blockchain - Отличие обычных баз данных от блокчейн

Sun, 13 Nov 2022 06:20:39 +0600

Если вы уже работали с базой данных и ещё мало что знаете про блокчейн, то вы можете подумать, что блокчейн также использует базы данных как приложения, но это не совсем так. И в этой статье мы рассмотрим различия.

Базы данных

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

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

Базы данных в блокчейн

Базы данных в блокчейн находятся на неограниченном количестве децентрализованных узлов (node). И каждый узел является администратором базы данных, в свою очередь участвуя в каждой транзакции. Для того чтобы транзакция была одобрена узлы должны достигнуть консенсуса. Благодаря этому консенсусу злоумышленнику гораздо сложнее вмешаться в работу.

В Ethereum консенсус достигается использованием механизма proof of stake, тогда как Bitcoin использует механизм майнинга.

CRUD vs RW-only

В традиционных базах данных клиент может использовать все операции CRUD (create, read, update, delete), если у него есть права конечно.

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

Прозрачность

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

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

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

Валидация данных

Мы уже говорили о том, что в блокчейн старая запись всегда остаётся неизменной. Для примера представим ситуацию что в вашем кошельке сейчас находится 100 BTC или ETC (какая больше нравится). Далее вы переводите 10 BTC или ETC мне за хорошую статью (мечты), в следствии чего создается новая транзакция в сети блокчейн. Сейчас же у вас в кошельке баланс будет равен 90 BTC или ETC, но, если рассматривать транзакции мы всегда сможем просмотреть что у вас было 100 BTC или ETC в своё время. Т.е. мы сохраняем всю информацию о движениях в нашем кошельке.

В итоге

В итоге можно выделить два основных отличия:

Децентрализация - управление не происходит одним узлом (человеком)
Неизменность данных - каждая новая транзакция создаёт новую запись с новым значением, вместо обновления старой записи

Linux - Как dnf ищет нужный нам пакет?

Fri, 28 Oct 2022 06:20:39 +0600

Если вы администрируете устройства с RHEL, Fedora или CentOS на борту то вы уже вводили команду dnf install огромное количество раз, и возможно никогда даже и не задумывались о том, что же там происходит после вызова этой команды. Нет, конечно понятное дело, что в итоге ставится нужный нам пакет, но вот как это происходит?

Установка пакета

Для примера мы хотим поставить пакет telnet. Для начала нужно понимать, что, когда мы говорим пакет telnet, мы как бы говорим о том, что нужно установить некий файл с расширением .rpm, если конкретнее что-то в стиле telnet-0.17-76.el8.x86_64.rpm.

Часто поэтому можно встретить словосочетание RPM пакет, что сразу говорит о том, что этот пакет предназначен для RHEL, Fedora или CentOS.

sudo dnf install telnet

Команда выше перед тем как поставить пакет должна еще его найти, обычно ищет в интернете. Также вы можете устанавливать пакеты используя команду rpm, но сделать это с использованием dnf или yum куда легче порой быстрее.

yum или dnf?

Я думаю уже ни для кого ни секрет что эти 2 команды по сути выполняют одно и тоже. Но этот абзац я включил в статью так как до этого момента никогда не задумывался как расшифровывается yum и dnf.

yum - Yellowdog Updater, Modified
dnf - Dandified yum

Yum появился раньше dnf, но на данный момент dnf является менеджером пакетов по умолчанию, но сам yum никто никуда еще не убирал.

Как находятся пакеты?

Как мы уже говорили вначале нужно найти необходимый нам пакет. Для этого dnf обращается в начале к файлу манифестов репозитория (repository manifest file), который должен находится в ОС. У самого dnf этот файл также хранится в кэше, что ускоряет установку пакета. Но если информацию о необходимом пакете в кэше найти не удалось, то поиски продолжатся в файлах с расширением .repo в директории /etc/yum.repos.d. В этих файлах dnf ищет url для того чтобы обратится к хранилищу пакетов (репозиторий) ассоциированных с файлом репозитория .repo.

Кэш

Для примера давайте сперва очистим весь наш кэш и попробуем снова установить пакет telnet. В итоге мы должны увидеть процесс обновления кэша.

Для начала проверим что у нас в директории /var/cache/dnf есть файлы кэша для всех наших репозиториев.

sudo dnf repolist

appstream                                                       CentOS Stream 8 - AppStream
baseos                                                          CentOS Stream 8 - BaseOS
extras                                                          CentOS Stream 8 - Extras

sudo ls -la /var/cache/dnf | grep solv

-rw-r--r--.  1 root root 21152015 Oct 28 17:50 appstream-filenames.solvx
-rw-r--r--.  1 root root  6069505 Oct 28 17:50 appstream.solv
-rw-r--r--.  1 root root 12148821 Oct 28 17:50 baseos-filenames.solvx
-rw-r--r--.  1 root root  5945363 Oct 28 17:50 baseos.solv
-rw-r--r--.  1 root root     1787 Oct 28 17:50 extras-filenames.solvx
-rw-r--r--.  1 root root    27929 Oct 28 17:50 extras.solv

Теперь очистим наш кэш и снова проверим наличие файлов.

sudo dnf clean dbcache
sudo ls -la /var/cache/dnf | grep solv

И теперь попробуем установить пакет telnet.

sudo dnf install telnet

Согласитесь что теперь команда установки ищет наш пакет гораздо дольше чем ранее, всё это происходит из-за того что наш кэш пуст и нужно добавить туда информацию из репозиториев, указанных в /etc/yum.repos.d.

Кэш и новый репозиторий

Также каждый раз когда мы вызываем dnf install у нас проверяется наличие нового файла репозитория в директории /etc/yum.repos.d, точнее наличие метаданных для репозитория. Для примера поставим пакет epel-release, который добавит нам новый репозиторий.

sudo dnf install -y epel-release
ls -la /etc/yum.repos.d | grep epel

-rw-r--r--.  1 root root  1417 Jun  8  2021 epel.repo

Теперь снова попробуем поставить пакет telnet, информация про который уже есть у нас в кэше.

sudo dnf install telnet

Extra Packages for Enterprise Linux 8 - x86_64                                                                   4.8 MB/s |  13 MB     00:02
Extra Packages for Enterprise Linux Modular 8 - x86_64                                                           611 kB/s | 733 kB     00:01

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

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

sudo ls -la /var/cache/dnf | grep epel

drwxr-xr-x.  3 root root       42 Oct 28 16:49 epel-6519ee669354a484

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

Репозитории

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

Dnf также пробегается по каждому файлу .rpm и ищет там необходимый пакет до первого совпадения.

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

sudo dnf repolist

appstream                                           CentOS Stream 8 - AppStream
baseos                                              CentOS Stream 8 - BaseOS
extras                                              CentOS Stream 8 - Extras

Собственно команда выше просто пробегает по файлам .repo в директории /etc/yum.repos.d/ и вытаскивает оттуда repo id и repo name, но только если репозиторий активен (enabled=1).

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

В итоге

При установке пакета сперва смотрится кэш
Если нет в кэше нет информации о пакете (например, устаревший кэш) проверяются файлы репозитория и также обновляется кэш
Пакет выкачивается с url ассоциированного с репозиторием
Происходит установка

Что такое супер-приложение (superapp)?

Fri, 21 Oct 2022 06:20:39 +0600

Само понятие супер-приложение (superapp) появилось уже давно, а именно в 2010 году. Но как обычно это бывает, чтобы новинка получила обширный интерес нужно время и парочка удачных кейсов.

Если пытаться провести аналогии с супер-приложением из жизни, то хорошим примером будет швейцарский нож, который даёт своему владельцу возможность использовать большое количество инструментов имея всего один нож. Так вот супер-приложение (superapp) позволяет использовать вам всего одно приложение вместо 10 или даже 100 приложений.

Ну и конечно сам разработчик не остаётся без преимуществ. Если у приложения уже тысячи пользователей, то новый микро-сервис добавляемый в супер-приложение (superapp) не нуждается в раскрутке или большей рекламе. Так как база пользователей уже существует достаточно вывести уведомление для текущих пользователей с описанием нового микро-сервиса.

Также идея супер-приложение (superapp) заключается в том, что при выпуске нового мини приложения разработчику не нужно выкладывать новый микро-сервис в магазине приложений. В идеале в супер-приложение (superapp) новый микро-сервис должен попасть автоматически, без какого-либо действия от пользователя. Правда это иногда сложно осуществить и поэтому приходится обновлять супер-приложение (superapp) в магазине приложений.

Для примера если вы используете одно приложение для заказа такси, другое для оплаты и третье для покупки товаров у вас уже 3 разных приложения. При чём везде нужно регистрироваться отдельно, привязывать карты, постоянно авторизоваться во всех трёх приложениях. Так вот идея супер-приложение (superapp) - это как раз объединения всех этих 3 приложений в одно целое. Конечно же не нами, а разработчиками приложений)

Примеры

В качестве примеров конечно же на первых местах всегда будут приложения из Азии, так как самые первые и масштабные в итоге приложения были разработаны в Китае. Самым масштабным на данный момент, наверное, является WeChat, у которого в составе куча сервисов для платежей, игр, развлечений, бронирования и т.д. Если говорим про Азию, то также можно упомянуть следующие приложения: AliPay, Gojek, Grab.

Если смотреть на запад, то тут конечно уже знакомый нам Uber, как минимум в качестве такси или доставки. В состав Uber также входит Uber Money, UberEats.

В России же самым популярным, наверное, является YandexGo, в принципе я думаю не нуждается в представлении для жителей России и Казахстана.

Ну и Казахстан не отстаёт, имея у себя Kaspi. Самый популярный банк имеет своё приложение, в котором помимо Kaspi QR есть и Kaspi магазин.

Пользовательский интерфейс

Согласитесь, что пользователи разные и как говорится на вкус и цвет товарищей нет. Т.е. один пользователь может пользоваться всем микро-сервисами, а вот другой к примеру, только парочкой. Соответственно супер-приложение (superapp) должно предоставить возможность пользователю самому решать какие именно микро-сервисы загружать при старте приложения.

Итог

Лень двигатель прогресса. Из-за того, что пользователь хочет делать минимум движений для получения конечного результат супер-приложения (superapp) и пользуются спросом.

Будущее развитие супер-приложений (superapp) я считаю будет изобретение собственных смартфонов для супер-приложения (superapp).

Ansible 2.9 - Просмотр версии collection

Fri, 21 Oct 2022 06:20:39 +0600

Если у вас последняя версия ansible и ansible-galaxy то можно просмотреть список всех collections просто одной командой ansible-galaxy list.

Но вот если вас старая версия ansible-galaxy, в которой нет опции list то придётся немножко подумать. В основном рекомендации в интернете — это просто обновить ansible-galaxy и это хорошее решение, но не всегда доступное.

Просмотр версии collection

Так вот чтобы просмотреть нам понадобятся 2 директории: /usr/share/ansible/collections и /home/username/.ansible/collections/. В этих двух директориях по умолчанию хранятся все collections. И если вам повезло, и разработчик вложил в свой collection файлы CHANGELOG или README, то возможно в этих файлах вы и найдёте версию.

В моём случае версия была в файле CHANGELOG.rst.

sudo vim /home/username/.ansible/collections/ansible_collections/containers/podman/CHANGELOG.rst

v1.9.4

PostgreSQL - Баним пользователя после неудачных попыток входа

Thu, 13 Oct 2022 06:20:39 +0600

Сразу оговорюсь что в бесплатной версии PostgreSQL нет встроенного функционала, который бы это обеспечивал. Поэтому все варианты решения данной задачи в той или иной степени можно будет назвать костылями. Одну статью с использованием fail2ban я уже написал, теперь дело за вторым вариантом.

Суть работы

В PostgreSQL используются хуки, которые если просто выражаться без подробностей этакие api модули, написанные на C. Так вот благодаря этим hook вы можете обращаться к уже запущенным сессиям в PostgreSQL, загружая эти модули при старте PostgreSQL.

Мы будем использовать кастомный hook под названием session_exec. Суть в том, что благодаря session_exec мы можем запускать любую функцию в PostgreSQL, но только если аутентификация прошла успешна, т.е. сессия открыта. Я думаю вы сразу поняли почему этот метод я бы назвал костылём, а если нет, то ответ будет ниже. В любом случае я советую дочитать до конца, может вы не так привередливы, как я.

В итоге схема будет следующая:

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

Недостатки

Сразу распишу недостатки этого метода чтобы вы сразу для себя решили нужно ли вам это.

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

Установка session_exec

Клонируем репозиторий

sudo git clone https://github.com/okbob/session_exec.git
cd session_exec

Компилируем и ставим session_exec

sudo dnf install redhat-rpm-config -y
sudo find / -name pg_config
sudo make PG_CONFIG=/usr/pgsql-14/bin/pg_config
sudo make PG_CONFIG=/usr/pgsql-14/bin/pg_config install

Подготовка таблиц

Как я уже говорил выше нам понадобиться 2 таблицы:

auth_table - в которой будем хранить информацию об авторизации
postgres_log - будет FOREIGN TABLE для логов

Поэтому создаём эти 2 таблицы, в таблице postgres_log обратите внимание на команду где я делаю парсинг логов PostgreSQL. Если у вас в postgresql.conf значение переменной log_line_prefix не '%m [%p] %q%u@%d@%h ' парнсинг будет отличаться.

sudo su - postgres
vim get_logs.sh

find /var/lib/pgsql/14/data/log/ -type f -name "*.log" -mtime -1 -exec cat {} \; | grep "password authentication failed " | awk -F " " '{print $1,$2,$3"@",$4"@",$5"@",$6"@",$7" "$8" "$9" "$10" "$11" "$12;}'  | awk '{ gsub("@ ","@"); print }'

chmod u+x get_logs.sh
psql

create table auth_table
(
login_time timestamp(3),
user_name text ,
auth int4
);

CREATE EXTENSION file_fdw;
CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;

CREATE FOREIGN TABLE postgres_log(
  log_time timestamp(3),
  session_id  text,
  user_name text,
  database_name text,
  connection_from text,
  error_severity text,
  message text
) SERVER pglog
OPTIONS ( program '/var/lib/pgsql/get_logs.sh', format 'csv', delimiter '@');

Создание пользователя для тестов

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

sudo vim /var/lib/pgsql/14/data/pg_hba.conf

host    all             admin             127.0.0.1/32            md5
local    all             admin                        md5

sudo systemctl reload postgresql-14
sudo su - postgres
psql

CREATE USER admin WITH PASSWORD '123456';

А я напоминаю, что в проде не стоит писать в команде открытый пароль.

psql -U admin -d postgres

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  password authentication failed for user "admin"

Теперь сделаем select к таблице postgres_log и проверим что доступ к логам PostgreSQL присутствует.

select * from postgres_log;

          log_time           | session_id | user_name | database_name | connection_from | error_severity |                    message

-----------------------------+------------+-----------+---------------+-----------------+----------------+---------------------------------------
---------
 2022-10-11 11:01:55.938 +06 |  [206815]  |  admin    | postgres      | [local]         |  FATAL:        |  password authentication failed for user admin

Первичная запись

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

psql

insert into auth_table  select log_time,user_name,0
    from postgres_log
    where message LIKE '%authentication failed%'
    and error_severity= 'FATAL:';

Создание функции

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

psql

create or replace function custom_login() returns void as $$
declare
res text;
c1 timestamp(3) with time zone;
begin

-- Get the latest time in the current log 
select login_time 
from public.auth_table 
where auth = 0 
order by login_time 
desc limit 1 
into c1; 

 -- Insert the latest data into auth_table surface 
insert into public.auth_table  
select log_time,user_name 
from public.postgres_log 
where message LIKE '%authentication failed%'
and error_severity= 'FATAL:' 
and log_time > c1;

update public.auth_table set auth = 1 where login_time > c1; 

-- Check if the number of login failures is greater than 3, If more than 3 Then lock the user 
for res in select user_name from public.auth_table where auth = 1 group by user_name having count(*) >=3 
loop
-- Lock the user 
EXECUTE format('alter user %I nologin',res); 
-- Disconnect the currently locked user session 
EXECUTE 'select pg_catalog.pg_terminate_backend(pid) from pg_catalog.pg_stat_activity where usename=$1' using res; 
raise notice 'Account % is locked!',res;
end loop;
end;
$$ language plpgsql strict security definer set search_path to 'public';

Вызов библиотеки session_exec

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

sudo vim /var/lib/pgsql/14/data/postgresql.conf

session_preload_libraries = 'session_exec'
session_exec.login_name='custom_login'

sudo systemctl restart postgresql-14

Теперь если неудачно залогинится и проверить таблицу auth_table то у нас должна появится запись о неудачной аутентификации от пользователя admin.

psql

select * from auth_table;

2022-10-11 11:01:55.938 |  admin    |    0
2022-10-11 11:43:28.614 |  admin    |    1

Тестируем

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

psql -U admin -d postgres
psql -U admin -d postgres
psql -U admin -d postgres

psql

NOTICE:  Account admin is locked!

\du

                                   List of roles
 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 admin     | Cannot login                                               | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Разблокировка пользователя

А вот разблокировать пользователя придётся вручную, выполнив команды ниже:

update auth_table set auth = 0 where user_name='admin' and auth=1;
alter user admin login ;
\du

 Role name |                         Attributes                         | Member of
-----------+------------------------------------------------------------+-----------
 admin     |                                                            | {}
 postgres  | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Итог

Самый большой минус этого решения что нужно удачно залогинится чтобы пользователь всё-таки заблокировался, при этом не важно под каким пользователем вы залогинились (superuser и т.д.). При этом в целом сам пользователь, который неудачно логинился 3 раза после тоже не зайдёт, но вот ошибка будет psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: terminating connection due to administrator command. Но если у вас большой проект и там авторизация происходит часто, то это небольшая проблема.

Второе это то что при каждом логине будет считывается информация с лог файлов PostgreSQL что будет немного притормаживать саму систему. Насколько сильно будет страдать производительность я не знаю, так как тестировал на редко используем сервере. Если уж этот процесс действительно долгий то как решение можно получать логи только сегодняшнего дня используя следующий запрос: find /var/lib/pgsql/14/data/log/ -type f -name "*.log" -mtime -1 -exec cat {} \; | grep "$asd .* password authentication failed ".

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

Fail2ban - Selinux context

Sun, 09 Oct 2022 06:20:39 +0600

История начинается с того что мне понадобилось настроить Fail2ban на блокировку по IP если кото-то неудачно залогинился в PostgreSQL, если интересно можно почитать тут. Так вот написал я своё правило верно, но при старте fail2ban получил ошибку Have not found any log file for postgres-lockuser jail. По сути ошибка говорит о том, что нет никаких логов в директории, что я указал. Но я-то знаю, что там есть, да и если выключить Selinux то всё работает прекрасно.

Решение Have not found any log file for jail

Начинающий специалист или в простонародном пофигист просто отключил бы этот вредный Selinux и пошёл дальше смотреть приколы в глобальной паутине. Но это не мой выход, и я решил разобраться. Да и решение на самом деле оказалось довольно простым.

/var/log/audit/audit.log

Для начала проверим логи /var/log/audit/audit.log.

sudo tail -f /var/log/audit/audit.log | grep fail2ban-server

type=AVC msg=audit(1665124834.173:407292): avc:  denied  { read } for  pid=16323 comm="fail2ban-server" name="log" dev="sdi" ino=1442802 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

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

sudo audit2allow -w -a

type=AVC msg=audit(1665124834.173:407292): avc:  denied  { read } for  pid=16323 comm="fail2ban-server" name="log" dev="sdi" ino=1442802 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0
        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

В итоге мы видим, что нет правила selinux чтобы Fail2ban имел доступ к логам PostgreSQL.

Создадим это правило

На самом деле всё просто и создаём мы все одной командой.

Для начала узнаем какое правило нам нужно найти в логах. Для этого выполняем:

sudo audit2allow -a

#============= fail2ban_t ==============
#!!!! WARNING: 'unlabeled_t' is a base type.
allow fail2ban_t unlabeled_t:dir read

Теперь используя grep отыщем логи с упоминанием fail2ban и сразу же создадим правило только для fail2ban. Иначе в правило попадут все проблемные сервисы и права для них.

sudo grep fail2ban /var/log/audit/audit.log | sudo audit2allow -M fail2ban-postgresql

To make this policy package active, execute:
semodule -i fail2ban-postgresql.pp

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

sudo ls -la | grep fail2ban

-rw-r-----. 1 root   root   2008 Oct  7 14:07 fail2ban-postgresql.pp
-rw-r-----. 1 root   root    840 Oct  7 14:07 fail2ban-postgresql.te

В файле fail2ban-postgresql.te как раз-таки и прописывается что будет происходить при активации данного правила.

sudo vim fail2ban-postgresql.te

module fail2ban-postgresql 1.0;

require {
        type unlabeled_t;
        type fail2ban_t;
        class dir read;
}

#============= fail2ban_t ==============

#!!!! WARNING: 'unlabeled_t' is a base type.
allow fail2ban_t unlabeled_t:dir read;

Применяем правило

И теперь собственно последний шаг в этом нелегком деле - это применить созданное правило.

sudo semodule -i fail2ban-postgresql.pp

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

Fail2ban - Блокировка по IP при неудачной аутентификации в PostgreSQL

Sun, 09 Oct 2022 06:20:39 +0600

Так уж сложилось что в бесплатной версии PostgreSQL нет возможности блокировать пользователя после достижения определенного количества неудачных попыток аутентификации. Поэтому приходится использовать что-то другое для решения этой задачи.

Fail2ban

При использовании Fail2ban банить именно пользователя в PostgreSQL не получится, если только не использовать скрипты PostgreSQL для блокировки пользователя. Но тут встаёт вопрос с подключением к бд, и хранению пароля.

В моём же случае было достаточно просто блокировать подключения к PostgreSQL с IP-адреса, от которого были множественные неудачные подключения.

Создаём jail

Jail включает в себя набор правил и фильтров, по которым и происходим блокировка.

Для создания выполняем следующее:

sudo vim /etc/fail2ban/jail.d/postgres.conf

[postgres-iplock]

enabled = true
#filter name
filter = postgres-iplock
#filter action
action = iptables-postgres
#path to logs
logpath = /var/lib/pgsql/12/data/log/postgresql-*.log
maxretry = 3
bantime = 380
usedns = raw

Создаём фильтр

Используя фильтр Fail2ban будет искать вхождение в лог файлах, путь к которым указан в переменной logpath.

sudo vim /etc/fail2ban/filter.d/postgres-iplock.conf

[Definition]
failregex = ^.*@<F-ID/> FATAL:  password authentication failed .*

Внимание ваш pattern для фильтра может отличатся, так как в PostgreSQL можно изменить стиль вывода логов, используя переменную log_line_prefix, в файле postgresql.conf. В моём случае значение переменной '%m [%p] %q%u@%d@%h '.

Создаём правило

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

Я же выбрал стандартный iptables только подредактировал под порт 5432.

sudo cp /etc/fail2ban/action.d/iptables.conf /etc/fail2ban/action.d/iptables-postgres.conf
sudo vim /etc/fail2ban/action.d/iptables-postgres.conf

[INCLUDES]

before = iptables-common.conf

[Definition]

actionstart = <iptables> -N f2b-<name>
              <iptables> -A f2b-<name> -j <returntype>
              <iptables> -I <chain> -p tcp --dport 5432 -j f2b-<name>

actioncheck = <iptables> -n -L <chain> | grep -q 'f2b-<name>[ \t]'

actionban = <iptables> -I f2b-<name> 1 -s <ip> -j <blocktype>

actionunban = <iptables> -D f2b-<name> -s <ip> -j <blocktype>

[Init]

Тестируем

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

sudo systemctl restart fail2ban

Пытаемся неудачно залогинится на сервер PostgreSQL как минимум 3 раза. Если всё сделано правильно, то после 3 раза у нас просто будет недоступен порт 5432.

psql -U admin -d postgres

В файле логов находим следующие записи:

2022-10-07 16:41:31,773 fail2ban.filter         [1109]: INFO    [postgres-lockuser] Found 192.168.0.11 - 2022-10-07 16:41:31
2022-10-07 16:41:34,613 fail2ban.filter         [1109]: INFO    [postgres-lockuser] Found 192.168.0.11 - 2022-10-07 16:41:34
2022-10-07 16:41:37,023 fail2ban.filter         [1109]: INFO    [postgres-lockuser] Found 192.168.0.11 - 2022-10-07 16:41:36
2022-10-07 16:41:37,073 fail2ban.actions        [1109]: NOTICE  [postgres-lockuser] Ban 192.168.0.11
2022-10-07 16:47:56,173 fail2ban.actions        [1109]: NOTICE  [postgres-lockuser] Unban 192.168.0.11

Время, через которое IP-адрес будет разбанен задаётся в переменной bantime.

Итог

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

В общем решение всегда за вами подходит вам такой метод или нет.

Еще один минус в том, что fail2ban не умеет работать с ротацией логов. Т.е. если активный файл с логами создастся после запуска сервиса fail2ban он не поймёт, что логи в новом файле. Во избежание такой ситуации все активные логи надо писать в один файл и к нему применять какой-нибудь logrotate.

Ansible - Timeout waiting for privilege escalation prompt

Thu, 29 Sep 2022 06:20:39 +0600

При выполнении задачи (task) в Ansible можно получить ошибку timeout waiting for privilege escalation prompt. При чём ошибка плавающая, может вылезать на любой задаче в play.

Решение 1

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

vim /etc/ansible/ansible.cfg

[defaults]
timeout = 60

Решение 2

Вторым решением, которое было правдиво именно в моём случае является нагрузка на сервер. Первым делом я рекомендую проверить нагрузку на ваш сервер. В моём случае сервер был полностью загружен по ОЗУ, причём это клиентский сервер, а не сервер с Ansible.

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

Windows - Безопасный пароль в скриптах

Fri, 23 Sep 2022 06:20:39 +0600

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

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

Export-Clixml

Наш первый вариант — это команда Export-Clixml, которая просто сохраняет пароль в xml файл. Т.е. суть работы следующая:

Вы экспортируете пароль в файл под текущим пользователем, под которым будете запускать скрипт
Удостоверяетесь что доступ к этому файлу есть только у этого пользователя
Уже используя команду Import-CliXml импортируете пароль в свой скрипт
Рекомендация от меня если возможно запретить этому пользователю вход в систему и сделать файл скрытым

Скажу сразу что этот вариант мне не нравится. Да вы получите доступ к файлу с паролем только под этим пользователем. Но не забываем несколько вещей:

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

#ask for password
$pwd = Get-Credential myuser
#store password in file
$pwd | Export-CLiXml password.clixml
# Make files hidden
(get-item password.clixml).Attributes += 'Hidden'
#get password from file
$password= Import-CliXml password.clixml

ConvertTo-SecureString

Вариант второй уже нравится мне больше. Тут мы используем команду ConvertTo-SecureString которая преобразует обычную строку в безопасную. Также для большей безопасности то, что мы получили от команды ConvertTo-SecureString будем дополнительно шифровать, с использованием файл ключа. Суть работы следующая:

Мы создаём файл ключ, который дальше будет использоваться для создания зашифрованной строки
Создаём текстовый файл, в котором сохраняем пароль в чистом виде (потом удаляем)
Преобразовываем обычную строку в безопасную (ConvertTo-SecureString)
Преобразовываем безопасную строку в зашифрованную используя ключ (ConvertFrom-SecureString)
Сохраняем полученное в файл
Используем в скриптах расшифровывая с использованием файл ключа

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

#path for key file
$keyFile  =  "keyfile.key"
#path for file which contain password (must be deleted after first run)
$insecurePassFile  =  "insecurePass.txt"
##path for file which will be contain encrypted password
$securePassFile  =  "securePass.txt"

#Create key file
$key  =  New-Object  Byte[]  32
$key | Out-File  $keyFile
(get-item $keyFile).Attributes += 'Hidden'

#Convert password to secure string and then to encrypted string
$key  =  Get-Content  $keyFile
$password  =  Get-Content  $insecurePassFile | Select-Object  -First  1 | ConvertTo-SecureString  -AsPlainText  -Force | ConvertFrom-SecureString  -key  $key
$password | Out-File  $securePassFile
(get-item $securePassFile).Attributes += 'Hidden'

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

После можно уже использовать эту схему у себя в скрипте:

#Get password in secure string
$SecurePassword = Get-Content  $securePassFile | ConvertTo-SecureString  -Key  $key
$Credentials  =  New-Object  System.Management.Automation.PSCredential -ArgumentList  $UserName, $SecurePassword

#Get password 
$pwd  = [System.Net.NetworkCredential]::new("", ( Get-Content  $securePassFile | ConvertTo-SecureString  -Key  $key ) ).Password
$pwd
$pwd2  =  $Credentials.GetNetworkCredential().Password
$pwd2

ConvertTo-SecureString

Вариант выше конечно же хорош, но мне этого еще недостаточно. Ну что тебе не нравится тут? - спросите вы. А не нравится мне то, что тут присутствует файл ключ, который всё также может стырить какой-нибудь жулик (жулик не воруй).

И что можно сделать? Да по сути ничего не надо особо менять, выполняем всё тоже самое только без ключа (ConvertFrom-SecureString). Магия тут вся заключается в Windows Data Protection API, благодаря которой вместо ключа будет не файл, а ваша учетная запись WIndows. Да, да вот такая замечательная новость, т.е. для того чтобы добраться до пароля жулику нужно будет залогинится под вашей учетной записью и именно на этом же хосте.

#path for file which contain password (must be deleted after first run)
$insecurePassFile  =  "insecurePass.txt"
##path for file which will be contain encrypted password
$securePassFile  =  "securePass.txt"

#Convert password to secure string and then to encrypted string
$password  =  Get-Content  $insecurePassFile | Select-Object  -First  1 | ConvertTo-SecureString  -AsPlainText  -Force | ConvertFrom-SecureString
$password | Out-File  $securePassFile
(get-item $securePassFile).Attributes += 'Hidden'

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

#Get password in secure string
$SecurePassword = Get-Content  $securePassFile | ConvertTo-SecureString
$Credentials  =  New-Object  System.Management.Automation.PSCredential -ArgumentList  $UserName, $SecurePassword

#Get password 
$pwd  = [System.Net.NetworkCredential]::new("", ( Get-Content  $securePassFile | ConvertTo-SecureString ) ).Password
$pwd
$pwd2  =  $Credentials.GetNetworkCredential().Password
$pwd2

Заключение

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

Linux - Ставим PowerShell

Wed, 07 Sep 2022 06:20:39 +0600

Вопрос конечно спорный нужно ли ставить PowerShell в Linux, но задачи бывают разные. Например, мне нужно было использовать PowerCLI, который есть только под PowerShell.

CentOS

Добавляем репозиторий

curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

Если у вас версия CentOS не 7, то обязательно замените цифру 7 в команде curl.

Ставим PowerShell

sudo yum install --assumeyes powershell
pwsh

Ubuntu

Добавляем репозиторий

sudo apt-get update
sudo apt-get install -y wget apt-transport-https software-properties-common
wget -q "https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb"
sudo dpkg -i packages-microsoft-prod.deb

Ставим PowerShell

sudo apt-get update
sudo apt-get install -y powershell
pwsh

Ansible - user 'xxx' does not exist in /etc/passwd

Wed, 07 Sep 2022 06:20:39 +0600

При выполнении обычной задачи по созданию пользователя получил ошибку usermod: user ‘xxx’ does not exist in /etc/passwd, хотя до этого уже выполнял такую же задачу с другим пользователем. Соответственно мысль о том, что что-то не так с сервером я сразу отсёк.

Суть проблемы

Вся суть тут в том, что вы скорее всего используете на этом хосте SSO. Если говорить простыми словами, то у вас для авторизации используется AD.

И вся проблема в том, что вы пытаетесь локально на хосте создать пользователя, который уже существует в AD. В моём случае я пытался создать пользователя, который уже был создан во FreeIPA.

Решение

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

Ну если вам уж очень нужно создать такого же пользователя локально, то можно попробовать удалить домашнюю директорию пользователя, например, sudo rm /home/username.

MinIO - Распределенный режим (Distributed Mode)

Fri, 05 Aug 2022 06:20:39 +0600

Мы уже говорил о том, как не надо устанавливать сервер MinIO в production. В этой же статье как раз и поговорим о том, как же всё-таки надо ставить MinIO в productiion среде.

В распределенном режиме подразумевается, что у вас в общем 4 или более дисков (каталогов), которые могут быть отданы одной ноде либо нескольким. Конечно запускать всё на одной ноде в productiion среде не рекомендуется. Каждая нода MinIO в распределенном режиме имеет полную картину о других нодах так что ваше приложение может подключаться к любой ноде.

В распределенном режиме автоматически включается опция erasure code, которая дублирует ваши данные обеспечивая возможность не потерять данные при выходе из строя нод либо дисков. Можно сравнить данную функцию с RAID, но Erasure coding обеспечивает восстановление на уровне объекта с меньшими затратами.

В зависимости от того какую четность erasure code вы настроили вы можете продолжать операции чтения и записи только с m/2 серверами или m*n/2 дисками, подключенными к сети и доступными.

Распределенном режим также поддерживает следующие функции:

Репликация объектов
Блокировка однократной записи и многократного чтения
Версионность объекта

Требования

Каждая нода должна иметь доступ к другим нодам по API порту. Также все сервер MinIO должен быть запущен с использованием одинаковых портов на всех нодах.

MinIO рекомендуют использование балансировщика нагрузки для управления подключением к кластеру, например, NGINX, HAProxy.

Одинаковые имена

Для того чтобы развернуть MinIO в распределенном режиме ваши имена серверов должны называться так чтобы в итоге вы могли использовать регулярные выражения для передачи этих имён одной строкой создавая таким образом пул серверов (server pool).

Например имея такие имена серверов как minio1.example.com, minio2.example.com, minio3.example.com мы легко можем перечислить их одной строкой типа minio{1...3}.example.com.

JBOD

При использовании MinIO рекомендуется использовать голые диски (JBOD) с типом файловой системы XFS.

Если верить официальному сайту, то использование файловых систем, отличных от XFS как правило, имеют более низкую производительность.

Ещё одна рекомендация — это использовать одинаковые диски во всех нодах пула серверов, как тип жесткого диска, так и его размер. Кроме того, MinIO ограничивает размер используемого диска до самого маленького диска. Например, если в ноде есть 15 дисков по 10 ТБ и 1 диск по 1 ТБ, MinIO ограничивает емкость каждого диска до 1 ТБ, по сути, как и СХД.

Ну и еще одно логичное замечание — это то что все диски должны быть перемонтированы с использованием fstab, будет плохо если все диски пропадут после перезагрузки.

Одинаковая конфигурация

На сайте min.io сказано, что строго рекомендуется использовать сервера с одинаковым аппаратным обеспечением, хотя на мой взгляд это не так важно. Конечно использовать сервера с разным объёмом ОЗУ или количеством ядер не стоит, но вот какая разница какой производитель ОЗУ или количество планок я не совсем понимаю.

Планирование мощностей

Также рекомендуется брать железо для MinIO с расчётом на то что вы не будете его апгрейдить как минимум еще 2 года.

Например, если ваше приложение за год создаёт файлы общим размером в 5ТБ, то вы должны иметь 15ТБ свободного дискового пространства.

Установка

Мы будем рассматривать установку MinIO в распределенном режиме, состоящую из одного пула серверов (Server Pool).

1. Установка сервера MinIO

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

Для установки сервера MinIO можно воспользоваться 3 методами:

Установка с использованием RPM (RHEL)

wget https://dl.min.io/server/minio/release/linux-amd64/minio-20220523184511.0.0.x86_64.rpm -O minio.rpm
sudo dnf install minio.rpm -y

Установка с использованием DEB(UBUNTU)

wget https://dl.min.io/server/minio/release/linux-amd64/minio_20220519182059.0.0_amd64.deb -O minio.deb
sudo dpkg -i minio.deb

Скачать бинарный файл

wget https://dl.min.io/server/minio/release/linux-amd64/minio
sudo mv minio /usr/local/bin/
sudo chmod +x /usr/local/bin/minio

2. Создание systemd сервиса

Если вы установили с использованием deb или rpm пакета, то у вас уже создался файл сервиса по пути /etc/systemd/system/minio.service, если же нет, то придётся создавать его вручную.

sudo vim /etc/systemd/system/minio.service

[Unit]
Description=MinIO
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
WorkingDirectory=/usr/local

User=minio-user
Group=minio-user
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi"
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=65536

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutStopSec=infinity
SendSIGKILL=no

[Install]
WantedBy=multi-user.target

Обратите внимание на User и Group именно под этим пользователем и группой будет работать сервис, так что у этого пользователя должны быть полные права к каталогам с данными.

Для того чтобы добавить нового пользователя и сделать его владельцем каталогам с данными выполняем следующее:

sudo groupadd -r minio-user
sudo useradd -M -r -g minio-user minio-user
sudo chown minio-user:minio-user /data1 /data2 /data3 /data4

3. Создание файла с переменными

Как вы уже заметили в файле сервиса значениями многих параметров являются переменные, соответственно нам надо как-то передать эти переменные. Для этого нам понадобится создать файл /etc/default/minio и поместить в него переменные.

sudo vim /etc/default/minio

#собственно указываем сервера и директории для данных
MINIO_VOLUMES="https://minio{1...4}.example.net:9000/mnt/disk{1...4}/minio"
#порт консоли
MINIO_OPTS="--console-address :9001"
MINIO_ROOT_USER=minioadmin
MINIO_ROOT_PASSWORD=passw0rd
# URL-адрес балансировщика нагрузки 
# Это значение *должно* совпадать на всех серверах MinIO
# у вас нет балансировщика нагрузки, установите это значение на любой *один* из нод MinIO
MINIO_SERVER_URL="https://minio.example.net:9000"

sudo chown minio-user:minio-user /etc/default/minio

Также по желанию вы можете установить значения и для других переменных.

4. TLS/SSL сертификаты

Если вы хотите использовать https то вам понадобится пара открытого (.crt) и закрытого ключа (.key). Их нужно будет поместить в директорию ${HOME}/.minio/certs.

Если вы запускаете MinIO как сервис systemd то папкой ${HOME} будет являться домашняя директория пользователя, в нашем примере minio-user. Т.е. получается ключи нужно положить в директорию /home/minio-user/.minio/certs.

Если вы используете сертификат подписанный вашим личным центром сертификации то нужно будет поместить его публичный ключ в каталог /home/minio-user/.minio/certs/CAs. И это конечно же нужно делать на каждой ноде пула серверов.

Если вам чем-то не угодила папка сертификатов по умолчанию вы всегда можете задать свой собственный путь используя –certs-dir.

5. Настраиваем firewall

Ну и конечно нашим нодам нужно общаться между собой по портам 9000. Если у вас по умолчанию включен firewall а так собственно и должно быть, то необходимо его настроить.

sudo firewall-cmd --add-port=9000/tcp --permanent
sudo firewall-cmd --add-port=9001/tcp --permanent
sudo firewall-cmd --reload

5. Запускаем сервис MinIO

И вот мы наконец-то перешли уже к запуску сервера MinIO. Чтобы пул серверов заработал нужно запустить все ноды в пуле.

sudo systemctl enable minio.service
sudo systemctl start minio.service

Проверяем что наш сервис живой выполнив команду sudo systemctl status minio.service. Если с сервисом что-то пошло не так вы всегда можете посмотреть его логи выполнив команду journalctl -u minio.service.

6. Подключаемся к консоли

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

В итоге получаем такую картину, где вбиваем логин и пароль (задавали в файле переменных).

Используя консоль, вы можете создавать пользователей, права доступа, бакеты и т.д. Правда не всё можно сделать через консоль, поэтому необходимо также и установить MinIO Client.

7. Установка MinIO Client

Используя MinIO Client, вы получаете возможность управления сервером MinIO в командной строке.

wget https://dl.min.io/client/mc/release/linux-amd64/mc
sudo mv mc /usr/local/bin/mc
sudo chmod +x /usr/local/bin/mc

8. Создаём alias для сервера MinIO

Для того чтобы управлять сервером используя MinIO Client нужно задать серверу alias дабы не писать каждый раз адрес сервера и его логин и пароль. Если вы делаете это локально, т.е. на том же сервере где стоит сервер MinIO можно в качестве ip-адреса использовать 127.0.0.1. Но тут в отличии от консоли необходимо указывать API порт, который по умолчанию 9000.

Опять-таки вы можете создать alias для любой ноды в пуле ну или же на всех нодах локально, всё на ваше усмотрение.

mc alias set local http://127.0.0.1:9000 minioadmin minioadmin

Added `local` successfully.

mc admin info local

●  127.0.0.1:9000
   Uptime: 19 minutes
   Version: 2022-05-19T18:20:59Z
●  127.0.0.1:9000
   Uptime: 19 minutes
   Version: 2022-05-19T18:20:59Z
●  127.0.0.1:9000
   Uptime: 19 minutes
   Version: 2022-05-19T18:20:59Z

Команда mc admin info local выводит нам всю информацию о нодах MinIO.

Veeam - Мониторинг через PowerShell

Fri, 22 Jul 2022 06:20:39 +0600

Как такого готово модуля под ELK либо Splunk у Veeam Backup and Replication нету и вроде не предвидится. А когда такое происходит приходится что-то придумывать самому, обычно на помощь приходят скрипты. И эта статья не исключение.

Сразу оговорюсь что в этой статье я не буду использовать стандартный функционал Veeam Backup and Replication с оповещениями по email и т.д. Я считаю если есть система мониторинга, то нужно всё добавлять туда и смотреть всё в одном месте, хоть это иногда и сложно.

Veeam.Backup.PowerShell

Для того, чтобы работать с Veeam Backup and Replicationнам понадобится модуль Veeam.Backup.PowerShell, который ставится по умолчанию вместе с самим Veeam Backup and Replication.

Для того чтобы начать работу открываем консоль Veeam Backup and Replication, далее в меню выбираем Console > Powershell.

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

Get-Module -Name Veeam.Backup.PowerShell

oduleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Manifest   1.0        Veeam.Backup.PowerShell             {Add-CTFile, Add-HP3Snapshot, Add-HP3Storage

Также можно вывести список команд, которые мы можем использовать благодаря этому модуля используя команду Get-Help либо Get-VBRCommand. Обратите внимание так как мы используем для мониторинга, то соответственно мы будем использовать только команды Get.

Get-Help Veeam.Backup.PowerShell

Get-VBRHvServerVolume             Cmdlet    Veeam.Backup.PowerShell   Returns volume-specific settings for Microso
Get-VBRInstalledLicense           Cmdlet    Veeam.Backup.PowerShell   Returns details about licenses installed on 
Get-VBRInstanceLicenseSummary     Cmdlet    Veeam.Backup.PowerShell   Returns details on the per-instance license 
Get-VBRSecurityOptions            Cmdlet    Veeam.Backup.PowerShell

Get-VBRCommand -Verb Get

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-HP3InfrastructureVolume                        1.0        Veeam.Backup.PowerShell
Cmdlet          Get-HP3Snapshot                                    1.0        Veeam.Backup.PowerShell
Cmdlet          Get-HP3Storage                                     1.0        Veeam.Backup.PowerShell
Cmdlet          Get-HP3Volume                                      1.0        Veeam.Backup.PowerShell

Документация

Вы всегда можете найти документацию по той или иной команде на сайте, либо же выполнить команду Get-Help.

Get-Help Connect-VBRServer

SYNOPSIS
    Connects to Veeam backup server.


SYNTAX
    Connect-VBRServer [-Server <String>] [-Port <Int32>] [-Timeout <Int32>] [<CommonParameters>]

Создание пользователя

Конечно правильным тоном в мониторинге считается что вы всегда создаёте отдельного пользователя с ограниченными правами, если это возможно конечно. Вот в случае с Veeam Backup and Replication так как раз и не получится потому что чтобы использовать модуль Veeam.Backup.PowerShell вам необходимо быть в группе Veeam Backup Administrator, жаль конечно.

Для начала нужно создать этого самого пользователя в самой ОС Windows, как это делать я опущу так как считаю, что с этим должен справится даже самый юный сисадмин.

После того как пользователь был добавлен надо добавить его в группу Veeam Backup Administrator в самой консоли Veeam Backup and Replication. Для этого в левом верхнем меню выбираем Users and Roles.

Проверка подключения

Теперь, когда у нас есть пользователь остаётся проверить подключение к Veeam Backup and Replication. Для этого используем команду Connect-VBRServer, если получаете ошибку о уже существующей сессии выполните Disconnect-VBRServer.

Disconnect-VBRServer
Connect-VBRServer -Server 127.0.0.1 -U VeeamReader

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

Get-VBRLocalhost

Description        : Backup server
IsUnavailable      : False
Type               : Local
ApiVersion         : Unknown

Проверка лицензии

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

Для проверки лицензии используется команда Get-VBRInstalledLicense, или вот вам готовый скрипт.

Get-VBRInstalledLicense

SupportExpirationDate               : 3/15/2023 12:00:00 AM
AutoUpdateEnabled                   : False
FreeAgentInstanceConsumptionEnabled : True
CloudConnect                        : Disabled

Проверка бэкапов

Естественно вам необходимо также мониторить и сами бэкапы, а точнее их состояние, когда выполнялись и т.д. Для этого используется команда Get-VBRBackup, или вот вам готовый скрипт.

Get-VBRBackup

Backup Job 1              VMware Backup   12/3/2021 10:02:5...               1

Проверка подключенных хостов

Используя Veeam Backup and Replicationвы можете бэкапить как виртуальные так и физические сервера, но для начала вам нужно добавить эти в сервера в сам Veeam Backup and Replication. И вот чтобы мониторить какие именно вы добавили сервера используется команда Get-VBRServer, или вот вам готовый скрипт.

Get-VBRServer

Info               : 192.168.0.2 (VMware ESXi server)
Name               : 192.168.0.2
Reference          : host-2
IsUnavailable      : False
Type               : ESXi

Info               : 192.168.0.3 (Microsoft Windows server)
Name               : 192.168.0.3
IsUnavailable      : False
Type               : Windows

Тут, например, можно сделать alert в системе мониторинга если один из серверов со статусом IsUnavailable = True.

Список Job

Для того чтобы получить список всех задач в Veeam Backup and Replication используется команда Get-VBRJob, или вот вам готовый скрипт.

Get-VBRJob

Job Name                  Type            State      Last Result  Description
--------                  ----            -----      -----------  -----------
Backup Job 1        VMware Backup   Stopped    None         Created by asd\Administrator at 12/4/2021 11:57 PM.
Backup Job 3         VMware Backup   Stopped    None         Created by asd\Administrator at 12/4/2021 12:25 AM

Информация о сервере

Ну и уже знакомая нам команда Get-VBRLocalhost, или вот вам готовый скрипт.

Get-VBRLocalhost

```json
Description        : Backup server
IsUnavailable      : False
Type               : Local
ApiVersion         : Unknown

Заключение

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

Могу лишь описать схему как это у меня уже работает со Splunk:

Я добавил все эти скрипты в приложение (Splunk Deployment)
Добавил input
Создал dashboard и alerts

Если у вас агент не может запускаться от имени определённого пользователя, то вам в скриптах придётся еще добавлять подключение используя команду Connect-VBRServer. Но так как Veeam Backup and Replication ставится только на Windows то значит агент скорее всего работает как сервис, а как запустить сервис от определённого пользователя в Windows легко узнать с помощью google.

Также вы можете запускать скрипты через Execbeat и отправлять вывод в Elasticsearch. Подробнее про execbeat по ссылке.

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

ELK - Запуск команд и отправка вывода в Elasticsearch (execbeat)

Fri, 22 Jul 2022 06:20:39 +0600

Если вы тут оказались, то значит вы также, как и я захотели отправлять вывод своих скриптов в Elasticsearch. По умолчанию в стеке ELK запускать скрипты можно только используя Logstash. Но конечно ставить на все хосты Logstash как-то не хочется, и тут вопрос не в том, что просто не хочется, а в том насколько это целесообразно.

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

Execbeat

И для нашей темы интересен агент Execbeat, так как благодаря ему мы можем запускать команды (скрипты) на Windows или Linux. Можно заметить, что по сути проект уже давно не обновлялся, поэтому использовать его или нет хороший вопрос, на который вы должны найти ответ сами.

Установка

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

Windows

Скачиваем архив и распаковываем в нужную нам директорию.

Linux

wget https://github.com/christiangalsterer/execbeat/releases/download/3.3.0/execbeat-3.3.0-i686.rpm
sudo yum -y install execbeat-3.3.0-i686.rpm
ls /etc/execbeat

Настройка

Дальнейшие шаги будут идентичны для обоих типов ОС, поэтому не буду расписывать отдельно для каждой.

Для начала стоит заменить содержимое файла execbeat.template.json на содержимое этого файла.

Далее создаём шаблон индекса для execbeat, сам файл тут.

 PUT _index_template/execbeat-main
{
  "priority": 98,
  "template": {
"mappings": {
  "_routing": {
    "required": false
  },
  "numeric_detection": false,
  "_meta": {
    "beat": "execbeat",
    "version": "5.6.2"
  },
  "_source": {
    "excludes": [],
    "includes": [],
    "enabled": true
  },
  "dynamic": true,
  "dynamic_templates": [
    {
      "strings_as_keyword": {
        "mapping": {
          "ignore_above": 1024,
          "type": "keyword"
        },
        "match_mapping_type": "string"
      }
    }
  ],
  "date_detection": false,
  "properties": {
    "@timestamp": {
      "type": "date"
    },
    "meta": {
      "type": "object",
      "properties": {
        "cloud": {
          "type": "object",
          "properties": {
            "machine_type": {
              "type": "keyword"
            },
            "availability_zone": {
              "type": "keyword"
            },
            "instance_id": {
              "type": "keyword"
            },
            "project_id": {
              "type": "keyword"
            },
            "provider": {
              "type": "keyword"
            },
            "region": {
              "type": "keyword"
            }
          }
        }
      }
    },
    "beat": {
      "type": "object",
      "properties": {
        "hostname": {
          "eager_global_ordinals": false,
          "index_phrases": false,
          "fielddata": false,
          "norms": true,
          "index": true,
          "store": false,
          "type": "text",
          "index_options": "positions"
        },
        "name": {
          "eager_global_ordinals": false,
          "index_phrases": false,
          "fielddata": false,
          "norms": true,
          "index": true,
          "store": false,
          "type": "text",
          "index_options": "positions"
        },
        "version": {
          "eager_global_ordinals": false,
          "index_phrases": false,
          "fielddata": false,
          "norms": true,
          "index": true,
          "store": false,
          "type": "text",
          "index_options": "positions"
        }
      }
    },
    "exec": {
      "type": "object",
      "properties": {
        "stdout": {
          "eager_global_ordinals": false,
          "index_phrases": false,
          "fielddata": false,
          "norms": true,
          "index": true,
          "store": false,
          "type": "text",
          "index_options": "positions"
        },
        "exitCode": {
          "coerce": true,
          "index": true,
          "ignore_malformed": false,
          "store": false,
          "type": "long",
          "doc_values": true
        },
        "stderr": {
          "type": "keyword"
        },
        "command": {
          "eager_global_ordinals": false,
          "index_phrases": false,
          "fielddata": false,
          "norms": true,
          "index": true,
          "store": false,
          "type": "text",
          "index_options": "positions"
        }
      }
    },
    "tags": {
      "type": "keyword"
    }
  }
}
  },
  "index_patterns": [
"execbeat-*"
  ],
  "composed_of": []
}

Создаём скрипт в той же директории getLicenseInfo.bat
```
powershell.exe .\getLicenseInfo.ps1
```
Добавляем этот скрипт в планировщик, редактируя файл execbeat.yml.

execbeat:

  commands:

    -
      schedule: "@every 5m"
      command: .\getLicenseInfo.bat
    -
      schedule: "@every 5m"
      command: .\GetVeeamBackups.bat

5.Прописываем куда отправлять вывод, всё в том же файле

output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["elknode2:9000","elknode1:9000"]

  # Optional protocol and basic auth credentials.
  loadbalance: true
  protocol: "https"
  username: "execbeat"
  password: "5YQ2cN"

Запуск

Теперь осталось только запустить сам Execbeat.

sudo execbeat.sh -e

.\execbeat.exe -c .\execbeat.yml -e -d "*"

Итог

На данный момент автор еще не добавил поддержку Elasticsearch версии 7.x, что собственно наталкивает на мысли о необходимости его использования. Вполне возможно, что лучше будет выводить ответы в текстовый файл и уже его отправлять в Elasticsearch с помощью Filebeat. По крайней мере тут точно будет работать с Logstash, у меня данные через Logstash не приходили с Execbeat.

Как поставить Корневой сертификат Единого шлюза доступа к Интернету

Tue, 12 Jul 2022 06:20:39 +0600

Поступил вопрос от пользователя как поставить сертификат ЕШДИ c расширением .cer в доверенные корневые сертификаты? Если кто не знает, то это супер сертификат (Корневой сертификат Единого шлюза доступа к Интернету), который стоит посередине между вами и интернетом в сети государственных органов Казахстана. Писать о том плохо это или хорошо не буду, я думаю понятно почему.

Так вот мне казалось, что ответ будет довольно простым и в стиле вот ссылочка на оф сайт, где собственно всё расписано. А не тут-то было, ссылка, то есть, только вот инструкция только для Windows. Ох как же это знакомо, мы что-то сделаем, а вся последующая головная боль это уже проблемы пользователя.

Ну и раз не смогли это сделать специалисты ГТС то распишу я, может кому-то пригодится.

Windows

Собственно, вот сама инструкция от них.

Но если вам вдруг не подошла их инструкция то вот моя.

Обычный метод

Скачиваем сертификат с сайта https://sts.kz/eshdi/
Открываем сертификат и нажимаем установить
Выбираем расположение (если нужно для сервисов, то лучше ставить на компьютер)
Нажимаем несколько раз далее и готово

Скрипт

Я тут написал скрипт, который поставит либо удалит сертификат за вас. Итак, что он умеет:

Скачивает сертификат с сайта (url может меняться, проверьте правильность на самом сайте sts.kz)
В зависимости от того что вы выбрали ставит либо удаляет сертификат

При запуске скрипта через Powershell будет запрос, где каждая цифра означает:

Ставит сертификат только для текущего пользователя
Удаляет сертификат у текущего пользователя
Ставит сертификат только для компьютера и стало быть для всех пользователей, программ, сервисов и т.д.
Удаляет сертификат с компьютера
Удаляет сертификат с компьютера и у пользователя

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

RHEL

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

Обычный метод

Скачиваем сертификат

sudo yum -y install wget
sudo wget https://sts.kz/wp-content/uploads/2021/05/Unified_State_Internet_Access_Gateway.cer -O /etc/pki/ca-trust/source/anchors/Unified_State_Internet_Access_Gateway.crt

Обновляем список доверенных корневых сертификатов
```
sudo update-ca-trust
```
Если хочется удостоверится что сертификат стоит, то можно выполнить команду
```
trust list | grep "Unified State Internet Access Gateway"
```
```
 label: Unified State Internet Access Gateway
```

Скрипт

Также написал скрипт, который я проверял на CentOS и Ubuntu. Суть та же, либо добавляет, либо удаляет сертификат. Как им пользоваться написано в описании проекта на github.

Ubuntu

Обычный метод

Скачиваем сертификат

sudo apt -y install wget
sudo wget --output-document /usr/local/share/ca-certificates/Unified_State_Internet_Access_Gateway.crt https://sts.kz/wp-content/uploads/2021/05/Unified_State_Internet_Access_Gateway.cer

Обновляем список доверенных корневых сертификатов
```
sudo update-ca-certificates
```
Если хочется удостоверится что сертификат стоит, то можно выполнить команду
```
trust list | grep "Unified State Internet Access Gateway"
```
```
 label: Unified State Internet Access Gateway
```

Скрипт

Замечание

Многие сервисы не работают с сертификатами установленными в системе и для таких сервисов придётся искать мануалы как и куда добавлять сертификат. Работает данный метод или нет можно просто выполнив команду curl на сайт, на котором подменяется сертификат.

Linux - Установка шрифтов Microsoft (Times New Roman)

Mon, 04 Jul 2022 06:20:39 +0600

В зависимости от условий иногда бывает необходимым наличие шрифтов, которые есть в Microsoft, например, Times New Roman. Причин для этого может быть куча, в моём случае все оригинальные документы должны быть с этим шрифтом и создаёт их приложение.

Установка Times New Roman в Ubuntu

В Debian системах на самом деле всё просто, уже имеется пакет, который достаточно просто поставить.

sudo apt-get update
sudo apt-get install msttcorefonts

Установка Times New Roman в RHEL (CentOS)

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

Для начала нам придётся собрать rpm пакет, не переживайте сильно всё довольно просто. Я обычно делаю такие дела на отдельной виртуалке, разумеется также ОС что и на серверах.

Ставим необходимые пакеты:

sudo yum -y install rpm-build ttmkfdir cabextract

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

wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
sudo rpmbuild -bb msttcorefonts-2.5-1.spec

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

Если вы всё сделали правильно, то в директории $HOME/rpmbuild/RPMS/noarch/ вы найдёте rpm пакет. Собственно, осталось лишь поставить его там, где это необходимо.

sudo yum install /root/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm

Может еще потребуется перезапустить сервис xfs, но у меня и так сработало.

fc-list | grep Time

/usr/share/fonts/msttcorefonts/timesi.ttf: Times New Roman:style=Italic,cursiva,kurzíva,kursiv,Πλάγια,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,kursywa,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana
/usr/share/fonts/msttcorefonts/times.ttf: Times New Roman:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,thường,Arrunta
/usr/share/fonts/msttcorefonts/timesbd.ttf: Times New Roman:style=Bold,Negreta,tučné,fed,Fett,Έντονα,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Pogrubiona,Negrito,Полужирный,Fet,Kalın,Krepko,đậm,Lodia
/usr/share/fonts/msttcorefonts/timesbi.ttf: Times New Roman:style=Bold Italic,Negreta cursiva,tučné kurzíva,fed kursiv,Fett Kursiv,Έντονα Πλάγια,Negrita Cursiva,Lihavoitu Kursivoi,Gras Italique,Félkövér dőlt,Grassetto Corsivo,Vet Cursief,Halvfet Kursiv,Pogrubiona kursywa,Negrito Itálico,Полужирный Курсив,Tučná kurzíva,Fet Kursiv,Kalın İtalik,Krepko poševno,nghiêng đậm,Lodi etzana

Небольшой обзор AWS

Mon, 04 Jul 2022 06:20:39 +0600

AWS (Amazon Web Services) - это, наверное, на данный момент самая распространенная облачная система, которая располагает большим функционалом. Содержит более 200 сервисов, понятное дело, что все их рассматривать я не буду.

ЕС2 — Elastic Compute Cloud

Это, наверное, самый основной интерфейс для управления виртуальными серверами, которые в Amazon называются Amazon EC2 Instance. Также позволяет создавать свои образы, при этом имеет кучу образов по умолчанию. Присутствует возможность создания резервных копий.

Благодаря Security Groups вы можете ограничить список ip адресов с которых можно получить доступ к управлению.

Также вы можете тут создавать балансировщики нагрузки, которые распространяют нагрузку между EC2 Instance.

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

Благодаря Availability Zone (AZ) вы можете сами решать в каком регионе и какой страны размещать ваши виртуальные сервера (EC2 Instance). В зависимости от страны может меняться ping.

S3 — Amazon Simple Storage

Сервис для хранения данных, этакий web storage. На данный момент уже есть куча бесплатных версий S3 хранилищ, один из основных minio.

Оплачивается S3 за объем данных, исходящий трафик и по количеству запросов.

RDS — Amazon Relational Database Service

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

Преимущество на вскидку по сравнению с физическими серверами, что тут вам будет проще обновлять тот же MS SQL Server (не надо просить бюджет на лицензии).

Route 53

Это сервис для создания своего собственно домена, и управления записями в этом домене. Вы можете поднять dns сервера только для внутреннего использования в ЕС2.

CloudWatch

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

IAM — Identity and Access Management

Сервис для разграничения доступа ко всем сервисам AWS. Т.е. определённым сотрудникам вы можете дать доступ только на чтение, а другим полные права на управление.

В итоге

Рассмотрим плюсы и минусы AWS.

Плюсы	Минусы
Большая функциональность, под каждую задачу есть свой сервис.	Нет ЦОД на территории РФ и КЗ.
Есть бесплатные тарифы для многих сервисов.	Платить нужно буквально за всё подряд.
Отличная и подробная документация, большое количество курсов.	Высокая сложность в использовании.
Очень популярна, большое количество интеграций.	Перегруженный интерфейс.
Высокая надежность.

В итоге можно сказать что самый главный минус в том, что он дорогой, и не все организации могут себе позволить размещать свои сервера в другой стране.

Vcenter - Обновление версии 6.7 до 7

Mon, 27 Jun 2022 06:20:39 +0600

Для начала скачивает официальный дистрибутив с сайта. После скачивания монтируем полученный iso на свой компьютер (важно чтобы у вас был сетевой доступ к хосту).

Обновление Vcenter Server Appliance

Запускаем installer.exe, который находится по пути vcsa-ui-installer\win32
В появившемся окне выбираем Upgrade
Соглашаемся со всеми условиями и жмём NEXT
Тут указываем доступ к Vcenter, который мы хотим обновить (ip-адрес или доменное имя) и нажимаем Connect
Дальше заполняем поля для подключения к существующему Vcenter и к ESXI, на котором он запущен
Если всё указали правильно и подключение удалось, то дальше задаём доступ к ESXI хосту на котором будет новый Vcenter
Выбираем конфигурацию для нового Vcenter
Выбираем datastore, на котором будут хранится файлы
Задаём временный ip-адрес, после обновления мы будем использовать прежний ip-адрес и доменное имя
В последнем окне проверяем всю конфигурацию и жмём FINISH
После завершения первого этапа переходим ко второму нажав CONTINUE
Дважды нажимаем NEXT, после чего попадаем на вкладку с проверкой перед самим обновлением
Обязательно читаем все предупреждения если они есть и уже в зависимости от их серьёзности принимаем решение о обновлении
Выбираем какие данные мы хотим перенести на новый Vcenter
Проверяем все настройки и жмём FINISH. Важно замечание на время обновления ваш старый Vcenter будет не доступен

Может также случиться так что мастер установки скажет, что всё выполнено, но вы не сможете зайти на Vcenter по старому имени. Решением может оказаться зайти на новый ip-адрес Vcenter по порту 5480 и увидеть, что всё-таки обновление еще продолжается (https://new_ip_here:5480).

Standalone MinIO на Linux

Fri, 24 Jun 2022 06:20:39 +0600

Рассмотрим установку MinIO на сервере в режиме Standalone. Важное замечание что в production средах рекомендуется устанавливать MinIO в режиме Distributed Mode.

Требования

Для того чтобы продолжить установку убедитесь в следующем:

Ваш пользователь от которого вы будете запускать MinIO должен иметь полные права на каталог, в который будет сохранять файлы MinIO (~/minio)

sudo chown minio ~/minio

У вас должны быть права для создания файлов в директории /usr/local/bin. Туда помещается исполняемые файлы MinIO
64-разрядная ОС

Приступаем

1. Установка сервера MinIO

Для установки сервера MinIO можно воспользоваться 3 методами:

Установка с использованием RPM (RHEL)

wget https://dl.min.io/server/minio/release/linux-amd64/minio-20220523184511.0.0.x86_64.rpm -O minio.rpm
sudo dnf install minio.rpm -y

Установка с использованием DEB(UBUNTU)

wget https://dl.min.io/server/minio/release/linux-amd64/minio_20220519182059.0.0_amd64.deb -O minio.deb
sudo dpkg -i minio.deb

Скачать бинарный файл

wget  https://dl.min.io/server/minio/release/linux-amd64/minio
sudo mv minio /usr/local/bin/
sudo chmod +x /usr/local/bin/minio

2. Запуск сервера MinIO

Как уже упоминалось выше в качестве data директории будем использовать ~/minio, вы же всегда можете использовать другую директорию.

mkdir ~/minio
minio server ~/minio --console-address :9090

В итоге должны получить информацию о том, как подключиться к нашему серверу MinIO (ip-адрес, порт, логин, пароль).

Используя --console-address :9090 мы говорим, что console будет слушать порт 9090. Сonsole - это по сути своей web интерфейс.

3. Настроим файрволл

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

sudo firewall-cmd --add-port=9090/tcp --permanent
sudo firewall-cmd --reload

4. Подключаемся к консоли

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

В итоге получаем такую картину, где вбиваем логин и пароль (по умолчанию minioadmin minioadmin).

Используя консоль вы можете создавать пользователей, права доступа, бакеты и т.д. Правда не всё можно сделать через консоль, поэтому необходимо также и установить MinIO Client.

5. Установка MinIO Client

Используя MinIO Client, вы получаете возможность управления сервером MinIO в командной строке.

wget https://dl.min.io/client/mc/release/linux-amd64/mc
sudo mv mc /usr/local/bin/mc
sudo chmod +x /usr/local/bin/mc

6. Создаём alias для сервера MinIO

Для того чтобы управлять сервером используя MinIO Client нужно задать серверу alias дабы не писать каждый раз адрес сервера и его логин и пароль. Если вы делаете это локально, т.е. на том же сервере где стоит сервер MinIO можно в качестве ip-адреса использовать 127.0.0.1. Но тут в отличии от консоли необходимо указывать API порт, который по умолчанию 9000.

mc alias set local http://127.0.0.1:9000 minioadmin minioadmin

Added `local` successfully.

mc admin info local

●  127.0.0.1:9000
Uptime: 19 minutes
Version: 2022-05-19T18:20:59Z

Команда mc admin info local выводит нам всю информацию о нодах MinIO.

Logstash - Keystore

Mon, 20 Jun 2022 06:00:39 +0600

С помощью Keystore мы можем безопасно использовать пароли в файлах конфигураций ELK. Если просто, то мы создаём хранилище ключей, к которому будут иметь доступ только приложения ELK.

Для начала находим где именно лежит бинарный файл logstash-keystore, именно его мы будем использовать для создания keystore.

sudo find / -name logstash-keystore

/usr/share/logstash/bin/logstash-keystore

Создание keystore

Для создания keystore используем наш бинарный файл добавляя значение create.

cd /usr/share/logstash/bin/
./logstash-keystore create

Команда создания выведет сообщение что мы должны установить LOGSTASH_KEYSTORE_PASS, сообщение выглядит так: Please set the environment variable LOGSTASH_KEYSTORE_PASS. Т.е. требуется, чтобы пользователь, запускающий Logstash, определил переменную среды LOGSTASH_KEYSTORE_PASS.

Собственно, остаётся только так и cделать раз это настройка от самого ELK. Добавляем LOGSTASH_KEYSTORE_PASS в env и он в итоге окажется в файле /usr/share/logstash/config/logstash.keystore. Удостоверьтесь что у пользователя есть права на запись в эту директорию.

Если у вас logstash запущен как сервис, то необходимо также добавить эту переменную в сам сервис, используя сам файл описания сервиса (/etc/systemd/system/logstash.service) либо же добавить в файл /etc/default/logstash.

Добавляем переменную

Если вы хоть немного знакомы с иб, то уже должны понимать, что записывать пароли в историю команд не стоит поэтому перед выполнением export отключаем запись команд в bash history.

sudo set  +o history
export LOGSTASH_KEYSTORE_PASS=mypassword
sudo set  -o history

И снова запускаем logstash-keystore create.

/usr/share/logstash/bin/logstash-keystore create --path.settings /etc/logstash

Created Logstash keystore at /etc/logstash/logstash.keystore

Добавление ключей в keystore

И осталось дело за малым а собственно осталось только добавить ключи в keystore, используя команду ./logstash-keystore add.

./logstash-keystore add USR --path.settings /etc/logstash/
./logstash-keystore add PASS --path.settings /etc/logstash/

Просмотр ключей в keystore

Для того чтобы просмотреть что там лежит в нашем keystore используем ./logstash-keystore list.

./logstash-keystore list --path.settings /etc/logstash/

usr
pass

Удаление ключей из keystore

./logstash-keystore remove USR --path.settings /etc/logstash/
./logstash-keystore remove PASS --path.settings /etc/logstash/

Использование ключей

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

elasticsearch {
        user => "${usr}"
        password => "${pass}"
      }

Filebeat / Metricbeat - 169.254.169.254

Sat, 21 May 2022 06:00:39 +0600

В логах Filebeat или же просто мониторя исходящий трафик на сервере вы можете обнаружить что ваш Filebeat постоянно обращается к ip-адресу 169.254.169.254.

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

Вот пример тех данных что он пытается отправлять:

{
  "cloud": {
    "account.id": "123456789012",
    "availability_zone": "us-east-1c",
    "instance.id": "i-4e123456",
    "machine.type": "t2.medium",
    "image.id": "ami-abcd1234",
    "provider": "aws",
    "region": "us-east-1"
  }
}

Отключение

Для того чтобы отключить это просто удаляем add_cloud_metadata из processors в файле конфигурации.

sudo vim /etc/filebeat/filebeat.yml

processors:
  - add_host_metadata:
      when.not.contains.tags: forwarded
  - add_docker_metadata: ~
  - add_kubernetes_metadata: ~
  - add_cloud_metadata: ~  <------ DELETE IT

sudo systemctl restart filebeat

Filebeat - Дублирование логов

Sat, 21 May 2022 06:00:39 +0600

Может так произойти что при использовании связки Filebeat + Elasticsearch вы в итоге получите дублирование логов. А заметить это можно далеко не сразу, так как это происходит только после перезапуска Filebeat. Т.е. для примера вы мониторите файл /var/log/messages и вроде бы всё нормально вам приходят события (документы) в Elasticsearch, но вот вы решаете по какой-то причине перезапустить Filebeat и в ужасе осознаёте, что все те события, которые были отправлены в Elasticsearch ранее отправляются снова и в итоге вы получаете дублирование.

Файл registry

Для того чтобы понимать какие события Filebeat уже отправил в Elasticsearch используется файл под названием registry, в котором хранится информации о отправке событий. Т.е. если события с файла /var/log/messages были успешно доставлены в Elasticsearch в файл registry помещается информация обозначающая это. Когда вы перезапускаете сервис Filebeat он как раз обращается к этому файлу для того чтобы понять отправлялись ли события с файла ранее.

Если вам вдруг нужно заново отправить все события из файла в Elasticsearch в теории вы просто можете удалить registry и перезапустить Filebeat. Но на практике я это не проверял.

Вариант 1: Нет прав на запись

Естественно первым делом стоит обратиться к логам самого Filebeat и если вы там найдёте запись вида Writing of registry returned error: open /data/registry.new: permission denied. то значит нужно дать пользователю от которого запущен Filebeat доступ к папке где лежит registry.

Одним из возможных решений будет изменить владельца директории и файлов на пользователя, от которого запущен Filebeat.

sudo chown -R filebeat path_to_registry

sudo systemctl restart filebeat

Вариант 2: Несколько filestream без id

При таком случае в логах вы найдёте сообщение filestream input ID without ID might lead to data duplication, please add an ID and restart Filebeat. И как понятно из самого сообщения если мы используем несколько filestream, то необходимо каждому задать id.

sudo vim /etc/filebeat/filebeat.yml

filebeat.inputs:

- type: filestream
  id: "bash"
  enabled: true
  paths:
    - /home/*/.bash_history

- type: filestream
  id: "oom"
  enabled: true
  paths:
    - /var/log/messages

sudo systemctl restart filebeat

Backup - Почему восстановление дольше самого бэкапа

Fri, 29 Apr 2022 06:00:39 +0600

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

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

Запись в файловую систему

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

Скорость записи в RAID

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

Для примера RAID 5, RAID 6 имеют самые маленькие показатели записи на диск по сравнению с другими, при том что RAID 0 самый большой. Да, многие могут возразить что в наше время уже никто не использует RAID 5, так как давно уже есть RAID 50 и т.д. но никто не отменял уже действующие системы хранения с RAID 5 и отсутствием бюджета для изменения этой ситуации.

В интернете много статей на тему сравнения скорости RAID групп можете почитать про это.

Copy-on-write snapshot

Следующей проблемой может служить использование технологии Copy-on-write snapshot. Называется это Copy-on-write потому что перед тем как записать что-то новое на диск все блоки копируются перед тем как пере-записаться. Зачастую такими методами пользуются владельцы NAS систем.

Т.е. если я хочу изменить файл, то система скопирует все блоки, которые занимает данный файл в промежуточный snapshot и только потом произведёт запись в эти блоки. В итоге такая простая манипуляция займёт ажно три операции ввода/вывода: одна операция чтения и две операции записи. Три операции потому что перед изменением блока нужно сперва его прочесть, а затем записать существующий блок в новое место и уже потом записать в этот блок новую информацию.

Если вы изменили файл, который был в snapshot то система сама поймёт в каком именно snapshot его искать. Т.е. система также тратит много времени на то чтобы понять в каком snapshot находится файл к которому вы обращаетесь (их может быть куча). Соответственно, чем больше у вас snapshot-ов тем меньше у вас производительность.

Логи транзакций

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

Ленточные накопители

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

Да, и ещё один весомый аргумент — это то что приводы такой библиотеки могут выполнять только одно действие чтения или записи. Т.е. если привод сейчас записывает данные, то он не может использоваться для чтения. Но обычно приводов несколько, так что жить можно.

Docker - unknown flag iidfile

Thu, 21 Apr 2022 06:00:39 +0600

При запуске какого-либо проекта с использованием docker-compose можно наткнутся на ошибку unknown flag: –iidfile. Сразу скажу, что решение этой проблемы в моём случае было радикальным.

Решение unknown flag: –iidfile

Скорее всего вы установили старую версию docker, да именно docker а не docker-compose. Например, если вы ставите на CentOS7 из репозитория по умолчанию.

Чтобы решить эту проблему нужно сперва удалить docker. Обратите внимание что при удалении остановятся все ваши запущенные контейнеры.

CentOS

Удаляем установленный docker

sudo yum remove docker \
                docker-client \
                docker-client-latest \
                docker-common \
                docker-latest \
                docker-latest-logrotate \
                docker-logrotate \
                docker-engine

Добавляем репозиторий

sudo yum install -y yum-utils
sudo yum-config-manager \
  --add-repo \
  https://download.docker.com/linux/centos/docker-ce.repo

Ставим docker-ce

sudo yum install docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker
sudo systemctl start docker

Ubuntu

Удаляем установленный docker

sudo apt-get remove docker docker-engine docker.io containerd runc

Добавляем репозиторий

sudo apt-get update
sudo apt-get install ca-certificates curl gnupg lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Ставим docker-ce

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

Вы всегда можете найти инструкцию по установке docker-ce на той или иной ОС на сайте docker.com.

Veeam - Failed to load module [veeamsnap] with parameters [zerosnapdata=1 debuglogging=0]

Thu, 14 Apr 2022 06:00:39 +0600

После установки Veeam Agent for Linux решил сделать локальный бэкап с помощью агента и наткнулся на ошибку Veeam - Failed to load module [veeamsnap] with parameters [zerosnapdata=1 debuglogging=0].

Решение №1

Первым на что стоит посмотреть это проверить установлены ли библиотеки модуля veeamsnap. Если вы ставили veeam из репозитория, то скорее всего у вас установился пакет veeamsnap. Например, проверить это можно командой sudo yum list veeamsnap.

Теперь проверим собственно наличие библиотек выполнив команду:

 sudo find /lib/modules | grep veeamsnap

Если команда выше ничего не вывела, то выходит библиотек у вас в системе от veemsnap нету. И вот почему это может произойти. Если перейти по ссылке то видно что рекомендуется для RHEL устанавливать 2 пакета: veeam и kmod-veeamsnap, хотя при установке пакета veeam автоматом ставится пакет veeamsnap.

Для начала удалим пакет veeamsnap, если он стоит конечно же.

 sudo rpm -e --nodeps veeamsnap

И потом поставим руками пакет kmod-veeamsnap. Если у вас проблемы с тем что пакет не найден можете прочитать статью по установке Veeam Agent for Linux.

sudo yum -y install kmod-veeamsnap

Снова выполняем проверку наличия библиотек.

sudo find /lib/modules | grep veeamsnap

/lib/modules/3.10.0-327.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-1062.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-1127.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-1160.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-123.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-229.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-514.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-693.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-862.el7.x86_64/extra/veeamsnap.ko
/lib/modules/3.10.0-957.el7.x86_64/extra/veeamsnap.ko

Решение №2

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

Veeam - Бэкап PostgreSql

Tue, 12 Apr 2022 06:20:39 +0600

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

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

Так вот для того чтобы делать бэкап PostgreSql нужно будет установить на сервере с PostgreSql - Veeam Agent for Linux. Об этом у меня есть отдельная статья.

Добавляем задачу в Veeam Backup and Replication

После того как вы установили Veeam Agent for Linux можно приступать к созданию задачи. Для этого:

Переходим в Jobs > Backup и добавляем новую задачу
Добавляем сервер с PostgreSql
Ставим галочку напротив Enable application-aware processing и настраиваем бэкап PostgreSql, а именно добавляем пользователя для подключения к PostgreSql.
Дальше выставляем время запуска и завершаем мастер создания задачи

Восстановление

UPDATE: В этом году планируется выпуск новой версии Veeam Backup and Replication, а именно v12 где собственно поработали как раз над бэкапом PostgreSQL. В итоге в новой версии уже не нужен будет никакой Veeam Agent и появиться Veeam Explorer for PostgreSQL, благодаря которому можно будет восстановить полностью инстанс или отдельную БД. Как только появится возможность проверить я это использую и обновлю статью.

И вот мы дошли до восстановления, которое обычно никто не проверяет, главное, что бэкап есть. Так вот как привык восстанавливать обычный администратор бд ему всегда нужна возможность восстановить отдельные бд или даже отдельные таблицы. Часто еще восстановить нужно уже на имеющемся кластере PostgreSql.

Так вот в Veeam так сделать не получиться, суть в том, что хоть Veeam и создаёт checkpoint в PostgreSql при бэкапе он всё еще использует систему snapshot, т.е. он просто также бэкапит всю виртуальную машину, а точнее диски. И в таком случае для восстановления вам придётся либо восстановить полностью виртуальную машину, либо только тот диск, на котором у вас была бд, при этом если там их куча, то восстановятся тоже все, а не только одна нужная. Считаю, что это очень большой недостаток.

Восстановление в целом ничем не отличается от того же восстановления виртуальной машины и описывать всё в подробностях я не вижу особого смысла.

Вариант на просторах интернета

Изучая тему, я нашел решение, в котором человек делал бэкап используя Scripts. Т.е. перед началом бэкапа он выполнял скрипт, который делал бэкап используя встроенную утилиту в PostgreSql и потом уже делал бэкап дисков. Весь механизм описан в этой статье и использовал он pg_dumpall, хотя в сети много тем о том, что dump это не бэкап.

По моему мнению такая схема имеет место быть если вы хотите делать бэкап всего через Veeam и не хотите ломать голову над другими решениями. Но я бы немного исправил его подход, а именно:

Использовал бы другую утилиту для бэкапа, например, pgbackrest
С помощью veeam делал бы бэкап только диска куда делал бэкап с помощью утилиты pgbackrest
Каким-то образом удалял бэкап с хоста после проверки

Чем хорош такой подход

Немного размышлений на тему почему может быть выгоден такой подход:

Вы всё также можете делать выборочный бэкап
Вы можете вести статистику бэкапов (провален или выполнен), но это если у вас нет никакого мониторинга
У вас все бэкапы в одном месте

Veeam - Установка Veeam Agent for Linux

Tue, 12 Apr 2022 06:00:39 +0600

Используя Veeam Agent for Linux вы можете делать backup приложений на хосте, например добавляется возможность делать backup PostgreSql.

Есть 2 способа установки агента:

Вручную
С помощью консоли Veeam Backup and Replication

Firewall

Не забудьте настроить правила на файерволе открыв порты от клиента к серверу и обратно. Список портов можно поссмотреть на офсайте.

Вручную

Для начала рассмотрим способ установки вручную хотя я всё же рекомендую использовать метод с консолью.

Все пакеты приложения Veaam находятся на сайте http://repository.veeam.com/.

Добавим репозиторий, в моём случае для CentOS

sudo vim /etc/yum.repos.d/veeam.repo

[veeam]
baseurl=http://repository.veeam.com/backup/linux/agent/rpm/el/7/x86_64/
gpgcheck=0
enabled=1
gpgkey=http://repository.veeam.com/keys/veeam.gpg

Ставим агент Veeam и добавим текущего пользователя в группу veeam. После добавления нужно перезайти в систему.
```
sudo yum install -y veeam
sudo rpm -e --nodeps veeamsnap
sudo yum -y install kmod-veeamsnap
sudo usermod -a -G veeam admin
```
Если непонятно зачем я удаляю пакет veeamsnap то можно почитать статью.
Запускаем агент
```
veeam
```
Используя пробел ставим галочку напротив соглашений.
Используя tab переходим на кнопку next и жмём ENTER.
Создание образа восстановления можно пропустить. Суть в том, что создаётся загрузочный iso образ вашего сервера, куда входят файлы ОС. Если хотите всё же создать, то потребуется наличие wget в системе. Необходимо будет установить пакеты squashfs-tools, xorriso и genisoimage.
```
sudo yum -y install squashfs-tools genisoimage xorriso
```
Далее необходимо предоставить ваш лицензионный ключ.
Но если у вас нет ключа, то просто нажимаем FINISH.

С помощью консоли Veeam Backup and Replication

Переходим в консоли в Inventory > Physical Infrastructure
Создаём Protection group, где Type устанавливаем в Individual computers
В computers добавляем ip-адресс или доменное имя компьютера
Далее завершаем мастер установки после которого начнётся установка агента

Сам Veeam Agent for Linux также требует лицензирования, но если у вас Veeam Backup and Replication с лицензией, то можно использовать и его лицензию.

Для этого переходим в License > Instances и ставим галочку Allow unlicensed agents to consume instances. После этого возможно понадобиться перезапустить сервис veeam на клиенте.

Также необходимо привязать лицензию к клиенту используя кнопку Manage по тому же пути License > Instances.

В итоге после всего проделанного в созданной группе вы должны увидеть свой компьютер или сервер.

Зависимости

Для того чтобы установить последнюю версию Veeam Agent for Linux понадобиться наличие python версии 3.0 или выше на клиентском устройстве.

В случае с CentOS7 можно установить следующим образом:

Добавим репозиторий ius

sudo vim /etc/yum.repos.d/ius.repo

[ius]
name = IUS for Enterprise Linux 7 - $basearch
baseurl = https://repo.ius.io/7/$basearch/
enabled = 1
repo_gpgcheck = 0
gpgcheck = 1
gpgkey = https://repo.ius.io/RPM-GPG-KEY-IUS-7

Ставим python

sudo yum install -y python36 python36-devel python36-pip

Powershell - Операторы сравнения

Thu, 07 Apr 2022 06:20:39 +0600

Как и в любом языке программирования в PowerShell также присутствуют операторы сравнения, при чём не в обычном для людей виде знаков <, >, =.

Вместо знаков в PowerShell используются буквы, которые обозначают сами слова сравнения, например -gt означает Greater than (Больше).

Таблица операторов сравнения

Оператор	Значение	Описание
-le	Less than or equal	Меньше или равно
-lt	Less than	Меньше чем
-ge	Greater than or equal	Больше или равно
-gt	Greater than	Больше чем
-ne	Not equal	Не равно
-eq	Equal	Равно
-like	Wildcard comparison	Поиск по шаблону
-notlike	Wildcard comparison	Поиск по несоответствию шаблонов
-match	Regular expression comparison	Поиск соответствия по регулярным выражениям
-notmatch	Regular expression comparison	Поиск несоответствия по регулярным выражениям
-in	Containment operator	Поиск по коллекции
-notin	Containment operator	Поиск по коллекции (не содержит)
-replace	Replace operator	Заменяет часть или всё значение
-is	Type	Возвращает *true* если объекты одинаковы
-isnot	Type	Возвращает true если объекты неодинаковы

le

Этот оператор означает меньше или равно и эквивалентен <=.

5 -le 8
5 -le 5

True
True

lt

Этот оператор означает меньше и эквивалентен <.

5 -le 8

True

ge

Этот оператор означает больше или равно и эквивалентен >=.

5 -ge 8
10 -ge 8
10 -ge 10

False
True
True

gt

Этот оператор означает больше и эквивалентен >.

5 -gt 8
12 -gt 8

False
True

ne

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

2 -ne  2
"abc" -ne  "def"
"abc" -ne  "abc"

False
True
False

eq

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

2 -eq  2
"abc" -eq  "def"
"abc" -eq  "abc"

True
False
True

like

Этот оператор сопоставления и ведёт себя аналогично оператору -eq но работает только со словами и также может принимать регулярные выражения.

"my home here" -like "home"
"my home here" -like "*home*"

False
True

notlike

Этот оператор сопоставления и ведёт себя аналогично оператору -ne но работает только со словами и также может принимать регулярные выражения.

"my home here" -notlike "*home*"
"my home here" -notlike "*abc*"

False
True

match

Этот оператор сопоставления и ведёт себя аналогично оператору -like только с отличием того что он не обращает внимание на место символа поиска в строке.

Также при использовании -notmatch и -match создаётся автоматически переменная $Matches, к которой вы можете получить доступ.

"my home here" -like "home"
"my home here" -like "*home*"
"my home here" -match "home"
"my home here" -match "h[qoea]me"

False
True
True
True

Используя -match вы также можете разбивать какую-либо строку на переменные присваивая им значения слов из этого предложения используя регулярные выражения.

"I saw Helen yestrday" -match '.*\s(?<name>\w+)\s(?<date>\w+)'
$Matches

Name                           Value
----                           -----
date                           yestrday
name                           Helen
0                              I saw Helen yestrday

notmatch

Этот оператор сопоставления и ведёт себя аналогично оператору -notlike только с отличием того что он не обращает внимание на место символа поиска в строке.

"my home here" -notlike "*home*"
"my home here" -notlike "*abc*"
"my home here" -notmatch "home"
"my home here" -notmatch "h[aedb]me"

False
True
False
True

in and notin

Этот оператор себя как оператор -like только здесь вы можете для сравнения передать сразу коллекцию для сопоставления. Т.е. вместо того чтобы сопоставлять по одному значению вы делаете множественное сопоставление.

"avb" -in  "avb", "def"
"avb" -in  "asd", "def", "dasd", "derwerf", "grtg"

True
False

"avb" -notin  "avb", "def"
"avb" -notin  "asd", "def", "dasd", "derwerf", "grtg"

False
True

replace

Как уже понятно из названия этот оператор служит для замены значения. Например, вы можете переименовывать названия всех документов в папке используя регулярные выражения.

Пример с изменением расширения всех log файлов в текущей директории.

Get-ChildItem *.log | Rename-Item -NewName { $_.name -replace  '\.log$','.txt' }

Если вам важна чувствительность к регистру можно воспользоваться оператором -creplace.

"my home here" -replace "home", "****"
"my home here" -replace "\s(\w+)\s", " **** "
"my home here" -replace "HOME", "****"
"my home here" -creplace "HOME", "****"

my **** here
my **** here
my **** here
my home here

is and isnot

Операторы сравнения типов (-is и -isnot) используются для определения того, относится ли объект к определенному типу. Возвращает Boolean значение: true или false.

"abs" -is [int]
"abs" -isnot [int]
123 -is [int]
123 -isnot [int]
"abs" -is [string]

False
True
True
False
True

Ansible - Используем тэги (tags)

Wed, 06 Apr 2022 06:20:39 +0600

Иногда бывает полезным использование тэгов в большом playbook. Тэги необходимы для того чтобы выполнить именно определённые tasks из всего playbook.

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

Допустим у вас playbook из 20 - 30 задач (tasks) и вам нужно выполнить только 2 - 3 задачи, например, просто перезапустить сервис или установить какие-то пакеты. В таком случае вы назначаете этим задачам определённый тэг и запускаете его.
Ещё один пример это сделать один playbook в котором можно прописать задачи по управлению всеми сервисами, например, тэг для отключения сервиса PostgreSQL и тэг для его включения. Это позволит вам при необходимости управлять всеми сервисами.

Все файлы в статье вы можете найти в репозитории [github](https://github.com/tipoitkz/ansible-examples).

Как использовать

Для использования тэгов придётся выполнить следующие 2 шага:

Задать задаче (task) тэг
При запуске playbook указать этот тэг

Задать задаче (task) тэг

В качестве примера я буду использовать playbook по управлению сервисами. В playbook 2 задачи по управлению сервисом metricbeat, где один включает сервис и другой выключает. Для демонстрации я просто использую debug, понятное дело, что нужно использовать service. Обратите внимание на tags, их также может быть несколько для одной задачи.

vim tasks.yml

- hosts: localhost

  tasks:

    - name: Stop metricbeat
      debug:
        msg: Stop metricbeat
      tags:
        #тут наш тэг для остановки
        - stop metricbeat

    - name: Start metricbeat
      debug:
        msg: Start metricbeat
      tags:
        #тут наш тэг для запуска
        - start metricbeat

При запуске playbook указать этот тэг

Теперь нам осталось только запустить playbook с определённым тэгом. Для этого используем знакомую команду ansible-playbook и передаем опцию --tags. Опция --tags может принимать несколько значений, например --tags "tag1,tag2,tag3".

Для остановки используем тэг stop metricbeat.

ansible-playbook tasks.yml --tags="stop metricbeat"


TASK [Stop metricbeat] **************************************************************************************************************************
ok: [localhost] => {
    "msg": "Stop metricbeat"
}

Для запуска используем тэг start metricbeat.

ansible-playbook tasks.yml --tags="start metricbeat"


TASK [Start metricbeat] *************************************************************************************************************************
ok: [localhost] => {
    "msg": "Start metricbeat"
}

Какие задачи запустятся?

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

ansible-playbook tasks.yml --tags="start metricbeat" --list-tasks

playbook: tasks.yml

  play #1 (localhost): localhost        TAGS: []
    tasks:
      Start metricbeat  TAGS: [start metricbeat]

Используем роли

Для того чтобы задать тэг роли (role) нужно задавать тэг именно в playbook где вызываются эти роли.

Пример с использованием roles:

vim roles.yml

- hosts: localhost

  roles:

    - role: stop_metricbeat
      tags:
        #тут наш тэг для остановки
        - stop metricbeat

    - role: start_metricbeat
      tags:
        #тут наш тэг для запуска
        - start metricbeat

ansible-playbook roles.yml --tags="start metricbeat"


TASK [start_metricbeat : Start metricbeat] ******************************************************************************************************
ok: [localhost] => {
    "msg": "Start metricbeat"
}

TASK [start_metricbeat : Start service2] ********************************************************************************************************
ok: [localhost] => {
    "msg": "Start service2"
}

Пример с использованием import_role:

vim import_role.yml

- hosts: localhost

  tasks:

    - import_role:
        name: stop_metricbeat
      tags:
        #тут наш тэг для остановки
        - stop metricbeat

    - import_role: 
        name: start_metricbeat
      tags:
        #тут наш тэг для запуска
        - start metricbeat

Наследование тэгов

В Ansible по умолчанию тэги не распространяются на вложенные задачи, т.е. когда мы запускаем задачу в playbook с определённым тэгом то задача эта запускается только потому что задан тэг для самой задачи, а не для роли, например.

Если вам вдруг нужно добавить наследование тэга для можно воспользоваться include_tasks или include_role добавляя apply.

vim include_tasks.yml

- hosts: localhost

  tasks:

    - include_tasks:
        file: roles/start_metricbeat/tasks/main.yml
        apply:
          tags: start metricbeat
      tags:
        #тут наш тэг для остановки
        - start metricbeat

    - include_tasks:
        file: roles/stop_metricbeat/tasks/main.yml
        apply:
          tags: stop metricbeat
      tags:
        #тут наш тэг для запуска
        - stop metricbeat

ansible-playbook include_tasks.yml --tags="stop metricbeat"

TASK [include_tasks] ****************************************************************************************************************************
included: /home/admin/ansible-examples/tags/roles/stop_metricbeat/tasks/main.yml for localhost

TASK [Stop metricbeat] **************************************************************************************************************************
ok: [localhost] => {
    "msg": "Stop metricbeat"
}

TASK [Stop service2] ****************************************************************************************************************************
ok: [localhost] => {
    "msg": "Stop service2"
}

Мы видим, что в итоге у нас остановились оба сервиса хотя, как и в случае с Используем роли, но тут немного другой расклад. Тут выполнились обе задачи в роли потому что мы добавили ко всем задачам в роле stop_metricbeat тэг stop metricbeat, используя apply.

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

vim include_tasks_without_apply.yml

- hosts: localhost

  tasks:

    - include_tasks:
        file: roles/start_metricbeat/tasks/main.yml
      tags:
        #тут наш тэг для остановки
        - start metricbeat

    - include_tasks:
        file: roles/stop_metricbeat/tasks/main.yml
      tags:
        #тут наш тэг для запуска
        - stop metricbeat

ansible-playbook include_tasks_without_apply.yml --tags="stop metricbeat"


TASK [include_tasks] ****************************************************************************************************************************
included: /home/admin/ansible-examples/tags/roles/stop_metricbeat/tasks/main.yml for localhost

TASK [Stop metricbeat] **************************************************************************************************************************
ok: [localhost] => {
    "msg": "Stop metricbeat"
}

Зарезервированные тэги

Ansible предоставляет 2 зарезервированных тэга:

always - задачи с этим тэгом будут выполнятся всегда, в независимости от того какой тэг вы указали при запуске. Убрать это поведение можно используя опцию --skip-tags always.
never - не трудно догадаться что тут обратная история задачи с этим тэгом не будут выполняться только если вы не укажете конкретно --tags never.

vim always.yml

- hosts: localhost

  tasks:

    - name: Stop metricbeat
      debug:
        msg: Stop metricbeat
      tags: [stop metricbeat,always]
        #тут наш тэг для остановки

    - name: Start metricbeat
      debug:
        msg: Start metricbeat
      tags:
        #тут наш тэг для запуска
        - start metricbeat

ansible-playbook always.yml --tags="start metricbeat"

TASK [Stop metricbeat] **************************************************************************************************************************
ok: [localhost] => {
    "msg": "Stop metricbeat"
}

TASK [Start metricbeat] *************************************************************************************************************************
ok: [localhost] => {
    "msg": "Start metricbeat"
}

vim never.yml

- hosts: localhost

  tasks:

    - name: Stop metricbeat
      debug:
        msg: Stop metricbeat
      tags: [never]
        #тут наш тэг для остановки

    - name: Start metricbeat
      debug:
        msg: Start metricbeat
      tags:
        #тут наш тэг для запуска
        - start metricbeat

ansible-playbook never.yml

TASK [Start metricbeat] *************************************************************************************************************************
ok: [localhost] => {
    "msg": "Start metricbeat"
}

Powershell - Архивация логов IIS

Fri, 18 Feb 2022 06:20:39 +0600

Так уж получилось, что логи iis должны лежать на сервере локально, при этом они занимают кучу места на диске. Было решено архивировать их, но после пары месяцев делать это вручную надоело, и я решил написать скрипт.

Функционал

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

(!Ссылка на github)[https://github.com/tipoitkz/scripts-powershell/blob/main/iis/archive-iis-logs.ps1]

(!Ссылка на wiki github)[https://github.com/tipoitkz/scripts-powershell/blob/main/archive-iis-logs.md]

Fold - Делаем текст более читаемым в Linux

Fri, 11 Feb 2022 07:20:39 +0600

Если вы сталкивались в linux с тем что вывод текста файла вылезает за экран и приходится скролить по бокам, или вы просто хотели бы сделать вывод текста немного поуже в ширину то осуществить это вам поможет утилита fold.

Т.е. fold это утилита в linux которая урезает длину строки в выводе, что помогает пользователю в удобочитаемости. Большинство терминалов имеют ширину экрана 80 символов в строке и иногда чтение файлов с длинными строками вызывает не очень хорошие чувства у пользователей.

Использование fold

Для примера создадим файл /tmp/fold.txt и заполним его текстом. Текст можно взять в интернете, используя сервисы генерации рыбы текста.

vim /tmp/fold.txt

Теперь выведем содержимое файла обычной командой cat.

cat /tmp/fold.txt

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

Выведем текст ограничивая длину строки в 50 символов используя команду fold.

fold -c50 /tmp/fold.txt

Linux - Out Of Memory killer

Mon, 24 Jan 2022 06:20:39 +0600

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

Т.е. когда процесс говорит, что нуждается в 2 Гб памяти ОС резервирует за ним эти 2 Гб, но использование памяти происходит по факту. Возможно, что эти 2 Гб памяти будут использоваться только при пиковой нагрузке на процесс, а сейчас по факту он использует 200-300 Мб. Получается, что в итоге за процессом резервируется 2Гб, но используется только 200-300 Мб. Т.е. все 2Гб будут выделены процессу только тогда, когда они ему действительно нужны.

Минус такого подхода в том, что может так сложиться что в определённый момент ОС зарезервирует больше памяти чем у неё есть. И если вся память ОЗУ будет израсходована, то произойдёт сбой системы.

Т.е. в системе с 2 Гб ОЗУ процессам может быть зарезервировано все 3 Гб.

Демонстрация

Для того чтобы продемонстрировать что произойдёт с ОС при полной загрузке ОЗУ просто забьём всё свободное место в директориях /dev/shm и /run. Перед выполнением запустите в другом терминале команду top чтобы мониторить загрузку по ОЗУ.

Внимание не повторяйте эти команды если вам важно время работы ОС.

Для начала отключим swap:

sudo swapoff -a

И теперь используя команду dd забьём всё свободное место:

sudo dd if=/dev/zero of=/run/fill bs=3k count=1024k
sudo dd if=/dev/zero of=/dev/shm/fill bs=3k count=1024k

И когда мы это выполнили загрузка по ОЗУ должна быть 100%.

Теперь попробуем выполнить любую команду.

sudo df -h

-bash: fork: Cannot allocate memory

И всё, у вас нет больше памяти для новых процессов. Более того вы даже не сможете выполнить команду reboot для перезагрузки ОС.

Как выбраться

Для того чтобы отменить предыдущий шаг демонстрации можно перезагрузить ОС на горячую, используя кнопку перезагрузки. И второй способ — это убить какой-нибудь не сильно важный процесс в системе, благо команда kill работает и уже после удалить файлы /dev/shm/fill и /run/fill.

kill -9 1122
rm /dev/shm/fill /run/fill

OOM Killer

Ну и согласитесь терять вот так боевой сервер, тем более если это физический сервер и стоит он где-то в другом городе не хотелось бы только из-за того, что какой-то процесс отъелся ОЗУ. И для того чтобы такого не происходило у нас есть Out Of Memory Killer. Он принудительно завершает один из процессов что в итоге освобождает память. По сути в блоке сверху я сделал то же самое что и OOM Killer, за исключением того, что я выбрал ненужный мне процесс. OOM Killer же может убить и весьма важный процесс для вас, например процесс PostgreSQL.

Понять, что тот или иной процесс был убит OOM Killer можно по записям в файле /var/log/messages. Он будет содержать запись Out of Memory: Killed process 125 (vault).

Для того, чтобы завершить процесс ОС вызывает функцию out_of_memory. После чего OOM Killer решает какой именно процесс ему завершить и потом проделывает это с ним.

Перед тем как вызвать out_of_memory выполняются следующие проверки:

Достаточно ли в ОС еще места подкачки (swap) (nr_swap_pages > 0)? Если да, то не вызываем ООМ
Был ли завершений процесс в течение последних 5 секунд? Если да, то не вызываем ООМ

swapoff -a
perl -wE 'my @xs; for (1..2**20) { push @xs, q{a} x 2**20 }; say scalar @xs; sleep;'
swapon -a

Killed

cat /var/log/messages | grep "Out of"

Jan 24 11:57:39 vm-2 kernel: Out of memory: Killed process 11144 (perl) total-vm:6500608kB, anon-rss:3421028kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:12752kB oom_score_adj:0

Какой процесс завершать?

В функции out_of_memory, которую мы упоминали выше вызывается функция под названием select_bad_process, которая отвечает за выбор процесса для завершения. Она решает насколько тот или иной процесс подходит для уничтожения с помощью функции badness. В итоге благодаря функции badness процесс проходит отбор по правилам и в конце назначается репутация процесса.

Получается, что OOM Killer не завершает любой процесс, он завершает именно тот который по мнению функции select_bad_process является самым плохим основываясь на оценке процесса (oom_score).

Посмотреть какую именно оценку получил тот или иной процесс вы всегда можете, выполнив команду cat /proc/$PID/oom_score, где $PID - id процесса.

cat /proc/868/oom_score

Чем выше репутация у процесса, тем больше вероятности что именно его и завершит OOM Killer.

Оценка вычисляется благодаря функции int_sqrt. Во время оценки внимание обращается на:

Объем памяти, используемый процессом.
Размер памяти любого дочернего процесса (не включая поток ядра).
Оценка процесса увеличивается для хороших процессов и уменьшается для длительных процессов.
У процессов с возможностями CAP_SYS_ADMIN и CAP_SYS_RAWIO снижены оценки.

Если процесс запущен от root его значение будет разделено еще на 4, потому что от root запускаются как правило только хорошие процессы. То же самое происходит и с процессами, которые имеют доступ к физическим устройствам (/dev).

Для примера запустим 2 perl скрипта и проверим их репутацию.

perl -wE 'my @xs; for (1..2**15.7) { push @xs, q{a} x 2**15.7 }; say scalar @xs; sleep;'
perl -wE 'my @xs; for (1..2**14.6) { push @xs, q{a} x 2**14.6 }; say scalar @xs; sleep;'

   3914 root       20   0 2731M 2706M   424 S  0.0 73.4  0:00.54 perl -wE my @xs; for (1..2**15.7) { push @xs, q{a} x 2**15.7 }; say scalar @xs; sleep;
   4018 root       20   0  615M  590M   424 S  0.0 16.0  0:00.12 perl -wE my @xs; for (1..2**14.6) { push @xs, q{a} x 2**14.6 }; say scalar @xs; sleep;

cat /proc/3914/oom_score
cat /proc/4018/oom_score

1156
773

В итоге получается, что процесс, который использует больше памяти имеет репутацию больше чем второй процесс.

Отключить OOM Killer

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

Но если вы всё же хотите отключить OOM Killer, то выполняем следующее:

sudo cat /proc/sys/vm/panic_on_oom

sudo echo 1 > /proc/sys/vm/panic_on_oom

Уменьшаем oom_score

Если вам важно чтобы какой-то процесс не завершался, то можно уменьшиться его репутацию. Для этого в файл oom_adj помещаем значение от -16 до +15.

cat /proc/8367/oom_score

echo -5 > /proc/8367/oom_adj
cat /proc/8367/oom_score

echo 5 > /proc/8367/oom_adj
cat /proc/8367/oom_score

Отключить OOM Killer для процесса

Если вы хотите отключить OOM Killer только для определённого процесса в файл oom_adj записываем число -17. Но нужно понимать, что как только вы перезапустите службу отвечающую за этот процесс его id изменится и соответственно и репутация.

echo -17 > /proc/8367/oom_adj
cat /proc/8367/oom_score

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

И в таком случае лучше задавать репутацию в файле сервиса через переменную OOMScoreAdjust.

[Service] OOMScoreAdjust=-17

PostgreSQL

В приложении сервера БД PostgreSQL каждый запрос порождает отдельный процесс. Соответственно если ОЗУ закончилось сам сервис PostgreSQL отключен не будет, завершиться только тот процесс, который занял всё ОЗУ.

При этом сама база перейдёт в режим recovery из-за отмены транзакции.

В итоге

Не нужно боятся OOM Killer он наоборот сохранит вам нервы. Другое дело что нужно писать свои сервисы так чтобы они не съедали всё ОЗУ на сервере или ограничивать объём используемого ОЗУ для сервиса.

WireGuard - Создаём Point-To-Point vpn

Fri, 21 Jan 2022 20:20:39 +0600

Понятное дело, что у вас уже должен быть устройство, на котором вы будете поднимать сервер WireGuard и, если это просто vpn для обхода ограничений интернета в вашем регионе сервер с WireGuard должен находится в другом регионе, например, в другой стране.

Схема

Серверная часть WireGuard будет стоять на виртуальном сервере, который арендуется у digitalocean
На своём компьютере я ставлю также WireGuard и подключаюсь к серверу (1)
Использую интернет через vpn (2)

Выбор региона для виртуалки

Если вы уже ранее работали с облаками и размещали там виртуальные сервера, то вы скорее всего уже знаете о том, что в зависимости от региона пинг до вашей виртуальной машины варьируется. И соответственно идеально было бы разместить так чтобы пинг был минимальный.

Так как я размещаюсь на digitalocean у меня есть скрипт, который выдаст вам пинги в зависимости от региона.

Для windows (cmd):

{
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-nyc1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-nyc2.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-nyc3.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-ams2.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-ams3.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-sfo1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-sfo2.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-sgp1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-lon1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-fra1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-tor1.digitalocean.com/
    curl -w "%{url_effective};%{time_connect}\n" -o /dev/null -s http://speedtest-blr1.digitalocean.com/
} | sort -t';' -k2

Для Linux:

wget -qO - https://raw.githubusercontent.com/jakejarvis/datacenter-speed-tests/master/ping.sh | bash

Или просто используя ссылку.

Теперь, когда мы определились где именно размещать виртуальный сервер выполняем deploy последней версии ubuntu и назначаем ей floating IP. Об этом я тут писать не буду, но если интересно или вы никогда этого не делали, то можно посмотреть отрезок на видео внизу.

Настройка сервера на ubuntu

1 - Устанавливаем WireGuard и генерируем ключи

Для начала ставим последние обновления и уже потом ставим сам WireGuard.

sudo apt update -y
sudo apt install wireguard -y

Теперь, когда мы установили WireGuard нужно создать пары закрытого и открытого ключей для сервера, используя wg genkey.

sudo wg genkey | sudo tee /etc/wireguard/private.key

KPfbJtgKfrWxihTpA2t59ETzcU/yyyyC5rereZDGsdG14=

Также для большей безопасности нелишним будет отобрать права на доступ к файлу у всех кроме владельца.

sudo chmod go= /etc/wireguard/private.key

И следующая команда уже создаст нам публичный ключ.

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

pnoYatoBe5rrJ9d574t5ttteraxF/91t45t45t51hN5HdCTgfgY=

2 - Выбор ip адресов

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

В этом же шаге мы назначим ip адреса нашей приватной сети. Я решил выбрать подсеть 10.10.0.0/24.

Самому серверу WireGuard я выдам ip 10.10.0.1, но вы можете назначить любой другой в пределах 24 маски. Соответственно так как этот ip адрес уже занят для своего компьютера я задам ip 10.10.0.2.

3 - Создание конфигурации сервера WireGuard

Теперь, когда у нас есть пара ключей и мы выбрали ip адреса самое время создать файл конфигурации для нашего сервера WireGuard.

sudo vi /etc/wireguard/wg0.conf

[Interface]
#тут наш приватный ключ /etc/wireguard/private.key
PrivateKey = KPfbJtgKfrWxihTpA2t59ETzcU/yyyyC5rereZDGsdG14=
#приватный ip для сервера
Address = 10.10.0.1/24
ListenPort = 51830
SaveConfig = true

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

4 - Настройка сетевой конфигурации сервера WireGuard

Если вы хотите направить интернет-трафик вашего узла WireGuard (клиент) через сервер WireGuard, вам необходимо настроить IP-переадресацию.

sudo vi /etc/sysctl.conf

net.ipv4.ip_forward=1

sudo sysctl -p

net.ipv4.ip_forward = 1

5 - Настройка файрвола WireGuard

Чтобы разрешить трафик WireGuard VPN через брандмауэр сервера, вам необходимо включить masquerading, которая представляет собой концепцию iptables, обеспечивающую динамическую трансляцию сетевых адресов (NAT) на лету для правильной маршрутизации клиентских подключений.

Для начала определим наш интерфейс, обычно eth0.

ip route list default

default via 128.199.16.1 dev eth0 proto static

Теперь добавляем правила для файрволла в файл конфигурации WireGuard сервера.

sudo vi /etc/wireguard/wg0.conf

[Interface]
#тут наш приватный ключ /etc/wireguard/private.key
PrivateKey = KPfbJtgKfrWxihTpA2t59ETzcU/yyyyC5rereZDGsdG14=
#приватный ip для сервера
Address = 10.10.0.1/24
ListenPort = 51830
SaveConfig = true

PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

И осталось разрешить входящие подключения на порт 51830.

sudo ufw allow 51830/udp
sudo ufw allow OpenSSH
sudo ufw disable
sudo ufw enable

6 - Запуск сервера WireGuard

И последний этап, который мы проделываем на самом сервер это запуск сервера WireGuard с тем конфигом что мы сделали.

sudo systemctl enable --now wg-quick@wg0.service
sudo systemctl status wg-quick@wg0.service

Active: active (exited)

Настройка WireGuard на стороне клиента

Так как мне нужен vpn на компьютере с windows для начала мне нужно скачать установочный файл по ссылке. Если у вас другая ОС на клиенте по той же ссылке можно найти инструкцию по установке.

1 - Генерируем ключи

Также, как и для сервера генерируем ключи для клиента.

sudo wg genkey | sudo tee /etc/wireguard/peer-private.key
sudo chmod go= /etc/wireguard/private.key

aMc+s6zWG4ULDMMIkUWcCn7GH1svNQF/FPMlH8EFUWQ=

sudo cat /etc/wireguard/peer-private.key | wg pubkey | sudo tee /etc/wireguard/peer-public.key

c7UpF4kWp6ZJIKRfjiuucjpAx1gC1scldIzxSOF/cw4=

2 - Конфигурации клиента WireGuard

Создаём текстовый файл wg0.conf и записываем в него:

[Interface]
#тут наш приватный ключ /etc/wireguard/peer-private.key
PrivateKey = aMc+s6zWG4ULDMMIkUWcCn7GH1svNQF/FPMlH8EFUWQ=
Address = 10.10.0.2/24

[Peer]
#публичный ключ сервера /etc/wireguard/public.key
PublicKey = pnoYatoBe5rrJ9d574t5ttteraxF/91t45t45t51hN5HdCTgfgY=
AllowedIPs = 10.10.0.0/24
#статический ip сервера
Endpoint = 144.144.144.141:51830

И следующим шагом импортируем настройки в WireGuard.

Добавление открытого ключа клиента узла на сервер WireGuard

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

sudo cat /etc/wireguard/peer-public.key

c7UpF4kWp6ZJIKRfjiuucjpAx1gC1scldIzxSOF/cw4=

Теперь выполняем добавление ключа на сервер WireGuard используя следующую команду:

sudo wg set wg0 peer c7UpF4kWp6ZJIKRfjiuucjpAx1gC1scldIzxSOF/cw4= allowed-ips 10.10.0.2

Чтобы просмотреть что команда выполнилась, и мы добавили клиента выполняем sudo wg.

sudo wg

interface: wg0
  public key: pnoYatoBe5rrJ9d574t5ttteraxF/91t45t45t51hN5HdCTgfgY=
  private key: (hidden)
  listening port: 51830

peer: c7UpF4kWp6ZJIKRfjiuucjpAx1gC1scldIzxSOF/cw4=
  allowed ips: 10.10.0.2/32

Подключение

Теперь всё готово к подключению и нам всего то нужно нажать Activate нашего туннеля.

И для проверки просто попробуем пропиговать приватный ip нашего сервера.

sudo wg

Pinging 10.10.0.1 with 32 bytes of data:
Reply from 10.10.0.1: bytes=32 time=451ms TTL=64
Reply from 10.10.0.1: bytes=32 time=462ms TTL=64
Reply from 10.10.0.1: bytes=32 time=482ms TTL=64
Reply from 10.10.0.1: bytes=32 time=397ms TTL=64

Роутинг

Если вы хотите отправлять весь ваш трафик в тунель, т.е. на vpn сервер то AllowedIPs на клиенте нужно изменить.

[Interface]
#тут наш приватный ключ /etc/wireguard/peer-private.key
PrivateKey = aMc+s6zWG4ULDMMIkUWcCn7GH1svNQF/FPMlH8EFUWQ=
Address = 10.10.0.2/24

[Peer]
#/etc/wireguard/public.key
PublicKey = pnoYatoBe5rrJ9d574t5ttteraxF/91t45t45t51hN5HdCTgfgY=
AllowedIPs = 0.0.0.0/0
#статический ip сервера
Endpoint = 144.144.144.141:51830

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

Назначаем свой dns

Если вы хотите переназначить используемый dns сервер добавляем переменную DNS в файл конфигурации клиента.

[Interface]
#тут наш приватный ключ /etc/wireguard/peer-private.key
PrivateKey = aMc+s6zWG4ULDMMIkUWcCn7GH1svNQF/FPMlH8EFUWQ=
Address = 10.10.0.2/24
DNS = 8.8.8.8

[Peer]
#/etc/wireguard/public.key
PublicKey = pnoYatoBe5rrJ9d574t5ttteraxF/91t45t45t51hN5HdCTgfgY=
AllowedIPs = 0.0.0.0/0
#статический ip сервера
Endpoint = 144.144.144.141:51830

Видео

Что такое VPN?

Wed, 19 Jan 2022 06:20:39 +0600

Начнём с самого банального, а именно с расшифровки этих трёх букв VPN - Virtual Private Network, что в переводе на русский язык означает виртуальная частная (приватная) сеть.

Слово сеть здесь тут участвует потому что объединение 2 или более устройств используя любые каналы связи уже подразумевает создание сети.
Что такое частная или приватная, наверное, и так понятно, основной аргумент что не общая, а значит частная. Подразумевается, что в вашей сети только доверенные устройства, хотя сейчас, когда vpn предоставляет куча организаций, да еще и бесплатно то это уже не совсем так.
Виртуальная в большей степени означает то что у этой сети нет доступа к вашей физической сети, ну по крайней мере так по умолчанию.

Зачем нам VPN?

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

И еще один распространённый способ — это использование vpn для подключения между собой нескольких офисов, дата-центров. Эти офисы могут находится в разных городах или даже странах, но благодаря vpn сотрудники этих офисов совместно могут работать с одними общими ресурсами, например, база 1с. Конечно достичь этого можно просто выставив свою базу в интернет, но это чревато плохими последствиями, например, взломом и хищением данных. Т.е. основная цель объединить множество географически распределённых систем в одну сеть, при том сделать это безопасно.

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

Кто использует?

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

Есть такой сайт https://www.gwi.com/, который занимается статистикой. Так вот у них есть также и статистика того, кто и как пользуется vpn.

Вот несколько интересных фактов из их исследований:

Даже люди в возрасте от 55-64 используют vpn (28%)
34% пользователей используют vpn чтобы защитить свои персональные данные
34% используют для прослушивания музыки и 32% для видео
72% пользователей используют компьютеры

Всю эту статистику вы можете скачать по ссылке

Как это работает?

Я не буду слишком вдаваться в подробности потому как я считаю, что 80% читающим это будет неинтересно. Я просто попытаюсь объяснить максимально просто и показать пару примеров.

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

Так вот если теперь перевести историю в наши реалии получается, что:

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

Т.е. вы можете открыть заблокированный ресурс потому что трафик идёт уже не от вас, а от самого vpn сервера. Получается для того же оператора, который предоставляет вам интернет вы не открываете сайт, а просто пересылаете какой-то трафик на vpn сервер.

Но нужно понимать, что вы можете столкнутся с запретами той страны, в которой находится ваш vpn сервер.

Какой vpn использовать?

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

Поэтому я лично стараюсь использовать свой личный vpn сервер. И у меня есть несколько статей, о том, как его настроить:

ipsec vpn (более безопасный)

ELK - комбинированный поиск

Tue, 18 Jan 2022 06:20:39 +0600

В elk существует возможность делать вложенный поиск, т.е искать по заданным критериям в уже выполненном поиске. Такой поиск также называется как bool query.

Включает в себя 4 оператора:

must
must_not
should
filter

Рассмотрим каждый из них подробнее чтобы понять в чем их различия.

must

Равнозначен and, т.е означает что введённое значение должно находится в выведенных документах. Чем больше must в условиях тем больше совпадений должно быть найдено.

Например выведем все документы со значением logstah в поле content и значением Engineering в category. Видим что их количество 91

GET blogs/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "content": "logstah"
          }
        },
        {
          "match": {
            "category": "Engineering"
          }
        }
      ]
    }
  }
}

Например выведем все документы со значением logstah и access в поле content и значением Releases в category. Видим что их количество 21

GET blogs/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        },
        {
          "match": {
            "category": "Releases"
          }
        },
        {
          "match": {
            "content": "access"
          }
        }
      ]
    }
  }
}

must_not

Оператор must not означает что в результатах поиска не должно присутствовать переданное значение. В примере ищем поле content с присутствующим словом Elastic и category с отсутствующим значением News ( всё корме News ).

GET blogs/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
      , "must_not": [
        {"match": {
          "category": "News"
        }}
      ]
    }
  }
}

should

Should в отличии от первых двух не исключает никаких документов из вывода. Он просто сортирует вывод в зависимости от запроса.

Например выведем документы с полем content, в котором находится слово Elastic. В выводе видим первые документы имеют разных author.

GET blogs/_search
{
  "_source": {
    "includes": ["author","title"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
    }
  }
}

Например выведем документы с полем content, в котором находится слово Elastic и полем author используя should. В выводе видим первые документы имеют author которого мы указали в поиске Amy White.

GET blogs/_search
{
  "_source": {
    "includes": ["author","title"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
      , "should": [
        {"match_phrase": {
            "author": "Amy White"
          }
        }
      ]
    }
  }
}

Для should можно задать параметр minimum_should_match, который задаёт количество совпадений при многоразовым should ( по умолчанию 0 для многоразовым should и 1 для одного should ). Если его выставить, то уже будет фильтрация документов.

GET blogs/_search
{
  "_source": {
    "includes": ["author","title"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
      , "should": [
        {"match": { "title": "stack" }},
        {"match": { "title": "query" }},
        {"match": { "title": "speed" }}
      ]
    }
  }
}

GET blogs/_search
{
  "_source": {
    "includes": ["author","title"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
      , "should": [
        {"match": { "title": "stack" }},
        {"match": { "title": "query" }},
        {"match": { "title": "speed" }}
      ],
      "minimum_should_match": 1
    }
  }
}

filter

Filter также исключает документы из вывода и в общем отвечает на вопрос да или нет. Т.е допустим вы хотите получить документы находящиеся в интервале какого-то времени. Соответственно вы задаёте данный интервал и если интервал совпадает ( ответ ДА ), то документ будет выведен.

Например выведем все документы со значением Elastic в поле content. Видим что их количество 716.

GET blogs/_search
{
  "_source": {
    "includes": ["author","title","publish_date"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
    }
  }
}

Например выведем все документы со значением Elastic в поле content и дата публикации publish_date позднее чем 2017-05-24. Видим что их количество 166.

GET blogs/_search
{
  "_source": {
    "includes": ["author","title","publish_date"]
  },
  "query": {
    
    "bool": {
      "must": [
        {
          "match": {
            "content": "Elastic"
          }
        }
      ]
      , "filter": [
        {"range": {
          "publish_date": {
            "lte": "2017-05-24"
          }
        }}
      ]
    }
  }
}

Итоговая таблица что на что влияет

оператор	влияет на hits	влияет на _score	фильтрует вывод
must	Y	Y	N
must_not	Y	N	Y
should	N	Y	N
filter	Y	N	Y

Wallpapers - Обои для рабочего стола (Топ за 2021)

Sun, 16 Jan 2022 00:54:39 +0600

Ну и раз уже прошёл 2021 год я решил создать тему с обоями от Smashing Magazine за 2021 год.

скачать без календаря

скачать с календарём

Wallpapers - Обои для рабочего стола (Январь 2022)

Sun, 16 Jan 2022 00:54:39 +0600

На дворе уже январь 2022 года. И если вам также хочется новых картинок на вашем рабочем столе, то предлагаю вам тему для Windows, в которой обои от Smashing Magazine.

скачать

Соцсети

Группа в Telegram

YubiKey - Получение идентификатора токена (Token ID)

Tue, 04 Jan 2022 21:47:39 +0600

На самом деле всё просто каждый Ubikey может генерировать OTP, в котором как раз и содержится Token ID. Token ID - это первые 12 символов OTP, который генерирует Ubikey. Т.е. проще всего сгенерировать OTP используя Ubikey в текстовый редактор или в терминал и отсчитать от начала 12 символов, и вы получите ваш Ubikey.

Ну и если вы не хотите отсчитывать, можно воспользоваться терминалом:

read opt; ID=$(echo  $opt | cut -c1-12)

После вы генерируете OTP используя ваш Ubikey, например, у меня это сканер по центру. В итоге в переменную ID запишется ваш Token ID.

echo $ID

ccytuctkoplk

Yubico OTP - Включаем двухфакторную аутентификацию в Linux

Tue, 04 Jan 2022 21:30:39 +0600

OTP расшифровывается как One Time Password, ну и если кто-то нуждается в переводе на русский язык: одноразовый пароль.

Одноразовый пароль действителен только лишь для одного сеанса аутентификации, т.е. после того как вы его использовали, например, для входа в систему он уже становится неактуальным. Также актуальность временного пароля может ограничиваться временем активности пароля.

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

Yubico OTP

О том, что такое Yubico я уже писал ранее, можно ознакомиться тут.

Yubico OTP - это простой, но безопасный механизм аутентификации, который поддерживается всеми выпускаемыми версиями YubiKey. Yubico OTP может использоваться как второй фактор в схеме двухфакторной аутентификации или сам по себе, обеспечивая однофакторную аутентификацию, т.е. как основное средство аутентификации, как и дополнительное.

YubiCloud

YubiCloud - это веб-служба от компании Yubico для проверки одноразовых паролей. Перед использованием YubiCloud вам необходимо получить API ключ. Также для людей, которые не доверяют серверам в интернете, которые обслуживают не они есть возможность развернуть свои сервера YubiCloud, подробнее по ссылке.

Способы применения

Есть возможность применить OTP используя 2 способа:

Плагины интеграции для Windows login, FreeRADIUS, Wordpress, phpBB и PAM.
Библиотеки для языков программирования, используемые для создания собственной интеграции.

Получаем API

Переходим сюда и заполняем поля. Для того чтобы заполнить YubiKey OTP нужно активировать YubiKey, чтобы он вставил значение. В итоге мы должны получить наши Client ID и Secret key.

Применение

1.Первым делом поставим пакет pam_yubico:

sudo dnf install epel-release -y
sudo dnf install pam_yubico -y

sudo apt update
sudo apt install libpam-yubico -y

2.Создаём файл /etc/yubico-mapping и добавляем в него тех пользователей, которые должны иметь возможность логиниться при помощи yubico в формате пользователь:yubikey токен (только первые 12 символов). Для того чтобы получить токен просто нажимаем на сканер yubikey. Также вы можете добавить пользователю несколько ключей, просто используя строку типа пользователь:yubikey токен:yubikey токен2:yubikey токен3

Если не поняли как получить токен советую к прочтению статью.

sudo vim /etc/yubico-mapping

admin:crtyccjflici
test:crtyccjflici

3.Редактируем /etc/pam.d/sshd, id мы получили когда регистрировались на сайте.

sudo vi /etc/pam.d/sshd

auth required pam_yubico.so id=1624 debug authfile=/etc/yubico-mapping

sudo systemctl restart sshd

4.Если хотите логиниться только используя yubikey

sudo vi /etc/pam.d/sshd

#@include common-auth  если UBUNTU
#auth substack password-auth
auth required pam_yubico.so id=1624 debug authfile=/etc/yubico-mapping

sudo systemctl restart sshd

5.Настраиваем SELINUX

sudo setsebool -P authlogin_yubikey on

6.Пробуем залогиниться

ssh  test@192.168.0.132

Password:
YubiKey for `test':

Permission denied, please try again.

Может сложится так что у вас не будет запроса YubiKey при попытке залогиниться на конечный хост, а будет только запрос пароля, после ввода которого вы просто получите ошибку Permission denied, please try again.

Для решения этой проблемы выполняем следующее:

sudo vim /etc/ssh/sshd_config

ChallengeResponseAuthentication yes

sudo systemctl restart sshd

Видео

ELK - Мониторинг json файла и failed to parse field of type [keyword]

Wed, 08 Dec 2021 20:51:39 +0600

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

Итоговая схема доставки: filebeat -> logstash -> elasticsearch.

Настройка filebeat

Тут в целом ничего сложного просто добавляем новый input и задаём файл для мониторинга.

sudo vim /etc/filebeat/filebeat.yml

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /tmp/*.json
  json.keys_under_root: true
  json.overwrite_keys: true
  json.add_error_key: true
  json.expand_keys: true
 
  processors:
  - add_tags:
      tags: [json-test]

sudo systemctl restart filebeat

Добавляем данные в файл

Для этого просто создаём файл json в каталоге tmp и заполняем его данными. Для генерации тестовых данных можно воспользоваться онлайн генератором.

Ошибка failed to parse field of type [keyword]

И вроде всё работает, и я получаю данные, т.е. документы появляются в index: filebeat-*, но только если я записываю в файл простой массив без вложенностей.

{"balance":"$3,357.79","picture":"http://placehold.it/32x32","eyeColor":"brown","name":"Murray Suarez","gender":"male","company":"IDEALIS","email":"murraysuarez@idealis.com","phone":"+1 (833) 600-3849","address":"986 Beverly Road, Gulf, Pennsylvania, 9249","registered":"2019-04-24T03:48:24 -06:00","greeting":"Hello, Murray Suarez! You have 10 unread messages.","favoriteFruit":"apple"}

Но вот как только я пытаюсь проиндексировать уже сложный массив я получаю ошибку: failed to parse field [friends] of type [keyword]. Ошибка появляется на этапе передачи документа в elasticsearch, т.е. на последнем этапе.

{"balance":"$1,325.77","picture":"http://placehold.it/32x32","eyeColor":"green","name":"Janette Becker","gender":"female","company":"TETAK","email":"janettebecker@tetak.com","phone":"+1 (908) 551-2528","address":"106 Coleman Street, Frizzleburg, Iowa, 1948","registered":"2020-06-08T05:07:20 -06:00","greeting":"Hello, Janette Becker! You have 5 unread messages.","favoriteFruit":"banana","friends":[{"id":0,"name":"Kristie Ewing"},{"id":1,"name":"Vance Wooten"},{"id":2,"name":"Clark Mcfadden"}]}

Решение failed to parse field of type [keyword]

Ошибка заключается в том, что elasticsearch не может правильно сопоставить тип поля. И нужно вручную сопоставить тип поля в шаблоне (mapping).

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

sudo vim /etc/logstash/conf.d/output.conf

output {
  if "filebeat" in [agent][type] and "json-test" in [tags] {
    elasticsearch {
      hosts => ["https://elk-1:9000","https://elk-2:9000","https://elk-3:9000"]
      index => "json-test-%{+YYYY.MM.dd}"
    }
  }
  if "filebeat" in [agent][type] and "json-test" not in [tags] {
    elasticsearch {
      hosts => ["https://elk-1:9000","https://elk-2:9000","https://elk-3:9000"]
      index => "filebeat-%{+YYYY.MM.dd}"
    }
  }
}

В итоге всё проиндексировалось, и я получил данные. Дальше можно получить весь mapping и уже дальше его использовать в своём template, ну а так как мне всё равно нужен был новый index меня всё устраивает.

Если проанализировать вывод ниже понятно, что elasticsearch пытался создать поле friends с типом keyword, тогда как тип должен быть long.

GET json-test-2021.12.08/_mapping

{
  "json-test-2021.12.08" : {
    "mappings" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "address" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "agent" : {
          "properties" : {
            "ephemeral_id" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "hostname" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "id" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "name" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "type" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "version" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            }
          }
        },
        "balance" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "company" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "ecs" : {
          "properties" : {
            "version" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            }
          }
        },
        "email" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "eyeColor" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "favoriteFruit" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "friends" : {
          "properties" : {
            "id" : {
              "type" : "long"
            },
            "name" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            }
          }
        },
        "gender" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "greeting" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "host" : {
          "properties" : {
            "architecture" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "containerized" : {
              "type" : "boolean"
            },
            "hostname" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "id" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "ip" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "mac" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "name" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "os" : {
              "properties" : {
                "codename" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "family" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "kernel" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "name" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "platform" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "type" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                },
                "version" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                }
              }
            }
          }
        },
        "input" : {
          "properties" : {
            "type" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            }
          }
        },
        "log" : {
          "properties" : {
            "file" : {
              "properties" : {
                "path" : {
                  "type" : "text",
                  "fields" : {
                    "keyword" : {
                      "type" : "keyword",
                      "ignore_above" : 256
                    }
                  }
                }
              }
            },
            "offset" : {
              "type" : "long"
            }
          }
        },
        "name" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "phone" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "picture" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "registered" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "tags" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    }
  }
}