AWSでec2-linux使い始め設定

linuxのホスト作る時は、amazonlinuxかubuntu使ってる。

redhatでホスト作る場面は今のところないけど、試験作成ではalmalinuxで使う。

amazonlinuxはdnfとか使えるから、redhat系を常用してる人には優しいかも。

使い始めの設定

ec2-linuxを使い始めるための設定でいっつもやってる内容のメモ。

ホスト名を変更設定

名前が勝手につくからaws-ec2のホスト名変える。

AWS EC2 - Amazon Linux2 のホスト名を永久的に変える方法 #AmazonLinux2 - Qiita

qiita.com

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

セキュリティグループで歯止めするからファイアウォールは使わん。

もし設定されてたら停止かアンインストール。

AlmaLinux9.2でfirewalldやselinuxを停止する #SELinux - Qiita

qiita.com

タイムゾーンを日本に変更

毎回ググるけどosによってどれかをやってる。

<title data-next-head="">[Linux(Ubuntu)]タイムゾーンを日本時間にする5つの方法まとめ

zenn.dev

時刻同期サーバを設定

昔はntpd使ってた。

Linuxサーバー時刻を（現在時刻と）合わせる #CentOS - Qiita

qiita.com

最近はchrony使う。

NTPによる時刻合わせ - Linux技術者認定 LinuC | LPI-Japan

linuc.org

aws内部にntpサーバあるから解説にある設定そのまま実施。amazonlinuxやったら最初から設定できてたはず。

EC2 インスタンスのタイムリファレンスを、ローカル Amazon Time Sync Service を使用するように設定します。 - Amazon Elastic Compute Cloud

docs.aws.amazon.com

ルート以外のドライブあるときはフォーマットしてマウント

フォーマットして使う。windowsホストから見えるようにしとくと楽になるからsambaで共有してること多い。

AWSでEBSをマウント | ギャバンITサービス

gavann-it.com

ec2ホストに権限つける

IAMでロール作って、cloudwatchに書き込みする権限をつける。

ec2-linux

aws cliインストール

インストールしとく。

docs.aws.amazon.com

CloudWatchAgentインストール

こっちもインストールしとく。そういえばubuntuで入れたことないな。

CloudWatch エージェントパッケージをダウンロードする - Amazon CloudWatch

docs.aws.amazon.com

CloudWatchログ保管設定

amazonlinux2023でやったこと。

エージェントをインストールする。

sudo dnf install amazon-cloudwatch-agent

設定ファイルのconfig.jsonを作る。

CloudWatch エージェント設定ファイルを手動で作成または編集する - Amazon CloudWatch

docs.aws.amazon.com

エージェントの設定のため、ウィザード使う。

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

設定けっこう長い。

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128


[gvisadmin@ip-172-16-20-137 ~]$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
================================================================
= Welcome to the Amazon CloudWatch Agent Configuration Manager =
=                                                              =
= CloudWatch Agent allows you to collect metrics and logs from =
= your host and send them to CloudWatch. Additional CloudWatch =
= charges may apply.                                           =
================================================================
On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:
1 ⭐️linuxなので１を選択
Trying to fetch the default region based on ec2 metadata...
2023/12/12 06:36:33 I! imds retry client will retry 1 times
Are you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1 ⭐️ec2なので１を選択
Which user are you planning to run the agent?
1. root
2. cwagent
3. others
default choice: [1]:
1 ⭐️実行ユーザはrootで１を選択
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
2 ⭐️cloudwatchに飛ばすだけでstatsDデーモン不要のため２を選択
Do you want to monitor metrics from CollectD? WARNING: CollectD must be installed or the Agent will fail to start
1. yes
2. no
default choice: [1]:
2 ⭐️cloudwatchに飛ばすだけなので不要のため２を選択
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
2 ⭐️cloudwatchに飛ばすだけでメトリクス不要なので２を選択
Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
1. yes
2. no
default choice: [2]:
2 ⭐️設定ファイルはこれから作るので２を選択
Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
1
Log file path:
/var/log/audit/audit.log ⭐️OSのログファイルを指定
Log group name:
default choice: [audit.log]
bastion-/var/log/audit/audit.log ⭐️awsコンソールで表示するグループ名を指定
Log stream name:
default choice: [{instance_id}]
bastion-/var/log/audit/audit.log ⭐️awsコンソールで表示するストリーム名を指定
Log Group Retention in days
1. -1
2. 1
3. 3
4. 5
5. 7
6. 14
7. 30
8. 60
9. 90
10. 120
11. 150
12. 180
13. 365
14. 400
15. 545
16. 731
17. 1096
18. 1827
19. 2192
20. 2557
21. 2922
22. 3288
23. 3653
default choice: [1]:
1 ⭐️無期限として「１. -1」を指定
Do you want to specify any additional log files to monitor?
1. yes
2. no
default choice: [1]:
2 ⭐️他に指定ログないので２を指定
Do you want the CloudWatch agent to also retrieve X-ray traces?
1. yes
2. no
default choice: [1]:
2 ⭐️X-ray traceは不要なので２を指定
Existing config JSON identified and copied to:  /opt/aws/amazon-cloudwatch-agent/etc/backup-configs
Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully. ⭐️ここに保存されるだけでまだ使えん
Current config as follows:
{
        "agent": {
                "run_as_user": "root"
        },
        "logs": {
                "logs_collected": {
                        "files": {
                                "collect_list": [
                                        {
                                                "file_path": "/var/log/audit/audit.log",
                                                "log_group_name": "bastion-/var/log/audit/audit.log",
                                                "log_stream_name": "bastion-/var/log/audit/audit.log",
                                                "retention_in_days": -1
                                        }
                                ]
                        }
                }
        }
}
Please check the above content of the config.
The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json.
Edit it manually if needed.
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2　⭐️ssmは不要なので２を指定
Program exits now.
[gvisadmin@ip-172-16-20-137 ~]$

