二度忘れた事を三度忘れないようにする

しがないフリーランスIT系エンジニア

AWS CloudwatchAgentを導入する際に躓いたこと

EC2インスタンスの詳細なメトリクス情報を取得するために、従来のスクリプトタイプのものからデーモンタイプのモノが出てきていたので試した。

OSはamzn2-ami-hvm-2.0.20181008-x86_64-gp2を利用。

  1. RunCommandでAgentをインストールするとtypes.dbが無いとエラーになる。
E! Error parsing /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml, open /usr/share/collectd/types.db: no such file or directory

これはちゃんとした解決策かどうか不明だけど、ファイルを作ることで回避できた。

mkdir /usr/share/collectd
touch /usr/share/collectd/types.db
  1. RunCommandでパラメータストアの設定を指定するも読み込まれない。
    これはドキュメントの確認不足でした。名前が「AmazonCloudWatch-」で始まるモノしか読まないようで変更することで何事もなく読み込まれた。

キーボードのスイッチまとめ

キーボードのスイッチを一覧でまとめた物が見当たらなかったので、自分用にメモ。
原則Cherry MX互換系を記載。荷重は情報元をベースに書いてるので、他所で見る値とは違うケースが多いかと。

情報元

The Comparative Guide to Mechanical Switches - Input Club

Mechanical Key Switches



※ 表の意味
TPF - Tactile Peak Force - クリック感を感じるピーク時の荷重
AF - Actuation Force - キー反応時の荷重
BoF - Bottom-Out Force - キーを押し切った時の荷重

 

メーカ コミュニティ タイプ TPF AF BoF
Cherry - クリック 65g 55g 60g
Cherry - クリック 80g 53g 82g
Cherry - クリック 70g 60g 82g
Cherry - タクタイル 45g 38g 55g
Cherry - クリア タクタイル 65g 51g 85g
Cherry - タクタイル 84g 67g 110g
Cherry - リニア - 37g 54g
Cherry - リニア - 55g 75g
Cherry - リニア - 78g 110g
Gateron - クリック 58g 43g 62g
Gateron - クリック 80g 65g 90g
Gateron - タクタイル 48g 37g 52g
Gateron Zealio タクタイル 55g 33g 60g
Gateron - クリア リニア - 27g 40g
Gateron - リニア - 43g 55g
Gateron - リニア - 50g ?
Gateron - リニア - 50g ?
Greetech - クリック 60g 50g 55g
Greetech - タクタイル 60g 39g 55g
Greetech - リニア - 42g 55g
Greetech - リニア - 56g 78g
Kaihua - クリック 53g 31g 50g
Kaihua - クリック 42g 40g 55g
Kaihua - クリック 55g 50g 60g
Kaihua - 箱白 クリック ? 50g ?
Kaihua - スピードゴールド クリック ? 60g ?
Kaihua - スピードプロライトグリーン クリック ? 50g ?
Kaihua NovelKeys x Kaihua クリック 66g 30g 49g
Kaihua NovelKeys x Kaihua パールブルー クリック 57g 42g 65g
Kaihua NovelKeys x Kaihua ネイビー クリック 77g 40g 67g
Kaihua InputClub HakoViolet(バイオレット) タクタイル 39g 28g 50g
Kaihua InputClub HakoTrueピンク) タクタイル 58g 58g 94g
Kaihua InputClub HakoClear(クリア) タクタイル 63g 54g 79g
Kaihua InputClub HaloTrue(サーモン) タクタイル 60g 54g 100g
Kaihua InputClub HaloClear(クリア) タクタイル 65g 52g 78g
Kaihua - タクタイル 50g 42g 60g
Kaihua - タクタイル 45g 29g 65g
Kaihua - 箱茶 タクタイル ? 50g ?
Kaihua - スピードカッパー タクタイル ? 50g ?
Kaihua - スピードプロパープル タクタイル ? 50g ?
Kaihua NovelKeys x Kaihua ロイヤル(紫) タクタイル 65g 29g 55g
Kaihua NovelKeys x Kaihua タクタイル 59g 46g 70g
Kaihua - リニア - 28g 53g
Kaihua - 箱赤 リニア - 37g 55g
Kaihua - スピードシルバー リニア - 40g ?
Kaihua - リニア - 50g 65g
Kaihua - スピードプロブルゴーニュ リニア - 50g ?
Kaihua NovelKeys x Kaihua リニア - 57g 82g
Kaihua - リニア - 60g ?
Kaihua - 箱黒 リニア - 60g ?
Kaihua - スピードブロンズ リニア - 60g ?
MOD - H(橙) タクタイル ? 62g 78g
MOD - L(マゼンタ) タクタイル ? 45g 62g
MOD - M(シアン) タクタイル ? 55g 68g
MOD - SH(緑) タクタイル ? 70g ?
MOD - L(マゼンタ) リニア - 45g ?
MOD - M(シアン) リニア - 55g ?
MOD - H(橙) リニア - 62g 80g
Outemu - クリック 63g 47g 60g
Outemu - タクタイル 54g 40g 60g
Outemu - リニア - 47g 61g
Outemu - リニア - 66g 84g

