IT Labor Note

2015年8月17日月曜日

chef 12 server のインストールで混乱したのでメモを残しておく

以下の公式サイトからダウンロードしようとすると、何か登録しないといけないようだがキャンセルしてもダウンロードはできてしまうので、登録は必須ではないらしい。
https://downloads.chef.io/chef-server/

配布自体は package cloud 経由で行われている。
https://packagecloud.io/chef/stable/install

以下のMLスレッドにある記事を見ると今後こっちが主流になるらしい。
http://lists.opscode.com/sympa/arc/chef/2014-12/msg00193.html

sha1 の結果は一緒だったので、簡単な方を選ぶ。
上記 packagecloud のインストラクションに従い以下のコマンドを実行する。


curl -s https://packagecloud.io/install/repositories/chef/stable/script.rpm.sh | sudo bash

実行すると、/etc/yum.repos.d/ 配下に chef_stable.repo というファイルが作成され、普通に yum でインストールできるようになる。
438 MB と結構でかいので少しインストールに時間がかかる。


$ sudo yum install chef-server-core

Loaded plugins: priorities, update-motd, upgrade-helper

amzn-main/latest                                                                                                                               | 2.1 kB     00:00

amzn-updates/latest                                                                                                                            | 2.3 kB     00:00

Resolving Dependencies

--> Running transaction check

---> Package chef-server-core.x86_64 0:12.1.2-1.el6 will be installed

--> Finished Dependency Resolution



Dependencies Resolved



======================================================================================================================================================================

 Package                                     Arch                              Version                                   Repository                              Size

======================================================================================================================================================================

Installing:

 chef-server-core                            x86_64                            12.1.2-1.el6                              chef_stable                            438 M



Transaction Summary

======================================================================================================================================================================

Install  1 Package



Total download size: 438 M

Installed size: 1.2 G

Is this ok [y/d/N]: y

Downloading packages:

chef-server-core-12.1.2-1.el6.x86_64.rpm                                                                                                       | 438 MB     00:40

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

  Installing : chef-server-core-12.1.2-1.el6.x86_64                                                                                                               1/1

  Verifying  : chef-server-core-12.1.2-1.el6.x86_64                                                                                                               1/1



Installed:

  chef-server-core.x86_64 0:12.1.2-1.el6



Complete!

ちなみに yum search すると、chef-server と chef-server-core の二つが表示されて、非常にややこしい。chef-server の方は以下のパッケージがインストールされる。

chef-server-11.1.7-1.el6.x86_64.rpm

こっちは chef 11 のサーバーなので要注意。他に以下のパッケージも 11 ってバージョンがついている。

chef-container-11.16.2-1.x86_64.rpm
private-chef-11.3.2-1.el6.x86_64.rpm

2015.8.18 追記
ちなみにこのリポジトリから取得できるパッケージは以下のとおりでした。


$ yum --disablerepo=* --enablerepo=chef_stable list available

Loaded plugins: priorities, update-motd, upgrade-helper

Available Packages

chef.x86_64                                         12.4.1-1.el6                                            chef_stable

chef-container.x86_64                               11.16.2-1                                               chef_stable

chef-ha.x86_64                                      1.0.0_rc.3-1                                            chef_stable

chef-marketplace.x86_64                             0.0.1-1.el6                                             chef_stable

chef-server.x86_64                                  11.1.7-1.el6                                            chef_stable

chef-server-core.x86_64                             12.1.2-1.el6                                            chef_stable

chef-sync.x86_64                                    1.0.0~rc.6-1.el5                                        chef_stable

chefdk.x86_64                                       0.7.0-1.el6                                             chef_stable

delivery.x86_64                                     0.3.210-1.el6                                           chef_stable

delivery-cli.x86_64                                 20150811030818+20150811030818-1.el6                     chef_stable

opscode-analytics.x86_64                            1.1.5-1.el6                                             chef_stable

opscode-manage.x86_64                               1.21.0-1.el6                                            chef_stable

