Крутой репозиторий, который содержит 2600+ вопросов с ответами и упражнений по DevOps, SRE, CI/CD, Kubernetes, Linux и не только.


Отлично подходит для подготовки к собесам и прокачки навыков.

Ссылка тут.

🎯 Как ускорить навигацию в командной строке


🔁 Повторный запуск под root — sudo !!

user@host: cat /var/log/messages
cat /var/log/messages: Permission denied.
❌Как не надо: Вверх. Влево. Влево. Влево. …. sudo Enter. Рррр.
✅Как надо: sudo !!


🔂 Повтор последнего аргумента — Alt + .

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

❌Как не надо: mkdir MyNewDirectory; cd MyNewDirectory
✅Как надо:

mkdir MyNewDirectory
cd <Alt+.>


🔍 Поиск команды в истории — Ctrl + R

Какую же команду я только что запускал? Вверх. Вверх. Вверх. Вверх. О, вот и она!

Снова и снова вам приходится копаться в истории, ведь вы не знаете более подходящих альтернатив. Но что, если я скажу вам о том, что есть… поиск?

❌Как не надо: Вверх. Вверх. Вверх. Enter.
✅Как надо: Ctrl+R

Просто нажмите Ctrl+R и введите первые буквы нужной команды. Если поиск не выдал нужную команду сразу, то нажмите Ctrl+R еще раз. Повторное нажатие используется для прокрутки результатов. Ниже приведен поиск для cat.

(reverse-i-search)cat: sudo cat /var/log/messages


🏠 Домашняя директория — cd

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


🔙 Назад в прошлую директорию — cd -

Иногда простой способ — самый лучший. Допустим, вы были в директории /var/www/foo, а теперь оказались в /etc . Простая команда cd — вернет вас обратно в /var/www/foo .

❌Как не надо: cd /var/www/foo
✅Как надо: cd -


🎭 Фоновый режим, передний план и контроль задач

Возможно, вам потребуется какое-то время, чтобы привыкнуть, но оно того стоит. Допустим, вы редактируете файл в vim (вы же не будете этого делать в nano, да?!). И вот вам вдруг захотелось что-то найти в директории /var/www/html. Конечно же, вы можете выйти из vim, перейти в нужную директорию, а потом вдруг решить, что неплохо было бы вернуться к редактированию. Есть и другой вариант — перевести vim в фоновый режим и вернуться к нему позже.

Напишите: Ctrl+Z. Эта комбинация переводит все текущие задачи с переднего плана в фоновый режим. Полезно как минимум для: less, cat, man, vim и т.д.

«И куда же отправится моя активная задача?» — спросите вы. Напишите jobs и сами узнаете.

user@host: jobs
[1] Stopped vim
Супер. Теперь можно заняться чем-то другим. А как только вы решите вернуться к задаче, напишите fg. Эта команда возвращает фоновую задачу (vim) на передний план. Обратите внимание, что фоновые процессы приостанавливаются. Поэтому если в файле вы выполняли что-то из разряда tail, то для завершения команды потребуется какое-то время. Если же в фоновом режиме запущено несколько задач, то напишите fg 3 , где 3 — это номер задачи для возобновления. Увидеть список задач можно по команде jobs.

🧠 Задача: Безопасный CI/CD для Docker-образов в GitLab

Условие:
У вас есть следующий пайплайн:

build_and_push:
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
    - docker build -t "$CI_REGISTRY_IMAGE:latest" .
    - docker push "$CI_REGISTRY_IMAGE:latest"

Он работает, но содержит серьёзные проблемы безопасности и архитектурные ошибки.

🚨 Проблемы:

1. `docker:dind` и `tcp://docker:2375` — критически уязвимы.
Это значит, что любой процесс может получить root-доступ к Docker-демону, а значит и к хосту раннера.

2. Нет валидации образов или сканирования.
В репозиторий может попасть уязвимый образ.

3. Использование тега `latest`.
Тег можно перезаписать в любой момент — нарушает идемпотентность и аудит.

4. Пароли в переменных среды.
Лучше использовать безопасные токены (например, OIDC).

5. Нет изоляции сборки.
Образ может использовать --privileged, --network=host, и не быть sandboxed.

✅ Цель: Переделать пайплайн

Переход от DIND → kaniko, добавить проверку безопасности и стабильную версификацию.

🛡️ Обновлённый .gitlab-ci.yml

variables:
  IMAGE_TAG: "${CI_COMMIT_SHORT_SHA}"

build_and_push:
  image:
    name: gcr.io/kaniko-project/executor:latest
    entrypoint: [""]
  script:
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor \
        --context $CI_PROJECT_DIR \
        --dockerfile $CI_PROJECT_DIR/Dockerfile \
        --destination $CI_REGISTRY_IMAGE:$IMAGE_TAG \
        --destination $CI_REGISTRY_IMAGE:stable \
        --snapshotMode=redo \
        --single-snapshot

