FULL STACK PYTHON GUIDE TO DEPLOYMENTS PDF

adminComment(0)
    Contents:

Deploy Python provides details on every Full Stack Python deployments book for Flask and Django. Sep 9, Full Stack Python An open book that explains concepts in plain language and provides the most helpful resources on creating, deploying and. Full Stack Python explains each layer of the web application stack, from the server up through the Learn Python the Hard Way is a free book by Zed Shaw. Dive into Python 3 is an open source book provided under the Creative Commons license and available in HTML or PDF form. I need to know how to deploy it.


Full Stack Python Guide To Deployments Pdf

Author:HOSEA PILGER
Language:English, French, Portuguese
Country:Finland
Genre:Art
Pages:281
Published (Last):05.05.2015
ISBN:625-5-64332-262-6
ePub File Size:30.74 MB
PDF File Size:12.82 MB
Distribution:Free* [*Sign up for free]
Downloads:22322
Uploaded by: CANDIE

Jul 31, Before joining Twilio, Matt Makai, our San Francisco-based Developer Evangelist , drove across America on a ronin-type quest to learn more. Your web app deployment. Server(s) / Platform-as-a-Service. H Operating system . JavaScript /css. Web server(s). - File system. T.,,.Il 1. HTTP(S) responses. Full Stack Python Guide to Deployments - Ebook download as PDF File .pdf), Text File .txt) or read book online. Python guide to deployments.

Click "Add this Linode! Refresh the page and look for the status to change to "Brand New. A page will appear to show more information about your new virtual private server. We're going with Ubuntu Therefore this version will receive security updates until April as shown on the Ubuntu wiki page for LTS releases.

Select Ubuntu Make sure you type the password in carefully and remember it! We'll need the password again in a few minutes to log in as our root user. We'll see the progress bars start to increase and in a couple of minutes it'll be ready to boot up. However, don't start up the server just yet. We need to create a public-private key pair that will be used to harden our new server against unauthorized login attempts.

Create Public and Private Keys Before we boot up our newly-provisioned server we need to create a public-private key pair on our local machine. Once we are using the key pair we can disable password logins for increased security. In addition, we won't have to type in a password each time we want to access the server via SSH, which is super convenient for quick logins.

If you already have an SSH key pair you want to use then feel free to skip on to the next section. However, if your existing key pair has a passphrase on it you'll want to follow these steps to create a new key pair.

This book uses a passphrase-less key pair to perform the automated deployments as well as minimize the typing during our manual deployment process. Again, if you are on Windows you'll need to set up VirtualBox with a Linux instance to follow these commands.

Create a local directory with the following commands to store our key pair.

Remember that there is also a companion GitHub repository with all 28 this code and tags for each chapter in case you do not want to type everything in yourself. However, even if you use the code in the repository you'll have to create your own public-private key pair with these steps since the key pair cannot be shared.

Throughout this book we will refer to the fsp-deployment-guide directory as the base directory for our deployment files.

Post navigation

Execute the following ssh-keygen command to create the public-private key pair. When prompted for a file in which to save the keys do not use the default. Instead, enter the following directory and file into the prompt.

Press enter twice when prompted for a passphrase. We will not use a passphrase for the deployer user's keys. The key pair will be generated by ssh-keygen. The private key should never be shared with anyone as it will allow access your server once it's 29 setup. Hosting Options Let's consider our hosting options before diving into the deployment on the Linode virtual private server. There are four general options for deploying and hosting a web application: System packages.

What are Virtualized Servers? Virtual private servers VPSs are virtualized slices of hardware run on top of a physical server. They're a stable company with solid support when issues occur. Virtualization software such as Xen and VMWare allow a providers' customers to use fractions of a full server that appear as their own independent instances.

Step-by-Step Instructions to Deploy and Operate Python Web Apps

But for our web application deployment. The primary disadvantage of virtualized servers is that there is resource overhead in the virtualization process. WSGI server. The application code can be pulled from a source controlled repository and configured in the environment. The deployer needs to provision one or more servers with a Linux distribution. I've used Linode for over five years now. If you're considering a different provider make sure to check the resources section at the end of this chapter for evaluating VPS alternatives.

You typically get what you pay for in the VPS hosting industryc. There are plenty of VPS hosting options. A note before we get started. Within the code snippets there are lines prefixed with that are comments. With that note out of the way. Each step will explain what to do along with some context. You don't have to type the comments in. Let's obtain a Linode account. Point your web browser to Linode. Throughout this book the instructions will follow a standard format.

Full Stack Python Guide to Deployments

Their landing page will look something like the following image. Fill out the appropriate information and add initial credit to your account. If you want to enter a referral code. You'll be sent an email for account confirmation. Sign up for an account. Your account You'll be given a page to add a Linode instance.

Once your account is activated refresh the page. Click "Add this Linode! Select the option. If your most of your users are located in a specific country or region you'll want to select the data center location closest to them. I chose Newark.

Refresh the page and look for the status to change to "Brand New. A page will appear to show more information about your new virtual private server. Therefore this version will receive security updates until April as shown on the Ubuntu wiki page for LTS releases.

We're going with Ubuntu Make sure you type the password in carefully and remember it!

We'll need the password again in a few minutes to log in as our root user. Select Ubuntu Remember that there is also a companion GitHub repository with all We need to create a public-private key pair that will be used to harden our new server against unauthorized login attempts.

This book uses a passphrase-less key pair to perform the automated deployments as well as minimize the typing during our manual deployment process. If you already have an SSH key pair you want to use then feel free to skip on to the next section.

Create Public and Private Keys Before we boot up our newly-provisioned server we need to create a public-private key pair on our local machine. We'll see the progress bars start to increase and in a couple of minutes it'll be ready to boot up. Once we are using the key pair we can disable password logins for increased security. In addition.

Create a local directory with the following commands to store our key pair. The key pair will be generated by ssh-keygen. Now you have two new files: Execute the following ssh-keygen command to create the public-private key pair.

Throughout this book we will refer to the fsp-deployment-guide directory as the base directory for our deployment files.

We will not use a passphrase for the deployer user's keys. When prompted for a file in which to save the keys do not use the default. Press enter twice when prompted for a passphrase. The private key should never be shared with anyone as it will allow access your server once it's Boot the Server and Secure It When we boot up the server we need to ensure it is locked down against unauthorized access attempts. Execute the following command to create one more new file with the newly created public key as an authorized key.

Bring up your local command line as we'll need it to connect to the remote machine. There are scores of malicious bots that search for servers across the IPv4 address range. With our new key files we can now fire up the server and set up our security configuration. When you're ready to begin the initial lock down steps we can start our machine up. Keep backups of these files in a safe place since once the server is locked down you'll need them to log in. Click the "Boot" button and the Ubuntu The Internet can be a dark place for unsecured servers.

Booting should take less than a minute. The public key can be shared with anyone and does not need to be kept private. Enter yes then enter the root password you created during the earlier Linode server provisioning step. This prompt is stating that you've never connected to this server before. You'll likely receive a prompt like the following warning.

The authenticity of host ' RSA key fingerprint is Next we're going to modify the SSH configuration so the root user account cannot be directly logged into. Ubuntu's package manager.

Only someone using the exact private key we created earlier can connect to this server. That will open the file in Vim. Ensure the system packages cache is up to date. You should see the following lines of the file in your editor. Let's install fail2ban with its sensible default settings. You will see a "Welcome to Ubuntu Now we can enter commands on the remote machine to get the server secured and setup.

Next upgrade all out of date packages. ListenAddress 0. Execute the following commands. Next we need to create a non-root group for the new non-root user we'll create in a few steps.

Edit PasswordAuthentication yes to the following. Modify UsePAM yes to the following. Save the file. Change PermitRootLogin yes to the following. Now add a non-root user with the non-root group we just created. Replace the name Matt Makai with your name but leave the quotes around You can change "deployers" to another group name if you want but you have to be consistent in future steps.

ChallengeResponseAuthentication no Change to no to disable tunnelled clear text passwords PasswordAuthentication yes We need to upload the public and private keys for the deployer user so we can log in with that account.

We'll need that in a minute. Go back to the command prompt on your local machine where the SSH keys we created earlier in this chapter are stored. Upload the Public Key In order to authenticate with our new deployer user. Create a directory for the new deployer user to store our public and private keys. Keep the root SSH connection open. You will be prompted to enter the same new password twice for this account.

Do not yet log off of root! In the terminal where root is logged in. Restart the SSH Service 1. Now try to SSH in with the new deployer user in the other terminal window. We can now close out our root connection! You won't be able to log directly into root any Again replace the IP address in this command with the IP address of your server. If you get a command prompt on the server. When prompted by the scp command enter the deployer's password that was created in the previous section.

Fill in the following blank fields then run this Fabric script with "fab bootstrap". Automating Server Setup Clearly we don't want to have to manually type in all these steps every time we create a new VPS instance.

Within prod create a new file named fabfile. Fortunately the Fabric library makes these instructions easy to automate. That's a really good thing because automated malicious bots often try to log into root with their attacks. Let's take a look at a short script that runs every step we just performed above. Also prevents SSH-ing in with the root user.

On your local machine. Matt Makai username for the new non-root user to be created env. Next edit line 21 with your server IP address that can be found on the dashboard of your Linode account. Change the value under env. Modify line 24 with your full name for the non-root user.

Within fabfile.

Create a virtualenv with the following commands. This virtualenv will hold our Python application dependencies. If you already have a directory where you keep your virtualenvs. Use the following pip command to install Fabric: You'll be prompted for a password for the new user and then the script will connect to the server again with that user to complete the steps we walked through manually earlier this chapter.

Execute the script from the local command line with fab bootstrap. We'll install that package as part of the Ansible scripts we're going to create in the next chapter. Be sure to take a look at the following links for learning reinforcement on initial server setup.

These initial basic security settings are a decent start over the default server settings. Note that this script does not install fail2ban like we did in the manual steps above. We will also introduce Ansible which will provide the rest of the automation necessary for the deployment. In the next chapter we'll establish the operating system configuration for running Python web applications. Ubuntu Linux Operating Systems An operating system runs on a server and controls access to computing resources that our web application will use to run.

An operating system makes many of the computing tasks we take for granted easy. Otherwise you'd need to control the CPU. Ubuntu Ubuntu is a Linux distribution packaged by the Canonical Ltd company. GNOME until the For desktop versions of Ubuntu. We will also lock down the operating system against unauthorized access attempts. LTS versions receive five years of post-release updates from Canonical. Every two years. Canonical creates a new LTS release. Ubuntu includes a package manager for installing necessary system libraries that we need to run our Python web application.

We performed this in the previous chapter to properly install fail2ban but it's always a good practice to update just before installing new packages. Installing Ubuntu Packages Ubuntu uses the Debian distribution as a base for packages. Windows and Mac OS X are not appropriate for our production deployment. As of First ensure the package manager's local cache is up to date. These packages are: Mac OS X. There are several required apt packages found on Linux servers running a Python stack.

With these packages in place we now have the basic system dependencies to get our Python environment running. It'll take a little while for the packages to get installed since Aptitude is downloading everything from the central Ubuntu package repositories. Enable the Firewall Ubuntu has a handy tool named Uncomplicated Firewall ufw..

When it's done you'll see something like the following line and you'll be back at the input prompt.

Next install the required packages for our Python web application deployment. We now need to enable the firewall with the following command: Processing triggers for libc-bin 2. This can either be under your project or a separate source control repository.

Our firewall is in place. If you want to skip typing these instructions in there's an open source GitHub repository that's tagged with steps for each chapter. Automating Operating System Setup Let's write the structure for the Ansible playbook which we'll fill in throughout each chapter's automation section from now on.

We'll also build on the Ansible scripts. Ansible Ansible is an open source configuration management tool written in Python that will allow us to automate the steps we performed manually above.

In the last chapter we created a prod directory for our fabfile. Remember to keep your confidential information such as usernames and passwords private! Ansible has hundreds of built-in modules to execute tasks for setting up and running servers.

The source code for every module is freely available on Ansible's GitHub repository. We just created a new file for the main YAML playbook named deploy. Next we're going to fill in the roles that will automate the steps we otherwise would have to manually execute. We also created a hosts file that'll tell Ansible what server IP addresses we should deploy to. This playbook deploys the whole application stack in this site.

Fill in the hosts file with the following text. The variables won't be used until we fill out roles that have the variable tokens in them. Replace We need to set variables to complete the roles. Some of these directories will be used later to set up the database and web server. We need to create the ubuntu. Chapter 3: Let's automate the first steps we took on the server where we manually updated the apt repository and installed required system packages.

Be sure to set the appropriate permissions on the file. Use the following pip command to install Ansible: Make sure to specify the location where you created the virutalenv back in chapter 2. We've created the basic outline of an Ansible playbook that automates what our manual instructions set up so far.

We need to install Ansible into our virtualenv. Now we can invoke that file by running it on the command line as follows.

You'll be asked for the sudo password once to kick things off then if everything's been typed in properly this playbook will automate the manual steps from this chapter and the previous one. In the next chapter on web servers we can configure the Nginx web server which was just installed through a system package. Additional Operating System Resources The following references provide greater insight into Linux distributions and how to deploy on Ubuntu.

