2019-05-16

Google Analyticsを導入してみる

ネットワーク google analytics

まえがき
Google Analytics初期設定
- 「新しいアカウント」設定画面
はてなブログ側の設定
Google Analytics追加設定
- フィルタリング設定
ちょっと使ってみる
まとめ

まえがき

そこはかとなくアクセス数が増えてきたので、Google Analyticsを導入してみようと思います。
中学生の時にもちょろっとブログをやっていたのですが、その時とは全然桁が違って、ネット世界(？)が発達したな〜と感じます。
?

Google Analytics初期設定

はてなブログのヘルプに導入方法の項があったので、こちらを見ながら進めます。

help.hatenablog.com

「新しいアカウント」設定画面

このブログの場合、設定内容はこんな感じです。

トラッキングの対象: ウェブサイト
アカウント名: mizukichi3-hatena_blog
ウェブサイトの名前: yyp٩( 'ω' )و
ウェブサイトのURL: mizukichi3.hatenablog.jp
業種: オンラインコミュニティ
レポートのタイムゾーン: 日本
データ共有設定: 全てにチェック

個人でやってるブログなのでそんなに気を使わずに設定を行いました。
「アカウント名」については複数のサービスに導入する場合、プレフィクスとかつけると良さそうですね。
今回も他に解析したいものが出てきた場合に備えて{自分のアカウント名}-{サービス名}でつけてみました。

「トラッキングIDを取得」をクリックし、サービス規約に同意したらGoogle Analytics側の設定は完了です。

はてなブログ側の設定

ヘルプに記載の通り、ブログの詳細設定画面の「解析ツール」に「Google Analytics埋め込み」という項目があるので、そこにUAから始まるトラッキングIDを記載します。これで設定は完了です。
あんまりこの辺りの知識がないので、「記事書く時にいちいちトラッキングタグ埋め込んだりするのかな…」とか思ってたんですが、とても簡単ですね…！

Google Analytics追加設定

フィルタリング設定

自分のPCからのアクセスをカウントしないように設定します。
こちらもヘルプに記載があるのでその通り進めます。
下記サイト等で自分のグローバルIPアドレスを調べます。

www.cman.jp

そのIPアドレスを「フィルタパターン」欄に記入します。

ただ、個人の場合このIPアドレスは一時的なものであることが多いと思います。
IPアドレスは枯渇するかもしれないと問題になっているため、空いているIPを融通する仕組みが使われています。
そのためここでIPアドレスを設定しても、変わってしまう可能性があります。
IPアドレス枯渇問題についてはこちらの解説がわかりやすかったです。

www.nic.ad.jp

私はあんまり気にしないので、試しにやってみた程度ですが、気になる場合はまず自分が固定IPを持っているかどうか(ご家庭のインターネット契約時にオプション等で取得しているかもしれません)確認して、持っていない場合は、多分お金はかかりますが固定IPを取得するのもありかもしれないですね。
でも多くの場合はそこまでしなくていいとは思います。

ちょっと使ってみる

まだ導入しただけなので全然わかりませんが、色々できそうです。
カスタムのレポートの作成とかもできるみたいですね。

まとめ

はてなブログへのGoogle Analyticsの導入は特につまづくことなくできました。
ただ、私はWebサイト運営とかマーケティング周りの知見がほぼないのでどう活用できるのかがあんまり分からないな〜って感じです。
もしかしたら導入しただけで終わりになっちゃうかもしれませんが、今後もしもっと興味が湧いたら遊んでみようかな〜と思います。

2019-05-02

GitHubにpushされたらLambdaのテストを自動で実行したい(願望)

github aws 備忘

背景・目標
環境
Pipelineの作成
CodePipelineを動かしてみる
- buildspec.ymlを作成
- appspec.ymlを作成

背景・目標

前回の続き、Lambda関数の中身を作成しているのですが、
ローカルで編集→GitHubにpush→Lambdaコンソールにコピペしてテストという流れが結構面倒です。
Lambdaコンソールでテストしながらコードの修正をしてもいいのですが、そうすると自分がどこで間違ったのか残らないのでまた同じところで詰まりそうです。

なので、タイトルの通りGitHubにpushされたらLambdaのテストを自動で実行する仕組みを作りたいと思って試行錯誤中です。
この記事の結末としては、まだ実行環境は作れていないです。
解決方法を求めてここに辿り着いた方がもしいたら申し訳ありません。

環境

