Docker コンテナーに IP アドレスを付ける方法

半分は備忘録ですが、 MACVLAN を使って Docker コンテナーに IP アドレスを付ける方法を記述します。

MACVLAN の設定

/etc/network/interfaces の記述例:

allow-hotplug eth0
iface eth0 inet manual
        up ip link set $IFACE up arp off
        up ifup macvlan0 || true
iface eth0 inet6 auto
        accept_ra 0
        down ifdown macvlan0 || true
        down ip link set $IFACE down

iface macvlan0 inet static
        address 192.0.2.2
        netmask 255.255.255.0
        gateway 192.0.2.1
        pre-up ip link add link eth0 name "$IFACE" type macvlan mode bridge 1
iface macvlan0 inet6 static
        address 2001:DB8::2/64
        accept_ra 2
        autoconf 1
        post-down ip link delete "$IFACE" type macvlan || true

補足: eth0 は IP 通信に使わないので ARP と RA を無効化しておきます。

Docker ネットワークの設定

コマンド例:

docker network create -d macvlan \
    --subnet=192.0.2.0/24 \
    --gateway=192.0.2.1 \
    --ip-range=192.0.2.128/25 \
    -o parent=eth0 \
    network-name

Docker コンテナーの設定

コマンド例:

docker container --network=network-name \
    --ip=192.0.2.3 \
    image 

Dockerfile 中で鍵サーバーから公開鍵の取得を試みるとエラーになる

Dockerfile の中で gpg --recv-keys を実行して公開鍵を取得しようとすると、エラーになったりならなかったりということがあったので、試行錯誤しながら対策してみました。

原因はおそらく IPv6 で鍵サーバーに接続しようとしたことで、 IPv6 を無効化することでひとまずエラーはなくなりなりました。

今回採用した IPv6 を無効化する方法は、 dirmngr.conf

disable-ipv6

を書くというものです。 gpg のオプションではなかったので、これにたどり着くまでは少し遠回りでしたね。

追記

エラー メッセージはこうでした。

gpg: keyserver receive failed: Cannot assign requested address

Docker にマウントしたディレクトリに作られる root 所有ディレクトリ対策

Docker コンテナーにディレクトリをマウントして何か作業をすると、root 所有のディレクトリが作られてしまうことがある。

そのようなディレクトリが作られても簡単に削除できるようにするのに、あらかじめ次のコマンドを実行してディレクトリに ACL を設定しておく方法が使える。

find . -type d -exec setfacl -m d:u:${USER}:rwx {} \;

Azure Functions で Docker Hub 自動タグ付けに挑戦中

docker pull しなくてもタグ付けができるのではないかと考えて、自動タグ付け機能を Azure Functions で実現しようとしています。

ウェブフックで API を呼び出そうとするとコールド スタートでタイムアウトしそうなことが判明して、キューを介した非同期処理にすることで回避しましたが、API の呼び出しはまだこれからといったところ。このまま無事完成するのでしょうか。

https://bitbucket.org/linuxfront/functions-azure

Hudson と Mercurial を利用した Maven 成果物のリリース管理

たまには何か書かないと PV が増えないので、今回は HudsonMercurial を利用した Maven 成果物 (artifact) のリリース管理について書いてみたいと思います。

ご存じの方もいるかと思いますが、私は OSSRH を利用して Maven Central Respository に Java 系成果物を公開しています。一例としては Google Login Plugin for Hudson とかですね。

ところで、Maven にはバージョンの末尾に -SNAPSHOT が付くと、リリース前のスナップショットとして扱われるという慣例があります。例えばバージョン X.Y-SNAPSHOT はバージョン X.Y より前のスナップショットという意味になり、Maven のリポジトリーでも別枠となります。

さてここまでを前置きとして、今回紹介するのは Hudson と Mercurial を利用して、成果物のリリースを半自動化してしまう手法です。

Hudson の使い方については別途調べてもらうとして、Hudson を使うことで Maven 成果物のデプロイ (deploy) までは自動化可能です。スナップショットの段階なら Hudson が新しいリビジョンを見つけるたびに自動デプロイしても何ら問題はありませんが、正式のリリースとなるとそうも言っていられません。

一応 OSSRH にステージング機能があるので、デプロイしてもいきなりリリースされることはないのですが、リリースしないものは破棄しなければなりませんので、リリース バージョンの自動デプロイは極力減らしたいところです。

そこで活用するのが Mercurial のブックマークです。例えばブックマーク release-candidate をリリース用のブランチに作成して、Hudson ではこのブックマークを追跡して自動デプロイするようにジョブを作っておきます。こうすると release-candidate の移動に伴ってリリース候補が OSSRH のステージング領域に自動デプロイされることになりますので、リリース OK となったら最後のリリース候補をリリースして残りを破棄すればリリース完了という流れです。

注意点としては、一旦リリースしたら次のリリースまでブックマークを移動しない (つまり自動デプロイしない) ようにすることでしょうか。Git でもブランチの移動を工夫すれば同様のことは可能だと思いますので、ぜひ試してみてください。