🛠 4 утилиты для работы с текстом в терминале

Когда работаешь с логами в ход обычно идут grep и awk. Но есть и другие инструменты, которые спасают не меньше:

• tr — заменяет или убирает символы:

cat names.txt | tr '[:lower:]' '[:upper:]'

Команда превратит весь текст в CAPS LOCK.

• sort — сортирует строки:

cat errors.log | sort

Хаос превращается в аккуратный список.

• uniq — убирает дубликаты:

cat users.txt | sort | uniq

• nl — нумерует строки:

cat config.yaml | nl

Удобно искать по номерам, а не на глаз.

Вместе они превращают любой текстовый файл в данные, с которыми приятно работать.

Например:

cat access.log | cut -d' ' -f1 | sort | uniq -c | sort -nr | nl | head

Топ-10 IP-адресов по количеству запросов, с нумерацией.

🐸Библиотека devops'a

#арсенал_инженера

🔄 Как перестать тратить ресурсы CI/CD впустую

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

В GitHub Actions удобно использовать стандартные триггеры или dorny/paths-filter: он проверяет diff и включает лишь нужные джобы. Меняли api/ — запускается сборка API. Вносили правки в web/ — прогоняются тесты фронтенда. Тронули infra/** — стартует деплой инфраструктуры. Всё остальное CI просто пропускает.

Пример:

# .github/workflows/ci.yaml
name: CI

on:
  pull_request:
    paths:
      - "api/**"
      - "web/**"
      - "infra/**"
  push:
    branches: [ main ]
    paths:
      - "api/**"
      - "web/**"
      - "infra/**"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Собираем, потому что изменились файлы из paths"

В GitLab этот механизм встроен в rules:changes. Можно настроить как отдельные jobs, так и дочерние пайплайны для разных модулей. Например, API живёт своей жизнью, фронтенд — своей, а объединяет их только Merge Request.

Пример:

stages: [build, test, deploy]

build_api:
  stage: build
  rules:
    - changes:
        - api/** 
        - package.json   # глобальный файл, влияющий на сборку API
      when: on_success
    - when: never
  script:
    - echo "Build API"; # ваши шаги

test_web:
  stage: test
  rules:
    - changes:
        - web/**
        - package.json
      when: on_success
    - when: never
  script:
    - echo "Test Web"

deploy_infra:
  stage: deploy
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      changes:
        - infra/**
        - .gitlab-ci.yml
      when: on_success
    - when: never
  script:
    - echo "Deploy Infra"

Не забывайте добавлять в фильтры и глобальные файлы — вроде package-lock.json или .gitlab-ci.yml. Они влияют на весь проект, и пропускать их опасно.

🐸Библиотека devops'a

#арсенал_инженера

😏 Быстрое переключение контекстов в Kubernetes

Когда работаете с Kubernetes, всегда приходится переключаться между кластерами — dev, staging, test, pre-prod, prod.
И каждый раз вводить длинное kubectl config use-context ... не только утомительно, но и чревато опечатками. За день такие мелочи могут отнять много времени.

Решение — небольшая утилита kubectx. Она делает переключение контекстов быстрым и удобным:

kubectx staging
kubectx prod
kubectx -

В паре с ней идёт kubens — тот же принцип, но для неймспейсов.

Итог: меньше рутины, выше скорость и меньше шансов ошибиться на боевых окружениях.

➡️ Переключить контекст

🐸Библиотека devops'a

#арсенал_инженера

🚦 Ускоряем GitLab CI/CD

Обычный пайплайн в GitLab идёт «ступеньками»: сначала build, потом test, потом deploy. Даже если задачи никак не связаны, они будут терпеливо ждать друг друга. В итоге лишние минуты и часы простаивания.

Вместо жёстких стадий можно описать зависимости между стадиями. В GitLab CI это называется DAG — Directed Acyclic Graphs.

Например:

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

Выглядит это так:

unit-tests:
  stage: test
  needs: [ "build-job" ]
  script: make test

lint:
  stage: test
  script: make lint

deploy:
  stage: deploy
  needs: [ "unit-tests", "lint" ]
  script: make deploy

DAG превращает ваш CI/CD из очереди в автомагистраль. Если у вас много джобов — самое время пересмотреть пайплайн.

🐸Библиотека devops'a

#арсенал_инженера

📎 Как дебажить distroless-контейнеры в Kubernetes

Distroless-образы стали популярны благодаря минимализму: внутри только ваше приложение и рантайм: Java, Go, Node.js. Никакого bash, curl или apt. Это повышает безопасность, ускоряет скачивание и снижает поверхность атаки.

Но у такого подхода есть обратная сторона — как отлаживать контейнер без шелла и утилит?

В обычном контейнере вы просто делаете kubectl exec -it pod -- bash и изучаете логи, процессы, сетевые соединения. В distroless — так не получится: шелла и инструментов там нет.

Kubernetes позволяет «прикреплять» временные контейнеры к работающему Pod без его рестарта. Вы можете подключить образ с нужными утилитами и дебажить приложение вживую:

kubectl debug pod/<имя-пода> -it --image=busybox --target=<контейнер>

Эфемерный контейнер делит тот же namespace, что и приложение, поэтому вы получаете доступ к файловой системе, процессам и сети. После завершения отладки контейнер исчезает.

🐸Библиотека devops'a

#арсенал_инженера

⚙️ Зачем нужен Control Plane в Kubernetes

Когда говорят о Kubernetes, чаще всего представляют себе кластер из множества узлов, где запускаются контейнеры. Но вся эта система работает не сама по себе — ей нужен мозг, управляющий всеми процессами. Этим мозгом и является Control Plane.

Control Plane — это набор компонентов, которые принимают решения о том, что, где и как должно выполняться в кластере. Если рабочие узлы можно сравнить с мускулами, то Control Plane — это нервная система и голова.

В состав Control Plane входят:

• kube-apiserver — главный вход в кластер. Все команды kubectl и взаимодействия с API проходят через него. Он обеспечивает проверку запросов, аутентификацию и валидацию.

• etcd — распределённое хранилище, где держится всё состояние кластера. По сути, это “база данных” Kubernetes, в которой записано, какие ресурсы есть, какое у них состояние и какие должны быть цели.

• kube-scheduler — отвечает за то, на какой рабочий узел попадут новые поды. Он анализирует доступные ресурсы, ограничения, правила и принимает решение.

• kube-controller-manager — набор контроллеров, которые следят, чтобы желаемое состояние совпадало с фактическим. Например, если вы сказали, что должно быть три пода, а осталось два, контроллер поднимет третий.

• cloud-controller-manager (опционально) — компонент для интеграции с облаками (AWS, Azure, GCP и др.), который умеет управлять балансировщиками, дисками и сетями в зависимости от платформы.

Главная сила Control Plane в том, что он реализует декларативную модель управления. Вы описываете в манифесте YAML, что «хочу три реплики приложения», а Control Plane сам добивается этого состояния: запускает поды, следит за их здоровьем и пересоздаёт при сбоях.

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

🐸Библиотека devops'a

#Арсенал_инженера

⚙️ Как получить середину файла в Bash

Команды head и tail отлично показывают начало и конец файла.
Но иногда нужно не первое и не последнее — а что-то из середины: фрагмент лога, центр дампа или середину отчёта.

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

Пример:

body -C5 app.log

Скрипт найдёт середину файла

🐸Библиотека devops'a

#арсенал_инженера

🧑‍💻 Используем NGINX как AI-прокси

За последние годы мир AI расширился до множества провайдеров моделей (LLM), каждый со своими API.
Чтобы упростить интеграцию, маршрутизацию и безопасность между приложениями и этими моделями, NGINX предлагает себя как лёгкий AI-прокси: он принимает запросы, трансформирует их (если нужно), маршрутизует, логирует и управляет отказами.

Как это работает:

• Если клиент шлёт запрос в формате OpenAI, но конечная модель — Anthropic, прокси с помощью NJS-скрипта преобразует вход («OpenAI → Anthropic») и выход обратно.

• В конфигурации хранится JSON с правами пользователей: модель A доступна одному, модель B — другому. Прокси проверяет, есть ли у пользователя доступ к запрашиваемой модели.

• Если запрос к основной модели неудачен, например, лимит или сбой API, прокси перенаправит на резервную модель по настройкам.

• После получения ответа прокси извлекает статистику токенов: prompt, completion, total и записывает её в логи NGINX.

Фрагмент конфига:

js_import /etc/njs/aiproxy.js;

server {
    listen 4242;
    default_type application/json;

    location /v1/chat/completions {
        set $aiproxy_user $http_x_user;
        js_content aiproxy.route;
    }

    location /openai {
        internal;
        rewrite ^ /v1/chat/completions;
        proxy_set_header Authorization 'Bearer ${OPENAI_API_KEY}';
        proxy_pass https://api.openai.com;
    }
    location /anthropic {
        internal;
        rewrite ^ /v1/messages;
        proxy_set_header x-api-key ${ANTHROPIC_API_KEY};
        proxy_pass https://api.anthropic.com;
    }
}

Прокси может подгружать права доступа из файла rbac.json, использовать настройки failover и преобразовывать запросы и ответы.

➡️ Блог NGINX

🐸Библиотека devops'a

#арсенал_инженера

🐳 Что такое Dockerfile

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

Всё строится из простых инструкций:

FROM golang:1.22-alpine   # базовый образ
WORKDIR /app              # рабочая директория
COPY . .                  # копируем файлы
RUN go build -o main .    # собираем проект
CMD ["./main"]            # команда запуска

• FROM — задаёт базовый слой (например, ubuntu, node, golang)
• WORKDIR — где выполняются команды
• COPY / ADD — добавляют файлы внутрь контейнера
• RUN — выполняет команды во время сборки
• CMD / ENTRYPOINT — определяют, что запустится при старте контейнера
• EXPOSE — сообщает, какие порты слушает контейнер
• ENV — задаёт переменные окружения

1. Docker читает Dockerfile построчно.
2. Каждая команда создаёт слой в образе.
3. Эти слои кэшируются — поэтому повторная сборка идёт быстрее.
4. Готовый образ можно запускать как контейнер, передавая параметры и окружение.

Что такое слой

Каждый слой — это snapshot изменений файловой системы.

На нашем примере:

1️⃣ FROM golang:1.22-alpine

Docker берёт готовый базовый образ с Golang и Alpine Linux.
Это уже несколько слоёв, собранных кем-то раньше:

• минимальная система (Alpine)
• системные библиотеки
• установленный Go-компилятор

Эти слои загружаются из Docker Hub и кэшируются локально.
Все они read-only — вы их не меняете, просто используете как основу.

2️⃣ WORKDIR /app

Создаётся новый слой, где внутри файловой системы появляется папка /app.
Теперь все последующие команды будут выполняться именно в ней.

Даже если она пуста, Docker фиксирует это изменение файловой структуры как отдельный слой.

3️⃣ COPY . .

Docker копирует все файлы из текущей директории (build context) в /app контейнера.
Результат — ещё один слой, где лежат исходники вашего проекта.

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

4️⃣ RUN go build -o main .

Docker запускает внутри контейнера команду go build.
Она создаёт бинарник main прямо в /app.

После завершения — создаётся новый слой,
в котором лежит тот самый скомпилированный файл.
Предыдущие слои (с исходниками, библиотеками и т.д.) остаются неизменными.

5️⃣ CMD ["./main"]

Это не создаёт новый слой.
CMD добавляет метаданные — какую команду Docker должен запустить,
когда контейнер стартует docker run image_name.

Dockerfile — это сердце контейнеризации. Без него не было бы reproducible-сборок, dev/test окружений и того самого works on my machine.

🐸 Библиотека devops'a

#арсенал_инженера

🖥 JSON Crack — визуализируйте данные

JSON Crack — это сервис сразу превращает данные в наглядное дерево: можно раскрывать узлы, искать нужные поля и экспортировать схему как изображение. Всё работает прямо в браузере — без отправки данных на сервер.

Кроме JSON поддерживаются YAML, XML, CSV и TOML. Есть валидатор, конвертер и генератор типов для TypeScript и Go. Отличный инструмент, если нужно быстро разобраться в структуре API или объяснить коллегам, как устроен ответ сервера.

➡️ Визуализировать свой JSON

🐸 Библиотека devops'a

#арсенал_инженера