DevOps
По всем вопросам- @workakkk @itchannels_telegram - 🔥полезные ит-каналы https://t.me/Golang_google - Golang программирование @golangl - golang chat @GolangJobsit - golang channel jobs @golang_jobsgo - jobs РКН: clck.ru/3FmvZA #VRHSZ
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام 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.