200 тыс.₽ сейчас РЕАЛЬНО базовый минимум ⏺️

Который нужен для комфортной жизни в любом месте⤵️

Не знаешь, где словить такой куш?

Удаленка в долларах 💸 — канал для профи из СНГ с вакансиями в стабильной валюте.

IT, маркетинг, дизайн, крипта: ты точно в этом разбираешься

Осталось только начать нормально зарабатывать!

15+ актуальных вакансий за сегодня уже в канале:
https://t.me/+qoCsrhInumQyN2Ni 🔗

🔐 Секреты в безопасности — управляем переменными окружения и .env!

Когда вы пишете код, велик соблазн вставить API-ключ или пароль от базы данных прямо в скрипт. Делать так — огромная ошибка. Если вы случайно выложите такой код на GitHub или отправите коллеге, ваши доступы станут публичными. Для защиты данных в Linux и разработке используют переменные окружения (Environment Variables).

Переменные окружения — это динамические значения, которые доступны процессам в системе. Самый известный пример — $PATH, где хранятся пути к программам. Вы можете создать свою переменную в терминале командой export API_KEY="secret123", и любой запущенный после этого скрипт сможет её прочитать.

Однако хранить секреты в истории терминала или в коде неудобно. Поэтому разработчики используют файлы .env. Это простые текстовые списки в формате КЛЮЧ=ЗНАЧЕНИЕ.

Правила работы с .env:
— Никогда не коммитьте .env в Git! Добавьте его в .gitignore.
— Создайте файл .env.example с пустыми значениями, чтобы другие знали, какие ключи нужны для запуска.
— Для загрузки переменных в Python используйте библиотеку python-dotenv, а в Node.js — dotenv.

В Docker работа с переменными еще проще. Вам не нужно копировать файл внутрь образа (это небезопасно). Вы просто указываете путь к файлу при запуске контейнера:

docker run --env-file .env my-app

Или прописываете их в docker-compose.yml в блоке environment. Это позволяет использовать один и тот же образ для тестов и для продакшена, просто меняя значения в файле настроек.

Зачем это инженеру? Это вопрос гибкости и безопасности. Если вам нужно сменить пароль от базы данных, вам не нужно пересобирать весь проект или менять код. Вы просто правите одну строчку в .env и перезапускаете сервис. Ваша программа становится «умнее», адаптируясь к среде, в которой она запущена.

🚪 Bash Ready | #практика

Работа с массивами

Массивы - это простой способ хранить списки без awk и временных файлов. Главное знать базовые приемы.

▪️ Добавление элементов

arr=(one two)
arr+=(three)
arr[5]=six

bash сам раздвигает индексы, дыры допустимы.

▪️ Удаление элементов

unset arr[1]

Элемент удаляется, но индексы не сдвигаются:

echo "${!arr[@]}"  # индексы

Удалить весь массив:

unset arr

▪️ Перебор элементов

Правильно:

for item in "${arr[@]}"; do
  echo "$item"
done

Неправильно (ломает пробелы):

for item in ${arr[@]}; do

▪️ Перебор с индексами

for i in "${!arr[@]}"; do
  echo "$i => ${arr[$i]}"
done

▪️ Размер массива

echo "${#arr[@]}"

🚪 Bash Ready | #практика

📦 Управляем софтом как профи — всё про APT и Snap

В Linux вы не ищете установщики на сайтах (это путь к вирусам и зависимости от библиотек). Вместо этого вы используете менеджеры пакетов. Это как App Store или Google Play, только в терминале и гораздо мощнее.

Большинство дистрибутивов (Ubuntu, Debian) используют APT (Advanced Package Tool). Он работает с репозиториями — огромными складами проверенного софта. Главная фишка APT в том, что он сам разруливает зависимости: если программе нужен Python или библиотека libssl, он скачает их автоматически.

Базовый набор команд:
— Обновить список доступного софта: sudo apt update
— Установить пакет: sudo apt install [имя_пакета] (например, git или nginx)
— Удалить программу: sudo apt remove [имя_пакета]
— Полное обновление всех программ: sudo apt upgrade

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

Работа со Snap:
— Найти софт: snap find [название]
— Установить: sudo snap install [название]
— Посмотреть установленное: snap list

Зачем это инженеру? Чтобы держать сервер в чистоте и безопасности. Регулярное обновление через apt upgrade закрывает дыры в защите. А знание того, как работает поиск пакетов, позволяет развернуть окружение для разработки за пару минут, не скачивая ничего вручную.

