— Лучшие практики использования томов Docker
🔹Используйте именованные тома для важных данных.
🔹Регулярно очищайте неиспользуемые тома, чтобы не занимать дисковое пространство.
🔹Будьте осторожны с привязанными томами, так как они дают контейнеру доступ к файловой системе хоста.
🔹Используйте плагины для томов для расширенных возможностей, таких как шифрование и снапшоты.

✅ Заключение
Docker Volumes — это мощный инструмент для управления данными в контейнерах. Их грамотное использование значительно упрощает развертывание, разработку и администрирование контейнеризированных приложений.

👉 DevOps Portal

Быстрый совет по 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 {} \;

👉 DevOps Portal

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

💡 Быстрый совет по Linux 🐧

Команда diff — полезный инструмент для поиска различий между файлами в терминале Linux. Однако, icdiff предлагает еще более удобное сравнение, выводя файлы бок о бок с цветным отображением изменений.

$ icdiff config-1 config-2

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

👉 DevOps Portal

🤓 Что такое 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

Эта команда сохранит ваши изменения и вернет рабочую директорию в состояние последнего коммита.

🔹Присвоение имени stash
Чтобы дать stash понятное название, используйте параметр -m:

git stash -m "<имя>"

Это поможет вам легче идентифицировать нужные сохраненные изменения позже.

🔹Просмотр списка stash'ей
Чтобы увидеть список всех сохраненных stash'ей, используйте:

$ git stash list

