この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay4「クラウドネイティブを担うコンテナを改めてライトに学ぶ」となります。

※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。

このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293

以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。

クラウドネイティブを担うコンテナとは？

昨日のDay3にて、クラウドネイティブとは何たるかを簡単にまとめております。クラウドネイティブを実現する技術要素として、マネージドサービスとコンテナを挙げさせていただきました。マネージドサービスは各社でそれぞれ特徴もあるので、各社さんに委ねさせていただくとして、コンテナについてはもう少しどんなものなのかをこちらではライトに説明できればと思います。

まず、代表的なものとしてDockerというものがあるので、そちらを例にまず感覚を養っていただきます。Dockerが整備されたOS（ここでは私のMac上で実行しています）の上で、以下のコマンドを実行すると、nginxというWebサーバーが入ったコンテナが起動します。本来はこちらのスライドにビデオが埋め込まれているのですが、このコンテナの起動は一瞬です。今までは、Webサーバーを用意するにあたっても、OSをインストールし、Webサーバーをインストールして起動するなど、こんな一瞬ではとても終わる作業ではありませんでした。

これは具体的にどういう仕組みで動いているのかですが、まず自前で用意するにせよ、誰かの用意したものを利用するにせよ、コンテナが起動できるコンテナイメージをダウンロードしてきて実行する必要があります。仮想マシンに置き換えると、仮想マシンテンプレートのようなものです。これは非公開の環境に作ることもできますし、Docker Hubのように第三者が用意しているものを利用することもできます。これらのコンテナイメージのポータルにはnginxやphp・Javaといった既に環境構築が整備されたコンテナイメージが準備されています。物に依りますが、仮想マシンテンプレートが数GB〜数十GBとすると、コンテナイメージはMB単位のイメージで済みます。

容量からおわかりいただける通り、すぐにダウンロードは終わります。また、これらを起動するのも一瞬です。すぐに自分のPC上で、nginx等のWebサーバーを起動することができるようになります。詳しい仕組みはここでは解説いたしませんが、とにかく軽量ですぐに起動できるというところが、クラウドネイティブに最適な要素となる技術です。

このコンテナがどのように成立しているのか見ていきます。先程のコンテナイメージというのは、事前に作成しておく必要があります。こちらは一瞬では行きませんが、どのような仕組みで作成しておくことができるのかについて説明します。Dockerの場合、Dockerfileというものにそのコンテナイメージを定義することができます。スライドを見ていただくと分かる通り、FROM句でベースイメージを指定できます。ここでは、nginx 1.21を利用したコンテナイメージをベースにすることが定義されています。その後、RUN句でそのベースイメージ上で実行するコマンドを定義することができます。このRUN句によって、ベースイメージに必要なライブラリなどをインストールしておくことができます。

このDockerfileの通りにコンテナイメージを作りなさいということを指示できるわけです。この作業によって、コンテナイメージを作っておくことができます。つまり、このDockerfileというテキスト情報にこのコンテナに何が入っているかがすべて定義されており、どんな場所にいてもこの通りの環境を共通して再現できるということが大きなメリットとなります。

つまり、今まで仮想マシンというのは、GB単位の非常に大きなサイズであったために、持ち運びにも時間がかかっていましたし、その仮想マシンの中のOSに入っている環境というのはなかなか可視化ができていませんでした。また、仮想マシンというのはクラウドごとに実装方法が異なっていて、それぞれのクラウドベンダーごとにイメージを変換する必要がありました。

一方、コンテナはDockerfileという数KBレベルのものを容易に持ち運ぶことができ、かつその環境が全員同じであることを保証することができるようになるわけです。そのため、開発環境においては、複数の環境を整えるために複数のOSを用意するのではなく、Dockerfileという共通の環境定義ファイルがあるというようなイメージです。また、基本的にはコンテナ実行環境さえあればいいので、自分のPCからクラウド環境まですべてコンテナイメージの変換は不要です。

今までは単一のコンテナについての話でしたが、システムは単一のコンテナによって成立しているわけではなく、複数のコンテナによる集合体になります。それを担っていることでデファクトになっているのはkubernetes(k8s)となります。Dockerfileが単一のコンテナ定義をしていたのと同様に、k8sでも同様のテキストファイルを定義して、複数のコンテナの定義をします。

