Добавление файла размещает его на многих машинах, которые являются частью подключенного роя. Когда вы добавляете файл, вы получаете адрес. Этот адрес относится к файлу, а не к серверу, на котором он находится.
IPFS также имеет фиксированные шлюзы - машины, подключенные к IPFS, которые являются частью роя и помогают облегчить публикацию и выборку файлов в рое. Эти шлюзы также имеют Javascript API, позволяющий интерфейсным приложениям напрямую взаимодействовать с IPFS, опять же без сервера.
Передавая сеть сообществу, мы устраняем трение, вызванное обязательством одной организации умиротворить заинтересованные стороны или давлением со стороны различных форм власти.
Это довольно круто, и это очень просто, если вы немного измените представление о файловой системе.
План на выходные - настроить виртуальный частный сервер в качестве шлюза IPFS для размещения небольшого веб-сайта с доменом вроде https://ipfs.example.com
.
Эта статья предназначена для профессиональных разработчиков или любителей, интересующихся распределенной сетью, и мы рассмотрим…
- Настройка IPFS на сервере для создания шлюза
- Поддержание работы шлюза как службы
- Получение файлов и публикация файлов в IPFS
- Укажите доменное имя на общедоступном шлюзе и на нашем шлюзе
- Настройте SSL с помощью Let’s encrypt для nginx
- Обратный прокси-сервер шлюза с помощью nginx, перенаправьте запросы с веб-порта на внутренний порт, на котором работает IPFS.
- Конфигурация кеширования для нашего нового шлюза IPFS.
Установите IPFS на Ubuntu 20.04
Сначала убедитесь, что система обновлена, и установите tar и wget:
|
|
Затем загрузите последнюю версию IPFS (вы можете проверить доступные версии здесь) и установите его:
|
|
Распакуйте и переместите в извлеченную папку для установки:
|
|
Обычно запускать общедоступную службу от имени пользователя root - не лучший вариант. Итак, создайте новую учетную запись пользователя для запуска IPFS и переключитесь на нее:
|
|
Проверьте версию и давайте инициализируем ipfs:
|
|
Запишите результат. Идентификатор однорангового узла идентифицирует однорангового узла в отличие от контента, который будет опубликован одноранговым узлом, нам это понадобится позже.
|
|
Для некоторой радости вы можете сделать то, что он предлагает, и запустить нижеприведенный документ, который покажет вам документ readme IPFS.
|
|
Пока все хорошо, но мы хотим убедиться, что так и будет. Чтобы IPFS постоянно работала, мы должны настроить демон ipfs deamon &
для работы в фоновом режиме. Перейдем в систему и сделаем служебный файл:
|
|
Создайте файл /etc/systemd/system/ipfs.service
с этим содержимым:
|
|
Разрешите пользователю ipfs запускать долго работающие службы, включив задержку для этого пользователя:
|
|
Включите и запустите службу:
|
|
Теперь IPFS должна быть запущена и запускаться при загрузке сервера.
Давайте убедимся, что он восстановится после перезагрузки, а затем перезагрузимся, чтобы проверить это.
|
|
Войдите в систему и проверьте активность с помощью
|
|
Давайте наведем порядок, удалив файлы, которые мы скачивали и распаковывали.
|
|
Теперь убедитесь, что мы подключаемся к другим узлам роя.
|
|
и вы должны увидеть большой старый список сверстников! Ура! Потрясающие!
Другие члены роя также смогут выполнить ту же команду и увидеть наш шлюз в списке.
Время публиковать!
Так же, как когда мы настраиваем apache
или nginx
для веб-хостинга, я собираюсь создать папку с тем же именем, что и домен, который будет указывать на эту папку. Я назвал эту папку ipfs.example.com
, вы можете называть ее как хотите, но позже, когда у вас будет много сайтов, вы можете не знать, какой домен указывает на какую папку.
|
|
Хорошо, давайте сделаем действительно крутой сайт. Все должно быть статичным, поэтому не более чем старый добрый HTML, JavaScript и CSS.
|
|
и скопируйте или сделайте что-нибудь получше:
|
|
Мы можем опубликовать это, выпрыгнув из папки
|
|
Вы должны просто увидеть папку ipfs.example.com
, которую мы создали ранее. Теперь мы хотим добавить всю папку и ее содержимое в IPFS.
|
|
Это рекурсивно добавляет все содержимое папки ipfs.example.com
в IPFS. Вы должны увидеть примерно такой результат:
|
|
IPFS сгенерирует хеш для каждого добавленного файла. В конце он предоставит вам хеш-код вашего сайта, это тот, который нас интересует.
|
|
Ваш сайт теперь добавлен в IPFS. Вы можете просмотреть его сейчас на шлюзе ipfs.io
: https://ipfs.io/ipfs/QmV8G4Ez...
Или на своем локальном по адресу localhost:8080
. Или на любом другом шлюзе.
Вау, волшебство !!! Но подождите, если я хочу изменить сайт, этот хеш будет изменяться, и если я свяжу домен с хешем, он будет ломаться каждый раз, когда я меняю сайт. Что нам нужно сделать, так это связать хэш сайта с идентификатором партнера.
|
|
и вы получите два нижеприведенных хэша, которые теперь связаны между собой, первый хеш - это ваш идентификатор партнера, который мы сохранили ранее, а второй - хеш вашего сайта.
|
|
Для связывания однорангового идентификатора с файлом или папкой используются IPNS.
IPNS можно рассматривать так же, как DNS, домен, который не изменяется и может быть связан с любым IP-адресом. С IPNS у нас есть одноранговая идентификация, которая может быть связана с любым файлом или папкой. Обратите внимание, что теперь мы используем «ipns» (межпланетная система имен), а не «ipfs» (межпланетная файловая система), как мы делали это раньше по ссылке ниже.
https://ipfs.io/ipns/QmeQe5FT...
Так что даже если мы изменим сайт, эта ссылка всегда будет хорошей. А чтобы сменить сайт, нам просто нужно сделать…
|
|
Примечание: объекты, добавленные с помощью
ipfs add
, по умолчанию закрепляются рекурсивно. Закрепление ipfs - это способ убедиться, что сборка мусора не удаляет объекты, которые вы хотите сохранить.
Давайте сделаем так, чтобы этот URL выглядел немного лучше, где бы вы ни приобрели свой домен, они предоставят вам панель управления, в которой вы можете редактировать свои записи DNS. В DNS давайте добавим запись TXT
на ipfs.example.com
и дождемся ее распространения.
|
|
Теперь мы можем перейти к https://ipfs.io/ipns/ipfs.example.com
лучше, но все же не самое лучшее, давайте добавим запись A
, указывающую на IP-адрес https://ipfs.io
|
|
результат
|
|
Итак, давайте укажем запись A
для ipfs.example.com
на 209.94.90.1
и снова подождем, пока она распространится.
В качестве альтернативы это можно сделать с помощью CNAME
для ipfs.example.com
, чтобы указать на gateway.ipfs.io
, что позволит избежать привязки к любому IP-адресу.
Теперь мы можем перейти на ipfs.example.com
.
Просто чтобы убедиться, что на сервер не полагаются, выключите его и снова запросите домен ipfs.example.com
, и вы обнаружите, что он все еще там!
Пока люди продолжают его запрашивать, он будет оставаться там, если его никто не запросит какое-то время, сборщик мусора узлов избавится от него. Если вы будете поддерживать свой сервер в рабочем состоянии, он всегда будет там.
Установите nginx с SSL-сертификатами Let’s Encrypt
Убедитесь, что система обновлена, и установите nginx
:
|
|
Отредактируйте /etc/nginx/sites-available/default
|
|
Проверьте свою конфигурацию:
|
|
Если все в порядке, перезагрузите nginx:
|
|
Это будет проксировать все запросы к example.com
и ipfs.example.com
на наш IPFS шлюз, работающий на localhost:8080
, но без кеширования!
Установите Certbot
|
|
Запустите Certbot
, чтобы получить сертификаты SSL
. Certbot
поддерживает nginx
и автоматически обновит ваш файл конфигурации.
|
|
Certbot попросит вас выбрать, является ли доступ HTTPS
обязательным или необязательным (выберите вариант «Безопасный»).
Чтобы повысить безопасность, обновите параметры Диффи-Хеллмана:
|
|
Включите этот файл где-нибудь в блоке server
вашей nginx конфигурации /etc/nginx/sites-available/default
, например:
|
|
Опять же, проверьте свою конфигурацию:
|
|
Если все в порядке, перезагрузите nginx:
|
|
Срок действия сертификатов Let's Encrypt
истекает через 90 дней, поэтому у вас должны быть средства для их автоматического обновления. Crontab - хороший способ сделать это:
|
|
Добавьте в конец файла следующую строку:
|
|
При этом certbot renew --quiet
будет запускаться каждый день в 3:15. Он проверяет, скоро ли истекает срок действия сертификатов (через 30 дней или меньше), и, если да, обновляет их.
Теперь, если вы перейдете на https://example.com
, вы должны увидеть веб-сайт, который вы добавили в IPFS выше.
Давайте попробуем заставить обратный прокси nginx правильно кэшировать ответ IPFS. Это не ускорит загрузку начального запроса страницы, но во всех последующих запросах он будет невероятно быстрым, так как будет поступать с локального диска.
Отредактируйте /etc/nginx/sites-available/default
Удалить эту строку
|
|
Добавить эту строку
|
|
Добавьте этот блок с истечением срока действия над существующим блоком сервера
|
|
В серверном блоке добавьте
|
|
Затем отредактируйте nginx.conf
|
|
Под http, добавьте
|
|
Раскомментируйте
|
|
Добавьте
|
|
Опять же, проверьте свою конфигурацию:
|
|
Тест может завершиться неудачно, потому что некоторых папок не существует, поэтому добавьте те, на которые он жалуется, вручную и повторите попытку.
|
|
Затем перезапустите снова…
|
|
Ура! Вернувшись на вкладку сети в Chrome Dev Tools
, html-файлы
проверяются на сервере и получают 304
без изменений, а изображение получает 200
из кэша памяти и быстро загружается.
Окончательная версия со шлюзом кеширования находится в сети здесь https://ipfs.example.com
. Если вы хотите сравнить его с отсутствием кеширования, вы можете посетить более медленный общедоступный шлюз по адресу https://ipfs.io/ipns/ipfs.example.com
.
Заключение
В мире, где секунды на счету, IPFS - отличный запасной вариант, но я бы не стал жертвовать потерей пользователей из-за более медленных или непостоянных скоростей по сравнению с резкими скоростями и безопасностью более крупной и предсказуемой облачной службы, которая также защищает вас от атак ddos. и выталкивание вашего контента на границы Интернета и что наиболее важно, отправка всех файлов в браузер одновременно.