Важно помнить про гигиену: после удаления тяжелых программ в системе могут остаться ненужные зависимости. Команда sudo apt autoremove найдет эти «хвосты» и удалит их, освобождая место на диске.

🚪 Bash Ready | #практика

🕵️ Как читать мысли сервера? — tail -f и journalctl!

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

Самый простой способ увидеть, что происходит с файлом прямо сейчас — команда tail -f. Она «приклеивается» к концу файла и мгновенно выводит новые строки, как только они там появляются. Это незаменимо при отладке веб-серверов или ботов.

Примеры использования:
— Следить за запросами к сайту: tail -f /var/log/nginx/access.log
— Смотреть последние 50 строк (а не 10 по умолчанию): tail -n 50 -f app.log



В современных системах (Ubuntu, Debian, CentOS) за логи отвечает служба systemd. Она собирает данные изо всех щелей в единый бинарный журнал, которым управляет утилита journalctl. В отличие от обычных текстовых файлов, здесь можно искать записи с хирургической точностью.

Мощные фильтры journalctl:
— Логи конкретного сервиса: sudo journalctl -u nginx
— Только ошибки и критические сбои: sudo journalctl -p err..emerg
— Записи за последние 15 минут: sudo journalctl --since "15 min ago"
— Посмотреть логи с момента последней загрузки: sudo journalctl -b

Зачем это инженеру? Чтобы не тонуть в информационном шуме. Когда сервер «лежит», вам не нужны все записи за месяц — вам нужно знать, что случилось пять минут назад. Комбинация journalctl -f -u my_app позволит вам видеть ошибки вашего приложения в реальном времени, даже если оно запущено как системная служба.

Помните, что логи могут занимать много места. Если диск переполнен, проверьте папку /var/log. Но лучше настроить автоматическую ротацию (logrotate) или ограничить размер журнала в конфигах journald, чтобы сервер не «задохнулся» от собственных записей.

🚪 Bash Ready | #практика

🌐 Проверка сети в Linux — ping, curl и ss!

Когда сервер не отвечает или API выдает ошибку, первым делом нужно понять: проблема в кабеле, в настройках сети или в самом приложении. В Linux есть три кита диагностики, которые помогут «пропинговать» путь до цели и увидеть все открытые двери (порты) системы.

Самая база — это ping. Команда отправляет маленькие пакеты (ICMP) до узла и ждет ответа. Если пакеты возвращаются, значит, сетевой уровень работает. Если нет — либо узел выключен, либо файрвол блокирует проверку.

Примеры:
— Проверить связь: ping google.com
— Пинговать только 4 раза и остановиться: ping -c 4 8.8.8.8

Если связь есть, но сайт не открывается, в дело вступает curl. Это браузер в терминале. Он позволяет увидеть ровно то, что отдает сервер: заголовки, JSON-ответы или HTML-код. Это лучший способ проверить работу вашего бэкенда или API.