Для просмотра краткого описания stash'а выполните:
```bash
git stash show
Где <stash> — это идентификатор stash'а из списка git stash list.

🔹Применение stash'а
Когда вы готовы вернуть сохраненные изменения, используйте команду git stash pop:

git stash pop

Эта команда применяет изменения и удаляет stash из списка. Если вы хотите сохранить stash после применения, используйте:

git stash apply

🔹Применение конкретного stash'а
Чтобы применить stash, кроме последнего, используйте:

git stash apply <stash>

Или:

git stash pop --index <stash>

Где <stash> — идентификатор stash'а из git stash list. apply сохраняет stash, а pop удаляет его после применения.

🔹Создание новой ветки с stash'ем
Вы можете создать новую ветку и применить к ней изменения из stash'а:

git stash branch <branch-name> <stash>

Эта команда создаст новую ветку с изменениями из stash'а, привязанными к коммиту, в котором stash был создан.

🔹Удаление stash'ей
Когда stash больше не нужен, удалите его командой:

git stash drop <stash>

Это удаляет один stash. Чтобы удалить все stash'и, используйте:

git stash clear

После очистки stash'и невозможно будет восстановить.

🔹Дополнительные возможности
Git stash поддерживает множество дополнительных опций, включая возможность отправки stash'ей в удаленный репозиторий. Подробнее читайте в официальной документации.

— Когда использовать Git Stash?

Git stash полезен в следующих ситуациях:
🔹Переключение на другую ветку для получения обновлений
🔹Временное сохранение работы для исправления критической ошибки (hotfix)
🔹Разрешение конфликтов при выполнении git rebase
🔹Пауза в работе для слияния другой ветки в вашу

С помощью stash можно легко менять контексты работы без необходимости делать временные коммиты.

— Заключение
Git stash позволяет откладывать локальные изменения без коммитов, помогая гибко управлять рабочим процессом и переключаться между ветками. Это делает его важным инструментом для эффективной работы с Git.

👉 DevOps Portal

Микросервисы vs Монолитная архитектура

В разработке программного обеспечения выбранный архитектурный подход может существенно повлиять на масштабируемость, удобство сопровождения и общую производительность приложения. Два основных архитектурных шаблона — монолитная архитектура и микросервисы — широко используются в современной разработке.

Сегодня мы рассмотрим ключевые различия между ними, их преимущества и недостатки, а также дадим рекомендации по выбору подходящего подхода для конкретного случая.

— Что такое монолитная архитектура?

Монолитная архитектура — это традиционный подход, при котором все компоненты приложения, такие как пользовательский интерфейс, бизнес-логика и уровень доступа к данным, объединены в единую, неделимую систему. Эти компоненты тесно связаны между собой и развертываются как единое целое. Этот стиль архитектуры используется десятилетиями и остается актуальным для определенных типов приложений.

🔹Преимущества монолитной архитектуры
1. Простое развертывание: Монолитные приложения развертываются как единое целое, что делает процесс развертывания относительно простым.

2. Упрощенная разработка и тестирование: Поскольку все компоненты находятся в одном кодовом репозитории, разработчики могут легче понимать логику приложения, что упрощает разработку и тестирование.

3. Эффективное взаимодействие компонентов: В монолитном приложении компоненты взаимодействуют напрямую, так как работают в одном адресном пространстве памяти, что минимизирует накладные расходы на коммуникацию.

🔹Недостатки монолитной архитектуры
1. Проблемы с масштабируемостью: По мере роста и усложнения приложения становится трудно масштабировать отдельные компоненты независимо. В большинстве случаев приходится масштабировать всю систему, что может быть неэффективно и дорого.

2. Сложности при непрерывном развертывании: Любое обновление или исправление ошибки требует повторного развертывания всего приложения, что может привести к простою и усложнению процесса обновления.

3. Ограничения по технологиям: Монолитные приложения обычно разрабатываются на одном технологическом стеке, что снижает гибкость в выборе новых технологий для отдельных компонентов.

— Что такое микросервисная архитектура?
Микросервисная архитектура — это подход, при котором приложение строится как набор небольших, независимых сервисов, каждый из которых отвечает за определенную бизнес-логику. Эти сервисы слабо связаны друг с другом, взаимодействуют через четко определенные API и могут разрабатываться, развертываться и масштабироваться независимо.

🔹Преимущества микросервисной архитектуры
1. Гибкость в масштабировании: Каждый сервис можно масштабировать независимо в зависимости от его потребностей, что позволяет более эффективно использовать ресурсы.

2. Изоляция отказов: Если один сервис выходит из строя, это не обязательно влечет за собой сбой всего приложения, так как другие сервисы продолжают работать.

3. Технологическая гибкость: Каждый сервис может быть разработан с использованием наиболее подходящего технологического стека, что позволяет командам выбирать лучшие инструменты и языки программирования.

4. Непрерывное развертывание: Обновления и исправления могут применяться отдельно к каждому сервису, снижая риск сбоев и позволяя выпускать новые версии чаще.

🔹Недостатки микросервисной архитектуры
1. Усложнение системы: Разделение приложения на множество сервисов создает сложности в управлении межсервисной коммуникацией, обеспечении согласованности данных и мониторинге системы в целом.

2. Дополнительные операционные расходы: Управление множеством сервисов требует более сложной инфраструктуры и инструментов мониторинга.

3. Накладные расходы на производительность: Коммуникация между сервисами осуществляется через сеть, что может привести к дополнительной задержке из-за сериализации и десериализации данных.

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

1. Монолитная архитектура: Подходит для небольших приложений с ограниченными требованиями, а также для проектов, не предполагающих значительного роста или необходимости масштабировать отдельные компоненты.

2. Микросервисная архитектура: Подходит для более сложных и масштабных приложений, где важна возможность масштабирования, изоляция отказов и технологическая гибкость. Особенно полезна для организаций с несколькими кросс-функциональными командами, работающими над разными частями приложения.

— Заключение

Выбор между монолитной и микросервисной архитектурой зависит от конкретных требований, ограничений и целей вашего приложения и организации. Монолитные приложения проще в разработке и развертывании, тогда как микросервисы обеспечивают масштабируемость, отказоустойчивость и технологическую гибкость. Важно тщательно оценить потребности вашего проекта и взвесить все «за» и «против», прежде чем принимать окончательное решение.

👉 DevOps Portal

💡 Совет по Docker: Используйте аргументы в вашем Dockerfile для таких вещей, как тег базового образа.

Таким образом, вам не придется изменять Dockerfile при каждом обновлении базового образа.

$ docker build --build-arg BASE_IMAGE_TAG=20.04 -t my-image .

👉 DevOps Portal

Автоматизируем выпуск валидных SSL-сертификатов в локальном Kubernetes

В данном туториале максимально просто расскажу и покажу на практике как настроить автоматический выпуск сертификатов в локальном kubernetes так, что бы ваша локальная машина доверяла им. Я постарался написать его так, чтобы даже новичкам можно было настроить свой куб просто следуя данной инструкции

👉 Читать

👉 DevOps Portal

💡 Быстрый совет по Linux

При работе в редакторе nano нажмите

Alt+#

чтобы отобразить номера строк

👉 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

💡 Быстрый совет по Linux 🐧

Найдите недавно изменённые файлы за последние 5 минут:

find . -type f -mmin -5

Полезно, когда вы устраняете неполадки и хотите знать, какие файлы были недавно изменены

👉 DevOps Portal

Awesome-limits

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

Некоторые полезные материалы из репозитория:
🔹Ограничения в Linux (например, ulimit, sysctl).
🔹Лимиты облачных сервисов (AWS, Google Cloud, Azure).
🔹Ограничения баз данных (PostgreSQL, MySQL).
🔹Сетевые лимиты (максимальное количество подключений, ограничение портов).

https://github.com/lorin/awesome-limits

👉 DevOps Portal

💡 Быстрый совет по Linux

Проверить bash-скрипт на синтаксические ошибки можно командой:

bash -n scriptname

👉 DevOps Portal

Сетевое взаимодействие в 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-адресов между контейнерами и хостами.

— Команды Docker для сетевого взаимодействия

🔹Подключение контейнера к сети
Для подключения контейнера к сети используйте команду docker network connect:

docker network connect mynet container1

Это добавит контейнер container1 в сеть mynet.

🔹Создание сети
Для создания новой сети используйте команду docker network create:

docker network create --driver bridge mynet

Это создаст новую сеть bridge с именем mynet.

🔹Отключение контейнера от сети
Для того чтобы отключить контейнер от сети, используйте команду docker network disconnect:

docker network disconnect mynet container1

Это удалит контейнер container1 из сети mynet, и контейнер больше не сможет общаться с другими контейнерами в этой сети.

🔹Просмотр сети
Для просмотра настроек сети и подключённых контейнеров используйте команду docker network inspect:

docker network inspect mynet

Эта команда выводит низкоуровневые данные о сети и её пирах.

🔹Список доступных сетей
Для отображения всех сетей на хосте Docker используйте команду docker network ls:

docker network ls

Эта команда выведет список сетей, их идентификаторы, типы драйверов, IP-адреса и другие данные.

🔹Удаление сети
Для удаления сети, которая больше не используется, используйте команду docker network rm:

docker network rm mynet

Эта команда удалит сеть mynet с хоста. Контейнеры больше не смогут обмениваться данными по этой сети.

🔹Публичное сетевое взаимодействие
По умолчанию контейнеры не имеют доступа к публичной сети и изолированы от внешней сети. Чтобы открыть порты, используйте аргумент -p при запуске контейнера:

docker run -p 80:5000 myapp

Эта команда направит внутренний TCP-порт 5000 на внешний порт 80. Контейнер теперь будет доступен на порту 80 с внешней сети.

— Заключение

Сетевое взаимодействие Docker предоставляет различные драйверы сетей для изоляции или соединения контейнеров. Сетевые драйверы bridge просты в использовании, но драйверы overlay и macvlan предоставляют больше гибкости. Команды для работы с сетями позволяют создавать сети, подключать контейнеры и настраивать параметры. В целом, сетевые возможности Docker предоставляют мощные инструменты для проектирования распределённых приложений.

👉 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

В терминале должно появиться сообщение Hello, World!.

Вы также можете запустить скрипт, набрав:

bash my_script.sh

Для этого не нужно давать права на выполнение скрипта.

— Что такое Shebang

Первая строка в вашем Bash-скрипте, #!/bin/bash, называется "shebang" или "hashbang". Она указывает операционной системе, какой интерпретатор следует использовать для выполнения скрипта. В данном случае, #!/bin/bash означает, что для выполнения скрипта следует использовать оболочку Bash.

Например, если вы хотите запустить скрипт с использованием интерпретатора zsh, ваша shebang строка будет выглядеть так:

#!/bin/zsh

— Добавление скрипта в PATH

Хотя вы можете запускать скрипт, указывая полный путь к файлу (/path/to/my_script.sh), гораздо удобнее добавить скрипт в переменную окружения PATH, чтобы запускать его из любой директории. Вот как это можно сделать:

🔹Откройте файл конфигурации вашей оболочки (например, .bashrc или .bash_profile) в текстовом редакторе.
🔹Добавьте следующую строку в файл, заменив /path/to/scripts на путь к директории, где вы хотите хранить свои скрипты:

export PATH="$PATH:/path/to/scripts"

🔹Сохраните и закройте файл.
🔹Перезапустите терминал или выполните команду source ~/.bashrc (или source ~/.bash_profile), чтобы применить изменения.

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

✅ Заключение

В этом руководстве вы научились создавать и запускать первый Bash-скрипт, понимаете, что такое строка shebang, и добавили скрипт в PATH системы для удобного запуска. С этими основами под рукой вы можете начать изучать более сложные концепции написания скриптов на Bash и создавать мощные автоматизационные скрипты для оптимизации рабочего процесса.

Картинка в хорошем качестве (PDF) в комментариях

👉 DevOps Portal

Репозиторий с пошаговым руководство о том, как стать инженером DevOps в 2025, со ссылками на соответствующие учебные ресурсы

👉 https://github.com/milanm/DevOps-Roadmap

👉 DevOps Portal

Когда вы смотрите на использование ОЗУ на сервере с Linux,

❌ люди часто обращают внимание на свободную память

✅ Но вместо этого им стоит сосредоточиться на доступной памяти

Позвольте объяснить, почему.

Свободная память — это объем ОЗУ, который в данный момент не используется вообще. Для серверов это пустая трата ресурсов.

Доступная память — это количество ОЗУ, которое можно выделить новым или существующим процессам без использования свопа. Считайте это вашей «реальной свободной памятью».

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

С другой стороны, доступная память — это «используемая память», которую можно освободить без потери производительности, связанной с использованием свопа. Она также включает в себя кэш и буферы.

На сервере с Linux, который работает уже некоторое время, если в нем много свободной памяти, это значит, что он не использует ресурсы эффективно.

Если вы задумываетесь о том, нужно ли вашему серверу обновление ОЗУ, вы должны смотреть на «доступную память», а не только на «свободную память» при принятии решения.

👉 DevOps Portal