開発チーム用のテストサーバー

こんにちは、Habr！ この記事では、開発チームにテストサーバーを展開した経験を共有したいと思います。 要するに、問題の本質-開発チームとphpのいくつかのプロジェクトがあります。 私たちは少なく、プロジェクトは本質的に1つでしたが、1つのテストサーバーを使用して、タスクを顧客に見せるために、開発者は一定時間サーバーを「列に並べ」ました。 時間内に「ウィンドウ」がなかった場合は、待つ必要がありました。 時間が経つにつれて、チームとタスクの複雑さがそれぞれ大きくなり、検証時間とテストサーバーの混雑が増加し、リードタイムとボーナスに悪影響を及ぼしました。 したがって、解決策を探す必要がありましたが、それは未解決です。

入門

何だった：

1. 1つのテストサーバー
2. Gitlabと別のサーバー上のredmine
3. 問題を整理したい

すべてのサーバーはローカルネットワークにあり、テストサーバーには外部からアクセスできません。



必要なもの：

1. 複数のプロジェクト/ブランチを同時にテストする機能
2. 開発者は、サーバーにアクセスしてセットアップし、他のユーザーから何かを壊すことはできません。
3. すべてが可能な限り便利で、できればgitlab（CI / CD）から1つのボタンで行う必要があります。

ソリューションオプション

1. 1つのサーバー、多くのホスト

最も簡単なオプション。 同じテストサーバーを使用します。開発者のみが各ブランチ/プロジェクトのホストを作成し、nginx / apache2構成に追加する必要があります。



長所：

1. すぐに誰もが理解する
2. 自動化できる

短所：

1. 要件の条項2が満たされていません-開発者はデータベースの更新を開始し、状況によってはすべてを入れることができます（こんにちはAndrew！）
2. 多数の構成ファイルによるかなり複雑な自動化

2.サーバー上の各開発者に！

各サーバーを割り当て、開発者自身が経済を担当します。



長所：

1. 開発者はプロジェクト用にサーバーを完全にカスタマイズできます

短所：

1. 要件の条項2が満たされていない
2. 高価なリソースは、テストではなく、開発の進行中に単にアイドル状態になることがあります
3. サーバーが異なるため、自動化はポイント1よりもさらに複雑です

3.コンテナ化-ドッカー、kubernetes

この技術は私たちの生活にますます浸透しています。 自宅では、長い間プロジェクトにdockerを使用しています。

Dockerは、オペレーティングシステムレベルの仮想化環境でのアプリケーションの展開と管理を自動化するためのソフトウェアです。 カーネルでcgroupsをサポートする任意のLinuxシステムに移植できるコンテナに、すべての環境と依存関係を含むアプリケーションを「パック」できます。また、コンテナ管理環境も提供します。

長所：

1. 1つのサーバーが使用されます
2. すべての要件が満たされています。

短所：

1. 画像やコンテナは、多くのスペースを占有する場合があります。スペースを解放するには、すでに古くなっているクラウンをきれいにする必要があります。

Dockerの実装

gitlab、AutoDevOpsを使用している場合、kubernetesの設定が非常に頻繁に目に留まりました。 さらに、さまざまなミートアップのひげを生やした男たちは、kubernetesでの作業がいかにクールかを語っています。 そのため、クラスターを施設に展開することを決定し、サーバーが要求され（そして、テスト用のサーバーに触れることはできません。そこでテストされています）、サーバーが起動しました！



私はkubernetes 0の経験があるため、これらすべてのクラスターがどのように機能するかを理解しようとして、マニュアルに従ってすべてが行われました。 しばらくして、私はなんとかクラスターを上げることができましたが、その後、証明書、キー、そして実際にデプロイの難しさに問題がありました。 同僚に作業方法を教えるために、よりシンプルなソリューションが必要でした（たとえば、同じ休暇をSkypeに座ってセットアップの手伝いをしたくない）。 したがって、kubernetesは放置されました。 Docker自体は残り、コンテナルーティングのソリューションを見つける必要がありました。 それらは異なるポートで取得できるため、同じnginxを内部リダイレクトに使用できます。 これは、リバースプロキシサーバーと呼ばれます。

リバースプロキシサーバーは、外部ネットワークから内部ネットワークに論理的に配置された1つ以上のサーバーにクライアント要求を中継するプロキシサーバーの一種です。 同時に、要求されたリソースがプロキシサーバーに直接配置されているかのようにクライアントに見えます。

リバースプロキシ

車輪を再発明しないために、私は既成のソリューションを探し始めました。 そしてそれが発見されました-これはtraefikです。



Træfikは、マイクロサービスの展開を簡素化する最新のHTTPリバースプロキシおよびロードバランサーです。 Træfikは、既存のインフラストラクチャコンポーネント（Docker、Swarmモード、Kubernetes、Marathon、Consul、Etcd、Rancher、Amazon ECSなど）と統合され、自動的かつ動的に構成されます。 Dockerを使用するには、ソケットを指定するだけで十分です。Træfik自体がすべてのコンテナとそれらへのルーティングを検索します（詳細については、「Dockerでのアプリケーションのパッキング」を参照）。





ここで、ポート80、443、8080（プロキシのWebフェイス）をリッスンし、ドッカーソケット、構成ファイル、および証明書フォルダーをマウントする必要があることをプロキシに通知します。 テストサイトの命名の便宜上、ローカルドメインゾーン* .testを作成することにしました。 そのサイトにアクセスすると、ユーザーはテストサーバーにアクセスします。 したがって、traefikフォルダー内の証明書は自己署名されていますが、Let's Encryptをサポートしています。