scan_image:
  image: aquasec/trivy:latest
  stage: test
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$IMAGE_TAG

🔍 Разбор улучшений:

• Kaniko — работает без привилегий, не требует docker.sock
• `IMAGE_TAG` = SHA — версии стабильны, audit-friendly
• Trivy — автоматическое сканирование уязвимостей
• Удаление `latest` — используем stable и SHA
• Нет `docker:dind` — безопаснее, проще и быстрее
• Безопасная аутентификация — можно заменить username/password на OIDC в GitLab

📌 Дополнительно:

1. Добавьте rules: в пайплайн, чтобы запускать сборку только по main или тэгам.
2. Используйте readonly контейнеры и fsGroup если применимо.
3. Ограничьте доступ к runner через protected: true.

💣 Бонус: почему docker:dind = уязвимость?

Если runner запускается в privileged режиме, то docker:dind даёт возможность выполнять произвольные команды от root внутри и вне контейнера — включая монтирование хостовых директорий. Это делает возможным побег из контейнера.

💡 Такой пайплайн не только безопаснее, но и более прозрачен, масштабируем и предсказуем.

🐧 Малоизвестный, но полезный совет для Linux

Хочешь ускорить работу в терминале?

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

🔧 Пример:

mkdir new_project
cd !$

📌 Ещё пример:

curl https://example.com/file.zip
wget !$

Другими словами эти символы, заменяются последним аргументом предыдущей строки команды.


🔁 Работает с vim, cp, mv, tar и др.

💡 Экономит много времени!

🚀 Zadig — облачная DevOps-платформа с открытым исходным кодом. Проект предлагает гибкие workflow-решения для Kubernetes-сред, позволяя командам автоматизировать процессы тестирования и доставки кода без глубокого погружения в инфраструктурные детали.

Разработчики используют неинвазивный подход к CI/CD, где пользователи могут быстро настраивать пайплайны через готовые шаблоны. Платформа поддерживает различные стратегии релизов и предоставляет инструменты для мониторинга производительности процессов.

🤖 GitHub

@devopsitsec

🧩 DevOps-задача с подвохом: всё работает, но тормозит

У вас в Kubernetes кластере работает микросервис orders. Всё "зелёное":
- ✅ нет ошибок 5xx
- ✅ логи чистые
- ✅ CPU и RAM в норме
- ✅ Pod'ы не рестартятся
- ✅ HPA не срабатывает

Но пользователи жалуются: ⚠️ заказы проходят с задержкой до 1.5 сек.

🔍 Что под капотом:
- 3 реплики orders
- Зависимость: inventory (всего 1 реплика)
- Один из `orders`-подов иногда теряет сетевое соединение на ~30 сек
- Readiness-проба — /healthz, всегда 200 OK
- HPA срабатывает только по CPU > 80%
- Есть метрика queue_size, но она нигде не используется


🎯 Что происходит?
Kubernetes считает проблемный под "живым", потому что /healthz отвечает.
Но этот под не может достучаться до inventory.
Часть трафика уходит в никуда и тормозит.

CPU низкий, ошибок нет — HPA не срабатывает.
Проблема остаётся невидимой, пока пользователи страдают.


✅ Как починить:

1. ✂️ **Проверять зависимости в Readiness:**
```yaml
readinessProbe:
exec:
command: ["sh", "-c", "curl -sf http://inventory/healthz || exit 1"]
```

2. 📈 **Добавить алерты на latency, queue size и gRPC ошибки**

3. ⚖️ **Настроить HPA по бизнес-метрикам:**
```yaml
type: External
metric:
name: queue_size
```

4. 🧬 **Добавить 2+ реплики в `inventory`** — избавляемся от SPOF

5. 🧠 **Включить tracing (например, Jaeger)** для отслеживания зависаний

💡 **Урок:** Даже без ошибок система может работать нестабильно.
DevOps-инженер должен уметь **видеть деградацию до того, как её заметит пользователь.**

#DevOps #Kubernetes #SRE #Monitoring #CI_CD #HPA

🛡️ Инструмент для анализа Kerberos

KerbTool — это утилита для взаимодействия с Kerberos-протоколом, разработанная для тестирования безопасности и проведения атак на аутентификацию в Active Directory. Написана на Go.

🧰 Возможности:
• AS-REQ с любым именем пользователя (без предварительной аутентификации)
• Получение TGT и TGS
• Поддержка дешифровки и анализа билетов
• Brute-force и словарные атаки на учетные записи
• Поддержка режимов "kerberoasting" и "asreproasting"
• Работает в Linux, Windows и MacOS

