• Tips

    Capistranoで新規作成したEC2インスタンスにSSH接続する

    前回に引き続き、Capistranoで新たに作成したEC2インスタンスにSSHでログインしてみます。

    まず、事前準備として、AWS側で新規インスタンス用のキーペアを作成しておきます。AWSマネージメントコンソールの「EC2」メニューから「NETWORK & SECURITY」カテゴリの「Key Pairs」メニューで、キーペアを作成できるので、必要に応じて作成してください。本項の例では、「deploy-test」というCapistranoが稼動しているデプロイ環境用インスタンスで使用しているキーペアを使います。

    AWSマネージメントコンソール：キーペア

    そして、利用するキーペアのプライベートキーファイル（本項例ではdeploy-test.pemファイル）をCapistranoを実行するデプロイ環境のデプロイを実行するユーザのホームディレクトリ（本項例では/home/deploy-user/）にアップロードしておきます1。 アップロードしたプライベートキーには適切な読み込み権限を付与しておく必要があるので、ファイルのパーミッションを変更します。

    $ cd ~
$ chmod 600 deploy-test.pem
$ ls -l *.pem
-rw------- 1 deploy-user deploy-user 1692 Jul  2 10:18 deploy-test.pem

    デプロイ設定ファイルconfig/deploy.rbは下記のように修正。

    # config valid only for Capistrano 3.1
lock '3.2.1'

# AWS SDK for Ruby を読み込む
require 'aws-sdk'

# AWS SDK用の設定
AWS.config({
  :access_key_id => '<AWS ACCESS KEY ID>', 
  :secret_access_key => '<AWS SECRET ACCESS KEY>', 
  :region => 'ap-northeast-1', 
})

# AMIのimage_id
# Amazon Linux AMI 2014.03.2 (HVM)
set :ami_image_id, 'ami-29dc9228'

# 作成するInstance数
set :instance_count, 2

# 作成するInstanceタイプ
set :ec2_instance_type, 't2.micro'

# 作成先のAvailability Zones
set :availability_zones, [ 'ap-northeast-1a', 'ap-northeast-1c' ]

# 作成先のsubnet_id（必要に応じて）
set :subnet_ids, [ 'subnet-********', 'subnet-********' ]

# 使用するキーペア名
set :key_pair_name, 'deploy-test'

# プライベートキーファイル
set :privert_key_file, 'deploy-test.pem'

# 利用するセキュリティグループID
set :security_groups, [ 'sg-********', 'sg-********', 'sg-********', 'sg-********' ]

# Capistranoデフォルトのタスクを削除する
framework_tasks = [:starting, :started, :updating, :updated, :publishing, :published, :finishing, :finished]
framework_tasks.each do |t|
  Rake::Task["deploy:#{t}"].clear
end
Rake::Task[:deploy].clear

desc 'Launch an EC2 instance to each availability zone different'
task :launch do
  run_locally do
    ec2 = AWS::EC2.new

    created_instances = []
    cnt = 0
    while cnt < fetch(:instance_count) do
      if cnt.even? then
        current_az = fetch(:availability_zones)[0]
        current_sn = fetch(:subnet_ids)[0]
      else
        current_az = fetch(:availability_zones)[1]
        current_sn = fetch(:subnet_ids)[1]
      end
      i = ec2.instances.create(
        :image_id => fetch(:ami_image_id),
        :monitoring_enabled => false,
        :availability_zone => current_az,
        :subnet => current_sn,
        :key_name => fetch(:key_pair_name),
        :security_group_ids => fetch(:security_groups),
        :disable_api_termination => true,
        :instance_type => fetch(:ec2_instance_type),
        :count => 1,
        :associate_public_ip_address => true
      )
      sleep 10 while i.status == :panding
      created_instances << i.id
      cnt += 1
    end
    execute "echo -n #{created_instances} > ~/CREATED_INSTANCES"

  end