Lambda + GolangでEC2インスタンス起動時にRoute53へレコード登録する

github.com

ありそうでそれっぽいものがなかったので、なら作ろう、ということで勉強中のGolangを使い、こちらの記事を参考にGolangでEC2インスタンスが起動したらRoute53へレコード登録するモノを作ったので、その際にハマったポイントをメモ。

CloudWatch eventsを使ってEC2起動時にTagチェックをし必須TagがなければTerminateするLambdaサンプル - Qiita

最重要事項:ドキュメントをよく読む。

Lambda 関数ハンドラ (Go) - AWS Lambda

今回はCloudWatchEventを使ってLambdaをキックするだけ。流れは、

  1. CloudWatchEventでキックされたLambdaは例にしたがってlambda.startする
  2. lambda.startで指定したハンドラの第2引数はgithub.com/aws/aws-lambda-go/eventsのCloudWatchEvent
  3. CloudWatchEventからインスタンスの情報を取得
  4. 3で取得した情報を基にRoute53へレコード登録

と簡単なモノ。既にレコードがある場合はエラーになります。更新とか出来るけど、意図せず変わってしまうのも危険なので割り切って新規登録だけに。

真っ先に参考にさせてもらったサイト。

AWS LambdaにGoサポートが入ったので使ってみた | ブログ :: Web notes.log


流れの2では第2引数でCloudWatchEventが取れるということすらわからず1、2時間さまよった結果どこかで見たのだけど、メモするのを忘れた。。。

func Handler(ctx context.Context, event events.CloudWatchEvent) () {
...
}

とりあえず色々なイベントがあらかじめ定義されていて引数に取れるようです。参考サイトの情報から、もしかしたら、という予想でやってみたらうまく行った、という流れの可能性もあったかもしれないけど、どこか参考ページと思われるところがあれば紹介してもらえると助かります。


流れの3ではこちらの記事を参考にインスタンスの情報を取ることに成功。

AWS SDK for Go でEC2インスタンス情報取得 - Qiita

