Architect's Log

Today I Learned - 2026-06-09

2026-06-09T16:35:26+09:00

今日学んだことを雑多に書く。

route53:GetHostedZoneのPermissionエラーでCloudFormationスタックのデプロイに失敗する

AccessDenied. User doesn't have permission to call route53:GetHostedZone. Rollback requested by user.

テンプレートのパラメータで Route53 ホストゾーンを型指定している yaml HostedZoneId: Type: AWS::Route53::HostedZone::Id Default: Z0123xxxxxxxxxxxxxxxx Description: Route53 hosted zone ID.
マネージメントコンソールでデプロイしている
CloudFormation のサービスロールでroute53:GetHostedZoneを許可している

デフォルト値のZ0123xxxxxxxxxxxxxxxxが、その環境に存在しないホストゾーン ID だったことが原因。おそらくデプロイの際に内部的にroute53:GetHostedZoneを実行していると思われる。

解決策はDefault属性の削除か、またはType属性をStringに変更する。

なお、サービスロールを指定しない場合はサインインユーザーの認証情報がスタックデプロイに使用される。

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-iam-servicerole.html

CloudFormation はデフォルトで、スタックオペレーションのためのユーザー認証情報から CloudFormation が生成する一時的なセッションを使用します。サービスロールを指定すると、CloudFormation はロールの認証情報を使用します。

Lambda関数にCloudFormationでタグをつける

Resources:
  StartStepFunctionLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: StartStepFunctionLambda
      # ... その他のプロパティ
      Tags:
        - Key: Environment
          Value: production
        - Key: Project
          Value: my-project

Today I Learned - 2026-06-08

2026-06-08T20:55:38+09:00

今日学んだことを雑多に書く。

CloudFormationパラメータのTips

デフォルト値。

Parameters:
  StateMachineArn:
    Type: String
    Description: ARN of the Step Functions state machine to start.
    Default: arn:aws:states:ap-northeast-1:123456789:stateMachine:AddRdsReader

許可リスト。

Parameters:
  DBInstanceClass:
    Type: String
    AllowedValues: 
      - db.r8g.xlarge
      - db.r8g.2xlarge
      - db.r8g.4xlarge
      - db.r8g.8xlarge
      - db.r8g.12xlarge
      - db.r8g.16xlarge
      - db.r8g.24xlarge
      - db.r8g.48xlarge

入力パターン。正規表現で指定。

Parameters:
  DBInstanceClass:
    Type: String
    AllowedPattern: ^db\.r8g\.(\d+)?xlarge$

AWS リソース。

Parameters:
  AvailabilityZone:
    Type: AWS::EC2::AvailabilityZone::Name

AWS リソースのリスト。複数選択可。

Parameters:
  AvailabilityZone:
    Type: List<AWS::EC2::AvailabilityZone::Name>

最小値。最大値。

Parameters:
  PromotionTier:
    Type: Number
    MinValue: 0
    MaxValue: 15

参考。

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cloudformation-supplied-parameter-types.html

ncコマンドでの疎通確認

Ubuntsu on WSL で確認。

待ち受けておく。

nc -lk 8443

別ターミナルから接続。

echo "OK" | nc -q 0 localhost 8443

出力される。

nc -lk 8443
# OK

-l: Listen モード

-k: Keep inbound sockets open for multiple connects. 切断後も同じポートで次の接続を待ち続ける。

-q 0: quit after EOF on stdin and delay of secs. STDIN で EOF 後すぐに閉じる。

ncコマンドで200を返す

while true; do
  echo -e "HTTP/1.1 200 OK\r\nContent-Length: 3\r\n\r\nOK\n" | nc -l 8443
done

別ターミナルから接続。

echo "hello" | nc -q 0 localhost 8443
# HTTP/1.1 200 OK
# Content-Length: 3
# 
# OK
#

-q 0によるクローズを発動させるには、echo をパイプでつなぐ。パイプの書き込み側が閉じられると、読み込み側（nc の stdin）は「もう読むデータはない」(EOF) と認識する。

Today I Learned - 2026-06-05

2026-06-05T21:15:11+09:00

今日学んだことを雑多に書く。

Lambda関数をCloudFormationでデプロイする

Lambda 関数を CloudFormation でデプロイしたい。

2026-06-02のTIL で作成した関数をデプロイするテンプレートはこちら。

AWSTemplateFormatVersion: '2010-09-09'
Description: Deploy Lambda for Step Functions start workflow.

Parameters:
  StateMachineArn:
    Type: String
    Description: ARN of the Step Functions state machine to start.

Resources:
  StartStepFunctionLambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - sts:AssumeRole
      Path: /
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: StartStepFunctionPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - states:StartExecution
                Resource: !Ref StateMachineArn

  StartStepFunctionLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: StartStepFunctionLambda
      Runtime: python3.14
      Handler: index.lambda_handler
      Role: !GetAtt StartStepFunctionLambdaExecutionRole.Arn
      Timeout: 60
      Environment:
        Variables:
          STATE_MACHINE_ARN: !Ref StateMachineArn
      Code:
        ZipFile: |
          import boto3
          import json
          import os

          sfn = boto3.client('stepfunctions')

          STATE_MACHINE_ARN = os.environ['STATE_MACHINE_ARN']

          def lambda_handler(event, context):
              input_payload = {
                  "instanceType": event['instanceType'],
                  "clusterId": event['clusterId'],
              }

              response = sfn.start_execution(
                  stateMachineArn=STATE_MACHINE_ARN,
                  input=json.dumps(input_payload)
              )

              return {
                  'statusCode': 200,
                  'executionArn': response['executionArn']
              }

Outputs:
  StartStepFunctionLambdaArn:
    Description: ARN of the Step Functions start Lambda function
    Value: !GetAtt StartStepFunctionLambda.Arn

  StartStepFunctionLambdaName:
    Description: Name of the Step Functions start Lambda function
    Value: !Ref StartStepFunctionLambda

Today I Learned - 2026-06-02

2026-06-02T20:13:30+09:00

Today I Learned (TIL) の投稿。今日学んだことを雑多に書く。

Lambda関数からステートマシンを起動する

import boto3
import json
import os

sfn = boto3.client('stepfunctions')

# 環境変数から取得
STATE_MACHINE_ARN = os.environ['STATE_MACHINE_ARN']

def lambda_handler(event, context):
    # イベントからパラメータを受け取る
    input_payload = {
        "instanceType": event['instanceType'],
        "clusterId": event['clusterId'],
        # その他の必要なパラメータ
        ... 
    }

    response = sfn.start_execution(
        stateMachineArn=STATE_MACHINE_ARN,
        input=json.dumps(input_payload)
    )

    return {
        'statusCode': 200,
        'executionArn': response['executionArn']
    }

Lambda 関数からステートマシンを起動するためには、Lambda 関数に適切な IAM ロールを割り当てる必要がある。以下は IAM ポリシーの例。

{
  "Effect": "Allow",
  "Action": "states:StartExecution",
  "Resource": "arn:aws:states:ap-northeast-1:123456789:stateMachine:AddRdsReader"
}

Today I Learned - 2026-05-31

2026-06-01T07:47:56+09:00

Today I Learned (TIL) の投稿。今日学んだことを雑多に書く。

壁紙のボールペン跡を落とす

うっかりボールペンで壁紙を汚してしまった。

エタノールが効くらしい。

www.youtube.com

たまたま自宅に消毒用エタノールがあったので、使ってみる。スプレーしたティッシュで叩いたら、綺麗に落ちた。

使ったのはこちら。

amzn.to

Today I Learned - 2026-05-30

2026-05-30T17:03:55+09:00

朝活のもくもく会に参加した

https://morimori.connpass.com/event/395025/

週末は 8:00～9:30 開催。開始時にやること、終了時にやったことを投稿する。

時間を予約すると、それだけでメリハリがつく気がする。続けてみる。

先延ばしにしていた登壇スライドリポジトリの整備ができた。

https://github.com/JHashimoto0518/slide-deck/

再起動なしでマウントしたい

OS を再起動すると/etc/fstabを元にマウントされるが、再起動を避けたいケースがある。

# fstabに記述されているすべてのファイルシステムをマウントする
sudo mount -a
# 特定のエントリだけマウントする
sudo mount /mountpoint

