Пакетный ад сложных проектов с зависимостями

Многие администраторы критически относятся к современным нововведениям, наподобие контейнеризации и часто вздыхают: мол старый-добрый APT. Но жизнь всегда расставляет все на свои места.

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

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

Чтобы не быть голословными расскажем реальную историю с нашим старым сайтом, который более 16 лет просуществовал на движке Movable Type. Хотя это будет характерно для любого сложного приложения, которое живет отдельно от пакетной базы дистрибутива.

Movable Type – сложный движок, в своей работе он использует Perl и большое количество модулей, часть из которых ставится из пакетной базы дистрибутива, часть из CPAN. Единого рецепта нет, разработчики положили в комплект скрипт, который говорит, чего не хватает, а дальше ты сам.

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

Потом приходит черед PHP, на котором построена другая половина движка и начинаются все те же самые танцы с библиотеками, хотя тут уже немного попроще. Но все равно особенности были.

Потом еще недельку ловим ошибки сборки сайта, читаем логи и добираем недостающее, потому как скрипт проверял только базовые библиотеки, а установленные темы или плагины могли иметь «свое понимание о прекрасном».

Настроили, записали, забыли? Как бы не так. Теперь нам надо это все сопровождать и обновлять. Что представляет собой отдельное развлечение, с цыганами, балалайками и медведями.

Обновили движок – он хочет новые версии библиотек, которых или нет в пакетах или там не те версии или начинаются конфликты, и вы снова старательно подбираете «рецептуру» для новой версии.

Надо обновить хостовую ОС? Эта песня хороша, начинай сначала. Снова берем скрипт и начинаем собирать «солянку сборную, мясную». А дальше выясняется, что такого пакета в дистрибутиве больше нет и хорошо если мы найдем другой пакет, который предоставит нам эту или совместимую библиотеку и, если она с нашим движком заработает.

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

И даже имея на руках все нужные списки пакетов и «заклинания» поднять это все на чистой системе было задачей со звездочкой. Потому что либо чего-то не хватало, либо что-то не работало, либо работало – но не так. И понять, что именно это было и какой пакет, который «исторически» кочевал в старой системе CPAN и отвечал за нужный эффект было крайне сложно.

А настоящее развлечение началось, когда движок сменил владельца и те резко поменяли лицензионную политику, оставив версию с открытым исходным кодом без обновлений. А остаться сегодня без обновлений – это гарантированно оказаться взломанным, причем уже не «если», а «когда».

При том, что уязвимости бывают разные и взломать через них можно не только сам сайт, но систему целиком. В этом случае только долго и старательно латать, искать, вычищать – и все это руками.

В результате сайт последний год-полтора существовал в режиме «только чтение», потому что иначе сразу становился проходным двором для всех желающих.

Кроме того, отсутствие обновлений движка сделало невозможным обновление хостовой ОС, так как движок банально не поддерживал новые версии.

После чего, в очередной раз вынырнув из этой мешанины начинал с тоской и нежностью смотреть в сторону Docker.