以前AWS上でのCI/CDハンズオンの勉強会に行ったことを思い出し、AWS CodePipelineで出来るような気がするので、一旦CodePipelineを使う方法で進めます。

Pipelineの作成

早速Pipelineを作っていきます。
CodePipeline > パイプライン > パイプラインを作成するで作成画面に移ります。

Step1 パイプラインの設定を選択する

この画面ではパイプラインの名前と、IAMロールを設定します。
パイプライン名はわかりやすい名前をつけて、ロールについてはパイプライン用のロールがまだないので、"New Service Role"を選んで新しく作ります。
こんな感じ↓
f:id:mizukichi3:20190429111120p:plain

Step2 ソースステージを追加する

この画面ではコードのソースを設定します。
今回はGitHubにpushされたらテストが動くように設定したいので、「ソースプロバイダー」はGitHubを選択します。
リポジトリ名とブランチ名はテストしたいリポジトリとブランチを選択します。
検出オプションはGitHubウェブフックを選択します。
GitHubウェブフックの説明文の「GitHub でウェブフックを使用して、変更が発生したときにパイプラインを自動的に開始」が今回やりたいことなので。
こんな感じです↓
f:id:mizukichi3:20190429112210p:plain

Step3 ビルドステージを追加する

この画面ではビルドする環境を追加します。
「プロバイダーを構築する」ではAWS CodeBuildとJenkinsが選択できるようになっています。
今回はAWS CodeBuildを使ってみたいと思います。
リージョンはTokyoを選択し、「プロジェクトを作成する」をクリックすると、ビルド環境の作成ページに移ります。
f:id:mizukichi3:20190429112814p:plain

ビルド環境の作成

この画面では実行環境を作成していきます。
Project configurationではProject nameにわかりやすい名前をつけます。
EnvironmentではManaged imageを選択し、各パラメータを↓のように設定します。
f:id:mizukichi3:20190429113902p:plain すぐ下にある「追加設定」と"Buildspec"はデフォルトのままにしています。
"Logs"はCloudWatch logsにチェックを入れます。
ここまで設定したら、"Continue to CodePipeline"をクリックしてからCodePipelineの作成ページに戻ります。
↓のように正常に作成されたメッセージが表示されていればOKです。
f:id:mizukichi3:20190429114846p:plain

Step4 デプロイステージを追加する

この画面ではデプロイ先を設定します。
今回はCodeDeployを使ってLambdaにデプロイしたいと思います。

CodeDeployでアプリケーションを作成する

まずCodeDeployでデプロイするアプリケーションの設定をします。
一旦CodeDeployの画面を別タブで開き、「アプリケーションの作成」をクリックして作成画面に移ります。
アプリケーション名にわかりやすい名前をつけて、「コンピューティングプラットフォーム」でAWS Lambdaを選択します。
f:id:mizukichi3:20190429115535p:plain 次にデプロイグループを作成します。
デプロイグループ名はわかりやすい名前をつけます。
サービスロールは"AWSCodeDeployForLambda"のポリシーを付与したロールをIAMコンソールで作成して選択します。
デプロイ設定は一旦デフォルトのままにします。
下の方にある「詳細」もデフォルトのままにします。
これでCodeDeploy側の設定は完了したので、デプロイステージの追加画面に戻ります。
アプリケーション名とデプロイグループで先ほど作ったものを選択します。

Step5 レビュー

設定内容を確認して、「パイプラインを作成する」で完了です。
作成後すぐにパイプラインが動きますが、初回だからということだと思います。
今後はpushしたら動く感じになるはずです…！

CodePipelineを動かしてみる

とりあえずHelloWorldでpushしてみます。
コードはLambdaを作成した時に最初に書いてあるものを使いました。

import json

def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

pushするとパイプラインが動き始めましたが、Buildの段階で失敗してしまいました。
詳細をみてみると、 YAML_FILE_ERROR: YAML file does not existというエラーが出ています。
buildspec.ymlを作ってGitHubに置かないといけないっぽいですね。

buildspec.ymlを作成

とりあえずこんな感じで作ってみました。
参考: docs.aws.amazon.com

version: 0.2

phases:
  install:
    commands:
      - pip install boto3
artifacts: 
  files:
    - '**/*'

今度はビルドは成功しましたが、デプロイに失敗しました。
詳細をみてみると、BundleType must be either YAML or JSONというメッセージが出ています。
調べてみると、appspec.ymlというファイルが必要みたいです。

appspec.ymlを作成

こちらを参考にappspec.ymlを作成してみました。

docs.aws.amazon.com

