kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

Webサーバ/APIサーバ用コンテナイメージの標準化を考える

docker

きっかけ

まだ僕がコンテナ技術に不慣れなこともあって、こういった標準仕様が存在すればよいなと思っていたことがちょうど言語化されたものをtwitterで見た。

  • コンテナに割り当てるリソースの管理
  • オートスケーリング
  • graceful shutdown
  • logの転送
  • 秘匿情報のinject

これらはコンテナでWebサーバやAPIサーバを構築する場合どれもほぼ必須だったりあれば非常に便利にも関わらず、実行環境や個人の好みに実装が依存してしまっている。結果的に各地で車輪の再発明が行われたり手間を理由に実装が後回しにされている。

Web Developer も知っておきたい Kubernetes における Sidecar Pattern と Ambassador Pattern - Quipper Product Team Blogこの記事のようにここの項目で優れた技術やアイデア・仕組みが創出されても再利用されづらいのが問題である。

提案

次のようなコンテナイメージのインターフェイスの標準仕様はどうか。

  • 名前: Elastic Container Implementation Standard 柔軟性を持ったコンテナ実装の標準仕様(仮)
  • 利用方法: コンテナ作成後、そのコンテナのインターフェイス仕様を記したJSONファイルを作成してセットで取り扱う。
  • JSONサンプルイメージ
{
    "resouce": {
        "memory": "4G",
        "vcpu": 2
    },
    "scaling": {
        "min_instance": 1,
        "max_instance": 10,
        "min_cpu": "3%",
        "max_cpu": "90%",
        "min_memory": "10%",
        "max_memory": "80%"
    },
    "shutdown": {
        "max_wait_disconnection": "60s"
    },
    "log": {
        "path": "/var/log/apache/"
    },
    "variable": [
        "env",
        "db_url",
        "db_user",
        "db_password"
    ]
}

まずコンテナイメージ作成側のメリットとして、無数のバリエーションがあったリソース管理やオートスケーリングしきい値の設定方法、logの転送方式が標準化され、実装者による仕様のブレがなくなる。 コンテナ基盤(kubernetesやECS、あるいはその上に構築されるコンテナ実行環境)側のメリットとしてはまず提供するべき機能が明確になる。次にコンテナ側の仕様が固定されるため個別のコンテナの仕様に合わせる必要がなくなる。

次のステップ

実際に上の仕様にそってコンテナイメージを作ってみる。 また、その仕様に沿ったコンテナを実行できる環境をKubernetes(できるならEKS?)ベースで構築する(CloudFormationかTerraformを使いたい)

蛇足

アイデアとしては動かすアプリケーションの仕様をyamlで定めたElastic Beanstalkと思想が通じるものがある。 この仕様はBeanstalkがサポートしていたDocker以外のアプリケーションを切り捨てることでDockerに特化し、かつ仕様をシンプルにしたものと言える。