🎯 Для чего используется:
• Red team-проверки
• Аудит конфигурации Kerberos
• Тестирование уязвимостей в аутентификации
• Извлечение хэшей из TGS/AS-REP без входа в систему

💡 Альтернатива таким инструментам как Impacket и Rubeus, но в удобной кроссплатформенной обёртке на Go.

https://github.com/jfjallid/kerbtool

🔥 Успех в IT = скорость + знания + окружение

Здесь ты найдёшь всё это — коротко, по делу и без воды.
Пока другие ищут, где “подглядеть решение”, ты уже используешь самые свежие инструменты!

AI: www.tgoop.com/ai_machinelearning_big_data
Python: www.tgoop.com/pythonl
Linux: www.tgoop.com/linuxacademiya
Собеседования DS: www.tgoop.com/machinelearning_interview
C++ www.tgoop.com/cpluspluc
Docker: www.tgoop.com/DevopsDocker
Хакинг: www.tgoop.com/linuxkalii
Devops: www.tgoop.com/devops_teleg
Data Science: www.tgoop.com/data_analysis_ml
Javascript: www.tgoop.com/javascriptv
C#: www.tgoop.com/csharp_ci
Java: www.tgoop.com/javatg
Базы данных: www.tgoop.com/sqlhub
Python собеседования: www.tgoop.com/python_job_interview
Мобильная разработка: www.tgoop.com/mobdevelop
Golang: www.tgoop.com/Golang_google
React: www.tgoop.com/react_tg
Rust: www.tgoop.com/rust_code
ИИ: www.tgoop.com/vistehno
PHP: www.tgoop.com/phpshka
Android: www.tgoop.com/android_its
Frontend: www.tgoop.com/front
Big Data: www.tgoop.com/bigdatai
МАТЕМАТИКА: www.tgoop.com/data_math
Kubernets: www.tgoop.com/kubernetc
Разработка игр: https://www.tgoop.com/gamedev
Haskell: www.tgoop.com/haskell_tg
Физика: www.tgoop.com/fizmat

💼 Папка с вакансиями: www.tgoop.com/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: www.tgoop.com/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: www.tgoop.com/addlist/eEPya-HF6mkxMGIy
Папка ML: https://www.tgoop.com/addlist/2Ls-snqEeytkMDgy
Папка FRONTEND: https://www.tgoop.com/addlist/mzMMG3RPZhY2M2Iy

😆ИТ-Мемы: www.tgoop.com/memes_prog
🇬🇧Английский: www.tgoop.com/english_forprogrammers
🧠ИИ: www.tgoop.com/vistehno

🎓954ГБ ОПЕНСОРС КУРСОВ: @courses
📕Ит-книги бесплатно: https://www.tgoop.com/addlist/BkskQciUW_FhNjEy

Подпишись, если хочешь быть в числе тех, кого зовут в топовые проекты!

🔧 OpenSAGE — амбициозный проект по реверс-инжинирингу игрового движка из классических стратегий. Разработчики ставят перед собой сложную задачу: воссоздать с нуля технологию SAGE, которая использовалась в играх EA Pacific, не нарушая авторских прав.

Проект находится на ранней стадии — сейчас ведется работа с форматами данных (.map, .w3d, .ini и другими) и рендерингом. Команда использует интересный подход: вместо декомпиляции исходного кода они анализируют файлы ресурсов и поведение оригинальной игры, что делает проект легальным с точки зрения законодательства.

🤖 GitHub

🧩 Контейнеры утекают из-под контроля: расследование Container Drift

Исследователи из Detectify опубликовали глубокий разбор того, как дрейф контейнеров (container drift) может привести к незаметному скомпрометированному окружению — даже при использовании современных DevSecOps-практик.

🧠 Что такое container drift?
Это когда контейнер на проде начинает вести себя не так, как при сборке: в него попадают новые файлы, изменяются бинарники, запускаются подозрительные процессы — всё это делает инфраструктуру уязвимой, а атаки — малозаметными.

🔍 В статье исследуются:
• Как злоумышленники модифицируют контейнеры после развертывания
• Какие артефакты и следы остаются внутри образов
• Как выявить отклонения с помощью forensics-инструментов
• Почему традиционные сканеры не всегда работают

📌 Вывод: Даже если контейнер был безопасен при сборке — он может «уплыть» в неизвестном направлении. Нужны новые методы мониторинга и реагирования на изменения внутри работающих образов.

🔗 Читайте полную статью: https://detect.fyi/adrift-in-the-cloud-a-forensic-dive-into-container-drift-f29524f4f6c4

🚀 Jenkins X — инструмент для автоматизации CI/CD в Kubernetes, который умеет разворачивать Preview Environments прямо в pull requests. Всё работает на Cloud Native pipelines от Tekton.