マウント先のEFSファイルシステムIDを確認する

複数の EFS ファイルシステムがある。誤ったファイルシステムをマウントしていないか確認したい。

dfの出力では EFS の接続先が 127.0.0.1 となり、ファイルシステム ID を確認できない。どうすればよいか？

df -h
# 127.0.0.1:/path ...

EFS マウントヘルパーが TLS マウント時に自動生成するファイルをみればよい。

ファイルシステム ID がfs-xxxxxxxxxxxxxx、マウントポイントが/home/my-user/contents、トンネルのポートが20000だとすると、以下のように出力される。

sudo ls -1 /var/run/efs/
# fs-xxxxxxxxxxxxxxx.home.my-user.contents.20000

EFSの接続先が127.0.0.1である理由

先に記載したとおり、EFS の接続先が 127.0.0.1 として出力される。Amazon Linux 2023 (AL2023) で確認。

# AL2
fs-xxxxxxxxxxxxxx.efs.ap-northeast-1.amazonaws.com:/contents ... /home/my-user/contents
 
# AL2023
127.0.0.1:/contents ... /home/my-user/contents

原因は Amazon Linux でサポートする amazon-efs-utils のバージョンアップ（1 系 → 2 系）の際に、デフォルトでのセキュリティ強化が入ったため。

amazon-efs-utils 2 系では、EFS マウント時にデフォルトで転送時暗号化が有効になる
その場合、NFS クライアントは暗号化されたトンネル経由で EFS に接続するため、df コマンドでは接続先が 127.0.0.1 として表示される

参考: https://docs.aws.amazon.com/ja_jp/efs/latest/ug/encryption-in-transit.html

EFS マウントヘルパーは、efs-proxy (efs-utils バージョン 2.0.0 以降) または stunnel (efs-utils の以前のバージョン) を使用して EFS ファイルシステムとの安全な TLS 接続を確立することでプロセスを管理します。

Today I Learned - 2026-05-29

2026-05-29T22:34:40+09:00

はてなブログワークフローで記事を投稿する

テンプレートリポジトリ: https://github.com/hatena/Hatena-Blog-Workflows-Boilerplate

セットアップは省略。組織ではなく個人利用を想定。

下書きを作成する

プルリクエストを作成する。

Actions から create draft を選択し、Titleに記事タイトルを設定、Branch: mainに対して実行する

作成した下書きを含むプルリクエストが作成される

下書きを含むブランチがリモートに作成される。ブランチ名は draft-entry-xxxxx という形式になっている。

ローカルで下書きを編集する

リモートの情報を取得してからスイッチする。

git fetch origin
git switch draft-entry-xxxxx

記事を公開する

下書きを編集したらフロントマターのDraft: trueを削除し、コミット、プッシュする。

git push origin draft-entry-xxxxx

-u (--set-upstream) で次回からブランチ指定を省略できる。マージ後にブランチは削除するので、今回はつけていない。

プルリクエストを main ブランチにマージすると記事が公開される。

はてなブログワークフローで既存記事を修正する

main ブランチに修正を直接プッシュしても、記事には反映されない。修正ブランチを main ブランチにマージする必要がある。

修正ブランチを作成する。

git switch -c fix/entry

修正をコミットしたらプッシュする。

git push origin fix/entry

GitHub でプルリクエストを作成し、main にマージすると、記事に反映される。

Linuxディストリビューションのバージョンを取り出す

ディストリビューションのバージョンを確認したい。

Amazon Linux 2023 の例。

$ cat /etc/os-release | grep PRETTY_NAME | cut -d'"' -f2
# Amazon Linux 2023.7.20250331

元の出力は以下のようになっている。

$ cat /etc/os-release
# NAME="Amazon Linux"
# VERSION="2023"
# ID="amzn"
# ID_LIKE="fedora"
# VERSION_ID="2023"
# PLATFORM_ID="platform:al2023"
# PRETTY_NAME="Amazon Linux 2023.7.20250331"
# ANSI_COLOR="0;33"
# CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2023"
# HOME_URL="https://aws.amazon.com/linux/amazon-linux-2023/"
# DOCUMENTATION_URL="https://docs.aws.amazon.com/linux/"
# SUPPORT_URL="https://aws.amazon.com/premiumsupport/"
# BUG_REPORT_URL="https://github.com/amazonlinux/amazon-linux-2023"
# VENDOR_NAME="AWS"
# VENDOR_URL="https://aws.amazon.com/"
# SUPPORT_END="2029-06-30"

なお、カーネルのバージョンを出力するには、以下のコマンドを使用する。

$ uname -r
# 6.12.20-23.97.amzn2023.x86_64

Webサーバーを構成していないターゲットに対してALBのエンドポイントにリクエストして疎通確認する方法（続き）

til-2026-05-28 のコードを再掲する。

python3 -c "
import http.server, socketserver

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'OK')
    def log_message(self, format, *args):
        pass  # ログ抑制

with socketserver.TCPServer(('', 8443), Handler) as httpd:
    httpd.serve_forever()
"

リッスンポートは環境依存なので、環境変数で渡すようにする。

PORT=8443 python3 -c "
import http.server, socketserver, os

PORT = int(os.environ['PORT'])

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'OK')
    def log_message(self, format, *args):
        pass  # ログ抑制

with socketserver.TCPServer(('', PORT), Handler) as httpd:
    print(f'Listening on port {PORT}')
    httpd.serve_forever()
"

出力の際にプロンプトが改行されず見づらいので、末尾に改行を入れる。

PORT=8443 python3 -c "
import http.server, socketserver, os

PORT = int(os.environ['PORT'])

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
-        self.wfile.write(b'OK')
+        self.wfile.write(b'OK\n')
    def log_message(self, format, *args):
        pass  # ログ抑制

with socketserver.TCPServer(('', PORT), Handler) as httpd:
    print(f'Listening on port {PORT}')
    httpd.serve_forever()
"

Ctrl + Cでエラーが出力される

^CTraceback (most recent call last):
  File "<string>", line 16, in <module>
  File "/usr/lib64/python3.9/socketserver.py", line 232, in serve_forever
    ready = selector.select(poll_interval)
  File "/usr/lib64/python3.9/selectors.py", line 416, in select
    fd_event_list = self._selector.poll(timeout)
KeyboardInterrupt

Ctrl+C による KeyboardInterrupt を Catch して、いったん解消した。あとで精査する。

with socketserver.TCPServer(('', PORT), Handler) as httpd:
     print(f'Listening on port {PORT}')
-    httpd.serve_forever()
+    try:
+        httpd.serve_forever()
+    except KeyboardInterrupt:
+        pass
 "

Ctrl + Cで終了した直後に再度実行するとエラー終了する

Traceback (most recent call last):
  File "<string>", line 14, in <module>
  File "/usr/lib64/python3.9/socketserver.py", line 452, in __init__
    self.server_bind()
  File "/usr/lib64/python3.9/socketserver.py", line 466, in server_bind
    self.socket.bind(self.server_address)
OSError: [Errno 98] Address already in use

使用中のポートへの再バインドで失敗している。SO_REUSEADDR を有効にすると、TIME_WAIT 状態のソケットが残っていても同じポートにバインドできるようになる。

+socketserver.TCPServer.allow_reuse_address = True
 with socketserver.TCPServer(('', PORT), Handler) as httpd:
     print(f'Listening on port {PORT}')
     try:
         httpd.serve_forever()
     except KeyboardInterrupt:
         pass

これらをすべて取り込んだ改良版。

PORT=8443 python3 -c "
import http.server, socketserver, os

PORT = int(os.environ['PORT'])

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'OK\n')
    def log_message(self, format, *args):
        pass

socketserver.TCPServer.allow_reuse_address = True
with socketserver.TCPServer(('', PORT), Handler) as httpd:
    print(f'Listening on port {PORT}')
    try:
        httpd.serve_forever()
    except KeyboardInterrupt:
        pass
"

Today I Learned - 2026-05-28

2026-05-29T08:55:05+09:00

til (Today I Learned) をブログに投稿する試み。

NLBを複数の踏み台サーバーのエンドポイントにしたい

現状

