Настройка приватного Apt/Yum репозитория для внутренних пакетов

Настройка приватного Apt/Yum Repository для внутренних пакетов

Отметим: когда в организации есть собственные пакеты — кастомные версии nginx с модулями, внутренние агенты мониторинга, патченые библиотеки — их нужно как-то распространять по серверам. Копировать .deb/.rpm вручную через scp не масштабируется: версии расходятся, обновления пропускаются, нет централизованного учёта. Приватный репозиторий решает задачу: apt install internal-agent или dnf update nginx-custom — и сервер получает актуальную версию с подписью.

Мы, как практикующие DevOps-инженеры с 10+ годами опыта, настраиваем такие репозитории под ключ. Наши сертифицированные специалисты (Kubernetes, AWS, Linux) гарантируют стабильность и безопасность — от подписи GPG до автоматической публикации через CI/CD. Свяжитесь с нами, чтобы оценить ваш проект за один день. За 5 лет мы развернули более 50 репозиториев для клиентов из финансового и телеком-секторов.

Почему стоит использовать приватный репозиторий?

• Версионирование и откаты: храните историю версий, легко откатитесь при проблемах.
• Безопасность: подпись пакетов GPG исключает подмену; доступ ограничивается через RBAC.
• Автоматизация: CI/CD может публиковать пакеты при каждом теге, а Ansible — обновлять серверы.
• Масштабирование: репозиторий можно развернуть на отдельном сервере или в облаке, обслуживая сотни машин.

Как настроить Apt-репозиторий на базе Aptly?

aptly — инструмент для управления Debian/Ubuntu репозиториями. Умеет подписывать, делать snapshots, публиковать через HTTP. Развёртывание занимает 30 минут.

apt install aptly gnupg
# Создаём GPG-ключ для подписи репозитория
gpg --batch --gen-key <<EOF
Key-Type: RSA
Key-Length: 4096
Name-Real: Internal Repo
Name-Email: [email protected]
Expire-Date: 0
%no-protection
EOF
gpg --export --armor [email protected] > /etc/apt/trusted.gpg.d/internal-repo.asc

aptly repo create -distribution=jammy -component=main internal
aptly repo add internal /path/to/package_1.0_amd64.deb
aptly publish repo internal filesystem:public:jammy

Раздача через Nginx:

server {
    listen 80;
    server_name repo.internal.example.com;
    root /var/www/aptly/public;
    autoindex on;

    location / {
        try_files $uri $uri/ =404;
    }
}

На клиенте:

deb [signed-by=/etc/apt/trusted.gpg.d/internal-repo.asc] http://repo.internal.example.com jammy main
apt update && apt install internal-agent

Как настроить YUM/DNF-репозиторий через createrepo?

Для RHEL/CentOS/AlmaLinux используем createrepo_c — быстрая генерация метаданных:

dnf install createrepo_c gpg
mkdir -p /var/www/repos/el9/x86_64/Packages
cp internal-agent-1.0.x86_64.rpm /var/www/repos/el9/x86_64/Packages/
createrepo_c /var/www/repos/el9/x86_64/
createrepo_c --update /var/www/repos/el9/x86_64/ # при добавлении пакетов

Подпись:

gpg --detach-sign --armor /var/www/repos/el9/x86_64/repodata/repomd.xml 

Клиент: /etc/yum.repos.d/internal.repo:

[internal]
name=Internal Repository
baseurl=http://repo.internal.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=http://repo.internal.example.com/RPM-GPG-KEY-Internal

Что выбрать: Nexus Repository Manager как универсальное решение?

Если нужен репозиторий с веб-интерфейсом, управлением доступом и поддержкой нескольких форматов (apt, yum, Maven, npm, Docker), используем Nexus OSS. Запуск в Docker:

services:
  nexus:
    image: sonatype/nexus3:latest
    ports:
      - "8081:8081"
    volumes:
      - nexus-data:/nexus-data
    environment:
      INSTALL4J_ADD_VM_PARAMS: "-Xms2g -Xmx2g -XX:MaxDirectMemorySize=3g"

Загрузка пакета:

curl -u admin:password --upload-file package_1.0_amd64.deb \
    "http://nexus.internal:8081/repository/apt-internal/"

Сравнение инструментов: таблица выбора

Для двух дистрибутивов (Ubuntu и CentOS) можно развернуть Aptly и createrepo на одном сервере. Если нужна универсальность — Nexus лучше подходит: экономия времени на администрирование до 60%.

Как автоматизировать публикацию через CI/CD?

Правильный workflow: CI/CD собирает пакет, подписывает, публикует в репозиторий. Клиенты получают обновление через стандартный apt upgrade или Ansible.

Пример для GitLab CI:

---
publish:
  stage: deploy
  script:
    - dpkg-buildpackage -us -uc -b
    - curl -u ${NEXUS_USER}:${NEXUS_PASS} \
        --upload-file ../internal-agent_*.deb \
        "${NEXUS_URL}/repository/apt-internal/"
  only:
    - tags
---

Мы настраиваем такие pipeline за 1–2 дня. Можно также триггерить Ansible-playbook на обновление пакетов на серверах после публикации.

Что входит в работу

• Аудит текущей инфраструктуры и выбор инструмента.
• Развёртывание репозитория (Aptly/createrepo/Nexus) с подписью GPG.
• Настройка раздачи через Nginx или обратный прокси.
• Подключение целевых серверов к репозиторию (через Ansible).
• Создание CI/CD pipeline для автоматической публикации.
• Документация и обучение команды (runbook).
• Гарантийная поддержка 30 дней.

Сроки и как начать

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

Безопасность и доступность репозитория

Репозиторий внутренних пакетов — критичная инфраструктура: если он недоступен, apt upgrade на сотнях серверов завершается ошибкой. Мы настраиваем мониторинг доступности через Prometheus blackbox exporter и резервное зеркало для отказоустойчивости.

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

Свяжитесь с нами — оценим ваш проект за 1 день и предложим оптимальное решение под вашу инфраструктуру.