Переезжаем на Debian buster на сервере

debianeach

Опубликован:  2019-07-02T12:31:02.145745Z

Всё течёт, всё меняется, совсем не так давно Дебианыч обновлял свой десктоп на Debian buster, дело было в феврале. Как и ожидалось, этот период использования тестового выпуска Debian на десктопе прошёл вполне благополучно и плодотворно, никаких более или менее серьёзных каверз и осложнений не случилось, и десктопом Debian buster я доволен и удовлетворён - дарит много радости изо дня в день.

Настал июль, команда разработчиков Debian анонсировала запланированную дату очередного релиза - 6 июля. Пришло время переводить на buster и web-сервер auriz.ru. На всё мероприятие с учётом соответствующей подготовки web-приложения и тестовых деплойментов на локальную виртуальную машину у меня ушла вся последняя неделя, включая выходные. Краткий, слегка сумбурный отчёт о возникших трудностях и их решении предлагаю вашему вниманию в этом обзоре.

Скажу пару слов о самом сервере... Проект auriz.ru развёрнут на KVM-VDS-сервере одного из популярных Российских хостинг-провайдеров. Виртуальная машина сервера имеет 512 MiB RAM и одно ядро процессора, всё это великолепие обеспечено 10 ГиБ дискового пространства на базе HDD. Сервер не очень мощный и испытывает дефицит оперативной памяти, но на текущем этапе развития проект довольствуется тем, что есть, а то, что есть в распоряжении вполне справляется со своими задачами и весьма невысокой посещаемостью. В программной части сервера ещё вчера работал Python-3.5.3 в сочетании с PostgreSQL и Redis на пакетной базе Debian stretch. В целом сервер работал без сбоев.

Перевод сервера на Debian buster потребовал некоторой доработки web-приложения. Полугодовой продакшн выявил небольшую утечку памяти на одном из url-адресов приложения, которую мне, честно говоря, лень было отлавливать и отлаживать. Основное опасение при переезде на buster было связано именно с недостатком оперативной памяти, поэтому предварительно я выяснил причину утечки с целью устранить её при переезде. Было решено сохранить git-репозиторий версии приложения stretch и начать новый проект на базе существующего в новом git-репозитории. Под это дело я рискнул и обновил версии всех используемых сторонних библиотек и серверной и клиентской частей приложения, хочется идти в ногу со временем.

Предварительный тестовый деплоймент web-приложения был осуществлён на виртуальную машину VirtualBox c использованием существующей базы данных auriz.ru, сохранённой в текстовый файл с помощью pg_dump. Этот деплоймент прошёл довольно успешно и не выявил вообще никаких проблем, приложение было протестировано с разным объёмом RAM виртуальной машины, процесс развёртывания полностью повторял аналогичный процесс на пакетной базе Debian stretch. Воодушевлённый этим сиюминутным успехом я отправился на VDS, и получил некоторые существенные, но вполне решаемые траблы.

Поскольку в мои цели входило тестирование абгрейда существующей операционной системы, сначала я просто подключил ветку buster в /etc/apt/sources.list и сделал apt update && apt full-upgrade. После первой перезагрузки сервера меня ждала одна очень серьёзная неприятность. Странным образом при старте сервера был допущен fail и сброс по таймауту сервиса ssh, в результате чего первая перезагрузка сервера заняла порядка 6 минут, хотя обычно ему было достаточно одной минуты.

Второй выявленной проблемой был странный многократный сбой при старте сервера Gunicorn с последующим восстановлением рабочего процесса. При этом после окончательной загрузки сервер всё-таки работал удовлетворительно. Поскольку абгрейд делался на существующей пакетной базе, система кроме всего прочего ещё и сохранила кластер PostgreSQL9.6. Расстроившись, я принял решение провести чистую установку операционной системы Debian buster с форматированием жесткого диска и восстановлением базы данных в кластере PostgreSQL11.

Операционная система была установлена из стандартного образа Debian-netinst. К сожалению, проблема с сервисами ssh и Gunicorn повторилась. Кроме этого при создании новой базы данных PostgreSQL при помощи createdb почему-то пришлось явно задавать кодировку и локаль текущей базы данных, с этим справился, и только после этого получилось без ошибок восстановить данные из бэкапа. Подозреваю, что виной тому неправильно настроенная системная локаль, возможно при установке операционной системы я где-то зевнул...

Недолгое гугление проблемы с ssh-сервером привело меня на багтрекер Debian - ошибка давно известна и хорошо описана, воспроизводится не на всех серверах и на текущий момент не имеет внятного решения. Устранить неполадку получилось после внимательного чтения всей ветки установкой пакета haveged в соответствии с рекомендациями разработчиков. С этого момента сервер начал стартовать в штатном режиме, на загрузку сервера уходит примерно минута-полторы. Проблема с Gunicorn отвалилась сама собой.

Таким образом я констатирую факт, переезд на Debian buster на сервере состоялся. Все трудности были героически преодолены и в копилку добавился бесценный опыт. Я получил возможность продолжить разработку приложения на пакетной базе Debian buster. Ещё некоторое время я пристально понаблюдаю за работой сервера и, возможно, в ближайшей перспективе перейду на новый тарифный план, чтобы исключить влияние недостатка оперативной памяти на работу сервиса. Полное описание всего процесса деплоймента сделаю чуть позже. А пока наслаждаюсь новой операционной системой и жду долгожданного релиза.

Комментарии: