5

J'ai suivi un excellent guide (Serverless Stack) qui crée une infrastructure sans serveur CRUD typique avec une interface de réaction. Il utilise le Serverless Framework pour AWS. Ce que je n'aime pas, c'est que pour amorcer la configuration, il y a beaucoup de clics manuels dans les interfaces graphiques (la plupart du temps l'interface de la console d'Amazon). C'est à dire. l'installation n'est pas contrôlée par la version et n'est pas facilement reproductible. Il ne serait pas facile de l'étendre avec un processus CI/CD etc. Dans cet exemple, les ressources suivantes doivent être configurées manuellement:Cadre sans serveur: comment réaliser une infrastructure complète en tant que code?

  • AWS Cognito utilisateur Piscine
  • AWS Cognite Pool application utilisateur
  • AWS Cognito Federated Identity Piscine
  • AWS DynamoDB exemple
  • seaux AWS S3 (x3) (ce accueille également le frontend)
  • la distribution CloudFront AWS
  • fichier de zone AWS Route53

Les seules ressources qui sont construites à partir du code sont les fonctions de (Serverless de lambdas) eux-mêmes, ainsi que les instances API Gateway. C'est ce que fait le framework sans serveur en utilisant son fichier serverless.yml. Mais toutes les ressources ci-dessus sont et non créées automatiquement. Ils doivent parfois être referenced to en utilisant leurs ARN, mais ils ne sont pas créés par la configuration serverless.yml. L'exécution d'un tel système en production (qui repose fortement sur la création manuelle de services via des interfaces graphiques) serait risquée.

Je pensais qu'une solution pour cela serait d'utiliser Terraform ou Cloudformation. Mais le Framework Serverless lui-même utilise déjà Cloudformation pour l'installation de Lambda, mais pas pour d'autres ressources. Alors, comment pourrait-on éliminer cet écart? En d'autres termes, comment reconstruire l'ensemble de l'installation décrite au code Serverless Stack?

Il semblerait étrange, et peut-être pas possible, d'avoir CloudFormation setup Serverless, qui possède alors ses propres modèles Cloudformation pour configurer lambdas. Il peut être plus judicieux d'étendre le Framework Serverless pour définir non seulement les fonctions et les API Gateways qui doivent être créées sur un serverless deploy, mais également d'autres ressources telles qu'un DynamoDB ou un pool d'utilisateurs Cognito. Y a-t-il des exemples ou des tentatives de personnes qui le font déjà?

Répondre

3

Je suis d'accord que la documentation sur ce serait un excellent pull request here. Vous avez raison: serverless utilise CloudFormation sous le capot. Le cadre expose les machines CloudFormation sous-jacentes, au moyen de la clé resources de votre serverless.yml.

Je pense the intent of the framework est que vous mettriez le reste de ces ressources (stuff Cognito, S3, etc.) dans la section resources: de votre fichier serverless.yml, en utilisant regular old CloudFormation syntax.

Par exemple, ce fichier va créer une table DynamoDB et le godet S3, en plus de la fonction serverless:

service: aws-nodejs # NOTE: update this with your service name 
provider: 
    name: aws 
    runtime: nodejs6.10 
functions: 
    hello: 
    handler: handler.deletecustomer 
    events: 
     - http: 
      path: /deletecustomer 
      method: post 
      cors: true 
resources: 
    Resources: 
    tablenotes: 
     Type: AWS::DynamoDB::Table 
     Properties: 
     AttributeDefinitions: 
      - AttributeName: noteId 
      AttributeType: S 
      - AttributeName: userId 
      AttributeType: S 
     KeySchema: 
      - AttributeName: userId 
      KeyType: HASH 
      - AttributeName: noteId 
      KeyType: RANGE 
     ProvisionedThroughput: 
      ReadCapacityUnits: '5' 
      WriteCapacityUnits: '5' 
    mysamplebucket: 
     Type: AWS::S3::Bucket 
     Properties: 
     WebsiteConfiguration: 
      IndexDocument: index.html 
      ErrorDocument: error.html 
     AccessControl: Private 
     VersioningConfiguration: 
      Status: Suspended 

Si vous êtes nouveau CloudFormation, je recommande aussi de prendre un coup d'oeil à CloudFormer .

0

Base sur les options de @Mike Patrick, en ajoutant ma compréhension pour le framework sans serveur et d'autres outils similaires de mise au point sans serveur.

Comme vous l'avez mentionné, pour les projets sans serveur, il y a beaucoup de ressources impliquées. Combinez-les ensemble n'est pas un travail simple. Donc choisir un bon outil est difficile.

Comparez Serverless framework-Cloudformation et Terraform, cadre serverless est spécialiste Serverless, CloudFormation et Terraform sont GP

CloudFormation et terraform sont entièrement Infrastructure as Code qui a couvert la plupart des ressources.

L'infrastructure Serverless est une couche intermédiaire uniquement destinée à générer un modèle Cloudformation, qui est principalement réservé aux ressources apparentées sans serveur.

Vous pouvez écrire tout dans le modèle Cloudformation directement, mais le fichier de modèle sera volumineux, il est difficile à maintenir par son modèle JSON/Yaml. Avec quelques dizaines de lignes dans serverless.yml, le framework sans serveur peut générer des milliers ou plusieurs milliers de lignes de modèle de cloudformation. Cela permet d'économiser beaucoup de temps pour gérer les codes de cloudformation.

Cela n'a aucun sens de laisser le framework sans serveur gérer toutes les ressources AWS, ce que d'autres outils font déjà le mieux.

Le framework sans serveur est encore en développement, en raison de sa popularité, de nombreux développeurs sont impliqués pour y ajouter des fonctionnalités au quotidien. Peut-être qu'un jour vous pourrez obtenir ce dont vous avez besoin, mais maintenant vous devez combiner un framework sans serveur avec Cloudformation ou Terraform ou d'autres outils dans certains cas.