🛠 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

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