Как в вашей компании обеспечивается установка пакетов и обслуживание репозиториев?

Question

[UlarSur]

Как в вашей конторе обеспечивается обновление хостов Linux в локальной сети где нет доступа в интернет ?!
Я слышал про Nexus, мы им даже пользуемся. Но оно какое - то корявое, не удается мне с ним совладать. Он выдает url для качки у себя в веб.морде, но он по дефолту его не поддерживает для качки из указанного remote storage, потому тебе все равно нужно поправить файл .repo правильно с этими $ символами, baseurl/ (бла-бла) чтобы он производил качку, но не понятно каким образом настроить этот шаблон учитывая что его нигде нет и сам Nexus его тоже не делает.
Столкнувшись с такими проблемами, мне теперь дико интересно как обеспечивается получения обновления в очень больших компаниях где установка пакетов и обновление является критический важным, скажем фин.тех структуры ?

Давайте рассмотрим пример на дистрибутиве CentOS который уже не поддерживается. Но очевидно у многих есть хосты у которых есть дистрибутивы CentOS на котором уже крутятся какие - то сервисы, как например их обновлять если миграция пока не предоставляется возможным. У меня была мысль сделать локальное хранилище для репозиториев из Cent-OS Vault. Там очень большая версионность, например для версии 6 есть 6.10, 6.7, 6.9. Если для каждой версии, я скачаю самую последнюю версию и раздам его через nginx? Подойдет ли он для обновления разных версии CentOS или для каждой версии придется скачивать разную версию чтобы его поддерживать ? Например для CentOS хостов на 6 версии, я скачаю 6.10. Для 7 версии, скачаю 7.9.2009/. Для 8 версии, скачаю 8.5.2111/. или нужно фулл репозитории делать ?

Answer 1

[shurshur]

Делаются локальные копии основных репозиториев (reposync, debmirror и другие подобные инструменты), это может касаться и самих дистрибов с пакетами, и всяких менеджеров пакетов для языков типа pip, maven, npm. Либо, как вариант, доступ к ним прописывается через прокси с хорошо контролируемым списком хостов, куда разрешено ходить. Отдельные приложения (вне репозиториев или собственные разработки или свои кастомные сборки) можно класть в свои репозитории либо иногда норм даже просто положить архивом на http, который скрипт раскатки (ansible?) скачает и положит куда надо. Например, именно так у нас по хостам расползается jdk всех нужных версий (в тех проектах, где до контейнеризации нужно ещё космическое количество рефакторинга провести).

В современном мире крупные компании с большим серверным парком нередко систему вообще не обновляют, а полностью перезаливают новый сервер и на него мигрируют. Кроме того, сейчас тренд всё запускать в контейнерах, в которых количество софта невелико, а в случае необходимости собирается новый образ и раскатывается в прод как и любое рядовое обновление.

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

Comments

[rPman]

В репозитарии хранится не самая последняя версия пакетов, а сразу куча для всей релизной ветки ОС, это верно как для deb так и для rpm дистрибутивов.

Как хранить только последние, а то место нужно под терабайт?

[shurshur]

rPman, если фильтровать по архитектурам и релизам - сильно уменьшится.

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

Что в репозиториях не последняя версия - это известное дело. Это так в любой репе. Даже в rolling-дистрибутивах сложно достичь настоящей актуальности - а ведь есть ещё вопрос стабильности и консистентности, который в релизах достигается именно через заморозку и массовое тестирование только выбранных сочетаний версий.

Когда нужно специфический софт определённой версии, его можно собрать отдельно, в виде пакетов, AppImage итд итп. В конце концов, контейнеры...

[rPman]

shurshur, охх! а разве репы docker контейнеров, pypi, composer, npmjs, crates для rust,.. snap и прочее прочее можно сделать offline?

[shurshur]

rPman, для pip у нас даже вроде делали. Но я не пользовался, штучные пакеты через wheel таскал.

Образа просто в локальный registry переливал, в том числе и не с докерхаба.

В общем и целом, если кому-то нужно - всегда сможет.

[fenrir]

rPman, Раз, два. Открываешь доступ не до интернета, а до внутреннего нексуса, в нем хранишь все артефакты. Для пользователей все работает как обычно.

[UlarSur]

fenrir, вы пользуетесь Nexus-ом ?

[fenrir]

UlarSur, да пользуемся, у нас закрытый контур без интернета. Но я разработчик, не DevOps.

Answer 2

[CityCat4]

как например их обновлять если миграция пока не предоставляется возможным

Никак. Зачем их обновлять? Работает - не трогай. У меня до сих пор пара EL6 пашет - все руки обновить не доходят.

Обычно в таких случаях собственную репу подымают. И заруливают туда все хосты за обновлениями. Один какой-то смотрит в тырнет и собирает пакеты, остальные с него обновляются.

Comments

[Alexey Dmitriev]

очень вредный ответ

[Ziptar]

Alexey Dmitriev, он вредный а случае форточек, а в случае линей, да ещё которые в инет не ходят - он формально вредный, но практически к негативным последствиям едва ли ведет

Answer 3

[Alexey Dmitriev]

Уменьшить версионность и стандартизировать ПО.
Развернуть прокси к публичным репозиториям или частные копии репозиториев и переписать пути к ним.