В основе интерфейса лежит jx CLI, модульная утилита для управления процессами. Есть куча плагинов, отдельные библиотеки для работы с SCM, Kubernetes и Lighthouse, а также Octant-UI для визуализации.

🤖 GitHub

@devopsitsec

Ozon Tech приглашает на Platform Meetup.

20 июня инженеры команды Платформы расскажут, как запустили учения по отключению дата-центра.

Что в программе:
⚫️ запуск боевых нагрузочных тестов по продовым рубежам;
⚫️ восстановление порядка в хаосе с волшебными пуллерами и discovery во спасение кластеров;
⚫️ активацию токенов, пробуждение протоколов и новую жизнь системы;
⚫️ Service Mesh и вести об отключении через Warden;
⚫️ единство множества кластеров в славном Федеративном Кубере.

Регистрируйтесь на офлайн/онлайн.

Полезная таблица инструментов DevSecOps

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

#devops #девопс

@devopsitsec

🌪️ Atmos — проект, делающий инфраструктурный код управляемым. Этот инструмент предлагает необычный подход к работе с Terraform, превращая моноолитные конфигурации в модульные компоненты, связанные через YAML-стэки.

Atmos позиционируется как мост между сложностью enterprise-инфраструктуры и простотой локальной разработки, позволяя применять одни и те же практики и в CI/CD, и в командной строке. Инструмент явно рассчитан на тех, кто устал от кастомных bash-скриптов для оркестрации Terraform, но не готов погружаться в полноценные платформы вроде Crossplane.

🤖 GitHub

@devopsitsec

⚙️ Написание собственного Load Balancer всего за 250 строк кода

В свежей статье на *Beyond the Syntax* Sushant Dhiman показывает, как создать HTTP‑балансировщик нагрузки с нуля, используя всего ~250 строк Go-кода!

👨‍💻 Что в статье:
- Простой балансировщик, который принимает HTTP-запросы и распределяет их на пул серверов.
- Поддержка алгоритма round‑robin.
- Health‑checks: временно убирает из пула серверы, которые не отвечают.
- Как добавлять и убирать бэкенды динамически.
- Версия с конкурентной обработкой запросов.

🧩 Почему это полезно:
- Понятный, минималистичный код — отлично подойдёт для учебы и практики.
- Пошагово объясняется каждый компонент: от приёма соединений до проверок здоровья серверов.
- Реализация буквально «на коленке», без сложных фреймворков.

🚀 Итог:
Учебный, но практичный пример, как за минимальными усилиями и строками кода получить работующий Layer‑7 балансировщик. Отлично для новичков и тех, кто хочет вникнуть «под капот» инфраструктуры.

🔗 Читайте статью

@DevOPSitsec

🧠 AI для Linux-админов: как ИИ меняет DevOps

Pro.Tecmint запустили серию «AI for Linux» — практическое руководство по применению языковых моделей (ChatGPT, GPT4All, DeepSeek) в администрировании и автоматизации.

📌 Что внутри:
• Интеграция LLM в bash-скрипты
• ShellGPT, TerminalGPT, Aichat, Warp Terminal
• GPT4All и DeepSeek для офлайн-логов
• Fabric AI и настройка Python-окружения

⚙️ Это не просто обзор. Это практика для DevOps и сисадминов, которые хотят автоматизировать рутину и ускорить решения прямо из консоли.

🧩 Важно: материалы доступны только подписчикам Pro.Tecmint.

Полезно, если:
✔️ Ты уже уверенно работаешь с Linux
✔️ Хочешь встроить ИИ в свои shell‑скрипты и пайплайны
✔️ Ищешь инструменты, которые реально ускоряют работу

❌ Не подойдёт новичкам — нужно знать, как работает Linux под капотом.

📌 Читать

@DevOPSitsec

📊 Данные не врут. Твои навыки — тоже.

Яндекс Практикум предлагает пройти тест, который объективно оценит, насколько ты готов к работе в BigTech.

Тест состоит из двух частей:

1️⃣ Задачи на хард скиллы — реальные кейсы с собеседований в топовых IT-компаниях;
2️⃣ Задания на софт скиллы — оценивают коммуникацию и командную работу, важные для больших проектов.

По итогу ты получаешь подробный фидбек и шкалу готовности — где ты сейчас и какие навыки стоит прокачать.

В Яндекс Практикуме есть курсы для разработчиков, тестировщиков, DevOps и аналитиков с опытом — чтобы быстро и эффективно подтянуть квалификацию.
Обучение проходит с реальными проектами и живой проверкой от экспертов из Яндекса, Amazon, Ozon и других.

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

Реклама, АНО ДПО “Образовательные технологии Яндекса”, ИНН 7704282033, erid: 2VtzqwWcUm4