🥇Docker を使用した継続的デリバリーの実践 (レビューとビデオ)

当社のテクニカルディレクターの最新の講演に基づいた出版物からブログを開始します。ディストル（ドミトリー・ストリャロフ）。これらはすべて 2016 年にさまざまな専門的なイベントで開催され、DevOps と Docker のトピックに特化したものでした。 Badoo オフィスで行われた Dockerモスクワミーティングの XNUMX つのビデオは、すでに公開されています。公開オンライン。新しいものには、レポートの本質を伝える記事が追加されます。それで…

31月XNUMX日のカンファレンスにて RootConf 2016フェスティバル「Russian Internet Technologies」（RIT++ 2016）の一環として開催された「継続的デプロイメントとデプロイメント」セクションは、「Docker を使用した継続的デリバリーのベストプラクティス」レポートで始まりました。 Docker やその他のオープンソース製品を使用して継続的デリバリー (CD) プロセスを構築するためのベストプラクティスを要約し、体系化しました。私たちは実稼働環境でこれらのソリューションを使用しているため、実際の経験に頼ることができます。

XNUMX時間もお時間いただける機会がございましたら、 レポートのビデオ, フル視聴することをおすすめします。それ以外の場合は、主な概要をテキスト形式で以下に示します。

Docker を使用した継続的デリバリー

下に 連続放出 私たちは、アプリケーションコードが Git リポジトリから最初に実稼働環境に到達し、その後アーカイブに到達するという一連のイベントを理解しています。彼女はこんな感じです。 Git → ビルド → テスト → リリース → 運用.

レポートの大部分はビルド段階 (アプリケーションのアセンブリ) に当てられており、リリースと操作のトピックについては簡単に触れられています。 問題とそれを解決できるパターンについて説明しますが、これらのパターンの具体的な実装は異なる場合があります。

そもそもなぜここで Docker が必要なのでしょうか? このオープンソースツールの文脈で継続的デリバリーの実践について話すことにしたのは当然のことでした。レポート全体はその使用法に特化していますが、アプリケーションコードのロールアウトの主なパターンを考慮すると、多くの理由が明らかになります。

主な展開パターン

したがって、アプリケーションの新しいバージョンをロールアウトするときは、必ず次のような問題に直面します。 ダウンタイムの問題、本番サーバーの切り替え時に生成されます。アプリケーションの古いバージョンから新しいバージョンへのトラフィックを即座に切り替えることはできません。まず、新しいバージョンが正常にダウンロードされただけでなく、「ウォームアップ」していること (つまり、リクエストを処理する完全な準備ができていること) を確認する必要があります。

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

コンテナ化は、導入時に他にも多くの利点をもたらします。どのアプリケーションも依存します 特定のバージョン (またはバージョン範囲) 通訳者、モジュール/拡張機能などの可用性とそのバージョン。そして、これは直接実行可能な環境だけでなく、環境全体にも当てはまります。 システムソフトウェア とそのバージョン (使用される Linux ディストリビューションまで)。コンテナにはアプリケーションコードだけでなく、必要なバージョンのプレインストールされたシステムソフトウェアとアプリケーションソフトウェアも含まれているため、依存関係の問題を忘れることができます。

一般化しましょう 主な展開パターン 新しいバージョンでは、次の要素が考慮されます。

最初は、古いバージョンのアプリケーションが最初のコンテナーで実行されます。
その後、新しいバージョンがロールアウトされ、XNUMX 番目のコンテナーで「ウォームアップ」されます。この新しいバージョン自体には、更新されたアプリケーションコードだけでなく、その依存関係やシステムコンポーネント (たとえば、OpenSSL の新しいバージョンやディストリビューション全体) も含まれる可能性があることに注意してください。
新しいバージョンがリクエストを処理する準備が完全に整うと、トラフィックは最初のコンテナから XNUMX 番目のコンテナに切り替わります。
古いバージョンを停止できるようになりました。

アプリケーションの異なるバージョンを別々のコンテナーにデプロイするこのアプローチには、別の利便性が提供されます。 クイックロールバック 古いバージョンに戻します (結局のところ、トラフィックを目的のコンテナーに切り替えるだけで十分です)。

最後の最初の推奨事項は、船長ですら非を見つけることができないもののように聞こえます。[Docker を使用して継続的デリバリーを構成する場合] Docker を使用する [そしてそれが何をもたらすかを理解する]」これはすべての問題を解決する特効薬ではなく、素晴らしい基盤を提供するツールであることを忘れないでください。

再現性

「再現性」とは、アプリケーションを操作するときに遭遇する一般化された一連の問題を意味します。私たちはそのようなケースについて話しています。

ステージングのために品質部門によってチェックされたスクリプトは、本番環境で正確に再現される必要があります。
アプリケーションは、さまざまなリポジトリミラーからパッケージを受信できるサーバー上で公開されます (時間の経過とともに、アプリケーションは更新され、インストールされているアプリケーションのバージョンも更新されます)。
「地元ではすべてうまくいきます！」 (...そして開発者は運用環境に入ることができません。)
古い (アーカイブされた) バージョンで何かを確認する必要があります。
...

