Блог Андрея Смирнова (aptly)

aptly 0.8

Andrey — Sat, 04 Oct 2014 20:57:38 GMT

Новая версия aptly 0.8 была выпущена 3-го октября. Теперь все новости об aptly будут публиковаться в блоге: http://www.aptly.info/post/aptly-0-8/

aptly 0.7 - S3 publishing, complex queries

Andrey — Tue, 29 Jul 2014 17:22:04 GMT

aptly 0.7 has been released today. aptly is a Debian repository management tool, it allows to mirror remote repositories, create local package repositories, manage repositories snapshots and publish them back as Debian repository. aptly main idea is "owning your own repository": you can mix and match official repos, 3rd-party repositories, your own packages, creating your own stable/testing/whatever repositories, allowing reproducible package installations along with controlled upgrades. It is available for download as binary executables or from Debian repository:

deb http://repo.aptly.info/ squeeze main

When installing from repository, don't forget to import key used to sign the release:

$ gpg --keyserver keys.gnupg.net --recv-keys 2A194991
$ gpg -a --export 2A194991 | sudo apt-key add -

Aptly has new logo, soon I'm going to launch new website:

Most important new features are:

Publishing to Amazon S3

aptly can publish repositories directly to Amazon S3.

First, create new S3 bucket using AWS console. Let it be aptly-repo. Remember Amazon region you have used to create, I'll be using us-west-1 in this example. If you're going to have public repository, enable website hosting for that bucket.

Go to IAM page, create new user, save access key ID and secret access key and create bash script aws.creds.sh:

# Access Key ID:
# AKIAISHG7G3H8AWBCFG
# Secret Access Key:
# E7aujXChaMZwp3ghfk45+Zabd55

export AWS_ACCESS_KEY_ID="AKIAISHG7G3H8AWBCFG" AWS_SECRET_ACCESS_KEY="E7aujXChaMZwp3ghfk45+Zabd55"

In IAM console, attach new custom policy for that user:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1405592139000",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::aptly-repo/*", "arn:aws:s3:::aptly-repo"
      ]
    }
  ]
}

This user would have limited access only to the bucket you've created.

Now, configure aptly, edit configuration file ~/.aptly.conf and add key S3PublishEndpoints:

"S3PublishEndpoints": {
  "aptly-repo": {
    "region": "us-west-1",
    "bucket": "aptly-repo",
    "acl": "public-read"
  }
}

If you're going to have public repository, set acl to public-read, otherwise set acl to private. Now you're ready to do your first publish. For example, to publish snapshot my-snapshot to the mentioned bucket, run:

aptly publish snapshot my-snapshot s3:aptly-repo:

As with publishes to local filesystem, you can publish under prefix:

aptly publish snapshot my-snapshot s3:aptly-repo:debian/

All regular publish commands are supported: you can switch between snapshots (atomically), update published local repositories, drop published repos, etc. aptly would do its best to upload package files only once to package pool in S3.

In order to use published repository, for public repositories use regular HTTP protocol in /etc/apt/sources.list:

deb http://s3-us-west-1.amazonaws.com/aptly-repo wheezy main

For private repositories you would need special apt s3 transport, after installing transport you can use it like that:

deb s3://AWS_ACCESS_ID:[AWS_SECRET_KEY_IN_BRACKETS]@s3-us-west-1.amazonaws.com/aptly-repo wheezy main

Package Queries

Before 0.7, aptly supported only Debian dependency-like package queries. In version 0.7, complex queries were introduced. Query syntax matches reprepro query language, reference could be found in the docs. I'll give some examples.

Now you can filter mirrors to include only packages with limited priorities:

aptly mirror create -filter="Priority (required)" wheezy-required http://mirror.yandex.ru/debian/ wheezy main

Or download single packages and all its dependencies:

aptly mirror create -filter="nginx" -filter-with-deps wheezy-required http://mirror.yandex.ru/debian/ wheezy main

Pull packages with complex conditions:

aptly snapshot pull snapshot1 source snapshot2 '!Name (% *-dev), $Version (>= 3.5)'

Or remove packages based on query:

aptly repo remove local-repo 'Name (% http-*) | $Source (webserver)'

In the next version, package queries would be used to filter snapshots, search for packages in repos/snapshots and local repos, and do whole "world" package searching.

Other Features

