Forkwell Press

SHARE

infra study meetup #2 第2部 アイキャッチ画像
Event report

Infra Study Meetup VM時代の開発と Kubernetes による Cloud Native な開発のこれから【2部】

エンジニアに役立つ情報を定期的にお届けします。

Forkwell が主催する技術イベント「Infra Study」。今回は「VM時代の開発とCloud Native時代の開発」というテーマで開催しました(開催日:2020年 5月20日)。第2部では、青山さんの基調講演から「VM時代と Docker / Kubernetes を比較したパート」を紹介します。Docker によって開発者とインフラエンジニアの体験がどのように変わったかや、CAPS のコード化と Kubernetes のコード化の違いが、わかりやすく解説されています。

他のパートをご覧になりたい方は、以下を参照してください。

VM時代との比較

今回は、VM時代と Docker / Kubernetes を比較して紹介します。

即座に安定したビルド〜デプロイを実現するイメージ化

まず Docker が大きく寄与したものとして、コンテナのイメージ化が挙げられます。アプリケーションとアプリケーションを実行するための環境を、ひとまとめにイメージ化できたところですね。かつコンテナ化により、Immutable Infrastructure もさらに強固に徹底できたのも一つのメリットかなと。

[VM]インフラのビルド〜デプロイまでの道のり

従来の環境だと、Terraform などで VM を起動し、Chef や Ansible でセットアップして、そのあとに Jenkins でアプリケーションをデプロイするのは結構時間がかかるので、あまりやらないパターンかなと。

これをもう少し進化させると、ベースイメージを作り、Terraformで VM を起動したら、あとアプリケーションデプロイするだけにするあたりが、だいたい現実的な解かなと。今のコンテナ時代みたいに、アプリケーション自体を VM のイメージのなかに入れて起動するのは、あんまりやっていないと思います。

[Cloud Native]インフラのビルド〜デプロイまでの道のり

Docker の時代では、Dockerfile でイメージ自体をビルドするところは、開発者側ができるような作業です。ここら辺も組織のポリシーによるとは思うんですけれども、個人的にはDockerfile を書くまでを開発者サイドでやるといいと思います。

あとはイメージ化したものを、Kubernetesへのマニフェスト記述により、コンテナとして起動できると。このコンテナのイメージ化のなかにアプリケーション自体も入ってるので、完全に同じような状態で起動が保証されるようになりました。これがインフラから見たときのビルドからデプロイの変化ですね。

[VM]アプリのビルド〜デプロイまでの道のり

開発者側から見ると、従来はコードのリポジトリに対してプッシュすると、CI が走ってバイナリをどっかに置いておき、 CD で VM にデプロイするような流れでした。

[Cloud Native]アプリのビルド〜デプロイまでの道のり(GitOpsの場合)

Kubernetes の環境になると GItOps を使うことが多いですが、アプリケーションエンジニアから見るとコードに対してプッシュすると、コンテナイメージがつくられ、コンテナイメージを使うように、インフラの構成情報が変更されます。

どのアプリケーションがクラスタに登録されているかがコードとして見れますし、Docker のコンテナイメージのレジストリ置き場には環境込みのアプリケーションが置かれているので、非常にわかりやすい状態になったと思います。

[Cloud Native]開発環境の準備のしやすさ

またアーティファクト自体はコンテナイメージとマニフェストだけなので、基本的に外部に依存する部分さえ用意すれば、どこでも手元でコピーを作れる点がメリットです。今は外部に依存するところも、コンテナで補えます。

アプリケーション実行のベストプラクティスのコード化

アプリケーション実行のベストプラクティスのコード化について話します。

CAPS のコード化と Kubernetes のコード化の違い

2つ目が Kubernetes です。アプリケーション実行を念頭に置いたベストプラクティスがコード化されているかなと思います。従来の Chef とか Ansible のコード化はあくまでもインフラのものなので、構築スクリプト的なんですね。

一方で Kubernetes のコード化は、アプリケーションをどう動かすかにフォーカスしています。また、安定的に動かすためのベストプラクティス的な設定群です。

[Kubernetes]アプリ実行のベストプラクティスのコード化

たとえばコンテナを動かす設定は、アプリケーションが前提となるようにどのアプリケーションを動かすかを定義して、それに対し環境変数などで環境を切り分けるような設定もかけます。

他にはヘルスチェックやリソースの割り当て、アプリケーション実行時のライフサイクルに関する設定、こういったものがすぐに直接書けるところが、アプリ実行のためのコード化になっていると思います。

Kubernetes を使う際、コンテナの停止処理のお作法みたいなものがあります。停止時は、SIGTERM が送られてきて、その後、一定時間後に SIGKILL が送られるというコンテナのライフサイクルがあります。

Kubernetes を使うと、こういうライフサイクルの対応を必然的にやることになるので、アプリケーション開発のベストプラクティスのレールにある程度乗れるのもいいところだと思います。

インフラの抽象化

インフラの抽象化について話します。

[VM]ロードバランサの連携/IPアドレスの管理

Kubernetes はインフラレイヤーを抽象化しているので、インフラエンジニアじゃなくても、開発者側でも触りやすくなっています。大なり小なりあると思いますが、従来の環境だと、ロードバランサの連携は、スクリプトや手動管理、IPアドレスも自分たちで管理していたと思います。

[Kubernetes]ロードバランサとの連携

ただ Kubernetes になると、こういったコンテナのIPアドレスは一切管理しません。コンテナにはラベルがついていて抽象的に管理します。ロードバランサとの連携もこのラベルをベースとして、 Kubernetes がメンバーの更新などを自動的にやってくれます。

この2つのリソースを作ると、コンテナが3つ立ち上がり、ロードバランサが自動的に作られて、メンバーの管理をしてくれます。

[Kubernetes]IPアドレスの管理

開発者もこの抽象化されたコードを使って操作ができ、IPアドレスは、ロードバランサのIPアドレスなどとかも、このサービスリソースの名前で解決できるので、アプリケーションから通信するときはすべて DNS を経由して、名前で検索できるようになります。

あとは、グローバル IPアドレスとかもExternal DNS を使うと外部の DNS と自動連携することができたり、cert-manager を使うと証明書の自動発行や自動登録も可能になります。


 

「VM時代の開発」と「Kubernetes による Cloud Native な開発」のこれから は3部作に分かれています。続きはこちらからご覧ください。

【1部】「VM時代の開発」と「Kubernetes による Cloud Native な開発」のこれから
【2部】「VM時代の開発」と「Kubernetes による Cloud Native な開発」のこれから
【3部】「VM時代の開発」と「Kubernetes による Cloud Native な開発」のこれから

 

Infra Study Meetupとは?

Forkwellは「成長し続けるエンジニアを支援する」をコンセプトに勉強会を開催しています。Infra Study Meetupは、インフラ技術の「これまで」と「これから」を網羅的に学ぶイベントです。インフラ技術の各分野に精通した講師を招いた講演や著名エンジニアによる発表を実施しています。

※注意事項

当記事に掲載されている全ての情報は、イベント実施日時点の情報であり、完全性、正確性、時間の経過、あるいは情報の使用に起因する結果について一切の責任を負わないものとします。

ForlkwellPress ロゴ画像

編集部

Follow

エンジニアに役立つ情報を定期的にお届けします。

エンジニアに役立つ情報を定期的にお届けします。

SHARE

目次

目次