ブログRSSフィード

TFLintでTerraformを静的解析

Sun, 11 Jan 2026 21:36:30 GMT

目次

はじめに
TFLintとは
前提事項
設定ファイルの解説（.tflint.hcl）
TFLintの具体的な利用方法
Terraformコード例
TFLint静的検査結果
まとめ

はじめに

普段、TerraformをVS Codeで利用する場合、Terraform公式拡張機能と合わせてリアルタイム構文チェックなどのエコシステムが利用可能です。

これらと合わせてチェックをより強化できるTFLintと呼ばれる静的検査ツールがあり、簡単に紹介できればと思っています。

TFLintとは

主要クラウドプロバイダー（AWS/Azure/GCP）に関する警告やエラーについて、Terraformコードを解析し、知らせてくれるフレームワークとなっており、各機能はプラグインによって提供される仕組みとなっているツールになっています。

廃止された構文や未使用変数、ベストプラクティスに沿ったルールセットが含まれています。

AWSのルールセットは、公式プラグイン「TFLint Ruleset for terraform-provider-aws」として提供されています。

実際の設定ファイルやチェックした結果を紹介します。

前提事項

TFLintインストール方法については、次を参照してください。
- https://github.com/terraform-linters/tflint?tab=readme-ov-file#installation
Terraformの基礎的な知識については解説しません。

設定ファイルの解説（.tflint.hcl）

項目	設定値
enabled	TFLintを有効にするか否かを true / false で指定します。
deep_check	より踏み込んだ解析（deep check）にするか否かを true / false で指定します。
version	利用するルールセットプラグインのバージョンを指定します。 AWSであれば、基本的に https://github.com/terraform-linters/tflint-ruleset-aws/releases/latest に出てくるバージョン指定で問題ありません。
source	プラグインの取得元を指定します。AWSの場合、公式のtflint-ruleset-awsリポジトリを指定します。

以下は、設定例になります。

deep_checkを有効にする場合、AWSであれば読み取り権限が必要になります。

plugin "aws" {
  enabled    = true
  deep_check = true
  version    = "0.45.0"
  source     = "github.com/terraform-linters/tflint-ruleset-aws"
}

TFLintの具体的な利用方法

tflintの基本的なコマンドは次の通りです。

詳細なコマンドは、GitHub公式を参照するようにしてください。

初期化
- tflint —initコマンドでプラグインのダウンロードが実行されます。
静的検査
- tflintコマンドでカレントディレクトリに対して静的検査が可能です。
- tflint —recursiveコマンドで再帰的に静的検査が可能です。

Terraformコード例

以下に示す例は、EC2インスタンス作成（AWS_instance）と、未指定を許容する任意入力変数（default = nullのvariable）の書き方をまとめて示したサンプルです。

resource "aws_instance" "example" {
  ami           = "ami-03d1820163e6b9f5d"
  instance_type = "t3.micro"
  key_name      = "example-key-pair"
}

variable "scheduler_rds_identifier" {
  type        = string
  description = "example"
  default     = null
}

TFLint静的検査結果

TFLintの実行結果では、EC2のkey_nameに指定したキーペア名が実在しない（または一致しない）ためエラーになっている点と、宣言したscheduler_rds_identifier変数がどこからも参照されておらず未使用として警告になっている点が確認できました。

tflint --recursive
6 issue(s) found:

Error: "example-key-pair" is invalid key name. (aws_instance_invalid_key_name)

  on bastion.tf line 10:
  10:   key_name                    = "example-key-pair"

