Dockerによる継続的デリバリーの実践（レビューとビデオ）

テクニカルディレクターdistol （Dmitry Stolyarov）の最近のスピーチに基づいて作成された出版物からブログを開始します。 それらはすべて、2016年にさまざまなプロのイベントで開催され、DevOpsとDockerのテーマに専念していました。 BadooのオフィスでのDocker Moscowの会議のビデオの1つは、すでにサイトに公開されています。 新しいものには、レポートの本質を伝える記事が添付されます。 だから...



5月31日、ロシアのインターネットテクノロジーフェスティバル（RIT ++ 2016）の一環として開催されたRootConf 2016会議で、レポート「Dockerによる継続的配信のベストプラクティス」で継続的展開および展開セクションが開きました。 Dockerおよびその他のオープンソース製品を使用して継続的デリバリー（CD）プロセスを構築するためのベストプラクティスをまとめて体系化しました。 これらのソリューションは実稼働環境で使用されているため、実際の経験に頼ることができます。







ビデオレポートに 1時間を費やす機会がある場合は、完全に見ることをお勧めします。 それ以外の場合-以下はテキスト形式のメインスクイーズです。

Dockerによる継続的デリバリー

継続的デリバリとは、一連のイベントを意味します。その結果、Gitリポジトリからのアプリケーションコードが最初に実稼働状態になり、その後アーカイブに移動します。 Git→ビルド（アセンブリ）→テスト（テスト）→リリース（リリース）→操作（後続のメンテナンス）のようになります。





レポートのほとんどはビルドステージ（アプリケーションアセンブリ）に当てられており、リリースと操作のトピックは概要で説明されています。 これらを解決できる問題とパターンについて説明しますが、これらのパターンの特定の実装は異なる場合があります。



なぜここでDockerが必要なのですか？ このオープンソースツールのコンテキストで継続的デリバリーの実践について話すことにしたからという理由だけではありません。 レポート全体がアプリケーションに当てられていますが、アプリケーションコードを展開する主なパターンを検討する際には、多くの理由がすでに明らかにされています。

メインロールアウトパターン

そのため、アプリケーションの新しいバージョンを展開するときに、運用サーバーの切り替え中に発生するダウンタイムの問題に必ず遭遇します。 古いバージョンのアプリケーションから新しいバージョンへのトラフィックはすぐに切り替えることができません。まず、新しいバージョンが正常にダウンロードされるだけでなく、「ウォームアップ」されていることを確認する必要があります。





したがって、しばらくの間、アプリケーションの両方のバージョン（古いものと新しいもの）が同時に機能します。 ネットワーク、ファイルシステム、IPCなど、 共有リソースの競合が自動的に発生します。 Dockerを使用すると、同じホスト（サーバー/仮想マシン）内でリソースの分離が保証される別々のコンテナーで異なるバージョンのアプリケーションを実行することにより、この問題を簡単に解決できます。 もちろん、まったく分離せずにいくつかのトリックを行うことができますが、既製の便利なツール、つまり逆の理由がある場合、それを無視しないでください。



コンテナ化には、デプロイ時に他の多くの利点があります。 すべてのアプリケーションは、 インタープリターの 特定のバージョン （またはバージョンの範囲）、モジュール/拡張機能などの存在、およびそれらのバージョンに依存します。 また、これは、即時実行可能環境だけでなく、 システムソフトウェアとそのバージョン（使用されているLinuxディストリビューションまで）を含む環境全体にも適用されます。 コンテナにはアプリケーションコードだけでなく、必要なバージョンのプリインストールされたシステムおよびアプリケーションソフトウェアも含まれているため、依存関係の問題を忘れることができます。



リストされた要因を考慮して、新しいバージョンを展開する主なパターンを要約します。

