This article is intended for those with Python Web foundation

Author: HelloGitHub- Squeaks

HelloGitHub introduces Zappa, a Serverless framework for Python.

Zappa makes it easy to deploy Python applications: just a few commands, package code, upload to the cloud, go live, and bingo! Thus reduce deployment cost, put down the heavy burden of operation and maintenance. All you need is a little Python Web foundation!

How convenient is it? An order to deploy immediately!

Project address: github.com/Miserlou/Za…

Let’s try it out!

One, foreword

1.1 introduce Serverless

At the beginning, I mentioned a puzzling term: Serverless. I was also doubtful at the beginning. After many searches, we can simply assume that Serverless means to build and run applications without worrying about the underlying infrastructure and the need to manage servers. The specific concepts are as follows:

1.1.1 What the hell?

Recall the process of launching a simple Python Web application.

  • A server that runs 24 hours a day: a cloud host, for example, to set up the code environment and configure the systems that keep our applications running;
  • Deploy a Web server: Select an appropriate Web server, configure and start it, and implement reverse proxy and load balancing.
  • Domain binding: Finally, if we want to be widely accessible, we need to register the domain name and bind it to the server;
  • Operations and Maintenance: Configuration and startup After the application goes live, we also need to manage and maintain our servers to prevent hacker attacks and cope with future user access peaks.

For applications using Serverless architecture, we only need to care about our application writing and core business, without worrying about cloud host, operating system, resource allocation, Web server configuration and other related issues, without considering server specifications, storage types, network bandwidth, automatic expansion and scaling. There is no need to operate and maintain the server, continuously install and apply system patches, and back up data. Everything non-core is outsourced to public cloud operators, freeing developers from complex deployment and operations environments to focus on the value of the business itself.

To use a Zappa phrase, “without any permanent infrastructure.”

Knocking on the blackboard, despite the name being Serverless, still requires a physical server, but we developers are out of the way.

1.1.2 What are the benefits?

  • Reduce operation and maintenance requirements and maintenance costs;
  • Fully automated flexible capacity expansion and reduction: During peak service hours, the computing capacity and capacity of the product automatically expand to accommodate more user requests. Conversely, when the business declines, the resources used will shrink at the same time to avoid resource waste.
  • Cost savings and a new metered pricing model: developers only need to pay based on usage. In the case of no business volume, no idle resources will be occupied and no expenses will be incurred.

1.1.3 It is generally believed that Serverless = FaaS + BaaS

  • BaaS (Backedn as a Service)
    • Back-end refers to a variety of cloud products and cloud services, such as object storage OS, message queue MQ, cloud database DB, cloud cache Redis and various services provided in the form of API. Users can use it without considering o&M tasks such as deployment, capacity expansion, backup, and security.
  • FaaS (Functions as a Service)
    • As the core of Serverless, users only need to write and upload the core business code, and submit it to the platform to complete the deployment, scheduling, traffic distribution, elastic scaling and other capabilities. It provides a new way to provide computing resources, further reducing the threshold of cloud computing.

1.1.4 AWS Lambda

In this project, we offer free AWS Lambda package for overseas ACCOUNTS of AWS. AWS Lambda, launched by Amazon in 2014 as the earliest framework product for Serverless, is a Serverless computing service that runs code without preloading or managing a server. Lambda can run code for almost any type of application or back-end service, simply upload the corresponding code, and it takes care of all the work needed to run and extend the code.

1.2 Python Serverless framework

Enter Zappa! We can use the Zappa tool to test Serverless technology for Serverless deployment of our Python applications and experience the speed of unlimited scaling, zero downtime, and zero maintenance. With Zappa, we don’t have to:

  • Configuring the Web Server
  • Paid 24/7 server uptime
  • Worry about load balancing and scalability
  • Keep your server online at all times

Two, do it yourself

Flask time: Now that I’ve had some success deploying a simple Flask application, don’t be afraid to follow along

2.1 environment

  1. Python version: 3.6/3.7/3.8
  2. Test system: Ubuntu 18.04.4LTS

2.2 to prepare

  1. Make sure your projects are running in a virtual environment.

    Python 3.x is required
    python --version
    
    # installation Pipenv
    pip install --user pipenv
    
    # Get into your own projects
    cd demo
    
    Instantiate pipfile and venv
    pipenv shell
    Copy the code

  2. Install Zappa and Flask, add additional libraries if needed.

    $ pipenv install zappa flask
    Copy the code

  3. Pipenv run python my_app.py = pipenv run python my_app.py = pipenv run python my_app.py

    from flask import Flask
    app = Flask(__name__)
    
    @app.route('/')
    def hello() :
        return "hello, from Zappa! \n"
    
    if __name__ == '__main__':
        app.run()
    Copy the code
  4. Register an AWS account, and install the AWS Credentials file correctly

    • Log in to AWS and find the Access Keys (Access Key IDS and Secret Access keys) under My Security Credentials. If none exist, create one. Remember the Access Key ID and Secret Access Key

    • Install the AWS CLI and add the credentials

      Install in a virtual environment
      pipenv install awscli
      
      # View information
      aws configure list
      
      Add the access key ID and Secret Access key as prompted
      aws configure
      
      # Region name and Output Format are optional
      Copy the code

    • The config file and the credentials file are displayed in the ~/. Aws directory. The credentials file contains the ACCESS key ID and secret Access key of AWS. The config command stores region name and output format.

    • If you are using Windows, check out the tutorial on installing the AWS Credentials file.

