В двух предыдущих постах я рассказал о том, что такое ipfs и как развернуть сайт в ipfs и, помимо этого, для эксперимента настроил раздачу своего блога через ipfs: ipfs.romka.eu.

Сайт обслуживается дешёвой виртуальной машиной, а, как оказалось, ipfs довольно прожорлив до ресурсов процессора, особенно при выполнении команды ipfs add. Несколько раз хостер просто молча прибивал мою виртуалку из-за превышения ею каких-то лимитов.

В моём случае ipfs работает в докер-контейнере, который запускается через docker compose. Поэтому я сконфигурировал запуск контейнера следующим образом, чтобы сильно ограничить потребляемые ресурсы:

  ipfs:
    image: ipfs/kubo:latest
    container_name: ipfs_container
    volumes:
      - /home/romka/ipfs:/data/ipfs
      - /var/www/romka.eu/public:/data/ipfs/public:ro
    <...>
    restart: always
    command: daemon --enable-gc --migrate=true --enable-pubsub-experiment
    cpus: 0.3
    mem_limit: 256m
    memswap_limit: 256m
    environment:
      GOMAXPROCS: 1

Теперь ipfs-процесс ограничен по ресурсам и хостер доволен, но вот команда ipfs add стала падать с ошибкой вида Error: unexpected EOF. Я не стал копать глубже, но в свете того что ошибка появилась после добавления ограничений, похоже на то что это следствие того что ОС просто прибивает процесс ipfs из-за Out of Memory error (OOM). Дальше я расскажу как мне удалось исправить эту проблему.

В предыдущем блогпосте я рассказал об основных принципах работы IPFS и базовых возможностях предоставляемых системой. Здесь я рассмотрю немного более продвинутый пример и я расскажу о том, как в IPFS развернуть статический веб-сайт.

Для начала я в двух словах объясню в чём состоит различие между динамическими и статическими веб-сайтами.

У динамических веб-сайтов за отдачу содержимого отвечает какая-то программа. Обычно такие программы пишутся на одном из языков вроде PHP, JavaScript, Python, Go и других. Запрос от браузера пользователя обслуживается веб-сервером, который перенаправляет его программе, а программа в ответ на лету генерирует какую-то html-страницу, которая возвращается пользователю. В теории, запросы к одному и тому же адресу от разных пользователей могут получать разные ответы. Такой подход оправдан в случае если действительно есть необходимость отдавать разным пользователям разный контент при запросе одних и тех же страниц. Например, в социальных сетях одна и та же страница новостей для разных пользователей содержит разные новости.

В случае статического веб-сайта, все html-файлы заранее созданы и лежат в файловой системе сервера. Все запросы к сайту также обслуживаются веб-сервером, но он, минуя другие программы, отдаёт html-файлы с диска. Таким образом, все пользователи получают абсолютно одинаковые ответы на запросы к одинаковым адресам. Это максимально простой, быстрый и надёжный способ раздавать данные, который подходит для блогов вроде этого (хотя есть и куда более сложные сценарии использования статических сайтов).

IPFS – это распределённое хранилище и оно не способно обслуживать динамические сайты, однако вполне подходит для статических. Фактически, статический веб-сайт это просто директория с набором html-файлов, css, скриптов и картинок. Чтобы разместить такой сайт в IPFS достаточно добавить эти файлы в систему командой вида ipfs add .... Однако есть несколько важных нюансов, о которых я бы хотел рассказать.

Для того чтобы сделать статический веб-сайт доступным в IPFS нужно выполнить 4 шага:

1. запустить ipfs daemon,
2. в html-файлах использовать относительные ссылки на локальные ресурсы,
3. добавить dnslink,
4. использовать IPNS и включить его автоообновление.

На самом деле, только первые два шага обязательны к выполнению, но последние два сделают доступ к сайту более удобным. Дальше я детальнее расскажу о каждом из шагов.

