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

как сказать production по-русски?

передать в exploitation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прод

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

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

Всё распихать по докер контейнерам.

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

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

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

guix, nixos

или по подманконтейнерам
https://www.youtube.com/watch?v=t4PEoHAvf1A

Работает – не трогай.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читал про Ansible,

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

Сам не пробовал, поэтому рекомендовать не буду, но вообще guix deploy как раз для того и придуман.

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

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

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

В общем тебе можно использовать докер/или другую систему «контейниризации» или виртуалку

Очень плохой совет.

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

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

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

Встречал определение «продуктивное окружение», но лично мне оно режет глаз.

Для твоего юзкейса ансибл идеален. Он делает именно так как ты хочешь - подключается к машине по SSH.

Встречал определение «продуктивное окружение», но лично мне оно режет глаз.

Промышленное оно. Но так тоже режет с непривычки.

Всё распихать по докер контейнерам.

Вот это еще обязательно сделать, да.

Работает – не трогай.

Не работает – ну и пусть.

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

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

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

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

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

я уповаю на то

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

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

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

нанять девопса

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

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

как сказать production по-русски Промышленная эксплуатация.

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

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

Убиться веником! 😁

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

Тебе что, Т.З. написать?

З.Ы. Накатить. Для начала.

Накатить.

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

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

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

как сказать production по-русски?

На живом / на живой.

Истину глаголешь, малятко. 😁

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

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

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

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

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

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

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

и уволить попик-стартера?!

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

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

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

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

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

Git + CI/CD + Ansible.

И запретить ручные правки напрямую на сервере.

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

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

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

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

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

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

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

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

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

эмодзи

руководитель-клоун порвался
найс

Jenkins же. Тем более что у вас там git-репозитории.

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

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

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

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

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

Вы упорно игнорируете возможность создания документации, скажите, вы что, devops?