3
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

この記事は、求ム!Cloud Nativeアプリケーション開発のTips!【PR】日本マイクロソフト Advent Calendar 2020 の 2 日目です(後から追っかけで書いています)。

今まで携わっていないサービスに急にアサインされたり、転職して新天地でのプロジェクトなど、Docker 環境が構築されていないプロジェクトにジョインすることがあります。

そんなとき、開発環境の構築手順が「秘伝のタレ化」していることがままあります。しかし、「秘伝のタレ化」した手順にしたがっても開発環境は基本構築できません。そんなときは、可動しているマシン環境をコピーしたり、「秘伝のタレ化」した手順から構築する開発環境を想定してあーでもない、こーでもないと試行錯誤するといった作業を行う必要があり、かなり苦痛を伴う作業になります。

そういった状況に陥り、「コンテナ化(Docker)だ!」と環境構築周りを刷新するエンジニアのために大事なことを残しておきます。

大事なことを疎かにして後で困った事態に陥ったエンジニアをたびたび見てきたので、参考にしてください。

1. コンテナ化(Docker)するならすべての環境をコンテナ化すること

よくある状況として、開発環境構築だけコンテナ(Docker)化し、検証環境や本番環境はコンテナ化していないというのがあります。

これには「自分に閉じた開発環境だけであれば上司や関係各所と調整をしなくてもよい」という理由があります。今は少ないと思いますが、コンテナについての知識や理解が乏しい上司や関係各所を納得させるのが面倒というのをよく聞きます。

本番環境や検証環境で問題が起こらなければ一見何の問題もないように思えます。

しかし、本番環境の問題を検証環境では再現できるが、開発環境では再現できないという場合に問題が起こります。

この場合、本番で起こっている問題を防ぐ対応の前に、本番環境・検証環境と開発環境の差異の調査を行う必要があり、ただでさえ急いでバグ対応をしなければならない状況なのに他にも労力を割かなければならないのでやめた方がいいです。

今までこの調査をしてきてよくあったのは

  • オレオレ開発環境だけライブラリのバージョンが異なる
  • オレオレ開発環境だけそもそも入れているライブラリが異なる

といったものです。面倒な「秘伝のタレ化」した手順から環境構築するのが嫌なのはわかりますが、中途半端なことをせず、「プログラマーの三大美徳」の「第一の美徳」である「怠慢(Laziness)」の「全体の労力を減らすために手間を惜しまない気質」を発揮した方がよいです。

2. コンテナ化(Docker)するならミニマムにすること

「コンテナ化(Docker)するならすべての環境をコンテナ化する」についで大事なことはミニマムにすることです。

これは Docker 化に本人が不慣れだからなのか、オールインワンの方がよいと思っているのかなのか、何が必要なのかよく理解していないが故にとりあえず全部載せにしているのか、そのいずれもなのか要因は様々ですが、結果として巨大なイメージファイルを作成します。

巨大なイメージファイルだと、pull するのにも時間がかかりますし、どこかの設定を変えただけでビルドし直しになるので、柔軟性が損なわれます。

何が本当に必要で、ミニマムにするには対象のシステム・インフラを理解しなければできないので、とても面倒なことはわかりますが、中途半端なことをせず、「プログラマーの三大美徳」の「第二の美徳」である「短気(Impatience)」の「今ある問題に対応するプログラムにとどまらず、今後起こりうる問題を想定したプログラムを書くことができるか。今後起こりうる問題を想定したプログラムとは、例えば要望に柔軟に答えられる作りにするなど」を発揮した方がよいです。

3. コンテナ化(Docker)するならコードの意味を理解すること

「コンテナ化(Docker)するならミニマムにすること」についで大事なことはコードの意味を理解することです。

これは Docker 自体に本人が不慣れだったり、そもそも Docker を便利なツール程度にしか理解していない(本質を理解していない)、いずれもなのか要因は様々ですが、結果として本人も理解していないが一見して動作するコードを作成します。

本人的には環境構築で楽をしたいのが目的なので“動けばOK”なのでしょうが、まともなエンジニアならば、検証環境や本番環境に適応するものが“よくわからないけど、動くもの”では困ります。

人は誰しも変化を恐れるものです。特にインフラの意味をあまり理解していないエンジニアからすると Docker のコードは分かり易いものではありません。そのため、コードを理解するのはとても面倒なことはわかりますが、中途半端なことをせず、「プログラマーの三大美徳」の「第三の美徳」である「傲慢(Hubris)」の「神罰が下るほどの過剰な自尊心、または人様に対して恥ずかしくないプログラムを書き、保守しようとする気質」を発揮した方がよいです。

わからないのであれば、公式ドキュメントを読むのもいいでしょう。

私は Ruby on Rails のコードを書くのですが、Quickstart: Compose and Rails | Docker Documentation は英語とはいえ、理解し易く書いてあります。

また、以下のドキュメントも知識チェックがついているので、参考になるかと思います。

参考

プログラマ - Wikipedia

3 日目は @changeworld の「百聞は一見に如かず、Kubernetes の基礎を学ぼう!」です。引き続きお楽しみください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
3
Help us understand the problem. What are the problem?