Bash Ready | Linux

🌐 Понимание REST API — как общаются современные сервисы? Когда вы заказываете еду через приложение, проверяете прогноз погоды или авторизуетесь на сайте через Google, под капотом происходит одно и то же: разные программы общаются друг с другом. Самый популярный стандарт для такого общения — архитектурный стиль REST (Representational State Transfer). В основе REST API лежит простая концепция: всё в системе является ресурсом (пользователь, заказ, статья, картинка). У каждого ресурса есть свой уникальный адрес (URL). Например, /api/v1/users — это адрес, по которому живут данные всех пользователей. Чтобы совершить действие с ресурсом, клиент (браузер или мобилка) отправляет серверу стандартный HTTP-запрос, используя определенный метод (глагол). Основные методы REST API: — GET — получить данные (например, открыть список постов). Этот метод безопасен: он не должен ничего менять в базе. — POST — создать новый ресурс (например, зарегистрировать пользователя или опубликовать новый пост). — PUT / PATCH — обновить существующие данные. PUT обычно заменяет ресурс целиком, а PATCH — меняет только отдельные поля. — DELETE — удалить ресурс. Зачем это инженеру? REST делает систему гибкой и масштабируемой. Бэкенд, написанный на Python (FastAPI / Django), ничего не знает о том, как устроен фронтенд. Он просто принимает запросы и возвращает структурированный ответ — обычно в формате JSON. Пример JSON-ответа от сервера: { "id": 42, "username": "python_developer", "status": "active" } Благодаря такому разделению вы можете полностью переписать мобильное приложение, но если структура REST API (эндпоинты и формат данных) осталась прежней, бэкенд даже не заметит изменений. После обработки запроса сервер обязательно возвращает код ответа (HTTP Status Code), чтобы клиент сразу понял, что произошло: — 2xx (например, 200 OK, 201 Created) — всё прошло успешно. — 4xx (например, 400 Bad Request, 404 Not Found) — ошибка на стороне клиента (неверные данные, ресурс не существует). —

🗄️ Хранилища Key-Value — зачем бэкенду нужен Redis? В классических базах данных вроде PostgreSQL или MySQL данные лежат в таблицах на жестком диске. Это надежно, но медленно, если запрашивать их тысячи раз в секунду. Когда приложению нужна максимальная скорость, на сцену выходит Redis — высокопроизводительная СУБД типа «ключ-значение», которая хранит все данные прямо в оперативной памяти (In-Memory). В Redis нет таблиц, строк и сложных SQL-запросов. Вся работа строится вокруг пар данных: вы записываете значение по определенному ключу, а затем мгновенно извлекаете его. Скорость чтения и записи в Redis измеряется микросекундами, что позволяет обрабатывать сотни тысяч запросов в секунду на скромном железе. Два главных сценария использования Redis: — Кэширование: Вместо того чтобы при каждом визите пользователя делать тяжелый запрос к основной базе (например, вытягивать каталог товаров), вы один раз сохраняете результат в Redis. При следующем запросе приложение забирает данные из кэша за доли миллисекунды. — Хранение сессий: Токены авторизации и сессии пользователей идеально подходят для Redis. При каждом клике на сайте бэкенд проверяет, валиден ли токен. Делать эту проверку через оперативную память гораздо эффективнее. Зачем это инженеру? Redis избавляет основную базу от перегрузок. У Redis есть встроенный механизм TTL (Time To Live) — вы можете указать время жизни для любого ключа, например, 10 минут: SET user_session_123 "active" EX 600 По истечении этого времени Redis сам удалит ключ, автоматически очистив память. Это избавляет разработчика от необходимости писать логику очистки старого кэша вручную. Помимо простых строк, Redis из коробки поддерживает сложные структуры данных: списки, хэши, множества (Sets) и даже сортированные множества. Благодаря этому его часто используют не только как кэш, но и как брокер сообщений для очередей задач или для реализации счетчиков в реальном времени (например, просмотры статьи или лимиты запросов к API). Главный минус Re

