Azure Webjob is another great feature from Azure WebApp which provides cost effectiveness for running background job. With all the great features, and lots of buzz about open source supports in other languages like Java or python. I was let down by the available documentations which can properly guide a newbie like me to use the Webjob properly.
Architecture wise, Webjob and WebApp are running on the same logical machine. The Django Codes that I have deployed in production are available in "wwwroot", the root of IIS. On the other hand, Webjob is located in a different folder at the home directory, "data/jobs". This is clearly to show that the Webjob is not running on the IIS. Hence it will not cost any performance on the IIS.
Back to executing Webjob with python, I have been doing a lot of research and trying to ask a lot of resources from MS. Most of the answer that I received are similar, "Webjob and WebApp are sharing the same server". None of the answers were actually showing me the example codes in python. However, I solved the puzzle from different parts of the blogs.
Here are solutions that I have managed to work on and put in run.py for the Webjob.
1. Instead of creating/install a new set of packages via PIP (webjob does not support PIP), we will refer to the existing packages that were installed via PIP in virtual environment:
import sys
sitepackage = "D:\home\site\wwwroot\env\Lib\site-packages"
sys.path.append(sitepackage)
2. With the similar approach at step one, we may need to call functions/models that are defined in different django app as part of the scheduled task in Webjob. Hence, the following are the reference of the django project path:
myproject = "D:\home\site\wwwroot"
sys.path.append(myproject)
3. We still need to refer to django settings.py to make sure that we do not need to replicate the settings that are already defined. With the research of stackoverflow, I managed to find a code that help me to solve the problem:
from optparse import OptionParser
usage = "usage: %prog -s SETTINGS | --settings=SETTINGS"
parser = OptionParser(usage)
parser.add_option('-s', '--settings', dest='settings', metavar='SETTINGS', help="The Django settings module to use", default='DjangoProject.settings')
(options, args) = parser.parse_args()
if not options.settings:
parser.error("You must specgfy a settings module")
os.environ['DJANGO_SETTINGS_MODULE']=options.settings
4. Executing the tasks that are designed for the relevant jobs as usual python code.
Voala! Your webjob is ready to be executed. Remember, you need to zip up the run.py before you upload it. Now, you can run your webjob by reusing the codes in your original django project without replicating them,
Please leave comments for this blog.
Architecture wise, Webjob and WebApp are running on the same logical machine. The Django Codes that I have deployed in production are available in "wwwroot", the root of IIS. On the other hand, Webjob is located in a different folder at the home directory, "data/jobs". This is clearly to show that the Webjob is not running on the IIS. Hence it will not cost any performance on the IIS.
Back to executing Webjob with python, I have been doing a lot of research and trying to ask a lot of resources from MS. Most of the answer that I received are similar, "Webjob and WebApp are sharing the same server". None of the answers were actually showing me the example codes in python. However, I solved the puzzle from different parts of the blogs.
Here are solutions that I have managed to work on and put in run.py for the Webjob.
1. Instead of creating/install a new set of packages via PIP (webjob does not support PIP), we will refer to the existing packages that were installed via PIP in virtual environment:
import sys
sitepackage = "D:\home\site\wwwroot\env\Lib\site-packages"
sys.path.append(sitepackage)
2. With the similar approach at step one, we may need to call functions/models that are defined in different django app as part of the scheduled task in Webjob. Hence, the following are the reference of the django project path:
myproject = "D:\home\site\wwwroot"
sys.path.append(myproject)
3. We still need to refer to django settings.py to make sure that we do not need to replicate the settings that are already defined. With the research of stackoverflow, I managed to find a code that help me to solve the problem:
from optparse import OptionParser
usage = "usage: %prog -s SETTINGS | --settings=SETTINGS"
parser = OptionParser(usage)
parser.add_option('-s', '--settings', dest='settings', metavar='SETTINGS', help="The Django settings module to use", default='DjangoProject.settings')
(options, args) = parser.parse_args()
if not options.settings:
parser.error("You must specgfy a settings module")
os.environ['DJANGO_SETTINGS_MODULE']=options.settings
4. Executing the tasks that are designed for the relevant jobs as usual python code.
Voala! Your webjob is ready to be executed. Remember, you need to zip up the run.py before you upload it. Now, you can run your webjob by reusing the codes in your original django project without replicating them,
Please leave comments for this blog.
