Docker と Gitlab CI を使用した開発とテストのプロセス

Inventos の Alexander Sigachev によるレポート「Docker + Gitlab CI を使用した開発とテストのプロセス」のトランスクリプトを読むことを提案します。

Docker + Gitlab CI に基づいた開発およびテスト プロセスの実装を始めたばかりの人は、基本的な質問をすることがよくあります。 どこから始めればよいでしょうか? どのように整理すればよいでしょうか？ テスト方法は?

このレポートは、Docker と Gitlab CI を使用した開発とテストのプロセスについて構造化された方法で説明されているため、優れています。 このレポート自体は 2017 年のものです。 このレポートから、基本、方法論、考え方、使用経験を学ぶことができると思います。

気にしない人は猫の下にいてください。

私の名前はアレクサンダー・シガチェフです。 私はインベントスで働いています。 Docker を使用した私の経験と、社内のプロジェクトに Docker を徐々に導入している方法についてお話します。

プレゼンテーションのトピック: Docker と Gitlab CI を使用した開発プロセス。

これは Docker についての 2 回目の話です。 最初のレポートの時点では、開発者のマシン上でのみ Docker in Development を使用していました。 Dockerを使っていた社員の数は3～XNUMX人程度でした。 徐々に経験を積んで、少しずつ前進してきました。 私たちのへのリンク 最初のレポート.

このレポートには何が記載されるのでしょうか? 私たちが集めた熊手や、解決した問題についての経験を共有します。 どこも美しいわけではありませんでしたが、先に進むことができました。

私たちのモットーは、手に入るものはすべてドッキングすることです。

私たちはどのような問題を解決しているのでしょうか?

社内に複数のチームがある場合、プログラマーは共有リソースとなります。 プログラマーがあるプロジェクトから引き抜かれ、しばらくの間別のプロジェクトに任される段階があります。

プログラマーがすぐに理解できるようにするには、プロジェクトのソース コードをダウンロードして、できるだけ早く環境を起動する必要があります。これにより、このプロジェクトの問題の解決をさらに進めることができます。

通常、ゼロから始める場合、プロジェクトにはほとんどドキュメントがありません。 設定方法に関する情報は古参の方のみに公開されています。 従業員は XNUMX ～ XNUMX 日で自分たちで職場を設営します。 これを高速化するために、Docker を使用しました。

次の理由は、開発における設定の標準化です。 私の経験では、開発者は常に主導権を握ります。 XNUMX 件ごとに、カスタム ドメイン (vasya.dev など) が入力されます。 彼の隣に座っているのは隣人の Petya で、そのドメインは petya.dev です。 このドメイン名を使用して、Web サイトまたはシステムのコンポーネントを開発します。

システムが成長し、これらのドメイン名が構成に組み込まれ始めると、開発環境の競合が発生し、サイト パスが書き換えられます。

データベース設定でも同じことが起こります。 セキュリティを気にせず、空の root パスワードを使用して作業する人もいます。 インストール段階で、MySQL は誰かにパスワードを要求し、そのパスワードは 123 であることが判明しました。開発者のコ​​ミットに応じてデータベース構成が常に変更されることがよくあります。 誰かが設定を修正しましたが、誰かが設定を修正しませんでした。 ある種のテスト構成を取り出したときにトリックがありました。 .gitignore そして各開発者はデータベースをインストールする必要がありました。 このため、始めるのが難しくなりました。 とりわけ、データベースについて覚えておく必要があります。 データベースの初期化、パスワードの入力、ユーザーの登録、テーブルの作成などが必要です。

もう 2017 つの問題は、ライブラリのバージョンが異なることです。 開発者がさまざまなプロジェクトに取り組むことがよくあります。 5.5 年前 (5.7 年から - 編注) から始まったレガシープロジェクトがあります。 立ち上げ時には、MySQL 2017 から開始しました。 MySQL のより新しいバージョン、たとえば XNUMX 以前 (XNUMX 年 - 編注) を実装しようとする最新のプロジェクトもあります。

MySQL を扱う人なら誰でも、これらのライブラリには依存関係が伴うことを知っています。 ２塁を併走するのはかなり問題がある。 少なくとも、古いクライアントが新しいデータベースに接続するには問題があります。 これにより、いくつかの問題が発生します。

