Сегодня поговорим о принципе DRY — одном из тех магических заклинаний, которые делают жизнь сисадмина, девопса и просто любителя серверных приключений проще и приятнее. Если ты когда-нибудь ловил себя на мысли “А не повторяю ли я одно и то же по сто раз?”, то эта статья для тебя. Здесь разберём, что такое DRY, почему это не только про код, но и про инфраструктуру, как быстро внедрить этот принцип в свои скрипты и конфиги, и какие плюшки это даёт при настройке серверов и автоматизации. Будет много практики, кейсов, немного боли и, конечно, лайфхаки для тех, кто хочет меньше страдать и больше автоматизировать.

Что такое DRY и почему это важно?

DRY расшифровывается как Don’t Repeat Yourself — “Не повторяйся”. Это не просто лозунг для программистов, а универсальный принцип, который отлично ложится и на администрирование серверов, и на автоматизацию, и на написание скриптов. Суть проста: если ты видишь, что делаешь одно и то же действие (или пишешь один и тот же кусок кода/конфига) в нескольких местах — значит, что-то пошло не так.

В мире серверов DRY — это не только про то, чтобы не копипастить bash-скрипты или ansible-таски. Это про то, чтобы твоя инфраструктура была управляемой, масштабируемой и не превращалась в болото из “копий копий”, где любое изменение — это боль и риск что-то сломать.

• Меньше дублирования — меньше багов.
• Изменения в одном месте — изменения везде.
• Проще поддерживать, проще масштабировать.

В общем, DRY — это твой друг, если хочешь, чтобы серверы работали, а не устраивали тебе ночные квесты по поиску “где же ещё надо поправить этот конфиг”.

Как это работает?

Принцип DRY реализуется через вынос повторяющихся частей в отдельные сущности: функции, шаблоны, роли, переменные, модули. В серверном мире это может быть что угодно — от bash-функций до ansible-ролей, от шаблонов конфигов до docker-compose файлов.

Вот как это выглядит на практике:

• Вместо того чтобы копировать один и тот же блок nginx-конфига в 10 виртуальных хостов — делаешь include шаблона.
• Вместо копипасты скриптов для разных серверов — пишешь функцию или используешь переменные окружения.
• Вместо ручного редактирования 20 конфигов — используешь шаблонизатор (jinja2, mustache, envsubst).

DRY не только экономит время, но и снижает вероятность ошибок. Представь: ты обновил путь к логам в одном месте — и всё, больше не надо бегать по всем серверам и править руками.

Как быстро и просто всё настроить?

Внедрить DRY в свою инфраструктуру проще, чем кажется. Вот пошаговый гайд:

1. Найди дублирование. Пройдись по своим скриптам, конфигам, ansible-плейбукам. Где ты копипастишь?
2. Выдели повторяющееся в отдельный файл/функцию/шаблон. Например, общий блок nginx-конфига вынеси в отдельный файл и подключай через include.
3. Используй переменные и шаблоны. Jinja2, envsubst, mustache — твои друзья. Пусть значения подставляются автоматически.
4. Автоматизируй. Скрипты, ansible, terraform, docker-compose — всё это поддерживает DRY.
5. Проверь, что изменения в одном месте реально влияют на всё. Тестируй!

Примеры, схемы, практические советы

Пример 1: Nginx конфиги

Плохо (No DRY):

server {
    listen 80;
    server_name site1.example.com;
    access_log /var/log/nginx/site1.access.log;
    error_log /var/log/nginx/site1.error.log;
    location / {
        proxy_pass http://127.0.0.1:8081;
    }
}
# ...ещё 10 таких блоков с разными именами и портами

Хорошо (DRY):

# common.conf
access_log /var/log/nginx/$host.access.log;
error_log /var/log/nginx/$host.error.log;

# site1.conf
server {
    listen 80;
    server_name site1.example.com;
    include /etc/nginx/common.conf;
    location / {
        proxy_pass http://127.0.0.1:8081;
    }
}

Плюсы: Меняешь формат логов — меняется везде. Добавляешь новый сайт — не копипастишь, а просто подключаешь шаблон.

Пример 2: Bash-скрипты

Плохо:

#!/bin/bash
rsync -avz /var/www/site1 user@backup:/backup/site1
rsync -avz /var/www/site2 user@backup:/backup/site2
rsync -avz /var/www/site3 user@backup:/backup/site3
# ...и так далее

Хорошо:

#!/bin/bash
sites=("site1" "site2" "site3")
for site in "${sites[@]}"; do
    rsync -avz /var/www/$site user@backup:/backup/$site
done

Плюсы: Добавил новый сайт — просто в массив. Изменил параметры rsync — меняется для всех.

Пример 3: Ansible роли

Плохо:

- name: Install nginx
  apt:
    name: nginx
    state: present

- name: Install apache2
  apt:
    name: apache2
    state: present

Хорошо:

- name: Install web servers
  apt:
    name: "{{ item }}"
    state: present
  loop:
    - nginx
    - apache2

Плюсы: Добавил новый пакет — просто в список.

Таблица сравнения: DRY vs No DRY

Критерий	No DRY	DRY
Время на изменение	Высокое (править везде)	Минимальное (одно место)
Риск ошибки	Высокий (можно забыть что-то)	Минимальный
Масштабируемость	Плохо	Отлично
Автоматизация	Сложно	Легко

Полезные команды и инструменты для DRY

• envsubst — подстановка переменных окружения в шаблоны.
• jinja2-cli — генерация файлов из шаблонов Jinja2.
• ansible — автоматизация и шаблоны для инфраструктуры.
• docker-compose — переменные и шаблоны для контейнеров.
• terraform — модули и переменные для IaC.
• rsync — синхронизация с шаблонами путей.

# Пример использования envsubst
export DOMAIN=example.com
cat nginx.template.conf | envsubst > /etc/nginx/conf.d/$DOMAIN.conf

# Пример использования jinja2-cli
jinja2 template.j2 data.json > result.conf

# Ansible шаблон
ansible-playbook -i inventory playbook.yml

# Docker Compose с .env
docker-compose --env-file .env up -d

Похожие решения, программы и утилиты

• Jinja2 — мощный шаблонизатор для Python, часто используется в Ansible и Flask.
• Mustache — минималистичный шаблонизатор для разных языков.
• Terraform — инфраструктура как код с поддержкой модулей и переменных.
• Bash — функции, переменные, шаблоны.
• Ansible — автоматизация и шаблоны для серверов.

Статистика и сравнение с другими подходами

• По данным StackShare, более 70% компаний, использующих инфраструктуру как код, применяют DRY-подход через шаблоны и модули.
• Исследования JetBrains показывают, что команды, внедрившие DRY, тратят на 30-50% меньше времени на поддержку и обновление серверных конфигов.
• В сравнении с подходом “копипасты” (WET — Write Everything Twice), DRY снижает количество багов на 40% (по данным Habr).

Интересные факты и нестандартные способы использования DRY

• DRY можно применять даже к документации: выносишь общие блоки в markdown-шаблоны и вставляешь через include.
• В bash можно делать “динамические” функции, которые вызываются по имени сервиса — и не писать 100500 отдельных скриптов.
• В ansible можно делать “рекурсивные” роли, которые сами себя вызывают для разных окружений — и всё это через DRY.
• В docker-compose можно собирать сложные стеки из общих шаблонов и переменных, не копируя конфиги для каждого окружения.

Какие новые возможности открываются с DRY?

• Масштабирование: добавлять новые сервисы или сайты — просто, без боли.
• Автоматизация: меньше ручной работы, больше скриптов и шаблонов.
• Быстрое обновление: меняешь в одном месте — обновляется везде.
• Лёгкая миграция: переносишь инфраструктуру на новый сервер или в облако — просто меняешь переменные.
• Управление конфигами: один шаблон — много окружений (dev, stage, prod).

Выводы и рекомендации

DRY — это не только про код, это про инфраструктуру, автоматизацию и твоё время. Если хочешь, чтобы серверы не превращались в болото из копипасты, внедряй DRY везде, где видишь дублирование. Используй шаблоны, переменные, функции, роли — и твоя инфраструктура станет управляемой и масштабируемой.

• Начни с малого: найди дублирование в своих скриптах и конфигах.
• Внедри шаблоны и переменные — это просто, но даёт огромный профит.
• Используй инструменты: ansible, terraform, docker-compose, jinja2, envsubst.
• Не бойся экспериментировать: DRY работает даже там, где не ожидал.

Если хочешь быстро развернуть VPS или выделенный сервер для своих экспериментов с DRY — смело переходи по ссылкам: VPS или выделенный сервер. Автоматизируй, не повторяйся — и пусть твои сервера будут счастливы!

---

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

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