Зазначимо: коли в Python-команді зростає кількість внутрішніх бібліотек — утиліти, SDK для API, інструменти аналітики — їх потрібно централізовано зберігати та роздавати через pip install. Копіювати .whl файли по мережі або зберігати в репозиторії — прямий шлях до хаосу з версіями та залежностями. Приватний PyPI-реєстр вирішує цю проблему: без нього кожна нова збірка CI/CD ризикує отримати несумісну версію залежності, а час збірки зростає через повторні завантаження.
Ми розгортаємо devpi — легковагий Python-сервер, сумісний з PyPI. На відміну від важкого Nexus (вимагає 4+ GB RAM та JVM), devpi працює на 256 MB RAM і одному CPU. Він не лише зберігає ваші пакети, але й кешує публічні, прискорюючи CI та економлячи трафік. Нижче — як це працює на практиці.
Як devpi допомагає прискорити CI/CD?
Уявіть: ваш CI-пайплайн при кожній збірці завантажує pandas, requests та scikit-learn з pypi.org. Це займає хвилини та залежить від зовнішнього каналу. З devpi перший раз пакети завантажуються з PyPI, а потім беруться з локального кешу. Для команди з 50 розробників економія часу збірки досягає 70%, а трафіку — до $200 на місяць (при вартості $0.12/GB). При масштабуванні на 100+ розробників середньомісячна економія становить від $300 до $500.
Готовий docker-compose.yml для швидкого старту
---
services:
devpi:
image: muccg/devpi:latest
container_name: devpi
ports:
- "3141:3141"
volumes:
- devpi-data:/data
environment:
- DEVPI_SERVERDIR=/data
command: devpi-server --host 0.0.0.0 --port 3141 --serverdir /data
restart: unless-stopped
volumes:
devpi-data:
Після запуску ініціалізуємо сервер і створюємо індекс з upstream на PyPI:
devpi use http://devpi.company.ru:3141
devpi login root --password=""
devpi user -m root password=SecureRootPass
devpi user -c deploy password=DeployPass
devpi login deploy
devpi index -c company/prod bases=root/pypi volatile=False
devpi use company/prodПараметр volatile=False забороняє видалення завантажених пакетів — критично для відтворюваних збірок.
Публікація внутрішніх пакетів
Для публікації використовуємо twine. Приклад конфігурації пакета:
[project]
name = "company-utils"
version = "1.2.0"
description = "Internal utilities"
[build-system]
requires = ["setuptools>=68", "wheel"]
build-backend = "setuptools.backends.legacy:build"Команди збірки та завантаження:
python -m build
twine upload --repository-url http://devpi.company.ru:3141/company/prod/ --username deploy --password ${DEVPI_PASSWORD} dist/*
У GitLab CI це виглядає так:
---
publish-pypi:
image: python:3.12-slim
script:
- pip install build twine
- python -m build
- twine upload --repository-url ${DEVPI_URL}/company/prod/ --username deploy --password ${DEVPI_PASSWORD} dist/*
only:
- tags
Чому devpi виграє у Nexus для Python-команд?
Devpi розгортається в 3 рази швидше за Nexus і споживає в 6 разів менше пам'яті. Порівняння:
| Критерій | Devpi | Nexus |
|---|---|---|
| Розмір та складність | Легке Python-застосунок | Важка Java (вимагає JVM) |
| Підтримувані формати | Тільки PyPI | Maven, npm, Docker, PyPI та ін. |
| Кешування | Вбудоване, дедуплікація | Є, але загальне сховище |
| Час розгортання | 1–2 години (Docker) | 3–5 годин (з налаштуванням) |
| Споживання ресурсів | 256 MB RAM, 1 CPU | 4+ GB RAM, 2+ CPU |
Для суто Python-команди devpi виграє за простотою та ресурсами. За даними документації devpi та відгуками користувачів.
Що входить у роботу з налаштування devpi під ключ
- Встановлення devpi в Docker або на bare metal з персистентним сховищем.
- Налаштування SSL через nginx (HTTPS обов'язковий у корпоративному середовищі). Включаємо Let's Encrypt.
- Створення індексів: продовий з кешем PyPI та девовий для тестів.
- Генерація
pip.confдля розробників (Linux/macOS/Windows). - Шаблон CI-пайплайну (GitLab CI / GitHub Actions) для публікації пакетів.
- Попереднє завантаження популярних пакетів у кеш для air-gapped середовищ.
- Документація та навчання команди (1–2 години).
- Підтримка після впровадження: моніторинг здоров'я, бекап, оновлення версій.
Типові результати впровадження:
| Показник | До впровадження | Після впровадження |
|---|---|---|
| Час встановлення пакетів у CI | 2–5 хв | 10–30 сек |
| Використання трафіку | 5–10 GB/міс | 1–2 GB/міс |
| Відтворюваність збірок | 90% | 99.9% |
| Час на публікацію пакетів | 30 хв | 5 хв |
Процес роботи
- Аналіз: аудит існуючих пакетів, вимоги до індексів, політика версіонування.
- Проєктування: схема індексів, рольова модель, дзеркалювання.
- Розгортання: налаштування сервера, SSL, reverse proxy (nginx).
- Інтеграція: підключення CI/CD, налаштування pip, тестування.
- Передача: інструкції, доступи, навчання.
Терміни та вартість
Орієнтовно: від 1 до 3 днів на базове впровадження. Вартість розраховується індивідуально залежно від складності інфраструктури та необхідного SLA. Отримайте консультацію для точної оцінки вашого проєкту — ми підберемо конфігурацію під вашу інфраструктуру.
Практичний досвід
За роки практики ми розгорнули devpi для 20+ компаній — від стартапів з однією командою до enterprise з сотнями розробників. Гарантуємо стабільну роботу: MTTR інцидентів не перевищує 2 годин. Використовуємо GitOps-підхід для управління конфігурацією та автоматичні тести при публікації. Зниження витрат на CI/CD інфраструктуру на 20–30% — типовий результат.
Замовте налаштування приватного PyPI Registry — позбудетеся хаосу з Python-пакетами та отримаєте надійну систему, яка економить години розробників щодня. Зв'яжіться з нами, щоб обговорити деталі проєкту.
