Список базовых команд Linux для повседневного использования
(продолжение предыдущего поста)

1. Bash Commands (базовые команды Bash):
- uname -a — показать систему и ядро;
- head -n1 /etc/issue — показать дистрибутив;
- mount — показать смонтированные файловые системы;
- date — показать системную дату;
- uptime — показать время работы системы;
- whoami — показать имя пользователя;
- man command — показать руководство по команде.

2. File commands (команды работы с файлами и директориями):
- ls — список директории;
- ls -a — показать всё (включая скрытые файлы);
- ls -R — рекурсивный список;
- ls -r — обратный порядок;
- ls -t — сортировка по времени последнего изменения;
- ls -S — сортировка по размеру файла;
- ls -l — длинный формат списка;
- ls -1 — по одному файлу в строке;
- ls -m — вывод через запятую;
- ls -Q — вывод в кавычках;
- cd — перейти в домашнюю директорию;
- pwd — показать текущую директорию;
- mkdir dir — создать директорию dir;
- cd dir — перейти в директорию dir;
- rm file — удалить файл;
- rm -r dir — удалить директорию dir (рекурсивно);
- rm -f file — принудительно удалить файл;
- rm -rf dir — удалить директорию dir (рекурсивно, без подтверждения);
- cp file1 file2 — скопировать file1 в file2;
- mv file1 file2 — переименовать file1 в file2;
- ln -s file link — создать символьную ссылку «link» на файл;
- touch file — создать или обновить файл;
- cat > file — поместить стандартный ввод в файл;
- more file — вывести содержимое файла;
- less file — вывести содержимое файла (с постраничным просмотром);
- head file — вывести первые 10 строк файла;
- tail file — вывести последние 10 строк файла.

3. File permissions (команды управления правами доступа к файлам):
- chmod 775 file — изменить права доступа файла на 775;
- chmod -R 600 folder — рекурсивно изменить права доступа папки на 600;
- chown user.group file — изменить владельца файла на user и группу на group.

4. Process management (управление процессами):
- ps — показать снимок процессов;
- top — показать процессы в реальном времени;
- kill pid — завершить процесс с ID pid;
- pkill name — завершить процесс по имени name;
- killall name — завершить все процессы, имена которых начинаются с name.

5. Searching (поиск):
- grep pattern files — поиск шаблона в файлах;
- grep -i — поиск без учёта регистра;
- grep -r — рекурсивный поиск;
- grep -v — инвертированный поиск (показать строки, где шаблон не найден);
- grep -o — показать только совпадающую часть файла;
- find /dir/ -name name* — найти файлы, начинающиеся с name в директории /dir/.

6. Network (сетевые команды):
- ping host — отправить пинг на хост host;
- dig domain — получить DNS для домена;
- dig -x host — обратный поиск по хосту;
- wget file — скачать файл;
- wget -c file — продолжить прерванную загрузку;
- wget -r url — рекурсивно скачать файлы с URL.

7. SSH (команды SSH):
- ssh user@host — подключиться к хосту как пользователь user;
- ssh -p port user@host — подключиться, используя порт p;
- ssh -D port user@host — подключиться и использовать бинд-порт.

8. Installation (команды установки):
- ./configure — настройка перед компиляцией;
- make — компиляция программы;
- make install — установка скомпилированной программы.

Стратегии совместного использования кода
(продолжение в следующем посте)

Стратегии совместного использования кода
(продолжение предыдущего поста)

Есть 4 основные стратегии совместного использования кода в микросервисной архитектуре: Code Replication (Кодовое дублирование), Shared Library (Общая библиотека), Shared Service (Общий сервис) и Sidecar (Сайдкар). Рассмотрим каждую из них подробно.

#### 1. Code Replication (Кодовое дублирование)

Суть: код, необходимый нескольким сервисам, копируется (дублируется) в каждый из них. На схеме видно, что SERVICE A, SERVICE B и SERVICE C содержат копию SHARED CODE.

Преимущества:
* простота реализации — не требует дополнительных инфраструктурных решений;
* автономность сервисов — каждый сервис содержит весь необходимый код локально;
* отсутствие сетевых задержек, связанных с обращением к внешним ресурсам.

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

Когда использовать: подходит для небольших проектов или случаев, когда код используется редко и не требует частого обновления.

#### 2. Shared Library (Общая библиотека)

Суть: сервисы используют общую библиотеку кода. На схеме показано, что SERVICE A, SERVICE B и SERVICE C подключают модули (SC1, SC2, SC3, SC4, SC5) из общей библиотеки.

