Задать вопрос

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

Как в вашей конторе обеспечивается обновление хостов 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/. или нужно фулл репозитории делать ?

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

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

Это вообще часть подхода, при котором инфраструктура имеет свой жизненный цикл, свои практики и инструменты, которые отделены от жизненного цикла конечных бизнес-приложений с их совсем другими методами раскатки, обновления, контроля работоспособности.
Ответ написан
CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER
как например их обновлять если миграция пока не предоставляется возможным

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

Обычно в таких случаях собственную репу подымают. И заруливают туда все хосты за обновлениями. Один какой-то смотрит в тырнет и собирает пакеты, остальные с него обновляются.
Ответ написан
SignFinder
@SignFinder
Wintel\Unix Engineer\DevOps
Уменьшить версионность и стандартизировать ПО.
Развернуть прокси к публичным репозиториям или частные копии репозиториев и переписать пути к ним.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы