И так если вам опять нечем заняться, но есть время, то добро пожаловать под кат.
Что же мы имеем? Отлаженный на локалхосте скрипт, его рабочую версию в репозитарии, аккаунт в OpenShift и настроенные доступы до питонячьего приложения находящегося там.
Итак смотрим в исходник и задаемся вопросом что изменилось за время изложения? Практически ничего, разве что добавилась какая то странная проверка на venv и на наличие local_settings . С последней все просто: что бы в репе не указывать реальные данные о серверах и емэйлах, храню их в отдельном фале. Это подсмотрено в джанге и стоит добавить в копилку хороших практик. Копируем сценарий к себе.
Вторая проверка найдена на просторах stakowerflow и в принципе может быть закомментирована но для начала она нам понадобится что бы увязать вместе скрип питона, шелла и виртуальное окружение. Зачем? Конечно же что бы таки добраться до OpenShift. А то там одни парсеры сайтов засели)
Когда вы стряпаете свой домен, добавляете картриджи, не проходите мимо создания ключей доступа для того что бы авторизоваться и поработать через консоль. Легко гуглится туторил запуска крона для пыхи. В случае с питоном, чуть больше шагов: в ежеминутном скрипте надо активировать виртуальное окружение и уже потом запускать скрипт. Следует отметить, что у людей часто бывают проблемы, потому что они не изучили системные переменные окружения. Можно конечно пробежаться по этому туторилалу, но он ужасен, а при установке через вебморду pip ставиться по дефолту, как и многие другие вещие.
Отлично, теперь идем в <appname>/.openshift/cron/minutely/ наш weather.sh но с правильными путями:
В принципе не плохо, но вот в чем дело: не красиво иметь один репозитарий для хранения скрипта, а потом ручкми копировать его в репу для OpenShift. Надо использовать git submodule. Идем на страницу своего проекта, копируем ссулку на главную страницу, потом открываем приватное окно браузера, вставляем, жмакаем не clone https и сохраняем линк, пока не пойем суть манипуляций. Зачем столько телодвижений: если склонировать ссылку на проект, если вы уже авторизованы на bitbucket, то в пути ссылки будет ваше имя. Соответственно, на сервере опеншифта, при попытке склонировать субмодуль возникнет ошибка, так как на сервере вы не авторизованы на битбакете.
Так вот имеем линку <link> в буфере. А теперь переходим в репу приложения openshift и делаем следующее:
Отлично, у меня в репе лежит все вместе, поэтому в папку крона надо будет положить символьную линку на скрипт. Переходм в нее и:
Отлично, да вот еще одна беда осталасть: так как в субмодуле игнорируются локальные настройки, то их бесполезно класть в ту же папку. В принципе можно поизвращаться с импорот модулей и консант из других дирректорий, но это переусложение. Гораздо проже создать хук для сервера, что бы он при стягивании обновления с репозиария еще копировал файл с настройками из коня репы в папку субмодуля. Просто и эффективно)
Что же мы имеем? Отлаженный на локалхосте скрипт, его рабочую версию в репозитарии, аккаунт в OpenShift и настроенные доступы до питонячьего приложения находящегося там.
Итак смотрим в исходник и задаемся вопросом что изменилось за время изложения? Практически ничего, разве что добавилась какая то странная проверка на venv и на наличие local_settings . С последней все просто: что бы в репе не указывать реальные данные о серверах и емэйлах, храню их в отдельном фале. Это подсмотрено в джанге и стоит добавить в копилку хороших практик. Копируем сценарий к себе.
Вторая проверка найдена на просторах stakowerflow и в принципе может быть закомментирована но для начала она нам понадобится что бы увязать вместе скрип питона, шелла и виртуальное окружение. Зачем? Конечно же что бы таки добраться до OpenShift. А то там одни парсеры сайтов засели)
Когда вы стряпаете свой домен, добавляете картриджи, не проходите мимо создания ключей доступа для того что бы авторизоваться и поработать через консоль. Легко гуглится туторил запуска крона для пыхи. В случае с питоном, чуть больше шагов: в ежеминутном скрипте надо активировать виртуальное окружение и уже потом запускать скрипт. Следует отметить, что у людей часто бывают проблемы, потому что они не изучили системные переменные окружения. Можно конечно пробежаться по этому туторилалу, но он ужасен, а при установке через вебморду pip ставиться по дефолту, как и многие другие вещие.
Отлично, теперь идем в <appname>/.openshift/cron/minutely/ наш weather.sh но с правильными путями:
#! /bin/bash source "$VIRTUAL_ENV"/bin/activate python "$OPENSHIFT_REPO_DIR"tasks/weather.py >> "$OPENSHIFT_PYTHON_LOG_DIR"weather.log 2>&1 deactivateкоммитим и пушим. Да-да, слэшей после этих переменных окружения не надо, удостовериться в этом можно, если сделать эхо переменной, находясь в терминале сервера. Если включили принт на проверку песочницы и проверки адресатов, тогда, если в консоли (с предварительно установленным руби и гемом от openshift) ввести
rhc tail <appname>то,покажутся все логи сервака. Можно конечно отслеживать только логи нашей приложения, но для этого нам понадобится законнектится к их серверу а дальше
cd $OPENSHIFT_PYTHON_LOG_DIR tail -f weather.logИ видим, что заработало.
В принципе не плохо, но вот в чем дело: не красиво иметь один репозитарий для хранения скрипта, а потом ручкми копировать его в репу для OpenShift. Надо использовать git submodule. Идем на страницу своего проекта, копируем ссулку на главную страницу, потом открываем приватное окно браузера, вставляем, жмакаем не clone https и сохраняем линк, пока не пойем суть манипуляций. Зачем столько телодвижений: если склонировать ссылку на проект, если вы уже авторизованы на bitbucket, то в пути ссылки будет ваше имя. Соответственно, на сервере опеншифта, при попытке склонировать субмодуль возникнет ошибка, так как на сервере вы не авторизованы на битбакете.
Так вот имеем линку <link> в буфере. А теперь переходим в репу приложения openshift и делаем следующее:
git submodule add <link>Рекомендую подробнее про это почитать.
Отлично, у меня в репе лежит все вместе, поэтому в папку крона надо будет положить символьную линку на скрипт. Переходм в нее и:
ln -s ../../../weather/weather_openshift.sh weather_openshift.sh
#! /bin/bash cp "$OPENSHIFT_REPO_DIR"settings_production.py "$OPENSHIFT_REPO_DIR"weather/Поздравляю, это был долгий путь, главное помнить, что их сервера находятся в часовом поясе UTC-5 :) Но да ничего правильное время рассылки можно выставить в local_settings.
А узнать текущий часовой пояс можно
date +%:zДумете все заработало и можно успокоиться? Как бы не так) Скорее всего после нескольких дней успешной работы ничего приходить не будет. Вы будете думать, что где то что то наебнулось, смотреть в логи, курить спеки, но все будет тщетно. А на самом деле все просто. Админы из OpenShift не сериалы смотрят, а делом заняты и удумали, что если инстанс не используется то отправлять его в сон со всеми картриджами. В принципе логично. Только в логах будет гнетущая пустота. И так надо научить сервер поддерживать жизнь ноде. Так как в системе стоит курл, то может придти мысль использовать его покрону, но нет, это не сработает. Что бы нода поняла, что она нужна, нужно стучаться из внешнего адреса. К счасью, на том же PaaS умный парень сделал приложение Uptime, назначение которого не сложно догадаться.
Такие вот такие неожиданные костыли)
