Розгортання IPFS-ноди
Уявіть: ви запускаєте NFT-колекцію, метадані зберігаються на публічному шлюзі. Раптом шлюз падає — ваша колекція «сліпне». Або ви будуєте децентралізований додаток, який має працювати без єдиної точки відмови. В обох випадках власна IPFS-нода — єдине надійне рішення. Наш досвід включає 30+ проектів — від NFT-маркетплейсів до децентралізованих сховищ. Нижче — детальне керівництво з установки та налаштування production-ready ноди з урахуванням типових помилок.
Коли публічний шлюз не годиться?
IPFS (InterPlanetary File System) — content-addressed децентралізована файлова система. Адресація за content hash (CID) означає, що файл з однаковим вмістом завжди має однаковий CID, незалежно від того, хто і де його зберігає. Це ключова властивість для Web3: NFT-метадані, адресовані за CID, не можуть бути тихо підмінені — зміна вмісту змінює CID.
Публічні шлюзи (ipfs.io, Cloudflare) зручні для тестування, але в production підводять: ліміти запитів, повільне завантаження, ризик недоступності. Власна нода гарантує доступність даних (pinning) та швидкість, а при великих обсягах трафіку (понад 1 ТБ/міс) виявляється дешевше, ніж Pinata або NFT.Storage — економія може сягати 40%. Крім того, час відповіді шлюзу при пікових навантаженнях зростає в 2–3 рази, що критично для користувацького досвіду.
| Критерій | Публічний шлюз | Власна нода |
|---|---|---|
| Доступність | Залежить від оператора | Під ваш контроль |
| Швидкість | Обмежена лімітами | Максимальна |
| Pinning | Тільки на час сесії | Постійний |
| Конфіденційність | Шлюз бачить CID | Повна ізоляція |
| Вартість при >1TB/міс | Висока (паблік-ліміти) | Низька (тільки залізо) |
Установка та конфігурація Kubo
Kubo — reference реалізація IPFS на Go. Використовуємо останню стабільну версію:
wget https://dist.ipfs.tech/kubo/v0.28.0/kubo_v0.28.0_linux-amd64.tar.gz tar -xvzf kubo_v0.28.0_linux-amd64.tar.gz cd kubo && sudo bash install.sh ipfs init --profile server ipfs daemon & --profile server важливий для хмарного деплою: без нього нода витрачає ресурси на mDNS discovery, який марний у датацентрі. Profile server також вимикає локальні HTTP-точки для LAN-пошуку.
Як налаштувати IPFS-ноду для production?
Production-конфігурація вимагає жорсткого обмеження ресурсів. Без цього нода може «з'їсти» всю пам'ять і диск. Встановіть наступні ліміти:
ipfs config Datastore.StorageMax "100GB" ipfs config --json Swarm.ConnMgr.LowWater 200 ipfs config --json Swarm.ConnMgr.HighWater 400 ipfs config --json Swarm.ConnMgr.GracePeriod '"1m"' ipfs config --json Swarm.Transports.Network.Relay false ipfs config --json Gateway.NoFetch true ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Origin '["*"]' Gateway.NoFetch true — нода не буде завантажувати CID, які не зберігаються локально. Без цього налаштування нода стає публічним шлюзом і може накопичувати чужі дані, переповнюючи сховище. Обмеження StorageMax захищає диск від переповнення: при досягненні 95% ліміту IPFS починає активно видаляти незапінені блоки. Рекомендується залишити не менше 20% вільного місця для службових даних та тимчасових файлів.
При великій кількості пірів (>1000) варто збільшити Swarm.ConnMgr.LowWater до 500 та HighWater до 1000. Для покращення часу відповіді gateway увімкніть кешування: ipfs config --json Gateway.Cache.CacheSize 1000000 — кеш на 1 млн блоків. При 500 пірах витрата оперативної пам'яті становить близько 512 МБ, враховуйте це при виборі сервера.
Systemd сервіс
Для автоматичного запуску та перезапуску використовуємо systemd:
[Unit] Description=IPFS Daemon After=network.target [Service] Type=notify User=ipfs Environment=IPFS_PATH=/data/ipfs ExecStart=/usr/local/bin/ipfs daemon --migrate=true Restart=on-failure RestartSec=10s LimitNOFILE=65536 [Install] WantedBy=multi-user.target Після створення файлу виконайте sudo systemctl enable ipfs && sudo systemctl start ipfs.
Pinning: гарантія доступності
Додати файл в IPFS без pinning — він буде видалений при наступній garbage collection. Pinning фіксує CID локально. Для програмного pinning через API використовуємо ipfs-http-client:
import { create } from "ipfs-http-client"; const client = create({ url: "http://localhost:5001/api/v0" }); async function uploadAndPin(content: Buffer, filename: string): Promise<string> { const result = await client.add( { path: filename, content }, { pin: true, wrapWithDirectory: true } ); return result.cid.toString(); } Для перевірки стану pinning використовуйте ipfs pin ls --type recursive та ipfs repo stat.
Як налаштувати nginx reverse proxy для gateway?
API (порт 5001) не повинен бути відкритий назовні — тільки gateway (порт 8080). Налаштування nginx з кешуванням та SSL:
server { listen 443 ssl; server_name ipfs.yourservice.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_cache_valid 200 1d; proxy_cache_bypass $http_cache_control; proxy_read_timeout 300s; proxy_buffering off; } } Кешування на 1 день безпечне, оскільки CID — immutable ідентифікатори. Якщо файл оновлюється, CID змінюється, старий кеш автоматично протухає.
Моніторинг стану ноди
Регулярно перевіряйте розмір сховища (ipfs repo stat), кількість пірів (ipfs swarm peers | wc -l) та bandwidth (ipfs stats bw). Для автоматизації використовуйте Prometheus з ipfs-prometheus-exporter. Налаштуйте алерти: сховище >90% ліміту, кількість пірів <5 (ізоляція від мережі), bandwidth >80% пропускної здатності сервера.
| Метрика | Команда/Тул | Поріг алерту |
|---|---|---|
| Розмір сховища | ipfs repo stat |
>90% StorageMax |
| Кількість пірів | ipfs swarm peers |
<5 |
| Bandwidth | ipfs stats bw |
>80% ліміту |
Типові помилки при налаштуванні
- Використання дефолтного профілю замість server — mDNS в датацентрі створює зайвий трафік. Завжди вказуйте
--profile server. - Відкритий API-порт 5001 в інтернет — зловмисники можуть пінити чужі дані та виснажити диск. Закривайте порт через firewall.
- Відсутність ліміту StorageMax — призведе до переповнення диска. Завжди встановлюйте явне обмеження.
- Ігнорування GC — без pinning дані губляться. Пініть все, що має жити довго.
- Неправильне налаштування Gateway.NoFetch — нода починає завантажувати будь-які CID, споживаючи трафік. Відключайте цю опцію, якщо не хочете бути публічним шлюзом.
Що входить в роботу
При замовленні розгортання IPFS-ноди під ключ ми надаємо:
- Установку та налаштування Kubo з оптимальною конфігурацією під ваш проект
- Інтеграцію з існуючою інфраструктурою (CI/CD, моніторинг)
- Налаштування nginx reverse proxy та SSL-сертифіката
- Документацію з адміністрування та доступами
- Навчання команди базовим операціям (pinning, моніторинг)
- Супровід протягом гарантійного періоду
Отримайте консультацію з налаштування вашої IPFS-ноди. Замовте розгортання — ми проведемо аудит ваших вимог і запропонуємо оптимальну конфігурацію. Зв'яжіться з нами для консультації.