13139
Присоединяйтесь к нашему каналу и погрузитесь в мир DevOps Сотрудничество, реклама: @devmangx Менеджер: @Spiral_Yuri РКН: https://clck.ru/3P8kFH
⚙️ Смотрите какую штуку нашёл - https://sadservers.com/ разные варианты проблем, которые нужно решить на сервере Linux. При этом, серверы для тренировки можно получить прямо тут же, на сайте.
Cистема отслеживает выполняемые команды и по ходу дает подсказки — очень удобно и дружелюбно
Архитектуру ресурса ребята показали на Github: https://github.com/fduran/sadservers
👉 DevOps Portal
Этот репозиторий — сборник вопросов и ответов для подготовки к DevOps-собеседованиям.
Там есть темы про Docker, Kubernetes, CI/CD, облака, мониторинг, безопасность, Linux и Git.
Отлично подойдёт для подготовки к интервью и освежения знаний 👍
Бросайте в закладки: https://github.com/rohitg00/devops-interview-questions
👉 DevOps Portal
Понимание системных логов Linux
Системные логи, которые часто можно найти в директории /var/log на системах Linux, являются важным инструментом для мониторинга и устранения проблем в системе. Вот краткие заметки о некоторых распространённых системных логах:
— syslog: Лог общего назначения, который содержит сообщения от различных системных служб и приложений. Это основной файл журнала, в который поступают сообщения из многих других логов.
— auth.log: Записывает сообщения, связанные с аутентификацией, включая успешные и неудачные попытки входа, изменения паролей и события аутентификации пользователей.
— kern.log: Записывает сообщения, относящиеся к ядру системы, такие как ошибки оборудования, загрузка модулей ядра и другие активности ядра.
— messages: Универсальный лог-файл, который записывает различные системные сообщения, включая старты и завершения работы системы, а также другие события, связанные с системой.
— dmesg: Отображает сообщения из кольцевого буфера ядра, предоставляя реальный временной обзор событий, связанных с ядром, и обнаружением оборудования во время загрузки системы.
— cron: Записывает сообщения, связанные с заданиями cron и запланированными задачами, включая время их выполнения и ошибки, возникшие при их выполнении.
— secure: Записывает сообщения, связанные с безопасностью, включая попытки аутентификации, повышение привилегий и другие события безопасности.
— apache/access.log и apache/error.log: Логи, специфичные для веб-сервера Apache. access.log записывает логи HTTP-доступа, а error.log фиксирует ошибки и предупреждения сервера Apache.
— nginx/access.log и nginx/error.log: Подобные логам Apache, эти логи специфичны для веб-сервера Nginx и записывают события доступа и ошибки.
— mysql/error.log: Записывает ошибки и предупреждения, возникшие у сервера базы данных MySQL, включая ошибки при старте, сбои запросов и сбои баз данных.
Эти логи предоставляют ценную информацию о производительности системы, событиях безопасности и помогают при устранении проблем.
Регулярный мониторинг и анализ этих логов помогают поддерживать здоровье системы и выявлять потенциальные проблемы до того, как они перерастут в серьёзные.
👉 DevOps Portal
Краткий гайд по Linux Logical Volume Manager
LVM меняет способ управления дисковым пространством в Linux, позволяя объединять несколько физических дисков в единый гибкий пул хранения.
Представьте это как большой контейнер, в который можно добавлять или убирать элементы (в данном случае, хранилище) по мере необходимости.
С LVM вы не ограничены жесткой структурой традиционных разделов диска. Вместо этого вы можете динамически изменять размер хранилища, создавать резервные копии с помощью снимков (snapshots) и даже настраивать конфигурации для повышения производительности и надежности.
Основные преимущества использования LVM:
🔹Гибкое хранилище – легко изменяйте размер и управляйте дисковым пространством в соответствии с вашими потребностями.
🔹Снимки для безопасных резервных копий – создавайте моментальные снимки для быстрого резервного копирования без прерывания работы системы.
🔹Упрощенное управление дисками – используйте несколько дисков как единое целое, оптимизируя пространство и организацию хранения.
👉 DevOps Portal
Репозиторий с пошаговым руководство о том, как стать инженером DevOps в 2025, со ссылками на соответствующие учебные ресурсы
👉 https://github.com/milanm/DevOps-Roadmap
👉 DevOps Portal
— Команды Docker для сетевого взаимодействия
🔹Подключение контейнера к сети
Для подключения контейнера к сети используйте команду docker network connect:
docker network connect mynet container1
docker network create:docker network create --driver bridge mynet
docker network disconnect:docker network disconnect mynet container1
docker network inspect:docker network inspect mynet
docker network ls:docker network ls
docker network rm:docker network rm mynet
-p при запуске контейнера:docker run -p 80:5000 myapp
💡 Быстрый совет по 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
💡 Быстрый совет по Linux
Заменяйте часть команды с помощью fc.
Например, если вы опечатались и вместо apt ввели atp, можно заменить его в команде так:
fc -s atp=apt
💡 Быстрый совет по Ansible
Долгий запуск команды приводит к тайм-ауту?
Используйте настройку ansible_command_timeout
Она задает максимальное время (в секундах), в течение которого Ansible будет ждать завершения команды
👉 DevOps Portal
Быстрый совет для Linux
Используйте этот онлайн-проект, чтобы проверить, для каких дистрибутивов и версий доступен тот или иной пакет:
👉 https://repology.org
Настоящее спасение ☺️
👉 DevOps Portal
Когда вы смотрите на использование ОЗУ на сервере с Linux,
❌ люди часто обращают внимание на свободную память
✅ Но вместо этого им стоит сосредоточиться на доступной памяти
Позвольте объяснить, почему.
Свободная память — это объем ОЗУ, который в данный момент не используется вообще. Для серверов это пустая трата ресурсов.
Доступная память — это количество ОЗУ, которое можно выделить новым или существующим процессам без использования свопа. Считайте это вашей «реальной свободной памятью».
Разница в том, что свободная память не используется и просто лежит без дела. Потери ресурсов.
С другой стороны, доступная память — это «используемая память», которую можно освободить без потери производительности, связанной с использованием свопа. Она также включает в себя кэш и буферы.
На сервере с Linux, который работает уже некоторое время, если в нем много свободной памяти, это значит, что он не использует ресурсы эффективно.
Если вы задумываетесь о том, нужно ли вашему серверу обновление ОЗУ, вы должны смотреть на «доступную память», а не только на «свободную память» при принятии решения.
👉 DevOps Portal
Введение в написание скриптов на Bash
Скрипты на Bash — это мощный инструмент, который позволяет автоматизировать различные задачи на системах на базе Unix, таких как Linux и macOS. Они представляют собой последовательность команд, записанных в файл, который может быть выполнен оболочкой Bash. Вместо того чтобы вручную вводить и запускать команды одну за другой в терминале, создание Bash-скрипта позволяет сохранить эти команды в файл и выполнить их сразу, что делает процесс более эффективным и удобным.
В этом посте мы рассмотрим основы создания и запуска первого скрипта на Bash.
— Преимущества скриптов на Bash
Существует несколько преимуществ при создании скриптов на Bash:
🔹Автоматизация: Скрипты могут автоматизировать повторяющиеся задачи, экономя ваше время и силы.
🔹Согласованность: Выполняя одну и ту же последовательность команд, вы обеспечиваете выполнение задач одинаково каждый раз, уменьшая вероятность ошибок.
🔹Портабельность: Скрипты Bash можно легко передавать и запускать на разных системах на базе Unix, что делает их высоко переносимыми.
— Создание и запуск первого Bash-скрипта
Для создания нового Bash-скрипта откройте текстовый редактор и создайте новый файл с расширением .sh, например, my_script.sh. Затем добавьте следующую строку кода:
#!/bin/bash
echo "Hello, World!"
cd. Например, если скрипт сохранён в домашней директории, используйте команду cd ~.chmod +x my_script.sh
./my_script.sh
bash my_script.sh
#!/bin/bash, называется "shebang" или "hashbang". Она указывает операционной системе, какой интерпретатор следует использовать для выполнения скрипта. В данном случае, #!/bin/bash означает, что для выполнения скрипта следует использовать оболочку Bash.#!/bin/zsh
/path/to/my_script.sh), гораздо удобнее добавить скрипт в переменную окружения PATH, чтобы запускать его из любой директории. Вот как это можно сделать:.bashrc или .bash_profile) в текстовом редакторе./path/to/scripts на путь к директории, где вы хотите хранить свои скрипты:export PATH="$PATH:/path/to/scripts"
source ~/.bashrc (или source ~/.bash_profile), чтобы применить изменения.PATH системы для удобного запуска. С этими основами под рукой вы можете начать изучать более сложные концепции написания скриптов на Bash и создавать мощные автоматизационные скрипты для оптимизации рабочего процесса.
Сетевое взаимодействие в Docker
Сетевое взаимодействие Docker позволяет контейнерам общаться друг с другом и с внешним миром. Docker поддерживает различные типы сетей, каждый из которых предназначен для определённых случаев. В этом посте мы рассмотрим драйверы сетей, предоставляемые Docker, и приведём практические примеры.
— Драйверы сетей Docker
Docker упрощает коммуникацию между контейнерами, создавая сеть по умолчанию — bridge (мост), что позволяет разработчикам сосредоточиться на создании и запуске контейнеров, не беспокоясь о сетевом взаимодействии. Хотя эта сеть по умолчанию подходит для большинства случаев, Docker также предлагает другие варианты.
Docker позволяет создавать три различных типа сетевых драйверов «из коробки»: bridge, host и none. Однако эти драйверы могут не подходить для всех случаев, поэтому мы также обсудим пользовательские сети, такие как overlay и macvlan. Давайте рассмотрим каждый из них более подробно.
🔹Драйвер Bridge
Драйвер по умолчанию для сетей Docker — это драйвер bridge. Он создаёт частную сеть внутри хоста. Каждый контейнер, подключённый к сети bridge, получает внутренний IP-адрес, что позволяет контейнерам на одной и той же bridge-сети обмениваться данными. Для внешнего доступа необходимо открывать порты.
Драйвер bridge создаёт интерфейс docker0 на хосте, который служит шлюзом между контейнерами и внешней сетью. Он управляет маршрутизацией между внутренними и внешними интерфейсами.
Этот драйвер подходит, когда контейнеры должны работать в изолированном режиме, но иметь возможность обмениваться данными между собой. Однако использовать драйвер bridge не рекомендуется для рабочих (продакшн) окружений, так как контейнеры общаются через IP-адреса, а не через автоматическое обнаружение сервисов, чтобы сопоставить IP-адрес с именем контейнера.
🔹Драйвер Host
Как следует из названия, драйвер host использует сетевую инфраструктуру хостовой машины, исключая сетевую изоляцию между контейнером и хостовой машиной, на которой работает Docker. Например, если контейнер использует порт 80 и применяется хостовая сеть, то приложение контейнера будет доступно на порту 80 IP-адреса хоста. Этот драйвер используется, если необходимо полагаться на сетевую инфраструктуру хоста, а не на Docker.
Однако драйвер host несовместим с Docker Desktop и требует использования хостовой машины на базе Linux.
Хостовые сети устраняют абстракцию контейнера, и их следует использовать с осторожностью, так как могут возникнуть конфликты портов между контейнерами и хостом.
🔹Драйвер None
Драйвер none предоставляет контейнеру доступ к сети только через интерфейс loopback. Это полностью изолирует контейнер от внешних сетей. Такой драйвер полезен для приложений, которые обмениваются данными только внутри себя, а также для высокозащищённых приложений, где критична максимальная изоляция или когда сетевой доступ вообще не требуется.
🔹Драйвер Overlay
Overlay-сети позволяют контейнерам на разных хостах Docker обмениваться данными в Docker Swarm. Это использует встроенное шифрование и распределённую компоненту для маршрутизации трафика между участвующими хостами.
Overlay-сети позволяют контейнерам на разных хостах внутри кластера Swarm общаться так, как если бы они находились в одной локальной сети. Несколько приложений могут использовать одну и ту же overlay-сеть, но оставаться изолированными друг от друга. Это полезно для крупных распределённых приложений.
🔹Драйвер Macvlan
Драйвер macvlan назначает каждому контейнеру уникальный MAC-адрес для виртуального сетевого интерфейса, что делает контейнеры видимыми как физические устройства в сети. Контейнеры получают уникальные IP-адреса во внешней сети.
Этот драйвер даёт контейнерам такую же сетевую видимость, как у физических хостов, но при этом сохраняется абстракция Docker. С этим драйвером могут возникать конфликты IP-адресов между контейнерами и хостами.
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