銀色うつ時間

思い出すたび何か胸につっかえてるだけ

mysqlコンソールでプロンプトを変更する

mysqlコマンドの出力結果を貼ったりするときに、見る人に「このサーバ内での作業なんですよー」みたいなのを示しておきたかったりする。もちろんデフォルトは以下

mysql>

そういうときはPROMPTを使うとよい。作業日時やログインユーザ、ホスト名などの表示変更が可能だ。例えば作業ユーザとホスト名を指定したい場合は以下。

mysql> PROMPT \u@\h >

>とスペースを最後につけておいた方が個人的には見栄えがよい。 プロンプトは次のような表示となる。

user@database01 >

以下はよく使うシーケンス。

\c
カウンタ。複数のSQLを実行する場合にナンバリングに使える

\D
日時

\u
ログインユーザ名

\h
ホスト名

特定のプロンプトを毎回打つのが面倒なので、その場合は$HOME/.my.cnfにPROMPTを設定しておけば、デフォルトで設定できる。

Ansibleで冪等性を保つためにはfailed_whenとかstatを使うと便利

構成管理ツールとしてAnsibleを使って開発環境を作っているんだけど(本番でも使えるようにとかはまだできてない)、特定のコマンドの実行結果によって次の処理をスキップするかどうかみたいなのを制御したい場面がある。

例えばcentos6.xでnginxの設定を行いたいとすると、以下のようになる。

- name: get nginx rpm
  get_url: url="http://nginx.org/packages/centos/6/noarch/RPMS/nginx-release-centos-6-0.el6.ngx.noarch.rpm" dest="/var/tmp/nginx-release-centos-6-0.el6.ngx.noarch.rpm"
- name: add nginx rpm
  yum: name=/var/tmp/nginx-release-centos-6-0.el6.ngx.noarch.rpm state=present
- name: install nginx
  yum: name=nginx state=present
- name: register service
  service: name=nginx enabled=yes
- name: add conf file
  copy: src=../files/extra.conf dest=/etc/nginx/conf.d
- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup

確かにこれでもnginxのインストールと必要な設定は行えるが、このままでは冪等性が担保されない。Ansibleのコアモジュールの多くは冪等性をチェックしているが、shellモジュールなどの冪等性は担保されない。対象のサーバに対してこのスクリプトを実行した場合、2回目移行もdefault.confをmvしようとしてエラーになるだろう。

幸いAnsibleにはregisterという出力を変数に格納できる仕組みがあるので、それを利用するとよい。

- name: is nginx already installed
   shell: which nginx
   register: which_nginx

# (中略)

- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup

しかし、これではエラーとなってしまう。Ansibleは終了ステータスが0以外のものを原則エラーとして解釈するからだ。which nginxでnginxが存在しなかった場合、no nginx foundのようなものがエラー出力に出てしまうから、ハンドリングする必要がある。

結果、以下のように書くのがよい。

- name: is nginx already installed
   shell: which nginx
   register: which_nginx
   failed_when: which_nginx not in [0, 1]

# (中略)

- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup
  when: which_nginx.rc == 1

failed_whenは値に記述した結果のBooleanでタスクの成功可否を判定する。failed_whenを使うことで終了ステータスの正常・エラーに関わらずタスク自体は通過させ、以後はそこで宣言した変数のステータスや出力内容を見ながらタスクを実行するかスキップするか決めるようにするとよいと思う。

余談だが、特定ファイルの存在確認をするためには以下のようなやり方がある

- name: check default conf
  stat: path=/etc/nginx/conf.d/default.conf
  register: is_exists
- name: move default conf
  shell: mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.backup
  when: is_exists.stat.md5 is defined

statモジュールを利用して変数にset、md5ハッシュ値が存在するかどうかで以降のタスクを制御する。

インフラエンジニアの教科書読んだ

インフラエンジニアの教科書

インフラエンジニアの教科書

読んだ。業務でアプリケーション開発をしているだけでは分からなかった領域を知れてよかった。以下のようなトピックをざっくりと解説しているが、ちゃんと頭の中に収めるには他の本を読んだりやれる領域は実際に手を動かしてみる必要がありそう。

