DevOps
По всем вопросам- @workakkk @itchannels_telegram - 🔥полезные ит-каналы https://t.me/Golang_google - Golang программирование @golangl - golang chat @GolangJobsit - golang channel jobs @golang_jobsgo - jobs РКН: clck.ru/3FmvZA #VRHSZ
Показати більше📈 Аналітичний огляд Telegram-каналу DevOps
Канал DevOps (@devopsitsec) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 23 589 підписників, посідаючи 5 462 місце в категорії Технології та додатки та 27 814 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 23 589 підписників.
За останніми даними від 28 серпня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 92, а за останні 24 години на -2, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 10.21%. Протягом перших 24 годин після публікації контент зазвичай збирає 5.10% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 2 406 переглядів. Протягом першої доби публікація в середньому набирає 1 202 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 8.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як devops, kubernetes, git, github, кластер.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥полезные ит-каналы
https://t.me/Golang_google - Golang программирование
@golangl - golang chat
@GolangJobsit - golang channel jobs
@golang_jobsgo - jobs
РКН: clck.ru/3FmvZA
#VRHSZ”
Завдяки високій частоті оновлень (останні дані отримано 29 серпня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
> text.txt
@devopsitseccontainer. Это инструмент для создания и запуска Linux-контейнеров на macOS.
Что важно:
● Написан на Swift и оптимизирован под Apple Silicon
● Использует собственный механизм контейнеризации и лёгкие виртуалки
● Поддерживает стандартные OCI-образы (совместим с Docker/Podman)
Полезный и нативный способ запускать контейнеры прямо на Mac.
Наконец‑то альтернатива Docker, сделанная самими Apple.
📦 Два пакета:
1. `containerization` — низкоуровневый API:
• управление образами,
• загрузка из репозиториев,
• создание Ext4 rootFS,
• запуск изолированных процессов в vminitd.
2. `container` — высокоуровневый инструмент в стиле Docker:
• команды для запуска, остановки и управления,
• интеграция с launchd.
⚡️ Быстрый запуск VM (<1 сек) достигается за счёт оптимизированного ядра и init-системы vminitd. Обмен с VM происходит через gRPC поверх vsock.
📌 Совместимость:
• Работает в macOS 15 и новее, но рекомендуется macOS 15.6 Beta 1 — только там:
• корректно работает с сетями,
• поддерживается IP-перевязка.
• Только Apple Silicon (Intel — не поддерживается).
• Поддержка Rosetta 2 позволяет запускать x86-контейнеры.
🔓 Инструмент уже доступен на GitHub и открыт для разработчиков.
container system start
➡️ Гайд по работе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
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 внутри и вне контейнера — включая монтирование хостовых директорий. Это делает возможным побег из контейнера.
💡 Такой пайплайн не только безопаснее, но и более прозрачен, масштабируем и предсказуем.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.