Zenn
🗂

開発環境にDocker導入した話

2023/03/27に公開
AWS
Docker
tech

はじめに

一昨年、新プロジェクトの立ち上げ時、その開発環境にコンテナ(Docker)を導入しました。
今では当たり前に導入されているDockerですが、設計から構築までを行う中で、様々な調査を行い、導入に至ったので、今更ながらその流れを思い出しながら順に記載していこうと思います。

環境構成を調査

まずはローカル環境でdockerファイルを使ってアプリがビルドしたことを確認。アプリの通信などは基本的なREST構成だったので特に問題もありませんでした。(dockerファイルの中身もシンプル)

その後、AWSでコンテナ環境を動かす際にはどういった構成になるかを調べました。

最初に、環境を構成する構築要素を紹介します。
AWSでコンテナ環境を作るには、コンテナの管理をする”コントロールプレーン”(ECSやEKS)と、実際にコンテナが稼働する”データプレーン”(EC2やFargate)という2つの要素が必要となります。
これらのサービスを組み合わせることでAWSでコンテナ環境を構築していきます。

調査結果として、構成の例とそれぞれのメリットデメリットをひと通りまとめました。下記に記載します。

ECS on EC2

メリット

  • インスタンスタイプの変更などに関するリソース拡張が容易にできる
  • 利用するイメージのキャッシュをEC2のホスト上に保持できるため、デプロイに関しては速い
  • EC2は多くのエンジニアにとって慣れ親しんだサービスであるため学習コストが低い
  • 障害対応時のリカバリ調査もしやすい

デメリット

  • EC2インスタンスの管理が必要となるため管理コストがかかる
  • 学習コストは低いがこの構成の選択肢は良くも悪くも無難

ECS on Fargate

メリット

  • 構築やスケールが比較的容易に行える
  • sshポートを開ける必要がないため、セキュリティリスクが少ない
  • Fargateによりインスタンスの管理が不要になり、管理コストがなくなる
  • sshログインはできないが、ecs execを使ってコンテナに入ることができるため障害対応時の調査が可能

デメリット

  • コンテナごとにENIがアタッチされるため、デプロイに関しては比較的遅い
  • EC2と比較して従量課金制であるが、少し割高な料金になる
  • イメージがキャッシュできないため、デプロイはEC2より少し遅い

EKS on EC2

メリット

  • 利用するイメージのキャッシュをEC2のホスト上に保持できる
  • EKS(Kubernetes)界隈のコミュニティが活発であり、エンジニアリング観点としては良い面が多い

デメリット

  • EKS(Kubernetes)の学習コストが比較的高い
  • ECSと比較してEKSにも課金があるため割高な料金になる(課金額はデータプレーンの利用料と比較したら低い)
  • EKS(Kubernetes)が定期的なバージョンアップが必要であるため、運用コストがかかる

EKS on Fargate

メリット

  • EKS on EC2と比べるとFargateを選択しているため、運用コストが低い
  • 尖った構成になるため、エンジニアリング的な観点としては良いことが多い

デメリット

  • EKSは導入ケースがあるが、データプレーンにFargateを使用する場合の導入ケースや参考文献が少ない
  • 現時点ではいくつかの制約事項があり、導入の障壁が高い

構成図(デプロイ含む)の一例紹介

それぞれの構成の特徴や展開するサービス、その当時の社内エンジニアリング等々を考慮し、構築する際のコンテナ環境導入のファーストチョイスは”ECS on Fargate”だと考え、こちらを採用することにしました。
以下がサービス構成図の一例です。

ハマりどころ

構成図を作成し、実際の構築を行う中で様々な問題点もあったので紹介します。

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

JVM系言語との相性が悪い

そもそもの話として起動が遅いです。加えて開発言語にJVM言語を採用する場合、イメージサイズやメモリ使用量が大きくなるという問題もあります。

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

弊社では開発にMacを使用したので問題はなかったのですが、参考程度に書こうと思います。「Docker for Windows」を利用するにはHyper-Vを有効化する必要がある為Windows10 Proが必要になります。

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

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

こちらはソース管理ツールにGitLabを導入している場合に限りますが、CodeBuildのソースプロバイダはGitLabをサポートしていません。（GithubやBitbucketはサポートされているんですけどねー💦）
対応策としては、AWSのソース管理サービス(CodeCommit)でGitLabのソースをミラーリングする、ことで回避しました。

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

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

最後に

悪戦苦闘しながらも、設計から導入まで行えたのは非常にいい経験でした。
また、デプロイツールにおいても、AWSに集約したため、Jenkinsサーバーをたてるなどの余計なサーバー管理が不要となりました。今ではEKSなどを採用する企業も多いと思いますし、私が現時点でコンテナ環境を導入するのであれば、また違った構成を選ぶと思います。Kubernates勉強しなきゃ！

ということで今回はここまでです。

Discussion