サイトアイコン cocone engineering

開発環境にDockerを導入しようとしたら大苦戦した話

こんにちは、cocone connectでサーバーエンジニアをしているマイヤーズです。

 

今回弊社で新しいプロジェクトを立ち上げることになり、その開発環境にコンテナを導入することとしたのですが、その結果思わぬ苦戦を強いられたので、導入にあたっての流れを順に記載していこうと思います。

Dockerの導入を検討されている方のご参考になればと思います。

そもそもDockerってなんだっけ?

まず初めにDockerについて軽く説明しようと思います。

 

DockerとはDocker社が開発したコンテナ型の仮想環境を作成・実行するためのプラットフォームで、OS上に隔離されたアプリケーションの実行環境(コンテナ)を作成し、1台のホストマシン上で複数のホストが動いているかのような環境を実現する仮想化技術です。

この説明ではイメージがつかないと思うので、VMwareやVirtualBoxをはじめとする仮想マシンと比較してみましょう。

 

仮想マシンもDockerも仮想化という意味では同じなのですが、構成が異なります。

仮装マシンではホストマシン上でハイパーバイザを利用してゲストOSを動かし、その上でミドルウェアなどを動かしています。

それに対してコンテナはホストマシンのカーネルを利用し、プロセスやユーザなどを隔離することであたかも別のマシンが動いているかのように動かすことができます。

そのためコンテナは軽量で高速に起動・停止をすることが可能です。

 

 

他にもDockerの特徴には以下のようなものがあります。

Dockerの仕組みで大事なこと

Dockerを使う上で知っておくべきことはいくつかありますが、今回は重要な”マウント”と”イメージ”についてご紹介します。

マウント

マウントはホスト側(コンテナの外)にあるディレクトリ・ファイルをコンテナの中から利用できるようにする機能です。

マウントすることによりホスト側で編集・保存したものがコンテナ環境の同ファイルでも同じ編集内容が保存されるようになります。

インタプリタ言語であれば開発したものが都度Docker環境に構築されるため、開発が容易に行えます。

イメージ

イメージはDockerコンテナの実行に必要な概念としてのパッケージ(ファイルやメタ情報の集合体)です。

Dockerイメージの構成はDockerファイルに記載されている命令文がレイヤ構造になっています。

AWS環境でコンテナ環境を実現するには?

ここまではDockerを使ったローカル環境での開発について記載してきました。

ただ、実際に本番環境に上げる際には、AWSやGCPなどのクラウドサービスを使って環境を構築していくと思います。

 

そこで今回はAWSでコンテナ環境を構成する構築要素を紹介します。

AWSでコンテナ環境を作るには、コンテナの管理をする”コントロールプレーン”(ECSやEKS)と、実際にコンテナが稼働する”データプレーン”(EC2やFargate)という2つの要素が必要となります。

これらのサービスを組み合わせることでAWSでコンテナ環境を構築していきます。

AWSコンテナ関連サービスの組み合わせの検討

代表的な構成の組み合わせは以下の4つで、それぞれに違いや特徴があります。

ECS on EC2

 

メリット

 

デメリット

 

ECS on Fargate

 

メリット

 

デメリット

 

EKS on EC2

 

メリット

 

デメリット

 

EKS on Fargate

 

メリット

 

デメリット

 

構成図の一例紹介

それぞれの構成の特徴や展開するサービス・弊社の社内エンジニアリング等々を考慮し、現時点のコンテナ環境導入のファーストチョイスは”ECS on Fargate”だと考え、採用することになりました。

そうと決まれば次はサービス構成図の作成を行います。

こちらが弊社で構築しようと考えた”ECS on Fargate”の構成図になります。

 

ハマりどころと問題点

構成図を作成し、社内調査を行い、公式ドキュメントやQiitaなどを活用し、いざコンテナ環境を構築!

と進めていたのですが、進めるたびにたくさんの問題に直面しました。

ローカル環境での開発にあたっての問題点

JVM系言語との相性が悪い

そもそもの話として起動が遅いです。

加えてイメージサイズやメモリ使用量が大きくなるという問題もあります。

また、Docker開発する際にはリモートデバッグが必要になってきますが、Docker + IntelliJ IDEAで開発する場合にはローカルデバッグ推奨のためデバッグ方法について悩みました。

 

Dockerfileで立ち上げたアプリのリモートデバッグはうまくいくのに、docker-compose.ymlを使うとうまくいかない

この問題はIntelliJ IDEAがdocker-compose.ymlをうまいことキャッシュしているせいな気がしますが、原因は調査中です……。

 

Windowsで利用するハードルが高い

弊社では開発にMacを使用したので問題はなかったのですが、参考程度に書こうと思います。

「Docker for Windows」を利用するにはHyper-Vを有効化する必要がある為Windows10 Proが必要になります。

また、Macでは動くがWindowsだと動かないという記事が散見されるというのもあります。

 

AWSコンテナ環境での開発にあたっての問題点

CodeBuildのソースプロバイダがGitLabをサポートしていない

こちらはソース管理ツールにGitLabを導入している場合に限りますが、CodeBuildのソースプロバイダはGitLabをサポートしていません。

GithubやBitbucketはサポートされているんですけどね……。

対応策としては、AWSのソース管理サービス(CodeCommit)でGitLabのソースをミラーリングする、などがあります。

 

CodePipelineがサブモジュールをサポートしていない

この問題の対応策としては、サブモジュールをCodeBuildやjenkins等のビルドツールでビルドする際に、サブモジュールを含めたアプリケーションのソースを丸ごとクローンするなどがあります。

ただ、VPCでCodeBuildを使用するにはNATゲートウェイもしくはNATインスタンスが必要となり、使用料金が高くなってしまいます。

NATはお高い……。

最後に

今回Dockerを導入するにあたって、サンプルアプリをECS環境で構築し、Hello Worldするところまでは比較的スムーズでしたが、実際の開発サイクルの検討やプロトアプリを載せた場合に問題が多発してしまいました。

とりわけデバッグ方法の模索とビルド周りは原因調査に時間がかかってしまったため、一旦コンテナ環境の構築をペンディングし、EC2とCodeDeployでアプリ側を構築する方針としました。

 

開発にあたって良い部分が多いDockerではありますが、使っているツールや展開するサービスの規模によっては問題もあります。

開発環境にコンテナ環境を選択される際の参考になればと思います。

 


 

cocone connectでは一緒に働く仲間を募集中です。

ご興味のある方は、こちらのリンクからぜひご応募ください。

 

cocone connect株式会社 採用情報

https://recruit.jobcan.jp/coconeconnect

 

cocone connect株式会社 公式サイト

https://connect.cocone.co.jp/

 

また、ココネでも一緒に働く仲間を募集中です。

ご興味のある方は、ぜひこちらの採用特設サイトをご覧ください。

https://www.cocone.co.jp/recruit/contents/

モバイルバージョンを終了