🚀 Шпаргалка по Docker 🐳

🔹 Сборка (Build)
🔹 Запуск (Run)
🔹 Шаринг (Share)
🔹 Управление (Management)


📌 Сборка образов
📍 Создать образ из Dockerfile и присвоить тег:

docker build -t myimage:1.0 .

📍 Посмотреть локальные образы:

docker image ls

📍 Удалить образ:

docker image rm alpine:3.4

📌 Запуск контейнеров
📍 Запустить контейнер на порту 5000:

docker container run --name web -p 5000:80 alpine:3.9

📍 Остановить контейнер:

docker container stop web

📍 Принудительно завершить контейнер:

docker container kill web

📍 Список запущенных контейнеров:

docker container ls

📍 Удалить все контейнеры:

docker container rm -f $(docker ps -aq)

📌 Работа с образами (Share)
📍 Скачать образ из реестра:

docker pull myimage:1.0

📍 Изменить тег у локального образа:

docker tag myimage:1.0 myrepo/myimage:2.0

📍 Запушить образ в реестр:

docker push myrepo/myimage:2.0

📌 Управление Docker (Management)
⚙️ docker app – Управление приложениями
⚙️ docker image – Управление образами
⚙️ docker container – Управление контейнерами
⚙️ docker network – Управление сетями
⚙️ docker volume – Управление хранилищами
⚙️ docker stack – Управление Docker Stack
⚙️ docker swarm – Управление кластером Swarm
⚙️ docker system – Управление всей системой

📝 Сохраните, поделитесь с друзьями и подписывайтесь на канал! 💙🐳

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Вопрос, который часто задают в начале собеса

Представлен вывод команды top. Что означает каждая запись в выводе?

top — 10:44:36 up 91 days, 19:29, 7 users, load average: 0,00, 0,02, 0,05
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,0 us, 1,5 sy, 0,0 ni, 96,9 id, 0,0 wa, 0,0 hi, 0,0 si, 1,5 st
KiB Mem : 12137392 total, 6227844 free, 1117728 used, 4791820 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 10090148 avail Mem

top — утилита
10:44:36 — время системы
up — сколько система работает с момента последнего запуска
7 user — количество авторизованных юзеров в системе
load average: 0.00, 0.02, 0.05 — параметр средней нагрузки на систему за период времени 1 минута, 5 минут, 15 минут
156 total — всего процессов в системе
1 running — количество процессов в работе
155 sleeping — ожидание процесса или сигнала
0 stopped — количество приостановленных процессов сигналом STOP или выполнение трассировки
0 zombie — количество зомби-процессов, которые завершили своё выполнение, но присутствующие в системе, чтобы дать родительскому процессу считать свой код завершения.

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

💡 Calico Whisker — безопасные сетевые политики в Kubernetes без простоев

Работая с Kubernetes, вы наверняка сталкивались с риском простоев при внедрении сетевых политик. Ошибки в конфигурации могут случайно заблокировать легитимный трафик, а отладка таких ситуаций — сплошная головная боль.

Теперь есть решение: Calico Whisker — механизм этапных сетевых политик. Суть простая:

🔸 Вы пишете политику, но не применяете её сразу.
🔸 Система "наблюдает", какой трафик она бы заблокировала или пропустила.
🔸 Вы смотрите логи, анализируете поведение.
🔸 И только потом, когда уверены, активируете её без изменений.

Это как staging-режим, только для сетевой безопасности. Без риска. Без простоя.

Идеально для DevSecOps и всех, кто хочет внедрять Zero Trust подход аккуратно и осознанно.

https://www.tigera.io/blog/calico-whisker-staged-network-policies-secure-kubernetes-workloads-without-downtime/

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Soft skills. Стоит ли вкладываться в софт скилы DevOps, программистам, тестировщикам?

Говорят Айтишник, особенно DevOps и SRE, должен быть улыбчивый, коммуникабельный и всё в этом роде. Зачем нужны софт скилы?

источник

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Kagent + Ollama: ИИ-агент для работы с Kubernetes

Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.

1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.

На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.

После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.

Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».

👉 Регистрируйтесь: https://vk.cc/d233Rj

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

📣 Kubernetes Events — новостная лента вашего кластера

Kubernetes Events — это ресурсы типа Event в Kubernetes, которые информируют вас о том, что происходит в вашем кластере. Это похоже на новостную ленту для компонентов кластера: они фиксируют всё — от запуска Pod'ов до ошибок в работе контроллеров.

Каждое событие в Kubernetes содержит:

* message: краткое описание произошедшего
* reason: код причины события
* type: Normal или Warning
* involvedObject: объект, к которому относится событие (например, Pod или Node)
* firstTimestamp, lastTimestamp, count: время и количество повторений

🔎 Как посмотреть события:

kubectl get events

Или для конкретного Pod'а:

kubectl describe pod <pod-name>

Kubernetes сам удаляет события через час. Это значит, что они не предназначены для долговременного хранения.

📤 Хранение событий

Если вам нужно сохранить события дольше, можно:

* Настроить аудит в Kubernetes
* Использовать внешние системы логирования (например, Elasticsearch + Fluentd)
* Подключить event exporters

https://decisivedevops.com/kubernetes-events-news-feed-of-your-kubernetes-cluster-826e08892d7a/

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

Проектирование CI CD. DevOps умеешь?

Не каждый DevOps инженер умеет проектировать ci cd конвейер. А сейчас все чаще и чаще это спрашивают на собеседовании DevOps инженера.

источник

#devops #девопс

📲 Мы в MAX

Подпишись 👉@i_DevOps

🔥 Elasticsearch или PostgreSQL: зачем платить за сложность?

В DevOps-сообществе тренд «просто используй Postgres» с каждым годом становится всё более актуальным. Команда TigerData выкатили отличную статью, в которой разобрали 10 главных болей при эксплуатации Elasticsearch в продакшене и объяснили, как архитектура PostgreSQL помогает их избежать.

Спойлер: с великой силой (ES) приходит великая операционная боль.

Вот лишь несколько классических проблем, о которых идет речь в материале:

☕ JVM Garbage Collection (GC). Elasticsearch работает на Java, а значит, внезапные паузы "stop-the-world" при сборке мусора - часть вашей жизни. Если нода «подвисает» надолго, кластер считает ее мертвой и начинает панически перераспределять данные. Итог: каскадный отказ на пустом месте. Postgres написан на C, управляет памятью напрямую и не страдает от подобных фризов.

🧩 Математика шардирования. Неправильный сайзинг шардов в ES - это бомба замедленного действия. Слишком маленькие шарды создают оверхед, слишком большие приводят к проблемам с ребалансировкой и восстановлением.

🔄 ETL-пайплайны и синхронизация. Держать основные данные в реляционной БД и постоянно переливать их в ES для поиска - это всегда костыли, риск рассинхрона, задержки (lag) и лишняя точка отказа.

📈 Оверхед на мониторинг. ES требует отдельного зоопарка инструментов и глубокой узконаправленной экспертизы для поддержания кластера в зеленом статусе.

Какой выход предлагают авторы?
Для большинства проектов полномасштабный ES просто не нужен. Современный PostgreSQL (благодаря мощным расширениям вроде pg_textsearch с поддержкой BM25 и pgvector для векторного поиска) отлично справляется с задачами поиска. Вы получаете полноценные ACID-транзакции, единую точку правды и предсказуемое потребление ресурсов без возни с настройкой JVM.

Рекомендуется к прочтению всем, кто устал дебажить кластеры ES по ночам и задумывается о консолидации инфраструктуры.

https://www.tigerdata.com/blog/10-elasticsearch-production-issues-how-postgres-avoids-them

#devops #elasticsearch #postgresql #database #architecture #backend


📲 Мы в MAX

Подпишись 👉@i_DevOps

22 октября Kubernetes-сообщество встречается офлайн в Москве!

Кому будет интересна конференция:
– DevOps- и SRE-инженерам;
– специалистам по Kubernetes и облачной инфраструктуре;
– платформенным инженерам;
– архитекторам и техническим руководителям;
– всем, кто занимается эксплуатацией и развитием инфраструктуры.

Что будет в течение дня?

🎤 Доклады
Программа продолжает дополняться, но уже сейчас в ней много интересных тем: 
– От бизнес-требования к ядру Linux;
– Как дать агенту управление кластером вашей инфраструктуры;
– Как в MWS Cloud Platform доставляют системный софт в managed K8s;
– Как сделать мультитенантность в Kubernetes-платформе;
– LLM-диагностика инцидентов в Kubernetes и OpenStack.

Без острых тем тоже не обойдёмся: обсудим, есть ли сегодня альтернатива Kubernetes и всегда ли стоит строить инфраструктуру вокруг него, и попробуем разобраться, правда ли ИИ однажды оставит нас без работы.

⚡️ Активности партнеров
Дополнительная возможность пообщаться с участниками конференции и включиться в интерактивные форматы от партнеров.

🍻 Афтепати
После основной программы нетворкинг продолжится уже в неформальной обстановке.

👉 Регистрируйтесь и зовите коллег — все подробности по ссылке!