Полезные флаги curl:
— Получить только заголовки (проверить статус 200 OK или 404): curl -I [https://google.com](https://google.com)
— Отправить POST-запрос с данными: curl -X POST -d "param=value" http://localhost:8000
— Скачать файл: curl -O [https://example.com/file.zip](https://example.com/file.zip)

Но что если сервис запущен, а достучаться до него не выходит? Нужно проверить, открыт ли нужный порт внутри самой системы. Раньше для этого использовали netstat, но сейчас стандартом стала утилита ss (socket statistics). Она быстрее и показывает больше деталей.

Как проверить порты:
— Показать все слушающие TCP-порты: ss -ltn
— Показать, какая программа занимает порт: sudo ss -ltnp (флаг p покажет название процесса и его PID).

Зачем это инженеру? Чтобы не тратить часы на поиск бага в коде, когда проблема в закрытом порту 80 или 5000. Комбинация этих инструментов позволяет проследить весь путь: от «видит ли мой компьютер сервер» до «отвечает ли конкретное приложение на конкретном порту».

🚪 Bash Ready | #практика

🕒 Автоматизация по расписанию — всё про Crontab!

Если у вас есть скрипт для бэкапа, парсер цен или бот, который должен присылать отчет каждое утро, вам не нужно запускать их вручную. В Linux для этого существует Cron — классический планировщик задач, который работает в фоновом режиме и выполняет команды точно в срок.

Настройка задач происходит через специальный файл — таблицу cron. Чтобы открыть её для редактирования, введите команду crontab -e. Каждая строка в этом файле — это отдельное задание, которое описывается пятью полями времени и самой командой.

Синтаксис Cron (правило пяти звезд):
— * * * * * /путь/к/скрипту
— Поля по порядку: Минуты (0-59), Часы (0-23), День месяца (1-31), Месяц (1-12), День недели (0-6, где 0 — воскресенье).

Примеры популярных настроек:
— 0 5 * * * — запускать каждый день ровно в 5:00 утра.
— */15 * * * * — запускать каждые 15 минут.
— 0 9 * * 1 — запускать каждый понедельник в 9:00.
— 0 0 1 * * — запускать первого числа каждого месяца в полночь.

Для удобства можно использовать сокращения, например @reboot для запуска скрипта сразу после загрузки сервера или @daily вместо 0 0 * * *.

Зачем это инженеру? Это основа автономности системы. Вместо того чтобы помнить о необходимости почистить папку /tmp или обновить сертификаты, вы один раз прописываете задачу в crontab и забываете о ней. Cron сам проследит за выполнением и, если настроено почтовое уведомление, даже сообщит об ошибке.

Важный нюанс при работе с Cron: у него своя «минималистичная» среда окружения. Он не знает, где находятся ваши программы, поэтому всегда указывайте полные пути к файлам и интерпретаторам (например, /usr/bin/python3 вместо просто python3). Также полезно перенаправлять вывод скрипта в лог-файл, чтобы потом можно было проверить, как прошел запуск: >> /home/user/logs/cron.log 2>&1.

Если нужно временно отключить задачу, не обязательно её удалять — достаточно поставить символ # в начале строки, закомментировав её. А чтобы посмотреть текущий список всех активных заданий без входа в редактор, используйте crontab -l.

Использование Cron превращает набор разрозненных скриптов в четко работающий механизм, который не требует вашего присутствия 24/7. Это один из самых надежных инструментов в арсенале любого разработчика и админа.

🚪 Bash Ready | #практика

🛡️ Основы SSH — безопасный доступ к серверу!

SSH (Secure Shell) — это основной способ управления Linux-сервером на расстоянии. Он создает зашифрованный туннель между вашим компьютером и сервером, благодаря чему ваши пароли и команды не могут быть перехвачены.

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

ssh user@123.123.123.123

Однако в профессиональной среде пароли считаются небезопасными. Их можно подобрать брутфорсом, а вводить их каждый раз при входе — неудобно.

Переход на ключи (SSH Keys):
Это гораздо более надежный метод. Вы создаете пару ключей на своем компьютере: приватный (остается у вас) и публичный (копируется на сервер).

— Генерация ключей: ssh-keygen -t ed25519 (алгоритм ed25519 сейчас считается самым современным и быстрым).
— Копирование на сервер: ssh-copy-id user@host.



После этого сервер будет «узнавать» ваш компьютер в лицо, и пароль больше не потребуется.

Для удобства работы с десятками серверов стоит настроить файл конфига ~/.ssh/config. Это позволит вместо длинных команд писать просто ssh prod или ssh home.

Пример настройки конфига:

Host prod
    HostName 1.2.3.4
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Зачем это инженеру? Во-первых, это безопасность. Отключив вход по паролю в настройках сервера (PasswordAuthentication no), вы защищаете систему от 99% автоматизированных атак. Во-вторых, это автоматизация: скрипты и системы деплоя смогут подключаться к серверам без вашего участия.

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

Работа через SSH — это стандарт индустрии. Освоив ключи и конфиги, вы делаете свою работу не только безопаснее, но и в разы быстрее, превращая вход на любой сервер в дело одной секунды.

🚪 Bash Ready | #практика

🛡️ Настройка файрвола UFW — закрываем лишние двери

Файрвол (межсетевой экран) — это первый рубеж обороны вашего сервера. По умолчанию в Linux могут быть открыты десятки портов, через которые злоумышленники пытаются найти уязвимости. UFW (Uncomplicated Firewall) — это простая надстройка над сложным инструментом iptables, которая позволяет управлять доступом буквально парой команд.

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

Базовые команды для старта:
— Разрешить SSH: sudo ufw allow ssh (или порт 22)
— Включить файрвол: sudo ufw enable
— Проверить статус и правила: sudo ufw status verbose

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

Управление правилами:
— Открыть веб-трафик: sudo ufw allow 80/tcp (HTTP) и sudo ufw allow 443/tcp (HTTPS)
— Открыть диапазон портов: sudo ufw allow 3000:3005/tcp
— Закрыть порт: sudo ufw deny 111
— Удалить правило: sudo ufw delete allow 80/tcp

Зачем это инженеру? Это минимизация поверхности атаки. Если вы запустили базу данных PostgreSQL или Redis для внутренних нужд, им нечего делать в открытом интернете. С помощью UFW вы можете разрешить доступ к базе только с определенного IP-адреса:
sudo ufw allow from 192.168.1.50 to any port 5432

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



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

Правильно настроенный UFW — это спокойный сон админа. Вы точно знаете, какие порты «светят» наружу, а какие надежно спрятаны внутри системы.

🚪 Bash Ready | #практика

Работа с массивами

Массивы - это простой способ хранить списки без awk и временных файлов. Главное знать базовые приемы.

▪️ Добавление элементов

arr=(one two)
arr+=(three)
arr[5]=six

bash сам раздвигает индексы, дыры допустимы.

▪️ Удаление элементов

unset arr[1]

Элемент удаляется, но индексы не сдвигаются:

echo "${!arr[@]}"  # индексы

Удалить весь массив:

unset arr

▪️ Перебор элементов

Правильно:

for item in "${arr[@]}"; do
  echo "$item"
done

Неправильно (ломает пробелы):

for item in ${arr[@]}; do

▪️ Перебор с индексами

for i in "${!arr[@]}"; do
  echo "$i => ${arr[$i]}"
done

▪️ Размер массива

echo "${#arr[@]}"

🚪 Bash Ready | #практика

🐳 Основы Docker — упаковываем приложения в контейнеры

Если фраза «на моем компьютере всё работает» стала для вас проклятием при деплое, пора переходить на Docker. Это технология контейнеризации, которая позволяет упаковать приложение со всеми его зависимостями, библиотеками и конфигами в один изолированный образ, который запустится везде одинаково.

В отличие от виртуальных машин, контейнеры не копируют целую операционную систему. Они используют ядро основной системы (Host OS), что делает их невероятно легкими и быстрыми. Запуск контейнера занимает секунды, а не минуты.

Основные понятия:
— Dockerfile — текстовый файл-рецепт, по которому собирается образ.
— Image (Образ) — «замороженный» снимок вашего приложения (аналог инсталлятора).
— Container (Контейнер) — запущенный и работающий экземпляр образа.

Базовые команды для работы:
— Запустить контейнер: docker run -d -p 8080:80 nginx (флаг -d запускает в фоне, а -p пробрасывает порты).
— Посмотреть запущенные: docker ps
— Остановить контейнер: docker stop [ID_контейнера]
— Посмотреть логи внутри контейнера: docker logs -f [ID_контейнера]

Зачем это инженеру? Для чистоты и порядка. Вам больше не нужно захламлять основную систему разными версиями Python, Node.js или базами данных. Вы можете запустить PostgreSQL одной командой, поработать с ней и удалить контейнер, не оставив в системе ни одного лишнего файла.

Контейнеры обеспечивают идеальную изоляцию. Если ваше приложение внутри Docker «упадет» или попытается занять всю память, это не затронет остальные процессы на сервере (если настроены лимиты). Это стандарт для современного бэкенда, микросервисов и CI/CD процессов.

Чтобы не вводить длинные команды в терминале, для управления группой контейнеров (например, приложение + база данных + кэш) используют Docker Compose. Но это уже тема для отдельного большого разговора.

Использование Docker превращает процесс развертывания софта из сложного квеста в простую и предсказуемую задачу. Это один из важнейших навыков для любого IT-специалиста в 2026 году.

🚪 Bash Ready | #практика

🛠️ Docker Compose — управляем оркестром контейнеров

Если Docker — это один контейнер, то Docker Compose — это дирижер, который запускает целую связку сервисов одной командой. Вам больше не нужно по очереди поднимать базу данных, бэкенд и Redis, прописывая каждому порты и сети вручную. Все настройки хранятся в одном файле docker-compose.yml.

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

Пример простого конфига:

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: secret_password

Основные команды:
— Запустить всё разом: docker-compose up -d (флаг -d запустит всё в фоновом режиме).
— Остановить и удалить всё: docker-compose down (очищает контейнеры и сети, созданные проектом).
— Посмотреть статус: docker-compose ps
— Пересобрать образы после правок кода: docker-compose up --build

Зачем это инженеру? Для быстрого развертывания среды разработки. Новый коллега может скачать проект из Git, выполнить docker-compose up, и через минуту у него будет полностью рабочее окружение со всеми базами данных и зависимостями, настроенными ровно так же, как у вас.

Compose также автоматически создает внутреннюю сеть для ваших сервисов. Это значит, что бэкенд может обращаться к базе данных просто по имени сервиса db, а не по IP-адресу. Это делает систему гибкой и защищенной: порты базы данных можно вообще не пробрасывать наружу, оставив их доступными только внутри «кольца» контейнеров.

Использование Docker Compose избавляет от ошибок ручного ввода и гарантирует, что проект запустится в идентичном виде на вашем ноутбуке, на сервере для тестов и на продакшене. Это следующий уровень профессиональной работы с контейнерами.

🚪 Bash Ready | #практика

🐍 Python-скрипты в фоне — управляем через Systemd!

Вы написали крутого Telegram-бота или парсер на Python, запустили его в терминале, но стоит закрыть консоль или разорвать SSH-соединение — и процесс умирает. Чтобы скрипт работал вечно, сам перезапускался после сбоев и поднимался после перезагрузки сервера, его нужно превратить в системную службу (service) через Systemd.

---

Systemd — это стандартный менеджер систем и служб в Linux. Вместо того чтобы городить костыли с nohup или &, вы создаете один простой конфиг-файл, который берет на себя весь контроль над вашим кодом.

Как это настроить:

— Создайте файл службы: sudo nano /etc/systemd/system/my_bot.service

— Наполните его конфигурацией:

[Unit]
Description=My Python Telegram Bot
After=network.target

[Service]
User=user
WorkingDirectory=/home/user/my_project
ExecStart=/home/user/my_project/venv/bin/python main.py
Restart=always

[Install]
WantedBy=multi-user.target

В блоке ExecStart важно указывать полный путь к интерпретатору Python (лучше из виртуального окружения venv), а параметр Restart=always гарантирует, что если ваш скрипт «упадет» с ошибкой, система сама поднимет его через пару секунд.

Основные команды для управления:
— Обновить список служб: sudo systemctl daemon-reload
— Запустить бота: sudo systemctl start my_bot
— Включить автозагрузку при старте сервера: sudo systemctl enable my_bot
— Проверить статус: sudo systemctl status my_bot

Зачем это инженеру? Это превращает ваш «скрипт на коленке» в надежное серверное решение. Вам больше не нужно проверять вручную, работает ли бот. Вы можете смотреть логи службы через уже знакомый нам journalctl -u my_bot и точно знать, когда и почему произошла ошибка.


🚪 Bash Ready | #практика

🌐 Обратный прокси — зачем нужен Nginx перед вашим кодом?

Когда вы запускаете Python-бота, FastAPI-приложение или Node.js сервер, они обычно работают на портах вроде 8000 или 5000. Выставлять их напрямую в интернет — плохая идея. Профессиональный стандарт — ставить «перед» ними Nginx в режиме Reverse Proxy (обратного прокси).



Nginx — это сверхбыстрый веб-сервер, который принимает все входящие запросы из интернета на стандартные порты (80 и 443) и аккуратно перенаправляет их вашему приложению, работающему глубоко внутри системы.

Что это дает на практике:
— SSL-сертификаты: Nginx берет на себя шифрование (HTTPS). Вашему коду не нужно знать, как работать с сертификатами — он просто получает чистый трафик.
— Безопасность: Вы закрываете все порты файрволом, кроме 80 и 443. Приложение становится невидимым для прямых атак.
— Статика: Картинки, видео и CSS-файлы Nginx отдает в разы быстрее, чем Python или JS, разгружая ваш основной код.
— Отказоустойчивость: Если у вас запущено несколько копий приложения, Nginx может распределять нагрузку между ними (Load Balancing).

Минимальный конфиг для проксирования:
Создается файл в /etc/nginx/sites-available/my_app:

server {
    listen 80;
    server_name your_domain.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Зачем это инженеру? Это финальный штрих, который превращает «скрипт, запущенный в консоли» в полноценный веб-сервис. Без Nginx вы не сможете подключить нормальный домен с HTTPS (через Certbot) и защитить приложение от элементарных DDoS-атак или переполнения соединений.

Использование обратного прокси позволяет вам гибко обновлять приложение: вы можете остановить сервис, а Nginx в это время будет показывать пользователям красивую страницу «Технические работы» вместо ошибки «Соединение сброшено». Это стандарт, без которого не обходится ни один серьезный проект в вебе.

🚪 Bash Ready | #практика

🔒 Безопасность в один клик — ставим SSL через Certbot

Если вы настроили Nginx, ваш сайт уже доступен, но браузеры помечают его как «Незащищенный». В 2026 году HTTPS — это не роскошь, а обязательное требование. Чтобы бесплатно получить SSL-сертификат от Let's Encrypt и настроить его автоматическое обновление, используется утилита Certbot.

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

Как превратить http в https за пару минут:

— Установка Certbot и плагина для Nginx:
sudo apt update && sudo apt install certbot python3-certbot-nginx

— Запуск магии:
sudo admin certbot --nginx -d your_domain.com (можно указать несколько доменов через -d).

Во время работы Certbot спросит ваш email (для уведомлений об истечении срока) и предложит автоматически настроить редирект с HTTP на HTTPS. Всегда выбирайте «Redirect» — это гарантирует, что пользователи всегда будут на защищенной версии сайта.

Зачем это инженеру? Во-первых, это доверие пользователей и поисковиков. Во-вторых, это защита данных: без HTTPS любой посредник в сети (например, провайдер в кафе) может перехватить пароли или токены, которые передаются между браузером и вашим сервером.

Сертификаты Let's Encrypt выдаются на 90 дней, но Certbot автоматически добавляет задачу в планировщик. Проверить, сработает ли автопродление в будущем, можно командой:
sudo certbot renew --dry-run

Использование Certbot делает процесс управления безопасностью невидимым и надежным. Вам больше не нужно следить за датами и вручную копировать ключи — система всё сделает за вас, поддерживая «зеленый замочек» в адресной строке вечно.

🚪 Bash Ready | #практика

📊 Индексы в базах данных — как ускорить запросы в 100 раз?

Представьте, что вы ищете главу в бумажной книге на 500 страниц. Если листать по порядку, вы потратите уйму времени. Но если заглянуть в оглавление в конце книги, вы найдете нужную страницу за секунды. Индексы в базах данных (PostgreSQL, MySQL, SQLite) работают точно так же.

По умолчанию база данных выполняет Full Table Scan — она перебирает каждую строчку в таблице, чтобы найти нужную. Если у вас 100 записей, это мгновенно. Если 10 миллионов — сервер «задохнется». Индекс создает отдельную структуру (обычно это B-Tree или B-дерево), где данные отсортированы, что позволяет базе находить значения с помощью бинарного поиска.

Когда стоит создавать индекс:
— В колонках, по которым вы часто делаете WHERE (например, email, user_id).
— В полях, используемых для сортировки (ORDER BY).
— В полях, по которым происходит объединение таблиц (JOIN).

Как создать индекс (на примере SQL):

CREATE INDEX idx_user_email ON users(email);

Зачем это инженеру? Это самый дешевый и эффективный способ оптимизации бэкенда. Часто разработчики пытаются купить сервер помощнее или переписать код на Python, хотя проблема решается добавлением одного индекса. Запрос, который длился 5 секунд, после индексации может выполняться за 0.05 секунды.

Однако у индексов есть «цена». Каждый новый индекс замедляет операции записи (INSERT, UPDATE, DELETE), так как базе нужно обновлять не только таблицу, но и само «оглавление». Также индексы занимают место на диске. Поэтому золотое правило: индексируйте только те поля, по которым реально идет поиск.

Чтобы проверить, использует ли база ваш индекс, используйте команду EXPLAIN ANALYZE перед вашим запросом. Она покажет «план выполнения» и честно ответит, просмотрела ли база всю таблицу или воспользовалась быстрым индексом.

Использование индексов — это переход от «просто написания кода» к пониманию того, как работают данные под капотом. Это база для любого разработчика, работающего с высокими нагрузками.

🚪 Bash Ready | #практика

🐳 Кастомные Docker-образы — пишем правильный Dockerfile

Запуск готовых контейнеров вроде Nginx или PostgreSQL — это здорово, но для деплоя собственного приложения (на Python, Node.js или Go) нужно научиться собирать свои образы. Для этого пишется Dockerfile — текстовый файл с пошаговыми инструкциями для сборки.

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

Пример правильного Dockerfile для Python (FastAPI):

# 1. Базовый образ (минималистичный alpine или slim)
FROM python:3.11-slim

# 2. Установка рабочей директории
WORKDIR /app

# 3. Копируем файлы зависимостей отдельно (для кэширования слоев)
COPY requirements.txt .

# 4. Установка пакетов без сохранения кэша менеджера
RUN pip install --no-cache-dir -r requirements.txt

# 5. Копируем остальной код приложения
COPY . .

# 6. Указываем порт, который слушает приложение
EXPOSE 8000

# 7. Команда для запуска
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Зачем это инженеру? Для создания стандартизированной среды. Копирование requirements.txt перед основным кодом — это классический паттерн. Если вы измените строчку в коде, но не тронете зависимости, Docker при сборке возьмет готовый слой с установленными библиотеками из кэша за долю секунды, а не будет скачивать их заново.

Также важно следить за безопасностью и размером. Использование легковесных образов (с тегом -slim или -alpine) уменьшает размер итогового контейнера с условного гигабайта до 100–150 мегабайт. Маленький образ быстрее передается по сети на сервер и содержит меньше потенциальных уязвимостей в системных библиотеках.

Для еще большей оптимизации используют Multi-stage builds (многоэтапную сборку), когда в одном Dockerfile первый контейнер собирает проект (используя тяжелые инструменты компиляции), а второй — просто забирает готовый результат, оставаясь максимально чистым.

Написание кастомных Dockerfile переводит работу с инфраструктурой на уровень "Infrastructure as Code" (Инфраструктура как код). Теперь процесс сборки вашего приложения задокументирован, автоматизирован и не зависит от настроек конкретного сервера.

🚪 Bash Ready | #практика

🔄 Миграции баз данных — как менять структуру без потери данных?

В начале проекта ваша база данных выглядит просто: таблица users с полями id и username. Но проект растет, и вам нужно добавить поле email, изменить тип данных у пароля или создать связь с новой таблицей заказов. Делать это вручную через SQL-запросы на живом сервере — верный путь уронить продакшен и потерять данные. Для правильного управления схемой используют миграции.

Миграции — это система контроля версий для вашей базы данных. Каждое изменение структуры оформляется в виде небольшого файла-скрипта (на Python, JS или чистом SQL), который содержит две обязательные инструкции:
— Upgrade (Up): что конкретно нужно сделать (например, добавить колонку).
— Downgrade (Down): как откатить это изменение назад, если что-то пошло не так.

В экосистеме Python стандартом для миграций являются Alembic (для SQLAlchemy) или встроенный механизм в Django ORM.

Как выглядит типичный процесс работы:
— Вы меняете модель в коде приложения.
— Генерируете файл миграции: alembic revision --autogenerate -m "add_email_to_user".
— Инструмент сравнивает ваш код с текущей базой и создает файл, где прописаны команды вроде op.add_column(...).
— Применяете изменения: alembic upgrade head.

Зачем это инженеру? Для командной разработки и безопасного деплоя. Когда ваш коллега скачает свежий код из Git, ему не придется гадать, какие таблицы вы добавили. Он просто запустит команду миграции, и его локальная база данных автоматически обновится до нужного состояния.

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

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

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

🚪 Bash Ready | #практика

🪵 Логирование без боли — почему стоит забыть про print()

Когда вы только учитесь кодировать, для проверки значений принято использовать обычный print(). Но в реальных проектах и на сервере print() становится бесполезным: он просто выплевывает текст в консоль, не говоря, когда произошла ошибка, в каком файле она случилась и насколько она критична. Для этого используют логирование (модуль logging или библиотеку Loguru).

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

Стандартные уровни логирования:
— DEBUG: подробная информация для отладки (значения переменных, шаги цикла).
— INFO: подтверждение, что всё идет по плану (сервер запущен, пользователь вошел).
— WARNING: случилось что-то неожиданное, но программа работает (мало места на диске).
— ERROR: серьезная проблема, часть функций не работает (ошибка базы данных).
— CRITICAL: полная остановка системы (упал весь сервер).

В Python стандартный модуль logging требует настройки, поэтому в современном бэкенде часто используют Loguru. Она красивая, быстрая и настраивается в одну строчку.

Пример работы с Loguru:

from loguru import logger

# Настраиваем запись в файл с ротацией (чтобы файл не весил гигабайты)
logger.add("app.log", format="{time} {level} {message}", level="INFO", rotation="10 MB")

def divide(a, b):
    try:
        logger.debug(f"Делим {a} на {b}")
        return a / b
    except ZeroDivisionError:
        logger.exception("Попытка деления на ноль!") # Автоматически запишет весь traceback ошибки

divide(10, 0)

Зачем это инженеру? Простой print() сотрется, как только закроется терминал. Правильный логгер сохраняет данные в файлы, автоматически снабжая каждую строчку точным временем, именем функции и уровнем важности.

Настроив ротацию (rotation="10 MB"), вы защищаете диск сервера: как только файл лога разрастется, Loguru заархивирует его и начнет новый. А благодаря правильным уровням вы сможете настроить отправку уведомлений в Telegram только для ошибок уровня ERROR и выше, не отвлекаясь на штатные INFO сообщения.

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

🚪 Bash Ready | #практика

🔒 Безопасное хранение паролей — зачем солить хэши?

Когда пользователь регистрируется на вашем сайте, он вводит пароль. Сохранять его в базу данных в чистом виде (plain text) — преступление против безопасности. Если злоумышленники взломают базу, они получат доступ к аккаунтам всех пользователей. Для защиты данных используют хэширование, но даже обычного хэша сегодня уже недостаточно.

---

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

Однако простые алгоритмы (MD5, SHA-1, SHA-256) работают слишком быстро. Хакеры используют радужные таблицы (Rainbow Tables) — гигантские базы заранее вычисленных хэшей для миллиардов популярных паролей. Если ваш пароль 123456, его хэш моментально найдется в такой таблице.

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

Как это работает:
— Пользователь вводит пароль: qwerty.
— Система генерирует случайную соль: x9F2kL.
— Пароль и соль соединяются, и хэшируется уже строка qwerty_x9F2kL.
— В базу данных сохраняются и соль, и полученный хэш.

Зачем это инженеру? Чтобы сделать радужные таблицы абсолютно бесполезными. Даже если два пользователя выберут одинаковый пароль 123456, из-за разной соли их хэши в базе данных будут кардинально отличаться. Хакеру придется подбирать пароль для каждого пользователя индивидуально методом брутфорса, на что уйдут годы.

В современном бэкенде (Python, Node.js, Go) для этого используют специальные «медленные» алгоритмы, такие как Bcrypt, Argon2 или Scrypt. Они намеренно заставляют процессор тратить миллисекунды на вычисление одного хэша. Для обычного пользователя задержка незаметна, но для хакера скорость перебора падает с миллионов вариантов в секунду до пары сотен.

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

🚪 Bash Ready | #практика

🧵 Потоки против Процессов — как заставить код работать параллельно?

Когда ваше приложение начинает делать несколько дел одновременно — например, обрабатывать запрос пользователя, скачивать картинку и считать тяжелую математику — вам нужно параллелить вычисления. В операционных системах и языках программирования (включая Python) для этого есть два главных инструмента: процессы (Processes) и потоки (Threads). Они звучат похоже, но работают совершенно по-разному.

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

Поток — это единица выполнения *внутри* одного процесса. Один процесс может запустить десятки потоков. Главное отличие: все потоки одного процесса делят между собой общую память. Они видят одни и те же переменные и объекты.

В чем разница при написании кода:

— Ресурсы: Создать процесс — «дорого» для процессора и оперативной памяти. Создать поток — в разы быстрее и легче.
— Обмен данными: Потокам легко общаться друг с другом, ведь у них общая память. Процессам, чтобы передать данные друг другу, приходится использовать сложные механизмы (IPC, очереди, сокеты).
— Безопасность: Если в одном из потоков случится критическая ошибка (например, Segmentation Fault), упадет весь процесс целиком со всеми остальными потоками. В случае с процессами — погибнет только один, изолированный элемент.

Зачем это инженеру? Чтобы правильно выбирать инструмент под конкретную задачу.

В Python есть своя специфика — GIL (Global Interpreter Lock). Это глобальная блокировка, которая разрешает только одному потоку выполнять код Python в один момент времени. Из-за этого потоки в Python идеально подходят для задач, связанных с ожиданием ввода-вывода (I/O-bound): например, делать запросы к API, скачивать файлы или ждать ответа от базы данных. Пока один поток ждет сеть, другой работает.

Если же вам нужно разгрузить процессор тяжелыми математическими расчетами, кодированием видео или обработкой больших данных (CPU-bound), потоки в Python не помогут — они будут выполняться по очереди на одном ядре. В этом случае нужно использовать процессы (multiprocessing), которые честно запустятся на разных ядрах вашего процессора.

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

🚪 Bash Ready | #практика