Warning: [Fixable] variable "scheduler_rds_identifier" is declared but not used (terraform_unused_declarations)

  on main.tf line 147:
 147: variable "scheduler_rds_identifier" {

Reference: https://github.com/terraform-linters/tflint-ruleset-terraform/blob/v0.13.0/docs/rules/terraform_unused_declarations.md

また、どのようなルールセットが入っており、deep_checkで検査される項目の記載が以下、GitHubにございますので興味がある方は参照してください。

https://github.com/terraform-linters/tflint-ruleset-aws/blob/master/docs/rules/README.md

まとめ

TFLintを使ってTerraformコードを静的に検査し、環境依存値（例：EC2のキーペア名）の不整合や、未使用変数のような保守性を下げる記述を早い段階で洗い出せることを確認しました。

Terraform Workspaceで実現する環境分離とリモートステート連携

Sun, 09 Nov 2025 10:10:00 GMT

目次

はじめに
Terraform Workspaceとは
動作確認内容
流れ
まとめ

はじめに

こんにちは、今回は、より実践的な内容として、Terraformでの環境分離についてお話ししたいと思います。

Terraformを利用して、複数環境の構築をする際、環境間の設定差異などを考慮する必要があり、単一環境と比べて管理方法などが複雑になってくることがあります。

今回、紹介するTerraform Workspaceを利用する事でどの様にして環境間の分離を実現し、リモートステートを連携させるかについて紹介します。

なお、Terraformで環境分離する手法として、今回紹介する、ワークスペースによる分離とファイルレイアウトによる分離 など複数存在しますが、今回はワークスペースを利用した方法にフォーカスして紹介します。

Terraform Workspaceとは

Terraform Workspaceを使うと、Terraformの状態を管理するステートファイルを複数作成でき、ワークスペースごとに名前を付けて同じコードベースで複数の環境を管理できます。

動作確認内容

Terraform Workspaceは、同一フォルダ内で複数のワークスペースを作成し管理する機能になります。

環境間のリソース参照を実現するため、最初に参照元となるprodワークスペースを作成します。

次に参照先のstgワークスペースを作成し、stgワークスペースからprodワークスペースのリモートステートを参照する動作確認を行います。

流れ

環境準備

事前作業として、AWS CLIコマンドを使用し、Terraformのステートファイルを管理するS3バケットを作成します。

S3バケットの作成

export BUCKET=terraform-workspace-demo01
export REGION=ap-northeast-1

バケット作成

aws s3api create-bucket \
  --bucket "$BUCKET" \
  --region "$REGION" \
  --create-bucket-configuration LocationConstraint="$REGION"

バージョニング有効化

aws s3api put-bucket-versioning \
  --bucket "$BUCKET" \
  --versioning-configuration Status=Enabled

検証用Terraformファイルの作成

以下の内容でmain.tfファイルを作成します。

terraform {
  required_version = "1.11.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.89.0"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

locals {
  env = terraform.workspace
}

# ここがVPC作成定義（各workspaceで独立したVPCが作成されます）
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = {
    Name        = "${local.env}-vpc"
    Environment = local.env
    ManagedBy   = "Terraform"
  }
}

# このworkspaceで作成したVPCのID
output "vpc_id" {
  description = "各workspaceで作成したVPCのID"
  value       = aws_vpc.main.id
}

# 環境間参照デモ: prodのstateを、prod以外のworkspaceから参照
data "terraform_remote_state" "prod" {
  count     = terraform.workspace == "prod" ? 0 : 1
  backend   = "s3"
  workspace = "prod"
  config = {
    bucket               = "terraform-workspace-demo01" # backend.tfと同じ
    region               = "ap-northeast-1"
    encrypt              = true
    workspace_key_prefix = "env"
    key                  = "stack/terraform.tfstate"
  }
}

# prodのVPC IDを表示（prod自身ではnull）
output "prod_vpc_id" {
  description = "prod workspace の VPC ID（prod以外で表示）"
  value       = try(data.terraform_remote_state.prod[0].outputs.vpc_id, null)
}

次に、以下の内容でbackend.tfファイルを作成します。

terraform {
  backend "s3" {
    bucket               = "terraform-workspace-demo01" # 一意のS3バケット名に置換
    region               = "ap-northeast-1"
    encrypt              = true
    use_lockfile         = true  # DynamoDB不要のS3ネイティブロック
    workspace_key_prefix = "env" # S3上: env/<workspace>/stack/terraform.tfstate
    key                  = "stack/terraform.tfstate"
  }
}

プロジェクト初期化

Terraformのプロジェクトを初期化します。

正常に成功すると、S3バックエンドが設定され、Terraformの初期化が完了します。

terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

...{中略}

Terraform has been successfully initialized!

...{中略}

prodワークスペースの作成と適用

terraform workspace new {環境名}コマンドを使用して、任意のワークスペース名を作成できます。

terraform workspace new prod

Created and switched to workspace "prod"!

You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

terraform workspace listコマンドで、現在のワークスペースを確認します。

今回の場合、defaultワークスペースとprodワークスペースが存在することが確認できます。

defaultワークスペースはTerraform初期化時に自動的に作成されるワークスペースかつ削除できないため、こちらのワークスペースは利用せずにprodワークスペースを利用します。

terraform workspace list

  default
* prod

terraform plan 実行後、terraform apply を実行し、prodワークスペースのVPCを作成します。

...{中略}

aws_vpc.main: Creating...
aws_vpc.main: Still creating... [10s elapsed]
aws_vpc.main: Creation complete after 12s [id=vpc-01f858cac1ff4826c]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

vpc_id = "vpc-01f858cac1ff4826c"

適用後、以下AWS CLIコマンドでterraform applyで作成されたVPCを確認します。

Nameタグがprod-vpcであることが確認できます。

aws ec2 describe-vpcs --vpc-ids vpc-01f858cac1ff4826c --query 'Vpcs[].{VpcId:VpcId, State:State, CidrBlock:CidrBlock, IsDefault:IsDefault, Name: Tags[?Key==`Name`].Value | [0]}' --output table

CidrBlock	IsDefault	Name	State	VpcId
10.0.0.0/16	False	prod-vpc	available	vpc-01f858cac1ff4826c

stgワークスペースの作成と適用

同様に、terraform workspace new {環境名}コマンドを使用して、stgワークスペースを作成します。

terraform workspace new stg

Created and switched to workspace "stg"!

You're now on a new, empty workspace. Workspaces isolate their state,
so if you run "terraform plan" Terraform will not see any existing state
for this configuration.

terraform workspace listコマンドで、現在のワークスペースを確認します。

stgワークスペースが作成されていることが確認でき、stgワークスペースに切り替わっていることが確認できます。

terraform workspace list

  default
  prod
* stg

terraform plan 実行後、terraform apply を実行し、stgワークスペースのVPCを作成します。

...{中略}

aws_vpc.main: Creating...
aws_vpc.main: Still creating... [10s elapsed]
aws_vpc.main: Creation complete after 11s [id=vpc-04184270516210ce1]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

prod_vpc_id = "vpc-01f858cac1ff4826c"
vpc_id = "vpc-04184270516210ce1"

情報

stgワークスペースではterraform_remote_stateデータソースを利用して、prodワークスペースのVPC IDを参照しています。
prod_vpc_id出力値にprodワークスペースで作成されたVPC IDが表示されていることが確認できます。

適用後、以下AWS CLIコマンドでterraform applyで作成されたVPCを確認します。

Nameタグがstg-vpcであることが確認できます。

aws ec2 describe-vpcs --vpc-ids vpc-04184270516210ce1 --query 'Vpcs[].{VpcId:VpcId, State:State, CidrBlock:CidrBlock, IsDefault:IsDefault, Name: Tags[?Key==`Name`].Value | [0]}' --output table

CidrBlock	IsDefault	Name	State	VpcId
10.0.0.0/16	False	stg-vpc	available	vpc-04184270516210ce1

S3バケット内の状態確認

S3バケット内に、ワークスペースごとにステートファイルが保存されていることが確認できます。

aws s3api list-objects --bucket terraform-workspace-demo01 --query 'Contents[].{Key: Key, Size: Size, LastModified: LastModified}' --output table

Key	LastModified	Size
env/prod/stack/terraform.tfstate	2025-11-09T08:34:05+00:00	1981
env/stg/stack/terraform.tfstate	2025-11-09T08:58:20+00:00	3386

まとめ

Terraform Workspaceを利用する事で、同一コードベースで複数環境の分離を実現できることが確認できました。

ディレクトリを分けることなく、環境ごとにワークスペースを切り替えるだけで、環境分離が可能になるため、管理が容易になる点がメリットです。

反面、同一リソースを作成しない場合は、ワークスペースごとに条件分岐をコードに追加する必要があるため、コードが複雑になる点がデメリットとなります。

AWS CodeBuildからAmazon EKS APIへのアクセス認証エラー対処

Mon, 23 Dec 2024 07:53:35 GMT

目次

はじめに
事象
1. エラー例①
2. エラー例②
前提条件
調査
対処
動作確認
まとめ

はじめに

AWS CodePipelineからAmazon EKSに対して、CI/CDをおこなう機会があり、AWS CodeBuild処理時にEKSクラスター API認証エラーとなり時間を溶かしましたので備忘録として記録します。

事象

AWS CodeBuildのビルド設定ファイルに次のコマンドを設定しており、エラーになっている状態です。

エラー例①

EKSクラスターへの認証情報が正しくない場合や、クラスターのAPIサーバへ到達できない場合に出るエラーメッセージとなります。

kubectl apply -f deployment.yaml

error: error validating "deployment.yaml": error validating data: failed to download openapi: the server has asked for the client to provide credentials; if you choose to ignore these errors, turn validation off with --validate=false

エラー例②

EKSクラスターAPIサーバへのリクエストが認証に失敗したことを示しており、認証情報の不足やアクセス権限の不足が疑われます。

kubectl get pods --v=9

[
  {
    "metadata": {},
    "status": "Failure",
    "message": "the server has asked for the client to provide credentials",
    "reason": "Unauthorized",
    "details": {
      "causes": [
        {
          "reason": "UnexpectedServerResponse",
          "message": "unknown"
        }
      ]
    },
    "code": 401
  }
]

　→※抜粋して記載しております。

前提条件

認証情報設定
- aws eks update-kubeconfig --region {リージョン名} --name {クラスター名} コマンドが成功している状態とします。
CodePipelineでCodeBuildを使用していることを前提とします。
EKSクラスターの作成はすでにおこなわれている状態とします。

調査

Amazon EKS API サーバーの不正サーバーエラーの解決 | AWS re:Post

注:Amazon EKS オーセンティケーターログを有効にします。このクエリは、クラスター作成者としてマッピングされた IAM エンティティを返します:

上記サイトに記載の通り、Amazon EKSオーセンティケーターログを確認することで解決の糸口が分かりますのでこちらのログを確認します。

ログはCloudWatchログに次のような形式で吐かれます。

CloudWatchロググループ名：/aws/eks/{クラスター名}/cluster
ログストリーム名：authenticator-{変動する文字羅列}

次のような形で認証エラーに関するログが吐かれることを確認しました。

見やすくするため加工しております。

このエラーメッセージは、EKSクラスターの認証に問題が発生していることを示しており、CodeBuildにアタッチしているIAMロール（mysystem-codebuild-role）がEKSクラスターのアクセス権限マッピングに含まれていない為、出ています。

denied"
arn="arn:aws:iam::{AWSアカウント12桁}:role/mysystem-codebuild-role"
client="127.0.0.1:38884"
error="Identity
is
not
mapped"
method=POST
path=/authenticate

対処

原因が分かりましたので対処します。

CodeBuildのサービスロールをRBACユーザーにマッピングします。

ここで言うと、configMapにあります、aws-authへ記載するようにします。

参考記事
- kubectl error You must be logged in to the server (Unauthorized) when accessing EKS cluster | AWS re:Post
  1. CodeBuild のサービスロールを Kubernetes RBAC ユーザーにマッピングします。EKS クラスターを接続したターミナル Cloud9 から、次のコマンドを使用して、configMap aws-auth に IAM ロール eks-CodeBuildServiceRole の正しいエントリがあることを確認します。
- Amazon EKS API サーバーの不正サーバーエラーの解決 | AWS re:Post
  
  注:Amazon EKS オーセンティケーターログを有効にします。
  このクエリは、クラスター作成者としてマッピングされた IAM エンティティを返します:

念の為、参考記事を記載しておます。

とても参考になりますのでお時間のある方は覗いてみてください。

kubectl edit -n kube-system configmap/aws-auth こちらのコマンドを使用してマッピングします。

追記箇所を分かりやすく示しておりますので、ご参考ください。

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::{awsアカウント12桁}:role/mysystem-eks-fargate-pod-execution-role
      username: system:node:{{SessionName}}
    - groups:
      - eks-console-dashboard-full-access-group
      rolearn: arn:aws:iam::{awsアカウント12桁}:role/test-role
      username: test-iam-role
# ===========================================================================================
# ここから↓
    - groups:
      # master にマッピングしないと権限エラーになるので注意。
      - system:masters
      # CodeBuild のロールを指定する。
      rolearn: arn:aws:iam::{awsアカウント12桁}:role/mysystem-codebuild-role
      username: mysystem-codebuild-role
# ここまで追記↑
# ===========================================================================================
  mapUsers: |
    - groups:
      - eks-console-dashboard-full-access-group
      userarn: arn:aws:iam::{awsアカウント12桁}:user/test-user
      username: test-iam-user
kind: ConfigMap
metadata:
  creationTimestamp: "2024-11-27T00:15:47Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "3922938"
  uid: 15ca1b80-ea0d-41cc-94ce-29612300d2a8

動作確認

CodeBuildを発火させ、冒頭に記載したapplyコマンドやgetコマンドでエラーなく通れば問題ありません。

それぞれのログは見やすく加工しております。

調査解説部分で記載しております、Amazon EKSオーセンティケーターログを再度確認し次のようなログが吐かれていることを確認します。

time="2024-12-07T12:29:05Z"
level=info
msg="access
granted"
arn="arn:aws:iam::{awsアカウント12桁}:role/mysystem-codebuild-role"
client="127.0.0.1:36628"
groups="[system:masters]"
method=POST
path=/authenticate
uid="aws-iam-authenticator:{awsアカウント12桁}:AROA2AKHZ2S5YWUTHZL7A"
username=mysystem-codebuild-role

また、CodeBuildのIAMロールに対してEKSクラスターへのIAMロール引き受けを許可している設定をIAMロールへおこなっている為、次のログも確認しています。

time="2024-12-07T12:29:05Z"
level=info
msg="STS
response"
accesskeyid=ASIA2AKHZ2S5XMHJMHRA
accountid={awsアカウント12桁}
arn="arn:aws:sts::{awsアカウント12桁}:assumed-role/mysystem-codebuild-role/AWSCodeBuild-3e19932d-afa7-4ad6-9e90-4e25075cfbfa"
client="127.0.0.1:36628"
method=POST
path=/authenticate
session=AWSCodeBuild-3e19932d-afa7-4ad6-9e90-4e25075cfbfa
userid=AROA2AKHZ2S5YWUTHZL7A

まとめ

CodeBuildのIAMロール設定をしただけでは、EKSクラスターで持っている認証情報で弾かれるためちゃんと両方設定しないといけないということが分かりました。

今年ももう年の瀬に近づいてきましたね。

時が経つのは早いものです。

RDSストレージオートスケーリングとシークレットマネージャー統合について検証してみた

Wed, 31 Jul 2024 18:33:15 GMT

目次

概要
動作検証流れ
前提条件
環境構築
1. RDSシークレットマネージャー統合機能について
RDSストレージオートスケーリング
おわりに

概要

こんにちは、久方ぶりのブログ投稿となりますが、皆さまいかがお過ごしでしょうか。

さて、今回は、RDSのストレージオートスケーリング機能および、RDS作成時にシークレットマネージャーとの統合項目が増えておりましたのでこれらの動作確認をした記録となります。

動作検証流れ

本記事では、Terraformコードを用いて最初に検証する環境を作成します。

その後、PythonのプログラムからRDSに対して、データを入れていき、ストレージオートスケーリング動作を確認します。

※Terraformコード中は、シークレットマネージャー統合機能を使用せず、従来方式であるデータベースユーザおよびデータベースパスワードを直接指定するようにしています。

※シークレットマネージャー統合については、実際に筆者の方で動作確認し、気になった点を記載しています。

前提条件

EC2インスタンスへのAWS CLIコマンドインストール、IAMロールについては解説しません。
RDSへ接続可能なEC2については前提知識とし解説しません。
Terraformの基礎知識は解説しません。

環境構築

次のTerraformコードでは、VPC、サブネット、ストレージオートスケーリングを監視する為のCloudWatch Alarm、SNS通知等の設定を記載しております。

サブネットや、セキュリティグループ、通知用メールアドレス等いくつか環境に合わせて変更すべき箇所をコード中に明示していますので試される際は、ご承知ください。

また、作成されるRDSデータベースエンジンはMariaDBとなっています。

# rds.tf

variable "env_name" {
  description = "Environment name prefix"
  type        = string
  default     = "dev" # 環境名プレフィックスを指定
}

variable "subnet_ids" {
  description = "List of subnet IDs for the RDS subnet group"
  type        = list(string)
  default     = ["{既存のサブネットID、1番目を指定}", "{既存のサブネットID、2番目を指定}"] # 既存のサブネットIDを指定
}

variable "security_group_ids" {
  description = "List of existing security group IDs"
  type        = list(string)
  default     = ["{既存のセキュリティグループIDを指定}"] # 既存のセキュリティグループIDを指定
}

variable "notification_email" {
  description = "Email address for SNS notifications"
  type        = string
  default     = "{メールアドレスを指定}" # 通知を受け取るメールアドレスを指定
}

variable "allocated_storage" {
  description = "Initial allocated storage in GB"
  type        = number
  default     = 20 # 初期割り当てストレージ
}

variable "max_allocated_storage" {
  description = "Maximum allocated storage in GB"
  type        = number
  default     = 50 # 最大割り当てストレージ
}

# ストレージの10%未満の値を計算
locals {
  storage_threshold = var.allocated_storage * 0.10 * 1024 * 1024 * 1024 # 10%をバイトに変換
}

# SNSトピックの作成
resource "aws_sns_topic" "rds_storage_scaling_alerts" {
  name = "${var.env_name}-rds-storage-scaling-alerts"
}

# SNSトピックのサブスクリプション（メール通知）
resource "aws_sns_topic_subscription" "email_subscription" {
  topic_arn = aws_sns_topic.rds_storage_scaling_alerts.arn
  protocol  = "email"
  endpoint  = var.notification_email
}

# サブネットグループの作成
resource "aws_db_subnet_group" "rds_subnet_group" {
  name       = "${var.env_name}-rds-subnet-group"
  subnet_ids = var.subnet_ids

  tags = {
    Name = "${var.env_name}-RDSSubnetGroup"
  }
}

# RDSパラメータグループの作成
resource "aws_db_parameter_group" "mariadb_parameters" {
  name   = "${var.env_name}-mariadb-parameter-group"
  family = "mariadb10.11" # MariaDBの最新バージョンに合わせて変更

  parameter {
    name  = "max_connections"
    value = "100"
  }

  # 他のMariaDBに適用するべきパラメータをここに追加
}

# RDSインスタンスの作成
resource "aws_db_instance" "mariadb" {
  identifier            = "${var.env_name}-my-mariadb-instance"
  allocated_storage     = var.allocated_storage
  max_allocated_storage = var.max_allocated_storage
  storage_type          = "gp3"
  engine                = "mariadb"
  engine_version        = "10.11.8" # MariaDBの最新バージョンを指定
  instance_class        = "db.t3.medium"
  username              = "Admin"
  password              = "passw0rd" # manage_master_user_password が有効の場合、コメントアウトすること逆も然り
  #manage_master_user_password = true       # AWS Secrets Manager で管理を有効にする
  parameter_group_name   = aws_db_parameter_group.mariadb_parameters.name
  skip_final_snapshot    = true
  multi_az               = false # SingleAZに設定
  db_subnet_group_name   = aws_db_subnet_group.rds_subnet_group.name
  vpc_security_group_ids = var.security_group_ids
  availability_zone      = "ap-northeast-1a"

  tags = {
    Name = "${var.env_name}-MyMariaDBInstance"
  }
}

# CloudWatchアラームの作成
resource "aws_cloudwatch_metric_alarm" "rds_storage_alarm" {
  alarm_name          = "${var.env_name}-RDSStorageAutoScalingAlarm"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "FreeStorageSpace"
  namespace           = "AWS/RDS"
  period              = "300" # 5分間の期間
  statistic           = "Average"
  threshold           = local.storage_threshold # 10%未満の空きストレージ容量
  alarm_description   = "This alarm triggers when free storage space is less than 10% of the allocated storage for 5 minutes."
  dimensions = {
    DBInstanceIdentifier = aws_db_instance.mariadb.identifier
  }
  alarm_actions             = [aws_sns_topic.rds_storage_scaling_alerts.arn]
  ok_actions                = [aws_sns_topic.rds_storage_scaling_alerts.arn]
  insufficient_data_actions = [aws_sns_topic.rds_storage_scaling_alerts.arn]
}

RDSシークレットマネージャー統合機能について

manage_master_user_password を有効にするとRDSをAWS Secrets Managerで管理にできます。

RDSによってパスワード管理および自動ローテーション有効状態となり管理されます。

パスワードの更新が定期的になされ、シークレットの名前が明示的に指定できないため注意が必要となります。

RDSストレージオートスケーリング

RDSストレージオートスケーリングの動作確認をおこなう為にいくつか事前作業があります。

次のAWS CLIコマンドを使用し、作成したRDSのストレージサイズを確認します。

デプロイ時点で、20GBとなっていれば問題ないです。

# aws rds describe-db-instances --db-instance-identifier "dev-my-mariadb-instance" --query "DBInstances[0].AllocatedStorage" --output text

RDSへデータを入れ続けるプログラム設置

EC2インスタンスに次のPythonプログラムを設置します。

10MBのダミーデータを入れ続けRDSストレージを減らしていき、オートスケーリングを発火されるためのプログラムとなっています。

データベース接続情報項目については、各自環境に合わせてください。

ユーザやパスワードについては、Terraformコード内に記載しているものが使用されますが、hostについては各自環境へ置き換えが必要と推察されます。

# auto.py

import pymysql
import random
import string
import time
import multiprocessing

# データベース接続情報
host = 'dev-my-mariadb-instance.cnvmbmz0rzzo.ap-northeast-1.rds.amazonaws.com'
port = 3306
user = 'Admin'
password = 'passw0rd'
database = 'auto'
table = 'auto'
dummy_data_size_mb = 10  # ダミーデータのサイズ（MB単位）
num_processes = 10  # 並列実行するプロセスの数

# 1MB = 1024 * 1024 bytes
dummy_data_size_bytes = dummy_data_size_mb * 1024 * 1024

def create_database_if_not_exists(connection):
    with connection.cursor() as cursor:
        cursor.execute(f"CREATE DATABASE IF NOT EXISTS {database}")
        connection.commit()

def create_table_if_not_exists(connection):
    with connection.cursor() as cursor:
        cursor.execute(f"USE {database}")
        create_table_sql = f"""
        CREATE TABLE IF NOT EXISTS {table} (
            id INT AUTO_INCREMENT PRIMARY KEY,
            random_string MEDIUMTEXT,
            random_number INT
        )
        """
        cursor.execute(create_table_sql)
        connection.commit()

def generate_random_string(size_in_bytes):
    letters = string.ascii_lowercase
    return ''.join(random.choice(letters) for _ in range(size_in_bytes))

def insert_dummy_data():
    connection = pymysql.connect(
        host=host,
        port=port,
        user=user,
        password=password,
        database=database
    )
    with connection.cursor() as cursor:
        while True:
            random_string = generate_random_string(dummy_data_size_bytes)
            random_number = random.randint(1, 1000000)
            sql = f"INSERT INTO {table} (random_string, random_number) VALUES (%s, %s)"
            cursor.execute(sql, (random_string, random_number))
            connection.commit()
            print(f"Inserted data of size: {len(random_string) / (1024 * 1024):.2f} MB, Number: {random_number}")
            time.sleep(0.1)  # 0.1秒毎にデータを挿入

def main():
    # 初期設定のために一度だけ接続
    connection = pymysql.connect(
        host=host,
        port=port,
        user=user,
        password=password
    )

    try:
        create_database_if_not_exists(connection)
        create_table_if_not_exists(connection)
    finally:
        connection.close()

    # 並列プロセスの開始
    processes = []
    for _ in range(num_processes):
        process = multiprocessing.Process(target=insert_dummy_data)
        process.start()
        processes.append(process)

    try:
        for process in processes:
            process.join()
    except KeyboardInterrupt:
        print("Data insertion stopped by user.")
    finally:
        for process in processes:
            process.terminate()

if __name__ == "__main__":
    main()

必要パッケージインストール

EC2インスタンスに対して、次の通りパッケージをインストールします。

# dnf install mariadb
→MySQLクライエントです。データベースへの接続検証に使用可能です。

# dnf install pip
→pythonのパッケージ管理であるpipをインストールします。

# pip install pymysql
→プログラムで使用する為、インストールします。

※AWS CLIがない場合、インストールします。

※AWS CLIの最新バージョンのインストールまたは更新 - AWS Command Line Interface

プログラム実行

プログラムを実行するとダミーデータが格納されていき最終的に、テーブルがフルですよというエラーが出ます。

RDSのストレージは、20GBありますので、ストレージを枯渇させるまで、プログラムの実行時間が長時間になる為、気長にストレージを使い切るまで待ちます。

# python auto.py

・
・[中略]
・
Inserted data of size: 10.00 MB, Number: 12934
Inserted data of size: 10.00 MB, Number: 454018
Inserted data of size: 10.00 MB, Number: 561060
Inserted data of size: 10.00 MB, Number: 400860
Process Process-9:
Traceback (most recent call last):
  File "/usr/lib64/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib64/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/root/auto.py", line 55, in insert_dummy_data
    cursor.execute(sql, (random_string, random_number))
  File "/usr/local/lib/python3.9/site-packages/pymysql/cursors.py", line 153, in execute
    result = self._query(query)
  File "/usr/local/lib/python3.9/site-packages/pymysql/cursors.py", line 322, in _query
    conn.query(q)
  File "/usr/local/lib/python3.9/site-packages/pymysql/connections.py", line 563, in query
    self._affected_rows = self._read_query_result(unbuffered=unbuffered)
  File "/usr/local/lib/python3.9/site-packages/pymysql/connections.py", line 825, in _read_query_result
    result.read()
  File "/usr/local/lib/python3.9/site-packages/pymysql/connections.py", line 1199, in read
    first_packet = self.connection._read_packet()
  File "/usr/local/lib/python3.9/site-packages/pymysql/connections.py", line 775, in _read_packet
    packet.raise_for_error()
  File "/usr/local/lib/python3.9/site-packages/pymysql/protocol.py", line 219, in raise_for_error
    err.raise_mysql_exception(self._data)
  File "/usr/local/lib/python3.9/site-packages/pymysql/err.py", line 150, in raise_mysql_exception
    raise errorclass(errno, errval)
pymysql.err.OperationalError: (1114, "The table 'auto' is full")

ストレージ枯渇後の動作確認

RDSイベント取得

次のコマンドを使用して、対象RDSのイベントを取得します。

無事にストレージオートスケーリングが実施されると次の通り遷移します。

low storage
configuration change
Finished applying autoscaling-initiated modification to allocated storage.

# aws rds describe-events --source-identifier dev-my-mariadb-instance --source-type db-instance | jq

{
  "Events": [
    {
      "SourceIdentifier": "dev-my-mariadb-instance",
      "SourceType": "db-instance",
      "Message": "Storage autoscaling has triggered a pending scale storage task that will reach or exceed the maximum storage threshold. Increase the maximum storage threshold.",
      "EventCategories": [
        "failure"
      ],
      "Date": "2024-07-28T11:43:59.979000+00:00",
      "SourceArn": "arn:aws:rds:ap-northeast-1:{AWSアカウントID12桁}:db:dev-my-mariadb-instance"
    },
    {
      "SourceIdentifier": "dev-my-mariadb-instance",
      "SourceType": "db-instance",
      "Message": "The free storage capacity for DB Instance: dev-my-mariadb-instance is low at 0% of the provisioned storage [Provisioned Storage: 19.27 GB, Free Storage: 0 B]. You may want to increase the provisioned storage to address this issue.",
      "EventCategories": [
        "low storage"
      ],
      "Date": "2024-07-28T11:45:29.823000+00:00",
      "SourceArn": "arn:aws:rds:ap-northeast-1:{AWSアカウントID12桁}:db:dev-my-mariadb-instance"
    },
    {
      "SourceIdentifier": "dev-my-mariadb-instance",
      "SourceType": "db-instance",
      "Message": "Applying autoscaling-initiated modification to allocated storage.",
      "EventCategories": [
        "configuration change"
      ],
      "Date": "2024-07-28T11:45:34.406000+00:00",
      "SourceArn": "arn:aws:rds:ap-northeast-1:{AWSアカウントID12桁}:db:dev-my-mariadb-instance"
    },
    {
      "SourceIdentifier": "dev-my-mariadb-instance",
      "SourceType": "db-instance",
      "Message": "Finished applying autoscaling-initiated modification to allocated storage.",
      "EventCategories": [
        "configuration change"
      ],
      "Date": "2024-07-28T11:47:57.791000+00:00",
      "SourceArn": "arn:aws:rds:ap-northeast-1:{AWSアカウントID12桁}:db:dev-my-mariadb-instance"
    }
  ]
}

次のコマンドを使用して、RDSのストレージサイズを確認するとオートスケーリングの上限に設定している50GBになっていることが確認できます。

# aws rds describe-db-instances --db-instance-identifier "dev-my-mariadb-instance" --query "DBInstances[0].AllocatedStorage" --output text

暫くすると、ストレージ最適化（Storage-optimization）が走ります。

オートスケーリング前後のCloudWatch画面

次の画像通り、20GBから枯渇状態までいき、スケーリング後、上限値50GB - 消費したストレージサイズ20GB = 30GBの空きができスケーリングされました。

画像をホバー/タップすると拡大表示されます

RDSストレージオートスケーリング制限事項

RDSのストレージオートスケーリングについて気になった点を記載します。

RDSストレージオートスケーリング発火条件

Amazon RDS ストレージの自動スケーリングによる容量の自動管理

使用可能な空き領域は、割り当てられたストレージの 10% 未満です。

低ストレージ状態は 5 分以上続きます。

最後のストレージ変更、あるいはインスタンスでストレージの最適化が完了してから少なくとも 6 時間経過しています。

制限事項を抜粋しています。

追加ストレージは、10GBもしくは、現在割り当てられているストレージの10%と記載がありましたが、オートスケーリングの上限まで一気にスケーリングされたのは制限事項によるものです。

制限事項

オートスケーリングの場合、RDS は後続のオートスケーリングオペレーションのストレージサイズを予測します。後続のオペレーションが最大ストレージしきい値を超えると予測される場合、RDS では最大ストレージしきい値にオートスケーリングします。

監視面で気になった点は次の通りです。

CloudWatch Alarmに設定しているRDS FreeStorageSpace監視（dev-RDSStorageAutoScalingAlarm）の閾値は、ストレージオートスケーリングに追従しないのでオートスケーリング後のディスクサイズに沿った10%未満の閾値に設定する必要があります。

おわりに

RDSオートスケーリング便利な反面、注意すべきことがある為、気を付けて使っていきたいですね。

Ubuntuで急に読み込み専用ファイルシステムになった

Sun, 25 Feb 2024 20:21:15 GMT

目次

概要
事象
対処
対処後
まとめ

概要

Raspberry Pi 4 Model B Rev 1.2のUbuntu 20.10にて、Kubernetes v1.20.4を動かしており、POD上でgitlabの日次バックアップを実施している時間帯でファイルシステムが壊れ、読み込み専用ファイルシステムになっておりました。

これらの影響により、nodeが使用不可になり、名前解決が出来ない状態に陥りました。

備忘録として対応したことを記録する。

警告：fsck コマンドを使用して、システム領域を修正する場合は、手動で電源 Off/On できる環境で実施するようにしてください。

事象

/root/ 配下にtouchコマンドができない状態を確認。

touch test

touch: 'test' に touch できません: 読み込み専用ファイルシステムです

名前解決不可であることを確認。

curl ifconfig.io

curl: (6) Could not resolve host: ifconfig.io

Failed to start Network Name Resolution. となり、名前解決サービスが起動不可になることを確認。

systemctl status systemd-resolved

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2021-07-20 20:44:25 JST; 2s ago
       Docs: man:systemd-resolved.service(8)
             https://www.freedesktop.org/wiki/Software/systemd/resolved
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
    Process: 2930 ExecStart=/lib/systemd/systemd-resolved (code=exited, status=226/NAMESPACE)
   Main PID: 2930 (code=exited, status=226/NAMESPACE)

 7月 20 20:44:25 k8s-node-a systemd[1]: systemd-resolved.service: Start request repeated too quickly.
 7月 20 20:44:25 k8s-node-a systemd[1]: systemd-resolved.service: Failed with result 'exit-code'.
 7月 20 20:44:25 k8s-node-a systemd[1]: Failed to start Network Name Resolution.

現在時刻がおかしくなることを確認。

date

2021年  7月 20日 火曜日 20:37:43 JST

対処

/（ルート） システムで書き込みが出来ない状態になっていますので、fsckコマンドを使用し、ファイルシステムの修正をします。

ファイルシステム修正を実施するデバイスの確認をおこないます。

fdisk -l

...[中略]...
ディスク /dev/sda: 57.76 GiB, 62018519040 バイト, 121129920 セクタ
Disk model: USB 3.0 DISK
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x254a9658

デバイス   起動 開始位置  最後から    セクタ サイズ Id タイプ
/dev/sda1  *        2048    526335    524288   256M  c W95 FAT32 (LBA)
/dev/sda2         526336 121129919 120603584  57.5G 83 Linux

デバイス /dev/sda2 が /（ルート） となります。

df -PTh

Filesystem     Type   Size  Used Avail Use% Mounted on
tmpfs          tmpfs  380M   19M  362M   5% /run
/dev/sda2      ext4    57G   29G   26G  53% /
tmpfs          tmpfs  1.9G     0  1.9G   0% /dev/shm
tmpfs          tmpfs  5.0M  4.0K  5.0M   1% /run/lock
tmpfs          tmpfs  4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/sda1      vfat   253M  153M  100M  61% /boot/firmware
tmpfs          tmpfs  380M  8.0K  380M   1% /run/user/1000

fsck コマンドを使用し、対象のデバイスを修復します。

修正<y>? のように修正するか確認がでるので yes を押します。

他にも、修正箇所がある場合、都度確認が求められますので yes を押します。

fsck -f /dev/sda2

fsck from util-linux 2.36
e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking iノードs, blocks, and sizes
Iノードs that were part of a corrupted orphan linked list found.  修正<y>? yes
Iノード 34490 was part of the orphaned iノード list.  FIXED.
Iノード 1181537 has a extra size (11824) which is invalid
修正<y>? yes
...[中略]...
writable: ***** ファイルシステムは変更されました *****
writable: ***** REBOOT SYSTEM *****
writable: 412572/3769136 files (0.2% non-contiguous), 7686354/15075448 blocks

ファイルシステムの修復が完了すると、 reboot する必要がありますので、手動で電源 Off/On します。

筆者の環境では、ファイルシステム修正後、 reboot コマンド、 shutdown コマンドが使用出来ない状態となったため、手動で再起動しています。

対処後

対処後、冒頭の事象で確認したコマンドを打ち、問題ないことが確認できれば問題ありません。

まとめ

原因はまったく分かりませんが、今後、発生しないことを祈ります。

Amazon EC2 cloud-init の機能を使用し、公開鍵を変更する（備忘録）

Wed, 17 Jan 2024 22:12:00 GMT

目次

はじめに
結論

はじめに

Amazon EC2インスタンスの公開鍵をcloud-initの機能を使用して変更する時に、時間を溶かしたので備忘録として記録します。

結論

以下、サイトが大変参考になりました。

EC2のキーペアを失くしたので設定しなおしてみた | DevelopersIO

cloud-initには、初回EC2インスタンス作成時のみに実行するパターンと作成した後のインスタンスで起動時に毎回、実行するパターンを選択できます。

参考したサイトでは、前者の方で、筆者は、後者の方で実行したかったので以下内容でユーザデータに指定し実行しました。

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [users-groups, always]
users:
  - name: ec2-user
    ssh-authorized-keys: 
    - ssh-rsa AAAA***

[users-groups, once] になっていた部分を [users-groups, always] に変更します。
- ssh-rsa AAAA*** 部分の AAAA*** 箇所を設定したい公開鍵に変更します。
- 公開鍵に記載されている id-rsa 以降に羅列されている文字列となりますので注意ください。

AWS ANS ポエム（VPC）

Mon, 15 Jan 2024 22:39:00 GMT

目次

IPアドレスについて

IPアドレスについて

public ip

public ipは、subnetレベルで有効にするパターンとEC2インスタンスを起動する際に有効にするパターンが存在する。

IPアドレスの開放タイミングについて、インスタンスをターミネートすると開放され次回、起動時は別のIPアドレスがAmazonのPublic IPプールから割り当てられる。

EIPは、AWSアカウントに割り当てられIPアドレスを意図的に開放しない限り、保持できる。

private ip

private ipは、サブネットのアドレス範囲から割り当てるパターンや、明示的に指定して割り当てることが可能。

インスタンスに対して1回限りの割り当てとなり、IPアドレスの変更不可となり、インスタンスをターミネートした際に開放される。

private ipアドレスは、VPC内の通信に利用できるが、インターネットとの通信はおこなえない。

IPv6について

IPv6は、IPv4と異なり、すべてpublic ipアドレスとなる。

インスタンスの起動停止でIPアドレスは開放されず、ターミネートした際に、開放される仕組みとなっている。

デフォルトですべてのVPCはIPv4アドレスを必要とし、オプションとして、IPv6アドレスを使用するか否かを選択することができる。

IPv6のみを使用したいといったことはできない。

AmazonからIPv6用にDNSが提供されず、IPv4のみAmazonからDNSが提供され、固定のレンジとなり、IPアドレス範囲を選択することはできない。

特定のAWSアカウントとのAMIの共有

Sat, 30 Dec 2023 21:43:49 GMT

目次

概要
AMI共有
カスタマーキー作成
作成したカスタマーキーのキーポリシーを変更
1. キーポリシーの編集
AMIを作成したKMSキーでコピー
共有先注意事項

概要

アカウントAに作成したAMIをアカウントBに共有する方法について気になったので備忘録として記録する。

参考文献
- Amazon マシンイメージ (AMI) を別の AWS アカウントとプライベートに共有する | AWS re:Post
- 特定の AWS アカウントとの AMI の共有 - Amazon Elastic Compute Cloud

AMI共有

AWSマネージメントコンソールより、EC2サービスページに移動し、共有したいEC2インスタンスを選択し、AMIを作成します。

作成した、AMI権限の編集を選択し、共有アカウント欄に共有したいAWSアカウントID 12桁を入れ、変更を保存することでAMIを対象アカウントに共有することができる。

以下、エラーが出る場合、カスタマー管理ポリシーで作成する必要がありますので、カスタマーキー作成の項目をおこなってから実施します。

イメージ属性を変更できませんでした

Snapshots encrypted with the AWS Managed CMK can’t be shared. Specify another snapshot.

画像をホバー/タップすると拡大表示されます

カスタマーキー作成

AWSマネージメントコンソールより、「Key Management Service (KMS)」サービスページに移動し、カスタマー管理型のキーを選択後、キーの作成を押します。

画像をホバー/タップすると拡大表示されます

キーを設定

何も変更せず次へボタンをクリックします。

画像をホバー/タップすると拡大表示されます

ラベルを追加

エイリアス項目に任意の分かりやすい名前を設定し、次へボタンをクリックします。

画像をホバー/タップすると拡大表示されます

キーの管理アクセス許可を定義

何も変更せず次へボタンをクリックします。

キーの使用法アクセス許可を定義

何も変更せず次へボタンをクリックします。

確認

設定内容に問題ないことを確認し、完了ボタンをクリックします。

画像をホバー/タップすると拡大表示されます

作成したカスタマーキーのキーポリシーを変更

ポリシービューへの切り替えをクリック後、編集をクリックします。

画像をホバー/タップすると拡大表示されます

キーポリシーの編集

参考文献
- Amazon EBS スナップショットの共有 - Amazon Elastic Compute Cloud

キーポリシーの編集より、以下内容に書き換え、変更を保存をクリックします。

{共有元AWSアカウントID12桁}

{共有元AWS IAMユーザ名}

{共有先AWSアカウントID12桁}

上記項目は、適宜自分の環境に置き換えてください。

{
    "Id": "key-consolepolicy-3",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{共有元AWSアカウントID12桁}:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::{共有元AWSアカウントID12桁}:user/{共有元AWS IAMユーザ名}",
                    "arn:aws:iam::{共有先AWSアカウントID12桁}:root"
                ]
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::{共有元AWSアカウントID12桁}:user/{共有元AWS IAMユーザ名}",
                    "arn:aws:iam::{共有先AWSアカウントID12桁}:root"
                ]
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "kms:GrantIsForAWSResource": "true"
                }
            }
        }
    ]
}

