今更学ぶコンテナ入門2024

# イントロダクション

**本記事の想定する読み手**

コンテナやdocker、kubernetesという言葉は聞いたことあるんだけど理解できているかというと正直ビミョーな人。

**読むとどんなことがわかるか？**

- コンテナの仕組み
- コンテナオーケストレーション
- コンテナ環境でのCI/CD

# コンテナの仕組み
　コンテナとは「アプリケションとその実行に必要なライブラリなどを一つのパッケージにしたもの」です。そして、コンテナ技術そのものは、OSレベルの仮想化技術のことを指します。よく従来のVMとの比較されますが、一番の違いはゲストOSの上でアプリを動かすかどうかです。

比較記事は量産されているのでリンク先をご覧ください。

> https://www.idcf.jp/words/container.html
 
### コンテナのメリット

- VMに比べ軽量で起動が早い。
- 下層OSへの依存関係を明確化し、移植性を最大化
- アプリケーションのリリース速度・頻度を上げることができる。
- オートスケールアウトでアクセス負荷に強い。
- 開発環境と本番環境の差異を最小限にし、CI/CDを可能にする。
- マルチクラウドで一貫した動作が期待でき、インフラサービスへのロックインから解放される。
- 新規事業やDXの実現時に既存のインフラ環境や運用管理スキームに足を引っ張られない。

怪しすぎるくらいにいいことばかり…（伏線）
当然ながら完璧な技術ではありませんがデメリットはさておき、コンテナの中身について見ていきましょう。
### コンテナの構成

ではコンテナはどのように動かすのでしょうか。

VMのようにゲストOSを使用せず動かすためにはまず、コンテナエンジンが必要です。このコンテナエンジンがカーネルを共有できるようにすることによって、ホストOSのみで複数のアプリケーションを動作させることができます。

![スクリーンショット 2024-07-24 23.36.19.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1115033/638f8ec2-be1e-7f37-f720-cae439d42eb9.png)



独学でプログラミングを勉強してきた私にとって、コンテナは革命的技術かもしれません（大げさ）
今までローカルに環境構築してビルドしたアプリを、いざ本番環境にリリースしたら全っっっ然動かない😇　なんてことがなくなる。
さらに、ちょっとPythonでもやってみるか〜といって構築した環境を気づいたら使わなくなってたなんて経験ありますよね。
そんな時も気兼ねなく環境ごと捨てられて、昔入れたランタイムやライブラリを古いまま放置して、大事な時にエラー…なんてこともなくなる。
なんと素晴らしい技術でしょう。


# コンテナオーケストレーション

 従来のVMに変わり、モダンなアプリの構築に大きく寄与するコンテナ技術ですが、エンタープライズアプリケーションのような規模の大きいシステムを構築するとなると考慮しなければいけないことが沢山あります。

　一般的にエンタープライズ規模のアプリケーションでは、負荷分散や耐障害性を目的とてクラスタ構成をとることが多いです。特に、生活インフラ系や金融系などの事業の停止が人々の生活に直接影響する企業で多く見られます。

コンテナベースのアプリケーション構築においても、この考え方は変わらず、クラスタ構成をとる上で必要な知識が求められます。
具体的には次のようなことを考慮しなければいけません。

- クラスタで稼働するコンテナの管理
- リソース管理
- 負荷分散
- スケーリング
- 耐障害性
- 監視

そこで必要なのが、コンテナオーケストレーションツールです。

> コンテナオーケストレーションとは、コンテナのライフサイクル全体にわたってタスクを自動化して管理するツールです。コンテナオーケストレーションを利用することによって、複雑な環境がはるかに管理しやすくなります。コンテナのデプロイ、スケーリング、保護に必要な手作業が最小限に抑えられ、アプリケーション開発の速度、俊敏性、効率を向上させることができます。
> 
> 
> 　コンテナオーケストレーションは、大規模で動的な環境でコンテナを管理するためには欠かせません。コンテナライフサイクルでは、プロビジョニングとデプロイ、コンテナ間のリソースの割り当て、ホスト間のコンテナのスケーリングと移動、ロードバランシング、コンテナの健全性の監視など、数多くの作業が必要になります。
> 
> https://www.splunk.com/ja_jp/data-insider/container-orchestration.html
> 

**コンテナオーケストレーションの代表的な機能**

代表的なツールとしてKubernetesが挙げられます。

[Kubernetes](https://www.notion.so/Kubernetes-cf5526ff2c4a40b79e0005ce53a9c3be?pvs=21)

- 設定とスケジューリング
- プロビジョニングとデプロイ
- 健全性の監視
- リソースの割り当て
- 冗長性と可用性
- 更新とアップグレード
- コンテナのスケーリングや削除によるインフラ全体のワークロードの分散
- ホスト間のコンテナの移動
- ロードバランシングとトラフィックルーティング
- コンテナの相互作用の保護

Kubernetesではコンテナの管理、運用に役立つ機能を提供しますが以下の機能は有していません。

サードパーティのツールと連携して実現する必要があります。

- コンテナの動的ビルド/デプロイ
- ミドルウェアの管理
- クラスタのロギングや監視
- コンテナのセキュリティ
- クラスタのアップグレード


これらの弱点を補うために、 kubernetesのマルチクラウドへの適合性を活かして、各種クラウドプラットフォームが kubernetesをラップしたマネージドサービスを展開しています。

実際にコンテナを運用するに際ては、これらのサービスの利用が推奨されます。

代表的なマネージドサービスとしては、redhat open shiftなどが挙げられます。

# CI/CD

　CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称であり、手作業で行われていたテストのフェーズからデリバリー、デプロイメントに至るタスクを自動で行える仕組みのことです。このタスクの一連のステップは、まとめてCI/CDパイプラインと呼ばれます。

コンテナ環境におけるCI/CDでは主に次の作業を自動化します。

1. 修正・変更されたソースコードの解析
2. コンテナビルド
3. テスト
4. レジストリにプッシュ
5. マニュフェストを変更
6. クラスタにデプロイ

また、これらのタスクの自動化はアプリケーション開発者が本来の仕事であるビジネスロジックへ集中する環境を提供することにつながります。

**CI/CDの運用体制**

CI/CDパイプラインの構築には開発から運用・そしてインフラ領域の知識といったも幅広い知識と経験が必要になります。

前述の「アプリケーション開発者が本来の仕事であるビジネスロジックへ集中する環境を提供すること」を実現するためには、アプリケーションエンジニアリングとリリースエンジニアリングは明確にチームを分けるのがベターです。

リリースエンジニアリングの役割

CICDパイプラインの構築

- アプリケーションの品質担保を自動化
- DevSecOpsの実現

各環境へのデプロイ承認

- Gitのマージリクエストを使ってデプロイ承認フローを構築することができる
- ブランチのマージ ＝ 対応する環境へのデプロイとする運用

ブランチ戦略の策定と運用

### CIOpsからGitOpsへ

> 近年では、GitOps(バージョン管理ツールである Git を活用した運用手法) といった言葉が浸透してきており、従来開発部門において培われてきた文化・手法をインフラの管理に活用しようという流れがあります。GitOps という言葉自体はWeaveworks 社が 2017年に提唱した言葉であり彼らの[ブログ](https://www.weave.works/blog/gitops-operations-by-pull-request)でも語られています。
　前述した CI/CD プロセスの多くは1つのコードリポジトリ内でソースコードと Kubernetes のマニフェストファイルなどを管理します。そのためちょっとしたマニフェストファイルの変更でデプロイ環境が動かなくなってしまった場合、複雑なパイプラインをトレースして何が原因だったか、ロールバックするべきバージョンはどれなのか調査が必要になるケースがあります。また、同時にいくつもの CI ジョブが走った場合、最終的にデプロイ環境に作られるシステムはどのバージョンなのか保証することは容易ではないでしょう。
　そこでGitOps ではこれらのアプリケーションコードとインフラコードを個別にバージョン管理し、アプリケーションとインフラの CI/CDプロセスを明確に分離し互いの影響を受けないようにするとともに、Kubernetes のようなコンテナインフラをバージョン管理しようというコンセプトです。
https://www.netone.co.jp/media/detail/20200303-1/
> 

これまでのCI Opsでは以下のようなリスクが発生

- CIの権限肥大化（中央集権的）
- SIngle Source of Truthの実現が難しい（構成ドリフトを検知しない）
- 各環境への穴あけなどネットワーク設定も必要

Git Opsを実現できると…

- CDツールは限定的なデプロイ権限しかもたいない（自分のクラスタのみ）
- Gitリポジトリへのアクセスは参照権限のみ
- 構成ドリフトを検知・自動修正によるSIngle Source of Truthの実現

## まとめ

- コンテナは従来の仮想化の課題を解決する技術。
- 一方で、エンタープライズ利用ではクラスタ構成が必須となり、それに伴う一般的な知識習得とコンテナに関する課題がある。
- それらの課題への対処として、Kubernetesを始めとするオーケストレーションツールの利用が推奨されるが、学習コストが高い。
- これらの課題を乗り越えられれば、CICDやgitOpsなどを実現しやすく、サイクルの早い現代ビジネスにおいて優位を取ることが可能になる。