5️⃣ коротких и небанальных советов для Linux-администраторов

▪️ 1. Всегда проверяй journalctl вместо dmesg для современных систем

- dmesg покажет только сообщения ядра с момента загрузки.
- А journalctl -k -b -1 покажет логи ядра предыдущего ребута, что критично при расследовании падений.

---

▪️ 2. Используй ss вместо netstat

- netstat устарел и медленнее.
- ss -tunap даст быстрее и подробнее информацию о соединениях и сокетах.

---

▪️ 3. Всегда включай `bash`-историю с таймстемпами

Добавь в .bashrc:

export HISTTIMEFORMAT="%F %T "

- Теперь команда history покажет не только команды, но и время их выполнения — незаменимо при расследованиях.

---

▪️ 4. Следи за зомби-процессами правильно

- Команда:

ps -eo pid,ppid,state,cmd | grep ' Z '

- Поможет быстро находить процессы в состоянии "zombie", которые могут накапливаться и вызывать утечки ресурсов.

---

▪️ 5. Используй nice и ionice для тяжёлых задач

- Чтобы не положить систему нагрузкой от tar, rsync или других утилит:

nice -n 19 ionice -c2 -n7 tar -czf backup.tar.gz /big/data

- Это заставит процесс работать с минимальным приоритетом по CPU и диску.

@DevopsDocker

📌Как Gemini превращает изучение языков в персонализированный опыт: обзор 3 экспериментов.

Представьте, что учите язык не по учебникам, а через ситуации, в которых оказываетесь каждый день. Именно эту идею воплотила команда Google в проекте Little Language Lessons— трех экспериментах на базе Gemini API, которые делают обучение живым и контекстным.

Первый эксперимент, Tiny Lesson, решает проблему «как сказать это сейчас?». Вы описываете ситуацию — например, «потерял паспорт» — и получаете словарь и фразы в формате JSON. Всё благодаря промптам, где Gemini генерирует структурированные данные: массив терминов с транскрипцией и переводом, а также советы по грамматике.

Например, если целевой язык — японский, модель сама определит, нужна ли транскрипция ромадзи, и подготовит материал за 2 API-запроса. Это не просто список слов, а готовый микрокурс под конкретный сценарий.

Второй, Slang Hang, убирает «учебникоговорение». Тут Gemini выступает как сценарист: создаёт диалоги на целевом языке с культурными нюансами и сленгом. Все генерируется одним запросом — от контекста сцены до реплик с пояснениями. Пример: диалог продавца и туриста может включать неформальные выражения, которые не найдешь в стандартных учебниках.

Правда, иногда модель ошибается или придумывает выражения, так что без проверки носителем не обойтись. Но сам подход — дать пользователю «уши» в реальных разговорах выглядит перспективно, особенно с интеграцией Cloud Translation для мгновенного перевода.

Третий, визуальный эксперимент — Word Cam. Наводите камеру на объект, и Gemini не только определяет его (bounding box), но и предлагает слова вроде «подоконник» или «жалюзи». Детекция работает через Gemini Vision, а дополнительные дескрипторы (цвет, материал, примеры употребления) подтягиваются отдельным запросом. Для изучения бытовой лексики почти идеально, хотя точность сильно зависит от качества снимка.

Во всех экспериментах задействован Text-to-Speech — озвучка слов и фраз. Но есть нюанс: для редких языков голоса зачастую звучат неестественно или не совпадают с диалектом. Например, выберете мексиканский испанский, а синтезатор выдаст акцент из Мадрида. Разработчики честно признают: это ограничение текущих API, и над ним еще работать.

Little Language Lessons — начало переосмысления процесса обучения языкам. Проекту пока не хватает тонкой настройки под лингвистическую специфику (идиомы или региональные диалекты), но основа уже заложена.

🟡Статья


@ai_machinelearning_big_data

#AI #ML #LLM #Gemini

⚙️ DevOps‑челлендж «Zero‑Downtime? Серьёзно?»

Вам выдали репозиторий ShopCat (SaaS‑платформа).
Он уже «работает» в Kubernetes‑кластере AWS EKS, собирается GitHub Actions и раскатывается Helm‑чартом.
Менеджеры уверяют, что *«релизы без простоя, всё по‑мажору»* — но пользователи получают 502 при каждом деплое.

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

📂 Что есть в репо

.
├─ docker/
│  └─ Dockerfile        # двухступенчатая сборка
├─ helm/
│  └─ shopcat/          # Chart.yaml + values.yaml + templates/*
├─ k8s/
│  ├─ namespace.yaml
│  └─ ingress.yaml      # AWS ALB Ingress Controller
├─ .github/workflows/
│  └─ deploy.yml        # CI → CD
└─ terraform/
   ├─ eks.tf
   ├─ rds.tf
   └─ outputs.tf

⚠️ Подвох № 1 (скрытый таймер)
В Dockerfile есть RUN adduser ... с интерактивным sudo‐prompt’ом, который «застревает»,
но только если кеш Docker‑слоёв инвалидирован (например, при обновлении base‑image).