次の問題は、開発者がローカル マシンで作業する場合、ローカル リソース、ローカル ファイル、ローカル RAM を使用することです。 問題に対するソリューションを開発する際のすべての対話は、3 台のマシン上で動作するというフレームワーク内で実行されます。 例としては、Production 3 にバックエンド サーバーがあり、開発者がファイルをルート ディレクトリに保存し、そこから nginx がファイルを取得してリクエストに応答する場合です。 このようなコードが運用環境に侵入すると、そのファイルが XNUMX つのサーバーのいずれかに存在することがわかります。

マイクロサービスの方向性は現在発展しつつあります。 大規模なアプリケーションを、相互に対話するいくつかの小さなコンポーネントに分割する場合。 これにより、特定のタスクのスタックに対してテクノロジを選択できるようになります。 また、開発者間で作業と責任を共有することもできます。

フロントエンド開発者は JS 上で開発しており、バックエンドにはほとんど影響を与えません。 バックエンド開発者は、この場合、Ruby on Rails を開発し、Frondend には干渉しません。 インタラクションは API を使用して実行されます。

おまけに、Docker の助けを借りて、ステージングでリソースをリサイクルすることができました。 各プロジェクトにはその特性があるため、特定の設定が必要でした。 物理的には、仮想サーバーを割り当てて個別に構成するか、ある種の可変環境を共有する必要があり、ライブラリのバージョンによってはプロジェクトが相互に影響を与える可能性がありました。

ツール。 何を使うのでしょうか？

• ドッカー自体。 Dockerfile は、単一アプリケーションの依存関係を記述します。
• Docker-compose は、いくつかの Docker アプリケーションをまとめたバンドルです。
• ソースコードの保存には GitLab を使用します。
• システム統合にはGitLab-CIを利用しています。

レポートは XNUMX つの部分から構成されます。

最初の部分では、開発者のマシン上で Docker がどのように実行されたかについて説明します。

XNUMX 番目のパートでは、GitLab と対話する方法、テストを実行する方法、ステージングに展開する方法について説明します。

Docker は、(宣言的アプローチを使用して) 必要なコンポーネントを記述することを可能にするテクノロジーです。 これは Dockerfile の例です。 ここで、公式の Ruby:2.3.0 Docker イメージから継承していることを宣言します。 Ruby バージョン 2.3 がインストールされています。 必要なビルド ライブラリと NodeJS をインストールします。 ディレクトリを作成することを説明します /app。 アプリディレクトリを作業ディレクトリとして設定します。 このディレクトリに、必要な最小限の Gemfile と Gemfile.lock を配置します。 次に、この依存関係イメージをインストールするプロジェクトをビルドします。 コンテナーが外部ポート 3000 でリッスンする準備ができていることを示します。最後のコマンドは、アプリケーションを直接起動するコマンドです。 プロジェクト開始コマンドを実行すると、アプリケーションは指定されたコマンドを実行しようとします。

これは、docker-compose ファイルの最小限の例です。 この場合、XNUMX つのコンテナー間に接続があることを示します。 これはデータベース サービスと Web サービスに直接反映されます。 ほとんどの場合、Web アプリケーションはデータを保存するためのバックエンドとして何らかのデータベースを必要とします。 ここでは MySQL を使用しているため、例は MySQL を使用していますが、他のデータベース (PostgreSQL、Redis) を使用することを妨げるものはありません。

Docker ハブの公式ソースから MySQL 5.7.14 のイメージを変更せずに取得します。 Web アプリケーションを担当するイメージを現在のディレクトリから収集します。 最初の起動時に画像を収集します。 次に、ここで実行しているコマンドが実行されます。 戻ると、Puma 経由の起動コマンドが定義されていることがわかります。 Puma は Ruby で書かれたサービスです。 XNUMX 番目のケースでは、オーバーライドします。 このコマンドは、ニーズやタスクに応じて任意に使用できます。

また、開発者ホスト マシンのポートをコンテナ ポートの 3000 から 3000 に転送する必要があることについても説明します。 これは、Docker に直接組み込まれている iptables とそのメカニズムを使用して自動的に行われます。