Преимущества:
* уменьшение объёма кода за счёт его централизации;
* упрощение поддержки — обновления вносятся в одном месте;
* возможность повторного использования кода между сервисами;
* поддержка версий библиотеки позволяет контролировать совместимость.

Недостатки:
* зависимость сервисов от общей библиотеки может усложнить развёртывание и обновление;
* необходимость синхронизации версий библиотеки между сервисами;
* риск конфликтов зависимостей, если сервисы используют разные версии библиотеки.

Когда использовать: оптимально для проектов с большим количеством сервисов, использующих общий функционал (например, библиотеки для логирования, трассировки, работы с API).

#### 3. Shared Service (Общий сервис)

Суть: вместо включения кода в сервисы или использования библиотек, сервисы обращаются к отдельному общему сервису по сети. На схеме SERVICE A, SERVICE B и SERVICE C делают сетевые вызовы к SHARED SERVICE.

Преимущества:
* полная изоляция логики — общий сервис можно обновлять независимо от клиентских сервисов;
* централизованное управление функционалом (например, аутентификация, кэширование, обработка платежей);
* масштабируемость — общий сервис можно масштабировать отдельно от клиентских сервисов;
* упрощение развёртывания новых сервисов — достаточно добавить вызов к общему сервису.

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

Когда использовать: подходит для критических сервисов с высокой нагрузкой (например, сервис аутентификации, платёжный шлюз), где важна централизованная логика и масштабируемость.

#### 4. Sidecar (Сайдкар)

Суть: отдельный процесс (сайдкар) запускается вместе с сервисом и предоставляет ему дополнительные функции. На схеме SERVICE A и SERVICE B работают вместе с SIDECAR, который отвечает за логирование, мониторинг, работу с Circuit Breaker и другие задачи.

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

Недостатки:
* усложнение развёртывания — нужно управлять двумя процессами (сервис + сайдкар);
* дополнительные ресурсы — сайдкар потребляет ресурсы наравне с основным сервисом;
* необходимость синхронизации работы сервиса и сайдкара.

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

### Резюме

Выбор стратегии зависит от:
* сложности и объёма общего кода;
* требований к масштабируемости и надёжности;
* архитектуры существующей системы;
* необходимости изоляции бизнес-логики от инфраструктурных задач.

Code Replication — для простых случаев с малым объёмом кода.
Shared Library — для повторного использования кода с умеренной сложностью.
Shared Service — для критически важных централизованных функций.
Sidecar — для добавления инфраструктурных возможностей к существующим сервисам.

Основные команды Linux для получения информации о системе
(продолжение предыдущего поста)

1. Отобразить информацию о ядре и архитектуре системы:
uname -a

2. Показать информацию о CPU:
cat /proc/cpuinfo

3. Отобразить использование памяти (RAM):
free -h

4. Получить время работы системы (uptime):
uptime

5. Показать детализированное использование системных ресурсов:
top

6. Отобразить использование диска для всех смонтированных файловых систем:
df -h

7. Проверить текущее использование диска по директориям:
du -sh *

8. Показать информацию об устройствах PCI:
lspci

9. Отобразить информацию об USB-устройствах:
lsusb

10. Показать информацию о сетевых интерфейсах:
ifconfig

11. Отобразить сообщения ядра (полезно для отладки оборудования):
dmesg | less

12. Проверить системные журналы (для недавней активности/ошибок):
tail -f /var/log/syslog

13. Отобразить информацию об блочных устройствах (диски, разделы):
lsblk

14. Вывести список всех загруженных модулей ядра:
lsmod

15. Показать имя хоста системы:
hostname

16. Отобразить активных пользователей:
who

17. Проверить запущенные процессы:
ps aux

18. Показать статус батареи (для ноутбуков):
upower -i /org/freedesktop/UPower/devices/battery_BATO

19. Отобразить журнал загрузки системы:
journalctl -b

20. Показать общий обзор аппаратного обеспечения системы:
lshw

Порядок выполнения команд в запросе SQL #sql

5 HTTP-статусных кодов, которые "не должны были существовать"
(продолжение в следующем посте)

5 HTTP-статусных кодов, которые "не должны были существовать"
(продолжение предыдущего поста)

Многие так или иначе знакомы с протоколом HTTP и его статусными кодами. Однако мало кто знает, что есть 5 кодов состояния HTTP, которые являются необычными, забавными или проблематичными - грубо говоря, статусные коды, которые "не должны были существовать"

1. 451 — "Unavailable for legal reasons" (Недоступно по юридическим причинам)
- Используется, когда доступ к запрашиваемому ресурсу запрещён по юридическим причинам.
- Некоторые сайты применяли этот код, чтобы избежать соблюдения законодательных требований, например, GDPR.
- Символика: изображение молотка, отсылающее к судебной тематике.