Коротко говоря, IPFS (InterPlanetary File System) – это одноранговая распределённая сеть, позволяющая организовать хранение и распространение файлов. Любой желающий может присоединиться к сети для того чтобы начать распространять собственные данные и/или помочь распространению существующих в сети файлов. Архитектура системы была вдохновлена известными распределенными системами, в том числе BitTorrent, но в отличие от него предоставляет дополнительные инструменты. Например, IPFS может быть использована для размещения статических веб-сайтов.

Для проекта написана отличная документация, в которой можно найти ответы на все интересующие вопросы об этой системе. Для более глубокого понимания системы я рекомендую прочитать эту документацию, а также оригинальную статью от авторов проекта. В этой статье я постараюсь максимально доступно и последовательно дать всю информацию, необходимую для того, чтобы читатель с нулевыми знаниями об IPFS смог понять основные принципы её работы. Также я здесь порассуждаю о практической пользе от IPFS. В следующем посте я расскажу о том как развернуть в IPFS собственный статический сайт.

Около года назад мы с Олей переехали из Москвы в Берлин. В Москве Оля работала на немецкую компанию. Летом 2020 года компания решила закрыть российский офис и Оле предложили релоцироваться в Берлин. Обстоятельства сложились очень удачно: мы давно подумывали попробовать пожить за пределами России, но хотелось чтобы мы оба имели работу. Так как я программист, казалось, что мне найти работу будет проще и мы хотели чтобы сначала работу нашла Оля. В итоге, всё примерно так и сложилось: сначала около трех месяцев после переезда я потратил на подготовку к собеседованиям и около месяца прошло с момента когда я отправил первое резюме до момента когда я получил оффер в компанию своей мечты.

В этом блогпосте хочу рассказать о переезде, подготовке к интервью, поиске работы, а также о своих впечатлениях. Мне самому будет интересно почитать эти записи через пару лет и посмотреть насколько поменяются мои мысли. Этот текст — не инструкция по релокации в другую страну или по прохождению собеседования в большую IT-компанию, а просто повествование о моем опыте.

Здесь и далее фотографии просто чтобы разбавить рассказ, но к событиям в тексте они имеют косвенное отношение

Всем привет. Предлагаю вашему вниманию свой перевод поста “CPU Utilization is Wrong” из блога Брендана Грегга.

Метрика загруженности процессора (CPU utiliztion), которую все мы привыкли использовать, обычно понимается неправильно. Что такое загруженность процессора? То насколько процессор сейчас занят работой? Нет, это не так, и да, я говорю о метрике %CPU, которая используется всегда и везде, в каждой утилите мониторинга производительности, например в top(1).

Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже? Вот что это значит на самом деле:

Задача

Есть консольная команда вида:

./do-something.sh -x 1

Значение аргумента x может меняться в диапазоне от 1 до 30 000. Выполнение команды для одного аргумента занимает от 30 секунд до 15 минут. Нужно максимально быстро выполнить эту команду для заданного диапазона аргументов на N-ядерном сервере максимально используя ресурсы сервера.

Возможные варианты решения

1. Простой цикл от 1 до 30 тысяч с запуском команды на каждой итерации будет использовать только 1 ядро. Это решение неприемлемо: оно будет работать слишком долго и не задействует все доступные ресурсы сервера.
2. Можно вручную разбить диапазон на N частей и запустить N циклов вида:

   for i in `seq 1 1000`
   do
    ./do-something.sh -x $i
   done

Второе решение лучше первого — оно задействует все доступные ядра процессора, но оно все равно неприемлемо. Команды выполняются с непостоянной скоростью. В каком-то из диапазонов могут попасться только легкие команды, которые выполнятся, предположим, за несколько минут, а в каком-то — тяжелые и их выполнение затянется на несколько часов. Таким образом, часть ядер быстро освободится, будет простаивать и ресурсы сервера опять будут использованы неоптимально.