AWS 各リージョンのデフォルトVPCをまとめて削除するpythonスクリプト(boto3利用)
AWS SDK for Python (Boto3)の練習用に、各リージョンのデフォルトVPCをまとめて削除するpythonツールを作りました。
github.com
利用方法
- (1) boto3をインストールする
- インストールは下記ドキュメントを参照
- Quickstart — Boto 3 Docs 1.9.9 documentation
- (2) スクリプトをcloneする
git clone https://github.com/Noppy/delete_default_vpc.git
- (3)実行する
cd delete_default_vpc ./delete_default_vpc.py -a 'AWS_ACCESS_KEY_ID' -s 'AWS_SECRET_KEY_ID'
- 引数でアクセスキー&シークレットキーを渡すのはセキュリティの観点から正直バットプラクティスなので、実用化する場合はセッション取得周りの実装を見直したほうが良いと思います。
蛇足
boto3の全体像が理解できなく、結構苦労し
- botoのバージョン: botoが古いver2、boto3が2015年にGAされたver3
- 低レベル実装と、高レベル実装
- 明示的にセッションを取得する場合は、"boto3.session.Session"を利用する。
- わからなかったらBoto 3 Documentation — Boto 3 Docs 1.9.9 documentation公式ドキュメントのここを見る
vimの設定と操作時のTips
vimを利用する時の設定と操作時のメモです。
1. ~/.vimrc設定
" setting set fenc=utf-8 "文字コードをUFT-8に設定 set nobackup " バックアップファイルを作らない set noswapfile " スワップファイルを作らない set showcmd " 入力中のコマンドをステータスに表示する " 見た目系 set number "行番号を表示 set smartindent " インデントはスマートインデント set visualbell " ビープ音を可視化 set showmatch " 括弧入力時の対応する括弧を表示 set laststatus=2 " ステータスラインを常に表示 set wildmode=list:longest " コマンドラインの補完 "set cursorline " 現在の行を強調表示 "set cursorcolumn " 現在の行を強調表示(縦) :syntax on "構文解析に基づいて色を付ける " Tab系 set list listchars=tab:\▸\- " 不可視文字を可視化(タブが「▸-」と表示される) set expandtab " Tab文字を半角スペースにする set tabstop=4 " 行頭以外のTab文字の表示幅(スペースいくつ分) set shiftwidth=4 " 行頭でのTab文字の表示幅 " 検索系 set ignorecase " 検索文字列が小文字の場合は大文字小文字を区別なく検索する set smartcase " 検索文字列に大文字が含まれている場合は区別して検索する set incsearch " 検索文字列入力時に順次対象文字列にヒットさせる set wrapscan " 検索時に最後まで行ったら最初に戻る set hlsearch " 検索語をハイライト表示 " ESC連打でハイライト解除 nmap <Esc><Esc> :nohlsearch<CR><Esc>
多分こちらのページの内容をベースに多少カスタマイズしたものです。
2. vim操作のTips
VPC 閉域空間でCloudFormationのcfnヘルパーを使うときは、CFnのEndpointがいる話
インターネット接続していないVPC環境で、CloudFormationのcfnヘルパーを使ってインスタンスの中のセットアップをしたら、インスタンスの作成がエラーになってハマった話です。
原因
cfnヘルパーでの設定完了を通知するcfn-signalがCloudFormationのエンドポイントと通信できず、完了通知ができなかったため
対処
VPCにCloudFormationのVPC Endpoint(Private Link)を設置する。
ちなみに、CloudFormationのPrivate Link(VPC EndpointのInterface型)がサポートされたのは、2018年8月22日でつい先日の話でした。
参考情報
Creating the VPC EndPoint for AWS CloudFormation
To create the VPC endpoint for the AWS CloudFormation service, use the Creating an Interface Endpoint procedure in the Amazon VPC User Guide to create the following endpoint:
com.amazonaws.region.cloudformation
region represents the region identifier for an AWS region supported by AWS CloudFormation, such as us-east-2 for the US East (Ohio) Region.
VPC閉塞網からyumリポジトリにアクセスする(Amazon Linux & RHEL)
はじめに
セキュリティなどの理由で、VPCからインターネットへの外の通信をさせないようにしている環境を想定した検証環境で、必要なパッケージ追加をしようとしてハマったのでまとめました。
Amazon Linux1&2の場合
概要
Amazon Linuxのyumリポジトリは、S3が利用されています。ですので、S3用のVPC Endpointを作ることでInternet Gatewayを介さずにyumリポジトリにアクセスすることができるようになります。
VPC Endpoint(S3)の設定
VPCに、S3用のVPC Endpointを作成して、yumリポジトリ用のS3バスケット(下記の2個)にからオプジェクトをGetできるようにします。
- (AmazonLinux)yumリポジトリのS3バスケット
- packages.Region Code.amazonaws.com/*",
- repo.Region Code.amazonaws.com/*"
- (AmazonLinux2)yumリポジトリのS3バスケット
- amazonlinux.Region Code.amazonaws.com
- amazonlinux-2-repos-Region Code ※2021.6頃以降はこちらに変更された模様
Endpointのポリシーには以下のような設定をします。より厳密にするためには、amazonの前の"*"を各リージョンのコード(例えば東京リージョンの場合、ap-northeast-1)とします。
{ "Statement": [ { "Sid": "Amazon Linux AMI Repository Access", "Principal": "*", "Action": [ "s3:GetObject" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::packages.*.amazonaws.com/*", "arn:aws:s3:::repo.*.amazonaws.com/*", "arn:aws:s3:::amazonlinux.*.amazonaws.com/*", "arn:aws:s3:::amazonlinux-2-repos-<B>Region Code</B>/*"" ] } ] }
公式情報は、Amazon Linuxのよくある質問をご覧ください。
上記のVPCエンドポイントポリシーを作成するCloudFormationのサンプルです
S3VpcEndpoint: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !Ref Vpc ServiceName: !Sub com.amazonaws.${AWS::Region}.s3 RouteTableIds: - !Ref RouteTable1 - !Ref RouteTable2 PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: '*' Action: - 's3:*' Resource: # Allow connections to the Amazon Linux yum repositories - "arn:aws:s3:::packages.*.amazonaws.com/*" - "arn:aws:s3:::repo.*.amazonaws.com/*" # Allow connections to the Amazon Linux2 yum repositories - "arn:aws:s3:::amazonlinux.*.amazonaws.com/*" - Fn::Join: - "" - - "arn:aws:s3:::amazonlinux-2-repos-" - !Sub "${AWS::Region}" - "/*"
RHELの場合
概要
License includedなRHELを利用した場合のパッケージ管理は、Red Hat Update Infrastructure (RHUI) を利用します。
Q: Red Hat Enterprise Linux を実行中の Amazon EC2 インスタンス用に、更新や定期的なパッチを受け取るにはどのようにすればよいですか?
Red Hat Update Infrastructure (RHUI) が Red Hat によってそれぞれの AWS リージョンでメンテナンスされており、定期的なアップデートとパッチを利用できます。Red Hat Enterprise Linux インスタンスはリージョンごとのリポジトリにアクセスして差分更新を受信することができます。またすべては料金に含まれています。
AWSのRHUIの場合、パブリックなネットワーク上にRHUIサーバーがいるようで、どうしてもインターネットアクセスが必要になります。VPCに閉じることに拘らない場合は、NATGWをつけてしまえば良いですが、要件的にそれが難しい場合取りうる手段としては以下の2つが考えられると思います。
- VPCの外に簡単に出れない環境でのRHUIアクセス方法
- ForwardProxy(URLフィルタで制限)を利用する
- RHUIのyumリポジトリのコピーをVPC内に設ける
ただ「yumリポジトリのコピーをVPC内に設ける」案は、(1)RHUIからのリポジトリコピーをどうやるかという技術的課題と、(2)コピーしたyumリポジトリ上のrpmパッケージのredhatライセンス上の解釈が判断つかない、という理由から今回は「RHUIのyumリポジトリのコピーをVPC内に設ける」方法を取っています。
具体的には、public subnetにproxyを構成して、RHELのyum設定(/etc/yum.conf)にプロキシ設定を追加しています。
Forward Proxy設定
フィルタリング対象URL
公式な情報はなさそうで、私が実機を確認した範囲の情報ですがRHELインスタンスの/etc/yum.repos.d/rhui-load-balancers.confを見ると、以下のURLにアクセスしているように見えます。
- rhui2-cds01.
.aws.ce.redhat.com - rhui2-cds02.
.aws.ce.redhat.com
[2020.9.20追記]
詳細わかりませんが、最近動かしたらRHUIのURLが以下に変更されてたので追記します。(URLから推測するに、RHUI2からRHUI3にアップデートしたんですかね)
- rhui3.REGION.aws.ce.redhat.com
Forward Proxy設定
今回は手っ取り早く、squidを利用しています。
- (1) squidのrpmのインストール
sudo yum -y install squid
- (2) squid設定
- /etc/squid/squid.conf
# define ip address acl localnet src 127.0.0.0/8 acl localnet src ::1/128 acl SSL_ports port 443 acl Safe_ports port 443 # https acl CONNECT method CONNECT # Deny CONNECT to other than secure SSL ports http_access deny !Safe_ports http_access deny CONNECT !SSL_ports # Only allow cachemgr access from localhost http_access allow localhost manager http_access deny manager # from where browsing should be allowed http_access allow localnet # include url white list acl whitelist dstdomain "/etc/squid/whitelist" http_access allow whitelist # And finally deny all other access to this proxy http_access deny all #------------------------------------------ http_port 0.0.0.0:3128 # Leave coredumps in the first cache dir coredump_dir /var/spool/squid # anonymouse host name visible_hostname unknown # change log format logformat squid %tl %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt
-
- /etc/squid/whitelist(東京リージョンの場合*1 )
#For RHUI2 rhui2-cds01.ap-northeast-1.aws.ce.redhat.com rhui2-cds02.ap-northeast-1.aws.ce.redhat.com #For RHUI3( Added on Sep. 20, 2020) rhui3.ap-northeast-1.aws.ce.redhat.com
- (3) squidの再起動
sudo systemctl restart squid
RHELのyumへのProxy設定
- /etc/yum.conf (下記の設定を追記します。3128の部分は、squid.confのhttp_portの設定に従います)
proxy=http://<forward proxyのFQDNまたはIP>:3128
インスタンスのユーザデータや、CloudFormationのcnf-initヘルパーなどでこの設定を追加するようにしておくと便利だと思います。
*1:他リージョンは、ap-northeast-1を置き換えます
AWS 特定のAMIの各リージョンのImageID一覧を取得するシェル
1.概要
特定の種類のAMIについて、各リージョンのImageIDを取得し、CSV形式で出力するシェルスクリプトです。
例えば、SQL Server Web Editionが含まれているLicense-includeなwindowsインスタンスの各リージョンのImageIDを知りたいとかいうときに利用します。
作成したCSVフィルをExcelとかで開くとこんな感じで情報を確認できます。
2.使い方
2.1 前提
このツールは下記のコマンドが使えることが前提となります。
2.2 ソースコードの取得とセットアップ
ソースコードはこちらのgithubになります。
github.com
- (1) GitHubからコードをcloneする
$ git clone https://github.com/Noppy/aws_list_amis.git
- (2) 必要に応じて適切なフォルダにシェルをコピーする
$ cp aws_list_amis/list_amis.sh DEST_DIRECTORY_PATH
2.3 実行
- (1)マネジメントコンソールなどで、取得したいAMIの名前を確認する
- (a)「EC2」サービスに移動
- (b)「インスタンスの作成」を押し、「コミュニティーAMI」を選択する
- (c)検索などを利用し目的のAMIを見つけて、名前をコピーする
- (2)シェルを実行する
取得したAMIの名前を引数にしてシェルを実行する。結果は標準出力に出力されるので、必要に応じてファイルにリダイレクトする。
./list_amis.sh "Windows_Server-2012-R2_RTM-English-64Bit-SQL_2016_SP1_Web-2018.07.11" > Win_SQL_WebEdition.csv
AWS リージョンのコードと名称の一覧を取得する
結論
例えば「”Asia Pacific (Tokyo)", "ap-northeast-1"」という感じに、リージョン名称とリージョンコードの一覧を取得するのは、下記のAWSのEC2ユーザーズガイドの"Regions and Availability Zones"のリージョン一覧表から取得するのが良さそう。(結局手作業ですが)
docs.aws.amazon.com
(補足)aws cliでのリージョン一覧取得
aws cliで、"aws ec2 describe-regions"でもリージョン一覧が取得できますが、リージョンコード(ap-northeast-1とか)と、EC2のエンドポイント (ec2.ap-south-1.amazonaws.comとか)しか取得できず、ap-northeast-1が”Asia Pacific (Tokyo)"というのは自動では取れないんですね。
aws cli取得例1 アジアのリージョンを取得する
aws ec2 describe-regions --output json --filters 'Name=region-name, Values=ap-*' { "Regions": [ { "Endpoint": "ec2.ap-south-1.amazonaws.com", "RegionName": "ap-south-1" }, { "Endpoint": "ec2.ap-northeast-2.amazonaws.com", "RegionName": "ap-northeast-2" }, { "Endpoint": "ec2.ap-northeast-1.amazonaws.com", "RegionName": "ap-northeast-1" }, { "Endpoint": "ec2.ap-southeast-1.amazonaws.com", "RegionName": "ap-southeast-1" }, { "Endpoint": "ec2.ap-southeast-2.amazonaws.com", "RegionName": "ap-southeast-2" } ] }
取得例2 リージョンコード一覧を抜き出す
aws ec2 describe-regions --output text --query 'Regions[].{Name:RegionName}' ap-south-1 eu-west-3 eu-west-2 eu-west-1 ap-northeast-2 ap-northeast-1 sa-east-1 ca-central-1 ap-southeast-1 ap-southeast-2 eu-central-1 us-east-1 us-east-2 us-west-1 us-west-2
取得例3 シェルで、抜き出したリージョンコード一覧をREGIONSという配列にセットする
declare -a REGIONS=( $(aws --output text ec2 describe-regions --query 'Regions[].{Name:RegionName}'|sort) )
取得したREGIONS配列を利用する例
for i in ${REGIONS[@]}; do echo "region code = $i";done region code = ap-northeast-1 region code = ap-northeast-2 region code = ap-south-1 region code = ap-southeast-1 region code = ap-southeast-2 region code = ca-central-1 region code = eu-central-1 region code = eu-west-1 region code = eu-west-2 region code = eu-west-3 region code = sa-east-1 region code = us-east-1 region code = us-east-2 region code = us-west-1 region code = us-west-2
AWSのドキュメントリンク
個人用のメモです。
リージョンに関する情報
ネットワークに関する情報
サービスに関する情報
RHEL7 on EC2にdockerをセットアップする手順
はじめに
RHEL7 on EC2(License Included)でのdockerセットアップ手順を記載します。
Amazon Linux2へのdockerセットアップ手順(下記)との違いは、RHUI*1のEPELレポジトリを有効化してそこからdockerをインストールするところです。
nopipi.hatenablog.com
手順
RHEL7 on EC2へのdockerインストール
基本的には、ECS agentガイドにある手順を参考にRHEL用に一部カスタマイズして進めます。
EPELレポジトリの登録
awsが提供するライセンス込みのRHELインスタンスにdockerをインストールする場合は、RHUI(Red Hat Update Infrastructure)*2のEPEL(Extra Packages for Enterprise Linux)から、dockerをダウンロードします。
EPELはデフォルトでは登録がないので、まずEPELの登録をします。(2020/11/10 RHUIの仕様が変わったようで、リポジトリ名が変わっていたのでそれに合わせてコマンドを変更しました)
sudo yum install yum-utils
sudo yum-config-manager --enable rhel-7-server-rhui-extras-rpms
dockerの起動とOS起動ときの自動起動設定
sudo systemctl start docker sudo systemctl enable docker
dockerコマンドをec2-userで実行するための設定
ec2-userのセカンダリグループに、dockerrootグループを追加します。dockerのグループが、dockerではなくdockerrootなので注意してください。
あとdockerdのsocketファイルの所有者が"root:root"なので、dockerrootグループがwriteできるよう所有者を"root:dockerroot"に変更します。(もっとスマートな方法があればいいのですが、ちょっと見つからなかったので)
sudo usermod -a -G dockerroot ec2-user sudo chown root:dockerroot /var/run/docker.sock
確認
dockerコマンドを実行して確認する。実行して、ClientとServerの両方の情報が表示されればOKです。
$ docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.6 Git commit: 3dfb8343b139d6342acfd9975d7f1068b5b1c3d3 Built: Fri Jun 15 23:15:12 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.6 Git commit: 7390fc6/18.03.1-ce Built: Fri Jun 15 23:17:24 2018 OS/Arch: linux/amd64 Experimental: false
リファレンス
EC2(Amazon Linux2)にprivateなdocker registryの作るメモ
1.はじめに
検証用にプライベートなdocker registryをAWS EC2上のAmazon Linux2に作った時のメモです。レジストリを立てて、別のサーバからdockerイメージをpush/pullして確認するまでを記録しています。
内容は、こちらの記事を参考にしています。
2.セットアップ手順
2.1 前提環境
雑な絵ですが、こんな感じの構成を作ります。
このメモの前提となる構成は以下の通りです。
2.2 dockerのセットアップ
プライベートdocker registryをインストールするインスタンスにsshログインして、下記の記事の手順でdockerをセットアップします。
nopipi.hatenablog.com
dockerレジストリ用のディレクトリ作成
/home/docker/ └── registry ├── certs └── data
ディレクトリの作成と確認手順はこちらですl
sudo mkdir -p /home/docker/registry/{certs,data} find /home/docker/
2.3 SSLの自己証明書(オレオレ証明書)の作成
検証用なのでオレオレ証明書で勘弁してもらいます。opensslコマンドの途中で聞かれる内容は、とりあえず全てデフォルト(リターン)とします。
openssl req -newkey rsa:4096 -nodes -sha256 -keyout domain.key -x509 -days 365 -out domain.crt
- オプション説明
作成した秘密鍵(domain.key)と、サーバ証明書(domain.crt)をレジストリのディレクトリに移動します。
sudo mv domain.key /home/docker/registry/certs/ sudo mv domain.crt /home/docker/registry/certs/
2.4 dockerレジストリの起動
レジストリのイメージ登録とコンテナの実行を同時に行います。
cd /home/docker/registry docker run -d \ --restart=always \ --name docregistry \ -v `pwd`/certs:/certs \ -v `pwd`/data:/var/lib/registry \ -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \ -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \ -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \ -e REGISTRY_STORAGE_DELETE_ENABLED=True \ -p 443:443 \ registry:2
- オプション説明
dockerイメージを確認します。
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE registry 2 b2b03e9146e1 2 weeks ago 33.3MB
registryコンテナが実行されているか確認します。
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ddd75d47e43a registry:2 "/entrypoint.sh /etc…" 16 seconds ago Up 16 seconds 0.0.0.0:443->443/tcp, 5000/tcp docregistry
3.クライアントからdockerイメージをpushしてみる
dockerのクライアントとなる別のサーバから、プライベートdocker registryへのimageのpush、pullを確認します。
3.1 httpsの接続確認
まずは素のhttpsで、クライアントから、プライベートdocker registryにアクセス可能かを確認します。
(1)サーバ証明書のコピー
プライベートdocker registry用に作成したサーバ証明書を、クライアントにコピーします。ssh ログインするときに"-A"オプションを利用するとsshの鍵を自動でforwardingしてくれるので、クライアントのインスタンスに秘密鍵を置く必要がありません。(今回の話からは脱線するので、詳しくはこちらを参照)
MACの場合でデフォルトの秘密鍵を利用する場合は、こんな感じでログインします。
ssh -A ec2-user@[クライアントのDNS or IP] scp ec2-user@ip-10-203-64-60.ec2.internal:/home/docker/registry/certs/domain.crt .
3.2 dockerへのサーバ証明書登録
コピーしたサーバ証明書をdockerの設定ディレクトリに格納します。
格納は、下記ルールに基づいて格納します。
- "/etc/docker/certs.d/[dockrレジストリのFQDN:ポート番号]"のディレクトリに
- ”ca.crt”というファイル名で格納
- ディレクトリのポート番号は、httpsでフォルトの443の場合は省略可能
この/etc/dockerディレクトリは、root権限がないと移動することもできないので、rootにチェンジして作業します。
$ sudo -i # cd /etc/docker/ # mkdir certs.d # cd certs.d/ # mkdir ip-10-203-64-60.ec2.internal # cp /home/ec2-user/domain.crt /etc/docker/certs.d/ip-10-203-64-60.ec2.internal/ca.crt # exit $
3.3 プライベートレジストリへのイメージのpushとpull
動作確認として、docker hubからubuntuのコンテナイメージをpullしてきて、プライベートdockerレジストリに登録してみます。
(1)イメージのpullとtag作成
ubuntuのイメージをpullしてきて、プライベートdockerレジストリ登録用のtagを作成します。
docker pull ubuntu:16.04 docker tag ubuntu:16.04 ip-10-203-64-60.ec2.internal/my-ubuntu docker images REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu 16.04 e13f3d529b1a 4 days ago 115MB ip-10-203-64-60.ec2.internal/my-ubuntu latest e13f3d529b1a 4 days ago 115MB
(2)イメージのpush
プライベートdocker registryにイメージをpushします。
docker push ip-10-203-64-60.ec2.internal/my-ubuntu The push refers to repository [ip-10-203-64-60.ec2.internal/my-ubuntu] 709bdd00b1a4: Pushed 07b9c3c04cbd: Pushed 6eaddaf493f1: Pushed a0e188d0e278: Pushed 711e4cb62f50: Pushed latest: digest: sha256:0d06090fff94c0a3640729c7ef7e6b36ad5b41bec600cc2be92739c90d204243 size: 1357
pushしたイメージが登録されているか、プライベートdocker registryのカタログを参照します。
[ec2-user@ip-10-203-128-109 ~]$ curl --cacert domain.crt https://ip-10-203-64-60.ec2.internal/v2/_catalog {"repositories":["my-ubuntu"]}
(3)イメージのpull
まず確認のため、ローカルにあるdockerイメージを削除します。
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE ubuntu 16.04 e13f3d529b1a 4 days ago 115MB ip-10-203-64-60.ec2.internal/my-ubuntu latest e13f3d529b1a 4 days ago 115MB $ docker rmi e13f3d529b1a e13f3d529b1a $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE
プライベートdocker registryから、イメージをpullして確認します。
$ docker pull ip-10-203-64-60.ec2.internal/my-ubuntu $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE ip-10-203-64-60.ec2.internal/my-ubuntu latest e13f3d529b1a 4 days ago 115MB
opensslコマンドのhelpを出す
opensslコマンドのメモです。
1.コマンドのSYNOPSIS
openssl command [ command_opts ] [ command_args ]
2.コマンドのヘルプ表示方法
2.1 [command]一覧を出す
"help"というコマンドは無いが、”invalid command”エラーでコマンド一覧が表示される。コマンドの説明は"man openssl"で確認する。
openssl help
2.2 各コマンドのオプション
コマンドの後ろに"help"をつけると、"unknown option"となりオプション一覧が表示される。
例えばreqコマンドのオプションの場合は以下
openssl req help
またreqなどのスタンダードコマンドは、"man req"などmanでコマンド名を指定することで詳細なmanを参照できる。
man req REQ(1) OpenSSL REQ(1) NAME req - PKCS#10 certificate request and certificate generating utility. SYNOPSIS openssl req [-inform PEM|DER] [-outform PEM|DER] [-in filename] [-passin arg] [-out filename] [-passout arg] [-text] [-pubkey] [-noout] [-verify] [-modulus] [-new] [-rand file(s)] [-newkey rsa:bits] [-newkey alg:file] [-nodes] [-key filename] [-keyform PEM|DER] [-keyout filename] [-keygen_engine id] [-[digest]] [-config filename] [-multivalue-rdn] [-x509] [-days n] [-set_serial n] [-asn1-kludge] [-no-asn1-kludge] [-newhdr] [-extensions section] [-reqexts section] [-utf8] [-nameopt] [-reqopt] [-subject] [-subj arg] [-batch] [-verbose] [-engine id] DESCRIPTION The req command primarily creates and processes certificate requests in PKCS#10 format. It can additionally create self signed certificates for use as root CAs for example. 以下略
Amazon Linux2にdockerをセットアップする手順
Amazon Linux2上にdocker環境を作った時のメモです。
手順
インスタンスを立ち上げて、sshログインしてからの手順です。
(1)dockerのインストール
sudo yum -y update sudo yum -y install docker
(2)dockerサービスの起動
最初の"start"でdockerサービスを開始(dockerデーモン起動)します。次のenableでOS起動時のサービス開始を有効化します。
sudo systemctl start docker.service sudo systemctl enable docker.service
(3)ec2-userユーザへの権限付与
dockerコマンドでの操作を行うには、dockerグループに所属している必要があります。usermodコマンドで、ec2-userのセカンダリグループにdockerグループを追加します。
sudo usermod -a -G docker ec2-user
ログイン中のセッションには設定が反映されないため、一度ログアウト&ログインをおこない、idコマンドで設定を確認します。
ログアウト&ログイン後に、 $ id uid=1000(ec2-user) gid=1000(ec2-user) groups=1000(ec2-user),4(adm),10(wheel),190(systemd-journal),994(docker)
(4)確認
dockerコマンドを実行して確認する。実行して、ClientとServerの両方の情報が表示されればOKです。
$ docker version Client: Version: 18.03.1-ce API version: 1.37 Go version: go1.9.6 Git commit: 3dfb8343b139d6342acfd9975d7f1068b5b1c3d3 Built: Fri Jun 15 23:15:12 2018 OS/Arch: linux/amd64 Experimental: false Orchestrator: swarm Server: Engine: Version: 18.03.1-ce API version: 1.37 (minimum version 1.12) Go version: go1.9.6 Git commit: 7390fc6/18.03.1-ce Built: Fri Jun 15 23:17:24 2018 OS/Arch: linux/amd64 Experimental: false
- Server側のエラー
- "Cannot connect to the Docker daemon...”: dockerデーモンが起動していない可能性。(2)とNW設定を見直し
- "Got permission denied while trying to connect ":権限がない可能性。(3)を見直し
EC2でnetconsoleを使ってカーネルメッセージを取得する
1.はじめに
EC2インスタンスで、netconsoleを使ってカーネルメッセージを別サーバに飛ばして見る方法のメモです。ncatを利用しnetconsoleサーバを一時的に作る方法と、syslogサーバに飛ばす方法の、2つを説明します。*1
2.前提
3.netconsole serverを一時的に立てて取得
デバックや再現テストとかで一時的に使いたいという場合はncatコマンドで簡易的なサーバを立ててカーネルメッセージを取得することができます。以下の説明の構成概要は以下の通りです。
3.1 netconsole serverの準備
(1) security group設定
今回の例では、UDPの6666port で受診しますので、以下のようなInbound許可ルールを持つセキュリティーグループを設定して、netconsole serverインスタンスにアタッチします。
方向 | タイプ | プロトコル | ポート | ソース |
---|---|---|---|---|
Inbound | custom UDPルール | UDP | 6666 | 172.31.37.0/24 |
(2) ncatのパッケージインストール
ncatコマンドは、nmap-ncatパッケージに含まれていますので、このパッケージをインストールします。
sudo yum -y install nmap-ncat
(3) ifconfigでネット設定を確認
ncatコマンドでlistenするIPアドレスと、そのIPアドレスが割り当てられているMACアドレス(クライアントで利用)を控えます。
$ ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001 inet 172.31.37.224 netmask 255.255.240.0 broadcast 172.31.47.255 inet6 fe80::410:9aff:feda:c3d2 prefixlen 64 scopeid 0x20<link> ether 06:10:9a:da:c3:d2 txqueuelen 1000 (Ethernet) RX packets 27150 bytes 35693608 (34.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 10838 bytes 805351 (786.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
今回の場合での必要情報は、以下になります。
3.2 netconsole client実行
カーネルメッセージを出力するサーバの設定です。netconsoleのカーネルモジュールにオプションをつけてローディングすればOKです。一時的な利用を想定して、netconsoleモジュールを手動でロードする手順にしています。
(1)クライアントのネット設定を確認
利用するIPアドレスと、そのIPアドレスが割り当てられているデバイス名を確認します。
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9001 inet 172.31.37.12 netmask 255.255.240.0 broadcast 172.31.47.255 inet6 fe80::4ca:cdff:fe50:cc8 prefixlen 64 scopeid 0x20<link> ether 06:ca:cd:50:0c:c8 txqueuelen 1000 (Ethernet) RX packets 26294 bytes 35430311 (33.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2764 bytes 318056 (310.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
確認する情報は以下になります。
(2)netconsoleのローディング
modprobeコマンドを利用してnetconsoleカーネルモジュールをローディングします。"netconsole="以下はこのカーネルモジュールのオプション設定です。
sudo modprobe netconsole 'netconsole=6666@172.31.37.12/eth0,6666@172.31.37.224/06:10:9a:da:c3:d2'
netconsoleオプションの書式は以下の通りです。*3
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
4.syslog serverでカーネルメッセージを取得する
カーネルメッセージを定常的またはある程度の期間取得し続ける場合は、syslogサーバを立てて取得した方が良いかもしれません。ここではsyslogをUDPの514ポートでlistenする構成の手順を記載します。
4.1 rsyslogサーバの設定
(1)rsyslogにUDPでのListenを有効化
UDPの514番ポートでの受信ができるようにrsyslog.confを設定します。
/etc/rsyslog.conf:
# Provides UDP syslog reception $ModLoad imudp $UDPServerRun 514
(2)設定の有効化
rsyslogを再起動し、設定を有効化します。
$ sudo systemctl restart rsyslog
4.2 クライアント(netconsole)の設定
クライアント側は恒常的なメッセージ収集のため、サーバ起動時にnetconsoleが設定されるように"/etc/sysconfig/netconsole"に送信先となるsyslogサーバのIPアドレス設定を行います。
(1)送信先のsyslogサーバIPとポート設定
/etc/sysconfig/netconsole
# The IP address of the remote syslog server to send messages to SYSLOGADDR=172.31.37.224 # The listening port of the remote syslog daemon SYSLOGPORT=514
(2)netconsoleのサービスの再起動
netconsole.serviceを再起動し設定を反映させます。
またOS再起動後も反映されるようい"systemctl enable・・・"でサービスを有効化します。
$ sudo systemctl restart netconsole.service $ sudo systemctl enable netconsole.service
Linuxのテスト用に、ハングアップやパニック状態にするカーネルモジュールを作ってみた
テストのために、AWSのAmazon Linuxのインスタンスをカーネルレベルでハングアップさせたかったので、テスト用のカーネルモジュールを作ってみました。
できること
使い方
カーネルモジュールのビルド
コードはGitHubにあります。
github.com
(1) 必要なパッケージのインストール
カーネルモジュールのビルドに、gccとkernel-develが必要になります。(Amazon Linuxの場合)
sudo yum -y install git gcc kernel-devel
(2) ソースコードをローカルに持ってきます
git clone https://github.com/Noppy/HangAndPanicKernelModule.git cd HangAndPanicKernelModule/
(3)ビルドします
make ls *.ko hang_panic.ko
使い方
(1)モジュールのインストール
sudo insmod hang_panic.ko lsmod |grep hang_panic
(2)使い方の確認方法(要root権限)
cat /proc/hang_panic <<Hang&Panic module>> 'echo c > /proc/hang_panic' >>> panic 'echo h > /proc/hang_panic' >>> hang(disable local irq and preempt) 'echo H > /proc/hang_panic' >>> hang(disable only local irq)
(3)ハングアップさせる(要root権限)
(a) Local IRQ と preemptionをdisableにしてハング(おそらく、ping応答もできない)
echo h > /proc/hang_panic
(b) Local IRQのみdisable(ping応答はできるレベル)
echo H > /proc/hang_panic
(4)パニック(要root権限)
# echo c > /proc/hang_panic
#蛇足
10年前のkernel2.6時代は、ジャイアントロック(BKL:Big Kernel Lockともいう)があったので、もっと綺麗にハングさせることができたのですが、ソースコードの中を探したのですが、今はシステムワイドなロックのコードがないんですね・・。RHEL3時代に、お客さん先のシステムでBKLに苦しめられたのも、今は昔ということなんですね。
AWS CLIのセットアップ(RHEL/Mac)
2.RHELに AWS CLIをインストール
こちらを参照
上記の公式ドキュメントの内容をベースにインストールします。
(1) unzipをインストールする
$ sudo yum -y install unzip
(2) AWS CLIバンドルインストーラをダウンロードする
$ curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
(3) ダウンロードしたファイルを解凍する
$ unzip awscli-bundle.zip
(4) インストーラを実行する
$ sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
$ aws --version aws-cli/1.16.77 Python/2.7.14 Linux/4.14.72-73.55.amzn2.x86_64 botocore/1.12.67
4.AWS CLIの設定
4.1 管理用のPCからAWS CLIを利用する場合(アクセスキーによる認証)
設定手順は、こちらの公式ページを参照して下さい。
アクセスキーの漏洩によるアカウント乗っ取りの可能があるので、EC2インスタンス上でAWS CLIを利用する場合は、次のIAMロールをEC2に割り当てる方法の利用を検討します。*1
(1)IAMユーザのアクセスキー ID とシークレットアクセスキーの生成と取得
以下は公式ドキュメントからの抜粋です。
- IAM コンソールを開きます。
- コンソールのナビゲーションペインで、[Users] を選択します。
- IAM のユーザー名 (チェックボックスではありません) を選択します。
- [Security credentials] タブを選択し、次に [Create access key] を選択します。
- 新しいアクセスキーを表示するには、[Show] を選択します。認証情報は以下のようになります。
(2)AWS CLI設定
aws cliに、取得したアクセスキーとシークレットアクセスキー、デフォルトリージョンを設定します。
$ aws configure AWS Access Key ID [None]: XXXXXXXXXXXXX <==アクセスキーを設定 AWS Secret Access Key [None]: YYYYYYYYYYYY <==シークレットアクセスキーを設定 Default region name [None]: ap-northeast-1 <==デフォルトリージョン設定( ap-northeast-1は東京リージョン) Default output format [None]:
4.2 EC2からAWS CLIを利用する場合(EC2にIAMロール割り当て)
ユーザガイドは私にはわかりずらかったです。こちらの公式ブログの記事の方がわかりやすかったです。
(1)IAM ロールの作成
- IAM コンソールを開きます。
- コンソールのナビゲーションペインで、[Roles] を選択します。
- [Create role]を選択します。
- [AWS Service]を選び、許可したいサービスを選び[Next Permission]で進む。
- 適切なpolicyを選び[next:Review]で進む。
- Roleの名前と詳細説明を入力し、[Create Role]でロールを作成する
(2)EC2へのRole割り当て
- EC2コンソールを開きます。
- コンソールのナビゲーションペインで、[Instances] を選択します。
- [Create Instance]でインスタンス作成中に、作成したRoleを割り当てるか、
- 割り当てたいインスタン(起動中も可)を選択し、[Attach/Replace IAM Role]で作成したロールをEC2に適用
(3)AWS CLI設定
ロールを割り当てる場合は、アクセスキーとシークレットキーは設定しないようにします。
$ aws configure AWS Access Key ID [None]: AWS Secret Access Key [None]: Default region name [None]: ap-northeast-1 <==デフォルトリージョン設定( ap-northeast-1は東京リージョン) Default output format [None]:
5.その他
5.1 コマンド保管
awsコマンドを[TAB]キーで保管してくれるAWSコンプリータという機能があります。これをシェルに組み込めばコマンドを保管してくれます(pythonだからかわかりませんが、保管までに微妙な間があり使いづらいですが)。公式ドキュメントはこちらです。
(1)AWSコンプリータの場所を確認する
$ which aws_completer /usr/bin/aws_completer
(2)プロファイルに組み込む
環境に依存しますが、例えば "~/.bash_profile"の末尾に下記行を追加します。
#Enable aws command autocompletion complete -C '/usr/bin/aws_completer' aws
(3)反映
プロファイルを読み込み設定を反映させます。
source .bash_profile