できたファイルを設置先にコピーする。

1
2
3
4
5
6
7


[gvisadmin@ip-172-16-20-137 ~]$ sudo cp -p /opt/aws/amazon-cloudwatch-agent/bin/config.json /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
[sudo] password for gvisadmin:
[gvisadmin@ip-172-16-20-137 ~]$
:(中略)
[root@ip-172-16-20-137 ~]# ls -l /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
-rw-r--r--. 1 root root 342 Dec 12 06:41 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
[root@ip-172-16-20-137 ~]#

CloudWatchエージェントを起動

エージェントのサービスを有効にして起動する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


[root@ip-172-16-20-137 audit]# systemctl status amazon-cloudwatch-agent.service
○ amazon-cloudwatch-agent.service - Amazon CloudWatch Agent
     Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; disabled; preset: disabled)
     Active: inactive (dead) ⭐️最初は動いてへん
[root@ip-172-16-20-137 audit]#

[root@ip-172-16-20-137 audit]# systemctl enable amazon-cloudwatch-agent.service ⭐️サービスを有効にしとく
Created symlink /etc/systemd/system/multi-user.target.wants/amazon-cloudwatch-agent.service → /etc/systemd/system/amazon-cloudwatch-agent.service.
[root@ip-172-16-20-137 audit]# systemctl start amazon-cloudwatch-agent ⭐️サービス起動
[root@ip-172-16-20-137 audit]# systemctl status amazon-cloudwatch-agent.service
● amazon-cloudwatch-agent.service - Amazon CloudWatch Agent
     Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; enabled; preset: disabled)
     Active: active (running) since Tue 2023-12-12 06:55:01 UTC; 1s ago ⭐️動いた
   Main PID: 469197 (amazon-cloudwat)
      Tasks: 7 (limit: 1061)
     Memory: 106.8M
        CPU: 267ms
     CGroup: /system.slice/amazon-cloudwatch-agent.service
             mq469197 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -config /opt/aws/amazon-cloudwatch-agent/etc/a>

Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal systemd[1]: Started amazon-cloudwatch-agent.service - Amazon Clo>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: D! [EC2] Found active net>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: 2023/12/12 06:55:01 I! im>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: I! Detected the instance >
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: 2023/12/12 06:55:01 Readi>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: 2023/12/12 06:55:01 I! Va>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: I! Detecting run_as_user.>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: I! Trying to detect regio>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469203]: 2023/12/12 06:55:01 Confi>
Dec 12 06:55:01 ip-172-16-20-137.ap-northeast-1.compute.internal start-amazon-cloudwatch-agent[469197]: I! Detecting run_as_user.>

ログ出とる。

ec2-linux

CloudWatchログの保管設定

ec2-windowsでもやったけど、保管期間設定しとかんと溜まり続ける。

aws

3年ぐらいとか設定でええ。

aws

CloudWatchメトリクス取得設定

踏み台として稼働させることのほうが多いから、メトリクス設定はあんまりやらん。

設定したいときは、さっきのエージェント設定ウィザードの質問でyesを答える。

Do you want to monitor any host metrics? e.g. CPU, memory, etc.

そうやなければ、作ったconfig.jsonに ec2-windowsで使った設定ファイルをマージして使えばええ。

EFSマウント

EFS はフルマネージドのファイルシステムなんやて。

たまに使う。

ebs/s3/efsって性質違うけど、できること似てるから混同するなぁ。

EFSをec2-linuxホストにマウントできる。長いコマンドラインやけど、EFSのコンソール画面で接続文字列提供してくれる。

mount -t nfs4 -o accesspoint=fsap-xxx,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=100,retrans=2,noresvport fs-xxx.efs.ap-northeast-1.amazonaws.com:/ /GVIS-efs

