LINUX.ORG.RU
ФорумAdmin

Развёртывание в суровый научный продакшн

 ,


0

4

(Ломоносовы наших дней, как сказать production по-русски?)

У нашей лаборатории есть сервер. Когда-то его брали, чтобы запустить на нём веб-интерфейс для научного кода, разработанного в нашей же исследовательской группе. Код написан в «лучших» традициях научного программирования, для работы требует FFTW и BLAS, а также базу данных MySQL со строго определённым содержимым. Веб-интерфейс сделан на Perl5, всё это более-менее хорошо работает.

Прошло время. Обстоятельства потребовали разместить на этом же сервере: NextCloud, ещё научный код (Python3, 1,3-гигабайтное виртуальное окружение), MediaWiki для другой исследовательской группы, а сейчас ещё и статический сайт для третьей исследовательской группы.

NextCloud из архива, как ни странно, есть не просит (но им почти не пользуются) и даже может сам себя обновлять без особых проблем. Научный код активно сопротивляется попыткам его опакетить и поэтому живёт прямо в системах контроля версий. (Было хуже. Когда мы начинали, научный код жил в виде папки на общем диске.) Он даже работает в двух экземплярах на разных поддоменах, один - для обкатки новых функций, другой - стабильная версия для всего мира. MediaWiki не простая, а семантическая, поэтому в дистрибутивную копию MW пришлось распаковать zip-архивы с расширениями. Коллегам со статическим сайтом нужен доступ по SFTP, чтобы сайт изредка редактировать. Всему этому нужны свои файлы конфигурации для nginx.

Как это всё разворачивать, чтобы ничего не забыть и не сойти с ума? Читал про Ansible, cdist, Chef, CFEngine, Puppet, но это скорее про организацию целой кучи машин; некоторые из них запускают специальный сервер обновления конфигурации. Для нашего одного VPS это из пушки по воробьям. Мне проще и безопаснее подключиться по SSH с аутентификацией по ключу, чем разбираться, как обезопасить ещё один сервер.

Сейчас всё сделано через пачку sh-скриптов общей длиной менее 500 строк кода, аккуратно написанных так, чтобы они были идемпотентными. Если что-то падает, безопасно исправить ошибку и перезапустить скрипт с самого начала. Чтобы убедиться, что скрипты работоспособны, почти все изменения в состояния сервера я сначала вношу в скрипт, а потом запускаю скрипт, чтобы их применить.

Но сложность скриптов только растёт, и там уже происходит очень много всего: пользователей создать, файлы распаковать, конфигурацию подложить, базу создать, права раздать, сертификаты получить. Как сделать систему, которую, если что, сможет поддерживать другой человек?

★★★★★

Как это всё разворачивать, чтобы ничего не забыть и не сойти с ума?

Чем баш скрипт не устраивает?
В общем тебе можно использовать докер/или другую систему «контейниризации» или виртуалку. Внутри там всё на скриптах будет, а снаружи ты просто даёшь пользователям такой «блоб», который они запускают и просто используют.
Ну ещё ты можешь настроить CI/CD чтобы при коммите в гит у тебя этот «блоб» перестраивался и доставлялся счастливым пользователям.

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 1)

Продуктовое, боевое окружение.

У меня отдельная виртуалка (или докер) в которой крутится только nginx. На нем соответсвенно реверс прокси до других сайтов, ssl терминация и basic auth если надо.

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

skyman ★★★★
()
Ответ на: комментарий от Bad_ptr

Сейчас всё сделано через пачку sh-скриптов общей длиной менее 500 строк кода

Мне проще и безопаснее подключиться по SSH с аутентификацией по ключу, чем разбираться, как обезопасить ещё один сервер.

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

ваше «проще и безопаснее» вылилось в 500 строк интересных баш конструкций

Для нашего одного VPS это из пушки по воробьям.

вы можете написать terraform манифест который поднимает две (и больше) виртуальные машины, различия будут только в доменах

science-prod - виртуалка с продом

science-staging (поднимается на изменение в репозитории, проверяется что все работает как ожидаемо, и виртуалка выключается)

в cloudinit этих виртуалок вам нужно добавить git deployment ключ для репозитория с конфиг менеджмент системой

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

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

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

и добавит новых

но если вы реальные научные работники, то это автоматически означает что кто-то из вас умеет писать на Scheme, тогда ставьте сразу виртуалку с guix и создавайте окружения для ПО

gagarin0
()
Последнее исправление: gagarin0 (всего исправлений: 2)

«Запускать в производство»

Рассмотрите контейнеризацию: каждый сервис каждой рабочей группы в отдельном ведре со своими зависимостями и конфигурацией!

