Techniques Python x AWS x Serverless pour que les débutants passent à l'étape suivante
J'ai été sur scène avec le titre. Cela faisait longtemps que je n'étais pas sur scène en dehors de la compagnie et j'étais très nerveuse.
J'ai réussi à changer l'itinéraire de ce à quoi je pensais au départ, pourquoi les gens utilisent le délai au maximum, etc., mais je le dis quand même quand je repense à la composition et aux sujets individuels. Je pensais qu'il manquait quelque chose, je vais donc le compléter ici.
Les diapositives sont disponibles sur SpeakerDeck.
C'est une diapositive qui présente les astuces en termes de contenu, j'ai donc senti que je ne pourrais peut-être pas répondre à la question "Puis-je sortir des débutants avec ça?"
Bien sûr, il n'y a aucune intention de fraude de titre. J'ai une expérience (pour le moment) dans le choix de ce titre et de ce contenu, je vais donc l'écrire.
Dans mon passé, c'est un ensemble de compétences que j'ai quelques connaissances sur AWS, mais je n'ai pas une solide expérience en développement d'applications. Dans ce contexte, je n'étais pas habitué à la structure de répertoire de base et à sa conception, et j'étais confus. Puis, parce que je ne le comprenais pas, je craignais qu'il y ait quelque chose d'unique au sans serveur, et je ne savais pas quoi faire (même si je n'en étais pas conscient, donc je ne pouvais pas le résoudre). ..
Après cela, j'ai réalisé que l'idée de la partie développement d'application, même si elle est sans serveur (comme je l'ai dit dans cette annonce), devrait suivre la pratique du langage normalement. J'espère que tous ceux qui vont défier le serverless seront informés qu'ils n'auront pas peur plus que nécessaire.
J'ai moi-même vécu un état de "j'en ai marre de ne pas savoir quoi faire ensuite" à propos du serveur sans serveur. L'information que je voulais savoir à l'époque était la matière pour cette époque, alors je l'ai annoncée.
Ce genre de partage d'introduction est une partie très importante, n'est-ce pas? Parce qu'il n'y a pas de pouvoir attrayant dans une présentation qui ne soulève pas d'histoire ou pourquoi vous pouvez sympathiser. Je regrette que cette omission ait pu rendre difficile la compréhension du message qui séduit les téléspectateurs.
C'est la partie dont j'ai manqué l'explication dans la section telle que "Stage".
Le Serverless Framework nomme joliment les ressources AWS que vous déployez pour éviter les conflits entre les étapes. Par conséquent, l'attribut Name n'est souvent pas requis si vous utilisez le Framework sans serveur.
Cependant, je voudrais dire ici que "N'est-il pas préférable de nommer explicitement le nom de la ressource?" En fait, cela apparaît un peu sur la diapositive, mais la convention de dénomination est comme ça ↓
# template.yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
Avec ce type de dénomination, il est possible de gérer des noms de ressources faciles à prévoir et qui ne souffrent pas de noms entre services / étapes.
L'opinion opposée est: "Puisque toute l'infrastructure est gérée par code, n'est-il pas nécessaire de prêter attention au nom que les humains peuvent voir?" Si quoi que ce soit, je voudrais soutenir cela.
Vous n'avez pas à vous soucier des conflits de noms de ressources et des limites de caractères (par exemple, les noms de fonctions lambda peuvent comporter jusqu'à 64 caractères), il est donc plus facile de ne pas les nommer vous-même de manière étrange. La gestion des conventions de dénomination est également bruyante à mesure que la description de la source (sur la pile) augmente. Si possible, je serais heureux de vous laisser le nom.
Alors pourquoi devrions-nous lui donner un nom explicite? Il y a deux points que j'apprécie personnellement, dont chacun est le suivant. Je pense que la situation du projet dont je suis en charge est biaisée. peut être.
Étant donné que j'utilise beaucoup Step Functions, il y a des scènes occasionnelles où je souhaite rechercher des journaux sur plusieurs Lambdas.
Pour le moment, CloudWatch Logs Insights est principalement utilisé pour rechercher des journaux, mais le nom du groupe de journaux à ce moment-là est actualisé (avec des conventions de dénomination explicites), la recherche est donc un peu plus facile. est.
Probablement, je pense qu'il existe différentes façons de faire une recherche de journal par balise tout en utilisant Datadog (sans compter sur les règles de dénomination), mais cette méthode est l'un des choix que je peux faire maintenant. Je pense que c'est une méthode raisonnablement raisonnable qui convient à la scène de l'opération.
Je pense qu'il est plus avantageux d'avoir une règle de nommage afin d'écrire à la fois la description côté pile et la description côté application dans une certaine mesure (c'est le mérite que je veux affirmer davantage).
S'il s'agit d'un simple diagramme de configuration, vous pouvez soustraire la valeur avec GetAtt ou Ref de CloudFormation, ce n'est donc pas un gros problème. Les conventions de dénomination sont utiles lorsque le diagramme est gonflé.
Par exemple, imaginez une configuration avec plusieurs files d'attente SQS. Dans le code Python, vous avez besoin d'un point de terminaison de file d'attente, l'URL de la file d'attente (identifiable par AccountId, Region et QueueName).
Vous pouvez vous référer à l'URL de la file d'attente créée avec Ref et la transmettre à la variable d'environnement lambda, mais personnellement, je pense qu'il suffit de transmettre respectivement l'ID de compte, la région et l'attribut de nom de la file d'attente. ..
Les ID de compte et les régions sont susceptibles d'entrer en jeu lors de l'utilisation d'autres services AWS. Cela ne semble pas être un problème, et il est très facile d'implémenter une fonction utilitaire qui crée une URL de file d'attente, donc je pense qu'il est préférable de choisir celle qui semble fonctionner dans un petit tour.
Quant à la gestion de Python comme base de code telle que décrite ci-dessus, considérons la gestion côté pile (je pense que l'avantage de la convention de nommage est ici assez grand).
Je republierai la définition du nom de file d'attente de SQS plus tôt. Le nom de la file d'attente était une image créée en joignant service et stage.
#[Republier] modèle.yml
# SQS Queue name
Name: ${self:service}-my-queue-${self:provider.stage}
En tant que définition de pile réelle, c'est comme déclarer la chaîne de caractères entière de Name (ou la partie de ma-queue) dans la variable d'environnement ou la section personnalisée du modèle.
De cette façon, vous pouvez écrire des références à partir de ressources ailleurs (par exemple, des définitions de stratégie IAM) relativement rapidement. Puisque la partie de nom déclare qu'elle peut être désignée comme une variable, les ARN, etc. sont simplement joints et assemblés.
Je pense qu'il y a un point ici que "Non, il y a Ref et GetAtt", mais personnellement je ne recommande pas de les utiliser comme un détour.
Je pense qu'en abuser, en particulier autour des politiques, peut conduire à des références circulaires dans CloudFormation. Ceci est basé sur des règles empiriques et je ne peux pas le justifier dans une phrase claire, mais je ne veux pas utiliser une fonction qui fait directement référence aux ressources AWS. Au lieu de cela, la stratégie consiste à s'appuyer sur des variables d'environnement ou des variables moins nuisibles dans la section personnalisée. Je m'abstiens consciemment d'utiliser Ref, GetAtt (en particulier autour des politiques IAM).
Il est difficile de déboguer CloudFormation, mais je ne veux pas avoir de problème avec la référence circulaire de CloudFormation après que la configuration augmente ...? Ce n'est pas quelque chose que les êtres humains déboguent. ..
Pour cette raison, je préfère déclarer explicitement les noms de ressources (même s'ils sont un peu fastidieux et ennuyeux). Ce que j'ai écrit dans cette section n'est qu'un effet secondaire, mais je le prends très au sérieux.
Pour le matériel sans serveur, s'il y a suffisamment d'informations pour couvrir les matériaux de contour et les didacticiels, c'est plutôt bâclé, mais à la fin, j'ai senti que cela n'éliminerait pas la partie qui démange dans la scène de développement réelle. J'ai donc postulé avec le désir de combler cette lacune.
Je pense avoir parlé de ce que je veux transmettre maintenant, mais comme les connaissances de base sur AWS étaient une partie que je pourrais approfondir, il aurait peut-être été bon de l'appliquer dans une session de 45 minutes (le composant Python devient mince) Je me demande comment c'est comme un TPO car ça finira)
D'un autre côté, malheureusement, la réaction a été moindre que ce à quoi je m'attendais, donc je n'ai pas pu avoir une idée de l'histoire elle-même à partir de cette annonce (le fait que la session du programme arrière était trop forte). Il y a plusieurs facteurs possibles, comme le fait que ma présentation elle-même pouvait être améliorée et qu'il était difficile pour les principaux participants de PyCon de se rencontrer.) Il est peu probable qu'il n'y ait pas de demande, alors je vais essayer de le découvrir en changeant de lieu et en parlant. Le matériau de base est prêt.
Je pense que ce serait bien si je pouvais écrire un peu plus de connaissances systématiques, plus proches de la pratique. Il serait peut-être bon d'essayer dans le prochain livre technique.