Comment Coinbase met à l'échelle des applications sans serveur


Sans serveur, en particulier AWS Lambda, c'est impressionnant. Échelle de 0 à presque infini, il ne coûte presque rien et s’intègre à presque tout. Le problème commence lorsque vous passez d'un ingénieur implémentant des applications à un compte à de nombreux ingénieurs implémentant de nombreux comptes partagés. Il est difficile de veiller à ce que les applications suivent les mêmes bonnes pratiques de nommage et de sécurité pour empêcher tout le monde de marcher sur les pieds.

L'objectif est de fournir une expérience sûre et agréable à des milliers de développeurs qui créent et déploient des centaines d'applications sans serveur sur des dizaines de comptes AWS. À cette fin, nous avons développé et ouvert Fenrir, notre implémenteur AWS SAM. Cette publication explique comment nous utilisons Fenrir pour déployer sans serveur dans une grande entreprise.

Ce que le framework (SAM, sans serveur …) ne fait pas

Les infrastructures sans serveur incluent généralement une CLI pouvant créer / mettre à jour des ressources AWS et implémenter le code. Par exemple, l'implémentation sans serveur et l'implémentation sam utilisent AWS Cloud Formation (CF) pour libérer le code. Ces commandes d'implémentation sont utiles au début et peuvent être facilement placées dans un canal IC / CD pour accélérer le lancement de l'application.

Lorsque davantage d'ingénieurs commencent à implémenter des applications sans serveur, il est judicieux de s'assurer que:

  • Utilisez des noms cohérents: une bonne allocation des noms (et l’étiquetage) des ressources, telles que Lambda et API Gateway, maintiendra les comptes en ordre et indiquera clairement quelles ressources appartiennent à quels projets.
  • Suivez les pratiques de sécurité recommandées.: par exemple, mettez en pratique le "privilège minimal" lorsque vous attribuez des groupes de sécurité et des rôles IAM lambda séparément.
  • Créer un flux de travail fiable: gérer proprement les défauts de manière à montrer aux développeurs ce qui est arrivé, pourquoi et comment y remédier
  • Enregistrer ce qui est mis en œuvre: réagir rapidement à ce qui est actuellement mis en œuvre permet aux ingénieurs d’affiner et de comprendre l’état actuel du monde.

Notre solution consistait à construire un déployeur centralisé. Cet implémenteur fournit des limites claires aux développeurs travaillant sur le même compte AWS et bloque l'implémentation à moins que des pratiques communes ne soient suivies. Cela élimine la surcharge cognitive d'une grande quantité de détails et permet aux ingénieurs de se concentrer sur le code de leur application.

Fenrir Serverless Serverless Deployer

Fenrir

Fenrir est notre implémentateur AWS SAM; à sa base est une réimplémentation de la sam déploiement commande en tant que fonction d'étape AWS, il s'agit donc d'un sans serveur sans serveur (sans serveur²) déployer. sam déploiement est un alias pour un script python en deux étapes aws créer-changer-set et aws cloudformation execute-change-set.

La machine d'état Fenrir réplique ces étapes avec des transitions d'état, des tentatives et une gestion d'erreur explicite:

L'entrée de cette machine à états est un modèle SAM avec des données supplémentaires telles que ProjectName, ConfigName et le compte AWS à implémenter. La machine d'état Fenrir effectue les opérations suivantes:

  • Valider: indiquez les valeurs par défaut, puis validez que le modèle est correct et que toutes les ressources référencées peuvent être utilisées.
  • bloquer: créer un bloc pour s’assurer qu’une seule implémentation par projet peut être exécutée à la fois.
  • CreateChangeSet et attendre Run: créer un ensemble de modifications pour une pile CF. Attendez que le changeset soit validé et disponible.
  • ExecuteChangeSet et attend Le succès: attendez la fin de l'exécution.

Cette machine d'état se termine par un Le succès été, un FailureClean Etat dans lequel le lancement n’a pas été réussi mais le nettoyage réussi, ou une FailureDirty Indiquez que cela ne devrait jamais arriver et alertera l'équipe.

Fenrir (comme notre autre implémenteur open source Odin) suit la norme Bifrost pour créer des implémenteurs dans Coinbase. Bifrost ajoute la prise en charge de plusieurs comptes, la sécurité par défaut, la visibilité sur les déploiements et une intégration simple dans nos outils existants.

Ce que Fenrir ne fait pas

Fenrir ne prend en charge que des sous-ensembles d'AWS SAM. En limitant la portée du modèle, vous réduisez la surface pour de possibles conflits de noms et risques de sécurité.

Les ressources supportées sont AWS :: Serverless :: Function, AWS :: Serverless :: Api, AWS :: Serverless :: LayerVersion, AWS :: Serverless :: SimpleTable. Chacune d’elles a ses limites, par exemple la AWS :: Serverless :: Function Les limitations des ressources sont:

  • Nom de la fonction Il est généré et ne peut pas être défini.
  • Papier et VPCConfig.SecurityGroupIds S'il est défini, il doit faire référence aux ressources qui ont étiquettes correctes *.
  • VPCConfig.SubnetIds doit avoir le DeployWithFenrir étiquette égale à true.

