morimorihogeです。最近やたらインフラの仕事をしてることが多いです。インフラ仕事は嫌いじゃないのですが、集中して作業する時間を確保しないとミスが怖いので作業時間の確保が大変ですね。ゲームする時間も取らないといけないのに。忙しい忙しい。
またしても小ネタです。
オンプレ？VM？Container？
最近はDockerをはじめとするContainerで、HVMとかPVな感じで普通にLinuxが起動してくる環境ではない環境を触ることも増えました。
Dockerを代表とするContainer環境はここ3〜5年くらいで一部の意識高い層が使うものからかなりコモディティシフトしてきたように思えます。事例も増えたしproductionで使ってるケースも増えました。
とはいえ、Containerは設計思想がVMベースとは異なるので、これまでVPC等の仮想マシン環境やオンプレを使ってきた人達にとっては色々とルールが異なるので戸惑うこともあります。
また、最近はprovisioningをChefやAnsible、Itamae等で自動化するといった流れもあるのですが、開発者はDocker環境で構築するけど本番環境はVMといったケースもあり、環境毎に動かないコマンドがあったりする場合には個別に制御する必要が出てきます。インフラエンジニアは意識高い所をやろうとするとかなり辛みもあるのでその辺のさじ加減が求められてる感じありますね。
弊社では開発環境はほとんどDocker環境になりましたが、本番環境ではまだ限定的な利用としていることが多いです。受託開発なんかだと、自分達しか保守できないものをリリースして納品するというのはやや抵抗があるので、なるべく引き継ぎできるエンジニアの多い普通のVM環境を想定した方が後々辛みを生まないだろう、という落としどころでやっています。
ただ、自由度が大きなプロジェクトなんかではアリですね。最近は新しい技術を使ってOKというお客様も増えましたので、品質が上がる方向に良い技術は取り入れていっています :)
Docker Containerかどうかは /.dockerenv があるかどうかで分かる
長々と前口上を書きましたが、Docker Containerかどうかは /.dockerenv ファイルの有無で分かります（以下は公式ubuntuコンテナ）。
このファイルはDocker Containerのセットアッププロセスっぽいところで定義されている ので恐らくどんなContainerでも使って良いと思います。
他にも /.dockerinit というファイルがあったようですが、こちらはv1.11から削除されているようなので今は使わない方が良いでしょう。
シェルスクリプトの中から調べるなら普通にtestコマンドを使えば良いので、Itamae recipeであれば
# systemd依存な処理
not_if 'test -f /.dockerenv'
# Dockerの場合の代替処理
only_if 'test -f /.dockerenv'
みたいな感じで書けば良いかと思います。
まとめ
そんなわけでインフラ作業のメモがてら記事にしてみました。なおこれはDockerを使っている場合の話なので、systemd-nspawnなど別のコンテナ環境を使っている場合には使えないです。あしからず。