サーバ

  • タワー型・ラック型などのサーバの種類
  • SATASASSSD等ストレージの種類
  • 仮想化技術・ハイパーバイザなど
  • RAIDで行う冗長化とパフォーマンス向上の戦略

ネットワーク

  • ルータの役割
  • L2/L3スイッチ
  • L4/L7スイッチ(LB)
  • ネットワーク構成の構造(front/back2層・3階層構造・ネットワークファブリック)
  • OSI参照モデル

ストレージ

  • ローカルストレージ・外部ストレージ・ホットスペアなど
  • 外部ストレージを利用したディスクI/O性能の向上
  • シンプロビジョニング(容量の仮想化)

DC

  • DCの選定(拡張性・地理的要因・空調など)
  • ネットワーク機器の配置・エアフローなど

障害対応

大規模インフラ

  • 資材調達
  • CDN
  • DSR構成による負荷分散(L4スイッチを上位スイッチに直接接続することで捌けるリクエスト量を増やし、ネットワーク構成の自由度を上げる)

広範囲な領域をざっくりと説明しているだけなので、ひとつひとつの解説が薄い感は否めない。インフラエンジニアのお仕事案内としてはよいかもしれないけど、業務レベルとなると全く太刀打ち出来ないという認識を持ってもう少し詳しい解説をしている書籍を読む必要がある。今度はネットワーク構成についてや高可用性が求められる場合におけるアプリケーションのシステム構成、要求性能の算出からハードウェアを選定する技術などを学びたい。

ある光

実家の愛犬、ごんたくんが旅立ってしまった。

12月の頭から調子が悪くなり始めて、1/20の未明にあっさり逝ってしまった。心臓病だった。13歳と3ヶ月だった。

12月に調子が悪いという報告を聞いた日、偶然なのかお告げなのか分からないけど、僕はたまたまごんたくんの夢を見ていて、ちょっと嫌な予感がしていたところに本当に知らせがきてびっくりした。会えるのが最後になるかもしれないと思い年始に帰省したのだけれど、痩せてはいたものの思ったより元気そうだったので一安心していた矢先だった。「遺影撮っておかなきゃ」なんて冗談交じりに言いながらカメラを向けていたけど、まさかそれから3週間で本当に死んでしまうなんて正直思っていなくて、今も現実感がなかったりする。年末年始は仕事関連でも色々あったので悩んでいたけれど、帰省しておいて本当によかった。最後に、頭を撫で、ジャーキーをあげて、 一緒に散歩することもできた。

いつも母が仕事から帰ると小屋から出てきて喜ぶのだけど、それが出てこなくなって、2日後のことだったらしい。その日は夜中まで母親についてもらっていて、翌朝様子を見てみると、眠るように死んでいたそうだ。最後まで大好きな母に撫でてもらって、ごんたくんは幸せだったと信じたい。

誰かを噛んで怪我させたことなんで一度もないし、初対面の人でも決して吠えたりしない優しい犬だった。いつも家族に対して愛想よく振る舞って、僕と散歩するときは飛び跳ねて喜んだりしていた。芸は待てとお手と伏せくらいしかできなかったけど、僕はそんなごんたくんが好きだった。

元々は、おばあちゃんの家で飼われていた犬に子どもが産まれてしまったという田舎ではよくある話で、引き取り手が必要になって我が家にやってきた仔犬だった。僕が13歳のときだ。妹が大事そうに抱えていたその雑種の仔犬は、突然別の場所に連れて来られて不安そうな表情をしていたのを、よく憶えている。寒い冬の日の夕方、一緒に歩いた道すがら、ごんたくんが立ち止まって、僕も立ち止まって、遠州のからっ風が吹いた時、空は美しい赤で、ああ、僕らは心が通じていると感じた(犬を飼う人のいくらかは分かってくれると思う)こと、多感な時期に色々悩んで、ナンバーガールだとかフィッシュマンズなんかを聞きながら何も言わない少年の側にいつまでもいてくれたこと、上京してからあまり帰省したかったけど、ごんたくんは僕のことをちゃんと覚えていて、帰省する度に喜んでくれたこと。そんな思い出の断片が、僕の身体の中で跳ねっ返る。

1/19は妹の20歳の誕生日で、もしかしたらごんたくんは妹の成人を見届けるまで頑張ってくれたのかもしれない。

夜になるとごんたくんを思い出して、泣いてしまう。こうして文章にすると、僕は自分でもびっくりするくらいごんたくんが好きだったということ、ごんたくんと過ごした日々がいかに素晴らしいものだったかということに、改めて気付かされる。

ごんたくん、大好きだよ。今までありがとう。

f:id:sisidovski:20131215091835j:plain

2014年振り返り

少し早いけど、2014年の振り返り。

濃い1年だった。エンジニアとして多くのことを学び、多くのことが今だ学べずに残してしまっている。この1年を誰に感謝するかと問われれば、それはJavaScriptだろう。2月から4月まではサーバ・クライアントどちらもJavaScriptの新規サービスの開発をする機会があり、それが自身にとって得難い経験となった。今まではjQueryでDOM操作をする程度の表層でのみ利用していて気がついていなかったメソッドの意味や、曖昧だった言語の仕様、ソフトウェアに対する要求について考えることができた。必然的にモダンなJavaScript界隈の話を見聞きすることが多くなり、新しい技術やトレンドを追い出すようになった。また、チーム内で教える立場になったこともあり、曖昧な認識では説明できないことが増えた。聞かれたことを夜な夜な学んで翌日しれっと話す、といったことも何度かあったが、未だ充分な役割は果たせていないように思える。

Keep

  • いわゆるMEANスタックであるとか、WebScoket、WebComponentsなどについて学んだ。モダンなフロントエンド開発や技術については今後も継続して色々挑戦していきたい。NodeやMongoなども。

  • 自分が触ったことのない言語に挑戦した(主にGo, Swift, Rubyなど)。使いこなすレベルにまで至っているものは少ないが、手を動かしたり言語仕様について学んだりすることができた。

  • 多少のアウトプットはできた。何度か発信することができたように思う。同人誌にSocket.IOの記事を書いたりした。

  • 外のライブラリに機能追加pull requestを投げた。Angular.jsのプラグインになかった機能を自分で追加して後日pull request投げた。「機能はOK。ちょっとテスト足りないから追加で書いといたわ」と言われたのが切ない。

Problem

  • 全体的に、テストを書いた方がいい機会で書けなかった。よくある時間がないとかいうアレだったのだけれど、テスト書いておけばエンバグして手戻り、みたいな作業減るよなーという場面を作ってしまった。

  • インフラに関する知識が足りない。ネットワークやシステム構成の話の基本的な部分から、各種のミドルウェアに対する理解だったり。あとAWSとか全然ついていけてない。

  • 新しい言語やフレームワークを学んでも自分で何か作れるところまでいかなかった。また、設計やデザインパターンについてもっと理解を深めたいが。

  • 依然としてアウトプットが少ない

  • 英語が思ったより学べなかった。夏くらいまでは毎日Podcast聞いたりしていたけど、最近は全く手がついていない。

Try

  • テストが当たり前の状況にする。そのためにRailsRSpecを使って、テストの導入からテスト駆動な開発まで自分でやってみる。また、jsでもテストが当たり前で書けるように書ける部分は原則書くようにする。

  • マスタリングTCP/IPをひと通り読む。AWSで1つのアプリケーションを色々なミドルウェアを使って動かしてみる。herokuとかに色々任せきりにしない。nginx, (apache), mysql, redisなどを1人で色々設定してみる。

  • 自分でライブラリを作って公開してみる。デザパタ本を読みなおしたりDDD本を読んだりしてブログにまとめる。

  • 月1で記事を書く。また、月1で振り返りをして、軌道修正を行う。

  • 課題を課すためにも、できる限り毎日DUOとかやる。