🐳 Очистка Docker — как вернуть гигабайты дискового пространства Docker — потрясающий инструмент, но у него есть вредная привычка: он незаметно пожирает место на жестком диске. Вы обновили код, пересобрали образ, запустили новый контейнер — а старые слои, неиспользуемые тома и остановленные контейнеры остались лежать мертвым грузом. Со временем эта «свалка» может забить диск сервера на 100%, что приведет к падению всех приложений. Когда вы пересобираете образ, старые слои теряют связь с тегами и превращаются в так называемые dangling (зависшие) образы. В выводе команды docker images они отображаются со странными именами <none>:<none>. Сами по себе они уже никогда не очистятся. Главная команда для генеральной уборки: docker system prune Эта команда в один клик удаляет: — Все остановленные контейнеры. — Все неиспользуемые сети (networks). — Все «зависшие» (<none>:<none>) образы и кэш сборки. Если вы хотите пойти дальше и снести вообще все неиспользуемые образы (даже те, у которых есть нормальные теги, но которые сейчас просто не запущены), добавьте флаг -a: docker system prune -a Зачем это инженеру? Для предотвращения критических сбоев. Но здесь кроется важный нюанс: по умолчанию docker system prune не трогает тома (Volumes). И это сделано ради вашей безопасности, ведь в томах хранятся боевые данные — например, файлы вашей базы данных PostgreSQL или Redis. Если вы уверены, что на локальной машине или тестовом сервере вам больше не нужны старые объемы данных, их нужно удалять принудительно, добавив специальный флаг: docker system prune --volumes Или точечно через команду docker volume prune. Чтобы держать сервер в тонусе и не доводить диск до критической отметки, опытные админы не чистят всё руками. Они один раз настраивают уже знакомый нам планировщик Cron, добавляя туда задачу выполнять автоматическую базовую очистку docker system prune -f (флаг -f убирает подтверждение y/n) раз в неделю. Регулярный мониторинг свободного места с помощью команды df -

⚙️ Переменные окружения — как правильно хранить секреты проекта Никогда не пишите пароли от баз данных, токены Telegram-ботов и секретные ключи API прямо в коде (хардкод). Если вы случайно выложите такой проект в публичный репозиторий на GitHub, злоумышленники найдут ключи за пару минут с помощью автоматических парсеров. Для безопасного управления конфигурацией используют переменные окружения (Environment Variables или env). Переменные окружения — это динамические значения, которые живут внутри операционной системы или конкретной терминальной сессии, отдельно от вашего приложения. Код просто обращается к системе и забирает нужные настройки на лету. В процессе разработки стандартным решением является использование файла **.env, который создается в корне проекта. Пример структуры файла .env:** DATABASE_URL=postgresql://user:secret_pass@localhost:5432/mydb BOT_TOKEN=123456789:ABCdefGhIJKlmNoPQRsTUVwxyZ DEBUG=True Критически важно: файл .env должен быть обязательно добавлен в ваш файл .gitignore, чтобы он ни при каких обстоятельствах не попал в Git. Для команды вместо этого создают файл-шаблон .env.example, где оставляют только названия переменных без реальных секретных данных. Зачем это инженеру? Это делает приложение гибким и безопасным. В экосистеме Python для удобной работы с переменными окружения используют библиотеки вроде python-dotenv или встроенные механизмы Pydantic (pydantic-settings). Пример чтения переменных в коде Python: import os from dotenv import load_dotenv # Загружаем переменные из файла .env в окружение load_dotenv() # Достаем значения db_url = os.getenv("DATABASE_URL") bot_token = os.getenv("BOT_TOKEN") # Второй аргумент — значение по умолчанию, если переменная не найдена debug_mode = os.getenv("DEBUG", "False") == "True" Такой подход позволяет использовать один и тот же код в разных средах без его изменения. Локально на компьютере вы используете .env с тестовой базой данных, на стейджинг-сервере прописываете другие значения, а на п

