Развертывание IPFS-ноды

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1306 услуг
Развертывание IPFS-ноды
Простой
от 1 дня до 3 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1308
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1221
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    921
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1149
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    612
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    886

Развёртывание IPFS-ноды

IPFS (InterPlanetary File System) — content-addressed децентрализованная файловая система. Адресация по content hash (CID — Content Identifier) означает, что файл с одинаковым содержимым всегда имеет один и тот же CID, независимо от того, кто и где его хранит. Это ключевое свойство для Web3: NFT метаданные, адресованные по CID, не могут быть тихо подменены — изменение содержимого меняет CID.

Собственная нода нужна, когда публичные шлюзы (ipfs.io, Cloudflare) не обеспечивают нужную надёжность или скорость, когда нужно гарантировать доступность ваших данных (pinning), или когда объёмы трафика делают использование Pinata/NFT.Storage неоправданно дорогим.

Установка и конфигурация 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  # server profile отключает локальные mdns-объявления

# Запуск daemon
ipfs daemon &

--profile server важен для облачного деплоя: без него нода тратит ресурсы на mDNS discovery, который бесполезен в датацентре.

Конфигурация для production

# Ограничение использования памяти (критично, IPFS может потреблять много)
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"'

# Ограничение bandwidth
ipfs config --json Swarm.Transports.Network.Relay false

# Gateway: отдавать только запиненные CID (не работать публичным шлюзом)
ipfs config --json Gateway.NoFetch true
ipfs config --json Gateway.HTTPHeaders.Access-Control-Allow-Origin '["*"]'

Gateway.NoFetch true — нода не будет скачивать CID, которые не хранятся локально. Без этой настройки нода становится публичным шлюзом и может накапливать чужие данные.

Systemd сервис

# /etc/systemd/system/ipfs.service
[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 локально:

# Pin конкретного CID
ipfs pin add QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG

# Проверить список запиненных
ipfs pin ls --type recursive

# Garbage collection (удаляет незапиненное)
ipfs repo gc

Для программного pinning через API:

import { create } from "ipfs-http-client";

const client = create({ url: "http://localhost:5001/api/v0" });

// Загрузка и pinning файла
async function uploadAndPin(content: Buffer, filename: string): Promise<string> {
  const result = await client.add(
    { path: filename, content },
    { pin: true, wrapWithDirectory: true }
  );

  const cid = result.cid.toString();
  console.log(`Uploaded: ipfs://${cid}/${filename}`);
  return cid;
}

Nginx reverse proxy для gateway

API (5001) не должен быть открыт наружу — только gateway (8080):

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;   # кешировать CID ответы (они immutable)
        proxy_cache_bypass $http_cache_control;

        # Важно для больших файлов
        proxy_read_timeout 300s;
        proxy_buffering off;
    }
}

Мониторинг

# Размер хранилища
ipfs repo stat

# Количество peers
ipfs swarm peers | wc -l

# Bandwidth статистика
ipfs stats bw

В Prometheus через ipfs-prometheus-exporter или периодический скрипт с записью метрик. Алерты: ipfs_repo_size_bytes > threshold, ipfs_peers_count < 5 (изоляция от сети).

Pinata как гибридный подход

Собственная нода + Pinata (или web3.storage) как backup — хорошая практика для NFT-проектов. Pinata пиннит ваши CID на своей инфраструктуре, ваша нода обеспечивает быстрый доступ для ваших пользователей. Pinata API:

const pinata = new PinataSDK({ pinataJwt: process.env.PINATA_JWT });
await pinata.upload.cid("QmYour...CID");