Lorawan-stack: Предоставлять стандартные системные пакеты в качестве альтернативы Docker
Резюме:
Все основные дистрибутивы Linux используют менеджеры пакетов для контролируемой и безопасной установки программного обеспечения.
Это предложение заключается в том, что пакеты создаются в форматах RPM , deb и opkg в качестве отправной точки, а дополнительные форматы пакетов добавляются позднее.
Зачем нам это надо?
Многие корпоративные организации запрещают git подключаться к любым серверам, кроме их собственных, а также могут не разрешать команды wget .
Docker также часто недоступен в этих организациях, однако доступ к репозиториям пакетов является «известным количеством», и поэтому его легче продать командам безопасности, особенно потому, что пакеты, как правило, полностью подписаны как часть процесса создания.
Есть также ситуации, для которых Docker просто не подходит. Это может быть, например, когда системные интеграторы/поставщики управляемых услуг хотят выполнить масштабирование с помощью чего-либо AWS Auto Scaling Groups на основе инстансов, а не контейнеров, или для установки на «голое железо» в безопасных средах.
Установка с помощью инструментов управления конфигурацией, таких как Ansible, Chef или Puppet, также невероятно сложна, если у вас нет доступных пакетов.
Наконец, установка из репозитория git, а не из пакета, затруднена без компиляторов, что создает угрозу безопасности при установке компиляторов в производственных системах.
Что уже есть?
В настоящее время у нас есть выбор между двумя докер-контейнерами ( ttn-lw-stack и ttn-lw-cli ) или сборкой двоичных файлов с тем же именем из git.
Развертывание осуществляется либо через docker pull , либо через git clone , оба из которых могут не работать за корпоративными/образовательными брандмауэрами.
Чего не хватает?
Возможность установки через yum , apt или opkg
Как вы предлагаете это реализовать?
Это должно быть относительно легко реализовать с помощью GO Releaser , однако GO — это не тот язык, с которым я особенно знаком (пока!)
Окружающая обстановка:
Linux — на базе CentOS/RHEL, на базе Debian/Ubuntu, на базе OpenWRT
Что вы можете сделать сами и в чем вам нужна помощь?
Мне нужно подтверждение того, что это подходящий способ упаковки приложения go для развертывания, а затем помощь с реализацией от того, кто понимает GO!
proffalken
Все 10 Комментарий
Я начну с добавления пакетов в APT, AUR и https://github.com/nixos/nixpkgs , так как я уже знаком с их форматом. Другие будут добавлены позже.
Вклады, конечно, всегда приветствуются!
rvolosatovs
2 февр. 2019
@rvolosatovs , вы собираетесь использовать go-releaser или другой способ создания пакетов?
Я был бы рад поработать над RPM, если я знаю, что вы используете для их создания! :)
proffalken
3 февр. 2019
Мы сделаем и эту часть компакт-диска.
Также добавление brew в список желаний.
johanstokking
3 февр. 2019
Просто добавлю свою поддержку к этому. Я никогда раньше не использовал докер, и хотя я понимаю, что существует множество языков программирования, это был огромный скачок для того, кто никогда раньше этого не делал. Несмотря на то, что разработчики любят делать вещи из репозитория, это не очень удобно для конечных пользователей.
mrpackethead
11 февр. 2019
Спасибо за всю вашу работу над этим, я надеюсь найти время в ближайшие несколько дней, чтобы добавить поддержку RPM и протестировать ее.
proffalken
13 февр. 2019
@proffalken Мы создадим пакет RPM как часть CI — вы сможете найти его на нашей странице релизов, как только мы выпустим релиз. (К вашему сведению, github также поддерживает каналы Atom для выпусков: https://github.com/thethingsnetwork/lorawan-stack/releases.atom)
Я последовал вашему предложению использовать goreleaser.
Что касается самого пакета RPM - это (пока) просто https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L79 -L92
Я подозреваю, что расположение внешнего интерфейса, например, нестандартно для RPM-пакетов и, по сути, не является стандартным для стека (мы ожидаем, что оно будет в /srv/ttn-lorawan/public ).
Так что ваш вклад в то, как это должно быть сделано, был бы очень полезен.
Обратите внимание, что для brew , например, мы оборачиваем двоичный файл стека, чтобы установить связанную переменную среды так, чтобы она указывала на внешний интерфейс:
https://github.com/TheThingsNetwork/lorawan-stack/blob/b1183962c502e6b53191086c23567c546c2b8ec5/.goreleaser.yml#L116 -L119
Я уверен, что ожидаемое расположение этого в пакете RPM отличается, но, надеюсь, мы сможем использовать тот же подход.
rvolosatovs
14 февр. 2019
@rvolosatovs имеет для меня смысл.
Настройку env vars, вероятно, лучше всего выполнить в сервисном скрипте systemd, я постараюсь собрать его вместе, как только смогу.
Втыкать вещи в /srv/ttn-lorawan/public тоже вполне приемлемо :)
proffalken
15 февр. 2019
@rvolosatovs , можете ли вы обновить метки и/или оригинальный комментарий, чтобы указать, что нам больше не нужна помощь или помощь с конкретным дистрибутивом? До того, как члены сообщества начнут охотно внедрять это, пока большая часть этого находится в стадии разработки.
johanstokking
18 февр. 2019
Заблокирован из-за отсутствия релиза v3.0.0 .
Публиковать предварительные версии в репозитории не имеет смысла.
rvolosatovs
18 мар. 2019
Закрыт в связи с релизом. У нас есть поддержка Snappy и Brew, а также файлы deb и rpm.
johanstokking
9 апр. 2019
Смежные вопросы
kschiffer
·
10Комментарии
virtualguy
·
15Комментарии
neoaggelos
·
31Комментарии
johanstokking
·
16Комментарии
kschiffer
·
32Комментарии
Самый полезный комментарий
Мы сделаем и эту часть компакт-диска.
Также добавление
brewв список желаний.