インターネット業界では、市場の需要や製品が常に変化しているため、組織は常に納品や生産環境のアップデートを行うことで適応を迫られています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
序章
本投稿は、「Dockerで継続的デリバリーのあり方を変える」シリーズの第1弾として、Dockerにまつわる背景や課題、プロセスについて解説しています。Dockerは、変革された継続的デリバリーのためのサービスです。後編では、その配信プロセスとともにDockerの活用方法を探っていきます。
Dockerの背景
インターネット業界では、市場の需要や製品が常に変化しているため、組織は生産環境の更新や継続的な納品を行うことで適応していくことを余儀なくされています。このような開発に対する新しいアプローチは、継続的インテグレーション（CI）や継続的デリバリー（CD）と呼ばれ、開発、生産、デリバリーのプロセスを組み合わせて循環的なプロセスに変換するものです。
しかし、このアプローチは長期的にはいくつかの問題を導入しています。その一つは、曖昧な本番環境を、その環境の経験が浅い後継者に引き継ぐことの難しさです。
さらに、最終的な生産開始前に生産環境で行われるデバッグが障害となります。需要や製品が絶え間なく変化するため、メンテナンスが大変なだけでなく、常に更新が必要となります。
従来のCDプロセス：概要と課題
従来の開発ソリューションには、プロセス、継続的インテグレーション（CI）、継続的デリバリー（CD）があります。これらのプラクティスは、開発プロセス、生産プロセス、およびデリバリープロセスを組み合わせ、循環的なプロセスに変換します。
- 統合（2つのものを組み合わせること）：ドキュメントの提出時には、コードはコードと一緒に、コンパイル時には、コードはロジックと一緒に、テスト時には、コードは機能と一緒に、生成からデプロイまで、そしてリリースのための生成時には、コードはシステムと一緒に、システムはシステムと一緒になります。システムが2つのものを組み合わせるたびに、統合が行われます。
- 継続的なテスト：（システムの）物理的な検査のように、最終的な起動前にシステムの欠陥を迅速に発見し、排除するのに役立ち、テストされていない機能、欠落した機能、または欠陥のあるコードセグメントの組み合わせを防止します。一般的に、このプロセスは継続的に行われるべきです。
- フィードバックループ：連続統合パイプのフローチャートでは、各ステップはフィードバックループで構成されています。これにより、迅速なフィードバックが可能になり、問題の特定と修正が容易になります。
例えば、コードを提出した後、開発者はまず、そのコードが他のコードと競合しないことを確認します。また、開発者はコードがユニットテストに合格するようにコンパイルに成功したかどうかをテストします。これらの要件をすべて満たすと、開発者は次の項目に進むことができます。しかし、開発者が衝突しないコードを提出したにもかかわらず、そのコードがシステム全体のコンパイルが成功しなかったというフィードバックを受け取った場合、開発者はそのコードを修正する必要があります。
フィードバックは、開発者が次に何をすべきかを知ることができるように、開発の時点まで速やかにさかのぼらなければなりません。さらに、ユニットテストは、システム機能や統合テストとは切り離しておくべきです。これは、これらのテストの速度が変化し、テストが異なるタイプのフィードバックを生成するからです。
CDプロセスの構築-環境要件
一般的に、企業やプロジェクトでは複数の環境を必要とします。一般的に、企業の本番環境はパブリッククラウドに置かれ、開発プロセスはオフライン環境に置かれます。パブリッククラウド環境とオフラインの開発環境が矛盾していると、最終製品の発売時に問題が発生する可能性があります。
CDプロセス - 遭遇した問題
完全な継続的統合システム環境が体系的に構築されていても、問題が発生することがあります。開発者が異なる言語環境やパッケージに依存している場合もあり、コンパイル環境の競合やメンテナンスが困難になることがあります。
問題の発生源
問題の大部分は、開発者がコードと関連する依存関係を提供するだけで、実際の運用では、動作環境、環境記述、依存関係、データベース、キャッシュなども必要となるために発生します。
Docker: ソフトウェアデリバリーのあり方を変える
Dockerでは、環境の生成に必要な情報はすべて配信されたコードに含まれています。コードには、環境だけでなく、依存関係、キャッシュ、設定、変数、コンテナ、jarパッケージを記述した記述ファイルが含まれています。
このアプローチは、コードとその他の必要なすべてのコンポーネントをコンテナに詰め込み、運用チームにコンテナを納品することに似ています。このコンテナの核となる特徴は、その移植性にあります。コンテナにはすべての環境依存関係が含まれているため、運用環境に関係なく同じ結果を実現することができます。
Dockerのコンピテンシー
Dockerが登場する前は、コンテナを作成するための仕様上の制約が多くありました。Dockerはソフトウェアだけではなく、コンテナを実装するための新しいアプローチです。
- 環境を記述する能力：Dockerファイルは、ソフトウェアが必要とする環境全体を記述することができます。
- 階層的なファイルシステム：Dockerイメージは、各操作をバージョン管理のレイヤーとして記述するパッケージ管理のソリューションを提供します。
- OSの分離：Dockerは実行時にOSの違いを遮蔽します。
Dockerはコンテナ技術
仮想化技術では、ハードウェアとソフトウェアを仮想マシンに仮想化します。各仮想マシンは完全なオペレーティングシステムであり、十分に分離されていますが、起動に数分かかる場合があります。
コンテナ技術の従来の仮想化技術との大きな違いは、すべてのコンテナが完全なオペレーティングシステム層を持たず、親マシンのOSカーネルを自分のものとして使用している点にあります。
コンテナ技術の最大の利点は、従来の仮想マシンを使用しないため、コンテナを数秒で起動できることです。さらに、コンテナは仮想マシンに比べてオーバーヘッドが低いため、ユーザーはより多くのコンテナをサーバー上に配置することができます。
Dockerを使ったソフトウェアデリバリの3つのステップ
1、ビルド：オペレーティングシステムの基盤、環境、起動するポート、実行するスクリプトを記述します。システムは記述ファイルをローカルストレージ内にあるDockerイメージとして保存します。
2、Ship: イメージを一番奥のDockerレジストリにプッシュします。
3、Run: 実行時にパブリックレジストリからイメージをプルします。コンテナは環境記述であると同時に、どのような環境で実行しても同じ結果をレンダリングします。
ケーススタディ BBCニュース
BBC Newsは、世界中に500人以上の開発者が分散している世界的なニュースサイトの会社です。世界各地で異なる言語を使用しているため、10以上のCI環境を持っています。BBC News社は、コーディングプロセスを統一し、CI環境を統一的に管理する方法を考えなければなりませんでした。既存のジョブはスケジュールを組んで実行するのに最大60分かかり、順次実行されていました。Dockerを利用することで、ジョブは並行して実行されるようになり、大幅にスピードアップしました。さらに、コンテナを利用することで、開発者はCI環境を気にする必要がなくなりました。
おわりに
今回の記事では、継続的インテグレーションと継続的デリバリーにおけるDockerとその役割について紹介しました。Dockerを使ったContinuous Deliveryは、主にアプリケーションのリスクを軽減しながら、より短いイテレーションで信頼性の高いソフトウェアを生産することで、より早く価値を提供することを目的としています。
この記事の次の部分では、Dockerの利用方法を検討し、そのビルド環境やUT環境について解説します。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