その一般的な本質は、使用される環境の完全な遵守（および人的要因の不在）が必要であるという事実に要約されます。再現性をどのように保証できるでしょうか? Dockerイメージを作成する Git のコードに基づいて、テストサイト、運用環境、プログラマーのローカルマシンなど、あらゆるタスクに使用します。同時に、実行されるアクションを最小限に抑えることが重要です。後の画像の組み立て: 単純であればあるほど、エラーが発生する可能性は低くなります。

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

インフラストラクチャ要件 (サーバーソフトウェアの可用性、そのバージョンなど) が形式化されておらず、「プログラム」されていない場合、アプリケーションの更新をロールアウトすると、悲惨な結果が生じる可能性があります。たとえば、ステージングではすでに PHP 7.0 に切り替え、それに応じてコードを書き直しています。その後、本番環境で古い PHP (5.5) が使用されていると、きっと誰かが驚くでしょう。インタプリタのバージョンにおける大きな変更を忘れることはないかもしれませんが、「悪魔は細部に宿る」のです。驚きは依存関係のマイナーアップデートにあるかもしれません。

この問題を解決するアプローチは次のように知られています。 IaC (Infra Structure as Code、「コードとしてのインフラストラクチャ」) これには、アプリケーションコードとともにインフラストラクチャ要件を保存することが含まれます。これを使用すると、開発者と DevOps スペシャリストは、同じ Git アプリケーションリポジトリを、その異なる部分で操作できます。このコードから、Git で Docker イメージが作成され、インフラストラクチャの詳細をすべて考慮してアプリケーションがデプロイされます。簡単に言えば、画像を組み立てるためのスクリプト (ルール) はソースコードと同じリポジトリに存在し、マージされる必要があります。

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

Docker イメージ、Git との通信

Git から収集されたすべての Docker イメージは、一時とリリースの XNUMX つのカテゴリに分類されます。 一時的なイメージ Git のブランチの名前でタグ付けされており、次のコミットによって上書きされる可能性があり、プレビューのみにロールアウトされます (本番環境にはロールアウトされません)。これがリリース版との主な違いです。どの特定のコミットが含まれているかは決してわかりません。

一時イメージに収集することは理にかなっています。マスターブランチ (マスターブランチを別のサイトに自動的にロールアウトして、マスターの現在のバージョンを常に確認できます)、リリースのあるブランチ、特定のイノベーションのブランチです。

一時イメージのプレビューを実稼働環境に変換する必要が生じた後、開発者は特定のタグを付けます。タグごとに自動収集 リリースイメージ (そのタグは Git のタグに対応します) ステージングにロールアウトされます。品質部門による検証が成功すると、生産に進みます。

ダップ

ここで説明した内容 (ロールアウト、イメージのアセンブリ、その後のメンテナンス) はすべて、Bash スクリプトやその他の「即席」ツールを使用して独立して実装できます。しかし、これを行うと、ある時点で実装が非常に複雑になり、制御性が低下することになります。これを理解して、私たちは CI/CD を構築するための独自の特殊なワークフローユーティリティを作成するようになりました。 ダップ.

そのソースコードは Ruby で書かれており、オープンソースで公開されています。 GitHubの。残念ながら、現時点ではドキュメントがこのツールの最大の弱点ですが、私たちはそれに取り組んでいます。そして、私たちは dapp について何度も書いたり話したりするつもりです。なぜなら... 関心のあるコミュニティ全体とその機能を共有するのが待ちきれませんが、それまでの間、問題やプルリクエストを送信したり、GitHub でプロジェクトの開発をフォローしたりしてください。

13 年 2019 月 XNUMX 日更新: 現在プロジェクト中 ダップ に名前変更されました ワーフ、そのコードは Go で完全に書き直され、ドキュメントは大幅に改善されました。

Kubernetes

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

ロールアウトのために、Kubernetes は以下を提供します。

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

継続的デリバリーは単に新しいバージョンをリリースするだけではないため、Kubernetes にはその後のインフラストラクチャのメンテナンスのための多くの機能 (すべてのコンテナの組み込み監視とロギング、自動スケーリングなど) が備わっています。これらはすべてすでに機能しており、適切な機能が追加されるのを待つだけです。プロセスへの実装。

最終的な推奨事項

ドッカーを使用します。
あらゆるニーズに対応するアプリケーションの Docker イメージを作成します。
「インフラストラクチャはコードである」という原則に従ってください。
Git を Docker にリンクします。
ロールアウトの順序を調整します。
既製のプラットフォーム (Kubernetes またはその他) を使用します。

ビデオとスライド

パフォーマンス動画（約XNUMX時間） YouTubeで公開された (レポート自体は 5 分から始まります - この瞬間から再生するにはリンクをクリックしてください).

報告書のプレゼンテーション:

PS

私たちのブログのトピックに関するその他のレポート:

«werf - Kubernetes の CI / CD 用ツール (概要とビデオレポート)» (Dmitry Stolyarov、27 年 2019 月 XNUMX 日、DevOpsConf にて);
«データベースとKubernetes» (Dmitry Stolyarov、8 年 2018 月 XNUMX 日 HighLoad++);
«Kubernetes と GitLab を使用した CI/CD のベストプラクティス» (Dmitry Stolyarov、7 年 2017 月 XNUMX 日 HighLoad++);
«小規模プロジェクトにおける Kubernetes の経験» (ドミトリー・ストリャロフ、6 年 2017 月 XNUMX 日、RootConf にて).

出所： habr.com

Docker を使用した継続的デリバリーの実践 (レビューとビデオ)