Парсим сайты, которые не хотят, чтобы их парсили: обход блокировок

Современные сайты защищаются от парсинга: капчи, блокировка по IP, анализ поведения браузера. Наивный requests.get() уже не работает. Нужно маскироваться под человека.

Используем Selenium WebDriver с Stealth-плагином и ротируем User-Agent.

Настройка "стелс"-браузера на Python:

from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium_stealth import stealth
import random

# Создаем опции Chrome
options = Options()
options.add_argument("--headless=new")  # Запуск в фоне
options.add_argument(f"--user-agent={random.choice(user_agents)}")  # Рандомный UA
options.add_experimental_option("excludeSwitches", ["enable-automation"])
options.add_experimental_option('useAutomationExtension', False)

driver = webdriver.Chrome(options=options)

# Применяем stealth-плагин для сокрытия автоматизации
stealth(driver,
        languages=["en-US", "en"],
        vendor="Google Inc.",
        platform="Win32",
        webgl_vendor="Intel Inc.",
        renderer="Intel Iris OpenGL Engine",
        fix_hairline=True,
        )

driver.get("https://hard-to-parse-site.com")
# Дальше работаем как с обычным браузером

➤ Ротация User-Agent: смена «отпечатка» браузера делает запросы менее похожими друг на друга.
➤ Selenium Stealth: плагин скрывает следы автоматизации, которые ищут анти-бот системы (например, наличие navigator.webdriver).
➤ HEADLESS-режим: запуск без GUI, но его одного часто недостаточно.

Важно: всегда проверяйте robots.txt и Terms of Service сайта. Уважайте нагрузку на чужой сервер (добавляйте задержки time.sleep()).

Приходилось ли вам бороться с анти-бот системами?

Писать парсер для защищенного сайта — это игра в кошки-мышки с системными администраторами этого сайта. Главное — не переходить в DDoS. 🐭🐱

🌐 @helcode | #python

Скрипты-самоубийцы: как автоматически остановить скрипт, если он сломался

Ваш скрипт завис и висит сутками, съедая ресурсы? Научите его вовремя уходить с достоинством!

Скрипты, которые работают с внешними ресурсами (сеть, БД, API), могут внезапно зависнуть на неопределенное время. Это съедает память, блокирует другие процессы и портит картину мониторинга. Нужен встроенный механизм самоликвидации.

Используем декораторы и сигналы для установки таймаутов.

Способ 1: таймаут на отдельную функцию (декоратор)

import signal
from functools import wraps

class TimeoutException(Exception):
    pass

def timeout(seconds=10):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            # Устанавливаем обработчик сигнала ALARM
            def handle_timeout(signum, frame):
                raise TimeoutException("Функция выполнена дольше {seconds} секунд!")
            
            old_handler = signal.signal(signal.SIGALRM, handle_timeout)
            signal.alarm(seconds)  # Заводим будильник
            try:
                result = func(*args, **kwargs)
            finally:
                signal.alarm(0)  # Отключаем будильник
                signal.signal(signal.SIGALRM, old_handler)  # Восстанавливаем старый обработчик
            return result
        return wrapper
    return decorator

# Использование
@timeout(5)  # Максимум 5 секунд на выполнение
def call_slow_api():
    import time
    time.sleep(10)  # Имитация долгого запроса
    return "success"

try:
    call_slow_api()
except TimeoutException:
    print("Функция прервана по таймауту!")

➤ Сигнал SIGALRM: посылается ядром Linux по истечении времени, заданного signal.alarm().
➤ Декоратор @timeout: позволяет обернуть любую функцию, установив для нее лимит выполнения.
➤ Важно: этот метод работает только в главном потоке и не для всех операций (например, некоторые системные вызовы могут быть не прерваны).

Сталкивались ли вы с зависанием скриптов?

Научить скрипт самоликвидироваться — это как дать секретному агенту капсулу с ядом. Жестко, но эффективно для миссии.

🌐 @helcode | #python

Кэширование для ленивых: ускоряем скрипты в 100 раз без усилий

Ваш скрипт 100 раз ходит за одними и теми же данными? Пора дать ему память!

🏋️ Многие скрипты делают одни и те же «тяжелые» операции при каждом запуске: чтение больших файлов конфигурации, запросы к медленным API, сложные вычисления. Кэширование результатов между запусками — простой способ ускорить их в разы.