📡 Протокол WebSocket — двусторонняя связь в реальном времени Классический HTTP работает по принципу «запрос-ответ»: клиент (браузер) просит данные, сервер их отдает, и соединение закрывается. Но что делать, если вам нужно построить чат, онлайн-игру или живой график котировок криптовалют? Заставлять браузер каждую секунду слать HTTP-запросы — дико неэффективно. Для таких задач используют протокол WebSocket. В отличие от HTTP, WebSocket создает одно постоянное, открытое соединение между клиентом и сервером. Обе стороны могут отправлять друг другу данные в любой момент времени без лишних заголовков и задержек. Как устроен жизненный цикл WebSocket: — Handshake (Рукопожатие): Клиент отправляет обычный HTTP-запрос с особыми заголовками, говоря серверу: «Давай перейдем на WebSocket». — Upgrade: Если сервер согласен, соединение «апгрейдится» (статус код 101 Switching Protocols). — Двусторонний обмен: Канал открыт. Теперь данные летают туда и обратно в виде легких фреймов. — Закрытие: Любая сторона может закрыть соединение в любой момент. Зачем это инженеру? Ради мгновенной реакции и экономии ресурсов. В HTTP каждый запрос тянет за собой кучу служебной информации (куки, заголовки браузера, тип контента), которая может весить больше, чем полезные данные. В WebSocket после установки соединения накладные расходы составляют всего несколько байт на сообщение. В экосистеме Python работать с WebSocket невероятно удобно через фреймворк FastAPI. Он из коробки предоставляет простой синтаксис для управления такими соединениями. Пример простейшего WebSocket-сервера на FastAPI: from fastapi import FastAPI, WebSocket app = FastAPI() @app.websocket("/ws") async def websocket_endpoint(websocket: WebSocket): await websocket.accept() # Принимаем соединение while True: # Ждем сообщение от клиента data = await websocket.receive_text() # Тут же отправляем ответ назад await websocket.send_text(f"Сервер получил: {data}") WebSocket — это незаменим

📬 Брокеры сообщений — зачем вашему проекту Celery и RabbitMQ? Когда пользователь нажимает кнопку «Зарегистрироваться», ваш бэкенд должен сделать много дел: создать запись в базе данных, сгенерировать тяжелый PDF-договор, загрузить аватарку в облако и отправить приветственное письмо на почту. Если делать всё это в основном потоке веб-запроса, пользователь будет секунд 10 смотреть на крутящийся лоадер. Чтобы этого избегать, тяжелые задачи уводят в фоновый режим с помощью очередей задач. --- Для реализации такой схемы нужна связка из двух компонентов: Брокера сообщений (например, RabbitMQ или Redis) и Воркера (в мире Python это чаще всего Celery). Как устроена эта цепочка: — Веб-приложение (Producer): Быстро сохраняет юзера в базу, кидает короткую задачу вроде «отправь письмо юзеру №42» в брокер и тут же возвращает пользователю ответ 200 OK. Для юзера всё произошло мгновенно. — Брокер сообщений (RabbitMQ): Принимает эту задачу, складывает её в очередь и хранит, пока освободится исполнитель. — Воркер (Celery Worker): Постоянно слушает брокер, забирает задачу из очереди и спокойно выполняет её на фоне, не мешая основному сайту. Зачем это инженеру? Это кардинально повышает живучесть и скорость системы. Если сторонний сервис отправки писем вдруг «приляжет», ваше приложение не упадет. RabbitMQ сохранит задачу в очереди, а Celery будет пытаться отправить её снова и снова, пока сервис не оживет. Пользователь об этих проблемах даже не узнает. Пример кода на Python с использованием Celery: from celery import Celery # Инициализируем Celery и указываем RabbitMQ в качестве брокера app = Celery('tasks', broker='amqp://guest@localhost//') @app.task def send_welcome_email(user_id): # Тут логика генерации PDF и отправки тяжелого письма print(f"Письмо для пользователя {user_id} успешно отправлено!") В основном коде FastAPI или Django вы вызываете эту функцию не напрямую, а через специальный метод: send_welcome_email.delay(user_id). Слово .delay() как раз и дает кома

