Dockerfile

TL;DR Alertmanagerの設定には一部Secretが含まれる バージョン管理システムに入れたくない initContainerでconfdを使って設定ファイルを生成する Alertmanagerの設定の一部をSecretに格納できる confd kelseyhightower/confd は非常に軽量な設定ファイル管理ツールです。基本的にはテンプレートエンジンですが、多くのバックエンドデータストアからデータを持ってきて、設定ファイルに書き出すことが出来ます。 また、事前処理や事後処理を行うことが出来るので、例えば設定ファイルを書き換えたあと、リロードする、というところまでconfdで行うことが出来ます。 Install Go言語で書かれているため、インストールは非常に簡単で、バイナリをダウンロードしてきて実行権限を与え、パスの通ったところに置くだけです。バイナリはリリースページ からダウンロードすることが出来ます。 使用方法 confdを使用するためには、三つのものを用意する必要があります。 テンプレートリソース テンプレート データストア テンプレートリソース テンプレートリソースには、どのテンプレートを使用して、どんなキーでデータストアからデータを取り出し、完成した設定ファイルをどこに置くのか、事前処理・事後処理はどんなものかを記述します。書式はTOMLで、慣れ親しんだ(慣れ親しんでない？)iniファイルの様に気軽に書くことが出来ます。/etc/confd/conf.d以下に配置します。 テンプレート テンプレートはその名の通り、設定ファイルのテンプレートです。ここに、データストアから取り出したデータを合わせて設定ファイルを作成します。書式はGo言語のtext/template に準じます。/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で使用して、設定ファイルを生成します。...

Travis CIでDockerfileをテストする等、dockerを使用したい場合、以下の様に.travis.ymlに記述することでdockerを有効にすることできます。 1 2 3 4 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に追加します。 1 2 3 4 5 6 7 8 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日現在 ↩︎

Docker 17.05から、新機能としてmulti-stage builds というものが導入されました。 これは、コンテナイメージをより最適化するために有用な機能で、Dockerfileからコンテナイメージをビルドする際にビルド依存のライブラリ/環境とランタイム依存のライブラリ/環境を切り分けることができる機能です。 具体例を見てみましょう。 Go言語で書かれた何らかのアプリケーションをコンテナ上で動かすことを考えます。 以前までであれば、以下のような二つのDockerfileを用いて作成します。 まずはビルド用Dockerfileです 1 2 3 4 FROM golang:1.7.3 WORKDIR /go/src/github.com/someone/foo/ COPY app.go . RUN GOOS=linux go build -a -o app . つぎに、実行用のDockerfileです。 1 2 3 4 FROM busybox:latest WORKDIR /root/ COPY app . CMD ["./app"] このようにすることで、ビルド時にはGo言語のビルド環境が入ったコンテナを、実行時は(Go言語環境は不要なので)busyboxコンテナを使用することで、実行イメージを小さく抑えることができます。 しかし、このように二つのDockerfileを使用する場合、コンテナイメージのビルド手順が煩雑になる、複数ファイルのため管理しにくいなどの問題がありました。 multi-stage buildsを実装されたことで、以下のようにDockerfileを一つにまとめることができます。 1 2 3 4 5 6 7 8 9 FROM golang:1.7.3 AS build WORKDIR /go/src/github.com/someone/foo/ COPY app.go . RUN GOOS=linux go build -a -o app ....