Используем декоратор @cache из стандартной библиотеки Python (появился в 3.9+).

Кэширование результатов тяжелой функции:

from functools import cache
import time

@cache  # Волшебная строка, которая все кэширует
def get_weather(city):
    # Имитация медленного HTTP-запроса к API погоды
    time.sleep(2)
    # Здесь реальный запрос: requests.get(f"http://weather.com/{city}").json()
    return f"Погода в {city}: +25°C"  # Возвращаем заглушку

# Первый вызов — медленный (2 секунды)
print(get_weather("Москва"))  

# Все последующие вызовы с ТЕМ ЖЕ аргументом — мгновенные!
print(get_weather("Москва"))  # Результат взят из кэша
print(get_weather("Москва"))  # Снова из кэша

# Вызов с новым аргументом — снова медленный (2 секунды)
print(get_weather("Санкт-Петербург"))  

# Кэш хранится ТОЛЬКО в течение работы программы.
# Для кэша между запусками нужны другие решения (redis, diskcache)

➤ @cache (или @lru_cache из functools для более старых версий) запоминает аргументы, с которыми вызывалась функция, и ее возвращаемое значение.
➤ При повторном вызове с теми же аргументами функция не выполняется, а результат возвращается из памяти.
➤ Важно: aункция должна быть чистой (pure) - возвращать одинаковый результат для одинаковых аргументов без side effects.

Где вы используете кэширование?

Добавить @cache - это как поставить термос с кофе рядом с кроватью. Проснулся, выпил, уже бодрый - не надо идти на кухню и варить заново.

🌐 @helcode | #python

Мы переехали, обновились и снова в строю!

Бот @ScriptGeniusBot полностью функционирует в новой группе. Все скрипты на месте, поиск работает, категории доступны.

Что можно делать:
✅ Искать нужные скрипты
✅ Скачивать код одним файлом

Спасибо за терпение! Теперь работаем в усиленном режиме 💪

🌐 @helcode | #обновление #автоматизация

Как избежать хаоса: конфигурация скриптов в YAML

Ваши скрипты обрастают десятками параметров в коде? Пора вынести их в конфиг!

«Жесткие» параметры внутри кода (пути, адреса, пороги срабатывания) - это зло. При каждом изменении нужно лезть в код, рискуя что-то сломать. Правильное решение - выносить конфигурацию в отдельные файлы.

Используем YAML - человекочитаемый формат для конфигов.

Пример файла config.yaml:

database:
  host: "localhost"
  port: 5432
  name: "my_app"
  user: "admin"

logging:
  level: "INFO"
  file: "/var/log/my_app.log"

api:
  endpoint: "https://api.example.com/v1"
  timeout_seconds: 30
  retry_attempts: 3

features:
  enable_telemetry: false
  cache_size: 1000

Загрузка конфига в Python:

import yaml  # pip install PyYAML

with open("config.yaml", "r") as f:
    config = yaml.safe_load(f)

# Теперь доступ к параметрам прост и безопасен
db_host = config['database']['host']
timeout = config['api']['timeout_seconds']

➤ YAML поддерживает сложные структуры (словари, списки), комментарии и более читаем, чем JSON.
➤ Отделение кода от конфигурации - ключевая практика DevOps. Это позволяет использовать один и тот же код в разных окружениях (dev, prod) без изменений.
➤ Версионирование: rонфиг-файлы можно хранить в git отдельно от кода с разными ветками для разных сред.

Как вы храните конфигурацию?

Переход на YAML-конфиги - это как перейти от управления государством через указы, написанные на салфетке, к полноценной конституции. Порядок и предсказуемость!

🌐 @helcode | #yaml #python

Автоматическое тестирование скриптов: оно вам нужно?

Вы запускаете скрипт и молитесь, чтобы он не сломал прод? Пора подружиться с тестами!

Скрипты для автоматизации - такое же ПО, как и веб-сервисы. Они могут содержать баги, которые приводят к потере данных или простою систем. Писать тесты для скриптов кажется overkill, но это окупается их надежностью.

🛠 Пишем простой unit-тест для функции из скрипта с помощью pytest.

Допустим, у нас есть функция в script.py:

# script.py
def process_data(input_data):
    """Удаляет все числа меньше 10 из списка."""
    if not isinstance(input_data, list):
        raise ValueError("Input must be a list!")
    return [x for x in input_data if x >= 10]

Пишем тест в файле test_script.py:

# test_script.py
import pytest
from script import process_data

# Стандартный тест на корректные данные
def test_process_data_positive():
    assert process_data([1, 10, 20, 5]) == [10, 20]

# Тест на пограничное условие
def test_process_data_boundary():
    assert process_data([9, 10]) == [10]

# Тест на некорректный ввод
def test_process_data_negative():
    with pytest.raises(ValueError):
        process_data("not a list")

Запуск тестов:

pytest -v test_script.py

➤ Unit-тесты проверяют отдельные функции («юниты») изолированно от остального кода.
➤ pytest - стандарт де-факто для тестирования в Python: простой синтаксис, информативные сообщения об ошибках.
➤ Тесты помогают без страха рефакторить код и добавлять новую функциональность, не ломая старое.

Вы пишете тесты для своих скриптов автоматизации?

Писать тесты для скриптов — это как надевать страховку при работе на высоте. Кажется, что и так можно, но однажды это спасет вам проект.

🌐 @helcode | #python

Процесс, Поток, Демон: кто из них многозадачник, а кто – невидимка?

В мире Linux-автоматизации эти трое - основа основ. Путаница в них может стоить вам ресурсов сервера или нестабильной работы скрипта. Давайте расставим все по полочкам!

Теория:
➤ Процесс - это тяжеловес. Программа в работе со своим адресным пространством, памятью и данными. Как отдельный запущенный экземпляр браузера.
➤ Поток (Thread) - это легковес внутри процесса. У процессов могут быть свои «потоки-министры», которые делят между собой память и ресурсы родителя, но выполняют задачи параллельно. Экономят ресурсы, но усложняют дебаг.
➤ Демон (Daemon) - это процесс-отшельник. Он работает в фоне, не привязан к терминалу и обычно запускается при старте системы. Ваш веб-сервер (nginx) или cron - классические демоны.

Посмотреть все процессы можно классикой: ps aux. А чтобы найти демоны, ищите те, у которых в столбце TTY стоит ?.

А вы как предпочитаете писать многопоточные приложения? Python с threading, Go с горутинами, или старый добрый C? Поделитесь опытом в комментах!

Если процесс — это целый завод, то потоки — это цехи на этом заводе. А демон — это заводской призрак, который работает ночью, пока все спят.

🌐 @helcode | #linux

JQ: ваш карманный ниндзя для боя с JSON в терминале

Контекст: API сыпят на нас тоннами JSON. Ручной парсинг глазами — путь в никуда. Команда jq превращает эту кашу в структурированные данные, с которыми можно работать прямо в bash.

Код/Пример:
Допустим, у нас ответ от API такой: {"users": [{"name": "Alice", "id": 1}, {"name": "Bob", "id": 2}]}

➤ Достать всех юзеров: curl ... | jq '.users'
➤ Только имена: curl ... | jq '.users[].name' -> "Alice", "Bob"
➤ Имя первого юзера: curl ... | jq '.users[0].name' -> "Alice"
➤ Преобразовать в массив имен: curl ... | jq '[.users[].name]' -> ["Alice", "Bob"]

Ключ к успеху - точка (.) означает текущий объект, а комбинации фильтров [] (для массивов) и .key (для полей) творят "магию".

Какой ваш самый сложный или изящный jq-однострочник?

jq для JSON — это как световой меч для джедая: без него можно обойтись, но с ним ты чувствуешь силу.

🌐 @helcode | #python

xargs: или как заставить одну команду работать с тысячей аргументов

Вывод ls, find или grep часто нужно скормить другой команде (например, rm или mv). Но большинство утилит не принимают вход из пайпа. xargs — это мост между ними.

➤ Массовое удаление: find . -name "*.tmp" | xargs rm -f
(Найди все .tmp файлы и передай их имена команде rm)
➤ Параллельный запуск: cat urls.txt | xargs -P 5 -I {} curl -O {}
(-P 5 запустит 5 параллельных закачек curl)
➤ Для сложных имен (с переносами и пробелами): find . -name "*.log" -print0 | xargs -0 ls -la
(-print0 и -0 используют нулевой байт как разделитель — это безопасно)