aptly can now pull all matching packages with aptly snapshot pull command using flag -all-matches, e.g. one can pull subset of versions from 0.7 to 0.9:

aptly snapshot pull stable1 foo-snapsot stable2 'foo (>= 0.7), foo (<= 0.9)'

Download speed could be limited while mirroring using config option downloadSpeedLimit, so that aptly won't consume all bandwidth.

All Changes

Full ist of changes since 0.7:

direct publishing to Amazon S3 (#15)
support for new, powerful query language in many commands: aptly snapshot pull, aptly repo move, aptly repo copy, aptly repo import and aptly repo remove
bug fix: files from conflicting packages might override each other while publishing (#65)
partial mirrors: filter package lists when mirroring (#64)
new commands: mirrors, local repositories and snapshots can be renamed (#63)
new command: aptly mirror edit allows to change mirror filtering (#63)
download transfer rate could be limited either via configuration file parameter downloadSpeedLimit or with flag -download-limit for command aptly mirror update (#62)
new flag: -all-matches for aptly snapshot pull enables pulling of all matching packages (#70), thanks to Simon Aquino
when matching single package in aptly snapshot pull latest version would be pulled (#67), thanks to Simon Aquino
new flag: -sort for aptly snapshot list allows to change order of snapshots in the list (#73), thanks to Simon Aquino
bug fix: publish update fails on empty multi-component repo (#66)
bug fix: aptly snapshot pull might remove already pulled packages (#78)
bug fix: aptly package was missing bzip2 dependency (#84)
aptly binary packages are built with go1.3

Golang Meetup July 2014

Andrey — Fri, 25 Jul 2014 12:37:35 GMT

Вчера прошел отличный Golang Moscow Meetup в офисе Google. Было очень много участников, что не может не радовать. Интересный crash course Go от Дмитрия Вьюкова, "секретный" проект по автоматической генерации кода от Алексея Палажченко. Всем большое спасибо!

Выкладываю слайды своего доклада:

aptly 0.6

Andrey — Sun, 08 Jun 2014 20:57:38 GMT

Новая версия aptly 0.6 была выпущена 7-го июня. aptly можно скачать в виде исполняемых файлов или подключив Debian-репозиторий:

deb http://repo.aptly.info/ squeeze main

При установке из репозитория в первый раз, не забудьте проимпортировать ключ, которым подписан релиз:

$ gpg --keyserver keys.gnupg.net --recv-keys 2A194991
$ gpg -a --export 2A194991 | sudo apt-key add -

Вот самые важные новые возможности этой версии:

Публикация репозиториев из нескольких компонентов

Одной из основных идей aptly является список пакетов: snapshotы, зеркала и локальные репозитории - это списки пакетов (если быть более точным, списки ссылок на пакетов). Когда происходит операции слияния, перетаскивания, копирования или перемещения пакетов - пакеты перемещаются между списками. Компоненты - это способ разбить список пакетов на группы, обычно эти группы имеют смысл только для опубликованных репозиториев. В то же самое время сопоставление пакета и компонента не является универсальным: Debian группирует пакеты в компоненты main, contrib и non-free, Ubuntu использует другое разделение на компоненты, а сторонние репозитории используют компоненты для разделения пакетов для разных версий Debian (например, squeeze, wheezy и т.п.) или для обозначения стабильных и тестовый версий пакетов.

Чтобы не переусложнять aptly, я решил, что не стоит создавать отображение пакетов на компоненты и не разбивать списки пакетов на компоненты. Каждый список (snapshot, зеркало или локальный репозиторий) состоит из "одного компонента" (на самом деле в нем нет компонентов вообще). Во время публикация репозитория несколько таких списков могут быть опубликованы как отдельные компоненты.

По умолчанию при создании зеркала aptly объединяет все компоненты в единый список. Если мы хотим сохранить разделения, для каждого исходного комопонента необходимо создать зеркало:

aptly mirror create wheezy-main http://ftp.ru.debian.org/debian/ wheezy main
aptly mirror create wheezy-contrib http://ftp.ru.debian.org/debian/ wheezy main
aptly mirror create wheezy-non-free http://ftp.ru.debian.org/debian/ wheezy non-free

aptly mirror list -raw | xargs -n 1 aptly mirror update

Затем мы создадим snapshot для каждого зеркала:

aptly snapshot create wheezy-main-7.5 from mirror wheezy-main
aptly snapshot create wheezy-contrib-7.5 from mirror wheezy-contrib
aptly snapshot create wheezy-non-free-7.5 from mirror wheezy-non-free

И опубликуем все snapshotы в едином репозитории, сохраняя исходную структуру компонентов (мы публикуем distribution wheezy в префикс upstream):

aptly publish snapshot -component=main,contrib,non-free -distrubtion=wheezy wheezy-main-7.5 wheezy-contrib-7.5 wheezy-non-free-7.5  upstream

aptly достаточно умен, чтобы самостоятельно определить имена компонентов и название дистрибутива, так что можно опустить их имена (запятые необходимы, чтобы aptly знал количество компонентов):

aptly publish snapshot -component=,, wheezy-main-7.5 wheezy-contrib-7.5 wheezy-non-free-7.5 upstream

Конечно, мы могли выполнять все обычные операции, которые поддерживает aptly: объединение snapshotов, перетаскивание пакетов и т.п.

Обработка конфликтов пакетов

Пакет во вселенной пакетов Debian идентифицируется тройкой (architecture, name, version). Если у двух пакетов одинаковые (architecture, name, version), но разное содержимое, такую ситуацию называют конфликтом пакетов. Руководство Debian запрещение включение конфликтующих пакетов в репозитории, которые могут использоваться совместно на одной машине (такие репозитории, которые могут быть включены в один файл apt.sources). К сожалению, в действительности такие конфликты встречаются не так уж редко: один такой пакет существует в репозиториях squeeze + security updates, другая такая же ситуация в репозитории puppet, где собраны одни и те же версии пакетов для разных дистрибутивов Debian в одном репозитории и разных компонентах.

До версии 0.6 при обнаружении конфликта aptly останавливался и не позволял продолжать операцию. В новой версии aptly умеет обрабатывать такие конфликты, есть только одно ограничение: конфликт не должен произойти в рамках одного списка (в одном snapshot, одном зеркале или локальном репозитории). Но это ограничение вполне естественно, иначе конфликт может опубликован в одном репозитории, что точно недопустимо.

Это изменение незаметно для пользователей, обновившихся до версии 0.6: aptly в фоновом режиме по мере обновления зеркал или создания новых snapshot обновляет способ хранения ссылок на пакеты.

Публикация пустых репозиториев

Многие люди используют aptly для автоматизации каких-то процессов, в том числе и с использованием систем управления конфигурацией. Для таких сценариев использования удобно создать локальный репозиторий (пустой), сразу его опубликовать, чтобы создать точку для apt.sources, а потом добавлять пакеты и обновлять опубликованный репозиторий.

До версии 0.6 aptly не позволял публиковать пустые репозитории, теперь это ограничение снято. При публикации пустого репозитория необходимо сразу корректно задать список архитектур (обычно aptly автоматически определяет список архитектур по списку пакетов, в случае пустого списка это невозможно). После публикации изменить список архитектур уже неовзможно, для его изменения потребуется удалить опубликованный репозиторий и опубликовать заново.

Объединение snapshotов: новая стратегия

aptly поддерживает слияние snapshotов - это может быть полезно для объединения основного репозитория с обновлениями безопасности или со сторонним репозиторием. В версии 0.6 доступно три стратегии объединения:

из пакетов с одинаковой парой (architecture, name) остается тот, который принадлежит snapshotу, который расположен "правее" в командной строке (по умолчанию);
из пакетов с одинаковой парой (architecture, name) остается тот, версия которого больше (-latest);
все версии пакетов сохраняются (-no-remove, новое в 0.6).

Полный список изменений

Вот полный список изменений в версии 0.5:

support for multi-component published repositories (#36)
handling duplicate packages with different content gracefully (#60)
repositories published by aptly now can be consumed by debian-installer (#61)
new flag: -no-remove for aptly snapshot merge to merge snapshots with all package versions preserved (#57)
publishing of empty snapshots/repositories is possible (#55)
aptly repo add now exists with 1 if any of files failed to add (#53)
bug fix: Package: line comes first in package metadata (#49)
bug fix: when command parsing fails, aptly returns exit code 2 (#52)
bug fix: pulling more than 128 packates at once (#53)
bug fix: aptly graph may get confused with package pull requests (#58)

aptly 0.5

Andrey — Thu, 24 Apr 2014 20:12:18 GMT

Новая версия aptly 0.5 была выпущена сегодня. aptly можно скачать в виде исполняемых файлов или подключив Debian-репозиторий:

deb http://repo.aptly.info/ squeeze main

При установке из репозитория в первый раз, не забудьте проимпортировать ключ, которым подписан релиз:

$ gpg --keyserver keys.gnupg.net --recv-keys 2A194991
$ gpg -a --export 2A194991 | sudo apt-key add -

Вот самые важные новые возможности в этой версии:

Публикация локальных репозиториев

Есть два основных случая использования локальных репозиториев:

тестирование новых версий пакетов
предоставление стабильного способа распространения новых версий

Во втором случае лучше всего создать snapshot локального репозитория и опубликовать его. Однако когда активно тестируются новые версии, создание snapshot при каждом изменении выглядит не очень разумным. aptly начиная с версии 0.5 поддерживает публикацию локальных репозиториев напрямую. Более того, когда репозиторий обновляет, его опубликованное представление можно обновить в один шаг.

При создании локального репозитория можно указать параметры, которые будут использоваться по умолчанию при публикации (distribution and component):

aptly repo create -distribution=wheezy testing-wheezy
aptly repo add -remove-files testing-wheezy incoming/*.deb
aptly publish repo testing-wheezy
...
aptly repo add -remove-files testing-wheezy incoming/*.deb
aptly publish update wheezy

Читать далее… (3 минут чтения осталось)

aptly: система управления репозиториями пакетов (РИТ-2014)

Andrey — Mon, 14 Apr 2014 19:41:26 GMT

Еще одним докладом на РИТ был рассказ про aptly. Презентация не очень сильно отличалась от доклада на Devops Meetup, из существенного нового была только поддержка локальных репозиториев.

Было много вопросов про поддержку yum-репозиториев, надо будет обязательно добавить возможность работать с ними как с Debian репозиториями.

Слайды доклада:

Новая версия aptly 0.5 все еще задерживается, никак не могу выделить достаточное количество времени, чтобы закончить разработку. Но скоро уже все должно быть!

aptly 0.4

Andrey — Tue, 11 Mar 2014 12:14:03 GMT

Сегодня вышла версия aptly 0.4: теперь aptly поддерживает работу с локальными репозиториями пакетов. Теперь с помощью aptly можно управлять коллекцией собственных пакетов, публиковать их, создавать snapshotы, объединять их с upstream репозиториями. Скачивайте или собирайте из исходников, пишите багрепорты, обсуждайте в группе aptly-discuss, читайте меня (@smira) в Twitter, чтобы получить информацию о новых релизах.

К заметным нововведениям в версии 0.4 также можно отнести поддержку source пакетов, возможность удаления неиспользуемых файлов, очистка базы данных и оптимизация объема используемой памяти.

Полный список изменений:

поддержка локальных репозиториев пакетов
aptly поддерживает зеркалирование и публикацию source-пакетов в дополнение к бинарным пакетам
новая команда: aptly db cleanup убирает неиспользуемые файлы пакетов и записи в БД
пиковое использование памяти было уменьшено в три раза
новые параметры: -keyring и -secret-keyring в команде aptly snapshot publish
новый конфигурационный параметр: downloadSourcePackages включает зеркалирование source-пакетов
новый параметр: -with-sources в команде aptly mirror create
новые параметры: dependencyFollowSource и -dep-follow-source, позволяющие отслеживать``Source:`` зависимости
новый команды в группе aptly repo: add, copy, create, drop, import, list, move, remove and show
команда aptly snapshot create поддерживает создание snapshot локальных репозиториев
новый параметр `` -no-remove`` в команде aptly snapshot pull: не удалять другие версии пакетов при перетаскивании (сохранять старые версии)
команда aptly mirror create поддерживает сокращенные PPA url: ppa:user/project
новый конфигурационные параметры: ppaDistributorID и ppaCodename для указания правил обработки PPA url
пакеты в списках печатаюся с подчеркиваниями вместо дефисов, например, pkg_1.3-3_amd64 вместо pkg-1.3-3-amd64

С возможностью работы с локальными репозиториями, схема сущностей aptly и связей между ними теперь выглядит так:

Оптимизация использования памяти в aptly

Andrey — Wed, 05 Mar 2014 13:21:41 GMT

В следующей версии (0.4) aptly использование памяти в самых частых операциях сократится в три раза благодаря несложным оптимизациям. Т.к. aptly написана на Go, это будет короткая история об оптимизации использования памяти программами на Go.

Когда я начинал разрабатывать aptly, я подозревал, что использование памяти будет далеко не оптимальным, т.к. aptly "переваривает" большое количество метаданных пакетов (например, зеркало Debian репозитория может содержать информацию о 30 тыс. пакетов). Я не замечал, что aptly использует много памяти до того, как не начал тестировать на виртуалке с 512 Мб памяти. aptly работала крайне медленно из-за постоянного свопирования. Я такого никак не ожидал: почему используется столько памяти?

Для начала я применил тривиальные оптимизации:

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

Вместо того, чтобы создавать буфер каждый раз...

// Encode does msgpack encoding of Package
func (p *Package) Encode() []byte {
    var buf bytes.Buffer

    encoder := codec.NewEncoder(&buf, &codec.MsgpackHandle{})
    encoder.Encode(p)

    return buf.Bytes()
}

... можно использовать его повторно:

// Internal buffer reused by all Package.Encode operations
var encodeBuf bytes.Buffer

// Encode does msgpack encoding of Package, []byte should be copied, as buffer would
// be used for the next call to Encode
func (p *Package) Encode() []byte {
    encodeBuf.Reset()

    encoder := codec.NewEncoder(&encodeBuf, &codec.MsgpackHandle{})
    encoder.Encode(p)

    return encodeBuf.Bytes()
}

Во-вторых, необходимо начать измерять то, что мы пытаемся оптимизировать: использование памяти. С помощью поста в блоге CloudFlare это сделать совсем несложно. Вот что я обнаружил:

Читать далее… (1 минут чтения осталось)

aptly 0.3

Andrey — Mon, 10 Feb 2014 19:20:40 GMT

Сегодня вышла новая версия 0.3 aptly. Это первая версия, которую я рекомендую для широкого использования, скачивайте или собирайте из исходников, пишите багрепорты, обсуждайте в группе aptly-discuss, читайте меня (@smira) в Twitter, чтобы получить информацию о новых релизах.

Новые возможности:

с помощью команды aptly serve можно быстро раздать по HTTP все опубликованные репозитории, aptly подскажет строчки для apt sources;
при зеркалировании удаленных репозиториев aptly проверяет цифровую подпись и контрольные суммы загружаемых файлов, если в в вашей связке ключей GnuPG не хватает ключа для данного репозитория, aptly подскажет что делать;
поддерживается flat-формат Debian-репозиториев (такие создает, например, OBS);
теперь можно удалять зеркала (mirror) и слепки (snapshot);
aptly может визуализировать граф зависимостей между созданными зеркалами, слепками и опубликованными репозиториями;
для aptly есть bash completion, попробуйте, это очень удобно!
aptly теперь умеет создавать пустой слепок (snapshot);
можно указать расположение конфигурационного файла с помощью ключа -config.

Картинка для привлечения внимания (пример того, что может сделать aptly graph):

aptly 0.2, Встреча DevOps Moscow январь 2013

Andrey — Wed, 29 Jan 2014 08:24:00 GMT

Случилось два хороших события: вышла версия 0.2 aptly, и я представил aptly на январской встрече DevOps в Москве.

aptly - это система управления репозиториями пакетами Debian (в будущем и rpm-репозиториями), которая позволяет контролировать то, какие версии пакетов будут установлены, а также изменять версии пакетов контролируемым образом. Базовой концепцией aptly является snapshot - неизменяняемый срез репозитория пакетов, который обеспечивает повторяемость. Операции над срезами позволяют, например, перетащить новую версию nginx из backports или добавить к основному репозиторию пакет Percona MySQL Server из репозитория Percona.

К середине февраля должна выйти версия 0.3, в которой будут добавлены небольшие возможности, чтобы пользоваться aptly было удобнее.

Пару слов про DevOps Meetup: огранизовано все было отлично, пришло очень много народу, интересные доклады. Следите за следующими встречами! Видео моего доклада про aptly Яндекс уже выложил. Слайды доклада можно скачать в формате PDF или посмотреть в онлайне под катом.

Читать далее… (1 минут чтения осталось)