dockerについて #事前知識

はじめに

従来はインフラエンジニアとアプリケーションエンジニアに分かれて、 サービスをつくるための仕事を実施していた(らしいです)。 正直、私はアプリケーションエンジニアであり、 インフラエンジニアは必要ですが後述する理由によってインフラエンジニアになる人は かなり少数になってしまうのだと思います。 そこで、最近はPaaS(Platform as a Service)やDockerと言われる仮想技術化によってインフラ構築をサクッと 終わらせることが多くなっています。 本記事では、このようなDockerに関わる話題を記載する予定です。

インフラエンジニアにならない人たち

はじめにで述べたように私自身もアプリケーションエンジニアであると思います。 出身も機械系のロボット工学が専攻ですので、色々な理由からインフラエンジニアになりたいと思うことが少なかったです。

まず、インフラエンジニアにならない人たちが多い理由としては、私の個人的な意見ですが次のことが挙げられると思います。

1. 学生であれば、限られた期間でNEWな研究開発の実績をあげることが難しい
2. 社会人であれば、インフラエンジニアは評価されにくい（日本企業は特に）
3. Webネイティブな世代や物心ついたころから携帯電話やインターネットを利用していた世代にとって、サービスは常時提供されていることが当たり前であり、意識的に知覚できるコトはアプリケーションエンジニアの実績となる側面が多い

物議を醸してしまうかもしれませんが、少なくとも私がインフラエンジニアに前向きにならなかった理由は上記の通りでした。

大学院生のときは、ロボット工学におけるサービス面を探求し、どのような機能のユーザエクスペリエンスを変えれば自動運転が当たり前の世の中になるのか？といった側面から、技術的な探求や新しい手法の実装・評価を行っていました。

現在はIT関連の一部上場企業で勤務していますが、悪い意味で日本的な特色をもつ企業です。 サービスは当たり前に運用され続け、問題が生じたときはバッシングを受けます。 普通に稼動していることは褒められることではなく、評価されにくいです。 さらに社内における自身のアピールポイントとして訴求しにくい側面がインフラエンジニアにはあると思います。 0から1をつくりあげ、新しく利益を上げるアイデアはアプリケーションエンジニアが立ち上げ、 立ち上げた1を0に戻さないように努力し続ける人がインフラエンジニアであると捉えています。 3番目にあげた項目も似ており、サービスが24時間・365日通常通りに稼動していることは当たり前で、問題が起きたときにだけ文句を言われてしまいます。 例えば、少し前にみんなが遊んでいたポケモンGOも障害が発生すればTwitterなどで不平不満があがりますが、 正常運行しているときは誰も褒めるようなTweetを書くことはないでしょう。 "今日も無事ログインできて、快適なポケモンライフを送っているぜ！"なんてTweetをする人はいないでしょう。

このような評価されにくい、褒められにくい、といった側面がインフラエンジニアに重くのしかかり、 目立つ側面であるアプリケーションエンジニアばかりが増えてしまうのだと私は思っています。

仮想化技術でどう変わっているのか

私もインフラ構築や維持は、時間がかかる上に褒められることが(少)なく、好んで取り組みたいとは思いません。 しかしインフラエンジニアは必須です。 人間が生きていく上で呼吸をしないと生命を維持できないことと同じで、必ずいるのです。 そこでアプリケーションエンジニアにとって便利なものが仮想化技術です。 ご存知かと思いますが、以下に記載するdockerは仮想化技術を活用することで、アプリケーションエンジニアがインフラ構築、維持管理を行いやすくなり、新たなサービスや技術に対するtry&errorを高速化することが可能になります。

dockerの概要

公式のリファレンス¹や各種サイト、書籍を読めば沢山書いてあるので、ここでも自分用のメモとして残すことが主眼になります。 特に本記事では文献²を参考にしています。 最低限必要と考えられるインフラ周りのワードについても触れられているので、私のようなインフラエンジニア初心者にとってイメージしやすい良書だと思います。

dockerの特徴

1. linuxカーネルを基盤として、この機能をうまく使うことで構成されている

2. dockerfileによりinfrastructure as codeを実現し、docker imageを作り出す。更にdocker imageを鋳型にすることでdocker containerの構築を楽にする
   また、docker fileをgit連携することで、変更箇所が明確にすることが可能

3. Docker Hubによって作成したdocker imageを共有することが可能で、公式や開発者が構築済みのimageを簡単に自分の環境でcontainer化することができる

dockerまわりの便利なやつら

巷でいうdockerは、いわゆるdocker engineというクジラさんがキャラクタなものを指しています。 クジラさんは前述したような特徴がある主人公みたいなやつで、さらにクジラさんを助けてくれる愉快な仲間たちがコンポーネントと呼ばれます。

愉快な仲間たち

1. docker kitematic（エイさん）
   • エイさんはGUIツールを司ります
   • docker engineはCUIなのでグラフィカルにいじりたい人はエイさんの力を借りることになる
2. docker registry（カイさん）
   • カイさんは作成したimageをみんなで共有する仲良しさんです
3. docker compose（タコさん）
   • タコさんは沢山ある足を活かして、多数のcontainerを一元管理する仕事ができるマンです
4. docker machine（クルマさん）
   • クルマさんはクラウド環境にdockerの実行環境をつくる働き者です。クジラさんが生活できる場を作ってくれます
5. docker swarm（コクジラさん）³
   • docker engineのクジラさんは各マシンに生息して各自が自由に生活をしています。これを統括する役割がコクジラさんです。

まとめ

今回はdockerについて概説しました。 かなり荒っぽい説明になってしまいましたが、やはり各機能は触ってみないと分かりにくいと思います。 本記事も適宜、図解にして補足を充実させていこうと考えています。 また不定期更新になりますがdockerについても次回以降はハンズオン形式にしてみようと思います。

参考文献

---

1. Enterprise Container Platform | Docker↩

2. プログラマのためのDocker教科書 インフラの基礎知識＆コードによる環境構築の自動化

   ↩

3. Docker Swarm入門↩