xargs берет элементы из стандартного ввода, формирует из них аргументы и подставляет в указанную команду.

А вы используете xargs?

🌐 @helcode | #linux

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

Представьте: Вы запускаете скрипт деплоя второй раз, потому что первый завис. А он вместо того, чтобы понять, что все уже готово, начинает все с начала и ломает систему. Знакомо? Этого избегают идемпотентные скрипты.

Идемпотентность — это свойство операции, позволяющее применять её многократно без изменения результата beyond the initial application. Проще: сколько бы раз вы не нажимали кнопку вызова лифта — он приедет только один раз.

Пример:
➤ НЕ идемпотентно: echo "data" >> file.log (при каждом запуске в файл добавится новая строка)
➤ Идемпотентно: echo "data" > file.log (файл будет перезаписан одним и тем же содержимым)
➤ Идемпотентно в Ansible: пакетные менеджеры (apt, yum) или модули копирования файлов по умолчанию идемпотентны. Они проверяют текущее состояние и меняют его только если нужно.

А вы задумываетесь об идемпотентности своих скриптов? Какие трюки используете (проверка флагов, lock-файлы)? Делитесь лайфхаками!

Идемпотентный скрипт — это как пес, который лает на почтальона каждый день с одинаковым энтузиазмом. Результат предсказуем.

🌐 @helcode

Grep: 5 флагов, которые вернут вам часы жизни

Ручной поиск по логам или коду — это адское занятие. grep — Ваш первый и главный друг в этой битве. Но знание всего пары флагов превращает его из молотка в целый "швейцарский нож".

🛠 Пример:
Допустим, ищем упоминания error в проекте:
➤ -r (рекурсивно): grep -r "error" /path/to/project/ (обыщет все файлы во всех папках)
➤ -i (игнорируй регистр): grep -i "connection" file.log (найдёт и Connection, и CONNECTION)
➤ -c (покажи count): grep -c "404" access.log (не покажет строки, просто посчитает количество 404-ых ошибок)
➤ -A, -B, -C (контекст):
1) grep -A 3 "Exception" log.txt (покажет строку с исключением и 3 строки после)
2) grep -B 2 "panic" log.txt (покажет строку с паникой и 2 строки до)
3) grep -C 1 "timeout" log.txt (покажет строку с таймаутом и по 1 строке до и после)

Флаги -A (After), -B (Before), -C (Context) — это спасение при чтении логов, где важно понять, что привело к ошибке и что было после.

Какой ваш самый частый или самый сумасшедший grep-однострочник?

Grep без этих флагов — это как искать иголку в стоге сена без магнита. А с ними — у Вас есть магнит, металлоискатель и карта, где спрятана вторая иголка.

🌐 @helcode | #linux

Пишем на Python'е сторожа для важных задач

Запустили бэкап или сборку? Теперь можно пойти пить кофе и молиться, чтобы всё прошло well. Или написать простого бота-напоминалку, который отправит вам в Telegram сообщение о результате.

