Can anyone give me some advice on automating the start up of my virtualenv app on Windows? I have a small Flask app that runs on gunicorn. It runs fine, but how do I put it into production? I don't want to have to go in manually and cd into the directory and type activate and then gunicorn app:blog. How does one go about employing a virtualenv? Here is what I've tried scripting:
echo off
cd C:\Users\Darkn\Code\Python\flask-intro
venv\scripts\activate.bat
venv\scripts\waitress-serve --port=5000 app:app
The first two lines get executed, but the last line doesn't do anything.
The activate script from virtualenv gave me some clues. The trick was to prepend the virtualenv path to the system path. Then the script could just cd into the project directory and start the app.
#echo off
set "VIRTUAL_ENV=C:\Users\Darkn\Code\Python\flask-intro\venv"
set "PATH=%VIRTUAL_ENV%\Scripts;%PATH%"
cd C:\Users\Darkn\Code\Python\flask-intro
waitress-serve --port=5000 app:app
I used the answer by Darc Nawg to install a windows service using WinSW with the following xml config file.
<service>
<id>com.taxicabmanager.django</id>
<name>Taxicab Manager Django</name>
<description>Industry standard Django and GraphQL components of Taxicab Manager.</description>
<env name="VIRTUAL_ENV" value="C:\source\taxicab-manager-django\env-taxicab-manager-django"/>
<env name="PATH" value="%VIRTUAL_ENV%\Scripts;%PATH%"/>
<workingdirectory>C:\source\taxicab-manager-django</workingdirectory>
<executable>waitress-serve</executable>
<arguments>--port=2003 --url-scheme=http api.wsgi:application</arguments>
<logmode>rotate</logmode>
<delayedAutoStart/>
<onfailure action="restart" />
</service>
From somewhere else:
#ECHO OFF
:<name>
CALL "C:\path\to\activate.bat"
python -O -m <env> <script>
IF %ERRORLEVEL% NEQ 0 (
ECHO Restarting <name>...
GOTO <name>
)
Related
I was trying to systemd a flask app. I tried to write a script like this:
#!/bin/bash
cd /path/to/app
source venv/bin/activate
python start.py
and just ExecStart this script in the .service file. But this doesn't quite work as starting the service errors with
python: command not found
I actually ran into quite a few issues, but eventually resolved with service file:
[Service]
WorkingDirectory=/path/to/app
ExecStart=/path/to/app/venv/bin/python start.py
Without WorkingDirectory, the file paths do not seem to work as the static file can't even be found.
So my question is actually why doesn't script above in the beginning work? The cd took effect, but the venv activate didn't?
I am having an issue via an apache Nearly Free Speech server (I have been following the NFS guide via this link: https://blog.nearlyfreespeech.net/2014/11/17/how-to-django-on-nearlyfreespeech-net/. I have created a run-django.sh file to properly run the application which also opens a virtualenv (I have named the folder 'venv'). These are the contents of my run-django.sh file:
#!/bin/sh
. venv/bin/activate
exec python3 manage.py runserver
On the current step of the guide I am attempting to run the run-django.sh as follows:
[questionanswer /home/protected]$ ls
question_answer run-django.sh venv
[questionanswer /home/protected]$ cd question_answer/
[questionanswer /home/protected/question_answer]$ ../run-django.sh
.: cannot open bin/activate: No such file or directory
How is this not detecting my directory of 'venv/bin/activate' ?
I am editing my .ebextensions .config file to run some initialisation commands before deployment. I thought this commands would be run in the same folder of the extracted .zip containing my app. But that's not the case. manage.py is in the root directory of my zip and if I do the commands:
01_collectstatic:
command: "source /opt/python/run/venv/bin/activate && python manage.py collectstatic --noinput"
I get a ERROR: [Instance: i-085e84b9d1df851c9] Command failed on instance. Return code: 2 Output: python: can't open file 'manage.py': [Errno 2] No such file or directory.
I could do command: "python /opt/python/current/app/manage.py collectstatic --noinput" but that would run the manage.py that successfully was deployed previously instead of running the one that is being deployed atm.
I tried to check what was the working directory of the commands ran by the .config by doing command: "pwd" and it seems that pwd is /opt/elasticbeanstalk/eb_infra which doesn't contain my app.
So I probably need to change $PYTHONPATH to contain the right path, but I don't know which path is it.
In this comment the user added the following to his .config file:
option_settings:
aws:elasticbeanstalk:application:environment:
DJANGO_SETTINGS_MODULE: myapp.settings
PYTHONPATH: "./src"
Because his manage.py lives inside the src folder within the root of his zip. In my case I would do PYTHONPATH: "." but it's not working.
AWS support solved the problem. Here's their answer:
When Beanstalk is deploying an application, it keeps your application files in a "staging" directory while the EB Extensions and Hook Scripts are being processed. Once the pre-deploy scripts have finished, the application is then moved to the "production" directory. The issue you are having is related to the "manage.py" file not being in the expected location when your "01_collectstatic" command is being executed.
The staging location for your environment (Python 3.4, Amazon Linux 2017.03) is "/opt/python/ondeck/app".
The EB Extension "commands" section is executed before the staging directory is actually created. To run your script once the staging directory has been created, you should use "container_commands". This section is meant for modifying your application after the application has been extracted, but before it has been deployed to the production directory. It will automatically run your command in your staging directory.
Can you please try implementing the container_command section and see if it helps resolve your problem? The syntax will look similar to this (but please test it before deploying to production):
container_commands:
01_collectstatic:
command: "source /opt/python/run/venv/bin/activate && python manage.py collectstatic --noinput"
So, the thing to remember about beanstalk is that each of the commands are independent, and you do not maintain state between them. You have two options in this case, put your commands into a shell script that is uploaded in the files section of ebextensions. Or, you can write one line commands that do all stateful activities prefixed to your command of interest.
e.g.,
00_collectstatic:
command: "pushd /path/to/django && source /opt/python/run/venv/bin/activate && python manage.py collectstatic --noinput && popd"
I have a simple python script which I want to start a daemon-service in background in docker container
/sbin/start-stop-daemon --start --user root --make-pidfile --pidfile /var/lock/subsys/my-application.pid --exec 'python /opt/app/uc/monitor/bin/my-application.py'
when I execute this command in a shell I get
/sbin/start-stop-daemon: unable to stat //python /opt/app/uc/monitor/bin/my-application.py (No such file or directory)
However when execute just the below command in shell it works
python /opt/app/uc/monitor/bin/my-application.py
I'm sure the python is installed and all the links have been setup.
Thanks for the help
That error message implies that start-stop-daemon is looking for a file to open (the stat operation is a check before it opens the file) and treating your 'python ... ' argument as if it was a file.
See this example which confirms this. You may need to read the man page for start-stop-daemon, for your Ubuntu version, to check what a valid command would be for your setup.
Simplest solution is probably to create a shell script (say /opt/app/uc/monitor/bin/run-my-application.sh), and put this into it:
#!/bin/bash
python /opt/app/uc/monitor/bin/my-application.py
Be sure to do chmod +x on this file. If python is not found, use which python to find the path to python and use that in the script.
Now try:
/sbin/start-stop-daemon --start --user root --make-pidfile --pidfile /var/lock/subsys/my-application.pid --exec '/opt/app/uc/monitor/bin/run-my-application.sh'
When I was developing and testing my project, I used to use virtualenvwrapper to manage the environment and run it:
workon myproject
python myproject.py
Of course, once I was in the right virtualenv, I was using the right version of Python, and other corresponding libraries for running my project.
Now, I want to use Supervisord to manage the same project as it is ready for deployment. The question is what is the proper way to tell Supervisord to activate the right virtualenv before executing the script? Do I need to write a separate bash script that does this, and call that script in the command field of Supervisord config file?
One way to use your virtualenv from the command line is to use the python executable located inside of your virtualenv.
for me i have my virtual envs in .virtualenvs directory. For example
/home/ubuntu/.virtualenvs/yourenv/bin/python
no need to workon
for a supervisor.conf managing a tornado app i do:
command=/home/ubuntu/.virtualenvs/myapp/bin/python /usr/share/nginx/www/myapp/application.py --port=%(process_num)s
Add your virtualenv/bin path to your supervisord.conf's environment:
[program:myproj-uwsgi]
process_name=myproj-uwsgi
command=/home/myuser/.virtualenvs/myproj/bin/uwsgi
--chdir /home/myuser/projects/myproj
-w myproj:app
environment=PATH="/home/myuser/.virtualenvs/myproj/bin:%(ENV_PATH)s"
user=myuser
group=myuser
killasgroup=true
startsecs=5
stopwaitsecs=10
First, run
$ workon myproject
$ dirname `which python`
/home/username/.virtualenvs/myproject/bin
Add the following
environment=PATH="/home/username/.virtualenvs/myproject/bin"
to the related supervisord.conf under [program:blabla] section.