Быстрее всего развернуть LXD, но есть решения куда ближе к традициям научного программирования, чтоб поработать побольше.

anonymous
()

Ломоносовы наших дней, как сказать production по-русски?

Прод

Но сложность скриптов только растёт, и там уже происходит очень много всего: пользователей создать, файлы распаковать, конфигурацию подложить, базу создать, права раздать, сертификаты получить

Я лично не вижу никакого другого варианта, кроме программирования. То есть скриптоты не избежать никак. Разве что сделать это через конфиги, чтобы сами скрипты пореже трогать.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от kaldeon

Я лично не вижу никакого другого варианта, кроме программирования

@ugoday с бабашкой перепишет 500 строк баша в 128 строк на бабашке

Разве что сделать это через конфиги

guix, nixos

gagarin0
()

Мимококодил и ни разу не админ, но брякну

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

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

Ибо есть куча всего, никак друг с другом не связанное, вот пусть и живёт каждый в своей песочнице и шарят ресурсы общего хоста.

Ну или не чруты, а что-то более нахлобученное, суть также самая.

LINUX-ORG-RU ★★★★★
()

Продакшын - дежурная система. Поставить на дежурство.

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

Irma ★★★
()

(Ломоносовы наших дней, как сказать production по-русски?)

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

для работы требует FFTW и BLAS,

apt-get install fftw3 fftw3-dev libblas-dev …

Python3, 1,3-гигабайтное виртуальное окружение

Anaconda, pip, заодно там и R может жить.

Как это всё разворачивать, чтобы ничего не забыть и не сойти с ума?

Примерный план:

  1. Создать git репозитарий
  2. Начать уже писать документацию, что, для чего и как поднято и положить в этот репозитарий.
  3. Все sh скрипты и конфиги положить в этот же репозитарий и ссылаться в документации на файлы из него. Все изменения в конфигах проводить через эту репу.

Изменения конфигов нечастые, установочный скрипт меньше 500 строк кода это ни о чем, поэтому такой способ оптимальный. В общем, не увидел ничего сурового: openBLAS, FFTW, LINPACK у каждой обезъяны стоит.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)

Ломоносовы наших дней, как сказать production по-русски?

Производство.

Читал про Ansible,

Сиё берите. Для того, чтоб начать вообще ничего не нужно почти. Один статичный inventory файл, указывающий на ваш сервер. Один Makefile (или аналог), для наиболее популярных вариантов запуска. А дальше то же самое, что и с bash-скриптами, только проще организованное.

ugoday ★★★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Вы всё правильно говорите, но:

а) нужно добавить ещё управление правилами сетевого фильтра, чтобы сервисы из разных chroot’ов друг с другом за 80-й порт не дрались.

б) вжух-вжух-вжух, мы только что реализовали недокументированную, глючную и тормозную вариацию на тему докера.

ugoday ★★★★★
()

Как это всё разворачивать, чтобы ничего не забыть и не сойти с ума?

Опиши подробнее что скрывается за словом «разворачивать». Я так понимаю у тебя уже есть сервер и на нём всё и так развёрнуто. Ты второй хочешь такой же? Или «разворачивать» = «обновлять»?

firkax ★★★★★
()

Если речь идёт о поддерживаемости, то нужно брать какую-то широко используемую систему оркестрации, чтобы организации было проще найти человека, который знаком с ней. Я бы смотрел в сторону ansible или docker. А скорее всего и то другое вместе. Конфиги для них хранить в гите.

То что вы описываете про существующие bash-скрипты весьма напоминает то как работает ansible в том смысле что анализируется текущее состояние системы и вносятся те правки, которые ещё не вносились.

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

cobold ★★★★★
()
Ответ на: комментарий от Bad_ptr

можно использовать докер

только надо иметь в виду, что идеология докера — один «процесс» на «контейнер», т.е. скорее всего нужно будет несколько «контейнеров» и потом докер-композе
(хотя можно и несколько процессов в одном докер контейнере запустить и даже систему инициализации(init) типа runit)

Bad_ptr ★★★★★
()
Ответ на: комментарий от ugoday

я уповаю на то

суровый научный продакшн

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

Из 500 строчек на баше, я думаю они уложатся в 120 на scheme, возможно даже меньше и в конце прослезятся и уйдут в запой

gagarin0
()

Сейчас всё сделано через пачку sh-скриптов общей длиной менее 500 строк кода

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

gagarin0
()
Ответ на: комментарий от LINUX-ORG-RU

отдельным чрутам

изобретаешь контейнеры они так примерно и появились, а так по теме lxc или докер контейнеры под это предназначены, тем более готовый sh скрипт (500 строк) есть, ресурсы оверхед минимальный

