あけましておめでとう😂！ では、今日はLinux 4.20より導入された PSI を試していきたいわけですが、まずは環境構築からやっていきたいとおもいます。今後、「〜していきたい」と言う表現が続きますが、そこは任意のユーチューバーやゲーム実況者の声に置き換えてお読みください。 PSIは公式サイトがあります。 facebookmicrosites.github.io Pressure Stall Information とは、各種リソース、CPU/メモリ/IO のプレッシャー状況を取得する方法で、具体的には /proc やcgroup2配下のファイルを経由してゲットできます。いわゆるロードアベレージのように参照できるのかどうかが気になっていて、色々試していきたいと思います。 ちなみに、TenForwardさんがすでに紹介記事を軽く書いていますので、僕はあれですね、フォロワーとしてやっていき

こんばんは、皆さんはチェックポイントアンドリストアでしょうか。そのようにやっていきましょう。今日はCRIUの話をします。 CRIU について プロセスのチェックポイントイメージを取り、そのイメージからプロセスを再生する技術です。LinuxではだいたいCRIUを使えばできます。もちろん、コンテナのチェックポイント・リストアにも応用できます。 TenForwardさんの記事が詳しいですので是非そちらもお読みください。 gihyo.jp 何ができるかというところが気にかかるでしょうが、TenForwardさんの記事にある通り： ライブマイグレーション 起動が遅いサービスのスピードアップ あたりが有益そうな用途でしょう。 前者は、KVMのような仮想化方式でやっているように、動的にコンテナを動かしているホストを変えたりしたい場合に使えます。例えば特定のホストにコンテナが偏ってるぞ〜みたいなパターンの

haconiwa という、いわゆるLinuxコンテナに関する様々な技術を組み合わせて、自分のためのコンテナを作ることができるRuby製のツールと、そのDSLを作った。ひとまずこれぐらいはやりたいということができていそうなので、バージョン 0.2.0 としてリリースした。 github.com 使い方 ほぼREADMEの日本語版。 前提として、以下のライブラリとコマンドが必要になるので入れておいて欲しい。 libcap (libcap.so.2 を FFI 経由で使う) nsenter (yum install util-linux とかそういう感じで入れる) ひとまず動かしたい場合は、rbenvなどが整った環境で、gemとして入れるのがいいと思う。多分Ruby 2.0 以降で動く気がする。 $ gem install haconiwa $ rbenv rehash そして、現在のhacon

ある日、 OpenStack にあるサーバAが起動しなくなった :sob: OpenStack なのでディスクイメージは見ることができる という状態。起動しないので mysqldump のようなコマンドは使えないが、以下のように復旧した。 同じアーキ、同じOSでサーバを作り直す Puppetなどでサーバ構成管理していればなんちゃないですね。していない場合は... ...... サーバAの母艦ノードに入る いわゆる、compute nodeというもの。 拡張の種類にもよるが、 nova show などで確認できるはず。また、一緒に instance_name というものも確認できる、控えておく。 $ nova show test001 +--------------------------------------+---------------------------------------

github.com みなさん、userdata書いてますか（挨拶）。 今日は、細々と書いてきた、自作ツールの紹介をしてみます。 どういうものか たとえば、同じPuppetのマニフェスト、同じアプリをデプロイするけれど、サーバAはweb向けのロードバランサー、サーバBはAPI向けのロードバランサーの配下にいて欲しくて、それぞれ固有の動きをさせたいような場合があるかもしれない。 そういうとき、まず、サーバAの起動時に、EC2のタグ機能を使って aws ec2 run-instances ......... # インスタンスIDを控えるか変数に入れる aws ec2 create-tags --resources i-XXXXXXX --tags Key=LoadBalancerName,Value=www とやることが考えられる。サーバBなら Key=LoadBalancerName,Val

「プロジェクト全体のMLにエラー通知メール飛ばすのうざい」、「〜についてはみんながいるチャンネルで相談すべきことではない」みたいな指摘がある。 個人的には情報は可能な限り広いスコープで公開してほしいし、自分でもそうしようとしている。まだ未熟なので霊力に負けることもあります...。 というのも、「情報が届いていない」ことによる不利は仕事上非常に大きいし、場合によって致命的になるので、むしろ冗長化して届けられているべきなのである。 あと、情報が多ければ多いほど普通は判断が適切になると思うので、情報が広く共有されていると言うことは、チームメンバー一人一人が自分で判断できる材料を持ちやすくなると言うことにもつながる。スクラムとか色々言われているけど「一人一人が自分で判断できる」ということはどういう開発スタイルでも大事だと思う。 なのでむしろみんながいる場で議論していたり、細かい情報をどんどん流して