証明書の生成

 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout domain.key -out domain.crt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

開始する前に、Dockerでプロキシネットワークを作成する必要があります（独自の名前を付けることができます）。

 docker network create proxy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、traefikをphpサイトのコンテナに接続するためのネットワークになります。 したがって、パラメータexternal：trueで指定することにより、サービスのネットワークパラメータとファイル全体のネットワークで指定します。





ここではすべてが非常に簡単です。httpおよびhttpsトラフィックのエントリポイントを指定します。証明書がローカルの場合は、insecureSkipVerify = trueを設定することを忘れないでください。 entryPoints.https.tlsセクションでは、証明書を指定することはできません。traefikは証明書を置き換えます。



サービスを開始できます

 docker-compose up -d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

site.testアドレスにアクセスすると、このドメインはどのコンテナにも関連付けられていないため、404エラーが発生します。

ドッカーにアプリケーションをパックします

次に、アプリケーションでコンテナを構成する必要があります。



1.ネットワークでプロキシネットワークを指定する

2. traefik設定でラベルを追加します



以下は、いずれかのアプリケーションの構成です





アプリサービスのネットワークセクションで、プロキシとデフォルトを指定する必要があります。これは、構成からわかるように、2つのネットワークで使用できることを意味します。ポートを外部に転送せず、すべてネットワーク内に移動します。



次に、ラベルを構成します

  - traefik.enabled=true # traefik    - traefik.frontend.rule=Host:TEST_DOMAIN,crm.TEST_DOMAIN,bonus.TEST_DOMAIN #    traefik     - traefik.docker.network=proxy #   - traefik.port=443 #,     ssl   80   http - traefik.protocol=https #  #  phpmyadmin   http 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般的なネットワークセクションで、external：trueを指定します



TEST_DOMAIN定数は、site.testなどのドメインに置き換える必要があります



アプリケーションを起動する

 docker-compose up -d
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、site.test、crm.site.test、bonus.site.testのドメインに移動すると、作業サイトが表示されます。 また、ドメインpma.site.testには、データベースを操作するためのphpmyadminがあります。

GitLabを構成する

タスクハンドラーを作成し、このために実行します

 gitlab-runner register
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

gitlabのURL、トークン、およびタスクの実行に使用するトークン（エグゼキューター）を指定します。 テストとgitlabは異なるサーバー上にあるため、ssh executorを選択します。 sshを介して接続するには、サーバーアドレスとユーザー名/パスワードを指定する必要があります。



ランナーは、1つ以上のプロジェクトに添付できます。 私の作業ロジックはどこでも同じなので、共有ランナーが作成されました（すべてのプロジェクトに共通）。

最後に、CI構成ファイルを作成します





この構成では、ビルドとクリアの2つの段階について説明します。 ビルドフェーズには2つのオプションがあります-build_developとbuild_prod







Gitlabは、理解可能なプロセスフロー図を作成します。 私の例では、すべてのプロセスが手動で開始されます（手動パラメーターの場合）。 これは、テストサイトを展開した後、開発者がコンテナ全体を再構築せずに編集内容をコンテナにプルできるようにするためです。 別の理由は、ドメイン名-サイト$ CI_PIPELINE_ID.testです。CI_PIPELINE_IDは、アセンブリを開始したプロセスの番号です。 つまり、検証のためにドメインsite123.testを使用してサイトを送信しました。ホットエディットを行うために、開発者はすぐに変更をコンテナに流し込みます。



sshエグゼキューターの小さな機能。 サーバーに接続すると、フォームのフォルダーが作成されます。

 /home//builds/_runner/0/_/_
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、行が追加されました

 cd ../ && cp -r $CI_PROJECT_NAME $CI_PIPELINE_ID && cd $CI_PIPELINE_ID
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その中で、上のフォルダーに移動し、プロジェクトをプロセス番号のあるフォルダーにコピーします。 したがって、1つのプロジェクトの複数のブランチを展開できます。 ただし、ハンドラーの設定では、[現在のプロジェクトにロック]をオンにする必要があります。そのため、ハンドラーは同時に複数のブランチを展開しようとしません。



クリアステージはコンテナを停止し、フォルダを削除します。ルート権限が必要な場合があるため、エコーパスワードを使用します。 sudo -S rm、ここでpasswordはパスワードです。

ガベージコレクション

時々、スペースを占有しないように未使用のコンテナを削除する必要があります。これは、このようなコンテンツを含むスクリプトがクラウンにハングアップするためです。

 #!/bin/bash #   : docker ps --filter status=dead --filter status=exited -aq | xargs -r docker rm -v #   : yes | docker container prune #    : yes | docker image prune #    : yes | docker volume prune
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1日に1回実行します。

おわりに

このソリューションは、テストと新機能のリリースを大幅に最適化するのに役立ちました。 質問に答える準備ができて、建設的な批判は受け入れられます。

ボーナス

毎回Dockerfileから画像を収集しないように、ローカルのdockerレジストリに保存できます。





このオプションは認証を使用しません。これは安全な方法ではありません（!!!）が、重要ではないイメージの保存には適しています。



表示するようにgitlabを構成できます

  gitlab_rails['registry_enabled'] = true gitlab_rails['registry_host'] = "registry.test" gitlab_rails['registry_port'] = "5000"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、画像のリストがgitlabに表示されます