Composer над пакетным менеджером

конкретный пример приведи, а то вышеописанное - это собственно цель существлвания пакетных менеджеров.

Я решал это административными методами. Если какой-то штуке нужны странные зависимости, начальству говорится, что штука не нужна, и ищутся альтернативы.

Чтобы поставить docker-engine 1.23.2, надо пойти на гитхаб, найти ссыль (хорошо, если она вообще еще есть), качнуть пакет, распаковать в правильные места, раздать права. Мне было бы куда спокойнее, если бы я мог просто вбить install docker-engine@1.23.2.

Собственно, я аналогию с композером не спроста привел.

ясно-понятно. выражайся яснее, пакетный менеджер здесь совершенно не при чем.

sudo apt-get install docker-engine=1.23.2

если, конечно такой пакет с такой версией есть в твоём репозитории

Откуда взялось требование использовать именно Docker, а не (намного более неизменный) LXC? Почему именно версию 1.23.2, а не дистрибутивную?

P.S. на текущем месте работы, одним из первых изменений, которое я провел, было вынедрение используемого не по назначению Docker'а.

Ну на чем-то надо бы пример привести? Когда весь деплоер на 2/3 состоит из добавления репозиториев и apt update, невольно задумываешься о смысле жизни

Благодарю за ценное замечание. Если у вас будут еще какие-либо сравнимые по ценности ремарки - в любое время дня и ночи с замиранием сердца буду ждать вас.

Вот пусть тот, кто такое допустил в production, и задумывается о смысле жизни. Не твое дело заметать за ним такие какашки. Отправляй продукт на доработку, чтобы или все свое носил с собой в сборочном (а не деплойном) скрипте, или не был таким придирчивым к версиям. Имеется целевой дистрибутив, и версий софта, которых в нем нет, для тебя и для твоей компании не существует.

Ну и вдогонку. Необходимость добавлять кучу сторонних репозиториев на предмет обновлений - признак или неправильного выбора целевого дистрибутива, или какого-то расхождения между окружением разработки и production. Может вам нужна Ubuntu не-LTS, или вообще Arch?

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

Что до докера, то открыл его для себя и счастлив. Теперь можно ограничиться совокуплением с одним пакетом при работе с LAMPP. Про LXC вообще впервые слышу, из всех динамиков звучит docker. Расскажите, что за зверь в сравнении с докером?

или какого-то расхождения между окружением разработки и production >>

Да можно вообще собрать свою ось и тягать везде ее. Но для установки лампа как-то ломает так изголяться.

Всё таки не смог осилить. А какой функционал даёт пакетный менеджер дистрибутива, если не этот? Ну кроме случая когда, как уже заметили, нужная версия будет отсутствовать в репах. Но это реально не проблема менеджера. Или суть в создании виртуальных окружений, как это может тот же npm? Дык для этого докер и придумали как раз. Я НЕ ПОНИМАТ! Т_Т

LXC - это более древний и примитивный, по сравнению с Docker'ом, контейнерный движок. Рекомендуемая область применения - замена виртуалок, в противоположность Docker'овской идеологии «контейнеров для приложений». Т.е. извне все выглядит, как обычный chroot, а изнутри - как обычная система (с systemd и всем тем, что он там запустит) с сетевой картой eth0 и IP-адресом. Присутствует во многих дистрибутивах, есть не просит, оверхеда от overlayfs нет. Контейнеры создаются через lxc-create, клонируются через lxc-copy, можно еще бекапить в tar.gz. Конфиги обычные текстовые, типа такого:

lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.arch = x86_64
lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = lxcbr0
lxc.net.0.hwaddr = 00:16:3e:55:e4:c4
lxc.cgroup.memory.limit_in_bytes = 1024M
lxc.start.auto = 1
lxc.log.level = 4
lxc.rootfs.path = /var/lib/lxc/etherpad/rootfs
lxc.uts.name = etherpad

Но для установки лампа как-то ломает так изголяться.

А чем не устраивает версия LAMP'а в дистрибутиве? (вопрос не к тебе, а к тем, кто требует новую версию)

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

Решение - Arch в production (важно: без фиксации версий, чтобы когда-нибудь сломалось). Цель - отучить разработчиков от гонки за версиями зависимостей. По опыту, оно живет примерно год, после чего разработчики (если это внутренние разработчики) перестают гнаться за версиями зависимостей, и можно передеплоить софт на Ubuntu не-LTS без внешних репозиториев.

А какие преимущества дает Arch? Я сейчас деплоюсь просто с хостерских дефолтных дистров Ubuntu 16.04 и пр.

Конечная цель - иметь надежное развертывание проекта на вышеназванной оси с учетом смены хостеров. Проекты небольшие и скорее обособленные

Arch в production

звучит уже больно

А какие преимущества дает Arch?

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

Arch на хосте использовать не надо. Достаточно в контейнере (работает, при условии использования HWE-ядра на Ubuntu на хосте), и пробросить нужные порты через iptables. Напоминаю: цель - затроллить тех, кто гоняется за версиями зависимостей.

Конечная цель - иметь надежное развертывание проекта на вышеназванной оси с учетом смены хостеров.

Решается элементарно через LXC.

apt install lxc iptables-persistent
wget https://.../my-container.tar.gz
cd /var/lib/lxc
tar xf /root/my-container.tar.gz
iptables ... # на предмет проброса портов
/etc/init.d/iptables save
lxc-start -n my-container

Ну или можно для проброса портов использовать скрипт, упоминаемый в lxc.net.0.script.{up,down}. Пример тут: https://github.com/patrakov/lxc-expose-port, но мы от этого отказались, так как на хосте все равно есть reverse proxy для разруливания запросов по контейнерам.

Еще кроме LXC можно посмотреть на OSTree. У нас его пытаются использовать для развертывания (пока не в production) региональных сайтов на всяких облачных VPS. Мое личное субъективное мнение - требует много работы (существенно больше, чем LXC) на этапе сборки репозитория, т.к. Ubuntu выпилило интеграцию с GRUB. Но зато потом получается деплой на чем угодно (операционная система заменяется полностью) одной командой.