Comments 42
Все готово, теперь можно запускать проект в работу.
и тут начинается самое "веселое", потому что в статье ни слова про права доступа...
Хорошее уточнение, да, действительно, этот момент опущен. Фокус сделал именно на том, как выполнить базовый деплой проекта и установить зависимости без прямого доступа в интернет.
нет доступа в глобальный интернет;
Значит должен быть бастион или outbound proxy с контролем (full log with SSL offload или whitelist)
pc или vm c доступом в интернет
Если прокси нет - поднимите сами на этой VM и всё.
Это штатный enterprise подход и нет необходимости приседать каждый раз - достаточно указать системный прокси.
Обычно ставят Palo Alto, ну или squid по бедности. Плюс SEIM.
В чем суть статьи? Не понял ни смысла ни инструкции.
Как файлы перенести с сервера на сервер при помощи git?
ну такое...
Необходимо выполнить деплой python-проекта со всеми его зависимостями из локального Git (Bitbucket) на сервер в изолированном сегменте сети.
Основная проблема заключается в том, что для python-проекта невозможно подтянуть зависимости простой командой «pip install», так как доступа к каталогам пакетов типа PyPI просто нет - решение этой проблемы и описано в данной статье.
Решение этой проблемы известно уже много лет - допустим, широко известный Nexus (который вообще из мира Java) в бесплатной версии умеет работать прокси репозиторием pypi уже лет 10 наверное. При этом вокруг него можно строить решение, которое будет контролировать безопасность устанавливаемых модулей.
Я уверен, что в питон мире есть и другие решения для подъема проксирующего сервера подобного назначения. Просто вы их не там ищете. Неужели вы думаете, что вы первый, кто оказался в изолированном сегменте без интернета? Да все банки так уже лет 20 живут.
Да, я согласен с вами
Указал с стате ваш комментарий
Статья нацелена не новичков, прошу сильно не возмущаться))
Не, так новичкам так может быть даже проще. Поставить тот же нексус - ну это может пол дня. Зато потом это будет полноценное решение. Я не возмущаюсь, а скорее удивляюсь, что не попробовали поискать готовое решение, которое несомненно есть.
Ну кстати. решение с докером тоже может быть вариантом. Причем опять же, как вариант проксирующего docker registry, который будет стоять между сегментами, а собирать образы вы будете с доступом в интернет. Самое смешное, что тот же нексус это снова умеет. И да, вариант с репозиторием RPM тоже есть.
Да, это справедливо, но в моем случае просто сказали разверни быстрее, прав нет, доступов нет, согласование доступов займет недели, а сделать нужно.
Если бы мне попалась такая маленькая инструкция, то это ускорило бы мой процесс.
Поэтому надеюсь, что кому-нибудь джуну это немного сократит время..
Я указал в статье ваш комментарий, поэтому если человеку это извращенство будет нужно, то он будет читать дальше
Под эти условия наверное да, ручное решение может оказаться самым быстрым. Все-таки, найти и настроить готовое - нужно время.
Хотя как вон там ниже написали - сначала собрать все с доступом к интернету, вам pip все файлики сложит на диск - потом это все заархивировать и перенести в изолированный сегмент, и там установить - тоже выглядит решением.
так я это и описал, или есть еще более удобный вариант?
Не, сорри. Я скорее про то, что точно такой же вариант уже в комментариях предложили :) Ну то есть, он таки напрашивается как один из.
еще более удобный вариант?
Ну, не знаю.. Завернули в docker image там где есть интернет, развернули там где нужно.. Или это слишком просто? ;)
ЗЫ а, у вас docker запрещен ;) PyPy разрешен, а docker нет. нуок ;)
Да, с docker было бы удобнее
Это действие одно из хороших решений
Укажу ваш комментарий в статье
Ну, в большинстве случаев сейчас это правда лучший вариант - но если приложение какой-нибудь "клей" выполняющий кучу подергушек системных утилит или там кастомного IPC-взаимодействия с чем-то - докер может быть и не лучшим вариантом. Впрочем, это прям постараться надо в наше время )
Не плохо, но как это обновлять?
Действительно хорошим вариантом было бы описание проксирующего PyPi сервера (если такой существует) доступного в изолированном участке.
Раз можно переносить данные между своим сервером и этим изолированным, то собрать docker-контейнер со всеми зависимостями, сделать docker save, скопировать файл на изолированный сервер, сделать там docker load, пользоваться. При необходимости обновления процесс повторить.
Но если на оффлайновом сервере не был установлен предварительно докер и доустановить уже нельзя, то тогда да, только копировать ручками зависимости.
Docker запрещен в компании)))
А так согласен
Ну я вижу вы любите трудности преодолевать...
Ну используйте podman - примерно во всем лучше )))
Интересно, из каких соображений может быть запрещено использование докера)
Первое же, что приходит в голову - можно легко подмонтировать корень файловой системы с root доступом. Дальше - множество других вариантов, так как у Docker огромные проблемы с безопастностью из-за использования централизованного сервиса с правами системы. Как правильно подметили, что бы их (проблемы с безопастностью) решить был придуман podman.
неплохо, но как это обновлять?
В случае с линуксом почему вы не соберете все в бинарный пакет и не установите уже его?
Не понял, а почему предварительно не скачать с pypi все требуемые whl-файлы и потом установить тем же pip'ом?
А не проще использовать встроенную в Python виртуализацию установки пакетов?
На локальной машине устанавливаем пакеты в папку:
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txtКопируем папку .venv на сервер, активируем там виртуальную среду, которая подключит модули из папки и работаем.
Да, тоже хороший вариант
Добавлю в статейку
Спасибо
не очень хорошая идея:
file venv/bin/python
---
venv/bin/python: symbolic link to /usr/bin/python3
Так суть такой виртуализации - локальная установка пакетов для python, сам он в системе должен быть уже установлен, на него путь и укажет.
Тут главное, под такой же системой локально устанавливать, чтобы пути совпали, если из под windows, то сюрпризы с путями могут быть, хотя их можно и вручную потом подправить наверное.
А если на сервере исходно и python нет, то задача вообще совершенно другая, тогда и предложенный автором метод не поможет.
Тажа лажа) я просто ставил на онлайн машине виндовой все что нужно, а потом переносил на оффлайн машину виндовую папку c:\python и все. Когда нельзя все, кроме копирования файлов, других вариантов особо и нет.
Деплой python-проекта на linux-сервере в изолированном сегменте сети