コピペしただけでは意味がないのでドキュメントも読み、理解を深める。ただ、2でインスタンスのIDが取れているので、全インスタンスの情報を取得するのはよろしくない、ということでインスタンスIDを基に情報を取得した。(絞り込み出来てるはず・・・

ec2 - Amazon Web Services - Go SDK


流れの4はひたすらドキュメントを読み解き、最終的にドキュメントにサンプルコードがあり、それを参考にすることでレコード登録が出来た。

route53 - Amazon Web Services - Go SDK

Readmeとか英語にしないと!と思ったけど意味通じなくなるので、開き直って日本語で書きました。

はてなブログの投稿をTwitter連携した

はてなブログのアカウント設定から外部アカウント連携しただけで、その投稿テストなので内容は無い!

ちなみに、予約投稿でないとTwitterに投稿ツイートしてくれないのね。。。

AmazonLinuxでRailsを動かす(2018年4月版)

毎回nokogiriにしてやられるのでメモ。不要なものもありそうだけど、とりあえず。あと、ちょっとバージョン変わったり、ubuntuとかAmazonLinux2、CentOS7等の別Linuxでも似たようなモノ入れれば大体いけるはず。

今回使ったモノ

$ yum install -y ruby24 ruby24-devel mysql57-devel gcc-c++ glibc-headers libyaml-devel zlib-devel libxml2-devel libxslt-devel
$ alternatives --config ruby # ruby2.4に切り替え
$ gem install --no-ri --no-doc nokogiri -- --use-system-libraries
$ gem install --no-ri --no-doc rails
$ rails new test-project -d mysql -B
$ cd test-project
$ vi Gemfile
   追記> gem 'json'
   追記> gem 'mini_racer'
$ bundle install
$ rails s

これでほぼバニラ状態であれば動くはず。DBは好きなモノに変えちゃって良い。 mini_racerの代わりにnode入れてもいいし、そもそもそのへん使わないという場合はコメントアウトしてしまおう。

API-Gatewayのリクエスト検証をServerlessで設定する

Webコンソールからはぺろっと出来る設定ですが、Serverlessで設定しようとしたところ、あんまり情報がなかったのでメモ。

Webコンソールにある2つのチェックルールはデフォルトでは定義されておらず、aws cliで確認しても情報は出てこない。
一度選択して設定してやると新規で定義されてaws cliでも出て来るようになる。なので、Serverlessではチェックルールを定義するところからしてやる必要がある。
あとあるあるパターンで英語のAWSドキュメントじゃないとMethodに与えるプロパティ「RequestValidatorId」が載ってなくてハマってた。

resources:
  Resources:
     TekiTouVal:
       Type: AWS::ApiGateway::RequestValidator
       Properties:
         Name: TekiTouValidator
         RestApiId:
           Ref: ApiGatewayRestApi
         ValidateRequestParameters: true
     TekitouMethod:
       Type: AWS::ApiGateway::Method
        略
        RequestValidatorId:
          Ref: TekiTouVal
        略

参考

AWS::ApiGateway::RequestValidator - AWS CloudFormation

Docker + Rancher + Portainer 開発環境構築編

前回で初期設定が完了したので、それっぽい開発環境を作っていきます。
Docker + Rancher + Portainer 導入〜初期設定編 - 二度忘れた事を三度忘れないようにする

1.Rancherにアクセスし「Add Stack」を押してStackを作成する。 (今回はデフォルトの環境を利用
f:id:knhko:20170730165608p:plain
ここで、オプションで普段利用しているdocker composeファイルを指定したり、Rancher用のcomposerファイルを作成して指定することが出来ます。

2.作成したStackに「Add Service」を押してServiceを登録する。
f:id:knhko:20170730171126p:plain
1つ目のブロックでコンテナをいくつ起動するかをここで設定できますが、今回は開発用なので1つにします。
Side Kick Containerというものがありますが、今回は利用しません。というか詳細を理解出来てません。。。恐らくメインとなるサービスに対して依存関係のあるモノ(DB等)を関連付けて一緒に動かすモノだと思うのですが。。。
2つ目のブロックでサービスの名前、説明、利用イメージを指定します。「Port Map」でホストOSで待ち受けるポートとコンテナで待ち受けるポートのマッピングを行えます。「Service Links」は既に作成しているサービスにアクセスする際はここで指定します。

f:id:knhko:20170730173816p:plain
次にDockerの詳細設定が出来るので必要に応じて入力します。コンソールの種類もココで設定出来るので、開発では便利なオプション「-i -t」を指定します。

f:id:knhko:20170730180700p:plain
Volumesタブの「Volumes」でホストOSのディレクトリをコンテナから参照出来る様にします。例のとおり「ホストのボリュームまたはディレクトリパス:コンテナのマウントポイント:権限」という順番で記述します。

他にもIPアドレスドメイン、セキュリティ、CPU・メモリリソースのリミット等をGUIで簡単に設定できます。
なお、通常のdockerコマンドと同様にコンテナを作成するとコンテナ数、名前、ServiceLinksしか変更出来なくなります。

3.起動したコンテナの整備をする。
色々な手法で構築済みコンテナを準備出来ます。今回はRancherのWebコンソールを使ってnginxとphp-fpmを入れました。
f:id:knhko:20170730191200p:plain

4.同様の手順でMySQLのコンテナを準備する。
明示的に設定していなければ同じStack内のサービスであればServiceLinkすることなく疎通可能なはず。。。設定しておくとStackトップページでLink図が綺麗になるくらい、なはず。。。

5.LBを作成する。 Stackトップページの「Add Service」右にある記号をクリックすると、Service以外も作成出来るので、LBを作成します。
f:id:knhko:20170730192606p:plain
ぱっと見ただけでもAWSのELB/ALBと同等からそれ以上のLBを導入出来るのがわかりますね。
1つ目のブロックはLBもコンテナベースで動くようなのでサービス同様コンテナの数を指定出来ます。
2つ目のブロックはLBの振り分けルールを一括で設定する箇所になります。

Access - Dockerクラスタ外部から通信を受け付ける場合はPublic、それ以外はInternalで良いはず。
Protocol - HTTP/S,SNI,TCP,TLSと幅広く対応しており、選択プロトコルによって以降の選択項目が変化します。今回はHTTP/Sで進めます。
Request Host - ドメインレベルの分散ルールが書けるのです。AWSにはない地味だけど便利な機能です。これを使うとローカル開発環境ではすごく助かったりします。
Port, Path - 待ち受けポートとリクエストパスで、この辺はAWSのソレと変わりないかと思います。
Service - 分散先をService単位で設定します。AWSでいうTargetGroupかな。
Port - Serviceで待ち受けているポートを指定します。これは各コンテナで待ち受けているポートで良いのでWebサーバであれば80,443となります。
※Selector Ruleは未検証なのでどういったものか詳しい方教えてください。。。

3つ目のブロックでSSLやStickyの設定、haproxyのコンフィグを直接書くといったことが出来ます。

6.完成。のはず

以上、アプリ周りは端折りましたが、ローカル開発環境レベルであれば実用に耐えられるかと思います。