ghq + pecoでターミナルを快適化してみる
概要
Gitをターミナルで操作するようにしたが、リポジトリ間の移動がやや面倒くさい。
そんなときにこの構成を知ったので試していく。
ghqとは
pecoとは
- テキストのリストをgrepしてそれに対してなにかコマンドを起動する事ができるツール。
導入方法
Mac
- ともにhomebrewで導入できる
brew install ghq brew install peco
windows
- pecoはchocolateyでインストール
- ghqはGoで取得
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)
- VSCodeを立ち上げ
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にフルアクセスできるロールを新規に作成しました。
これを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パターンというのが紹介されていました。
それの実装について、メリットがピンと来ていなかったのですが、下記のスライドで理解できました。
そこでLaravelでADRのResponderを使ってみようと思います。
実装
書いてみたコードはこちら。
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でした。
- EC2に ssh で入る
- とりあえず、
sudo yum update
sudo yum install -y awslogs
/etc/awslogs/awscli.conf
に設定を書くservice awslogs start
これでコンソールを確認すると、 /var/log/messages
にログが出ていました。
まとめ
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で構成管理できる。
スタック単位で管理し、スタックにはリソースの集合体がぶら下がる。
そのため、スタックの構築や破棄でAWSのリソースを操作できる。
JSONやyamlで管理されているため、コードとして保存することができ、再現性が高くなっている。
※属人化を解決しやすい
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