ghq + pecoでターミナルを快適化してみる

概要

Gitをターミナルで操作するようにしたが、リポジトリ間の移動がやや面倒くさい。
そんなときにこの構成を知ったので試していく。

ghqとは

pecoとは

  • テキストのリストをgrepしてそれに対してなにかコマンドを起動する事ができるツール。

導入方法

Mac

  • ともにhomebrewで導入できる
brew install ghq
brew install peco

windows

choco install peco
go install github.com/motemen/ghq
alias g='cd $(ghq root)/$(ghq list | peco)'

使い方

ghq get Gitリポジトリ
cd $(ghq root)/$(ghq list | peco)
code $(ghq root)/$(ghq list | peco) -r
  • CUIでPhpStormを開く
open -b com.jetbrains.phpstorm $(ghq root)/$(ghq list | peco)

最後に

これで快適なGitライフを

参考

EC2にポリシーをつけて、fluentdでログを飛ばす

概要

EC2のログをfluentdでCloudWatchに投げる - juve534のブログ

前回の実装時に、IAMでユーザを作って、設定ファイルに記載しました。 ただ、設定ファイルにユーザの情報が載ってしまうので、セキュリティが気になると思いました。
そこでロールを作成し、EC2に付与します。

# 対応 IAMでロールを作成します。 今回はCloudWatchにフルアクセスできるロールを新規に作成しました。

ロール作成画面
IAMロール作成

これをEC2にアタッチします。 アクション>インスタンスの設定 からIAMロールの割当を行ってください。

これで準備はOKです。 あとは前回の設定ファイルを修正します。

変更点は設定ファイルからキーとシークレットキーの削除になります。

# アクセスログ
<source>
  @type tail
  format apache
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/httpd.access.log.pos
  tag td.apache.access
</source>

# logsへログを転送
<match td.apache.**>
  @type cloudwatch_logs
  region ap-northeast-1
  log_group_name apache
  auto_create_stream true
  use_tag_as_stream true
</match>

設定を変更したら、fluentdを再起動して、Apacheにアクセスしてみました。

systemctl restart td-agent
curl http://127.0.0.1

CloudWatchをみると正常にログが吐き出されていることが確認できました。

まとめ

ユーザを作成しなくても、EC2にロールを付与することで、CloudWatchにログを投げることができました。

LaravelでResponderを使ってみる

概要

Laravel本ADRパターンというのが紹介されていました。

それの実装について、メリットがピンと来ていなかったのですが、下記のスライドで理解できました。

speakerdeck.com

そこでLaravelでADRのResponderを使ってみようと思います。

実装

書いてみたコードはこちら。

github.com

PostsShowJsonResponderにステータスコードとメッセージの出力を任せました。
データが無いときは ModelNotFoundException を吐くので、コントローラーでキャッチして、 null を返すようにしてみました。
※データが無いときは404にしたいから

例外時のステータスコードはもうちょっとやりようがあるなと思いました。

感想

Responderに出力を任せられるので、コントローラーが薄くなって良いなと思いました。
実際はもっとステータスコードを分けると思うので、その時にResponderがきれいになるようにしたいです。

EC2のログをfluentdでCloudWatchに投げる

概要

fluentd でEC2のログを CloudWatchLog に投げていきます。

導入

まずは公式サイトに沿って導入します。

$ curl -L https://toolbelt.treasuredata.com/sh/install-amazon2-td-agent3.sh | sh

次にCloudWatchに投げたいので、プラグインを導入します。
プラグインfluent-plugin-cloudwatch-logsを使います。

$ td-agent-gem install fluent-plugin-cloudwatch-logs

次にApacheをインストールします。 fluentdがアクセスできるように、ログディレクトリの権限変更も行います。

$ yum install -y httpd
$ chmod 777 -R /var/log/httpd

これで事前準備はOKです。

設定

設定は /etc/td-agent/td-agent.conf に記載します。
今回はテストとして、Apacheのログをターゲットにします。

# アクセスログ
<source>
  @type tail
  format apache
  path /var/log/httpd/access_log
  pos_file /var/log/td-agent/httpd.access.log.pos
  tag td.apache.access
</source>

# logsへログを転送
<match td.apache.**>
  @type cloudwatch_logs
  region ap-northeast-1
  aws_key_id キー
  aws_sec_key キー
  log_group_name apache
  auto_create_stream true
  use_tag_as_stream true
