Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
Docker
01- Основы. Принцип работы. Почему docker. Сравнение с виртульной машиной. Применение.
02- Установка Docker в Linux и Windows.
03- Основные команды. Управление портами. Port Mapping.
04- Переменные. Environment Variables.
05- Volumes. Постоянные данные. Persisting Data.
06- Сети в докер. Network: bridge, host, none, macvlan, ipvlan
07- Dockerfile. Создаем СВОИ контейнеры.
08- Docker-COMPOSE. Простой запуск контейнеров.
09- Portainer. Управлять Docker ПРОСТО. Обзор, установка, настройка.
10- Watchtower. Автоматизация: обновление Docker контейнеров.
источник
👉 @devops_star
01- Основы. Принцип работы. Почему docker. Сравнение с виртульной машиной. Применение.
02- Установка Docker в Linux и Windows.
03- Основные команды. Управление портами. Port Mapping.
04- Переменные. Environment Variables.
05- Volumes. Постоянные данные. Persisting Data.
06- Сети в докер. Network: bridge, host, none, macvlan, ipvlan
07- Dockerfile. Создаем СВОИ контейнеры.
08- Docker-COMPOSE. Простой запуск контейнеров.
09- Portainer. Управлять Docker ПРОСТО. Обзор, установка, настройка.
10- Watchtower. Автоматизация: обновление Docker контейнеров.
источник
👉 @devops_star
👍5
Назовите главные компоненты архитектуры Kubernetes.
Master-ноды (master node, control plane) координируют все операции кластера: управляют распределением и резервированием ресурсов, контролируют состояние контейнеров, управляют масштабированием и выполняют обновления. Компоненты мастер-нод включают:
kube-apiserver — точка доступа к панели управления мастер-ноды, обеспечивает взаимодействие между мастер- и рабочими узлами, отслеживает состояние рабочих узлов и информирует мастер о важных изменениях;
kube-scheduler — отвечает за распределение нагрузки на рабочие узлы, постоянно мониторит доступные ресурсы и используемые ресурсы на каждом узле, принимает решение о запуске нового Pod;
Controller Manager — управляет работой контроллеров, таких как Deployment, ReplicaSet, StatefulSets, DaemonSet, Jobs, CronJob;
ETCD — хранит информацию о настройках и состоянии кластера, его метаданные, представляет собой распределенную базу данных в формате ключ-значение.
Nodes (рабочие узлы) — на них запускаются поды с контейнерами. На каждой worker ноде Kubernetes работают:
kubelet — процесс, который управляет запуском, удалением и обновлением подов с контейнерами;
kube-proxy — настраивает сетевые правила на рабочих узлах.
Как в Kubernetes устроена работа с хранилищами?
Kubernetes имеет различные типы хранилищ, включая встроенный emtyDir. Некоторые из них являются stateless, что означает, что они существуют только во время работы пода. Данные, которые хранятся там, также имеют такой же срок жизни.
Для statefull-приложений используются постоянные хранилища, называемые Persistent Volumes (PV). PV — это запас хранилища, выделенный администратором кластера Kubernetes. Это могут быть локальные диски, СХД или внешние диски. Они не зависят от жизненного цикла подов.
Persistent Volume Claim (PVC) — это запрос на выделение PV с определенными характеристиками, такими как тип хранилища, объем и тип доступа. Для описания доступных PV используются Storage Classes.
В процессе работы под отправляет запрос PVC, который затем обращается к PV и передает его поду.
👉 @devops_star
Master-ноды (master node, control plane) координируют все операции кластера: управляют распределением и резервированием ресурсов, контролируют состояние контейнеров, управляют масштабированием и выполняют обновления. Компоненты мастер-нод включают:
kube-apiserver — точка доступа к панели управления мастер-ноды, обеспечивает взаимодействие между мастер- и рабочими узлами, отслеживает состояние рабочих узлов и информирует мастер о важных изменениях;
kube-scheduler — отвечает за распределение нагрузки на рабочие узлы, постоянно мониторит доступные ресурсы и используемые ресурсы на каждом узле, принимает решение о запуске нового Pod;
Controller Manager — управляет работой контроллеров, таких как Deployment, ReplicaSet, StatefulSets, DaemonSet, Jobs, CronJob;
ETCD — хранит информацию о настройках и состоянии кластера, его метаданные, представляет собой распределенную базу данных в формате ключ-значение.
Nodes (рабочие узлы) — на них запускаются поды с контейнерами. На каждой worker ноде Kubernetes работают:
kubelet — процесс, который управляет запуском, удалением и обновлением подов с контейнерами;
kube-proxy — настраивает сетевые правила на рабочих узлах.
Как в Kubernetes устроена работа с хранилищами?
Kubernetes имеет различные типы хранилищ, включая встроенный emtyDir. Некоторые из них являются stateless, что означает, что они существуют только во время работы пода. Данные, которые хранятся там, также имеют такой же срок жизни.
Для statefull-приложений используются постоянные хранилища, называемые Persistent Volumes (PV). PV — это запас хранилища, выделенный администратором кластера Kubernetes. Это могут быть локальные диски, СХД или внешние диски. Они не зависят от жизненного цикла подов.
Persistent Volume Claim (PVC) — это запрос на выделение PV с определенными характеристиками, такими как тип хранилища, объем и тип доступа. Для описания доступных PV используются Storage Classes.
В процессе работы под отправляет запрос PVC, который затем обращается к PV и передает его поду.
👉 @devops_star
👍3❤1
Media is too big
VIEW IN TELEGRAM
Docker с 0 до 100%. Всё, что нужно знать.
00:00:00 | Intro
00:01:35 | Основы Docker.
00:19:30 | Установка Docker в Linux и Windows.
00:25:40 | Основные команды.
00:54:55 | Управление портами: Port Mapping.
01:08:55 | Переменные в Docker: Environment Variables.
01:20:20 | Постоянные данные: Docker Volumes.
01:48:41 | Сети в Docker. Network.
02:30:11 | Создание своих контейнеров. Dockerfile.
03:40:59 | Docker Compose. Применение.
04:32:28 | Portainer – Web UI для управления Docker.
источник
👉 @devops_star
00:00:00 | Intro
00:01:35 | Основы Docker.
00:19:30 | Установка Docker в Linux и Windows.
00:25:40 | Основные команды.
00:54:55 | Управление портами: Port Mapping.
01:08:55 | Переменные в Docker: Environment Variables.
01:20:20 | Постоянные данные: Docker Volumes.
01:48:41 | Сети в Docker. Network.
02:30:11 | Создание своих контейнеров. Dockerfile.
03:40:59 | Docker Compose. Применение.
04:32:28 | Portainer – Web UI для управления Docker.
источник
👉 @devops_star
🔥4👍1
Контейнеризация
От Docker до Kubernetes: историческая ретроспектива
Введение в Docker
Введение в Kubernetes. Часть 1. Установка кластера
Введение в Kubernetes. Часть 2. Поды и сервисы
Введение в Kubernetes. Часть 3. Горизонтальное маштабирование.
Введение в Kubernetes. Часть 4. Отказоустойчивость для клиентов
Введение в Kubernetes. Часть 5. Интеграция с NFS
Что такое операторы в Kubernetes?
источник
👉 @devops_star
От Docker до Kubernetes: историческая ретроспектива
Введение в Docker
Введение в Kubernetes. Часть 1. Установка кластера
Введение в Kubernetes. Часть 2. Поды и сервисы
Введение в Kubernetes. Часть 3. Горизонтальное маштабирование.
Введение в Kubernetes. Часть 4. Отказоустойчивость для клиентов
Введение в Kubernetes. Часть 5. Интеграция с NFS
Что такое операторы в Kubernetes?
источник
👉 @devops_star
👍6
Расскажите, как вы будете запускать приложение в Kubernetes, если из инструментов у вас только kubectl?
Общий процесс запуска приложения в Kubernetes выглядит следующим образом:
1. Сначала необходимо упаковать приложение в контейнер.
2. Далее запускаем контейнер в виде реплик с использованием Deployment.
3. Для доступности приложения в интернете и возможности подключения к нему настраиваем сервис LoadBalancer, который присваивает публичный IP-адрес и позволяет подключаться к кластеру извне.
4. Для маршрутизации трафика через балансировщик создаем Ingress в кластере, описывающий правила маршрутизации, и запускаем Ingress-контроллер.
Все эти шаги можно выполнить с помощью kubectl, используя командную строку. Это императивный способ управления Kubernetes, когда мы явно указываем, что нужно сделать.
В промышленной эксплуатации часто используется декларативный подход, при котором мы описываем желаемое состояние в манифестах, и Kubernetes самостоятельно принимает решения о необходимых действиях. Затем мы применяем эти манифесты с помощью команды kubectl apply.
Terraform Backend. Какой лучше?
AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.
terraform enterprise — Standard (без блокировки).
etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути.
etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.
gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.
Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа.
Существуют также и другие Backend для Terraform.
👉 @devops_star
Общий процесс запуска приложения в Kubernetes выглядит следующим образом:
1. Сначала необходимо упаковать приложение в контейнер.
2. Далее запускаем контейнер в виде реплик с использованием Deployment.
3. Для доступности приложения в интернете и возможности подключения к нему настраиваем сервис LoadBalancer, который присваивает публичный IP-адрес и позволяет подключаться к кластеру извне.
4. Для маршрутизации трафика через балансировщик создаем Ingress в кластере, описывающий правила маршрутизации, и запускаем Ingress-контроллер.
Все эти шаги можно выполнить с помощью kubectl, используя командную строку. Это императивный способ управления Kubernetes, когда мы явно указываем, что нужно сделать.
В промышленной эксплуатации часто используется декларативный подход, при котором мы описываем желаемое состояние в манифестах, и Kubernetes самостоятельно принимает решения о необходимых действиях. Затем мы применяем эти манифесты с помощью команды kubectl apply.
Terraform Backend. Какой лучше?
AWS S3 — Standard (с блокировкой через DynamoDB). Сохраняет состояние в виде заданного ключа в заданном сегменте на Amazon S3. Этот бэкэнд также поддерживает блокировку состояния и проверку согласованности через DynamoDB.
terraform enterprise — Standard (без блокировки).
etcd — Standard (без блокировки). Сохраняет состояние в etcd 2.x по заданному пути.
etcdv3 — Standard (с блокировкой). Сохраняет состояние в хранилище etcd в виде K/V с заданным префиксом.
gcs — Standard (с блокировкой). Сохраняет состояние как объект в настраиваемом префиксе в заданном сегменте в Google Cloud Storage (GCS). Этот бэкэнд также поддерживает блокировку состояния.
Gitlab Terraform state (с блокировкой). Хранит состояние в Gitlab Terraform state хранилище, используя HTTP протокол и права Gitlab для доступа.
Существуют также и другие Backend для Terraform.
👉 @devops_star
👍2
Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!)
Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉
ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...
🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥
Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.
И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:
💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.
Что вы получаете за меньшие деньги:
1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.
"А подвох?" Да нигде!
▶️14 дней БЕСПЛАТНО: протестируйте всё.
▶️БЕСПЛАТНАЯ миграция: перенесем ваши проекты без простоев.
▶️Гарантия возврата: риск — ноль.
‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.
Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.
Хватит переплачивать и ждать ответа! Получите максимум.
👉 Действуйте выгодно:
1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: [email protected]
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀(Получите бонус!)
4. Присоединяйтесь: @itentis
https://itentis.cloud Мощное облако. Честная цена. Люди на связи.
Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqvR4orm
Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉
ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...
🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥
Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.
И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:
💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.
Что вы получаете за меньшие деньги:
1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.
"А подвох?" Да нигде!
▶️14 дней БЕСПЛАТНО: протестируйте всё.
▶️БЕСПЛАТНАЯ миграция: перенесем ваши проекты без простоев.
▶️Гарантия возврата: риск — ноль.
‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.
Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.
Хватит переплачивать и ждать ответа! Получите максимум.
👉 Действуйте выгодно:
1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: [email protected]
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀(Получите бонус!)
4. Присоединяйтесь: @itentis
https://itentis.cloud Мощное облако. Честная цена. Люди на связи.
Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqvR4orm
❤1👍1
Рабочие процессы Арго - паттерны, проверенные на продакшене
Argo Workflows представляет собой отличную платформу для автоматизации инфраструктуры и заменил Jenkins в качестве основного инструмента для выполнения запланированных или управляемых событиями задач автоматизации.
За время работы с Argo Workflows мне приходилось убивать кластеры, ломать рабочие процессы и вообще вносить беспорядок в работу. Я также создал множество рабочих процессов, которые нуждались в рефакторинге, поскольку их стало сложно поддерживать.
Цель этой статьи - поделиться некоторыми уроками, которые я извлек, и некоторыми паттернами, которые я разработал, чтобы помочь вам избежать тех же ошибок, которые совершил я.
https://hodgkins.io/blog/argo-workflow-proven-patterns-from-production/
👉 @devops_star
Argo Workflows представляет собой отличную платформу для автоматизации инфраструктуры и заменил Jenkins в качестве основного инструмента для выполнения запланированных или управляемых событиями задач автоматизации.
За время работы с Argo Workflows мне приходилось убивать кластеры, ломать рабочие процессы и вообще вносить беспорядок в работу. Я также создал множество рабочих процессов, которые нуждались в рефакторинге, поскольку их стало сложно поддерживать.
Цель этой статьи - поделиться некоторыми уроками, которые я извлек, и некоторыми паттернами, которые я разработал, чтобы помочь вам избежать тех же ошибок, которые совершил я.
https://hodgkins.io/blog/argo-workflow-proven-patterns-from-production/
👉 @devops_star
👍1
AI уже в терминале, пайплайнах и IDE — теперь это не тренд, а часть ежедневной работы 🤝
Если вы хотите использовать его не для генерации котиков и резюме, а в реальных DevOps-процессах — посмотрите на этот курс
Ребята показывают, как AI помогает инженерам каждый день:
- генерирует IaC через локальную LLM
- автоматизирует CI/CD через GitLab API и n8n
- делает авто-триаж алертов и документацию из действий
Не «генерация ради генерации», а конкретные инструменты: локальная LLM, GitLab API, n8n, RAG-бот.
Всё проверяется кодом и метриками, чтобы AI не ломал пайплайн, а действительно ускорял релизы
После внедрения таких решений MTTR снижается на треть, а релизы проходят стабильнее 👌
📅 Старт 20 октября, всего 20 мест
Курс «AI в DevOps» →здесь 📍
Если вы хотите использовать его не для генерации котиков и резюме, а в реальных DevOps-процессах — посмотрите на этот курс
Ребята показывают, как AI помогает инженерам каждый день:
- генерирует IaC через локальную LLM
- автоматизирует CI/CD через GitLab API и n8n
- делает авто-триаж алертов и документацию из действий
Не «генерация ради генерации», а конкретные инструменты: локальная LLM, GitLab API, n8n, RAG-бот.
Всё проверяется кодом и метриками, чтобы AI не ломал пайплайн, а действительно ускорял релизы
После внедрения таких решений MTTR снижается на треть, а релизы проходят стабильнее 👌
📅 Старт 20 октября, всего 20 мест
Курс «AI в DevOps» →здесь 📍