DevOps
По всем вопросам- @workakkk @itchannels_telegram - 🔥полезные ит-каналы https://t.me/Golang_google - Golang программирование @golangl - golang chat @GolangJobsit - golang channel jobs @golang_jobsgo - jobs РКН: clck.ru/3FmvZA #VRHSZ
Mostrar más📈 Análisis del canal de Telegram DevOps
El canal DevOps (@devopsitsec) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 23 589 suscriptores, ocupando la posición 5 462 en la categoría Tecnologías y Aplicaciones y el puesto 27 814 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 23 589 suscriptores.
Según los últimos datos del 28 agosto, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 92, y en las últimas 24 horas de -2, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 10.21%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 5.10% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 406 visualizaciones. En el primer día suele acumular 1 202 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 8.
- Intereses temáticos: El contenido se centra en temas clave como devops, kubernetes, git, github, кластер.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @workakkk
@itchannels_telegram - 🔥полезные ит-каналы
https://t.me/Golang_google - Golang программирование
@golangl - golang chat
@GolangJobsit - golang channel jobs
@golang_jobsgo - jobs
РКН: clck.ru/3FmvZA
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 29 agosto, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
> 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.