やってたこと 2024/08
8/1(木) - 11(日)
SRE NEXT 2024 Staff & LT
初の Ask the Speaker を受けたことに関してはとりあえず書いた
その他については月内になにか書く
EventBridge -> Lambda -> (RDS) StartExportTask
の続き
Lambda のスクリプトはほぼ https://www.perplexity.ai/ に作ってもらった。テスト含め。
lambroll でデプロイ構築。Terraform 使わず。
IAM 最小権限難しいなってなってた
関連つぶやき
VPC Peering 跨ぎで RDS 接続
ルーティングがわからないのでサポートに確認
関連つぶやき
Aurora Serverless V1 (mysql5.7:Aurora2系) から V2 (mysql8.0:Aurora3系) に上げるメンテナンス
検証は 30 分くらいだったのが、本番は 2 時間くらいかかった
関連つぶやき
既存リソースの terraform import 大会(S3・Route53)
↓の発展というか応用
S3 は流用できた。
Route53 は単純には流用できないことがわかった。
8/12(月祝) - 19(月)
とある Laravel ベースかんたんAPIの Hono 移植
App Runner で動いてるやつを、Lambda にしていこうかなっていうのをやっている。
コードの移植が完了して、テストを量産した(AIにやってもらった)
docker image に載せて Lambda に置こうかなと思っているが、Cloudflare Workers でも Deno でも、妥当に動けばそれで良い。お安く済むとありがたい。何かいいのないかなあ。
関連つぶやき
Apache のロードバランサー設定を HAProxy に移植
Apache にロードバランサー機能あるの今まで知りませんでした。
これもまた AI 先生に軽くやってもらい、疎通検証が妥当な感じだったので「終わったぽよ〜」報告した。
関連つぶやき
data.aws_caller_identity.current に関する大勘違い
4文字の間違いにだいぶ時間溶かした
BigQuery Data Transfer Service for Amazon S3 の IaC化へ挑む
EventBridge -> Lambda -> (RDS) StartExportTask の続き
↓使うっぽい
↓で Google Cloud というか gcloud の使い方を思い出すなど。
既存リソースの terraform import 大会 の要領で、AI先生にサポートいただいて google_bigquery_table を HCL 化して、設定を1つ terraform import してみて整理して、それを x テーブルで回して見事に一発ズドンで google_bigquery_data_transfer_config 設定を構築するコードの中心がこちら。
main.tf
provider "google" {
#credential = var.credentials # gcloud auth login, gcloud auth application-default login で認証してください
project = var.project
region = var.region
}
data "sops_file" "secrets_aws_access" {
source_file = "./secrets_aws_access.enc.json"
}
variable "bq_table_list_file" {
type = string
default = "bq_table_names.list"
}
locals {
bq_table_names = csvdecode(file(var.bq_table_list_file))
bq_table_names_list = [for bq_table in local.bq_table_names : bq_table.name]
# ハイフンをアンダースコアに置換する
table_resource_names = {
for name in local.bq_table_names_list :
name => replace(name, "-", "_")
}
}
resource "google_bigquery_data_transfer_config" "tables" {
for_each = toset(local.bq_table_names_list)
project = var.gcp_project_id
location = var.region
display_name = "${local.dataset_id}.${each.key}"
data_source_id = "amazon_s3"
destination_dataset_id = local.dataset_id
schedule = "every 24 hours"
schedule_options {
start_time = "2024-08-17T20:00:00Z" # JST: 2024-08-18 05:00:00+0900
}
email_preferences {
enable_failure_email = true
}
params = {
destination_table_name_template = each.key
data_path = "s3://${local.rds_export_bucket}/rds-{run_time+9h|\"%Y\"}-{run_time+9h|\"%m\"}-{run_time+9h|\"%d\"}/${local.rds_export_db_name}/${local.rds_export_db_name}.${each.key}/*/*.gz.parquet"
access_key_id = data.sops_file.secrets_aws_access.data["access_key_id"]
secret_access_key = null
file_format = "PARQUET"
write_disposition = "WRITE_TRUNCATE"
max_bad_records = "0"
ignore_unknown_values = "false"
field_delimiter = ","
skip_leading_rows = "0"
allow_quoted_newlines = "false"
allow_jagged_rows = "false"
}
sensitive_params {
secret_access_key = data.sops_file.secrets_aws_access.data["secret_access_key"]
}
}
fargate-bastion-mysql-client をつくった
README が充実してもういいような気もしているが久々の Zenn 記事にする予定
ほどよい、terragrunt 入門になった
8/20(火) - 31(土)
DNSレコードの最後のドット「.」に関する学び
- さくらのクラウドの DNS でどうしても CNAME レコード設定が完了しなかった
- amplify のカスタムドメイン設定でやる2つの CNAME 設定、ACM 用は「.」が必要で、サブドメイン自体用は「.」不要
EC2 の中でなにかする ssm send-command
- GitHub Actions でデプロイをやるパターンでうまくいかなくてハマってた気持ちになっていたが実は動いてた
- それに気づいたのは翌昼に別件で "httpd -v" を取得して回るスクリプトを作るっていうのを Spike してて
waveaccounting/terraform-aws-chatbot-slack-configuration
module 消失
事件: こんなこともあるんですね...
教えてもらっていた記事にコメントを入れた
Cognito ID Pool の Terraform での構築設定把握
amplify が作ってくれた role, policy がよくはできているんだが、jsonencode をバラすのをやってるとどんどん時間溶ける。。
setopt APPEND_CREATE
旧同僚からの助言
Terragrunt での CI 体制
時間的な代償はあったがある程度「モノにした」
過程で、GitHub Actions での label 設定 API に文字数制限(50)あることを知った
2時間でとある VPC の削除を完了(IaC最高)
某Jenkins環境一式を撤去。EC2 Savings Plans が切れるため。(マスターノードはECS(Fargate)+EFS、ワーカーノードがEC2。docker build させるには EC2 が必要だったがゆえの構成)
CodePipeline への移行中だが、結局使ってないので Good-bye した。今までありがとう。
調整したことは、いくつかの module の version を明記した、くらい。そうでないと terraform init しきれなかったので。alb のやつ(最新9 だけど 8 に固定した)くらいだったかな。
関連ポスト
ECSデプロイの B/G -> Rolling Update 移行を「掴んだ」
なかなかに苦労したが、目処が立って IaC を整理すると、けっこう「そうでもなかった」。
ポイントは、ロードバランサーから一式新しいのを作ってやるのが吉、というところでしょうか。
今回の場合、API Gateway(オーサライザーで認証) -> NLB -> ALB という経路だったので、なおさら、一部だけを挿げ替えようとしても、ハマるだけ、と知りました。
なお、本番の移行を無停止で達成するのは難しそうではある。
関連ポスト
ElastiCache (Redis) と Aurora RDS (MySQL) の import で把握したこと
- ElastiCache: ↓の ignore_changes 指定が必要
- Aurora RDS: performance_insights_retention_period は null にするのが吉(7, 731が設定可能)
関連ポスト