背景
去年触っていた時は
Key Management Serviceについて勘違いしていたこと - あーありがち(2018-10-21)
こんな感じで、
- GCPの中にコードを送り込むことを自動化する際にサービスアカウントを使うので、そのアカウントの鍵が必要
- pkgcloud が keyFilename がないと激おこ
という理由で鍵をどう管理するかを考えていたのだけど、事情が変わって鍵の管理を全部不要にできたので、これをまとめておく。
まとめ
- pkgcloud が 2019-04 時点で依存 npm を gcloud から @google-cloud に乗り換えたおかげで client library の挙動が正しくなった
- 動作時のサービスアカウントの default credentials と permissions を取得できる
- Cloud Source Repositories & Cloud Build を使うことで Google Cloud の外から中へ入れる必要がなくなった
結果、サービスアカウントの鍵を Google Cloud 外に持ち出す必要はなくなった。
なくせたこと
これまでサービスアカウントの鍵を外に持ち出しつつリポジトリの中に鍵を納めないようにするため、
- あちこちの環境変数に鍵の中身をぶちまける
- 必要に応じてこの環境変数の中身を鍵ファイルとして書き出し、その鍵ファイルのありかをコードに教える
- 例えば deploy 時、例えば実行時
という作業とコードの準備をしていたのだが、これらが一切不要になった。めでたい。
ではこれを可能にしたサービスを紹介する。
Cloud Source Repositories
Cloud Source Repositories | Google Cloud
- Cloud Source Repositories は GitHub と Bitbucket に対して同期する機能を持っている
- 同期の際の認証は OAuth
この時点で Google Cloud の外から中へ持ち込むという課題はクリアしている。外から中へ持ち込むのではなく中から外へ取得しにいく形になる。
なお、次の Cloud Build の関係で、リポジトリはプロジェクト単位で作ることになる。Google Cloud は staging 環境用にもう一つプロジェクトを作ることを推奨しているので、production 用と staging 用のプロジェクト別にリポジトリを持つ形になる。
※ 2020 のいつ頃からか、Cloud Build の方で直接 Cloud Build GitHub アプリを使って GitHub に接続できるようになったので、ミラーが目的でないならそちらを利用する方がよいと思います。ビルドステータスを GitHub に返すことができるので。
Cloud Build
Cloud Build - 継続的インテグレーションのためのビルドの自動化 | Cloud Build | Google Cloud
- 設定は cloudbuild.yaml か Dockerfile で行う
- 各ステップ用に Docker コンテナが用意してあってそれらに YAML ファイルから指示を出す
これだけ読むと最近よく見るクソ面倒くさい CI/CD のように見えるが、少なくとも deploy に限ってはかなり簡単。理由は以下の通り。
- Cloud Build が動き始めている段階で「目的のプロジェクトに属している状態で、かつその Project ID は環境変数として持っている
- gcloud コマンドのインストールは不要(それ用のコンテナがある)
- サービスアカウントの activation も不要(そもそもコンテナが Cloud Build 用のアカウントで動いている)
- build の動く条件は cloudbuild.yaml 内ではなく trigger の方に指定する。cloudbuild.yaml 内に面倒な分岐は書く必要がない
- 1 の関係で deploy 先のプロジェクトは分かっているのでこれの切り替えも不要
少なくとも Google Cloud 外の CI から deploy するのに比べるとマジで何倍も楽。マジ。
Cloud Build もうちょっと早く出会いたかったぜ…。
参考
gisty を知ったのはもう記憶にもないくらい昔だし、直接勧められたのは
Twitter / ゆーけー/赤松 祐希: @wtnabe gistにプロダクトコードとテストコ …
なんと3月なので9ヶ月前という体たらくでございますが、ようやく使ってみました < gisty
必要な準備
- gisty gem
- GISTY_DIR
- git の config
- 使っている Ruby が参照できる OpenSSL 証明書
gisty を使うには clone する場所を環境変数で指定しておく。post するだけでも同時に clone するので GISTY_DIR の指定は必須である。
また、git の config は最終的にこんな形になればよい。
[github]
user = USERNAME
token = XXXXXXXXXXXXXXXXXXXXXXX
いずれにしてもエラーメッセージを見ればどうすればよいかは分かるので簡単。
実は、4 でハマった。
Ruby の参照できる OpenSSL 証明書
なんかこれ前にもハマった気がするんだけど、今回は Mac OSX でどうやって解決したか。
gistyをMacから使う - Dive into the Tech World!
を見ると
$ ruby -ropenssl -e 'p OpenSSL::X509::DEFAULT_CERT_FILE'
で、どのファイルを見に行っているか分かる。見るとそこには何もファイルがない。
FreeBSD のとき(Ruby の SSL の証明書検証の失敗でハマっていた - あーありがち(2010-01-14))には ca_root 関係の ports があったけど、MacPorts にはないっぽい。それっぽいのは
$ port search cert
curl-ca-bundle @7.21.2 (net)
CA certificate bundle for curl
なので、これを入れて
/opt/local/etc/openssl/cert.pem@ ->
/opt/local/share/curl/curl-ca-bundle.crt
の link を張って対処。
使い方
$ gisty help
で確認できる。(gisty –help ではない。)
gisty post *
としてできあがったのがコレ。
gist: 748375 - fabrication with faker and forgery- GitHub
ふー。長かった。
gisty syncに注意
gisty sync は自分の作った gist 全部を local に clone しようとする。その際、
1回1回鍵の passphrase を聞かれる。
自分は普段 ssh-agent とか使わないのでものすごく面倒になって途中でやめてしまった。
sync の際には ssh-agent や keychain を活用すべし。
- ZF,ZS-top (cosina.co.jp)
- コシナ、ニコンFマウントの「カールツァイス ディスタゴンT*」 (デジカメWATCH)
※ なぜか Amazon には ZM マウントしか出てこないので写真が使えないぞ。
不覚にも全然認識してなかった。こんないいものが出ているとは。ちゃんと絞り連動用の爪までついてる! スバラシイ。(いや爪が必要なカメラ持ってないけど)
一眼なら(というかコンパクトでないなら)レンズはマニュアルで十分だと思っている人間なのでこれはとても魅力的。やっぱ狙うなら 35mm か。うーん、さすがにいいお値段しますなぁ。
最近広告が入るようになったんだけど、これが IBM の真四角のやつ。これはさすがにやめてほしい。こんなやつを入れられたらせっかくの一覧性が台無し。
休んでるんだけどこんな実験。
何をしているのかというと、例えば PukiWiki みたいにグローバルな関数と global 宣言しまくりなコードをどうにかいじりやすくするためにとりあえず class で分けて、class::func() で呼ぶようにして、必要なときだけ extends して関数を override したら少しは扱いやすくなるかなーということの確認。分かったことは、
- Perl の package とは違うので変数は使えない
- グローバルスコープだろうが class内だろうが、同じ関数を二重に定義することはできない
- extends して override することは通常通り可能
ほんとにただ :: を使って「関数の名前空間を分ける」だけに利用することは可能だってことですな。問題は global 宣言しまくりの変数の方か。
<?php
/**
* クラスを名前空間の分離だけに利用するテスト
*/
print "<pre>\n";
class Hoge {
function func() {
echo "function name divided func()\n";
}
}
function globalfunc() {
echo "function global scope globalfunc()\n";
}
Hoge::func();
globalfunc();
class Fuga extends Hoge {
function func() {
echo "Fuga::func()\n";
}
}
Fuga::func();
Hoge::func();
/*
// parse error
class First {
class Second {
function func() {
echo "Double class is available ?\n";
}
}
}
First::Second::func();
*/
/*
// Fatal Error: Cannot redeclare class Hoge
class Hoge {
function func() {
echo "Hoge::func()\n";
}
}
*/
print "</pre>\n";
?>
風邪と雪かきのダブルパンチで体力的に限界。
結論から言うとイマイチ。
PHP を使ってる人は phpdoc の方で満足してて Doxygen 方面に声が届いていないのかもしれない。個人的には PHP も JavaScript も全部 Doxygen の Javadoc スタイルでカバーできれば言うことなしだと思っていたんだけど、そんなに甘くないようだ。
まず根本的な問題として PHP に対応していると言いながら、Doxygen は 「Javadoc スタイルのコメントが PHP の中にも書ける」程度にしか認識していない。設定ファイルの中に PHP に関する設定って出てこないし。やっぱ C/C++/Java を前提に作られている感じがすごくする。細かいところではファイルのインクルードを出力してくれないとかあるんだけど、基本的には
記述量少なめのスクリプト言語向きではない
感じがする。1.2.5 → 1.3.9 で HTML と PHP の混在にはずいぶん強くなったとは言え、まだまだ PHP の特徴をつかみきれてない。当面は phpdoc + jsdoc で行くのが現実的だと思う。Doxygen の latex 出力 → PDF 変換は結構ほしい機能なんだけどなぁ。
from スラド
OS X の対応スキャナの数を増やす試みですな。
OS X は実は Classic OS を使ってなかった(MacOS 的には)門外漢の方が簡単にメリットを享受できるんだけど、デバイス周りもレガシーものはなかなか扱いが難しい。Mac って、OS はともかく本体は安くはないし、そのうえ周辺機器まで総取っ替えなんて、普通はできまへん。
こういう部分こそ Apple はもっと頑張ってほしいですな。アプリレベルで頑張ってデベロッパを窮地に追いやっちゃうようなことしてる場合じゃないんじゃないか。
(本当はあまり古い機械を壊れてないからって使い続けてる方がどうかなとも思うんだけど、普通、PC 以外の機械って壊れない限りは使い続けますわな。ベンダー側とユーザー側の意識がこれほど遠い業界って他にあるんだろうか。)