コピペコードで快適生活

明日使えるソースを自分のために

GoogleAnalyticsメモ

ユーザ

https://support.google.com/analytics/answer/2992042?hl=ja
ユーザとは、Analyticsからcookieに振られたUserIDで判別される。
つまりブラウザが変われば別ユーザとカウントされる。

セッション

https://support.google.com/analytics/answer/2731565?hl=ja
セッションとは1ユーザのひとまとまりの行動
以下でリセットされる。

- 時間による期限切れ:
  - 操作が行われない状態で 30 分経過した後
  - 午前 0 時
- キャンペーンの切り替わり:
  - キャンペーン経由でサイトにアクセスして離脱した後、別のキャンペーン経由でサイトに戻ってきた場合

GoogleAnalytics APIメモ

https://ga-dev-tools.appspot.com/query-explorer/ https://support.google.com/analytics/answer/1008004?hl=ja

所感

cookieベースでユーザとセッションを測定しているので、アクセスログだけから同じ精度の集計を行うのは難しい。
アクセスログからはページビューを出すくらいが限度かな。

BigQueryのクエリ料金メモ

BigQueryのクエリ課金にビビっていたので、課金ルールを確認した。

  • テーブルスキャンした対象の列のデータ量に応じて課金される
    • SELECT * やると全列分に課金されるので、必要な分だけに絞る。
  • インデックスはないのでフルスキャン
    • whereに何書いてもフルスキャンされる
    • テーブル分割することでスキャン対象を絞ることができる
  • キャッシュ
    • クエリの結果は匿名データセット(=キャッシュ)に保存される
    • クエリはまずキャッシュがあるかチェックする
    • キャッシュを返す場合はコストゼロ
  • dry-runで走査するデータ量を確認できる
    • dry-runはbqコマンドのオプション指定で実行できる
    • 2021-01-05時点でconsoleからはできない模様 → でもクエリ実行前に走査量は確認できる
  • link

ChefZero覚え書き

はじめてChefZeroのコード読むことになったので、調べたこと覚え書き。

インストール

ここからDL https://downloads.chef.io/products/chefdk

knife-zeroインストール

chef gem install knife-zero --no-document

node

# 対象サーバのリストを出力する
knife node list

# 環境をリスト出力する
knife environment list

# 環境(development)を作る
knife environment create development

# サーバ追加
# サーバに接続してサーバ情報をnodes/test_node.jsonに書き出す
# 情報もりもりなので、.chef/knife.rb で knife[:automatic_attribute_whitelist] を指定して書き出す属性を絞ったほうがいい
knife zero bootstrap test-server.com:<ポート> -x test_user --sudo -N test_node

# nodeに実行するrecipeを追加
knife node run_list add 'test_node' 'recipe[sample_cook::default]'

# recipe実行
# knife zero converge QUERY (options)
knife zero converge name:test_node -x test_user --sudo

.chef/knife.rb

knife[:automatic_attribute_whitelist] = %w(
  fqdn/
  os/
  os_version/
  hostname
  ipaddress/
  roles/
  recipes/
  ipaddress/
  platform/
  platform_version/
)

cookbook

# cookbook作成
chef generate cookbook cookbooks/sample_cook

# recipeを作る例
# cookbooks/sample_cook/recipes/default.rb
package 'vim' do
    action :install
end

role

Chefにおけるロールとは、同じ役割のサーバをまとめて管理するための仕組みである。 例えばWebサーバーが5台あった場合、同じ設定をサーバごとに用意しては手間が増えるしミスの可能性も高くなるが、 webというロールを用意して、webロールに対してランリストなどを記述することにより、個別のサーバーへの設定はロールを適用するだけで済むようになる。

## 作成
bundle exec knife create my_role

## 編集
bundle exec knife edit my_role

roles/my_role.json

{
  "name": "my_role",
  "description": "",
  "json_class": "Chef::Role",
  "default_attributes": {

  },
  "override_attributes": {

   },
   "chef_type": "role",
   "run_list": [
     "recipe[xxx]"
   ],
   "env_run_lists": {
     "production": [
       "recipe[yyy::zzz]"
     ]
   }
}

recipe