1. 最初に、アプリケーションの古いバージョンが最初のコンテナで実行されます。
2. 次に、新しいバージョンが展開され、2番目のコンテナで「ウォームアップ」されます。 この新しいバージョン自体が、更新されたアプリケーションコードだけでなく、その依存関係、およびシステムコンポーネント（たとえば、OpenSSLの新しいバージョンまたはディストリビューション全体）を保持できることは注目に値します。
3. 新しいバージョンがリクエストを処理する準備が完全に整ったら、トラフィックは最初のコンテナから2番目のコンテナに切り替わります。
4. これで、古いバージョンを停止できます。

異なるバージョンのアプリケーションを別々のコンテナにデプロイするこのアプローチでは、もう1つの利便性が得られます。古いバージョンにすばやくロールバックできます （結局、必要なコンテナにトラフィックを切り替えるだけで十分です）。





最後の最初の推奨事項は、キャプテンでさえもめないことです：「 [Dockerで継続的デリバリーを編成する場合] Dockerを使用する [そしてそれが与えることを理解する] 」。 これは問題を解決する「銀の弾丸」ではなく、素晴らしい基盤を提供するツールであることを忘れないでください。

再現性

「再現性」とは、アプリケーションの操作時に発生する一般的な一連の問題を意味します。 そのような場合について話している：

• 品質部門がステージングに関して検証したシナリオは、本番環境で正確に再現する必要があります。
• アプリケーションは、リポジトリのさまざまなミラーからパッケージを受信できるサーバー上で公開されます（時間の経過とともに、インストールされたアプリケーションのバージョンとともに更新されます）。
• 「すべてがローカルで機能します！」（...および開発者は本番環境では許可されていません。）
• 古い（アーカイブされた）バージョンの何かをチェックする必要があります。
• ...

それらの一般的な本質は、使用される環境の完全なコンプライアンス（および人的要因の不在）が必要であるという事実に要約されます。 再現性を保証する方法は？ Gitのコードに基づいてDockerイメージを作成し、それを任意のタスクに使用します：テストプラットフォーム、運用環境、プログラマーのローカルマシン...イメージの作成後に実行されるアクションを最小限に抑えることが重要です。エラーが発生する可能性が少ないほど重要です。

インフラストラクチャはコードです

インフラストラクチャの要件（サーバーソフトウェアの可用性、バージョンなど）が正式でなく、「プログラミング」されていない場合、アプリケーションの更新を展開すると、悲惨な結果に終わる可能性があります。 たとえば、ステージングでは、すでにPHP 7.0に切り替えており、それに応じてコードを書き直しています。古いPHP（5.5）を使用した実稼働環境での外観は、きっと驚くでしょう。 インタプリタのバージョンの大きな変更を忘れないかもしれませんが、「悪魔は細部に宿っています」：依存関係のマイナーな更新であることが判明するかもしれません。



この問題を解決するアプローチはIaC（Infrastructure as Code）として知られており、インフラストラクチャ要件をアプリケーションコードと共に保存する必要があります。 それを使用する場合、開発者とDevOpsスペシャリストは、アプリケーションの1つのGitリポジトリを、その異なる部分で作業できます。 このコードから、GitはDockerイメージを作成します。Dockerイメージでは、インフラストラクチャのすべての詳細を考慮して、アプリケーションがデプロイされます。 簡単に言えば、イメージを組み立てるためのスクリプト（ルール）は、ソースコードと同じリポジトリに配置し、一緒にマージする必要があります。







マルチレイヤーアプリケーションアーキテクチャの場合（たとえば、Dockerコンテナー内で既に実行されているアプリケーションの前にあるnginxがあります）、各レイヤーのGitのコードからDockerイメージを作成する必要があります。 次に、最初のイメージにはインタープリターと他の「最も近い」依存関係を持つアプリケーションがあり、2番目のイメージにはアップストリームのnginxがあります。

Docker Images Gitリンク

GitからコンパイルされたすべてのDockerイメージは、一時とリリースの2つのカテゴリに分類されます。 一時的な画像は Gitのブランチの名前でタグ付けされ、次のコミットで上書きでき、プレビュー用にのみ展開できます（本番用ではありません）。 これは、リリース版との重要な違いです。具体的なコミットがどのようなものであるかはわかりません。



