Перенаправление потоков: >, >>, 2>, | и вот вы уже волшебник 🔮

Вывод команды мешает на экране? Нужно сохранить результат в файл или ошибки — в лог? Или скормить результат одной команды на вход другой? Вся магия Linux строится на управлении потоками.

У каждой программы есть три стандартных потока:
➤ stdin (0) — стандартный вход (куда программа читает данные).
➤ stdout (1) — стандартный вывод (куда программа пишет данные).
➤ stderr (2) — стандартный вывод ошибок (куда программа пишет ошибки).

Какую самую крутую или неочевидную цепочку из перенаправлений и пайпов вы собирали? Хвастайтесь в комментах, соберем сборник лучших практик!

Оператор | (пайп) — это социальная сеть для Linux-команд. Одна команда постит свой вывод, а другая его лайкает и репостит, обрабатывая дальше.

🌐 @helcode

Криптография на пальцах: симметричное vs асимметричное шифрование

🗣 Когда ваш скрипт передает пароли или ключи, он не должен кричать о них на всю сеть. Шифрование — это стетоскоп, который превращает этот крик в шепот. Но какой тип выбрать?

➤ Симметричное: один ключ и для шифрования, и для расшифровки. Как один ключ от замка. Быстро и эффективно, но нужно безопасно передать ключ второй стороне.
➤ Пример: AES
➤ Асимметричное: два ключа - публичный (для шифрования) и приватный (для расшифровки). Публичный ключ можно раздавать всем. Медленнее, но решает проблему передачи ключа.
➤ Пример: RSA

Пример (создание SSH-ключей - это асимметричное шифрование):
ssh-keygen -t ed25519 -C "your_email@example.com"

Вы больше доверяете симметричному или асимметричному шифрованию? В каких случаях что использовать?

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

🌐 @helcode

SSH: козыри для удаленной "магии"

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

🛠 Пример:
➤ Подключение с определенным ключом:
ssh -i ~/.ssh/my_key user@host
➤ Запуск команды без входа на сервер:
ssh user@host 'ls -la /tmp'
➤ Проброс порта (туннелирование):
ssh -L 8080:localhost:80 user@host
➤ Проброс GUI-приложения:
ssh -X user@host firefox
➤ Упрощение через ~/.ssh/config:

Host myserver
HostName 192.168.1.1
User myuser
IdentityFile ~/.ssh/my_key

Теперь просто: ssh myserver

Файл ~/.ssh/config - лучший друг. Он запоминает настройки для разных серверов, чтобы не вводить их каждый раз.

Какой ваш самый частый или самый хитрый сценарий использования SSH? Делитесь лайфхаками!

SSH без ~/.ssh/config - это как звонить другу, каждый раз набирая полный номер с кодом страны. С конфигом - это добавление его в избранное.

🌐 @helcode | #bash

Cron + Ansible: Дуэт мечты для ежедневной рутины

Вы написали шикарный скрипт для бэкапа. Он работает. Один раз. А нужно, чтобы он запускался каждую ночь. Cron - это кукушка, которая будет будить ваш скрипт по расписанию. А Ansible - это дирижер, который расставит таких кукушек на всех серверах.

Пример (простой cron-файл):

# Пример crontab -e
# Минута Час День_месяца Месяц День_недели Команда
0 2 * * * /path/to/backup.sh  # Каждый день в 2:00
*/5 * * * * /path/to/check_status.sh  # Каждые 5 минут

Пример (задание cron через Ansible):

- name: Add backup cron job
  cron:
    name: "Daily Backup"
    minute: "0"
    hour: "2"
    job: "/path/to/backup.sh"
    user: "deploy"

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

А Вы как предпочитаете настраивать крон? Вручную, через Ansible, или может быть есть инструменты покруче?

Cron - это самый старый и надежный будильник в мире IT. Он разбудит ваш скрипт даже в выходной.

🌐 @helcode | #bash #yaml

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

