今朝メーリングリストで通知が来たので試してみた！
GitHubとDockerHubを連携させて自動でイメージのビルドを行ってみる
ローカルにDocker Registry立てたりGCR使ったりはしたことあったけど本家たるDockerHubって使ったことが無かったので、思い立ってちゃんと使ってみることにした。
DockerHubにはAUTOMATED BUILDというGitHub（もしくはbitBucket）のリポジトリにDockerfileを含んだpushすると自動でイメージをビルドしてくれる機能がある。
実際にイメージを使う側としても、Dockerfileが公開されてて人為的な操作の入らないAutomated Buildじゃないと怖くて使う気がしないわけで、DockerHubに公開する際はどんどん活用していきたい。
何はともあれ、最初にアカウントを作成しておく。
https://hub.docker.com/hub.docker.com
（最初慌ててここでリポジトリを作成してしまったのだが、後からAutomated buildを設定する項目は見当たらなかったので多分最初からそれ用に作らないといけなそう。要注意だ。）
続きを読むDocker/Docker ComposeのSecretsを試す
接続情報などコンテナ内への記述が憚られる情報について外部から与える方法としてsecretsがdocker 1.13/docker-compose.yamlのformat ver3.1からサポートされた。
予めdocker secretコマンドでファイルを登録するか、もしくはdocker-compose.yaml内でファイルを指定することで、それらのファイルがコンテナ内の/run/secretesディレクトリ以下にマウントされる。
kubernetes学習番外編 コンテナ起動時のコマンド実行
何かしらの設定ファイルが必要なアプリケーションをDockerイメージとして作成する場合、可搬性を考慮するならコンテナ内に予め特定の状況の設定ファイルを格納するのではなく、コンテナ起動時に環境変数から設定ファイルを生成するのが望ましかったりする。 (設定ファイルをマウントするという手もあるけど、あんまエレガントじゃない気がするんだよね。それこそK8Sだと手間だし。設定は全部環境変数で賄う形に統一してしまうのがDockerの運用としては美しいと思う。)
そんな場合によく用いられる手段の一つがenvsubstを用いて設定ファイルを生成した後にアプリケーションの起動コマンドを実行するという方法であり、具体的には
- CMDとしてアプリケーションの起動コマンドを設定
- ENTRYPOINTなんかで生成コマンドを終えた後に、CMD設定値なり実行コマンドなりが引数で渡ってくるのでそれをexecで実行
なんて作りにしたりする。
こんな形にしておくと嬉しいのが、commandを差し替えても設定ファイルそのものは生成されることであり、同じイメージで起動オプションだけを変えたコンテナを立てたりする場合に便利だったりする。
というわけで僕はよくENTRYPOINT+CMDな構成のイメージを作るんだけど、最近K8Sの案件で意図と違う挙動をしたりすることがあったので、ちょっと検証してみた。
続きを読むkubernetes学習その４ GCRの認証
Dockerイメージの保管場所としてGoogle Container Registry(GCR)を用いる場合、同じプロジェクト内の例えばGoogle Container Engine(GKE)なんかでpullする分には認証も要らないのだけど、開発環境としてminikubeだったり他の場所でk8sを動かしたりしている場合には認証を行う必要がある。
個人アカウントでの認証を用いる場合とサービスアカウントを発行して用いる場合の２通りを示した。
続きを読むkubernetes学習その３ スケールとかB/Gデプロイとか
引き続きk8s学習話。
前回k8sでPodとServiceという概念や、その中で名前やラベルといった抽象的な表現を用いて扱うことを学んだ。
今回は実際にそれを利用してスケールしたりB/Gデプロイ的なことをしてみる。
続きを読むkubernetes学習その２ 最低限文化的なサービスを立ち上げてみる
引き続きkubernetesの使い方について学習。
前回作ったminikubeの環境で実際にyamlファイルを用いた操作を行ってみる。
最低限把握しておくこと
作業の前にザックリと用語と概念を把握。
- Node: 実際にコンテナが動いているマシンのこと。
kubectl get nodeで一覧を見ることができる。 - Pod: 同一のNode上で動かすコンテナ群。スケールする場合このPod単位での操作になるので、機能を実現する最低単位で分割していくと良さそう。
- Service: それぞれのNode/Podで動作しているコンテナ同士や外部との通信を司る概念。
- Resource: PodとかServiceとかいった概念をk8sではこう呼ぶらしい。
- Manifestfile: Resourceの設定ファイルで、yamlやjsonなどの形式で記述できる。
今のところの大雑把な理解でいえば、Podがdocker-compose.yamlでいうところのservicesおよびvolumes項、Serviceがnetworks項にあたりそう。
この業界では「インスタンス上で動く何かしらの機能」を指して「サービス」と言ったりする（現にこの記事のタイトルもdocker-composeは前者の意味で使ってる）わけだけど、それと混同しないように注意したい。
続きを読む