[PYTHON] Erstellen Sie mit Chalice eine flaschen- / flaschenähnliche Webanwendung auf AWS Lambda

Einführung

Wenn Sie eine kleine Webanwendung erstellen möchten, verwenden Sie Python Flask oder Bottle. ) Kann verwendet werden. Diese Frameworks können mithilfe von Python-Dekoratoren realisiert werden, um "welche URL" und "welches Programm ausgeführt wird" zu unterstützen. Die folgende Flask-Anwendung implementiert beispielsweise einen Webserver, der "Hallo Welt!" Zurückgibt, wenn der HTTP-Zugriff auf "/" erfolgt und die Antwort auf die Routing-Antwort sehr einfach zu verstehen ist.

Zitiert von Flask's offizieller Seite

# https://flask.palletsprojects.com/en/1.1.x/quickstart/
from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello, World!'

Jetzt funktionieren diese Webanwendungen reibungslos, wenn sie zu Entwicklungszwecken lokal ausgeführt werden. Wenn Sie jedoch versuchen, es als Produktionsvorgang auf einem anderen Server auszuführen, müssen Sie einen zugänglichen Server beschaffen oder Middleware wie "nginx" + "uwsgi / gunicorn" ausführen, also vom Abschluss der Entwicklung bis zur Produktion Der Eindruck ist, dass vor dem Betrieb viele Dinge vorzubereiten sind. Berücksichtigen Sie insbesondere für den Server, ob der Server neben der Anwendung normal funktioniert, z. B. die laufenden Kosten (tatsächliche Kosten), die Tatsache, dass die laufende Middleware nicht verfügbar ist und der Dienst nicht bereitgestellt werden kann, die Festplatte voll ist usw. Es besteht die Idee, dass ich den Server nach Möglichkeit gar nicht erst verwenden möchte, z. B. die Notwendigkeit, sich mit dem Ablauf der Sicherheitsunterstützung für das Betriebssystem und die Middleware zu befassen. Aus dieser Motivation

• Sie können mit Python eine Webanwendung mit einer einfachen Beschreibung wie Flask / Bottle erstellen.
• Die oben genannte Webanwendung kann ohne Verwaltung des Servers betrieben werden.

Ich habe mich gefragt, ob diese beiden Punkte gelöst werden können, und als Ergebnis konnte ich dies mithilfe des Mikroframeworks Kelch für AWS Lambda erreichen. Daher werde ich diese Methode einführen. ..

TL; DR

--Verwenden Sie in der Antwort von Chalice "text / html"