作成したappspec.ymlはこちら。

version: 0.0
resources:
  - name-of-function-to-deploy:
    type: "AWS::Lambda::Function"
    properties:
      name: HelloWorld
      alias: HelloWorld
      currentversion: "1"
      targetversion: "1"
hooks:
  - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
  - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"

こちらのファイルをpushしてみましたが、また同様のBundleType must be either YAML or JSONというメッセージが出てしまいました。
どうにも原因がわからないので、CodeDeployから手動でデプロイしてみます。
するともう少し詳し目のエラーメッセージが出ました。

The deployment failed because the AppSpec file that specifies the AWS Lambda deployment configuration is missing or has an invalid configuration. The input AppSpec file is a not well-formed yaml. The template cannot be parsed.

ymlファイルがどこか間違っているみたいです。
ここからはymlファイルを直しても全然進むことができなかったため、一旦保留にしたいと思います。
本当にやりたいのはLambdaを動かすことで、こちらの環境構築をやっているとLambdaの方が進まなくなっちゃいそうなので…

こちらの記事は自分用の手順書として残しておくことにします…
前回の記事のLambdaが作り終わったらこちらを再開してみようかなと思います。

2019-04-23

EC2インスタンスを夜になったら自動で停止する前編

aws

背景
方法を考える
- 1. Lambdaを使う方法
- 2. Systems Managerを使う方法
実装
次回: 関数の中身の作成

背景

個人のAWS環境のインスタンスを止め忘れてしまうことが度々あるので、この仕組みを作ることにしました。

方法を考える

1. Lambdaを使う方法

インスタンスを停止する関数を作り、CloudWatch Eventのcronで毎晩起動してあげればできそうです。
"Lambda EC2"でググったら公式のQ&Aもありました。

aws.amazon.com

2. Systems Managerを使う方法

Systems ManagerのAutomationドキュメントに"AWS-StopEC2Instance"というのがあります。
これをMaintenance Windowで毎晩実行するように指定してあげればできそうです。

実装

今回はLambdaの勉強も兼ねて、1. の方法で実装したいと思います。
上で載せたQ&Aを参考に進めていきます。

Lambda関数の作成

Lambda関数を作ります。
「一から作成」を選択して、関数名とランタイムを下記のように設定します。

関数名: StopEc2Instances
ランタイム: Python3.7

アクセス権限については今回はカスタムロールを作るので、
「関数のアクセス権限を定義するロールを選択します。カスタムロールを作成するには、IAM コンソールに移動します。」
からIAMコンソールに移動してロールを作ります。

IAMロールの作成

IAMロールを作ります。
「信頼されたエンティティ」は「AWSサービス」、「このロールを使用するサービス」は"AWS Lambda"を選択し、「次のステップ: アクセス権限」をクリック。
f:id:mizukichi3:20190423210041p:plain 今回はカスタムポリシーを使うので、「ポリシーの作成」をクリックしてポリシーの作成ページに飛びます。
f:id:mizukichi3:20190423210505p:plain "JSON"タブをクリックし、下記のポリシーを貼り付けます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Start*",
        "ec2:Stop*"
      ],
      "Resource": "*"
    }
  ]
}

「ポリシーの確認」をクリックし、名前をつけます。今回は"stop-instances-lambda-policy"にしました。
説明は入力しなくても良いので今回は省略します。
「ポリシーの作成」をクリックするとポリシーが作成されるので、作りかけになっていたロールの作成画面に戻ります。
更新ボタン(ぐるぐるしてる矢印マーク)を押して、先ほど作成したポリシーを探し、チェックボックスにチェックを入れます。
「アクセス権限の境界の設定」については今回は必要ないのでそのままで。
次のステップの「タグ」も現時点では必要ないのでスキップします。
ロールの名前をつけて、「ロールの作成」をクリックして終わりです。

Lambda関数の作成続き

作りかけになっているLambda作成画面に戻ります。
「アクセス権限」 > 「実行ロールの選択または作成」> 「実行ロール」プルダウンから「既存のロールを使用する」を選びます。
更新ボタンを押して、プルダウンを開くと先ほど作成したロールが出てくるので、選択します。
これで関数の箱ができました。

トリガーの設定

Lambda関数を動かすためのトリガーを設定します。
今回は毎日夜0時にインスタンスを停止するように設定します。
Lambdaコンソールで、「トリガーの追加」から"CloudWatch Events"を選択します。
「トリガーの設定」 > 「ルール」で「新規ルールの作成」を選択します。
名前をつけ、ルールタイプの設定をします。
今回は定刻にLambdaを起動したいので、「スケジュール式」を選択します。
「スケジュール式」に下記のcron式を入力します。

