3 petites histoires que j'ai vérifiées en utilisant Chalice

1. Comment inclure des fichiers statiques dans les fonctions Lambda

--Scenario: Je souhaite traiter un simple fichier de configuration (YAML, JSON, etc.) comme un fichier à lire dans une fonction Lambda. --Problème: J'ai mis ʻenv.yml dans le même répertoire que ʻapp.py, mais calice deploy n'a pas téléchargé le fichier --Solution: Créez un répertoire appelé chalicelib sous le projet calice et placez-y les fichiers. Voir les résultats de l'arbre ci-dessous. --Lors de son utilisation, lisez-le comme filepath = os.path.join (os.path.dirname (__ file __), 'chalicelib', 'env.yml') et résolvez-le.

• La même chose est montrée dans le manuel officiel

$ tree -a .
.
├── .chalice
│   └── config.json
├── .gitignore
├── app.py
├── chalicelib
│   └── env.yml
└── requirements.txt

Lors du déploiement avec calice, les autorisations de fichier sont héritées comme dans le cas de Linux / Mac. Par conséquent, si vous déployez un fichier tel que «750», notez que lorsque vous essayez de lire ce fichier, vous obtiendrez une autorisation refusée au moment de l'exécution.

• Cas similaire. Probablement parce que lors de l'extraction du fichier zip créé au moment du téléchargement, les autorisations au moment de l'enregistrement sont étendues telles quelles.

2. La politique IAM n'est pas générée automatiquement / Comment définir la politique par vous-même

--Scenario: L'une des fonctionnalités utiles de Chalice est la génération automatique de stratégie IAM. Il s'agit d'une fonction qui détermine automatiquement lors de l'accès aux ressources AWS à l'aide de la bibliothèque boto3 dans Lambda et génère automatiquement et de manière dynamique une stratégie IAM. --Problème: pour une raison quelconque, mon programme n'a pas généré et accordé automatiquement cela.

Quand je l'ai recherché, c'était parce que ** seuls les programmes utilisant boto3.client étaient automatiquement générés **. Il existe également un moyen d'utiliser la ressource dans boto3, mais même si vous l'utilisez, elle ne sera pas soumise à la génération automatique d'IAM. Tous mes programmes utilisaient boto3.resource.

Par conséquent, puisque la stratégie IAM est automatiquement générée, ** Toujours utiliser boto3.client ** lors de l'utilisation de boto3 avec Chalice peut être une ligne directrice. Inversement, si vous souhaitez utiliser un rôle IAM existant ou gérer vous-même la description de la stratégie, désactivez ʻautogen_policy dans .chalice / config.json`. Par exemple:

json:.chalice/config.Extrait de json

  "stages": {
    "dev": {
      "api_gateway_stage": "api",
      "autogen_policy": false
    }
  }

Si cette option est désactivée, la valeur par défaut est de lire policy- <nom de l'étape> .json (dans ce cas, policy-dev.json) dans .chalice. Si vous souhaitez spécifier un alias, spécifiez le nom du fichier avec ʻiam_policy_file`. Cliquez ici pour une explication plus détaillée

json:.chalice/policy-dev.Écrivez simplement l'autorité d'accès dans le rôle dans json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:*"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "xxxx-xxxx-xxxx-xxxx-1234"
    },
    {
        "Effect": "Allow",
        "Action": [
            "logs:CreateLogGroup",
            "logs:CreateLogStream",
            "logs:PutLogEvents"
        ],
        "Resource": "arn:aws:logs:*:*:*",
        "Sid": "xxxx-xxxx-xxxx-xxxx-1235"
    }
  ]
}

Si vous souhaitez utiliser une bibliothèque externe, vous l'utiliserez probablement si vous utilisez boto3.resource. En raison de l'autorité IAM, si vous ne disposez pas de l'autorité d'opération IAM en premier lieu, vous pouvez spécifier l'ARN du rôle IAM et l'attribuer (ʻiam_role_arn`).

La description selon laquelle seul le client peut générer automatiquement une stratégie IAM est, par exemple, Explication in AWS BlackBelt series Beaucoup plus détaillé que l'article](https://michimani.net/post/aws-about-auto-generate-iam-policy-in-chalice/), mais j'ai trouvé cela dans la documentation officielle Je n'ai pas trouvé la description. Ça devrait aller, mais ...

3. Compatible CORS

--Scenario: API Gateway avec ajax depuis un navigateur --Je veux appeler Lambda et obtenir une réponse --Problème: Lorsque j'y accède avec ajax depuis un navigateur, il est repoussé à cause de CORS. La même chose s'applique lors de l'exécution sur «calice local».

Vous devrez définir le CORS en fonction de votre cas d'utilisation, mais c'est il est plus rapide de lire la formule -cors-support) L'explication est substantielle.

En règle générale, après avoir défini les paramètres appropriés pour l'instance de calice.CORSConfig, passez les paramètres à cors dans le décorateur comme@ app.route (chemin, cors = config). Le fera bien.