COLUMN

引っ越しやデータ移動が簡単（可搬性）

dockerについて語られる時、よく可搬性の高さが話題となります。従来の引っ越しは、インフラエンジニアがサーバーを移設するか、あるいは、物理マシンは移動させず、別の場所に用意したサーバーに手作業で以前と同じ環境を構築するなどし、さらにネットワークの調整まで必要で、大変、手間のかかるものでした。

dockerを導入すると、Dockerfileにサーバー構築のレシピが記述されていることや、レシピから作成したコンテナイメージをレポジトリから読み込みできることから、サーバーのお引越しが簡単になる・・、まさに物流のコンテナから連想される可搬性の高さに言及されることがしばしばあります。特定の場面でこのdockerコンテナの可搬性の高さに救われる場合もあるのですが、実際の運用ではこの可搬性の高さが便利だと感じられる場面は限定的であることが多いようです。

原因としては以下の二点が考えられます。

コンテナ基盤の構築・ネットワーク機器の設定と調整が別途必要

dockerコンテナのお引越しそのものは本当に簡単です。現在稼働しているサーバーのレシピであるDockerfileを引っ越し先にコピーし、そこでコンテナビルドの作業を行うと、引っ越しは終わりです。

ただ、これにはお膳立てが必要で、すでに引っ越し先のコンテナ基盤が設置済である場合のお話となります。dockerコンテナでWebサーバーが動作していると言う場合、その前段に、Firewallやロードバランサー、リバースプロキシなどが置かれていて、かつ、ローカルネットワークとインターネットが接続されているなどは、コンテナの範囲外となります。

※上記のネットワーク機器もまとめてコンテナ化してしまう方法もありますが、いずれにしても、DNSサーバーの更新やコンテナ基盤の準備などなんらかのインフラ基盤作業は残ってしまいます。

いつでも引っ越しできるコンテナ基盤が先に用意されている場合に限り、コンテナの可搬性の高さと有用性を実感できるかと思います。例えば、検証環境、ステージング環境、本番環境がすでに用意されており、ローカルPCでの開発やコンテナへの組み込みを終えた後、検証環境、ステージング環境、本番環境と継続的で連続的なデプロイが必要な場面では大変スピーディーで、以前の課題であった本番環境へのデプロイに3営業日待ちと言ったことは少なくなりました。つまりコンテナの導入の基準は、「このために使う、このシーンで使えばこう言った効果がある」とシンプルに明言できることが重要かと思われます。

データ移行は手作業となることが多い

コンテナを高速にデプロイすることは可能ですが、その足回り、土台の準備には時間がある程度かかってしまうと言うお話を致しましたが、もう一つ、コンテナの中に入っているデータ、また連携しているローカルのデータも引っ越しの際の課題となります。

[1]コンテナがローカルのファイルシステムをマウントしている場合

dockerコンテナは主となるサービス(プロセス)が停止するとコンテナの内部のデータは消去されてしまいます。そのため、データに永続性を持たせたい場合は、ローカルストレージをマウントするか、NFSなどを用いてローカルの他のサーバーのドライブをマウントして利用します。こういう用途では、そのローカルの何らかのデータも手作業で引っ越し先にコピーしてやる必要があります。

[2]コンテナがローカルのデータベースと連携している場合

ウェブアプリケーションがデータを蓄積しているデータベースも引っ越しが必要となることが多いかと思います。特にライセンスが厳しい商用データベースを利用している場合、引っ越し先の待機データベースのライセンスの必要性やライセンスモビリティ、データベースデータ移行時の手順の確認やリハーサルも必要で、事前にこう言った問題をクリアにしておくことが必要です。

上記の理由により、ウェブアプリケーションでよく用いられるコンテナの可搬性の高さと現実の運用で直面するさまざまな問題には注意と十分な事前確認・検討が必要です。

dockerコンテナについてお悩みの方は、NTT東日本までお気軽にご相談ください。

属人性の解消

このコラム執筆当初は、「dockerコンテナによって属人性の解消が可能」と言う認識についてその通りだと認識して書き進めていたのですが、コンテナには大きなメリットと共にそれ相応のデメリットが存在することを思い出し、「真偽が微妙」の枠にお引っ越しすることとなりました。

IaC(インフラのコード化)の導入により、dockerコンテナを導入するとOSの初期設定やミドルウェアのインストールや設定などが文字として残ることで、「インフラエンジニアが何をしているのかさっぱりわからない」と言う印象を払拭し、作業を可視化することで属人性が解消されるのではと考えておりました。ただ、再考したところ、コンテナ基盤の作りこみやFirewallやロードバランサーなどの作業は依然として職人芸的なところがあるため、dockerコンテナのみでは属人性は解消しないのではないかと考えるようになりました。また、ベテランSEが作成したDockerfileの記述もシェル芸(^*1)を含む職人芸的なギミックが随所に施されており、結局、このレシピ(Dockerfile)を読んでわかる人は限られてしまうのではないかと言う問題があるかと思います。