2. 218 — "This is fine!" (Это нормально!)
- Код вдохновлён популярным интернет-мемом, в котором изображён горящий дом и невозмутимый пёс с подписью "This is fine!".
- Указывает, что ошибка не должна перехватываться сервером — она передаётся клиенту.
- Применяется для обхода переопределений ошибок веб-сервера Apache.
- Символика: улыбающийся смайлик с поднятым вверх большим пальцем.

3. 420 — "Enhance your calm" (Успокойтесь)
- Нестандартный код, который буквально просит клиента "успокоиться".
- Изначально использовался Twitter для обозначения ситуаций, когда клиент превышал лимиты запросов (rate limits).
- Впоследствии заменён на стандартный код 429 (Too Many Requests).
- Символика: изображение человека в позе медитации, подчёркивающее идею "успокоения".

4. 530 — "Site Frozen" (Сайт заморожен)
- Применяется, когда сайт остаётся работоспособным, но намеренно заблокирован провайдером.
- Используется компанией Pantheon (облачный провайдер) для обозначения заблокированных сайтов — например, из-за неоплаченных счетов или истёкших пробных периодов.
- Символика: изображение веб-страницы с морозными узорами, визуально отображающее "заморозку".

5. 418 — "I’m a teapot" (Я — чайник)
- Появился как шутка ко Дню смеха (April Fool’s Day) в 1998 году.
- Символизирует сервер, который не способен "сварить кофе" (выполнить запрошенное действие).
- Несмотря на шуточный характер, код был поддержан основными реализациями HTTP.
- Даже породил шуточное "социальное движение" — Save 418 movement.
- Символика: изображение чайника, подчёркивающее юмористический характер кода.

Паттерн Event Sourcing (источники событий)
(продолжение в следующем посте)

Паттерн Event Sourcing (источники событий)
(продолжение предыдущего поста)

Event Sourcing (источники событий) — это архитектурный паттерн, при котором изменения состояния системы сохраняются в виде последовательного лога событий (событийного журнала), а не напрямую в виде состояния сущностей. Этот подход позволяет воссоздать текущее или историческое состояние системы, воспроизводя события в хронологическом порядке.

Разберём принцип работы по изображению:

1. App (Приложение): инициирует операции (Operations), которые преобразуются в события.

2. Event Store (Хранилище событий):
* служит центральным хранилищем, где последовательно сохраняются все события, происходящие в системе;
* события хранятся в неизменяемом (immutable) виде — их нельзя удалить или изменить, только добавить новые;
* это "источник истины" для всей системы.

3. Event Store Consumer (Потребитель хранилища событий):
* считывает события из хранилища (Consume Event);
* применяет события для формирования текущего состояния системы;
* обновляет Current State DB (БД текущего состояния) — оптимизированную базу данных для быстрого доступа к актуальному состоянию сущностей.

4. Current State DB (БД текущего состояния):
* содержит актуальное состояние системы, сформированное на основе событий;
* используется для быстрых операций чтения (например, отображения данных пользователю).

5. Replay Processor (Процессор воспроизведения):
* позволяет "перепроиграть" события из хранилища для воссоздания состояния системы на любой момент времени (Point in Time — PIT);
* полезен для отката изменений, аудита, восстановления после сбоев или анализа истории изменений.

6. Point in Time DB (БД момента времени):
* хранит состояния системы на определённые моменты времени (снимки состояния);
* позволяет быстро получить состояние системы "на дату", без необходимости полного перебора событий.

Ключевые особенности Event Sourcing:
* Децентрализованное изменение и чтение данных — события могут обрабатываться асинхронно разными компонентами системы.
* Аудит и история изменений — полный лог событий позволяет отследить, кто, когда и какие изменения вносил.
* Возможность отката — при ошибках или необходимости можно "откатить" систему до предыдущего корректного состояния.
* Масштабируемость — событийный лог легко горизонтально масштабируется.
* Сочетание с CQRS — часто используется вместе с паттерном CQRS (Command Query Responsibility Segregation) для разделения команд (изменений) и запросов (чтения).

Примеры применения:
* финансовые системы (где важна история транзакций);
* системы электронной коммерции (отслеживание изменений корзины, заказов);
* CRM-системы (логирование изменений статусов клиентов);
* игровые платформы (сохранение прогресса игрока).

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

Аутентификация на основе токенов и HMAC
(продолжение в следующем посте)

Аутентификация на основе токенов и HMAC
(продолжение предыдущего поста)