opscode-push-jobs-client.x86_64                     1.1.5-1.el6                                             chef_stable

opscode-push-jobs-server.x86_64                     1.1.6-1                                                 chef_stable

opscode-reporting.x86_64                            1.5.1-1.el6                                             chef_stable

private-chef.x86_64                                 11.3.2-1.el6                                            chef_stable

supermarket.x86_64                                  2.0.0~alpha.0-1.el6                                     chef_stable

2015年7月21日火曜日

ほとんど何もないところから無理やり、S3 にでっかいファイルをアップロードしたメモ


gzip -c < verybigfile | split -b 100m -d -a 3 - verybigfile.gz.

for FF in verybigfile.gz.* ; do ./s3up.sh $FF ; done



$ cat s3up.sh

────────────────────────────────────

#!/bin/bash

file=$1

bucket=shellupload

resource="/${bucket}/${file}"

contentType="application/octet-stream"

dateValue=`date -R`

stringToSign="PUT\n\n${contentType}\n${dateValue}\n${resource}"

s3Key=XXXXXXXXXXXXXXXXXXXXXXXX

s3Secret=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

signature=`echo -en ${stringToSign} | openssl sha1 -hmac ${s3Secret} -binary | base64`

curl -v -L -X PUT -T "${file}" \

  -H "Host: ${bucket}.s3.amazonaws.com" \

  -H "Date: ${dateValue}" \

  -H "Content-Type: ${contentType}" \

  -H "Authorization: AWS ${s3Key}:${signature}" \

  https://${bucket}.s3.amazonaws.com/${file}

────────────────────────────────────

このシェルをどこから拾ったか忘れた。しくしく
多分ここからこぴって、適当になおした。

http://tmont.com/blargh/2014/1/uploading-to-s3-in-bash

2015年6月19日金曜日

Amazon Elastic File System (EFS) を気づいたら使えるようになっていたので、早速起動してみた。

Amazon Elastic File System (EFS) を気づいたら使えるようになっていたので、早速起動してみた。とりあえず起動してみただけなので、とりあえずファーストレビュー。

EFS は AWS が提供する、NFS v4 サーバ。ディスク容量が自動的に割り当てられるのと、サーバ自体がスケーラブルになっているとの触れ込み。

これまで、NFS のサイジングやディスク容量の管理に悩まされていたシステム管理者にとってまさにこれだけのために、AWSに移行したくなる素晴らしいソリューション。

また s3fs の遅さやパーミッション設定の難しさに悩んでいた人にも朗報となるだろう。しかも料金はディスクを使用している分だけ。無駄にストレージに投資することもない。

マネージメントコンソールからEFSのアイコンをクリック。プレビューの申請が通っていないと申し込み画面に飛ばされる。現在は us-west-2 （Oregon）のみ使えるようになっていた。

クリックすると最初の案内画面に飛ばされる。迷わず "Create File System" をクリック。

VPC 、Subnet 、Security Group を AZ 毎に指定。実運用に回すときは、NACL や Security Group の設計に配慮が必要になるだろう。

IP アドレスは自分で指定することも自動的に割り当てることも可能。VPC 内なのでそれほどアドレスにこだわる必要もないと思うので、自動割り当て。可用性等を考慮するとどの道、DNS名での指定が有効だと思われる。

次はタグ付け。とりあえず Name タグだけつけておく。

最後に確認画面。特に変更がなければ "Create File System" をクリックして作成完了。

これで完了。

非常に簡単に高性能で可用性が高い共有ファイルシステムが使えるようになりました。

とは言え、万能の道具は無いのでいくつか注意事項はあると思います。

特にNFS 上の単一ファイルへの書き込み時排他制御には十分注意が必要です。

マニュアルにも明示的にロックの制限が記載されています。

詳細はマニュアルを確認していただくとして、ロックに関しては以下の制限があります。

一つのファイルに対して、すべてのファイルシステムのユーザーに対して87 までしかロックがかけられません。複数のサーバにまたがっても87までです。

