COMP3297 Software Engineering Department of Computer Science The University of
Individual Assignment 1: Deploying into Production Quarantine Data Dashboard
This worksheet covers rolling out your dashboard application for real-world use. You’ll deploy to a cloud platform as a true web application configured for release.
We are using Heroku as our PaaS. You’ll use Git to deploy to Heroku by pushing your application’s main or master branch from your local repo to a remote repo hosted on Heroku. General notes on the use of Git are available if you need to refresh your knowledge.
Copyright By PowCoder代写 加微信 powcoder
Remember from the introduction to our Django environment, when you deploy, Heroku will package your application together with its dependencies into a dyno, which is a virtualized Linux container. It contains your application and all its dependencies. Your Quarantine Data Dashboard product is stateless, and so deployment should be particularly straightforward.
During deployment, Heroku looks for certain files in specific places. For consistency, we’ll refer to particular directories as follows:
· Project Root. This is the directory containing manage.py and your app directory. It will also serve as your repository root and is where your .git repo will be located. It contains the following sub- directory:
· Configuration Root. This contains the project-wide configuration files such as settings.py and the app server entry point, wsgi.py.
Before deploying, clean up your directories and delete any junk that does not belong there. You’ll be pushing everything to the cloud platform and so you want only files that are needed for your application. If you don’t delete them, you should add them to your .gitignore file before deployment.
Ahead of deployment, run the development server locally to make sure your application is working before you start making changes for production.
A: Create a Heroku app
Get a Heroku account and create an app.
Get a free Heroku account here:
https://signup.heroku.com/
We’ll deploy using the Heroku Command Line Interface (CLI) which requires Git. You need to commit your code to a local Git repo before you can deploy it. If you don’t have Git installed or have not used it during development, follow the instructions here:
https://devcenter.heroku.com/articles/git
If you don’t have a local repo yet, execute git init to create a Git repo in your Project Root.
Also install the Heroku Command Line Interface locally. Assuming you already have Git installed and set up on your machine, follow instructions here to install the CLI for your platform:
https://devcenter.heroku.com/articles/heroku-cli#install-the-heroku-cli
Most of the Heroku actions in this worksheet can be performed either through your Heroku Dashboard or from the CLI. We’ll use the CLI in most cases.
(If you prefer a Dashboard for admin rather than a CLI, just login here: https://id.heroku.com/login)
CLI: In a terminal, login to Heroku by entering:
heroku login
After authentication, create a new app on Heroku by entering:
heroku create
You will see something like the following, with an app name generated by Heroku. Or you can pass an app name of your own after “create “; the name must be unique and Heroku-legal. If you are using the Heroku Dashboard, just leave the app name blank for Heroku to generate a name.
In this case, fierce-headland-61511.herokuapp.com would be the URL of your app after you deploy.
The URL of the Heroku Git remote would be https://git.heroku.com/fierce-headland-61511.git. If you ran create from your app’s root directory, the Heroku Git repo will automatically be set up as a remote for your local repo. You can check by executing git remote -v
If it has not been added yet, or you wish to do it later, you will need to add it explicitly and name it heroku. For the example above, you would create the remote with the following Git command:
git remote add heroku https://git.heroku.com/fierce-headland-61511.git
Creating app… done, ⬢ fierce-headland-61511
https://fierce-headland-61511.herokuapp.com/ | https://git.heroku.com/fierce-headland-61511.git
(replace the URL in this example with your own)
B: Prepare your application for deployment
For complicated deployments we normally prepare for it in several stages as follows:
· First, move off the development server and onto a production-level WSGI server locally. We test locally in Heroku Local (part of the Heroku CLI).
· Then we deploy to Heroku with our SQLite DBMS and test remotely.
· Next, we switch to Postgres and test locally
· Finally we deploy to Heroku and test with the provisioned Postgres database.
Since deploying your application will involve almost none of these complications, we will stick with the development server locally and will not test in Heroku Local before deploying.
So, you will deploy your current application immediately to Heroku. There you will use gunicorn in place of Django’s development server.
1. Tell Heroku your application’s process type(s) and entry point(s).
This is critically important information for Heroku. Heroku wants it in a file named Procfile (no extension). It specifies what gets executed on startup in a dyno of the given process type.
Make your Procfile: You want Heroku to start the gunicorn server, telling it the app server entry point. You can copy the entry point from the location of the application object given in the WSGI_APPLICATION setting in settings.py.
So, for a Django web project using gunicorn, with the wsgi module in a directory named my_config_root, the Procfile will contain:
(of course, replace my_config_root with your own Configuration Root)
Put the Procfile in the directory containing manage.py. That is, in your Project Root. Heroku has other
ways of finding the files it needs, but this is the simplest approach.
2. Install gunicorn in your development environment: pipenv install gunicorn
Note: this is just an easy way to get gunicorn into your list of dependencies for your Heroku environment. You won’t run gunicorn locally and, in fact, since it is not cross-platform it will not run in certain environments anyway.
3. Set Allowed Hosts.
Django docs tell us that in development, “when DEBUG is true and ALLOWED_HOSTS in empty, the host is validated against [‘.localhost’, ‘127.0.0.1’, ‘[::1]’]. We need to add our Heroku host, and also those we want to retain for local access.
In settings.py: Paste your site’s hostname into ALLOWED_HOSTS and add local hosts explicitly: ALLOWED_HOSTS = [‘fierce-headland-61511.herokuapp.com’, ‘localhost’, ‘127.0.0.1’]
(of course, replace the hostname in this example with your own)
4. Prevent Heroku from running collectstatic.
During deployment, Heroku runs Django’s collectstatic command automatically to gather all static files into a single directory. Normally, we need to specify the directory by setting STATIC_ROOT in settings.py.
Since your application uses only remote static assets, we will disable collectstatic by setting a config var for the application from the terminal:
You can also set config vars from the Heroku Dashboard if you prefer
5. Provide all remaining information Heroku needs to serve your app.
What Heroku needs to know:
i) Heroku will detect that it is dealing with a Python app. But it needs to know what version of Python to use, if not the default runtime.
Provide this to Heroku in a text file runtime.txt. Example of contents:
Currently Heroku supports python-3.10.2, python-3.9.10 (default), python-3.8.12, and python-3.7.12.
ii) What packages it must install for you.
Heroku will first look for a requirements.txt file that lists your dependencies. If it doesn’t find one, it will install dependencies with Pipenv from your Pipfile.lock file.
If you did not use Pipenv, you can use pip freeze within your virtual environment to populate the file.
pip freeze > requirements.txt
If you did use Pipenv, you do not need a requirements.txt file.
Put your runtime.txt file (and requirements.txt if you don’t have a Pipfile.lock) in the same place as your Procfile. That is, put them all together in the directory containing manage.py, which is your Project Root.
Deploying requires only the simple step of pushing your project’s Git repo main/master branch to Heroku. If you created your local Git repo in the Project Root, then deployment is particularly straightforward since that is the configuration assumed by Heroku.
Add anything you don’t need on Heroku to your .gitignore file.
Prepare to deploy by adding your project’s files to the Git index (staging area), and commit the changes to your local repo. This will likely be a simple case of adding everything and then committing.
Then, to deploy, all you need to do is push your main/master branch to your Heroku remote.
The push will initiate activity to build your app and (we hope) start the web process you specified in the Procfile. Your app can then be run from anywhere through its Heroku URL.
Congratulations, your app is now accessible to the world!!
The next step is to make some small changes to bring your deployment up to production quality. That will be covered in a short second worksheet.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com