Как посоветуете выполнять развёртывание web сервера Rust на VDS?

Question

[Сергей Ы]

Добрый вечер, добрался до деплоя веб приложения на Расте(у меня на salvo.rs но смысл думаю одинаков для всех) на VDS, гугление результатов не принесло! Чтобы проверить работоспособность конечно я воспользовался scp и закинул бинарник из target/release/ и папку со статикой и запустил через systemd все это дело! НО это неудобно и не правильно, тем более хотелось бы получить более менее рабочую схему деплоя, сразу скажу я в раст пришёл после разработки на скриптовых языках, там весь исходный код летит на ВДС ну или контейнер, здесь же необходимо обеспечить доставку только исполняемых файлов, причём интересно и с Докером и без него, с Докером пока единственная мысль это собирать образ локально и его docker push, просьба без критики, благодарен любым советам

Answer 1

[Владлен Хеллсайт]

Абсолютно так же как и остальными Node.JS, Go и другими языками в современном мире пакуется в контейнер и деплоится в прод. Есть несколько готовых вариантов, но все они будут придерживаться docker и docker compose:

- ручное: Клонируем репозиторий, билдим на этом сервере docker compose build && docker compose up -d.
- ручное: Локально билдим докер образ и пушим в регистр докера, на самой машине так же docker compose pull && docker compose up -d но уже только с получением образа из регистра докера в docker compose.
- полу-автоматически: Пишем .sh скрипт который на git хуки или руками будет делать действия что и в одном из предыдущих вариантов, но без Workflow.
- автоматически: Используем GitLab/Github Workflow или любой другой, на каждый релиз/коммит/PR запускаем Workflow с билдом, дальше пушит полученный контейнер в регистр, затем последним этапом будет подключение по SSH к серверу и применения условного

cd /path/to && docker compose pull && docker compose up -d

Я привёл самые простые варианты. Ещё есть варианты с k8s, ansible и другими вещами, но это не ваш случай судя по всему.

Comments

[Сергей Ы]

Да, спасибо , Все способы которые Вы написали я использую для приложений на джанге, Здесь всё понятно! Еще раз спасибо, если кто то на практике другие подходы применяет, просьба написать!

[Василий Банников]

1. Сейчас уже не docker-compose, а docker compose
2. Нафига деплой на гит-хуки вешать?
3. А зачем сюда docker compose вообще вкорячивать, если у нас всего одно приложение и статика?

[Владлен Хеллсайт]

Василий Банников,
1. Сила привычки (поправил)
2. Потому что такие варианты действительно используются (Workflow по сути это просто подписка на гит хуки, но от вендора)
3. Добавить Nginx и может ещё Let's Encrypt? Сомневаюсь что приложению не нужны какие-то внешние сервисы по типу Redis, Postgres или ещё чего-то.

[Сергей Ы]

Василий Банников, с докером я согласен, приложений может быть и не одно + БД, но если оно одно то докер правда лишний

[Василий Банников]

Владлен Хеллсайт,
2. Но локально я бы деплой на хуки побоялся делать. Да и в облаке предпочитаю деплоить по кнопке.
3. Это вполне и без докера делается) А базы данных что-то страшно в докер пихать.

[Владлен Хеллсайт]

Василий Банников,
2. Я только примеры привёл, а дальше всё зависит от конкретного выбора. Я предпочитаю в целом автоматически деплой основанный на PR в master. А если что не так, легко откатиться в k8s на предыдущую версию.
3. На страшные вещи есть бэкапы, а если проект действительно большой, сомневаюсь что для него не был бы выделен отдельный сервер для базы на bare metal.

[Василий Банников]

Владлен Хеллсайт, а в большом проекте могут базы и при помощи соответствующего оператора в кубере разворачивать)

[Владлен Хеллсайт]

Василий Банников, можно и так (по сути ничем не отличается от того что было в докере :D), но базы любят когда они на голом железе. Автоматизировать stateful application в оркестраторе — это боль.

[Василий Банников]

Владлен Хеллсайт, не, оператор вполне может быть достаточно сложным) https://cloudnative-pg.io/
Уж точно гораздо сложнее, чем "как в докере")

Answer 2

[Василий Банников]

НО это неудобно и не правильно

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

с Докером пока единственная мысль это собирать образ локально и его docker push

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

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

Как ты правильно сказал - отправлять тут нужно только исполняемые файлы. А как же ты тогда раньше скриптовые языки запускал? Без systemd?

Comments

[Сергей Ы]

не хочется усложнять, это в точку! Без systemd никак или он или докер! Вот как Вы написали это 2 самых живых пока для меня версий! Решил опробовать ради интереса Отечественного зверя https://gitflic.ru/, Вот незадача не могу найти Реестр Контейнеров в нём)))

[Василий Банников]

Сергей Ы, не вижу ни одной причины трогать этого зверя, когда есть куча разных self-hosted платформ)
Тот же гитлаб например, а для контейнеров можно nexus поднять

[Сергей Ы]

Василий Банников, интересно было )) Это была единственная причина и она закончилась