Вы подлатали сервер, перезапустили его, и он... сломался. Конфиги сбились, версии поплыли. Знакомо? Иммутабельные серверы (также известны как "сервер с неизменяемой инфраструктурой) - это некая философия, где сервер после развертывания становится "священной коровой": его нельзя менять, можно только убить и создать новый.

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

Плюсы иммутабельного подхода:
➤ Предсказуемость
➤ Воспроизводимость
➤ Упрощение отката
➤ Безопасность

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

🌐 @helcode

Systemd: как приручить демонов современности

Раньше демоны были простыми. Теперь у нас есть systemd - это и система инициализации, и менеджер служб. Вот шпаргалка по самым нужным командам.

Пример:
➤ Посмотреть статус службы:
systemctl status nginx
➤ Запустить/остановить службу:
systemctl start nginx
systemctl stop nginx
➤ Включить/выключить автозагрузку:
systemctl enable nginx
systemctl disable nginx
➤ Перечитать конфиги:
systemctl daemon-reload
➤ Посмотреть логи службы:
journalctl -u nginx -f

Systemd использует "юниты" (unit files) для управления службами. Это конфиги в формате INI, которые говорят systemd, как управлять вашим демоном.

Вы уже писали свои .service файлы? Для каких демонов? Поделитесь опытом!

Systemd - это такой родитель, который знает о своих детях-демонах всё: где они, что делают, и почему плачут (пишут в логи).

P.S. Если интересно углубиться - моя статья по теме на Хабр.

🌐 @helcode

Пишем свой systemd сервис для Python-скрипта

У Вас есть полезный Python-скрипт, который должен работать постоянно как демон. Держать его в screen или nohup это каменный век. Давайте сделаем его полноценным systemd-сервисом!

Пример (/etc/systemd/system/my_script.service):

[Unit]
Description=My Awesome Python Script
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/opt/my_script
ExecStart=/usr/bin/python3 /opt/my_script/main.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Как использовать:

sudo systemctl daemon-reload
sudo systemctl enable my_script
sudo systemctl start my_script

➤ Restart=always - перезапускать скрипт, если он упал
➤ RestartSec=5 - ждать 5 секунд перед перезапуском
➤ User=deploy - от имени какого пользователя запускать

А Вы уже перевели свои скрипты на systemd?

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

🌐 @helcode

Git: не просто система контроля версий, а машина времени для вашего кода

"Это работало вчера!" - фраза, от которой стынет кровь. Git - это не просто способ хранить код, а полноценная машина времени, которая позволяет вернуться к любому моменту жизни проекта.

➤ Коммит - это слепок состояния файлов в определенный момент времени.
➤ Ветка- это указатель на конкретный коммит, который движется вперед.
➤ Слияние - это объединение изменений из разных веток.

Продвинутые концепции:
➤ Rebase vs Merge - два способа интегрировать изменения
➤ Interactive rebase - переписывание истории (осторожно!)
➤ Git hooks - автоматизация на события в Git

Git - это самый дешевый и эффективный способ путешествовать во времени. Правда, в отличие от Делореана, он не может попасть в будущее, где ваш код уже написан.

🌐 @helcode | #git

Docker: шпаргалка для тех, кто не хочет тонуть в контейнерах

"У меня на машине работает!" - самый страшный баг в истории. Docker решает это, упаковывая приложение со всем его окружением в контейнер. Вот шпаргалка, чтобы не запутаться в базовых командах.

Пример:
➤ Собрать образ:
docker build -t myapp:latest .
➤ Запустить контейнер:
docker run -d -p 8080:80 myapp:latest
➤ Посмотреть запущенные контейнеры:
docker ps
➤ Посмотреть все контейнеры:
docker ps -a
➤ Остановить контейнер:
docker stop <container_id>
➤ Посмотреть логи:
docker logs <container_id>
➤ Зайти внутрь контейнера
docker exec -it <container_id> bash

Dockerfile - это инструкция по сборке образа. Образ - это шаблон. Контейнер - это запущенный экземпляр образа.

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

🌐 @helcode | #docker

Пишем свой Dockerfile для Python-приложения

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

Пример:

# Используем официальный Python образ
FROM python:3.11-slim

# Устанавливаем рабочую директорию
WORKDIR /app

# Копируем зависимости сначала (для кэширования)
COPY requirements.txt .
RUN pip install -r requirements.txt

# Копируем весь проект
COPY . .

# Открываем порт
EXPOSE 8000

# Запускаем приложение
CMD ["python", "main.py"]

Как собрать и запустить:

docker build -t mypythonapp .
docker run -p 8000:8000 mypythonapp

Сначала копируем requirements.txt и устанавливаем зависимости - это позволяет Docker кэшировать этот слой и не переустанавливать зависимости при каждом изменении кода.

А Вы уже перевели свои проекты в Docker?

Писать Dockerfile - это как собирать чемодан в отпуск: положил всё необходимое, но не забыл про зубную щетку (системные зависимости).

🌐 @helcode | #docker

Мониторинг: или как понять, что ваш сервер умирает, до того как это увидят пользователи

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

➤ Метрики - количественные данные (CPU, память, диски)
➤ Логи - качественные данные (что происходило)
➤ Трейсинг - отслеживание запроса через все сервисы

Популярный стек:
➤ Prometheus - сбор метрик
➤ Grafana - визуализация
➤ ELK/EFK - работа с логами
➤ Jaeger - трейсинг

А какой стек мониторинга используете Вы? Что мониторите в первую очередь?

Сервер без мониторинга - это как пациент в коме: Вы не знаете, жив он или нет, пока не попробуете пнуть (сделать запрос).

🌐 @helcode

Prometheus + Grafana: первый контакт

Вы поставили Prometheus и Grafana, открыли интерфейс и... запутались в метриках и дашбордах. Вот шпаргалка по самым полезным метрикам и запросам.

🛠 Пример:

# CPU использование
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Память использование
node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

# Свободное место на диске
node_filesystem_avail_bytes{mountpoint="/"} 

# Rate HTTP запросов
rate(http_requests_total[5m])

PromQL - это язык запросов Prometheus. rate() считает скорость изменения метрики за промежуток времени, очень полезно для счетчиков.

А какая Ваша любимая метрика или самый полезный дашборд? Делитесь скриншотами!

Prometheus - это тот парень, который считает каждую мелочь. А Grafana - это его друг-художник, который превращает эти цифры в красивые графики.

🌐 @helcode | #PromQL

Мониторим свое приложение: пишем кастомные метрики для Prometheus

Встроенных метрик системы часто недостаточно. Хочется знать, сколько пользователей онлайн, сколько запросов в секунду обрабатывает Ваше приложение, какая бизнес-логика выполняется. Давайте научим ваше приложение разговаривать с Prometheus!

🛠 Пример:

from prometheus_client import Counter, Gauge, start_http_server
import time

# Создаем метрики
REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP Requests')
USERS_ONLINE = Gauge('users_online', 'Number of online users')

# В обработчике запроса
def handle_request():
    REQUEST_COUNT.inc()  # Увеличиваем счетчик
    USERS_ONLINE.set(get_online_users())  # Устанавливаем значение

# Запускаем HTTP сервер для метрик
start_http_server(8000)

➤ Counter - только увеличивается (запросы, ошибки)
➤ Gauge - может увеличиваться и уменьшаться (пользователи онлайн, температура)
➤ Histogram - распределение значений (время ответа)

🌐 @helcode | #python

Балансировщики нагрузки: или как разделить ношу на несколько плеч

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

➤ Round Robin - по очереди
➤ Least Connections - тому, у кого меньше подключений
➤ IP Hash - один и тот же пользователь всегда попадает на один сервер

Типы балансировщиков:
➤ L4 (Transport) - работает на уровне TCP/UDP
➤ L7 (Application) - работает на уровне HTTP, умнее

Популярные решения:
➤ nginx - простой и эффективный
➤ HAProxy - профессиональное решение
➤ Cloud Load Balancers - от облачных провайдеров

А Вы какой балансировщик используете? С какими интересными кейсами сталкивались?

Балансировщик нагрузки - это как администратор в клубе: решает, кого впустить, кому сказать "мест нет", а VIP-клиентов (по IP hash) всегда проводит к их любимому столику (серверу).

🌐 @helcode

Nginx как балансировщик: включаем многопоточность для нашего приложения

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

🛠 Пример (конфиг для балансировки):

upstream backend {
    server backend1.example.com:8000 weight=3;
    server backend2.example.com:8001;
    server backend3.example.com:8002 backup;
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

➤ weight=3 - в 3 раза больше запросов на этот сервер
➤ backup - использовать только если остальные упали
➤ proxy_set_header - передавать заголовки клиента

А Вы настраивали health checks в nginx? Какие стратегии балансировки используете?

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

🌐 @helcode

Кеширование: или как не делать одну и ту же работу дважды

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

➤ Client-side caching - браузер кеширует статику
➤ Server-side caching - Redis, Memcached для данных
➤ CDN caching - кеширование контента географически ближе к пользователям
➤ Database caching - кеш-запросов в самой БД

Когда использовать:
➤ Данные редко меняются
➤ Вычисления тяжелые
➤ Частые одинаковые запросы

А вы какой подход к кешированию используете? Redis, Memcached или что-то другое? Делитесь опытом!

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

🌐 @helcode

Redis: 5 команд, которые сделают вас мастером кеширования

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

Пример:

# Положить значение
SET user:123 "John Doe" EX 3600  # EX - время жизни в секундах

# Получить значение
GET user:123

# Проверить существование ключа
EXISTS user:123

# Установить несколько значений за раз
MSET user:123 "John" user:456 "Jane"

# Увеличить счетчик
INCR page_views

EX 3600 устанавливает время жизни ключа в 1 час. Автоматическое удаление устаревших данных - одна из крутейших фич Redis.

Какую самую необычную задачу вы решали с помощью Redis?

Redis - это диктофон для ваших данных: записал, прослушал, а через час оно само стирается. Удобно!

🌐 @helcode | #bash

Кешируем результаты API-запросов в Redis

Ваш скрипт делает запросы к медленному API, которое отвечает одними и теми же данными. Давайте сохраним результат в Redis и будем использовать его вместо повторных запросов!

🛠 Пример:

import redis
import requests
import json
import time

r = redis.Redis(host='localhost', port=6379, db=0)

def get_cached_data(user_id):
    cache_key = f"user:{user_id}"
    cached = r.get(cache_key)
    
    if cached:
        print("Данные из кеша!")
        return json.loads(cached)
    
    # Если нет в кеше - делаем запрос к API
    print("Делаем запрос к API...")
    response = requests.get(f"https://api.example.com/users/{user_id}")
    data = response.json()
    
    # Сохраняем в кеш на 5 минут
    r.setex(cache_key, 300, json.dumps(data))
    return data

# Использование
user_data = get_cached_data(123)

setex устанавливает значение с временем жизни. Через 5 минут ключ автоматически удалится.

А вы кешируете запросы к внешним API? Какие библиотеки или подходы используете?

Кеширование API-запросов - это как записывать сериал на флешку: не нужно ждать загрузки каждый раз, когда хотите пересмотреть.

P.S. Если Вам интересно, как мы настраивали кеширование в нашем боте и с чем столкнулись на практике - пишите об этом в комментариях! Спойлер: ошибок было действительно много...

🌐 @helcode | #python

Очереди сообщений: или как разгрузить ваш основной сервис

Пользователь загрузил видео, а ваш сервер должен его обработать, отправить уведомления, сгенерировать превью... И все это мгновенно! Очереди сообщений позволяют отложить тяжелую работу и выполнять ее фоном.

Ключевые понятия:
➤ Producer - производитель (отправляет сообщения)
➤ Consumer - потребитель (обрабатывает сообщения)
➤ Queue - очередь (хранит сообщения)
➤ Broker - посредник (управляет очередями)

Популярные решения:
➤ RabbitMQ - классика, много возможностей
➤ Redis Streams - просто, если уже есть Redis
➤ Apache Kafka - для больших объемов данных

Вы используете очереди в своих проектах? Для каких задач?

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

🌐 @helcode

RabbitMQ: управляем очередями как профессионалы

RabbitMQ - один из самых популярных брокеров сообщений. Вот основные команды для управления им из командной строки.

Пример:

# Создать очередь
rabbitmqadmin declare queue name=video_processing durable=true

# Отправить сообщение
rabbitmqadmin publish exchange=amq.default routing_key=video_processing payload="hello"

# Посмотреть статистику
rabbitmqctl list_queues name messages_ready messages_unacknowledged

# Создать пользователя
rabbitmqctl add_user myuser mypassword

# Настроить права
rabbitmqctl set_permissions -p / myuser ".*" ".*" ".*"

durable=true делает очередь устойчивой - сообщения не потеряются при перезагрузке RabbitMQ.

Какие самые интересные паттерны с очередями Dы реализовывали? Work queues, pub/sub?

Команда rabbitmqctl - это как пульт управления для Dаших очередей: можно посмотреть, кто в очереди стоит и сколько народу ждет своей очереди.

🌐 @helcode | #bash