⚠️ Подвох № 2 (невидимая «дырка» в rolling‑update)
В шаблоне Deployment:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
---
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080

* /healthz возвращает 200 даже во время graceful‑shutdown (SIGTERM → 30 с drain).
* terminationGracePeriodSeconds = 60, а Ingress ALB считает Pod «живым», пока тот не закроется.
* В итоге старый Pod уже не принимает новые запросы, но остаётся в EndpointSlice ещё ±60 секунд.

⚠️ Подвох № 3 («сам себе злобный Буратино»)
Helm‑values указывают образ image: shopcat:latest.
GitHub Actions пушит тэгированный :vX.Y.Z, но тэг :latest перезаписывается той же джобой PR‑preview.
В production во время canary‑release может внезапно оказаться незамёрженый код Pull‑Request’а.

## 🏆 Задание

1. Настройте pipeline, чтобы:
* на каждый PR собирался shopcat:<sha> и катил preview‑релиз в namespace pr‑<num>,
* на main пушился shopcat:v<semver>, после чего Helm делал blue/green‑deploy в prod.
2. Измените манифесты так, чтобы во время rolling‑update не было 502/504:
* никакого даунтайма, даже если контейнеру нужно 60 с на graceful‑shutdown;
* сетевой трафик должен _сначала_ уходить от старых Pod’ов, а _потом_ те выключаются.
3. Ограничьте blast‑radius: превратить latest в «immutable image tag» и запретить Helm обновлять release, если image.tag уже был задеплоен (hint: .Chart.AppVersion + `helm.sh/hook`).
4. Найдите и исправьте «застревающий» шаг в Dockerfile, чтобы кэш всегда использовался, а билд не ждал интерактива.
5. ✅ Предоставьте:
* патчи (`.diff`) или PR в репозиторий,
* скриншот успешного kubectl rollout status deployment/shopcat ‑‑watch,
* краткое Post‑mortem (≤ 300 слов): *«Почему был даунтайм и какой фикс вы сделали»*.

## 💣 Неочевидные ограничения

* Нельзя менять исходный код приложения (только инфраструктура).
* Кластер prod имеет 2 ноды t3.medium (4 vCPU, 8 GiB) — бюджету больно от лишних replica‑set’ов.
* CI‑время — ≤ 5 мин на каждый PR.
* Все секреты — только через AWS Secrets Manager; в манифестах не должно быть plaintext.

🔜 Решение

@DevOPSitsec

💻 Kube-green — это оператор Kubernetes, разработанный для снижения углеродного следа кластеров!

🌟 Он позволяет приостанавливать модули, которые не используются, и уменьшать масштабирование кластера, что экономит ресурсы и снижает энергопотребление. В будущем планируется добавить "Green Dashboard" для мониторинга сбережений энергии и влияния на экологию.

🔐 Лицензия: MIT

🔗 Ссылка: *клик*
🖥 Github

@devopsitsec

🐳 Как устроен Docker: что происходит «под капотом»

Поговорим немного про базу.

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

1) Что такое контейнер?

Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.

2) Основные компоненты

• Docker Engine
– Docker Daemon (`dockerd`) управляет контейнерами, образами, сетями
– Docker CLI (`docker`) — интерфейс пользователя
– REST API — взаимодействие CLI и Daemon

👉 Пример: docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс.

3) Namespaces

Механизм изоляции в Linux, создающий для контейнера:

• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)

👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.

4) Cgroups

Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.

5) Union File Systems (OverlayFS)

Docker использует многослойную файловую систему. Каждый шаг Dockerfile создаёт новый слой.
При запуске контейнера создаётся верхний writable-слой, остальные read-only.

👉 10 контейнеров на одном образе разделяют слои → экономия места.

6) Container Runtime

Docker использует runc для запуска контейнера (соответствует OCI Runtime Spec).
Daemon вызывает runc, который через clone(), setns(), chroot() изолирует процесс.

7) Docker Images

Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (`/var/lib/docker`) или в реестре (Docker Hub, GitLab Container Registry).

8) Docker Networking

Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.

👉 Можно пробросить порты через -p, создать собственные сети, объединять контейнеры через docker network connect.

В Swarm используется Overlay network (сеть между хостами).

9) Безопасность

Docker использует:

• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)

⚠️ По умолчанию контейнеры имеют широкий доступ (например, /proc виден). Для production стоит ограничивать права (например, `--cap-drop`).

10) Что происходит при `docker run nginx`?

1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается runc для изоляции процесса
7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command

Контейнер живёт, пока жив его процесс.

11) Почему Docker — не магия?

Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.

Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.

12) Заключение

Под капотом Docker:

• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие

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

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

➡️ Подробнее

@DevopsDocker

🖥 Эта статья объясняет, как использовать инструмент K3D для запуска легковесных Kubernetes-кластеров K3S в контейнерах Docker!

🌟 В статье описываются шаги по установке и настройке K3D, создание кластеров, управление их состоянием и развертывание приложений. K3D идеален для локальной разработки, тестирования и CI/CD, благодаря своей простоте и низкому потреблению ресурсов.

🔗 Ссылка: *клик*

@devopsitsec