Événements soutenu Les types ils sont:

  • Api: Vous devez avoir RestApiId, qui est une référence à une ressource d'API locale
  • S3: Le cube doit avoir étiquettes correctes *
  • Kinesis: La séquence doit avoir étiquettes correctes *
  • DynamoDB: La séquence doit avoir étiquettes correctes *
  • SQS: La queue devrait avoir étiquettes correctes *
  • Calendrier
  • CloudWatchEvent

*: Les étiquettes correctes signifient que les étiquettes Nom du projet, Nom de configuration sont correctes.

SNS ce n'est pas dans la liste des événements compatibles. Au moment de la rédaction de ce document, SNS ne prend pas en charge les étiquettes, ce qui rend difficile la validation d’un Lambda. Vous êtes autorisé à écouter un sujet SNS. Trouver des moyens de soutenir de tels événements et ressources en toute sécurité est l’un des objectifs futurs de Fenrir.

Bonjour fenrir

Un modèle SAM simple qui fonctionne avec Fenrir inclut ProjectName et ConfigName, par exemple. template.yml ressemblerait à ceci:

ProjectName: "coinbase / deploy-test"
ConfigName: "développement"
AWSTemplateFormatVersion: "2010-09-09"
Transformer: AWS :: Serverless-2016-10-31
Ressources:
holaapi
Type: AWS :: Sans serveur :: Api
Propriétés:
StageName: dev
Configuration du point final: REGIONAL
Salut:
Type: AWS :: Sans serveur :: Fonction
Propriétés:
CodeUri:.
Rôle: lambda-role
Contrôleur: hello.lambda
Temps d'exécution: go1.x
Événements:
Salut:
Type: Api
Propriétés:
RestApiId:! Ref helloAPI
Route: / bonjour
Méthode: GET

Le code hello lambda:

paquet principal
importer "github.com/aws/aws-lambda-go/lambda"
func main () {
lambda.Start (func (_ interface {}) (interface {}, erreur) {
retour carte[string]string {"body": "Hello"}, nil
})
}

Fenrir utilise Docker pour compiler et regrouper le code envoyé à AWS. La fonction hello nécessite /hello.zip pour exister dans le conteneur de la fenêtre de menu fixe intégré, par exemple, le fichier Docker:

De golang
WORDDIR /
EXECUTE apt-get update && apt-get install -y zip
DUPDO. .
EXECUTE aller à github.com/aws/aws-lambda-go/lambda
GOOD GOOD = linux GOARCH = amd64 aller construire -o hello.lambda.
Exécuter zip hello.zip hello.lambda

Pour empaqueter et implémenter le modèle à l'aide de la fonction steps que vous exécutez Forfait fenrir & présentoir fenrir:

  1. forfait construire l'image Docker puis extraire les fichiers zip
  2. se dérouler charger les fichiers zip et envoyer le modèle en tant qu'entrée à la fonction d'étapes de Fenrir

Mise en œuvre

Fenrir est principalement implémenté en utilisant:

  • aws-sdk-go pour interagir avec CloudFormation et d'autres ressources AWS
  • step en tant que cadre pour la construction, le test et le déploiement de fonctions d'étape AWS (pourquoi Coinbase utilise-t-il des fonctions d'étape)
  • goformation pour encoder / décoder les ressources CloudFormation et SAM en tant que structures Golang et les valider à l'aide du schéma JSON.

goformation utilise la spécification de ressource AWS CloudFormation et la spécification SAM pour générer du code et du schéma JSON. Fenrir les utilise pour encoder, décoder, modifier et valider les modèles. Cette génération de code permet à Fenrir de suivre facilement l'évolution du SAM et de lancer rapidement les fonctions.

Avenir

Il est difficile de concevoir des outils évolutifs, sûrs et faciles à utiliser. Fenrir propose à ses développeurs des outils de pointe avec des limites claires quant à leur utilisation. C'est une belle victoire, mais il reste encore beaucoup à faire pour admettre davantage de ressources, d'événements et de propriétés SAM.

SAM / Fenrir ne peut pas déployer de sites Web statiques dans S3 derrière CloudFront, car CloudFormation ne prend pas en charge le chargement des objets S3. Une fonction future de Fenrir est de fournir une ressource CloudFormation personnalisée pouvant télécharger des fichiers sur S3 pour l'hébergement de sites Web statiques. Cela ferait de Fenrir un implémenteur sans serveur full-stack².

Enfin, Fenrir est encore en phase de test et nous accueillons les contributions ou demandes de fonctionnalités dans notre référentiel Github.

Bonne lecture

Cours Crypto
Logo
Enable registration in settings - general