Создаем логические тома LVM на Linux

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

Это краткое руководство по внедрению LVM на вашем linux-сервере или рабочей станции.

https://telegra.ph/Sozdaem-logicheskie-toma-LVM-na-Linux-10-09

📌 Calico Whisker - безопасные сетевые политики в Kubernetes без простоев

Работая с Kubernetes, вы наверняка сталкивались с риском простоев при внедрении сетевых политик. Ошибки в конфигурации могут случайно заблокировать легитимный трафик, а отладка таких ситуаций — сплошная головная боль.

Теперь есть решение: Calico Whisker — механизм этапных сетевых политик. Суть простая:

👉🏻 Вы пишете политику, но не применяете её сразу.
👉🏻 Система "наблюдает", какой трафик она бы заблокировала или пропустила.
👉🏻 Вы смотрите логи, анализируете поведение.
👉🏻 И только потом, когда уверены, активируете её без изменений.

Это как staging-режим, только для сетевой безопасности. Без риска. Без простоя.

https://www.tigera.io/blog/calico-whisker-staged-network-policies-secure-kubernetes-workloads-without-downwww.tgoop.com/

Механизм запуска процесса в Linux

В этой статье я расскажу о том, что происходит внутри ядра Linux, когда процесс вызывает execve(), как ядро подготавливает стек и как затем передаёт управление пользовательскому процессу для выполнения.

Изучил я этот механизм, когда разрабатывал Zapper — инструмент Linux, удаляющий все параметры командной строки из любого процесса без прав root.

https://habr.com/ru/companies/ruvds/articles/946236/

Собираем docker и деплоим из GitHub Actions

Я приведу краткую инструкцию, как быстро собирать проект и деплоить docker. Времена докера никуда не ушли, все мелкие проекты мы до сих пор делаем на обычных докерах, а также там, где всё on-premise и не дают облака с Kubernetes. Сопровождать Kubernetes самим - то еще удовольствие, особенно, когда заказчики не выделяют бюджеты на "золотых" (Ваня, привет!) devops-еров.

Флоу будет очень простым: одним job мы собираем образ (с указанием тэга или ветки) и кладем в приватный репозиторий образов GitHub, а другим job деплоим оттуда. Это удобно, когда есть несколько сред и мы один раз собираем и контейнер запускаем из него с разными переменными среды. И важное условие: мы не устанавливаем docker-compose или github runner на сервер с docker.

https://habr.com/ru/articles/824526/

Ставим пароль на GRUB

1. Генерация хэш-пароля
За данное действие отвечает утилита:
grub-mkpasswd-pbkdf2 

А затем два раза ввести будущий пароль для GRUB. Полученный хэш – это длинная строка, которая начинается с grub.pbkdf2. Ее нужно скопировать и куда-нибудь сохранить.

2. Изменить настройки 
Теперь нужно назначить супер-пользователя для GRUB. Это удобно делать через файл /etc/grub.d/00_header, отредактировав его содержимое. Удобнее сначала открыть текстовый документ, куда все было сохранено, и вставить команду следующего вида:
cat << EOF
set superusers="user_name"
password_pbkdf2 user_name хэш-пароль
EOF
Вместо user_name во второй и третьей строке укажите предпочтительное имя супер-пользователя GRUB, а также замените хэш пароль на свой.

Теперь выполните:
sudo nano /etc/grub.d/00_header

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

3. Обновить конфигурацию
sudo update-grub

4. Проверить работу
reboot

Какие есть best practices для написания Dockerfile?

1. Запускать только один процесс на контейнер.
2. Стараться объединять несколько команд RUN в одну для уменьшения количества слоёв образа.
3. Частоизменяемые слои образа необходимо располагать ниже по уровню, чтобы ускорить процесс сборки, т.к. при изменении верхнего слоя, все нижеследующие слои будут пересобираться.
4. Указывать явные версии образов в инструкции FROM, чтобы избежать случая, когда выйдет новая версия образа с тегом latest.
5. При установке пакетов указывать версии пакетов.
6. Очищать кеш пакетного менеджера и удалять ненужные файлы после выполненной инструкции.
7. Использовать multistage build для сборки артифакта в одном контейнере и размещении его в другом.

👩‍💻 Шпаргалка по PowerShell / Краткий справочник

gist.github.com/pcgeek86/3...

Сохраняем вывода команды Top в файл

Поскольку я не использовал опцию delay, приведенная ниже команда top перенаправит вывод команды top за одну итерацию в файл.
top -b -n 1 > /home/i_odmin/backup/output.txt