end

    では、インスタンスラウンチタスクを実行してみます。

    ...

  • Tips

    CapistranoでAWS EC2インスタンスをデプロイする時の注意点

    前回のデプロイ設定ファイルで新たに作成されたEC2インスタンスには、キーペアやセキュリティグループなどが設定されていなかったため、そのままでは作成したインスタンスにSSHでアクセスできませんでした…1orz

    その後、色々とデプロイ設定を修正して、作成したEC2インスタンスにSSHでログインするところまで出来たので、その経緯を備忘録として書いてみた次第。 まぁ、CapistranoでAWSのEC2インスタンスを作成する際…というより、「AWS SDK for Ruby」でEC2インスタンスを作成する時の注意点…に近いのかもしれない。

    まず、前回のconfig/deploy.rbからインスタンスラウンチのタスク部分を見てみる。

    desc 'Launch an EC2 instance to each availability zone different'
task :launch do
  run_locally do
    ec2 = AWS::EC2.new

    created_instances = []
    cnt = 0
    while cnt < fetch(:instance_count) do
      if cnt.even? then
        current_az = fetch(:availability_zones)[0]
        current_sn = fetch(:subnet_ids)[0]
      else
        current_az = fetch(:availability_zones)[1]
        current_sn = fetch(:subnet_ids)[1]
      end
      i = ec2.instances.create(
        :image_id => fetch(:ami_image_id), 
        :availability_zone => current_az,
        :subnet => current_sn, 
        :instance_type => fetch(:ec2_instance_type), 
        :count => 1
      )
      sleep 10 while i.status == :panding
      created_instances << i.id
      cnt += 1
    end
    execute "echo -n #{created_instances} > ~/CREATED_INSTANCES"

  end
end

    作成するインスタンスに対して、AvailabilityZoneとSubnetの設定しかしていないので、そりゃあアクセス不能になります。最低限、セキュリティグループを設定して、外部からのアクセス経路を確保して、キーペアを設定して認証ユーザがログイン可能にしてあげる必要はあります。あとは、PublicIP（PublicDNS）を自動で割り振られるようにして、インターネットからのアクセスも出来るようにしておくあたりまでが、最小設定となるかと。

    ...

  • Tips

    PV InstanceからHVM Instanceへ変換(CentOS6)

     

    準備するもの

    ① EC2 Instance(CentOS6)既存の動いているものでもOK ② 変換元のRoot deviceのSnapshot ③ ②から作成したEBS Volume (SSDのほうが作業が早い) ③ 空のEBS Volume (SSDのほうが作業が早い)

    DEVICEの確認

    # fdisk -l |grep dev
Disk /dev/xvda: 10.7 GB, 10737418240 bytes
Disk /dev/xvdb: 4289 MB, 4289200128 bytes
Disk /dev/xvdf: 10.7 GB, 10737418240 bytes <-PV環境のRoot device
Disk /dev/xvdg: 10.7 GB, 10737418240 bytes <-空のEBS Volume

    作業開始

    １．PVのDiskを縮小し、コピー容量を減らす

    ...

  • Tips

    Capistranoで異なるAvilabilityZoneにEC2インスタンスをラウンチする

    前回、

    次回はデータベースの作成や初期設定を直前タスクとして挿入して、さらにWordPressの設定ファイルの書き換え、GitHubからWordPressテーマをダウンロードするところまでやってみようと思います。

    とか云っていたのですが、都合によりCapistrano3を使ってAWSのEC2インスタンス作成を行ったので、そのTIPSを残しておこうかと思います。 今回は、デプロイ用のEC2インスタンスから公式のAMIを利用してAvailabilityZonesが異なるエリアにそれぞれEC2インスタンスを立ててみました。試験的に、AMIは最新のインスタンスタイプ「t2.micro」に対応した「Amazon Linux AMI 2014.03.2 (HVM)」を利用して、Tokyoリージョンの1aと1cのAvailabilityZoneにそれぞれ2台ずつ、合計4インスタンスを同時に立ててみます。

    ※ 事前準備として、インスタンスを立てるAWSアカウントにてVPCやSubnet等EC2インスタンスを作成する上で必要最小限の設定をしておく必要があります。特に今回は異なるAvailabilityZoneへのインスタンスを立てるのでそれぞれのゾーンにSubnetを設定しておく必要があります。

    さて、早速デプロイの手順です。 はじめに、デプロイ環境（サーバ）の設定を行うため、config/deploy/test.rbを編集します。 今回は動的に作成したEC2インスタンスをデプロイ環境とするため、事前のサーバ設定ができません。というのも、AWSで立ち上がる新規インスタンスにはElasticIPを付与しないので、毎回PublicIPが異なり、エンドポイントURLも動的に変わってしまうためです。なので、今回はインスタンスが起動した後にCapistoranoのタスクにて対象サーバを設定するようにします。 初期のサーバ設定は不要となるので、記述をコメントアウトしておきます。なお、SSHのオプションだけは最終的に共通で利用する予定なので残しておきます（今回のデプロイタスクでは使いませんが…）。

    $ vim config/deploy/test.rb

    #role :app, %w{deploy@localhost}
