privateのAmazon Elastic Search 改め Amazon OpenSearch Service のKibanaを公開する
PrivateのAmazonElasticSearchのKibanaって、CloudFrontで公開しようとしても公開出来ないので不親切。 ALB-ESとか CF-ESとか 簡単に公開できるようにしてくれればいいのに。
公開の仕方は巷に溢れているのだけれど、今回はReverseProxyで公開する。
構成は
ALB-Nginx-ES
設定箇所は、 ALB
IF パスが /_plugin/kibana/* 追加で送信元IPとかALBのSGとか使って公開具合はコントロールすると良い THEN 転送先 Nginx/Apacheその他webserverのReverseProxyサーバ
ALBとNginxを動かすリソース、ESのSecurityGroup
同一のSGに含めるか、いい感じに設定すると良い 下流のリソースが上流からの通信を許可すれば良い
Nginxの設定
server{ <省略> location /_plugin/kibana/ { proxy_pass https://<ESのKibana URLっていう方。vpcから始まってes.amazonaws.com/_plugin/kibana/まで>; } <省略> }
Nginxの設定は
nginx -t
で記述をテストしてから再起動する。
これで、ESをALBの設定を使って公開できる。
心に潤いが欲しい時は池かと。
MacでRailsTutorialをやる2
MacでRails Tutorialをやる - i俺のあれこれ
の続き
rails tutorialで、ローカル(自分のマシン)に
$ bundle install --without production
やら、
$ bundle update
の操作をしている記述がある。 dockerコンテナで同じ事を実行しようと思ったら、
version: "3.9" services: db: image: postgres volumes: - ./tmp/db:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: password web: build: . <省略>
docker-compose.ymlが上の通りになっているので、 rails アプリケーションはwebサービスで動かすため、
$ docker-compose run --no-deps web bundle install --without production
こうする。と、進む。 ここまで。
名盤である。 1996年に友達から借りた時には、もうちょいっと、こう、文字が沢山書いてあるジャケットだった記憶がある。 のだけれども、先日、本人にオトマロルイーズって言っても覚えていなかったし、別物なのかも知れない。 が、偶然、記憶していた名前がオトマロ・ルイーズだったらそれはそれでなんらかの共感現象が起きているとしか思えない。
- アーティスト:オトマロ・ルイーズ
- 発売日: 1992/10/21
- メディア: CD
在庫がないのが残念だが、これまた名盤である。 ベース好きな人には是非聞いてもらいたい。
MacでRails Tutorialをやる
MacをつかってRailsTutorialsを進めようとすると、Macで用意したGem(Gemfile.lock)とHerokuでcreate しようとするGemfile.lockに差分が出る。
曰く、 お前のローカルはdarwinだけど、herokuの環境はlinuxにしておくれ とのこと。
仕方がないので、MacにDockerをインストールして、Turorialを進める。
早速躓いたところを処理。
Docker公式のRails環境準備 Quickstart: Compose and Rails | Docker Documentation
以下の実行の部分でこける
$ docker-compose run --no-deps web rails new . --force --database=postgresql <省略> Service 'web' failed to build : COPY failed: forbidden path outside the build context: ../compose ()
これは、具体的には、Dockerfileの中のこの部分の実行でこけている
COPY ../compose /myapp
Dockerで、一個上のディレクトリのcomposeをコンテナの中の/myappにcopyしようとしているが、そんなものは用意していない。 用意をしたのはdocker-compose.ymlで、同じディレクトリ内である。そのため、こけた部分の記述を以下のように書き換える。
COPY docker-compose.yml /myapp
これでその後の手順はうまくいくはず。
sudo chown -R $USER:$USER .
の部分はもしかすると
sudo chown -R $USER .
にしないとエラーになるかも。自分のGroupを確認して欲しい。
今日はここまで。
camusは、多分、一番値段と味が信頼出来るcognacだと思う。 開けたてを飲むときついばかりで全然美味くないので、グラスに注いで2時間程度待つか、栓をあけずに5年くらい寝かした瓶を用意するか(オークションで出回っている)、すると良い。 葡萄の甘味、香り、熟成香が一体になっている中にもそれぞれが感じられて、とても良い。
クルボアジェ VSOP ルージュ [ ブランデー 700ml ]
- 発売日: 2016/12/06
- メディア: 食品&飲料
これも寝かすと美味い。と、いうか、cognac(コニャック)、armagnac(アルマニャック)は、大体、寝かすと美味い。
yum 動作確認済みのパッケージ類だけupdateしたい
簡単です。 redhat,CentOS,Fedora,AmazonLinux,AmazonLinux2で使えます。
1.検証環境、検証機でyum updateをします その際にパッケージを記録します(root)。
rpm -qa |sort > before sudo yum update -y rpm -qa |sort > after
2.updateしたシステムが問題なく動く事を確認します
3.問題なく動くまで更新対象を調整してください。updateした内容だけ抜き取ります。
diff --new-line-format='%L' --unchanged-line-format='' before after > update
4.実機に3で作ったupdate ファイルを移動してupdateします(root)。なんなら再度検証機で試してもらっても良いかと思います。
rpm -qa |sort > before cat update | xargs yum update -y rpm -qa |sort > after diff --new-line-format='%L' --unchanged-line-format='' before after > update_production
5.更新されたファイルが意図通りである事を確認します
diff update update_production
6.各環境に合わせて起動が必要なプロセスを再起動したり、設定を変更して下さい
終わり
こんなの乗りたい
複数AWSアカウントの運用の仕方<CLI> switch role/assumed role
ルール
まず、集権的アクセス権を有するAWSアカウントをaggregatorアカウントとします。 次に、操作されるAWSアカウントをbranchアカウントとします。
ローカルマシンから、aggregator AWSアカウントにあるhogeユーザが、switch roleでbranch AWSアカウントにあるbranchroleを使ってbranchroleの操作をする事を目的とします。
ただのswitch roleです。ご存知の方は他所にどうぞ。
ながれ
- branchアカウントで、Roleを作成します 名付けてbranch-role
- aggregatorアカウントのUsersPolicyにAction: sts:AssumeRole,Effect: Allow,Resource: branch-roleを割り当てます
- ローカルマシンの~/.aws/credentialにaggregatorアカウントのUserで発行したaws_access_key_id,aws_secret_access_key等を設定します
- ローカルマシンの~/.aws/configにbranch-roleのprofile,role_arn,source_profile,regionを設定します
- ターミナルからawsコマンドを--profile profileをつけて実行します
もう少しこまかい設定
1. branchアカウントで、Roleを作成します 名付けてbranch-role
GUI/CLI問わず、branchアカウントのIAMからRoleを作成します。 Role作成時に、「Another AWS account」を選択して、Account IDにaggregatorアカウントのAWSアカウント番号を入力します。 付与するPolicyはaggregatorアカウントで使わせたい人に合わせてPolicyを設定します。 ここで覚えておきたいのは、branchアカウントでは、aggregatorアカウントにRoleの使用許可を出すだけで、そのRoleをどのユーザで利用可能にするかは、後述のaggregatorアカウントのUserPolicyで設定する事です。
branchRole作成後、作成したbranch Roleのサマリから「Role ARN」,「Give this link to users who can switch roles in the console」の値をコピーして手元に置いておきます。
各AWSアカウントで必要な分だけRoleを作成します。このRoleをbranchroleとしておきます。
2. aggregatorアカウントのUsersPolicyにAction: sts:AssumeRole,Effect: Allow,Resource: branch-roleを割り当てます
具体的にjsonの記述は以下のようになります。
{ "Statement": [ { "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "ここに", "1で作成したbranch Roleの", "Role ARNを、ダブルクォーテーションとカンマで分けて必要なだけ書いて", "いきます", "このUsersPolicyを使うUserは、書いたRoleにswitch roleできるようになります" ] } ] }
このPolicyをaggregator AWSアカウントのUserにattachします。 aggregatorアカウントのUserと呼んでおきます。このUserをCLIから利用するために、aws_access_key_id,aws_secret_access_keyを発行しておきます。手元に置いておきます。 このUserを使ってaggregatorのAWSアカウントを操作するのであれば他にもPolicyをattachしてください。
3. ローカルマシンの~/.aws/credentialにaggregatorアカウントのUserで発行したaws_access_key_id,aws_secret_access_key等を設定します
ターミナルでホームディレクトリに隠しディレクトリ.awsを作成し、その中にcredentialsというファイルを作成、CLIでaggregatorのUsersPolicyを割り当てたUserの認証情報を保存します。
具体的には
[hoge] aws_access_key_id = xxxxxxxxxxxxxx aws_secret_access_key = xxxxxxxxxxxxxxxxxxx
このように保存します。
同じディレクトリ(~/.aws/)に、configというファイルを作成して、
[default] region = ap-northeast-1
とやっておけば、ターミナルからそのユーザに割り当てられたpolicyの操作が可能です。
$ aws ec2 describe-instances --profile hoge
で実行結果が返ってきます。
4. ローカルマシンの~/.aws/configにbranch-roleのprofile,role_arn,source_profile,regionを設定します
3.で追加したconfigファイルに、switch role用のprofileを追記します。 具体的には
[default] region = ap-northeast-1 ⏬のように追加 [profile branchrole] role_arn = arn:aws:iam::xxxxxxxxxxxxx:role/xxxxxxxxxxxxxxxxxxxxx source_profile = hoge (region = ap-northeast-1defaultにしたければ追加)
5. ターミナルからawsコマンドを--profile profileをつけて実行します
aws ec2 describe-instances --profile branchrole
これで、aggregator AWSアカウントにあるhogeユーザが、switch roleでbranch AWSアカウントにあるbranchroleを使ってbranchroleの操作をする事ができるようになります。