つないでdfしたらこう見える。サイズが8.0Eって書いてある。

ec2-linux

初めて見たけど、8エクサバイトって、800京バイト=8000ペタバイト=800万テラバイトやな。

サイズどのぐらい

800万テラってどのぐらいやねん。8TBのディスクが100万個ってイメージ湧きにくい。

ちょっとアホな想像。

buffaloの外付け8TB-HDD が税込定価で１個５万円ほど。厚さ39mm。

単純計算で500億円分の回転ディスクがあるってことか。

１箇所に置いてるわけないやろけど、かさばるやろなぁ。電力も放熱もツライやろなぁ。

厚さ39mmを100万個積み上げたとしたら、3900万mm=390万cm=39000m=39km、大阪からやったら阪神高速の湾岸線通ってポートアイランドまで行ける距離。

実容量で800万テラバイトやから、冗長ディスク含んだらもっといっぱいディスクあることになるやんなぁ。

ハードディスクコントローラとかどうしてるんやろ。

8TBのディスク故障率が1年で1%やとしても、100万の1%=1万÷365=27.397ぐらいやから毎日27〜28個ずつ壊れてくんか。

大阪からポートアイランドまでに敷き詰めたディスクを、毎日27〜28個ずつ特定して交換するなんてゾッとする。

市販品使ってるわけないやろし、運用設計でええ方法編み出しるんやろけど、維持たいへんやろな。

windowsホストから見えるか

EFSつけたマウントポイントをsambaで共有したら、なんとec2-windowsホストからも使える。

net useでドライブ接続してドライブのプロパティ見たら800万テラバイトちょっと切ってる。数値が表示されるまでworkingって状態が５分続いた。

ec2-linux

「大きなファイルを保管利用できてええなぁ」って思うけど、費用が青天井になってまうから怖い。

「売るほどある」っちゅうのはこういうことやな。

ただ、ec2-windowsホストからドライブ共有先のEFSにdjangoのソース置いてvscodeでgitの履歴見ようとしたら、表示終わるまでカクンカクン動いてしもて、更新数見えるまで１時間ですまへんぐらい待たされた。

やり方あるかもしれんけど、使い物にならんかったから即日利用とりやめ。

ec2-linux

定期的なバックアップとして、tar.gzで固めたファイルを保管するのはええけど、小さいファイルの大量処理はうまいこといかんな。

docker設定

amazonlinux2023でもdockerは動く。

１つか２つぐらいやったらec2-linuxホストにサービス設定してもええけど、dbとかアプリとかを個別にチマチマ入れるの面倒やし、compose.yaml書いてたらそのまま使えるからdocker使うのやめられへん。

試験構築したときメモリ16GBぐらい欲しかったから、マシンタイプはt3.xlargeを設定。

docker.serviceのバージョン見てるとubuntu版よりは少しだけ古いし、コマンドラインでdocker compose使ったらcompose.yamlに書いたサービス名の補完ができんかった(見つけられんだけやったかもしれんけど)。

xrdpコンテナ作って動かしたり、 jupyterコンテナ、 djangoコンテナ、 mariadbコンテナも同じように動かせる。

dockerイメージを ECR のレジストリに保管するためのセキュリティグループの設定難しかったけど、 ECS で動かしたことあったな。

ECSはkubernetesと比べたら、なんちゃってコンテナクラスタで、慣れたら構築早いんかもしれん。

少しは楽に動かせるかもしれんけど、独特の設定必要やし覚えにくい。

自分はdocker/minikube/microk8sの順に覚えたから、ECSやなくて EKS のほうがスンナリ入れるんかもな。

すぐに使う場面なさそうや。

お菓子の家が作れるシステムエンジニアです

使い始めの設定#

ホスト名を変更設定#

ファイアウォールを無効化#

タイムゾーンを日本に変更#

時刻同期サーバを設定#

ルート以外のドライブあるときはフォーマットしてマウント#

ec2ホストに権限つける#

aws cliインストール#

CloudWatchAgentインストール#

CloudWatchログ保管設定#

CloudWatchエージェントを起動#

CloudWatchログの保管設定#

CloudWatchメトリクス取得設定#

EFSマウント#

サイズどのぐらい#

windowsホストから見えるか#

docker設定#

使い始めの設定

ホスト名を変更設定

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

タイムゾーンを日本に変更

時刻同期サーバを設定

ルート以外のドライブあるときはフォーマットしてマウント

ec2ホストに権限つける

aws cliインストール

CloudWatchAgentインストール

CloudWatchログ保管設定

CloudWatchエージェントを起動

CloudWatchログの保管設定

CloudWatchメトリクス取得設定

EFSマウント

サイズどのぐらい

windowsホストから見えるか

docker設定