#role :web, %w{deploy@localhost}
#role :db, %w{deploy@localhost}

set :ssh_options, {
  keys: %w(/home/deploy/.ssh/id_rsa),
  forward_agent: true,
}

    今回のデプロイでは、「AWS SDK for Ruby」を利用するので、あらかじめSDKをインストールしておきます。

    $ sudo gem install aws-sdk

    次に、config/deploy.rbにデプロイ内容を設定します。

    $ vim config/deploy.rb

    # config valid only for Capistrano 3.1
lock '3.2.1'

# AWS SDK for Ruby を読み込む
require 'aws-sdk'

# AWS SDK用の設定
AWS.config({
  :access_key_id => '<AWSアカウントのACCESS KEY ID>', 
  :secret_access_key => '<AWSアカウントのSECRET ACCESS KEY>', 
  :region => 'ap-northeast-1', # EC2 Instanceを作成するリージョン
})

# AMIのimage_id
# Amazon Linux AMI 2014.03.2 (HVM)
set :ami_image_id, 'ami-29dc9228'

# 作成するInstance数
set :instance_count, 4

# 作成するInstanceタイプ
set :ec2_instance_type, 't2.micro'

# 作成先のAvailability Zones
set :availability_zones, [ 'ap-northeast-1a', 'ap-northeast-1c' ]

# 作成先のsubnet_id
set :subnet_ids, [ 'subnet-********', 'subnet-********' ]

# Capistranoデフォルトのタスクを削除する
framework_tasks = [:starting, :started, :updating, :updated, :publishing, :published, :finishing, :finished]
framework_tasks.each do |t|
  Rake::Task["deploy:#{t}"].clear
end
Rake::Task[:deploy].clear

desc 'Launch an EC2 instance to each availability zone different'
task :launch do
  run_locally do
    ec2 = AWS::EC2.new

    created_instances = []
    cnt = 0
    while cnt < fetch(:instance_count) do
      if cnt.even? then
        current_az = fetch(:availability_zones)[0]
        current_sn = fetch(:subnet_ids)[0]
      else
        current_az = fetch(:availability_zones)[1]
        current_sn = fetch(:subnet_ids)[1]
      end
      i = ec2.instances.create(
        :image_id => fetch(:ami_image_id), 
        :availability_zone => current_az,
        :subnet => current_sn, 
        :instance_type => fetch(:ec2_instance_type), 
        :count => 1
      )
      sleep 10 while i.status == :panding
      created_instances << i.id
      cnt += 1
    end
    execute "echo -n #{created_instances} > ~/CREATED_INSTANCES"

  end
end

desc 'Check the activation status of new instances'
task :check do
  created_instances_list = 'CREATED_INSTANCES'

  run_locally do
    ec2 = AWS::EC2.new

    begin
      if test "[ -f ~/#{created_instances_list} ]"
        created_instances = capture("cd ~; cat #{created_instances_list}").chomp
        ci = created_instances.gsub(/(\[|\s|\])/, '').split(',')
        target_instances = ec2.instances.select { |i| i.exists? && i.status == :running && ci.include?(i.id) }.map(&:private_ip_address)
        if target_instances.length == 0 then
          raise "No created instances"
        end
        target_instances.each { |var| 
          server var, user: 'ec2-user', roles: %w{web app}
        }
      end
    rescue => e
      info e
      exit
    end

  end
end

task :deploy => :check do
  run_locally do

    info roles(:all)
    info 'Next task of deploy on new instances'

    # deploy start

  end