Аутентификация на основе токенов и аутентификация HMAC являются распространенными формами аутентификации. Посмотрим, в чем они различаются.

1. Принцип работы

- Аутентификация на основе токенов (Token-based authentication):
1. Клиент отправляет логин и пароль на Authentication Server.
2. Сервер аутентификации генерирует токен (уникальную строку) и передаёт его клиенту.
3. Клиент включает токен в заголовки HTTP-запросов к Web Server при обращении к ресурсам.
4. Web Server проверяет валидность токена и, если он действителен, предоставляет доступ к ресурсу.

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

- Аутентификация на основе HMAC (HMAC authentication):
1. Клиент запрашивает API key у Authentication Server.
2. Сервер передаёт клиенту API key (секретный ключ).
3. Клиент генерирует HMAC-подпись (hmac A) на стороне клиента, используя API key и параметры запроса (например, URI, метод HTTP, временная метка).
4. Клиент отправляет запрос к Web Server вместе с HMAC-подписью.
5. Web Server генерирует свою HMAC-подпись (hmac B) с теми же параметрами, используя свой экземпляр API key.
6. Web Server сравнивает hmac A (от клиента) и hmac B (собственно сгенерированный). Если подписи совпадают — запрос считается аутентифицированным.
7. При успешной проверке клиент получает доступ к ресурсу.

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

2. Используемые механизмы безопасности

- Токены:
- Используют систему «выдать и использовать» (token issuance and validation).
- Токены могут быть JWT (JSON Web Tokens) с подписями, которые содержат метаданные (истечение срока действия, идентификатор пользователя и т. д.).
- Защита строится на валидации подписи токена и его срока действия.

- HMAC:
- Основан на криптографической функции HMAC (Hash-based Message Authentication Code), которая сочетает хэш-функцию и секретный ключ.
- Гарантирует целостность данных (данные не изменены в пути) и аутентичность отправителя (только владелец секретного ключа может сгенерировать корректную подпись).
- Секретный ключ никогда не передаётся в открытом виде — только используется для генерации подписей.

3. Этапы взаимодействия

- Токены: 4 основных шага (вход → получение токена → отправка запросов с токеном → доступ к ресурсу).
- HMAC: 7 шагов, включая генерацию и сравнение подписей (запрос API key → генерация подписи клиентом → отправка запроса → генерация подписи сервером → сравнение подписей → доступ к ресурсу).

4. Уровень сложности и вычислительных затрат

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

5. Сценарии применения

- Токены: подходят для веб-приложений, мобильных приложений, где важна простота и скорость аутентификации. Часто используются в REST API, SPA (Single Page Applications).
- HMAC: предпочтителен для API, где критична безопасность (финансовые сервисы, платёжные системы), а также для микросервисов, где требуется строгая проверка целостности запросов.

6. Уязвимости и защита

- Токены: уязвимы к перехвату (если не используются защищённые каналы, например, HTTPS). JWT могут быть подвержены атакам, если подпись не проверена должным образом.
- HMAC: более устойчив к перехвату, так как даже зная запрос, злоумышленник не сможет сгенерировать корректную подпись без секретного ключа. Однако требует строгой защиты API key.

Краткое резюме:
- Токены — удобны и быстры, но менее безопасны.
- HMAC — более сложен в реализации, но обеспечивает высокий уровень защиты за счёт криптографической проверки целостности и подлинности. Выбор зависит от требований к безопасности и архитектуры системы.

Типы криптографии
(описание в следующем посте)

Типы криптографии
(продолжение предыдущего поста)

В зависимости от устойчивости к квантовым вычислениям криптография делится на два основных класса:
1. Quantum-breakable (уязвимые для квантовых атак).
2. Quantum-secure (устойчивые к квантовым атакам).

#### 1. Quantum-breakable (уязвимые для квантовых атак)

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

- RSA encryption (шифрование RSA):
- Сообщение шифруется с помощью публичного ключа получателя.
- Расшифровывается с помощью приватного ключа.
- Безопасность основана на сложности разложения на простые множители (вычисления приватного ключа из публичного).

- Diffie-Hellman key exchange (обмен ключами Диффи-Хеллмана):
- Два участника совместно создают общий секретный ключ по незащищённому каналу.
- Этот ключ используется для зашифрованной коммуникации.
- Безопасность основана на сложности задачи дискретного логарифма.

- Elliptic curve cryptography (криптография на эллиптических кривых):
- Используются математические свойства эллиптических кривых для генерации публичных и приватных ключей.
- Сложность восстановления приватного ключа из публичного связана с задачей дискретного логарифма на эллиптических кривых.

