11687
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Связь: @devmangx № 5581790357
💡 Быстрый совет по Linux
Проверить bash-скрипт на синтаксические ошибки можно командой:
bash -n scriptname
💡 Быстрый совет по Linux 🐧
Найдите недавно изменённые файлы за последние 5 минут:
find . -type f -mmin -5
💡 Быстрый совет по Linux
При работе в редакторе nano нажмите
Alt+#
чтобы отобразить номера строк
👉 DevOps Portal
💡 Совет по Docker: Используйте аргументы в вашем Dockerfile для таких вещей, как тег базового образа.
Таким образом, вам не придется изменять Dockerfile при каждом обновлении базового образа.
$ docker build --build-arg BASE_IMAGE_TAG=20.04 -t my-image .
Микросервисы vs Монолитная архитектура
В разработке программного обеспечения выбранный архитектурный подход может существенно повлиять на масштабируемость, удобство сопровождения и общую производительность приложения. Два основных архитектурных шаблона — монолитная архитектура и микросервисы — широко используются в современной разработке.
Сегодня мы рассмотрим ключевые различия между ними, их преимущества и недостатки, а также дадим рекомендации по выбору подходящего подхода для конкретного случая.
— Что такое монолитная архитектура?
Монолитная архитектура — это традиционный подход, при котором все компоненты приложения, такие как пользовательский интерфейс, бизнес-логика и уровень доступа к данным, объединены в единую, неделимую систему. Эти компоненты тесно связаны между собой и развертываются как единое целое. Этот стиль архитектуры используется десятилетиями и остается актуальным для определенных типов приложений.
🔹Преимущества монолитной архитектуры
1. Простое развертывание: Монолитные приложения развертываются как единое целое, что делает процесс развертывания относительно простым.
2. Упрощенная разработка и тестирование: Поскольку все компоненты находятся в одном кодовом репозитории, разработчики могут легче понимать логику приложения, что упрощает разработку и тестирование.
3. Эффективное взаимодействие компонентов: В монолитном приложении компоненты взаимодействуют напрямую, так как работают в одном адресном пространстве памяти, что минимизирует накладные расходы на коммуникацию.
🔹Недостатки монолитной архитектуры
1. Проблемы с масштабируемостью: По мере роста и усложнения приложения становится трудно масштабировать отдельные компоненты независимо. В большинстве случаев приходится масштабировать всю систему, что может быть неэффективно и дорого.
2. Сложности при непрерывном развертывании: Любое обновление или исправление ошибки требует повторного развертывания всего приложения, что может привести к простою и усложнению процесса обновления.
3. Ограничения по технологиям: Монолитные приложения обычно разрабатываются на одном технологическом стеке, что снижает гибкость в выборе новых технологий для отдельных компонентов.
— Что такое микросервисная архитектура?
Микросервисная архитектура — это подход, при котором приложение строится как набор небольших, независимых сервисов, каждый из которых отвечает за определенную бизнес-логику. Эти сервисы слабо связаны друг с другом, взаимодействуют через четко определенные API и могут разрабатываться, развертываться и масштабироваться независимо.
🔹Преимущества микросервисной архитектуры
1. Гибкость в масштабировании: Каждый сервис можно масштабировать независимо в зависимости от его потребностей, что позволяет более эффективно использовать ресурсы.
2. Изоляция отказов: Если один сервис выходит из строя, это не обязательно влечет за собой сбой всего приложения, так как другие сервисы продолжают работать.
3. Технологическая гибкость: Каждый сервис может быть разработан с использованием наиболее подходящего технологического стека, что позволяет командам выбирать лучшие инструменты и языки программирования.
4. Непрерывное развертывание: Обновления и исправления могут применяться отдельно к каждому сервису, снижая риск сбоев и позволяя выпускать новые версии чаще.
🔹Недостатки микросервисной архитектуры
1. Усложнение системы: Разделение приложения на множество сервисов создает сложности в управлении межсервисной коммуникацией, обеспечении согласованности данных и мониторинге системы в целом.
2. Дополнительные операционные расходы: Управление множеством сервисов требует более сложной инфраструктуры и инструментов мониторинга.
3. Накладные расходы на производительность: Коммуникация между сервисами осуществляется через сеть, что может привести к дополнительной задержке из-за сериализации и десериализации данных.
🤓 Что такое git stash?
Git stash позволяет временно сохранить черновик ваших изменений, которые еще не были зафиксированы (committed), и вернуть рабочую директорию в чистое состояние. Это полезно, если вам нужно переключиться на другую задачу, но вы не хотите коммитить незавершенную работу.
— Как работает Git Stash?
Когда вы выполняете команду git stash, Git берет все незакоммиченные изменения из вашей рабочей директории и сохраняет их в специальном хранилище (stash) — по сути, это стек отложенных изменений. После этого все незакоммиченные изменения удаляются из рабочей копии, и она снова соответствует последнему коммиту (HEAD).
Сохраненные изменения остаются в отдельном месте, пока вы не будете готовы снова применить их. Это позволяет переключаться между ветками, получать обновления из удаленного репозитория, выполнять rebase и другие операции, не мешая текущей незавершенной работе.
— Рабочий процесс с Git Stash
🔹Сохранение изменений в stash
Перед тем как зафиксировать изменения в stash, сначала добавьте файлы в индекс, чтобы Git начал их отслеживать:
$ git add .
$ git add file.txt demo.txt
Затем создайте новый stash:
```bash
$ git stash
git stash -m "<имя>"
$ git stash list
<stash> — это идентификатор stash'а из списка git stash list.git stash pop
git stash apply
git stash apply <stash>
git stash pop --index <stash>
<stash> — идентификатор stash'а из git stash list. apply сохраняет stash, а pop удаляет его после применения.git stash branch <branch-name> <stash>
git stash drop <stash>
git stash clear
Docker Daemon (Демон Docker)
Демон Docker — это серверная составляющая Docker, которая работает в фоновом режиме для управления образами Docker, контейнерами, сетями и томами.
Он играет ключевую роль в архитектуре Docker, слушая запросы API от клиента Docker и выполняя запрашиваемые операции.
—Ниже приведены основные функции демона Docker:
1. Управление образами
🔹Управляет Docker-образами, которые используются как шаблоны для создания контейнеров.
🔹Загружает образы из реестра Docker (например, Docker Hub) и сохраняет их локально на хосте Docker.
🔹Управляет жизненным циклом и хранением этих образов.
2. Управление контейнерами
🔹Отвечает за запуск, остановку и управление контейнерами Docker.
🔹Создает новый контейнер из образа при выполнении команды docker run.
🔹Останавливает и удаляет контейнеры в ответ на команды docker stop и docker rm.
3. Сетевое управление
🔹Управляет сетями Docker, которые соединяют контейнеры друг с другом и с внешними системами.
🔹Поддерживает различные сетевые драйверы (например, bridge, host, overlay, macvlan) для обработки различных сетевых требований и сценариев.
4. Управление томами
🔹Управляет томами Docker для сохранения данных, генерируемых контейнерами.
🔹Позволяет подключать тома к контейнерам во время их работы, что позволяет сохранять и обмениваться данными между контейнерами.
5. API
🔹Предоставляет REST API для программного взаимодействия с Docker.
🔹Клиент Docker использует этот API для отправки команд (например, создание контейнеров или управление образами) демону.
— Как работает демон Docker
🔹Фоновый процесс: работает непрерывно в фоновом режиме на хосте Docker.
🔹Взаимодействие: прослушивает запросы API от клиента Docker через Unix-сокет или сетевой порт.
🔹Настройка: может быть настроен с помощью различных параметров, таких как драйверы хранения, сетевые драйверы и параметры логирования, для разных вариантов использования.
Демон Docker является основным компонентом архитектуры Docker, обеспечивая удобное управление контейнерами, образами и сетями, а также обеспечивая гибкость и масштабируемость для контейнеризованных приложений.
👉 DevOps Portal
— Лучшие практики использования томов Docker
🔹Используйте именованные тома для важных данных.
🔹Регулярно очищайте неиспользуемые тома, чтобы не занимать дисковое пространство.
🔹Будьте осторожны с привязанными томами, так как они дают контейнеру доступ к файловой системе хоста.
🔹Используйте плагины для томов для расширенных возможностей, таких как шифрование и снапшоты.
✅ Заключение
Docker Volumes — это мощный инструмент для управления данными в контейнерах. Их грамотное использование значительно упрощает развертывание, разработку и администрирование контейнеризированных приложений.
👉 DevOps Portal
💡 Совет дня по Linux 🐧
В Linux оператор конвейера (|) полезен, когда нужно направить вывод одной команды на вход другой для дальнейшей обработки:
$ cat data.txt | grep "No such file"
grep не даст результата.|&.$ cat data.txt |& grep "No such file"
grep смогла найти совпадение.|& в bash является сокращением для оператора перенаправления 2>&1 |:$ cmd-1 2>&1 | cmd-2
Что такое параметризованные пайплайны в Jenkins?
— Динамичные и переиспользуемые пайплайны
Параметризованные пайплайны в Jenkins позволяют передавать пользовательские входные данные при запуске билда, делая конвейеры более гибкими и универсальными. Это позволяет использовать один и тот же пайплайн для разных сценариев без необходимости значительных изменений в коде.
— Применение:
🔹Конфигурация сборок: Запуск сборок для разных окружений (dev, staging, production), веток или версий приложения.
🔹Тестирование: Выполнение тестов на разных браузерах, операционных системах и конфигурациях.
🔹Деплой: Развертывание приложения в различные среды с индивидуальными настройками.
🔹Кастомные workflow: Возможность задавать параметры вручную для специфических задач.
— Создание параметризованного пайплайна
1. Определение параметров: В Jenkins Pipeline (в декларативном или скриптовом синтаксисе) используется директива parameters для объявления доступных параметров:
pipeline {
parameters {
string(name: 'ENVIRONMENT', defaultValue: 'dev', description: 'Целевое окружение для деплоя (dev, staging, prod)')
choice(name: 'BUILD_TYPE', choices: ['Release', 'Debug'], description: 'Тип сборки')
}
}stages {
stage('Build') {
steps {
echo "Сборка для окружения: ${params.ENVIRONMENT}"
echo "Тип сборки: ${params.BUILD_TYPE}"
}
}
}
Как работает преобразование сетевых адресов (NAT)
Преобразование сетевых адресов (NAT) — это фундаментальная технология в современных сетях, которая позволяет устройствам в частной сети обмениваться данными с внешними сетями, такими как Интернет, используя один публичный IP-адрес. Эта возможность критически важна для экономии ограниченных ресурсов IPv4-адресов и повышения безопасности сети. Рассмотрим, как работает NAT на основе приведенной инфографики.
— Основы NAT
NAT работает, изменяя информацию о IP-адресах в пакетах, когда они проходят через маршрутизатор или брандмауэр. Конкретно, он преобразует частные IP-адреса в локальной сети в публичный IP-адрес для связи с внешними сетями.
— Компоненты и процесс
1. Частная сеть и публичный IP:
🔹Устройства в частной сети получают частные IP-адреса (например, 192.168.3.6, 192.168.3.7, 192.168.3.8).
🔹Маршрутизатор, выполняющий NAT, имеет частный IP-адрес (например, 192.168.3.0/24) на своем внутреннем интерфейсе и публичный IP-адрес (например, 200.100.10.1) на внешнем интерфейсе, предоставленный поставщиком Интернет-услуг (ISP).
2. Преобразование пакетов:
🔹Когда устройство (например, 192.168.3.6) хочет общаться с внешним сервером (например, 65.44.21.24) через Интернет, оно отправляет пакет с своим частным IP-адресом в качестве источника.
🔹Маршрутизатор с включенным NAT перехватывает этот пакет. Прежде чем отправить его в назначение, маршрутизатор заменяет частный IP-адрес (192.168.3.6:5733) на свой публичный IP-адрес (200.100.10.1:5733). Этот процесс позволяет пакету пройти через Интернет, поскольку он не маршрутизирует частные IP-адреса.
3. Поддержание сеансов:
🔹Маршрутизатор поддерживает таблицу NAT для отслеживания активных сеансов. Эта таблица содержит соответствия между внутренними частными IP-адресами и портами и внешними публичными IP-адресами и портами.
🔹Например, таблица NAT может отображать соответствие 192.168.3.6:5733 -> 200.100.10.1:5733, что позволяет маршрутизатору корректно перенаправлять ответы обратно на исходное устройство в частной сети.
4. Обратное преобразование пакетов:
🔹Когда внешний сервер (65.44.21.24) отвечает, он отправляет пакеты на публичный IP-адрес (200.100.10.1:5733).
🔹NAT-маршрутизатор перехватывает эти входящие пакеты, обращается к таблице NAT и преобразует адрес назначения обратно в частный IP-адрес (192.168.3.6:5733), прежде чем отправить его соответствующему внутреннему устройству.
— Преимущества NAT
🔹Сохранение IP-адресов: NAT позволяет нескольким устройствам в локальной сети использовать один публичный IP-адрес, что значительно уменьшает количество требуемых IP-адресов.
🔹Безопасность: NAT скрывает внутренние IP-адреса сети, обеспечивая дополнительный уровень безопасности, предотвращая прямой доступ к внутренним устройствам из внешней сети.
— Заключение
NAT — это важная технология, которая помогает эффективно использовать IP-адреса и повышать безопасность сети. Преобразуя частные IP-адреса в публичные и управляя этими соответствиями, NAT обеспечивает бесперебойную связь между частными сетями и Интернетом. Эта функциональность незаменима в условиях ограниченных ресурсов IP-адресов и повышенных требований к безопасности.
👉 DevOps Portal
💡 Быстрый совет по Linux 🐧
Когда вы запускаете программу в терминале или по SSH, она завершится сразу после закрытия сессии терминала (когда вы выйдете из него) или при разрыве соединения.
Чтобы избежать этого и сохранить выполнение программы и всех её процессов, используйте команду nohup (сокращение от no hangup – «без зависания»). Она игнорирует все сигналы разрыва соединения, позволяя процессу продолжать работу даже при закрытии терминала.
Например, чтобы сжать большой объем данных с помощью команды tar и гарантировать, что процесс не прервётся при случайном закрытии терминального окна, выполните команду:
$ nohup tar -cf archive.tar file1 file2
nohup создаёт файл nohup.out, в который записывает вывод команды:$ cat nohup.out
tmux, disown или screen.
💡 Совет по Linux
Получите контекст вашего поиска с помощью grep, используя параметр -C:
$ grep -C3 filename
Репозиторий с кучей полезных материалов и информации, связанных с DevOps
Содержит ресурсы по таким темам, как Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure и GC
👉 DevOps Portal
Это репозиторий примеров из книги "Ansible for DevOps" Джеффа Гирлинга.
Он демонстрирует использование Ansible для автоматизации серверов и управления конфигурациями, с реальными примерами и плейбуками
👉 https://github.com/geerlingguy/ansible-for-devops
👉 DevOps Portal
Awesome-limits
Репозиторий содержит полезную подборку ресурсов, связанных с различными ограничениями в вычислениях: лимиты файловых дескрипторов, памяти, процессов, сети и других аспектов операционных систем и облачных сервисов.
Некоторые полезные материалы из репозитория:
🔹Ограничения в Linux (например, ulimit, sysctl).
🔹Лимиты облачных сервисов (AWS, Google Cloud, Azure).
🔹Ограничения баз данных (PostgreSQL, MySQL).
🔹Сетевые лимиты (максимальное количество подключений, ограничение портов).
https://github.com/lorin/awesome-limits
👉 DevOps Portal
Лучшие практики Terraform, которые вам нужно знать
1. Структура кода, качество кода и организация
Никогда не храните всю конфигурацию в одном main.tf файле. Разделяйте файлы по папкам в зависимости от ресурсов, окружений, регионов и проектов. Если конфигурация простая, используйте команду terraform workspaces для управления несколькими окружениями. Это также ускоряет выполнение Terraform.
Стандартизируйте соглашения по именованию. Используйте входные и выходные переменные — не хардкодьте значения, которые можно передавать в переменные или получать из источников данных.
2. Поддерживаемость и повторное использование
Создавайте переиспользуемые модули для инфраструктурных компонентов (ресурсные и инфраструктурные модули). Храните модули в отдельном репозитории или в специальной директории (modules/). Думайте о них как о шаблонах для ваших ресурсов. Старайтесь, чтобы ресурсные модули были максимально простыми.
3. Управление состоянием
Всегда используйте удаленное хранилище для файлов состояния. Варианты хранения:
🔹S3 с блокировкой DynamoDB (AWS)
🔹Google Cloud Storage
🔹Azure Storage
🔹Terraform Cloud
🔹MinIO (самостоятельный хостинг)
🔹GitLab (да, GitLab поддерживает хранение состояния Terraform)
4. Практики безопасности
🔹Избегайте хардкодинга секретов. Используйте переменные окружения или инструменты управления секретами, такие как Hashicorp Vault, AWS Secrets Manager, Google Secret Manager.
🔹Шифруйте файл состояния в удаленном хранилище.
🔹Управляйте доступом к файлу состояния через IAM-политики.
🔹Избегайте использования учетной записи администратора. Определите IAM-роль или сервисный аккаунт для выполнения Terraform.
5. Продвинутый подход: применяйте принцип DRY с Terragrunt
Terragrunt — это обертка для Terraform и инструмент для оркестрации инфраструктуры. Он нативно поддерживает инфраструктурные модули и управляет зависимостями, что позволяет уменьшить дублирование кода. Именно поэтому ключевой принцип — DRY (Don't Repeat Yourself — Не повторяйся).
👉 DevOps Portal
Автоматизируем выпуск валидных SSL-сертификатов в локальном Kubernetes
В данном туториале максимально просто расскажу и покажу на практике как настроить автоматический выпуск сертификатов в локальном kubernetes так, что бы ваша локальная машина доверяла им. Я постарался написать его так, чтобы даже новичкам можно было настроить свой куб просто следуя данной инструкции
— Выбор между монолитной и микросервисной архитектурой
Решение о выборе архитектурного подхода должно основываться на ряде факторов, таких как сложность приложения, требования к масштабируемости, размер команды и цели организации. Вот несколько общих рекомендаций:
1. Монолитная архитектура: Подходит для небольших приложений с ограниченными требованиями, а также для проектов, не предполагающих значительного роста или необходимости масштабировать отдельные компоненты.
2. Микросервисная архитектура: Подходит для более сложных и масштабных приложений, где важна возможность масштабирования, изоляция отказов и технологическая гибкость. Особенно полезна для организаций с несколькими кросс-функциональными командами, работающими над разными частями приложения.
— Заключение
Выбор между монолитной и микросервисной архитектурой зависит от конкретных требований, ограничений и целей вашего приложения и организации. Монолитные приложения проще в разработке и развертывании, тогда как микросервисы обеспечивают масштабируемость, отказоустойчивость и технологическую гибкость. Важно тщательно оценить потребности вашего проекта и взвесить все «за» и «против», прежде чем принимать окончательное решение.
👉 DevOps Portal
💡 Совет по Linux
Получайте уведомления, когда ваши команды в терминале завершаются!
$ sudo apt update; notify-send "Обновление завершено" "Получение обновлений завершено"
apt update на любую команду, выполнение которой займет некоторое время. Не забудьте сначала установить inotify-tools:$ sudo apt install inotify-tools
💡 Быстрый совет по Linux 🐧
Команда diff — полезный инструмент для поиска различий между файлами в терминале Linux. Однако, icdiff предлагает еще более удобное сравнение, выводя файлы бок о бок с цветным отображением изменений.
$ icdiff config-1 config-2
Быстрый совет по Linux 🐧
Вы можете использовать опцию -exec команды find, чтобы вызвать внешнюю программу для выполнения определённого действия над найденными файлами, соответствующими заданным критериям. Например, удаление файлов, вывод прав доступа и т. д.
$ find ~/ -type f -exec ls -lah {} \;-exec:exec ls — указывает find выполнить команду ls для каждого найденного файла.-lah — отображает все файлы (включая скрытые), их права доступа и другие метаданные (например, размер) в удобочитаемом формате.{} — это специальный placeholder, заменяемый именем каждого найденного файла. Он всегда должен быть последним в списке параметров.; — указывает конец списка параметров. Его необходимо экранировать (\;), иначе shell интерпретирует его неправильно.; можно использовать +, что позволяет передавать сразу несколько файлов в одну команду. Между + и {} должен быть пробел.-exec. Например, следующая команда считает количество слов в текстовых файлах и их занимаемое место на диске:$ find . -name "*.txt" -exec wc {} \; -exec du -sh {} \;
👩💻 Docker Volumes: Полное руководство
Контейнеры Docker изначально задумывались как эфемерные, то есть их файловая система не сохраняется после остановки или удаления контейнера. Docker Volumes (тома) обеспечивают механизм хранения и обмена данными, который выходит за пределы жизненного цикла контейнера, предотвращая потерю данных. Это особенно важно для приложений, которым требуется постоянное хранилище, таких как базы данных, CMS или stateful-сервисы.
— Типы томов Docker
Существует три основных типа томов в Docker:
🔹Именованные тома (Named Volumes)
Это наиболее распространенный и удобный тип. Они управляются самим Docker и хранятся в файловой системе хоста в специальном каталоге (/var/lib/docker/volumes/ на Linux). Именованные тома подходят для хранения данных, требующих сохранности (например, базы данных) и легко поддаются резервному копированию или миграции.
🔹Анонимные тома (Anonymous Volumes)
Анонимные тома, как и именованные, управляются Docker, но не имеют явного имени. Они используются для временных данных, которые не нужно сохранять между пересозданиями или перезапусками контейнера. Их сложнее отслеживать, и они автоматически удаляются, когда контейнер, их использующий, уничтожается.
🔹Привязанные тома (Bind Mounts)
В отличие от обычных томов, привязанные тома позволяют монтировать конкретный каталог или файл с хостовой системы в контейнер. Этот метод предоставляет больше контроля над местоположением и правами доступа к данным. Изменения, внесенные в файлы на хосте, сразу отображаются в контейнере и наоборот. Bind mounts удобны для совместного использования конфигурационных файлов или исходного кода в процессе разработки.
— Создание и монтирование именованных томов
Создать именованный том можно командой:
docker volume create jenkins_home
docker run -d --name jenkins -p 8080:8080 -v jenkins_home:/var/data jenkins/jenkins
jenkins_home монтируется в контейнер по пути /var/data.:ro:docker run -d --name jenkins -p 8080:8080 -v jenkins_home:/var/data:ro jenkins/jenkins
-v, но без указания источника:docker run -d -v /data nginx
-v:docker run -d -p 80:80 -v $(pwd):/data nginx
--mount:docker run -d -p 80:80 --mount type=bind,source=$(pwd),target=/data nginx
/data внутри контейнера, появятся в текущем каталоге на хосте.docker volume ls
docker volume inspect jenkins_home
docker volume rm jenkins_home
docker volume prune
💻 Основные компоненты Kubernetes
Управление современными распределенными приложениями — это сложная задача. Обеспечение надежности, масштабируемости и отказоустойчивости систем требует использования сложных инструментов оркестрации.
И здесь на помощь приходит Kubernetes.
Kubernetes (K8s) упрощает развертывание, масштабирование и управление контейнеризованными приложениями, становясь основой современной практики DevOps.
В своей основе Kubernetes строится на нескольких ключевых компонентах, каждый из которых выполняет свою роль.
Понимание этих компонентов даст вам крепкую базу знаний — давайте погрузимся 😱
🔹Node: Машины (физические или виртуальные), на которых работают контейнеризованные приложения. Узлы (Nodes) хостят рабочую нагрузку, которая состоит из Pods.
🔹Pod: Самая мелкая единица развертывания в Kubernetes, содержащая один или несколько контейнеров, которые делят хранилище, сеть и ресурсы.
🔹Control plane (Управляющая плоскость): "Мозг" кластера, управляющий состоянием системы и контролирующий работу узлов и Pods.
Состав управляющей плоскости:
• API сервер: обрабатывает запросы на управление кластером
• Scheduler (Планировщик): назначает Pods на узлы
• Controller manager (Менеджер контроллеров): поддерживает желаемое состояние системы
• etcd: хранит конфигурацию кластера и его состояние в виде распределенного хранилища ключ-значение
🔹Service (Сервис): Предоставляет стабильные конечные точки (IP/DNS), чтобы обеспечить связь между Pods или открыть приложения для внешних пользователей.
🔹Ingress: Управляет внешним трафиком HTTP/HTTPS, направляя его к соответствующим сервисам внутри кластера.
🔹Namespace: Виртуальный кластер в рамках Kubernetes, позволяющий изолировать ресурсы и поддерживать многопользовательскую среду.
🔹Persistent Volume (Постоянный том): Отделяет хранилище от Pods, обеспечивая сохранность данных при перезапуске или удалении контейнеров.
Все эти компоненты работают вместе, создавая мощную систему для автоматизации оркестрации приложений. Kubernetes стал основой для обеспечения надежности и масштабируемости в современных программных системах.
Однако это не решение для каждого приложения. Есть крутой кривой обучения и высокая сложность. В некоторых случаях более простые или легковесные решения, такие как Docker Swarm или PaaS-платформы, могут быть более подходящими
👉 DevOps Portal
💡 Быстрый совет по Linux 🐧
Многие либо не знают об этом, либо редко используют.
Нажатие Ctrl+U в терминале Linux удаляет все от позиции курсора до начала строки.
Аналогично, Ctrl+K удаляет все от позиции курсора до конца строки.
Это особенно полезно, если вы неправильно ввели пароль. Вместо того чтобы долго удерживать клавишу backspace, просто нажмите Ctrl+U, чтобы очистить ввод и ввести пароль заново.
Эти сочетания клавиш имеют множество других практических применений
👉 DevOps Portal
💡Совет по Bash-скриптам
Вы можете использовать ловушку DEBUG, чтобы шаг за шагом проходить через bash-скрипт, давая вам возможность проверять каждую строку перед её выполнением — это идеально для отладки!
— Вот как это работает:
Команда trap с параметром DEBUG срабатывает сразу перед выполнением каждой строки, приостанавливая выполнение, чтобы вы могли решить, хотите ли продолжить. Это как интерактивное «пошаговое выполнение» вашего bash-скрипта.
В отличие от sh -x, который выводит каждую строку без остановки, этот метод позволяет вам контролировать выполнение каждой команды перед её запуском.
Ловушка DEBUG не является настоящим сигналом, а представляет собой специальную функцию (псевдосигнал), которая срабатывает перед каждой строкой скрипта, что удобно для понимания поведения скрипта построчно.
Вы также можете изучить похожие псевдосигналы, такие как EXIT, который выполняет команды перед завершением скрипта; RETURN, который срабатывает при возврате из функции или после того, как скрипт был загружен (с помощью source или .); и ERR, который обрабатывает команды, возвращающие ненулевой код завершения при активированном set -e.
👉 DevOps Portal
🖥 Основные компоненты Docker: объяснение
Docker решает проблему «у меня на машине работает» 😱
Разработка и развертывание приложений сопряжены с рядом сложностей. Несогласованность программного обеспечения в разных средах приводит к серьезным проблемам: сбоям при развертывании, усложнению разработки и тестирования и другим неприятностям.
Docker решает проблему «у меня на машине работает» и упрощает развертывание приложений, инкапсулируя их вместе с зависимостями в стандартизированные, масштабируемые и изолированные контейнеры (контейнеризация).
В основе Docker лежит несколько ключевых компонентов.
Разбираясь в них, вы получите прочную базу понимания. Давайте разберем их!
🔸Образы (Images)
Образы — это неизменяемые шаблоны, используемые для создания контейнеров. Они создаются с помощью инструкций в Dockerfile или загружаются из Docker-реестра, такого как Docker Hub.
🔸Контейнер (Container)
Контейнер — это запущенный экземпляр образа. Это легковесный, автономный пакет, содержащий все необходимое для работы приложения.
🔸Dockerfile
Файл, содержащий последовательность команд для создания образа Docker.
🔸Docker Engine
Docker Engine отвечает за запуск и управление контейнерами. Он состоит из демона Docker и CLI-инструмента, взаимодействующего с ним через REST API.
🔸Docker Daemon
Фоновый сервис, управляющий объектами Docker. Он обрабатывает API-запросы и управляет образами, контейнерами, сетями и томами хранения.
🔸Docker Registry
Репозитории для хранения и распространения образов Docker. Реестры могут быть публичными или частными. По умолчанию Docker использует публичный реестр Docker Hub.
🔸Сеть Docker (Docker Network)
Контейнеры работают в сетях, что позволяет им взаимодействовать друг с другом и с внешним миром. Сеть предоставляет коммуникационный шлюз между контейнерами на одном или разных хостах.
🔸Тома (Volumes)
Тома позволяют сохранять данные вне контейнера и делиться ими между контейнерными инстансами, даже после удаления контейнера. Они обеспечивают независимость данных от жизненного цикла контейнера.
Все эти компоненты взаимосвязаны, создавая удобную систему для автоматизации развертывания, масштабирования и управления приложениями. Благодаря этому Docker стал мощным и важным инструментом в современной разработке программного обеспечения.
👉 DevOps Portal
Структура манифеста развертывания Kubernetes: объяснение
В YAML-файле развертывания Kubernetes определяется, как приложение должно быть развернуто и управляться в кластере Kubernetes.
Ниже приведена структура YAML с пояснениями.
— Объяснение ключевых разделов
🔸apiVersion & kind: Определяет, что этот ресурс является развертыванием и использует API Kubernetes apps/v1.
🔸metadata: Содержит информацию, такую как имя и метки для организации приложения.
🔸spec.replicas: Определяет желаемое количество работающих экземпляров (Pod'ов).
🔸spec.selector.matchLabels: Гарантирует, что развертывание управляет только Pod'ами с соответствующими метками.
🔸spec.template:
- Определяет шаблон Pod'а (его metadata и spec).
- Раздел containers описывает контейнер, включая образ, порты и ресурсы.
- Можно также задать переменные среды, монтирование томов и лимиты ресурсов.
🔸spec.strategy: Управляет стратегией обновления развертывания (RollingUpdate или Recreate).
🔸volumes: Позволяет определить постоянное хранилище, такое как ConfigMaps, Secrets или Persistent Volumes.
— Дополнительные параметры
🔸Проверки работоспособности: Liveness & Readiness Probes
🔸Управление размещением: Affinity & Node Selectors
🔸Предварительная обработка: Init Containers
👉 DevOps Portal
💡 Быстрый совет по Docker
Хотите узнать, сколько дискового пространства занимают образы, контейнеры, локальные тома или кэш сборки?
Используйте команду:
docker system df
Строим контейнерные образы как профи 😎
Множество ресурсов по созданию образов:
🔹5 учебных пособий по композиции образов, выбору базового образа, многоступенчатым сборкам и образам без дистрибутива.
🔹12 практических задач для создания и отладки образов.
Посмотреть здесь: https://labs.iximiuz.com/skill-paths/build-container-images
👉 DevOps Portal