Python for Entrepreneurs Transcripts
Chapter: Deploying to the cloud
Lecture: Supervisor waitress
0:01 We got our whole application up and running in the last video but the wsgi server was only running when we were logged in
0:07 under the deploy a user and running it manually. That's not going to suffice for a regular application,
0:12 what we really need is some way to keep our pyramid application up and running in the background, all the time, and have it automatically restart
0:19 if for some reason the application shuts down. That's where the tool supervisor comes in;
0:24 supervisor is a commonly used tool in Python application deployments to start, stop and restart services that you need to run your application.
0:32 We're going to install supervisor, we are going to have it run the p.serve command which is using the waitress whiskey server to run our application,
0:40 then when we go back to our application's url everything will be set up nginx will serve as a reverse proxy,
0:46 and forward requests on to our Python application our Python application will run its code
0:51 supervisor will ensure that the application stays up and running and our application will respond back through nginx server
0:57 and we can keep on serving users, let's set up the last few bits of our Ansible playbook now.
1:02 We again need to write a couple of new files, one is a yaml file for a supervisor
1:06 that will run the wsgi server, and the second is a template for the supervisor configuration we'll start out by writing the yaml file for Ansible.
1:14 Open up roles/common/tasks and start one up that is called wsgi.yml. Our first task is to make sure that supervisor is installed via the system package
1:24 this should look familiar at this point, we're going to use the apt module search for the package named supervisor, make sure it's installed
1:31 and just in case update that system cache and we need to be a Super User to do it. Alright Ansible install supervisor, then what-
1:40 well, we need a configuration for supervisor. So we use the template module, and we'll specify a supervisor app jinja template
1:51 and it will be put under the supervisor configuration directory on our server. And we'll just give it the name of the app name,
2:05 just in case we want to have multiple supervisor configurations out there. Often this will come in if you're running a task queue like celery,
2:12 you'll have multiple supervisor configurations for every single process that you want to manage.
2:17 So by giving it the app name we should know which application this one is running. We load up our configuration, and then what we want to do
2:23 is we actually want to stop the supervisor process, we need to be Super User for this,
2:28 and we actually also need to be Super User for the previous command, all these should be run with Super User privileges.
2:35 Now there's one quirk that I often run into with supervisor which is that if you just restarted quickly,
2:40 it often won't take the configuration files and reload them on Ubuntu, it's a bug that's been out there for a while,
2:47 and so the way that I typically get around it is I pause during the restart process, I stop supervisor I pause
2:53 and then I restart it, and that gets around the issue. You may be able to find a better way to handle this,
2:58 but for now, we want to make sure that we know that this works, when we restart supervisor that our configuration takes effect,
3:04 so this will ensure that you won't have any problems with it. There is certainly room to optimize this part of the deployment.
3:10 And then finally, we need to restart supervisor and then I also restart nginx when this happens, that way nginx is not caching any of the results
3:19 everything is restarted from a clean slate. Next, we need to write our template file for supervisor,
3:24 it's under roles/common/templates/supervisor_app.conf.j2 and this is what this supervisor configuration looks like the program will be called app name
3:38 or we'll punch in the application name that we've given it which is blue yellow in our case, we'll give it the commands to run
3:45 so under our virtual env directory, so we're reusing a lot of these variables that we've already created
3:51 we use the pserve command, and we'll give it a production.ini, we need to run this from a specific directory,
3:58 and so we can specify the exact directory in which we want to run this command that will give it the sub app directory, but of course,
4:07 in your case, if you don't have sub applications folders within folders multiple versions of applications, just give it the app directory.
4:14 The user we're running this as is the deploy a user so we're not running it as root, we're running it as our deploy user,
4:20 we do want to auto start this application up, we don't want to manually start the application, and we also want to auto restart it
4:26 in case supervisor has to restart the application, if the app shuts down we want to restart it,
4:31 and we'll redirect any errors to log files, and this should be standard error. We've only reused variables that we already defined,
4:42 so we don't need to define any new variables for our deployment. The one last step is just to make sure that this new yaml file
4:48 is a part of our playbook, so under rules/common/tasks/main.yml make sure wsgi.yml is in there, save that, let's try to kick it off-
5:04 it looks like everything ran without a problem, but the ultimate test is to check our url, see if our application is live
5:10 we'll restart- boom, blue yellow rockets, we got our whole application up and running, being served by a waitress on the back end as our wsgi server
5:22 and we're in business. So now we have our complete Ansible playbook that also can form the foundation in case you want to change any of these pieces
5:30 if you want to swap out the wsgi server, use a different wsgi server add new features and functionality to your application,
5:36 if you need to do additional configuration, you can do all that by modifying this Ansible playbook. We can rerun this over and over again,
5:44 as our code changes, keep our application updated. And finally have a repeatable automated way to do our deployment.