end

    実際にインスタンスのラウンチをしてみる。

    ...

  • Tips

    Capistrano3でWordPressのデプロイをしてみる

    Capistrano3を使って、自ホストに最新版のWordPressをデプロイしてみたのでその手順をログとして残しつつ、デプロイツール「Capistrano」の理解を進めていこうと思います。 事前準備として、デプロイ用の環境をAmazonEC2にt2.microインスタンスとしてラウンチして、WordPressが動作する環境（Apache+MySQL+PHP）、Rubygem（とRVM）、そしてCapistrano3のインストールまで出来ている状態で記載しています(この辺の事前準備の手順も後日TIPSとしてまとめたいと思っていますが、今回は省略します)。

    さて、早速手順に入ります。 はじめに、デプロイプロジェクト用のディレクトリを作成して、Capistranoをインストールします。

    $ cd ~
$ mkdir test-project
$ cd test-project
$ cap install STAGES=test
mkdir -p config/deploy
create config/deploy.rb
create config/deploy/test.rb
mkdir -p lib/capistrano/tasks
Capified

    Capistrano3ではマルチステージデプロイ機能がデフォルトでONになっているので、単にcap installを行っただけだと、productionステージとstagingステージが作成されてしまいます。 今回はテスト用に自分のローカルホストのみを対象にデプロイを試すので、testステージのみのプロジェクトを環境変数STAGESの引数に指定します1。

    次にCapistranoの初期設定を行います。必要ならば、プロジェクトディレクトリ直下に作成されたCapfileを編集します。

    $ vim Capfile

    今回はrvmやrbenvをデプロイに使わないので、編集項目はありません2。

    続いて、デプロイ環境（サーバ）の設定を行うため、config/deploy/test.rbを編集します。

    $ vim config/deploy/test.rb
----
role :app, %w{deploy@localhost}
role :web, %w{deploy@localhost}
role :db, %w{deploy@localhost}

