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

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

Коли в організації є власні пакети — кастомні версії 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 день і запропонуємо оптимальне рішення під вашу інфраструктуру.