また Linux NFSv4 の制限として以下があります。

一インスタンス当たり同時に128ユーザまでしか、ファイルを同時にオープンできません。
一インスタンス当たり 32,768 ファイルまでしか同時にファイルを開けません。
一マウント当たり、8192 ロックまでしか獲得できません。
一マウント当たりユニークなファイルとプロセスの組み合わせは、256までです。例えば 1 プロセスならば、256ファイルのロックを取得できますが、8プロセスなら 32ファイルまでのロックを獲得できません。

まぁもともと NFS のロックはあてにしてはいけない（いつの話だよｗ）っていう話もありますし、同時実行性能の観点からはできるだけロックレスな構成にする必要もあります。

とは言え EFS の登場で、これまでオンプレから移行しづらかった案件やスケーラビリティに問題があったシステムでも、容易に拡張可能になるのではないでしょうか。

2015年1月9日金曜日

EC2スポットインスタンスのターミネート通知機能が利用できるようになったので、ちょっと試してみた。

AWS EC2 にはスポットインスタンスというちょっと変わった利用方法があります。
インスタンス起動時に価格を指定して起動することができます。通常オンデマンドより大幅に安い値段でインスタンスを起動できますが、スポット価格が指定した価格を上回った場合、突然インスタンスが停止してしまいます。

安く使えるのでいいのですが、突然止まってしまってあ゛っ!!!てなることがあります。そういう声も多いのか、インスタンスの停止を予告する機能が追加されました。

【AWS発表】EC2スポットインスタンスのターミネート通知機能

多分以下のような使い方をするのではないでしょうか?以下の例では、通知を受けたら自身のスナップショットを作成しています。他の使い方もあるかもしれません。


#!/bin/bash



#You Need Set Proper IAM Role

#GET REGION

REGION=`curl -s -f  http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//g'`



#Instance ID

InstanceID=`curl -s -f  http://169.254.169.254/latest/meta-data/instance-id`



#wait until the "temination-time" available

until curl -s -f  http://169.254.169.254/latest/meta-data/spot/termination-time

do

  sleep 5

done



#Warning all

wall "!!!!!!!!!!spot instance termination begin!!!!!!!!!"



#Wait a while for saving data etc.

sleep 30



#GET EBS

EBS=`aws ec2 describe-instances --region=${REGION} --output text --instance ${InstanceID} | awk '/^EBS/{print $5}'`



#GET snapshots

for II in $EBS ; do

  #the voodoo magic

  sync; sync; sync;

  aws ec2 create-snapshot --volume-id $II --region $REGION

done

2014年11月30日日曜日

AWS KMS が使えるのに気付いたので、早速試してみたメモ

re:invent で発表された、AWS Key Management Service が使えるようになっているのに気付いたので、早速使ってみることにしました。
このサービスは管理的には非常に重要でキーを安全に共有したいとか、キーがどれだっけ?とか、緊急の対処が必要なのにキーが見つからないとか、そういう状況に陥らないようにするために、こう言ったサービスが非常に重要だったりします。
サポートされているリージョンは以下の通りです。東京でも使えますね。

http://docs.aws.amazon.com/kms/latest/developerguide/regions.html

Region Name	Region	Endpoint	Protocol	Support Date
US East (Northern Virginia) Region	us-east-1	kms.us-east-1.amazonaws.com	HTTPS	11/12/2014
US West (Northern California) Region	us-west-1	kms.us-west-1.amazonaws.com	HTTPS	11/12/2014
US West (Oregon) Region	us-west-2	kms.us-west-2.amazonaws.com	HTTPS	11/12/2014
EU (Ireland) Region	eu-west-1	kms.eu-west-1.amazonaws.com	HTTPS	11/12/2014
EU (Frankfurt) Region	eu-central-1	kms.eu-central-1.amazonaws.com	HTTPS	11/12/2014
Asia Pacific (Singapore) Region	ap-southeast-1	kms.ap-southeast-1.amazonaws.com	HTTPS	11/12/2014
Asia Pacific (Sydney) Region	ap-southeast-2	kms.ap-southeast-2.amazonaws.com	HTTPS	11/12/2014
Asia Pacific (Tokyo) Region	ap-northeast-1	kms.ap-northeast-1.amazonaws.com	HTTPS	11/12/2014
South America (Sao Paulo) Region	sa-east-1	kms.sa-east-1.amazonaws.com	HTTPS	11/12/2014

