Едно от нещата, които от известно количество години поддържам е автоматичен инсталатор за „Моята библиотека“.
Линкът води към публично git хранилище. В него се намира скрипт за автоматична инсталация уеб сървър, сървър за бази от данни, PHP интерпретатор и автоматизирано инсталиране на софтуера, който задвижва „Моята библиотека“, по-позната като chitanka.info.
Идеята е относително проста и изпълнението е тривиално. Насочено е към по-напредналите потребители на GNU/Linux и по-специално Debian и Ubuntu дистрибуциите. Единствено е необходимо потребителят да разполага с root достъп до сървър (за предпочитане виртуална машина) и да стартира скрипта chitanka.sh.
Той ще се погрижи за това да инсталира необходимите софтуерни компоненти, които споменах по-горе. Освен тях, ще инсталира софтуера, който задвижва читанка, ще свали актуално състояние на базата данни, както и съдържание на книгите.
Грубо казано, с малко повече късмет и добра свързаност, в рамките на няколко часа, скриптът ще направи нещо като огледало, което всеки може да си съхранява и използва както намери за добре.
Тези дни реших да актуализирам скрипта, за да е съвместим с актуалната версия на Ubuntu с дългъг период на поддръжка – 22.04. Уви, оказа се, че хората, които пишат софтуера за „Моята библиотека“ все още не са го нагодили да използва последните версии на PHP, което значи, че инсталаторът е непотребен за Ubuntu 22.04. Ще изчакам още известно време, за да наваксат, преди да pull request-на към тяхното хранилище.
Някои от нещата, които подобрих напоследък са свързани с може би малко безумен пропуск при uninstall процедурата – не се изтриваше базата данни. Според мен, за да е адекватен процесът по деинсталиране на всичко, което е необходимо за работата на „Моята библиотека“, трябва да се мине стъпка по стъпка и да се деинсталират допълнителните софтуери, да се премахне базата данни, потребителя към нея и…изобщо да се премахне каквото и да е, което е „донесено“ от инсталатора. : )
В общи линии в момента просто изчаквам. Докато изчаквах ми хрумна, че по-скоро освен инсталационен скрипт, трябва да добавя и някаква debug функционалност. Случвало ми се е да се свързват с мен и да ми казват, че нещо се е случило и „огледалото“, което прави инсталатора ми, просто е спряло да работи. Не е нужно да казвам, че за правилен анализ какво се е случило и защо нещо не работи, на мене ми е необходим контекст. Поради тази причина, мисля да напиша една debug функционалност, която да прави едно добро количество проверки на състоянието на операционната система, да събере определена информация за компонентите, от които зависи работата на „огледалото“, да ги подреди в подходящ за разчитане и разбиране формат и при евентуален проблем, да поискам тази информация.
Един от последните случаи беше, че потребител се е опитал да направи промяна на storage engine на таблиците в базата данни, това беше довело до счупване на целия MariaDB сървър и накрая просто помолих да ми даде root достъп, за да оправя, каквото мога. За съжаление не винаги е възможно да ми се преодстави такъв достъп.
Много пъти са ме питали защо предпочитам да е по този начин, а не по някой друг. Истината е, че всичко е въпрос на време. Този инсталационен скрипт трябва да работи и поддържа няколко различни версии на няколко различни дистрибуции. Всеки път, когато правя генерална промяна в някоя логика, трябва да имам пет броя виртуални машини, върху които да тествам дали инсталацията ще премине успешно. И тук не говорим за пет произволни виртуални машини, а възможно най-стерилни версии, по възможност, непосредствено след инсталация.
Този проблем опитах да го реша, като инсталирах пет (скоро шест) виртуални машини със съответните параметри и на всяка направих копие, като само смених IP адреса в конфигурацията. На лаптопа ми използвам Debian и qemu виртуализация, та относително цивилизовано се случват при мен нещата. Обаче всички тестове ми отнемат много време. Тук искам да отворя скоба, че контейнерите също са решение, но се натъкнах на кривини при контейнер с Ubuntu 18.04, като там нямаше неща, които са налични при инсталиране на сървърна версия върху виртуална машина.
Все едно ден, все още не смятам, че с Ansible (например) ще е по-добре. Да, ще е по-лесен за поддръжка инсталатор, обаче има други неща, като големия rsync на съдържанието, който може да доведе до стигането на непредвидени таймаути. Идеята за капсуловане с докер е добра, обаче докер със себе си носи негатива на това, че ще има сто мрежови интерфейса на машината, което е проблем, ако потребител иска да има „огледало“ на домашната машина.
Идеята за капсулована среда е добра, обаче има и своите негативи. Някой от хората около „Моята библиотека“ е направил готова за ползване виртуална машина. Не съм я разглеждал в чак толкова детайлно, но по форумите виждам проблеми, които, когато изникнат, ще са трудни за преборване и поддръжката се усложнява.
Една от много добрите идеи за капсулована версия на „Моята библиотека“, която ми се върти е т.нар. „жив диск“ (live CD). Логиката е семпла – потребител си сваля един .iso файл, записва го на флашка, рестартира компютъра и си има своя версия на библиотеката. Проблемите с това също ги има. Не толкова технически, колкото организационни. Нека приемем, че си харесам някакъв актуален Debian, настроя го, актуализирам го и го направя на жив диск. Това е чудесно, до момента, в който си дам сметка, че флашата, на която е записан, трябва да е много голяма, за да има съдържанието на библиотеката. Да речем, че това вече не е грандиозен казус, защото огромни и бързи флашки вече има на разумни цени. Да речем, че излизат по две актуализирани версии на година. Вариантът за жив диск означава, че човекът ще трябва да си рестартира компютъра всеки път, когато иска да зареди библиотеката. Това е бавен и изнервящ процес, защото живите дискове са чувствително по-бавни от истинска дистрибуция.
Вариант, който също мислих за относително удачен е да окомплектовам една готова за използване версия като просто използвам virtualbox. Там проблемите, за които се сещам също са колосално количество. Рано или късно хората ще искат да си обновят версиите и това ще доведе до момента, в който ще трябва да влязат в машината. Ако бих правил такава виртуална машина, то определено не искам да им давам root достъп. Обаче удачно ли е да има втори потребител, по някакъв начин jail-нат и той да стартира един update скрипт.
Ох…толкова много проблеми за нещо, което изглежда толкова простичко.
Та…ако някой изобщо чете това и е стигнал до тук, моля да ме извини за логореята. Липсата на списване на блог ми се е отразила по неприятен начин.
Та…ако на някой му хрумва идея как да се направи изолация на ниво приложение (по възможност без докер) и я сподели, ще съм безкрайно благодарен и ще го черпя нещо в най-якия бар на галактиката.
Leave a Reply