また、停止すると中のデータが消えてしまうなどの仕様や注意点などdockerに対する理解や知識も必要で、いざdockerベースのシステムを勢いでリリースしようものなら、「dockerを触れるのはあの人とあの人の2人だけ」とますます触るのが怖いシステムへ発展していき属人性が加速していくのではないかなどの懸念が残ります。インフラ系IT技術者の数が圧倒的に足りない昨今、追加要件で「コンテナ経験者」を織り込むと既存メンバーからのアサインや新規SE採用がさらに難しくなります。大冒険で「えいやっ！」でk8s (kubernetes)なんて導入した日には、ますます、その傾向は加速するものと考えられます。現段階では、コンテナの導入によるメリット・デメリットを事前にきちんと整理してからと言うところに落ち着くのではないでしょうか。

1 … シェル芸とは
Unixシェルとコマンドを駆使し、複雑難解な処理を華麗に鮮やかに解決するUnixコマンドの名人をシェル芸人と呼び、コマンド一撃で瞬時に課題を解決する名人技をシェル芸と呼びます。彼らがアドリブで生み出す複雑難解な長文ワンライナー、時にシンプルで簡素、スマートなコマンドは、Unix哲学の神髄と言えるでしょう。

dockerコンテナについてお悩みの方は、NTT東日本までお気軽にご相談ください。

ゲストOSがなく、OSの種類を選べない

この説明はdockerやコンテナ仮想化アーキテクチャの説明としては、正確な表現です。OSの定義をOSのコア領域であるカーネルのみとした場合、コンテナ仮想化基盤で動作しているカーネルは一つだけですので、正しい説明となります。ところが、実用上・実務上の利用段階では、広義のOS環境を選べてしまいます。この辺りの話は要件定義や基本設計では重要な話ですので、「OSを選べない」「ゲストOSが存在しない」と言う説明がどういう意味なのか正しく理解して導入する必要があります。

一例として Ubuntu 20.04 LTS で動作するコンテナのDockerfileを例に見てみましょう。

1行目に注目して下さい。しっかりCentOS 7系のOSイメージが指定されていますね。これはUbuntu 20.04 LTS上でCentOS 7系のコンテナが動作しているということです。また、Ubuntu内のCentOSコンテナにおいてRedhat系で広く採用されているyumコマンドが実行されています。つまり、狭い意味でのOS(カーネル)は選択・変更できませんが、広義のOS環境としては複数のOSを選択して使い分けることが可能なのです。と言うことは、それに伴い、利用できるコマンドやミドルウェアなどもそれぞれのOS、バージョンに由来するもの、適合するものを利用することとなります。ここがコンテナ案件の要件定義などのフェーズで重要になるポイントです。コンテナを利用することで本来は一台のサーバーで共存できないソフトウェア同士を個別にインストールすることも可能です。

共有しているのはOSのカーネルの部分なので、「コンテナ仮想化ではOSを選べない」と言うのは誤解でもあり、正しくもある表現だと言うことがわかります。

dockerコンテナを導入することで1台のOSの上に複数の異なるディストリビューション、異なるバージョンのLinuxコンテナを同時に設置することができます。正確な意味ではOS(カーネル)は1つだけですが、コンテナ空間内には明らかに別の異なるOS環境が存在しているのです。

「そういう意味ではなく、コンテナ基盤のOSがLinuxに限定されてしまう話ですよ」と言う声も聞こえてきそうですが、そういう意味では実務上OSがLinuxしか選べないと言うのはある程度は正しい説明だと思います。一般仮想化の自由度に対してコンテナ仮想化の組み合わせはかなり制限されています。とは言え、dockerコンテナを利用する場合、コンテナ基盤OSにLinux一種しか選べないと言うわけではないという点をお話したいと思います。

dockerはLinux上でLinuxコンテナ環境を提供するソフトウェアでした。その意味において、OSはLinuxしか選べませんし、コンテナもLinuxの中でディストリビューションやバージョンを選べるだけの時代がしばらく続きました。しかしながら、マイクロソフトはWindows Server 2016上で動作するWindowsネイティブのdockerコンテナサービスをリリースしました。このコンテナはdocker社とマイクロソフトの共同開発です。Windows向けのdockerコンテナですので、コンテナはIISなどWindowsのネイティブアプリケーションやサービスが動作するコンテナとなります。Linuxコンテナと同様、Windows ServerのdockerもWindowsのカーネルであるNTカーネルをコンテナと共有する作りとなっています。NTカーネル上で動作するWindowsコンテナとなります。

Linux   ＋ Linuxネイティブコンテナ   

Windows ＋ Windowsネイティブコンテナ 

2023年現在、メジャーOSで、上記の組み合わせが用意されていますので、この2種をコンテナ基盤として選択することが可能です。長くなりましたので、次の回でLinux以外のさまざまなOSをコンテナ基盤とするお話もしたいと思います。