set :ssh_options, {
  keys: %w(/home/deploy/.ssh/id_rsa),
  forward_agent: true,
}

    そして、config/deploy.rbにデプロイ内容を設定します。

    ...

  • Tips

    Google Glass Word Lens と Play game

    Google Glassレポートその2です。

    前回は借り物でしたが、今回は Google Glass Explorer Edition Ver 2.0 を自社で購入してのレビューです。
    すごい！代表カッコイイ！！！

    まず、借りていたver1と今回のver2の違いについて。

    ggっても明確な情報は捕まりません。

    Google Glass 2 offers minor but important hardware updates

    一番よくまとまっていると思われたのが、↑のサイト。

    で、その情報によれば

     

    • イヤホンが付いてくる

    Glassはメガネのツルにあたる部分に骨伝導スピーカーが付いています。
    大体はこれで事足りると思うのですが、聞こえない場合の手段が追加された形だと思います。
    より万人向けに。素晴らしいことです。

     

    • 処理速度10%向上

    ほんの少しですがパフォーマンスが向上している模様。
    イイネ！

     

     

    overheat

    ちなみに重たいアプリを動かしていると熱くなり使用を控えるようメッセージが出るのは変わりませんでした。
    残念…

     

     

    続いて前回おざなりなレビューをした２つのアプリの使い方について

     

     

    device-2014-06-11-170958

    OK glass が表示されている状態で、Glassの右こめかみのあたりをタップ。
    インストールされているアプリを切り替えられる状態になります。
    メガネのツルの部分を左右にスワイプし目的のアプリを探します。

     

     

    translate_title
    Word Lensを見つけたら、すかさずタップ。

    ...

  • Tips

    Google Glass ファーストインプレッション

    噂のGoogle Glass。USでは既にかなり楽に入手できるようになっています。
    んが、日本では買えません。なぜ買えないんだぁー！
    リスクのある並行輸入業者に頼めということでしょうか。
    いや、無理です。(Glassのお値段的に)

    でも、持っている人は持っているんですよねぇ。
    Early Adopterな方々との情報格差がまた広がる…そんな絶望感を抱えながら、我社の代表にダメ元で相談したところ、期間限定ではありますが、Glassをお知り合いの方から借りてくれるとのこと！
    ありがとうございます！さすがです！！

    そんなこんなで触らせて頂いたGoogle Glassの感想です。
    120%私見です。ご容赦下さい。

    さて、メガネ型のウェラブルデバイスといえば、どうしても期待してしまうのがAR。
    拡張現実ではないでしょうか。

     

    AR1

    ↑こんなの。

    現実を上書きし、世界の有り様を拡張してしまう….サイバー！！(鼻血ブー
    Google Glassはどこまでそんな世界を引き寄せてくれるのでしょうか？
    ワクワクしながら、試してみました。

    結果：
    Google Glassは ARを実現するツールではない。

    まあ、ある程度分かっていた事ではあるのですが、Glassは視界の右上に小さなディスプレイを追加するものです。
    決して存在しないものをあたかも存在するかのように感じさせてくれるデバイスではありません。
    ただ、それでもなお、この製品が市場に受け入れられ順調に成長を続けていけば、いずれは万人が思い浮かべるARの世界を実現するようなデバイスにたどり着くかもしれない…そんな可能性は感じました。

    このデバイスの可能性を試すには、アプリを追加する必要があります。
    ところがアプリを追加するために必要なAndroidアプリ、MyGlassは日本からはダウンロードできません。
    なってこった。

    しょうがないので野良アプリをインストールします。
    私は以下からダウンロードしました。

     

    Download Latest MyGlass APK

    あくまで自己責任でお願いします。

    アプリを起動しBluetoothでペアリングすれば準備完了。
    ワシワシアプリをインストールしましょう。

    私がインストールしたアプリの中で特に気になったのは以下の２つです。

    Mini Games

    首の動きで操作するのが新しい！そして若干ARぽい。

     

    Word Lens

    見たものを翻訳できる！
    これは…未来ぽい！

    ...

  • Tips

    WordPressのサイトが重くなった時のプラグインパフォーマンス検証

    とある多国語サイトをWordPressで構築している時に、結合試験もほぼ終わったあたりで、構築サイト全体のパフォーマンス・チューニングをしていた時の備忘録です。
    対象のサイトは規模がそんなに大きくなかったので、AWSのm3.mediumのインスタンスに構築していたのだが、開発途中からサイト全体のパフォーマンスが落ちて、だいぶ重いサイトになって来てました。サイトのパフォーマンス検証「GTmetrix」でのレポートを見ると、サイト内で利用している画像のレスポンスがレイテンシー食っているという結果しか出ず、とりあえずは出来る限りの画像最適化を行って、フロントエンドのパフォーマンスはだいぶ良くなったのだが、WordPressの管理画面は重いまま変わらなかった。WEBサーバ側で静的コンテンツのGZIP圧縮や、.htaccessを利用せずにhttpd.conf内に設定を移行など、諸々対応してみたが効果はなかった。他にMySQLTunerでDBの設定を検証・チューニングしてみたが、特に変化なし。
    う～む、CloudWatchを見るとCPU使用量がやけに大きいので、AWSインスタンスの非力さが原因なのかも…そうなると、最終的にはm3.mediumインスタンスからc3系へのインスタンス変更が必要かも知れないなぁ…とか考えていたのだが、そもそも開発中のサイトで社内の数人しかアクセスしない管理画面が重いというのは根本的に別の要因があるはず。サイト全体に関わるものというと、テーマかプラグインかしかない。そこで、導入しているプラグインのパフォーマンス検証を行ってみたところ、ビンゴ！…パフォーマンス低下の原因はプラグインだった。

    今回プラグインのパフォーマンス検証に利用したのが「P3（Plugin Performance Profiler）」だ。プラグインのパフォーマンスを検証するのに別のプラグインを入れるというのも変な話だが、このP3プラグインはWordPressサイト内でのプラグインやテーマのパフォーマンスを細かいところまでスキャン・レポーティングしてくれるかなり優秀なものだ。導入も簡単で、プラグインをダウンロードして有効化すればいつでも管理メニューの「ツール」からパフォーマンススキャンができる。

    このP3プラグインでスキャンした結果はこうなった。

    p3_before

    多言語化プラグインの「Polylang」とカスタム投稿タイプ系プラグインの「Types」がランタイムを圧迫しているのがわかる。さすがに多言語サイトなので「Polylang」は外せないが、カスタム投稿タイプ系のプラグインは同系プラグインが多いので差し替え可能だ。「Types」は「Polylang」に公式対応しているプラグインなので採用していたのだが、たかだかカスタム投稿の拡張をするだけで、ここまでランタイムを占有されてはちょっと使い勝手が良いとは言えない。
    そこで、「Types」プラグインを外して、同系で使い慣れている「Custom PostType UI」プラグインを導入してみた。

    p3_after

    「Types」で占有されていたランタイムがなくなり、プラグインロードタイムやプラグインインパクトが改善された。管理画面の体感速度も数十倍に向上し、本来のサクサク編集できるUXが復活した。プラグイン一つでここまでパフォーマンスが変わるものなんだなぁ…と実感できました。

    今回の件から、今後WordPressサイトを作る際には、プラグインの機能よりもパフォーマンスを重視して選定した方が良いと私的には思えました。なぜなら、プラグインの機能で足りないものは後からいくらでも追加することができるが、プラグインのコアに依存するパフォーマンスを改修するのは非常に困難だからです。
    特に管理画面が重いと、サイトを運用するWEB担当者のモチベーションがかなり下がってしまうので、ちょっと機能不足でもストレスなく運用できる管理画面の方が喜ばれるのではないだろうか。

    ...

  • Tips

    AWS認定ソリューションアーキテクト–アソシエイトレベル受験体験記

    おはようございます。インフラの宮下です。
    ゴールデンウィーク突入の直前に「AWS 認定ソリューションアーキテクト – アソシエイトレベル」を受験しましたので、
    試験の手続き方法や勉強内容について守秘義務に反しない程度にご紹介します。

    ○　試験の事、そして申込みまで

    試験範囲は、Blueprintが公開されていますので正確な情報はそちらを確認してください。
    blueprint

    現時点での出題配分は下記の通りで、Blueprintでは一つ一つ細かく説明がなされています。
    時間の限られている社会人は、勉強の基本はBlueprintを見て戦略を練るのが最短距離とい言うのが私の方針です。

    1.0 Designing highly available, cost efficient, fault tolerant, scalable systems　60%
    2.0 Implementation/Deployment　10%
    3.0 Data Security　20%
    4.0 Troubleshooting　10%

    Blueprintを一読した印象では、単純にサービスを知っているだけでは厳しそう、という印象でした。

    実際に試験を申し込まないと受験できませんので、申込方法を説明します。
    AWSのページで案内している通りKryterion社が試験を提供しています。
    ここでの注意点は、英語ページのままサインアップすると試験が英語版しか出てきません。
    サイトが日本語ページである事を確認してサインアップしましょう。（英語版を希望する時は逆に英語でサインアップする）

    サインアップ後に「試験のお申し込み」で「AWS 認定ソリューションアーキテクト-アソシエイトレベル」を選択すると 試験会場の選択そして日時の選択になります。

    私は、池袋の会場で申し込みました。池袋の地理に明るい自分はすぐに分かりましたが、不慣れな人は
    場所はしっかりと確認しておいた方が良いかもしれません。
    大塚方面を線路沿いに進み、公園の向かい向かいにあるそんなに大きくないビルの中になります。
    試験日程ですが、まだ会場がそれほど多くないせいか直近1週間は結構混んでいます。
    1～2週間先をゆとりをもって予約をするのが良いと思います。

    試験を申し込んだら完了メールが来ますので、印刷して当日は必ず持参しましょう。
    結構大事な事がかいてあります。
    「受験者認証コード」を提示しないと受験できなかったり、身分証明書を2種類用意するとか

    ○　試験対策について

    ...

  • Tips

    nginxでヘルスチェックのアクセスログを出力させない設定

    おはようございます。インフラの宮下です。
    今回はnginxのログ関連の設定になります。

    目次

    1. はじめに
    2. ngx_http_geo_moduleについて
    3. nginxへの設定
    4. 参考サイト

    はじめに

    apacheで良く実施する、setenvの定義を利用して特定NWから来るログを出力しないような設定をnginxでも実施したかったのですが同じ機能が無かったので調べてみました。 使い道としては、ロードバランサーのヘルスチェックや監視サーバからの接続など、ログに出力しない方が都合が良い時に利用できます。 解析するには不要ですし、余計なDISK I/Oも抑えられます。

    ngx_http_geo_moduleとは

    公式ドキュメント

    ドキュメントの通りIPアドレスを変数としてセットできます。
    一般的に使われるのは、特定の国のNWは接続拒否するような時にこのモジュールを使う事が多いようです。 そのような場合は、includeして大量に登録された別ファイルで管理する事も可能です。

    nginxへの設定

    nginx.confに設定します。
    [shell]# vi nginx.conf http { include mime.types; （中略） # not access_log IP’s geo $no_log { default 0; 172.0.1.0/24 1; } server { （中略） location / { root /var/www/html; index index.cgi index.php index.html index.htm; if ($no_log) { access_log off; } } }[/shell]

    ...

  • Tips

    Solaris10にUSB外付けハードディスクを付けてバックアップを取得する

    おはようございます。インフラの宮下です。普段はクラウド中心なのですが、
    solarisにUSBのHDDを付ける事があったのでその手順を紹介します。

    環境：solaris10
    機器：SPARC T2000
    HDD：IOデータの500GB　USBポータブルハードディスク

    ○1回目

    あまり何も考えずにとりあえず接続してみました。messagesにログが出てきて認識されている事は
    確認できます。

    [shell]Apr 9 15:45:11 test-web21 usba: [ID 912658 kern.info] USB 2.10 device (usb4bb,152) operating at hi speed (USB 2.x) on USB 2.0 external hub: storage@1, scsa2usb2 at bus address 7 Apr 9 15:45:11 test-web usba: [ID 349649 kern.info] I-O DATA DEVICE, INC. HDPF-UT 000315C3C1900CEE Apr 9 15:45:11 test-web genunix: [ID 936769 kern.info] scsa2usb2 is /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,2/hub@4/storage@1 Apr 9 15:45:11 test-web genunix: [ID 408114 kern.info] /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,2/hub@4/storage@1 (scsa2usb2) online Apr 9 15:45:13 test-web scsi: [ID 583861 kern.info] sd5 at scsa2usb2: target 0 lun 0 Apr 9 15:45:13 test-web genunix: [ID 936769 kern.info] sd5 is /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,2/hub@4/storage@1/disk@0,0 Apr 9 15:45:13 test-web genunix: [ID 408114 kern.info] /pci@400/pci@2/pci@0/pci@f/pci@0/usb@0,2/hub@4/storage@1/disk@0,0 (sd5) online[/shell]
    パーテション情報を確認すると残念ながらNTFSで、なんとsolarisは未対応の為フォーマットエラーになってしまいました。

    ...

  • Tips

    mysqlのreplication関連リンクまとめ

    mysqlのreplication関連情報まとめ

    こんにちは。小宮です。
    なんだかmysqlのことを聞かれることが多い今日この頃なので、
    聞かれたときコピペできるように聞かれがちなことが説明されてるリンクをまとめる試みです。
    この記事だけ読んでも大したことはわかりませんのであしからずご了承ください。
    （自分がすっかり忘れたときにも役立ちそうです。）

    ・基本
    現場指向のレプリケーション詳説
    漢(オトコ)のコンピュータ道: MySQLレプリケーションを安全に利用するための10のテクニック
    Art of MySQL Replication.
    バイナリログに書かれるのは更新系のクエリです。
    補足すると、I/Oエラーは、物理的にディスクが壊れた、ネットワーク的につながらない、レプリケーション用ユーザのIDとパスワードが間違っている、server_idが重複している
    　などの理由で起こることがあります。SQLエラーの主な原因は上記の最初のリンクに書いてありますが主に重複エラーが多い印象です。

    参考までに現在のreplicationまわりの設定値はだいたいこんなかんじです。

    [shell]## replication (master/slave) log-bin=mysql-bin log-bin-index=mysql-bin.index binlog_format=mixed server-id = 133 relay-log=mysqld-relay-bin relay-log-index=mysql-relay-bin.index log_slave_updates=1 replicate-ignore-db=mysql,information_schema,performance_schema binlog-ignore-db=mysql,information_schema,performance_schema skip_slave_start read_only slave_net_timeout=120

    ## replication (for 5.6) gtid-mode = OFF enforce_gtid_consistency=false master-info-repository=TABLE relay-log-info-repository=TABLE relay_log_recovery=ON #sync-master-info=1 slave-parallel-workers=0 binlog-checksum=CRC32 #master-verify-checksum=1 #slave-sql-verify-checksum=1 binlog-rows-query-log_events=1 #log_bin_use_v1_row_events=ON #sync_binlog=1 report-port=3306 report-host = 192.168.1.133[/shell]

    ...

  • Tips

    OpenSSLの重大バグ(CVE-2014-0160)への対応

    こんにちは。小宮です。

    OpenSSLの重大バグが発見されたという記事をうけまして、
    さすがに影響が大きいようなので関連情報を記録しておきます。
    OpenSSLの重大バグが発覚。インターネットの大部分に影響の可能性 | TechCrunch Japan
    JVNVU#94401838: OpenSSL の heartbeat 拡張に情報漏えいの脆弱性

    影響範囲はopenssl-1.0.1~1.0.1fということで、まじめに最新にしてるサイトが影響を受けるという皮肉なことに。
    でもまあ影響範囲が限定的なのは良かったと思います。
    弊社ではCentOS6.5とAmazonLinuxの環境が影響を受けました。

    まず以下をご覧ください。
    対策方法を記しているサイト：
    AWS - EC2インスタンスのOpenSSLのHartbleed Bug対応 - Qiita
    opensslのTLS heartbeat read overrun (CVE-2014-0160)を対処した | Ore no homepage

    バージョンの確認方法は

    rpm -qa|grep openssl

    とか

    openssl version

    という感じで、
    CVE-2014-0160をfixしてるパッチがあたってるかどうかは、以下のように確認しました。

    rpm -q --changelog openssl |head
* 月  4月 07 2014 Toma? Mraz <tmraz@redhat.com> 1.0.1e-16.7
- fix CVE-2014-0160 - information disclosure in TLS heartbeat extension

    あたってなければ、yum update opensslして
    sshd、crond、httpd等のopensslを利用しているサービスを再起動しました。

    ...

  • Tips

    mysqlfailoverをデーモンになってから試してみた

    ※ 古い記事ですのでご注意ください。

    こんにちは。小宮です。

    まだ使いたい人がいるかわかりませんが検証してみましたので載せておきます。
    長い記事になりますのでお時間のあるときにどうぞ。

    mysqlfailoverを–forceつけず–daemon=startで起動させる

    以前検証したときは
    　–forceつけないと動かなかったのと
    　デーモンで起動させるオプションは存在しなかった
    というわけでそこを再度たしかめてみます。

    ・構成：

    192.168.1.133   komiya-test-mysql01 my1
192.168.1.155   komiya-test-mysql02 my2
192.168.1.150   komiya-test-mysql03 my3
192.168.1.241   komiya-test-mysql04 my4 manager
192.168.1.222   vip

    ・インストール：
    パッケージは公式とかこのへんからダウンロードできます。
    とりあえずchefでmysql5.6とutility等を入れておきました。
    ssh-copy-idとknife solo prepareして
    nodeファイルのrunlistにdbロール指定して
    knife solo cookしただけで以下と必要な設定ファイルが置かれて
    server_idとかreport_hostとか自動的に入るようにしました。
    参考にしたレシピはこちら。

    以下が関連パッケージです。
    mysql-utilitiesはpythonで書かれたツールなのでmysql-connector-pythonが必要です。

    $ rpm -qa|grep -i mysql
MySQL-shared-compat-5.6.15-1.linux_glibc2.5.x86_64
MySQL-test-5.6.15-1.linux_glibc2.5.x86_64
perl-DBD-MySQL-4.013-3.el6.x86_64
mysql-utilities-1.4.1-1.el6.noarch
mysqltuner-1.1.1-1.el6.noarch
MySQL-client-5.6.15-1.linux_glibc2.5.x86_64
MySQL-server-5.6.15-1.linux_glibc2.5.x86_64
MySQL-devel-5.6.15-1.linux_glibc2.5.x86_64
mysql-connector-python-1.1.4-1.el6.noarch
mysqlreport-3.5-4.el6.noarch

    ・replicaitonを組む
    server_idはipアドレスの第4オクテットにしたので重複しないはず。
    report_hostも自分のIPに自動的になってるはず。

    ...