Créez des API REST Go Serverless et déployez-les sur AWS à l'aide du framework SAM (Amazon Linux untime)

Pourquoi un autre tutoriel Go

AWS a récemment abandonné plusieurs services et environnements d'exécution. Comme nous l'avons vu avec l'arrêt de notre bien-aimé CodeCommit et d'autres services cruciaux, Go1.x n'est plus pris en charge pour les fonctions AWS Lambda.

Si vous essayez de déployer la plupart des didacticiels obsolètes, vous pourriez rencontrer des erreurs comme celle-ci :

Resource creation Initiated    
CREATE_FAILED                    AWS::Lambda::Function            DemoFunction                     
                                   Resource handler returned message: 
                                   "The runtime parameter of go1.x is no longer supported for 
                                   creating or updating AWS Lambda functions. We recommend you 
                                   use a supported runtime while creating or updating functions. 
                                   (Service: Lambda, Status Code: 400, Request ID:  
                                   81f1f708-0a7a-40d0-8442-b9c16510d01f)" 
ROLLBACK_IN_PROGRESS             AWS::CloudFormation::Stack       lambda-go-gorilla                
                                   The following resource(s) failed to create: 
                                   [DemoFunction]. Rollback requested by user.

Ce qu'il faut retenir, c'est que la seule constante dans les logiciels est le changement. Cependant, il y a quelques principes intemporels que nous devons toujours garder à l'esprit :

Pour résoudre ce problème, j'ai décidé de créer un référentiel à jour avec toute l'infrastructure nécessaire au déploiement d'une application Go. Deux options sont disponibles :

1. Déploiement avec Fargate à l'aide de conteneurs Docker.
2. Déploiement à l'aide du framework SAM sur AWS.

Vous pouvez GitHub trouver le référentiel ici.

Principes intemporels du développement de logiciels

• L'infrastructure en tant que code est essentielle.
• De bonnes conventions de dénomination dans les logiciels sont cruciales.
• Testez toujours votre logique.
• Disponibilité et évolutivité
• Pipeline de déploiement en tant que mécanisme permettant d'automatiser le processus de livraison de logiciels.
• L'observabilité est obligatoire.
• La sécurité est un citoyen de premier ordre dans les applications cloud natives.
• Go est une excellente option pour créer des API.

L'infrastructure en tant que code est essentielle

Une infrastructure immuable nous permet de déclarer ce que nous voulons à un niveau supérieur et garantit que les environnements de développement et de production restent aussi proches que possible. Par exemple :

CompoundingFunction:
  Type: AWS::Serverless::Function
  Metadata:
    BuildMethod: makefile
  Properties:
    FunctionName: CompoundingFunction
    Architectures: ["arm64"]
    Handler: bootstrap
    Runtime: provided.al2
    CodeUri: ./functions/CompoundingFunction/
    MemorySize: 512
    Timeout: 10
    Environment:
      Variables:
        COMPOUNDING_TABLE_NAME: !Ref CompoundingTable
    Policies:
      - DynamoDBCrudPolicy:
          TableName: !Ref CompoundingTable
    Events:
      ApiGatewayPost:
        Type: Api
        Properties:
          RestApiId: !Ref ApiGateway
          Path: /compounding
          Method: POST

De bonnes conventions de dénomination dans les logiciels sont essentielles

N'ayez pas peur de refactoriser si vous disposez d'une bonne suite de tests. Le refactoring est une activité essentielle dans le développement de logiciels. Les noms sont importants car ils apparaissent partout dans les modules, fonctions, packages, variables, etc.

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

// Response is the structure for the response JSON
type Response struct {
    Message      string    `json:"message"`
    GainsPerYear []float64 `json:"gainsPerYear"`
}

type Request struct {
    Principal  float64 `json:"principal"`
    AnnualRate float64 `json:"annualRate"`
    Years      int     `json:"years"`
}

func HelloHandler(ctx context.Context, event events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    var req Request
    err := json.Unmarshal([]byte(event.Body), &req)
    if err != nil {
        return createResponse(400, "Invalid request body")
    }
    fmt.Println("Request", req)
    gainsPerYear := CalculateCompoundInterest(req.Principal, req.AnnualRate, req.Years)
    fmt.Println(gainsPerYear)
    response := Response{
        Message:      "Calculation successful",
        GainsPerYear: gainsPerYear,
    }

    body, err := json.Marshal(response)
    if err != nil {
        return createResponse(500, "Error marshalling response")
    }

    return createResponse(200, string(body))
}

