Docker

知らなかったのでメモしておく。 説明や利用方法はこちらの記事にまとまっている。 Dockerのマルチアーキテクチャイメージについて調べてみた｜Developers.IO ・単一のDockerイメージで複数種類のOSやCPUアーキテクチャをサポートさせることができる。 ・このイメージを起動させると、Dockerが実行されているホストのアーキテクチャに応じて適切なイメージが自動で選択される。 ・Docker Hub上の公式イメージの多くはマルチアーキテクチャをサポートしている。 作成方法は公式ドキュメントに書かれている。 Leverage multi-CPU architecture support｜Docker Documentation Experimental な buildx サブコマンドを使う。Docker Engine 19.03.8 から使える。 Docker for Mac の場合、Settings > Command Line から experimental features を有効にする必要がある。 Settings > Docker Engine で以下も設定する必要もあるかも。私はすでにこうなっていた。 { "debug": true, "experimental": true } 前述の公式ドキュメントの通りにやると Docker Hub に masutaka/demo:latest が push される。 https://hub.docker.com/repository/docker/masutaka/demo/tags ※ masutaka/demo:default は $ docker build -t masutaka/demo:default . で普通にビルドした Docker Image。 builder は忘れずに元に戻しておく。 $ docker buildx ls NAME/NODE DRIVER/ENDPOINT STATUS PLATFORMS mybuilder docker-container mybuilder0 unix:///var/run/docker....

先週 Building Docker Images with heroku.yml が GA になってました。 Building Docker Images with heroku.yml Is Generally Available heroku.yml は使ったことがなく、最近 Redash を Docker on Heroku で 立て、モチベーションが上がっているので、早速試してみました。 今までの方法と比較しながら、気づいたことを中心にまとめていきます。 Container Registry & Runtime (Docker Deploys) 今まで Heroku で Docker を使うときは、このようにデプロイしていました。 $ heroku container:push web # (1) $ heroku container:release web # (2) (1) でローカルで docker build して、Heroku の Docker registry に push します。 (2) で push した Docker Image をデプロイします。 heroku への git push は不要でした。ローカルで docker build するの...

先日素振りがてら、個人の小さな Rails リポジトリを Dockerize しました。 https://github.com/masutaka/github-organization-watcher/pull/45 現在クローズドβの CircleCI 2.0 は Docker 前提らしいので、これも素 振りがてら移行してみました。 https://github.com/masutaka/github-organization-watcher/pull/48 CircleCI 2.0 はここから申請すれば、すぐ使えるようです。 https://circleci.com/beta-access/#request-access 移行前の印象 (1) 1.0 では宜しくやってくれたけど、2.0 は circle.yml に全部書く必 要があるみたい。面倒そう。 (2) とは言え、Dockerfile や docker-compose.yml があるし、ちょっと やれば動くだろう。 (3) Alpine Linux の Docker Image 使えば、1.0 よりは速くなるのかな。 移行後の感想 (1) 予想に違わない面倒くささ・・・！ オートマがマニュアルになった感じ。 (2) 使えませんでした ／(^o^)＼ 参考にはなったけど。 (3) 速い・・・！！！（移行前: 01:38 、移行後: 00:30 ） 両方ともキャッシュあり状態です。Alpine Linux もそうかもしれないけ ど、とにかくキャッシュのリストアが速かったです（後述）。あと、 CircleCI のビルドが全体的に高速です。 circle.yml circle.yml は 1.0 から 2.0 に移行して、このようになりました。同じ ディレクトリにある Dockerfile や docker-compose....

ローカルに nginx や mysql が起動していたり、gem install のためだけ に cmake や icu4c を brew install するのは嫌になったので、三連休で 出来るだけ Dockerize しました。仕事の素振りも兼ねています。 nginx このブログの記事を書く時のプレビューや、雑多な html ファイルの表示 に使っています。 今まで $ brew install nginx して、nginx.conf も別途管理していまし たが、以下のような雑な docker-compose.yml で、雑にマウントするだけ で良くなりました。 version: '3' services: nginx: image: nginx:alpine ports: - 8080:80 volumes: - /Users/masutaka/Sites:/usr/share/nginx/html restart: on-failure:10 Snow Leopard からの流れで、雑多な html は ~/Sites に置いています。 $ docker-compose up -d しておけば、macOS を再起動しても nginx が 起動してくれます。 ほかにグローバルに必要な service が増えたら追加していきます。 mysql MySQL を使う Rails アプリケーションがあったので、とりあえず...

サーバの CI ってどうするのが良いのでしょうね。現状やむを得ず行って いますが、やり過ぎ感も否めないです。 [2014-09-14-1] に Wercker+Vagrant+EC2 の組み合わせでこのサーバの CI を始めてから、[2015-02-08-2] に CircleCI+Vagrant+EC2 に変更しま した。そして今回、CircleCI+Docker に変更しました。 理由は EC2 を使うのは大げさだと思い始めたからです。CI 時間の短縮を 期待しましたが、ほとんど変わりませんでした。結果的に、時々 EC2 イ ンスタンスを起動するのに 30 分以上かかり、CircleCI のタイムアウト 時間を超える問題は解決出来ましたが。 Docker 入門できて自己満足は得られたのですが、Docker の使い方ではな いなあというのが正直な感想です。 Docker を使ってサーバの CI をするためには、openssh-server をインス トールする必要があります。そもそも Docker は一度インスタンスを作っ たら変更を加えるべきではないため、Docker を起動してから knife-solo で変更を加えるのは誤った使い方です。 このブログのサーバ（さくらの VPS）には nginx や td-agent、 elasticsearch などがごちゃごちゃと入ってますが、同じ環境を Docker で作るのもおかしな話です。Docker は 1 サーバ 1 責務だと思うので、 例えば nginx だけをインストールする使い方が正しい気がします。 そういう意味で無理して CI しているなあと、モヤモヤしているところです。 修正内容はこちらです。末尾に解説を記載しました。 ./script/bootstrap-docker.sh このスクリプトは CircleCI の dependencies.pre で実行されます。...