AMIを作成したKMSキーでコピー

AWSマネージメントコンソールより、EC2のサービスページに行き、AMIの画面から、AMIのコピーを先ほど作成したKMSキーを使用しておこないます。

コピーしたAMIから冒頭記載のAMI共有でエラーが出ず共有したいアカウントへ共有できます。

画像をホバー/タップすると拡大表示されます

共有先注意事項

共有先では、AMIのプライベートイメージとして表示されます。

共有されたAMIを使用し、EC2インスタンスを立ち上げ後、立ち上げたEC2インスタンスのAMIを作成します。

その後、共有されたEC2インスタンスは削除し、先ほど作成したAMIを使用し、EC2インスタンスを立ち上げます。

このようにすることで、共有元のAWSアカウントID所有ではなく、自分自身AWSアカウントID所有のAMIとなります。

AWS NatゲートウェイでAZを跨がないようルートテーブルに定義することが推奨されている件について

Sun, 26 Mar 2023 14:09:00 GMT

目次

概要
検証
1. サブネット作成時のAZ選択画面
2. ping検証
感想

概要

AWS Certified Advanced Networking – Specialty（ANS-C01）の資格勉強をおこなっていたところ、ある書籍にて「インスタンスからNATゲートウェイへの通信はAZをまたがないよう、ルートテーブルにルートを定義します。」と記載がありました。

私は、当初、NatゲートウェイってAZまたがないと使えないのでは？と思っていましたが、サブネット作成時にAZ選べれたので恥ずかしかったです。

今回は、AZまたぐ場合とまたがない場合の差違について簡単に試してみましたので備忘録として記録します。

検証

サブネット作成時のAZ選択画面

サブネット作成画面で、1a、1cなど選択できることが分かりますね。

private subnet 1a（apne1-az4）に所属したEC2インスタンスからpublic subnet 1a（apne1-az4）に所属したnatインスタンスを経由した時のping値とprivate subnet 1a（apne1-az4）に所属したEC2インスタンスからpublic subnet 1c（apne1-az1）に所属したnatインスタンスを経由した時のping値を計測してみます。

画像をホバー/タップすると拡大表示されます

ping検証

natおよびsubnetともに1a

private subnet 1a（apne1-az4）に所属したEC2インスタンスからpublic subnet 1a（apne1-az4）に所属したnatインスタンスを経由した時のping値

[root@nat-test ~]# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 バイト応答 送信元 8.8.8.8: icmp_seq=1 ttl=103 時間=2.77ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=2 ttl=103 時間=2.39ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=3 ttl=103 時間=2.34ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=4 ttl=103 時間=2.35ミリ秒

--- 8.8.8.8 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.341/2.460/2.770/0.179 ms

nat 1c、subnet 1a