2.3 Installation and Configuration

  1. Initialize by executing the following statement to define the deployment and configuration Settings, automatically detecting the application type (Flask or Django)

    $ zappa init
    Copy the code

    The following Settings may be required during execution and can be modified later in the newly generated zappa_setting.json configuration file:

    When we’re done, we’ll have a zappa_settings.json file in our project directory that contains the basic deployment Settings we just defined, which we can modify later to suit our needs.

    {
        "dev": {
            "app_function": "my_app.app"."profile_name": null."project_name": "demo"."runtime": "python3.6"."s3_bucket": "zappa-ti0ra29xi"}}Copy the code
  2. Notice If the region information has been added to the ~/. Aws /config file, the region information will be automatically found during Zappa init. No further modification is required.

    If not, modify zappa_settings.json to add region information as follows:

    # change it as follows
    {
        "dev": {
            "app_function": "my_app.app"."profile_name": null,
            "project_name": "demo"."runtime": "python3.6"."s3_bucket": "zappa-ti0ra29xi"
            "aws_region": "us-west-2"}}Copy the code

    You can select region information. For details, go to.

2.4 Deployment and Usage

After configuring the Settings, you can package and deploy the application using the following commands:

$ zappa deploy dev
Copy the code

When we call deploy, Zappa automatically packages our application and local virtual environment into a Lambda-compatible Archive, replaces all dependencies with pre-compiled versions for Lambda, sets up functionality handlers and the necessary WSGI middleware, Then upload archive to S3, create and manage the necessary Amazon IAM policies and roles, register them as new Lambda functions, create new API gateway resources, create WSGI-compatible routes for them, Link it to the new Lambda Function, and finally remove the Archive from the S3 bucket.

After successful execution, a link appears that takes you to our simple Web application. When I saw the online application, I was so pleased that I cried out fast and accurate.

Other commands

  1. Update action: Assuming that the application is already deployed and only needs to upload the new Python code without modifying the underlying route, you can do the following:

    $ zappa update dev
    Copy the code

    This will create a new Archive, upload it to S3 and update Lambda Function to use the new code.

  2. To view the status of deployment and event plans, simply use the command:

    $ zappa status production
    Copy the code
  3. View deployment logs:

    $ zappa tail dev
    
    # filter HTTP requests
    $ zappa tail dev --http
    
    Do the opposite and display only non-HTTP events and log messages
    $ zappa tail dev --non-http
    
    # Select duration
    $ zappa tail dev --since 4h # 4 hours
    Copy the code
  4. Rollback action: Rolls back the deployed code to a previous version by providing the number of revisions to return.

    Roll back to the version deployed three years ago
    $ zappa rollback production -n 3
    Copy the code
  5. Modify zappa_setting.json to add the following:

    {
        "dev": {..."events": [{
                // The function to execute
                "function": "your_module.your_function".// When to execute it (in cron or rate format)
                "expression": "rate(1 minute)"}],... }}Copy the code

    Then do the following, and our function will execute every minute.

    $ zappa schedule dev
    
    # cancal
    $ zappa unschedule dev
    Copy the code
  6. Undeploy: To remove previously released API Gateway and Lambda Function, simply:

    $ zappa unschedule dev
    Copy the code

Four, step on the pit suggestions

Before the successful operation of a pit, tens of thousands of times, all because of their own hands and eyes blind magic changed a lot of places, the experience of the error recorded, to share with the small white like me.

  1. “Unable to import module ‘handler’ : CHS relative import with no known parent package () : CHS relative import with no known parent package ()

  2. If the following error message is displayed, replace the region information. If the fault is rectified, go to.

    $ zappa deploy dev
    Calling deploy for stage dev..
    Creating demo-dev-ZappaLambdaExecutionRole IAM Role..
    Error: Failed to manage IAM roles!
    You may lack the necessary AWS permissions to automatically manage a Zappa execution role.
    Exception reported by AWS:An error occurred (InvalidClientTokenId) when calling the CreateRole operation: The security token included in the request is invalid.
    To fix this, see here: https://github.com/Miserlou/Zappa#custom-aws-iam-roles-and-policies-for-deployment
    Copy the code
  3. If we’re in zappa init, don’t use the default distribution s3_bucket, must pay attention to the same name is not allowed in his own name, click to view the official method, otherwise an error botocore. Errorfactory. BucketAlreadyExists: An error occurred (BucketAlreadyExists) when calling the CreateBucket operation: The requested bucket name is not available. The bucket namespace is shared by all users of the system. Please select a Different name and try again.

Write at the end

When I successfully deploy, I suddenly feel wonderful and relaxed, as if I no longer have the complicated process mentioned before, but a few commands, white PIAO AWS service, our application is easily online, don’t you quickly share the generated link to your friends to click on it.

So far, we have basically implemented the quick deployment of a simple Flask application. Due to lack of space, some of Zappa’s advanced features are not mentioned, and how to use Zappa to deploy Django applications or larger projects (including databases, etc.). I hope interested partners can try more, I have begun to look forward to rubbing hands. If you are interested in open source projects, please pay attention to HelloGitHub for the first time and we will bring you more interesting dry goods content.