Skip to content

Latest commit

 

History

History
221 lines (150 loc) · 6.99 KB

02-Troubleshoot-the-Development-Environment.md

File metadata and controls

221 lines (150 loc) · 6.99 KB
Raw

Troubleshoot the Development Environment

Troubleshoot the Development Environment

  1. Information only

  2. Information only

  3. Copy the file caleston-code.tar.gz from Bob's laptop to Bob's home directory on the webserver devapp01 
    scp caleston-code.tar.gz devapp01:~/
  4. On the devapp01 webserver, unzip and extract the copied file in the directory /opt/.

    Note that the /opt directory is owned by root on devapp01 so we'll need sudo

    ssh devapp01

sudo tar -zxf caleston-code.tar.gz -C /opt

    Don't exit from the ssh session just yet. We need to remain on devapp01

  5. Delete the tar file from devapp01 webserver. 
    rm caleston-code.tar.gz
  6. Make sure that the directory is extracted in such a way that the path /opt/caleston-code/mercuryProject/ exists on the webserver.

    Nothing to do here. If you got Q4 right, then this will work too - press OK.

    You can verify if you like:

    ls -l /opt/caleston-code/mercuryProject/
  7. For the client demo, Bob has installed a postgres database in devdb01.
    SSH to the database devdb01 and check the status of the postgresql.service
    What is the state of the DB?

    At this point you are still logged into devapp01, so first return to Bob's laptop

    exit

    Now go to the db node

    ssh devdb01

systemctl status postgresql.service

    Note the status: Active: inactive (dead) ...

    Don't exit from the ssh session just yet. We need to remain on devdb01

  8. Add an entry host all all 0.0.0.0/0 md5 to the end of the file /etc/postgresql/10/main/pg_hba.conf on the DB server.
    This will allow the web application to connect to the DB.     
    sudo vi /etc/postgresql/10/main/pg_hba.conf

    Make the change as directed, save and exit vi.

  9. Start the postgres DB on the devdb01 server. 
    sudo systemctl start postgresql.service
  10. What port is postgres running on? Check using the netstat command? 
    sudo netstat -ptean

    There's 2 entries for postgres, one each for IPv4 and IPv6, but both are using the same port. Note this port down - you will need it later!

  11. Back on the devapp01 webserver. Attempt to start the web application by:
    Navigate to the directory /opt/caleston-code/mercuryProject
    Next, run the command python3 manage.py runserver 0.0.0.0:8000

    At this point you are still logged into devdb01, so first return to Bob's laptop

    exit

    Now go to the app node

    ssh devapp01

cd /opt/caleston-code/mercuryProject
python3 manage.py runserver 0.0.0.0:8000

    Note it dumps a stack trace on the screen, i.e. it crashed! Thus the answer is No.

    Press CRTL + C

  12. Why did the command not work?

    The answer to this is in the stack trace at the end. The app cannot connect to the database on the address and port indicated. Also remember the earlier question where you were asked to find the port that the database server is listening on!

  13. It appears that Bob did not configure his app to connect a postgres database running on a different server.

    For this, we need to first find the file we need to edit, so we're going to use find to find files and use grep to find the specific text, with the -l switch to print the file path the text was found in.

    find . -type f -exec grep -l 'DATABASES = {' "{}" \;

    Edit the file that was returned by the above

    vi ./mercury/settings.py

    Scroll down to DATABASES = { and beneath this set the correct host and port. Save and exit.

  14. Now that has been set up, change the ownership of ALL files and directories under /opt/caleston-code to user mercury.

    You'll need to be root to reassign ownership

    sudo chown -R mercury /opt/caleston-code
  15. Great! Everything should now be in order to restart the application.

    If you've followed all the above steps, you should still be in directory /opt/caleston-code/mercuryProject

    Start the app as directed and verify it works, then CTRL-C to exit.

    Now run the migration. Note that the venv directory is not beneath the current directory as the question suggests. It is actually in the parent directory, hence ../venv below.

    source ../venv/bin/activate
python3 manage.py migrate

    Start the app again so the question will validate.

    What is this venv stuff?

    If you're considering learning Python (highly recommended as it is required in many DevOps jobs), this means Virtual ENVironment. It allows you to install Python packages on a project-by-project basis, thus not polluting the main Python installation. This is especially useful on your development environment where you may have multiple Python projects all with different package requirements.

  16. Well done! Now, for the final task before the client presentation.

    Here we have to create a systemd unit file to make the Python app be runnable as a service.

    First quit the running webapp by pressing CTRL-C

    Note that in unit files, the process to execute (in this case python3) we must use its fully qualified path, as systemd does not have a search path. Get this like this

    which python3

    Now create the unit file

    sudo vi /etc/systemd/system/mercury.service

    And put the following in to satisfy the question requirements

    [Unit]
Description=Project Mercury Web Application

[Service]
ExecStart=/usr/bin/python3 manage.py runserver 0.0.0.0:8000
Restart=on-failure
WorkingDirectory=/opt/caleston-code/mercuryProject/
User=mercury

[Install]
WantedBy=multi-user.target

    Now enable and start the service. We must run a daemon-reload whenever we have created, edited or deleted a unit file. Note that the .service extension is optional with systemctl commands. We can say mercury.service, or simply mercury

    sudo systemctl daemon-reload
sudo systemctl enable mercury
sudo systemctl start mercury

  17. Information only - browse the running application!