docker

思い切ってKubernetesを構築、試験運用を始めました。Ubuntu Server 20.04のMicroK8sです。 docker-compose で動作するところは確認できていたので余裕かと思っていたのですが、はまってしまいました。 症状は、 CrashLoopBackOffで再起動が続く状態。これ当然まともにコンテナが起動せずに終了してしまっているからなんですが、手元の環境ではDockerfileとdocker-composeの合わせ技で奇跡的にうまく動作していたため、Kubernetes側の問題だろうとあれこれ調査して時間を浪費してしまいました。 KubernetesではDockerfileによるbuild済みのコンテナイメージを起動します。docker-composeに記載している処理は、Kubernetesのyamlに記載するか、Dockerfileに記載する必要があります。 が、Kubernetesのyamlに同じ内容を記述できるとは限らず、また記述できても同じ動作をするかはわかりません。ですので、極力Dockerfileに記載してdocker-compose.ymlはシンプルにとどめておいたほうがよさそうと感じました。 また、内部の名前解決用に使用しているDNSは、解決できないと8.8.8.8にforwardしてしまう。Kubernetesの外の社内サーバを名前で参照する場合には、dnsConfigなどの設定でforward先を変更する必要がある。 https://qiita.com/sugimount/items/1873d9d332a25f5b0167

一人で開発していても、テストやデプロイにミスが出る可能性はある。 CIの導入を検討した。 結論としては、CI用途のサーバーを別途導入することはしない。現在主に開発しているC#プロジェクトでは、CIにもWindowsが必要となる。ライセンス費用が必要だし、Dockerでお手軽に再構築できる環境としたいため。 やりたいことは以下の通り リポジトリのPRコードのビルド テスト、結果通知、OKならmerge DBの構成情報に関して、リポジトリと実環境で差異がないかチェック 1,2点目はWindowsを避ける以上、不可能。開発時に自端末でテストを行い、PRのコメントに記載する運用で対応。 3点目は、毎日定時に実行する普通のバッチでなんとかなるレベル。 テストに関して、DBに関連するところは一切やっていない。面倒なので。 一方で内製アプリの殆どはDBのデータを持ってきてそのまま表示し、加工して更新する程度のものがほとんどのため、結果ほとんどテストがない状態。 本番環境に接続する際には専用のクラスを利用しているので、テスト環境用にも同様のクラスを作成し、テスト実行時にはそちらを利用してDB接続するようにしてテストを行うようにする。まずこちらが優先。 Dockerでdumpファイルから空のデータベースを作成するDockerfileを作成し、開発にすぐに利用できるようにする。 その上で、上記の運用で品質をさらに高めていく。

Docker Hostのスタートアップサービスにて、Docker ContainerをBuild, Upするスクリプトを実行しているのですが、以下のようなエラーが大量に発生してUpしていませんでした。 8月 26 03:07:44 sever-name dockerd-current[864]: time="2018-08-26T03:07:44.615597202+09:00" level=error msg="could not calculate checksum for \"fb1077f711d4fc436c0b6e115f8cdb0c871f46c818ec998efbf489df5e4a4de5\", \"devmapper: Unknown device fb1077f711d4fc436c0b6e115f8cdb0c871f46c818ec998efbf489df5e4a4de5\"" ... 8月 26 03:07:44 server-name dockerd-current[864]: time="2018-08-26T03:07:44.617971873+09:00" level=error msg="migration failed for 866ae31005298fd6f1bb2944418eb34969b16ead2a18ed332fa011a311f3b4b2, err: open /var/lib/docker/graph/60e65a8e4030022260a4f84166814b2683e1cdfc9725a9c262e90ba9c5ae2332/json: no such file or directory" ... ログの内容を見ると、以下のissueと同じように見える。再起動前にDockerのバージョンが1.13.1-74 に上がったようだし… https://github.com/moby/moby/issues/20147 対処方法は記事からは判明せず。 スタートアップスクリプトを手動で実行したところ、普通にupしたので、docker containerが起動していなければスクリプトを再度実行するcronジョブを登録することで暫定対処した。

storage driverがdevice mapperの場合のディスク容量 device mapperの場合は、既定のディスク容量が10GBほどとなる。Oracle DatabaseのDockerコンテナをbuildするとこける。 storage driverを最初からoverlay2 にするための方法 インストール時にデバイスタイプにLVMを指定すると、Dockerのstorage dirverはdevice mapperになる。 https://docs.docker.com/storage/storagedriver/select-storage-driver/#supported-backing-filesystems 基本ディスクを選んで、xfsを選んでやる必要がある。 さらに、CentOS7 1511(minimal)の場合は上記の手順でもやはりdevice mapperが既定となる。overlayを使用するための設定がされていないためと想像される。 https://docs.docker.com/storage/storagedriver/overlayfs-driver/ CentOS7 1804(minimal)で基本ディスク(xfs)でインストールすれば、overlay2がstorage driverとして設定される。

Host側でのresolv.confを変更したのだが、containerには、docker-compose restartやstop -> startでは反映されない。 一度downしてからupする必要がある。