Как работает преобразование сетевых адресов (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 🐧

Многие либо не знают об этом, либо редко используют.

Нажатие Ctrl+U в терминале Linux удаляет все от позиции курсора до начала строки.

Аналогично, Ctrl+K удаляет все от позиции курсора до конца строки.

Это особенно полезно, если вы неправильно ввели пароль. Вместо того чтобы долго удерживать клавишу backspace, просто нажмите Ctrl+U, чтобы очистить ввод и ввести пароль заново.

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

👉 DevOps Portal

Что такое параметризованные пайплайны в 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: 'Тип сборки')
    }
}

2. Использование параметров: Обращение к значениям, введенным пользователем, через объект params в шагах пайплайна:

stages {
    stage('Build') {
        steps {
            echo "Сборка для окружения: ${params.ENVIRONMENT}"
            echo "Тип сборки: ${params.BUILD_TYPE}"
        }
    }
}

3. Запуск сборок: При старте параметризованного пайплайна в UI Jenkins появится форма для ввода параметров.

— Типы параметров в Jenkins:
🔹String: Текстовый ввод.
🔹Choice: Выпадающий список значений.
🔹Boolean: Флаг (true/false).
🔹File: Загрузка файла.
🔹Password: Скрытый ввод для конфиденциальных данных.
🔹И другие. (Полный список доступен в документации Jenkins.)

— Преимущества параметризованных пайплайнов:
🔹Гибкость: Управление процессами без изменения кода пайплайна.
🔹Переиспользуемость: Один пайплайн можно применять для разных задач.
🔹Удобство: Позволяет даже нетехническим пользователям запускать билды с нужными параметрами.
🔹Оптимизация CI/CD: Упрощает процессы непрерывной интеграции и доставки (CI/CD).

— Дополнительные замечания:
🔹Можно задавать параметры по умолчанию.
🔹В истории билдов отображаются введенные параметры для каждого запуска.
🔹Для управления параметризованными пайплайнами можно использовать Jenkins Shared Libraries.

👉 DevOps Portal

💻 Основные компоненты 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 🐧

В Linux оператор конвейера (|) полезен, когда нужно направить вывод одной команды на вход другой для дальнейшей обработки:

$ cat data.txt | grep "No such file"

Однако это не перенаправляет ошибки. Если файл не существует, команда grep не даст результата.

Что если нужно перенаправить и обработать как ошибки, так и обычный вывод? 🤔

Здесь на помощь приходит оператор перенаправления |&.

Этот оператор направляет как стандартный вывод (stdout), так и стандартные ошибки (stderr) первой команды через конвейер на стандартный ввод (stdin) второй команды. Посмотрите на следующий пример:

$ cat data.txt |& grep "No such file"

Обратите внимание на разницу: команда grep смогла найти совпадение.

Оператор |& в bash является сокращением для оператора перенаправления 2>&1 |:

$ cmd-1  2>&1  |  cmd-2

👉 DevOps Portal

👩‍💻 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 сгенерирует его автоматически.

Для запуска контейнера с монтированным томом используйте флаг -v:

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

— Создание и монтирование привязанных томов

Привязанные тома используют файловую систему хоста, а не Docker. Чтобы создать bind mount, необходимо заранее создать нужный каталог или файл на хосте.

Для монтирования каталога используйте флаг -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

🔹Список всех томов в системе:

docker volume ls

🔹Просмотр информации о томе:

docker volume inspect jenkins_home

🔹Удаление томов Docker
Удаление конкретного тома:

docker volume rm jenkins_home

Удаление всех неиспользуемых томов:

docker volume prune

Анонимные тома и привязанные тома обычно удаляются вместе с контейнером.

— Практическое применение Docker Volumes

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

— Лучшие практики использования томов 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