update readme
This commit is contained in:
welld1
126
README.md
126
README.md
@@ -1,11 +1,123 @@
|
||||
# django_installer
|
||||
installer for django using nginx and gunicorn
|
||||
# Django Setup for CentOS 7
|
||||
## install.sh
|
||||
### Variables
|
||||
when you open install.sh you'll see these variables at the top:
|
||||
```bash
|
||||
# vars
|
||||
yumlogloc="/root/logs/yum.log"
|
||||
yumlogmsg="See logs/yum.log for more info."
|
||||
|
||||
## Branch Configuration
|
||||
### Master
|
||||
firelogloc="/root/logs/firewall.log"
|
||||
firelogmsg="See logs/firewall.log for more info."
|
||||
|
||||
Master branch contains a verified and working script.
|
||||
pylogloc="/root/logs/python.log"
|
||||
pylogmsg="See logs/python.log for more info."
|
||||
pylink="https://www.python.org/ftp/python/3.7.0/Python-3.7.0.tar.xz"
|
||||
|
||||
### Dev
|
||||
# Django Project Settings
|
||||
user="centos"
|
||||
djalog="/root/logs/django.log"
|
||||
djamsg="See logs/django.log for more info."
|
||||
projectname="mysite"
|
||||
hostname="centos.duco.net"
|
||||
|
||||
Dev branch contains a broken, possibly unstable, unverified script
|
||||
# if you are doing this on a personal install you will prob need this.
|
||||
install_epel_release=False
|
||||
```
|
||||
These can (and should) be changed to match your configuration needs. For example: any of the "logloc" log location variables can be changed to log somewhere else. The "logmsg" log message variables can be changed to reflect different log locations or output a custom message.
|
||||
|
||||
The Django Project Settings variables should be changed to match your configuration. You have (essentially) 3 options for user configuration:
|
||||
1. user = "[primary (sudo) user here]"
|
||||
2. user = "nginx"
|
||||
3. user = "[other user]"
|
||||
|
||||
My recommendation is to use nginx as the user. The installer takes care of creating a home directory for nginx and setting permissions. Of course there is no problem with specifying another user. You could "adduser django" and set django as the user. The installer will automatically assign permissions as needed. Setting the user to the primary sudo account is risky but the installer won't complain if you do it quietly.
|
||||
|
||||
The projectname variable can be whatever you want. When django starts the project it will use this name.
|
||||
|
||||
The hostname will be inserted into "ALLOWED_HOSTS" in your app settings. Multiple hosts are not supported at the moment so set this to the address you'll test with. You can add additional hosts by manually editing settings.py.
|
||||
|
||||
### Dependencies
|
||||
In order for this script to work its magic you'll need a few packages provided by Yum. This part is likely to break due to Yum's inconsistency accross distributions, firewall and proxy configurations, and whether CentOS had its morning coffee. There are a few measures you can take to prevent this. One of those is understanding exactly what this script does.
|
||||
|
||||
```install_epel_release=True```
|
||||
|
||||
If you are installing this on a system with the minimal CentOS build you'll need install_epel_release to be True. Epel_release includes, among other things, nginx. Kinda hard to run the site without that.
|
||||
|
||||
```bash
|
||||
# check if root
|
||||
if [[ $EUID -ne 0 ]]; then
|
||||
echo "This script must be run as root"
|
||||
exit 1
|
||||
fi
|
||||
cd /root/
|
||||
|
||||
echo "Installing dependencies..."
|
||||
# create necessary dirs
|
||||
if [ ! -d "/root/scripts" ] ; then
|
||||
mkdir scripts
|
||||
fi
|
||||
if [ ! -d "/root/logs" ] ; then
|
||||
mkdir logs
|
||||
fi
|
||||
if [ $install_epel_release = True ] ; then
|
||||
yum -y install epel-release
|
||||
fi
|
||||
```
|
||||
|
||||
The first part of the script is fairly straight forward. If you aren't root, the installer can't use yum and won't work. It then creates the necessary directories to prevent future complaints and installs the aforementioned epel-release package if you want it.
|
||||
|
||||
```bash
|
||||
yum -y install gcc wget nginx libsqlite3x-devel.x86_64 postgresql-server postgresql-devel postgresql-contrib bzip2-devel zlib-devel libffi-devel openssl-devel policycoreutils-python.x86_64 >> $yumlogloc
|
||||
firewall-cmd --zone=public --add-port=80/tcp --permanent >> logs/firewall.log
|
||||
firewall-cmd --zone=public --add-port=443/tcp --permanent >> logs/firewall.log
|
||||
firewall-cmd --reload >> logs/firewall.log
|
||||
semanage permissive -a httpd_t >> logs/firewall.log
|
||||
```
|
||||
|
||||
These are the 5 commands the script runs next (without all the error checking and logging). If there were any commands I would recommend you run manually: it's these. Definitely read through the yum install logs to make sure everything went smoothly. Like I mentioned earlier: yum doesn't like to behave.
|
||||
|
||||
The firewall commands are specific to a CentOS 7 minimal install. You may not need them. They may not work at all. The installer doesn't really care if they fail because they aren't mission critical. It'll yell at you and that's about it.
|
||||
|
||||
The semanage command fixes an issue where the websocket would be inaccessible after an install causing 502 errors and loud swearing.
|
||||
|
||||
```bash
|
||||
wget $pylink > $pylogloc
|
||||
tar xf Python-3.7.0.tar.xz >> $pylogloc
|
||||
cd Python-3.7.0
|
||||
./configure --prefix /usr/src/python37 >> $pylogloc
|
||||
make >> $pylogloc
|
||||
make altinstall >> $pylogloc
|
||||
/usr/src/python37/bin/python3.7 -m pip install --upgrade pip >> $pylogloc
|
||||
/usr/src/python37/bin/python3.7 -m pip install virtualenv >> $pylogloc
|
||||
cd /root/
|
||||
rm Python-3.7.0.tar.xz >> $pylogloc
|
||||
```
|
||||
|
||||
If you've ever installed Python from source this part should look familiar. Right now it grabs the latest version of Python 3.7 and installs it to /usr/src/python37/. It uses alt install to prevent conflict with previous versions of python (I've been told CentOS will break if it can't find python 2, a real problem if you use make install).
|
||||
|
||||
You could get rid of this section and do it yourself with another version of python. As long as python can be found at /usr/src/python37 and it has django support the installer will continue to chug along happily.
|
||||
|
||||
```bash
|
||||
echo "Starting Django project..."
|
||||
if [ ! -d "/home/$user" ] ; then
|
||||
mkdir /home/$user
|
||||
chown -R $user:$user /home/$user
|
||||
fi
|
||||
mkdir /home/$user/$projectname
|
||||
cd /home/$user/
|
||||
/usr/src/python37/bin/python3.7 -m virtualenv $projectname/venv >> $djalog
|
||||
source $projectname/venv/bin/activate >> $djalog
|
||||
pip install django gunicorn psycopg2-binary >> $djalog
|
||||
cd $projectname
|
||||
django-admin startproject $projectname >> $djalog
|
||||
cd /home/$user/
|
||||
sed -i "s/ALLOWED_HOSTS = \[\]/ALLOWED_HOSTS = \[\"$hostname\"\]/" $projectname/$projectname/$projectname/settings.py
|
||||
echo "STATIC_ROOT = os.path.join(BASE_DIR, 'static')" >> $projectname/$projectname/$projectname/settings.py
|
||||
python $projectname/$projectname/manage.py collectstatic
|
||||
python $projectname/$projectname/manage.py makemigrations
|
||||
python $projectname/$projectname/manage.py migrate
|
||||
deactivate
|
||||
chown -R $user:$user $projectname
|
||||
cd /root/
|
||||
```
|
||||
Reference in New Issue
Block a user