%w(
  bind-utils
  nagios-plugins
  nagios-plugins-all
).each { |name| package name }

include_recipe 'mackerel-agent'
include_recipe 'mackerel-agent::plugins'

package 'mackerel-check-plugins'
  • package は環境に合わせてよしなに yum installapt-get に置き換えてくれる
  • include_recipe は、recipeを取り込む。
    • 依存するrecipeは、#{COOKBOOK}/metadata.rb} に書き込む必要がある
    • 外部cookbookも使える

attribute

上書きされる順番は弱い順にAttribute→recipe→Environment→Role。
Attributeの強さは弱い順にdefault→force_default→normal→override→force_override→automatic。

Berkshelf

外部クックブックのインストール管理できるbundlerみたいなやつ。
Berksfile に参照するcookbookを書いて、以下でインストールできる。

# vendor/cookbooks ディレクトリにインストールする例
berks vendor vendor/cookbooks

外部クックブックはここにまとめてある。 https://supermarket.chef.io/

DryRun

# --why-run オプションで DryRun が実行される。
# 実行結果に Would xxxx と緑で表示されるのが、実際に実行される処理。
bundle exec knife zero converge 'name:node_name' -a ipaddress --why-run

chefのバージョンアップ

bundle exec knife zero converge 'name:#{SERVER_NAME}' -a ipaddress --why-run --client-version 13.12.14

gem install

サーバ内でChefRuby用のgemを直接インストール

sudo /opt/chef/embedded/bin/gem list | grep xxx
sudo /opt/chef/embedded/bin/gem install xxx

参考

Terraform覚え書き

滅多に使わなくて忘れると思ったので。

terraform install

tfenvでバージョン切り替えできる

コマンド

# 必要となるpluginをインストールする。
terraform init

# 設定ファイルが正しいかチェック/本番環境との差分出力
terraform plan

# チェックの通った設定ファイルを本番環境に適用する
terraform apply
  • tfstateファイルはapplyのたびに生成される、現在の環境状態を表したJSONファイル。

設定ファイル

# 設定ファイルの拡張子は *.tf

# providerにはawsやopenstackが入る
provider "xxx" {
}

# 実際に作成するリソースを定義する
resource "aaa(リソースの種類)" "bbb(リソースの名前)" {
}
  • terraformがビルドに使うのはカレントディレクトリにある.tfファイル
  • リソースの種類は、プロバイダーがAWSの場合はaws_*という名前でTerraformで予め定義されています。VPCであればaws_vpc、EC2であればaws_instanceです。

変数の定義と参照

variable "access_key" {}
variable "secret_key" {}

provider "aws" {
    access_key = "${var.access_key}"
    secret_key = "${var.secret_key}"
    region = "ap-northeast-1"
}

変数代入は下記3種あり

  • オプション渡し
  • 環境変数渡し
  • ファイルで定義 (terraform.tfvars, variables.tf)

output

outputを指定することで、terraformコマンド実行時に指定した属性値がコンソール上に出力できる。

output "public ip of cm-test" {
  value = "${aws_instance.cm-test.public_ip}"
}

Module

モジュールの定義

# modules/VPC/main.tf

variable "vpc_cidr_block" {}
variable "vpc_name" {}

resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr_block
  instance_tenancy     = "default"
  enable_dns_hostnames = true

  tags = {
    Name = "${var.vpc_name}-vpc"
  }
}

モジュールを組み込む側

# module.tf

module "vpc_hoge" {
  source         = "./modules/VPC"
  vpc_cidr_block = "10.0.0.0/16"
  vpc_name       = "hogehoge"
}
  • これで、./modules/VPC/main.tf で定義された resource をベースにしたモジュールができる。
  • 参照先にresourceが複数ある場合は、module読み込みで全部作成される。
  • 指定した値(vpc_cidr_blockやvpc_name)は、module内の変数に渡される。

同じリソースを複数作る

resource "openstack_compute_floatingip_associate_v2" "example" {
  count       = "${var.example_count}"
  floating_ip = "${element(openstack_networking_floatingip_v2.example.*.address, count.index)}"
  instance_id = "${element(module.example.ids, count.index)}"
}
  • countは、作成するリソースの数。
  • elementは、element retrieves a single element from a list.

