OmniAICreator/Qiita-1.07M huggingface dataset:
windows server をNTPサーバとしてLinuxとWindowsでそのサーバを参照し時刻同期する



# windows server をNTPサーバとしてLinuxとWindowsでそのサーバを参照し時刻同期する

## はじめに

この記事では、Windows ServerをNTP(Network Time Protocol)サーバとして設定し、LinuxとWindowsからそのサーバを参照する方法について説明します。

## Windows Serverのファイアウォール設定の解除手順

Windows ServerのファイアウォールがNTP通信をブロックしている場合は、以下の手順で解除します。

1. 管理者としてログインします。
2. コントロールパネルを開きます。
3. 「システムとセキュリティ」を選択します。
4. 「Windows Defender ファイアウォール」をクリックします。
5. 左側のパネルで、「高度な設定」をクリックします。
6. 左側のパネルで、「受信規則」を選択します。
7. 右側のパネルで、「新しい規則」をクリックします。
8. 「プログラム」を選択し、「次へ」をクリックします。
9. 「このプログラムのパス」に、NTPサーバのプログラムパスを指定します。通常は`C:\Windows\System32\w32time.exe`です。
10. 「次へ」をクリックします。
11. 「接続を許可する」を選択し、「次へ」をクリックします。
12. 「すべてのプロファイル」にチェックを入れて、「次へ」をクリックします。
13. 名前を適切に入力し、必要に応じて説明を追加します。
14. 「完了」をクリックして設定を保存します。

## Windows Serverの設定

1. Windows Serverで管理者としてログインします。
2. PowerShellを開きます。
3. 以下のコマンドを実行して、NTPサーバの設定を行います。

```
w32tm /config /manualpeerlist:"ntp.example.com" /syncfromflags:manual /reliable:YES /update
```

4. NTPサービスを再起動します。
```
Restart-Service w32time
```

## LinuxからWindows Serverを参照し、時刻同期する方法
1. Linuxマシンで管理者権限でターミナルを開きます。
2. NTPクライアントをインストールします。例えば、Ubuntuの場合は以下のコマンドを実行します。

```
sudo apt-get update
sudo apt-get install ntp
```

3. NTP構成ファイル(/etc/ntp.conf)を編集します。以下のように追記します。
```
server ntp.example.com
```

4. NTPサービスを再起動します。

```
sudo systemctl restart ntp
```
これで、LinuxマシンはWindows ServerをNTPサーバとして参照できるようになります。


## WindowsからWindows Serverを参照し、時刻同期する方法

1. Windowsマシンで管理者としてログインします。
2. コントロールパネルを開きます。
3. 「日付と時刻」を選択します。
4. 「インターネット時間」タブをクリックします。
5. 「設定」ボタンをクリックします。
6. 「インターネット時間の設定」ダイアログボックスで、チェックボックスをオフにし、「変更」ボタンをクリックします。
7. 「サーバーの追加」ダイアログボックスで、NTPサーバのIPアドレスを入力します。例えば、`192.168.1.100`など。
8. 「OK」ボタンをクリックして設定を保存します。

これで、Windowsマシンは指定したWindows ServerのIPアドレスをNTPサーバとして参照し、時刻を同期します。

## まとめ
この記事では、Windows ServerをNTPサーバとして設定し、LinuxとWindowsからそのサーバを参照する方法について説明しました。正確な時刻同期はネットワーク環境において重要ですので、適切な設定を行うことをお勧めします。
ubuntu22.04 LTSへxrdpでログイン出来なかったけど解決した話


## 概要
ubuntuでもGUIを操作したくてxrdpをインストールしたが上手くいかなかった時の対処法

## 前提
### 接続先
OS : Ubuntu 22.04 LTS
xrdp Version : 0.9.23.1

### 接続元
OS : Windows 11 home
クライアント : RDP

## xrdpと.xsession-errorsのログの確認

### 1. xrdpログの確認

#### 確認手順：

1. SSHを使用してUbuntuサーバーに接続します。
2. xrdpのログファイルを確認します。
```bash
   sudo less /var/log/xrdp.log
```

#### xrdpログの内容：
```
[20240314-12:55:07] [INFO ] connection problem, giving up
[20240314-12:55:07] [INFO ] some problem
[20240314-12:55:07] [ERROR] xrdp_sec_send_fastpath: xrdp_fastpath_send failed
[20240314-12:55:07] [ERROR] xrdp_rdp_send_fastpath: xrdp_sec_send_fastpath failed
[20240314-12:55:07] [ERROR] xrdp_orders_send: xrdp_rdp_send_fastpath failed
...
```

#### 解析結果
接続問題に関連するエラーメッセージが多数含まれています。これらのエラーがxrdp接続の問題の原因となっている可能性があります。

### 2. .xsession-errorsログの確認と解析
#### 確認手順：

1. SSHを使用してUbuntuサーバーに接続します。
2. xrdpのログファイルを確認します。
```bash
   sudo less /home/$user名/.xsession-errors
```

#### .xsession-errorsログの内容：
```
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
...
/etc/X11/Xsession.d/30x11-common_xresources: line 16: has_option: command not found
...
/etc/X11/Xsession.d/90x11-common_ssh-agent: line 9: has_option: command not found
...
```

#### 解析結果
.xsession-errorsログには、has_option: command not found エラーが複数回記録されています。これは、関連するスクリプト内で使用されるコマンドが見つからないことを示しています。

## 対処法
以下の有益な記事がありました。どうやらubuntu 22.04 LTSのバグっぽいです。
https://ubuntu-mate.community/t/xsession-d-errors-how-to-fix-line-has-option-command-not-found/25673

記事の通り以下のコマンドを実行しxrdpを再起動することで解消します。
```bash
cat <<\EOF | sudo tee /etc/X11/Xsession.d/20x11-add-hasoption
# temporary fix for LP# 1922414, 1955135 and 1955136 bugs
# read OPTIONFILE
OPTIONS=$(cat "$OPTIONFILE") || true

has_option() {
 if [ "${OPTIONS#*
$1}" != "$OPTIONS" ]; then
   return 0
 else
   return 1
 fi
}
EOF
```
dockerコマンドのsudoを省略する


## 概要
dockerコマンドでいちいちsudoするのがだるいので省略する

## 手順

1. sudo 特権のあるユーザでログインします。

2. docker グループを作成し、ユーザを追加します。
$ sudo usermod -aG docker ubuntu

3. PCを再起動するとsudoを使わなくてもdockerコマンドが使える。

## 参考
https://docs.docker.jp/v1.12/engine/installation/linux/centos.html#:~:text=docker%20%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AE%E4%BD%9C%E6%88%90,-docker%20%E3%83%87%E3%83%BC%E3%83%A2%E3%83%B3%E3%81%AF&text=docker%20%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E5%88%A9%E7%94%A8%E6%99%82%E3%81%AB%20sudo,%E3%81%8C%E5%8F%AF%E8%83%BD%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82
【2024年版】Rundeckのジョブ結果をSlackに通知する方法


Rundeckでジョブ実行の結果をSlackに通知するために、Slack Incoming Webhookプラグインを使って設定する方法を解説します。

## 前提条件

- Rundeck バージョン: 5.7.0
- Slack バージョン: プロダクション 4.41.96 64-bit
- rundeck は EC2(amazon_linux_2)にinstall

## 手順

### 1. SlackのWebhook URLを取得

1. [Slack API](https://api.slack.com/apps)のページにアクセスし、「Create New App」から新しいAppを作成します。
2. 「Incoming Webhooks」を有効化します。
3. 「Add New Webhook to Workspace」をクリックし、通知先のチャンネルを選択します。
4. Webhook URL（例：`https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX`）が生成されるので、これをコピーしておきます。このURLは後で使用します。

### 2. RundeckでSlack Notificationプラグインのインストール

Slack Incoming WebhookプラグインがRundeckにインストールされていない場合、以下の手順でインストールしてください。

1. GitHubからプラグインをダウンロードし、`/var/lib/rundeck/libext/` に配置します：
   ```
   wget -O /var/lib/rundeck/libext/slack-incoming-webhook-plugin.jar https://github.com/rundeck-plugins/slack-incoming-webhook-plugin/releases/download/v1.2.5/slack-incoming-webhook-plugin-1.2.5.jar
   ```

   - **補足**: `/var/lib/rundeck/libext/` に配置するだけでOKです。再起動は不要です。

### 3. Rundeckのプロジェクト設定でSlack Notificationを設定

#### GUIでの設定方法

1. Rundeckにログインし、対象のプロジェクトを選択します。
2. 「PROJECT SETTINGS」から「Edit Configuration」を選択します。
3. 「Edit Configuration file」をクリックし、以下の内容を追加します。

   ```
   project.plugin.Notification.SlackNotification.channel=\#ex-rundeck-job
   project.plugin.Notification.SlackNotification.webhook_base_url=https\://hooks.slack.com/services
   project.plugin.Notification.SlackNotification.webhook_token=T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
   ```

   - `channel`には通知先のSlackチャンネルを指定します。
   - `webhook_base_url`にはSlackのWebhook URLのベース部分 `https://hooks.slack.com/services` を設定します。
   - `webhook_token`にはWebhook URLのトークン部分を指定します（例：`T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX`）。

4. 「Save」をクリックして設定を保存します。

   - **注意点**: `vim /etc/rundeck/project.properties` などでCLIから設定ファイルを直接編集しても、設定が反映されないことがあります。必ずGUIから設定を行ってください。

### 4. ジョブでSlack通知を設定

1. 対象のジョブを開き、「Notifications」タブに移動します。
2. 「成功時」と「失敗時」の通知タイプを「Slack Incoming Webhook」に設定します。
3. 必要に応じて通知の詳細（チャンネルやユーザー名など）を設定します。

   - **補足**: 通知の詳細設定が空欄の場合でも、`Edit Configuration file`で設定しているのでデフォルトで動作します。

### 5. 設定の確認

ジョブを実行して、設定したSlackチャンネルに通知が届くか確認してください。

![](https://storage.googleapis.com/zenn-user-upload/bb8641c1d256-20241112.png)

## まとめ

以上の手順で、RundeckとSlackを連携して、ジョブの実行結果をSlackに通知することができます。特にプロジェクト設定の変更はGUIから行うよう注意しましょう。
AWS SSMを使ってオンプレミスのwindowsを管理する


## 概要
以前まで特定の端末にアクセスするための中継役となる踏み台サーバを
使用するのが一般的でしたが実装コスト、管理コスト、セキュリティ面から
現在ではAWS SSMが使われています。

今回はオンプレミスのwindowsをSSMの管理対象としてRDPするところまで説明します。

## 手順

### アクティベーションの設定

1. AWSへアクセス
2. AWS Systems Manager を押下
3. **ノード管理 > ハイブリッドアクティベーション** を押下
4. **アクティベーションを作成する** を押下
5. 必要項目を設定する

- アクティベーションの説明
  - 説明を記載します。(optional)
- インスタンス制限
  - SSM管理下にしたいインスタンスの数を記載
- アクティベーションの有効期限
  - このアクティベーションの有効期限。期限が切れると登録できなくなる。(空白は1日後になる)
- デフォルトのインスタンス名
  - コンソールに表示される名前(optional)

6. ポップアップが表示されるので"activation-code" と "activation-id" をメモする。
　 ※ポップアップ以外では二度と確認出来ないので注意

### SSM Agentを対象端末にインストールする

公式手順：https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-win.html

1. プロキシ変数の設定

HTTP プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```

HTTPS プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```

2. 管理者権限でWindows PowerShell を開く
3. 以下のコマンドを実行する

```
$code = **"activation-code"**
$id = **"activation-id"**
$region = **"region"**
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/AmazonSSMAgentSetup.exe", $dir + "\AmazonSSMAgentSetup.exe")
Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=$code", "ID=$id", "REGION=$region") -Wait
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```

エラーが出た場合は以下を参照してください。
https://zukkie.link/1000-2/#toc2

### RDPを有効にする

1. 対象のwindows端末で 設定 > システム > リモートデスクトップ
2. リモートデスクトップを有効にする

### インスタンス名の変更(必要な場合のみ)

1. AWSへアクセス
2. AWS Systems Manager を押下
3. **ノード管理 > フリートマネージャー** を押下
4. 対象のノードIDを押下
5. **ノードアクション > ノード設定 > タグの追加** から以下の形式でタグを作成する

```
キー：Name 値：インスタンス名
```
【2024年版】費用面や楽さから見るマイクロ法人最強構成


フリーランスエンジニアは高収入を得やすい一方で、国民健康保険の負担が大きいという課題があります。本業より稼いでいない副業でマイクロ法人を設立し、そちらで社会保険に加入することで、保険料の負担を大幅に減らすことが可能です。

以下、費用面や手軽さから見たマイクロ法人の最強構成を紹介します。

## 1. 会社設立：マネーフォワード会社設立（0円）

マネーフォワードの「会社設立」サービスを利用すれば、無料で会社設立が可能です。わかりやすいガイドにより、簡単に会社を設立できます。さらに、クラウド会計ソフトをマネーフォワードにすると、電子定款の作成が無料になります。

ポイント：

- 定款作成時は、広めの業種で作成することをおすすめします。
  - 例えば、飲食業、情報通信業、配送業などを含めておくことで、将来的な事業拡大に柔軟に対応できます。

- 決算月は繁忙期を避けるように設定しましょう。
  - 自身の忙しい時期に決算が重なると負担が大きくなります。

## 2. クラウド会計ソフト：マネーフォワード スモールビジネスプラン（年35,760円）

会計ソフトは必須であり、機能面でマネーフォワードのスモールビジネスプランがおすすめです。ただし、費用を抑えたい場合は、弥生会計 オンラインや簡単クラウド会計などの安価なソフトを選ぶことも可能です。

## 3. 決算：ココナラで代行（年40,000円）

決算と仕訳の代行をココナラで依頼します。これにより、正確な決算書と申告が可能になります。

## 4. バーチャルオフィス：レゾナンス（月1転送プラン、年11,800円）

副業を開始する際に、バーチャルオフィスの契約を行います。おすすめはレゾナンス（月1転送プラン、年11,800円）です。GMO（月1転送プラン、年19,800円）よりも費用を抑えられます。さらに、レゾナンスはGMOあおぞらネット銀行を紹介してくれるため、法人口座開設がスムーズに行えます。

## 5. 法人口座：GMOあおぞらネット銀行

- マイクロ法人でも審査に通りやすい銀行
- 口座維持手数料無料・振り込み手数料が安い
- 保険料の自動引き落としに対応している

以上の理由により、GMOあおぞらネット銀行がマイクロ法人では最適です。2年マイクロ法人を運用しましたがほとんどが保険料の払込票なのでバーチャルオフィスを月1転送にしても問題ありません。

## 絶対にかかる費用

法人住民税：年70,000円

登記費用（合同会社）：設立時のみ60,000円

印鑑代：設立時のみ5,000円

## 最後に

費用面でメリットがある場合、マイクロ法人の設立を検討すべきです。以下のサイトでシミュレーションが可能です。

[マイクロ法人設立シミュレーション](https://wakuwaku-happiness.com/20220108/microhojin_simulation/)
windowsにインストールしたpgAdminでDB参照する方法


## 概要
windows で postgresを参照したい時の手順

## 日本語化
1. **pgadmin configure** を押下
2. **User language** を押下
3. **Japanese** を選択

## DB登録

1. General → **名前** を登録
2. 接続 → **ホスト名/アドレス** を登録
3. 接続 → **管理用データベース** を登録
4. 接続 → **パスワード** を登録
AWSシステムマネージャーを使用してEC2へのDatadog agentのインストールを自動化する


AWSシステムマネージャーのAutomationドキュメントを使用すると、既存の複数のEC2インスタンスにDatadog agentを効率的にインストールできます。

## 利点

- 複数のインスタンスに同時にインストールできる
- プロセスが自動化されるため、人的エラーのリスクが低減される
- インストールプロセスの一貫性が保たれる
- 大規模な環境での展開が容易になる

## 前提条件

1. AWSアカウントにアクセス可能であること
2. 対象のEC2インスタンスにSSMエージェントがインストールされていること
3. EC2インスタンスに適切なIAMロールが割り当てられていること（AmazonSSMManagedInstanceCore ポリシーを含む）
4. DatadogのAPI keyを用意していること

## 手順

### SSMオートメーションドキュメントの作成

1. AWSマネジメントコンソールで「Systems Manager」に移動します。
2. 左側のメニューから「ドキュメント」を選択し、「ドキュメントの作成」の中の「オートメーション」をクリックします。
![](https://storage.googleapis.com/zenn-user-upload/e6e29c2379ba-20240718.png)

3. 「コード」をクリックし以下のYAMLコードを使用して新しいオートメーションドキュメントを作成します：

```yaml
---
schemaVersion: '0.3'
description: 'Install Datadog Agent on EC2 instances'
assumeRole: '{{AutomationAssumeRole}}'
parameters:
  InstanceIds:
    type: StringList
    description: 'EC2 Instance IDs'
  DatadogApiKey:
    type: String
    description: 'Datadog API Key'
  AutomationAssumeRole:
    type: String
    description: '(Optional) The ARN of the role that allows Automation to perform the actions on your behalf.'
    default: ''
mainSteps:
  - name: InstallDatadogAgent
    action: 'aws:runCommand'
    inputs:
      DocumentName: AWS-RunShellScript
      InstanceIds: '{{InstanceIds}}'
      Parameters:
        commands:
          - |
            DD_API_KEY={{DatadogApiKey}} bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"
```

ドキュメントに名前を付けて（例：「datadog_agent_install」）保存します。
![](https://storage.googleapis.com/zenn-user-upload/b576a15724a9-20240718.png)

### オートメーションの実行

Systems Managerダッシュボードで「オートメーション」を選択し、「Owned by me」の中に先ほど作成したRunbookを指定し「オートメーションの実行」をクリックします。
![](https://storage.googleapis.com/zenn-user-upload/7ed44b2456bd-20240718.png)

以下のパラメータを入力します：
- InstanceIds: Datadog agentをインストールしたいEC2インスタンスIDのリスト
※Show interactive instance pickerをONにするとEC2が出てくるのでそれを選択してもOK
- DatadogApiKey: DatadogのAPI key

![](https://storage.googleapis.com/zenn-user-upload/222d0d31a5df-20240718.png)

「実行」をクリックしてオートメーションを開始します。

### 結果の確認

オートメーションの実行状況を確認します。
完了後、対象のEC2インスタンスにSSH接続し、Datadog agentが正常にインストールされたことを確認します：

```bash
sudo systemctl status datadog-agent
```

![](https://storage.googleapis.com/zenn-user-upload/868db919483b-20240718.png)


## 注意点

- SSMエージェントが正しくinstallされている必要がある
- 適切なIAMが設定されている必要がある
- datadog API keyは機密情報なので取り扱い注意
windows で SSM がインストールされている端末にportforwardする


## 概要
windows で SSM がインストールされている端末にportforwardする
linux はSSMでRDPがサポートされていないのでlinuxにRDPしたい時とかに使う

## 前提
- linuxの場合、対象サーバにXRDPがインストールされている
- 対象サーバにSSM Agentが入っている
- 対象サーバがインターネットに接続できる

## 手順

1. AWS CLI install ※してない場合のみ
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html

2. アクセスキー作成 ※してない場合のみ
aws ログイン→セキュリティ認証情報→アクセスキー→作成
※secretは作成直後しか確認出来ないので漏洩しない場所に保存してください。"

3. aws configureコマンドでAWS接続設定 ※してない場合のみ
アクセスキーとregionを入力すればOK

4. セッションマネージャープラグインのインストール ※してない場合のみ
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/install-plugin-windows.html"

5. ポートフォワーディング
コマンドプロンプトで以下のコマンドを実行する
```
aws ssm start-session --target $インスタンスID --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389, localPortNumber=13389"
```

6. RDPを開き以下を入力しアクセスし認証情報を入力
localhost:13389"

## 備考
- 認証後すぐRDPが落ちる場合は対象サーバ内で以下のコマンドを実行してgnomeセッションを一旦KILLする
```
pkill gnome-session
```

- 重い場合はRDPの設定で画面を小さくして色の深度も浅くしてください
Ubuntu でローカルのDBをpgAdminで参照する方法


## 概要
postgres をGUIで扱えるツールであるpgAdminでローカルにあるDBを参照する方法を記載します。

## 手順

1. pgAdmin の install の為に以下のコマンドを実行

```
sudo apt install curl
sudo curl https://www.pgadmin.org/static/packages_pgadmin_org.pub | sudo apt-key add
sudo sh -c 'echo "deb https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) pgadmin4 main" > /etc/apt/sources.list.d/pgadmin4.list'
sudo apt update
sudo apt install pgadmin4
sudo /usr/pgadmin4/bin/setup-web.sh
```

2. ログイン用の `Email address` , `Password` を入力する

3. ポート80を8080に変更し443の設定を無効にする。
`sudo vi /etc/apache2/ports.conf`

```
#Listen 80
Listen 8080
#<IfModule ssl_module>
#       Listen 443
#</IfModule>
#<IfModule mod_gnutls.c>
#       Listen 443
#</IfModule
```

4. apacheの再起動
`sudo systemctl restart apache2`

5. ブラウザで以下を開く
http://127.0.0.1:8080/pgadmin4/browser/

6. 2で設定したEmailとPasswordでログイン
Get-Content : パス 'SSM\InstanceData\registration' が存在しないため検出できません。


## 概要
windows server 2022にRDPするためにSSM agentを[公式の方法](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-win.html)でインストールしようと以下のコマンドを実行したところ・・・

```
$code = "activation-code"
$id = "activation-id"
$region = "region"
$dir = $env:TEMP + "\ssm"
New-Item -ItemType directory -Path $dir -Force
cd $dir
(New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.$region.amazonaws.com/latest/windows_amd64/AmazonSSMAgentSetup.exe", $dir + "\AmazonSSMAgentSetup.exe")
Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=$code", "ID=$id", "REGION=$region") -Wait
Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")
Get-Service -Name "AmazonSSMAgent"
```

以下のエラーが出てしまった。
```
PS C:\Users\root\AppData\Local\Temp\ssm> Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")

Get-Content : パス 'C:\ProgramData\Amazon\SSM\InstanceData\registration' が存在しないため検出できません。

発生場所 行:1 文字:12

+ Get-Content <<<<  ($env:ProgramData + "\Amazon\SSM\InstanceData\registration")

    + CategoryInfo          : ObjectNotFound: (C:\ProgramData\...ta\registration:String) [Get-Content]、ItemNotFoundException

    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand
```

## 調査内容
`Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=$code", "ID=$id", "REGION=$region") -Wait`

でログを出してるみたいなので$env:TEMPで指定してたtempフォルダ内のログを見てみると

`2023-11-01 12:16:59 ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired:`

の記述を確認

どうやらアクティベーションの期限切れの様なので作り直してコマンドを再実行したらいけた

## 結論
ログを見よう
AWS SSMを使ってオンプレミスのlinuxを管理する


## 概要
以前まで特定の端末にアクセスするための中継役となる踏み台サーバを
使用するのが一般的でしたが実装コスト、管理コスト、セキュリティ面から
現在ではAWS SSMが使われています。

今回はオンプレミスのlinuxをSSMの管理対象としてRDPするところまで説明します。

## 手順

### アクティベーションの設定

1. AWSへアクセス
2. AWS Systems Manager を押下
3. **ノード管理 > ハイブリッドアクティベーション** を押下
4. **アクティベーションを作成する** を押下
5. 必要項目を設定する

- アクティベーションの説明
  - 説明を記載します。(optional)
- インスタンス制限
  - SSM管理下にしたいインスタンスの数を記載
- アクティベーションの有効期限
  - このアクティベーションの有効期限。期限が切れると登録できなくなる。(空白は1日後になる)
- デフォルトのインスタンス名
  - コンソールに表示される名前(optional)

6. ポップアップが表示されるので"activation-code" と "activation-id" をメモする。
　 ※ポップアップ以外では二度と確認出来ないので注意

### SSM Agentを対象端末にインストールする

公式手順：https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-win.html

1. プロキシ変数の設定

HTTP プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=http://hostname:port
```

HTTPS プロキシサーバーの場合は、次の変数を設定します。
```
http_proxy=http://hostname:port
https_proxy=https://hostname:port
```

2. 該当するディストリビューションで以下の「項番3」を実行する
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-install-managed-linux.html

### インスタンス名の変更(必要な場合のみ)

1. AWSへアクセス
2. AWS Systems Manager を押下
3. **ノード管理 > フリートマネージャー** を押下
4. 対象のノードIDを押下
5. **ノードアクション > ノード設定 > タグの追加** から以下の形式でタグを作成する

```
キー：Name 値：インスタンス名
```
Datadog モニターを Terraform で管理するための import 手順


# Datadog モニターを Terraform で管理するための import 手順

## Terraform ログイン

まず、Terraform Cloud にログインします（Terraform Cloud を使用している場合）

```bash
terraform login
```

## main.tfの作成

以下は作成例

```
terraform {
  required_providers {
    datadog = {
      source  = "DataDog/datadog"
      version = "~> 3.0"
    }
  }
  cloud {
    organization = "${terraform cloudの組織名}"

    workspaces {
      name = "${terraform cloudのワークスペース名}"
    }
  }
}

provider "datadog" {
  api_key = ${DATADOG_API_KEY の値}
  app_key = ${DATADOG_APP_KEY の値}
}

```

## import ブロックの作成
適切な Terraform 設定ファイル(例:import.tf) import ブロックを作成します。

```hcl
import {
  to = datadog_monitor.url_access_check
  id = "${monitorのID}"
}
```

## Terraform 設定ファイルの生成
以下のコマンドを実行して、既存のリソースに基づいて Terraform 設定ファイルを生成します。

```bash
terraform plan -generate-config-out=generated.tf
```

このコマンドにより、generated.tf ファイルが作成され、インポートされるリソースの設定が含まれます。

## 生成された設定の確認と調整
generated.tf ファイルの内容を確認し、必要に応じて調整します。リソース名、パラメータ、その他の設定が正しいことを確認。

## Terraform plan の実行
変更内容を確認するために、Terraform plan を実行します。

```bash
terraform plan
```

出力を確認し、予期しない変更がないことを確認します。

## Terraform apply の実行
問題がなければ、変更を適用します。

```bash
terraform apply
```

確認プロンプトが表示されたら、yes と入力して実行を続行します。

## 確認
適用が完了したら terraform show コマンドを使用して、Terraform の状態ファイルに正しくリソースが追加されていることを確認できます。

```
terraform show
```
サーバーレスを小学生でも分かる様に解説する試み


## 従来の方式が抱えていた課題
昔のシステム開発では、オンプレミスのサーバーにOSをインストールし、その上にアプリケーションやミドルウェア(Webサーバー、DBMSなど)を設定するのが一般的でした。その後、仮想化技術の普及により、EC2などのクラウド上の仮想サーバーを利用するケースが増えました。しかし、これらの方式には以下のような課題があります。

- (オンプレミスの場合) サーバーのハードウェア調達とOSのインストールに手間と時間がかかる
- OSやミドルウェアのインストール・設定に専門知識が必要
- OSやミドルウェアのバージョンアップ、セキュリティパッチ適用などの保守作業が必要
- 利用者がいない時間帯でもサーバーを起動し続ける必要があり、コストがかかり続ける
- スケーリングのために設定変更が必要で、トラフィックの増減に柔軟に対応しづらい
- ストレージについても、容量の見積もりや増設の作業が必要

## サーバーレスの登場
こうした課題を解決するため、近年ではサーバーレスアーキテクチャが注目を集めています。主要なクラウドプロバイダーは以下のようなサーバーレス関数サービスを提供しています。

- AWS Lambda
- Google Cloud Functions
- Microsoft Azure Functions
- IBM Cloud Functions

これらのサービスでは、開発者はサーバーのプロビジョニングや管理をすることなく、コードを書くことに集中できます。関数は特定のイベントによってトリガーされ、必要な時にのみ実行されるため、コストも最適化されます。

これらを他のサーバーレスサービス(API Gateway、DynamoDBなど)と組み合わせることで、ハードウェアの調達やOSの設定、ミドルウェアの管理なしで、柔軟にスケーリングできるシステムを構築できます。

## サーバーレスで何ができる？
サーバーレスアーキテクチャを活用することで、様々なタイプのアプリケーションを構築できます。例えば:

- RESTful APIやWebサイトのバックエンド
 - API GatewayとLambdaを組み合わせることで、スケーラブルなバックエンドを構築できます。
- IoTのデータ処理パイプライン
 - IoTデバイスからのデータをKinesis StreamsやIoT Coreで収集し、Lambdaで処理してDynamoDBに保存できます。
- 画像や動画の変換処理
 - S3に画像や動画をアップロードし、それをトリガーにLambdaで変換処理を実行できます。
- 定期的なバッチ処理
 - CloudWatch Eventsをトリガーに、Lambdaで定期的なバッチ処理を実行できます。
- チャットボットやSlackの通知
 - API GatewayとLambdaを使って、チャットボットやSlackの通知機能を実装できます。

このように、サーバーレスは幅広いユースケースに対応できます。アプリケーションの要件に合わせて、適切なサービスを組み合わせることが重要です。

## サーバーレスのメリット
サーバーレスアーキテクチャには以下のようなメリットがあります。

- ハードウェア調達やOSのセットアップが不要で、すぐに開発を始められる
- OSやミドルウェアの管理が不要なので、アプリケーションのロジックに集中できる
- リクエストがあった時だけ実行されるので、コストを最小限に抑えられる
- 自動でスケーリングされるため、トラフィックの増減に柔軟に対応できる
- ストレージの容量を気にする必要がなく、必要に応じて自動で拡張される

## 費用の比較
月間1万PVの小規模なブログシステムをホストする場合で比較してみましょう

オンプレミスのサーバーを使う場合:
```
サーバー調達費用: 約20万円(3年リース換算で約5,600円/月)
ストレージ(500GB): 約5,000円
電力代: 約3,000円/月
管理者人件費: 約5万円/月
合計: 約6万円/月
※サーバールームのコストは除外
```

EC2(t2.micro)とRDS(db.t2.micro)を使う場合:
```
EC2インスタンス料金: 約800円
RDSインスタンス料金: 約1,000円
ストレージ料金(EBS 30GB): 約300円
合計: 約2,100円/月
```

サーバーレス(API Gateway + Lambda + DynamoDB)の場合:
```
API Gateway: 1万リクエスト分で約120円
Lambda: 128MBメモリ, 1秒の実行時間として約18円
DynamoDB: 1GBまで無料、それ以降は1GBあたり約25円
合計: 約140円/月
```

小規模なシステムであれば、サーバーレスが最もコストを抑えられる選択肢と言えます。

## 注意点
ただし、サーバーレスにも注意点があります。

- 実行時間に上限がある(Lambdaの場合は最大15分)
- コールドスタート(初回起動の遅延)が発生する可能性がある
- 大規模なシステムではEC2などの従来の方式の方が安くなるケースがある
- 全ての処理をサーバーレスで実装するのは難しい場合がある

ステートフルな処理やリアルタイム性が求められる処理など、一部の処理は従来の方式で実装した方が良いケースもあります。システムのアーキテクチャ設計では、サーバーレスと従来の方式を適切に組み合わせることが重要です。

## まとめ
サーバーレスアーキテクチャは、ハードウェア調達やOSセットアップ、ミドルウェアの管理の手間を大幅に減らせ、小規模なシステムではコストも抑えられる優れた選択肢です。AWS Lambda、Google Cloud Functions、Azure Functionsなどのサービスを活用することで、開発者はインフラではなくアプリケーションに集中できます。

また、Lambda@EdgeやCloudflare Workersなどのエッジコンピューティングサービスと組み合わせることで、レイテンシーを低減し、ユーザーにより近い場所で処理を実行できます。これによりコールドスタートの改善が期待できます。

一方で、全てのユースケースに適しているわけではありません。システムの要件をよく見極め、オンプレミス、EC2などの仮想サーバー、サーバーレス、エッジコンピューティングを適切に組み合わせることが重要です。それぞれの特性を理解し、自分のシステムに合ったアーキテクチャを設計することが、モダンなアプリケーション開発において欠かせないスキルと言えるでしょう。
【AWS】CloudWatch の不要なメトリクスが高額請求の原因に？注意点と再発防止策


先日、**Billing and Cost Management の請求書**を確認したところ、見慣れないリージョンからの請求が発生していることに気づきました。内訳を詳しく確認した結果、CloudWatch のメトリクスが意図しないリージョンに設定されており、料金が高騰していることが判明しました。

調査の結果、原因は **全リージョンで CloudWatch メトリクスが作成された** ことによるものでした。

この経験を踏まえ、同様の事象が発生した場合の対処法と、Datadog 利用時の注意点をまとめました。

### 1. 請求額の高騰に気づいたら、まず原因を特定

CloudWatchの料金が高額になっている場合、以下の要因が考えられます。

* **ログの保存量増加:**  ログの保存期間やログ出力が多いサービスがないか確認。
* **CloudWatch Logs Insights の利用:**  複雑なクエリや長期間のデータ検索を行っていないか確認。
* **CloudWatch メトリクスの利用:**
    * **カスタムメトリクスの増加:**  意図しないカスタムメトリクスが作成されていないか確認。
    * **不要なリージョンへのメトリクス設定:**  今回のケース。
* **CloudWatch アラームの利用:**  多数のアラームを設定していないか確認。
* **Vended Logs (AWS サービスからのログ):** VPC Flow Logs や Route 53 クエリログなどの取り込み量を確認。
* **CloudWatch Events (EventBridge) の利用:**  イベントの送受信量を確認。

### 2. 不要なメトリクスの削除 (AWSサポートへの依頼)

**現在、AWSの CloudWatch メトリクスは、ユーザー自身で削除できません。** 特に、Datadog などのサードパーティ製ツールによって作成されたメトリクスは、AWSコンソールから直接削除できない場合があります。

不要なメトリクスを削除したい場合は、**AWSサポートに依頼**する必要があります。

1. **AWSサポートコンソール**にアクセスします。
2. **ケースを開く**を選択し、**サービス:** に「CloudWatch」、**カテゴリ:** に「メトリクス」などを選択します。
3. **件名**と**詳細**に、不要なメトリクスが存在するリージョンとメトリクス名、および削除を希望する旨を記載します。
4. 必要に応じて、Cost Explorerや請求書の画面キャプチャなどを添付します。

### 3. メトリクスが作成された原因の調査 (CloudTrail)

同様の事象の再発を防ぐために、不要なメトリクスがいつ、何故作成されたのかを調査します。**AWS CloudTrail** を利用することで、APIの実行履歴を確認できます。

1. **AWSマネジメントコンソール**にログインし、**CloudTrail**を開きます。
2. 左側のナビゲーションペインで、**[イベント履歴]** を選択します。
3. 以下の条件でイベントをフィルタリングします。
    * **タイムスタンプ:**  メトリクスが作成された可能性のある期間。
    * **サービス名:**  `CloudWatch`
    * **イベント名:**  `PutMetricData`
    * **ユーザー名:** Datadog のインテグレーションに関連する IAM ロールまたはユーザー。
    * **リージョン:**  不要なメトリクスが存在するリージョン。

CloudTrailのイベント詳細を確認し、原因は Datadog の AWS インテグレーション設定 にある事が判明しました。

### 4. 再発防止策と Datadog 利用時の注意点

今回の経験を踏まえ、以下の再発防止策と Datadog 利用時の注意点を検討します。

* **Datadog インテグレーション設定の見直し:** Datadog の AWS インテグレーション設定で、メトリクスを収集するリージョンを意図した範囲に絞り込めているか確認します。**特定リージョンのみを監視する設定が可能**な場合があるので、設定を見直してください。
* **不要なリージョンでのリソース作成の抑制:**  AWS Organizations の SCP (Service Control Policy) などを使用して、不要なリージョンでのリソース作成を制限することを検討します。
* **IaC (Infrastructure as Code) の導入と管理徹底:** Terraform などのIaCツールを利用してインフラ構成をコードで管理し、レビュープロセスを設けることで、意図しないリソース作成を防ぎます。
* **モニタリングとアラートの設定:**  CloudWatch のメトリクス変化を監視するアラートを設定し、予期しないメトリクスの増加や異常値を早期に検知できるようにします。
* **定期的なコストチェック:**  AWS Cost Explorer や **Billing and Cost Management の請求書**などを利用して定期的にコストを監視し、全リージョンからの請求など、異常な増減があれば早めに原因を調査します。
* **タグ付けの徹底:**  リソースに適切なタグを付与することで、コスト分析やリソース管理を容易にします。

### まとめ

CloudWatchの不要なメトリクスが原因で料金が高騰するケースは、設定ミスや自動化された処理などが原因で起こり得ます。特に、**Datadog のようなサードパーティ製監視ツールを AWS 環境に連携させる場合、リージョン設定には十分な注意が必要**です。**Billing and Cost Management の請求書**で全リージョンからの請求に気づくことが、異常を早期に発見するきっかけとなります。今回の経験を活かし、原因特定、AWSサポートへの依頼、そして Datadog の設定見直しを含む再発防止策を講じることで、AWSの利用料金を最適化することができます。
【AWS】WAFをterraform importしようとしたらThe scope is not valid(400エラー) が出る


## 事象
terraform import ブロックやterraform importコマンドでCloudFrontに割り当てたAWS WAFをimportしようとすると以下のエラー

```
Error: reading WAFv2 WebACL : operation error WAFV2: GetWebACL, https response error StatusCode: 400, RequestID: 77e90616-f220-46e7-a5f5-328eafeea190, WAFInvalidParameterException: Error reason: The scope is not valid., field: SCOPE_VALUE, parameter: CLOUDFRONT
```

## 結論
CloudFront を対象としたWAFをimportする場合は us-east-1(バージニア北部)を指定する
なのでap-northeast-01などで管理している場合はstateファイルを分割する必要がある

## 参考
https://registry.terraform.io/providers/babylonhealth/aws-babylon/latest/docs/resources/wafv2_web_acl#scope
【AIが超進化？！】話題のMCPを世界一分かりやすく解説


最近、AI界隈で「MCP」という言葉をよく耳にしませんか？
「なんだか難しそう…」「AIと何が違うの？」と思っている方も多いかもしれません。

でも大丈夫！この動画（記事）を見れば、MCPが何なのか、AIをどうパワーアップさせてくれるのか、スッキリ理解できます！
AIをもっと便利に、もっとパーソナルに使いたいと思っているあなた、必見です！

## 1. MCPって、一言でいうと何？ ～AIのスーパーアシスタント～

ズバリ、MCP（Model Control Program）とは…

**「AIの能力を最大限に引き出し、私たちの代わりに色々な作業をこなせるようにする『AIの拡張機能』であり、『AIの執事』のようなプログラム群」** のことです！

例えるなら…

*   **AIが「脳みそ」** だとしたら、**MCPは「手足」や「便利な道具箱」**。
*   **AIが「優秀な新人さん」** だとしたら、**MCPは「仕事を教える先輩」や「業務マニュアル」**。

MCPがあることで、AIはただ賢いだけでなく、実際に私たちのPCを操作したり、ファイルを整理したり、情報を集めたりといった具体的なアクションを起こせるようになるんです。

## 2. なんでMCPが注目されてるの？メリットは？

MCPが注目される理由は、AIの可能性をグンと広げてくれるからです。

*   **メリット１：AIが「できること」が格段に増える！**
    *   PC内のファイル操作（「このフォルダの画像を全部リサイズして」など）
    *   ウェブサイトからの情報収集・要約（「最新のAIニュースを3つ教えて」など）
    *   複数のアプリの連携（「メールで受け取った請求書をスプレッドシートにまとめて」など）
    *   プログラミングの自動化（「簡単なWebアプリ作って」など）
    *   これらはAI単体では難しい作業ですが、MCPが仲介することで可能になります。

*   **メリット２：AIを「自分専用」にカスタマイズできる！**
    *   **ローカルで実行可能**: 多くのMCPは、自分のパソコンにインストールして使えます。
        *   **プライバシー保護**: 大切な情報や個人的なデータを外部サーバーに送らずに済むので安心。
        *   **オフライン利用**: インターネットがない環境でも使える場合がある（AIモデルによる）。
        *   **APIコスト削減**: ローカルで動くAIモデルと組み合わせれば、クラウドAIの利用料を気にせず使える！
    *   **特定の知識を学習**: MCPの中には、手持ちの資料（PDF、Wordなど）をAIに読み込ませて、その情報に特化した「物知りAI」を作れるものもあります。（例: AnythingLLM）

## 3. MCPとAIモデルの関係は？AIもパソコンに入れる必要があるの？

ここ、ちょっとややこしいポイントですよね。分かりやすく説明します！

MCPを使うとき、AIモデルがどこにあるかは、いくつかのパターンがあります。

*   **パターン１：MCPはパソコン、AIモデルはクラウド上**
    *   MCP（例: Open Interpreterの一部機能）を自分のPCにインストール。
    *   AIの「脳みそ」自体は、OpenAIのGPTやGoogleのGeminiといった高性能なクラウドAIを利用（API経由）。
    *   **メリット**: 最新・高性能なAIを使える。PCスペックは比較的低くてもOK。
    *   **デメリット**: API利用料がかかる。データが外部に送信される。

*   **パターン２：MCPもAIモデルもパソコンの中 (完全ローカル)**
    *   MCPも、AIモデル（Llama 3, Mistral, Gemmaなど、Ollama等で動くオープンソースLLM）も自分のPCにインストール。
    *   **メリット**: 完全オフライン！プライバシー最強！API利用料なし！
    *   **デメリット**: 高性能なPC（特にメモリやGPU）が必要。設定が少し複雑な場合も。

## 4. 具体的なMCPにはどんなものがあるの？

いくつか代表的なMCPを紹介しますね！

*   **Open Interpreter**:
    *   自然言語（話し言葉）でPCを操作できる！ファイル操作、コーディング、情報検索など、まるでPCに話しかけるように指示できます。ローカルLLM/クラウドAPI両対応。
*   **AnythingLLM**:
    *   手持ちのドキュメントをAIに学習させて、あなた専用の「物知りチャットボット」を簡単に作れます。GUIで操作も簡単。社内ナレッジ共有や学習支援に便利！
*   **(その他、Youtuberさんが注目しているMCPや、動画でデモするものがあれば紹介)**

これらのツールは、それぞれ得意なことが違うので、目的に合わせて選ぶのがポイントです。

## 5. MCPを始めるには？難易度は？

MCPの種類にもよりますが、

*   **GUIベースのもの (例: AnythingLLM)**: 比較的簡単に始められます。ダウンロードしてインストールし、画面の指示に従って設定すればOK。
*   **CUIベースのもの (例: Open Interpreter)**: 少しコマンドラインの知識が必要な場合がありますが、導入手順自体は多くの情報が出ています。

最初は少し戸惑うかもしれませんが、一度使えるようになるとAI活用の幅が爆発的に広がりますよ！

## まとめ：MCPでAI活用のネクストステージへ！

MCPは、AIを単なる「賢いチャット相手」から、私たちの作業を具体的に助けてくれる「有能なアシスタント」へと進化させるための強力なツールです。

「AIって便利だけど、もっとこんなことできたら良いのにな…」
そんなあなたの願いを、MCPが叶えてくれるかもしれません。

ぜひこの動画（記事）をきっかけに、MCPの世界に一歩踏み出してみてください！
そして、あなただけのAI活用法を見つけて、未来を先取りしちゃいましょう！
DatadogでSlack通知時にインスタンスIDではなく名前を表示する方法


先日、Datadogで設定したモニターからSlackに通知を送信する際、通知内でインスタンスIDではなく、わかりやすいインスタンス名を表示したいという課題に直面しました。この記事では、その解決方法を共有します。

## 問題の背景

Datadogのモニターを設定し、アラートをSlackに通知すると、デフォルトではホスト名がインスタンスIDとして表示されます。これではどのインスタンスで問題が発生したのか直感的に把握しづらいです。

## 解決策

Datadog Agentが使用するホスト名は、以下の優先順位で決定されます。

1. **agent-hostname**: Datadog Agentの設定ファイルで明示的に設定されたホスト名（`ip-`や`domu`で始まらない場合）。
2. **hostname**: システムのDNSホスト名（EC2のデフォルトでない場合）。
3. **instance-id**: AgentがEC2のメタデータエンドポイントにアクセスできる場合。
4. **hostname**: EC2のデフォルトのDNSホスト名。

現在、インスタンスIDがホスト名として設定されているため、Datadog Agentの設定ファイルでホスト名を指定することで解決できます。

## 手順

1. **Datadog Agentの設定ファイルを編集**

    Datadog Agentのメイン設定ファイルである`datadog.yaml`を開き、以下のように`hostname`を設定します。

    ```yaml
    hostname: <あなたのインスタンス名>
    ```

    `<あなたのインスタンス名>`を実際のホスト名に置き換えてください。

2. **Datadog Agentの再起動**

    設定を反映させるため、Datadog Agentを再起動します。

    - **Linuxの場合**:

        ```bash
        sudo systemctl restart datadog-agent
        ```

    - **Windowsの場合**:

        サービスマネージャから`DatadogAgent`サービスを再起動します。

3. **変更の確認**

    Datadogのダッシュボードでホスト名が更新されていることを確認します。また、Slack通知でもインスタンス名が表示されていることを確認します。

## まとめ

Datadog Agentの設定ファイルで`hostname`を指定し、Agentを再起動することで、Slack通知に表示されるホスト名をインスタンス名に変更することができました。同じ問題でお困りの方の参考になれば幸いです。

## 参考資料

- [How does Datadog determine the Agent hostname?](https://docs.datadoghq.com/agent/faq/how-datadog-agent-determines-the-hostname/)
distrolessイメージ vs 一般的なDockerイメージ - セキュリティリスクと実例から学ぶ


distrolessイメージと一般的なDockerイメージの違いを、実際のセキュリティインシデントを交えて解説します。

## 一般的なDockerイメージ

- UbuntuやAlpineなど、フルのLinuxディストリビューションをベースにしています。
- パッケージマネージャー、シェル、各種ユーティリティツールが含まれています。
- 開発やデバッグが容易で、柔軟性が高いのが特徴です。

## distrolessイメージ

- アプリケーションと最小限のランタイム環境のみを含む超軽量イメージです。
- パッケージマネージャーやシェルなどの一般的なツールは省略されています。
- セキュリティと効率性を重視しています。
- Chainguard社が提供するdistrolessイメージは、さらにセキュリティを強化し、最適化されています。

## 一般的なDockerイメージが標的になった例

### 事例1: 2018年のTesla社へのサイバー攻撃

攻撃者は、パスワードで保護されていないKubernetesコンソールを発見。
悪意のあるコンテナをデプロイし、Teslaの社内システムに侵入。
結果、機密データが流出し、会社のクラウドリソースで暗号通貨のマイニングが行われました。
この事例から、不要なツールや権限を持つコンテナが攻撃者に悪用される危険性が分かります。

参考：https://japan.cnet.com/article/35114995/

### 事例2: Alpine Linux Dockerイメージの脆弱性

Alpine Linux の公式 Docker イメージに、約3年間にわたって空のルートパスワードが設定されていたことが発覚。
この脆弱性により、攻撃者がコンテナ内で容易に root 権限を取得できる可能性がありました。
影響を受けたバージョンは、Alpine Linux 3.3から3.9までの全てのオフィシャルイメージ。
この脆弱性は、数百万のコンテナに影響を与えた可能性があります。
この事例は、広く使用されているベースイメージでさえもセキュリティ上の問題を含む可能性があることが判明しました。

参考：https://jp.tenable.com/blog/cve-2019-5021-hard-coded-null-root-password-found-in-alpine-linux-docker-images

### 事例3: 2021年のAzure Container Instancesへの侵入（Unit 42による発見）

Palo Alto NetworksのUnit 42チームが、Microsoft Azure Container Instancesの脆弱性を発見。
攻撃者は、他のユーザーのコンテナにアクセスし、機密情報を盗む可能性がありました。
この脆弱性は「Azurescape」と名付けられ、コンテナエスケープの深刻な例となりました。
この事例は、クラウドプロバイダーが管理するコンテナ環境でも重大な脆弱性が存在し得ることを示しています。適切な分離とセキュリティ対策の重要性が再認識されました。

参考：https://unit42.paloaltonetworks.jp/azure-container-instances/

## 両者の比較

### セキュリティ

- 一般的なDockerイメージ：多くのツールが含まれ、攻撃対象が多くなります。
- distrolessイメージ：最小限の構成で、攻撃対象が大幅に減少します。

### イメージサイズ

- 一般的なDockerイメージ：数百MB〜1GB以上
- distrolessイメージ：数十MB程度

### メンテナンス

- 一般的なDockerイメージ：多くのパッケージの更新が必要
- distrolessイメージ：更新頻度が低く、管理が容易

### 開発とデバッグ

- 一般的なDockerイメージ：標準ツールで開発やデバッグが容易
- distrolessイメージ：特殊な方法が必要で、デバッグが難しい場合も

## 結論

distrolessイメージはセキュリティを重視する本番環境に適しており、一般的なDockerイメージは開発環境や柔軟性が必要な場合に適しています。
セキュリティインシデントから学んだように、必要最小限の構成でコンテナを運用することが、リスクの軽減につながります。プロジェクトの要件に応じて、適切なイメージタイプを選択しましょう。
Chainguard社のdistrolessイメージは、この分野でのリーダー的存在であり、高度なセキュリティと最適化を提供しています。セキュリティを重視するプロジェクトでは、Chainguardのイメージを検討する価値があります。
[postgres]docker内のDBをバックアップ・リストアする


## 全DBをbackup

```
sudo docker compose exec ${dockerのホスト名} pg_dumpall --clean --username ${user名} > /tmp/${ファイル名}.sql
```

## 特定のDBのみbackup

```
sudo docker compose exec ${dockerのホスト名} pg_dump ${DB名} --username ${user名} > /tmp/${ファイル名}.sql
```

## restore
```
sudo cat /tmp/${ファイル名}.sql | docker-compose exec -T ${dockerのホスト名} psql --username ${user名}
```
【上級編】bashシェルスクリプト 裏技 4選


bashシェルスクリプトには、効率的で強力なコードを書くための様々な裏技があります。本記事では、知られざる4つの裏技を紹介します。これらのテクニックを使いこなせば、より柔軟で堅牢なスクリプトを作成できるでしょう。

## 1. プロセス置換

プロセス置換を使うと、コマンドの出力を一時ファイルを作らずに他のコマンドの入力として使えます。

従来の方法：

```
ls dir1 > temp1.txt
ls dir2 > temp2.txt
diff temp1.txt temp2.txt
rm temp1.txt temp2.txt
```

プロセス置換を使用：

```
diff <(ls dir1) <(ls dir2)
```

プロセス置換を使うと、一時ファイルの作成と削除が不要になり、コードがシンプルになります。また、ディスクI/Oを減らせるので、特に大量のデータを扱う場合にパフォーマンスが向上します。

## 2. ヒアドキュメント

ヒアドキュメントを使えば、複数行のテキストを簡単にコマンドの入力として扱えます。

例：

```
cat <<EOF | sed 's/bash/zsh/g' > output.txt
This is a bash script.
We love bash!
EOF
```

このスクリプトは、テキスト内の「bash」を「zsh」に置換してoutput.txtに保存します。

## 3. 連想配列の活用

bashの配列と連想配列を活用すると、複雑なデータ構造を扱えるようになります。

配列の例：

```
fruits=("apple" "banana" "cherry")
echo ${fruits[1]}  # banana
```

連想配列の例：

```
declare -A colors
colors[apple]="red"
colors[banana]="yellow"
echo ${colors[apple]}  # red
```

## 4. トラップを使った特定シグナルの処理

トラップ機能を使うと、特定のシグナルに対して処理を指定できます。これにより、スクリプトの終了時やユーザーの割り込み時など、特定の状況下で適切な処理を行うことができます。

以下は、SIGINTシグナル（Ctrl+Cによる中断）とEXITイベント（スクリプトの終了）を処理する完全なスクリプト例です：

```
#!/bin/bash

# 一時ファイルの作成
touch tempfile.txt

# クリーンアップ関数の定義
cleanup() {
    echo "Cleaning up..."
    rm -f tempfile.txt
}

# SIGINT（Ctrl+C）のハンドラ
handle_sigint() {
    echo "Caught SIGINT (Ctrl+C)"
    cleanup
    exit 1
}

# EXITイベントとSIGINTシグナルにトラップを設定
trap cleanup EXIT
trap handle_sigint SIGINT

# メインの処理
echo "Script is running. Press Ctrl+C to interrupt."
count=0
while [ $count -lt 10 ]; do
    echo "Working... $count"
    sleep 1
    count=$((count + 1))
done

echo "Script completed normally."
```

このスクリプトの特徴：

1. `cleanup` 関数: 一時ファイルを削除するクリーンアップ処理を定義しています。

2. `handle_sigint` 関数: Ctrl+Cが押された時の処理を定義しています。クリーンアップを実行してから終了します。

3. `trap cleanup EXIT`: スクリプトが終了する際（正常終了、エラー終了問わず）に `cleanup` 関数を実行します。

4. `trap handle_sigint SIGINT`: Ctrl+Cが押された時に `handle_sigint` 関数を実行します。

5. メインの処理: 10秒間カウントアップしながら処理を行います。この間にCtrl+Cを押すと、`handle_sigint` 関数が呼び出されます。

このスクリプトを実行すると、以下のような動作が期待できます：

- 正常に完了した場合: 10秒後に処理が終了し、`cleanup` 関数が呼び出されます。
- Ctrl+Cで中断した場合: `handle_sigint` 関数が呼び出され、その後 `cleanup` 関数が実行されます。
- 他の方法で終了した場合（例：`kill`コマンド）: `cleanup` 関数のみが実行されます。

トラップを使用することで、スクリプトの終了時や特定のシグナルを受信した際の動作を細かく制御できます。これにより、リソースの適切な管理や、予期せぬ終了時の適切な対応が可能になります。

以上の4つの裏技を使いこなせば、より柔軟なbashスクリプトを作成できるでしょう。特に、プロセス置換とトラップの使用は、コードの簡潔さと堅牢性を大きく向上させます。ぜひ実際に試してみてください。
【AWS】CloudFrontをterraformで作るためus-east-01で管理する


CloudFrontは`us-east-1`リージョンにリソースを作成する必要があります。そのため、別リージョンで作成したリソースをCloudFrontで利用する場合、以下のようにプロバイダとモジュールを設定します。

以下のコードでは、CloudFrontのリソースは`us-east-1`で作成し、S3バケットなどのリソースは`ap-northeast-1`で作成する例を示しています。

```
# プロバイダ設定
provider "aws" {
  region = "ap-northeast-1"
}

provider "aws" {
  alias  = "us_east_1"
  region = "us-east-1"
}

# S3バケット (ap-northeast-1 リージョン)
resource "aws_s3_bucket" "example_bucket" {
  bucket = "example-bucket-ap-northeast-1"
  acl    = "private"
}

# CloudFront設定 (us-east-1 リージョン)
resource "aws_cloudfront_distribution" "example_distribution" {
  provider = aws.us_east_1

  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"

  origin {
    domain_name = aws_s3_bucket.example_bucket.bucket_domain_name
    origin_id   = "example-origin"

    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.example.iam_arn
    }
  }

  default_cache_behavior {
    target_origin_id       = "example-origin"
    viewer_protocol_policy = "redirect-to-https"

    allowed_methods  = ["GET", "HEAD"]
    cached_methods   = ["GET", "HEAD"]
    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

    min_ttl     = 0
    default_ttl = 3600
    max_ttl     = 86400
  }

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate.us_east_1_cert.arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }

  tags = {
    Environment = "example"
  }
}

# Origin Access Identity (us-east-1)
resource "aws_cloudfront_origin_access_identity" "example" {
  provider    = aws.us_east_1
  comment     = "Example OAI for CloudFront"
}

# ACM証明書 (us-east-1)
resource "aws_acm_certificate" "us_east_1_cert" {
  provider          = aws.us_east_1
  domain_name       = "*.example.com"
  validation_method = "DNS"

  tags = {
    Environment = "example"
  }
}
```

## ポイント
1. **プロバイダの指定**
   - `aws.us_east_1`をCloudFrontやACM証明書など`us-east-1`で作成する必要があるリソースに使用。
   - デフォルトの`aws`プロバイダは`ap-northeast-1`で使用。

2. **リソース間の連携**
   - S3バケットなど`ap-northeast-1`で作成したリソースの情報をCloudFrontに渡す。
   - 例: `aws_s3_bucket.example_bucket.bucket_domain_name`。
【2024年最新】EC2にSSM agentをinstallしてAWSコンソールからアクセス


## 概要
[公式の手順](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/agent-install-al2.html)で SSM agentをinstallしてもフリートマネージャーから認識されないのでひと手間加える必要がある

## 前提
- OSはAmazon linux
- セキュリティグループは
  - インバウンド: SSHアクセスするIPからSSH許可
  - アウトバウンド: 全て許可

## 手順

1. EC2 に SSH 接続
```
ssh -i ${秘密鍵のパス} ec2-user@${public IP}
```

2. [公式の手順](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/agent-install-al2.html)で SSM agent install

### x86_64

```
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_amd64/amazon-ssm-agent.rpm
```
### ARM64

```
sudo yum install -y https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/linux_arm64/amazon-ssm-agent.rpm
```

3. EC2 に 割り当てるIAMロールを作成するIAMコンソールで以下のロールを作成する

| **項目** | **値** |
| ---- | ---- |
| 信頼されたエンティティタイプ | AWS のサービス |
| ユースケース | EC2 Role for AWS Systems Manager |
| 許可ポリシー | AmazonSSMManagedInstanceCore |
| ロール名 | ${任意のロール名} |


4. EC2 に作成したロールを割り当てる

```
1. EC2サービスに移動します。
2. 左側のメニューから「インスタンス」を選択します。
3. 確認したいEC2インスタンスを選択します。
4. 下部のペインで「セキュリティ」タブを選択します。
5. 「IAMロール」の項目を確認します。ここに割り当てられているロールの名前が表示されます。
```

5. SSM フリートマネージャーからアクセス出来る事を確認する

## 参考
公式の別のところに書いてあった
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/setup-instance-permissions.html
【AWS】Terraformの公式AWS VPCモジュールを使用してサブネットを管理


## はじめに

[この記事](https://zukkie.link/%e3%80%90aws%e3%80%91terraform%e3%81%a7subnet%e3%82%92%e3%83%a2%e3%82%b8%e3%83%a5%e3%83%bc%e3%83%ab%e5%8c%96%e3%81%99%e3%82%8b/#google_vignette)でsubnetをモジュール化していたが公式のモジュールがあるのでそれを使ってみる


## 手順

1. モジュールの宣言:
  main.tfファイルに以下のコードを追加します。

```
module "vpc" {
 source  = "terraform-aws-modules/vpc/aws"
 version = "~> 5.0"

 name = "${var.environment}-vpc"
 cidr = var.vpc_cidr

 azs             = var.availability_zones
 private_subnets = [for i in range(3) : cidrsubnet(var.vpc_cidr, 8, i)]
 public_subnets  = [cidrsubnet(var.vpc_cidr, 8, 3)]

 enable_nat_gateway = true
 single_nat_gateway = true

 enable_dns_hostnames = true
 enable_dns_support   = true

 tags = {
   Environment = var.environment
 }
}
```

このコードでは以下の設定を行っています：

- `source`: Terraform Registryから公式VPCモジュールを参照します。
- `version`: モジュールのバージョンを指定します（ここでは5.x系の最新版）。
- `name`: VPCの名前を環境変数を用いて動的に設定します。
- `cidr`: VPCのCIDRブロックを指定します。
- `azs`: 使用するアベイラビリティーゾーンのリストを指定します。
- `private_subnets`: プライベートサブネットのCIDRブロックを動的に生成します。`cidrsubnet`関数を使用して、VPCのCIDRブロックから自動的にサブネットを作成します。
- `public_subnets`: パブリックサブネットのCIDRブロックを同様に生成します。
- `enable_nat_gateway`: NATゲートウェイを有効にします。
- `single_nat_gateway`: コスト最適化のため、単一のNATゲートウェイを使用します。
- `enable_dns_hostnames`と`enable_dns_support`: VPC内のDNS設定を有効にします。
- `tags`: リソースにタグを付与します。

2. 変数の定義:
  variables.tfファイルに必要な変数を定義します。

```
variable "environment" {
 description = "The environment (e.g., dev, staging, prod)"
 type        = string
}

variable "vpc_cidr" {
 description = "The CIDR block for the VPC"
 type        = string
}

variable "availability_zones" {
 description = "List of availability zones"
 type        = list(string)
}
```

これらの変数定義により：

- `environment`: デプロイ環境を指定できます（例：dev, staging, prod）。
- `vpc_cidr`: VPCのCIDRブロックを柔軟に設定できます。
- `availability_zones`: 使用するアベイラビリティーゾーンをリストで指定できます。

3. サブネットの参照:
  他のリソースからサブネットを参照する際は、以下のように記述します。

```
resource "aws_instance" "example" {
 subnet_id = module.vpc.public_subnets[0]
 # その他の設定...
}
```

このコードでは：

- `module.vpc.public_subnets[0]`: VPCモジュールが作成したパブリックサブネットの最初の要素（インデックス0）を参照しています。これにより、EC2インスタンスを特定のサブネットにデプロイできます。

## 公式モジュールを使用する場合のメリット

1. **簡潔性**: 複雑なVPCとサブネット構成を数行のコードで実現できます。
2. **ベストプラクティス**: AWSのベストプラクティスに基づいた設定が自動的に適用されます。
3. **保守性**: モジュールのバージョンアップにより、最新の機能や修正を容易に取り入れられます。
4. **一貫性**: 異なる環境間で一貫したネットワーク構成を維持しやすくなります。
5. **柔軟性**: モジュールのパラメータを調整することで、様々な要件に対応できます。

## 公式モジュールを使用する場合のデメリット

1. **カスタマイズの制限**: 非常に特殊な要件がある場合、モジュールでは対応できないことがあります。
2. **ブラックボックス化**: 内部の動作が見えにくくなり、トラブルシューティングが難しくなる可能性があります。
3. **バージョン管理**: モジュールのバージョン更新に伴う互換性の問題に注意が必要です。

## 結論

Terraformの公式AWS VPCモジュールは、多くの場合において、VPCとサブネットの管理を大幅に簡素化し、開発効率を向上させます。自動的なサブネット計算やベストプラクティスの適用により、安全で効率的なネットワーク設計が可能になります。
【AWS】AWS WAFでSQLインジェクションを防ぐ具体的な設定方法


## きっかけ
### OWASP ZAPでSQLインジェクションの脆弱性を検知
- **OWASP ZAP**（Zed Attack Proxy）を使用して、対象のWebアプリケーションに対して自動スキャンを実施。
- SQLインジェクションの脆弱性が検知されたことを確認。

### 対象ドメインにSQLインジェクションを試す
- 検知された脆弱性を確認するため、対象ドメインに対して手動でSQLインジェクションを試行。
  - 例: `https://example.com/login?username=admin&password=password' OR '1'='1`
- SQLインジェクションが成功し、不正なアクセスが可能であることを確認。

## 設定手順
### AWS Management Consoleにログイン
- [AWS Management Console](https://aws.amazon.com/console/)にログインし、**WAF & Shield**サービスに移動します。

### Web ACLの作成
1. **Web ACLs**を選択し、**Create web ACL**をクリックします。
2. **Name**と**Description**を入力します。
   - 例: Name: `SQLi-Protection-WebACL`, Description: `Web ACL to protect against SQL injection`
3. **Resource type**で保護対象のリソースタイプを選択します。
   - **Global resources (CloudFront Distributions)**: CloudFrontを使用している場合。
   - **Regional resources (Application Load Balancers, API Gatewayなど)**: ALBやAPI Gatewayを使用している場合。
4. **Region**を選択します（Regional resourcesの場合）。
5. **Next**をクリックします。

### ルールとルールグループの追加
1. **Add rules**をクリックし、**Add managed rule groups**を選択します。
2. **AWSManagedRulesSQLiRuleSet**を選択します。
   - このルールグループは、SQLインジェクション攻撃を防ぐためのマネージドルールを提供します。
3. **Add rule**をクリックしてルールを追加します。
4. **Next**をクリックします。

### ルールの優先順位を設定
1. 追加したルールの優先順位を確認します。
   - 必要に応じて、ルールの順序を調整します。
2. **Next**をクリックします。

### メトリクスの設定
1. **Configure metrics**で、CloudWatchメトリクスを有効にするかどうかを選択します。
   - メトリクスを有効にすると、WAFの動作状況をモニタリングできます。
2. **Next**をクリックします。

### Web ACLの確認と作成
1. 設定内容を確認します。
2. **Create web ACL**をクリックして、Web ACLを作成します。

### リソースへの関連付け
1. 作成したWeb ACLを、保護したいリソース（CloudFrontディストリビューションまたはALB）に関連付けます。
   - **Associated AWS resources**セクションで、関連付けるリソースを選択します。

### 動作確認
1. **SQLインジェクションのブロック確認**:
   - SQLインジェクションを試行し、AWS WAFがリクエストをブロックすることを確認します。
   - 例: `https://example.com/login?username=admin&password=password' OR '1'='1`
2. **通常のリクエストの通過確認**:
   - 通常のリクエストが通過し、アプリケーションが正常に動作することを確認します。

### ログの設定（オプション）
1. **Logging and metrics**セクションで、ログの設定を行います。
   - ログをCloudWatch LogsやS3に出力し、後で分析できるようにします。

## まとめ
- AWS WAFを使用して、SQLインジェクションを防ぐためのルールを設定。
- マネージドルールグループを活用し、簡単にセキュリティを強化。
- ログとメトリクスを設定し、WAFの動作状況をモニタリング。
【AWS】amplifyでreactアプリをデプロイしたが404エラー


## 概要
掲題の通りamplifyを使ってreactをデプロイしたが実際にアクセスすると404エラーになる。

## エラーが再現する手順
1. gihubリポジトリを作成
2. 作ったリポジトリをgit clone
3. cloneしたリポジトリ内で以下のコマンドを実行
```
npx create-react-app amplifyapp
```
4. git add .
5. git commit -m "コメント"
6. git push origin main
7. AWSコンソールからamplifyを開いてgithubからデプロイ

その際の`amplify.yml`

```
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - cd amplifyapp
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*
```

## 原因
`baseDirectory: build` となっており`amplifyapp/build`と階層構造で指定してなくてbuildしたリソースが使われてなかった。

修正後の`amplify.yml`
```
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - cd amplifyapp
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: amplifyapp/build
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*
```

これでURLからreactアプリが見れるようになった。
Windows環境でOh My Poshをインストール・テーマ切り替え手順


## Oh My Poshのインストール

まずは、Wingetを使ってOh My Poshをインストールします。

```
winget install JanDeDobbeleer.OhMyPosh -s winget
```

## PowerShellのプロファイルに設定を追加

PowerShellのプロファイルファイルに、Oh My Poshの初期化コードを追加して、PowerShellを起動するたびにOh My Poshが有効になるようにします。

### 手順

1. プロファイルファイルを編集します。

   ```
   notepad $PROFILE
   ```

2. ファイルに以下のコードを追加して、テーマ`paradox`を使用するように設定します。

   ```
   Import-Module posh-git
   oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\paradox.omp.json" | Invoke-Expression
   ```

3. 保存して閉じ、PowerShellを再起動します。

## テーマの確認と切り替え

### 利用可能なテーマの一覧表示

現在インストールされているOh My Poshのテーマを確認するには、以下のコマンドを実行します。

```
Get-PoshThemes
```

### テーマのプレビュー

特定のテーマを一時的にプレビューするには、以下のコマンドを使用します。`<theme-name>`にはプレビューしたいテーマ名を入力します。

```
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\<theme-name>.omp.json" | Invoke-Expression
```

### テーマの切り替えを永続化

気に入ったテーマを永続的に使用するためには、プロファイルファイルにそのテーマを設定します。

1. プロファイルファイルを再度開きます。

   ```
   notepad $PROFILE
   ```

2. 既存のテーマ設定を新しいテーマに変更します。例えば、`jandedobbeleer`に変更する場合:

   ```
   oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression
   ```

3. 保存してPowerShellを再起動します。

## フォントの設定

Oh My Poshのシンボルを正しく表示するためには、対応するフォント（例：Nerd Fonts）をインストールし、VSCodeやWindows Terminalに設定する必要があります。フォントの設定手順については、以下のリンクから詳細を確認してください。

- [Nerd Fonts](https://www.nerdfonts.com/)

---

これで、Oh My Poshをインストールして、テーマを切り替える手順は完了です。自分に合ったテーマを見つけて、ターミナル環境をカスタマイズしましょう！
優秀なエンジニアの価値が1000倍である根拠


## 導入

「優秀なエンジニアの価値が1000倍である」という話をしていきます。
これは単なる誇張ではなく、実際のデータや具体例に基づいた事実だと私は思います。では、なぜそう言えるのか、詳しく見ていきましょう。

## 勉強時間

まず、勉強時間から見ていきます。

- 勉強には2種類あります：実務で役立つ勉強と役立たない勉強
- 一般の日本人の平均勉強時間は1日たった6分
- 優秀なエンジニアは仕事を1日8時間（480分）実施しそのほとんどが実務に直結する
- これは一般人の80倍の勉強量

80倍もの実務に役立つ勉強をしている人が、一般人と同じ価値しかないわけがありません。この時点で、すでに大きな差が生まれているんです。

## イノベーション能力

優秀なエンジニアは新しいアイデアや技術を生み出す力があります。

- 例：業務効率化ツールの開発
  - 開発コスト：100時間
  - 年間の削減効果：1000時間

さらに、そのツールが他社にも販売可能なら、金銭的な価値を生み出す可能性もあります。

## チームへの影響

そんな新しいアイデアや技術を持つ優秀なエンジニアがいると、周囲のスキルも向上させられます。
老子の言葉で「魚を与えるのではなく釣り方を教えよ」という言葉がある通り技術を教える事が出来ればその価値は絶大なものになります。
具体的な例だと
- コードの管理をエクセルやスプレッドシートで行っていたレガシーな案件にgitを導入し、後進育成まで出来るエンジニアが参画する
- インフラリソースをコードで管理できなかった現場でterraformの経験が豊富でコード管理に加えてCI/CDを実現出来るエンジニアが参画

どちらも
- 工数削減
- ミスの減少
- メンバーのスキルアップ
の恩恵を享受出来ます。

このような優秀なエンジニアの影響は、数字でも明確に表れます：

- 10人チームに1人の優秀なエンジニアが加わると：
  - チーム全体の生産性が30%以上向上
  - 年間1億円の案件で3000万円以上の追加価値を創出

結果として：
- プロジェクトの成功率が向上
- チームメンバーの離職率が減少

これらの効果を金銭的価値に換算すると、優秀なエンジニア1人の影響力は年間で数千万円から1億円以上にも及ぶことがあります。

つまり、優秀なエンジニアは単に個人の生産性が高いだけでなく、チーム全体を底上げし、組織全体の価値を何倍にも高める力を持っているのです。この影響力こそが、優秀なエンジニアの価値が1000倍以上になる大きな要因の一つと言えるでしょう。

## リスク管理

最近は生成AIの台頭でプログラミングのハードルが下がってる一方でセキュリティの知識を持ったストッパー的な役割が出来るエンジニアの価値が高くなると予想しています。
優秀なエンジニアは潜在的な問題を事前に察知し、対策を立てます。

- 例：セキュリティリスク
  - 平均的なエンジニア：年間5件の脆弱性を見逃す
  - 優秀なエンジニア：全ての脆弱性を事前に発見・対策
- 1件のセキュリティ事故で平均5000万円の損失
- 優秀なエンジニア1人で年間2.5億円のリスクを回避可能

## まとめ

これらを総合すると、優秀なエンジニアの価値は容易に1000倍に到達します。さらに、長期的な影響や波及効果を考えると、その価値は計り知れません。
私自身、元は運用監視とエンジニアと呼べない最底辺の職についていましたのでそれこそ周りにマイナスの影響を与える人や仕事を全然しない癖に謎技術でマウント取ってくる人に遭遇したりもしましたが現在は平均以上のエンジニアになれてます。

優秀なエンジニアへの投資は、企業にとって最も賢明な選択の一つと言えるでしょう。共に自己研鑽を続け、優秀なエンジニアを目指しましょう。

以上、優秀なエンジニアの価値が1000倍である根拠についてでした。
【AWS】terraform で EC2を作成しようとしたところ InvalidGroup.NotFound が出る


## 概要

以下のterraformでEC2を作ろうとしたところSGグループが見つからない旨のエラーが出現

## tfファイル
```
resource "aws_instance" "dev_test_01" {
  ami                  = "ami-"
  availability_zone    = "ap-northeast-1a"
  iam_instance_profile = "SSM_access_for_EC2"
  instance_type        = "t2.micro"
  key_name             = "dev-test-01"
  private_ip           = "192.168.10.1"
  subnet_id            = "subnet-"
  security_groups = ["ec2-1", "ec2-2"]
  tags = {
    Name = "dev-test-01"
  }
  vpc_security_group_ids = ["sg-1", "sg-2", "sg-3"]
  root_block_device {
    volume_size = 8
    volume_type = "gp3"
  }
}
```

## エラーメッセージ
```
Error: creating EC2 Instance: operation error EC2: RunInstances, https response error StatusCode: 400, RequestID: , api error InvalidGroup.NotFound: The security group 'ec2-1' does not exist in VPC 'vpc-'
```

### 解決方法

`security_groups`を削除する

### 解決方法の理由

`security_groups`属性はEC2-Classicネットワークで使用されるもので、VPC内のインスタンスには適していません。一方、`vpc_security_group_ids`はVPC内のセキュリティグループを直接指定するために使用されます。VPC環境では、セキュリティグループはVPCに紐づいているため、`vpc_security_group_ids`を使用することで、正しいVPC内のセキュリティグループを確実に指定できます。