</match>

これで設定はOKです。

では早速動かしてみます。

$ systemctl start td-agent

これで起動したので、ログを吐き出してみます。

$ curl -vvv http://127.0.0.1

するとCloudWatchのapacheロググループに、td.apache.accessというログストリームができ、Apacheアクセスログがあることが確認できると思います。

簡易的ですが、以上で終了です。

EC2のログをawslogsでCloudWatchに投げる

概要

EC2のログをGUI上から確認したいと思っていました。 ログを投げるやり方は、 fluentdでやったことがありましたが、単純に、CloudWatchに投げるなら、 awslogs というのがあるそうです。
そこで下記記事を参考に awslogs を試しています。

【簡単】EC2でのCloudWatchLogsの使い方 - Qiita

導入

事前準備として、IAMユーザを作成しておきます。
お試しするなら、下記でOKでした。

  1. EC2に ssh で入る
  2. とりあえず、 sudo yum update
  3. sudo yum install -y awslogs
  4. /etc/awslogs/awscli.conf に設定を書く
  5. service awslogs start

これでコンソールを確認すると、 /var/log/messages にログが出ていました。

f:id:juve534:20191108022340p:plain

まとめ

CloudWatchに投げるなら awslogs は手軽で良いなと思いました。

CloudFormationで値を動的にする

概要

CloudFormation入門 - juve534のブログ

でCloudFormationに入門したのでその続き。 今回は値を動的にする方法を学びました。

内容

前回作ったものは値が動的になっており、そのまま使い回しができない状態になっています。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  FirstVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

これはVPCなので、ピンと来ないかもしれません。 では、EC2で見てみましょう。

 FirstEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: 't2.micro'
      SecurityGroupIds: 
        - !GetAtt FirstSecurityGroup.GroupId
      SubnetId: !Ref FrontendSubnet
      ImageId: 'ami-id'
      KeyName: '鍵名'

このテンプレートでいうと、AMIのIDやsshで使う鍵は動的にしたいと思いました。
また、Git等のバージョン管理に上げるときに、隠したいとも思います。

なので、Parametersを使って動的にします。

Parameters:
  # SSH用キーペアの指定
  KeyPair:
    Description: KeyPair Name
    Type: AWS::EC2::KeyPair::KeyName
  AmiId:
    Description: AMI ID
    Type: AWS::EC2::Image::Id

 FirstEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: 't2.micro'
      SecurityGroupIds: 
        - !GetAtt FirstSecurityGroup.GroupId
      SubnetId: !Ref FrontendSubnet
      ImageId: !Ref AmiId
      KeyName: !Ref KeyPair

Parametersには2つ定義を作りました。
KeyPairはコンソール上でいくつか作っていたので、既存のものを流用しています。 AMIも同様にいくつか作っていたので、流用できるようにしました。

これで、CloudFormationのコンソール上からテンプレートをアップし、Parameterを定義しました。

目論見通り、動的に値を変えられました。

まとめ

Parametersを使うことで、値を動的に変更できる。
テンプレートを使い回しに有効そうでした。

CloudFormation入門

概要

  • AWS用の構成管理ツール
  • JSONyamlで記載
  • スタックで管理
    • リソースの集合体(EC2, WAF)

AWSで構成管理できる。
スタック単位で管理し、スタックにはリソースの集合体がぶら下がる。
そのため、スタックの構築や破棄でAWSのリソースを操作できる。

JSONyamlで管理されているため、コードとして保存することができ、再現性が高くなっている。
※属人化を解決しやすい

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  FirstVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

2019/10/30現在もAWSTemplateFormatVersionは'2010-09-09'を定義すれば良いっぽい。 (FYI 形式バージョン - AWS CloudFormation)

Resources:
  <Logical ID>:
    Type: <Resource type>
    Properties:
      <Set of properties...>

Resourcesはリソースを定義する箇所。
VPCでもEC2でも、利用したいリソースを定義する。

  • Logical ID
    • テンプレート内で一意の値
    • 他のリソースから参照するときに使える
    • スタックの一覧もこの名前ででる
  • Resource type
    • 実際に作成したいリソース
  • Resource properties
    • 各リソースの作成時に指定するプロパティ
    • CidrBlockとかVPCのIDとか

下記のテンプレートは、FirstVPCという名前で、 10.0.0.0/16 をレンジとするVPCを作成している。

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  FirstVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16

参考