開発者は、以前と同様に、利用可能な任意の IP アドレスにアクセスすることもできます。たとえば、127.0.0.1 はマシンのローカルまたは外部 IP アドレスです。

最後の行は、Web コンテナが DB コンテナに依存していることを示しています。 Web コンテナの開始を呼び出すと、docker-compose が最初にデータベースを開始します。 データベースの開始時に (実際には、コンテナーの起動後です。これはデータベースの準備が整っていることを保証するものではありません)、バックエンドであるアプリケーションを起動します。

これにより、データベースが起動していないときのエラーが回避され、データベース コンテナーを停止するときにリソースが節約され、他のプロジェクトにリソースが解放されます。

プロジェクトでデータベース Dockerization を使用できるようになった理由。 すべての開発者向けに MySQL のバージョンを修正します。 これにより、バージョンが異なる場合、構文、構成、デフォルト設定が変更された場合に発生する可能性のあるエラーが回避されます。 これにより、データベース、ログイン、パスワードに共通のホスト名を指定できます。 私たちは、以前のように構成ファイル内の名前と競合の動物園から脱却しつつあります。

開発環境には、デフォルトとは異なる、より最適な構成を使用する機会があります。 MySQL はデフォルトで弱いマシン向けに構成されており、そのままの状態ではパフォーマンスが非常に悪いです。

Docker を使用すると、必要なバージョンの Python、Ruby、NodeJS、PHP インタープリターを使用できます。 ある種のバージョン マネージャーを使用する必要がなくなります。 以前の Ruby では、プロジェクトに応じてバージョンを変更できる rpm パッケージが使用されていました。 また、Docker コンテナーのおかげで、コードをスムーズに移行し、依存関係とともにバージョン管理することもできます。 インタプリタとコードの両方のバージョンを問題なく理解できます。 バージョンを更新するには、古いコンテナを下げ、新しいコンテナを上げます。 何か問題が発生した場合は、新しいコンテナを下げ、古いコンテナを持ち上げることができます。

イメージをビルドすると、開発環境と運用環境の両方のコンテナーが同じになります。 これは特に大規模なインストールに当てはまります。

フロントエンドでは JavaScipt と NodeJS を使用します。

これで、ReacJS 上の最後のプロジェクトが完成しました。 開発者はコンテナ内のすべてを実行し、ホットリロードを使用して開発しました。

次に、JavaScipt アセンブリ タスクが起動され、静的にコンパイルされたコードが nginx の保存リソースを通じて提供されます。

ここで私たちの前回のプロジェクトのスキームを示しました。

どのようなタスクが解決されましたか? モバイルデバイスが連携するシステムを構築する必要がありました。 彼らはデータを受け取ります。 XNUMX つの可能性は、このデバイスにプッシュ通知を送信することです。

このために私たちは何をしましたか？

私たちは、JS 上の管理部分、Ruby on Rails の REST インターフェースを介して動作するバックエンドなどのコンポーネントにアプリケーションを分割しました。 バックエンドはデータベースと対話します。 生成された結果はクライアントに渡されます。 管理パネルは、REST インターフェイスを介してバックエンドおよびデータベースと対話します。

プッシュ通知を送信する必要もありました。 その前には、モバイル プラットフォームに通知を配信するメカニズムを実装するプロジェクトがありました。

私たちは次のスキームを開発しました。ブラウザーからのオペレーターが管理パネルと対話し、管理パネルがバックエンドと対話し、タスクはプッシュ通知を送信することです。

プッシュ通知は、NodeJS に実装されている別のコンポーネントと対話します。

キューが構築され、そのメカニズムに従って通知が送信されます。

ここでは 2 つのデータベースが描かれています。 現時点では、Docker の助けを借りて、互いにまったく関連性のない XNUMX つの独立したデータベースを使用しています。 さらに、共通の仮想ネットワークがあり、物理データは開発者のマシン上の異なるディレクトリに保存されます。

同じですが、数値的には同じです。 ここでコードの再利用が重要になります。

先ほどライブラリの形式でコードを再利用することについて説明しましたが、この例では、プッシュ通知に応答するサービスが完全なサーバーとして再利用されます。 API を提供します。 そして、私たちの新しい開発はすでにそれと相互作用しています。