Additional Ansible Resources Ansible is a powerful configuration management tool.

The following resources will help you get more comfortable with using Ansible. Shell Scripts explains why automating with Ansible instead of shell scripts is a good idea. In our deployment, the web server handles serving up static files like our CSS and JS, while serving as a proxy that passes requests to the WSGI server and the response back to the web browser. Nginx is used by many of the top websites on the Internet.

Web Servers in Our Deployment The web server in our deployment will perform two roles:. The web server sends files to a web browser based on the browser's requests. A reverse proxy is simply a middleman that accepts an incoming HTTP request and passes it along to the WSGI server so it can process the request and issue a response.

In the first request. The web browser then accessed site. CSS and images. For the second use case the web server be a reverse proxy to pass on requests to our WSGI server so it can run our Python code and craft the response.

That scenario is shown in the following image. While both Nginx and Apache are fantastic pieces of software. Nginx In our deployment we'll use the Nginx web server. In this case the web server is configured to pass requests for non-static files to the WSGI server. In this case. Nginx is used at the largest scale by many organizations on the web so you won't have to worry about swapping it out later for Apache. First install the nginx package via apt on our remote machine.

Before we install and configure Nginx on our server we'll need to perform two steps: Installing Nginx We need to use the system package manager to install Nginx just as we did with fail2ban and our Python packages. Start by going to https: Sign up for an account or sign in to your existing account. Select the domain name you want to set up for this application. If you want your application to use encryption and it should!

In this case we'll deploy with the cyoa. Save the newly entered information. Both options are included in this chapter. There are two choices here. If instead you want a different subdomain. Note that we'll need to use sudo privileges to create and save the file within Nginx's configuration directory. If you want the standard www in your URL.

Add the following lines to the file. It may take a few minutes to take effect as the data must be propagated to many Domain Name System hosts. The certificates will get uploaded manually and then we'll modify the Ansible playbook to handle the step in the future. That means this certificate will give a warning on most browsers if you access the web application because the certificate has not been blessed by a central certificate authority.

Next we create a self-signed certificate. Execute these commands on your local machine. Generate a private key file using the openssl command as follows. Create a subdirectory from our base directory to hold our SSL certificate files as we generate them.

If you have trouble with the following steps be sure to read this detailed guide on creating a self-signed certificate. Replace this self-signed certificate with the certificate from a valid CA and those browser warnings will go away. California Locality Name eg. San Francisco Organization Name eg.

Common Name e. Not all questions need to be answered. If you enter '. Enter a passphrase. Enter pass phrase for ssl. What you are about to enter is what is called a Distinguished Name or a DN. Then you'll be prompted for a passphrase as shown below.

You are about to be asked to enter information that will be incorporated into your certificate request. There are quite a few fields but you can leave some blank For some fields there will be a default value.

My example information is shown below. Some of the questions. Next we need to generate a certificate signing request CSR. Fill in the information to the questions with your information.

Now you have an ssl. Within the directory that stores A challenge password []: An optional company name []: Now we need to configure it to serve up static files as well as pass requests to the WSGI server that we will set up later. There is no passphrase on cyoa.

From our local machine we need to copy in the SSL keys we just generated. Log back into your remote server. Create a directory to store the SSL certs temporarily on thed remote server. Install SSL Certificates Nginx was already installed on our server in chapter two when we executed apt-get install nginx. Remove the passphrase from the key file because it's a pain when using automation to start and stop the web server as the passphrase would need to be entered for all operations.

We'll also prepare it for passing requests to the WSGI server that will be set up in a later chapter. Nginx's configuration can only be changed with root privileges so with the deploy user first execute this command to ensure the rest of these steps are performed with superuser privileges.

Perform the following commands on the deployment server. Change into the Nginx configuration directory. Delete the SSL certificates from the home directory.

Create an SSL directory for our Nginx web app. Remember to use the IP address of your server instead of the one shown in this command.

Copy the SSL certificate files from the home directory. Before the application We handle the restarting of Nginx in the next section. Restarting Nginx We need to restart the Nginx server to enable our new configuration. If you're running through the manual steps first you can now flip to the next chapter on source control. Since this chapter had the option of using either plain old HTTP or Delete the default website file if it exists.

Restart Nginx so the new configuration takes effect. That's the subject of the next chapter. Automating the Nginx Configuration We need to add new files to our Ansible playbook to automate the Nginx configuration. To learn how to automate the Nginx configuration steps we just performed. Configuration for Nginx web server. Chapter 4: Ensure the file has the follow contents. The result is a file on our server that contains the same configuration file we otherwise would have to write manually.

Append the following YAML to the existing file. Create a file named main. Write the following contents into the file.

Now we can run our Ansible playbook again with our shell script to install and configure Nginx on our server. Additional Web Server Resources There are numerous guides that explain the underlying concepts web servers implement as well as how Nginx works.

Version 2. This handler allows us to restart Nginx during the playbook execution when it's necessary such as upon a configuration file modification. There is one more file to create before Ansible will have what it needs to automate the set up of the web server. Source Control In the next chapter we'll use Git to clone our source repository and ensure the appropriate code is on our server for the rest of the deployment.

An Introduction provides exactly what developers need to start using Nginx. Source Control Source control. Version control systems allow developers to modify code without worrying about permanently screwing something up. Unwanted changes can be rolled back to a previous working code state. In an application deployment. In this chapter. One developer can combine her code modifications with other developers' code by viewing differences in the code and merging in appropriate changes.

Our deployment will use the source control deployment approach for getting our code onto the production server. Note that some developers recommend deployment pipelines package the source code to deploy it and never have a production environment touch a source control system directly.

This method for deploying code via the git clone and git pull commands will make our deployment process look like the following diagram. Source control also eases developing software for teams. You can transition away from the service at a later time by moving your repositories to your own server if your needs change.

Execute the following command to create a new public-private key pair. Creating a Deploy Key We need to create a deploy key separate from the key we use to log into the server. A couple of recommended hosted version control services are: Perform these commands on your production server. Hosted Source Control Services We could install Git on a remote server and use that server to back up our source control.

This deploy key will grant read-only access from our server to the single repository that we want to use the commands git clone and git pull to grab our code. As mentioned earlier. They cannot be used interchangeably. Now you again have two new files: The following steps will walk through how to make that happen.

Press the fork button and select where to fork the repository. Click "Deploy Keys" on the left navigation bar. We need to add the deploy key we just created so that our new server can pull down the code. Click the settings link on the right navigation bar within the forked repository's page. Two text boxes will appear on the screen.

Do not allow write access. Press the "Add Key" button. Now you're all set to clone this forked repository's code onto your production server. Pulling Project Code to the Server Git is not yet installed on the server so the first step will be to get the system package dependency. Then we can pull down the application code from GitHub with our new deploy key. Install the git-core package via apt on our remote machine. Clone the remote Git repository so we have a copy of it on the server.

If the repository is private the deploy key will grant you access. Be sure to use your username in the below command with the fork we created earlier.

Continuous deployment at Instagram is the story of how their deployment process evolved over time from a large Fabric script to continuous deployments.

Along the way they encountered issues with code reviews, test failures, canary builds and rollbacks. It's a great read that sheds some light on how Python deployments can be done well at large scale. Stack Overflow's guide on how they do deployment is an awesome in-depth read covering topics ranging from git branching to database migrations. In this free video by Neal Ford , he talks about engineering practices for continuous delivery. He explains the difference between continuous integration , continuous deployment and continuous delivery.

Highly recommended for an overview of deployment concepts and as an introduction to the other videos on those subjects in that series.

Deployment learning checklist If you're tight on time look at the platform-as-a-service PaaS options. You can deploy a low traffic project web app for free or low cost. You won't have to worry about setting up the operating system and web server compared to going the traditional server route. In theory you should be able to get your application live on the web sooner with PaaS hosting. Traditional server options are your best bet for learning how the entire Python web stack works.

You'll often save money with a virtual private server instead of a platform-as-a-service as you scale up.Instead, enter the following directory and file into the prompt. Google's Python Class contains lecture videos and exercises for learning Python. When you read Full Stack Python you will understand deployments at a high level, but will not know the exact commands to, for example, configure an Nginx web server or set up continuous integration.

Select the option, month-to-month billing and the data center location of your choice. Publication date: Boot the Server and Secure It When we boot up the server we need to ensure it is locked down against unauthorized access attempts.

Computer Languages. This book uses a passphrase-less key pair to perform the automated deployments as well as minimize the typing during our manual deployment process.

However, even if you use the code in the repository you'll have to create your own public-private key pair with these steps since the key pair cannot be shared.

EARNESTINE from Huntsville
I do enjoy reading comics roughly . See my other posts. I take pleasure in radio-controlled car.
>