s-warus ★★★★
()
Ответ на: комментарий от sparkie

Накатить.

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

rupert ★★★★★
()
Последнее исправление: rupert (всего исправлений: 1)

Как сделать систему, которую, если что, сможет поддерживать другой человек?

Запихнуть все по контейнерам. Докер, lxc, proxmox выбирай, что удобнее или знаешь. Я в подобной ситуации перевел все на proxmox, так как есть миграция, централизованные бекапы и тд. Если нужны операционки древнее 16 убунты, то лучше запихнуть уже в виртуалки.

einhander ★★★★★
()

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

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

energetix_user ★★
()
Последнее исправление: energetix_user (всего исправлений: 1)

Но сложность скриптов только растёт

Вангану, что изначально не надо было пытаться запихнуть всё в один скрипт.

Как сделать систему, которую, если что, сможет поддерживать другой человек?

Переписать так, что бы «мог поддерживать другой человек».

anc ★★★★★
()

Я ансиблом, заведомо проверенные башскрипты, для внесения правок и обнов раскидываю в таком случае. Скрипт выполняется, пишет логи и логи ансисбл себе забирает. А ну и сами скрипты удаляю в конце плейбука. Сложность в том, что плейбуки кроном несколько недель выполняются ибо не все хочты бывают в онлайне, а сеть им по dhcp раздает контроллер домена. Статика только у серверов и единичных хостов.

teelledro
()
Последнее исправление: teelledro (всего исправлений: 1)

лаборатория — трудильня

Нулевое действие : переписать(али иметь когеррентно в двух проекциях) скриптоту на python3.14 ибо в отличии от баша есть типы

остальное вы ещё аппетита не нагуляли

ззы. - ну и очевидное -1 гитовать(контроль версий) изменения(не только продукта но и вот этого вот поддержания инфраструктуры) для рефлексии

qulinxao3 ★☆
()

Я бы это всё в docker-compose запихал. И переносить легко. Скопировал папку и всё, оно просто переедет и всегда будет работать. А что за лаба? Чем занимается? Может я даже просто так ща всё напишу, вроде как там не слишком сложно.

Pierre_Dolle
()

Как сделать систему, которую, если что, сможет поддерживать другой человек?

А точно нет проблемы XY? Ищется решение по оптимизации своей задачи, или решаются проблемы с контролем над процессом руководителя?..

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

ЗЫЖ Производство, а в научном контексте отдельного термина не могу припомнить, хотя оно должно быть в силу отсутсвия известных решений в научных целях. Нужно мемуары какие-нибудь почитать чтобы найти подходящее слово.
ЗЗЫЖ «Другой человек» это по нонешним !@#$ским меркантильным временам очень ответственное решение. Завтра может появиться другой руководитель, заявить о низкой личной эффективности не смотря на коллективный подход к делу, и повесить ярлык «переплаченный» с намеком на по собственному.

anonymous
()
Ответ на: комментарий от Pierre_Dolle

Запихать много ума не надо. Вот подумать головой над исходными данными задачи это уже сложнее.

Дано, лаборатория с единственным сервером под все и сразу. Те ни о каком оно просто переедет речи при данном поколении лаборантов не идёт. переносимость докера тут нафиг не нужна - переносить некуда.

Суть задачи: нужно чтобы при необходимости другой человек мог разобраться и поддерживать это. Докер же просто добавляет ещё один уровень абстракции скрывая исходный слой, в котором нужно разбираться те буквально усложняет процесс.

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

Джунам же простительно ляпнуть подобное не подумав, они ещё учатся, у них все впереди.

Obezyan
()
Ответ на: комментарий от Obezyan

Докер же просто добавляет ещё один уровень абстракции скрывая исходный слой, в котором нужно разбираться те буквально усложняет процесс

Наоборот же. Упрощает. Он добавляет унификацию и отсутствие надобности разбираться с внутрянкой и обвязкой самого приложения.

adn ★★★★
()
Ответ на: комментарий от Obezyan

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

adn ★★★★
()
Ответ на: комментарий от adn

Он добавляет унификацию и отсутствие надобности разбираться с внутрянкой и обвязкой самого приложения.

Вы предлагаете решение обратное исходной задаче. Суть в передачи информации о том как это работает внутри с возможностью дальнейшей доработки и сопровождения. Вы же предлагаете отгородиться стеной, и замести все под ковер. В таком режиме, не меняя конфиги, оно и без докер сейчас работает. А если придётся менять, то новому человеку все равно понадобится разобраться как работает внутри + разобраться с докером.

Obezyan
()