yamlの書き方メモ

何度調べても忘れてしまうため

配列

- リンゴ
- イチゴ
- みかん

ハッシュ

name: 鈴木
age : 20
born : tokyo

配列の中にハッシュ

- name: suzuki
  age : 20
  born : tokyo
- name: sato
  age: 21
  born: osaka

ネスト

同じ構造のままインデントすればいい

配列

- リンゴ
  - スーパーリンゴ
  - すごいリンゴ
- イチゴ
- みかん

ハッシュ

name: 鈴木
  mei:
    mei1: taro
    mei2: jiro
age : 20
born : tokyo

考え方

  • ネストさせるにはインデントさせればいい
  • ハッシュは当然キーが必要
  • 配列の中にハッシュなら先頭のハイフンが「配列」の宣言でその次以降にハッシュが書かれてると理解する -- リスト一つの中にハッシュが入るので後続もインデントする

AWS Security ScannerというUserAgentについて

タイトルのようなUserAgentのアクセスが来ていたので調べてみたら、 どうもAWS公式がスキャンをかけているらしい。 (bot netにされてないかとかをスキャンしてるらしい)

UserAgentなので参考情報と程度にしかならないが、 client-ipがAWSか位は調べておくと多少精度が上がるかもしれない。

が。いずれにせよAWSのEC2からUserAgent偽装してスキャンしてたら見分けられないので UserAgentでブロックしてしまっても問題ないレベルかもしれない。

glueで開発エンドポイントを作る時のメモ(VPCに入れる時)

S3の開発エンドポイントが必要

  • VPCエンドポイントはVPC単位で作成
  • VPCエンドポイントはルートテーブルに割り当てる
    • おそらくs3へのアクセスする時のルーティングで自動的に使ってくれる模様
  • vpcエンドポイントをルートテーブルにつけるとエンドポイント作成時の候補にVPCが出てくる

VPC作る時のメモ(RouteTable,NetWorkACL, NAT, InternetGateway)

VPC作成するときにルートテーブルとネットワークACLでよく迷うのでメモ

ルートテーブル

  • サブネットに付くもの
  • いわゆるルーティング
  • IGWとかNATへの行き先はここで指定する
  • サブネット側から選べるが何も指定しないとメインルートテーブルが選択される
  • privateとpublicでサブネット分けるならルートテーブルを分ける
    • private側のルートテーブルで0.0.0.0/0をNATに向ける
    • public側のルートテーブルで0.0.0.0/0をIGWに向ける

ネットワークACL

  • サブネットに付くもの
  • いわゆるファイヤーウォール
  • デフォルト設定で全開放
    • なのここは全開放のままでSGで適切的に開放して行くでいいと思ってる

NatGateway

  • サブネット単位
  • publicサブネットに付与する必要あり
  • private側の0.0.0.0/0をNatに刺してpublic側はIGWを指す

InternetGateway

  • VPCにアタッチする
  • 実際に使用するのはルートテーブル側

おまけ

  • enableDnsHostnames
  • enableDnsSupport デフォルトでオフになってるのでオンにするかは確認したほうがいい。 Glue使うときはonになってる必要がある

ALB + ACM + EC2 + SES + RDS + ElastiCacheでre:dash環境を構築する

マネージドサービスを使うのにECSは使わずにEC2な理由

なんとなくなのだが、ECSに持って行くのが面倒。workerとかその辺。 永続データさえちゃんと残しておけば最悪redash server自体は作り直しでもいいかなーと思い。

ソースはこちら github.com

ここに載ってる通りcloneして来てdocker-compose upすればとりあえず起動するが、 production readyな環境としてはセットアップスクリプトを使用する様子 redash.io

セットアップスクリプトはこちら github.com

って事でやってみる

前提

  • SESはSMTP認証で送信可能な状態
  • EC2, RDS(postgresql9.5) ElastiCache(Redis)はセットアップ済み
  • VPC,SecurityGroup的に
    • EC2からpostgresqlとElastiCacheに接続可能な状態(psql,redis-cliで接続を確認する)
    • ALBからEC2へ5000portで接続可能な状態にしておく
  • EC2は公式推奨のubuntu16で起動
  • ACMssl証明書取得済み
  • ALBにACMセット済み

思ったより前提が多いが。手馴れてれる内容ではある。

setup

EC2にsudo可能なユーザーでログインしたら

# redash起動場所
sudo mkdir /opt/redash
chown ubunt:ubuntu /opt/redash
# setup script取得
git clone https://github.com/getredash/redash.git

cloneして来たsetup.shをちょっと修正

https://github.com/getredash/setup/blob/master/setup.sh

環境変数の修正,DB接続のパスワードはRDS起動した時のパスワードを使う

# ここコメントアウトしちゃう
#POSTGRES_PASSWORD=$(pwgen -1s 32)
# RDSで設定したパスワード
POSTGRES_PASSWORD="postgresユーザーパスワード"
REDASH_DATABASE_URL="postgresql://postgres:${POSTGRES_PASSWORD}@RDSエンドポイント/postgres"

echo "REDASH_REDIS_URL=redis://ElastiCacheエンドポイント:6379/0" >> $REDASH_BASE_PATH/env
echo "POSTGRES_PASSWORD=$POSTGRES_PASSWORD" >> $REDASH_BASE_PATH/env

echo "REDASH_MAIL_DEFAULT_SENDER=SESで送信元に使うメールアドレス" >> $REDASH_BASE_PATH/env
# バージニアなら email-smtp.us-east-1.amazonaws.com
# https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/smtp-connect.html
echo "REDASH_MAIL_SERVER=SESエンドポイント" >> $REDASH_BASE_PATH/env
echo "REDASH_MAIL_USERNAME=SMTPユーザーネーム" >> $REDASH_BASE_PATH/env
echo "REDASH_MAIL_PASSWORD=SMTPパスワード" >> $REDASH_BASE_PATH/env
echo "REDASH_MAIL_USE_SSL=false" >> $REDASH_BASE_PATH/env
echo "REDASH_MAIL_USE_TLS=true" >> $REDASH_BASE_PATH/env
# TLS送信するから指定, デフォルト25だとエラー
echo "REDASH_MAIL_PORT=587" >> $REDASH_BASE_PATH/env

環境変数周りはここに載ってる redash.io

shellを変更し終わったら実行

sh ./setup/setup.sh

これでredashサーバは起動可能

ssl接続する場合

ALBの下に入れてしまうのが簡単 ACMssl証明書をセットして、 port 443 -> 5000でフォワードする

CloudWatchLogsのサブスクリプションフィルターでkinesis firehoseへ流すとjsonのダブルクオートがバックスラッシュでエスケープされる

CloudWatch Logs サブスクリプションフィルタの使用 - Amazon CloudWatch Logs

仕様らしい。

cw-logs自体がjson invalidで出力したいから、 messagesという中に含まれるユーザー側が出力する値はstringとして扱うためにダブルクォーテーションをエスケープされてしまう。

firehoseのlambda変換スクリプト内部でどうにかするしかなさそうである。

不便だなー。