confd + initContainerでAlertmanagerの設定をSecretに逃がす

TL;DR Alertmanagerの設定には一部Secretが含まれる バージョン管理システムに入れたくない initContainerでconfdを使って設定ファイルを生成する Alertmanagerの設定の一部をSecretに格納できる confd kelseyhightower/confd は非常に軽量な設定ファイル管理ツールです。基本的にはテンプレートエンジンですが、多くのバックエンドデータストアからデータを持ってきて、設定ファイルに書き出すことが出来ます。 また、事前処理や事後処理を行うことが出来るので、例えば設定ファイルを書き換えたあと、リロードする、というところまでconfdで行うことが出来ます。 Install Go言語で書かれているため、インストールは非常に簡単で、バイナリをダウンロードしてきて実行権限を与え、パスの通ったところに置くだけです。バイナリはリリースページ からダウンロードすることが出来ます。 使用方法 confdを使用するためには、三つのものを用意する必要があります。 テンプレートリソース テンプレート データストア テンプレートリソース テンプレートリソースには、どのテンプレートを使用して、どんなキーでデータストアからデータを取り出し、完成した設定ファイルをどこに置くのか、事前処理・事後処理はどんなものかを記述します。書式はTOMLで、慣れ親しんだ(慣れ親しんでない?)iniファイルの様に気軽に書くことが出来ます。/etc/confd/conf.d以下に配置します。 テンプレート テンプレートはその名の通り、設定ファイルのテンプレートです。ここに、データストアから取り出したデータを合わせて設定ファイルを作成します。書式はGo言語の<code>text/template</code> に準じます。/etc/confd/templates以下に配置します。 データストア そして、データストアにデータを入れる必要があります。 confdは、データストアとして、次のものをサポートしています(2018/08/20現在) etcd (GitHub: coreos/etcd ) consul (GitHub: hashicorp/consul ) dynamodb redis (GitHub: antirez/redis ) vault (GitHub: hashicorp/vault ) zookeeper (GitHub: apache/zookeeper ) rancher metadata-service (GitHub: rancher/rancher , rancher/metadata ) AWS Systems Manager パラメータストア 環境変数 ファイル Alertmanager Alertmanager はPrometheus からのアラートを受け取り、適切にハンドルするためのアプリケーションです。Alertmanagerの設定はYAMLで記述するのですが、SMTPのパスワードやSlack のIncoming Webhook URL 等、平文でバージョン管理システムに入れるのは躊躇われるデータを含みます。しかし、環境変数などから設定をすることも出来ないため、平文で記述するか、何らかの方法で設定ファイルを編集してから使う必要があります。 特に、Prometheus/AlertmanagerはKubernetes と併せて使用されることが多いため、出来ればKubernetesのSecret機能を使用したいところです。 そこでconfdをinitContainerで使用して、設定ファイルを生成します。...

2018-08-20 · nasa9084

Travis CIでdockerのバージョンを最新にする

Travis CIでDockerfileをテストする等、dockerを使用したい場合、以下の様に.travis.ymlに記述することでdockerを有効にすることできます。 sudo: required service: - docker が、その際のdockerのバージョンは17.03.11と、最新版ではありません。 特に問題なのが、multi-stage build は17.05からの機能であるということです。 Travis CIで使用できるdockerでは、multi-stage buildを使用したDockerfileはビルドすることができず、常にfailedとなってしまいます。 解決方法 Travis-CIでDockerのバージョンを上げるには、以下の記述を.travis.ymlに追加します。 sudo: required service: - docker before_install: - sudo apt-get update - sudo apt-get install -y -o Dpkg::Options::="--force-confnew" docker-ce dockerの再起動などの処理は必要ありません。 以上の記述により、Dockerのバージョンが最新版にアップデートされ、multi-stage buildも使用できるようになります。 2017年10月18日現在 ↩︎

2017-10-18 · nasa9084

Docker multi-stage builds

Docker 17.05から、新機能として<strong>multi-stage builds</strong> というものが導入されました。 これは、コンテナイメージをより最適化するために有用な機能で、Dockerfileからコンテナイメージをビルドする際にビルド依存のライブラリ/環境とランタイム依存のライブラリ/環境を切り分けることができる機能です。 具体例を見てみましょう。 Go言語で書かれた何らかのアプリケーションをコンテナ上で動かすことを考えます。 以前までであれば、以下のような二つのDockerfileを用いて作成します。 まずはビルド用Dockerfileです FROMgolang:1.7.3WORKDIR/go/src/github.com/someone/foo/COPY app.go .RUN GOOS=linux go build -a -o app .つぎに、実行用のDockerfileです。 FROMbusybox:latestWORKDIR/root/COPY app .CMD ["./app"]このようにすることで、ビルド時にはGo言語のビルド環境が入ったコンテナを、実行時は(Go言語環境は不要なので)busyboxコンテナを使用することで、実行イメージを小さく抑えることができます。 しかし、このように二つのDockerfileを使用する場合、コンテナイメージのビルド手順が煩雑になる、複数ファイルのため管理しにくいなどの問題がありました。 multi-stage buildsを実装されたことで、以下のようにDockerfileを一つにまとめることができます。 FROMgolang:1.7.3 AS buildWORKDIR/go/src/github.com/someone/foo/COPY app.go .RUN GOOS=linux go build -a -o app .FROMbusybox:latestWORKDIR/root/COPY --from=build /go/src/github.com/someone/foo/app .CMD ["./app"]一行目のAS build、九行目の--from=buildがポイントです。 AS hogeを使用することで、ビルドステージに名前をつけることができます。 加えて、COPYに--from=hogeの形で名称を指定することで、ビルドステージから直接ファイルをコピーしてくることができます。 これまでは一旦ホストにファイルを取り出してから再度コピーするという形だったので、かなり手間が省けると言えるでしょう。 golangイメージの中でも小さい、golang:alpineとbusyboxイメージでは、イメージサイズが200倍以上違うため、これは重要なアップデートと考えられます。

2017-08-17 · nasa9084