Сохранение вывода команды top с более чем одной итерацией из 5 итераций
Обычно программа работает непрерывно с задержкой в 2 секунды, и вы можете изменить это значение, добавив в верхнюю команду значение ‘-d’, как показано ниже:
top -n 5 -d 4 -b >/backup/output_1.txt

Как захватить вывод команды top в файл каждые 5 минут в течение часа
Система создает отдельный файл каждые 5 минут, который поможет вам определить список процессов, которые потребляли больше CPU и памяти в системе.
Добавляем следующий cronjob, который будет выполняться с 5 до 6 утра каждые 5 минут в течение часа.
Где
-n : Задает максимальное количество итераций.
-b : Работа в пакетном режиме (Запуск команды top в пакетном режиме для перенаправления вывода в другие программы или в файл)
-d : Интервал задержки (Задает задержку между обновлениями экрана)
0-59/5 5 * * * top -n 10 -d 4 -b > /home/i_odmin/backup/top_out-`date +\%Y\%m\%d\%H\%M\%S`.txt

Собраем вывод в один файл, используйте следующий cronjob
Cronjob будет выполняться с 9 до 10 утра каждые 5 минут в течение часа и добавлять результаты в один файл.
0-59/5 9 * * * top -b -n5 -d 5 >>/home/i_odmin/backup/output.txt

Записываем вывод команды top в файл каждые 5 минут в течение получаса
Добавляем следующий cronjob, который будет запускаться каждые 5 минут с 13:30 до 14:00 в течение получаса.
30-59/5 13 * * * top -n 10 -d 4 -b > /home/i_odmin/backup/top_out-`date +\%Y\%m\%d\%H\%M\%S`.txt

Docker 101: Фоновые контейнеры, логи и потоки STDIO

Практикуемся в получении их логов и повторном подключении к потокам STDIO: https://labs.iximiuz.com/challenges/docker-101-container-run-in-background

Советы по настройке history команд в Bash

Каждая вводимая в терминале команда сохраняется в файле ~/.bash_history. Чтобы посмотреть историю команд – введите history.

Настройка истории команд в Bash осуществляется путем добавления переменных окружения в файл ~/.bashrc.

Чтобы изменения в ~/.bashrc вступили в силу, выполните:

source ~/.bashrc


1. Добавляем Отображение Даты и Времени в Bash History
Иногда очень полезно узнать время, когда какая-либо команда была выполнена.

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

Для этого добавьте следующую строку в файл ~/.bashrc:

export HISTTIMEFORMAT="%h %d %H:%M:%S "
Теперь, набрав history, Вы получите следующий вывод:

113 Jun 08 16:31:06 sudo ifconfig
114 Jun 08 16:31:10 top
115 Jun 08 16:31:19 ping disnetern.ru
116 Jun 08 16:31:22 history

2. Увеличиваем Размер Хранимой Истории
Увеличьте HISTSIZE — количество команд, которые необходимо запоминать в списке истории (стандартное значение — 500).

export HISTSIZE=5000
Увеличьте HISTFILESIZE — максимальное количество строк, содержащееся в файле истории (стандартное значение — 500).

export HISTFILESIZE=5000


3. Добавляем Команды Bash в Файл с Историей
Bash перезаписывает файл .bash_history?

Чтобы добавлять новые команды в файл с историей, а не переписывать его каждый раз, добавьте следующую строку в ~/.bashrc:

shopt -s histappend


4. Мгновенно Сохранять Историю Команд
По умолчанию, Bash записывает историю команд в .bash_history, при завершении сессии.

Если сессия внезапно оборвется Вы потеряете текущую историю команд.

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

Добавьте следующую строку в файл ~/.bashrc, если переменная $PROMPT_COMMAND не была задана ранее:

PROMPT_COMMAND='history -a'
Добавьте следующую строку, если переменная $PROMPT_COMMAND уже была задана:

PROMPT_COMMAND='$PROMPT_COMMAND; history -a'

📌 SSH под капотом

В Linux Logical Volume Manager (LVM) - это система управления хранением данных, которая обеспечивает более гибкий подход к управлению дисковым хранилищем, чем традиционное разбиение на разделы. LVM работает за счет создания уровня абстракции между физическими устройствами хранения и файловой системой, позволяя создавать логические тома, которые могут охватывать несколько физических дисков.

С помощью LVM вы можете создавать группы томов из одного или нескольких физических дисков, а затем создавать логические тома в этих группах томов. Логические тома ведут себя как традиционные разделы диска, но у них есть несколько преимуществ:

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

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

- LVM предоставляет такие возможности, как моментальные снимки, которые позволяют создавать копии логических томов «точка-в-время» для целей резервного копирования или тестирования.

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