今年読んだ本

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

開眼!  JavaScript ―言語仕様から学ぶJavaScriptの本質

開眼! JavaScript ―言語仕様から学ぶJavaScriptの本質

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Swift離陸ガイド

Swift離陸ガイド

Swiftではじめる iPhoneアプリ開発の教科書 【iOS 8&Xcode 6対応】

Swiftではじめる iPhoneアプリ開発の教科書 【iOS 8&Xcode 6対応】

  • 読んでる・途中で止まってる本

シングルページWebアプリケーション ―Node.js、MongoDBを活用したJavaScript SPA

シングルページWebアプリケーション ―Node.js、MongoDBを活用したJavaScript SPA

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

来年もよろしくお願いします。

安全なWebアプリケーションの作り方1

読書会でのメモ

HTTPとセッション, 同一生成元ポリシー

HTTP

  • クライアントからサーバへのリクエスト、サーバからクライアントへのレスポンスで構成されるプロトコル
  • リクエストラインの構成は以下
  • メソッド
  • リクエストURL
  • プロトコルバージョン
  • 実際にはGET /hoge.php HTTP/1.1といった形式となる
  • リクエストヘッダにはRefererなどがつく
  • Refererはアプリケーションが意図した遷移を経ているかをサーバ側で検証する場合などに用いられるが、改変が容易
  • URLにセッションIDなど機密情報が含まれる場合にはセキュリティリスクとなる
  • レスポンスメッセージの構成は以下
  • ステータスライン HTTP/1.1 200 OK
  • ヘッダ Date: foo Server: Apache/2.2.14...
  • 空行
  • 本体 <body>...
  • レスポンスヘッダはContent-lengthやContent-Typeなどが代表的
  • Content-TypeはMIMEタイプというリソースの種類を指定するhtmlであればtext/html, jpg画像であればimage/jpg, pdf文書であればapplication/pdf
  • 特殊記号や日本語などのマルチバイト文字列をURL上に記述する場合はパーセントエンコーディングを行う必要がある
  • GET/POSTについて
  • GETメソッドを用いる場合は、「リソースに対して副作用を起こさない・機密情報を送信しない・送信するデータ量が少ない」場合に用いるのが望ましい
  • Referer経由で情報が漏洩する・アクセスログに記録されるため
  • hiddenパラメータは書き換え可能
  • HTTPには認識機構が用意されている
  • Basic認証
  • Digest認証
$user = $_SERVER['PHP_AUTH_USER'];
$pass = $_SERVER['PHP_AUTH_PW'];
if (!$user || !$pass) {
  header('HTTP/1.1 401 Unauthorized');
  header('WWW-Authenticate: Basic realm="Basic Authentification Sample"');
  exit;
}
  • Basic認証が設定されているサーバから401のレスポンスを受け取ると、ブラウザはBasic認証のidとpassを受け取るダイアログを表示する
  • 認証に成功すると、ブラウザはリクエストヘッダにAuthentificationを付与して送信し、ページの閲覧が可能となる
  • Cookieとセッション管理
  • HTTPはステートレスなプロトコルであるが、クライアント・サーバ間でログイン状態やその他の情報を記憶しておきたい場面が存在する
  • 認証状態の管理はセッション管理と呼ばれ、HTTPではブラウザのCookieを用いて実現される
  • 有効期限の設定されていないCookieはSessionと呼ばれ、ブラウザが閉じられるまで有効となる
  • Cookieは文字列長および利用者による変更が可能なため、Cookieにはセッションidのみ記録し、実際のセッション管理を行う値はサーバ側で保持することが多い
  • セッションidに求められる要件は以下
  • 第三者がセッションidを推測できない
  • 第三者からセッションidを強制されない
  • 第三者にセッションidが漏洩しない
  • 上記を満たすため、セッションには以下のようなことを考慮する必要がある
  • 乱数の質
  • ネットワーク的な盗聴の危険性
  • XSSからの漏洩
  • CookieのDomain属性/Secure属性/HttpOnly属性
  • Referer