当時、NodeJS のバージョン 4 を使用していました。 現在 (2017 年 - 編注)、最近の開発では NodeJS のバージョン 7 を使用しています。 新しいコンポーネントに新しいバージョンのライブラリが含まれても問題はありません。

必要に応じて、プッシュ通知サービスからリファクタリングして NodeJS バージョンを上げることができます。

また、API の互換性を維持できれば、これまで使用していた他のプロジェクトに置き換えることも可能になります。

Dockerを追加するには何が必要ですか? 必要な依存関係を記述する Dockerfile をリポジトリに追加します。 この例では、コンポーネントが論理的に分割されています。 これはバックエンド開発者の最小セットです。

新しいプロジェクトを作成するときは、Dockerfile を作成し、目的のエコシステム (Python、Ruby、NodeJS) を記述します。 docker-compose では、必要な依存関係であるデータベースについて説明します。 特定のバージョンのデータベースが必要であり、あちこちにデータを保存する必要があると説明します。

静的サービスを提供するために、nginx を備えた別の XNUMX 番目のコンテナを使用します。 写真のアップロードが可能です。 バックエンドはそれらを事前に準備されたボリュームに配置します。このボリュームも nginx を使用してコンテナーにマウントされ、静的になります。

nginx、mysql 構成を保存するために、必要な構成を保存する Docker フォルダーを追加しました。 開発者が自分のマシン上でリポジトリの git clone を実行すると、ローカル開発の準備ができたプロジェクトがすでに完成しています。 どのポートやどの設定を適用するかは問題ありません。

次に、管理、通知 API、プッシュ通知といういくつかのコンポーネントがあります。

これらすべてを開始するために、dockerized-app と呼ばれる別のリポジトリを作成しました。 現時点では、各コンポーネントの前に複数のリポジトリを使用しています。 これらは論理的に異なるだけです。GitLab ではフォルダーのように見えますが、開発者のマシンでは特定のプロジェクトのフォルダーになります。 XNUMX つ下のレベルは、結合されるコンポーネントです。

これは dockerized-app の内容のみの例です。 ここでは Docker ディレクトリも持ち出し、すべてのコンポーネントの対話に必要な設定をここに入力します。 プロジェクトの実行方法を簡単に説明した README.md があります。

ここでは XNUMX つの docker-compose ファイルを適用しました。 これは、段階的に実行できるようにするために行われます。 開発者がコアを操作する場合、プッシュ通知は必要ありません。単に docker-compose ファイルを起動するだけで、リソースが保存されます。

プッシュ通知と統合する必要がある場合は、docker-compose.yaml および docker-compose-push.yaml が起動されます。

docker-compose.yaml と docker-compose-push.yaml はフォルダー内にあるため、単一の仮想ネットワークが自動的に作成されます。

コンポーネントの説明。 これは、コンポーネントのコレクションを担当する、より高度なファイルです。 ここで注目すべき点は何ですか? ここではバランサーコンポーネントを紹介します。

これは、nginx と Docker ソケットをリッスンするアプリケーションを実行する既製の Docker イメージです。 動的。コンテナーがオンまたはオフになると、nginx 構成が再生成されます。 コンポーネントの処理を第 XNUMX レベル ドメイン名ごとに分散します。

開発環境には、.dev ドメイン - api.informer.dev を使用します。 .dev ドメインを持つアプリケーションは、開発者のローカル マシンで使用できます。

さらに、設定は各プロジェクトに転送され、すべてのプロジェクトが同時に起動されます。

グラフィック的には、クライアントはブラウザ、またはバランサーにリクエストを送信するためのツールであることがわかります。

ドメイン名バランサは、どのコンテナに接続するかを決定します。

管理者に JS を提供する nginx を使用することもできます。 これは、API を提供する nginx か、画像アップロードの形式で nginx に提供される静的ファイルです。

この図は、コンテナーが仮想ネットワークによって接続され、プロキシの背後に隠されていることを示しています。

開発者のマシンではIPを知ってコンテナにアクセスできますが、原則としてこれを使用しません。 実際には直接アクセスする必要はありません。