private subnet 1a（apne1-az4）に所属したEC2インスタンスからpublic subnet 1c（apne1-az1）に所属したnatインスタンスを経由した時のping値

[root@nat-test ~]# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 バイト応答 送信元 8.8.8.8: icmp_seq=1 ttl=103 時間=6.29ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=2 ttl=103 時間=4.92ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=3 ttl=103 時間=4.94ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=4 ttl=103 時間=4.95ミリ秒

--- 8.8.8.8 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.918/5.274/6.292/0.587 ms

感想

結果、同じAZに属している方が、同じデータセンター内からの接続の為、ping値が早いことが分かりました。

ドキュメントにも以下の様に記載がありました。

NAT ゲートウェイの基本

アベイラビリティーゾーン別に NAT ゲートウェイを作成し、同じアベイラビリティーゾーンに属する NAT ゲートウェイをリソースで使用するようにルーティングを設定します。

普段、気にしないところだったので勉強になりました。

haproxyによるWEB負荷分散

Sat, 25 Jun 2022 06:59:00 GMT

目次

概要
WEB01での作業
1. Apacheのインストール（WEB01）
2. コンテンツ設置（WEB01）
WEB02での作業
1. Apacheのインストール（WEB02）
2. コンテンツ設置（WEB02）
haproxyサーバでの作業
まとめ

概要

AlmaLinuxにて、haproxyを利用したWEBの負荷分散をしてみたいと思います。

今回、利用する環境は、haproxyサーバ1台、WEBサーバ2台構成とします。

haproxyサーバからWEB2台の private ip に対してチェックをおこないます。

サーバ名	private ip
WEB01	10.0.0.224
WEB02	10.0.0.97

画像をホバー/タップすると拡大表示されます

トラブルを防ぐため、iptablesやfirewalldやnftables等が動作していないことおよび、SELinuxが無効になっていることとします。

WEB01での作業

Apacheのインストール（WEB01）

haproxyでWEB負荷分散するためには、分散先でWEBサービスを Listen していなければいけないのでapacheのインストールをおこないます。

[root@WEB01 ~]# dnf -y install httpd

・
・[中略]
・
Installing:
 httpd                                      x86_64                      2.4.37-47.module_el8.6.0+2935+fb177b09.2                      appstream                      1.4 M
・
・[中略]
・
Complete!

[root@WEB01 ~]# systemctl --now enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

　→apacheサービスの自動起動を有効にし、サービスを開始します。

コンテンツ設置（WEB01）

haproxyによって分散先がわかるように、以下の様なコンテンツを設置します。

設置後、 http://{WEB01のグローバルIP}/ に対してアクセスをおこない、緑の背景に「WEB01のコンテンツが表示されているよ！」と表示されれば問題ありません。

[root@WEB01 ~]# vim /var/www/html/index.html

<!DOCTYPE html>
<html>
        <head>
                <meta charset="UTF-8">
                <title>WEB01のコンテンツ</title>
        </head> <!-- head -->

        <body style="background-color:green;">
                <h1>WEB01のコンテンツが表示されているよ！</h1><br>
        </body> <!-- body -->
</html> <!-- html -->

WEB02での作業

Apacheのインストール（WEB02）

WEB02でもWEB01同様の作業を実施します。

[root@WEB02 ~]# dnf -y install httpd

・
・[中略]
・
Installing:
 httpd                                      x86_64                      2.4.37-47.module_el8.6.0+2935+fb177b09.2                      appstream                      1.4 M
・
・[中略]
・
Complete!

[root@WEB02 ~]# systemctl --now enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

　→apacheサービスの自動起動を有効にし、サービスを開始します。

コンテンツ設置（WEB02）

haproxyによって分散先がわかるように、以下の様なコンテンツを設置します。

設置後、 http://{WEB02のグローバルIP}/ に対してアクセスをおこない、ピンクの背景に「WEB02のコンテンツが表示されているよ！」と表示されれば問題ありません。

[root@WEB02 ~]# vim /var/www/html/index.html

<!DOCTYPE html>
<html>
        <head>
                <meta charset="UTF-8">
                <title>WEB02のコンテンツ</title>
        </head> <!-- head -->

        <body style="background-color:pink;">
                <h1>WEB02のコンテンツが表示されているよ！</h1>
        </body> <!-- body -->
</html> <!-- html -->

haproxyサーバでの作業

haproxyインストール

[root@haproxy ~]# dnf install haproxy

Last metadata expiration check: 0:09:46 ago on Sat 25 Jun 2022 05:21:37 PM JST.
Dependencies resolved.
===============================================================================================================================================
 Package                         Architecture                   Version                                Repository                         Size
===============================================================================================================================================
Installing:
 haproxy                         x86_64                         1.8.27-4.el8                           appstream                         1.4 M

Transaction Summary
===============================================================================================================================================
Install  1 Package

Total download size: 1.4 M
Installed size: 4.2 M
Is this ok [y/N]: y
・
・[中略]
・

[root@haproxy ~]# systemctl --now enable haproxy

Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → /usr/lib/systemd/system/haproxy.service.

　→haproxyサービスの自動起動を有効にし、サービスを開始します。

haproxy設定ファイルの編集

[root@haproxy ~]# cp -p /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.org
[root@haproxy ~]# cp -p /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg_$(date +"%Y%m%d")
→あらかじめ、バックアップを取ります。

設定の確認

以下の様にデフォルトで、 log 127.0.0.1 local2 となっており、 syslogの種類が local2 となっていることを確認します。

[root@haproxy ~]# cat /etc/haproxy/haproxy.cfg

#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
・
・[中略]
・
    log         127.0.0.1 local2
・
・[中略]
・

haproxyインストールしたての /etc/haproxy/haproxy.cfg は以下のようになっているので変更します。

・
・[中略]
・
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend main
    bind *:5000
    acl url_static       path_beg       -i /static /images /javascript /stylesheets
    acl url_static       path_end       -i .jpg .gif .png .css .js

    use_backend static          if url_static
    default_backend             app

#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
backend static
    balance     roundrobin
    server      static 127.0.0.1:4331 check

#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend app
    balance     roundrobin
    server  app1 127.0.0.1:5001 check
    server  app2 127.0.0.1:5002 check
    server  app3 127.0.0.1:5003 check
    server  app4 127.0.0.1:5004 check

設定変更

以下のように、80番ポートで Listen し、分散先として、WEB01およびWEB02の private ip を指定するようにします。

[root@haproxy ~]# cat /etc/haproxy/haproxy.cfg

・
・[中略]
・
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend http_web
    bind *:80
    mode http
    default_backend app

#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend app
    balance     roundrobin
    mode http
    server WEB01 10.0.0.224:80 check
    server WEB02 10.0.0.97:80 check

diffの結果として、以下のような感じになることを確認します。

[root@haproxy ~]# diff -u /etc/haproxy/haproxy.cfg_$(date +"%Y%m%d") /etc/haproxy/haproxy.cfg

--- /etc/haproxy/haproxy.cfg_20220625   2022-04-19 04:31:18.000000000 +0900
+++ /etc/haproxy/haproxy.cfg    2022-06-25 20:02:21.718000000 +0900
@@ -64,27 +64,16 @@
 #---------------------------------------------------------------------
 # main frontend which proxys to the backends
 #---------------------------------------------------------------------
-frontend main
-    bind *:5000
-    acl url_static       path_beg       -i /static /images /javascript /stylesheets
-    acl url_static       path_end       -i .jpg .gif .png .css .js
-
-    use_backend static          if url_static
-    default_backend             app
-
-#---------------------------------------------------------------------
-# static backend for serving up images, stylesheets and such
-#---------------------------------------------------------------------
-backend static
-    balance     roundrobin
-    server      static 127.0.0.1:4331 check
+frontend http_web
+    bind *:80
+    mode http
+    default_backend app

 #---------------------------------------------------------------------
 # round robin balancing between the various backends
 #---------------------------------------------------------------------
 backend app
     balance     roundrobin
-    server  app1 127.0.0.1:5001 check
-    server  app2 127.0.0.1:5002 check
-    server  app3 127.0.0.1:5003 check
-    server  app4 127.0.0.1:5004 check
+    mode http
+    server WEB01 10.0.0.224:80 check
+    server WEB02 10.0.0.97:80 check

haproxyログ出力設定

haproxyのログを、 rsyslog で受信できるようにするため、 rsyslog 側での設定変更をします。

[root@haproxy ~]# netstat -nlp | grep 514
→UDP 514番ポートで受信するようにしたいため、あらかじめ Listen していないことを確認します。
※なにも出力がなければokです。

[root@haproxy ~]# cp -p /etc/rsyslog.conf /etc/rsyslog.conf_$(date +"%Y%m%d")
[root@haproxy ~]# cp -p /etc/rsyslog.conf /etc/rsyslog.conf.org
→あらかじめ設定ファイルのバックアップをおこないます。

rsyslog 設定ファイルを編集します。

module(load="imudp") # needs to be done just once および input(type="imudp" port="514") がコメントアウトされているのでコメントアウトを外します。
→これで、UDP 514番ポート待ち受けが有効になります。

# ### sample forwarding rule ### の上側あたりに、 local2.* /var/log/haproxy.log の記述を追加します。
→こちらを追加することにより、haproxyのログが、 /var/log/haproxy.log に記録されます。

重複ログ破棄設定

このままでは、 /var/log/messages にも /var/log/haproxy.log と同様の内容が記録されるため、 /var/log/haproxy.log にのみ記録するようにします。

*.info;mail.none;authpriv.none;cron.none /var/log/messages

↓以下へ変更。

*.info;mail.none;authpriv.none;cron.none;local2.none /var/log/messages

という風に local2.none を追加することで、 messages の haproxy 重複ログを抑制することが可能となります。

[root@haproxy ~]# vim /etc/rsyslog.conf

・
・[中略]
・
module(load="imudp") # needs to be done just once
input(type="imudp" port="514")
・
・[中略]
・
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local2.none                /var/log/messages
・
・[中略]
・
# Log all the haproxy messages in one place.
local2.*                                                /var/log/haproxy.log
・
・[中略]
・

rsyslog 設定ファイルの diff 結果は以下の通りとなります。

[root@haproxy ~]# diff -u /etc/rsyslog.conf_$(date +"%Y%m%d") /etc/rsyslog.conf

--- /etc/rsyslog.conf_20220625  2022-05-30 16:47:31.000000000 +0900
+++ /etc/rsyslog.conf   2022-06-25 21:08:50.901000000 +0900
@@ -16,8 +16,8 @@

 # Provides UDP syslog reception
 # for parameters see http://www.rsyslog.com/doc/imudp.html
-#module(load="imudp") # needs to be done just once
-#input(type="imudp" port="514")
+module(load="imudp") # needs to be done just once
+input(type="imudp" port="514")

 # Provides TCP syslog reception
 # for parameters see http://www.rsyslog.com/doc/imtcp.html
@@ -43,7 +43,7 @@

 # Log anything (except mail) of level info or higher.
 # Don't log private authentication messages!
-*.info;mail.none;authpriv.none;cron.none                /var/log/messages
+*.info;mail.none;authpriv.none;cron.none;local2.none                /var/log/messages

 # The authpriv file has restricted access.
 authpriv.*                                              /var/log/secure
@@ -64,6 +64,8 @@
 # Save boot messages also to boot.log
 local7.*                                                /var/log/boot.log

+# Log all the haproxy messages in one place.
+local2.*                                                /var/log/haproxy.log

 # ### sample forwarding rule ###

[root@haproxy ~]# systemctl restart haproxy rsyslog
→最後に haproxy と rsyslog サービスを再起動し、設定を適用します。

事後確認

http://{haproxyのグローバルIP}/ にアクセスし、ページリロード毎に、コンテンツが切り替わる事および、 haproxy.log のみにログが出力されていることを確認できればログ設定と負荷分散が上手くおこなえています。

ページリロード毎に以下、画像のように切り替わります。

画像をホバー/タップすると拡大表示されます　　　　　　　　　　　　　　　　 ↑↓ 画像をホバー/タップすると拡大表示されます

まとめ

私自身、haproxyについて、あまり理解できていなかったですが、実際に構築してみて、少しは理解できたかなぁと思いました。

簡単に冗長化できて感無量です！

AmazonLinux2022へTeraterm接続で躓いた件について

Fri, 03 Dec 2021 20:02:00 GMT

目次

概要
前提条件
環境
事象
対処
動作確認
まとめ
余談

概要

本日は、TeratermからAmazonLinux2022へ接続した際に、時間を溶かしたので備忘録として記録します。

前提条件

Amazon Linux2022インスタンスをAWSにデプロイ済みであること。

※AmazonLinux2022のデプロイ方法は以下を参考にしてください。

Launching Amazon Linux 2022 via EC2 Management Console

環境

ツール名	バージョン
Teraterm	4.106
（bash client）ssh	OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
（bash client os）	Microsoft Windows [Version 10.0.19043.1348]

事象

TeratermからAWS上に建てたAmazonLinux2022に対して接続すると認証に失敗する事象が発生します。

画像をホバー/タップすると拡大表示されます

Windowsのコマンドプロンプトからssh接続すると正常に接続できます。 ※altest.pemは、AmazonLinux2022インスタンス作成時に指定した秘密鍵を指定します。

D:\***\***>ssh -i altest.pem ec2-user@13.114.102.110