• Implementieren Sie eine lokale Route, die statische Dateien für lokale Tests zurückgibt
• Wenn Sie verschiedene Inhalte zurückgeben, sollten Sie nginx auf local setzen und es als Proxy verwenden. --Chalices @ app.route muss so konfiguriert sein, dass POST aus dem HTML-Formular empfangen wird
• Verwenden Sie CloudFront, um statische Dateien an S3 Origin zu streamen, andernfalls an API Gateway, das mit Chalice bereitgestellt wird
• Im Fall von API Gateway wird immer als "https: // / /" zugegriffen, aber unter Verwendung des Ursprungspfads von CloudFront wird der Zugriff auf oberster Ebene ("https: // /" verwendet. Selbst wenn Sie ) tun, können Sie zu einem bestimmten Zeitpunkt auf /` von API Gateway zugreifen.

Konfigurationsdiagramm für Service und Infrastruktur

Dieser Artikel behandelt viele der in AWS verfügbaren Ressourcen.

--API Gateway + AWS Lambda (automatisiert von Chalice) --CloudFront (der erste Endpunkt, der für den Site-Zugriff verwendet wird) --Amazon S3 (Speicherort statischer Dateien wie image / css / js) --Route 53 (Zuweisung der ursprünglichen Domain) --Certificate Manager (Ausstellen und Verwalten von SSL-Zertifikaten, die von CloudFront verwendet werden)

Die Grundeinstellungen und die Verwendung der einzelnen Dienste werden in diesem Artikel nicht behandelt.

Eine Illustration dieser Beziehungen ist wie folgt.

Implementierung von Webanwendungen

Ich stelle den gesamten Code auf Gtihub bereit, da die Codemenge moderat ist.

https://github.com/t-kigi/chalice-lambda-webserver-example

Der Code wird von Zeit zu Zeit in Anführungszeichen gesetzt. Den Gesamtablauf finden Sie in diesem Repository.

Gebrauchte Version etc.

Die Entwicklungsumgebung ist Ubuntu 18.04.

$ pipenv --version
pipenv, version 2018.11.26
$ pipenv run chalice --version
chalice 1.20.0, python 3.8.2, linux 5.4.0-48-generic

Für die Entwicklung von Webanwendungen erforderliche Kelcheinstellungen

1. Antwortunterstützung

Informationen zum Einrichten des Kelches usw. Ich habe bereits einen Artikel geschrieben finden Sie hier. Dieses Mal wird das Projekt als "Kelch-New-Project-Server" erstellt.

Das Standardverhalten von Chalice besteht darin, es für API-Zwecke zu verwenden. Wenn also nichts festgelegt ist, wird eine application / json-Antwort zurückgegeben. Wenn Sie jedoch eine Seite zurückgeben, die von einem Browser als Webanwendung angezeigt werden kann, ist es besser, eine Antwort von "text / html" zurückzugeben. Dazu müssen Sie den ContentType des Antwortheaders auf "text / html" setzen. Bei der Implementierung des obigen Flask-Beispiels mit Chalice lautet der Code wie folgt.

Wenn das Kolbenbeispiel in Kelch umgeschrieben wird(app.py)

from chalice import Chalice, Response
app = Chalice(app_name='server')

@app.route('/')
def index():
    return Response(
        status_code=200,
        headers={'Content-Type': 'text/html'},
        body='Hello, World!')

2. Einführung der Template Engine

Übrigens, wenn Sie so viel einstellen, wird der im Body geschriebene Inhalt mit "text / html" an die Client-Seite zurückgegeben. Mit anderen Worten, indem Sie eine Seite mit der Vorlagen-Engine erstellen und das Endergebnis an den Text senden, können Sie dasselbe tun wie mit einer Webanwendung, die die Vorlagen-Engine verwendet. Ich verwende hier "jinja2" als Vorlagen-Engine, aber wenn Sie eine andere Vorlagen-Engine verwenden möchten, ist das in Ordnung.

Diesmal ist die Verzeichnisstruktur wie folgt (Auszug nur notwendiger Teile)

.
├── app.py             #Kelches Einstiegspunkt
└── chalicelib         #Alle Dateien, die bereitgestellt werden sollen, müssen sich unter chalicelib befinden
    ├── __init__.py
    ├── common.py      #Platzieren Sie allgemeine Elemente, um andere von einem anderen Modul aus anzurufen
    ├── template.py    # chalicelib/Funktionen zum Laden von Vorlagen aus Vorlagen usw.
    └── templates      #Legen Sie die Vorlage darunter
        ├── index.tpl
        └── search.tpl

chalicelib/common.py(Auszug)

#Kelchobjekt, das von mehreren Dateien gemeinsam genutzt wird
app = Chalice(app_name='server')

#Der Pfad des Verzeichnisses, in dem sich das Projekt befindet
chalicelib_dir = os.path.dirname(__file__)
project_dir = os.path.dirname(chalicelib_dir)

chalicelib/Vorlagen Einstellungen, mit denen die folgenden Vorlagendateien abgerufen werden können(template.py)

import os
from jinja2 import Environment, FileSystemLoader, select_autoescape
from chalicelib.common import project_dir


template_path = os.path.join(project_dir, 'chalicelib/templates')
loader = FileSystemLoader([template_path])
jinja2_env = Environment(
    loader=loader,
    autoescape=select_autoescape(['html', 'xml']))


def get(template_path):
    '''Vorlage abrufen'''
    return jinja2_env.get_template(template_path)

Ein Beispiel für das Lesen von "chalicelib / templates / index.tpl" aus "app.py" ist wie folgt.

app.py

from chalicelib import template
from chalicelib.common import app


def html_render(template_path, **params):
    '''Gibt die HTML-Rendering-Antwort zurück'''
    tpl = template.get(template_path)
    return Response(
        status_code=200,
        headers={'Content-Type': 'text/html'},
        body=tpl.render(**params))


@app.route('/')
def index():
    '''Zurück zur obersten Seite'''
    return html_render('index.tpl')

3. Lokale Überprüfung

Verwenden Sie den Befehl chalice local zur Überprüfung in der lokalen Umgebung. Ich persönlich möchte jedoch häufig unterschiedliche Einstellungen für die lokale Umgebung und die Umgebung nach der Bereitstellung festlegen. Daher wird empfohlen, eine "lokale" Phase für die lokale Überprüfung zu erstellen. Wenn Sie beispielsweise eine lokale Bühne erstellen

• Zugriff auf AWS-Ressourcen mit Profil nur in der lokalen Phase (IAM-Rolle wird während der Produktion verwendet, daher wird Profil nicht verwendet)
• Definieren Sie eine Route, die nur in der lokalen Phase gültig ist

Kann realisiert werden

Fügen Sie den "lokalen" Bereich zu "Stufen" in ".chalice / config.json" hinzu, um die lokale Stufe zu erstellen.

{
  "version": "2.0",
  "app_name": "server",
  "stages": {
    "dev": {
      "api_gateway_stage": "v1"
    },
    "local": {
      "environment_variables": {
        "STAGE": "local"
      }
    }
  }
}

Nachdem Sie dies hinzugefügt haben, starten Sie es als "chalice local --stage local" (wenn es bereits ausgeführt wird, stoppen Sie den Prozess und starten Sie es neu). Jetzt wird die Umgebungsvariable "STAGE" nur dann mit dem Wert "local" definiert, wenn sie als "--stage local" ausgeführt wird.

4. Antwortunterstützung für statische Dateien

Die in der Entwicklung verwendeten statischen Hauptdateien sind Bilder, CSS und JavaScript-Code. Daher wird der Pfad zum Platzieren dieser Dateien festgelegt, und beim Zugriff darauf werden diese Dateien gelesen und zurückgegeben. Ich habe diese Dateien endlich in S3 hochgeladen und außerhalb von "chalicelib" abgelegt, weil ich nicht möchte, dass sie in Lambdas Uploads enthalten sind. Die vorbereitete Verzeichnisstruktur ist wie folgt.

Auszug nur des Teils, der zur Erläuterung der statischen Datei erforderlich ist

.
├── server
│   ├── app.py
│   ├── chalicelib
│   │   ├── __init__.py
│   │   ├── common.py
│   │   └── staticfiles.py
│   └── static -> ../static
└── static
    ├── css
    │   └── style.css
    ├── images
    │   ├── sample.png
    │   └── sub
    │       └── sample.jpg
    └── js
        └── index.js

Wenn Sie den Server mit "chalice local --stage local" ausführen, wird der Server unter "localhost: 8000" eingerichtet. Daher möchte ich es hier so einstellen, dass "static / images / sample.png " durch Zugriff auf "http: // localhost: 8000 / images / sample.png " abgerufen werden kann. Um dies zu erreichen, habe ich chalicelib / staticfiles.py vorbereitet.

chalicelib/staticfiles.py

#!/usr/bin/python
# -*- coding: utf-8 -*-

'''
Eine Implementierung, die eine statische Datei zurückgibt, die mit chalice local funktioniert.
CloudFront in Produktion->Weil es auf dem Weg zu S3 behandelt wird
Es soll nur während der Entwicklung verwendet werden.
'''

import os

from chalice import Response
from chalice import NotFoundError
from chalicelib.common import app, project_dir


def static_filepath(directory, file, subdirs=[]):
    '''Generieren Sie den Pfad der statischen Datei auf dem lokalen Server und geben Sie ihn zurück'''
    pathes = [f for f in ([directory] + subdirs + [file]) if f is not None]
    filepath = os.path.join(*pathes)
    localpath = os.path.join(project_dir, 'static', filepath)
    return (f'/{filepath}', localpath)


def static_content_type(filepath):
    '''Inhalt für statische Datei-Gibt den Typ zurück'''
    (_, suffix) = os.path.splitext(filepath.lower())
    if suffix in ['.png', '.ico']:
        return 'image/png'
    if suffix in ['.jpg', '.jpeg']:
        return 'image/jpeg'
    if suffix in ['.css']:
        return 'text/css'
    if suffix in ['.js']:
        return 'text/javascript'
    return 'application/json'


def load_static(access, filepath, binary=False):
    '''Statische Datei lesen'''
    try:
        with open(filepath, 'rb' if binary else 'r') as fp:
            data = fp.read()
        return Response(
            body=data, status_code=200,
            headers={'Content-Type': static_content_type(filepath)})
    except Exception:
        raise NotFoundError(access)


@app.route('/favicon.ico', content_types=["*/*"])
def favicon():
    (access, filepath) = static_filepath(None, 'favicon.ico')
    return load_static(access, filepath, binary=True)


@app.route('/images/{file}', content_types=["*/*"])
@app.route('/images/{dir1}/{file}', content_types=["*/*"])
def images(dir1=None, file=None):
    '''
Antwort der Bilddatei für die lokale Umgebung
    (Wenn Sie auf Lambda bereitstellen, funktioniert dies aufgrund des Pfads nicht. Streamen Sie es daher mit CloudFront an S3)
    '''
    (access, filepath) = static_filepath('images', file, [dir1])
    return load_static(access, filepath, binary=True)


@app.route('/css/{file}', content_types=["*/*"])
@app.route('/css/{dir1}/{file}', content_types=["*/*"])
def css(dir1=None, file=None):
    '''
Antwort der CSS-Datei für die lokale Umgebung
    (Wenn Sie auf Lambda bereitstellen, funktioniert dies aufgrund des Pfads nicht. Streamen Sie es daher mit CloudFront auf S3)
    '''
    (access, filepath) = static_filepath('css', file, [dir1])
    return load_static(access, filepath)


@app.route('/js/{file}', content_types=["*/*"])
@app.route('/js/{dir1}/{file}', content_types=["*/*"])
def js(dir1=None, file=None):
    '''
Antwort der JS-Datei für die lokale Umgebung
    (Wenn Sie auf Lambda bereitstellen, funktioniert dies aufgrund des Pfads nicht. Streamen Sie es daher mit CloudFront an S3)
    '''
    (access, filepath) = static_filepath('js', file, [dir1])
    return load_static(access, filepath)

Es ist ein Modul, das die Funktion hat, die Dateien unter "statisch" zu lesen und die Antwort nur zurückzugeben, wenn der Pfad spezifisch ist. Um dies nur für die lokale Bühne zu aktivieren

app.py(Auszug)

import os

stage = os.environ.get('STAGE', 'dev')
if stage == 'local':
    #Wird nur verwendet, wenn lokal
    from chalicelib import staticfiles # noqa

Laden Sie einfach "staticfiles" als ("# noqa" lädt das Modul, das mit "@ app.route" verknüpft werden soll, aber "app.py" gibt eine Warnung aus, dass es nicht direkt verwendet wird). ..

Wenn Sie in diesem Status auf "http: // localhost: 8000" zugreifen und das Image / CSS / JS ordnungsgemäß angewendet wird, ist das Laden der statischen Ressource erfolgreich.

$ pipenv run chalice local --stage local
Serving on http://127.0.0.1:8000
127.0.0.1 - - [23/Sep/2020 17:56:13] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [23/Sep/2020 17:56:14] "GET /css/style.css HTTP/1.1" 200 -
127.0.0.1 - - [23/Sep/2020 17:56:14] "GET /images/sample.png HTTP/1.1" 200 -
127.0.0.1 - - [23/Sep/2020 17:56:14] "GET /js/index.js HTTP/1.1" 200 -

Der Bildschirm, der durch Zugriff auf "http: // localhost: 8000" mit Chrome angezeigt wird, sieht wie folgt aus.

Mit diesem Betrag kann eine einfache Überprüfung vor Ort durchgeführt werden.

Referenz. Umgang mit Nginx

Die Methode, die obigen Pfade einzeln hinzuzufügen, ist nicht realistisch, wenn jedes Mal die Erweiterung oder der Zielpfad erhöht wird. In einem solchen Fall können Sie nginx lokal festlegen und die Servereinstellung verwenden, die den Speicherort beschreibt, sodass root nur für einen bestimmten Pfad "statisch" ist. Danach können Sie unter http: // localhost / weiter zugreifen und überprüfen. In diesem Artikel wird die Verwendung von Nginx nicht erläutert. Wenn es jedoch kompliziert wird, können Sie es einführen. Daher werde ich es als Referenz einführen.

nginx.Spezifisches Beispiel für conf

location / {
  #Klicken Sie hier für den normalen Zugriff
  proxy_pass http://localhost:8000;
}

location ~ ^/(images|css|js)/ {
  #Holen Sie sich statische Ressourcen von einem festen Pfad
  root (Projektpfad)/static;
}

5. Unterstützung für POST aus dem Formular

Beim POSTing aus dem Browserformular wird der Inhaltstyp als "application / x-www-form-urlencoded" oder "multipart / form-data" gesendet. Die Kelch-Seite akzeptiert dies standardmäßig nicht, daher muss es möglich sein, diese in den content_types der entsprechenden Methode zu empfangen.

chalicelib/common.py

post_content_types = [
    'application/x-www-form-urlencoded',
    'multipart/form-data'
]


def post_params():
    '''dict gibt die an die post-Methode gesendeten Parameter zurück'''
    def to_s(s):
        try:
            return s.decode()
        except Exception:
            return s
    #In str-Typ konvertieren und zurückgeben
    body = app.current_request.raw_body
    parsed = dict(parse.parse_qsl(body))
    return {to_s(k): to_s(v) for (k, v) in parsed.items()}

app.py

@app.route('/search', methods=['POST'],
           content_types=common.post_content_types)
def search():                                                                   
    '''Suchen nach'''
    params = common.post_params() #Holen Sie sich Parameter in Form von Diktat

Bereitstellen und Überprüfen des Betriebs von Chalice

Wenn Sie über ein weitgehend privilegiertes IAM mit Programmic Access verfügen, können Sie Ihre Anwendung mit einem einzigen Befehl "chalice deploy" bereitstellen. Wenn dies nicht der Fall ist oder Sie CI / CD-Tools verwenden möchten, können Sie mit dem Befehl "Kelchpaket" ein Toolkit erstellen, das mit CloudFormation bereitgestellt werden kann. Spezifische Beispiele sind wie folgt. Da --profile und --region weggelassen werden, fügen Sie sie nach Bedarf hinzu.

chalice_Beispiel für die Paketverwendung

BUCKET=<Geben Sie den S3-Bucket an, um Ressourcen für CloudFormation hochzuladen>

#In CloudFormation-Bereitstellungsmethode konvertieren
$ pipenv run chalice package build
$ cd build

#Paketieren und in S3 hochladen
$ aws cloudformation package --template-file sam.json \
  --s3-bucket ${BUCKET} --output-template-file chalice-webapp.yml

#Bereitstellung mit CloudFormation
$ aws cloudformation deploy --template-file chalice-webapp.yml --stack-name <STACK Name> --capabilities CAPABILITY_IAM

Dieses Mal verwenden wir das Ergebnis der Bereitstellung mit dem Befehl "chalice deploy". Da "--stage" nicht angegeben ist, wird hier die "dev" -Stufeneinstellung verwendet (in ähnlicher Weise werden "--region" und "--profile" weggelassen).

$ pipenv run chalice deploy
Creating deployment package.
Reusing existing deployment package.
Creating IAM role: server-dev
Creating lambda function: server-dev
Creating Rest API
Resources deployed:
  - Lambda ARN: arn:aws:lambda:ap-northeast-1:***********:function:server-dev
  - Rest API URL: https://**********.execute-api.ap-northeast-1.amazonaws.com/v1/

Durch den Zugriff auf die bereitgestellte URL wird "text / html" ordnungsgemäß zurückgegeben.

$ curl https://**********.execute-api.ap-northeast-1.amazonaws.com/v1/
<!DOCTYPE html>
<html lang="ja">
<head>
  <title>HELLO</title>
  <meta charset="UTF-8">
  <link rel="stylesheet" href="/css/style.css">
</head>
<body>
  <h1>Lambda Web Hosting</h1>
  <p>AWS Lambda als Backend+ Chalice (Python)Mit Flasche/Dies ist ein Beispiel, das sich wie eine Flasche bewegt.</p>
  <h2>Load Static Files</h2>
  <p>Eine weitere Datei im h1-Tag/css/style.Der aus CSS gelesene Stil ist korrekt.</p>
  <p>Das Bild ist wie folgt.</p>
  <img src="/images/sample.png "/><br>
  <p>JavaScript wird ebenfalls geladen.</p>
  <span id="counter">0</span><br>
  <button id="button" type="button">Zähler(Drücken Sie die Taste, um die Zahlen hinzuzufügen)</button>
  <h2>Form Post</h2>
  <p>Holen Sie sich die Übereinstimmung aus dem Datenbank-Mock, den Sie intern haben.</p>
  <form method="POST" action="/search">
    <label>Suchbegriff: </label>
    <input type="text" name="keyword" value="" />
    <br>
    <button type="submit">Suche</button>
  </form>
  <script src="/js/index.js"></script>
</body>
</html>

Stellen Sie statische Dateien in S3 Bucket bereit

Erstellen Sie irgendwo einen S3-Bucket, damit auf den Inhalt hier in CloudFront verwiesen werden kann. Dieses Mal habe ich einen "sample-Bucket.t-kigi.net" -Eimer vorbereitet. Dies kann wie folgt stapelweise hochgeladen / aktualisiert werden, beispielsweise mit "awscli".

#Wechseln Sie zum Stammverzeichnis der statischen Datei
cd static
#Kopieren Sie alle Dateien
$ aws s3 sync . s3://sample-bucket.t-kigi.net/
upload: css/style.css to s3://sample-bucket.t-kigi.net/css/style.css
upload: js/index.js to s3://sample-bucket.t-kigi.net/js/index.js  
upload: ./favicon.ico to s3://sample-bucket.t-kigi.net/favicon.ico   
upload: images/sub/sample.jpg to s3://sample-bucket.t-kigi.net/images/sub/sample.jpg
upload: images/sample.png to s3://sample-bucket.t-kigi.net/images/sample.png

CloudFront-Einstellungen

Nehmen Sie die folgenden Einstellungen vor, um eine CloudFront-Distribution als Website-Zugriffsquelle einzurichten. Darüber hinaus werden alle Verfahren in der verwalteten Konsole ausgeführt.

--Erstellen Sie mit Certification Manager ein SSL-Zertifikat für die Zieldomäne in ** us-east-1 --CloudFront gibt keine Region an, daher müssen alle verwendeten Ressourcen in us-east-1 erstellt werden.

• Dieses Mal wird das Zertifikat aktiviert und automatisch erneuert, indem ein Datensatz hinzugefügt wird, der belegt, dass Sie Administrator der Domäne der von Route53 verwalteten Hostzone sind. --Wählen Sie "Distribution erstellen"> "Web", um eine Distribution zu erstellen, und legen Sie Folgendes fest
• Geben Sie das API-Gateway ** FQDN ** für den Ursprungsdomänennamen ein (z. B. **********. Execute-api.ap-northeast-1.amazonaws.com)
• Ergänzung: Wenn Sie den URI einfügen, werden dieser und der nächste Ursprungspfad auf die entsprechenden Werte gesetzt.
• Setzen Sie die API-Gateway-Stufe in Origin Path für den Zugriff auf die oberste Seite (z. B. / v1). --Stellen Sie die Viewer-Protokollrichtlinie so ein, dass HTTP zu HTTPS umgeleitet wird (da das API-Gateway nur HTTPS akzeptiert).
• HTTP-Methoden dürfen alle Methoden als Webanwendungsserver akzeptieren. Geben Sie "GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE" an.
• Geben Sie "Managed-CachingDisabled" als Cache-Richtlinie in den Einstellungen für Cache- und Ursprungsanforderungen an. (Legen Sie fest, dass CDN zu diesem Zeitpunkt nicht als Cache-Server verwendet wird.)
• Geben Sie den FQDN der vorbereiteten Domain (hier lambdasite.t-kigi.net) in den alternativen Domainnamen der Verteilungseinstellungen an.
• Geben Sie im SSL-Zertifikat ein vorab erstelltes SSL-Zertifikat an ―― Unmittelbar nach dem Erstellen des Zertifikats wird es möglicherweise nicht in den Optionen angezeigt. Warten Sie in diesem Fall eine Weile --Wenn es immer noch nicht angezeigt wird, überprüfen Sie erneut, ob die erstellte Region us-east-1 ist.
• Geben Sie nichts in das Standardstammobjekt ein **
• Wenn Sie hier schreiben, wird die Anforderung der URL, die nicht mit dem Standardzugriff zusammenhängt, an API Gateway gesendet, und der Zugriff auf die Startseite schlägt fehl.
• Andere Artikel sind die Standardeinstellungen oder werden nach Belieben festgelegt
• Nachdem die Verteilung erstellt wurde, wählen Sie die ID und dann die Registerkarte "Ursprünge und Ursprungsgruppen"
• Fügen Sie einen S3-Bucket für statische Dateien hinzu, die zuvor mit Create Origin erstellt wurden
• Der ursprüngliche Pfad bleibt leer (oben im Bucket = oben in der URL)
• Setzen Sie den Bucket-Zugriff auf Ja beschränken --Wählen Sie Neue Identität erstellen, um eine neue Berechtigung für den Zugriff auf S3 vom CDN aus zu erstellen --Grant Leseberechtigungen für Bucket und "Ja, Bucket-Richtlinie aktualisieren", um die Bucket-Richtlinie zu aktualisieren --Öffnen Sie die Registerkarte "Verhalten" und geben Sie den Ursprung eines bestimmten Pfads in "Verhalten erstellen" an.
• Direkter Zugriff auf / images / *, / css / *, / js / *, / favicon.ico auf S3 Origin (siehe Bild unten)
• Zulässige HTTP-Methoden können GET / HEAD sein (oder entsprechend eingestellt werden)

Befolgen Sie die obigen Schritte und warten Sie, bis der CloudFront-Status Bereitgestellt wird. Es dauert ungefähr 10 bis 20 Minuten.

Beispielseite

Die oben bereitgestellten Beispielsites sind wie folgt.

https://lambdasite.t-kigi.net

Mit diesem Verfahren wird das / von CloudFront an das / v1 / von API Gateway weitergeleitet, sodass Sie den Zugriff auf Site-Top-Ebene verwalten können. Wenn Sie unverändert nach / v1-> / v1 übertragen möchten, müssen Sie in Origin Path der Ursprungseinstellung nichts eingeben.

Die Standardanzahl gleichzeitiger Lambda-Läufe beträgt 1000. Wenn Sie sie also mit dem CDN-Cache kombinieren, können Sie davon ausgehen, dass viele gleichzeitige Zugriffe ausgeführt werden.

Preisvergleich

HINWEIS: Jeder Preis basiert auf dem Preis in der Region ap-northeast-1 (Tokio) zum Zeitpunkt des Schreibens des Artikels am 23. September 2020.

Die Gebühr für 30 Tage (1 Monat), wenn t2.micro, eine kostenlose Stufe bei AWS (1 Jahr), bestehen bleibt

• Instanzbetriebsgebühr: 10.944 USD = "(0.0152 USD / Stunde * 24 Stunden * 30 Tage)"
• Mit Amazon Linux2 AMI verbundener Mindestpreis für das EBS-Volumen (8 GB): 0,96 USD = (0,12 USD / Monat * 8)
• Anderes Datenübertragungsvolumen außerhalb von AWS (0,114 USD / GB)

Wenn es sich um ein kleines System handelt, beträgt es ungefähr 1200 bis 1300 Yen (zum Zeitpunkt des Schreibens des Artikels). Es ist innerhalb von 12 Monaten nach dem Erstellen eines AWS-Kontos kostenlos. Wenn es jedoch darüber hinausgeht oder wenn Sie mehrere Konten innerhalb eines Unternehmens erstellen und diese verknüpfen, verschwindet die kostenlose Stufe (Erfahrungsgeschichte). .. Dies ist jedoch ein System, das Redundanz nicht berücksichtigt, und es wird davon ausgegangen, dass die Instanz bei einem Ausfall manuell behandelt wird. Wenn Sie es redundant machen möchten, müssen Sie zwei (oder mehr) Server vorbereiten oder ALB in den Vordergrund stellen (monatliche Gebühr + ca. 20 USD), was ein einfaches Kostenproblem verursacht.

Auf der anderen Seite, wenn Sie AWS Lambda verwenden

• Millionen kostenlose Anfragen pro Monat und 400.000 GB-Sekunden Rechenzeit sind kostenlos (unabhängig davon, wie lange Sie ein Konto erstellt haben).
• Wenn Sie die Anwendung mit 128 MB Speicher ausführen, ist die kumulierte Lambda-Verfügbarkeit für etwa 37 Tage (400.000 GB-Sekunden ÷ 0,125 GB = 3,2 Millionen Sekunden) pro Monat kostenlos ――Selbst bei mehr als 1 Million Anfragen, 0,2 USD pro 1 Million als nächstes
• Die S3-Gebühren betragen nur 0,37 USD für 1 Million Anfragen (GET) und 0,025 USD / Monat pro 1 GB.
• Das Datenübertragungsvolumen ist über CloudFront gleich (Datenübertragungsvolumen außerhalb von AWS (0,114 USD / GB)).
• Darüber hinaus fallen kleine Gebühren wie API Gateway und Route 53 an.

Wenn in einer solchen Form selten auf den Server zugegriffen wird, kann er mit etwa 1 bis 2 USD ausreichend betrieben werden. Ein einfacher Vergleich hat einen großen Vorteil, aber es ist auch bemerkenswert, dass "jeder hier verwendete AWS-Service redundant ist". Es kann schwierig sein, alle Daten wie Zehntausende von Anforderungen pro Sekunde mit Lambda zu verarbeiten. Wenn Sie jedoch die parallele Ausführung von CloudFronts Cache und AWS Lambda verwenden, können Sie Dienste mit Hunderten von Anforderungen pro Sekunde ohne besonderen Aufwand verarbeiten. Es gibt eine Möglichkeit. Der Nachteil ist, dass Lambdas Mechanismus darin besteht, dass es einige Zeit dauern kann, bis es zum ersten Mal gestartet wird, wenn kein Zugriff besteht, und die Antwortzeit möglicherweise nicht stabil ist.

Für vollständig statische Sites und SPAs

Eine Website, die nur aus statischen Inhalten besteht, kann nur mit CloudFront - S3 erstellt werden. Darüber hinaus werden verschiedene statische Inhalte in S3 abgelegt, die API wird von API Gateway bereitgestellt, und einige Pfade werden von CloudFront direkt mit API Gateway verbunden, um SPA (Single Page Application) zu erstellen, das sich nicht um CORS kümmert. Ich denke, das ist eine modernere Art, es zu benutzen.

Diesmal war es jedoch erforderlich, die Template-Engine unter Verwendung der im Back-End ausgetauschten Daten auszuführen. Daher wurde in der Vergangenheit über ein Design nachgedacht, das AWS Lambda als Standardursprung verwendet und den Kommunikationsfluss dorthin ermöglicht.

Zusammenfassung

Ich habe vorgestellt, wie eine Webanwendung wie Flask / Bottle, die ohne Server ist, mithilfe verschiedener Ressourcen von Chalice + AWS Lambda + AWS implementiert und in die tatsächliche Produktionsumgebung eingefügt wird. Infolgedessen wird ein Dienst jedoch mithilfe verschiedener AWS-Dienste erstellt. Ich denke, dass es schwierig wurde, ihn zu verstehen, selbst wenn Sie diesen Artikel ohne besondere Kenntnisse lesen.

Im Sinne der Erstellung einer Webanwendung, die den Server nicht verwaltet, kann jedoch gesagt werden, dass "am Ende eine Umgebung geschaffen wird, in der wir uns auf das Codieren konzentrieren können". Es mag wie ein Umweg erscheinen, den Server und jede Infrastruktur zu verstehen, weil Sie den Server nicht verwalten, aber ich persönlich denke, dass es in dieser Ära keinen Lernverlust gibt.

Entwicklungsinhalte außerhalb des Geltungsbereichs des Artikels

Basierend auf dem hier vorgestellten Projekt

--Verwenden Sie DynamoDB als Datenspeicher auf der Anwendungsseite

• Da es einige Einschränkungen bei der Verwendung von RDB gibt, kann es ein gutes Lehrmaterial sein, die Implementierung des Lambda - DynamoDB-Sets zu erlernen.
• Effizienter Cache-Betrieb mit CloudFront
• Dieses Mal ist der API-Cache AUS und der statische Ressourcen-Cache EIN. ――Der CDN-Cache kann abhängig von der Site-Erstellung und den Einstellungen zu Informationsverlusten anderer Benutzer führen. Berücksichtigen Sie daher bei der Verwendung in der Produktion sorgfältig die Beziehung zwischen dem Pfad und dem Cache, testen Sie ihn und verwenden Sie ihn.
• Einführung des Authentifizierungsmechanismus
• Jetzt wird eine Antwort zurückgegeben, auch wenn Sie direkt auf den URI von API Gateway zugreifen.
• Sie können Verbindungsbeschränkungen implementieren, indem Sie einen API-Schlüssel in das API-Gateway einfügen oder die Quell-IP-Adresse durch X-Forwarded-For im Lambda-Header ermitteln.
• Erstellen Sie eine eingeschränktere Website mithilfe von CloudFront Signed Cookies. es kann
• Wenn Sie ein separates IDaaS haben, können Sie den Authorizer-Mechanismus von Chalice verwenden.
• Implementieren Sie eine Webanwendung in einer anderen Sprache als Python ――Wenn Sie den Support-Teil von Chalice in Ihrer bevorzugten Sprache / Ihrem bevorzugten Framework umschreiben, können Sie dasselbe tun.

Durch die Einführung solcher Punkte ist es möglich, eine Umgebung zu erstellen, die tatsächlicheren Vorgängen standhält.