はじめに 先日、Terraform v1.5.0がリリースされました v1.5の目玉はなんと言っても import ブロックと terraform plan -generate-config-out によるtfファイルの生成ですよね〜。これで既存のリソースもimportし放題だと巷で話題です。 ところで、Terraformの特徴として、「インフラをコード化することで環境が再現できる」などと一般的に謳われています。また、Terraformには「既存リソースをimportする機能」があります。別にそれぞれ単独では間違ってはないのですが、これらを組み合わせて、「既存リソースをimportしてplan差分が出なければ元の環境を再現できる」と言えるのでしょうか？ 残念ながら現実にはそうとも言い切れません。なんとなく経験上わかってる人もいるとは思いますが、意外と気づいてない人も多そうな気がしたので、ち

はじめに Terraform v1.4がリリースされました。 上記のアナウンスでは特に言及されてないのですが、v1.4のUpgrade Guideに以下のような記載があり、TF_PLUGIN_CACHE_DIRと.terraform.lock.hclの組み合わせの挙動が若干変更になっています。 Provider caching during terraform init This change affects those who rely upon global provider caching and not the dependency lock file. terraform init now ignores entries in the optional global provider cache directory unless they match a checksum alr

data "aws_caller_identity" "current" {} output "account_id" { value = data.aws_caller_identity.current.account_id } 若干補足しておくと、 "${}" 自体が廃止されたわけではなく、今でも文字列の中に変数を埋め込む場合には必要ですが、式が変数の参照しか含まない場合は不要で、v0.13.4以降は冗長な書き方は警告が出ます。ちなみにv0.14のfmtはもう一歩踏み込んで、この書き方を自動で修正するようになりました。古いサンプルコードを雑にコピペできるようになってべんり。 Terraformではなく汎用的なHCLそのものの仕様を調べたいときは、 hashicorp/hcl にありますが、本稿執筆時点ではデフォルトのmasterブランチはまだHCL1であることに注意して下さい。 HCL

はじめに MacでDocker使うの重いですよね？ 手元のローカル開発環境のノートPCはMacで、Dockerコンテナという構成は、小さなアプリケーションであれば快適です。 が、そこそこ大きなモノリシックなアプリケーションとかを動かそうとすると、クッソ重くてストレスフルです。 Dockerは新しめのLinux Kernelで動かすと効率的なんだけど、Macで動かそうとするとIOとか遅いし、なんなのかもっさりします。 かと言って、LinuxをノートPCに使うのは茨の道です。（個人の見解です） そんな今日このごろ、Docker CE 18.09からssh経由でリモートのdockerデーモンに接続できるようになるようです。 mobyメンテナの須田さん、マジ神 つまり、dockerコマンドだけ手元のMacで動かして、dockerデーモンはAWSのEC2上にLinux立てたところで動かすみたいなこと

はじめに Terraform職人のみなさんは無限に「ぼくのかんがえたさいきょうのディレクトリ構成」についてメリデメを議論していますが、未だに銀の弾丸のようなベストプラクティスは見つかっていないようです。なぜでしょう？ それは最適解がサービスの規模、組織の構造、メンバーのスキルなどいろいろな変数に依存しているからです。さらに悩ましいことに、これらの要因は固定ではなく変化するので、ある時点での最適解が時間の経過とともに現状にうまくマッチしなくなり、いわゆる技術的負債になったりします。つらい。 個人的な解釈では、組織の成熟度に合わせてモジュールを細かく切っていく方向に徐々に向かっていくというような傾向があるようには思いますが、組織のフェーズによってうつりかわるものなので、唯一の最適解というものはそもそも存在しないのです。そんなこんなで、最近の私の関心事は、理想と現実がずれてきたときに、どうやった