cron(0 15 * * ? *)

※ここではタイムゾーンがUTCなので、-9した値を使います。
こんな感じです↓
f:id:mizukichi3:20190423213317p:plain

次回: 関数の中身の作成

だいぶ長くなってしまったので、本題とも言えるLambda関数のコードを書くのは後編に分けようと思います。
東京リージョンのインスタンスをすべて停止するように、*とかで指定できるかなと思ったのですが、InstansIdsって必須なんですね…
IDのハードコードはなるべくしたくないので、一旦起動中のインスタンスのIDを持ってきて変数に入れるということが必要そうです。

2019-03-12

ドラえも〜〜〜ん！！インターネットが繋がらないよ〜〜〜！！

ネットワーク

ふと「ドラえも〜〜〜ん！！インターネットが繋がらないよ〜〜〜！！」とドラえもんに泣きつくのび太くん、という図が思い浮かんだので、
インターネットが繋がらなくなった時のTips的なやつをのび太くんとドラえもんの会話で書いてみます。

※のび太くんの持っているPCからブラウザでWebページを見ることができなくなったという想定で書きます。
サーバ - インターネット間の通信は今回は除外します。

※※完全に勢いで書いたので間違っている部分もあるかもしれません。ご承知おきください。

のび太「ドラえも〜〜〜ん！！インターネットが繋がらないよ〜〜〜！！」
どらえもん「どうしたんだいのび太くん」
のび太「ブラウザを開いたんだけど、インターネットが見れないんだよ〜〜〜」
どらえもん「まずはのび太くんのパソコンがインターネットに繋がれる状態かみてみよう」

Windowsであればタスクバー、MacであればメニューバーにあるWi-Fiっぽいマークが
ちゃんと表示されていることを確認します。
無線LANの場合はPCにケーブルが刺さっているっぽいマークが表示されていることを確認します。

ドラえもん「のび太くんはインターネットには繋がれる状態みたいだね」
のび太「じゃあなんで見れないの？」
ドラえもん「見ようとしたWebページとは別のページも見てみよう」

ここで表示できたら、そのWebページがあるサーバがダウンしているか、DNSの問題である可能性が高いです。

のび太「他のサイトは見れるよ」
ドラえもん「ふむふむ。のび太くんが見ようとしていたWebページのサーバがダウンしているかもしれないね」
ドラえもん「他のところにある問題という可能性もあるから、調べてみよう」
ー黒い画面を起動して何やら打ち込むドラえもん

DNSの問題かどうか調べます。
WindowsならコマンドプロンプトかPowershell, Macならターミナルを起動して、nslookupで名前が引けるかどうか確認します。
ここで名前が引ければ、DNSの問題ではなくサーバ側に問題がある可能性が高いです。
しばらく待ってからアクセスしてみましょう。

ドラえもん「名前が引けないから、DNSの問題かもしれないね。」
ドラえもん「見に行くDNSサーバを変えてみよう」

Windowsの場合「コントロールパネル」から、Macの場合「システム環境設定」から見に行くDNSサーバを変更します。
Googleが提供している8.8.8.8などのパブリックDNSに変更します。
※詳しい変更方法は割愛します。
それでも閲覧できなければ、サーバ側の問題がある可能性が高いので、しばらく待ってからアクセスしてみましょう。
利用者がたくさんいるサービスであれば障害情報を出しているかもしれないので、調べてみてもいいかもしれません。

のび太「わあ！見れたよ！ありがとうドラえもん！」
ドラえもん「よかったねのび太くん」
のび太「お礼にどら焼きをあげるよ！」
ドラえもん「ありがとうのび太くん！」

繋がったみたいですね。
今回の原因は、DNSサーバ側の問題でした。
のび太くんのPCが普段見に行っているDNSサーバがダウンしている等の問題が起こっていると考えられます。
変更したDNSサーバについては気になるようであれば元に戻しても良いですし、気にならなければそのままでいいと思います。

2019-02-18

tilリポジトリを作ってみる

github 勉強備忘

社内のチャットでGitHubのtilリポジトリというものについて話しているのを見かけたので、調べてみました。
tilは"Today I Learned"の略で、その日覚えたことを書いていくリポジトリみたいです。*1
私も結構わからないことがあって都度調べているので、こういう形で残しておくのもいいかなと思い、作ってみました。
(毎回ブログを書くとなると結構重い、というのもあります)