🛠 Пример:
1. Создаем бота у [@BotFather](https://t.me/BotFather), получаем TOKEN.
2. Узнаем ID чата: проще всего написать боту [@userinfobot](https://t.me/userinfobot), он его вам скажет.
3. Скрипт-напоминалка (notify.py):

import requests

TOKEN = "YOUR_TELEGRAM_BOT_TOKEN"
CHAT_ID = "YOUR_CHAT_ID"
MESSAGE = "✅ Бэкап успешно завершен! Можно спать спокойно."

url = f"https://api.telegram.org/bot{TOKEN}/sendMessage"
params = {"chat_id": CHAT_ID, "text": MESSAGE}

requests.post(url, params=params).json()

4. Вставляем в скрипт бэкапа: python3 notify.py

Скрипт делает простой HTTP-запрос к Telegram API. Главное — не храните токен и chat_id в коде, если проект публичный! Используйте переменные окружения.

А вы куда получаете оповещения? Telegram, Slack, может быть, почта? И что мониторите? Расскажите о своем опыте автоматизации уведомлений!

Этот скрипт — как тот друг, который всегда звонит проверить, добрался ли ты домой. Надоедливо, но чертовски полезно.

🌐 @helcode | #python

Makefile: а этот парень зачем в нашем автоматизационном проекте?

✍️ Вы написали 10 скриптов для деплоя. Один чистит кэш, другой собирает проект, третий заливает его на сервер. Запускать их все по отдельности и запоминать порядок — не наш путь. Makefile — это ваш сборочный менеджер команд.

make — это утилита для управления сборкой, но программисты приспособили её для любой автоматизации. Вы описываете цели (targets) и зависимости между ними. Makefile делает процесс запуска сложных цепочек команд простым и предсказуемым.

🛠 Пример:

Вот простой Makefile для веб-проекта:

.PHONY: deploy clean build  # Говорим, что это не реальные файлы, а команды

build: clean
    npm run build

clean:
    rm -rf ./dist

deploy: build
    scp -r ./dist/* user@server:/path/to/app

# Теперь можно просто запустить:
# make deploy
# и make сделает clean -> build -> deploy

А вы используете Makefile не по назначению? Для деплоя, тестов, Docker-команд?

Makefile — это как шпаргалка с командами для самого себя, которую ты сделал вчера, чтобы сегодняшний ты ничего не забыл. Забота о будущем себе. 😉

🌐 @helcode | #makefile

Коды HTTP: учим язык, на котором с нами разговаривают сервера

Ваш скрипт отправил запрос к API, а в ответ — тишина или ошибка. Чтобы не гадать на кофейной гуще, нужно знать базовые коды состояния HTTP. Это не роскошь, а необходимость для любого, кто работает с веб-автоматизацией.

Пример:
➤ 200 OK: всё хорошо, проходите. Запрос выполнен успешно.
➤ 201 Created: не просто "OK", а "Я только что создал новую сущность по твоей просьбе". Ответ на успешный POST-запрос.
➤ 400 Bad Request: "я тебя не понял". Сервер не смог разобрать запрос из-за неверного синтаксиса (например, невалидный JSON).
➤ 401 Unauthorized: "предъяви пропуск". Требуется аутентификация, а вы её не предоставили.
➤ 403 Forbidden: "у вас нет доступа". Пропуск есть, но в этот кабинет пройти нельзя.
➤ 404 Not Found: "здесь ничего нет". Ресурс не найден.
➤ 500 Internal Server Error: "у нас на сервере что-то сломалось, но мы не знаем что". Универсальная ошибка серверной части.
➤ 502 Bad Gateway: "проксируемый сервер отдал мне какую-то дичь". Частая ошибка в балансировщиках и прокся.

Коды 4xx — это ошибка клиента (Вашего скрипта). Коды 5xx — ошибка сервера (там, куда Вы стучитесь).

С какими самыми странными или редкими кодами вам приходилось сталкиваться?

Если API отвечает вам кодом 200 — это как получить в ответ "да, слушаю". Код 500 — это молчаливый вздох и закатывание глаз. А 404 — это просто "Иди нафиг".

🌐 @helcode | #http

Shebang (#!): магическая строка, которая делает скрипт скриптом

Вы написали script.py, а система пытается запустить его через bash. Вы вручную пишете python3 script.py. Зачем? Достаточно добавить одну строку в начало файла, и система сама поймет, какой интерпретатор использовать.

Shebang — это первые два символа #! в самом начале исполняемого файла. После них указывается путь к интерпретатору.

🛠 Пример:
➤ Для Python: #!/usr/bin/env python3
(/usr/bin/env — это волшебная команда, которая ищет python3 в вашем PATH, что более универсально, чем жесткий путь)
➤ Для Bash: #!/bin/bash
➤ Для Node.js: #!/usr/bin/env node

⚙️ Как это работает:
1. Вы делаете файл исполняемым: chmod +x my_script.py
2. Запускаете его прямо: ./my_script.py
3. Система видит #!, читает путь до интерпретатора и запускает /usr/bin/env python3 ./my_script.py

А вы используете shebang?

Shebang — это как паспорт для Вашего скрипта. Без него это просто текстовый файл, который никуда не пустят. С ним — полноправный гражданин системы.

🌐 @helcode

Grep, Sed, Awk: святая троица текстовых ниндзя. Кого и когда использовать?

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

➤ grep — это сито. Его задача — фильтровать строки. Найти те, что подходят под шаблон, и пропустить их дальше. Идеален для простого поиска.
➤ Пример: grep "error" log.txt
➤ sed — это скальпель. Его сила — точечное редактирование текста (замена, удаление строк). Работает построчно.
➤ Пример: sed 's/foo/bar/g' file.txt (заменить все "foo" на "bar")
➤ awk — это комбайн. Целый язык для обработки данных. Мощь в работе со столбцами и сложной логикой.
➤ Пример: awk '{print $1}' file.txt (напечатать только первый столбец каждой строки)

Пример (комбо):
Посмотреть процессы Python и оставить только их PID:
ps aux | grep python | awk '{print $2}'

Какой инструмент из троицы ваш любимый и за что вы его любите?

🌐 @helcode | #linux

Tar: архивируем это немедленно! 🗄

Нужно срочно передать кучу файлов, сделать бэкап или положить что-то на долгое хранение? tar — Ваш верный друг. Главное — не утонуть в его флагах.

🛠 Пример:
➤ Создать архив (c - create):
tar -cf archive.tar file1.txt dir/
➤ Создать архив со сжатием gzip (z - gzip):
tar -czf project_backup.tar.gz project_dir/
➤ Распаковать архив (x - extract):
tar -xf archive.tar
➤ Распаковать в определенную директорию (C - change to directory):
tar -xf archive.tar -C /path/to/target/
➤ Просмотреть содержимое архива (t - list):
tar -tf archive.tar

Объяснение:
➤ -c — создать.
➤ -x — извлечь.
➤ -t — посмотреть.
➤ -f — указать имя файла (обязательный флаг!).
➤ -z — работать с gzip (используйте для .tar.gz или .tgz).
➤ -j — работать с bzip2 (для .tar.bz2).
➤ -v — verbose (показывать процесс, но не используйте в скриптах!).

А вы какой алгоритм сжатия предпочитаете? Старый добрый gzip (-.gz), более жесткий bzip2 (-.bz2) или современный xz (-.xz)? И почему?

Команда tar без флага -f — это как попытка заварить чай без чайника. Вода есть, чай есть, а результата нет. Система любезно напомнит Вам об этом. 😉

🌐 @helcode | #linux

.gitignore: искусство скрывать лишнее от посторонних глаз 🕵️‍♂️

Вы только что сделали git add . и увидели в коммите кучу мусора: кэши, логи, пароли, системные файлы. Паника! Как их убрать? Ответ — файл .gitignore. Он говорит Git'у, чем можно пренебречь.

.gitignore — это простой текстовый файл, в котором шаблонами перечисляются файлы и директории, которые не нужно отслеживать в Git.

Содержимое файла .gitignore для Python-проекта:

# Игнорируем кэш Python
__pycache__/
*.py[cod]

# Игнорируем виртуальное окружение
venv/
.env/

# Игнорируем логи
*.log

# Игнорируем файлы с чувствительными данными (пароли, ключи)
secrets.yml
config.json
*.key

# Игнорируем системные файлы
.DS_Store
Thumbs.db

А какие самые странные или полезные шаблоны были в ваших файлах .gitignore? Делитесь находками, чтобы все могли сделать свои репозитории чище!

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

🌐 @helcode | #git

Ansible, Chef, Puppet: или как приручить стадо серверов 🐑

Вы написали десяток bash-скриптов для настройки серверов. Они работают. Но что, если серверов не один, а сто? Как быть уверенным, что везде одинаковая конфигурация? Здесь начинается магия управления конфигурациями.

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

➤ Ansible: работает по SSH, не требует установки агента на целевые серверы. Конфиги пишутся на простом YAML. Идеален для старта.
➤ Puppet/Chef: требуют установки агента на сервер. Используют свой собственный DSL (Domain-Specific Language) для описания конфигураций. Мощные, но более сложные для изучения.

Простой плейбук Ansible для установки nginx:

- name: Install and start nginx
  hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: latest
    - name: Start nginx service
      systemd:
        name: nginx
        state: started
        enabled: yes

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

Если bash-скрипты — это ручное управление сервером с помощью рычагов и кнопок, то Ansible — это автопилот, который вы просто включаете и пьете кофе, пока он ведет самолет.

🌐 @helcode | #yaml

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

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

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

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

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

🌐 @helcode