はじめに 以前、Terraform本体/プロバイダ/モジュールのバージョンアップを自動化するtfupdateというツールを書いたのですが 、Terraformのバージョン制約だけじゃなくて、もうちょっと汎用的にHCLがコマンドで編集できたら便利では？と思って、hcleditというツールを書いてみました。 まだできることはそれほど多くはないのですが、設計方針というか特徴はこんなかんじです。 標準入出力でHCLを読み書きするので、簡単に他のコマンドとパイプして組み合わせることが可能です。 HCLのまま直接トークンを書き換えるので、可能な限りソースコード内のコメントを維持します。これは既存のHCLファイルをスクリプトなどで一括処理するのに便利です。 Terraformには依存せず、汎用的なHCLを対象にしているのでスキーマレスです。 HCL2対応(というかHCL1はサポートするつもりはありません

はじめに Terraformを長く運用しているとリソース名をリネームしたいというようなリファクタリングが稀によくあります。 これは terraform state mv コマンドを使うとできるのですが、このコマンドはtfstate(Terraformの状態管理ファイル)をデフォルトではその場で書き換えてしまいます。 https://www.terraform.io/docs/commands/state/mv.html しかしながらチーム開発をしている場合、 *.tf はgitでバージョン管理し、 tfstateはリモートのbackend(AWS S3とか)に保存するという管理方法が一般的です。つまり、リモートのtfstateをその場で書き換えてしまうと、masterブランチの状態と差分が出てしまいます。 tfファイル変更のレビュー前に、リモートのtfstateを書き換えずに、terraf

はじめに Terraform職人あらためシニアHCLエンジニア（？）の @minamijoyo です。 最近はHCL(HashiCorp Configuration Language)のパーサで遊んでいます。Terraformの設定をパースしていいかんじに書き換えることができるようになると夢が広がりますよね？ そんな個人的な趣味の産物として、Terraform本体/プロバイダ/モジュールのバージョン制約をいいかんじに一括で書き換えてくれる tfupdate というツールを書いたので紹介します。 これをCIとかジョブスケジューラで流せば、毎日最新版をチェックして、差分があれば自動でバージョンアップのPull Requestを生成したりできます。つまり、「ぼくのかんがえたさいきょうのTerraform版Dependabot」ができるのだ。 ※この記事は クラウドワークス Advent Cale

はじめに Dockerであんなコンテナやこんなコンテナを動かしてると、なんかうまく動かなくて、デバッグのためにtcpdumpとかstraceなどのツールが使いたくなることが稀によくあります。 そんな時、デバッグ対象のコンテナ内にツールを一時的にインストールしちゃうというのが、まぁ簡単で分かりやすいんですが、デバッグ対象のコンテナを汚すのはできれば避けたいところです。 Dockerのコンテナの分離というのは、結局のところLinuxのリソースの名前空間の分離であるので、逆に同じ名前空間を共有すれば、デバッグ用に立てた隣のコンテナから、デバッグ対象のコンテナのネットワークやプロセスの状態を観察することも可能です。 また、docker buildはDockerfileを標準入力から受け取ることもできるので、ワンライナーにしてデバッグ用のコンテナをシュッと呼び出せるようにしてみました。 TL;DR

ってなってて、これはもう完全に草w とか言ってたのが2018年の10月のことで、懐かしいです。 で、結局最終的なv0.11とv0.12のgitの差分がどうなったのか気になるじゃないですか。 というわけで計測してみると、これぐらいです。 [terraform@master|✔]$ git diff --shortstat v0.11.14...v0.12.0 5255 files changed, 606655 insertions(+), 1336138 deletions(-) warning: inexact rename detection was skipped due to too many files. warning: you may want to set your diff.renameLimit variable to at least 1922 and retry t

以前auditdでLinuxのファイル改竄検知をやりたくて、こんなのを書いた。 auditdでLinuxのファイル改竄検知を行う 実際に監視してみるとノイズが色々出るので、システムコールレベルで監視条件をチューニングしたくなった。 例えば以下のようなメッセージを無視したい。ちょっと見づらいので改行してるが、実際には1行です。 Nov 25 11:45:01 myhost audispd: node=myhost type=SYSCALL msg=audit(1480041901.111:5431): arch=c000003e syscall=83 success=no exit=-17 a0=7ffc046bdb7a a1=1ff a2=7ffc046bc750 a3=7ffc046bc1e0 items=1 ppid=17266 pid=17276 auid=502 uid=502 g

はじめに この記事は CrowdWorks Advent Calendar 2017 の8日目の記事です。 Terraform職人の @minamijoyo です。Infrastructure as Codeしてますか？ インフラのコード管理に Terraform を使い始めて2年ちょっと、本番環境で運用していると日々色んな学びがあるので、Terraformやってみた系の入門記事では語られない、現場の運用ノウハウ的なものを共有してみようかと思います。 Terraformを使い始めた or 使っている人が、こんなときどうするの？っていうときに参考になれば幸いです。 書き始めたら超長文になりました。概要は以下のとおりです。 公式ドキュメントを読もう tfファイルを書く技術 インデントを揃える 組み込み関数に親しむ lifecycleブロックを使う リソースの差分を無視する リソース再生成のとき

はじめに Rundeck便利なんだけど、ユーザ管理が貧弱すぎて、デフォルトだとWeb画面からユーザの追加すらできない。 じゃあどうやってユーザを追加するかというと設定ファイルにユーザ名とパスワードのハッシュを書くらしい。えっ、まじで？ 最近新しく作ってるサーバは基本Docker化しているので、ユーザ追加するたびに設定ファイルとかいじりたくないんだけど。。。 ほらイメージ更新したら、Dockerコンテナ再起動しないといけないし、それだけのためにジョブ止めたくないし。 なんかよい方法はないかと思って公式ドキュメント読んだらLDAP認証とかActiveDirectory認証とかのは出てくるんだけど、そーゆーのはあんまり好きじゃないんだ。Google認証とかGitHub認証とかOAuth2使えないの？って思って、Issue/PullRequestを眺めてたらこんなのを見つけた。 rundeck/r

Dockerフレンドリーなコマンドは設定ファイルなしでも引数でいろいろ挙動が指定できて便利なんだけど、 コマンドの引数の指定が長くなりがちである。 例えばoauth2_proxyはシングルバイナリで、設定ファイルもあるけど、すべての設定が引数で指定できる。 何も考えずに素朴に並べるとこんなかんじで、起動コマンドがクッソ長くなる。 version: '2' services: oauth2_proxy: image: oauth2_proxy command: /bin/oauth2_proxy -provider="github" -github-org="${OAUTH2_PROXY_GITHUB_ORG}" -github-team="${OAUTH2_PROXY_GITHUB_TEAM}" -http-address="0.0.0.0:4180" -redirect-url="htt

はじめに この記事はGo (その3) Advent Calendar 2016の18日目の記事です。 最近Goの勉強がてら、とある社内向けWebサービスのAPIを叩くCLIツールを書いてます。 有名どころのWebサービスならたいてい既に誰かがSDKなりCLIツールを作ってたりするので、それを使ればよいと思いますが、クローズドな社内向けのWebサービスとかだと、まぁ欲しい人が自分で書くしかないですね。 で、簡単なプロトタイプが動くようになったので、このあたりで覚えたことを整理してまとめてアウトプットしておこうかなと思います。 内容的には サブコマンド形式のCLIツールを作り方 spf13/cobraの使い方 viperと連携した透過的な設定ファイルの読み込み version番号の埋め込み、Makefile pkg/errorsによるエラーの伝搬、contextを使ったタイムアウト 標準のne

docker swarm 1.12.xのmanager1台/worker1台構成でクラスタ手動フェールオーバ/フェールバックして再起動する手順Dockerswarm はじめに 先日swarm manager1台/worker1台の構成で、おもむろにmanagerノードのOS再起動したらクラスタがぶっ壊れて悲しい思いをしたので、ちゃんとswarmクラスタのメンテナンス手順を調べました。 クラスタ運用する場合はスプリットブレインを避けるためにmanagerノードを3台以上立てるのが理想的ではありますが、開発環境などではそこまでリソースを割けないのでmanager1台運用にしてます。で、おもむろにmanagerを止めるとクラスタが壊れるので、安全にやるには一旦workerをmanagerに昇格してフェールオーバさせて、managerノードを再起動し、フェールバックさせるという手順を踏む必要があり

はじめに Dockerコンテナ内でdockerコマンドが使いたい。 このエントリは、いわゆるDocker in Dockerでネストしたいわけではなくて、同じdockerデーモンを共有する兄弟コンテナを立てたい場合の話です。 どういうユースケースかというと、 社内Heroku的なアプリケーションをDockerコンテナで動かして、Web画面をポチポチするとdocker service createしたいとか HubotをDockerコンテナで動かして、特定の発言に反応してdocker runしたいとか JenkinsをDockerコンテナで動かして、CIの実行でdocker runしたいとか Dockerを使ってるとなんでもDockerにしたい病になるので、Dockerコンテナを起動するような必要があるアプリケーションもDockerで管理したい。 作戦としては必要なイメージにdockerクラ

はじめに この記事は Docker2 Advent Calendar 2016 の11日目の記事です。 ちょっとした気まぐれでDocker Engineをソースコードからビルドしてみようかと思いたち、試しにやってみたのでやり方を共有します。 ビルド手順自体は開発者向けに公式ドキュメントの Open Source at Docker というページに丁寧に説明されているので、この辺を参考にしつつ進めていきますが、公式の説明はgitの説明とかそのレベルの説明いる？ってぐらいちょっと丁寧すぎて逆に冗長なので、ここではDocker固有の要点だけ抑えつつ、気になったポイントを補足しつつ説明していきます。 以下の手順は執筆時点の最新のmasterブランチ(1.14.0-dev@001cbc4)で試してますが、最新の情報については、適宜公式ドキュメントを確認してください。 ちなみに手元の環境はMac OS

はじめに この記事はCrowdWorks Advent Calendar 2016 の1日目の記事です。CrowdWorksのエンジニアが毎日なにかを書きます。 Docker 1.13がそろそろ出そうです。この記事を書いてる時点ではまだRC版ですが、正式版のリリースは2016/12/8頃の予定となっているようです。(※2017/01/20追記：当初予定より１ヶ月ちょっと遅延して最終的に2017/01/18に正式版がリリースされました。) Docker 1.12ではDockerクラスタを管理するswarmがDocker Engine本体に統合されましたが、Docker 1.13ではそのswarm関連の多くの改善が含まれています。 特に注目すべきはswarmクラスタに複数のサービスをまとめてデプロイする docker stack コマンド群のExperimental指定が外れたことと、dock