The authenticity of host '13.114.102.110 (13.114.102.110)' can't be established.
ECDSA key fingerprint is SHA256:u2mgWsLP+vfrTtQmNIGRFFVEXl5K50hGy13jmGIjTA4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '13.114.102.110' (ECDSA) to the list of known hosts.
       __|  __|_  )
       _|  (     /   Amazon Linux 2022 AMI
      ___|\___|___|  Preview

http://aws.amazon.com/linux/amazon-linux-2022

ssh接続ログを見ると、ssh-rsaが許可されていない旨のログがでていることが確認できます。

これは、AmazonLinux2022内部のOpenSSHがRSA/SHA1（ssh-rsaシグネチャ）をデフォルトで無効化されている事に起因します。

OpenSSH、今後はRSA/SHA1をデフォルトで無効に

[root@ip-10-0-0-120 ssh]# tail -f /var/log/secure

Dec  3 17:44:15 localhost sshd[14533]: userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

[root@ip-10-0-0-120 ssh]# ssh -V

OpenSSH_8.6p1, OpenSSL 1.1.1l  FIPS 24 Aug 2021

対処

sshd_configの先頭行等に PubkeyAcceptedAlgorithms=+ssh-rsa を書き込み、ssh-rsaシグネチャを許可するようにします。

cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org

cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config_$(date +%Y%m%d)

sed -i '1s/^/PubkeyAcceptedAlgorithms=+ssh-rsa\n/' /etc/ssh/sshd_config

systemctl restart sshd.service

動作確認

再度、Teratermからインスタンスにアクセスすると正常に接続できることが確認できます。

画像をホバー/タップすると拡大表示されます

ログ上からも認証が許可されていることが確認できます。

[root@ip-10-0-0-120 ssh]# tail -f /var/log/secure

Dec  3 18:31:10 localhost sshd[15526]: Accepted publickey for ec2-user from ***.***.***.*** port 50731 ssh2: RSA SHA256:************************
Dec  3 18:31:10 localhost sshd[15526]: pam_unix(sshd:session): session opened for user ec2-user(uid=1000) by (uid=0)
Dec  3 18:31:32 localhost sshd[15560]: Received disconnect from ***.***.***.*** port 50731:11: disconnected by server request
Dec  3 18:31:33 localhost sshd[15560]: Disconnected from user ec2-user ***.***.***.*** port 50731
Dec  3 18:31:33 localhost sshd[15526]: pam_unix(sshd:session): session closed for user ec2-user

まとめ

AmazonLinux2022のOpenSSLのバージョンが高いことによるもので、とても、勉強になりました。

以下、リンクは、AmazonLinux2022、AmazonLinux2、CentOS、Rocky LinuxについてAmazonLinux2022の位置づけが語られている興味深い記事なので是非みてみてください。

What’s different about Amazon Linux 2022? - DEV Community

余談

AmazonLinux2022インスタンス作成時に、ユーザデータとして以下を記述し、デプロイすることで本記事事象を回避できます。

#!/usr/bin/env bash
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config_$(date +%Y%m%d)
sed -i '1s/^/PubkeyAcceptedAlgorithms=+ssh-rsa\n/' /etc/ssh/sshd_config
systemctl stop sshd.service
systemctl start sshd.service

yumパッケージ管理でpyenvを使用したpythonインストール時のビルドエラートラブルシューティング

Fri, 26 Nov 2021 14:37:00 GMT

目次

事象
対処
対処後

事象

pyenvを使用してpythonをインストールしようとした時に以下のようにビルドエラーとなっている場合を想定しております。

pyenv install 3.9.0

Downloading Python-3.9.0.tar.xz...
-> https://www.python.org/ftp/python/3.9.0/Python-3.9.0.tar.xz
Installing Python-3.9.0...
WARNING: The Python bz2 extension was not compiled. Missing the bzip2 lib?
WARNING: The Python readline extension was not compiled. Missing the GNU readline lib?
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?

対処

以下、開発者ツールおよびpythonビルドに追加で必要なライブラリをインストールします。

yum groupinstall "Development Tools" -y

yum install zlib-devel bzip2 bzip2-devel readline-devel sqlite sqlite-devel openssl-devel xz xz-devel -y

対処後

以下のようにエラーや警告なくインストール完了すれば問題ございません。

pyenv install 3.9.0

pyenv: /root/.pyenv/versions/3.9.0 already exists
continue with installation? (y/N) y
Downloading Python-3.9.0.tar.xz...
-> https://www.python.org/ftp/python/3.9.0/Python-3.9.0.tar.xz
Installing Python-3.9.0...
Installed Python-3.9.0 to /root/.pyenv/versions/3.9.0

rustでServerless Framework使用してaws lambda関数をデプロイし実行してみた

Sat, 26 Jun 2021 05:18:00 GMT

目次

概要
前提条件
Rustについて
Serverless Frameworkのセットアップ
まとめ

概要

今回は、rust言語で、Serverless Frameworkを用いてAWS Lambda上にデプロイ（サンプルプログラム）し、Hello World!というお決まりのワードを表示してみたいと思います。

前提条件

awsコマンドインストール済で、aws configure認証情報設定済であること。
dockerがインストール済で、dockerサービスが起動していること。

Rustについて

Rustはシステムプログラミングや、コマンドラインプログラム、Webサーバ等、さまざまな用途に使用できるプログラミング言語です。

スピードとメモリー使用の観点で効率的で信頼性の高いコードへと自然に導くよう設計されており、C言語で問題となっているメモリー関連で弱かった部分をカバーしています。

また、コンパイラー型言語なのでコンパイル時、コードに問題のある箇所を確実に補足してくれます。

今回は、そのような特徴をもったRustがAWSからAWS SDK for RustというSDKがαリリースされましたので実際に使用していきたいと思います。

※ AWS SDK を使用した、連携は第2回目の記事で記載します。
※ 今回は、ただRustをLambda上で動かしてみるという内容になります。

Serverless Frameworkのセットアップ

Node.jsのインストール

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh | bash

. ~/.nvm/nvm.sh
→nvmの有効化

nvm install --lts --latest-npm
→nodeのインストール

nvm alias default 'lts/*'
→デフォルトにする。

※nvm(Node Version Manager)を使ってNode.jsをインストールする手順

LTSバージョンインストールについて

node -e "console.log('Running Node.js ' + process.version)"

Running Node.js v14.17.1

→Node.jsがインストールされたことを確認。

Serverless Frameworkのインストール

mkdir sls
→ディレクトリ作成

cd sls

npm init
→いくつか質問されるがすべてEnterで、最後の質問は、yesでOk。

npm install --save serverless
→Serverless Framework本体をインストール。

npm bin serverless

/root/sls/node_modules/.bin

echo 'export PATH="$HOME/sls/node_modules/.bin/:$PATH"' >> ~/.bash_profile
→パスを通す。

source ~/.bash_profile
→適用する。

serverless -v

Framework Core: 2.48.0 (local)
Plugin: 5.4.1
SDK: 4.2.3
Components: 3.12.0

→Serverless Frameworkがインストールされたことを確認。

※Serverless FrameworkでAWS Lambda関数を作成する

こちらの記事に書かれている内容となります。

プロジェクトの作成

cd ~
→ホームディレクトリ直下へ移動。

npx serverless install \
  --url https://github.com/softprops/serverless-aws-rust \
  --name rust-first-lambda-app \
  && cd rust-first-lambda-app \
  && npm install --silent

Need to install the following packages:
  serverless
Ok to proceed? (y) y
・
・
・
Serverless: Downloading and installing "serverless-aws-rust"...
Serverless: Successfully installed "serverless-aws-rust" as "rust-first-lambda-app"

→serverless AWS Rust templateが用意されているのでありがたく使わせてもらいます。

AWS上にデプロイ

npx serverless deploy

Serverless: Building Rust hello func...
Serverless: Running containerized build
Unable to find image 'softprops/lambda-rust:0.2.7-rust-1.43.1' locally
0.2.7-rust-1.43.1: Pulling from softprops/lambda-rust
・
・
・
   Compiling hello v0.1.0 (/code)
    Finished release [optimized] target(s) in 2m 58s
  adding: bootstrap (deflated 61%)
Serverless: Packaging service...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
・
・
・
Serverless: Stack update finished...
Service Information
service: rust-first-lambda-app
stage: dev
region: us-east-1
stack: rust-first-lambda-app-dev
resources: 6
api keys:
  None
endpoints:
  None
functions:
  hello: rust-first-lambda-app-dev-hello
layers:
  None

→Serverless Frameworkの標準的なデプロイコマンドで実施、AWS Lambda上に提供されるrustカスタムランタイムでビルドされ、その後、CloudFormationスタックが作成されデプロイされます。

AWS上にデプロイされたLambda関数の実行

npx serverless invoke -f hello -d ’{“Hello”:“World!”}’

{
    "Hello": "World!"
}

→正常に渡した値が返ってきていることが確認できました。

AWS上での確認

node.jsとrustで比較するのは、酷かもしてれませんが、メモリ効率、実行速度ともに良いですね。

CloudFormation

画像をホバー/タップすると拡大表示されます

Lambda（rust）

画像をホバー/タップすると拡大表示されます

Lambda（node.js）

画像をホバー/タップすると拡大表示されます

まとめ

Serverless Frameworkを使用すると簡単にAWS上へLambda関数をデプロイすることができ、ビルド環境もコンテナー上で処理されるのでいいことだらけですね。

CentOS8にpodmanをインストールしてみた

Wed, 09 Jun 2021 09:35:00 GMT

Photo by podman.io(2019) / Adapted.

目次

概要
手順
1. podmanのインストール
  1. コンテナーモジュールのインストール
  2. Dockerコマンドを使用できるようにする
2. コンテナーを実行してみる
まとめ

概要

CentOS Stream release 8にpodmanと言われるコンテナーオーケストレーションツールを入れてみます。

その後、WEBサーバコンテナーを持ってきて、ブラウザから、コンテナーにアクセスできることを確認します。

手順

podmanのインストール

コンテナーモジュールのインストール

[root@dev ~]# dnf module install container-tools

Dockerコマンドを使用できるようにする

[root@dev ~]# dnf install podman-docker

podmanコマンドラインをdockerコマンドに置き換えて実行できるようになります。

コンテナーを実行してみる

iptablesへ設定を追加する

[root@dev ~]# iptables -t filter -I FORWARD -i cni-podman0 ! -o cni-podman0 -j ACCEPT

[root@dev ~]# systemctl stop nftables

ファイアウォールを停止する。

WEBサーバコンテナーを実行する

[root@dev ~]# docker run --rm -p 8080:80 -it php:apache bash

root@b784d756b0b2:/var/www/html# apt-get update

・・・
Fetched 8448 kB in 2s (4250 kB/s)
Reading package lists... Done

aptを最新にする。

root@b784d756b0b2:/var/www/html# apt install vim

Reading package lists... Done
Building dependency tree
Reading state information... Done
・・・

エディターをインストール。

root@b784d756b0b2:/var/www/html# vim index.html

Hello World Podman

root@b784d756b0b2:/var/www/html# /etc/init.d/apache2 start

[....] Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.88.0.8. Set the 'ServerName' directive globally to suppress this message
. ok

WEBサーバサービス開始。

WEBサーバコンテナーにWEBブラウザからアクセスしてみる

http://***.***.***.***:8080/

GIPまたはLIPの8080番ポートにアクセスし、「Hello World Podman」が表示されることを確認します。

以下、キャプチャ画像のようになっていれば問題ありません。

画像をホバー/タップすると拡大表示されます

まとめ

dockerと比較し、podmanはvs codeとの連携ができなかったので、利便性を考えると微妙な感じでした。

今後、もっと親和性が向上していくことを願うばかりです。

インフラストラクチャ定義ツールについて

Thu, 03 Jun 2021 20:57:00 GMT

目次

Infrastructure as Codeのためのツール
無人実行のサポート

Infrastructure as Codeのためのツール

Cloud Formation、TerraFrom、OpenStack Heat等のツールがあり、インフラストラクチャリソースの割り当てや、どのような構成・設定をしたいのか指定します。

Infrastructure as Codeのメリットを享受する場合、インフラは、反復・テスト・再利用可能で自己記述的に管理する必要があります。

無人実行のサポート

信頼性の高い無人実行をサポートするために、スクリプトやタスクが備えるべき特徴として以下が挙げられる。

べき等（idempotent）

悪影響を及ぼさずに、同じスクリプトやタスクを複数回実行できる。

事前チェック

タスクは、開始するための条件を満たしているかチェックし、満たしていなければ目に見える形で意味のあるエラーを出力し、処理を失敗させシステムを使える状態に保つ。

事後チェック

タスクは、変更を加えることに成功したかどうかをチェックしする。
単にコマンドのリターンコードをチェックするだけではなく結果が正しいことを証明しなければならない。

例えば、Webサーバにおいて、バーチャルホストが追加されたことを確認するために、WebサーバにHTTPリクエストを送らなければならない。

目に見える形の失敗

タスクが正しく実行を失敗させた場合、その失敗はチームからわかる形になっていなければならない。
情報ラジエータ（自動テスト、速さ、インシデントレポート、継続的インテグレーションなどの最新情報がチーム等、一目で確認できるよう目につきやすい場所へ設置する手書きや絵や電子的なディスプレイの総称）を使用したり、モニタリングサービスと統合したりといった方法を使う。

What is an Information Radiator? | Agile Alliance
CommunalDashboard
パラメーター化

タスクは、同じタイプの複数オペレーションで使用できなければならない。
たとえば、1つのスクリプトで特徴の異なる複数仮想ホストを構成および設定や特定のパラメーターを見つける方法、条件ロジックやテンプレートを駆使し状況にあった構成・設定ができなければならない。

CentOS8 podman pull official image amazonlinux 起動エラー（未解決）

Fri, 26 Mar 2021 20:30:00 GMT

Photo by podman.io(2019) / Adapted.

目次

概要
コマンド

概要

CentOS8環境のpodmanに対してオフィシャルイメージのAmazonLLinuxをインストールすると下記エラーが出力され未解決・・・

Error reading manifest latest in docker.io/library/935e8db88df5: errors:

コマンド

[root@dev ~]# dnf install podman-docker

メタデータの期限切れの最終確認: 1:41:41 時間前の 2021年03月27日 00時25分40秒 に実施しました。
依存関係が解決しました。
=========================================================================================
 パッケージ            アーキテクチャー バージョン                            リポジトリー サイズ
=========================================================================================
podman-docker        noarch         2.2.1-7.module_el8.3.0+699+d61d9c41  AppStream  47 k
・
・
・
依存関係のインストール:
podman               x86_64         2.2.1-7.module_el8.3.0+699+d61d9c41  AppStream  14 M

[root@dev ~]# podman -v

podman version 2.2.1

[root@dev ~]# docker -v

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
podman version 2.2.1

[root@dev ~]# docker search --filter is-official=true amazonlinux

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
INDEX      NAME                           DESCRIPTION                                      STARS   OFFICIAL  AUTOMATED
docker.io  docker.io/library/amazonlinux  Amazon Linux provides a stable, secure, and ...  993     [OK]

[root@dev ~]# docker pull docker.io/library/amazonlinux

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Trying to pull docker.io/library/amazonlinux:latest...
Getting image source signatures
Copying blob 9da98c321efd done
Copying config 935e8db88d done
Writing manifest to image destination
Storing signatures
935e8db88df5c8906a27e29bf38705c932802cfcfccd5cd39abf408554badb97

[root@dev ~]# docker images

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
REPOSITORY                     TAG     IMAGE ID      CREATED      SIZE
docker.io/library/amazonlinux  latest  935e8db88df5  4 weeks ago  170 MB

Kubernetesクラスターへワーカーノードを追加してみる

Mon, 01 Mar 2021 18:17:00 GMT

Photo by CNCF – Change of venue(2019) / Adapted.

目次

概要
手順
Dockerのインストール
Kubernetesワーカーノード構築
まとめ

概要

今回は、「Raspberry Pi 4 Model B/4GB」にインストールしたKubernetes
シングルマスターへワーカーノードを1台追加してみたいと思います。

使用する環境は、「Ubuntu 20.10 aarch64」となります。
すべて管理者権限で操作をします。

この記事ではシングルマスター構築は触れませんので注意してください。

手順

Dockerのインストール

ファイアウォールの無効化

Kubernetesが動作する上でFWが原因で動作に問題が生じないように無効化します。

root@k8s-node-a:~# systemctl disable ufw.service

root@k8s-node-a:~# systemctl stop ufw.service

root@k8s-node-a:~# systemctl is-enabled ufw.service

disabled

root@k8s-node-a:~# systemctl is-active ufw.service

inactive

パッケージインデックスを最新に更新

root@k8s-node-a:~# apt-get update

864 kB を 5秒 で取得しました (171 kB/s)
パッケージリストを読み込んでいます... 完了

HTTPS経由でインストールできるようにするための準備

root@k8s-node-a:~# apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

上記コマンドを実行、実行すると下記のように続行するか聞かれるので「y」と押しEnterします。

・
・[中略]
・
この操作後に追加で 209 kB のディスク容量が消費されます。
続行しますか? [Y/n] y
・
・[中略]
・

DockerオフィシャルGPGキー追加

root@k8s-node-a:~# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

下記コマンドでインストールされたことを確認できます。

root@k8s-node-a:~# apt-key list

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
・
・[中略]
・
pub   rsa4096 2017-02-22 [SCEA]
      9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid           [  不明  ] Docker Release (CE deb) <docker@docker.com>
sub   rsa4096 2017-02-22 [S]
・
・[中略]
・
------------------------------------------------------
・
・[中略]
・

Docker Arm64版リポジトリ追加

root@k8s-node-a:~# add-apt-repository \
   "deb [arch=arm64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

コマンドを実行すると以下のようにDocker arm64レポジトリが取得されていることが分かりますね。

また、httpsを経由していることも同時に分かりますね。

Repository: 'deb [arch=arm64] https://download.docker.com/linux/ubuntu groovy stable'
Description:
Archive for codename: groovy components: stable
More info: https://download.docker.com/linux/ubuntu
Adding repository.
Press [ENTER] to continue or Ctrl-c to cancel.
Adding deb entry to /etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-groovy.list
Adding disabled deb-src entry to /etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-groovy.list
取得:1 https://download.docker.com/linux/ubuntu groovy InRelease [27.4 kB]
取得:2 https://download.docker.com/linux/ubuntu groovy/stable arm64 Packages [4,983 B]
・
・[中略]
・
32.3 kB を 3秒 で取得しました (12.7 kB/s)
パッケージリストを読み込んでいます... 完了

後から追加したレポジトリのリストは、/etc/apt/sources.list.d/に記録されます。

root@k8s-node-a:~# cat /etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-groovy.list

deb [arch=arm64] https://download.docker.com/linux/ubuntu groovy stable
# deb-src [arch=arm64] https://download.docker.com/linux/ubuntu groovy stable

Dockerエンジン（コミュニティ）版のインストール

パッケージインデックスを最新に更新します。

root@k8s-node-a:~# apt-get update

containerdはDocker社が開発している、コンテナーランタイムになりDockerのコンポーネントの一部として動作します。

途中で続行するか聞かれるので「y」を入力後、Enterを押します、その後、シムリンクが張られ自動起動ONになることが確認できます。

root@k8s-node-a:~# apt-get install docker-ce docker-ce-cli containerd.io

パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  docker-ce-rootless-extras libslirp0 pigz slirp4netns
提案パッケージ:
  cgroupfs-mount | cgroup-lite
以下のパッケージが新たにインストールされます:
  containerd.io docker-ce docker-ce-cli docker-ce-rootless-extras libslirp0 pigz slirp4netns
アップグレード: 0 個、新規インストール: 7 個、削除: 0 個、保留: 0 個。
83.9 MB のアーカイブを取得する必要があります。
この操作後に追加で 397 MB のディスク容量が消費されます。
続行しますか? [Y/n] y
・
・[中略]
・
containerd.io (1.4.3-1) を設定しています ...
Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service → /lib/systemd/system/containerd.service.
docker-ce-cli (5:20.10.4~3-0~ubuntu-groovy) を設定しています ...
libslirp0:arm64 (4.3.1-1) を設定しています ...
pigz (2.4-1) を設定しています ...
slirp4netns (1.0.1-1) を設定しています ...
docker-ce (5:20.10.4~3-0~ubuntu-groovy) を設定しています ...
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.
Created symlink /etc/systemd/system/sockets.target.wants/docker.socket → /lib/systemd/system/docker.socket.
docker-ce-rootless-extras (5:20.10.4~3-0~ubuntu-groovy) を設定しています ...
systemd (246.6-1ubuntu1.1) のトリガを処理しています ...
man-db (2.9.3-2) のトリガを処理しています ...
libc-bin (2.32-0ubuntu3) のトリガを処理しています ...

一般ユーザでもdockerを使えるようにする

root@k8s-node-a:~# gpasswd -a ubuntu docker

ユーザ ubuntu をグループ docker に追加

追加されたことは分かりますね。

root@k8s-node-a:~# grep docker /etc/group

docker:x:998:ubuntu

Kubernetesワーカーノード構築

事前準備

memoryが「0」無効化状態だとマスターを構築する際にERRORがでたので念の為、ワーカーノード側でも有効化状態に変更します。

現在は、下記の通り無効化状態であることが確認できます。

root@k8s-node-a:~# cat /proc/cgroups

#subsys_name    hierarchy       num_cgroups     enabled
・
・[中略]
・
memory  0       109     0
・
・[中略]
・

書き込み前の内容となります。

root@k8s-node-a:~# cat /boot/firmware/cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash

以下内容をboot時に読み込むファイルへ書き込みます。

末尾につづけて書くようにします。

root@k8s-node-a:~# vi /boot/firmware/cmdline.txt

cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

筆者、環境では書き込み後以下のようになりました。

root@k8s-node-a:~# cat /boot/firmware/cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash cgroup_enable=cpuset cgroup_enable=memory cgroup_memory=1

このままでは設定が適用されないのでOS再起動をおこないます。

root@k8s-node-a:~# reboot

無効状態「0」だったのが有効状態「1」になっていることが確認できますね。

root@k8s-node-a:~# cat /proc/cgroups

#subsys_name    hierarchy       num_cgroups     enabled
・
・[中略]
・
memory  11      486     1
・
・[中略]
・

KubernetesではSWAP領域を無効化することが条件になっていますので確認します。

以下コマンドでSWAPが有効になっているか確認できます、筆者環境では元々、SWAP領域がなかったようです。

この場合、なんの問題もないのでスルーしましょう。

root@k8s-node-a:~# /sbin/swapon -s

root@k8s-node-a:~# cat /proc/swaps

Filename                                Type            Size            Used            Priority

iptablesがnftablesバックエンドを使用しないようにする

Kubernetesはnftablesと互換性がないので以下コマンドをしようしてiptablesを使用するよう設定します。

root@k8s-node-a:~# apt-get install -y iptables arptables ebtables

root@k8s-node-a:~# update-alternatives --set iptables /usr/sbin/iptables-legacy

root@k8s-node-a:~# update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

root@k8s-node-a:~# update-alternatives --set arptables /usr/sbin/arptables-legacy

root@k8s-node-a:~# update-alternatives --set ebtables /usr/sbin/ebtables-legacy

KubernetesオフィシャルGPGキー追加

root@k8s-node-a:~# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

下記コマンドでインストールされたことを確認できます。

root@k8s-node-a:~# apt-key list

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
・
・[中略]
・
pub   rsa2048 2018-04-01 [SCE] [有効期限: 2021-03-31]
      54A6 47F9 048D 5688 D7DA  2ABE 6A03 0B21 BA07 F4FB
uid           [  不明  ] Google Cloud Packages Automatic Signing Key <gc-team@google.com>
・
・[中略]
・
------------------------------------------------------
・
・[中略]
・

Kubernetessリポジトリ追加

root@k8s-node-a:~# cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

レポジトリの設定ができたことを確認できますね。

root@k8s-node-a:~# cat /etc/apt/sources.list.d/kubernetes.list

deb https://apt.kubernetes.io/ kubernetes-xenial main

Kubernetessインストール

パッケージインデックスを最新に更新します。

root@k8s-node-a:~# apt-get update

以下、ツールのインストールをおこないます。

kubeadm：クラスターを起動するコマンドです。
kubelet　：クラスターの各ノードでPodを管理するコンポーネントです。
kubectl　：クラスターにアクセスするためのコマンドラインツールです。

root@k8s-node-a:~# apt-get install -y kubelet kubeadm kubectl

パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
以下の追加パッケージがインストールされます:
  conntrack cri-tools kubernetes-cni socat
提案パッケージ:
  nftables
以下のパッケージが新たにインストールされます:
  conntrack cri-tools kubeadm kubectl kubelet kubernetes-cni socat
アップグレード: 0 個、新規インストール: 7 個、削除: 0 個、保留: 0 個。
61.2 MB のアーカイブを取得する必要があります。
この操作後に追加で 277 MB のディスク容量が消費されます。
・
・[中略]
・
kubeadm (1.20.4-00) を展開しています...
conntrack (1:1.4.6-1) を設定しています ...
kubectl (1.20.4-00) を設定しています ...
socat (1.7.3.4-1) を設定しています ...
cri-tools (1.13.0-01) を設定しています ...
kubernetes-cni (0.8.7-00) を設定しています ...
kubelet (1.20.4-00) を設定しています ...
Created symlink /etc/systemd/system/multi-user.target.wants/kubelet.service → /lib/systemd/system/kubelet.service.
kubeadm (1.20.4-00) を設定しています ...
man-db (2.9.3-2) のトリガを処理しています ...

先ほどインストールツールのバージョンを固定にします。

root@k8s-node-a:~# apt-mark hold kubelet kubeadm kubectl

kubelet は保留に設定されました。
kubeadm は保留に設定されました。
kubectl は保留に設定されました。

固定化されたことが確認できます。

root@k8s-node-a:~# apt-mark showhold

kubeadm
kubectl
kubelet

Kubernetessシングルマスターへワーカーノードを追加する

マスター側マシン で以下コマンドを実行し、マスターのみであることが確認できます。

root@k8s-master:~# kubectl get nodes

NAME         STATUS   ROLES                  AGE     VERSION
k8s-master   Ready    control-plane,master   2d19h   v1.20.4

今回の記事では解説していません がマスター構築時にkubeadm initを実行しており、この時に、マスターへ追加するコマンドが出力されていますのでこちらのコマンドを使用してマスターへ追加します。

コマンドは以下の通り。

root@k8s-node-a:~# kubeadm join 192.168.1.108:6443 --token b677lw.mke79ur70zeagzss \
    --discovery-token-ca-cert-hash sha256:c95d9f8921e34fbabc2dfbc4e0e0a0919e02f899b12d8bab0de9603b3feab883

kubeadm joinは ワーカーノードつまりマスターとは違うマシンで実行 します。

kubeadm join 192.168.1.108:6443 --token b677lw.mke79ur70zeagzss \
>     --discovery-token-ca-cert-hash sha256:c95d9f8921e34fbabc2dfbc4e0e0a0919e02f899b12d8bab0de9603b3feab883

トークン失効していたみたいでerrorでてしまいましたので再発行します。

[preflight] Running pre-flight checks
        [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
        [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 20.10.4. Latest validated version: 19.03
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
error execution phase preflight: couldn't validate the identity of the API Server: could not find a JWS signature in the cluster-info ConfigMap for token ID "b677lw"
To see the stack trace of this error execute with --v=5 or higher

マスター側 で確認してみると確かに失効していました。 kubeadm token listで何も出力がない場合、トークンがない状態となります。

root@k8s-master:~# kubeadm token list

トークンの再発行をします。

そのまま、 ワーカーノード側 で実行します。

マスター とは違うマシンです。

root@k8s-master:~# kubeadm token create --print-join-command

kubeadm join 192.168.1.108:6443 --token t5yafu.rn5tniug8kiu1pbf     --discovery-token-ca-cert-hash sha256:c95d9f8921e34fbabc2dfbc4e0e0a0919e02f899b12d8bab0de9603b3feab883

発行されました。

有効期限があるみたいですね。

root@k8s-master:~# kubeadm token list

TOKEN                     TTL         EXPIRES                     USAGES                   DESCRIPTION                                                EXTRA GROUPS
t5yafu.rn5tniug8kiu1pbf   23h         2021-03-03T01:32:47+09:00   authentication,signing   <none>                                                     system:bootstrappers:kubeadm:default-node-token

ワーカーノード側 で再度実行するとすんなり追加されました。

root@k8s-node-a:~# kubeadm join 192.168.1.108:6443 --token t5yafu.rn5tniug8kiu1pbf     --discovery-token-ca-cert-hash sha256:c95d9f8921e34fbabc2dfbc4e0e0a0919e02f899b12d8bab0de9603b3feab883

control-planeで確認しろ言われるのでマスター側で確認します。

[preflight] Running pre-flight checks
        [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
        [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 20.10.4. Latest validated version: 19.03
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

k8s-node-aが追加されていることがわかります。

マスター側 で実行しています。

NotReady になっている場合、すこしまてば Ready 状態へ変わります。

root@k8s-master:~# kubectl get nodes

NAME         STATUS   ROLES                  AGE     VERSION
k8s-master   Ready    control-plane,master   2d20h   v1.20.4
k8s-node-a   Ready    <none>                 5m54s   v1.20.4

以下は Kubernetes Dashboard で確認したスクリーンショットとなります。

Kubernetes Dashboard はここでは解説しません。

ポッド 詳細みるとエラーでているが、正常と異常を繰り返しておりよく分からない状態、でも取りあえず動いているので気にしません。

画像をホバー/タップすると拡大表示されます

まとめ

Kubernetesへのワーカーノード追加ができました。

コンテナーよくわからんので、Infrastructure as Codeと一緒に勉強していければ良いと思っています。

まず、各コマンドの理解から入って、実際に自分で作成したコンテナーをKubernetesで動かしたいので進展あればまたブログに書きます。

AIDEをインストールおよび改ざんチェックしてみた

Thu, 25 Feb 2021 20:57:00 GMT

目次

AIDEをインストールおよび改ざんチェックしてみた

AIDEをインストールおよび改ざんチェックしてみた

概要

AIDEというOSSソフトを使い、インストールおよび改ざんチェックを行ってみたいと思います。

今回は、チェック部分までやり、次回、チェックスクリプトを作成していきたいと思っています。

AIDEのインストール

[root@ ~]# yum install aide

[root@ ~]# yum list installed | grep aide

aide.x86_64                           0.15.1-13.el7                  @base

設定ファイルのバックアップ

[root@ aide]# cp -p /etc/aide.conf /etc/aide.conf.org

[root@ aide]# cp -p /etc/aide.conf /etc/aide.conf_20210226
初期データベース生成時に、/etc/aide.confで定義されているルールセットのみチェックするので設定ファイルを変更しますのでバックアップしておきます。

設定ファイルの編集

[root@ aide]# vi /etc/aide.conf 100行目当りにある、「/bin/ CONTENT_EX」から最下行までのルールセットが不要なので削除します。

削除後、「/boot/ CONTENT_EX」を「/var/www/vhosts/ CONTENT_EX」へ変更します。

※「/var/www/vhosts/」は監視したいディレクトリを指定します。
複数ディレクトリを監視したい場合は、「{監視対象ディレクトリ} {CONTENT_EX等の監視ルール ※本設定ファイル内に記載があります。}」のルールセットを複製します。
例：「/var/www/vhosts/ CONTENT_EX」

※ファイル単体を監視する場合は、「{監視対象ファイル}$ {CONTENT_EX等の監視ルール ※本設定ファイル内に記載があります。}」と定義します。
例：「/etc/my.cnf$ CONTENT_EX」

※特定ディレクトリや特定ファイルを削除したい場合は、監視パスの先頭に「!」を付けるようにします。
例：「!/var/www/vhosts/mattermost.whitesweets.pgw.jp/LOG」

ここままでで、設定ファイルには下記のように設定しました。
※一部分のみ抜粋しています。

# Next decide what directories/files you want in the database. Aide
# uses a first match system. Put file specific instructions before generic
# matches. e.g. Put file matches before directories.

/var/www/vhosts/ CONTENT_EX
/etc/my.cnf$ CONTENT_EX

# Ignore apache log files
!/var/www/vhosts/mattermost.whitesweets.pgw.jp/LOG
!/var/www/vhosts/.jp/LOG
!/var/www/vhosts/whitesweets.pgw.jp/LOG

データベース生成

[root@ ~]# aide --init

AIDE, version 0.15.1

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

初期データベースを生成を行います。
※生成時間は設定した監視対象領域のコンテンツ数によって異なります。
コンテンツ量が多い場合、上記データベースファイルの肥大化に繋がるので、ディスク空き領域を確認し、生成中等サイズをモニタリングするようにします。

設定通り記録されているか確認

[root@ aide]# grep -v -E "\/etc\/my.cnf|\/var\/www\/vhosts\/" aide.db.new

@@begin_db
# This file was generated by Aide, version 0.15.1
# Time of generation was 2021-02-26 03:45:56
@@db_spec name lname attr perm inode uid gid lcount sha256 acl xattrs selinux

先ほど、生成した初期データベースが設定したルールセットのみであることが確認できます。

[root@ aide]# grep -E "\/LOG\/" aide.db.new | wc -l

0

除外設定をしたLOGディレクトリが除外されていることが確認できます。

[root@ aide]# head -n 6 aide.db.new;echo -e "\n---\n";tail -n 3 aide.db.new

@@begin_db
# This file was generated by Aide, version 0.15.1
# Time of generation was 2021-02-26 04:12:30
@@db_spec name lname attr perm inode uid gid lcount sha256 acl xattrs selinux
/etc/my.cnf 0 44025514013 100644 5210466 0 0 1 99BtTnIuXei4igc5MG31haE0EWHPej3bdSE1+QFBf4w= POSIX,dXNlcjo6cnctCmdyb3VwOjpyLS0Kb3RoZXI6OnItLQo=,0 0 0
/var/www/vhosts/whitesweets.pgw.jp 0 42951772189 40755 37782900 0 0 4 0 POSIX,dXNlcjo6cnd4Cmdyb3VwOjpyLXgKb3RoZXI6OnIteAo=,0 0 0

---

/var/www/vhosts/whitesweets.pgw.jp/WWW/wpWebCms3094X/wp-includes/widgets/class-wp-widget-media-video.php 0 44025514013 100755 50368753 48 48 1 4QeN5oYcd+7psGcjRVXhx1hNkrOUZVX1Iza9zUCZcAY= POSIX,dXNlcjo6cnd4Cmdyb3VwOjpyLXgKb3RoZXI6OnIteAo=,0 0 0
/var/www/vhosts/whitesweets.pgw.jp/WWW/wpWebCms3094X/wp-includes/widgets/class-wp-widget-media.php 0 44025514013 100755 50368754 48 48 1 qhDVwus4dDGxp4dUKP4eyfNCEaaI3dJ4JK0R14zrG7I= POSIX,dXNlcjo6cnd4Cmdyb3VwOjpyLXgKb3RoZXI6OnIteAo=,0 0 0
/var/www/vhosts/whitesweets.pgw.jp/WWW/wpWebCms3094X/wp-includes/widgets/class-wp-widget-custom-html.php 0 44025514013 100755 50368755 48 48 1 eLD9P+JtCgHyZXuBo/ORBzhi1CLE4AcvFO9C6Mw6St0= POSIX,dXNlcjo6cnd4Cmdyb3VwOjpyLXgKb3RoZXI6OnIteAo=,0 0 0

データベースの中身（おまけ）

[root@ ~]# cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
生成したデータベースを使用できるように、「.new.」部分を削除した形でコピーします。

動作確認

[root@ ~]# aide --check

AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2021-02-26 04:41:32

Summary:
  Total number of files:        24744
  Added files:                  2
  Removed files:                0
  Changed files:                0


---------------------------------------------------
Added files:
---------------------------------------------------

added: /var/www/vhosts/.jp/WWW/wp-content/uploads/wpcf7_captcha/1692799095.png
added: /var/www/vhosts/.jp/WWW/wp-content/uploads/wpcf7_captcha/1692799095.bash

チェックを実施した結果、ファイルが追加されていることが分かりますね。

[root@ ~]# aide --update

AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2021-02-26 04:46:45

Summary:
  Total number of files:        24744
  Added files:                  2
  Removed files:                0
  Changed files:                0


---------------------------------------------------
Added files:
---------------------------------------------------

added: /var/www/vhosts/.jp/WWW/wp-content/uploads/wpcf7_captcha/1692799095.png
added: /var/www/vhosts/.jp/WWW/wp-content/uploads/wpcf7_captcha/1692799095.bash

「aide --check」ではデータベースが更新されないので「aide --update」を実行し「/var/lib/aide/aide.db.new.gz」を「/var/lib/aide/aide.db.gz」へコピーするようにします。

[root@ ~]# cp -p  /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

cp: `/var/lib/aide/aide.db.gz' を上書きしますか? y

[root@ ~]# aide --update

AIDE, version 0.15.1

### All files match AIDE database. Looks okay!

### New AIDE database written to /var/lib/aide/aide.db.new.gz

再度、実行すると全部マッチし差違がなかったことを確認できます。

まとめ

設定ファイルの編集に少し迷いましたが、なれれば簡単ですね。

次回は、チェックスクリプトを作成していたいと思っています。

参考にしたサイト：https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/sec-using-aide

AWSにおけるInfrastructure as Codeの考え方

Wed, 27 Jan 2021 04:28:00 GMT

目次

IaCのイメージ
参考文献

IaCのイメージ

IaC（Infrastructure as Code）のイメージとして下記に示します。

サービス名	特徴	影響範囲
AWS CloudFormation	AWSリソース（VPC・EC2・RDS・Lamda等）のインフラ基盤をコード形式で管理するサービス	Global/Mutable
Terraform	HashiCorp社より提供されているオープンソースのインフラ基盤を宣言型コードで管理できるツールでaws・azure・gcp等の各種クラウドに対応している。	Global/Mutable
AWS OpsWorks	サーバの内部設定（ミドルウェア等のデプロイ自動化）管理をコード形式で管理するサービス。 CloudFormationよりも上のレイヤーになる。	Local/Mutable
Ansible		Local/Mutable
Kubernetes		Local/Immutable
Docker		Local/Immutable

※その他に「AWS Systems Manager（OSのパッチ適用やWindows、LinuxといたOS設定の自動化）」やAWS Config（フルマネージド型の構成履歴や構成変更通知機能を備えた監査サービス）が存在しますがここでは扱わないものとします。

aws iac 冪等性純粋性再現性

AWSにおけるサーバレスの定義は「お客様からみてサーバの存在を意識しない環境」のことをいう。

参考文献

RPA勉強会 SPECIAL EDITION ～AI-OCRを学ぼう～議事録

Mon, 07 Dec 2020 12:15:00 GMT

目次

取り巻くトレンド
AI-OCRメーカーセミナー1：クラウドじゃなくてもAI-OCRは使えます
AI-OCRメーカーセミナー2：請求書OCRをあきらめない！電子帳簿保存もまとめて解決
LT1準定型x手書き帳票をRPAに組み込んで処理できる件
T2 LINEのレシートOCRとRPA
LT3 Axrobo（アクロボ）×ジジラで元気にAI-OCR！

AI-OCR

取り巻くトレンド

多くの企業でAI-OCRの導入が進んでいる。
↑
OCR業界をこれから牽引していく技術。

チャットボットやAI対話等の定型化しやすいものはRPA化をしやすく導入が進んでいる。
OCR市場は成長市場で、コロナ下においても影響を受けていない。
↑
寧ろ、活発になってきている。

文字検出・認識+分類 = OCR技術
オンプレミスの事例が増えてきている。
オンプレミス自体、秘匿性が高い物なので、オンライン上に事例が上がりにくい。

eKYCの技術でOCRが使われている。

AI-OCRメーカーセミナー1：クラウドじゃなくてもAI-OCRは使えます

アライズイノベーション様

オンプレミスのAI-OCR：AIRead
↑
帳票データの処理等に使用される。

オンプレミスのAI-OCRデメリット

文字学習を自分たちで作成しないとならないため学習コストが高い。
サーバのスペックよって実行時間が異なってくる。

文字学習の際に個別に学習モデルを作成しようとすると、すごく時間が掛かり学習コスト
に関しても高くなってくる。

英語や英数字等は誤読しやすい傾向にある。

WinActor等の他RPAシステム等の連携ができる。

AI-OCRメーカーセミナー2：請求書OCRをあきらめない！電子帳簿保存もまとめて解決

オートメーションラボ様

紹介製品：sweeep
↑
請求書特化型OCR クラウド型で月額3万円～利用可能。

OCRとは
業務効率化の手段
「見る」を自動化する。

atena等への連携も可能になっている。
slackへの通知も可能。

263枚中7枚修正必要で読取り率97%になっており高精度。

LT1準定型x手書き帳票をRPAに組み込んで処理できる件

オートメーションエニウェア様 ↑
RPAのベンダー

botのことをデジタルワーカーと呼んでいる。
OCRの役割も担っている。

Automation Anywhere

IQ Bot×Tegaki

手書きをふくむ準定型業務を自動化できる。

T2 LINEのレシートOCRとRPA

エンザントライズ様

LINEのOCRとRPA

CLOVA OCR
↓
Excelへのエクスポートが可能。→RPAの連携ができる。（インドのRPA）

正確な読取り
APIなのでアプリ組込も可能

LT3 Axrobo（アクロボ）×ジジラで元気にAI-OCR！

アクロスロード様

AI-OCR：Jijilla
RPA：アシロボ
これらを連携してアクロボに流し込む形。

AI-OCRジジラ

手書きも活字も自動化できる。
ERPやSFA（営業支援システム）はの一気通貫で自動化できる。

アシロボの方で読み込んでジジラの方で処理する流れになる。

AWS SAA ポエム 2020年11月28日(土)

Sat, 28 Nov 2020 09:25:00 GMT

目次

問題・回答

問題・回答

Q1:S3を使用した共有サイトに、会員以外の人がファイルのダウンロードする行為を防ぐにはどのようにすれば良いか。

A:有効期限付きの著名付きURLを使用し、S3の一般公開用のアクセス権を削除する。
Q2:以下の要件を満たす事が出来るサービスは何か。
- 業務データを頻繁に登録・更新・削除することに耐えられるデータベース
- 複数のテーブルを結合してデータ取得することができる
- データベースのストレージを自動スケーリングすることができる
A:Amazon Aurora

Auroraはマネージド型のRDBをサポートしているデータベースの一つで 頻繁にデータの更新削除がおこなわれるデータベースに向いて おり SQLを発行して複数のテーブルを結合し、結合されたテーブルから対象のデータを取得することが出来る。

　　
また、Auroraは、フルマネージド型のデータベースサービスなので データ量に応じて自動スケーリング する機能を備えている。

**DynamoDBは一般的なRDBのようにSQLを利用したデータの取り出しには対応していない。**  

https://stackoverrun.com/ja/q/10132760  
> **DynamoDBはリレーショナルデータベースとして設計されておらず、結合操作をサポートしていません。**

zabbix ユーザパラメータ監視設定メモ

Mon, 09 Nov 2020 04:30:00 GMT

目次

リンク

リンク

Zabbix Official Repository
↳zabbix-releaseを使用する。
ホスト監視追加手順, 関連度合い強
 監視追加仕様アイテムの作成
 ZabbixにQmailのメールキューの監視を設定
 監視設定確認
 カスタムグラフ設定
 ユーザパラメータ設定
 リモートコマンド
↳リモートコマンドにより、監視しているホストで、ある条件を満たした時、あらかじめ設定したコマンドを自動的に実行されます。
↳アプリケーション（Webサーバ、ミドルウェア、CRM）が応答しない場合に自動的に再起動する。等

rmコマンドを使用した時の配列動作の挙動

Thu, 08 Oct 2020 11:55:00 GMT

目次

目的
ゴール
前提条件
ソースコード
挙動

目的

シェルスクリプト（bash）で、rmコマンドで配列の中身（ファイル）を削除後、echoコマンド等で削除した配列の中身を出力した場合の動作について理解する。

ゴール

どのような場合に、配列の中身（ファイル）を削除した時の動作が理解できるようになる。

前提条件

配列についての知識を有していること。
シェルスクリプトの独特な表現を理解している方。

ソースコード

findDelLogList=
mapfile -t findDelLogList < <(find "$scriptDir" -name "$findDelLogName*")

# 'declare -a findDelLogList='([0]="/var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_20_13_25")''
for((i = 0; i < ${#findDelLogList[@]}; i++)); do

    # 'declare -a findDelLogList='([0]="/var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_20_13_25")''
    tmp="${findDelLogList[i]}"

    # 'declare -a findDelLogList='([0]="/var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_20_13_25")''
    if rm -f "${findDelLogList[i]}"; then

        # '/var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_20_13_25'（変数tmp)

        # '/var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log'（変数cronStdOutLogFilePath)
        echo "古いログファイル：「 $tmp 」の削除を実施しました。" >> "$cronStdOutLogFilePath" 2>&1
        isFindDelLogList="0"

    else
        echo "古いログファイル：「 $tmp 」の削除に失敗しました。" >> "$cronStdOutLogFilePath" 2>&1
        isFindDelLogList="1"

    fi

    # '0'
    if [ "$isFindDelLogList" -eq "0" ]; then
        echo "古いログファイル：$(${findDelLogList[i]})の削除を実施しました。" >> "$cronStdOutLogFilePath" 2>&1

    elif [ "$isFindDelLogList" -eq "-1" ]; then
        echo "古いログファイル：$(${findDelLogList[i]})の削除に失敗しました。" >> "$cronStdOutLogFilePath" 2>&1

    fi

done

挙動

bash-4.2$ cat /var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log

上記コマンド出力結果 ↓↓↓↓

古いログファイル：「 /var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_17_27_25 」の削除を実施しました。
古いログファイル：の削除を実施しました。

削除前の削除ファイル配列変数を事前に変数tmpへ待避していない場合、後者のisFindDelLogList変数で判定している条件分岐内でfindDelLogList変数の中身が出力されなくなっています。

下記、デバッグコンソールの出力結果からもわかるように、待避していない場合、rmコマンドですでにファイルを削除してしまっているので そのようなファイルやディレクトリはありません となっているため、出力されず空白のままになってしまっています。

シェルスクリプト（bash）で変数の中身からファイルを削除しその後、削除結果を変数から参照する場合は、事前に削除前の変数中身を待避させ、待避させた変数から参照するようにしましょう。

デバッグコンソール出力結果 ↓↓↓↓

/var/www/vhost/dev.test.com/private/shell/swap_os_reboot.sh: 行 60: /var/www/vhost/dev.test.com/.vscode-server/extensions/rogalmic.bash-debug-0.3.9/bashdb_dir/swap_os_reboot.log_20201008_17_27_25: そのようなファイルやディレクトリはありません

AWS SAA ポエム 2020年10月05日(月)

Sun, 04 Oct 2020 22:40:00 GMT

目次

AWS S3パフォーマンス最適化

AWS S3パフォーマンス最適化

画像をホバー/タップすると拡大表示されます

https://qiita.com/iron-breaker/items/f35c1d54887c434a321a

AWS SAA 試験準備ワークショップ３

Tue, 29 Sep 2020 07:30:00 GMT

目次

AWSリソースへのセキュアなアクセスの設計
1. Amazon VPC（Amazon Virtual Private Cloud）
セキュアなアプリケーション階層の設計
1. 責任共有モデル
2. IAM（AWS Identity and Access Management）
適切なデータセキュリティオプションの選択
1. 転送中のデータ
2. 保管中のデータ
  1. データの暗号化
参考文献

AWSリソースへのセキュアなアクセスの設計

Amazon VPC（Amazon Virtual Private Cloud）

セキュアな外からはアクセスできなよ。といった空間を作ることができるサービスとなっている。

完全にアクセスできないのは利便性が低いので、 色々なコンポーネント を追加することにより きめ細やかなネットワーク を構築することができる。

EC2やRDSとはすべてこの中で動くようになっている。

サブネット

パブリックサブネット
- Elastic Network Interfaceに関連付け
- ルール許可のみをサポート
- ステートフル

NICなので当たっているEC2インスタンスサーバ単位でパケットの制御をすることができる。

パブリックインターネットへの直接アクセスをサポートし、インターネットゲートウェイへのルーティングテーブルエントリで指定する。

プライベートサブネット
- サブネットに関連付け
- ルールの許可と拒否をサポート
- ステートレス

サブネット単位なので、サブネットに入っているインスタンス等はすべて影響を受ける。
サブネット単位で一括にどこどこのポートを落としてしまうなんていう制御をおこなうことができる。

インターネットゲートウェイへのルーティングテーブルエントリがなく、NAT経由でパブリックインターネットに間接的にアクセスする。

用語のようなものだと思って押さえておくとよい、試験でもこのような感じで出てくる。

パブリックサブネットやプライベートサブネットで当たっている対象に違いがあることを認識しておく。

セキュリティグループ

アプリケーション層のセキュリティグループ、データ層のセキュリティグループといった具合で層によって、アクセスの振る舞いを変更したいときなどに用いるものである。
トラフィックの制御をおこなうことができる。

Amazon VPC接続

Amazon VPCでトラフィックをやり取りするサービスとして、 AWS Direct Connect や VPCピアリング接続 といった方法なども存在するので試験の前に一度確認する必要がある。

セキュアなアプリケーション階層の設計

責任共有モデル

AWSは クラウドの セキュリティに責任を持ち、お客様は クラウド内の セキュリティに責任をもつ。

AWSの基盤サービスやAWSグローバルインフラストラクチャといったお客様側で触れない部分は AWS側 が責任を持つ形となっている。

基盤側より上のレイヤー、EC2インスタンスの中には、AWS側はアクセスできなので お客様側 で責任をもって管理する必要がある。

マネージドサービス になってくればくるほど、 AWS側で 責任を持つ範囲が広くなる。

画像をホバー/タップすると拡大表示されます

AWS責任共有モデル図：https://aws.amazon.com/jp/compliance/shared-responsibility-model/

IAM（AWS Identity and Access Management）

誰がEC2インスタンスを 消してもいい 、誰が S3にバケットへオブジェクトを投入してもいい といったアクセス管理を細かく設定することができるサービスとなっている。

誰彼構わず管理者権限を付与するのではなく必要最小権限を付与するという原則がある。

IAMは凄く複雑になっているので試験を受ける前に一度、確認しておく必要がある。

適切なデータセキュリティオプションの選択

転送中のデータ

AWSに対して、データの転送が発生する場合で、S3とDynamoDB間の通信等は SSL/TLS 接続で暗号化されているので途中の経路で盗聴されることはない。

VPC上への資産に対して安全にアクセスをしたいという場合には、 VPNやAmazon DirectConnect 等のサービスを使用して接続することもできるので覚えておく必要がある。

AWS APIへのデータ送信 は、 AWS APIコールでHTTPSを使用し、すべてのAPIコールでSigv4の署名がなされる。

保管中のデータ

Amazon S3を例に、保存されたデータはデフォルトでプライベートなので、公開はされていないものとなるがユーザ側で細かい設定をして外部に公開することも可能である。
この場合、アクセス管理等についてユーザ側で責任をもって管理をしていく必要がある。

データの暗号化

S3に保管されているデータ自体の暗号化について、 サーバサイド暗号化 および クライアントサイド暗号化 というものが存在する。

クライアントサイド暗号化
- AWS KMSで管理するカスタマーマスターキー（CSE-KMS）
- クライアント側のマスターキー（CSE-C）

等が存在する。

自分のPCなどでOpenSSL等のコマンドを用いデータを暗号化しその 暗号化した文字列等 をS3へ保管するというもので 作成したキー 等についてはユーザ側で責任を持って管理をする必要がある。

サーバサイド暗号化
- Amazon S3で管理するキー（SSE-S3）
- AWS KMSで管理するキー（SSE-KMS）
- 顧客が提供するキー（SSE-C）

等が存在する。

参考文献

TAC-3：AWS 認定 - 試験準備ワークショップ「ソリューションアーキテクト ? アソシエイト」セッション 2

AWS SAA 試験準備ワークショップ②

Mon, 28 Sep 2020 19:00:00 GMT

目次

スケーラブルなコンピューティングリソースの識別
パフォーマンスとスケーラブルなストレージソリューションの選択
1. EBS（Amazon Elastic Block Store）
2. Amazon S3（Amazon Simple Storage Service）
  1. S3の料金体系
パフォーマンスが高いネットワーキングソリューションの選択
1. Amazon CloudFront
パフォーマンスの高いデータベースソリューションの選択
参考文献

スケーラブルなコンピューティングリソースの識別

垂直スケーリング

必要な時にEC2等のコンピューティングリソース（CPUやメモリ等）の上げ下げが可能になっている。

1台のサーバを大きくする、小さくすることを垂直スケーリングと呼ぶ。

利点

サーバの能力自体がそのまま垂直に上がる・下がるといったことをする為、中のアーキテクチャがクラウド特有 （水平スケーリング） に対応していない形で書かれていても、純然たるサーバの能力を上げる・下げるだけなので対応することが可能になる。

欠点

Java等のアプリケーションを実行している場合で、大量のヒープメモリを使用している場合、ガベージコレクションの時間が長くなってしまうなどが挙げられる。

垂直スケーリングをおこなう際には、EC2インスタンスの再起動が必要になってくる。

水平スケーリング

1個のサーバの処理能力を上げる・下げるのではなくサーバの台数を水平方向にどんどんどんどん増やしていこう、足りなければサーバを増やしていき、過剰であればへらしていくことを水平スケーリングという。

Amazon EC2 Auto Scaling

サーバをデブロイする削除するサービス。
CPUが何十%を超えたら自動的にスケーリングする等。

EC2 Auto Scalingグループの管理とスケールのみ必要な場合に使用。
EC2フリートの正常性維持のみに関係する。

AWSでは、特定アプリケーションを実行するために用意されたインスタンス群のことを フリート と呼び、状態を監視することで可用性の維持が期待できる。

AWS Auto Scaling

こちらは、AWS EC2に限ったスケーリングではなく、EC2のオートスケーリンググループ、ECS、、Aurora、DinamoDB等のサービスと連携して必要なキャパシティの変更が可能。

複数のサービスにまたがってスケーリングを管理したい場合に使用する。

Amazon CloudWatch

いつオートスケーリングをするか否かを管理することができ、AWSリソースのCPU使用率やネットワーク等をモニタリングすることができる。

モニタリング方式

デフォルトのモニタリング

AWS標準のモニタリングを指す。
AWSが標準でデータを収集してくれるものとなる。

カスタムメトリクスによるモニタリング

ユーザがCloudWatchの大して何時何分何秒にこのデータのメトリクスがいくつかのデータを渡すことによりユーザが定義したカスタムメトリクスを保存することで、CloudWatch上において見ることができる方式を指す。

ELB（Elastic load Blancing）

ELB配下に対して複数のサーバを配置することによりアクセスを分散させることができるので負荷対策に繋がり、これらのサービスを使うことで自動的にスケーリングすることが可能。

パフォーマンスとスケーラブルなストレージソリューションの選択

EBS（Amazon Elastic Block Store）

汎用SSD（gp2）
プロビジョンドIOPS SSD（io1）
スループット最適化HDD（st1）
ゴールドHDD（sc1）

ゴールドHDD > スループット最適化HDD > 汎用SSD > プロビジョンドIOPS SSDの順にI/O性能が高くなっている。
どういった場合にどういったものを選択しておけば良いか押さえておけば良い。

Amazon S3（Amazon Simple Storage Service）

ただデータを保存するといった用途だけではなく、htmlやjavascript、CSS等のファイルを置いて、WEBサーバとしての機能を持たすことが可能。
こうした機能をAWS側で、マネージドで管理してくれる。

S3のキャパシティ等を気にすることなく勝手にS3へアクセスできるよう処理してくれるので非常に高いスケーラビリティを享受することができる。

s3に保存される物は物（オブジェクトとして管理）され、KEYとして対応付けられている。

ユーザ側はKEYに対してアクセスすることで閲覧権限が付加されている場合、参照することができる。

S3の料金体系

中に保管しているデータ量に対して課金量が多くなっている、リクエスト回数やリージョン外への転送なども課金対象になっている。

S3へのデータ転送やS3から同一リージョンの他のサービスへのテータ転送は無料となっている。

S3にはストレージクラスというものが存在 しており、なにもしなかった場合は、S3標準といったストレージクラスに格納される。

中に置いている物を適切なストレージクラスに格納することによって、料金を抑えることができる。

ライフサイクルポリシー 、マネージメントコンソール上で、ボタンポチポチで設定することが可能で、中に入れたデータを時間的なポイントでストレージクラスを移動させることが実現できる。

S3標準（通常アクセス）⇒S3低頻度アクセス（アクセス少）⇒S3 Glacier（まったく見ないアーカイブ用）⇒ゴミ箱 といった様なライフサイクルポリシーを設定することが可能になっている。

何十日経過したらストレージクラスを移動するといった具合。

パフォーマンスが高いネットワーキングソリューションの選択

Amazon CloudFront

コンテンツデリバリーネットワーク（キャッシュ）のサービスになってくる。

例：エンドユーザが直接S3のコンテンツを参照しデータのやり取りをしている場合、間にCloudFrontを挟むことによって地理的な制約を受けずにスムーズにデータのやり取りをおこなうことができる。

CloudFront は世界中にサーバを持っておりデータを S3 からあらかじめキャッシュしておくことによりデータを素早く表示できる特性を持ち、データが存在しない場合には、都度 S3 を参照する。

エンドユーザからCloudFrontへのアクセスは自動的にもっとも近い CloudFrontエッジロケーション にアクセスし、 S3 へのアクセスは CloudFront のみからのアクセスを担保できるのでエンドユーザへは素早くデータを返すことができる仕組みとなっている。

適切な部分にデータを適切にキャッシュをするという部分も凄く重要な観点になってくる。

パフォーマンスの高いデータベースソリューションの選択

Amazon Database Service
- Amazon RDS
- Amazon DynamoDB
- Amazon Redshift

試験的にはこれらのデータベースサービスがよく利用される。

Amazon RDS

一般的な RDBMS として比較されるのが RDS で 複雑なトランザクションや複雑なクエリ 、 高耐久性 を求める場合に使用する。

Amazon RDSリードレプリカ

RDS 負荷軽減の施策として取られ、DBの負荷が大きくDB側で耐えきれない場合に、DBのコピー リードレプリカ 読込専用のインスタンスを作っておき 読み込み専用のインスタンスに対して読み込みアクセスを振り分け ることによってMatserの方に書き込みを制御している方へ、負荷がいかないようにするよという手法を リードレプリカ という。

書き込みのクエリを処理することはできないが、読み込みのクエリだけには耐えられるよということを担保するためのもの。

超高速な読み書き速度 や 簡単なGET/PUTリクエスト の場合は使用しない。
これらは試験によくでてくるポイントとなる。

DynamoDB

プロビジョンドスループット となり事前に読み込み書き込みそれぞれにおいて、どれくらいに量を使うよというリソースを事前に割り当てる方式となっている。

事前に割り当てた量を キャパシティユニット と言い、これを超えてしまうとエラーを返す。
なので適切な値まで上げてあげるよといったことが必要になってくる。

Amazon ElasticCache

Memcached や Redis と言ったようにな実際のcacheを管理する為のサービスとなっている。

DBに対して直接アクセスするのではなく、間に cache層 を置き（ElasticCache）等の中にDBのデータをキャッシュさせておきこれらのキャッシュデータにアクセスすることでDBに対するアクセスを下げることが期待できる。

Memcached
- マルチスレッド
- メンテナンスが簡単
- 簡単に自動検出機能で水平スケーリングできる。
Redis
- 複数のデータ構造をサポート
- アトミックオペレーション
- Pub/Subメーセージング
- リードレプリカ/フェイルオーバー
- クラスターモード/シャードされたクラスター
等の特徴がある。

試験的にはMemcachedやRedisは暗記するものではなく、どういったものかを把握していればよい。

参考文献

TAC-3：AWS 認定 - 試験準備ワークショップ「ソリューションアーキテクト ? アソシエイト」セッション 2

AWS SAA 試験準備ワークショップ①

Wed, 16 Sep 2020 09:00:00 GMT

目次

多層アーキテクチャソリューションの設計およびAWSのサービスを使用したデカップリングメカニズムの設計
1. ELBについて
可用性の高いアーキテクチャやフォールトトレラントなアーキテクチャの設計
適切な回復力あるストレージの選択
参考文献

`多層アーキテクチャソリューションの設計`および`AWSのサービスを使用したデカップリングメカニズムの設計`

疎結合とは、1つのサービスに問題が起きた場合に、全体に対して問題が波及するのではなく、問題を局所化しサービスを動かすことができることを指す。

WEBサーバがEメールサービスと直接通信している場合で、Eメールサーバがダウンした時、引きずられてWEBサーバに関わる処理ができなくなり、問題が大きくなるが間にSQS（メッセージキューイングサービス）を入れることでWEBサーバ自体は問題なく処理できることを担保できる。

ELBについて

Classic Load Balancer

旧式のロードバランサーとなっている。

Application Load Balancer

OSI参照モデルのレイヤー7で実行されリクエストの内容に基づいてトラフィックをルーティングしてくれる。
固定レスポンスとなっている。

Network Load Balancer

OSI参照モデルのレイヤー4で実行され、TCPパケットのロードバランシングで、高パフォーマンスのアプリケーション向けとなっている。

可用性の高いアーキテクチャやフォールトトレラントなアーキテクチャの設計

あらゆるものは必ず壊れる。それが終わることはない
壊れることを想定し、システムを構築しておく必要があることを意味している。

AWS Well Architected Frameworkを該当程度に理解しておく必要がある。

運用上の優秀性
セキュリティ
信頼性
パフォーマンス効率
コスト最適化

こらら4つの柱から成り立っている。

回復性の高いアーキテクチャを考える上で・・・

AWS CloudFormation
AWS Lambda
等のサービスが該当する。

適切な回復力あるストレージの選択

Amazon EC2インスタンスストア

エフェメラルボリュームは、インスタンスを停止すると揮発し、データが消えてしまうが、高速・広帯域なのでバッチ処理の一時ディスクやキャッシュとしての利用が好まれる。

Amazon EBS（Amazon Elastic Block Store）

ブロックレベルのストレージを提供し、インスタンスから独立した永続性を持つ。

EFS（Amazon Elastic File System）

EC2上で利用できる共有ファイルのディスクとなっている。
EBSを使った共有ファイルディスク作成は出来ないので注意が必要。

Amazon S3（Amazon Simple Storage Service）

インターネットからアクセス可能なオブジェクトストレージとなる。
容量は事実上無制限。

Amzaon S3アクセスコントロール

どのオブジェクトに誰がアクセスできるのか細かく定義することができる。

Amazon S3 Glacier

通常は取り出さないが、なにかあった時の為に、消すことはできないが使うことも、ほとんどない場合において安価に保存ができるストレージサービスとなっている。

参考文献

TAC-2：AWS 認定 - 試験準備ワークショップ「ソリューションアーキテクト – アソシエイト」セッション 1

最近お腹の調子が悪い

Sat, 12 Sep 2020 20:00:00 GMT

目次

はじめに

はじめに

最近、胸焼けが酷くなってきた筆者です。
体重も15kg位増え、標準体重気味になってきました。

お腹もたるんたるんで困っちゃいます。
ランニングでもしようかなぁp(´⌒｀q

シンタックスハイライトテスト(´∀`)ﾎﾟｯ

Sat, 12 Sep 2020 04:00:00 GMT

目次

はじめに
Mermaid

はじめに

gatsby-remark-vscode および robb0wen/synthwave-vscodeを使ったハイライトコーディングテストです。

テーマは「Dark (Visual Studio)」を使用しています。

公式？テーマとして提供されているのが感無量ですね。
リンク先

“C”

#include<stdio.h>

void main( void ) {
    printf( "%s\n", "ようこそ ! C 言語の世界へ(*･ω･*)" );

}

“C++”

#include<iostream>

using namespace std;

int main( void ) {
    cout << "ようこそ C++ の世界へ(*´∀`*)ﾎﾟｯ" << endl;

	return 0;

}

“C#”

using System.Collections.Generic;

class DictionaryExample {

	List<Items> myItems;
	Items myItems2;
	public List<Items> ItemsList { get { return myItems; } set { myItems = value; } }
	public Items ItemsList2 { get { return myItems2; } set { myItems2 = value; } }

	const int N = 6;

	public DictionaryExample( ) {
		myItems = new List<Items>( );

		for( int i = 0; i < N; i++ ) {
			myItems.Add( new Items( ) );
			myItems[ i ].dictionaryList = new Dictionary<int, string>( );

		}

		myItems2 = new Items( );
		myItems2.dictionaryList = new Dictionary<int, string>( );


	}

	public class Items {
		public Dictionary<int, string> dictionaryList;


	}


}

Mermaid

フローチャート

graph TD
    A[開始] --> B{条件チェック}
    B -->|Yes| C[処理A]
    B -->|No| D[処理B]
    C --> E[終了]
    D --> E

シーケンス図

sequenceDiagram
    participant Client
    participant Server
    participant DB

    Client->>Server: GET /api/data
    Server->>DB: SELECT FROM records
    DB-->>Server: rows
    Server-->>Client: 200 OK

クラス図

classDiagram
    class Animal {
        +String name
        +int age
        +speak() void
    }
    class Dog {
        +fetch() void
    }
    class Cat {
        +purr() void
    }
    Animal <|-- Dog
    Animal <|-- Cat

“Terraform / HCL”

# resource type と logical name が別色になることを確認
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "WebServer"
  }
}

data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-*"]
  }
}

variable "instance_type" {
  description = "EC2 instance type"
  type        = string
  default     = "t3.micro"
}

provider "aws" {
  region = "ap-northeast-1"
}

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  name   = "my-vpc"
  cidr   = "10.0.0.0/16"
}

output "instance_ip" {
  value = aws_instance.web_server.public_ip
}