Трудно представить разработчика, использующего macOS, но не использующего Homebrew. Это менеджер пакетов, позволяющий устанавливать сторонние программы (кстати, недавно он получил поддержку платформ Linux и Windows). Первоначально Homebrew работал, загружая программное обеспечение с upstream и собирая его на том же компьютере, где и производится установка. При сборке он следует инструкциям, указанным в формулах (formulæ), написанных на языке программирования Ruby (см. терминологию). Получив огромную популярность, Homebrew обзавёлся двумя важными возможностями. Во‑первых, он стал управлять дистрибутивами приложений macOS от разных поставщиков, таких как Sublime Text или Firefox. Эта возможность называется casks. Во‑вторых, он начал скачивать готовые пакеты уже собранного программного обеспечения. Эта возможность называется «бутылки» (bottles). Благодаря бутылкам не нужно компилировать программы и Homebrew достаточно скачать готовые пакеты под целевую систему. Однако эти пакеты надо где‑то хранить и раздавать. Как именно это работает для Homebrew? Рассмотрим пример SQLite, встраиваемой реляционной базы данных. Если мы посмотрим на соответствующую формулу Homebrew, sqlite.rb, то заметим инструкции по сборке в методе install и несколько шестнадцатеричных идентификаторов в блоке bottle. Homebrew использует эти инструкции для сборки и загружает бутылки в Интернет, чтобы затем их скачать и избежать компиляции на вашем компьютере. Если запустить команду brew install sqlite в любой системе, для которой доступна бутылка, Homebrew загрузит её и установит в систему. За последний месяц Homebrew раздал более 52 миллионов пакетов. Это число может быть выше, поскольку некоторые пользователи отключают аналитику. Даже если каждая бутылка занимает один мегабайт места, Homebrew должен был раздать более 50 ТиБ трафика в месяц. Это запретительно дорого почти на всех популярных облачных хранилищах. Homebrew — некоммерческий проект, принимающий пожертвования от спонсоров. Маловероятно, что даже очень щедрые пожертвования покроют ежемесячный счет на тысячи долларов США для таких сервисов, как Amazon S3, при таком объёме трафика. К счастью, команде Homebrew удалось найти хостинг. Первоначально они использовали недавно закрытую платформу Bintray. Позже Homebrew получил возможность размещения бутылок в GitHub Releases. Это довольно распространенная практика, используемая во многих открытых проектах, таких как Gensim (см., например, репозиторий gensim‑data). К сожалению, в этом случае нет стандартного способа указания метаданных и нет тривиального способа различить, под какую систему собрана одна и та же версия пакета. Недавно они перешли на GitHub Packages — те самые GitHub Packages, которые используются для хранения артефактов Maven и Docker‑образов. Реестр контейнеров хорошо подходит для хранения файлов разного размера, версий и свойств. GitHub же щедро предлагает неограниченный трафик для открытых проектов. Итак, когда вы открываете бутылку в Homebrew, вы скачиваете файлы из GitHub Packages, также известного как GitHub Container Registry. Но как именно Homebrew понимает, какие файлы загружать? Блок bottle в формуле содержит идентификаторы SHA-256, также известные как дайджесты архивов для конкретной платформы (см. снова sqlite.rb в качестве примера). На момент написания последней версией SQLite в Homebrew была 3.40.1. Поскольку GitHub Packages — это такой же реестр контейнеров, как Docker Hub и многие другие, и следует одним и тем же спецификациям, можно вручную собрать ссылку для загрузки файла, поскольку мы знаем имя образа (homebrew/core/sqlite) и его версию (3.40.1). Таким образом, бутылки находятся по адресу ghcr.io/homebrew/core/sqlite:3.40.1. Например, бинарники для x86_64 Linux имеют дайджест 8d1bae…85bb06. Для скачивания файла нам не хватает только токена аутентификации для реестра. Значение этого токена по умолчанию указано в Homebrew как QQ==. Однако мы можем запросить собственный токен с помощью одного простого запроса. Независимо от того, как мы получили токен, мы можем теперь скачать SQLite 3.40.1 для Linux (x86_64) в виде большого двоичного объекта (blob).  Не забудьте включить параметр --location в cURL (-L), чтобы следовать HTTP‑перенаправлениям при загрузке файла; мой текущий пример просто извлекает заголовки файлов (-I). Таким образом, мы можем достаточно легко вручную скачивать файлы из реестров контейнеров, будь то пакеты Homebrew или же обычные образы контейнеров. Мы могли бы остановиться на скачивании файлов по уже известным дайджестам в формулах Homebrew, но давайте разберемся, откуда взялись все эти идентификаторы. Итак, нам известен идентификатор образа, ghcr.io/homebrew/core/sqlite:3.40.1, поэтому воспользуемся спецификациями образа Open Container Initiative (OCI), чтобы самостоятельно восстановить их. Сущность верхнего уровня — это индекс образа (image index), который содержит информацию о вариантах операционной системы в формате JSON вместе с некоторыми другими метаданными. Давайте посмотрим на него.  Индекс ссылается на несколько манифестов образов (image manifest). Каждый манифест соответствует определённой платформе, определяемой архитектурой процессора, операционной системой и её версией. Поскольку все метаданные машиночитаемы (и иногда человекочитаемы), мы можем легко заметить две вещи. Во‑первых, в аннотациях есть поле sh.brew.bottle.digest, которое содержит тот же дайджест SHA-256, что и в формуле Homebrew. Но он был помещен туда намеренно в процессе сборки. Во‑вторых, мы не видим здесь никаких файлов, а дайджест манифеста для Linux (x86_64) другой: ff58c2…8c22da. Теперь нам нужно получить манифест нужного нам образа.  Образ содержит список слоёв. Каждый слой хранится и скачивается в виде отдельного файла. В нашем случае образ имеет только один слой с заголовком sqlite--3.40.1.x86_64_linux.bottle.tar.gz и его дайджест полностью совпадает с указанным в формуле! Итак, нам удалось восстановить ту же ссылку, которую мы видели несколькими абзацами выше. Это означает, что теперь мы можем опрашивать реестр контейнеров, скачивать файлы и не полагаться на проставленные ссылки. В образовательных целях мы использовали cURL, но это не самый надёжный способ, потому что мы не охватываем всю спецификацию и никак не обрабатываем возможные ошибки. Поскольку реестры контейнеров постепенно становятся в хранилищами общего назначения, организация Cloud Native Computing Foundation (CNCF) профинансировала проект OCI Registry As Storage (ORAS). Он позволяет скачивать и загружать образы и их метаданные так, как мы это делали с cURL, но с поддержкой со стороны CNCF и, надеюсь, с лучшей обработкой ошибок. ORAS реализован на языке программирования Go. Мы можем заменить наши вызовы cURL  для опроса манифеста и получить точно такой же JSON-ответ. Отдельная команда ORAS позволяет скачать все образы в текущий каталог. При помощи команды oras push можно загрузить данные с компьютера в образ контейнера, но наш токен должен иметь соответствующие разрешения для реестра контейнеров (это не очень сложно, см. документацию). Реестры контейнеров — популярный способ распространения больших файлов, использующий хорошо поддерживаемую Интернет‑инфраструктуру. Вы можете хранить там больше, чем просто программное обеспечение: файлы с параметрами моделей машинного обучения, обучающие наборы данных, и многое другое.  Уверенный пользователь ПК