マスターブランチ（マスターの現在のバージョンを常に表示するために別のプラットフォームに自動的にロールアウトできます）、リリースブランチ、特定のイノベーションのブランチなど、一時的なイメージで収集することは理にかなっています。





一時的な画像のプレビューがプロダクションでの翻訳の必要になった後、開発者は特定のタグを付けました。 リリースイメージはタグによって自動的に収集され（そのタグはGitのタグに対応します）、ステージングにロールアウトされます。 品質部門による成功したチェックの場合、彼は生産に行きます。

ダップ

説明されているすべて（ロールアウト、イメージのアセンブリ、その後のメンテナンス）は、Bashスクリプトおよびその他の「即興」手段を使用して個別に実装できます。 しかし、これを行うと、ある時点で実装が非常に複雑になり、処理が不十分になります。 これを理解して、CI / CD- dappを構築するための専用のワークフローユーティリティを作成しました 。



ソースコードはRubyで書かれており、 GitHubで公開されています 。 残念ながら、現時点でのドキュメントはツールの最も弱い点ですが、現在作業中です。 そして何度も何度もdappについて書いて話します。 関心のあるコミュニティ全体とその機能を共有したいと心から願っていますが、今のところは問題を送信してリクエストをプルし、GitHubでプロジェクトの開発をフォローしてください。



2019年8月13日更新： dappプロジェクトの名前がwerfに変更され、そのコードが完全にGoに書き換えられ、ドキュメントが大幅に改善されました。

クベルネテス

プロフェッショナル環境ですでに大きな認知を得ているもう1つの既製のオープンソースツールは、Dockerを管理するためのクラスターであるKubernetesです。 Dockerで構築されたプロジェクトの運用における使用のトピックはレポートの範囲を超えているため、プレゼンテーションはいくつかの興味深い機能の概要に限定されています。



Kubernetesのロールアウトでは次を提供します。

• 準備状況プローブ-アプリケーションの新しいバージョンの準備状況を確認します（トラフィックを切り替えます）。
• ローリング更新-コンテナからのクラスター内のイメージの順次更新（シャットダウン、更新、起動の準備、トラフィック切り替え）;
• 同期更新-異なるアプローチでクラスター内のイメージを更新します。最初にコンテナーの半分で、次に残りで。
• カナリアリリース-異常を監視するために、限られた（少数の）コンテナで新しいイメージを起動します。

継続的デリバリは新しいバージョンのリリースだけではないため、Kubernetesにはインフラストラクチャのその後のメンテナンスのための多くの機会があります：すべてのコンテナにわたる組み込みの監視とログ記録、自動スケーリングなど。

最終的な推奨事項

1. Dockerを使用します。
2. Dockerアプリの画像をすべてのニーズに合わせて作成します。
3. 「インフラストラクチャはコードです」という原則に従います。
4. GitをDockerに関連付けます。
5. ロールアウト順序を調整します。
6. 既製のプラットフォーム（Kubernetesなど）を使用します。

ビデオとスライド

スピーチのビデオ（約1時間）がYouTubeで公開されました （レポート自体は5分から始まります。 リンクはリンク上のこの瞬間からです） 。



レポートのプレゼンテーション：

PS

ブログのトピックに関するその他のレポート：

• 「 WerfはKubernetesのCI / CDツールです（レビューおよびビデオレポート） 」 （Dmitry Stolyarov、2019年5月27日、DevOpsConf） 。
• “ データベースとKubernetes ” （Dmitry Stolyarov; 2018年11月8日HighLoad ++） ;
• 「 KubernetesとGitLabでのCI / CDのベストプラクティス 」 （Dmitry Stolyarov; 2017年11月7日HighLoad ++） ;
• 「 小規模プロジェクトでのKubernetesでの経験 」 （Dmitry Stolyarov、2017年6月6日、RootConfで） 。