本日開催されたMackerel Dayで社内で「アプリケーションエンジニアがMackerelで楽しく監視構成している事例」（長い）を少ししゃべってきました。
発表時のスライドはどこに上げるのか？ など社内で確認することを完全に忘れていたので公開していないのですが、なるべく早めに共有したいと思っています。
この記事では小並感を垂れ流します。
追記：公開しました。
www.slideshare.net 続きを読む
PHPからMackerelにサービスメトリックを投げる
細かいことはいいから proc_open で mkr コマンドを使えばいいんじゃないかな。
投げる = mkrコマンドでサービスメトリックを投げるときのコマンドが throw
<?php $time = time(); $metoric = <<<_EOT_ metoric-name-1 {$value1} {$time} metoric-name-2 {$value1} {$time} _EOT_; // http://php.net/manual/ja/function.proc-open.php $cmd = 'mkr throw -s service-name '; $descriptorspec = array( 0 => array("pipe", "r"), 1 => array("pipe", "w"), ); $process = proc_open($cmd, $descriptorspec, $pipes); if (is_resource($process)) { fwrite($pipes[0], $metoric); fclose($pipes[0]); $output = stream_get_contents($pipes[1]); fclose($pipes[1]); $return_value = proc_close($process); // XXX コマンドの成否？ 眠いから今度 return value を見るよ //Log::info('mkr throw result...'.$output); } else { //Log::error('can not open process.'); }
mackerel-agent もいれば batch の実行ユーザは root だし、余裕だったぜ。
※ヤンキーな実装は自己責任でお願いします。
追記
極秘情報によると、PHPクライアントは誕生間近とのことです！
時間と心の余裕があったらやりたいAPIをPRしたいという思いはある。
追記２
超極秘情報によると、その誕生間近のクライアントでのサービスメトリック投稿の事例もあるようです！！
俺は寝たい（AM1:40）
追記３
私はmkrコマンドを無理やりたたけば、API_KEYのことを考えなくてよいという利点があることにに気が付いた。
（AM1:46）
CloudFrontではあるドメインを複数のディストリビューションに指定できない理由
先日AWSのCloudFrontを使うにあたって、以下のエラーに遭遇した。
Resolve Cloudfront Error "CNAMEAlreadyExists"
状況的には、あるドメインへのアクセスをDNSの設定変更で複数のCloudFrontディストリビューションに振り分けたい、といったものだった。
これは、CloudFrontの仕様上実現できない。
CloudFrontに独自のドメインでアクセスするためには、CloudFrontディストリビューションにそのドメインをCNAME設定する必要があるのだが、あるドメインは1つのディストリビューションにしか設定できない。
「仕様だから」で済ませばそれで良いと言えば良いのだが「何故そういう仕様なのか？」を考えてみると中々趣き深かった。
続きを読むセスタスのために嵐を購読する
10年以上前から、ファイブスター物語が載っている号だけNewtypeを購入している。とにかく早く読みたいからだ。
先月から、拳奴死闘伝セスタスを読みたいがためにヤングアニマル嵐を購入するようにした。とにかく早く読みたいからだ。
先日、7巻を遅ればせながら読み「やはり面白いなぁ。ザファル先生は最高だなぁ」と余韻に浸っていたところで奥付を眺めて衝撃を受けた。
「毎号掲載されている……」
無印アニマル時代からは考えられない状況である。
毎月セスタスが読めるとか最高じゃないか？ と、セスタス目当てに嵐を購読することにしたのだった。
- 作者: 技来静也
- 出版社/メーカー: 白泉社
- 発売日: 2017/05/29
- メディア: コミック
- この商品を含むブログ (1件) を見る
Bitbucket Pipelines で PHP のプロジェクトを Deployer する
お久しぶりです。 この半年間 FA:G の沼にはまりかけたりしていましたが、コードもそれなりに書いていました。
IoTのTの字は全くないですが、何故かPHPです。
さて、日ごろから1銭も払わずにGitのプライベートリポジトリを使わせていただいており非常に感謝しているサービスに Bitbucket Cloud があります。
いい加減ローカルマシンで Deployer のデプロイコマンドを叩くのに飽きたので、いわゆるCDしてやろうかと CircleCI と接続できる Bitbucket にリポジトリを持ってきました。
そうしたら、Bitbucketにもコードパイプラインが用意されていたんですね。 んじゃぁ、デイリーアクセス数十ヒットのこのBlogで紹介してユーザー数増加に貢献してやろうと思った次第です。
bitbucket-pipelines.yml
Bitbucket Pipelines は他のCIサービスよろしく、リポジトリ直下に bitbucket-pipelines.yml というCI設定を宣言したファイルを配置することで動作するようです。
詳しくはドキュメントを読んでください。 自分はろくすっぱ読まずに Try And Error してデプロイしました。
なので、以下の設定は相当に眉唾です。
皆さんは default（リポジトリ内容変化時に常に行われるビルド）にはいい感じのテストタスクを宣言してください。
この例では staging ブランチにPRがマージされたらデプロイ、のようなことを宣言しています。
deploy.php が既定の位置に配置されていれば -f 引数は要らないですね。
image: php:7.1.1
pipelines:
default:
- step:
script:
- ls -la ~/.ssh
- cat ~/.ssh/config
branches:
staging:
- step:
script:
- apt-get update
- apt-get install ssh -y
- curl -LO https://deployer.org/deployer.phar
- chmod +x deployer.phar
- ./deployer.phar -f=./front/deployer/deploy.php deploy staging -v
- ./deployer.phar -f=./admin/deployer/deploy.php deploy staging -v
Errors
私が見たエラーたちです。
Deployerのバージョンが上がっていた
[Error] Call to undefined function Deployer\server()
#0
phar:///opt/atlassian/pipelines/agent/build/deployer.phar/src/Deployer.php(309)
: require()
~~
require('phar:///opt/atl...')
#5 {main}
ﾊｧ? という感じのエラーが吐かれて意味不明だったのですが、 何のことはなくDeployerのバージョンが上がった際に破壊的な変更がいい感じに行われていただけでした。
さすがメジャーバージョンアップデート、後方互換なんて一切気にしてないぜ。
Servers to Hosts server($name, $hostname) to host($hostname)
ssh コマンドがインストールされていない
[Deployer\Exception\InitializationException] Failed to initialize ssh multiplexing
の様なエラーが出たんですね。 image の選定がイケてないのかもしれませんが、Deployerを動かすんだから、とPHPのビルド向けの php:7.1.1 を指定したら、ssh コマンドがインストールされていないようでした。
ssh コマンドのインストールを宣言して回避しました。 なお apt-get の update を行っておかないと install には失敗するようです。
別にエラーではないのですが、Pipelinesのビルド時にはリポジトリの設定で指定したSSHキーが以下のように配置されているみたいです。 これによってSSHコマンドのデフォルトに指定した鍵が使用されます。
ls -la ~/.ssh total 16 drwxr-xr-x. 2 root root 4096 May 26 17:31 . drwx------. 1 root root 4096 May 26 17:31 .. -rw-------. 1 root root 56 May 26 17:31 config -rw-r--r--. 1 root root 1606 May 26 17:31 known_hosts cat ~/.ssh/config IdentityFile /opt/atlassian/pipelines/agent/data/id_rsa
known_hosts
にBitbucketが入っていなくて、リモートマシンでの git clone が失敗していました。
他
いろいろダメだった気がしますが忘れました。
コスト
こんなところでしょうか。
Deployerの実行自体は基本的には以下の3行のスクリプトで行えるので、後はプロジェクトの事情に応じて周辺設定、宣言を適宜行っていけばいいと思います。
- curl -LO https://deployer.org/deployer.phar
- chmod +x deployer.phar
- ./deployer.phar deploy
正直PipelinesでDeployerするのにかけた時間と毎回コマンドを手で叩く時間の総計では、前者の方が長い結果になる気がするのですが、叩かなくてよくなる、というのはいいですね。
Bitbucket Server（Stash）にもくっついてこないかなぁ？ 標準添付だと何かと便利そうなのだけれどコンテナを実行できる環境とかないと無理だし、ないかな。欲しいんだけどなぁ。
そんな感じでした。
さくらのクラウド オブジェクトストレージにAWS SDK for .NETで接続する
ときに、素直にはいかなかったのでメモを残しておく。
さくらのクラウド オブジェクトストレージのバージョンは記事の日時現在、
SDKのバージョンは 3.3.5.3 だった。
“AWSSDK.S3”: “3.3.5.3”
概ね以下のような記述で接続できるクライアントを構成できた。
- endpoint: https://b.sakurastorage.jp/
- key: アクセスキーID
- secret: シークレットアクセスキー
// デフォルトの AWS4 に対応していないのでv2を使う様に設定する AWSConfigsS3.UseSignatureVersion4 = false; client = new AmazonS3Client( new BasicAWSCredentials(key, secret), new AmazonS3Config() { ServiceURL = endpoint, // XXX この設定は間違っているか無視される SignatureMethod = SigningAlgorithm.HmacSHA1, SignatureVersion = "2" });
記事現在の AWS SDK for .NET に関するドキュメントはバージョン3ではなく2で書かれていて、 そこではシグネチャの既定のバージョンは2なようだ。
そのため、逆に4を有効にするような案内が載っていたりするが、罠なので気を付ける。
AWS SDK、CLI、Explorer の使用 - Amazon Simple Storage Service
S3 クライアントを作成する前に、コードに以下を追加します.
AWSConfigs.S3UseSignatureVersion4 = true;
逆や。
これに限らず、もろもろのバージョンは後から不一致に気が付くとなかなか切ない思いになる。
巡察艦ゴースロスの個室で主計修技館の規則を読んでいたジント君の気分を垣間見た。