DataResources

リソースのデータを取得する。

以下の例では、data "openstack_networking_subnet_v2" を使うことで、openstack_networking_subnet_v2 リソースのデータを取得できるようになる。

# 定義
data "openstack_networking_subnet_v2" "subnet" {
  name = "subnet_1"
}

# subnet_1のデータを参照する
module "app" {
  cidr = "${data.openstack_networking_subnet_v2.subnet.cidr}"
}

https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs/data-sources/networking_subnet_v2

参考サイト

ctagsメモ

インストール

# メンテが止まっている
# exuberant-ctags
brew install ctags

# こっちを使う
# universal-ctags
brew install --HEAD universal-ctags/universal-ctags/universal-ctags

設定

# ~/.ctags

--append=yes
--recurse=yes
--php-kinds=cfd
--ruby-kinds=cfm
  • append=yes → tagsが既にあれば上書きではなく追加
  • recurse=yes → 配下ディレクトリを再起的にタグ作成するかどうか(-Rと同じ)
  • [言語]–kind → なんのタグを作成するかの設定(c=classなど)

設定の確認

ctags --list-maps
ctags --list-kinds=ruby

.tagsの検索範囲を設定

vimでctagを使う場合に、カレントディレクトリからホームディレクトリまで .tags を探す

# .vimrc

set tags=.tags;~

# デフォルトはこちら
# :set tags=./tags,tags

tagsファイルの作成

プロジェクトディレクトリに移動して

ctags -R --languages=Ruby -f .tags

で、プロジェクトディレクトリ直下に .tags ファイルが生成される。

  • f → 出力ファイルを指定。デフォルトはtags
  • R → 再帰的にファイルをチェックする

タグジャンプする

検索したいキーワードにカーソルを合わせて

  • CTRL-] → 現在のウィンドウでタグジャンプ
  • g CTRL-] → タグジャンプ先を候補表示する
  • CTRL-w] → ウィンドウを分割してタグジャンプ
  • CTRL-t → タグジャンプ先から戻る

参考

SSL通信が成立するまで

SSL通信に関して理解が微妙だったのに雑にメモ。

SSL通信が成立するまで

  • 秘密鍵は複合鍵
  • 公開鍵は暗号鍵
  • クライアントは共通鍵を作る。
  • サーバの公開鍵で暗号化して共通鍵を受け渡す。
  • その後の通信を共通鍵で暗号化して行う。
  • link

デジタル署名

X.509

p12ファイル

サーバのスペックをコマンドで確認する

現状のサーバのスペックを確認する必要があったので。

論理的なプロセッサ数を確認する

以下の場合は2個となる。

$ cat /proc/cpuinfo | grep processor
processor   : 0
processor   : 1

物理的なプロセッサ数を確認する

以下の場合は、idが2つあるため2個

$ cat /proc/cpuinfo | grep "physical id"
physical id : 0
physical id : 1

コア数を確認する

以下の場合は、1つのCPUにつき1コア

$ cat /proc/cpuinfo | grep "cpu cores"
cpu cores   : 1
cpu cores   : 1

ディスク容量を確認する

$ df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/vda1         50G  9.6G   41G   20% /

ディスクがSSDかHDDか

/sys/block/xxx/queue/rotational で、対象のデバイスがディスクかどうか確認する事ができる。 返り値が1の場合HDD、0の場合はSSDを使用している。

$ cat /sys/block/vda/queue/rotational
1

ネットワークの帯域計算

帯域 ≒ (データ・サイズ * 2)÷ 所要時間 [bytes/s] で計算できる。

$ ping -s 59992 xxx.example.com
60000 bytes from xxx.example.com (192.168.0.1): icmp_seq=41 ttl=62 time=1.71 ms

## 平均レスポンスタイム
cat ping.txt | awk '{print $8}' | sed -e 's/time=//g' | awk '{sum+=$1} END {print sum/NR}'
1.85512

平均データ転送量

サーバが起動してからの転送量 / サーバが起動してからの時間 で算出できる。

# 転送量の確認
cat /proc/net/dev

# サーバが起動してからの秒数(左側の値)
cat /proc/uptime