アプリケーションを Docker 化するにはどの例を参照すればよいでしょうか? 私の考えでは、良い例は MySQL の公式 Docker イメージです。

それはかなり挑戦的です。 多くのバージョンがあります。 ただし、その機能により、さらなる開発の過程で発生する可能性のある多くのニーズに対応できます。 時間をかけてすべてがどのように相互作用するのかを理解すれば、自己実装に問題はないと思います。

通常、Hub.docker.com には github.com へのリンクが含まれており、そこには生データが含まれており、そこから直接イメージを構築できます。

さらに、このリポジトリには docker-endpoint.sh スクリプトがあり、これは初期初期化とアプリケーション起動のその後の処理を担当します。

この例では、環境変数を使用して構成する機能もあります。 単一のコンテナーを実行するとき、または docker-compose を通じて環境変数を定義することによって、MySQL などの root に docker の空のパスワードを設定する必要があると言えます。

ランダムなパスワードを作成するオプションがあります。 ユーザーが必要で、ユーザーのパスワードを設定し、データベースを作成する必要があると言います。

私たちのプロジェクトでは、初期化を担当する Dockerfile をわずかに統合しました。 そこで、アプリケーションが使用するユーザー権限の単なる拡張となるように、ニーズに合わせて修正しました。 これにより、後でアプリケーション コンソールからデータベースを簡単に作成できるようになりました。 Ruby アプリケーションには、データベースを作成、変更、削除するためのコマンドがあります。

これは、github.com での MySQL の特定のバージョンがどのように見えるかを示す例です。 Dockerfile を開いて、そこでインストールがどのように行われているかを確認できます。

docker-endpoint.sh は、エントリ ポイントを担当するスクリプトです。 最初の初期化中には、いくつかの準備手順が必要ですが、これらのアクションはすべて初期化スクリプト内で実行されます。

では、第 XNUMX 部に進みましょう。

ソースコードを保存するために、gitlab に切り替えました。 これは、視覚的なインターフェイスを備えた非常に強力なシステムです。

Gitlab のコンポーネントの XNUMX つは Gitlab CI です。 これにより、後でコード配信システムを編成したり、自動テストを実行したりするために使用される一連のコマンドを記述することができます。

Gitlab CI 2 のトーク https://goo.gl/uohKjI - Ruby Russia クラブからのレポート - 非常に詳細なので、おそらく興味があるでしょう。

次に、Gitlab CI をアクティブ化するために必要なものを見ていきます。 Gitlab CI を開始するには、.gitlab-ci.yml ファイルをプロジェクトのルートに配置するだけです。

ここでは、テスト、デプロイなどの一連の状態を実行したいことを説明します。

docker-compose を直接呼び出すスクリプトを実行してアプリケーションを構築します。 これは単なるバックエンドの例です。

次に、データベースを変更してテストを実行するために移行を実行する必要があるとします。

スクリプトが正しく実行され、エラー コードが返されない場合、システムは展開の第 XNUMX 段階に進みます。

現在、展開ステージはステージング用に実装されています。 私たちはダウンタイムゼロの再起動を計画しませんでした。

全ての容器を強制的に消火し、試験の第一段階で回収した全ての容器を再度引き上げます。

現在の環境変数に対して、開発者によって作成されたデータベース移行を実行しています。

これは master ブランチにのみ適用されるという注意事項があります。

変更時は他の分岐は実行されません。

ロールアウトをブランチごとに整理することができます。

これをさらに整理するには、Gitlab Runner をインストールする必要があります。

このユーティリティは Golang で書かれています。 Golang の世界では一般的であるように、これは単一のファイルであり、依存関係を必要としません。

起動時に、Gitlab Runner を登録します。

Gitlab Web インターフェイスでキーを取得します。

次に、コマンド ラインで初期化コマンドを呼び出します。

Gitlab Runner を対話的にセットアップする (シェル、Docker、VirtualBox、SSH)

Gitlab Runner のコードは、.gitlab-ci.yml 設定に応じて、コミットごとに実行されます。

Web インターフェイスの Gitlab で視覚的にどのように見えるか。 GItlab CI に接続すると、現時点でのビルドの状態を示すフラグが表示されます。

