Vitaly

ЕСЛИ "из/от/с": %глагол% %предлог:"из/от/с"% [%откуда%] (добраться из Москвы, выезжаю из Тулы)
ИНАЧЕ: %существительное% %предлог% [%куда%] (Москвы в Санкт-Петербург, дорога до Витебского вокзала)

во-первых, действительно, вам нужно решить NER-задачу, то есть достать из строки названия. Такое умеет, например, библиотека Natasha (ссылка на гитхаб).
Потом, как вариант, сделать так: если перед объектом стоит "из" - это значит начальный пункт, если "в" - конечный пункт. Но это вторая задача, которая решается не ML, а с помощью подбора лингвистических правил, скорее.

"Каждый проект / сайт в отдельный контейнер" - в корне неверный подход. Контейнеризация - способ изоляции процессов, а не проектов. Т. е. на проекте у вас будет несколько контейнеров (один для ноды, один для реббита, один для постгреса и т. д.), и в основной системе вы будете видеть сразу всю эту кучу контейнеров со всех проектов. Поэтому, если Вы хотите изолировать друг от друга проекты, Ваш выбор - не контейнеры, а виртуалки на KVM (и вот там уже внутри виртуалок можно будет проект разбивать на контейнеры попроцессно). Так у вас будет нормальная изоляция проектов друг от друга, и проблемы в одном проекте будут по минимуму затрагивать другие.

ИМХО наиболее актуально - докер.
Банально - прост в настройке, есть уже собранные образы на любой вкус, минимальные накладные расходы (можно позволить себе меньше памяти и дешевле железо), лёгкий мониторинг и управление сервисами. Умеет изолировать сервисы, сети и ресурсы. Умеет поднимать упавшие сервисы. Умеет управлять кластерами. Есть множество удобных веб-морд для управления/мониторинга из любого места, где есть браузер.

По разбиению - рекомендую БД вынести в отдельный общий (глобальный) контейнер, т.к. это будет одна из самых тяжёлых по памяти частей. Несколько БД держать дорого, и имеет смысл, только если проекты несовместимы с общей БД, но такое редкость.
Часть проектов может работать только с mysql - тогда нужно держать два контейнера с БД: mysql и postgres
Понятно, что для каждого проекта нужен отдельный ограниченный пользователь в БД.
Такая организация не только экономит ресурсы, но и позволяет управлять всеми БД через одну веб-морду, а также позволит легко прикрутить бекапы сразу для всех проектов.

Также отдельно стоит вынести nginx, который будет принимать подключения, обеспечивать безопасность и маршрутизацию по контейнерам. Как минимум это нужно, чтобы собрать все общие настройки в одном месте, и для возможности разделять один внешний порт на множество проектов.
nginx из проектов можно заменить глобальным (nginx довольно гибкий, достаточно перенести настройки), а можно и не трогать - nginx довольно дешёвый по памяти.

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

Естественно все это нужно собирать под docker compose
И придерживаться правила: всё, что нужно проекту для работы, должно быть в одном docker compose файле (читай - каждый проект в своей папке)

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

Лучше разделить по стекам через KVM или другую нормальную виртуализацию.
Например LAMP в одну VM, почту в другую и т.д.

1. LXC/LXD возможны проблемы из-за кастрированности технологии
   
2. Docker вообще не про это
   

Virtuozzo Containers пока единственная более или менее полноценная среди контейнеров. Если делить на виртуальные машины.

Я так понял, что есть два компьютера, между которыми есть VPN-соединение. Т.е. у них есть IP-адреса от провайдеров; и IP-адреса от VPN-соединения.
И с одного - идёт обращение на второй.

В простейшем случае:

1. Если первый компьютер обращается к VPN-IP-адресу второго - то обращение идёт через VPN; источник = VPN-IP-адрес первого компьютера.
   
2. Если первый компьютер обращается к провайдерскому IP-адресу второго - то обращение идёт через Интернет; источник = провайдерский IP-адрес первого компьютера; это так потому. Это так потому, что иначе - IP-пакеты, порождаемые VPN, не дойдет до второго компьютера как положено.
   

Разъясните фразу "Захожу на сайт, работающий на сервере-2" - буду думать дальше.

Чтобы какие-то сервисы были доступны только с VPN - проще всего блокировать их порты (сами определяйте, какие) на физическом интерфейсе. Если неясно - спрашивайте.

Сам по себе vpn ничего не скрывает. Скрывает или nat, или proxy. Плюс через vpn вообще не может быть доступен ваш внешний адрес, поскольку для трафика внутри туннеля адрес источника это адрес туннельного интерфейса, а не адрес вашего интернет соединения.
Скорее всего трафик до нужных вам сервисов идёт не через туннель. Смотрите трассировку.

try:
    # do my automated tasks
except:
    pass
finally:
    driver.close()
    driver.quit()

Source©

Используй https://www.npmjs.com/package/rc-slider, классный пакет с большим суппортом и кастумизацией.

Вот пример на коленке https://codesandbox.io/s/late-grass-qlyin

Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:

git checkout master
git merge --squash dev

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

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

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

git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.

В свое время - еще до raspberry делали на via/atom. Потом повалили дешевые головы на андроиде и все забили.

Логово еще живых тут: www.pccar.ru/index.php?s=b6bcab38dc192353b0e2442c8...

У меня свой блок управления светом спаян и смонтирован из Arduino Nano, датчиков движения, блока реле, преобразователя UART -> RS485, БП на 12В, все на постоянку в сеть воткнуто, уже больше года работает, все на Али брал