対応しているサービスは以下の通りです。

Amazon Redshift
Amazon Simple Storage Service
Amazon Elastic Block Store

データストアとして使うサービスで暗号化がサポートされているサービスは全て使えるようです。個人的な趣味としては、RDSのEBSでつかえるのかなぁというのが気になります。

それでは、早速、使ってみたいと思います。単独のサービスとしては、management console には表示されません。 IAM のメニューの一つとして、あります。

早速 Getting Started Now してみましょう。

なんだかわからないキーがポツンと一つだけあります。クリックしてみると、”Default master key that protects my EBS volumes when no other key is defined” とあるので、EBSを暗号化するときに利用する、デフォルトのキーのようです。EBS暗号化をすでに利用している人はうっかり消さないようにしましょう。実際 management console 上では消せないようにガードされているようです。

よく考えずに、Create Key してみます。

エイリアスを入力しなければいけないようなので、とりあえず適当な名前を入力します。

IAMユーザーの選択を求められたので、汎用に使っている adminitorator 権限（ようするに制限なし）のユーザーを選択しました。

もう一回 IAM ユーザーの選択を求められます。よく読むと、キーの管理者とキーの利用者を別に設定できるようです。これはセキュリティ的によく考えられた設計だと思います。でもここでは同じユーザーを選択しました。よろしくないですね。

こんな感じでキーのポリシーが作成されました。キーの管理者権限と、使用者権限が別に設定されています。

次に進むとこんな感じで、キーが作成されています。初期で作成されたキーは洗濯できなくて、新しく作成されたキーば選択可能になっています。キーの削除も可能なようです。

クリックするとこんな感じの画面になって、キーの管理者と使用者を指定できるようになっています。

キー自体をアップロードしたり、ダウンロードしたりはできないようです。

実際どのようなユースケースが想定されるでしょうか。

例えば、研究開発部門で極秘のプロジェクトが進行していて、同社内でも他部門には知られたくない研究データがあったとします。もちろ他社の産業スパイなどにも注意が必要です。そのデータはEBSに格納されています。KMSを利用して、権限を限定して、かつEBS暗号化を利用することで、同社内でもデータを利用することを制限することが可能です。

人事データや給与データなども該当するかもしれません。

もっと簡単なユースケースでは、例えば18禁ビデオと、それ以外でアクセス可能な権限を分けるとかw

何れにしてもセキュリティ管理的には重要な機能が追加されたと思います。

2014年11月20日木曜日

クラウド運用について気づいた６つのこと

きょう、日本MSP協会の記念すべき第１回の会合に参加させていただき、たくさんの議論のなかで、気付き（というか思いつき）が幾つかあったのでメモしておきます。

運用は Managed それとも Operation

"運用でカバー" という言葉が示す通りとかく運用担当は雑用係になりがちです。そもそも運用とは何か？という問いかけに明確に答えられないのが実情だと思います。手順書をもらって作業するのが運用ということになりがちです。
これはただの operation だと思います。
operation を超えて Managed になるには何が必要なのだろうか? という問いかけに答える必要があります。

サービスカタログの必要性

Managed として認めていただくためには、 Managed Service として何が提供されるのかを明確にする必要があると感じました。そのためには Service Catalogue の充実が必要になると思いました。では Service Catalogue の内容として何が必要なのでしょうか? 幾つか思いつきですが並べてみます。

コスト最適化

