Démarrez / arrêtez régulièrement le serveur cloud de Sakura avec AWS Lambda + CloudWatch Events

Aperçu

Nous créons parfois un serveur sur le cloud de Sakura à des fins de vérification, mais il est difficile de le démarrer et de l'arrêter manuellement tous les jours. Ce serait bien s'il démarre automatiquement tous les matins au début du travail et s'arrête après la fin du travail. J'ai cherché quelque chose comme ça (minuterie en Nifukura), mais je ne l'ai pas trouvé. Le service de Sakura est bon marché, donc je pense qu'il suffit d'avoir un VPS pour une exécution régulière du traitement, mais je veux toujours le rendre sans serveur. Implémentons-le donc avec Lambda + CloudWatch Events en utilisant AWS! J'ai pensé. (Je pense que vous pouvez le faire avec Cloud Functions + Cloud Scheduler avec GCP ou Azure Functions + TimerTrigger avec Azure, mais je ne l'ai pas essayé.)

scénario

J'aimerais écrire le script en Python. Quand je l'ai recherché, une bibliothèque appelée saklient a été introduite dans ici. Quand je l'ai vérifié, cela a fonctionné, donc je vais l'utiliser. Il existe une description de la version bêta et il semble qu'elle n'ait pas été mise à jour depuis plusieurs années, est-ce que c'est ennuyeux? Je souhaite informer Slack du résultat de l'exécution avec un Webhook entrant.

Code entier

Activé pour un déploiement en masse avec Terraform. Il est publié ci-dessous.

https://github.com/shztki/lambda-sakuracloud-startstop

L'utilisation est décrite dans README. Cette fois, des informations telles que la clé d'accès seront entrées dans la variable d'environnement Lambda, c'est donc ici que je souhaite les chiffrer. Cependant, même si vous passez kms_key_arn à ʻaws_lambda_function, la valeur de variables dans ʻenvironment ne sera pas chiffrée. Normalement, après le déploiement, «Variables d'environnement côté client» dans ici Vous devez accéder à la console AWS et sélectionner manuellement «Activer les assistants pour le chiffrement en transit» pour «chiffrer» comme décrit dans «Pour chiffrer». Ceci est très dangereux si vous l'oubliez, et il peut être vu par quelqu'un avant de le crypter manuellement. Quoi qu'il en soit, je veux que la variable d'environnement soit dans la valeur chiffrée lorsque le déploiement est terminé ... C'est une mesure minutieuse, mais cette fois j'ai préparé un script shell appelé kms.sh et je l'ai passé à variables chiffrées avec l'AWS CLI.

data "external" "slack_webhook_url" {
  program = ["bash", "kms.sh"]

  query = {
    key_id    = module.kms_key.key_arn
    plaintext = var.slack_webhook_url
  }
}

#!/bin/bash

set -e

eval "$(jq -r '@sh "KEY_ID=\(.key_id) PLAINTEXT=\(.plaintext)"')"

result=$(aws kms encrypt --key-id $KEY_ID --plaintext $PLAINTEXT --query CiphertextBlob --output text)

jq -n --arg result "$result" '{"result":$result}'

image

Ce qui suit est publié quotidiennement sur Slack:

à partir de maintenant

Je me demande si je devrais ajouter un processus qui exclut les vacances.

finalement

Je me demande si AWS exploitera le cloud de Sakura, mais pardonnez-moi car c'est une ère multi-cloud. Je pense que le coût mensuel sera moins cher qu'un VPS (bien que l'emplacement exact soit inconnu). Bonne vie dans le cloud Sakura!