#### 2. Quantum-secure (устойчивые к квантовым атакам)

Эти методы разработаны для защиты от потенциальных квантовых атак. К ним относятся:

- Lattice-based cryptography (решётчатая криптография):
- Безопасность основана на сложности нахождения ближайшей точки в решётке с сотнями пространственных измерений.
- Приватный ключ ассоциируется с точкой решётки, а публичный — с произвольной точкой в пространстве.

- Code-based cryptography (криптография на основе кодов):
- Приватный ключ связан с кодом, исправляющим ошибки.
- Публичный ключ — это искажённая и ошибочная версия этого кода.
- Безопасность основана на сложности декодирования общего линейного кода.

- Multivariate cryptography (многомерная криптография):
- Основана на сложности решения систем многомерных полиномиальных уравнений.
- Использует сложные математические конструкции для обеспечения безопасности.

Резюме:
- Quantum-breakable методы эффективны сейчас, но уязвимы для будущих квантовых компьютеров.
- Quantum-secure методы разрабатываются для защиты данных в эпоху квантовых вычислений.

Полная шпаргалка по командам Docker
(продолжение предыдущего поста)

#### 1. Установка (Installation)
- Установка Docker Engine (только для Linux): [https://docs.docker.com/engine/install/](https://docs.docker.com/engine/install/).
- Установка Docker Desktop (Linux, macOS, Windows): [https://docs.docker.com/desktop/](https://docs.docker.com/desktop/).

#### 2. Команды для работы с контейнерами (Container commands)
- `docker run <image>` — создаёт и запускает новый контейнер.
- `docker run -p 8080:80 <image>` — публикует порт контейнера (80) на порт хоста (8080).
- `docker run -d <image>` — запускает контейнер в фоновом режиме (detached mode).
- `docker run -v <host>:<container> <image>` — монтирует директорию хоста в контейнер.
- `docker ps` — выводит список запущенных контейнеров.
- `docker ps --all` — выводит список всех контейнеров (запущенных и остановленных).
- `docker logs <container_name>` — получает логи контейнера.
- `docker logs -f <container_name>` — получает логи и следит за их обновлением в реальном времени (follow).
- `docker stop <container_name>` — останавливает запущенный контейнер.
- `docker start <container_name>` — запускает остановленный контейнер.
- `docker rm <container_name>` — удаляет контейнер.

#### 3. Выполнение команд внутри контейнера (Executing commands in a container)
- `docker exec <container_name> <command>` — выполняет команду внутри запущенного контейнера.
- `docker exec -it <container_name> bash` — открывает оболочку (shell) внутри запущенного контейнера для интерактивного взаимодействия.

#### 4. Команды для работы с образами (Image commands)
- `docker build -t <image> .` — создаёт новый образ из Dockerfile в текущей директории и присваивает ему тег (tag).
- `docker images` — выводит список локальных образов.
- `docker rmi <image>` — удаляет образ.

#### 5. Команды для работы с реестром контейнеров (Container registry commands)
- `docker login` — авторизуется в Docker Hub.
- `docker login <server>` — авторизуется в другом реестре контейнеров.
- `docker logout` — выходит из Docker Hub.
- `docker logout <server>` — выходит из другого реестра контейнеров.
- `docker push <image>` — загружает образ в реестр.
- `docker pull <image>` — скачивает образ из реестра.
- `docker search <image>` — ищет образы в Docker Hub.

#### 6. Системные команды (System commands)
- `docker system df` — показывает использование дискового пространства Docker.
- `docker system prune` — удаляет неиспользуемые данные (например, остановленные контейнеры, несуществующие образы).
- `docker system prune -a` — удаляет все неиспользуемые данные (включая остановленные контейнеры и образы).

#### 7. Команды Docker Compose
- `docker compose up` — создаёт и запускает контейнеры.
- `docker compose up -d` — создаёт и запускает контейнеры в фоновом режиме.
- `docker compose up --build` — пересобирает образы перед запуском контейнеров.
- `docker compose stop` — останавливает сервисы.
- `docker compose down` — останавливает и удаляет контейнеры и сети.
- `docker compose ps` — выводит список запущенных контейнеров.
- `docker compose logs` — показывает логи всех контейнеров.
- `docker compose logs <service>` — показывает логи конкретного сервиса.
- `docker compose logs -f` — показывает логи и следит за их обновлением.
- `docker compose pull` — скачивает последние образы.
- `docker compose build` — собирает или пересобирает сервисы.
- `docker compose build --pull` — скачивает последние образы перед сборкой.