MSP という業種は Managed 業務のアウトソーシングだと思います。アウトソーシングである以上、自社でやるよりもコストメリットがあることを訴求しなければいけないと思います。そのためにはサービス内容を貨幣価値で評価する必要があり、管理会計的な手法や、オペレーショナルリサーチ的な手法が必要になるように思います。同一コストであれば、デリバリーされる内容が自社運用するよりもレベルが高いとか、同じサービス内容であればコストが安いことなどをお客様や経営層に訴求する必要があると思います。

IT 統制の重要性

Managed Service の重要な課題となるのは IT 統制、特にセキュリティへのコミットメントではないでしょうか。本当に IT 統制を適用するとシステムの規模によりますが、それだけで莫大なコストがかかります。MSP に任せればセキュリティを含めて IT 統制、コンプライアンスは万全だと言われるような Service Catalogue の整備が必要だと思います。

運用設計の重要性

DevOps ではないですが、クラウド時代の運用は自動化手法が重要になってくると思います。そのためには、システム設計の段階から運用、コンプライアンスに関して重要なアーキテクチャを提案する必要があると思います。例えば、Immutable infrastructure 化する手法の提案などがあると思います。とりあえず作っちゃったから、あと運用よろしくでは IT 統制のコンプライアンスを取得するのは難しくなると感じました。

職業的ディシプリン（規律）の確立

IT 統制の中で最もリスクが高いのは、某通信教育会社の事例を引き合いに出すまでもなく、Human Factor だと思います。MSP に任せて安心だと思っていただくためには、マックス・ヴェーバーの「プロテスタンティズムの倫理と資本主義の精神」ではないですが、やはり倫理的な規範を示す必要があると思います。その規範の表明としてMSPチャーター（憲章）のようなものを制定する必要があるように思います。MSPチャーターに従うことが運用プロフェッショナルとして表明することなるようになったらいいなぁと思いました。

以上、とりとめもなく書いていますが多くの方のご意見を賜りたいと思います。

2014年9月16日火曜日

iproute2 の ss コマンドのバグと、Red Hat Enterprise Linux と CentOS と OSS

「 ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない」（ここから）というブログのエントリを読んでいて、物事にはいろいろな見方があるのだなぁ。と思ったので感想。

上記ブログエントリでは、「netstat の代わりに ss コマンドが RHEL7.0 で推奨になっているけれど、ss コマンドに "-a" コマンドを付与した場合、UDP のソケットを TCP として報告してしまうバグがあるから使い物にならないよ、みんな注意してね。」という内容。

このバグはRed Hat 社的には、2014年2月11日に "Bug 1063927 - ss reports udp sockets as tcp" として報告されていて、現在のステータスは "assigned"になっている。コメントから、現在の7.0では取り込みが間に合わなかったことになっているが、ステータスとしては、"assigned" のままなので、今後のリリースで取り込まれる可能性が十分にある。

コミュニティーには、2014年2月10日にコミットされているので、Red Hat 社としてもコミュニティーをウォッチしていて、可能であればバグフィックスを取り込もうとしている姿勢が見受けられるがいろいろな大人の事情で取り込みまでに時間がかかるのは仕方がない。

というよりは多分、Red Hat 社的には取り込まざるを得ないだろうと思っている。なぜなら、Bug 1063927 は Bug #1039625 -> Bug #1049459 -> Bug #1055607 という三つのバグをブロックしていて、この三つの Bug はいずれも非公開になっている。

オープンなはずの Bugzilla で非公開の Bug があるのは奇異な感じがするが、実際は Red Hat 社の特定顧客から、Customer Portal を通じて報告された Bug は、非公開として Bugzilla に登録される。Red Hat 社は顧客から依頼された修正は、基本的には取り込まなければいけないので、おそらく 7.1 以降で取り込まれるのだろう。

ただバグも仕様になってしまう、つまりバグ修正をすることによってむしろ非互換が発生すると判断された場合はその限りではないので、難しいところだ。

Cent OS を利用している人は何も言えないが、お金で解決してしまう Enterprise な世界である。

