Простой Bash-скрипт для синхронизации Git-репозиториев между разными серверами

Есть инструменты, которые переживают целые поколения технологий. Они появляются в эпоху физических серверов, доживают до контейнеров, переживают облака и внезапно обнаруживают себя в мире Kubernetes и сервисных сетей. Fail2Ban относится именно к таким инструментам. Если человек хотя бы несколько лет занимался эксплуатацией Linux-систем, вероятность того, что он никогда не устанавливал Fail2Ban, примерно такая же, как вероятность встретить администратора, который ни разу не писал chmod 777 в состоянии лёгкого отчаяния. Этот инструмент был буквально повсюду. Новый VPS? Ставим Fail2Ban. Публичный SSH? Ставим Fail2Ban. Nginx, Postfix, Dovecot, WordPress - для всего существовали готовые фильтры. И самое интересное заключается в том, что всё это действительно работало. Fail2Ban не был временным костылём или очередной модной игрушкой сообщества. Это был честный, надёжный и удивительно практичный инструмент, который спас огромное количество серверов от вполне реальных проблем.

В предыдущей статье я подробно разбирал, как автоматически разворачивать собственные серверы Hysteria2 через Ansible, получать сертификаты, создавать пользователей и превращать несколько VPS в нормальную воспроизводимую инфраструктуру вместо коллекции команд из истории shell. В результате у нас появились серверы Hysteria2 в нескольких географических точках и готовые URI подключения вида hysteria2://user:password@host:443. Но довольно быстро возник следующий совершенно логичный вопрос: если эти серверы уже существуют, почему через них должен ходить только ноутбук или телефон, а домашняя и серверная инфраструктура продолжает самостоятельно решать проблемы с доступом к внешним сервисам? Предыдущая схема хорошо решает транспортную часть задачи, теперь пришло время поставить над ней нормальный маршрутизатор.

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

Я столкнулся с этим, когда занимался проектами, которые собирают сведения об инфраструктуре и управляют ею через API. Сначала хотел сделать небольшой инструмент для собственных тестов, чтобы реже зависеть от лабораторного Proxmox. В результате появились четыре проекта: симуляторы API Proxmox VE, OpenStack, VMware и oVirt.

Когда инженеры представляли себе восстание машин, всё выглядело гораздо эффектнее. Сверхразум захватывает военные спутники, где-то на фоне горит Лос-Анджелес, из радио доносится синтезированный голос, а человечество наконец понимает, что подключать ядерный арсенал к Скайнету было не самой удачной архитектурной идеей. Реальность, как это часто бывает в инфраструктуре, оказалась одновременно прозаичнее и интереснее. Никаких терминаторов, красных глаз и путешествий во времени. Искусственный интеллект обнаружил Artifactory, нашёл несколько уязвимостей, организовал там импровизированную доску сообщений и вместе с другими агентами полез туда, куда организаторы эксперимента его вообще не приглашали. Киберпанк наступил, но вместо неоновых улиц нам достались Kubernetes, токены доступа и очередной разбор инцидента.

В 2014 году Kubernetes выглядел для многих инженеров странной игрушкой от Google. Зачем городить сложную систему оркестрации, если есть виртуальные машины, Bash-скрипты и проверенные временем конфигурации? Прошло несколько лет, и Kubernetes превратился в стандарт де-факто. Он изменил подход к доставке приложений, масштабированию и эксплуатации инфраструктуры.

Сегодня мы наблюдаем похожую ситуацию. На рынке искусственного интеллекта появляется множество новых терминов: агенты, инструменты, контекст, расширения. Среди них легко пропустить технологию, которая потенциально способна изменить повседневную работу инженеров не меньше, чем когда-то изменил её Kubernetes. Речь идёт о Model Context Protocol, или MCP.

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

Однако практика показала интересную вещь. Запреты не работают. Разработчики продолжают использовать ChatGPT для генерации кода. Аналитики загружают документы во внешние сервисы. Инженеры просят ИИ объяснить ошибки Terraform или Kubernetes. Данные компании всё равно покидают периметр, просто делают это неуправляемо.