コミットが 4 分前に行われ、すべてのテストに合格し、問題が発生しなかったことがわかります。

ビルドを詳しく見てみましょう。 ここでは、XNUMX つの州がすでに通過していることがわかります。 ステージング上のテスト ステータスとデプロイメント ステータス。

特定のビルドをクリックすると、.gitlab-ci.yml に従ってプロセスで実行されたコマンドのコンソール出力が表示されます。

弊社の製品の歴史はこんな感じです。 試みが成功したことがわかります。 テストが送信されても​​、次のステップには進まず、ステージング コードは更新されません。

Docker を実装したときにステージングでどのようなタスクを解決しましたか? 私たちのシステムはコンポーネントで構成されており、システム全体ではなく、リポジトリ内で更新されたコンポーネントの一部のみを再起動する必要がありました。

これを行うには、すべてを別々のフォルダーに分割する必要がありました。

これを実行した後、Docker-compose がパパごとに独自のネットワーク スペースを作成し、近隣のコンポーネントが表示されないという問題が発生しました。

これを回避するために、Docker でネットワークを手動で作成しました。 このプロジェクトではそのようなネットワークを使用することが Docker-compose で書かれています。

したがって、このメッシュで始まるすべてのコンポーネントは、システムの他の部分のコンポーネントを参照します。

次の問題は、ステージングを複数のプロジェクトに分割することです。

これらすべてを美しく、本番環境にできるだけ近づけるためには、Web のあらゆる場所で使用されているポート 80 または 443 を使用するのが良いでしょう。

どうやって解決したのでしょうか？ すべての主要プロジェクトに XNUMX 人の Gitlab Runner を割り当てました。

Gitlab では、複数の分散 Gitlab Runner を実行できます。これにより、すべてのタスクが無秩序に順番に実行されます。

家を持たないように、プロジェクトのグループを XNUMX つの Gitlab Runner に限定しました。Gitlab Runner はボリュームに問題なく対応できます。

nginx-proxy を別の起動スクリプトに移動し、そのスクリプトにすべてのプロジェクトのグリッドを追加しました。

私たちのプロジェクトには XNUMX つのグリッドがあり、バランサーにはプロジェクト名ごとに複数のグリッドがあります。 さらにドメイン名によってプロキシすることもできます。

リクエストはポート 80 のドメインを介して受信され、このドメインにサービスを提供するコンテナー グループに解決されます。

他にどのような問題がありましたか? これは、すべてのコンテナがデフォルトで root として実行されるものです。 これは、システムのルート ホストとは異なるルートです。

ただし、コンテナに入るとルートになり、このコンテナ内に作成するファイルはルート権限を取得します。

開発者がコンテナに入り、そこでファイルを生成するいくつかのコマンドを実行してからコンテナを離れた場合、開発者の作業ディレクトリにはアクセス権のないファイルが存在します。

どうすれば解決できますか? コンテナ内に存在するユーザーを追加できます。

ユーザーを追加したときにどのような問題が発生しましたか?

ユーザーを作成するとき、同じグループ ID (UID) とユーザー ID (GID) がないことがよくあります。

コンテナー内でこの問題を解決するには、ID 1000 のユーザーを使用します。

私たちの場合、これはほぼすべての開発者が Ubuntu OS を使用しているという事実と一致しました。 Ubuntu では、最初のユーザーの ID は 1000 です。

計画はありますか?

Docker のドキュメントを読んでください。 プロジェクトは活発に開発されており、ドキュメントは変更されています。 XNUMX ～ XNUMX か月前に受け取ったデータは、すでに徐々に古くなりつつあります。

私たちが解決した問題の一部は、標準的な手段ですでに解決されている可能性があります。

したがって、私はさらに進んで、オーケストレーションに直接進みたいと考えています。

一例として、すぐに使える Docker Swarm と呼ばれる Docker の組み込みメカニズムがあります。 Docker Swarm テクノロジーに基づいて実稼働環境で何かを実行したいと考えています。

コンテナーを生成すると、ログの操作が不便になります。 これでログが分離されました。 それらはコンテナ全体に散らばっています。 タスクの XNUMX つは、Web インターフェイスを通じてログに簡単にアクセスできるようにすることです。

出所： habr.com