func createResponse(statusCode int, body string) (events.APIGatewayProxyResponse, error) {
    return events.APIGatewayProxyResponse{
        StatusCode: statusCode,
        Body:       body,
        Headers:    map[string]string{"Content-Type": "application/json"},
    }, nil
}

func main() {
    lambda.Start(HelloHandler)
}

Testez toujours votre logique

Dans les applications sans serveur, les tests unitaires sont importants, mais n'oubliez pas d'inclure également des tests d'intégration, car la plupart de ces applications s'appuient sur des intégrations et des politiques pour résoudre les problèmes métier.

func TestCalculateCompoundInterest(t *testing.T) {
    principal := 100000000.0
    annualRate := 10.0
    years := 10

    result := CalculateCompoundInterest(principal, annualRate, years)
    lastElement := round(result[len(result)-1], 2)

    expected := round(259374246.01, 2)
    if !reflect.DeepEqual(lastElement, expected) {
        t.Errorf("Expected %v, but got %v", expected, lastElement)
    }
}

Disponibilité et évolutivité

Les architectures sans serveur sont hautement disponibles par défaut et sont basées sur des événements, supprimant la plupart des tâches opérationnelles. Cependant, si vous choisissez de vous appuyer sur ECS et des conteneurs, il est important d'inclure un équilibreur de charge pour répartir le trafic entre vos serveurs, garantissant à la fois la disponibilité et l'évolutivité.

  CompoundingLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: compounding-nlb
      Scheme: internet-facing
      Type: network
      Subnets:
        - !Ref PublicSubnetOne
        - !Ref PublicSubnetTwo

Pipeline de déploiement

Un pipeline de déploiement automatise le processus de livraison de logiciels. Nous avons créé un Makefile pour simplifier ce processus, facilitant le déploiement et l'exécution de tâches répétitives avec une seule commande. Cette approche améliore l'efficacité et la cohérence de votre flux de travail de déploiement.

L'observabilité est obligatoire

Assurez-vous d'avoir mis en place le traçage, la journalisation et les métriques. Avec les applications sans serveur, l'activation de ces fonctionnalités est aussi simple que d'ajouter Tracing : Active. La possibilité de voir tous les journaux dans un endroit central comme CloudWatch et de surveiller les interactions du service est inestimable.

La sécurité est un citoyen de premier ordre dans les applications cloud natives

La sécurité est primordiale dans toutes les applications. L'utilisation d'Amazon Cognito fournit une authentification robuste des utilisateurs, tandis que les clés API ajoutent une couche supplémentaire de contrôle et d'autorisation, garantissant que seuls les clients autorisés peuvent accéder à vos API.

Auth:
  DefaultAuthorizer: CompoundingAuthorizer
  Authorizers:
    CompoundingAuthorizer:
      UserPoolArn:  XXXX
    LambdaTokenAuthorizer:
      FunctionArn: !GetAtt LambdaTokenAuthorizerFunction.Arn
      FunctionPayloadType: REQUEST
      Identity:
        Headers:
          - Authorization
        ReauthorizeEvery: 100
  AddDefaultAuthorizerToCorsPreflight: false

Attribuez les autorisations minimales nécessaires à chaque service, utilisateur et composant pour réduire la surface d'attaque et empêcher tout accès non autorisé. Principe du moindre privilège :

      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref CompoundingTable

Références

1. Terraform en action - Utilisations pratiques et stratégies pour la mise en œuvre de Terraform, un outil pour construire, modifier et gérer l'infrastructure.
2. Pipelines de livraison continue

Conclusion

Les logiciels évoluent constamment et même si certains outils et pratiques changeront, les principes fondamentaux restent les mêmes. Nous avons besoin d'une infrastructure immuable, de CI/CD, de bonnes conventions de dénomination, d'une stratégie de test robuste, de la sécurité de nos API et de l'efficacité de nos applications. C'est pourquoi j'ai décidé de recréer ce projet de manière sans serveur.

Il n'y a jamais eu de meilleur moment pour être ingénieur et créer de la valeur dans la société grâce aux logiciels.

• LinkedIn
• Twitter
• GitHub

Si vous avez apprécié les articles, visitez mon blog jorgetovar.dev

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!