例えば、どんなコンテナを何台立てるかだけでなく、そのコンテナへのアクセスにロードバランサをどう使うかであるとか、負荷によって何台から何台までスケールアウト、スケールインしてねということも、このテキストファイルに書かれます。このような定義によって、コンテナが起動され、システムとして稼働することになるわけで、こちらも同様にどのようなシステムかというのがこのテキストファイルを見ればわかるようになっています。

今までお話したようなコンテナの軽量性やシステムとしての定義ファイルで実行できるという特徴を利用して、本番環境へのデプロイも自動化・効率化できます。例えば、ブルーグリーンデプロイメントは、現在の本番環境を維持したまま、切り替え予定の本番環境もデプロイして切り替える手法です。もちろんうまく行かなければ即時切り戻しをするのですが、これは今までの仮想マシンなどでは起動にも時間がかかったり、OSごと起動するため、やはりインプレースアップグレードなどになりがちだった部分です。また、カナリアリリースという手法では、現在の本番環境に少しずつ切り替え予定のコンテナを混ぜていき、うまくいくことがわかれば現在の本番環境を少しずつ削っていくというタイプの切替方法です。

このように失敗してもすぐに切り戻せる、失敗しても影響を最小限に抑えるという仕組みを実現できるため、Day3でお話した入念に準備をするというアプローチではなく、とにかくトライするという方法にシフトできるようになるわけです。

CI/CD DevOps DevSecOps

今まではどちらかというと実行環境や本番環境へのクラウドネイティブ対応の技術についての説明でしたが、開発スピードを向上させることも重要というのはDay3の記事でも書いたとおりです。この開発スピードに大きく寄与するのが、CI/CDとかDevOps/DevSecOpsと言われる部分です。

今まではコードを書いた後に、属人的なセキュリティの確認をして、実行可能な形式にビルドしたら、テストして、本番環境へデプロイするという流れだったわけですが、これらはすべて手動であったこと多かったように思います。

しかしながら、現在はセキュリティもコードの脆弱性スキャンや利用ライブラリの脆弱性を確認するサービスであったり、テストを自動化するものが出てきています。つまり、このステップがOKであれば、次のステップに渡してといったことを、全て自動的につなげることができます。これをDevOpsとか、セキュリティのことまで考慮したものであればDevSecOpsという呼び方がされるようになっています。さらにこの中で開発に関する部分をCI（Continuous Integration）、本番環境へのデプロイ部分をCD(Continuous Delivery)と分類しています。

実はこれらの仕組みもテキストファイルで定義されています。こういう条件をクリアしたら次のステップに回すなど、ステップごとにテキストファイルが定義されており、セキュリティ確認がOKであれば、次は実行可能形式へのビルドが行われて…のようなチェーンになるように作られます。CDの部分については、コンテナに限らず、クラウドが提供するマネージドサービスもIaC機能が整っていると思うので、これらと連携することによって自動的にデプロイすることまで可能になります。

私が個人開発をしているアプリケーションでは、このコードで本番環境にデプロイしたいと決めれば、テストや実行可能形式へのビルド、そして本番環境であるFirebaseまでのデプロイが自動化されていたりします。これをソースコードを決めた後に、テストしてOKだったら、実行可能形式へのビルドをして、それが成功したら本番環境へデプロイして…ということをやっていたら、手間すぎて立ち行かなくなるでしょう。

コンテナとは？

ここまで非常にライトな感じで紹介してきましたが、コンテナについて少しでも理解が深まれば幸いです。また、Day3の記事でコンテナが自前の運用が多少必要になる部分については、Dockerfileやk8sを定義するテキストファイルがあり、それらの中身を運用していく必要があるということを通じてわかっていただけたかと思います。クラウドが提供するマネージドサービスは、これらの定義というのをサービス仕様としているわけで、このサービス仕様を変えられない分、構築が不要であったり、スケールの設計が不要であったりということになり、便利に感じる部分があるわけです。逆にコンテナは、これらを運用する必要があるものの、マネージドサービスの仕様の範囲を超える自由度を手に入れることができるわけです。

Day3でも書きましたが、これらは一長一短であり、どちらが適しているかは、そのシステムの特性・要件とクラウド技術への習熟、既存の技術・人材の制約次第だということです。少なくともこのあたりを理解しておいていただければ、クラウドの利用やアプリケーションの方向性について判断できる下地にできているのではないかと思います。

執筆後記

このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day4以降もお待ちいただければと思います。

• ガバメントクラウドの在り方

• ガバメントクラウドの整備における課題感

• ガバメントクラウドの利用における課題感

• ガバメントクラウドの今後について考えてみる

Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。