Python x AWS x Serverless-Techniken für Anfänger, um den nächsten Schritt zu tun
Ich war mit dem Titel auf der Bühne. Es ist lange her, dass ich außerhalb der Firma auf der Bühne stand und ich war sehr nervös.
Ich habe es geschafft, die Route von dem zu ändern, worüber ich ursprünglich nachgedacht habe, warum die Leute die Frist in vollem Umfang nutzen und so weiter, aber ich sage es immer noch, wenn ich an die Komposition und die einzelnen Themen zurückdenke. Ich dachte, es fehlt etwas, also werde ich es hier ergänzen.
Die Folien sind auf [SpeakerDeck] verfügbar (https://speakerdeck.com/hassaku63/python-and-aws-and-serverless-step-to-the-next-stage-from-a-beginner).
Es ist eine Folie, die inhaltliche Tipps enthält, sodass ich das Gefühl hatte, die Frage "Kann ich damit den Anfängern entkommen?" Möglicherweise nicht beantworten zu können.
Natürlich besteht keine Absicht des Titelbetrugs. Ich habe (vorerst) einen Hintergrund bei der Auswahl dieses Titels und Inhalts, daher werde ich ihn aufschreiben.
In meinem Hintergrund ist es eine Fähigkeit, dass ich einige Kenntnisse im AWS-Bereich habe, aber keine soliden Erfahrungen in der Anwendungsentwicklung habe. Vor diesem Hintergrund war ich nicht an die grundlegende Verzeichnisstruktur und deren Gestaltung gewöhnt und war verwirrt. Dann, weil ich es nicht verstand, war ich besorgt, dass es etwas Einzigartiges für Serverless gibt, und ich wusste nicht, was ich tun sollte (obwohl ich es nicht wusste, also konnte ich es nicht lösen). ..
Danach wurde mir klar, dass die Idee des Anwendungsentwicklungsteils, obwohl er serverlos ist (wie ich in dieser Ankündigung sagte), der Sprachpraxis normal folgen sollte. Ich hoffe, dass jeder, der Serverless herausfordert, darüber informiert wird, dass er nicht mehr als nötig Angst hat.
Ich selbst hatte den Zustand "Ich habe es satt, nicht zu wissen, was ich als nächstes tun soll" über Serverless. Wir haben angekündigt, dass die Informationen, die wir zu diesem Zeitpunkt wissen wollten, das Material für diese Zeit waren.
Diese Art des Einführungsaustauschs ist ein sehr wichtiger Teil, nicht wahr? Weil eine Präsentation, die keine Geschichte aufwirft oder warum Sie mit ihr sympathisieren können, keine ansprechende Kraft hat. Ich bedauere, dass das Weglassen dies möglicherweise schwierig gemacht hat, die Botschaft zu verstehen, die die Zuschauer anspricht.
Dies ist der Teil, in dem ich die Erklärung in dem Abschnitt wie "Bühne" verpasst habe.
Das Serverless Framework benennt die von Ihnen bereitgestellten AWS-Ressourcen gut, um Konflikte zwischen Phasen zu vermeiden. Daher ist das Attribut Name häufig nicht erforderlich, wenn Sie das Serverless Framework verwenden.
Ich möchte hier jedoch sagen: "Ist es nicht besser, den Ressourcennamen explizit zu benennen?" Eigentlich erscheint es ein wenig auf der Folie, aber die Namenskonvention ist wie folgt ↓
# template.yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
Mit dieser Art der Benennung ist es möglich, Ressourcennamen zu verwalten, die leicht vorherzusagen sind und keine Namen zwischen Diensten / Stufen aufweisen.
Die gegenteilige Meinung lautet: "Da die gesamte Infrastruktur durch Code verwaltet wird, ist es nicht notwendig, auf den Namen zu achten, den Menschen sehen können?" Wenn überhaupt, würde ich das gerne unterstützen.
Sie müssen sich keine Gedanken über Ressourcennamenkonflikte und Zeichenbeschränkungen machen (z. B. können Lambda-Funktionsnamen bis zu 64 Zeichen enthalten), sodass es einfacher ist, sie nicht seltsam zu benennen. Die Verwaltung von Namenskonventionen ist ebenfalls verrauscht, wenn die Beschreibung der Quelle (auf dem Stapel) zunimmt. Wenn möglich, überlasse ich Ihnen gerne den Namen.
Warum sollten wir ihm einen expliziten Namen geben? Es gibt zwei Punkte, die ich persönlich mag, von denen jeder wie folgt ist. Ich denke, dass die Situation des Projekts, für das ich verantwortlich bin, voreingenommen ist. vielleicht.
Da ich häufig Schrittfunktionen verwende, gibt es gelegentlich Szenen, in denen ich Protokolle über mehrere Lambdas hinweg durchsuchen möchte.
Derzeit wird CloudWatch Logs Insights in den meisten Fällen zum Durchsuchen von Protokollen verwendet. Der Name der Protokollgruppe zu diesem Zeitpunkt wird jedoch aktualisiert (mit expliziten Namenskonventionen), sodass die Suche etwas einfacher ist. ist.
Wahrscheinlich denke ich, dass es verschiedene Möglichkeiten gibt, die Protokollsuche nach Tags durchzuführen, während Datadog verwendet wird (ohne sich auf Namensregeln zu verlassen), aber diese Methode ist eine der Entscheidungen, die ich jetzt treffen kann. Ich denke, dass es eine vernünftige Methode ist, die zur Operationsszene passt.
Ich denke, dass es vorteilhafter ist, eine Namensregel zu haben, um sowohl die Beschreibung auf der Stapelseite als auch die Beschreibung auf der Anwendungsseite zu einem gewissen Grad zu schreiben (dies ist der Verdienst, den ich mehr behaupten möchte).
Für ein einfaches Konfigurationsdiagramm können Sie den Wert mit GetAtt oder Ref of CloudFormation subtrahieren, sodass es nicht viel ausmacht. Namenskonventionen sind nützlich, wenn das Blockdiagramm aufgebläht ist.
Stellen Sie sich beispielsweise eine Konfiguration mit mehreren SQS-Warteschlangen vor. Im Python-Code benötigen Sie einen Warteschlangenendpunkt, die Warteschlangen-URL (erkennbar an AccountId, Region und QueueName).
Sie können mit Ref auf die URL der erstellten Warteschlange verweisen und diese an die Lambda-Umgebungsvariable übergeben. Ich persönlich halte es jedoch für ausreichend, die Konto-ID, die Region und das Namensattribut der Warteschlange zu übergeben. ..
Bei Verwendung anderer AWS-Services spielen wahrscheinlich Konto-IDs und Regionen eine Rolle. Es scheint kein Problem zu sein, und es ist sehr einfach, eine Dienstprogrammfunktion zu implementieren, die eine Warteschlangen-URL erstellt. Ich denke, es ist am besten, die zu wählen, die in einer kleinen Runde zu funktionieren scheint.
Betrachten wir für die Verwaltung von Python als Codebasis, wie oben beschrieben, die Verwaltung auf der Stapelseite (ich denke, dass der Wert der Namenskonvention hier ziemlich groß ist).
Ich werde die Definition des Warteschlangennamens von SQS früher erneut veröffentlichen. Der Name der Warteschlange war ein Bild, das durch Verbinden von "Service" und "Bühne" erstellt wurde.
#Vorlage [Repost].yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
Als tatsächliche Stapeldefinition ist es so, als würde man die gesamte Zeichenfolge von Name (oder den Teil von "my-queue") in der Umgebungsvariablen oder im benutzerdefinierten Abschnitt der Vorlage deklarieren.
Auf diese Weise können Sie relativ schnell Referenzen aus anderen Ressourcen (z. B. IAM-Richtliniendefinitionen) schreiben. Da der Namensteil angibt, dass er als Variable bezeichnet werden kann, werden ARN usw. einfach zusammengefügt und zusammengesetzt.
Ich denke, es gibt hier einen Punkt, an dem "Nein, es gibt Ref und GetAtt", aber ich persönlich empfehle nicht, sie als Umweg zu verwenden.
Ich bin der Meinung, dass der Missbrauch dieser Richtlinien, insbesondere im Zusammenhang mit Richtlinien, zu Zirkelverweisen in CloudFormation führen kann. Dies basiert auf empirischen Regeln und ich kann es nicht in einem klaren Satz rechtfertigen, aber ich möchte keine Funktion verwenden, die direkt auf AWS-Ressourcen verweist. Stattdessen besteht die Strategie darin, sich auf weniger schädliche Umgebungsvariablen oder Variablen im benutzerdefinierten Abschnitt zu stützen. Ich verzichte bewusst auf die Verwendung von Ref, GetAtt (insbesondere in Bezug auf IAM-Richtlinien).
Es ist schwer, CloudFormation zu debuggen, aber ich möchte kein Problem mit dem Zirkelverweis von CloudFormation haben, nachdem die Konfiguration gewachsen ist ...? Das ist nichts, was Menschen debuggen. ..
Aus diesem Grund ziehe ich es vor, Ressourcennamen explizit zu deklarieren (auch wenn sie etwas langweilig und nervig sind). Was ich in diesem Abschnitt geschrieben habe, ist nur ein Nebeneffekt, aber ich nehme es ziemlich ernst.
Wenn es für serverloses Material genügend Informationen gibt, um die Gliederungsmaterialien und Tutorials abzudecken, ist es ziemlich schlampig, aber am Ende hatte ich das Gefühl, dass es den juckenden Teil in der eigentlichen Entwicklungsszene nicht beseitigen würde. Also habe ich mich beworben, weil ich diese Lücke füllen wollte.
Ich glaube, ich habe darüber gesprochen, was ich jetzt vermitteln möchte, aber da das Grundwissen rund um AWS ein Teil war, den ich vertiefen konnte, war es möglicherweise gut, es in einer 45-minütigen Sitzung anzuwenden (Python-Komponente wird dünn). Ich frage mich, wie es wie ein TPO ist, weil es enden wird.
Auf der anderen Seite war die Reaktion leider geringer als ich erwartet hatte, so dass ich durch diese Ankündigung kein Gefühl für die Geschichte selbst bekommen konnte (der Punkt, an dem die Sitzung des Back-Programms zu stark war). Es gibt mehrere mögliche Faktoren, wie die Tatsache, dass meine Präsentation selbst Verbesserungspotenzial hatte und dass es für die Hauptteilnehmer von PyCon schwierig war, sich zu treffen.) Es ist unwahrscheinlich, dass es keine Nachfrage gibt, also werde ich versuchen, es herauszufinden, indem ich den Ort wechsle und spreche. Das Basismaterial ist fertig.
Ich denke, es wäre schön, wenn ich etwas systematischeres Wissen schreiben könnte, das der Praxis näher kommt. Es kann gut sein, sich im nächsten technischen Buch anzustrengen.