https://blog.takanabe.tokyo/ Recent content on Payforward Hugo -- gohugo.io en-us Fri, 02 Jan 2026 10:00:00 -0700 https://blog.takanabe.tokyo/2026/01/%E4%BC%9A%E7%A4%BE%E3%81%8C%E8%B2%B7%E5%8F%8E%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%82%AB%E3%83%8A%E3%83%80%E3%81%AB%E7%A7%BB%E4%BD%8F%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ Fri, 02 Jan 2026 10:00:00 -0700 https://blog.takanabe.tokyo/2026/01/%E4%BC%9A%E7%A4%BE%E3%81%8C%E8%B2%B7%E5%8F%8E%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F%E3%82%AB%E3%83%8A%E3%83%80%E3%81%AB%E7%A7%BB%E4%BD%8F%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ TL;DR 2024年に所属していた会社が買収され、その後2025年にカナダに移住したので近況報告です。 所属会社の買収 2022年よりLaunchableという機械学習を使ってテスト周辺の問題を解決するプロダクトを開発している会社で働いてきましたが、2024年の夏にLaunchableがCloudBeesに買収されました。うろ覚えですが、確か初めて社内で買収の話が出てから一週間後くらいには買収が決定しており、もの凄いスピード感でした。もちろん裏ではもっとやり取りがあったと思いますが私を含むほとんどのソフトウェアエンジニア目線では一瞬で買収されていたというのが当時の体感でした。 買収後の開発体制 CloudBeesは比較的大きな会社ですがLaunchableのプロダクトとチームが欲しかったみたいで、AIプロダクトの開発チームの一つとしてそのままのメンバーや開発体制で進めさせてもらっています。買収後によくあるチームの解体や強制的な技術移行に巻き込まれなかったのは良かったです。また、CloudBeesは世界中に社員が点在していますが、フルリモートが基本の会社です。Launchableもフルリモートが基本の会社であったためライフスタイルも大きく変えることなく開発に参加できました。 子供の成長と海外移住 国内でソフトウェアエンジニアとしてある程度スキルや経験を積んだことで、日本を離れてさらに新しい経験を積みたいという気持ちも強くなりました。もともとLaunchableで働いていたのも、日本にいながら英語で仕事ができる環境に魅力を感じていたからです。 また、2023、2024年ごろから子供の成長や環境の変化について考えるようになりました。2025年4月には子供が小学生になる予定だったため、どのタイミングで海外に移住するのが良いか家族で話し合うようになりました。私自身、人生で一度は海外でまとまった期間仕事をしたいという思いがずっとあり、いずれは挑戦したいと考えていました。 小学校高学年での引っ越しよりも、子供がまだ小さいうちの方が新しい環境に馴染みやすいのではないかと考え、思い切って移住を決断しました。この考えについては、Launchableに在籍していた頃から当時の社長であった川口さんにも相談しており、買収が決まった際の契約更改時にもCloudBees側にしっかりと伝えていました。 もちろん、友達や学校、生活環境が変わることへの不安もありましたが、家族で何度も話し合いながら慎重に準備を進めてきました。 予定より少し遅くなりましたが、CloudBeesからのサポートもあり、2025年の夏に日本からカナダへ家族で移住することができました。 カナダでの生活 カナダに来てからはゴミの捨て方が分からなかったり、車を人生で初めて購入したりと新しいことの連続でしたが、そういった不便も楽しみながら一つずつ解決しています。私個人の不便は努力すればいいだけなので正直どうとでもなりますが、一番気にしていたのは妻と子供が日本を離れても楽しくやっていけるかどうかでした。幸い、二人とも少しずつカナダでの生活にも慣れてきてくれているので安心しています。今後も家族が楽しく過ごせるようにサポートしていきたいです。 カナダでの仕事 タイムゾーンがJSTからPSTになったことでヨーロッパや北米の同僚とのコミュニケーションは取りやすくなりました。一方でアジアのメンバーと働くのは大変になりましたが、自分はどちらかというと朝型の人間なので、この辺りも今後働き方を模索していきたいと思っています。 世界中に社員がいるため他の人が何をやっているのかはわかりにくい環境ではありますが、チームとしては会社の主力製品の開発を任せてもらっているチームの中の1つだと全社ミーティングなど雰囲気から感じており、いい意味でプレッシャーもありながらプロダクト開発に取り組んでいます。 おわりに いつまで海外にいられるのかはまだ分かりませんが、これからもネットワーク、スキル、経験を培い、それを将来的に日本に還元できるような人間になりたいと思っています。 最後に現在私のチームでAI関連のプロダクトを開発するソフトウェアエンジニアを募集中です。 https://recruiting.paylocity.com/Recruiting/Jobs/Details/3550189 私のように海外でチャレンジをしてみたいという方におすすめです。ヘッドカウントや期限が限られているため少しでも気になった方は私にDMをしていただくか、こちらのサイトから直接応募してみてください! https://blog.takanabe.tokyo/2023/03/df12434a-322b-4fc6-9e6c-2f3703581b76/ Tue, 21 Mar 2023 09:00:00 +0000 https://blog.takanabe.tokyo/2023/03/df12434a-322b-4fc6-9e6c-2f3703581b76/ モチベーション Python機械学習プログラミングの”3.3.5 正則化による過学習への対処”で突然ロジスティック回帰の損失関数に過学習予防のために正則化項を追加する話が出てくるのだが、初見ではなぜ正則化項を追加していいのか、またそれがなぜ過学習を防ぐことに繋がるのかわからなかった。後者は次の記事で具体的に説明するとして、本記事では正則化項を足す(足せる)ことの理論を確認する。 正則化項とラグランジュの未定乗数法 ロジスティック回帰の損失関数は正則化項を追加する前は単純な凸関数であるため、勾配降下法、つまり重みに対して偏微分をすることで局所解を求められる。これは Python機械学習プログラミングをはじめから読んでいれば理解できる。一方で、その損失関数に正則化項を足したときに数学的にどのような問題を解いているのかは端折られているためわかりにくい。これを理解するにはラグランジュの未定乗数法を理解する必要がある。 ラグランジュの未定乗数法は、制約付き最適化問題を解くための数学的手法であり、制約条件を目的関数(この場合は損失関数)に組み込むことによって、制約付き最適化問題を無制約最適化問題に変換し、解を求めることを可能にする。制約付きの最適化問題を解くのは難しいから無制約の最適化問題に変換してしまえば凸関数である限り局所解は偏微分で出せるから嬉しいよねというのがこの手法の味噌だ。 ラグランジュの未定乗数法は目的関数と制約条件の組み合わせで構成され、ラグランジュ乗数を導入して制約条件を表現する。この関数はラグランジュ関数と呼ばれ、一般的に以下の数式で表される。 ここで、f(𝐱)は目的関数、g_i(𝐱)は不等式制約、h_j(𝐱)は等式制約、𝜆_iと𝜇_jはラグランジュ乗数である。 ラグランジュの未定乗数法とKKT条件 KKT条件（Karush-Kuhn-Tucker condition）とラグランジュの未定乗数法は、制約付き最適化問題を解く際に使用される数学的手法である。両者は密接に関連しており、KKT条件はラグランジュの未定乗数法に基づいて非線形制約付き最適化問題の最適解を特徴づけるために用いられる。そして、KKT条件は、非線形制約付き最適化問題の最適解に関する必要条件であり、次の条件を満たす必要がある。 勾配条件（stationarity condition） 制約付き最適化問題において、最適解（局所最適解）におけるラグランジュ関数の勾配がゼロになること 実行可能性条件（primal feasibility） 制約条件が満たされること。 双対実行可能性条件（dual feasibility） ラグランジュ乗数が非負であること。 補完スラック条件（complementary slackness） ラグランジュ乗数と制約条件の積が0になること。 これらを使うことで、制約条件を目的関数(この場合は損失関数)に組み込むことによって、制約付き最適化問題を無制約最適化問題に変換可能になる。 正則化項があるロジスティック回帰の損失関数を読み解く 以上を踏まえて、本記事の目的だったロジスティック回帰の損失関数と正則化項の式を解釈していく。実際に書籍で唐突に出現している数式 この数式に 1/2n が含まれているが2は微分したときに打ち消されるように都合のいい数字を使っているだけ。nは正則化項を損失と同じスケールにしているだけ。どちらも、定数なのでまるっと無視すれば式 (2) は、 とすることができる。この式 (3) はロジスティック回帰の損失関数と正則化項の和になっているが、これはラグランジュの未定乗数法を使って制約付最適化問題をすでに無制約最適化問題に変換した後の式(ラグランジュ関数)である。つまり式(1)の不等式制約がないラグランジュ関数を考えると元の式は次の制約付きの最小化問題にほかならない。 このとき、R は 正則化パラメータλ で決まる実数である。式 (4) は ラグランジュの未定乗数法により式 (3) に変換できる。つまり、重みのL2ノルムの二乗がλで決まる実数に等しくなるような制約のもとに損失関数が最小になるところを探す問題を解きたかったということだ。こちらの方がイメージはしやすい。式 (4) は意味はわかりやすいものの計算はしにくいからラグランジュの未定乗数法を使って式 (3) のラグランジュ関数に変換しているのだ。ちなみに正則化パラメータがλなのは、ラグランジュ乗数がλだからなのだ。 ラグランジュの未定乗数法の注意点 制約付き最適化問題を無制約最適化問題に変換する利点は、無制約最適化問題の解法（勾配降下法、ニュートン法など）を使用して、制約付き最適化問題の解を求めることができる点である。しかし、KKT条件は局所最適解に対してのみ成立するため、最適解が複数存在する場合や非凸問題の場合は使えない(はず？ちょっと自信がない)。 なるほどわからんというときは・・・ 完全に理解しなくてもいいと思う。このYoutube動画はすごくわかりやすかった。 所感 理系の学生は学部で履修する範囲(微積分か線形代数でやったはず)だから自分も例にもれずにラグランジュの未定乗数法は習った。でも、テストの問題を解くために覚えていただけで、現実として何に使うかわかってなかった。こういうときに使うのか。 https://blog.takanabe.tokyo/2023/03/3ab6662e-251a-4125-aa82-1f2d9253a261/ Tue, 14 Mar 2023 09:00:00 +0000 https://blog.takanabe.tokyo/2023/03/3ab6662e-251a-4125-aa82-1f2d9253a261/ モチベーション 前回はモデルの過学習(Over-Fitting)と学習不足(Under-Fitting)の背後にある理論について調べた。今回はベクトルのノルムについて調べる。これは線形回帰モデルで過学習を避けるために使われる正則化を理解するのに必要な知識である。 ベクトルのノルム 線形回帰モデルの正則化には一般的に L1, L2 ノルムが用いられる。そのためノルムとはなにかをまず理解する。Wikipedia によるとノルムは以下のように説明されている。 解析学において、ノルム (英: norm, 独: Norm) は、平面あるいは空間における幾何学的ベクトルの “長さ” の概念の一般化であり、ベクトル空間に対して「距離」を与えるための数学の道具である。ノルムの定義されたベクトル空間を線型ノルム空間または単にノルム空間という。 細かいことはわからないが、要は平面や3次元空間のべクトルの距離みたいに人間が直感的に理解できる範囲を超えた高次元ベクトル空間でも距離を扱えるように一般化しているのがノルムということだろう。機械学習においては L1 ノルムと L2 ノルムが多く用いられるようだ。 Lp ノルム L1/L2 についている数字はどこからきたのか。これは Lp空間という関数空間の定義からきている。深く立ち入ると全く理解不能な文章を読むことになるのでサラッと理解すると、 数学の分野における Lp 空間（エルピーくうかん、英: Lp space）とは、有限次元ベクトル空間に対する p-ノルムの自然な一般化を用いることで定義される関数空間である ということらしい。このとき、実数 p ≥ 1 に対して、x の p-ノルム（p-乗平均ノルム）あるいは Lp-ノルムは次で定義される。 この Lp-ノルムの定義においてp=1 のとき、 となり、これが L1 ノルムになる。また、 p=2 のとき となるが、これが L2 ノルムである。 L1 ノルムはマンハッタン距離と呼ばれ、L2 ノルムはユークリッド距離と呼ばれこともある。 L1 ノルムのイメージ ベクトル \(\bm{x} = (3,4)\) が与えられたとき L1 ノルムは 7 となる。 https://blog.takanabe.tokyo/2023/03/7474a84c-525e-4cde-a3ee-dc551ca399d1/ Mon, 13 Mar 2023 14:00:00 +0000 https://blog.takanabe.tokyo/2023/03/7474a84c-525e-4cde-a3ee-dc551ca399d1/ モチベーション モデルの過学習(Over-Fitting)と学習不足(Under-Fitting)の背後にある理論について調べたので記録しておく。 モデルの複雑さと予測誤差の関係 機械学習のモデルは複雑なほどいいというわけではないらしい。機械学習では手元にあるデータを訓練データとしてすべて突っ込むのではなく、学習用のデータと評価用データに分けるのだが、モデルが複雑すぎると学習用のデータを過学習してしまって評価用のデータでいい結果をだせないという話だそうだ。反対にシンプルすぎるモデルは学習が不十分なため期待した予測が出来ない。シンプル過ぎず、複雑すぎないモデルの構築が予測の精度を上げるらしい。 予測誤差の期待値を分解する この話の理論的な背景を理解するには、予測誤差の二乗期待を考える必要がある。二乗しているのは実際の値と予測値の差が負にならないようにするためである。 予測の誤差の期待値は最終的に評価データの分散と予測の分散とモデルの予測の誤りの和として分解できる。 $$ \begin{aligned} E[(y-\hat{y})^2] &= Var[y] + Var[\hat{y}] + (E[y] - E[\hat{y}])^2 \newline &= Var[y] + Var[\hat{y}] + Bias^2 \newline &= 訓練データの分散 + 予測値(モデル)の分散 + 予測の誤り \end{aligned} $$ この中でモデル構築者がコントロールできるのは後者の2項であり。予測の分散のことをバリアンス(Variance)といい、モデルの予測の誤りをバイアス(Bias)という。ちなみにこのVarianceとBiasだが機械学習の用語というよりは統計の基本的な考え方である。 モデルの複雑さとVariance/Biasの関係 予測誤差における Variance と Bias の関係をモデルの複雑さと共に図示したものが以下。 モデルがシンプル過ぎて学習できてないことを High Bias または Under-Fitting、モデルが複雑過ぎて学習データに対してFitしすぎてしまっていることを High Variance または Over-Fitting という。 所感 High Variance と High Bias どっちが Over-Fitting でどっちが Under-Fitting だっけ？と忘れそうだが、背景にある理論を理解すれば忘れることはなさそうだ。 読んでいる書籍 以下の本の”3. https://blog.takanabe.tokyo/2023/03/0a27cc19-d60e-4ee5-847b-2cf5b8390149/ Thu, 02 Mar 2023 12:00:00 +0000 https://blog.takanabe.tokyo/2023/03/0a27cc19-d60e-4ee5-847b-2cf5b8390149/ モチベーション 満を持して登場した OpenAI の ChatGPT API と Whisper API について調べて使ってみる。 ChatGPT API とりあえず使ってみる Create chat completion (Beta) を curl で叩いてみる。 $ curl https://api.openai.com/v1/chat/completions \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer TOKEN' \ -d '{ "model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "Hello!"}] }' # Output: { "id": "chatcmpl-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", "object": "chat.completion", "created": 1677759352, "model": "gpt-3.5-turbo-0301", "usage": { "prompt_tokens": 9, "completion_tokens": 12, "total_tokens": 21 }, "choices": [ { "message": { "role": "assistant", "content": "\n\nHello there! https://blog.takanabe.tokyo/2023/03/04755641-07a3-42d6-a421-b3f8f6fe65b2/ Wed, 01 Mar 2023 12:00:00 +0000 https://blog.takanabe.tokyo/2023/03/04755641-07a3-42d6-a421-b3f8f6fe65b2/ モチベーション 前回までは Hugging Face Course をやっていたが、Transformer についてはまた別途学習したいと思っているため一旦中断して Hugging Face の他の機能を先に試してみることにした。今回は Hugging Face Spaces を使う。 Hugging Face Spaces とは MLのデモアプリをお手軽にホストできる機能。 Hugging Face Spaces offer a simple way to host ML demo apps directly on your profile or your organization’s profile. This allows you to create your ML portfolio, showcase your projects at conferences or to stakeholders, and work collaboratively with other people in the ML ecosystem. Hugging Face で Spaces のページを開き、”Create new Space” ボタンをクリックすると、以下のように自分がホストしたいMLアプリの Space が作成できる。Model や Dataset と同様に Space も Git repository として管理する。Pull Request などもあり、GitHub を使える人がスムーズに使えるようになっていることを見るに、幅広いソフトウェアエンジニアに使ってもらうことが狙いだとわかる。 https://blog.takanabe.tokyo/2023/02/2bf5af3a-3f7b-4fe3-8d56-21d7a7627027/ Sun, 26 Feb 2023 12:00:00 +0000 https://blog.takanabe.tokyo/2023/02/2bf5af3a-3f7b-4fe3-8d56-21d7a7627027/ モチベーション 前回 Hugging Face Course 1-1 ~ 1-3 にて Transformers の pipeline の使い方を学んだ。今回は Transformer の歴史とコンセプトを学ぶ Chapter 1-4: How do Transformers work? from How do Transformers work? - Hugging Face Course A bit of Transformer history 2017年にAttention Is All You Needという論文が発表されてから、Transformer モデルは急激に進化を遂げたようだ。上の年表から毎年のように新しいモデルが発表されていることがわかる。 NOTE: 画像はHow do Transformers work? - Hugging Face Courseより引用。 Transformers are language models 結局 Transformer ってなんなの？というのが素人にはわからないのだけど、Language Model の一種とのこと。Language Model というのは大量の raw text に対して自己教師あり学習を行ったことを意味していて、人間がラベル付きのデータを用意することなく、入力データから自動的に学習の目的を算出するとのこと。 学習済みのモデルはこのままだとタスクには使えないため、transfer learning(転移学習)を経て特定のタスクに対してチューニングする。transfer learning は人手でラベル付けされてデータが用いられる。 https://blog.takanabe.tokyo/2023/02/92d3a650-1b97-4951-968c-1f068df6083d/ Sat, 25 Feb 2023 07:00:00 +0000 https://blog.takanabe.tokyo/2023/02/92d3a650-1b97-4951-968c-1f068df6083d/ モチベーション 前回 Hugging Face という機械学習界隈の GitHub っぽいものを見つけた。自分が探していたものっぽさがあるのでその使い方を学ぶために、Introduction - Hugging Face Course をみてみた。 コースの構成 Hugging Faceが提供するエコシステムでNLPやってみようとコースみたいだ。エコシステムとは以下を指すみたいだが、素人なのでなんのことかわからない。 Hugging Face Hub Transformers Datasets Tokenizers Accelerate コースは全 12 Chapter から構成され、それぞれの Chapter は6-8時間かかると想定されているとのことなので、単純に計算すると100時間くらいはかかる。 コースの Chapter 1 ~ 4 で Transformers ライブラリーの使い方を学ぶ。モデルがどのように動作するのか、Hugging Face Hubでどう使うのか、また結果をHugging Face Hub で共有する方法を学ぶらしい。Chapter 5 ~ 8 で Datasets とTokenizersを学ぶ。これが終われば基本的なNLPの問題をとけるようになるらしい。Chapter 9 ~ 12 ではNLPの他にTransformer モデルを使う方法を学ぶ。これは、音声認識やコンピュータビジョンなど。最終的にTransformerモデルが幅広い機械学習の問題に適用可能ということがわかるらしい。 コースに必要な事前知識 Python 初歩的なディープラーニングの知識 (例えば、Practical Deep Learning for Coders - Practical Deep Learning) Pythonはいいんだけど、ディープラーニングの知識はないので、ちょっとやって無理そうだったら１冊くらい機械学習の本を読んで戻ってこよう。PyTorch や TensorFlow は知らなくてもいいけど、知っていると理解を助けるとのこと https://blog.takanabe.tokyo/2023/02/2072ad89-d75c-4051-8ef7-2bdcc725f819/ Thu, 23 Feb 2023 00:00:00 +0000 https://blog.takanabe.tokyo/2023/02/2072ad89-d75c-4051-8ef7-2bdcc725f819/ モチベーション AWSのブログを読んでいたら”AWS and Hugging Face collaborate to make generative AI more accessible and cost efficient“という記事を見つけた。瑣末を省くとHugging Face とコラボして Generative AI を進めていくという話。 We’re thrilled to announce an expanded collaboration between AWS and Hugging Face to accelerate the training, fine-tuning, and deployment of large language and vision models used to create generative AI applications. Generative AI applications can perform a variety of tasks, including text summarization, answering questions, code generation, image creation, and writing essays and articles. https://blog.takanabe.tokyo/2023/02/94d2aed4-aa92-48f5-9d3a-d764bce5a2f0/ Wed, 22 Feb 2023 00:00:00 +0000 https://blog.takanabe.tokyo/2023/02/94d2aed4-aa92-48f5-9d3a-d764bce5a2f0/ モチベーション 業務でも機械学習を使うことになったのと Generative AI に興味を持ったので使うだけでなく体系的な知識を学びたくなった。せっかくなので、素人がどのようにして機械学習周りの知識を習得できるのかあとで振り返ると面白いと思うので記録していこうと思う。 自分の立ち位置 理系の大学院卒。とはいえ線形代数、微分積分、確立・統計、情報理論などの細かい話は忘却の彼方である。当時、数学は好きでそれなりに真面目に取り組んでいたので頭の片隅にインデックスが残っていることを期待している。 達成したいこと 業務で機械学習関連の話題についていけるようになること 気になった Generative AI の原理を理解できるようになること。今は特に以下が気になっている Chat GPT Stable Diffusion Whisper 機械学習関連の論文を読んで数式を含めて原理がわかる程度の知識があること 達成する気がないこと 自分で新しい機械学習の理論を構築できるようになること 構築された理論やモデルを使って新しい価値を創造できるソフトウェアエンジニアというポジションで在りたい 読んでいる書籍 以下の本のChapter1 (数学基礎), 2 (微分), 3 (線形代数)まで読んだ。練習問題は少ないけど大学1年の数学をさらっとおさらいするにはちょうどいい難易度とボリュームだと思う。 人工知能プログラミングのための数学がわかる本 Author: 石川 聡彦 Manufacturer: KADOKAWA Publish date: 2018-02-24T00:00:00.000Z https://blog.takanabe.tokyo/2023/02/08c885eb-04d0-468d-b710-ca1b6d0b3c92/ Tue, 21 Feb 2023 12:30:00 +0000 https://blog.takanabe.tokyo/2023/02/08c885eb-04d0-468d-b710-ca1b6d0b3c92/ モチベーション ブログで数式を使えるようにしたくて Hugo で KaTex を導入したのでそのメモ Why KaTex? Hugo は公式に MathJax をサポートしているが KaTex の方がレンダリングが早く様々な SaaS (Wiki、ブログ)が数式のサポートで KaTex を使っているので本ブログでも KaTex を採用することにした。 Hugo で KaTex を使えるようにする 自分の使っているテーマのlayouts/index.htmlを見ると以下のように {{ partial xxxx.html }} で layouts/partials/xxxx.htmlを読み込んでいる。 $ cat themes/xxxxxx/layouts/index.html {{ partial "head.html" . }} <body> <div id="blog"> {{ partial "header.html" . }} {{ partial "sidebar.html" . }} {{ partial "post/header-cover.html" . }} <div id="main" data-behavior="{{ .Scratch.Get "sidebarBehavior" }}" class="{{ with .Params.coverimage }}hasCover{{ end }} {{ if eq . https://blog.takanabe.tokyo/2021/12/1338a4bc-1a89-41bb-bbaa-64546af7cfc2/ Sat, 25 Dec 2021 00:30:00 +0900 https://blog.takanabe.tokyo/2021/12/1338a4bc-1a89-41bb-bbaa-64546af7cfc2/ TL;DR ソフトウェアエンジニアが英語を使えるメリットは沢山ある ソフトウェアエンジニアとして英語を”話せる”の期待値は低い ソフトウェアエンジニアに必要なのは英語より専門性 モチベーション 今度転職する会社で英語の勉強を頑張っている人達がいるので以下の発言をしたところ 自分が日本にいながら英語を話せるようになるのに相当な試行錯誤したので、他のエンジニアには高速道路を走って行けるように惜しみない支援をしていきたい — Takayuki Watanabe (@takanabe_w) December 21, 2021 興味がある人、役立つ人がいそうだった。英語でソフトウェア開発の仕事ができる日本人、職場が増えて欲しいと日頃から思っているため、ブログにて考え方や勉強方法を分割してしたためることにした。本記事でソフトウェアエンジニアとっての英語が話せるというのはどの程度のレベルなのかについて定義し、別記事にてそのレベルに到達するためにどのように勉強すれば良いのか説明する。また、これらの記事はソフトウェアエンジニアとして必要な語学力をどのように身につけるのかという点に重きを置いている。他の業界で通じるかどうか不明である。 予め断っておくが、全てのソフトウェアエンジニアは英語が出来ないとダメとか全てのビジネスで国外のユーザも含めて考えろ、その分野の No.1 を狙え等と言うつもりは毛頭ない。国内のユーザに特化したサービスというのは単一民族国家かつ島国で暮らす我々日本人にはとても需要があることはわかっている。一方で、英語が近年のソフトウェア産業における自然言語のデファクトであることや日本語より使用者の人口が多いのは事実だ。だから日本のソフトウェアエンジニアや企業にハッパをかけるために英語を習得したり企業の共通言語を英語化することでソフトウェア開発企業ならメリットがあるんだよ、挑戦できる企業はバランスを考えて挑戦して欲しいな、というくらいの考えで書いていると受け取っていただきたい。 そもそも英語は必要か? 人による。必要ない人は本当に必要ないと思う。 DeepL のように精度の高い翻訳機が出てきているのは事実で、近い将来技術が言語の障壁を感じなくさせてくれる可能性はある。僕は国内外問わず英語で仕事をしていきたいため、ここではポジショントークを展開させていただきたい。すなわち、ソフトウェアエンジニアが英語を使えるメリットと企業が共通言語を英語にするメリットを列挙していく。 個人が英語ができることのメリット ソフトウェアエンジニア一個人としてみたときの英語ができることのメリットはこの辺だろうか。 より多くのユーザに自分が開発したソフトウェアを届けられる 自然言語は流行りの技術と違い一瞬で陳腐化することがない 一次情報にアクセスできる(洋書や公式ドキュメントの翻訳は必要ない) 海外のカンファレンスでコミュニケーションできる。または登壇できる 同じ職種なのに日系企業より高待遇 例えば、以下のツイートで触れている本は翻訳されてようやく日本で話題になったが、英語で本読むエンジニアはだいぶ前から目を通して議論を深めている。 I'm reading "Team Topologies". After I read Inspired, Accelerate, Elegant puzzle and this book, I found that there are my ideal organization structures in my mind. — Takayuki Watanabe (@takanabe_w) January 31, 2020 https://blog.takanabe.tokyo/2021/12/2021%E5%B9%B4%E3%81%AE%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E7%92%B0%E5%A2%83/ Thu, 16 Dec 2021 06:30:00 +0900 https://blog.takanabe.tokyo/2021/12/2021%E5%B9%B4%E3%81%AE%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E7%92%B0%E5%A2%83/ モチベーション 過去数年間リモートワークで作業してきている。リモートワークをする上で何が良かったか、何が良くなかったかなど変遷が見えると面白いと思ったので 2021 年 版を備忘録として残す。 デスク 作業用のデスクには昨年に引き続き Loctek Ergonomic 社が販売している FlexiSpot E7 を使っており、昨年買って一番よかったと思っている物だ。リモートワークが中心になると必然的に運動量が減るため仕事をしているときに立ちながら仕事をしたいと思い購入した。思惑通り毎日立ちながら作業やミーティングに参加しているため多少の運動不足解消に役立っている。また、昼食後も立ちながら作業をすることで睡魔が襲ってくることはない。 E7 はデスクの高さを4つまで記録できる機能があり、僕は椅子に座る時用とスタンディング用の2つを使っている。残りの2つは今の所使っていない。 今購入しようとすると FlexiSpot E8 電動昇降スタンディングデスク・セット というのが自分が購入したデスクの後継モデルだそうだ。 ちょっとしたものが入れられる引き出しがデスク天板についていると便利だと思ったのであとから自分でイセトウの引出しを取り付けた。 筆箱、Kindle などを入れている。引出し自体はあったほうが良いと思うが、実際に使ってみてもう少し高さがあればなーと思うことが多々あるので、この浅い引き出しはおすすめしない。 デスク周りの整理 スタンディングデスクはケーブルがごちゃごちゃになるとデスクに引っかかってしまい危険なので、メッシュタイプのケーブルトレーを天板の裏に取り付け必要な電源タップはほとんどそこに収納している。 上の写真の通りデスク周辺がきれいになるように天板裏でなんとかケーブル類をまとめている。また、モニターアームとケーブルトレイで偶然できた隙間が Mac を挟むのにちょうど良い大きさだっため、Mac もデスクの下に収納している。 充電用のケーブルをまとめておくケーブルホルダーはサンワダイレクトのマグネットでケーブルをくっつけておけるもの(写真手前に写っている物)を使っている。昨年はケーブルを挟むタイプのもの(写真奥に写っているもの)を使っていたが、ポロポロ落ちてしまってそれが結構ストレスだった。マグネットでくっつけるタイプにしてからはそのストレスもないのでこれからケーブルホルダーの購入を検討している人にはマグネットタイプをおすすめしたい。 デスク照明 手元で本を読んだり、事務作業をするとき用のデスク照明には引き続き BenQ ScreenBar Plus をつかっている。これはディスプレイに挟み込むように装着するライトで電源の供給は USB Type-A で行う。 昨年も書いたが 5000 円安い前のモデルとの差分は調光調整のボタンと自動調光のためのセンサーが ScreenBar 本体から分離して手元にあること。手元に調光調整機能があったほうが便利かなと思い最新モデルを購入したが、実際は電源の ON/OFF しかしていないので旧モデルで十分だと思う。 モニター・モニターアーム PC のモニターには Dell U4021QW 40インチワイド曲面USB-C HUB モニタ－を使っている。このモニター選んだ理由は 2 つある。1つ目は自分がマルチディスプレイがあまり好きではなく、大きなディスプレイ一枚で作業したい点。2つ目はディスプレイ自体が USB Hub になっている点だ。特に 2 つ目は便利で、別途 KVM や USB Hub を購入することなく Webカメラ、マイク、キーボード、マウスなどをプライベート用と仕事用の Mac で共有し瞬時に切り替えることができる。配線のストレスから解放されるためとても気に入っている。 https://blog.takanabe.tokyo/2021/11/cookpad-%E3%82%92%E9%80%80%E8%81%B7%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ Wed, 17 Nov 2021 06:30:00 +0000 https://blog.takanabe.tokyo/2021/11/cookpad-%E3%82%92%E9%80%80%E8%81%B7%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ TL;DR 約 6 年間所属した Cookpad を退職した 年明けに Launchable に入社する はじめに 2016 年に入社してから約 6 年間働いてきた Cookpad を退職することになったのでご報告。 何をやっていたか Cookpad にはインフラ部(現 技術部 SRE グループ) の Software Engineer として入社した。はじめの 1 年は海外事業のインフラ周りを主に担当しながら、広告事業、クックパッド料理教室、クックパッドベビー[1]など多くの案件に関わらせて頂いた。技術スタックや働き方が前職と全く異なっていたため最初はとても苦労した。当時の僕をオンボードしてくれたメンバーは大変だったと思う。今でもとても感謝している。 2 年目からは自分から上司に相談して海外事業に集中するためにインフラ部から海外事業部に異動した。そこからは SRE としてずっと働いてきたがプロダクト、チーム、組織が良くなることなら手当たり次第にやってきた。そのおかげもありとにかく色々な経験を積むことができた。Cookpad の海外サービスは約80カ国で展開しているため、世界中にユーザがいるからこそ発生する面白い案件にいくつも巡り会えた。一部を例に挙げると、 宗教由来のイベントに伴う長期間の高負荷への対策[2] M&A で仲間になった他社サービスのデータを既存の Production DB へ統合[3] GDPR を考慮したソフトウェア・システムの開発 AWS China をつかった中国大陸向けのシステム開発 [4] などがある。他にも案件ではないが、多国籍のメンバー[5]との開発、時差があるメンバーとの開発、世界中にユーザがいるので深夜メンテナンスが不可能だったことは自分の今後の開発を考える上で大きな経験となった。海外事業部には約 5 年間従事していたことになるが、そのうち 3 年間は Lead Engineer としてチームの構築や戦略策定もしていた。その中で採用にも大きく関与していたため、世界中のエンジニアと採用試験をする機会にも恵まれた[6]。どのくらいのペースで履歴書が届くのか、どの程度のスキルセットのエンジニアがマーケットに多くいるのか、どのようにしたら自分が採用したいエンジニアにリーチできるのか、それに合わせてどのようにチームを構築していくのか等、多くの試行錯誤をすることで様々な知見を得ることができた。 優秀なメンバーに囲まれて、毎年新しいことに挑戦できる最高の会社だった。 退職のきっかけ 家族のライフスタイルと自分のワークスタイルが合わなくなった、これに尽きる。僕は 2020 年の SRE NEXT 直後からイギリスのオフィスで働くことになっていたが、COVID-19 を理由にそれを辞めた。その間日本から時差 9 時間あるチームと働いてきた。それでも最近までは家族のライフスタイルとマッチしていたため全然問題なかった。しかし、子供が成長すると共に家族のライフスタイルが朝型になり、夜型だった今までのワークスタイルを貫くことは困難になった。 会社はすべての業務を非同期で行うこと、チームメンバーはチームの業務時間をシフトすることなど色々な提案をしてくれた。申し出は嬉しかったけど、イギリスの組織は今後は UTC±3 hours で働けるメンバーで組織を構築していく方針がある。そんな中、日本から働くメンバーに引きづられるのはどう考えてもいびつな状態だ。Lead Engineer の role を信頼できるチームメンバーに引き継いで1年半以上経過しており、また、今年の8月に組織体制の大きな変更がありエンジニアリングにおけるリーダの新旧交代もあった。タイミングを図っていたが、自分が抜けてもチームも組織も問題ないと判断したためイギリスのチームから抜ける決断をした。加えて、僕は仕事では英語を使いたいため、日本の組織で働くことは考えず新しい挑戦をするために転職をする運びとなった。 https://blog.takanabe.tokyo/2021/08/%E3%82%B3%E3%83%AD%E3%83%8A%E7%A6%8D%E3%81%A7%E5%BF%85%E8%A6%81%E3%81%AA%E3%82%82%E3%81%AE%E3%81%AF%E6%9C%89%E9%85%B8%E7%B4%A0%E9%81%8B%E5%8B%95%E3%81%A0%E3%81%A8%E3%81%84%E3%81%86%E8%A9%B1/ Tue, 24 Aug 2021 11:00:00 +0900 https://blog.takanabe.tokyo/2021/08/%E3%82%B3%E3%83%AD%E3%83%8A%E7%A6%8D%E3%81%A7%E5%BF%85%E8%A6%81%E3%81%AA%E3%82%82%E3%81%AE%E3%81%AF%E6%9C%89%E9%85%B8%E7%B4%A0%E9%81%8B%E5%8B%95%E3%81%A0%E3%81%A8%E3%81%84%E3%81%86%E8%A9%B1/ モチベーション コロナ禍でリモートワーク中心になってきた世の中で、あなたがやる気、集中力、記憶力、ストレス耐性を失うのはあなたの気合や仕事への興味が不足していることが原因ではない。有酸素運動が不足しているために自分が持つポテンシャルを発揮できていない可能性があるという話を自分の経験と一流の頭脳という本から得た知識を交えて伝えるためにこの記事を書くことにした。 コロナ禍で運動をしなくなった コロナ禍以前は”健康と体力のために”会社から通勤できる距離に住居を構えることで、日常に運動を取り入れる戦略をとっていた。しかし、コロナ禍でリモートワークが増えたことで家から出る頻度が激減した。また、会社が恵比寿から横浜に移転したことで運動による通勤は困難になった。加えて生活で必要な物もほぼ全てインターネットで購入して外出を最小限に留めている。引きこもりの誕生だ。 運動を止めて起きたこと リモートワークだと意識的に時間を取らないと日常的に運動というイベントが発生することはない。結果として運動をする時間がほとんどなくなった。その結果、何が起きるかをすぐ自覚するのは難しい。自覚症状が出てきたのはリモートワークが中心になって 1 年ほど経ってからだ。仕事のときの集中力と情報処理の能力が以前ほどないように感じられるのだ。”加齢が原因でしょ”と皆思うかもしれない。僕もそうだった。しかし、集中力と情報処理能力の欠如は10年前との比較ではなく、1年前と比べてだ。加齢が原因というにはあまりにも顕著だった。運動が完全に不足していると思うに至った決定打は健康診断の結果で 1 年前と比べて体重が 5kg 増えてたからだ。 ランニングを始める 流石にまずいと思い、仕事の休憩時間に数十分走る軽いランニングを始めた。ランニングは少し運動をするにはもってこいだった。運動着とシューズがあれば誰でもできる。また、運動をしてこなかった人がランニングをすると短い期間内で走れる距離がどんどん伸びていく。成長を感じられるまでの時間が短いのはモチベーションを維持するのにもプラスだった。そんなこんなでかれこれ数ヶ月ランニングをしている。そしてあることに気がついた。理由はわからないが以前のように仕事に集中できるようになったのだ。 人間には有酸素運動が必要 最初はランニングで体力がついたから仕事のパフォーマンスが上がったくらいに考えていたが、同じような悩みを抱えていた同僚が 一流の頭脳という本を科学的根拠がかいてあるとお薦めしていたので読んでみた。この本は脳科学の観点から有酸素運動がなぜ人間に必要なのかが書かれていた。端的に説明すると継続的に有酸素運動をすることで人間の脳は鍛えられる。有酸素運動後の数時間は脳が BDNF、ドーパミンなどの化学物質を分泌するためパフォーマンスが上がるということだった。これは人間は元来狩猟、採取、大陸移動をして生活をしていた生き物で体や脳は移動することそれらの活動に必要な反応と成長を見せるからだ。テクノロジーが急激に発展しようとも生物の進化は急激には進まないため、脳は狩猟をしていたときと比べて大きく変わっていない。だから、有酸素運動が必要なのだと。 有酸素運動がもたらす効用 有酸素運動ををすることで発生する脳内物質が我々の活動に良い影響を与えるというのはなんとなくわかったと思う。僕が抱えている問題に対してどのような効果があるか列挙してみる。 ストレスが溜まりやすくなった気がする 有酸素運動(ストレスをかける活動)を続けることで、運動外でもコルチゾール(ストレスホルモン)の分泌量が減るのでストレスが減る 集中力が持続しない気がする 有酸素運動をすることでドーパンミンやノルアドレナリンが分泌されるため集中状態に入りやすい。この効果は数時間続くため、朝に有酸素運動を取り入れると昼のパフォーマンスが上がる 記憶力が低下している気がする 記憶の中枢は脳にある海馬。有酸素運動をすることで発生する BDNF は海馬の成長を促し、記憶力が強化される 一昔前に脳トレのゲームが流行っていた時期があったが、脳の機能を高めるという観点では運動が圧勝であることは研究で繰り返し証明されている 以前よりやる気にムラがある 有酸素運動で BDNF、セロトニン、ノルアドレナリン、ドーパミン などの物質が分泌されるため意欲が向上する などなど。コロナ禍以前は毎朝数十分の運動をしながら通勤をしていたことで図らずとも自分のパフォーマンスは上がっていたようだ。これらを踏まえると、コロナ禍で家にこもっている人が集中力、記憶力、ストレス耐性を失うのはその人の気合が不足しているせいではない。有酸素運動をしなくなり、脳に必要な科学物質が不足してしまうことが原因であるというのはあながち間違っていないのではないだろうか。 著書でおすすめしている有酸素運動 著書では軽い息切れを起こす程度の負荷で数十分有酸素運動をすることで脳の成長とパフォーマンス向上を促すことが一貫して説明されている。特に BDNF という本書で奇跡の物質、脳内最強の物質[1]とされている物質は有酸素運動をすることで生成される。筆者がおすすめしている有酸素運動は以下のようなもの。 ランニング スイミング サイクリング テニス スキーのクロスカントリー ウォーキングも著書の中では比較的おすすめの運動に分類されているが、軽い息切れを起こす(心拍を上げる)レベルの負荷でウオーキングするのは難しいと思うので素直にランニングをするのが良さそうだ。 まとめ 脳科学の本を大量に読み込んでいるわけではないが、データに基づく論理的な説明が多く腑に落ちることが多かった。僕のように運動が続けられない人は結局何か運動の効用を信じられる、自分を後押ししてくれる情報が必要なんじゃないだろうか。そんな人は一度この本を手にとって読んで見てほしい。運動の沢山のメリットを理解することでそれがモチベーションになるかもしれない。リモートワークが多くなった今こそ、意識して有酸素運動を習慣化することで自分の健康もパフォーマンスも最大に維持されるようにしていきたい。 [1]胡散臭くなってきたが著書では科学的な根拠とデータを持って説明している。 一流の頭脳 Author: アンダース・ハンセン Manufacturer: サンマーク出版 Publish date: 2018-02-23T00:00:01Z https://blog.takanabe.tokyo/2021/01/2020-%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/ Wed, 06 Jan 2021 16:00:00 +0000 https://blog.takanabe.tokyo/2021/01/2020-%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/ モチベーション 激動の 2020 年が終わり 2021 年が始まったので昨年を振り返る。 TL;DR COVID-19 で世界中ぐちゃぐちゃ SRE team の Lead をバトンタッチして IC に戻った プライベート COVID-19 新型コロナの影響で世界中がぐちゃぐちゃになった。年初にプライベートと仕事で計画していたことはすべて崩壊し、自分が希望していた所属している会社での海外出向は諦めた。出向を断念することになり気落ちした時期もあったが、コントロールできないことでいつまでもくよくよしていても時間の無駄なので、早い段階でマインドを切り替え今できることをしている。 家篭り 今年はほとんど家にいた。緊急事態宣言が出ているとか、いないとか関係なしに子供との散歩と運動以外で外出することは無かった。職業柄リモートワークが基本で会社に出勤しなくて良かっため、妻子と一日中一緒にいる時間が長くなった。仕事を辞めずに 1-2 歳の子供の成長をこんなに間近で見守り続けられると思っていなかったので、これに関してはコロナ禍で唯一自分にとっていい出来事だった。今後の人生でこんなに一緒に生活できることはなさそう。 デスク周りを改善した “リモートワーク環境を整えました“にまとめたとおり、向こう数年は引きこもる可能性があるためオフィス以上に生産性を上げるための投資をした。購入したなかで一番よかったものは大きな天板のスタンディングデスク。 Fitbit で腕が痺れる ウェアラブルデバイスの検証用兼に購入した Fitbit Inspire 2 が体に合わなかった。緑色 LED が自分の体になにかしらの影響を与えているのか、それとも Fitbit Inspire 2 自体が自分に合わなかったのかわからないが、装着すると肩から腕にかけて痺れるような感覚を持つようになった。明らかに普通の状態ではないため、使用して数日で装着を止めた。常に家にいて、すべての活動をコントロールしやすい状況なので自分に合うものがみつけたい。 こんなことを書くくらいにはプライベートでは何もなかった。 仕事関連 Individual Contributor (IC) に戻った 2019 年に Cookpad のグローバルプロジェクトの SRE チームの立ち上げを完遂した。今では Senior SRE が 8 人もいるチームに成長している。一区切りついたのと、長い間チームをリードするポジションにいたため、今後のキャリアのことを考えて 4月に Tech Lead (TL) と Engineering Manager (EM) の Role を他のメンバーにバトンタッチした。 理由としては、これ以上長い期間リードのポジションで働いていると Individual Contributor として働くことが困難になることと、Tech Lead としてのパフォーマンスが年々低下していくと考えたため。自分の理想のキャリアラダーは会社に所属している間は一定周期で IC と 組織をリードするポジションを行ったり来たりすることだが、この発想は THE ENGINEER/MANAGER PENDULUM や ENGINEERING MANAGEMENT: THE PENDULUM OR THE LADDER で語られていることに非常に近い。 https://blog.takanabe.tokyo/2020/10/%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E7%92%B0%E5%A2%83%E3%82%92%E6%95%B4%E3%81%88%E3%81%BE%E3%81%97%E3%81%9F/ Mon, 26 Oct 2020 22:00:00 +0900 https://blog.takanabe.tokyo/2020/10/%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E7%92%B0%E5%A2%83%E3%82%92%E6%95%B4%E3%81%88%E3%81%BE%E3%81%97%E3%81%9F/ TL;DR リモートワーク環境を刷新して仕事の効率が最高になった(と思う) モチベーション コロナ禍でリモートワークが当たり前になってきた。また、2020 年を契機にリモートワークができる職場が世界中で増えて行くことはほぼ間違いない。そこで、リモートワークの作業効率を向上させることを目的に自宅での作業環境を改善したのでその記録を残す。 スタンディングデスクの導入 スタンディングデスクの選択 スタンディングデスクは所属している会社で使っており、いつか家でも使いたいと思っていた。リモートワークが中心になり、今後もこのワークスタイルが続くことを踏まえ、少しでも運動不足解消の助けになればと思い導入することにした[1]。 スタンディングデスクにはいくつか種類があり、今回購入したのは電動昇降機能付きスタンディングデスクでボタンを押すと予め登録した高さに上下する。手でハンドルを回して高さを調整するタイプもあるのだが、僕はその作業自体が億劫になることが容易に想像できたのでそちらは選択肢から外した。 電動昇降機能付きスタンディングは中国の Loctek Ergonomic 社が販売している FlexiSpot を購入した。FlexiSpot を選んだ理由は Youtube でレビューの評価も動作している感じも良かったから。 FlexiSpot にはいくつかのバリエーションが存在するが、今回は FlexiSpot 電動式昇降デスク E7セット (140cm x 70cm の天板付き) を購入。天板は気に入らなければ後で別のものに変更することができるので、とりあえず今は公式のものでいいと考えた。E7 は FlexiSpot ラインで最近発売された型で、障害物検知機能がついている。障害物検知機能はおまけくらいの気持ちだったが、実際には自分にとっては重要な機能だった。気が付かないときにデスクが椅子などの障害物に引っかかっていることが結構あるからだ。 注文するとスタンディングデスク本体に在庫がなかったらしく、天板だけ先に到着した。この時間差のは配達は結構迷惑だった。注文した天板は 140cm x 70 cm なので大きさもさることながら、めちゃくちゃ重い。具体的な重量は測定しなかったが、一般的な成人男性でも一人で運ぶのであればかなり気合を入れないと持ち上げることはできない。スタンディングデスク本体が到着したのはその2-3週間後だったが、自室しか置くスペースがなかったのでそれまでの間は天板と一緒に寝る生活を強いられた。 デスク周りのケーブル配線をスッキリさせたかったので、アクセサリのケーブルダクトもついでに購入した。 スタンディングデスクの組み立て 再度購入するときのために組み立ての Tips も残しておく。スタンディングデスクの組み立て手順は説明書を読めば簡単に理解できる。ただし、電動ドライバーとドリルは予め準備しておいたほうが良い。電動ドライバーは必須ではないが、無理な体制で普通のドライバーでネジを回すのはかなり大変だ。また、ドリルも必須ではないが、天板に本体やダクトを装着するために頑丈な天板にネジ穴をあける必要がある。それをキリやドライバーでするのは不可能とは言わないが、ドリルでやったほうが無難だろう。ちなみに調子に乗ってドリルで天板を貫いた。天板の厚みは意識すること。 スタンディングデスクの組み立てを一人でする場合は腰、背、腕などのストレッチを十分に行ってから取りかかること。天板もスタンディングデスク本体もめちゃくちゃ重い。瞬間的にかなりの力を使う場面が何回かあったので、作業中に体を傷めないように注意。 デスク周りの整理 スタンディングデスクはケーブルがごちゃごちゃになるとデスクに引っかかってしまい危険だ。上述のケーブルダクトに加えてなるべくデスク周りを適度にきれいに保てるように工夫した。 まず、メッシュタイプのケーブルトレーを天板の裏に取り付け必要な電源タップはほとんどそこに収納することにした。ケーブルトレーは友人がオススメしていたサンワサプライのものを使用している。 サンワサプライ ケーブル配線トレー メッシュ 汎用タイプ CB-CT5 Author: N/A Manufacturer: サンワサプライ Release date: N/A ちょっとわかりにくいが、天板裏にこのように延長ケーブルと電源を集約している。 また、机の上を常に広く保つために余計な物やケーブル類はなるべく机に出ないように工夫した。これには両面テープで貼り付けるタイプのケーブルホルダーを使った。 https://blog.takanabe.tokyo/2020/04/github-cli-%E3%81%AF-hub-%E3%81%AE%E4%BB%A3%E3%82%8F%E3%82%8A%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%8B/ Fri, 24 Apr 2020 22:00:00 +0900 https://blog.takanabe.tokyo/2020/04/github-cli-%E3%81%AF-hub-%E3%81%AE%E4%BB%A3%E3%82%8F%E3%82%8A%E3%81%AB%E3%81%AA%E3%82%8B%E3%81%8B/ TL;DR github.com だけをを使っている場合 GitHub CLI は hub の代わりになる GitHub Enterprise には現在(2020/4/24 時点)対応していないので僕の用途では hub の代わりにはならない 2020/9/17 の GA のタイミングで GHE 対応しました！ モチベーション GitHub CLI でできることが増えてきたので普段 GitHub の CLI クライアントとして使っている hub から移行できるか調査した。 Repositoryの操作 repository コマンドは以下のコマンドしか使わなそう。 $ gh repo view -w # 現在の repository をブラウザで表示する Issueの操作 自分が使いそうな issue の基本的なコマンドとオプションはこの辺。 $ gh issue create # issue を terminal 上で作成する $ gh issue list -L 200 # 検索を結果を 200 件まで表示 (default 30) $ gh issue list -a takanabe # assignee:takanabe を使って issue を検索する $ gh issue list -l Type:Reactive # label:Type:Reactive を使って issue を検索する create コマンドは issue 作成に必要な項目をインタラクティブに好きなエディタで入力できるし、GitHub issue template も使えるので便利。 エディタは EDITOR=nvim のように環境変数で設定しておくか、 gh config コマンドでエディタの設定をすること。 list コマンドは peco などの interactive filter と組み合わせることでさらに便利になる。例えば、以下のような使い方。 https://blog.takanabe.tokyo/2019/12/2019-%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/ Tue, 31 Dec 2019 23:00:00 +0000 https://blog.takanabe.tokyo/2019/12/2019-%E5%B9%B4%E3%81%AE%E6%8C%AF%E3%82%8A%E8%BF%94%E3%82%8A/ モチベーション 令和元年の 2019 年も今日で最終日なので一年を振り返る。 TL;DR 子供が生まれた。めちゃくちゃかわいい 年初にアメリカの Computer Science 系の大学院合格したが、 現職で引き続き SRE として働いている 所属するグローバルチームの SRE チームの立ち上げを完遂しつつ、組織に SRE を実装した 組織論の復習と近代 Engineering Management ノウハウの獲得と実践を行った プライベート 子供が生まれた 去年の出来事としてカウントするか微妙だけど、2018 年の 12 月に子供が生まれました。 2019 年 1 月生まれの予定だったのですが、妊娠高血圧症候群(?)で妻の血圧が 200 近くまで上がってしまいました。入院して落ち着くのを待つこともあるとのことでしたが、妻の場合どんどん血圧が高くなってしまい、命の危険性があったので手術での出産となりました。 出産後も妻の体調はなかなかよくならず長期で入院したり、数ヶ月薬で血圧を抑える生活でした。今は母子ともに元気で、赤ちゃんは洋服をタンスから引張りだして床にばらまくのが日課になっています。かわいい。 アメリカの大学院に合格したけど行くのを辞めた 3月にはアメリカの Computer Science 系の大学院に合格しました。 大学院合格についてとその動機について興味がある方は “Carnegie Mellon University に合格した話” を見ていただきたい。そこに全て書いてあります。 また、現在は留学はしないで Cookpad で SWE in SRE として働いています。 大学院に行かない理由は色々ありますが、以下が主です。 妻の体調が心配だった 仕事である程度裁量を得られて、チームメンバーも良い人を集められた 申請していた奨学金に全て落ちたので、大学院の学費が金銭的に辛い アメリカの大学院に今回行かなかったけど、最低限の語学力が付いていることは明らかだし、今は行きたくなったらまた挑戦すればいいだけと考えています。業務や on-call をこなしながらの大学院受験は大変ですが、限られた時間でそれを突破したという経験は大きな自信になりました。 仕事関連 グローバルチームの SRE チームの立ち上げを完遂 Cookpad のグローバルサービスの SRE チームの立ち上げを完遂しました。 https://blog.takanabe.tokyo/2019/03/carnegie-mellon-university-%E3%81%AB%E5%90%88%E6%A0%BC%E3%81%97%E3%81%9F%E8%A9%B1/ Tue, 26 Mar 2019 13:11:06 +0000 https://blog.takanabe.tokyo/2019/03/carnegie-mellon-university-%E3%81%AB%E5%90%88%E6%A0%BC%E3%81%97%E3%81%9F%E8%A9%B1/ モチベーション 昨年密かに受験したアメリカの Computer Science 大学院の受験結果が返ってきたので、その報告となぜ大学院受験を志したのかを共有したい。なお、このブログは僕が所属している会社とその社員の意見は一切含まない、僕自身の考えを綴る場です。 アメリカの大学院に合格しました 普段の業務がそれなりに忙しく、休日の on-call 対応などもあったため計画どおりに勉強できることは少なかったのですが、Carnegie Mellon University Master of Software Engineering の合格通知が先日ありました。 Carnegie Mellon University とは Carnegie Mellon University はアメリカのペンシルベニア州南西部に位置するピッツバーグにある私立大学。通称 CMU 。U.S. News & World Report の調査によると CMU は MIT、Stanford、UC Berkeley と並びコンピュータ・サイエンスにおいて世界トップクラスの大学とされています。 特に得意としている分野は以下の通り。 僕の尊敬している Andy Pavlo もここの Database Group に所属して教鞭をとっています。 Master of Software Engineering とは Master of Software Engineering (MSE) は CMU の Institute for Software Research が提供している修士課程です。CMU の大学院では Computer Science 学部 (School)がさらに細かく分野ごとに分割されており、Institute for Software Research もその一研究機関。MSE の特徴的なのは応募者は2年以上の産業界での実務経験が必要なところ。ソフトウェアエンジニアが次のレベルに進むことを目的として参加するプログラムです。 https://blog.takanabe.tokyo/2019/03/2-%E5%B9%B4%E9%80%A3%E7%B6%9A%E3%81%A7-cookpad-techconf-%E3%81%A7%E7%99%BA%E8%A1%A8%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ Fri, 08 Mar 2019 04:57:34 +0000 https://blog.takanabe.tokyo/2019/03/2-%E5%B9%B4%E9%80%A3%E7%B6%9A%E3%81%A7-cookpad-techconf-%E3%81%A7%E7%99%BA%E8%A1%A8%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F/ Motivation 普段、海外に行ったり来たりしていて自分の活動を国内のエンジニアに共有することはあまりないので、年に一度くらい大きな場で発表するかというスタンスなのですが、幸運なことに所属している会社の TechConf で 2 年連続で海外展開における SRE の取り組みを発表させていただきました。生存報告として残しておきます。 発表内容 TechConf 2018 では海外展開ならではの話を多めにしていますが、TechConf 2019 では海外展開中に得られた知見と失敗についてです。泥臭い業務、プロセス、失敗の共有にこそ価値があると思っているので今後もキレイごとだけではなく、現場のリアルを共有していきたいです。以下は僕のお気持ちです。 海外展開に挑戦してる日本のソフトウェアサービスのあらゆる失敗と課題を共有して一社でも成功させたいな。世界を舞台にしてマネタイズも含めて成功する会社がないうちは、成功してる国のエンジニアより全体的に給料が低いのは自明だよね — Takayuki WATANABE (@takanabe_w) 2019年2月17日 3rd season があるかどうかは、今後の僕と会社の頑張り次第です。 https://blog.takanabe.tokyo/2018/08/toefl%E3%81%A7100%E7%82%B9%E8%B6%85%E3%81%88%E3%82%8B%E3%81%BE%E3%81%A7%E3%81%AB%E3%82%84%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8/ Sun, 26 Aug 2018 03:00:05 +0000 https://blog.takanabe.tokyo/2018/08/toefl%E3%81%A7100%E7%82%B9%E8%B6%85%E3%81%88%E3%82%8B%E3%81%BE%E3%81%A7%E3%81%AB%E3%82%84%E3%81%A3%E3%81%9F%E3%81%93%E3%81%A8/ モチベーション 仕事で必要な語学力強化の一環で年内にTOEFL100点突破を目標としていました。約半年毎日勉強し続けて、7月に104点を取得したので誰かの役に立つかもしれないので勉強方法を備忘録として残します。 なぜTOEFLを勉強するのか 仕事の採用面接やMTGのファシリテーションなど海外のエンジニアとコミュニケーションを取る機会が多く、その質が自分やチームの業務のアウトプットや効率に直結していると感じたので自力の底上げを図りたいと思ったのがきっかけでした。 あとは仕事の情報収集が最近は英語で本を読んだり、ポッドキャストを聞いたり、Youtubeを観たりとほぼ英語になっており、英語の情報処理能力をワンランクアップさせたいなと考えていました。 それまでも、GABAやDMMで英会話の勉強をしたり、海外のドラマを見たりと毎日色々な形式で勉強を続けていましたが、もう少し難易度の高い英語で自分に負荷をかける時期だと判断し、総合的に考えてTOEFL100点取得に時間を投資することを決めました。 万人に適切な手段なのかは正直疑問だけど、自分の場合数値目標があったほうが達成度を実感しやすい性分でモチベーションが保ちやすいことは分かっていました。なので、悪くはない選択だったと思う。 英語の利用習慣 一応、自分の英語の利用頻度 にも軽く触れておくと、現職ではサービスの海外展開を主に担当しているため、英語を使わない日はほとんどないです。ただ、エンジニアなので文書書いたり、コード書いたりする時間が多く、業務では主に読み書きでよく使います。英語を話すのは、カンファレンスでのプレゼン、MTGでの議論、採用面接などで必要に迫られたらという感じです。 勉強前後の語学力の変化 TOEFL勉強前の語学力 TOEIC 900点前後 ネイティブ同士の会話はほとんど聞き取れない TOEFL勉強後の語学力 MTGで効率の悪い話し方をしなくなった ライティングのスピードがものすごく上がった　 ネイティブ同士の会話が多少聞き取れるようになった 海外のドラマで出てくるフレーズに対する理解度が上がりより楽しめるようになった TOEFLの試験形式 試験時間は合計4時間弱で以下の順番で進んでいく。 リーディング: 60～80min リスニング: 60～90min 休憩: 10min スピーキング: 20min ライティング: 50min リーディングとリスニングの時間がブレるのは、必ずどちらかで点数に反映されない問題を解く必要がありその分時間が伸びるため。 4時間もの試験を受けるのは正直ダルいを超えてシンドイのですが、この負荷が一種自分が求めていたものなので、これを乗り越える訓練をしました。 スコア推移 1月から勉強を開始して、最終的なスコアは104。初回受験から見ていくと順調に伸びたように見える。とはいえ、5,6月は相当な時間勉強したのにもかかわらず、6/10の結果でかなり点数が下がったのでショックだった。この日は睡眠不足や体調不良などで集中力を保つには厳しいコンディションだったので、試合の前に既に負けていたのかもしれない。 試験日 スコア 勉強配分メモ 2018/2/4 計92: R:24, L:23, S:19, W:26 語彙強化:100%、当日に問題形式を把握して受験 2018/4/16 計96: R:26, L:25, S:22, W:23 語彙強化:60%、長文読解強化:20%、残り20% 2018/6/10 計92: R:23, L:25, S:17, W:27 語彙力強化:50%、リスニング強化:30%、残り:20% 2018/7/7 計104: R29, L:27, S:23, W:25 語彙力強化:30%、長文読解強化:20%、リスニング強化:30%、スピーキング強化:20% 勉強方法 勉強の頻度 出社前に朝2時間、帰宅後に1時間。週末に5時間くらいのペースで半年勉強していました。それぞれのパートの勉強方法は以下の通りです。 https://blog.takanabe.tokyo/2017/03/mysql5.7myisam%E3%81%A7geometry%E5%9E%8B%E3%81%AE%E6%8C%99%E5%8B%95%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B/ Mon, 20 Mar 2017 17:24:57 +0000 https://blog.takanabe.tokyo/2017/03/mysql5.7myisam%E3%81%A7geometry%E5%9E%8B%E3%81%AE%E6%8C%99%E5%8B%95%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B/ モチベーション MySQLでのGeometry型を扱う知見がないので調査する。また空間インデックスによる検索のパフォーマンスを確認する。 準備 MySQL Serverを準備する。 docker version Client: Version: 17.03.0-ce API version: 1.26 Go version: go1.7.5 Git commit: 60ccb22 Built: Thu Feb 23 10:40:59 2017 OS/Arch: darwin/amd64 Server: Version: 17.03.0-ce API version: 1.26 (minimum version 1.12) Go version: go1.7.5 Git commit: 3a232c8 Built: Tue Feb 28 07:52:04 2017 OS/Arch: linux/amd64 Experimental: true docker pull mysql/mysql-server docker run --name db -e MYSQL_ROOT_PASSWORD=pass -d mysql/mysql-server:5.7 docker container ls CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d3bcb42ada91 mysql/mysql-server:5. https://blog.takanabe.tokyo/2016/12/%E5%B9%B4%E6%9C%AB%E3%81%A0%E3%81%97%E5%8C%85%E4%B8%81%E3%82%92%E3%81%A1%E3%82%83%E3%82%93%E3%81%A8%E7%A0%94%E3%81%94%E3%81%86/ Thu, 29 Dec 2016 06:43:48 +0000 https://blog.takanabe.tokyo/2016/12/%E5%B9%B4%E6%9C%AB%E3%81%A0%E3%81%97%E5%8C%85%E4%B8%81%E3%82%92%E3%81%A1%E3%82%83%E3%82%93%E3%81%A8%E7%A0%94%E3%81%94%E3%81%86/ モチベーション 包丁の切れ味が悪くなってきたのでちゃんと包丁を研げるようになりたい。 砥石を使った研ぎ方 昔ながらの砥石を使った研ぎ方は以下を見ると良い。 包丁の正しい研ぎ方 - YouTube 刃物専門店 宮文　「両刃包丁の砥ぎ方」 - YouTube シャープナーを使う方法 砥石を使ってシャッシャと研ぐものだと思っていたけど、シャープナーなるものがあるらしい。なにこれ簡単で便利！と思ったけど、そもそもシャープナーと砥石は包丁の切れ味を良くするための原理が違うみたい。 シャープナーは「こすっている」だけ。プロに聞く、砥石で包丁を研ぐコツ | ROOMIE（ルーミー）やシャープナーは包丁を切れなくする？？｜10年かかるプロの料理技術を３ヶ月で習得！！AmaZing FRENCH によると、 ではシャープナーはどうかと言うと、実はシャープナーでは刃を薄くすることはできないんです。その代わり、刃先に傷をつけてギザギザにすることによって切れ味を出します。 これはノコギリと同じ原理ですね。ギザギザがあるとゴリゴリ切れていくので、切れるようになった感じがするのです。 よくお皿の裏で包丁をシャッシャッとこすって包丁を切れるようにすることがありますが、あれもこれと同じ原理です。 切れるように包丁を削っているわけではないのですぐに切れ味が悪くなるし、長期的にドンドン切れにくい包丁にしてしまうようです。なので僕は砥石を使って行こうかな。 良さそうな砥石 砥石の粒度で使い分けをする人もいるみたいだけど、一つで済ませたい人は中砥石が良いようだ。自分がみたなかで中砥石な”シャプトン 刃の黒幕 オレンジ 中砥 #1000”が良さそう。 シャプトン 刃の黒幕 オレンジ 中砥 #1000 Author: N/A Manufacturer: シャプトン(Shapton) Release date: N/A サポートアイテム 包丁研ぎ初心者の時は研いでいるときに包丁と砥石の適切な角度を保つのが難しい。そこで、それをサポートする物が清水製作所のスーパートゲールである。　 清水製作所 庖丁とぎ角度固定ホルダー スーパートゲール Author: N/A Manufacturer: 清水製作所 Release date: N/A これらをつかって包丁を研いで行こうと思います。 https://blog.takanabe.tokyo/2016/08/fluentdtd-agent%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%82%92%E7%A9%BA%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B/ Sun, 14 Aug 2016 18:44:28 +0000 https://blog.takanabe.tokyo/2016/08/fluentdtd-agent%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%82%92%E7%A9%BA%E3%81%A7%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B/ モチベーション PRレビュー依頼でたまにfluentdの設定レビューをすることがあるが、その場でドキュメントを読むと効率や精度が悪い。業務効率化のために今一度復習して頻出の設定に関して空で書ける・読めるようにする。 fluentdの周辺知識を復習する 各種ディレクティブで使えるパラメータは公式ドキュメントを見た。全体像をつかむなら以下の本が分かりやすい。だいぶ前に読んだのを読み返した。 サーバ／インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築！] Software Design plus Author: N/A Manufacturer: 技術評論社 Publish date: 2014-08-14 検証環境 本記事の検証環境構築用Vagrantfileと設定ファイルはここで管理している。以下の構成を作り、webで生成されたログをelasticsearchに突っ込む。webではnginxのアクセスログだけでなく、簡単なrubyスクリプトで生成されたログもfluentdでルーティングすることとする。 [ web ✕ 2 ]<-->[ aggregator ✕ 2 ]<-->[ elasticsearch ] 準備 共通設定 公式ドキュメントに従い、ファイルディスクリプタの上限を変更しておく。またホスト名やntpの設定など共通の設定をする。 $ ulimit -n 1024 $ sudo tee -a <<EOF /etc/security/limits.conf root soft nofile 65536 root hard nofile 65536 * soft nofile 65536 * hard nofile 65536 EOF $ sudo tee -a <<EOF /etc/hosts 192. https://blog.takanabe.tokyo/2016/07/aws-cli%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6rds%E3%81%AEparameter-group%E3%82%92region%E3%82%92%E8%B7%A8%E3%81%84%E3%81%A7%E3%82%B3%E3%83%94%E3%83%BC%E3%81%99%E3%82%8B/ Sun, 17 Jul 2016 03:31:55 +0000 https://blog.takanabe.tokyo/2016/07/aws-cli%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6rds%E3%81%AEparameter-group%E3%82%92region%E3%82%92%E8%B7%A8%E3%81%84%E3%81%A7%E3%82%B3%E3%83%94%E3%83%BC%E3%81%99%E3%82%8B/ モチベーション すでにTokyoリージョンでRDSを運用していて、Virginiaリージョンで新しくRDSを立てるときTokyoリージョンにあるParameter Groupと同じ設定のものをVirginiaリージョンで使いたかった。はじめは、copy-db-parameter-groupを使ってParameter Groupをクロスリージョンでコピーしようとしたがどうやらできないようなので、describe-db-parametersを使って力技で解決した。今後も同じことをする可能性が高いのでメモを残しておく。 copy-db-parameter-groupを使ってみた copy-db-parameter-group AWS CLI 1.10.47 Command Referenceをみると、ARNを指定すればクロスリージョンでParameter Groupをコピーできるようなことが書かれているのでやってみた。 # 同一リージョンの場合 aws rds copy-db-parameter-group \ --region us-east-1 --source-db-parameter-group-identifier source-pg \ --target-db-parameter-group-identifier dest-pg \ --target-db-parameter-group-description 'copy test' { "DBParameterGroup": { "DBParameterGroupName": "dest-pg", "DBParameterGroupFamily": "mysql5.6", "Description": "copy test" } } 同一リージョンで名前指定で実行するとコピーができた。一方で、リージョンをまたいでARN指定でコピーをすると以下のようなエラーが発生してコピーできない。 # クロスリージョンの場合 aws rds copy-db-parameter-group \ --region ap-northeast-1 --source-db-parameter-group-identifier arn:aws:rds:us-east-1:<your_acccount_id:pg:source-pg \ --target-db-parameter-group-identifier dest-pg \ --target-db-parameter-group-description 'copy test' A client error (DBParameterGroupNotFound) occurred when calling the CopyDBParameterGroup operation: DB ParameterGroup not found, not allowed to do cross region copy. https://blog.takanabe.tokyo/2016/05/mysql%E3%81%AEmaster%E3%83%95%E3%82%A7%E3%83%BC%E3%83%AB%E3%82%AA%E3%83%BC%E3%83%90%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEmha%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%A8%E8%A8%AD%E5%AE%9A/ Wed, 04 May 2016 07:05:44 +0000 https://blog.takanabe.tokyo/2016/05/mysql%E3%81%AEmaster%E3%83%95%E3%82%A7%E3%83%BC%E3%83%AB%E3%82%AA%E3%83%BC%E3%83%90%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEmha%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%A8%E8%A8%AD%E5%AE%9A/ モチベーション MySQLのフェールオーバを実現するためにMHAのインストール、設定、動作確認がしたい。 MHAとは MHAとは障害発生時にMasterのフェールオーバを自動化とスレーブの昇格を短いダウンタイムで自動的に行うためのツール。この辺をツールなしにやろうとするとミスオペの危険を孕んでいるし、何より手順が複雑で面倒なので大変便利なツールである。今回はそのツールの設定から動作確認までを行おうと思う。 検証環境 MHA用サーバ×1、MySQL Master×2、Slave×2にて検証を行う。 検証で使うVMはVerification of Master HA setting and behavior · GitHubを利用した。一連の手順は理解を深めるために手打ちで実施した。 mhaでの各コマンド実行結果は以下の通り。 vagrant@mha:~$ uname -a Linux mha 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux vagrant@mha:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.4 LTS Release: 14.04 Codename: trusty MHA利用の前準備 以下のことを踏まえてレプリケーションとsshの設定をする。 MHAはレプリケーションの設定には関与しない。レプリケーション周りは全て自分で設定する。(逆に言えば、レプリケーションが設定されている既存の環境に簡単に導入できる) MHA nodeはmha,master,slaveの全てで必要 mha managerも内部的にmha nodeモジュールを必要とするのでインストールする必要あり Master/Slaveでレプリケーションの設定ができていること MHA、Master、Slave間で公開鍵を使ったssh接続ができること レプリケーションの設定をする Masterの設定 Masterにするmaster1にMySQL5. https://blog.takanabe.tokyo/2016/04/%E5%B7%A8%E5%A4%A7%E3%81%AA%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AE%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8Balter-table%E5%AE%9F%E8%A1%8C%E6%99%82%E9%96%93%E3%81%AE%E6%A6%82%E7%AE%97%E6%96%B9%E6%B3%95/ Thu, 07 Apr 2016 15:04:32 +0000 https://blog.takanabe.tokyo/2016/04/%E5%B7%A8%E5%A4%A7%E3%81%AA%E3%82%B5%E3%82%A4%E3%82%BA%E3%81%AE%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8Balter-table%E5%AE%9F%E8%A1%8C%E6%99%82%E9%96%93%E3%81%AE%E6%A6%82%E7%AE%97%E6%96%B9%E6%B3%95/ モチベーション ALTER TABLE実行にかかる時間を見積もれるようになりたい。 背景 巨大なテーブルに対してALTER TABLEを実行する機会があった。何も考えずに実行してしまった結果、これがいつまでも経っても終わらない。経験豊かなエンジニアはまず、なぜ何も考えずにALTER TABLEをしたのかと疑問に思うだろうが自分は気にも留めていなかった。クエリ実行から丸２日経過して流石に不安になり実行時間を見積もってみると一週間以上かかることがわかった。同じ過ちを起こさない自戒の意味を込めて、この記事では以下について記録しておく。 ALTER TABLEの挙動 ALTER TABLE実行後に実行時間を概算方法する方法 ALTER TABLE実行前に実行時間を概算方法する方法 ALTER TABLEの挙動 MySQL、特にストレージエンジンにMyISAMやInnoDBを利用している時のALTER TABLEの挙動は以下の通りである。(漢(オトコ)のコンピュータ道: ALTER TABLEを上手に使いこなそうより引用) テーブルをTL_WRITE_ALLOW_READロックする。このロックは特殊なロックで、テーブルロックの一種であるが、他のセッションからのREADを許可し、WRITEをブロックする。 新しいテーブル定義を使って空のテンポラリテーブルを作成する。 古いテーブルから新しいテーブルへデータをコピーする。 テーブルの名前を付け替えて、新しいテーブルを古いテーブルと同じ名前にする。古いテーブルは破棄する。 新しいテーブルへブロックしていたWRITEをリダイレクトする。 上述の通り、ALTER TABLEの挙動は上書きではなく、新しいテーブル定義で一時テーブルを作り、そこにデータを挿入していく。また、セッションを抜けるタイミングで自動的にDROPされる。この一時テーブルだが、tmp_table_sizeの値と比較して小さい場合はMEMORYテーブルとしてメモリ上に、大きい場合はディスク上に生成される。したがって、巨大なテーブルに対してALTER TABLE実行する場合対象のテーブルのサイズ分以上の空き容量がディスクに必要になるのを忘れてはならない。50GBのテーブルを対象としているときは50GB以上の空き領域が必要。ディスク上に一時テーブルの格納場所だが、ほとんどの場合、元のテーブルと同じディレクトリにsql_XXXXというファイル名で生成する。ただし、ALTER TABLE でインプレース手法 (オンライン DDL) が使用された場合、InnoDB は一時ファイルを一時ファイルディレクトリ(–tmpdirや環境変数TMPDIRで指定)に生成する。 一方でパフォーマンスを稼ぐためにメモリ上に一時テーブルを作りたい場合は、MEMORYストレージエンジンのテーブル最大サイズを定義するmax_heap_table_sizeも合わせて増やす必要がある。 ALTER TABLEを実行すると一時テーブルを生成すると述べたが場合によってはその限りではない。例えば、ADD PARTITION、DROP PARTITION、COALESCE PARTITION、REBUILD PARTITION、REORGANIZE PARTITION を含む ALTER TABLE は一時テーブルを生成しない(old_alter_table システム変数を ON に設定するかalter_specification 句の 1 つとして ALGORITHM=COPYを明示的に指定することで一時テーブルを生成することもできる) ALTER TABLE実行時間の概算方法 Data set MySQLが公式に公開しているテスト用DBを利用する。 GitHub - datacharmer/test_db: A sample MySQL database with an integrated test suite, used to test your applications and database servers mysql use employees; mysql show tables; +----------------------+ | Tables_in_employees | +----------------------+ | current_dept_emp | | departments | | dept_emp | | dept_emp_latest_date | | dept_manager | | employees | | salaries | | titles | +----------------------+ 8 rows in set (0. https://blog.takanabe.tokyo/2016/04/master/slave%E9%96%A2%E4%BF%82%E3%81%AB%E3%81%82%E3%82%8Bmysql%E3%82%B5%E3%83%BC%E3%83%90%E3%81%A7master%E3%81%AB%E7%84%A1%E3%81%84%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%82%92slave%E3%81%AB%E4%BD%9C%E6%88%90%E3%81%97%E3%81%9F%E6%99%82%E3%81%AE%E6%8C%99%E5%8B%95/ Tue, 05 Apr 2016 15:13:43 +0000 https://blog.takanabe.tokyo/2016/04/master/slave%E9%96%A2%E4%BF%82%E3%81%AB%E3%81%82%E3%82%8Bmysql%E3%82%B5%E3%83%BC%E3%83%90%E3%81%A7master%E3%81%AB%E7%84%A1%E3%81%84%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB%E3%82%92slave%E3%81%AB%E4%BD%9C%E6%88%90%E3%81%97%E3%81%9F%E6%99%82%E3%81%AE%E6%8C%99%E5%8B%95/ モチベーション Masterに存在しないテーブルをSlaveで作成した時の挙動とさらに同じテーブルをMasterで作成した時の挙動を検証ベースで確認したい。 Masterに存在しないテーブルをSlaveで作成する レプリケーションの基本的な考え方として、Slave側から更新をしてはならないというものがある。実際には、レプリケーションが止まるだけなのでDBとしては利用できるのだが、再びレプリケーションを開始するには色々とDBの状態を同期する必要がある。一方で、Masterに存在しないテーブルをSlaveで作成しても実はレプリケーションは止まらないことを知った。実際に確認してみる。 @ Master mysql show master status; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000003 | 107 | | | +------------------+----------+--------------+------------------+ mysql use repl_test; mysql show tables; Empty set (0.00 sec) @ Slave mysql show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.33.10 Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000003 Read_Master_Log_Pos: 107 Relay_Log_File: mysqld-relay-bin. https://blog.takanabe.tokyo/2016/04/%E6%96%99%E7%90%86%E3%82%92%E5%A7%8B%E3%82%81%E3%81%A6%E3%81%8B%E3%82%89%E4%B8%80%E6%9C%88%E3%81%9F%E3%81%A3%E3%81%9F/ Fri, 01 Apr 2016 12:29:29 +0000 https://blog.takanabe.tokyo/2016/04/%E6%96%99%E7%90%86%E3%82%92%E5%A7%8B%E3%82%81%E3%81%A6%E3%81%8B%E3%82%89%E4%B8%80%E6%9C%88%E3%81%9F%E3%81%A3%E3%81%9F/ 2月くらいから料理をだいたい毎日作るようになった。 上手いかどうかは置いといて、最初の頃よりは手際も良くなってきて短時間でつくれるようになってきた。仕事をしながらだとやっぱり仕事に必要な自己研鑚とコーディングに時間を割きたくなってしまうのでもっともっと効率化を勧めて行きたい。半年後くらいには20分以内に作れるようになりたい。 そうそう、先日いろんな動画をみて調理方法を勉強したたんだけど、リクルートの料理サプリなるアプリの調理の基本の動画は僕みたいな食材の切り方を観たい！って人にはおすすめ。 ただ、慣れてきて調子に乗ると失敗するので注意しよう。一昨日はそのせいで塩と砂糖を間違えるというまさかそんなフィクションみたいなこと誰もやらんだろという失態を体験することになった。 とても食えたものじゃなくて申し訳ないけど、廃棄となってその日はひもじい思いをした。反省。 気候も暖かくなってきたし、食材も変わってくる季節なのでこれからも楽しみだ。 ##　3月のアウトプット * クックパッドのつくれぽ20件 * 平均調理時間47分 https://blog.takanabe.tokyo/2016/03/%E7%9F%AD%E5%86%8A%E5%88%87%E3%82%8A%E3%81%AE%E5%8B%95%E7%94%BB%E3%81%A8%E8%A9%A6%E3%81%9B%E3%82%8B%E3%83%A1%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F/ Sat, 19 Mar 2016 00:37:41 +0000 https://blog.takanabe.tokyo/2016/03/%E7%9F%AD%E5%86%8A%E5%88%87%E3%82%8A%E3%81%AE%E5%8B%95%E7%94%BB%E3%81%A8%E8%A9%A6%E3%81%9B%E3%82%8B%E3%83%A1%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%92%E3%81%BE%E3%81%A8%E3%82%81%E3%81%9F/ 一月も毎日料理をすれば食材を切るのにはだいぶ慣れてくる。ただ、その切り方は中学、高校の家庭科で習った知識で適当に切っているので、まあ不格好である。いつまでも適当に切っていても上達する見込みが無いので基本的なパターンは覚えていこうと思う。 この前買った本の後ろの付録の小冊子にこういう食材の切り方とか器具の選び方とか、出汁の引き方とか書かれていてすごく勉強になる。多分にもれず短冊切りの方法も図付きで書かれている。 世界でいちばんやさしい料理教室 料理力がぐんぐんつく本 Author: N/A Manufacturer: ベターホーム協会 Publish date: 2008-12-01 ただ、絵や文字だけだと動きのイメージが脳に焼き付かないので素材の切り方は、いろんな動画をまとめて見れるようにすることにした。また、短冊切りを試せるメニューも載せておく。 短冊切り 画像と文章で理解したいときは短冊切り　野菜の切り方　料理の基本 | ホームクッキング【キッコーマン】を確認する。 野菜のしあわせ｜にんじんの短冊切り [短冊切り　【料理の基本：切り方】 ヤマサムービーギャラリー 短冊切りを試せるメニュー 簡単激ウマ！鶏肉としめじの炊き込みご飯 by ナウちゃん 油揚げの短冊斬り。人参は千切りじゃなくて短冊切りにすればいい。 大根と人参のさっぱり炒め～♪♪ by えりじ９７ 翌日も美味♪麺つゆで簡単素朴なけんちん汁 by スタイリッシュママ 中華丼♪ by ちーすけ♡ いろんな動画見て、まとめているうちに覚えた。 https://blog.takanabe.tokyo/2016/03/%E3%82%82%E3%82%81%E3%82%93%E8%B1%86%E8%85%90%E3%81%A8%E7%B5%B9%E3%81%94%E3%81%97%E8%B1%86%E8%85%90%E3%81%AE%E9%81%95%E3%81%84%E3%81%8C%E5%88%86%E3%81%8B%E3%81%A3%E3%81%9F/ Fri, 18 Mar 2016 14:47:59 +0000 https://blog.takanabe.tokyo/2016/03/%E3%82%82%E3%82%81%E3%82%93%E8%B1%86%E8%85%90%E3%81%A8%E7%B5%B9%E3%81%94%E3%81%97%E8%B1%86%E8%85%90%E3%81%AE%E9%81%95%E3%81%84%E3%81%8C%E5%88%86%E3%81%8B%E3%81%A3%E3%81%9F/ ひとり暮らしをし始めてからタンパク質をとるのに豆腐を食べることが増えた。できるだけ時間を意識して食事を作るようにしているので、そう何品も作れないからだ。 それで、豆腐コーナーによく寄るんだけど、そこに立ちふさがるのは絹ごし豆腐ともめん豆腐違い。何が違うんだ？と思いながら適当に安い方を手にとって買ってしまうのだが、今日料理の本を読んでいてわかった。(以下引用) 絹ごし豆腐というのは温めた豆乳ににがりを入れ、型に入れてそのまま固めたもので、もめん豆腐は温めた豆乳ににがりを入れてゆるく固まったものを布に敷いた穴あきの型箱にいれ、重しを掛けて水分を抜いたもの。 なるほどねー。絹ごしの方は豆乳がもめんより濃いのと、口当たりがなめらかなのが特徴らしい。冷奴とか湯豆腐そのまま豆腐を食べる時は絹ごし豆腐の方が良いんだね。一方で、もめん豆腐は炒めものとかに向いてるみたい。 参考 木綿豆腐と絹豆腐の違い 世界でいちばんやさしい料理教室 料理力がぐんぐんつく本 Author: N/A Manufacturer: ベターホーム協会 Publish date: 2008-12-01 https://blog.takanabe.tokyo/2016/03/%E6%96%99%E7%90%86%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/ Tue, 08 Mar 2016 11:10:09 +0000 https://blog.takanabe.tokyo/2016/03/%E6%96%99%E7%90%86%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/ 転職を機に最近料理をするようになった。 思えば小さい頃はシェフになるとか言って、料理番組ばかり見ていたし。大学に入っても居酒屋やレストランでバイトをしていたので食に関する思いは人一倍強い。とはいえ包丁さばきも、調理も素人同然なので少しずつできることを増やしていきたい とりあえず、基本を学ぶためにこの本を買ってみた。 世界でいちばんやさしい料理教室 料理力がぐんぐんつく本 Author: N/A Manufacturer: ベターホーム協会 Publish date: 2008-12-01 上手くなりたいなー https://blog.takanabe.tokyo/2015/12/docker%E5%85%A5%E9%96%80%E3%81%8B%E3%82%89%E3%81%97%E3%81%A6%E3%81%8D%E3%81%9F%E3%81%93%E3%81%A8%E3%82%92%E6%A3%9A%E5%8D%B8%E3%81%97%E3%81%99%E3%82%8B/ Thu, 24 Dec 2015 15:56:33 +0000 https://blog.takanabe.tokyo/2015/12/docker%E5%85%A5%E9%96%80%E3%81%8B%E3%82%89%E3%81%97%E3%81%A6%E3%81%8D%E3%81%9F%E3%81%93%E3%81%A8%E3%82%92%E6%A3%9A%E5%8D%B8%E3%81%97%E3%81%99%E3%82%8B/ この記事はQiita Docker Advent Calendar 2015の25日目に投稿させて頂いた記事です。 DockerをVirtualBoxのVM代わりに利用することはこれまでもあったが、本番環境で大規模なシステムを組むことを想定して本腰をいれて学び始めたのはつい最近。 数十のサーバからなるシステムをコンテナ化するのを目標に、僕が実際に手を動かして実施したこと、あるいは参考にさせて頂いた記事を忘れないようにまとめさせて頂きました。 基本的にはDocker1.9時にリリースされている機能を対象にしており、リンクのタイトルにPAYFORWARDと付いているものは僕が実施した内容がまとまっている記事だ。また、参考リンクを載せている場合は現段階で一番良いと思っているものが載せてあり、より良いものを発見したら随時変更するつもりである。 ① 基礎知識編 1. ネットワークの基礎を学ぶ 手元でコンテナ動かして適当にVMの代わりに使う程度なら必要無いかもしれないけど、コンテナで大規模なネットワークを構築する場合はネットワークの基礎知識必要。TCP/IPとかOSI参照モデルとか基本的なことを勉強するのに参考になればと。そんなもん必要ないという人は飛ばしてください。 Dockerのネットワークを理解するためのネットワーク技術入門 | PAYFORWARD 2. Dockerで使われる技術を学ぶ LXCとかDockerとかコンテナ技術で使われているのはLinxuカーネルが標準で提供している機能が多い。特に、CgroupsやNamespaceといった技術はコンテナ技術を語る上で欠くことが出来ない。この辺はOpenStackのNeutronとか他の仮想化技術でも使われていたりする。基本となる技術はきちんと抑えて深掘りして行きたい。 Dockerを支える技術 @SlideShare by 中井悦司さん 今さら聞けない Linux コンテナの基礎 (2015-06-20) @Speaker Deck by 加藤泰文さん Linux Namespaces @SlideShare by Masami Ichikawaさん 加藤さんの今さら聞けない Linux コンテナの基礎は動画も公開されている。 今さら聞けない Linux コンテナの基礎 (1) - YouTube 3. Dockerの全体像を把握する 何をするにしてもそうだが、全体像を把握してから細かい知識をつけたり、実際にツールを触ってみるのが僕の性に合っている。全体像を理解する上ではzembutsuさんの資料が良かった。Dockerを使う目的が必ずしもスライド通りであるとは限らないが、こんな感じの技術なんだなという概要を掴む上でとても助かりました。 Docker Swarm入門 @SlideShare by zembutsuさん Docker入門-基礎編 いまから始めるDocker管理【2nd Edition】@SlideShare by zembutsuさん 1つ目はSwarm入門になってるけど、他のDockerツールについてもわかりやすくまとまっている。 4. 書籍 ここまでは無料のサイトやスライドの紹介を中心に行ったが本の方が良いという人はこの辺が個人的にお勧め。 https://blog.takanabe.tokyo/2015/12/docker%E3%81%AElogging-driver%E3%81%A7fluentd%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%83%AD%E3%82%B0%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ Thu, 24 Dec 2015 08:15:26 +0000 https://blog.takanabe.tokyo/2015/12/docker%E3%81%AElogging-driver%E3%81%A7fluentd%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%83%AD%E3%82%B0%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ Dockerコンテナで発生したログを確認するのにdocker logsが使われる。しかし、従来のログのようにSyslogやfluentdで管理したい時が有る。これを実現するにはDocker1.6から追加されているLogging Driverを使えばいい。Driverにはいくつか種類があるが、Syslog Driverを利用すればDockerホストのSyslogにコンテナのログを出力することが出来るし、fluentd Driverを使えばfluentdでログを集約できる。 この記事では、Logging Driverでログを管理することを目的として、最近Logging Driverの1つとして追加されたfluentdを利用したコンテナ内のログ管理をしてみる。 検証環境 ➤ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: OS X 10.10.5 (14F1021) Kernel Version: Darwin 14.5.0 Boot Volume: Macintosh HD Boot Mode: Normal ➤ vagrant -v Vagrant 1.7.4 ➤ docker-machine -v docker-machine version 0.5.4, build 6643d0e 検証構成 準備 Docker Machine + Vagrantで任意のLinuxディストリビューションでDockerホストを構築するを参考にしてDockerホストを用意する。 fluentd Logging Driverを使う ここからfluentd Logging Driverを使ったログの集約を行う。docker composeを使って構成で示した環境を構築するものとする。 Log collectorの設定ファイル準備 fluentdの公式イメージを利用する。fluentdのオリジナルDockerfileではDockerfileをビルドするときにflunet.confがあればそれをコンテナ内にコピーするようになっているので予め用意する。 ➤ mkdir fluentd ➤ mkdir -p fluentd/plugins ➤ touch fluentd/fluent. https://blog.takanabe.tokyo/2015/12/docker%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E3%81%BE%E3%81%A8%E3%82%81/ Wed, 23 Dec 2015 13:31:31 +0000 https://blog.takanabe.tokyo/2015/12/docker%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E3%81%BE%E3%81%A8%E3%82%81/ 国内外のDockerのユースケースを集めて今後の参考にする。随時更新予定。Dockerを含むアーキテクチャに触れずにこんな風に使ってますと、概念だけ説明している物は対象外としている。 大規模なプロダクション環境に使っているケースはわずかで開発環境とか分析システム開発とかミスっても大丈夫なところでノウハウを蓄積しているといった所だろうか。 国外 Docker Inc Use Cases | docker Netflix Cloud Native NetflixOSS Services on Docker by Andrew Spyker (IBM) and Sudhir Tonse (Netflix) - YouTube BBC News DOCKERCON EU: Enterprise CI Problems and our Solutions by Simon Thulbourn | Docker Blog Shopify Docker at Shopify: From This-Looks-Fun to Production by Simon Eskildsen - YouTube 国内 リクルート Dockerを活用したリクルートグループ開発基盤の構築 Cyber Agent Flexible Blue Green Deploymentのススメ｜サイバーエージェント 公式エンジニアブログ Next FRESH! https://blog.takanabe.tokyo/2015/12/docker-content-trust%E3%81%A7docker%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AB%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E7%BD%B2%E5%90%8D%E3%82%92%E3%81%99%E3%82%8B/ Wed, 23 Dec 2015 13:17:49 +0000 https://blog.takanabe.tokyo/2015/12/docker-content-trust%E3%81%A7docker%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AB%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E7%BD%B2%E5%90%8D%E3%82%92%E3%81%99%E3%82%8B/ Docker Bench for SecurityでDockerコンテナのセキュリティ診断を行うでは運用しているコンテナのセキュリティをDocker社の提供するベンチマークツールで診断した。起動しているコンテナに関するセキュリティはこのようなベンチマークツールで診断することは可能だが、そもそもコンテナの元となるイメージは信頼できるものなのだろうか。そんな不安を覚えたエンジニアは少なくないと思う。この記事ではDocker 1.8から追加されているDockerイメージへのデジタル署名の仕組みDocker Content Trustを使い、イメージの信頼性の検証を行う。 【注】実際には最後のイメージの真正性の確認で想定した挙動とことなる挙動が起きている。現在問い合わせ中。備忘録として残しておく。 Docker Content Trustとは Docker Content Trustはデジタル署名技術を利用したDocker イメージ発行者の真正性の検証とDocker イメージ自体の信頼性の検証を行う機能である。 MITM Attack、リプレイAttack、鍵の漏洩対策が施されており、信頼されないイメージに対して、docker pull、docker push、 docker build、 docker create、 docker runコマンドが使えなくなる。 詳細な仕組みを理解したい場合はIntroducing Docker Content Trust | Docker BlogとContent trust in Docker を読んで頂きたい。 Notaryとは Docker Content Trustを支えているツールにNotaryがある。Notaryは安全なイメージの公開と、イメージ内容を検証するためのDocker社のツールでOSSで公開されている。Notaryはイメージの信頼性の検証にはTUFが使っているとのこと。 実際に使ってみる 今回ははじめから構築するのではなく、Content Trustの検証をするためにDocker社が用意しているデモ用のコンテナを使う。 検証環境 ➤ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: OS X 10.10.5 (14F27) Kernel Version: Darwin 14.5.0 ➤ docker-machine -v docker-machine version 0.5.1 (7e8e38e) (Dockerホスト) * Docker version 1. https://blog.takanabe.tokyo/2015/12/docker-swarm-compose-%E3%81%A7%E3%83%9E%E3%83%AB%E3%83%81%E3%83%9B%E3%82%B9%E3%83%88%E7%92%B0%E5%A2%83%E3%81%A7overlay-network%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Sun, 20 Dec 2015 23:35:21 +0000 https://blog.takanabe.tokyo/2015/12/docker-swarm-compose-%E3%81%A7%E3%83%9E%E3%83%AB%E3%83%81%E3%83%9B%E3%82%B9%E3%83%88%E7%92%B0%E5%A2%83%E3%81%A7overlay-network%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ モチベーション Docker Composeで複数コンテナを管理するでは、複数コンテナからなるシステムをDocker Composeで一括管理可能にした。また、Docker Swarmで複数Dockerホストからクラスタを作るでは、複数のDockerホストからなるコンテナクラスタをDocker Swarmによって実現した。しかし、記事のようにディスカバリサービスとしてDockerHubを利用するのは本番環境では考えられない。また、コンテナ間通信では非推奨のlinkを用いていた。本記事では、これらをより本番での運用に近づけるために、ディスカバリサービスにConsulを、コンテナ間通信にoverlay networkを用いてマルチホストコンテナクラスタを構築する。 クラスタ全体構成 コンテナクラスタの構築手順 Consulを使ったDocker Swarmクラスタの構築手順をさらっとおさらいする。Consulを起動するDockerホストにて以下を実行する。 ➤ docker run --name consul -d \ -p "8500:8500" \ -h "consul" \ --restart=always \ progrium/consul -server -bootstrap Swarmクラスタを構築する。まずは、Swarm Masterから。 ➤ docker-machine create -d virtualbox \ --swarm --swarm-master \ --swarm-discovery="consul://$(docker-machine ip consul):8500" \ --engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \ --engine-opt="cluster-advertise=eth1:2376" swarm-master つづいて、Swarm Nodeを構築する。 ➤ docker-machine create -d virtualbox \ --swarm --swarm-discovery="consul://$(docker-machine ip consul):8500" \ --engine-opt="cluster-store=consul://$(docker-machine ip consul):8500" \ --engine-opt=" https://blog.takanabe.tokyo/2015/12/docker-universal-control-plane%E3%81%A7docker%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92gui%E3%81%A7%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ Sat, 19 Dec 2015 05:47:32 +0000 https://blog.takanabe.tokyo/2015/12/docker-universal-control-plane%E3%81%A7docker%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92gui%E3%81%A7%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ Docker Universal Control Planeとは？ Docker Universal Control PlaneはDocker社のエコシステムのGUIによる管理を実現させるDocker社純正のツールである。昨年まではプロジェクトネームOrcaの名で開発が進められてきたが、DockerCon EU2015でDocker Universal Control Planeに(以下UCP)統合される旨が告げられた。 UCPの哲学は開発チームと運用チームがコンテナベースのアプリケーションの開発、デプロイ、運用を本番環境で可能にさせることである。Dockcer Swarmによるコンテナのクラスタリングとオーケストレーションを始めとして、Docker Engine, libnetwork, volume, netowrk plugin, Registry, Composeが既にUCPから操作できる。また、コンテナのScale upもボタンを1つで実施できる。これまで開発されてきたDockerエコシステムをUCPから簡単に操作可能になったのだ。 2015年12月11日現在UCPはBetaリリースされている[1]。 なぜUCPを使うのか？ DockerのAPIを叩いてコンテナの管理をするGUIはこれまでにも幾つかある。その中でも、UCPを使って良いなーと思ったのは以下の点。 説明不要な直感的なUIを持っている Dockerエコシステムのための統合GUIなのでDockerシステムと相性が良い プロダクション環境での利用を意識した設計 Dockerのエコシステムと相性が良いのは言わずもがなかな。Docker社内で開発の連携が出来る分ツール間の親和性や新ツール追従の開発スピードは他を圧倒するだろう。 UIも秀逸だ。VMWare,CloudStack,OpenStackと様々な仮想化環境のラッパーとなるソフトウェアとそのGUIを触ってきたが、その中でも一番シンプルでわかりやすい。 また、HA構成による可用性やLDAPやActiveDirectoryとの連携によるアカウント管理、オンプレミスでのデプロイが可能なことなど本番環境での運用に対する配慮が初期から垣間見られる。開発も運用も大事にしたいという意識が感じられて本当に素晴らしい。 UCPを使ってみる 実際にUCPを使ってどんなことが出来るか確認する。UCPにアクセスするとログイン画面が出る。 ログインするとUCPがコントロールしているシステム全体のサマリーが表示される。 メニューを開くとDashboard、Applications、Nodes、Network、Images、Account、Settingの項がある。 Applications以降の項について何が出来るか確認する。 Containers(Engine,volume,network)を使ってみる Containersではコンテナの状態確認や操作(デプロイ、起動、停止、スケールアップ)ができる。 試しに１つredisのコンテナを立ててみる。 コンテナ名やコンテナ作成に使うImageを指定したが、他にもContainer config, Environment, Network, Volumes, Constraintsが設定でき、Dockerコマンド経由で出来ることは大体出来る印象。 Docker Registryにredisのイメージが無いので初回はDocker HubからImageの取得が行われる。Imageの取得が終わると数秒でredisコンテナが起動する。 起動後はコンテナの詳細確認出来たり、 コンテナのログをみたり、コンソールでコンテナの操作をしたりできる。redisのコンテナなのでいつものredisのログが確認できる。 また、Scaleボタンをクリックするとコンテナのスケールアップが実行される。但し、スケールアップしたコンテナの名前はランダムで決定されてしまう。 Images(Registry)を使ってみる Imagesでは管理しているImage一覧が表示される。先ほどDocker Hubから取得したredisのImageも登録されている。 Nodes(Swarm)を使ってみる Nodesを開くとクラスタを形成しているノード確認できる。今回は単一ノードで検証をしているので複数ノードでクラスタを形成した時の動作は後日追記する。 Network(libnetwork)を使ってみる NetworkではDockerが管理しているネットワーク情報が確認できる。 https://blog.takanabe.tokyo/2015/12/redux-router%E3%81%A7%E3%83%9A%E3%83%BC%E3%82%B8%E9%81%B7%E7%A7%BB%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B/ Fri, 18 Dec 2015 08:19:13 +0000 https://blog.takanabe.tokyo/2015/12/redux-router%E3%81%A7%E3%83%9A%E3%83%BC%E3%82%B8%E9%81%B7%E7%A7%BB%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%99%E3%82%8B/ この記事はQiita React.js Advent Calendar 2015の18日目に投稿させて頂いた記事です。 モチベーション reduxのページ切り替えにreact routerを導入したい 成果物 redux-routing-example/containers at master · takanabe/redux-routing-example · GitHubにredux-routerを使ったサンプルプロジェクトを置いておく。 redux-routerとは redxu-routerはreact-routerのAPIをReduxから利用出来るようにするもの。 Reduxではステートを1つのStoreで管理する規則があるが、redux-routerを使うことで、RouterもStoreで管理できるようになる。 ルーティングの例 ルーティングの設定はreact-routerと同じ。例えば、以下のようなルーティングの設定がされているとする。 <Route path="/" component={Parent} > <IndexRoute component={ChildA} /> <Route path="child_a" component={ChildA} /> <Route path="/child_b/:id" component={ChildB} > <Route path="gchild_a" component={GrandChildA} /> <Route path="gchild_b" component={GrandChildB} /> </Route> <Route path="*" component={NotFound} /> </Route> この時、アクセスするパスでRouterはレンダリングするComponentを決定する。 ”/“にアクセスした場合 Parent Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathにマッチするものがないのでIndex Routeに設定されているChildA Componentをレンダリング対象にする ChildA Componentに子階層がないためルーティングを終了する ”/child_aにアクセスした場合 Parent Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathがChildAのpathとマッチしているのでChildA Componentをレンダリング対象にする ChildA Componentに子階層がないためルーティングを終了する ”/child_a/xxxx”にアクセスした場合 Parent Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathが*にマッチするのでNotFound Componentをレンダリング対象にする NotFound Componentに子階層がないためルーティングを終了する ”/child_b/xxxx”にアクセスした場合 Parent Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathがChildBのpathとマッチしているのでChildB Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathにマッチするものがなく、Default Routeに設定されているGrandChildAをレンダリング対象にする ”/child_b/xxxx/gchild_b”にアクセスした場合 Parent Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathがChild-BのpathとマッチしているのでChild-B Componentをレンダリング対象にする 子階層を見に行き、pathにマッチしているComponentを探す pathにマッチしているのでGrandChild-Bをレンダリング対象にする ルーティングを利用してComponentを入れ子にする Componentを入れ子にしてパスによってレンダリングする子Componentを定義することっもできる。 https://blog.takanabe.tokyo/2015/12/docker%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80/ Sun, 13 Dec 2015 09:12:52 +0000 https://blog.takanabe.tokyo/2015/12/docker%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80/ はじめに DockerのネットワークにはVXLANなどの最新技術を始めとして様々なネットワーク技術が使われているが、これらはアプリケーションエンジニアのように低レイヤーの技術まで扱わない人には見たことの無い単語や概念ばかりで辛いことが想像できる。僕はこのあたりの知識はIaaSを構築していたり、小規模ISPの構築、運用に携わっていたので自然に身につけられたが、一般的には必要としていない人の方が多いのではないだろうか。 本記事では、ネットワーク技術に明るくない人を対象に体系的なネットワーク技術[1]を習得するための書籍や記事を紹介する。 Docker特有のネットワークについて この記事はDockerのネットワークに特化したものではない。それらを学びたい場合は中井悦司さんのDockerを支える技術が詳しいのでそちらを参照していただきたい。 ネットワークの仕組みを理解する ① ネットワークはなぜつながるのか 技術本ではないがネットワーク技術を学ぶ取っ掛かりになる本。読み終わる頃にはネットワークの仕組みの全体像がわかるようになる。いきなりTCPとかUDPとかネットワークプロトコルの話とかされてもわからないという人向け。 ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識 Author: 戸根 勤 Manufacturer: 日経BP Publish date: 2007-04-12 L2/L3/L4の基本を理解する Dockerのネットワーク構築で必要は主な知識はOSI参照モデルでいうところのLayer2からLayer4の技術である(L2、L4と略すことが多い)。ここで紹介している書籍や記事で出て来る単語は抑えておいた方がいい。 ② 3 Minutes Networking 技術書というよりは、読み本だが平易にL1からL7まで説明している。この本は元々Webサイトが書籍化されたもので、そちらは無料で閲覧可能。Webでの閲覧が好きな人は、3 Minutes Networkingを読めば良い。 [改訂新版] 3分間ネットワーク基礎講座 Author: 網野 衛二 Manufacturer: 技術評論社 Publish date: 2010-09-11 ③ マスタリングTCP/IP 入門編 OSI参照モデルで言うところのL3/L4の技術について極めてわかりやすく説明している。Dockerでもlibnetworkを使って自分でL3ネットワークを構築できるが、TCP/IPの知識が無いと自在に操ることが出来ない。TCP/IPについてこれよりわかりやすい日本語書籍は見たことがない。 マスタリングTCP/IP 入門編 第5版 Author: 竹下 隆史 Manufacturer: オーム社 Publish date: 2012-02-25 ④ ネットワークエンジニアとして(初級) “ネットワークエンジニアとして”という僕がネットワークを勉強しはじめた時に良く参考にしていたサイトがある。こちらも無料で閲覧出来る上に、とても解りやすくまとまっている。ここの初級辺を一通り読むと一層理解が深まるだろう。 https://blog.takanabe.tokyo/2015/12/material-ui%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%82%AB%E3%83%83%E3%82%B3%E3%81%84%E3%81%84ui%E3%81%AEreact%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ Fri, 11 Dec 2015 03:30:36 +0000 https://blog.takanabe.tokyo/2015/12/material-ui%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%82%AB%E3%83%83%E3%82%B3%E3%81%84%E3%81%84ui%E3%81%AEreact%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ この記事はQiita React.js Advent Calendar 2015の11日目に投稿させて頂いた記事です。 背景 Material UIというプロジェクトをご存知だろうか？これはGoogle Material Designが提供しているUIパーツをReactのコンポーネントとして配布するプロジェクトである。自分はフロントエンドエンジニアじゃないし、デザインに時間かけたくないからとりあえずBootstrapでも適用しておくかみたいなケースは結構あると思う。僕もRailsで書いたAPIサーバの管理画面を開発した時、最初はBootstrapを使おうと思っていた。でも、Bootstrapのデザインも飽きてきたし他に気軽に使えるものはないかな、と探していた時に見つけたのがMaterial UI。Reactも書けるようになってきたので使ってみることにした。 成果物 React + Redux + Material UIのboilerplateを作った。理由は2015年9月頃はReactとReduxとMaterial UIのバージョンの制限が厳しく少しバージョンが変わるだけで利用できなかったり、Webpack, ESLint、Redux Routerなどの設定を毎回するのが面倒だったから。このboilerplateでちょっとしたアプリを作る時は以下に置きますので使って下さい。 takanabe/react-redux-material_ui-boilerplate Material UIで遊ぶ Materia UIのウェブページにアクセスして、COMPONENTSにアクセスすると利用可能なMeterial Designなコンポーネントが表示される。コンポーネントの挙動を確認するために実際に手元でコードをいじっても良いが、以下のようにサイト内でインタラクティブに各コンポーネントの動作を確認できるので、まずは遊んで見ることをお薦めする。 Material UIを使ってみる 実際にプロジェクトの開始からステップバイステップでReactアプリにMaterial UIを組み込み以下のような構成のReactアプリを作ってみる。[1] <App <Header / <MainSection/ </App また、最終的なフォルダ構成はこうなる。 . ├── .eslintrc ├── components │ ├── Header.jsx │ └── MainSection.jsx ├── containers │ └── App.jsx ├── package.json ├── src │ ├── index.html │ ├── index.jsx │ ├── main. https://blog.takanabe.tokyo/2015/12/redux%E3%81%A8%E3%81%AF/ Thu, 03 Dec 2015 13:26:19 +0000 https://blog.takanabe.tokyo/2015/12/redux%E3%81%A8%E3%81%AF/ この記事はQiita React.js Advent Calendar 2015の4日目に投稿させて頂いた記事です。 この記事でわかること Reduxの基本的概念とRedux関連の用語 背景 Reactで良く使われるアーキテクチャスタイルにFluxというものがある。これはFacebookが考案したアーキテクチャスタイルで、MVCの亜種にオブザーバパターンを乗せてデータの一方向性のルールを適用させたものだ。このFluxから派生したアーキテクチャスタイルであるReduxが海外で評判が良く、自分でも使って見たくなったので色々調べてみた。 前提 Reactの基本的なことは理解している。 入門 React ―コンポーネントベースのWebフロントエンド開発 Author: Frankie Bagnardi Manufacturer: オライリージャパン Publish date: 2015-04-03 Reduxとは? ReduxはFluxを派生させたアーキテクチャスタイルであり、このアーキテクチャに則ったアプリケーションは①ステート[1]の管理が容易、②異なる開発環境(client,server, native)で一貫した振る舞いを持つアプリケーションの開発が可能、③テストが容易、④ステートの変更を遡れるデバッガーなど便利なツールを使った開発が可能、⑤Reactとの相性が良いなどの恩恵が得られる。 最近流行りのSPAなんかはアプリケーションのステート管理が複雑化しており、ステートをいかに簡単に管理できるかが課題になっている。ReduxはJavaScriptアプリケーションのステートの変更の手段とタイミングに制約を設けることでステートを予測可能にし、その管理を容易にする。 また、Reduxに則って開発するアプリケーションの関数群はステートレスなためテストが容易になる。Single Source of Truthの原則に従っているため、ステート変更のUndo、Redoが容易にでき、gaearon/redux-devtools · GitHubを使えばhot loadingやアプリケーションのステートの推移をコントロールできるため開発が非常に容易になる。次のビデオはHot Reloading with Time Travelというreact-europe 2015で発表されたでモンストーレションである。 Reactの課題である、ステートの管理を実現するアーキテクチャなのでReactをViewで使うアプリ開発者に特に注目を浴びている。 実装としてのRedux 先ほどReduxはアーキテクチャスタイルと述べたが、同じ名前のフレームワークも公開されている。このフレームワークを利用することで簡単にReduxアーキテクチャを自分のアプリケーションに取り込める。 rackt/redux · GitHub データフロー ReduxはFluxと同様、データの流れを一方向にする規約が有る。この規約はStoreのステートツリーを更新するときは必ずActionを経由する必要があるというものだ。Action経由でのStoreの更新は具体的には以下のような流れになる。 Action CreatorがViewやスケジューリングされている非同期のイベントなどをトリガーにActionを生成する(①) Middlewareがステート変更前後で任意の処理を実行する(②、③) Reducerが変更後のステートStoreに知らせる(④) Storeがステートを更新した後、Viewが変更を検知し自らを更新する(⑤) Actionは文字列定数の識別子(type)とStoreへの入力情報となるデータから構成されているJavaScriptオブジェクトのこと。 { type: ADD_TODO, text } Storeが管理するステートツリーはActionを経由しなければ更新することができない。また、Actionは何が実行されるのかという事実を扱う。ステートツリーをどのように変更するかを定義するのはReducerの担当になる。 https://blog.takanabe.tokyo/2015/12/kernel-3.19%E3%82%92%E6%90%AD%E8%BC%89%E3%81%97%E3%81%9Fubuntu-14.04%E3%81%AEvagrant-box%E3%82%92%E4%BD%9C%E3%82%8B/ Wed, 02 Dec 2015 15:52:12 +0000 https://blog.takanabe.tokyo/2015/12/kernel-3.19%E3%82%92%E6%90%AD%E8%BC%89%E3%81%97%E3%81%9Fubuntu-14.04%E3%81%AEvagrant-box%E3%82%92%E4%BD%9C%E3%82%8B/ Dockerでoverlay NWやoverlayfsがサポートされたがそれぞれKernel 3.16、3.18以上が必要になってくる。Ubuntu公式の14.04 TrustyのVagrant boxのKernelバージョンがこの条件を満たしておらず、毎回Kernelアップデートをするのが面倒だった。そこで、Dockerのoverlay NWやoverlayfsを試すためのVagrant Ubuntu14.04 boxを作ってみようと思う。 成果物 今回作成したVagrant boxはAtlasで公開した。利用するときは以下を実行する。 ➤ vagrant box add takanabe/ubuntu1404-docker 開発環境 ➤ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: OS X 10.10.5 (14F27) Kernel Version: Darwin 14.5.0 ➤ vagrant -v Vagrant 1.7.4 VagrantでUbuntu14.04のVMを作る いつもどおり手元にあるUbuntu14.04のboxを使ってVMを起動する。 ➤ vagrant box list ubuntu14.04 (virtualbox, 0) ➤ vagrant init ubuntu14.04 ➤ vagrant up Ubuntuのバージョンを確認する 起動したVMにログインして各種情報を確認する。 ➤ vagrant ssh $ uname -a Linux vagrant-ubuntu-trusty-64 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. https://blog.takanabe.tokyo/2015/11/docker-compose%E3%81%A7%E8%A4%87%E6%95%B0%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ Mon, 30 Nov 2015 12:56:33 +0000 https://blog.takanabe.tokyo/2015/11/docker-compose%E3%81%A7%E8%A4%87%E6%95%B0%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B/ DockerfileでDockerイメージの作成を自動化するでは、Dockerfileを使ってコンテナイメージを自動生成した。しかし、複数コンテナを操作する時は手動ないしはシェルスクリプト経由で依存関係を考慮してdokcerコマンドを実行する必要があった。今回はDocker Composeを利用して複数のコンテナの依存関係加味した一括操作を実現する。 システム構成 以下のようなシステムをコンテナを組み合わせて実現する。 検証環境 ➤ docker version Client: Version: 1.9.1 API version: 1.21 Go version: go1.4.3 Git commit: a34a1d5 Built: Fri Nov 20 17:56:04 UTC 2015 OS/Arch: darwin/amd64 Server: Version: 1.9.1 API version: 1.21 Go version: go1.4.2 Git commit: a34a1d5 Built: Fri Nov 20 13:12:04 UTC 2015 OS/Arch: linux/amd64 コンテナイメージを組み合わせて1つのシステムを構築する リバースプロキシ、Redmine、DB(PostGreSQL)のコンテナをdocker runで順番に起動してシステムを完成させる。 まずはリバースプロキシコンテナを起動する。このときリバースプロキシとなるNginxとredmineを--link redmine:redmineオプションをつける必要はない。代わりにRedmineコンテナ起動時にVIRTUAL_HOSTの設定をする。 docker run --name rproxy -d \ --publish 80:80 \ --volume /var/run/docker.sock:/tmp/docker.sock:ro \ jwilder/nginx-proxy:latest 続いて、DBコンテナを起動する。 https://blog.takanabe.tokyo/2015/11/dockerfile%E3%81%A7docker%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%9C%E6%88%90%E3%82%92%E8%87%AA%E5%8B%95%E5%8C%96%E3%81%99%E3%82%8B/ Sat, 28 Nov 2015 04:46:29 +0000 https://blog.takanabe.tokyo/2015/11/dockerfile%E3%81%A7docker%E3%82%A4%E3%83%A1%E3%83%BC%E3%82%B8%E3%81%AE%E4%BD%9C%E6%88%90%E3%82%92%E8%87%AA%E5%8B%95%E5%8C%96%E3%81%99%E3%82%8B/ Docker Machine + Vagrantで任意のLinuxディストリビューションでDockerホストを構築するでは、自分の好きなLinuxディストリビューションでVMを作り、docker-machineでDockerホスト化させた。今回はDockerホスト上で生成するコンテナの素とも言えるコンテナイメージをDockerfileから自動生成する。 Dockerfileとは DockerfileはDocker Imageの生成手順をまとめたものである。説明は色んなところにあるのでリンクを貼って割愛。 Dockerfileを書く時の注意とかコツとかハックとか | kim hirokuni Dockerイメージのレイヤー構造について - めもめも Dockerイメージの差分管理についてまとめてみた 検証環境 ➤ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: OS X 10.10.5 (14F27) Kernel Version: Darwin 14.5.0 ➤ docker-machine -v docker-machine version 0.5.1 (7e8e38e) (Dockerホスト) * Docker version 1.9.1 commitを重ねてJoke Boxのイメージを作成する 普通にDockerイメージを作る。今回は、slやcowsayなど著名なジョークコマンドが詰め込まれたコンテナイメージの作成を行う。以降、➤がMacのシェル、#がDockerホストのシェルを示す。 まずはubuntuのイメージを取得してコンテナを起動し、cowsayコマンドをインストールする。 ➤ CONTAINER_ID=$(docker run -it ubuntu:trusty /bin/bash) # apt-get update # apt-get install -y cowsay # /usr/games/cowsay "Dockerfile Demo" https://blog.takanabe.tokyo/2015/11/docker-machine-vagrant%E3%81%A7%E4%BB%BB%E6%84%8F%E3%81%AElinux%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7docker%E3%83%9B%E3%82%B9%E3%83%88%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Thu, 26 Nov 2015 11:36:56 +0000 https://blog.takanabe.tokyo/2015/11/docker-machine-vagrant%E3%81%A7%E4%BB%BB%E6%84%8F%E3%81%AElinux%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%A7docker%E3%83%9B%E3%82%B9%E3%83%88%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Docker Machineを使ってVirtualbox, AWS, ESXiにDockerホストを構築するでは、Docker Machineで使い慣れた環境上にDockerホストを構築した。しかし、VirtualBoxやESXiなどを使う場合、選択出来るLinuxディストリビューションが少ない(Boot2DockerとRancherOSくらい)という問題があった。本記事ではVagrantと組み合わせることで、任意のLinuxディストリビューションから生成したVMをdocker-machineで管理できるようにする。 Generic driverについて Docker Machine 0.3.0 Deep Dive | Docker Blogという記事を読んでいるとGeneric driverなるものがあり、sshでアクセスできるVMなら以下のようにオプションを変更するだけでDockerホストに出来るようだ。 $ docker-machine create -d generic \ --generic-ssh-user USER_NAME \ --generic-ssh-key /path_to/ssh_private_key \ --generic-ip-address VM_IP_ADDRESS \ DOCER_HOST_NAME これを使ってVirtualBox上にUbuntu14.04のDockerホストを構築する。 実行環境 ➤ system_profiler SPSoftwareDataType Software: System Software Overview: System Version: OS X 10.10.5 (14F27) Kernel Version: Darwin 14.5.0 ➤ docker-machine -v docker-machine version 0.5.1 (7e8e38e) ➤ vagrant -v Vagrant 1.7.4 ➤ vagrant plugin list vagrant-ohai (0. https://blog.takanabe.tokyo/2015/11/docker-swarm%E3%81%A7%E8%A4%87%E6%95%B0docker%E3%83%9B%E3%82%B9%E3%83%88%E3%81%8B%E3%82%89%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%82%92%E4%BD%9C%E3%82%8B/ Mon, 23 Nov 2015 06:59:34 +0000 https://blog.takanabe.tokyo/2015/11/docker-swarm%E3%81%A7%E8%A4%87%E6%95%B0docker%E3%83%9B%E3%82%B9%E3%83%88%E3%81%8B%E3%82%89%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%82%92%E4%BD%9C%E3%82%8B/ Docker Machineを使ってVirtualbox, AWS, ESXiにDockerホストを構築するでは、Docker machineによりVirtualBox上にDockerホストを構築した。Dockerホストを複数起動しているとそれらを1つのリソースプールとして扱いたいケースが当然出て来る。そこで、今回はDocker Swarmを使ってVirtualBox上にDocker Machineで構築した複数のDockerホストからクラスタを作ってみる。 Docker Swarmとは Docker Swarmとは、複数のDockerホストを1つのリソースプールとして束ねて、どのコンテナをどのホスト上で起動するかスケジューリング(配置決定)するツールである。Docker Swarmを使う場合、Dockerホストはクラスターを管理するSwarm Managerとクラスターを形成するSwarmノードにいずれかに属し、クラスタへの命令はSwarm Manager経由で行われる。 この辺を解りやすく説明されているスライドがあるので、詳しくはこちらを見て頂きたい。 [slideshare id=53220740&doc=introductiontodockerswarmdistribution-150926102344-lva1-app6892] 使用感をとりあえずみたいという人は動画もある。 Docker Online Meetup #28: Production-Ready Docker Swarm 準備 前準備として、Docker Toolboxをインストールしておく。まだインストールしていない場合は、Docker ToolboxでMac OSXにDocker環境を最速で構築するを参考にインストールする。 Docker Swarmによるクラスタ形成 Discovery backend Docker SwarmではSwarmノード(束ねられるDockerホスト)をDocker Swarm discovery で管理する。つまり、Swarm Managerはノードの情報を持っていない。Discovery backendはetcd、consul、Zookeeperなどを利用して自前で用意することも可能だが、ここではDocker HubがホスティングしているTokenベースのDiscovery backendを利用することとする。 Cluster-idの発行 Docker HubがホスティングしているDiscovery backendを利用するにはcluster-idの発行が必要である。このcluster-idはswarm createを実行すると生成される。ここでは、以下のようにdummy-vmというDockerホストを構築してその上のコンテナ内でcluster-idを生成する。 まず、dummy-vmという名前のDockerホストを作る。 ➤ docker-machine create -d virtualbox dummy-vm 作成したDockerホストの環境情報をshellに読み込ませる。 ➤ eval “$(docker-machine env local)” swarm createコマンドを実行してcluster-idを発行する。 ➤ docker run swarm create Unable to find image ‘swarm:latest’ locally latest: Pulling from library/swarm https://blog.takanabe.tokyo/2015/11/docker-machine%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6virtualbox-aws-esxi%E3%81%ABdocker%E3%83%9B%E3%82%B9%E3%83%88%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Sun, 22 Nov 2015 12:18:22 +0000 https://blog.takanabe.tokyo/2015/11/docker-machine%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6virtualbox-aws-esxi%E3%81%ABdocker%E3%83%9B%E3%82%B9%E3%83%88%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Docker ToolboxでMac OSXにDocker環境を最速で構築するでは、Docker Toolboxを利用してMacOSXにDocker環境を構築した。今回は、Docker Toolboxに含まれるDocker Machineを使って仮想環境にDockerホストを構築する。 Docker Machineとは Docker MachineとはDocker社が提供しているツールであり、Dockerホストを様々な仮想化環境に構築する。 これを使うことで、AWSでも、VirtualBoxでも、ESXiでもDocker deamonがインストールされたVMを作成できる。(要する簡単にリモートに上図の赤枠で囲まれている部分が構築出来る) Docker MachineがサポートするDriver Docker Machineは様々な仮想環境サポートするDriverを提供しており、2015年11月22日現在は以下がサポートされている。 Amazon Web Services Microsoft Azure Digital Ocean Exoscale Google Compute Engine Generic Microsoft Hyper-V OpenStack Rackspace IBM Softlayer Oracle VirtualBox VMware vCloud Air VMware Fusion VMware vSphere 今回はこの中から、Virtualbox、AWS、ESXiに絞ってDockerホストを構築してみる。 準備 前準備として、Docker Toolboxをインストールしておく。まだインストールしていない場合は、Docker ToolboxでMac OSXにDocker環境を最速で構築するを参考にインストールする。 仮想環境にDockerホストを構築する with Virtualbox まずはVirtualboxにDockerホストを構築する。 ➤ docker-machine create --driver=virtualbox vbox-test このコマンドを実行すると以下のようなメッセージが表示され、VirtualBox上にvbox-testという名前のDockerホスト(VM)が起動する。 Running pre-create checks... Creating machine... (vbox-test) OUT | Creating VirtualBox VM. https://blog.takanabe.tokyo/2015/11/docker-toolbox%E3%81%A7mac-osx%E3%81%ABdocker%E7%92%B0%E5%A2%83%E3%82%92%E6%9C%80%E9%80%9F%E3%81%A7%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Sun, 22 Nov 2015 05:32:56 +0000 https://blog.takanabe.tokyo/2015/11/docker-toolbox%E3%81%A7mac-osx%E3%81%ABdocker%E7%92%B0%E5%A2%83%E3%82%92%E6%9C%80%E9%80%9F%E3%81%A7%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ モチベーション 最速でMacOSXのDocker環境を構築する。 Docker Toolboxとは? Docker ToolboxとはDocker社が公式で提供しているWindowsやMacなどのPCでDocker環境を簡単に構築するパッケージのこと。手元のPCで試しにDockerを動かしてみたいときはとりあえずこれを入れれば良い。 Docker Toolboxが含むDockerツール群 Docker Toolboxでは以下のツールがインストールされる。 ツール名称 役割 Docker Client WindowsやMacからdockerコマンドを実行できるようにする Docker Machine Docker Engineが動くホストをローカルやリモートに構築する (旧boot2docker) Docker Compose 複数のコンテナをYAMLで管理する Docker Kitematic GUIでコンテナを管理する。VM管理におけるVirtualboxのような位置づけ VirtualBox Dockerを動かすVMの構築をする これらのツールは下図のような相関になる。 (参考:http://devcenter.magellanic-clouds.com/learning/docker-toolbox.html) Docker Toolboxのインストール それではDocker Toolboxをインストールする。公式のDocker ToolboxからMac OSX用のイメージをダウンロードする。ダウンロードしたDockerToolbox-X.Y.Z.pkg(X,Y,Zはバージョンを表す数字) を実行すると、インストレーションガイドが始まる。 これに従いDocker Toolboxをインストールする。 Docker Toolboxのダウンロードからここまで10分。 Kitematicを使ってみる コンテナをGUIで管理できるKitematicを使ってみる。spotlightでkitematicを検索実行する。 初回実行時は以下のような画面が表示されDocker MachineでVirtualbox上にDockerホストを構築する。 https://blog.takanabe.tokyo/2015/10/redux-boilerplate-with-react-material-ui/ Tue, 20 Oct 2015 13:57:55 +0000 https://blog.takanabe.tokyo/2015/10/redux-boilerplate-with-react-material-ui/ Motivation There is no boilerplate of Redux using React & Material UI when I wanted to created a new web application with the combination. Since I felt it was waste of time to solve its dependency problems among React, Redux and Material UI, I prepared its boilerplate on github. takanabe/react-redux-material_ui-boilerplate · GitHub I wish you would consentrate to develop application by using the template :) About boilerplate A boilerplate for React + Redux + Material UI + ES6 syntax applications. https://blog.takanabe.tokyo/2015/10/5%E5%B9%B4%E9%96%93%E3%81%A74%E4%B8%87%E4%BA%BA%E3%81%AE%E3%83%9C%E3%83%A9%E3%83%B3%E3%83%86%E3%82%A3%E3%82%A2%E3%81%A7%E5%83%8D%E3%81%8F%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%A8%E3%81%84%E3%81%86%E8%A8%98%E4%BA%8B%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0%E6%89%80%E6%84%9F/ Sun, 11 Oct 2015 03:13:03 +0000 https://blog.takanabe.tokyo/2015/10/5%E5%B9%B4%E9%96%93%E3%81%A74%E4%B8%87%E4%BA%BA%E3%81%AE%E3%83%9C%E3%83%A9%E3%83%B3%E3%83%86%E3%82%A3%E3%82%A2%E3%81%A7%E5%83%8D%E3%81%8F%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%A8%E3%81%84%E3%81%86%E8%A8%98%E4%BA%8B%E3%82%92%E8%AA%AD%E3%82%93%E3%81%A0%E6%89%80%E6%84%9F/ モチベーション とあるIT人材の育成の記事を読んで自分が考えていることを書きたくなった。 記事について 5年間で4万人のエンジニアが必要--IT分野の新業界団体「日本IT団体連盟」発足という見出しの記事を読んだ。 5年間で4万人のエンジニアが必要–IT分野の新業界団体「日本IT団体連盟」発足 - ZDNet Japan 所感 この記事の、”(サイバーセキュリティの文脈で)五輪そのものに対して、ボランティアで対応できるエンジニアが必要で、今後5年間で4万人のエンジニアを育てなくてはいけない…”の部分は本気なのだろうか？ 個人的にボランティア活動をするのは好きだし、日本のサイバーセキュリティ人材が不足しているのも事実なのでそれを増やそうという活動にも賛成できる。だけど、教育、研究、対価の面で必要な投資をせずに、オリンピックのサイバーセキュリティをボランティアがいないと回らないというのはおかしい。 その上、一般的にイメージするボランティアは、数時間、多くて1,2日程度無償で働くらいのものだが、ここでいうボランティアはそれとはかけ離れている。サイバーセキュリティで貢献するとなれば、会期中は24時間何日も張り付くことになるだろうし、何か貢献できるようなレベルになるには途方も無い時間の自己研鑚と現場経験が必要になる。 そもそも、国防を無償でするという美徳を求めてボランティアをするエンジニアは既にそういう活動をしているだろうし、軽い気持ちで1,2年勉強した程度の人が何かできるようになる程甘い世界でもない。 サイバーセキュリティに限らず、日本でITエンジニア不足しているという話は良く上がる問題だけど、必要なところに必要な投資をしないで、人材が育たないなというのは火を見るより明らかじゃないか。 まずはサイバーセキュリティをコストとして見るのではなく、将来のために長期的に投資をするべき分野という位置づけること、人材育成や現場で貢献している人にきちんと対価を払うことが重要じゃないだろうか。 参考 サイバーセキュリティを良くわからない人が読めるような本はこの辺 サイバーセキュリティ読本 Author: 一田和樹 Manufacturer: 原書房 Publish date: 2013-07-24 サイバー・インテリジェンス(祥伝社新書) Author: 伊東寛 Manufacturer: 祥伝社 Publish date: 2015-09-02 追記:2015.10.16 再び所感 前に書いた記事の続編ともなる記事があるみたいだ。 「五輪にはボランティアで働けるエンジニアが必要」発言の真意を聞く - ZDNet Japan 僕の知ってるエンジニア達はInteropは仕事の一環で行ってるよ。ボランティアで参加している企業ってどこなんだろうか。 荻原さんという人物を良く知らないし、記事になっている事以外のコンテキストもわからない。彼なりに色々考えた上でボランティアが今後の予算獲得に繋がると考えているのかもしれない。が、サイバーセキュリティを本務としている僕には彼の提案は刺さらなかった。 予算の内訳の関係上投資できない分野があるということは仕方がない。セキュリティは空気みたいな存在で、何も起きなかったら(もしくは気づいていないだけなら)ありがたみは感じづらいしね。ただ、重要、重要と口では言っているが投資に値しない分野と国に分類されている事実とボランティアのエンジニアで対応出来る程度の仕事と考えられていることが悲しい。 繰り返しになるがサイバーセキュリティのエンジニアであることはそんなに生ぬるいことではない。文字通り、僕たちはインターネット空間で起きる全てのサイバー攻撃に備えて幅広い分野の技術を学ばなくてはならないし、それぞれ得意な分野を突き詰めていく必要もある。また、世の中で流行っているもの(今だったらIoTだろうか)の知識も必要だ。日々発生する新しい攻撃手法の情報収集もしなくてはならない。 数の利が働かないのもサイバーセキュリティである。サイバーセキュリティにおいては一番脆弱なのは”人間”であり、人間の不完全さを利用して攻撃者は攻撃対象の情報収集するからだ。俗にソーシャルエンジニアリングというやつだ。 人が増えれば増えるほど攻撃者が好きを付くチャンスは増えるのだ。 ソーシャル・エンジニアリング Author: クリストファー・ハドナジー Manufacturer: 日経BP Publish date: 2012-11-01 また、攻撃者は重箱の隅を突くように一点の脆弱性を突くだけで良いが、こちらはインターネット空間の全ての攻撃から対象を守る必要がある。まるで、サッカーのPKのキッカーとキーパーのように、攻撃する側が圧倒的に有利な非対称な世界で闘っているのだ。正直、並大抵の人では実力者の邪魔になることはあっても役にも立たない。国の予算で教育されてボランティアとして集まったとしても多くは前者になるだろう。 https://blog.takanabe.tokyo/2015/09/nosql%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%AB%E3%82%88%E3%82%8B%E5%88%86%E9%A1%9E/ Sat, 05 Sep 2015 05:00:37 +0000 https://blog.takanabe.tokyo/2015/09/nosql%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E6%A7%8B%E9%80%A0%E3%81%A8%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3%E3%81%AB%E3%82%88%E3%82%8B%E5%88%86%E9%A1%9E/ モチベーション NoSQLの生まれた背景、分類、実装について説明できるようになりたい NoSQLとは NoSQLはNot Only SQLの略語で、RDB以外のデータベースの総称。従来はデータベースの操作に使う言語はSQLであり、その対象はリレーショナル・データベースであるというのが暗黙の認識であったが、データベースの操作をする言語はSQLだけじゃないし、リレーショナル・データベース以外のデータベースも必要であるという意味が込められている。つまるところ、SQL = RDBと解釈すればRDB以外のデータベースの総称がNoSQLの定義と言える。 NoSQLの特徴と生まれた背景 NoSQLの特徴を掴むには、クラウディアン社の河野達也さんのスライドと書籍を読むのがお勧め。この記事でもスライドと書籍を大いに参考にさせて頂いている。 Nosqlの基礎知識（2013年7月講義資料） from CLOUDIAN KK NOSQLの基礎知識 (ビッグデータを活かすデータベース技術) Author: 本橋信也 Manufacturer: リックテレコム Publish date: 2012-04-25 上記の資料を読むとNoSQLは以下のような傾向があるとわかる。 スキーマレスであること リレーションナルモデルの結合操作を利用しないこと 水平スケーラビリティが確保しやすい事が多いこと(スケールアウトに適している) トランザクションを利用できないものが多いこと NoSQLが生まれた背景にはデータの量と質が変わってきたことに関係がある。多様な種類のデータが取得出来るようになるにつれて、そのデータの量が莫大に増えてきており、またその種類の豊富さからスキーマの定義が容易ではなくなっているからだ。これを今風の言葉で表現するとビッグデータというのだろうが、このビッグデータ時代のデータの管理や処理を従来のRDBだけで行うのが困難になってきている。 実際に、Google、Amazon、Facebookなど大量のデータを扱う名だたるIT企業がNoSQLを利用した基盤を開発しており、彼らのサービスを支えている。 しかし、有名どころで使われているからという理由で手を出すと泣きを見る。我々がこのNoSQLを使いこなすには、種類、特性、用途を理解して適切に使い分ける必要がある。本記事ではNoSQLのデータ構造、アーキテクチャの観点での分類について説明する。 NoSQLとKVSの関係 色々なNoSQLの説明に入る前に、NoSQLとKVS(Key Value Store)の違いを言及しておきたいと思う。KVSはあるKeyとValueを1対1で紐付けて管理するデータ構造で、NoSQLにもKVSタイプのDynamoDB、Redis、memcachedなどが存在する。しかし、ことNoSQLの文脈の中で出て来るKVSという単語が純粋なKVSを指しているとは限らない。例えば、Google社のBigTableやApache HBaseはKeyに対してValueは複数のカラムであり多少複雑な構造がとれるわけだが、これも分散KVSなどと呼ばれていたりする。これを踏まえるとKVSの定義は非常に曖昧で、他の人がKVSと言っているときに、あるデータ構造を指しているとは思わない方がいい。 データ構造とアーキテクチャから見るNoSQLの分類 NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)によると、NoSQLは以下のように分類出来る。 見ての通りデータ構造とデータベースのアーキテクチャ観点で分類されている。以下ではそれぞれの特徴を説明する。 データ構造上の分類 Key/Value型 Key/Value型は保存するデータをValueとした時にそれとペアとなる一意のKeyを使ってValueの追加、呼出しを行うタイプ。 新しいデータが追加去れるにつれて図の行部分が追加されるので立てに表が縦方向に伸びていくイメージ。 このデータ構造はシンプルである点が特徴であり、RDBよりもはるかにスケールアウトしやすい。データの分割を考えるとき、RDBはテーブル間のリレーションが定義されているため、整合性を保つための排他制御なども必要だが、Key/Value型のNoSQLはどのKeyがどのサーバに保存されているかを管理する(シャーディング)だけで良く、ややこしいことを考える必要がない。 カラム指向型 カラム指向型はKey/Value型のValue部分を高度にしたものである。一意の行Keyに対して複数のカラムを持てるのが特徴。ここで言うカラムははKey/Valueからなっているっため1つの行Keyに対して複数のKey/Valueが格納される。 使い方としては、 カラム指向型はKey/Value型と同様にスケールアウトを得意としており、複数のサーバにデータを分割、複製することでデータ間の関係性を容易に管理できる。 ドキュメント指向型 ドキュメント指向型はJSON、XMLなどのフォーマットで記述されたドキュメントを管理する。各ドキュメントはネストしない形で保存されるためドキュメント間での親子関係はもたない。それぞれのドキュメントはユニークなIDを持っておりそれを利用してドキュメントを特定する。 https://blog.takanabe.tokyo/2015/09/window%E3%81%8B%E3%82%89%E9%80%81%E3%81%A3%E3%81%9F%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92mac%E3%81%A7%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B/ Fri, 04 Sep 2015 12:51:40 +0000 https://blog.takanabe.tokyo/2015/09/window%E3%81%8B%E3%82%89%E9%80%81%E3%81%A3%E3%81%9F%E3%83%86%E3%82%AD%E3%82%B9%E3%83%88%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E6%96%87%E5%AD%97%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92mac%E3%81%A7%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B/ モチベーション Windowsユーザから送られてきた文字化けしているテキストファイルをMac側で読めるように変更する WindowsとMacの文字コードの違い WindowsとMacの文字コードは異なる、そんなのはみんな知っているが恥ずかしながらLinuxコマンドでそれを変換する方法を知らずにいた。Windowsでは様々な文字コードを扱うことができるが、日本語を表現する標準エンコーディングとしてShift-JISが使われている。一方で、Mac OSXではUnicodeが標準だ。当然同じ文字を表すのに用いるビット列は異なる。 また、文字コードだけでなく、改行コードも異なる。WindowではCR+LFが、Mac OSXではLFが使われる。この、CR(キャリッジリターン)とLF(ラインフィード)はタイプライターが使われていた自体に言葉で馴染みがないかもしれない。Wikipediaには以下のように書かれている。 これらの用語はタイプライターが由来である。タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われる。英語などの左横書きにおける「キャリッジリターン」とは、紙を固定して移動する装置（キャリッジ）を元の位置に戻す（リターン、つまり紙の左端に印字装置が来る）ことである。「ラインフィード」とは紙を必要な行（ライン）だけ上に送る（フィード、つまり下の行に印字装置が来る）ことである。 nkfコマンド さて、文字コードや改行コードの違いを理解した所で、実際に変換してみる。変換にはnkfコマンドを使う。nkfはNetwork Kanji code conversion Filterの略で、ファイルの文字コードを変換するのに利用するコマンド。Shift-JISでエンコードされて送られてきたテキストファイルが文字化けするから、UTF-8に変換したい、などの状況で利用する。 今回は所有しているMacのUTF-8環境に合わせるために以下のコマンドを実行した。 $ nkf -g windows.txt Shift_JIS $ nkf -w --overwrite windows.txt $ nkf -g windows.txt UTF-8 Shift-JISからUTF-8に文字コードが変換されている。nkfコマンドがインストールされていない時は以下を実行する。 $ brew install nkf ##　MacからWindowsにShift-JISエンコーディングで送るには Shift-JISに変換するには以下を実行する。 $ nkf -s example.txt example-sjis.txt また、改行コードをWindowsのものに合わせるには以下を実行する。 $ nkf -Lw example.txt example-win.txt 既存ファイルを上書きしながら同時にエンコーディングと改行をコードをWindowsのものにするには以下を実行する。 $ nkf -s -Lw --overwrite example.txt fileコマンドでも文字コードの確認は出来る 実はファイルコマンドでも--mimeオプションをつけると文字コードを確認出来る。 $ file --mime example. https://blog.takanabe.tokyo/2015/08/ruby%E3%81%AE%E9%96%A2%E6%95%B0%E3%81%AE%E5%BC%95%E6%95%B0%E3%81%AF%E5%80%A4%E6%B8%A1%E3%81%97%E3%81%A7%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AE%E8%A8%BC%E6%98%8E%E3%82%92%E3%81%99%E3%82%8B/ Tue, 25 Aug 2015 14:48:14 +0000 https://blog.takanabe.tokyo/2015/08/ruby%E3%81%AE%E9%96%A2%E6%95%B0%E3%81%AE%E5%BC%95%E6%95%B0%E3%81%AF%E5%80%A4%E6%B8%A1%E3%81%97%E3%81%A7%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AE%E8%A8%BC%E6%98%8E%E3%82%92%E3%81%99%E3%82%8B/ モチベーション Rubyの関数の引数は値渡しである(参照渡しではない)ことを証明する 背景 プログラム言語ごとに、関数の引数が値渡しであったり参照渡しであったりと異なる。Rubyの記事を見ると、Rubyは参照渡しであるという記事を散見するが断言させてもらう。Rubyは値渡しである。アドレス番地などを用いた説明もできるがそれらは本記事の参考に譲り、ここではコードの振る舞いベースで値渡しであることの証明を行う。 変数が格納するのはオブジェクトを指すポインタのようなもの 整数を格納した変数を、別の変数に代入してそれらのobject idを確認してみる。 irb(main):001:0 val = 10 = 10 irb(main):002:0 val2 = val = 10 irb(main):004:0 val.object_id = 21 irb(main):005:0 val2.object_id = 21 これをみると、2つの変数のobject idは同値になっているため、変数には値が入っているのではなく、オブジェクトへの参照（ポイントのようなもの)が入っていることがわかる。 配列を関数の引数にしてみる 配列を関数の引数にして、関数内で変更するコードを書いてみる。 def display_obj_id(arg) puts "OID before assign: #{arg.object_id}" arg[0] = 10 puts "OID after assign: #{arg.object_id}" arg # arg = [3,3,3] # puts arg.object_id end array = [1,2,3] puts "array before func: #{array}" puts "OID outside of func: #{array. https://blog.takanabe.tokyo/2015/08/particle-swarm-optimization%E3%81%A7%E6%9C%80%E9%81%A9%E5%8C%96%E5%95%8F%E9%A1%8C%E3%82%92%E8%A7%A3%E3%81%8F/ Sat, 22 Aug 2015 03:25:43 +0000 https://blog.takanabe.tokyo/2015/08/particle-swarm-optimization%E3%81%A7%E6%9C%80%E9%81%A9%E5%8C%96%E5%95%8F%E9%A1%8C%E3%82%92%E8%A7%A3%E3%81%8F/ モチベーション メタヒューリスティック手法を開発するアプリケーションの中に導入したい Particle Swarm Optimizationとは Particle Swarm Optimization(以下PSO)とは群知能の一種であり、鳥の群れや魚の群れの行動をモデル化することで与えられた目的関数の最適解近傍を効率的に探索する手法である。近傍と述べているのは、求められた解が必ずしも最適解である保証はないが、現実的な時間内で近しい値を算出できるためである。似たような手法にGenetic algorithm(GA)やTabu search(TS)等が存在するが、PSOはそれらと比べて極めて実装が容易である。 PSOのモデル式 PSOのモデル式は群れの知能 : Particle Swarm Optimization(<特集>最適化問題へのアプローチ)を参考のこと。 目的関数と環境変数 以下の目的関数、環境変数からなる最適化問題を解く。 目的関数 : f(x,y) = x ^ 2 + y ^ 2 環境変数 : x, y 制約式 : - 10 ≤ x ≤ 10 , - 10 ≤ y ≤ 10 この式はメタヒューリスティック手法なんかを使わずとも、最適解が0であることはわかるので、PSOによる解もそれの近傍であると予想できる。 PSOの実装 def objective_function(vector) # f(x,y) = x^2 + y^2の右辺の計算 return vector.inject(0) {|sum, val| sum + val ** 2} end def get_random_vector(minmax_array) return Array. https://blog.takanabe.tokyo/2015/07/mysql%E3%81%A7%E5%A4%96%E9%83%A8%E3%82%AD%E3%83%BC%E5%88%B6%E7%B4%84%E3%81%AE%E5%8B%95%E4%BD%9C%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B/ Wed, 29 Jul 2015 14:33:13 +0000 https://blog.takanabe.tokyo/2015/07/mysql%E3%81%A7%E5%A4%96%E9%83%A8%E3%82%AD%E3%83%BC%E5%88%B6%E7%B4%84%E3%81%AE%E5%8B%95%E4%BD%9C%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B/ モチベーション ActiveRecordでアソシエーションの設定をする前に、MySQLの外部キー制約の設定方法の確認をしたい 準備 環境 mysql --version mysql Ver 14.14 Distrib 5.6.25, for osx10.10 (x86_64) using EditLine wrapper 実行するクエリ CREATE TABLE authors( id INT NOT NULL PRIMARY KEY, name VARCHAR(255) NOT NULL ) ENGINE=InnoDB; CREATE TABLE publishers( id INT NOT NULL PRIMARY KEY, name VARCHAR(255) NOT NULL ) ENGINE=InnoDB; CREATE TABLE books( id INT NOT NULL PRIMARY KEY, title VARCHAR(255) NOT NULL, author_id INT NOT NULL, publisher_id INT NOT NULL, FOREIGN KEY(author_id) REFERENCES authors(id) ON UPDATE RESTRICT ON DELETE RESTRICT, FOREIGN KEY(publisher_id) REFERENCES publishers(id) ON UPDATE CASCADE ON DELETE CASCADE ) ENGINE=InnoDB; INSERT authors(id, name) VALUES (1, 'author1'), (2, 'author2'), (3, 'author3'), (4, 'author4'), (5, 'author5'); INSERT publishers (id, name) VALUES (1, 'publisher1'), (2, 'publisher2'), (3, 'publisher3'), (4, 'publisher4'), (5, 'publisher5'); INSERT books(id ,title, author_id, publisher_id) VALUES (1, 'book1', 1, 1), (2, 'book2', 2, 2), (3, 'book3', 3, 3), (4, 'book4', 4, 4); この時、小テーブルのにレコードを挿入する、 https://blog.takanabe.tokyo/2015/07/cve-2015-3440-wordpress-4.2-%E3%81%AE%E8%84%86%E5%BC%B1%E6%80%A7%E3%82%92%E3%81%A4%E3%81%84%E3%81%9Fstored-xss%E3%81%AE%E6%A4%9C%E8%A8%BC%E3%82%92%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ Sat, 04 Jul 2015 12:17:21 +0000 https://blog.takanabe.tokyo/2015/07/cve-2015-3440-wordpress-4.2-%E3%81%AE%E8%84%86%E5%BC%B1%E6%80%A7%E3%82%92%E3%81%A4%E3%81%84%E3%81%9Fstored-xss%E3%81%AE%E6%A4%9C%E8%A8%BC%E3%82%92%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション XSSについて語る後輩に鼓舞された CVE-2015-3440とは CVE-2015-3440はXSSに関する脆弱性であり、WordPressに投稿された記事のコメント欄にjavascriptと大量の文字列を一緒に投稿することでコメント欄を表示したユーザのブラウザ上で任意のjavascriptを実行出来るというもの。これは、コメント欄の値を保持するMySQLのカラムTypeの最大サイズを超す文字列が書かれた時、その文字列を適切に処理できないために起こる。会社の後輩がこの脆弱性について話していたのだが、途中からロジックがわからくなり自分でも検証したくなった。 環境の準備 以下の環境を用意する。 --------------------------------------- | WordPres Container| MySQL Container | |-------------------------------------| | Docker | |-------------------------------------| | Vagrant Ubuntu (VirtualBox) | |-------------------------------------| | MacOS X | --------------------------------------- ローカルのvagrant box listに保存されているubuntu14_04を使う。 $ vagrant init ubuntu14_04　 Vagrantfileを編集する。 # 以下の行を追加する Vagrant.configure(2) do |config| ... config.vm.network "forwarded_port", guest: 80, host: 8080 config.vm.network "forwarded_port", guest: 80, host: 3306 ... config.vm.network "private_network", ip: "192.168.33.10" end VMを起動して環境情報を確認、最新化、Dockerのインストールを行う。 $ vagrant up $ vagrant ssh vagrant@vagrant-ubuntu-trusty-64:~$ lsb_release -a No LSB modules are available. https://blog.takanabe.tokyo/2015/06/docker-bench-for-security%E3%81%A7docker%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A8%BA%E6%96%AD%E3%82%92%E8%A1%8C%E3%81%86/ Tue, 30 Jun 2015 11:33:07 +0000 https://blog.takanabe.tokyo/2015/06/docker-bench-for-security%E3%81%A7docker%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E8%A8%BA%E6%96%AD%E3%82%92%E8%A1%8C%E3%81%86/ sited by docker/docker-bench-security · GitHub モチベーション Docker環境のセキュリティ診断ツールを触ってみる Dockerのセキュリティ Dockerが日常的に利用されるようになり、そのセキュリティの重要性も日に日に増してきている。Docker社もセキュリティには力を入れており、Docker Seicurity BlogでDockerのセキュリティポリシーやCVE情報等、Dockerのセキュリティ周辺情報を提供している。 加えて、同社はホワイトペーパー”Introduction to Container Security“でDockerコンテナを使うことでインフラリソースの追加投入をぜずにセキュリティを強化できることを述べており、特に以下の3点を言及している。 コンテナは基盤となるインフラのリソースを使うことなく、ホストの攻撃ベクトル(攻撃経路)を減らすために、アプリケーション同士やアプリケーションとホストを分離する保護レイヤを追加する。 コンテナと仮想マシンは同一環境にデプロイ可能でそれらはサービスをセキュアに分離するレイヤを提供する。 コンテナの本質は高速かつ簡易なOS、アプリケション及びインフラの各レイヤへのパッチ、アップデートを可能にさせることであり、システム全体のセキュリティ・コンプライアンスを維持を支援することである。 コンテナで1つレイヤーを追加し、適切にサービスとリソースの管理を行うことでセキュリティレベルが向上するという主張だ。 そんなコンテナのセキュリティだが、先日、Docker、VMware、楽天、Cognitive Scale、Internet Securities ExchangeらはCenter for Internet Securityと共にCIS Docker 1.6 Benchmarkと称したDocker Engineのベンチマーク調査をしている。この調査では、CISのセキュリティベンチマークプログラムが、組織がセキュリティのアセスメントと堅牢化をするための明確な定義を持ち、公正に議論されたベストプラクティスを提供していること、また、このコミュニティベースのベンチマークがLinuxやDockerの推奨設定を提供していると述べている。 Docker Bench for Securityはこのベンチマーク調査の推奨設定を基準にDockerコンテナの設定を自動的に診断するツールである。 環境の準備 Docker Bench for Securityを使うために環境の準備を行う。今回はVagrant上にUbuntu14.04を起動して、Dockerのインストールする。またテスト用のコンテナとしてNginxのコンテナを準備する。 Dockerのインストール まずはUbuntu14.04にて試験を実施するために、Docker: Installation of Ubuntuに従い必要な環境を準備する。 ローカルのvagrant box listに保存されているubuntu14_04を使う。 $ vagrant init ubuntu14_04　 Vagrantfileを編集する。 # 以下の行のコメントを外す # config.vm.network :private_network, ip: "192.168.33.10" VMを起動して環境情報を確認、最新化、dockerのインストールを行う。 $ vagrant up $ vagrant ssh $ vagrant@vagrant-ubuntu-trusty-64:~$ lsb_release -a No LSB modules are available. https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%807react-native%E3%81%A7ios%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E9%96%8B%E7%99%BA%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ Sun, 21 Jun 2015 02:13:23 +0000 https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%807react-native%E3%81%A7ios%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E9%96%8B%E7%99%BA%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション React Nativeを使ったiOSアプリケーションの開発フローを経験する React Nativeとは? React NativeはReact.jsを使ったネイティブアプリケーション開発を可能にさせるSDKのことで、Facebookが2015年に公開したもの。FacebookはReact Native: Bringing modern web techniques to mobileでReact Nativeについて以下のように説明している。 We’ve been using React Native in production at Facebook for some time now, and while there’s still a ton of work to do, it’s been working really well for us. It’s worth noting that we’re not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. https://blog.takanabe.tokyo/2015/06/prott%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ Thu, 11 Jun 2015 11:33:37 +0000 https://blog.takanabe.tokyo/2015/06/prott%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション Prottを使ったプロトタイピングを試してみる Prottとは ProttはGoodpatch社が開発しているプロトタイピングツールです。Goodpatchによると、 どうすればアイデアをリアルな感覚で確かめるまでの時間を縮められるのか。どうすれば場所や時間に関係なく互いに高めあうチームができるのか。ProttはUIデザイン会社GoodpatchのUIデザインプロセスの課題から生まれたツールです。 とのこと。”ラピッドプロトタイピング”とか”新しいチームワーク”をコンセプトとして開発されているんだって。使い方探していたらPVっぽいものが有りました。トランジッションを含めたプロトタイプがサクサク出来るようです。 Prott - Rapid Prototyping for Mobile Apps from Goodpatch on Vimeo. 使い方 基本的な使い方はKnowledge Base – Customer Feedback for Prottに書いてある通り。が、僕はプロトタイプを作るにあたり一切見ていません。 とりあえず何か作ってみよう 何はともあれ何か作ってみないと良し悪しがわからない。今回は以下のルールにもとづいてどこまでプロトタイピング出来るか試してみた。 作成時間は1時間とする Prottの使い方的なdocumentは読まない ワイヤーフレーム機能を使う 6月末まで無料プランでもワイヤフレームが使えるということなので、この機会に試しておく。 1. ラフデザインを作る まずはProttを使う前にラフデザインを作る。電車の移動時間に時計のアプリのデザインを手書きでちゃちゃっと作った。 2. 写真をProttに取り込む Prottは写真を取り込む機能があって、こんなふうにそれぞれの写真のどの部分が他の写真へどのようなトランジッションで遷移するか設定できる。 アイデアを思いついてラフデザインを作った時、とりあえずトランジッションをつけて他の人に共有してみようって時に便利かな。 3. ワイヤーフレーム作成機能 ラフデザインを元にワイヤフレームを作る、このPrott上でのワイヤフレームの作成がProttの有料プランについてくる。 今までパワーポイントとかキーノートとかで作成していたワイヤフレームをProttが持っているアプリケーション開発のために用意されたアイコンをドラッグアンドドロップしていくだけで作れる。早いし、簡単！また、トランジッションの設定もトランジッションを設定したい部分を選択して、移動先のスクリーンに黄色の線を繋ぐだけでできる。 4. 完成 実際に作成したプロトタイプをこちら。 本当に手早く、簡単にプロトタイプが作れた！ProttのUI自体はデザインの会社が作っているだけあって精錬されており、説明書がなくても触っていれば大体どんなことができるか推測できる。キーボードショートカットとか機能や機能の拡充を考えるとかなり流行りそう。また、Prottに慣れたらきちんとしたトランジッションを定義できるんだろうけど、1時間触って見た程度なのでイメージしていた動作になっていないところがある。6月末まで時間があるのでもう少し触って見ようと思う。 個人的に改善して欲しい所 Macアプリ版でアプリを起動する度にログイン情報を入力させないで欲しい(キャッシュが残っていない) 全体的に動作がもっさりしている スクリーンの選択画面でダブルクリックでスクリーンの編集モードになってほしい 概ね好印象なプロトタイピングツールであったが、Web版とMacアプリ版両方利用してみて両方ともやや動作がもっさりしている印象を受けた。また、慣れていないのもあるが、スクリーンを構成する要素の編集は思い通りにできない時があった。例えば、ラベルの文字の編集とか要素の選択とか。機能の拡充はもちろんだが、”ラピッドプロトタイピング”実現のために、UXの向上にも期待したい。 所感 久しぶりに使って、本当にいいサービスだなーと思うものに出会った。初心者でも1時間適当に触っていればなんとなく使い方がわかってくる。今回作成したプロトタイプも、Prottの学習時間を含めて1時間程度で出来た。作成したプロトタイプをSNSやメールなどで共有することができるので、プロトタイプの段階でユーザからフィードバックをもらいやすいし素晴らしく便利。ただし、ワイヤフレーム機能が有料であったり、作成できるプロトタイプの数が無料版だと1つだけだったりと、個人開発者には金銭的につらいので会社で効率よく開発を進めたいときにチームと相談して導入することを検討したい。 参考 公式 Prott - Rapid prototyping tool. https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%806react-componentscomponent%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ Sun, 07 Jun 2015 14:02:03 +0000 https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%806react-componentscomponent%E3%81%AE%E3%82%A8%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ モチベーション npmで公開されているReact componentsを使ってみる React Components Reactを使っていると似たようなComponentを作成している時がある。これも昔作ったよな、てな感じで。じゃあ、Componentをみんなで共有できるようなサービスがあれば便利出し作ってみようかな、と思っていたが既にReact Componentsなるサイトが存在していた。 何やらnpmでreact-componentというキーワードが入っているモジュールを検索出来るサービスらしい。せっかくなので使ってみようと思う。 react-modalモジュールを使ってみる react-modal-static-overlayというModalを実装しているComponentがあったので試しに使ってみる。 まずはnpmをつかってreact-modalをインストールする npm install react-modal 続いて、index.htmlとapp.jsxを書きreact-modal Componentを使ってみる。app.jsxは事前にコンパイルしてdist/build/build.jsに変換している。 +++ index.html +++ <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>React Modal test</title> </head> <body> <div id="app-container"></div> <script src = "./dist/build/build.js"></script> </body> </html> +++ src/app.jsx +++ var React = require('react'); var Modal = require('react-modal'); var appElement = document.getElementById('app-container'); Modal.setAppElement(appElement); Modal.injectCSS(); var App = React.createClass({ getInitialState: function() { return { modalIsOpen: false }; }, openModal: function() { this. https://blog.takanabe.tokyo/2015/06/windbg%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6notepad.exe%E3%82%92%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%81%99%E3%82%8B/ Wed, 03 Jun 2015 14:22:21 +0000 https://blog.takanabe.tokyo/2015/06/windbg%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6notepad.exe%E3%82%92%E3%83%87%E3%83%90%E3%83%83%E3%82%B0%E3%81%99%E3%82%8B/ モチベーション Windowsアプリケーションのプロセスにデバッガをアタッチしてその動きを追いたい 前提条件 コンピュータの仕組みやバイナリ関連の基礎を身に付けていること ※ 自信がない場合は本記事下部のおまけを参考にする。 WinDBGをつかってメモ帳をデバッグしてみる Windowsで使えるデバッガは色々あり、OllyDebugなんかはUIがユーザフレンドリで使いやすく多くのユーザに使われている。一方で、WinGDBはユーザビリティが良いとは言えないものの、Microsoft公式のデバッガであり、64bitアプリケーションのデバッグにも使える。今回は、WinGDBをつかってメモ帳のデバッグを行う。 環境準備 Windows環境を用意する modern.IEから評価用Windowsをダウンロードして仮想化ツール、Virtualboxで起動する。IE8 on Win7、VirtualBoxを選択してインストールする。 WinDBGをインストールする Microsoft Download CenterからWinDBGをダウンロードする。WinDBGはMicrosoft Windows SDKの中の1つのコンポーネントとして含まれており、SDKのインストーラでDebugging Toolsだけを選択すればWinDGBのみをインストールできる。また、cmd.exeからWinDBGを実行できるように以下の環境変数を設定する。 環境変数名：PATH(既存のPATHの末尾に値を追加) 値：C:\Program Files\Debugging Tools for Windows(x86)\ シンボルファイルのインストールとパスの設定 シンボルファイルとはソースコード、行番号、変数名、データ型などのプログラムの情報を格納しているファイルであり、デバッグに必要な情報（シンボル）が含まれたファイルのこと。拡張子はpdb(Program DataBase files)。デバッガとシンボルファイルリンクさせることで、デバッグでより詳細な情報を確認できる。インストールはWindows シンボル パッケージのダウンロードから行う。 また、都度WinDBGでパスの設定をするのは面倒なので、Use the Microsoft Symbol Server to obtain debug symbol filesを参考に環境変数にシンボルへのパスを設定する。 環境変数名：_NT_SYMBOL_PATH 値：SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols WinDBGでメモ帳をデバッグする プロセスにデバッガをアタッチする まずはnotepad.exeにWinDBGをアタッチする。 notepade.exeを起動する windbg.exeを起動する WinDBGのウィンドウからFile > Attach to a Process > notepad.exeよりプロセスにデバッガをアタッチする プロセスにデバッガをアタッチするとはじめはエントリポイントでブレーク状態になる。プロセスを動かしたいときはgを入力してブレーク状態を解放する。また、デバッガでプロセスの情報を確認したい場合は、WinDBGのBreakボタンをクリックする。この繰り返しがライブデバッグの基本的な流れとなる。 notepadに入力した文字列がメモリのどこに格納されているか確認する notepadに入力した文字列はファイルに保存しないとデータとしては残らないと思われがちがだが、実際にはキーボードから入力した瞬間からメモリに展開される。これを確認するには、notepadeに”hello”という文字列を入力した後に以下のコマンドを実行する。 0:001 s -u 0 L? https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%804react%E3%81%A7todo%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ Wed, 03 Jun 2015 12:55:39 +0000 https://blog.takanabe.tokyo/2015/06/react%E5%85%A5%E9%96%804react%E3%81%A7todo%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%9C%E6%88%90%E3%81%97%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション Reactに慣れるために簡単なSPAを作成したい 前提条件 Reactの基本文法理解している。 ToDoアプリの構成 以下のようなコンポネントの組み合わせでToDoアプリを構築する。大枠の構成は - TODO APP - TODO HEADER - TODO CONTAINER - TODO BANNER - TODO LIST ITEM #1 - TODO LIST ITEM #2 ... - TODO LIST ITEM #N - TODO FORM - TODO LIST のようにする。このReact JSXで表現するとこんな感じになる。 /* [TODO APP] */ var TodoApp = React.createClass({ ... }); /* [TODO BANNER] && [TODO LIST] */ var TodoBanner = React.createClass({ ... }); var TodoList = React. https://blog.takanabe.tokyo/2015/05/metasploit%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6windows%E3%81%AE%E4%BB%BB%E6%84%8F%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%95%E3%81%9B%E3%82%8B/ Tue, 26 May 2015 14:48:25 +0000 https://blog.takanabe.tokyo/2015/05/metasploit%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6windows%E3%81%AE%E4%BB%BB%E6%84%8F%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%95%E3%81%9B%E3%82%8B/ モチベーション ペネトレーションテストの勉強のためにMetasploitを使って、悪性URLにアクセスして来たWindows7クライアントに任意のコマンドを実行させてみる 環境 攻撃を受けるvictimクライアントと攻撃をするattackerクライアントの環境は以下の通り。 victimクライアント OS : Windows7 Professional SP1 32bit CPUアーキテクチャ: x86_64 ブラウザ : Internet Explorer 8 IP address : 192.168.1.59⁄24 C:\Users\sectusysteminfo OS 名: Microsoft Windows 7 Professional OS バージョン: 6.1.7601 Service Pack 1 ビルド 7601 OS 製造元: Microsoft Corporation OS 構成: スタンドアロン ワークステーション OS ビルドの種類: Multiprocessor Free システムの種類: X86-based PC プロセッサ: 2 プロセッサインストール済みです。 [01]: x64 Family 6 Model 42 Stepping 1 GenuineIntel ~2400 Mhz [02]: x64 Family 6 Model 42 Stepping 1 GenuineIntel ~2400 Mhz attackerクライアント OS : Kali Linux IP address : 192. https://blog.takanabe.tokyo/2015/05/react%E5%85%A5%E9%96%802reactify-watchifybrowserify-gulp%E3%81%A7jsx%E3%82%92%E8%87%AA%E5%8B%95%E3%83%93%E3%83%AB%E3%83%89%E3%81%99%E3%82%8B/ Sat, 23 May 2015 03:25:46 +0000 https://blog.takanabe.tokyo/2015/05/react%E5%85%A5%E9%96%802reactify-watchifybrowserify-gulp%E3%81%A7jsx%E3%82%92%E8%87%AA%E5%8B%95%E3%83%93%E3%83%AB%E3%83%89%E3%81%99%E3%82%8B/ モチベーション ReactのJSXの手動ビルドを自動でしたい 背景 Reactを使う場合JSXをJSに変換する必要があるのだがこれには2つの方法が有る。1つはhtmlの<script>タグ内にJSXを書きJSXTransformerでJSに変換する方法、もう一つは事前にJSXをビルドする方法である。前者は、自分でJSXをビルドをする必要はないが、html内の<script>タグ内に全てJSXを書く必要が有るため、JSXファイルを分割出来ない。また、JSXからJSへの変換が都度発生するためパフォーマンスの低下につながり現実的ではない。一方で、後者はファイルを分割できるため非常に便利だが、変更があるたびに自前でビルドする必要がある。僕は現状、都度手動でビルドを実行しているためとても面倒くさい。今回は煩わしさから解放されるべく手動で行っている部分を自動化するためにgulpのタスクを書いてみたいと思った次第である。 JSXの自動ビルドに必要なnodeパッケージ 大きく分けて以下の4つのnodeパッケージを使って自動ビルドを実現する。 gulp：Node.jsのStreamAPIを利用したビルドツール。gulpfile.jsにタスクの定義をすることでRakefileやMakeファイルのようなことができる reactify：JSXの変換とreact moduleの追加を行う Browserify：クライアントサイドのjavascriptでモジュール管理を実現するツール。これでbundleされたファイルはrequreで呼びだせる watchify：ファイルの差分を監視し、差分のみbrowserifyでビルドするツール。browserifyのラッパー的なツール gulp-browserifyというパッケージもあるみたいだが、Blacklisted · Issue #64 · deepak1556/gulp-browserify · GitHubによると、規約違反でブラックリストに入っているとのことなので使わないことにした。 gulpとvinyl 環境を構築する前にgulpのタスクを理解する。Node.js - Gruntfile.js が長すぎてつらい人は gulp を使ってみよう - Qiitaによると、gulpのタスクは 通常 gulp のタスクは、ざっくり言うと以下のような流れです。 gulp.src() でファイルの stream を作ります。 各プラグインが stream の中を流れるファイルを処理して、また stream に流します。 gulp.dest() で stream の中を流れてきたファイルを保存します。 ここで注意すべきは、gulp の扱う stream の中を流れるのは、ファイル一個に対応するオブジェクトだということです。具体的には vinyl という npm パッケージ で決まっている File オブジェクトです。ざっくり言うと、ファイルのパスとファイルの中身の情報を持っています。 ということです。この時重要なのはgulpのpipeに渡すオブジェクトはvinylでなくてはならないということです。 nodeパッケージをインストールする それでは、自動ビルド環境を構築していこう。まずはnodeパッケージのインストールをnpmを使って行う。インストールしたパッケージを他の環境でも利用できるようにするため $ npm init を実行してpackage.jsonを作成する。package.jsonでnpm install package_nameでインストールたパッケージの確認が容易になり、npm installを実行するだけで同じバージョンのパッケージを別環境でもインストールできるようになる。 https://blog.takanabe.tokyo/2015/05/react%E5%85%A5%E9%96%801-react%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%AA%BF%E3%81%B9%E3%81%9F%E3%81%AE%E3%81%A7%E3%81%BE%E3%81%A8%E3%82%81%E3%81%A6%E3%81%BF%E3%82%8B/ Mon, 18 May 2015 15:45:18 +0000 https://blog.takanabe.tokyo/2015/05/react%E5%85%A5%E9%96%801-react%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E8%AA%BF%E3%81%B9%E3%81%9F%E3%81%AE%E3%81%A7%E3%81%BE%E3%81%A8%E3%82%81%E3%81%A6%E3%81%BF%E3%82%8B/ モチベーション Virtual DOMを用いたフロントエンド開発をしたい Reactとは ReactはFacebookが開発したViewを実装するためのjavascriptライブラリである。Facebook, Instagram, Github Atomなどの海外サービスで利用されており、最近発売されたWEB+DB PRESS Vol.86でも特集として取り上げられるなど日本でも注目を集めている。AngularJSやBackbone.jsのようなフレームワークと比較されることが多いが、Reactはあくまでライブラリなので、他のフレームワークやライブラリとの併用も容易である。 なぜReactを使うのか？ Reactの特徴は高速かつシンプルで保守性の高いコードを書けることに尽きると思っている。それを支えているのは以下の特徴である。 シンプル(利用が容易)である Virtual DOMによるレンダリング効率の向上 コンポーネント指向で保守性、可読性が高い 一つ一つ具体的に見てみよう。 1. Reactのシンプルさ 従来のようなjQueryを使ったViewの操作はDOMに状態を持たせることになる。例えば、以下のようなページが与えられた時にユーザがボタンをクリックする回数でDOMに追加される<h1>Hello jQuery</h1>の数は変化する。このDOMの状態は開発者が管理することはできない。 $(function(){ $("button").click(function(){ if($("#added").length == 0) { $("#hoge").append("<h1 id='added'>Hello jQuery</p>"); } }); }); See the Pen jquery_sample by Takayuki Watanabe (@takanabe) on CodePen. コードが短いうちは問題にはならないが、大規模なアプリケーションとなるとありとあらゆるDOMの状態を考慮したコーディングが必要になるため、必然的にコードは複雑になり保守性が著しく低下する。AngularJS,Backbone.js,Vue,jsなどの最近流行りのjavascriptフレームワークはDOMの管理を分割して行うデータバインディング方式を採用しており、jQueryのような複雑なDOMの管理を避ける事ができる。しかし、どのフレームワークもそれなりに重く、学習コストが高い。一方で、ReactはViewの実装に特化したライブラリなので覚える用語やルールは少なく簡単に使える、Viewのロジックとアプリケーションロジックを分離できるため将来Reactを利用しなくなってもコードの再利用性が高いなどの利点がある。 ### 2. Virtual DOMによるレンダリング効率の向上 Ajax登場前後とReactによるDOMの操作はそれぞれ以下のようになる。 Ajax以前のWebアプリケーションと言えは、イベントが発生したらサーバでhtmlを生成して、レンダリングし直すことでViewの更新をしていた。この、Viewを更新するときは必ず全てをレンダリングし直す方式は開発者からするとシンプルな実装で済む上、状態管理も容易であるためありがたい。一方でサーバリソース、ネットワークリソースを無駄に消費する問題がありUXの低下を招く。AjaxによるWebアプリケーションは直接DOMの状態を変化させるため、全てをレンダリングし直す場合に要したリソースの無駄を防ぐことができるが。一方でDOMが状態を持つ点、コードの保守性、可読性が低下するなど別の問題を生んだ。ReactはAjax前後のWebアプリケーションの問題をVirtual DOM(VDOM)を導入することで解決している。VDOMはReactで導入されているDOMの抽象化概念である。Reactでは従来のようにDOMを直接操作するのではなくメモリ上にDOMと同じ構造のVDOMを作る。Viewの状態変化を検知すると状態変化前後のVDOMを比較し、その差分をパッチとしてオリジナルのDOMに当てることで効率的なレンダリングを実現する。このVDOMのおかげで開発者はViewの更新を全てレンダリングし直す時と同じ感覚でコードを書ける。DOMの構築速度の比較については[ここ](https://html5experts.jp/hokaccha/13301/)と[ここ](https://www.codementor.io/reactjs/tutorial/reactjs-vs-angular-js-performance-comparison-knockout)を参考にして頂きたい。 ### 3. コンポーネント指向により保守性・可読性が高い Reactはアプリケーションの構築をコンポーネントの組み合わせによって行う。コンポーネントによるViewの実現は以下の特徴を有しており、保守性、可読性の向上を支えている。 * 親コンポーネントが状態管理を一手に引き受けるため、子コンポーネントで状態の管理をしなくて良い * 開発速度が爆発的に向上することはないが、コードのどの部分がViewのどの部分に対応しているかわかりやすい * データの流れが一方向で親コンポーネントから子コンポーネントにデータの引き渡しが行われるため、データの流れが追いやすい 以下は、先ほどjQueryで実装したものをReactに変換したものである(表示する文字はHello Reactにしている)。Appコンポーネントは全ての子コンポーネントを束ねており、その子コンポーネントであるMessageコンポーネント、Buttonコンポーネントでそれぞれテキスト、ボタンに関するViewを分割実装している。 var React = require('react'); var App = React. https://blog.takanabe.tokyo/2015/04/gfm%E3%81%AE%E3%83%AA%E3%83%B3%E3%82%AF%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%E3%81%A7%E3%82%AF%E3%83%AA%E3%83%83%E3%83%97%E3%83%9C%E3%83%BC%E3%83%89%E3%81%AB%E3%82%B3%E3%83%94%E3%83%BC%E3%81%99%E3%82%8Balfred-workflow%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ Sun, 26 Apr 2015 11:50:43 +0000 https://blog.takanabe.tokyo/2015/04/gfm%E3%81%AE%E3%83%AA%E3%83%B3%E3%82%AF%E3%83%95%E3%82%A9%E3%83%BC%E3%83%9E%E3%83%83%E3%83%88%E3%81%A7%E3%82%AF%E3%83%AA%E3%83%83%E3%83%97%E3%83%9C%E3%83%BC%E3%83%89%E3%81%AB%E3%82%B3%E3%83%94%E3%83%BC%E3%81%99%E3%82%8Balfred-workflow%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション 自分でGFMに対応したLinkフォーマットに合わせるのが煩わしい 作ったAlfred workflow URL craftというworkflowを作った。これをインストールすれば、Alfredを開いてug 加工したいURLと入力するだけでクリップボードにGithub Flavored MarkdownのLinkフォーマットに従ったテキストが保存される。 アプローチ URLをGFMのLinkフォーマットに従い変更したものをクリップボードに保存する(以降GFM Link化と呼ぶ)にはいくつかのアプローチが有る。例えば、 ブラウザプラグインを利用して、現在開いているブラウザのアクティブなウィンドウのurlとタイトルを自動加工する Alfred workflowを利用してurlをコピーして引数として渡しスクリプトフィルタで自動加工する 前者に関しては、ブラウザプラグインを利用しているので現在閲覧中のWebサイトのURLとタイトルを簡単に習得できる。しかし、特定のブラウザでしか利用出来ないし、全てのブラウザのプラグインを作成するのは面倒である。それに比べて、後者はMacのアプリケーションAlfredを利用するものなので特定のブラウザという制約は受けない。Alfredを利用する場合、どのブラウザのどのタブのものをGFM Link化するか判定するロジックを組むのは色々と煩わしいが、workflowの引数としてGFM Link化したいURL情報をプログラムに渡す方法はシンプルで実装も簡単そうだ。よって、今回のAlfred workflowのスクリプトフィルタの引数に加工したURL情報を渡す方法を採用する。また、GFM Link化するURLが持つタイトル情報などは以下のように取得する。 Webページのタイトル htmlの<head><title>XXXX</title></head>の中にあるXXXXが目的のWebページのタイトルになる。 Webページのurl htmlの<link rel='canonical' href='YYYY/>にあるYYYYが目的のURLになる <link rel='canonical' href='http://blog.takanabe.tokyo/?p=335' /> しかし、今回はworkflowの引数としてGFM化したいURLを入力するのでその情報を利用することとする。ホットキーで一発で現在開いているWebページのURLを持ってきたいときには使いたいと思う。 workflowの作成手順 workflowはpythonのAlfredライブラリの使い勝手が良さそうなのでpythonで実装した。以下はメモ書き程度のworkflowの作成手順である。実装はアプローチに則り行った。 1. workflowの設定 Bundle ID:一意に決まるものが良い。まあでも自分の運用しているWebサイトのFQDNとかを使ってもいいだろう。 Created By: 自分の名前 Web Page:自分の運用しているWebサイト 2. Python Alfred workflow moduleのインストール インストール方法はInstallation :Alfred-Workflow 1.11.1 documentationに従った。 githubから最新のalfred-workflow-X.X.X.zipをダウンロードする ダウンロードしたファイルを解凍して、workflowディレクトリを取り出す 1.で作成したディレクトリに2.で取り出したworkflowディレクトリを以下のように格納する(作成したworkflowを右クリックすると該当のディレクトリを開くことができる) Your Workflow/ info.plist icon.png workflow/ __init__.py background.py update.py version web. https://blog.takanabe.tokyo/2015/04/t-pot%E3%81%AB%E3%82%88%E3%82%8Bdockerized-multi-honeypot%E3%81%AA%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E6%94%BB%E6%92%83%E8%A6%B3%E6%B8%AC%E7%92%B0%E5%A2%83%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Thu, 23 Apr 2015 15:34:11 +0000 https://blog.takanabe.tokyo/2015/04/t-pot%E3%81%AB%E3%82%88%E3%82%8Bdockerized-multi-honeypot%E3%81%AA%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E6%94%BB%E6%92%83%E8%A6%B3%E6%B8%AC%E7%92%B0%E5%A2%83%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ #モチベーション ハニーポットを使ってサイバー攻撃のトレンド観測をしたい 本記事を読むと最後にはこんな事ができる ハニーポットが収集した攻撃情報の時系列分析、どのプロトコルを狙ったものなのか、どこの国からの攻撃なのかなど、T-Potを構築することでこんな形で攻撃情報を可視化することができるようになる ハニーポットとT-Pot そもそも、ハニーポットとはインターネット上に飛び交うサイバー攻撃や悪性なWebサイトなどから攻撃情報を収集する技術である。通常ハニーポットは攻撃をひたすら待って収集する待ち受け型と自分から悪性サイトにアクセスするなどしてマルウェア検体を収集する巡回型のハニーポットに大別される。T-Potはドイツテレコムが開発している、異なる特徴を持つ待ち受け型のハニーポットをDockerコンテナ上で展開する機能と、ハニーポットで集取した各種ログをLogstash&Elasicsearch&Kibanaの解析機能をオールインワンで提供するサービスのことである。今回はこのT-Potを使って攻撃トレンドの観測環境を構築する。 アーキテクチャ 本家T-Potによるとアーキテクチャは以下のようになっている。これを見ると、Dockerコンテナで各種ハニーポット、分析部分、マルウェアのシグニチャマッチなどの照合部分がそれぞれ作られていることがわかる。各ハニーポットで収集されたトラフィックは全てのコンテナと共有する形で照合コンテナ、分析コンテナとの情報の共有を行う。また、これらのコンテナは1日1回自動的にリバートされまっさらな状態で再生成される。これにより、もしコンテナがマルウェアに乗っ取られたとしてもホストに影響が出る前にクリーンな状態にできると考えられる。 T-Potの構成要素 各ハニーポットの特徴 Glastopf Glastopfは脆弱なWebアプリケーションを模擬したハニーポット。SQLi、XSS,CSRFなどWebの脆弱性を付く基本的な攻撃を始めとして、Strutsなどのミドルウェアの脆弱性を付いた攻撃の観測まで期待できる。 Know Your Tools: Glastopf - A dynamic, low-interaction web application honeypot | The Honeynet Project Cyber Fast Track: Web Application Honeypot Final Report Kippo KippoはSSH通信に対する攻撃を観測するためのハニーポット。SSHにブルートフォース攻撃やパスワードリスト攻撃の観測が期待できる。 Github:desaster/kippo ハニーポット観察記録(11) honeytrap honeytrapは複数のネットワークサービスへの攻撃を観測するためのハニーポット。複数のネットワークサービスのエミュレーションをしており、他のハニーポットがマルウェアを収集する所に主眼をおいている中で、honeytrapは初期の攻撃を観測することが目的である Using hpfriends - the social data-sharing platform honeytrap – A Dynamic Meta-Honeypot Daemon dionea dioneaは最も完成度の高いOSSハニーポットで様々な攻撃情報を収集することができる。収集対象の攻撃はSMB、 http、 ftp、 tftp、 MSSQL、SIP(VoIP) などの各種プロトコルを想定している。 https://blog.takanabe.tokyo/2015/03/%E3%83%8E%E3%83%B3%E3%83%96%E3%83%AD%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0i/o%E3%81%A8%E9%9D%9E%E5%90%8C%E6%9C%9Fi/o%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B/ Thu, 26 Mar 2015 13:31:10 +0000 https://blog.takanabe.tokyo/2015/03/%E3%83%8E%E3%83%B3%E3%83%96%E3%83%AD%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0i/o%E3%81%A8%E9%9D%9E%E5%90%8C%E6%9C%9Fi/o%E3%81%AE%E9%81%95%E3%81%84%E3%82%92%E7%90%86%E8%A7%A3%E3%81%99%E3%82%8B/ モチベーション ブロッキングI/O，ノンブロッキングI/O，同期I/O，非同期I/O，I/O多重化を理解する 記事概要 非同期I/Oはインターネット上の文献を読んでいると、ノンブロッキングI/Oと同じだと解釈されていることが多い。同僚もノンブロッキングI/Oと非同期I/Oは同じだと話していたけど、この辺の話はあまり詳しくないから納得できなかったが、本当にそうなんだろうか。本記事では、非同期I/O、ノンブロッキングI/Oをの違いを整理することを主眼として、関連する同期I/O、ブロッキングI/O、I/O多重化などI/O周りのあやふやなに知識を焼きなおそうと思う。 とりあえず結論から 結論からいうと、ブロッキングI/Oと同期I/Oは同じであるが、ノンブロッキングI/Oと非同期I/Oは違うものと自分は判断した。 ブロッキングI/O & 同期I/O(Syncronous I/O) ブロッキングI/O(同期I/O)ではI/O処理時に対象のファイルディスクリプタが準備完了になっていない場合、ブロック状態、つまりプロセスはシステムコールの返答待ち状態になり張り付く。その間プログラムの処理が進むことはない。以下は、ブロッキングI/Oのユーザーモードとカーネルモードの遷移を表す。カーネルモードにコンテキストが切り替わり、システムコールの実行が完了すると元のユーザモードにコンテキストが戻り、ブロック状態からも解放される。(以降に出てくる図は”Boost application performance using asynchronous I/O”から引用させて頂いたものである) ノンブロッキングI/O ノンブロッキングI/OではI/O対象のファイルディスクリプタの準備完が了していないことをアプリケーション側に伝えるため即座にエラーが返る(errnoにEGAINが格納されて返ってくる)。一般に、O_NONBLOCKフラグを利用してノンブロッキングモードを宣言するが、この時プロセスはブロック状態にならず、CPUを他の処理に回すことができるためI/O待ち時間を有効活用できる。エラーはアプリケーション側でハンドリングしてリトライするタイミングを定義する必要がある。ノンブロッキングI/Oはソケットなどのネットワークに用いられるI/OモデルでディスクI/Oには使わない。C10K問題の対策としてノンブロッキングI/O+イベントループモデルを採用することでシングルスレッドで複数の接続を処理する方法がある。 非同期I/O(Asyncronous I/O) I/O処理が完了したタイミングで通知するI/Oモデルを非同期I/Oという。非同期I/Oは、通知はシグナルもしくはコールバックによって行われ、通知があるまではアプリケーション側で他の処理を進めることができる。プロセスがブロック状態にならない点ではノンブロッキングI/Oと一緒だが、非同期I/OはI/Oの処理が完了したら通知をし、ノンブロッキングI/OはI/O処理が可能な状態にないことをエラーで通知するので動きは異なる。 ノンブロッキングI/Oと非同期I/Oはどこが違う？ ノンブロッキングI/Oは処理がすぐできない時はエラーを返し、ブロック状態にさせない方式。一方、非同期I/Oは処理がすぐできない時は処理が完了するまでバックグラウンドで待機して、終了したタイミングで通知を返す方式(通知が来たら既に処理が終わっている)。 I/Oの多重化(I/O Multiplexing) I/O関連の調査をしていると必ず出てくるのがI/Oの多重化。このI/O多重化とはpoll()、select()、epollシステムコールを利用して、複数のファイルディスクリプタを1つのプロセスで管理すること。これらのシステムコールはファイルディスクリプタの状態変化を監視できるため、複数のファイルディスクリプタのいずれかが入出力準備が完了したかわかる。select、poll、epollの違いは以下の通り。 select selectはI/Oを多重化するためのシステムコールの1つ。監視対象のファイルディスクリプタn個をループの中で1つずつ状態確認する。そのため，計算量的には*O(n)*になる．また，扱えるファイルディスクリプタの数に上限があるため、現在はこのシステムコールを積極的に利用する理由は特にない。以下はselectを使ったsocket()、bind()、listen()後に準備ができているソケットを監視するプログラムだ。 void accept_loop(int soc) { char hbuf[NI_MAXHOST], sbuf[NI_MAXSERV]; int child[MAX_CHILD]; struct timeval timeout; struct sockaddr_storage from; int acc, child_no, width, i, count, pos, ret; socklen_t len; fd_set mask; /* child配列の初期化 */ for (i = 0; i < MAX_CHILD; i++) { child[i] = -1; } child_no = 0; for (;;) { /* select()用マスクの作成 */ FD_ZERO(&mask); FD_SET(soc, &mask); width = soc + 1; count = 0; for (i = 0; i < child_no; i++) { if (child[i] ! https://blog.takanabe.tokyo/2015/03/sensu-chef%E3%81%AEssl%E3%82%B5%E3%83%BC%E3%83%90%E8%A8%BC%E6%98%8E%E6%9B%B8%E4%BD%9C%E6%88%90%E3%81%AE%E6%B5%81%E3%82%8C%E3%82%92%E6%95%B4%E7%90%86%E3%81%99%E3%82%8B/ Sat, 21 Mar 2015 08:07:29 +0000 https://blog.takanabe.tokyo/2015/03/sensu-chef%E3%81%AEssl%E3%82%B5%E3%83%BC%E3%83%90%E8%A8%BC%E6%98%8E%E6%9B%B8%E4%BD%9C%E6%88%90%E3%81%AE%E6%B5%81%E3%82%8C%E3%82%92%E6%95%B4%E7%90%86%E3%81%99%E3%82%8B/ モチベーション sensu-chefのSSLサーバ証明書の自動生成スクリプトがしていることを把握して，流用可能か判断する． 記事概要 Sensuという監視のためのフレームワーク使って監視システムを構築する時，ChefやPuppetなどのConfiguration Managementツールを使うことが推奨されている．僕は普段からChefを使っているためSensuが公式に用意しているcookbook：sensu-chefを利用している．このsensu-chefはSensu serverとSensu clientとの通信にSSLを使うように実装されているため証明書の用意をする必要がある．一応，sensu-chefにはSSLで通信するときに必要な証明書を作成するためのスクリプトも用意されているのだが，その中身は果たして安全なのだろうか? スクリプトの処理内容を確認して，構築予定の監視サーバでどのように証明書を準備するか判断しようと思う， Sensuの論理アーキテクチャとSSL通信 Sensuの論理アーキテクチャは図の通り．今回整理するのは，Sensu serverとclientのMessage Queueとして利用しているRabbitMQとの通信に利用する証明書の作成スクリプトです．これは，RabbitMQのSSL Supportに書かれている内容を自動で処理するためのもの． 証明書の自動生成スクリプトを読んでいく sensu-chefのREADMEによると， >Running Sensu with SSL is recommended; this cookbook uses a data bag sensu, with an item ssl, containing the SSL certificates required. Sensu data bag items may be encrypted. This cookbook comes with a tool to generate the certificates and data bag item. If the integrity of the certificates is ever compromised, you must regenerate and redeploy them. https://blog.takanabe.tokyo/2015/03/chef%E3%81%A7sensu%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E7%9B%A3%E8%A6%96%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ Fri, 13 Mar 2015 15:11:55 +0000 https://blog.takanabe.tokyo/2015/03/chef%E3%81%A7sensu%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E7%9B%A3%E8%A6%96%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8B/ モチベーション 大規模インフラの監視ツールとしてSensuを導入したい， 記事概要 大規模なインフラの運用を安定化させるためにサーバの監視システムを選定している．監視システムは従来からZabbix，Nagios，Monitなど有名どころがありこれらは資料も，実績も十分にある．一方でこれらの監視ツールはサーバ台数が増加する度に多くの設定を投入する必要がある．これは，開発も運用もしている多忙なエンジニアからすると地味に辛い．そこで，クラウドのような多数のサーバからなるシステムを考慮して作られた，監視のフレームワークで最近注目されているSensuで監視システムを構築する． なぜSensuを選んだか? Sensuは急増するサーバ台数を考慮して設計されたフレームワークで，スケーラビリティが重要になってくるアーキテクチャに適している．また，以下の様な特徴を持っている． エージェント型の監視ツールなので監視対象のサーバにSensu clientをインストールすると監視対象になる．(運用者が一々設定を入れる必要がない) ややこしい設定ファイルの記述が要らない ChefやPuppetとの連係が考慮されている(CMツールとの相性が良い） ユーザビリティを考慮したWebUIがある 便利なプラグインが沢山ある APIが用意されているので独自拡張も容易 特に，先ほどから述べている通りエージェント型というメリットは大きく，運用も開発も行っている様な多忙なチームでサーバの追加時にChefのレシピを実行した瞬間からそのサーバが監視対象になるのは嬉しい．このように，自分に取って導入するに足るメリットがあり，従来のツールが使いにくいからという理由だけでSensuに興味を持っているわけではない．グダグタと長い説明になってしまった．．．それでは，Sensuのインストールを始めよう！ Sensuのインストール手順 この記事では，Chef client(knife solo)を使いSensuサーバの構築をする前提で話を進める．SensuはChefやPuppetなどのツールと組み合わせてインストールすることが公式に推奨されており，Chefのcookbook，Puppetのmanifestがそれぞれ用意されている．Chefを使ってインストールする場合はBerksfileにSensu(sensu-chef)を追加することで，include_recipeをしたrecipe内でSensuのLWRPが使用可能になる． #Berksfile source "https://supermarket.chef.io" cookbook 'sensu', '~> 2.6.0' cookbook 'uchiwa', '~> 1.0.0' この時Uchiwaのcookbookも一緒にインストールする．一昔前はsensu-dashboardというWeb GUIを要するレシピも存在していたが，既に非推奨になっており，代替手段を各々探す必要がある．APIがあるのでDashboardを自作しても良いが今回はUchiwaをインストールする． 次にknife cookbook create sensu-wrapper -o site-cookbooksで自作のwrapper cookbookを作成する．上述の通り，sensu-chefをrecipe内でincludeすることでsensuに必要なミドルウェアや設定に関するLWRPが利用に可能になる．作成したcookbookのrecipeはこんな感じ． include_recipe "sensu" include_recipe "sensu::redis" include_recipe "sensu::rabbitmq" sensu_handler "default" do type "pipe" command "ls" end sensu_client node.name do address node.ipaddress subscriptions node.roles + ["all"] end include_recipe "sensu::api_service" include_recipe "sensu::client_service" include_recipe "sensu::server_service" また，wrapperとなるrecipeのmetadata. https://blog.takanabe.tokyo/2015/03/%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E6%80%A7%E8%83%BD%E3%82%92%E6%9C%80%E5%A4%A7%E9%99%90%E3%81%AB%E5%BC%95%E3%81%8D%E5%87%BA%E3%81%99%E3%81%9F%E3%82%81%E3%81%AB%E3%81%99%E3%81%B9%E3%81%8D%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E7%AE%A1%E7%90%86%E3%81%A8%E3%83%9C%E3%83%88%E3%83%AB%E3%83%8D%E3%83%83%E3%82%AF%E3%81%AE%E7%89%B9%E5%AE%9A/ Wed, 11 Mar 2015 12:32:43 +0000 https://blog.takanabe.tokyo/2015/03/%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E6%80%A7%E8%83%BD%E3%82%92%E6%9C%80%E5%A4%A7%E9%99%90%E3%81%AB%E5%BC%95%E3%81%8D%E5%87%BA%E3%81%99%E3%81%9F%E3%82%81%E3%81%AB%E3%81%99%E3%81%B9%E3%81%8D%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E7%AE%A1%E7%90%86%E3%81%A8%E3%83%9C%E3%83%88%E3%83%AB%E3%83%8D%E3%83%83%E3%82%AF%E3%81%AE%E7%89%B9%E5%AE%9A/ モチベーション Linuxサーバの性能を引き出すために使うリソース管理コマンドとボトルネックの特定方法まとめる 背景 以前，NginxとElasticsearchの性能試験をしたがその結果がなぜそのようになるかを筋道を立てて説明することができず，結局推測して終わりにしてしまった．このまま終了しても学びがなく次に同じようなことをした時に活かせないので改めてLinuxサーバリソースの管理方法を勉強しようとおもう． とても良い本に巡り会えた 性能試験についてもっと考えるべき点があると悶々と過ごしている中，自分なりに考えたり調査していた．同じようなことを先輩エンジニアの方々もやっているようで，サーバのリソース管理のツールや方法はWeb上にもかなりの量が転がっていることがわかったが，僕の知識不足のためにどれも納得できなかった．そんな時にこの本に出会った． [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) Author: 安井 真伸 Manufacturer: 技術評論社 Publish date: 2008-08-07 該当するページは4章の性能向上チューニングの部分だけだが，とても勉強になった．しょっぱなから推測するな，計測せよと胸に突き刺さるフレーズがあり自分にはピッタリだった．内容はそれほど目新しいものではないが，サーバの負荷，ボトルネックの特定方法が理路整然としており，なるほど確かにそうだ！と思わせてくれる．普段何気なく使っているvmstat,ps,sar,topなどのリソース監視系のコマンドの動作についても深いところまで触れている．以下ではボトルネックの特定手順を簡単にまとめようと思う． サーバにかかっている負荷を知る Linuxサーバの場合負荷をしるための情報はLinuxカーネルが持っている．良く使われるps,top,sarなどのコマンドはLinuxで管理されている情報を人の見やすい形に表示しているに過ぎない．負荷を知るということはカーネルの動作を理解するということに他ならない．これらのコマンドは多くの情報を一度に表示しているけど，ボトルネックの基本的な見極め方や負荷とは何なのかを理解していれば見る情報も限られてくる．ということで定石をまず覚えよう． ボトルネックの見極め方 ロードアベレージを確認する CPU,I/Oのどちらがボトルネックになっているのか確認する 1. ロードアベレージの確認方法 topもしくはuptimeコマンドのロードアベレージを確認する．ロードアベレージはシステム全体の負荷状況を示す値で，値が高ければ何らかの負荷がかかっていると言える．これだけでは何がボトルネックになっているかは特定できないけどはじめの取り掛かりに使える．また，ロードアベレージが低い時にサーバのパフォーマンスが悪い時は，リモートホストやネットワークなどの外的要因やミドルウェア，ソフトウェアの設定や不具合を疑うといい． vagrant@vagrant-ubuntu-trusty-64:~$ top top - 13:11:50 up 12:38, 2 users, load average: 0.23, 0.09, 0.07 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.3 us, 19.3 sy, 0.0 ni, 76. https://blog.takanabe.tokyo/2015/03/wrk%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9Fnginx%E3%81%A8elasticsearch%E3%81%AEcache%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E6%80%A7%E8%83%BD%E8%A9%A6%E9%A8%93/ Wed, 04 Mar 2015 23:34:03 +0000 https://blog.takanabe.tokyo/2015/03/wrk%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9Fnginx%E3%81%A8elasticsearch%E3%81%AEcache%E3%81%AB%E5%AF%BE%E3%81%99%E3%82%8B%E6%80%A7%E8%83%BD%E8%A9%A6%E9%A8%93/ モチベーション Elasticsearchへの大量のリクエストを捌ける仕組みとしてcacheを導入したい 記事概要 昨年頃からElasticsearchと呼ばれる全文検索エンジンが脚光を浴びており様々な企業で採用されてきている．話題になっている理由は幾つかあるが，その中にHTTPでやりとりすることができるRESTfulなインタフェースを持っていることが挙げられる．また，HTTPを話すことができるモダンなシステムなため，NginxなどのHTTPを話せるミドルウェアとの親和性が高いのも魅力的． そんなElasticsearchだが，検索エンジンとして使うとなるとそれなりの量のリクエストを捌く必要がある．試験的にスループット(リクエスト/秒)を向上させる仕組み検討しているのだが，ひとまず，フロントにリバースプロキシサーバを配置してコンテンツcacheを効かせようと考えている．しかし，実はElasticsearch単体でもcacheの機能を持っていることがわかった．そこで，NginxをフロントにおいたNginx + Elasticsearchな構成とElasticsearch単体の性能試験を行うことでどちらのcacheを採用するかの判断材料にしようと思う． 検証結果 結論から言うと、正しい検証結果が得られているとは言いがたい。良くない試験として後学の為に残していく。 環境 ベンチマークサーバ AWS EC2 OS：Amazon Linux AMI 2014.09.2 (HVM) Instance Type：m3.medium vCPU:1 cpu RAM :3.75 GB HDD :1 x 4 (SSD)GB NW Perfomance: Moderate ベンチマークサーバ1(Nginx + Elasticsearch)の設定 適切なところにElasticsearchへのリバースプロキシの設定を行う． ちなみにvCPUが1つなのでNginxのワーカもそれに対応して1つにしている． http{ proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=my-key:8m max_size=50m inactive=120m; server { server_name ec2-WW-XX-YY-ZZ-.ap-northeast-1.compute.amazonaws.com; location / { proxy_pass http://127.0.0.1:9200; proxy_cache my-key; proxy_cache_key $host$uri$is_args$args; proxy_cache_valid 1h; client_max_body_size 8M; add_header X-Cache-Status $upstream_cache_status; } } } また，Elasticsearchのcache機能はデフォルトで有効になっているためelasticsearch. https://blog.takanabe.tokyo/2014/12/github%E3%81%A7%E3%83%95%E3%82%A9%E3%83%BC%E3%82%AF%E3%81%97%E3%81%9F%E3%83%AC%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%8B%E3%82%89%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%92%E9%80%81%E3%82%8B%E3%81%BE%E3%81%A7%E3%81%AE%E6%B5%81%E3%82%8C/ Sun, 14 Dec 2014 14:40:24 +0000 https://blog.takanabe.tokyo/2014/12/github%E3%81%A7%E3%83%95%E3%82%A9%E3%83%BC%E3%82%AF%E3%81%97%E3%81%9F%E3%83%AC%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%81%8B%E3%82%89%E3%83%97%E3%83%AB%E3%83%AA%E3%82%AF%E3%82%92%E9%80%81%E3%82%8B%E3%81%BE%E3%81%A7%E3%81%AE%E6%B5%81%E3%82%8C/ モチベーション GithubでOSSを管理するレポジトリにプルリクを飛ばして変更をMergeされるまでの流れを残したい 背景 GithubでForkをしないプルリクを飛ばすことは良くあるが，Forkをした時のプルリクの飛ばし方がよくわかっていなかった．今回，homebrew-caskに新しいCaskを追加する機会があり，このタイプのプルリクを飛ばした．実際にやってみるとそれほど難しくなかったので，手順概要と具体的な手順を残しておく． 手順概要 Githubページでプルリク対象のレポジトリを自分のアカウントにForkする Forkしたレポジトリを自分のPCにCloneする Cloneしたレポジトリでブランチを切る Cloneしたレポジトリでファイルを変更する 変更内容をCommitをする(Commitログはrebaseして1つにまとめる) 自分のアカウントにCommitをPushする 自分のアカウントからFork元のレポジトリに対してプルリクを飛ばす プルリク内容の変更依頼に対応する 作成者にプルリクをMergeしてもらう 例) homebrew-caskに新しいCaskを追加する homebrew-caskはhomebrewを拡張して，アプリケーションのインストールや管理する機能を提供する．インストールできるアプリケーションはCaskとして管理されており，`brew cask install cask名｀でインストールできる．普段使っているアプリケーションのCaskがない場合は自分でCaskを作成して，開発元に提供することもできる(エコシステムになっている)．今回ファイル名を一括変換できるShupapanというアプリケーションのCaskがなかったので，自分で作成し，プルリクを送ったのでその手順を見てみよう． 1. homebrew-caskを自分のGithubアカウントにForkする まずはGithubにログインして，hombebrew-caskの本家のレポジトリを自分のアカウントにForkをする．Forkはボタンをクリックするだけで簡単にできる． 2. PCにForkしたレポジトリをCloneする 自分のアカウントにForkしたレポジトリをPC(開発環境)にCloneする． ➤ git clone git@github.com:takanabe/homebrew-cask.git 3. Cloneしたレポジトリでブランチを切る masterブランチで開発を進めるのではなく，開発用のブランチを新たに作成する． ➤ cd homebrew-cask ➤ git checkout -b add_shupapan 4. ファイルを変更する Caskにshupapan.rbを追加する．Caskの作り方はhomebrew-caskのREAEMEや他のサイトを参考にした． 5. 変更内容ををCommitする ➤ git add -A ➤ git commit -m "Add Shupapan" 6. Commit内容をpushする ➤ git push 7. https://blog.takanabe.tokyo/2014/12/git%E5%85%A5%E9%96%80git%E5%88%9D%E5%AD%A6%E7%BF%92%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%8A%B9%E7%8E%87%E7%9A%84%E3%81%AA%E5%AD%A6%E7%BF%92%E6%96%B9%E6%B3%95%E3%82%92%E8%80%83%E3%81%88%E3%81%A6%E3%81%BF%E3%81%9F/ Fri, 12 Dec 2014 23:00:00 +0000 https://blog.takanabe.tokyo/2014/12/git%E5%85%A5%E9%96%80git%E5%88%9D%E5%AD%A6%E7%BF%92%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%8A%B9%E7%8E%87%E7%9A%84%E3%81%AA%E5%AD%A6%E7%BF%92%E6%96%B9%E6%B3%95%E3%82%92%E8%80%83%E3%81%88%E3%81%A6%E3%81%BF%E3%81%9F/ 本記事は，Git Advent Calendar 2014の13日目に投稿させて頂いた記事です．Gitの使い方がわからない人向けの記事です。 モチベーション 自分を成長させながらいかに効率的に技術を伝承するかが自分の中で課題になっており模索中なこの頃．試しに，社内でGitを使ったことのないエンジニアに1週間(合計7時間)で開発に必要なGitの知識を講義したので，その時に使用した教材や効率的な学習方法を初心者向けに共有する． 背景 一昔前はイケてるエンジニアはGitを使ってプログラムを管理してるみたいな感じだったが，今となってはGitはエンジニアにとって必要不可欠なツールになった．Gitがあるからコードの2重管理はなくなり，Gitがあるから継続的インテグレーションや継続的デリバリーが活きる，Gitがあるから変更に対してコメントを残せる．Gitが無いと開発が成り立たなくなって来ているのだ．特に，Githubのヒット以降，その流れは加速している．一方で，Gitを当たり前のように使いこなしている人がいる中で，そもそも使ったことがなかったり，SVNを使っていたためGitに乗り換えあぐねている技術者もいるだろう．僕の周りもそういう人が多く，チームの半分以上がGit未経験者だった．幸い彼らは学習意欲が高く，一週間お昼の時間に使い方を教えただけでGitの概念を理解し開発に足る知識を身に付けた．少しの時間を割くだけでチームの開発力は飛躍的に向上したと思う．せっかくなので，その時に考えた負担をかけずに効率的に勉強できる方法とそれをサポートする教材をGit初学習者に届けたいと思う． 効率的なGitの学習ステップ 習うより慣れろ！開発の現場に叩き込んでGitを使わせたほうが良い．エンジニアたるもの教わるのではなく，自分で学べという人もいるだろう．僕もその意見には概ね同意だが，経験や教え方次第でその後の勉強効率やチームの生産性がガラッと変わるものに関しては経験者が教える価値はあると考えている．Gitはまさにその類のツールで少しのポイントと少しのコマンドを覚えるだけですぐに使えるようになる(簡単だから世の中で普及しているのだ)．今回お届けする学習方法は以下の通りだ． ステップ1：Gitの概念がわかる資料を読む ステップ2：Gitの簡単な使い方を説明した資料を読む ステップ3：Gitの操作パターンを学べる問題集を解く ステップ4：Gitを使った実践的な開発をする 何の変哲もない当たり前のことを書かせてもらった．当たり前だからかどのように勉強するべきかを言及している書籍やサイトは少ない．それらの多くはコマンドの使い方や概念を説明するのに徹しており，網羅性は高い．しかし，初学習者にそこまで教える必要があるのか？というくらい基礎から応用まで膨大な情報が書かれている．また，まとめサイトなどが散見されるがそもそも初学習者はまとめサイトに挙げられているどのサイトを読めばいいのかがわからない．途中で躓かないように，それぞれのステップで必要な情報をだけ与えるのが効率の良い学習方法だと思う． じゃあ，何を使って勉強すればいいのか？ 勉強方法は人それぞれ好みがあるので好みから外れてしまった場合は申し訳ないが，Git初心者に対してどのような書籍やドキュメントを読めばよいか各ステップでピックアップさせて頂いた．勉強教材を探す時間も惜しいので，初学習者は何も考えずに以下で推薦する資料を使って勉強して欲しい．(サイトや書籍内にあるリンクも無視して黙々とピックアップした資料を読むのがオススメ．また，提示した順番に読んで頂いた方が学習効果は高い．) 学習に必要な時間：平均15時間 本記事で提案する学習ステップをこなすに必要な学習時間は，10時間〜20時間だと見積もっている．バラつきがあるのは理解力の違いとステップ3.5をこなすかを加味した結果だ．これを少ないと見るか多いと見るかは個々人で判断して頂きたい． ステップ1：Gitの概念がわかる資料を読む(所要時間：1hour) はじめのステップはまずGitがなぜ流行っているのか，どれだけ便利なのか，その破壊力を感じ取れる資料を読むのが良い．そこで便利そうだと感じていただければ以降の学習も苦にせず進めるだろう．逆に良くわからなくても，めげずに次のステップに進んでもらいたい．そんなこんなで以下の2つを推薦させてもらう． イラストでわかる！git入門の入門 Git、いつやるか？・・・今でしょ！ #git 追記2015.3.3 概念理解にちょうど良いmatsukazさんの動画を見つけたのでそちらを追記させて頂きます． ちょっと長いですが，非常にわかりやすいです． Vimeo:いつやるの？Git入門 ステップ2：Gitの簡単な使い方を説明した資料を読む(所要時間：8hour) ステップ1でなんとなくGitの雰囲気を掴んでもらえたと思う．ステップ2ではいきなり手を動かしながらGitの使い方を勉強して頂きたい．ここで，GitをサポートするGUIツールは沢山あるが，はじめは概念やコマンドを理解する意味でCUIでGitを学習するという前提で紹介させて頂いた．利用するコンテンツは以下の通りだ． Gitを初めからていねいに サルでもわかるGit入門 入門編 発展編 1つ目に挙げたGitを初めからていねいにはshinpei maruyamaさんが作られた物に僕が少しアレンジを加えたものになっている．Gitの全体の話から，実際手を動かしてGitの使い方を学べる素晴らしい教材だ．Git初心者に紹介すると好評だったので．初学習者にはとりあえずこのドキュメントを2周して欲しい．1周目でGitがどんなツールなのかを体験できるだろう．2周目は自分で空でコマンドを打てるようになってほしい．そして，覚えていないコマンドはメモって欲しい(全部メモっても使うコマンドが少ないことに気づくだろう)．また，教材の5章からHEADという単語が出てくるが，Gitを使いこなす上で非常に重要な概念なので是非覚え頂きたい． Gitを初めからていねいにが終わったら，次はサルでもわかるGit入門を読んで欲しい．この教材は少しGitを勉強した人の復習や，より深い理解の補強には向いているが全くGitを知らない初学習者にはおすすめしない．僕はサル以下だったので学生時代これを読んでもあまり使えるようにはなれなかった，だから，まずはGitを初めからていねいにを通読した上で読んで欲しい．きっと，次のステップに進む助けになるだろう．また，このサイトはePub形式の電子書籍も無料で公開しているのでそちらをダウンロードして読めるので嬉しい． ステップ3：Gitの操作パターンを学べる問題集を解く(所要時間：2hour) ステップ2でGitの簡単な使い方を学んだ後は，ステップ3では開発で使うであろうGitの利用パターンを問題集を使って繰り返し解いてもらう．無料で使える教材を探したが有名なものは見つけられなかった．強いて言えば，Learning Git Branchingというサイトがブランチの使い方の学習に役立ちそうだ．しかし，繰り返し解くには使いづらいし，最低限のことを覚えてもらうのに焦点を置きたいので，問題集は僕が用意した．特に4章は，初学習者が苦手とするであろうブランチの様々な使い方を学べるように構成したので繰り返し解いて頂きたい． Git quiz Git quizを見ていただくと問題が少ないのに気づくだろう．開発に入る前に必要な最低限の作法はそれだけ少ない．応用的な使い方や~ flowのような開発方針はチームで異なるのでその辺りはチームでメンバーに教えてもらうと良い．ステップ2でも述べたが，Gitを使いこなす上でHEADの概念を理解するのは非常に重要なので，それぞれの問題であるべきHEADの位置を図示させて頂いた．まだ，基本的な使い方をマスターする問題しかないけど，好評だったら応用編も作ろうと検討中． ステップ3.5: リモートレポジトリの管理にGithubを使いたい場合(所要時間：3hour) リモートレポジトリの管理はGithubやBitbucketなどのレポジトリホスティングサービスを利用するケースががほとんである．もし，Githubの使い方を学びたいなら以下の本をおすすめする． GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) この本は実践的なGithubの使い方がまとめられている書籍で非常に評価も高い．色々書籍を読んで見たが，もし，Githubの使い方を学びたいのであればこの本が一番だと思う． https://blog.takanabe.tokyo/2014/12/%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%81%AE%E5%91%A8%E8%BE%BA%E7%9F%A5%E8%AD%98%E3%81%BE%E3%81%A8%E3%82%81/ Fri, 05 Dec 2014 13:08:21 +0000 https://blog.takanabe.tokyo/2014/12/%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E7%AE%A1%E7%90%86%E3%81%AE%E5%91%A8%E8%BE%BA%E7%9F%A5%E8%AD%98%E3%81%BE%E3%81%A8%E3%82%81/ モチベーション 今更だけど，Webにおけるクッキー，セッション，セッション管理の意味を明確に説明できるようにしたい． 背景 Google先生に”クッキー　セッション 違い”と尋ねたことがある人は多いのではないだろうか？多分に漏れず僕もその一人である．検索結果からは沢山，クッキーとセッションについて説明しているサイトが引っかかるのはいいのだが，皆説明が異なる．要するにわかりにくいものなんだと思う．これは，英語で”session cookie difference”と検索しても大量にひっかかるので世界共通のようだ．ということで，今回自分なりにWebにおけるクッキー，セッション，セッション管理を理解し，なぜ混乱しやすいのかをまとめたいと思う． HTTPはステートレスなプトロコル HTTPはステートレスなプロトコルであり，状態は持たない．クライアントがリクエストを投げてサーバがレスポンスを返す，このキャッチボールを1往復したところで通信は切れる．つまり，一度目の通信でクライアントから某かの情報を受け取ったとしても，二度目の通信は前の通信の状態はは引き継がない全く関係のない通信になる．これが，HTTPの通信の原則である． 一方，前の通信の状態がわからないと不都合なケースも有る．Amazonでショッピングをするのを例に考えてみよう．Amazonを利用するユーザは商品の検索，選択，購入を行う．これらのアクションはサーバから見るとクライアントからの異なるリクエストである．先ほど説明した通りHTTPはステートレスなプロトコルなので，本来は商品を選択する通信が終了した後，商品の購入のリクエストをサーバに投げても選択した商品の情報は保持しておらず，ユーザが商品を購入できないことになってしまう．しかし，現実は，ご存知の通り，選択した商品はそのまま購入できる．これはWebアプリケーションの開発者が複数のHTTP通信をステートフルな通信に見せかけるような実装をしているからである． クッキーとセッション HTTPをステートフルな通信に見せかける方法は大きく分けて2種類あり，1つはクッキーを利用する方法，もう一つはセッションを利用する方法である．(ステートレスだとか，ステートフルだとか良く説明に使われるが，平たく言えば，サーバが通信記録のあるクライアントを判別したいケースがWebアプリケーションではしばしば起こる．それを実現するために有るのがクッキーとセッションだ．）それぞれについて説明していこう． クッキー(Cookie) A cookie, also known as an HTTP cookie, web cookie, Internet cookie, or browser cookie, is a small piece of data sent from a website and stored in a user’s web browser while the user is browsing that website. Every time the user loads the website, the browser sends the cookie back to the server to notify the website of the user’s previous activity. https://blog.takanabe.tokyo/2014/11/rails4-dbmigrate%E3%81%A7id%E4%BB%A5%E5%A4%96%E3%81%AE%E3%82%AB%E3%83%A9%E3%83%A0%E3%81%AB%E3%83%97%E3%83%A9%E3%82%A4%E3%83%9E%E3%83%AA%E3%82%AD%E3%83%BC%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%82%92%E8%A1%8C%E3%81%86/ Sun, 30 Nov 2014 04:50:00 +0000 https://blog.takanabe.tokyo/2014/11/rails4-dbmigrate%E3%81%A7id%E4%BB%A5%E5%A4%96%E3%81%AE%E3%82%AB%E3%83%A9%E3%83%A0%E3%81%AB%E3%83%97%E3%83%A9%E3%82%A4%E3%83%9E%E3%83%AA%E3%82%AD%E3%83%BC%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%82%92%E8%A1%8C%E3%81%86/ モチベーション Railsでテーブルのidカラム以外にプライマリキーを設定したい。インターネットに転がっている情報で色々やってみたが上手く行かなったので自分なりに調べてまとめる。 背景 Railsはその設計からidをテーブルのプライマリキーに自動的に設定してくれる。しかし、時にはid以外のカラムにプライマリキーの設定をしたい場合もあるだろう。公式ドキュメントやブログ情報によると、そういう時はオプションを指定することで任意のカラムにプライマリキーの設定が可能とのこと。 当初は下に挙げたドキュメントやブログを参考にテーブルのプライマリキーを設定しようとした。しかし、idが自動でプライマリキーに設定されることはなくなったが、 肝心の任意のキーをプライマリキーにするという要件を満たせなかった。 Ruby on Rails 4.1.8 RailsGuides Active Record Basics 「ActiveRecord」の基本とデータの参照 Railsで規約に沿わない古いデータを扱う Ruby on Rails - ActiveRecord で規約外のプライマリキーを使用する方法！ どうやら、公式ドキュメント通りだと思った通りの動作をしないようだ。公式ドキュメントが信頼出来ないとなると、どのように記述すればこちらの希望する処理になるかはフレームワークのコードを読まないとわからない。そうなると、フレームワークの意味が無いのだが・・・ただ、これだけ世で使われているフレームワークなので自分の勘違いの可能性もある。動作検証の結果と追加調査をを以下にまとめる。 検証してみた 環境 MacOSX 10.9.4 Ruby 2.1.2 Ruby on Rails 4.18 作りたいテーブル MySQLで以下のクエリを実行した時に作成されるテーブルと同様のものをrake db:migrateで作成する。 CREATE TABLE books( book_id INTEGER NOT NULL, title VARCHAR(250) NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, PRIMARY KEY(book_id) ); 通常の手順で作成したスキーマの確認 まずは、何も考えずに普通の手順で作成したテーブルスキーマを確認する。 手順は以下のとおり。 $ rails new book -d mysql $ rails g model book book_id:integer title:string $ rake db:create $ rake db:migrate 作成されたテーブルのスキーマは以下の通り。 https://blog.takanabe.tokyo/2014/11/mysql%E3%81%AE%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E5%BD%B9%E5%89%B2/ Sat, 29 Nov 2014 18:04:08 +0000 https://blog.takanabe.tokyo/2014/11/mysql%E3%81%AE%E3%82%A4%E3%83%B3%E3%83%87%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E5%BD%B9%E5%89%B2/ モチベーション MySQLの基本的な使い方はわかっているがインデックスの役割が曖昧だったので今一度整理する。 記事概要 MySQLに詳しい人は”インデックスを設定しろ！検索が早くなるから！”と言う。一方、自分はSQLでDBの簡単な操作はできるけど、インデックスに関しては”ふーん、インデックスを使うと早くなるのね。”程度の理解。しかし、DBの設計をするならインデックスの理解は必要不可欠である。そこで、DB、特にMySQLにおけるインデックスの役割となぜ検索が早くなるのかを計算量の観点から整理する。 MySQLのクエリに対する応答 MySQLのインデックスを理解するには、MySQLのクエリに対する応答をまず知らなくてはならない。 1つ例を挙げてみよう。今、Twitterのようなアプリを作成しており、ユーザ情報を格納するusers、全ユーザのtweet情報を格納するtweetsテーブルを以下のクエリで作成したとする。 CREATE TABLE twitter_modoki.users (id integer, name varchar(250), ); CREATE TABLE twitter_modoki.tweets (tweet_id integer, uid integer, content varchar(250), ); この時、ユーザTaroのtweetを全て取得するには、Taroが持つusers.idをキーとしてtweetsテーブルから該当するレコードを全て抽出すれば良い。tweetsテーブルのuidがTaroのレコードを全て抽出するクエリは以下のようになる。 SELECT content FROM tweets WHERE uid = 'Taroのusers.id' 上記、クエリを実行した時のMySQLの応答は, tweetsテーブル内の全てのレコードを読み込む uidフィールドを調査し、文字列’Taroのusers.id’と一致するか比較する となるが、これだとtweetsテーブルのレコードの数が増加するにつれて抜き出したいレコードの探索時間が増加する。この探索の計算量はtweetsテーブルにあるレコード数を*n*とした場合、*O(n)*となる(=線形探索の計算量)。 インデックスを設定した場合の計算量 それでは本題のインデックスの説明に入ろう。 インデックスはもともと、索引や見出しの意味を持つ。”データベース”という単語を国語辞典で引くときに、1ページ目から順に”データベース”という単語を調べる人はいないだろう。”て”の索引がついたページから”データベース”のページを探すのか普通だ。 DBでも同様に探索時間を効率的にするためのインデックスをつけることができる。 Twitterの場合、ユーザ情報をまとめたusersテーブルとユーザのtweetをまとめたtweetsテーブルが有り、ユーザ”Taro”のtweetをtweetテーブルから抽出するとき、普通にクエリを投げると全ユーザのtweetレコードに比例した探索時間が必要になることは既に説明した。 この時、以下のようにtweetテーブルのuidをインデックスとして設定すれば、Taroのusers.idとtweets.uid一致するレコードのみ探索することができる。 CREATE TABLE twitter_modoki.users (id integer, name varchar(250), ); CREATE TABLE twitter_modoki.tweets (tweet_id integer, uid integer, conent varchar(250), INDEX (uid) ); MySQLのインデックスはB-Treeと呼ばれるデータ構造で実現されている。そのため、Taroのtweetを抽出するために必要な探索時間は*O(log n)*になる。 https://blog.takanabe.tokyo/2014/10/mac%E3%81%ABqt%E7%89%88wireshark%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B/ Wed, 15 Oct 2014 15:32:13 +0000 https://blog.takanabe.tokyo/2014/10/mac%E3%81%ABqt%E7%89%88wireshark%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B/ モチベーション Macで動作が安定したWiresharkwを使いたい 背景 以前からXを使ったWiresharkをMacで使っていたが，僕のインストールの仕方が悪いのか起動が遅かったり，突然落ちたりと不安定だった．不便だと感じていたので，調べてみるとQtを使ったWiresharkがHomebrewで員ストールできるようなのでインストールしてみる． 環境 OS: MacOSX Marvericks 既存のWiresharkをアンインストールする やり方はWiresharkのアンインストール方法（Mac OS X）に則っておこなった． 注意点としては，通常のMacのアプリケーションアンインストール(Applicationディレクトリからゴミ箱にWiresharkを突っ込む方法)ではwiresharkへのシンボリックリンクが残ってしまうのでそれらはコマンドで消すこと. # wiresharkのアプリをけす Applcationディレクトリからゴミ箱にアプリを移動する # Wiresharkアプリを消しただけで消えないデータを削除する sudo dscl . -delete /Groups/access_bpf sudo rm -rf /Library/StartupItems/ChmodBPF sudo rm -rf ~/Library/Saved Application State/org.wireshark.Wireshark.savedState/ sudo rm ~/Library/Preferences/org.wireshark.Wireshark.plist # シンボリックリンクを消す sudo rm -rf /usr/local/bin/wireshark sudo rm -rf /usr/local/bin/capinfos sudo rm -rf /usr/local/bin/dftest sudo rm -rf /usr/local/bin/dumpcap sudo rm -rf /usr/local/bin/editcap sudo rm -rf /usr/local/bin/mergecap sudo rm -rf /usr/local/bin/randpkt sudo rm -rf /usr/local/bin/rawshark sudo rm -rf /usr/local/bin/text2pcap sudo rm -rf /usr/local/bin/tshark Wiresharkをインストールする brew install qt brew install wireshark --with-qt 基本的にはこれでOK. https://blog.takanabe.tokyo/2014/08/elasticsearch-kibana-fluentd%E3%81%A7%E3%83%AD%E3%82%B0%E8%A7%A3%E6%9E%90%E3%82%92%E8%A1%8C%E3%81%86%E5%89%8D%E3%81%AE%E4%B8%8B%E8%AA%BF%E3%81%B9/ Tue, 05 Aug 2014 16:01:22 +0000 https://blog.takanabe.tokyo/2014/08/elasticsearch-kibana-fluentd%E3%81%A7%E3%83%AD%E3%82%B0%E8%A7%A3%E6%9E%90%E3%82%92%E8%A1%8C%E3%81%86%E5%89%8D%E3%81%AE%E4%B8%8B%E8%AA%BF%E3%81%B9/ モチベーション ログ収集サーバ，解析サーバを構築して自分で管理しているサーバのログ解析を行いたい． 背景 個人で運用しているサーバをLXCを使って整理することにした．これまでおざなりにしていたログの収集・解析をFluentd + Elasticsearch + Kibanaで実施したいので，これらのシステムをLXC環境で構築するために必要な知識を習得する． 監視予定のログ nginxのアクセスログ 他未定 Fluentd / Elasticsearch / Kibanaとは サーバのセキュリティ対策や安定運用のために日々のログ監視は重要である．しかし，サーバの台数が増えるとそれぞれのサーバに入りログを確認するというのは現実的に無理がある(1台でも無理か・・・？)．そこで，普通はログを収集する仕組みを作り，溜め込んだログを何らかの方法で監視するのが一般的だ．Fluentd,Elasticsearch,Kibanaはこれらの一連の流れにおいて以下の役割を担う． Fluentd: 各サーバのログを収集する Elasticsearch: Fluentdで収集したログを解析する(検索エンジン) Kibana: Elasticsearchで解析したログをWebポータルで可視化する つまり，Fluentd + Elasticsearch + Kibanaを利用すれば，ログ収集→ログ解析→ログ可視化が簡単に実現できる． ログ分析になぜElasticsearchを使うのか？ 結論から述べると，全文検索を行う検索エンジンだからである．そもそも．僕の場合は収集するログがどんな特徴を持っているのか，どのログを収集すれば良いのかもあまりわかっていないため，全てのログ情報を良い感じに検索出来たり，解析してくれるロジックを導入したい．そんな願いを叶えてくれるのが全文検索と呼ばれる仕組みで，Elasticsearchはこの仕組みを採用している．全文検索エンジンの対抗馬としてApache Slor(ソーラ)が挙げられるが，SolrとElasticsearchを比べてみようによると， ElasticsearchはRESTによる操作が可能 SolrもElasticsearchもLucene(ルシーン)ベースで検索観点で大きく異なる部分は少ない 分析とか、集計情報を扱いたければElasticsearch RESTで操作可能な点，分析で有利な点からElasticsearchの方が良さそうだった．また，関わっているPJでElasticSearchを使っているケースが多いためこれを使うことにした．全文検索やElasticSearchの詳細については別記事で紹介しようと思う． ログ収集になぜFluentdを使うのか？ Elasticsearch社が提供しているログ収集ツールにLogstashというものがあるがfluentdの方がログの取りこぼしをしにくいなどの特徴から利用されているケースが多いようだ．また，fluentdは以下の特徴を持つ． 時系列，ストリーム系のデータを処理するのが得意 tagベースのルーティング 非構造化されたデータをJSONフォーマットに落とし込める fluentdを拡張するプラグインはRubyで開発できる Flumeは導入難易度が高い(Hadoopとは連携しやすい) 今回収集するログはまさに，ストリームの系の非構造のデータなので，fluentdで処理するにはうってつけである．1次格納先としてMongoDBにfluentdで収集したデータを格納しても良いが，プラグインを使うと直接Elasticsearchにデータを保存できる．今回はMongoDBのを別途管理したくないので，プラグインを利用して直接保存する． UIになぜKibanaを使うのか？ ここまでFluentdとElasticsearchの使用理由をそれなりに書いてきたが，Kibanaについては特に理由は無い．Elasticsearchとの組み合わせで実績があるものを採用した． LXC環境への導入イメージ リバースプロキシをかませる予定なので，そのリバースプロキシのアクセスログ収集が主な目的になるが一応，wiki,blog,kibanaのサーバでfluendエージェントを仕込んでおく． ログ解析環境に関しては破壊してもあまり被害は無いので将来的には違う構成にするかも知れない．とりあえず，LXC環境を構築したら導入しよう． 参考 Elasticsearch + Kibana + Fluentdでのログ収集解析関連 fluentd + MongoDB + Elasticsearch + Kibanaでログを可視化する 今日から始めるfluentd × Elasticsearch × kibana – カジュアルな解析・高速化 fluentdでnginxのログをElasticsearchとBigQueryに保存するお話 Elasticseach(検索エンジン) ElasticSeach チュートリアル Elasticsearch入門 新卒エンジニア研修で「Elasticsearch の歩き方」について話した 実践！Elasticsearch 全文検索システムの比較 - Elasticsearch vs Solr vs Amazon CloudSearch 検索業界の知識 & Lucene(検索ライブラリ) 検索エンジンの常識をApache Solrで身につける (1⁄4) Luceneソースコードリーディングの準備その１ Fluentd(ログ収集) Big Data入門に見せかけたFluentd入門 Fluentdが流行る理由がいま分かる、10の実践逆引きユースケース集 柔軟なログ収集を可能にする「fluentd」入門 fluentd vs Logstash Fluentd vs Logstash https://blog.takanabe.tokyo/2014/06/openstack-security-group%E3%81%A8l3-agent%E3%81%AE%E6%8C%99%E5%8B%95%E3%81%A7%E3%83%8F%E3%83%9E%E3%81%A3%E3%81%A6%E3%81%84%E3%81%9F/ Mon, 23 Jun 2014 08:57:17 +0000 https://blog.takanabe.tokyo/2014/06/openstack-security-group%E3%81%A8l3-agent%E3%81%AE%E6%8C%99%E5%8B%95%E3%81%A7%E3%83%8F%E3%83%9E%E3%81%A3%E3%81%A6%E3%81%84%E3%81%9F/ OpenStack memo Security Groupの設定 Floating IPを利用した通信ができないのでNeutronのモードをGREにしたり、VLANにしたりと色々試行錯誤していたらやっと原因がわかった。*Security Group*の設定が間違っていた。まさかFirewallの設定なんて基本的なところで引っかかっているとは。 OpenvSwtichの構成（VLANモード） 通常OpenvSwitchでVLANを設定するとポートにtag:VLANIDのようにタグが着くのだが、 OpenStackではどうやらovsから通信が出て行く瞬間にOpen Flowの仕組みでタグが付けられるようだ。故に、構築しているNW下記のようなovs構成をしている。 Bridge br-int Port "tapb5a5e7c4-9d" tag: 4095 Interface "tapb5a5e7c4-9d" type: internal Port "qvo7f7c766f-02" tag: 5 Interface "qvo7f7c766f-02" Port br-int Interface br-int type: internal Port "int-br-bond0" Interface "int-br-bond0" Port "qr-de5001b3-30" tag: 5 Interface "qr-de5001b3-30" type: internal Bridge br-ex Port "patch-bond0" Interface "patch-bond0" type: patch options: {peer=patch-ex} Port "qg-35b87733-90" Interface "qg-35b87733-90" type: internal Port br-ex Interface br-ex type: internal Bridge "br-bond0" Port patch-ex tag: 201 Interface patch-ex type: patch options: {peer="patch-bond0"} Port "phy-br-bond0" Interface "phy-br-bond0" Port "bond0" Interface "p1p2" Interface "p1p1" Port "br-bond0" Interface "br-bond0" type: internal ovs_version: "2. https://blog.takanabe.tokyo/2014/06/plaid-ctf-2013-web-charsheet%E3%82%92%E8%A7%A3%E3%81%84%E3%81%A6%E3%81%BF%E3%81%9F/ Sat, 21 Jun 2014 17:22:08 +0000 https://blog.takanabe.tokyo/2014/06/plaid-ctf-2013-web-charsheet%E3%82%92%E8%A7%A3%E3%81%84%E3%81%A6%E3%81%BF%E3%81%9F/ モチベーション 試しに1問CTFの問題を解いてみたい 記事概要 CTFについて調べたついでにPlaid CTF 2013のWeb系の問題を1問解いたので記録として残す。 解放メモ search.phpにアクセスすると以下の様な画面が表示される。 ①キャラクター検索フォームにてSQLiを実行 下記のSQLがサーバサイドで実行されていることがわかる。 また、ERRORの結果からLIKEの直後の％（ワイルドカード）部分に検索フォームに入れた値が入力されることがわかる。 SELECT c.id, c.name, DATE_FORMAT(c.lastedited, ‘%d %M %Y @ %H:%i’) as lastedited, c.owner, st.name as tname, ca.name as caname FROM sheet_templates st, characters c LEFT JOIN campaign ca on ca.id = c.campaign WHERE c.public = ‘y’ AND c.template_id = st.id AND UPPER(c.name) LIKE (‘%’) ORDER BY UPPER(c.name), UPPER(c.name) LIMIT 15 ②コメントアウト付きのSQL文を入力フォームに挿入 ') OR 1 = 1 -- https://blog.takanabe.tokyo/2014/06/plaid-ctf-2013-write-up-%E3%81%BE%E3%81%A8%E3%82%81/ Sat, 21 Jun 2014 16:59:16 +0000 https://blog.takanabe.tokyo/2014/06/plaid-ctf-2013-write-up-%E3%81%BE%E3%81%A8%E3%82%81/ モチベーション CTFって何？シリーズのつづき。CTF業界界隈では問題を解いてWebで晒すことを”Write up”というらしい。Plaid CTF 2013を調べているうちにそんなWrite upたちが沢山見つかったのでまとめて載せておく。 Write UP Collection Site pwn3r tistory :: Plaid CTF 2013 Write up collection - Challenges Challenges Write-up Pwnable ---------------------------------------------------- pork - http://pastie.org/7693773 - http://pwn3r.tistory.com/entry/Plaid-CTF-2013-pork - http://bases-hacking.org/pork-pctf2013.html - http://www.bases-hacking.org/pork-pctf2013.html ropsaurusrex - http://hackerschool.org/temp/pctf2013/ropasaurusrex_exp.py - http://codezen.fr/2013/04/22/plaidctf-2013-pwnable-200-ropasaurusrex-write-up/ - http://pastie.org/7693791 - http://bases-hacking.org/ropasaurusrex-pctf2013.html - http://www.bases-hacking.org/ropasaurusrex-pctf2013.html dynrpn - http://eindbazen.net/2013/04/pctf-2013-dynrpn-pwnable-250/ - http://pwnies.dk/post/dynrpn-plaidctf-2013/ bunyans_revenge - http://www.blue-lotus.net/plaidctf-2013-bunyans_revenge-writeup/ ---------------------------------------------------- Binary ---------------------------------------------------- three eyed fish - http://broot.ca/blog/plaidctf-three-eyed-fish-binary-100 - http://f00l.de/blog/?p=1781 cone - http://pastie. https://blog.takanabe.tokyo/2014/06/ctf%E3%81%A3%E3%81%A6%E4%BD%95/ Fri, 20 Jun 2014 15:53:37 +0000 https://blog.takanabe.tokyo/2014/06/ctf%E3%81%A3%E3%81%A6%E4%BD%95/ モチベーション 先日DEFCON予選に参加したがかなり難しかった。周りの人が熱を入れて参加しているので面白半分ついて行った感じ。そもそも、自分はCTFが何なのか理解していなかったりする。この機会に、CTFとはなんぞやを調べた。 そもそもCTFとは？ CTFとはCaputure the Flagの略でセキュリティの技術を競うコンテストの総称。冒頭で述べたDEFCONはこのCTFの大会で最も有名な大会で年に1度ラスベガスで行われるハッカーの祭典のこと。 CTFで出題される問題系統は？（随時更新） CTFの問題は各大会によって微妙に異なるようだ。以下、有名な大会と問題について記載する。 DEFCON 2011予選 Grab Bag:なんでもありのまぜこぜ Retro Revisited:過去問のアレンジ Binary L33tness:バイナリ解析問題 Pwtent Pwnable:リモートexploit Forensics:フォレンジック問題。 DEFCON 2012予選 Grab bag /urandom binary l33tness pwnables Forensics DEFCON 2013予選 3dub,web-base challenges:wwwのこと。Web系の問題 0x41414141:exploit問題。ASCII文字のAAAA \xff\xe4\xcc:shellcode問題。oh my god ACM gnireenigne:reverse engineering問題。右から左に読んでengineering DEFCON 2014予選(この年から問題作成チームが変わりすべての問題でバイナリの知識が必要になった。) Baby’s First:(初心者用問題　※超難しかった) 3dtt:プログラムでアルゴリズムを考えゲームを解く系 hackertool: heap: routarded: Duchess: Gynophage: HJ: Jymbolia: Lightning: Selir: Sirgoon: Vito Genovese: https://blog.takanabe.tokyo/2014/05/docker-pipework%E3%82%92%E3%81%A4%E3%81%8B%E3%81%A3%E3%81%A6%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AB%E5%9B%BA%E5%AE%9Aip%E3%82%92%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%82%8B/ Thu, 29 May 2014 15:42:15 +0000 https://blog.takanabe.tokyo/2014/05/docker-pipework%E3%82%92%E3%81%A4%E3%81%8B%E3%81%A3%E3%81%A6%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AB%E5%9B%BA%E5%AE%9Aip%E3%82%92%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%82%8B/ モチベーション Dockerのインターフェースに固定ipを振りたい 背景 現状，Dockerでコンテナを起動するとそれぞれのコンテナにeth0が追加される．その際に振られるipはDockerが勝手に割り振ってしまうためにコンテナに固定ipでアクセスしたいときは不便である．自分でbtctlをつかってブリッジや仮想インターフェースを作っても良いが，Pipeworkというツールを使うと簡単にDockerに固定をipを振れるようなので使ってみる． 環境 OS:Ubuntu 14.04 Pipeworkのインストール Dockerがインストールされ,コンテナが既にあるubuntuマシンにて以下を実行 $ sudo -s $ git clone https://github.com/jpetazzo/pipework.git $ apt-get install -y bridge-utils $ apt-get install -y arping コンテナにNICを追加する コンテナIDを調べ，NICを追加したいコンテナを起動し，NICを追加する. $ docker ps -a $ docker start 9bc312779a79 $ ./pipework br1 9bc312779a79 192.168.10.5/24 (コンテナに振りたいip) この時br1という名前のブリッジが自動的に生成されるが，br1のipは自分で振る必要がある． $ ip addr add 192.168.10.254/24 dev br1 $ ip addr show br1 22: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 3e:1c:29:d7:b7:04 brd ff:ff:ff:ff:ff:ff inet 192. https://blog.takanabe.tokyo/2014/05/lxc%E3%81%AE%E3%82%8F%E3%81%8B%E3%82%8A%E3%81%AB%E3%81%8F%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AE%E3%83%A1%E3%83%A2/ Thu, 29 May 2014 14:14:07 +0000 https://blog.takanabe.tokyo/2014/05/lxc%E3%81%AE%E3%82%8F%E3%81%8B%E3%82%8A%E3%81%AB%E3%81%8F%E3%81%8B%E3%81%A3%E3%81%9F%E3%81%A8%E3%81%93%E3%82%8D%E3%81%AE%E3%83%A1%E3%83%A2/ モチベーション OpenStackやらDockerやらLinux Container技術を使うサービスが増えて来たので根幹となる技術を理解したい． LXCとは LXCには広義ではLinux Kernelの標準機能を使って実現するコンテナを指すが，狭義にはlinuxcontainers.org で開発されているコンテナを扱うためのソフトウェアを指し，以降では，LXCと書いたらコンテナツールを指していると理解して頂きたい． コンテナを実現する根幹技術 Linux Containerを実現している技術で代表的なのがcroupとnamespaceである．ここに簡潔に書かれていた．簡単に言うとこういう事らしい． Cgroup:コンピュータに備わる物理的なリソース(cpu, memory, etc)を隔離/制限するための機能 Namespace(名前空間):カーネル/OSが扱うリソース(ホスト名、ネットワークスタック、PID、etc)を隔離するための機能 cgroupとlinux namespace ここに簡潔に書かれていた．簡単に言うとこういう事らしい． Cgroup:コンピュータに備わる物理的なリソース(cpu, memory, etc)を隔離/制限するための機能 Namespace(名前空間):カーネル/OSが扱うリソース(ホスト名、ネットワークスタック、PID、etc)を隔離するための機能 cgroupが物理的なリソースを,namespaceが論理的なリソースを管理するという理解でOKだろう． LXCでコンテナを作成してもip netns listでNetwork Namespaceが表示されない理由 LXCもNetwork Namespaceを使ってネットワーク分離を行っていると色々な記事でみたので，ip netns listを実行してみたが何も表示されなかった．これは，ip netns listが表示するのは/var/run/netns配下のファイルで，LXCは別のディレクトリでファイルの管理をしているから．どうやらlxc-createとip netns addではnetwork namespaceの作られ方が異なるようなので簡単に違いを残しておく． ip netnsを使う場合 まずは1つnetwork namespaceを作成する． > ip netns add nstest > ip netns list nstest 続いて，作成したnstestの中に入り,yesコマンドを実行する > ip netns exec nstest bash > yes 次に，ホストでnstest内で実行されているbashとyesコマンドのPIDを確認する > ip netns pid nstest 1820 1832 ホストでpstree -p を実行したところ，1820がbash,1832がyesのPIDだった．/proc/PID/ns/配下にそのプロセスが属しているnamespace群が格納されているので確認する． https://blog.takanabe.tokyo/2014/03/alfred-powerpack%E3%81%AE%E5%BF%85%E8%A6%81%E6%80%A7%E3%82%92%E8%80%83%E3%81%88%E3%82%8B/ Sun, 23 Mar 2014 15:02:23 +0000 https://blog.takanabe.tokyo/2014/03/alfred-powerpack%E3%81%AE%E5%BF%85%E8%A6%81%E6%80%A7%E3%82%92%E8%80%83%E3%81%88%E3%82%8B/ モチベーション 普段使っているAlfredの有料機能が必要か判断する． 背景 プログラミングをしている時，関数やクラスの使い方を調べるのにDashというアプリをつかっているのだが，一々アプリを開いて調べなきゃいけないのが少々面倒臭かった．調べてみると，普段から使っているランチャーアプリAlfredと連携することでAlfredからDashのドキュメントを開くことができるみたい．ただ，この機能を使うためにはAlfredの有料ライセンスを購入する必要があるので，何ができるようになるのか簡単に調査した上で購入を検討することにした． PowerPackとそのライセンス体系 PowerPackを導入するとAlfredで便利な機能を追加できる．追加できる昨日は公開されているものだけでなく，自作もできる．ライセンス体系はいかのようになっている． ライセンスの購入体系は2つ シングルユーザライセンス：Mac2台まで導入可能($17) ファミリライセンス：Mac5台まで導入可能($27) サポート(バージョンのアップグレード)はMega SupportLicenseが必要($32) そんなにメジャーバージョンアップが頻繁にあると思えないし， 使い勝手が良かったら，またメジャーバージョンアップの時に必要か判断する． 導入するなら，サポートなしのシングルユーザライセンスを購入しようかな． Alfredの設定を外部ファイルにexport 実は，Alfredの設定を外部ファイルに出力するにはPowerPackが必要だったりする． 新しいPCを設定するために色々なアプリの設定をいじるのはかなりストレスフルだからこれだけでも購入する価値が有る． PowerPackで利用可能になる機能一覧 ファイルシステムナビゲータ機能 alfredkara/Applications スニペット機能 普段からClipmenuを使っているがAlfredから呼び出せるのは便利かも Dashと連係 http://rikei-webmemo.hateblo.jp/entry/2014/06/19/104153 1passwordとの連係 1passwordとの連係も可能とのこと(自分は使っていないのでメモ) clipboardとの連係 Clipboardとの連係が可能とのこと(ClipboardヒストリーにはClipMenuという別アプリを利用するので必要ない) Appcleanerと連係 uninstall XXXとAlfredで入力するとそのアプリケーションを消すことができる． 便利． http://rikei-webmemo.hateblo.jp/entry/2014/06/17/150136 evernoteの検索 自分で貯めた良く使う英語の文を調べるのに便利な機能． http://ozappa21.com/facebook/archives/2472 http://www.alfredforum.com/topic/840-evernote-89-yosemite-support-search-create-append-preview-set-reminders-all-within-alfred/ever slackのチャネルを開く http://qiita.com/akira-hamada/items/1e391704d68d0af5e65e 結論 Mac使ってるなら黙ってAlfred Powerpackを購入は購入するべき．(以下の機能を使えるだけで購入する価値はあると考えた) Alfredの設定のexport Dashとの連係(workflow) evernoteとの連係(workflow) ファイルシステムナビゲータとの連係(自動) 参考 基本的な使い方 Alfred の無料版でつかえる機能の使い方と設定 PowerPack Alfred Powerpackの使い方，活用方法まとめ Alfred PowerPack を導入してみた Mac仕事効率化！Spotlightを完全に超えた神ランチャーアプリ「Alfred 2」の使い方とおすすめWorkflows10選。[Mac] フロントエンド開発者向けのAlfred Workflow https://blog.takanabe.tokyo/2014/02/docker%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ Wed, 05 Feb 2014 13:47:56 +0000 https://blog.takanabe.tokyo/2014/02/docker%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ モチベーション Dockerの基本的な使い方を学習したい 背景 個人で運用しているサーバを移行するにあたりコンテナ技術を使った運用に変更しようと思っている．コンテナ管理はLXCとDockerを候補に考えているがDockerの使い方がいまいちわかっていないので使ってみることにした． 環境 OS: Ubuntu14.04LTS Dockerをインストールする Ubuntu14.04へのインストール方法は公式ページを参照した． $ sudo apt-get update $ sudo apt-get install docker.io $ source /etc/bash_completion.d/docker.io (dockerコマンドをタブ補完できるようにする) Dockerイメージの取得 Dockerではコンテナを作るためにイメージと呼ばれるコンテナの素を利用する．(VMにおけるような位置づけ)イメージは自分で作ることもできるが，Docker Hubで提供されているものも自由に利用できる．今回は，Docker Hubで管理されているUbuntuの公式イメージを取得する． はじめはイメージを持たないが， sudo docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE Docker HubからUbutuイメージを取得すると一覧に出てくる $ sudo docker pull ubuntu $ sudo docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE ubuntu 15.04 4dd534bebcd0 13 hours ago 117.2 MB ubuntu vivid 4dd534bebcd0 13 hours ago 117. https://blog.takanabe.tokyo/2014/01/idrac%E3%81%AE%E4%BB%AE%E6%83%B3%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%83%AB%E3%81%8C%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%AA%E3%81%84%E5%95%8F%E9%A1%8C%E3%82%92%E5%AF%BE%E5%87%A6%E3%81%99%E3%82%8B/ Mon, 27 Jan 2014 14:34:50 +0000 https://blog.takanabe.tokyo/2014/01/idrac%E3%81%AE%E4%BB%AE%E6%83%B3%E3%82%B3%E3%83%B3%E3%82%BD%E3%83%BC%E3%83%AB%E3%81%8C%E8%B5%B7%E5%8B%95%E3%81%97%E3%81%AA%E3%81%84%E5%95%8F%E9%A1%8C%E3%82%92%E5%AF%BE%E5%87%A6%E3%81%99%E3%82%8B/ モチベーション iDRACの仮想コンソールにが起動できない問題の対処方法を残しておく ##iDRACの仮想コンソールが起動できない Java7のアップデートの伴って、セキュリティポリシの変更があり多くのWebアプリケーションが起動できなくなっている。iDRACも類に漏れず起動できなかった。起動可能にするためには、JAVAの設定のセキュリティ項目にある例外サイトリストに自分が利用するアプリケーションのURLを登録する必要があるとのこと。 参考： Java7のアップデートでiLO,iDRAC,IMM,iRMCが動かなくなる Unable to Launch iDRAC After Updating Java to 7u51 - Systems Management Forum - Servers - Dell Community Upcoming Exception Site List in 7u51 (Java Platform Group, Product Management blog) https://blog.takanabe.tokyo/2014/01/dell-r320%E3%81%AEsfp-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%82%92%E3%83%AA%E3%83%B3%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%81%95%E3%81%9B%E3%82%8B/ Thu, 23 Jan 2014 10:02:38 +0000 https://blog.takanabe.tokyo/2014/01/dell-r320%E3%81%AEsfp-%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%82%92%E3%83%AA%E3%83%B3%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%81%95%E3%81%9B%E3%82%8B/ モチベーション SFP+インターフェースをリンクアップさせる方法の備忘録 R45 NICとの違い LANケーブルの場合接続するだけでNICがリンクアップする。一方で、SFP+は接続するだけではリンクアップは確認できない。正常稼働を確認するにはOSをインストールしてインターフェース雨の設定をする必要がある。 SFP+のインターフェースをリンクアップさせたい DELLのサーバはデフォルトではSFP＋を指しても、SFPはリンクアップしない。従って、RJ45のNIC同様、OSをインストールしてネットワークカードの設定をする必要がある。以下、UbuntuでのNWインターフェース設定。 /etc/network/interfaces auto eth3 iface eth3 inet static address 0.0.0.0 https://blog.takanabe.tokyo/2013/12/scapy%E3%81%AB%E3%82%88%E3%82%8Bpacket%E7%94%9F%E6%88%90/ Wed, 18 Dec 2013 13:03:23 +0000 https://blog.takanabe.tokyo/2013/12/scapy%E3%81%AB%E3%82%88%E3%82%8Bpacket%E7%94%9F%E6%88%90/ モチベーション パケットクラフティングにより任意のパケット情報を生成したときのメモ書き Scapyのインストール Scapyのインストールを行う。pipですんなり入らない場合は以下のようにdnetやpcapモジュールもインストールする。 pip install scapy sudo scapyをすると以下のエラーが出る ➤ sudo scapy Password: INFO: Can't import python gnuplot wrapper . Won't be able to plot. INFO: Can't import PyX. Won't be able to use psdump() or pdfdump(). ERROR: Unable to import pcap module: No module named pcap/No module named pcapy ERROR: Unable to import dnet module: No module named dnet Traceback (most recent call last): File "/usr/local/bin/scapy", line 25, in <module> interact() File "/usr/local/lib/python2. https://blog.takanabe.tokyo/2013/11/lpic303%E6%9A%97%E5%8F%B7%E5%8C%96gpg%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ Mon, 18 Nov 2013 13:34:14 +0000 https://blog.takanabe.tokyo/2013/11/lpic303%E6%9A%97%E5%8F%B7%E5%8C%96gpg%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%8B/ モチベーション LPIC303を勉強する中でGPGを学ぶ機会が合ったので粗い感じでまとめておく。 GPG(GNU Privacy Guard) とは GPGとはWikipediによると、 GNU Privacy Guard (GnuPG) とは、Pretty Good Privacy (PGP) の別実装として、GPL に基づいた暗号化ソフトである。 OpenPGP 規格 (RFC4880) に完全準拠しているが、古い PGP との互換性は完全ではない。 とのことである。PGPがライセンスの関係上無償で利用できなくなったため、GNUが実装したもので、公開鍵暗号などが簡単に利用できる。 利用方法 秘密鍵と公開鍵を作成する ``` [takanabe@localhost ~]$ gpg --gen-key gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? https://blog.takanabe.tokyo/2013/08/nginx%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E6%A7%8B%E7%AF%89/ Sat, 31 Aug 2013 16:53:40 +0000 https://blog.takanabe.tokyo/2013/08/nginx%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AE%E6%A7%8B%E7%AF%89/ モチベーション Nginxでリバースプロキシ用の設定をメモする サブドメインでアクセス先サーバを変更する場合 server { listen 80; server_name wiki.www.example.jp; location / { proxy_pass http://192.168.33.1:80; } } server { listen 80; server_name blog.www.example.jp; location / { proxy_pass http://192.168.33.2:80; } } URIでアクセス先サーバを変更する場合 server { listen 80; server_name www.example.jp; location /wiki { rewrite ^/wiki/(.+) $1 break; proxy_pass http://192.168.33.1:80/$1; } location /blog { rewrite ^/blog/(.+) $1 break; proxy_pass http://192.168.33.2:80/$1; } location /log { rewrite ^/log/(.+) $1 break; proxy_pass http://192.168.33.3:80/$1; } } 実際に設定したもの blogへのアクセスだけならこれでOK https://blog.takanabe.tokyo/2013/08/vagrant%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6vm%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B/ Sat, 03 Aug 2013 14:18:39 +0000 https://blog.takanabe.tokyo/2013/08/vagrant%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6vm%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B/ モチベーション Vagrantを利用して開発環境を効率よく準備したい What is Vagrant? Vagrantとは違う環境に移行可能な開発環境を簡単に構築・管理し、配布することができる開発環境作成ツールのことで、VirtualBoxやVMWarePlayerなどの仮想マシンソフトウェアと一緒に使う。 具体的な例 Vagrantを導入するとこんなことができる。 どんなプラットフォーム上でも同じ開発環境を提供することができる 開発環境の違いによるエラーに悩まされない *構成管理ツールと合わせることで高度な設定ファイルを所持したVMを何度でも作成することができる VMごとに構成ファイルが微妙に異なるといった状態から脱却できる  基本的な使い方 Boxの登録 vagrant box add boxname boxurl // boxの作成 vagrant box list //作成したboxの確認 Vagrantの初期化 vagrant init boxname Vagrantの実行 vagrant up　//仮想マシンの構築 vagrant ssh　//仮想マシンに入る (仮想マシン内のファイル操作はローカルホスト内の/vagrantディレクトリから行うこと推奨) Vagnrantの終了　=仮想マシンをシャットダウン vagrant halt　//仮想マシンの停止 vagrant destroy // 仮想マシンの削除 boxファイルの場所 Vagrantに登録されているboxや仮想マシンの情報は /Users/username/.vagrant/boxes/以下に格納されている。 参考 Vagrantの使い方 - Qiita https://blog.takanabe.tokyo/2013/06/tty%E3%81%A8pts%E3%81%A8%E3%81%AF/ Sat, 08 Jun 2013 15:24:39 +0000 https://blog.takanabe.tokyo/2013/06/tty%E3%81%A8pts%E3%81%A8%E3%81%AF/ モチベーション tty,ptsを説明できるようにしたい tty,ptsとは ttyはteletypewriter(テレタイプライター)，ptsは擬似端末 (pseudo-terminal) の略で，標準出力の接続先デバイスを指す。今では考えられないが，一昔前は1つのホストに色々な人が端末をつないで作業をしていたとのこと．ここでいう端末はWindowsやMacなどのクライアント端末ではなく，キーボードのような役割を果たしていたと考えていいかな． 僕らが使っているLinuxやMacのターミナルでttyやpsコマンドをうつと出てくるttyはこの名残を受けていてterminalのデバイスファイルとしてどのtty(/dev/ttysXXX)を使ってるのかを表示する．tmuxを実行してペインを分割するとterminal画面があたかも2つになったかのようになるが，実際は2つの/dev/ttysXXX(XXXは数字)を使うことになる．また，ptsはsshでリモートサーバにログインした時に使われるデバイスファイル． gettyとは ここから引用した， シリアル接続(モデムも含む)端末からログインする際に、接続パラメーター設定を行なうためのプログラム。UNIXのブート時にinitプロセスがinittabを参照し、inittabに指定されているプログラムが起動される。gettyにはmgetty、agettyなどさまざまなバージョンがある。gettyの基本的な機能は、モデムや端末が接続されている回線(RS232-C)やコンソールを監視して、デバイスがアクティブになると、アクセスしてきたデバイスにログインプロンプトを送り、返ってきたユーザー名をloginプログラムに渡すことだが、シリアル回線の監視は行なわず、仮想端末をサポートするmingettyなどもある。 動作で確認する 1つのホストにsshで2つのコネクションを張った後ログインしてttyコマンドを打つ. これを見るとそれぞれのコネクションで異なるptsを利用していることがわかる.また,片方のpts/5からもう片方ののpts/7に向かってechoを実行するとpts/7の標準出力に実行結果が表示される． 参考 Linux起動の仕組みを理解しよう［init/inittab編］ (1⁄2) ttyとptsとptmxとpty ttyについて ttyやptsってなんぞ？ 端末の識別子 -ptsとtty- https://blog.takanabe.tokyo/2013/05/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/ Mon, 13 May 2013 15:42:15 +0000 https://blog.takanabe.tokyo/2013/05/%E3%83%96%E3%83%AD%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/ 自分の学んだことを綴ったり、世の中に還元したいという気持ちからブログを始めました。マイペースに更新していこうと思います。