NLB がポート 22 でリッスンしている
転送先：踏み台サーバーA（ポート 22）
踏み台サーバーB にも転送したい

別ポートでリスナーを追加

リスナーポート	ターゲットグループ (ポート)	ターゲット (ポート)
`22`	ターゲットグループA（22）	踏み台サーバーA (22)	既存
`2222`	ターゲットグループB（22）	踏み台サーバーB (22)	新規

NLBのセキュリティグループで新しいリスナーポートを許可

NLB のセキュリティグループで、ポート 2222 へのインバウンドルールを追加
NLB がセキュリティグループをサポートする前に作成されたため、今回はセキュリティグループがなかった

あとからセキュリティグループを関連付けることはできる？

セキュリティグループを関連付けずに NLB を作成した場合、あとからセキュリティグループを関連付けることはできない。

セキュリティグループを関連付けずに Network Load Balancer を作成した場合、後でセキュリティグループを Network Load Balancer に関連付けることはできません。Network Load Balancer を作成するときに、セキュリティグループを Network Load Balancer に関連付けることをお勧めします。

セキュリティグループを関連付けて Network Load Balancer を作成した後は、Network Load Balancer に関連付けられたセキュリティグループはいつでも変更できます。

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/load-balancer-security-groups.html

amazon-cloudwatch-agent-ctl

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/start-CloudWatch-Agent-on-premise-SSM-onprem.html

fetch-config アクションを使用して、設定を CloudWatch エージェントに適用できる。

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json \
  -s

オプション	値	意味
`-a`	`fetch-config`	アクション：設定を取得して適用する
`-c`	`file:/opt/...`	設定ソース：どこから設定を読み込むか
`-s`	（値なし）	Start：設定適用後にエージェントを起動する

-c オプションには、SSM パラメータストアも指定できる。

-c ssm:configuration-parameter-store-name

ターミナルからコピーペーストしてファイルを作成する際のバリデーション

セッションマネージャー (SSM) コンソールで疑似 SSH アクセスしている環境がある。

SSM のターミナルではファイルコピーができないため、ターミナルからコンテンツをクリップボードにコピーし、WSL のターミナルにペーストしてファイルを作成した。

双方のコンテンツ同一性を検証するにはファイルのハッシュ値を突き合わせるとよい。

# SHA256
sha256sum filename

Webサーバーを構成していないターゲットに対してALBのエンドポイントにリクエストして疎通確認する方法

ここではインフラ観点での疎通確認を指す。Web サーバーなどのアプリケーションが構成されていないターゲットに対して、ALB のエンドポイントにリクエストしてターゲットへの疎通を確認する方法。

以下の経路を想定する。

ALB (HTTP:443) -> ターゲットグループ (HTTP:8443) -> ターゲット (HTTP:8443)

Python の組み込み HTTP サーバーを使用して、ターゲットで HTTP リクエストを受け付けるようにする。リクエストパスに関わらず常に 200 OK を返すので、ヘルスチェックパスを気にせずに疎通確認できる。

python3 -c "
import http.server, socketserver

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'OK')
    def log_message(self, format, *args):
        pass  # ログ抑制

with socketserver.TCPServer(('', 8443), Handler) as httpd:
    httpd.serve_forever()
"

まず、ターゲットで HTTP サーバーを起動して、ローカルでリクエストしてみる。

curl http://localhost:8443/my-health-check-path
# OK

次に、ターゲットグループのヘルスチェックで Unhealthy が Healthy に変わるのを確認する。

なお、Healthy になるには、該当ターゲットグループを ALB に関連付ける必要があるので気を付けること。関連付けられていない場合は、ヘルスステータスは Unused: Target group is not configured to receive trafficfrom the load balancer となる。

Healthy になったら、ALB のエンドポイントにリクエストしてみる。

curl https://alb-endpoint/
# OK

このときに ALB の DNS 名と証明書のドメイン名が一致していないため、証明書の検証エラーになるので注意。

curl: (60) SSL: no alternative certificate subject name matches target host name 'my-alb.ap-northeast-1.elb.amazonaws.com'
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

疎通確認が目的なので、証明書の検証はスキップする。

curl -k https://alb-endpoint/
# OK

または、ドメインに対してリクエストする。

curl https://my-domain.com/
# OK

確認が終わったら、ターミナルで Ctrl + C して HTTP サーバーを停止する。

GitHub認証にGitHub CLIを利用するには

2025-09-27T21:41:32+09:00

コマンドラインから GitHub にアクセスする際に、認証する方法は複数あります。

GitHub CLI (gh) を使用しブラウザで認証すると、persnal access token の発行が不要になります。プロトコルは SSH も選べますが、今回は鍵の作成が不要な HTTPS を使用します。

環境

Ubuntu 24.04.3 LTS on WSL

手順

GitHub CLI (gh) をインストールします。

$ sudo apt update
$ sudo apt install gh                                                                                 
$ gh --version
# gh version 2.45.0 (2025-07-18 Ubuntu 2.45.0-1ubuntu0.3)                                                                                                                      ```

gh auth login を実行し、以下のように入力します。ブラウザで提示された URL にアクセスし、認証コードを入力します。

$ gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

gh が Git の credential helper として設定され、今後 git clone 等の際に認証が不要になります。

$ git config --list | grep credential
# credential.https://github.com.helper=
# credential.https://github.com.helper=!/usr/bin/gh auth git-credential
# credential.https://gist.github.com.helper=
# credential.https://gist.github.com.helper=!/usr/bin/gh auth git-credential

参考

https://docs.github.com/ja/authentication/keeping-your-account-and-data-secure/about-authentication-to-github

なぜKMSキーが割り当てられていないエイリアスが存在するのか？

2024-09-03T08:30:07+09:00

AWS CLI list-aliases のレスポンスに、TargetKeyId フィールドがないエイリアスが含まれていることがあります。

aws kms list-aliases
{
    "Aliases": [
        {
            "AliasName": "alias/aws/codecommit",
            "AliasArn": "arn:aws:kms:ap-northeast-1:xxxxxxxxxxxx:alias/aws/codecommit",
            "TargetKeyId": "xxxx...",
            "CreationDate": "2024-06-17T00:34:07.222000+00:00",
            "LastUpdatedDate": "2024-06-17T00:34:07.222000+00:00"
        },
        {
            "AliasName": "alias/aws/dynamodb",
            "AliasArn": "arn:aws:kms:ap-northeast-1:xxxxxxxxxxxx:alias/aws/dynamodb"
        },
        ...

なぜ、KMSキーが割り当てられていないエイリアスが存在するのか疑問に思い、調べてみました。

これらは、AWS が作成した定義済みのエイリアスで、まだ KMS キーとは関連付けられていないものでした。これらの定義済みエイリアスは、通常、サービスの使用をスタートすると AWS 管理キーに関連付けられます。

docs.aws.amazon.com

レスポンスには、TargetKeyId フィールドがないエイリアスが含まれている場合もあります。これらは AWS が作成した定義済みのエイリアスですが、まだ KMS キーとは関連付けられていません。

docs.aws.amazon.com

一部の AWS エイリアスには KMS キーがありません。これらの定義済みエイリアスは、通常、サービスの使用をスタートすると、AWS マネージドキーに関連付けられます。

ちなみに、CreateAlias API は TargetKeyId が必須なので、KMS キーが割り当てられないエイリアスを作成することはできません。

docs.aws.amazon.com

2022年に買って良かったもの８選

2022-12-31T19:50:00+09:00

2022年に買って良かったものを厳選して紹介します。

昇降式スタンディングデスク

腰痛を患ったので買いました。立って仕事をするようになり、腰の負担はかなり軽くなった気がします。

普通のデスクに乗せて使用するタイプです。ほとんど力を入れずに昇降でき、無段階で高さを調整できます。キーボード、マウス、ディスプレイを置いていますが、十分な広さがあります。構造はしっかりしていて揺れを気にせずに打鍵できます。その分重量はかなりあります (7.8Kg) 。

リンク

ノイズキャンセリングイヤーセット

ノイズキャンセリング付きです。以前からリモート会議中にPCの打鍵音がマイクに拾われていないか気になっていました。Zoomでテストしたところ、打鍵音は全く聞こえませんでした。高価なだけあって通話・音声は非常に安定しています。USBドングルを差し替えるだけで、複数デバイスで利用できます。

リンク

ケースがドッキングスタンドになっており、置くだけで充電できます。

www.poly.com

尚、単体モデルはケースとUSBドングルが付属していないので、ご注意ください。

コンパクトデジタルスケール

封筒の計量に使っています。郵便局まで計量に行くのが面倒で購入しました。コンパクトでよいです。カバーが測る物を載せる容器になるのも便利です。

リンク

ダンボールストッカー

洗面所の隙間にぴったり収まるサイズなので購入しました。景観を損なわずにダンボールを保管できます。

保管したままダンボールを縛れるのも便利です。キャスター付きで移動できます。マグネットでカッターなどの小物をくっつけられます。

リンク

ダンボール開梱カッター

ダンボールを簡単に開梱できます。700円で粘着テープを剥がすストレスから解放されました。ボタンを押したときだけロックが外れる安全設計です。マグネット付きなのでダンボールストッカーにくっつけています。

レターオープナーとの二役でコスパがよいです。

リンク

ドアストッパー

ネットスーパーをよく利用します。商品受け渡し中にドアを開放しておくのに使っています。強力なマグネットでドアをしっかり固定してくれます。

リンク

Kindle Oasis

就寝後にマンガを読むのに利用しています。iPhoneのKindleアプリでも読めますが、ブルーライトが気になるので購入しました。反応の遅さが少し気になりますが、概ね満足しています。

Oasisは購入当時の最上位モデルで、ページ送りボタンとディスプレイサイズを理由に選びました。広告なしモデルを選んで正解でした。

リンク

カバーも同時に購入しました。指を通すバンドが付属しており落下を防げます。私は電車の中でも読むので、このカバーが必須です。

リンク

Apple Watch Series 7

ジョギングにRunKeeperを使っています。ジョギングにiPhoneを携帯するのが煩わしく、Apple Watchを購入しました。

また、つい仕事に集中し過ぎてしまう自分にとっては、一定時間座り続けていると「スタンドの時間です！立ち上がって1分間ほど動きましょう」とリマインドしてくれる機能がよいです。

リンク

ASICS Runkeeper: ランニングアプリ

無料

(2022.12.31時点)

App Store

FitnessKeeper, Inc.

posted with ポチレバ

一昨年の開業で立て込んでいたこともありアウトプットが滞ってましたが、2023年はブログの再開に本腰を入れたいと思います。ではよいお年を。

【Terraform】movedブロックでmoduleをリファクタリングする

2022-05-08T19:29:46+09:00

movedブロックはTerraform1.1で導入された新機能です。moduleのリファクタリングに使えるか検証しました。

実行環境

ubuntu-20.04 on Windows 10 (WSL2)

$ terraform --version
Terraform v1.1.9
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v3.55.0

コード

準備したコードです。事前にapplyまで済ませてあります。

modules/vpc/variables.tf

variable "vpc_name" {
  type = string
}

variable "vpc_cidr" {
  type = string
}

variable "subnet" {
  type = list(object({
    name = string
    cidr = string
  }))
}

modules/vpc/main.tf

resource "aws_vpc" "this" {
  cidr_block  = var.vpc_cidr
  tags        = { Name = var.vpc_name }
}

resource "aws_subnet" "pub" {
  for_each = { for i in var.subnet : i.name => i }
  vpc_id      = aws_vpc.this.id
  cidr_block  = each.value.cidr
  tags        = { Name = each.value.name }
}

output "vpc_id" {
  value = aws_vpc.this.id
}

main.tf

module "vpc" {
  source = "../modules/vpc"

  vpc_name = "vpc-sample"
  vpc_cidr = "172.16.0.0/16"
  subnet = [
    {
      name = "subnet-sample1"
      cidr = "172.16.0.0/20"
    },
    {
      name = "subnet-sample2"
      cidr = "172.16.16.0/20"
    }
  ]
}

// moduleを使わない
resource "aws_security_group" "this" {
  name        = "securitygroup-sample1"
  vpc_id      = module.vpc.vpc_id
}

moduleを使わないリソースのリネーム

まずmoduleを使わず定義したリソースで試します。

セキュリティグループのリソース名をdefaultに変更します。

diff --git a/vpc_sample/main.tf b/vpc_sample/main.tf
index 6b09809..bfa4756 100755
--- a/vpc_sample/main.tf
+++ b/vpc_sample/main.tf
@@ -15,7 +15,7 @@ module "vpc" {
   ]
 }

-resource "aws_security_group" "this" {
+resource "aws_security_group" "default" {
   name        = "securitygroup-sample1"
   vpc_id      = module.vpc.vpc_id
 }

当然ですが、リソースを作り直すplanが出力されます。

$ terraform plan
aws_security_group.this: Refreshing state... [id=sg-02a601a6be35932e4]
module.vpc.aws_vpc.this: Refreshing state... [id=vpc-0c91c8c5673d89ee5]
module.vpc.aws_subnet.pub["subnet-sample1"]: Refreshing state... [id=subnet-01629b6f8717a5523]
module.vpc.aws_subnet.pub["subnet-sample2"]: Refreshing state... [id=subnet-0edf4b9618cf8f38f]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create
  - destroy

Terraform will perform the following actions:

  # aws_security_group.default will be created
  + resource "aws_security_group" "default" {
      + arn                    = (known after apply)
      + description            = "Managed by Terraform"
      + egress                 = (known after apply)
      + id                     = (known after apply)
      + ingress                = (known after apply)
      + name                   = "securitygroup-sample1"
      + name_prefix            = (known after apply)
      + owner_id               = (known after apply)
      + revoke_rules_on_delete = false
      + tags_all               = (known after apply)
      + vpc_id                 = "vpc-0c91c8c5673d89ee5"
    }

  # aws_security_group.this will be destroyed
  # (because aws_security_group.this is not in configuration)
  - resource "aws_security_group" "this" {
      - arn                    = "arn:aws:ec2:ap-northeast-1:601660378746:security-group/sg-02a601a6be35932e4" -> null
      - description            = "Managed by Terraform" -> null
      - egress                 = [] -> null
      - id                     = "sg-02a601a6be35932e4" -> null
      - ingress                = [] -> null
      - name                   = "securitygroup-sample1" -> null
      - owner_id               = "601660378746" -> null
      - revoke_rules_on_delete = false -> null
      - tags                   = {} -> null
      - tags_all               = {} -> null
      - vpc_id                 = "vpc-0c91c8c5673d89ee5" -> null
    }

Plan: 1 to add, 0 to change, 1 to destroy.

これを避けるには、従来はterraform state mvでリソース名をリネームする必要がありました。Terraform 1.1からはmovedブロックが利用できます。

dev.classmethod.jp

movedブロックを追加して、再度planを実行してみます。

$ git diff
diff --git a/vpc_sample/main.tf b/vpc_sample/main.tf
index 6b09809..2cb6d0b 100755
--- a/vpc_sample/main.tf
+++ b/vpc_sample/main.tf
@@ -15,7 +15,13 @@ module "vpc" {
   ]
 }

-resource "aws_security_group" "this" {
+resource "aws_security_group" "default" {
   name        = "securitygroup-sample1"
   vpc_id      = module.vpc.vpc_id
-}
\ No newline at end of file
+}
+
+moved {
+  from = aws_security_group.this
+  to = aws_security_group.default
+}

$ terraform plan
module.vpc.aws_vpc.this: Refreshing state... [id=vpc-0c91c8c5673d89ee5]
aws_security_group.default: Refreshing state... [id=sg-02a601a6be35932e4]
module.vpc.aws_subnet.pub["subnet-sample1"]: Refreshing state... [id=subnet-01629b6f8717a5523]
module.vpc.aws_subnet.pub["subnet-sample2"]: Refreshing state... [id=subnet-0edf4b9618cf8f38f]

Terraform will perform the following actions:

  # aws_security_group.this has moved to aws_security_group.default
    resource "aws_security_group" "default" {
        id                     = "sg-02a601a6be35932e4"
        name                   = "securitygroup-sample1"
        tags                   = {}
        # (8 unchanged attributes hidden)
    }

Plan: 0 to add, 0 to change, 0 to destroy.

今度はリソース名をリネームするplanが出力されました。add/destroyが0であることを確認して、applyします。

$ terraform apply
...
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

無事にリソースを再作成することなくapplyできました。念のため再度planします。

$ terraform plan
module.vpc.aws_vpc.this: Refreshing state... [id=vpc-0c91c8c5673d89ee5]
aws_security_group.default: Refreshing state... [id=sg-02a601a6be35932e4]
module.vpc.aws_subnet.pub["subnet-sample2"]: Refreshing state... [id=subnet-0edf4b9618cf8f38f]
module.vpc.aws_subnet.pub["subnet-sample1"]: Refreshing state... [id=subnet-01629b6f8717a5523]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

コードとstateが同期されていることを確認できました。

module内リソースのリネーム

ここからが本題のmoduleのリファクタリングです。

vpcのリソース名を変更するので、先に確認しておきます。

$ terraform state list | grep aws_vpc
module.vpc.aws_vpc.this

リソース名を変更し、movedを定義します。

$ git diff
diff --git a/modules/vpc/main.tf b/modules/vpc/main.tf
index 15d46e6..b6848a6 100755
--- a/modules/vpc/main.tf
+++ b/modules/vpc/main.tf
@@ -1,15 +1,20 @@
-resource "aws_vpc" "this" {
+resource "aws_vpc" "default"
   cidr_block  = var.vpc_cidr
   tags        = { Name = var.vpc_name }
 }

+moved {
+  from = aws_vpc.this
+  to = aws_vpc.default
+}

 resource "aws_subnet" "pub" {
   for_each = { for i in var.subnet : i.name => i }
-  vpc_id      = aws_vpc.this.id
+  vpc_id      = aws_vpc.default.id
   cidr_block  = each.value.cidr
   tags        = { Name = each.value.name }
 }

 output "vpc_id" {
-  value = aws_vpc.this.id
+  value = aws_vpc.default.id
 }

planを実行します。

$ terraform plan
module.vpc.aws_vpc.default: Refreshing state... [id=vpc-0c91c8c5673d89ee5]
aws_security_group.default: Refreshing state... [id=sg-02a601a6be35932e4]
module.vpc.aws_subnet.pub["subnet-sample1"]: Refreshing state... [id=subnet-01629b6f8717a5523]
module.vpc.aws_subnet.pub["subnet-sample2"]: Refreshing state... [id=subnet-0edf4b9618cf8f38f]

Terraform will perform the following actions:

  # module.vpc.aws_vpc.this has moved to module.vpc.aws_vpc.default
    resource "aws_vpc" "default" {
        id                               = "vpc-0c91c8c5673d89ee5"
        tags                             = {
            "Name" = "vpc-sample"
        }
        # (15 unchanged attributes hidden)
    }

Plan: 0 to add, 0 to change, 0 to destroy.

期待通りに、リネームするplanが出力されました。applyします（ログは省略）。

foreachを使ったリソースのリネーム

最後にforeachを使って生成したリソースをリネームできるか検証します。

サブネットのリソース名を確認しておきます。

$ terraform state list | grep aws_subnet
module.vpc.aws_subnet.pub["subnet-sample1"]
module.vpc.aws_subnet.pub["subnet-sample2"]

サブネットのリソース名を変更し、movedを定義しました。

$ git diff
diff --git a/modules/vpc/main.tf b/modules/vpc/main.tf
index b6848a6..9fd0774 100755
--- a/modules/vpc/main.tf
+++ b/modules/vpc/main.tf
@@ -15,6 +15,15 @@ resource "aws_subnet" "pub" {
   tags        = { Name = each.value.name }
 }

+moved {
+  from = aws_subnet.pub["subnet-sample1"]
+  to = aws_subnet.pub["pri-subnet-sample1"]
+}
+moved {
+  from = aws_subnet.pub["subnet-sample2"]
+  to = aws_subnet.pub["pri-subnet-sample2"]
+}
+
 output "vpc_id" {
   value = aws_vpc.default.id
 }
diff --git a/vpc_sample/main.tf b/vpc_sample/main.tf
index 2cb6d0b..009f1d2 100755
--- a/vpc_sample/main.tf
+++ b/vpc_sample/main.tf
@@ -5,11 +5,11 @@ module "vpc" {
   vpc_cidr = "172.16.0.0/16"
   subnet = [
     {
-      name = "subnet-sample1"
+      name = "pri-subnet-sample1"
       cidr = "172.16.0.0/20"
     },
     {
-      name = "subnet-sample2"
+      name = "pri-subnet-sample2"
       cidr = "172.16.16.0/20"
     }
   ]

planを実行します。

$ terraform plan
module.vpc.aws_vpc.default: Refreshing state... [id=vpc-0c91c8c5673d89ee5]
module.vpc.aws_subnet.pub["pri-subnet-sample1"]: Refreshing state... [id=subnet-01629b6f8717a5523]
aws_security_group.default: Refreshing state... [id=sg-02a601a6be35932e4]
module.vpc.aws_subnet.pub["pri-subnet-sample2"]: Refreshing state... [id=subnet-0edf4b9618cf8f38f]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.vpc.aws_subnet.pub["pri-subnet-sample1"] will be updated in-place
  # (moved from module.vpc.aws_subnet.pub["subnet-sample1"])
  ~ resource "aws_subnet" "pub" {
        id                              = "subnet-01629b6f8717a5523"
      ~ tags                            = {
          ~ "Name" = "subnet-sample1" -> "pri-subnet-sample1"
        }
      ~ tags_all                        = {
          ~ "Name" = "subnet-sample1" -> "pri-subnet-sample1"
        }
        # (9 unchanged attributes hidden)
    }

  # module.vpc.aws_subnet.pub["pri-subnet-sample2"] will be updated in-place
  # (moved from module.vpc.aws_subnet.pub["subnet-sample2"])
  ~ resource "aws_subnet" "pub" {
        id                              = "subnet-0edf4b9618cf8f38f"
      ~ tags                            = {
          ~ "Name" = "subnet-sample2" -> "pri-subnet-sample2"
        }
      ~ tags_all                        = {
          ~ "Name" = "subnet-sample2" -> "pri-subnet-sample2"
        }
        # (9 unchanged attributes hidden)
    }

Plan: 0 to add, 2 to change, 0 to destroy.

期待通りにリネームするplanが出力されました。changeが２件出力されているのはtagsを変更したためです。論点ではないので、このままapplyします。

$ terraform apply
...
module.vpc.aws_subnet.pub["pri-subnet-sample1"]: Modifying... [id=subnet-01629b6f8717a5523]
module.vpc.aws_subnet.pub["pri-subnet-sample2"]: Modifying... [id=subnet-0edf4b9618cf8f38f]
module.vpc.aws_subnet.pub["pri-subnet-sample2"]: Modifications complete after 0s [id=subnet-0edf4b9618cf8f38f]
module.vpc.aws_subnet.pub["pri-subnet-sample1"]: Modifications complete after 0s [id=subnet-01629b6f8717a5523]

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

無事applyできました。

変更後のコード

modules/vpc/variables.tfは変更なし。

modules/vpc/main.tf

resource "aws_vpc" "default" {
  cidr_block  = var.vpc_cidr
  tags        = { Name = var.vpc_name }
}

moved {
  from = aws_vpc.this
  to = aws_vpc.default
}

resource "aws_subnet" "pub" {
  for_each = { for i in var.subnet : i.name => i }
  vpc_id      = aws_vpc.default.id
  cidr_block  = each.value.cidr
  tags        = { Name = each.value.name }
}

moved {
  from = aws_subnet.pub["subnet-sample1"]
  to = aws_subnet.pub["pri-subnet-sample1"]
}
moved {
  from = aws_subnet.pub["subnet-sample2"]
  to = aws_subnet.pub["pri-subnet-sample2"]
}

output "vpc_id" {
  value = aws_vpc.default.id
}

main.tf

module "vpc" {
  source = "../modules/vpc"

  vpc_name = "vpc-sample"
  vpc_cidr = "172.16.0.0/16"
  subnet = [
    {
      name = "pri-subnet-sample1"
      cidr = "172.16.0.0/20"
    },
    {
      name = "pri-subnet-sample2"
      cidr = "172.16.16.0/20"
    }
  ]
}

// moduleを使わない
resource "aws_security_group" "default" {
  name        = "securitygroup-sample1"
  vpc_id      = module.vpc.vpc_id
}

moved {
  from = aws_security_group.this
  to = aws_security_group.default
}

所感

moduleをリファクタリングするにはstateの移動がかなり面倒で、リファクタリングを後回しにする要因になっていました。movedブロックはリファクタリングのトイルを減らす待望の機能追加です。

LINQPadでユニットテストを書くには？

2021-12-26T14:10:24+09:00

サマリー

LINQPadはv.6.9からxUnitをサポートしていて、ユニットテストが書けます。

https://www.linqpad.net/LINQPad6.aspx

You can now add xunit test support to your query via new option on the Query menu. This adds the required references, a runner, and a sample test method to get you started. There's also a option on the Query menu Alt+Shift+T to execute all tests.

この記事では、LINQPadでのユニットテストの書き方を説明します。

実行環境

LINQPad 7 (Premium Edition) v7.1.5 (X64) on Windows 10

セットアップ

新規でQueryを作成します。LanguageはC# Programを選びました。

void Main() {
    
}

// You can define other methods, fields, classes and namespaces here

QueryメニューからAdd XUnit Test Supportを選ぶと、テンプレートが挿入されます。

#load "xunit"

void Main() {
    //RunTests();  // Call RunTests() or press Alt+Shift+T to initiate testing.
}

// You can define other methods, fields, classes and namespaces here

#region private::Tests

[Fact] void Test_Xunit() => Assert.True (1 + 1 == 2);

#endregion

初回はConfirmationダイアログが表示されるので、はいを選んで、xUnitのPackageをダウンロードします。

Alt + Shift + Tでテストを実行できます。

コードを修正して、NGをテストします。

#region private::Tests

[Fact] void Test_Xunit() => Assert.True (1 + 1 == 1);

#endregion

期待通りNGになりました。

コードをテストしてみる

文字列を返す簡単なメソッドとテストコードを書きます。

private string GetGreeting(string name) {
    return $"Hello {name}";
}

#region private::Tests

[Fact] void Test_Xunit() => Assert.True (1 + 1 == 2);

[Fact] void Test_GetGreeting_OK() => Assert.Equal("Hello Bob", GetGreeting("Bob"));
[Fact] void Test_GetGreeting_NG() => Assert.NotEqual("Hello Bob", GetGreeting("Alice"));

#endregion

期待通りのテスト結果になりました。

テストコードを別ファイルにする

コード量が多くなると、テストコードを別ファイルにした方が見通しがよくなります。

Is it possible to use xUnit with LINQPad? - Stack Overflow

This will add a query with required boilerplate code referenced via #load so you can start testing facts and theories instantly.

#loadディレクティブでできるようなので、試してみます。

GetGreetingメソッドをGetGreeting.linqに移動しました。

void Main() {
    //RunTests();  // Call RunTests() or press Alt+Shift+T to initiate testing.
    GetGreeting("Bob").Dump();
}

// You can define other methods, fields, classes and namespaces here

private string GetGreeting(string name) {
    return $"Hello {name}";
}

テストコードに#load "GetGreeting"を入れます。

#load "xunit"
#load "GetGreeting"

#region private::Tests

[Fact] void Test_Xunit() => Assert.True (1 + 1 == 2);

[Fact] void Test_GetGreeting_OK() => Assert.Equal("Hello Bob", GetGreeting("Bob"));
[Fact] void Test_GetGreeting_NG() => Assert.NotEqual("Hello Bob", GetGreeting("Alice"));

#endregion

別ファイルのメソッドをテストできました。

まとめ

LINQPadはVisual Studioに比べてコードを書くまでのオーバーヘッドが小さく、検証・テスト用途で便利に使っていました。一方でテストが書けないためコード量が多くなるにつれ、開発効率が落ちる傾向がありました。

ユニットテストを用意することで、今後は複雑なコードもLINQPadで書けそうな感触を得ました。

参考

https://www.linqpad.net/LinqReference.aspx

forum.linqpad.net

Terraform作業ディレクトリの容量を節約するには？

2021-12-24T09:00:00+09:00

問題

ディスク領域不足のアラートが出た。

terraformerのimportを何度も繰り返したせいで、作業ディレクトリ全部にTerrafromのプロバイダープラグインがダウンロードされていたのが原因。

サマリ―

Terraform作業ディレクトリの容量を節約するには、プラグインをキャッシュするとよい。

作業ログ

作業ログを残しておきます。

ホームディレクトリに.terraformrcを作成し、キャッシュディレクトリを設定する。

$ cd    # ホームディレクトリに移動
$ cat << EOF > .terraformrc

plugin_cache_dir   = "$HOME/.terraform.d/plugin-cache"
EOF

作業ディレクトリの使用容量を確認しておく。

$ du -hs
235M    .

プラグインを削除。

$ rm -rf .terraform/

terraform initでエラーが発生。

$ terraform init
There are some problems with the CLI configuration:
╷
│ Error: The specified plugin cache dir /home/jhashimoto/.terraform.d/plugin-cache cannot be opened: stat /home/jhashimoto/.terraform.d/plugin-cache: no such file or directory
│
╵

公式ドキュメントに情報があった。

CLI Configuration - Terraform by HashiCorp

This directory must already exist before Terraform will cache plugins; Terraform will not create the directory itself.

キャッシュディレクトリはTeraformが作成してくれると思ってたが、事前に作らないといけなかった。

ディレクトリを作成してリトライしたら、成功した。

$ mkdir -p "$HOME/.terraform.d/plugin-cache"
$ terraform init

Initializing the backend...

Initializing provider plugins...
- terraform.io/builtin/terraform is built in to Terraform
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using hashicorp/aws v3.68.0 from the shared cache directory

...

Terraform has been successfully initialized!
...

Using hashicorp/aws v3.68.0 from the shared cache directoryからキャッシュを利用しているのがわかる。

プラグインをキャッシュした分使用量が減っている。

$ du -hs
465K    .

念のためplanできるか確認。

$ terraform plan

...

You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

実行環境

$ terraform --version
Terraform v1.0.9
on linux_amd64

ubuntu-20.04 on Windows 10 (WSL2)

参考

【Terraform】moduleへの依存を明示する

2021-08-15T17:33:25+09:00

Terraformはリソースの依存関係を自動的に解決してくれますが、明示的な指定が必要なケースがあります。

シナリオ

次のシナリオを考えます。

リソース
1. S3バケット (バケット)
2. セキュリティグループ
3. EC2インスタンス (インスタンス)
依存関係
1. インスタンスにセキュリティグループをアタッチする
2. インスタンスはバケットに依存する（起動時にバケットからアプリケーションをダウンロードする）

リソースへの依存を明示する

インスタンスのセキュリティグループへの依存はTerraformが解決してくれますが、バケットへの依存はTerraformは検知できません（知りようがありません）。

このようなケースではaws_instance.ec2のdepends_onでバケットへの依存を指定します。

resource "aws_s3_bucket" "this" {
...
}

resource "aws_security_group" "this" {
...
}

resource "aws_instance" "ec2" {
...
    depends_on = [aws_s3_bucket.this]
}

リソースをmodule化する

では、インスタンスに必要なリソースをmodule化したい場合は、どうすればいいのでしょうか。

こんなケースです。

module "bucket" {
  source = "../modules/storage/s3/private_bucket"
....
}

module "sg" {
  source = "../modules/network/security_group"
....
}

resource "aws_instance" "ec2" {
...
}

検証

depends_on = [module.bucket]でmoduleへの依存を明示できそうな気がします。検証してみました。

depends_onなし

terraform graph | dot -Tpng > graph.pngで依存関係を可視化すると、aws_instance_ec2はmodule.bucketに依存していないことがわかります。

サイズが大きいので、関係する箇所だけ貼ります。

depends_onあり

既出のコードにdepends_onを追加します。

resource "aws_instance" "ec2" {
...
  depends_on = [module.bucket]
}

applyして依存関係を出力すると、aws_instance_ec2にmodule.bucketへの依存が設定されています。

後で確認したら、リファレンスにちゃんと書いてありました。

www.terraform.io

Version note: Module support for depends_on was added in Terraform 0.13, and previous versions can only use it with resources.

depends_onのmoduleサポートはver.0.13のアップデートで入っていました。

medium.com

【Thunderbird】メールリストのフォントサイズを変更するには？

2020-03-15T08:57:55+09:00

Summary

拡張機能は公開が停止されているようなので、CSSをカスタマイズします。

環境

Windows 10
Thunderbird 68.6.0 (64bit)

手順

Profileの確認
- C:\users\[User Name]\AppData\Roaming\Thunderbird\Profiles\にProfileがある。
  - 複数のProfileフォルダがある場合、Thunderbird -profilemanagerを実行しProfile Managerを起動して、適用されているProfileを確認。
cssファイル作成
- Profileフォルダにchrome/userChrome.cssを作成する。font-sizeはお好みで。
Thunderbird起動

userChrome.css

/*
 * Do not remove the @namespace line -- it's required for correct functioning
 */
@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* set default namespace to XUL */

/* 
 * Make all the default font sizes 9 pt:
 */
* { font-size: 9pt !important; }

Reference

support.mozilla.org

developer.mozilla.org

Moving your profile folder - Thunderbird - MozillaZine Knowledge Base

Windows 10にMinikubeをインストールするには？

2020-01-10T12:30:00+09:00

Summary

Minikubeはローカルで稼働するKubernetesクラスタです。WindowsのHyper-V上にMinikubeをインストールしてみました。

Windows 10にMinikubeをインストールするには？

今回はChocolateyを使います。管理者権限で起動したPowershellで以下のコマンドを実行します。

PS > choco install minikube
...
PS > minikube start --vm-driver=hyperv
...
PS > minikube config set vm-driver hyperv    # To make hyperv the default driver:
! These changes will take effect upon a minikube delete and then a minikube start
PS > kubectl get pod -A    # for Command Testing
NAMESPACE     NAME                               READY   STATUS    RESTARTS   AGE
kube-system   coredns-6955765f44-lldqb           1/1     Running   0          30m
kube-system   coredns-6955765f44-tbtns           1/1     Running   0          30m
kube-system   etcd-minikube                      1/1     Running   0          30m
kube-system   kube-addon-manager-minikube        1/1     Running   0          30m
kube-system   kube-apiserver-minikube            1/1     Running   0          30m
kube-system   kube-controller-manager-minikube   1/1     Running   0          30m
kube-system   kube-proxy-j7nng                   1/1     Running   0          30m
kube-system   kube-scheduler-minikube            1/1     Running   0          30m
kube-system   storage-provisioner                1/1     Running   0          30m

Reference

minikube.sigs.k8s.io blog.jhashimoto.net

【Docker】Docker Desktopの自動起動を無効にできない

2019-10-30T09:38:00+09:00

Start Docker Desktop when you log inを設定しても、Docker Desktopが自動起動する。

環境

Windows 10 バージョン1903
Docker Desktop 2.1.0.4(39773)

対応

レジストリを直接編集する。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunからDocker Desktopのエントリを削除する。

参考

Docker Desktop always starts although disabled - Docker Desktop for Windows - Docker Forums

AWS障害の振り返り

2019-08-26T21:23:11+09:00

社内で共有した文書です。クラウド初心者向けに書いているので、割り引いて読んでください。

2019/08/23の障害についてAWSがサマリーを公表しました。

aws.amazon.com

AZ（データセンターのこと）の空調設備の障害によるオーバーヒートが原因とのことでした。

一部のインスタンスについては、ハードウェアの障害によりリタイヤが必要だったと書かれています。

顧客のインスタンスが一部復旧せず、休日のサーバー再構築が必要だったと聞きました。

EC2は仮想サーバーなので、基盤の物理サーバーが壊れたらインスタンスも壊れます。それに対処するのは、AWSユーザーの責任です。このあたりは、責任共有モデルとして説明されています。

aws.amazon.com

この記事がわかりやすいです。

tech.nikkeibp.co.jp

AWSの設計指針として「クラウドコンピューティングのアーキテクチャ: ベストプラクティス」というホワイトペーパーがある。

そこにいくつか記されている指針の中で、最も有名なのがDesign for failureだ。「システムは故障する可能性があるものだという前提を受け入れ、あらかじめ故障に備えた設計をする」という考え方である。

では、具体的にどう対処したらいいのか？という話ですが、障害によるシステムダウンを回避する設計をする必要があります。

クラウドらしい（クラウドの価値を十分に享受できる）順に以下となります。

マネージドサービスを組み合わせる
EC2のMultiAZ構成
単一のEC2インスタンス

1.が最も望ましい選択肢です。非機能要件の実現をクラウドベンダーに任せることができ、運用フェーズが楽になります。

公式の資料では、こちらがわかりやすいです。

AWS Black Belt Online Seminar 2016 クラウドのためのアーキテクチャ設計 -ベストプラクティス- from Amazon Web Services Japan

www.slideshare.net

1.が困難な場合は2.を選択すると、可用性を高めることができます。

ただし、

インフラとアプリケーションを冗長化できるよう設計する必要があります。シングルインスタンスで稼働しているシステムを単純にMultiAZに移行できるわけではありません。
冗長化するので使用料金は上がる
まじめに運用設計しないと、インスタンスが増える分だけ運用コストが上がる

3.は止むを得ないケース以外は避けてください。オンプレでサーバーを運用するのとほとんど変わりません。他に選択肢がなく採用する場合は、インスタンスのバックアップ（AMI Or スナップショット）を定期的に取得するようにしてください。

【Microsoft To-Do】待望のアップデートでリストのグループ化が可能に！

2019-08-14T00:04:34+09:00

Microsoft To-Doでリストのグループ化ができるようになりました。個人的には待望のアップデートです。

techcommunity.microsoft.com

Wonderlistから移行して唯一不便だったのは、フォルダがないことでした。これで解決です。

この機能は、ユーザーフォーラムで議論されていたものです。開発が活発なので今後に期待です。

we have this

How can we improve Microsoft To-Do?

7831 votes
925 comments

Folder support / Group lists

todo.uservoice.com

WSLインストール環境設定メモ

2019-08-04T11:43:51+09:00

WSLの環境構築のメモ。

WSLインストール

[プログラムと機能の追加]からWindows Subsystem for Linuxをインストール

Ubuntuインストール

ストアからインストール

ls配色

www.kwbtblog.com

AWS CLI

sudo apt install python3-pip
pip3 install awscli --upgrade --user

j-hashimoto@PC-02-280:~$ aws --version                                                                                  
-bash: /mnt/c/Users/XXXX/AppData/Local/Programs/Python/Python36/Scripts/aws: c:\users\xxxx\appdata\local\programs\python\python36\python.exe^M: bad interpreter: No such file or directory

gokigenmaru.hatenablog.com

viエディタTips

2019-08-04T10:34:51+09:00

最近Linuxを使い始めたが、すぐ忘れるのでメモ。随時追記します。

保存して終了

/wq

検索

/文字列

指定の行へ移動

/行番号

行コピー

/yy

ペースト

/p

行削除（バッファにコピー）

/dd

【PostgreSQL】データベースのグローバルな設定を変更する

2019-07-18T18:18:20+09:00

SELECT current_setting('hoge')で取得する値を変更したい。

set_config

set_config(setting_name, new_value, is_local)を実行したが、変更が反映されなかった。set_configによる変更のスコープはセッション単位であるため。

SETでセッション内でローカルに変更できるパラメータの値を変更することができます。対応する関数はset_config(setting_name, new_value, is_local)です。

ALTER DATABASE

ALTER DATABASEを使用すると、変更が永続化される（データベース単位のグローバルな設定値が変更される）。

ALTER DATABASE db_name SET setting_name TO new_value

PostgreSQLは3つのSQLコマンドでデフォルト値を設定します。すでに説明したALTER SYSTEMコマンドは、SQLによってグローバルな設定値を変更する方法を提供します; postgresql.confを編集するのと等価です。これに加え、データベース単位あるいはロール単位で設定するためのコマンドがあります:

ALTER DATABASEコマンドはデータベース単位でグローバルな設定値を上書きします。

ちなみに、サーバーのデフォルト値を変更する場合は、ALTER SYSTEMまたはpostgresql.confを編集する。

参考

www.postgresql.jp

.NET Frameworkのアップグレードによる影響を知りたい

2019-07-11T20:32:44+09:00

.NET 4.6.1と4.6.2の差異が知りたい🤔
#.NET
— jhashimoto (@JHashimoto0518) July 9, 2019

このサイトが便利。

docs.microsoft.com

現在のバージョンと移行先のバージョンを指定します。

変更点が確認できます。

【ASP.NET】compilation要素とhttpRuntime要素のtargetFrameworkプロパティの使い分け

2019-07-11T20:18:21+09:00

.NET3.5のASP.NETアプリを.NET4.6にアップグレードした。

<system.web> 
    <compilation debug="true" targetFramework="4.6" /> 
    <httpRuntime targetFramework="4.6" /> 
</system.web>

compilation要素とhttpRuntime要素のtargetFrameworkプロパティの使い分け。

compilation要素のtargetFrameworkプロパティは、ビルド時に参照される.NETFrameworkのバージョン。
httpRuntime要素のtargetFrameworkプロパティは、実行時に参照される.NETFrameworkのバージョン。
- exeの場合は、app.configのsupportedRuntime要素で指定できるが、ASP.NETはapp.configが使えないので、httpRuntime要素を使用する。

参考

stackoverrun.com

devblogs.microsoft.com

codeday.me

docs.microsoft.com

opentouryo.osscons.jp

RedshiftのよくあるTips

2019-06-20T21:41:09+09:00

RedshiftのよくあるTipsです。随時更新します。

テーブルの分散キーとソートキーを確認したい

fooSchamaにbarTableがあるとして、

-- 検索パスにスキーマを追加する（セッション内で有効）
set search_path to '$user', public, 'fooSchama';

SELECT * FROM pg_table_def WHERE schemaname = 'fooSchama' AND tablename = 'barTable' AND (distkey = true OR sortkey > 0);

dev.classmethod.jp

エクスポートするCSVにヘッダを付けたい

UNLOADでHEADERオプションを指定します。

HEADERオプションがサポートされる前は、こんなSQLを書く必要がありました。

UNLOAD (
    'SELECT
        column1,
        column2,
        column3
    FROM (
        SELECT
            ''column1'' AS column1,
            ''column2'' AS column2,
            ''column3'' AS column3
            1 as row_num
        WHERE 1 = 1
        UNION ALL
        SELECT
            CAST(column1 AS VARCHAR) AS column1,
            CAST(column2 AS VARCHAR) AS column2,
            CAST(column3 AS VARCHAR) AS column3,
            2 as row_rum
        FROM fooSchema.barTable
    ) T ORDER BY row_num)
TO 's3://bucketname/filename'
CREDENTIALS 'credentials';

HEADERオプションを使うとシンプルに書けます。

UNLOAD ('SELECT * FROM fooSchema.barTable)
TO 's3://bucketname/filename'
CREDENTIALS 'credentials'
HEADER;

dev.classmethod.jp

キャッシュを無効化したい

パフォーマンステストで必須です。

セッションレベルで無効化する方法 set enable_result_cache_for_session=off; ユーザーレベルで無効化する方法 ALTER USER awsuser SET enable_result_cache_for_session = off;
Redshift のリザルトキャッシュを無効化する方法 - ablog

検証

SELECT * FROM tableName LIMIT 1の結果セットがキャッシュされたものか？

SELECT * FROM SVL_QLOG WHERE substring = 'SELECT * FROM tableName LIMIT 1';

userid	query	xid	pid	starttime	endtime	elapsed	aborted	label	substring	source_query	concurrency_scaling_status_txt	from_sp_call
112	3901	12973817	31495	2019/6/24 4:44	2019/6/24 4:44	8892	0	default	SELECT * FROM tableName LIMIT 1		0 - Ran on the main cluster

source_queryがNullなので、キャッシュされていない。

ユーザーにテーブル権限を付与したい

-- スキーマへのALL権限
GRANT ALL ON SCHEMA schemaName TO userName;

-- スキーマの既存テーブルへのALL権限
GRANT ALL ON ALL TABLES IN SCHEMA schemaName TO userName;

-- デフォルト権限を設定して、新たに作成されたテーブルをreadOnlyUserNameが参照可能にする
ALTER DEFAULT PRIVILEGES IN SCHEMA schemaName GRANT SELECT ON TABLES TO readOnlyUserName;

dev.classmethod.jp

ユーザーの実行権限確認

dev.classmethod.jp

テーブルの分散キー確認

SELECT "schema", "table", diststyle FROM SVV_TABLE_INFO

docs.aws.amazon.com

Gitチートシート

2019-06-18T11:59:25+09:00

随時更新します。

基本操作

ブランチを作成したい

git branch [name]
git branch [name] [ハッシュ] // コミットを指定してブランチ作成

ブランチ移動

git checkout
git checkout -b [name] // ブランチの作成と移動を同時にやる

コミット移動

git reset             // 指定のコミットまで戻る。作業ファイルはそのまま
git reset --hard  // 作業ファイルの変更も元に戻る。注意！！

リモートリポジトリを追加

git remote add origin [url]

リモートリポジトリを確認

$ git remote -v

変更をプッシュしたい

git push origin master    // originというリモートリポジトリのmasterというブランチにプッシュ

git pushで毎回パラメータを指定するのが面倒

-uを指定すると、ローカルブランチがリモートブランチにリンクされます。次回以降は引数なしでgit pushを実行できます。

git push -u origin master

リモートの更新を確認したい

git fetch　// 更新情報を取得（ファイルは更新しない）

リモートの更新をマージしたい

git merge origin/master // 更新をマージ。この例ではoriginが指すリポジトリのmasterブランチをマージ。

二つのcommit間の差分を出力したい

qiita.com

git diff <コミットハッシュ1> <コミットハッシュ2>

コミットのログを見たい

git log
git log -p // ENTERを連続で押す、またはQで抜ける

コミットのログをグラフィカルに見たい

git log --graph

ローカルの単一ファイルの変更を元に戻したい

git checkout some_filename

トラブルシュート

コミットメッセージを間違えてしまった

www.granfairs.com

クローンしたらdevelopブランチがない

qiita.com

で、git branchすればわかるんだけど、このままだとmasterブランチしかローカルにcloneできてない。別のブランチ(developmentとする)もローカルにcloneしたい。

git checkout -b development origin/development

git configの変更が反映されない

globalよりもlocalのエントリが優先されます。

git config --global user.name John
git config --list | grep user.name
user.name=Thomas

--show-originでエントリのoriginを確認します。

git config --list --show-origin | grep user.name
file:C:/Users/xxx/.gitconfig        user.name=John
file:.git/config        user.name=Thomas    // localが優先される

globalのエントリを反映させたいなら、localのエントリを削除します。

git config --unset user.name
git config --list | grep user.name
user.name=John

その他

gitignoreのテンプレートがほしい

hnw.hatenablog.com

【PostgreSQL】経過日数を取得する

2019-02-08T16:01:01+09:00

PostgreSQLはDATEDIFFをサポートしていないので、調べました。

テストデータ作成

CREATE TEMP TABLE test AS SELECT TIMESTAMP '2019-01-08 10:00:00' AS created_at;

検証

TIMESTAMP型で引き算すると、INTERVAL型で結果を取得できます。

SELECT CURRENT_TIMESTAMP - created_at AS elapsed FROM test;

30 days 20:52:11.601642

INTERVAL型から日数を取り出すには、EXTRACTを使います。

SELECT EXTRACT(DAY FROM (CURRENT_TIMESTAMP - created_at)) AS elapsed FROM test

アーキテクチャ設計書の雛形がほしいときは？

2019-01-28T11:02:14+09:00

architecture template filetype:docxで検索。

【AWS Tools for Powershell】Data Pipelineの名前からパイプラインIDを取得する

2019-01-27T10:56:46+09:00

動機

パイプラインIDはパイプラインを再作成（削除して作成）すると変わるので、パイプライン名から動的に取得したい。

コード

[String[]] $pipelineIds = Get-DPPipeline -ProfileName $profile | Where-Object -EQ name $pipelineName | Select-Object -ExpandProperty Id