🛡️ Мидлвары — как фильтровать веб-запросы на подлете к коду? Представьте, что у вас в приложении на FastAPI, Django или Node.js есть 50 разных эндпоинтов. Для каждого из них нужно проверять, авторизован ли пользователь, логировать время обработки запроса и добавлять защитные заголовки. Писать этот код вручную внутри каждой функции — кошмар для поддержки. Чтобы решать такие сквозные задачи в один клик, используют Middleware (промежуточное ПО). Мидлварь — это специальный слой-перехватчик, который встает прямо на пути сетевого запроса от клиента к вашему основному коду (роутам) и на обратном пути ответа от сервера к клиенту. через мидлварь проходит абсолютно каждый запрос. Вы можете выстроить целую цепочку из таких фильтров, где каждый слой отвечает за свою задачу. Как устроен жизненный цикл запроса с Middleware: — Клиент отправляет запрос к серверу. — Middleware 1 (Логирование): Записывает время старта и IP-адрес клиента, передает запрос дальше. — Middleware 2 (Авторизация): Достает токен из заголовков. Если токен битый — мидлварь сразу разворачивает запрос назад и отдает ошибку 401 Unauthorized, даже не беспокоя основной код приложения. — Ваш код (Роут): Если всё ок, выполняется логика приложения (например, выдача списка товаров) и формируется ответ. — Обратный путь: Ответ снова летит через все мидлвари в обратном порядке. Например, слой безопасности может прикрепить к нему CORS-заголовки. Зачем это инженеру? Это идеальное воплощение принципа DRY (Don't Repeat Yourself). Вместо дублирования проверок безопасности, вы выносите их на глобальный уровень. Пример кастомной мидлвари для подсчета времени запроса на FastAPI: import time from fastapi import FastAPI, Request app = FastAPI() @app.middleware("http") async def add_process_time_header(request: Request, call_next): start_time = time.time() # Передаем запрос дальше по цепочке к роуту response = await call_next(request) # Этот код выполнится уже на обратном пути ответа process_ti

📡 Веб-хуки — как заставить сервер самому звонить вашему коду? Когда вы создаете Telegram-бота, парсер или платежную систему, вашему коду нужно оперативно узнавать о новых событиях: пользователь отправил сообщение, пришла оплата на криптокошелек или обновилась котировка. У вас есть два пути: постоянно спамить чужой сервер запросами в цикле (Polling) или настроить Webhook (веб-хук). --- Polling — это когда ваш скрипт каждые две секунды спрашивает: «Ну что, есть новые данные? А сейчас? А теперь?». Это дико перегружает процессор, тратит сетевой трафик и создает кучу пустых запросов. Webhook работает ровно наоборот (принцип *Don't call us, we'll call you*). Вы один раз говорите стороннему сервису: «Вот адрес моего сервера (URL). Как только что-то произойдет — сам пришли мне данные». Как устроен процесс работы через Webhook: — Вы поднимаете простейший веб-сервер (например, на FastAPI) и создаете эндпоинт, готовый принимать POST-запросы (например, /api/v1/telegram-webhook). — Регистрируете этот URL в стороннем сервисе (через настройки API Telegram, платежки или GitHub). — Когда происходит событие, сторонний сервис сам формирует HTTP-запрос с JSON-пакетом внутри и отправляет его на ваш адрес. — Ваш код мгновенно ловит этот запрос, обрабатывает данные и возвращает статус 200 OK, подтверждая, что всё получено. Зачем это инженеру? Ради моментальной реакции и тишины в логах. С веб-хуками бот отвечает пользователю за миллисекунды, потому что он не ждет следующего цикла проверки, а реагирует на входящий триггер здесь и сейчас. Ваш сервер отдыхает, пока нет реальной активности. Пример обработки веб-хука на FastAPI: from fastapi import FastAPI, Request, Response app = FastAPI() @app.post("/webhook/payment") async def receive_payment_webhook(request: Request): # Получаем JSON с данными о транзакции payload = await request.json() event_type = payload.get("event") amount = payload.get("amount") if event_type == "payment.success": print(f

🛠️ Идемпотентность API — как защитить систему от дубликатов запросов? Представьте ситуацию: пользователь в мобильном приложении нажимает кнопку «Оплатить заказ». Клик улетает на бэкенд, списываются деньги, но в этот самый момент на телефоне на секунду пропадает связь. Приложение не получает ответ от сервера, считает, что произошел сбой, и автоматически отправляет запрос повторно. Если ваш бэкенд не обладает свойством идемпотентности, у пользователя спишутся деньги дважды. Идемпотентность в программировании — это свойство метода или всей системы выдавать один и тот же результат при многократных идентичных запросах. Сколько бы раз вы ни отправили один и тот же запрос, состояние системы изменится только один раз, а все последующие ответы будут точной копией первого успешного ответа. В стандартном REST API некоторые HTTP-методы идемпотентны по определению: — GET: сколько раз ни запрашивай профиль пользователя, он не изменится. — PUT / DELETE: если вы обновили имя на конкретное значение или удалили пост с id=5, повторные вызовы дадут тот же результат (пост останется удаленным). — POST: не идемпотентен. Каждый новый вызов по умолчанию пытается создать новую запись в базе данных. Именно с ним и возникают проблемы при дублировании сетевых пакетов. Как это правильно реализовать на практике: Самый надежный способ защитить неидемпотентные операции (например, создание транзакции или отправку сообщения) — использование специального ключа идемпотентности (Idempotency-Key). — Генерация ключа: Перед отправкой POST-запроса фронтенд (или клиент) генерирует уникальный UUID для этой операции и прикрепляет его в заголовки: Idempotency-Key: 7b9e84b2-a42e-4e1b-b461-9f9361ad2a48. — Проверка на бэкенде: Когда запрос приходит на сервер, бэкенд первым в цепочке (например, через Middleware) проверяет, есть ли такой ключ в быстром кэше (идеально подходит Redis со временем жизни ключа в 24 часа). — Если ключа нет: Сервер понимает, что это уникальный запрос. Он сохраняет ключ в Redis со ста

🔄 Пул соединений (Connection Pool) — как не положить базу данных при нагрузке Когда ваш Python-скрипт или веб-сервер делает запрос к базе данных (PostgreSQL, MySQL), под капотом происходит сложный процесс: приложение стучится к серверу базы по сети, проходит авторизацию, открывает сетевой сокет, выполняет SQL-запрос и закрывает соединение. Если на каждый клик пользователя открывать новое соединение с нуля, сервер моментально захлебнется. Решение этой проблемы — Connection Pool. Открытие нового соединения — это одна из самых «дорогих» и медленных операций в работе с базами данных. Приложении тратит драгоценное время процессора и сети еще до того, как выполнит сам SQL-код. Пул соединений работает по принципу кэширования: при старте приложения создается фиксированное количество готовых, уже авторизованных сетевых подключений к базе (например, 10–20 штук), которые удерживаются в памяти в активном состоянии. Как устроен жизненный цикл запроса с Connection Pool: — Запрос к базе: Когда вашему коду нужно вытянуть данные, он не создает новое подключение, а просит пул выдать одно из свободных. — Выполнение кода: Приложение мгновенно получает готовый сокет, выполняет SQL-запрос и забирает результат. — Возврат в пул: Вместо закрытия соединения (connection.close()), код просто возвращает его обратно в пул. Оно остается открытым и ждет следующего пользователя. Зачем это инженеру? Чтобы защитить базу от падения и ускорить приложение в разы. У любой СУБД (например, PostgreSQL) есть жесткий лимит на максимальное количество одновременных подключений (max_connections). Если 500 пользователей одновременно зайдут на сайт без пула, база выдаст ошибку Too many connections и сайт упадет. Пул выступает в роли умного диспетчера. В экосистеме Python при работе с асинхронным бэкендом (FastAPI / SQLAlchemy) пул соединений настраивается автоматически прямо при создании движка (Engine). Пример настройки пула в SQLAlchemy: from sqlalchemy.ext.asyncio import create_async_engine DATABASE_UR

⚙️ Графическое вычисление (GPU) против Центрального процессора (CPU) — когда бэкендеру нужны видеокарты? Когда речь заходит об ускорении работы скриптов или сервисов, первая мысль разработчика — оптимизировать алгоритм или разложить задачи по ядрам процессора (CPU). Но бывают задачи, где даже самый мощный серверный процессор начинает безбожно тормозить. В этот момент тяжелые вычисления переносят на видеокарты (GPU). --- CPU (Центральный процессор) — это «мозг» компьютера, спроектированный для решения общих и сложных последовательных задач. У него относительно мало ядер (обычно от 4 до 64), но каждое ядро невероятно мощное, имеет высокую тактовую частоту и огромный кэш. CPU отлично справляется с ветвлением логики (if/else), управлением операционной системой, работой баз данных и выполнением стандартного кода вашего приложения. GPU (Графический процессор) — устроен совершенно иначе. Он создавался для отрисовки графики и работы с 3D, где нужно одновременно просчитывать цвет миллионов пикселей на экране. Для этого вместо нескольких мощных ядер в него упаковали тысячи мелких, простых ядер, работающих параллельно. Главные отличия в архитектуре вычислений: — Параллелизм: CPU обрабатывает задачи последовательно (или в несколько мощных потоков). GPU берет массив данных и обрабатывает тысячи элементов одновременно по одной и той же инструкции (архитектура SIMD — *Single Instruction, Multiple Data*). — Сложность операций: Ядро GPU не умеет эффективно выполнять сложную логику со множеством ветвлений. Его стихия — простая, однотипная математика: умножение матриц и работа с векторами. Зачем это инженеру? Чтобы понимать, в какой момент архитектуру проекта нужно дополнить видеокартами. Если вы пишете стандартное REST API или парсер — GPU вам ничем не поможет. Но есть три сферы, где без видеокарт проект просто не запустится: — Искусственный интеллект и Нейросети (AI/ML): Обучение моделей и генерация (будь то текст в LLM или картинки в Stable Diffusion) — это чистая линейная

Проверка времени отклика сервисов Когда сервис работает, но пользователи жалуются на медлительность, нужно мерить не аптайм, а отклик. Это легко сделать обычным curl. ▪️ Самый простой замер time curl -s https://bashtex.com > /dev/null Показывает общее время выполнения запроса и быстро понять, тормозит или нет. ▪️ Точнее: только сетевое время curl -s -o /dev/null -w "time_total: %{time_total}\n" https://bashtex.com Полезные метрики: time_namelookup time_connect time_starttransfer time_total Пример: curl -w "DNS:%{time_namelookup} CONNECT:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" \ -o /dev/null -s https://bashtex.com ▪️ Проверка нескольких сервисов for url in https://a.ru https://b.ru; do curl -o /dev/null -s -w "$url %{time_total}\n" "$url" done ▪️ Таймаут обязателен curl --connect-timeout 3 --max-time 5 https://bashtex.com Без таймаута любой мониторинг бесполезен.

Поиск забытых .ssh директорий После чистки пользователей в системе нередко остаются их .ssh-каталоги. Это мусор + потенциальная дыра: старые ключи могут лежать годами. ▪️ Быстрый поиск по системе find / -type d -name .ssh 2>/dev/null Найдет все .ssh, включая: /home/*/.ssh /root/.ssh нестандартные каталоги ▪️ Проверяем, существует ли владелец find / -type d -name .ssh -exec stat -c '%U %n' {} \; Если владелец: UNKNOWN или пользователь отсутствует в /etc/passwd то каталог подозрительный. ▪️ Поиск .ssh без пользователя while read user path; do id "$user" &>/dev/null || echo "Лишний: $path" done < <(find / -type d -name .ssh -exec stat -c '%U %n' {} \;) ⚠️ Перед удалением лучше сделать архив

Циклы while vs for - где что правильно В bash оба цикла нужны, но для разных задач. Путаница между ними - источник проблем. ▪️ for - перебор готового списка. Используй, когда список уже есть. for f in *.log; do echo "$f" done файлы; аргументы "$@"; элементы массива. ⚠️ Пример ошибок: for f in $(ls *.log); do # ломается на пробелах ▪️ while - поток данных. Идеален для чтения ввода. while IFS= read -r line; do echo "$line" done < file.txt строки с пробелами; вывод команд; большие файлы. ⚠️ Частая ошибка: cat file | while read line; do count=$((count+1)) # переменная пропадёт done (цикл в subshell!) for не является универсальным, а while безопаснее для данных. Перед созданием цикла нужно задавать себе вопрос: список или поток.

🧠 Быстрый просмотр SSL-сертификата домена Нужно быстро проверить срок действия SSL-сертификата у удалённого сайта без браузера? echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates 📌 Покажет строки вида: notBefore=Jun 1 00:00:00 2024 GMT notAfter=Aug 30 23:59:59 2024 GMT 🔒 Хочешь только дату окончания? Добавь | grep notAfter 📦 Убедись, что установлен openssl 💡 Подходит для мониторинга и ручной проверки валидности сертификатов.