github.com

GitHub上で作成するか、自分のローカルで作ってpushするかは悩みどころですね。
Markdownで作ろうと思うので、とりあえずはGitHub上でやってみようと思います。

*1:例: https://github.com/jbranchaud/til

2019-01-27

MacでGitHubのセットアップをする

github mac 備忘 git

Gitを使う勉強会に行くのですが、まだMacにしてから使っていなかったので環境設定をしました。たまにしかしない作業なので自分のためのメモとして残しておきます。 Windowsの時もお世話になった、こちらを参考にさせていただきました。

qiita.com

目的

GitHubでpush/cloneができるようにする。
二段階認証も設定できるとなおよし。

環境

OS
- Mac OS X 10.14.2
ターミナル
- iTerm 3.2.6

Gitインストール確認&設定

まずGitをインストールだ〜と思ったら、Macはデフォルトで入っているんですね。

$ git --version  
git version 2.17.2 (Apple Git-113)

次にメールアドレスと名前を設定します。

$ git config --global user.email "you@example.com"
$ git config --global user.name "Your Name"

この設定をしていないとgit commitができません。

キーペア作成

GitHubと連携するために、キーペアを作ります。

$ mkdir ~/.ssh  
$ cd ~./ssh  
$ ssh-keygen -t rsa  
Generating public/private rsa key pair.  
Enter file in which to save the key (/Users directory/.ssh/id_rsa): #ここでキーペアの名前を変えられる

キーペアの名前を変えなければ/Users directory/.ssh/配下にid_rsaとid_rsa.pubができます。

ssh configの作成

キーペアの名前を変えている場合、ssh configの設定が必要です。

Host github github.com
  HostName github.com
  IdentityFile ~/.ssh/hogehoge #自分の秘密鍵をフルパスで  
  User git

GitHubと連携

GitHubに先ほど作成したキーペアの公開鍵(.pubがついている方)を置きます。
公開鍵と秘密鍵は間違えると大変なので注意！
GitHubにログイン > 右上の自分のアイコン > Settings > 左のメニュー"SSH and GPG keys" まで行きます。
New SSH keyで鍵の名前と中身を入力します。
Add SSH keyで内容を保存したら、接続確認。
自分のリモートリポジトリからcloneできるか確認します。

$ git clone git@github.com:hoge/fuga.git

※sudoでやるとできません。
cloneができたら次はpushできるか確認します。
READMEを作ってpushしてみます。

$ cd {cloneしてきたリポジトリのディレクトリ}  
$ touch README.md
$ git add README.md  
$ git commit -m "created README.md"
$ git push

pushが完了したら、GitHubで反映されているか確認。
反映されていたら、連携の設定は完了〜

二要素認証の設定

そんなに大事なものは置いていないのですが、公開鍵を置いているので一応二要素認証でログインするように設定します。
GitHubにログイン > 右上の自分のアイコン > Settings > 左のメニュー"Security" まで行きます。
"Enable two-factor authentication"をクリック。
"Set up using in app"と"Set up using in SMS"があります。
一応他のサービスでGoogle authenticatorを使っているのですが、電話番号で済むならそれがいいと思ったので、SMSにします。
クリックするとRecovery codeが表示されるので、ダウンロードやコピーで保存して置きます。
何らかの理由で接続できなくなった際の復旧に必要なので、失くさない！
保存したら"Next"で次に進む。
電話番号を入力して、SMSが来たら記載の6桁の数字を入力して完了！
今後はサインインの際にSMSで番号が届きます。

2018-12-16

MojaveでVirtualBoxがインストールできない〜暫定対応編〜

mac virtualbox

これのその後です。
mizukichi3.hatenablog.jp

VitrualBox6.0を入れてみる

Candidate版の6.0が出たみたいなので、これを入れてみました。

virtualbox.org • View topic - VirtualBox 6.0 Release Candidate 1 released

ですが結果は同じく、インストールに失敗。

ネットワーク周りがいじれない

よくみてみると、「アプリケーション」ディレクトリにVirtualBox自体は存在していました。
適当に仮想マシンを作成して起動しようとしてみると、カーネルモジュールがインストールされていないというエラーが出ました。
他にもネットワーク周りがいじれないようです。*1
Windowsだと「管理者として実行」すると解決する場合もあるので、sudoで起動等を試してみましたがだめでした...

回避策を試す

前回も触れた回避策を試してみます。