お金を払って、問題のある製品を提供するのか?という方もいるかもしれないが、Red Hat 社の提供しているのは、QA と保守なので、QAで対応できなかった問題は保守で対応する。

そもそも Enterprise なシステムは、RHEL 7.0 をいきなり本番適用したりは絶対にない。それがよいかどうかの是非はおいておいて、Enterprise なシステムでは、設計からカットオーバーまで数年近い時間をかけてシステムを構築する。運用期間を含めたら10年以上に及ぶこともあるので RHEL のサポート期間は今や10年以上になっている。（参考:Red Hat Enterprise Linux のライフサイクル）

RHEL 7.0 から検証を始めて、自社に必要な修正を Red Hat 社に取り込ませ、実際に運用開始は 7.3 から開始みたいなことを普通に行う。本当に Enterprise なことをやっている人たちにはこれは単に課題管理であって、Red Hat がダメだとはならない。むしろ修正してもらえるかどうかわからないことの方が大問題なのである。そのために大金を払っている。

そもそも、バグ自体はメインストリームで修正されているので、自分でパッチを当てたバージョンを作って、とりあえず急場をしのぐというアプローチも考えられる。ただ本当に、Enterprise な環境だと、パッチの管理をどうするかとか、そのパッチ自体に問題があった場合の責任はとか、いろいろ問題が生じるので、そのあたりをお金を払って、Red Hat にやってもらっているのである。

普通の感覚だと、Red Hat 社のサポート料は高額に見えるが、自社で SE を雇って、QAを行い、場合によっては調査を実施して等などの諸費用を考えると、多くの場合 Red Hat 社にサポート料を払ってやってもらった方が安くなる。

一方で Red Hat 社では、世界中から寄せられる無理難題に対して応え続けた結果、今では結構なナレッジが蓄積されている。そう考えると、サポート料は情報に対する対価という意味合いも含まれている。

じゃあこういった情報を無料で使う方法が無いかというと、そうでもない。 Fedora を使うという方法がある。 Fedora は RHEL の先行リリースという側面があるので、Red Hat の Bugzilla に報告すると回答がもらえる場合がある。場合によっては修正が提供される場合もある。

ただし、新機能の積極的な取り込みが行われるので、人柱になってしまうリスクというかコストが発生するが自分で全部テストしたり、パッチを管理したりするよりははるかにましだ。

ところで、この BUG を追いかけていて、いろいろおもしろかったのは、"-a" オプションの取り扱いがいろいろ紆余曲折を経いていることだ。（Bug 829632、Bug 829630、Bug 811219 など）

もともと "ss" コマンドの仕様としては、"-a" で tcp しか表示しなかったようだ。(Bug 829630)
これは "-a" の仕様が "Listening" と "non-Listening" を表示するとなっていたのと、ソケットのタイプのデフォルトが、"tcp" になっていたからと説明している。がnetstat との互換性を考慮して修正されている。これが正しいのかどうかはやはり議論が必要だが、少なくとも netstat の出力に慣れた人にはよかったのだろう。

また、ここで新たな問題が発生する。両方表示するようにしたものの、そもそも tcp を表示する前提だったので、"tcp" と "udp" の区別を表示しなかったのだ。(Bug 829632)

これはさすがにまずいので、機能追加されている。そして今回の問題。つまり Bug 829632 の機能追加漏れになる。なかなか一度にすべての機能がそろわないという実例。

まさに Bug 1063927 のコメント 1 にある通り、"The `ss' utility needs a lot of love" な状態である。net-tools じゃなくて、iproute2 じゃないと、機能不足なことも多々あるので、今後の進展に期待したい。

OSS なので、様々な考え方や実装があっていいと思う。明確な仕様書が無い世界なので、一般的に合意された動作になるのが正しいと思う。 ”一般的に合意された” 動作になるためには公の議論が必要で、そのためにはMLや公開の bugzilla 等で意見を表明していくのが良いのではないだろうか。

そうでないと "RHEL" やそのクローンである "CentOS" の呪縛から逃れることができない。

登録: 投稿 (Atom)