DockerとCoreOSを使用してDigitalOceanでReviewNinjaをセルフホストする方法

投稿日: 2019-11-08 2022-04-20
タグ: Configuration Management, CoreOS, Docker, MongoDB, Node.js

序章

コードレビューは、現代のソフトウェア開発プロセスの不可分の一部になっています。分散バージョン管理システムの出現により、特にGitHubの誕生以来、プルリクエスト-レビュー-マージモデルがソフトウェア開発コミュニティの間で普及しました。ただし、GitHubに組み込まれているプルリクエストレビューシステムには、まだ多くの要望があります。その結果、プロセスを改善するためにGitHubと統合する多くのサードパーティコードレビューツールが存在します。 ReviewNinjaはそのようなツールの1つです。

ReviewNinja は、バニラGitHubプルリクエストレビューエクスペリエンスに加えて、いくつかの機能を追加します。「忍者スター」を付けることでプルリクエストを明示的に承認できるので、:shipit:、LGTM、またはその他の一般的な規則のようなコメントは不要です。また、プルリクエストが少なくとも2人のチームメンバーによってサインオフされていない場合、または誰かがプルリクエストに!fixのようなコメントを追加した場合に、マージをブロックするポリシーを設定できます。

ReviewNinjaは、SAPによって開発され、オープンソース化されています。ホストバージョンがありますが、独自のサーバーにデプロイして、プライベートGitHubリポジトリに使用できます。

このガイドでは、DockerとCoreOSを使用して、ReviewNinjaインスタンスをDigitalOceanにデプロイします。本番のReviewNinjaインスタンスにはいくつかの可動部分があるため、docker-machineを使用してリモートDockerホストを作成および制御し、docker-composeを使用してスタックを記述、構築、およびデプロイします。 DockerホストにはCoreOSを使用します。これは、クラウド展開用に調整された最小限のLinuxディストリビューションです。 CoreOSの新規インストールでは、systemdとDockerデーモンのみが実行されているため、アプリケーションで使用できるリソースが増えています。

前提条件

このチュートリアルを完了するには、次のものが必要です。

Docker、docker-machine、およびdocker-composeがローカルマシンにインストールされているため、デプロイするアプリケーションイメージをビルドできます。 Dockerの公式インストールドキュメントに従って、これらのツールを構成できます。 docker-machineとdocker-composeはどちらも、OSXとWindowsのDockerアプリで自動的にインストールされます。または、次のリンクを使用して手動でインストールできます。
Gitがローカルマシンにインストールされているため、ReviewNinjaリポジトリのクローンを作成してコンテナを作成できます。この前提条件を満たす必要がある場合は、公式のGitインストールドキュメントに従ってください。
読み取りアクセスと書き込みアクセスの両方を備えたDigitalOceanアクセストークン。これは、アプリケーションとAPI ページ。ホストを作成するにはdocker-machineで使用する必要があるため、このトークンをコピーします。
このチュートリアルでdocker-machineを使用して構成する1GBのCoreOSドロップレット。
GitHubアカウント。

ステップ1—CoreOSベースのDockerホストの作成とアクティブ化

展開のためのインフラストラクチャをセットアップしましょう。 docker-machineツールを使用すると、リモートマシンをDockerホストとしてプロビジョニングし、ローカルマシンからそれらを制御できます。 DigitalOceanを含む多くの人気のあるクラウドプロバイダーにドライバーを提供します。 docker-machineを使用して、Dockerホスト用のCoreOSドロップレットを作成します。

端末に切り替え、DigitalOceanアクセストークンを使用して次のコマンドを発行します。

docker-machine create --driver=digitalocean \
--digitalocean-access-token=DIGITAL_OCEAN_ACCESS_TOKEN \
--digitalocean-image=coreos-stable \
--digitalocean-region=nyc3 \
--digitalocean-size=1GB \
--digitalocean-ssh-user=core \
reviewninja

docker-machineに、coreos-stableイメージと1GBのメモリを使用して、NYC3データセンターにreviewninjaというドロップレットを作成するように指示しています。 CoreOSインストールのデフォルトユーザーはcoreであるため、--ssh-user=coreを指定していることに注意してください。

このコマンドを実行すると、次の出力が表示されます。

OutputRunning pre-create checks...
Creating machine...
(reviewninja) Creating SSH key...
(reviewninja) Creating Digital Ocean droplet...
(reviewninja) Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with coreOS...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

この新しい液滴がdocker-machineによって認識されるかどうかを見てみましょう。次のコマンドを実行します。

docker-machine ls

次の出力が表示されます。これは、Dockerホストreviewminjaがdigitaloceanドライバーを使用してリモートIPアドレスで実行されていることを示しています。

OutputNAME          ACTIVE   DRIVER         STATE     URL                          SWARM   DOCKER    ERRORS
reviewninja            digitalocean   Running   tcp://your_ip_address:2376            v1.10.3

Dockerホストを作成すると、出力の最後の行に次に何をすべきかが示されました。と言いました：

OutputTo see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env reviewninja

それでは、そのコマンドを実行してみましょう。

docker-machine env reviewninja

次のメッセージが表示されます。

Outputexport DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://your_server_ip:2376"
export DOCKER_CERT_PATH="/home/kevin/.docker/machine/machines/reviewninja"
export DOCKER_MACHINE_NAME="reviewninja"
# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

では、ここで何が起こっているのでしょうか。 Dockerアーキテクチャーは、クライアントサーバーモデルを使用します。 Dockerクライアントは、UnixソケットまたはTCPを介して通信できます。通常、Dockerクライアントは、Unixソケットを介してローカルにインストールされたDockerエンジンと通信します。ただし、TCPを介してDockerホストと通信するようにDockerクライアントに指示するために設定できる環境変数があります。表示される出力は、まさにそれを実行する環境変数を設定するための一連のシェルコマンドです。

最後の部分は言う：

Output# Run this command to configure your shell:
# eval $(docker-machine env reviewninja)

そのコマンドを実行するときは、後続のdockerコマンドに使用される環境変数を設定するこれらのコマンドを実行するようにシェルに指示します。

したがって、先に進んで、シェルでそのコマンドを実行します。

eval $(docker-machine env reviewninja)

ここで、docker infoを実行すると、ローカルのDockerデーモンではなく、リモートのDockerデーモンに関する情報が表示されます。

docker info

そのコマンドからの出力は次のようになります。

OutputContainers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.10.3
 [...]
Labels:
 provider=digitalocean

注：dockerコマンドの実行中に、次のエラーが発生する場合があります。

Error response from daemon: client is newer than server (client API version: 1.24, server API version: 1.22)

これは、使用しているDockerクライアントのバージョンがサーバーのバージョンと互換性がないことを意味します。これを修正するには、環境変数DOCKER_API_VERSIONをサーバーと同じバージョンに設定します。たとえば、サーバーでバージョン1.22が必要な場合は、次のコマンドを実行します。

export DOCKER_API_VERSION=1.22

次に、Dockerコマンドを再度実行してみてください。

これで、リモートDockerホストが構成され、Docker経由でアクセスできるようになりました。 ReviewNinjaコンテナーを作成する前に、GitHubでいくつかの作業を行う必要があります。

ステップ2—GitHubOAuthアプリケーションを登録する

ReviewNinjaはリポジトリにアクセスするためにGitHubのAPIを使用する必要があるため、ReviewNinjaのインストールをGitHubOAuthアプリケーションとして登録します。

まず、サーバーのIPアドレスを確認する必要があります。 docker-machineコマンドを使用して、次のことを実行できます。

docker-machine ip reviewninja

このコマンドが表示するIPアドレスを記録します。次に、GitHubアカウントにログインし、設定->OAuthアプリケーション->開発者アプリケーションに移動して新しいアプリケーションの登録ボタンを押します。

New GitHub OAuth application form

新しいアプリケーションのフォームが表示されたら、次の情報を入力します。

名前をreview-ninjaに設定します。
ホームページのURLをhttp://your_ip_addressに設定します。
承認コールバックURLをhttp://your_ip_address/auth/GitHub/callbackに設定します。

次に、アプリケーションの登録ボタンを押して変更を保存し、アプリケーションを作成します。新しく作成したアプリケーションが画面に表示されます。

クライアントIDとクライアントシークレットの値を安全な場所に保存します。それらをまもなくReviewNinjaアプリケーション構成に追加します。

GitHub app client id and secret

キーができたので、ReviewNinjaインスタンスの作成を始めましょう。

ステップ3—ReviewNinjaDockerコンテナを作成する

ReviewNinjaは、MongoDBに基づくストレージレイヤーに依存するNode.jsアプリケーションです。また、これを本番環境に配置するため、Node.jsアプリをプロキシサーバーの背後に配置して、アプリサーバーがインターネットに直接公開されないようにします。この目的のためにNginxを使用します。これは構成がたくさんあるので、 docker-compose を使用して、宣言的な方法で複数の関連するコンテナーをデプロイします。必要な構成を定義してから、docker-composeツールを使用して、指定されたすべてのランタイム環境でコンテナーを作成します。

まず、ReviewNinjaのソースコードを入手する必要があります。 Gitを使用して、ローカルマシンでソースコードのクローンを作成します。

git clone https://github.com/reviewninja/review.ninja.git

次に、プロジェクトのフォルダーに移動します。

cd review.ninja

このリポジトリにはDockerfileが含まれており、DockerにReviewNinjaアプリケーションイメージのビルド方法を指示します。このファイルをお気に入りのテキストエディタで開くと、次のコンテンツが表示されます。

Dockerfile

FROM node:0.12.2

COPY . /app

RUN npm install -g bower
RUN cd /app; npm install; bower install --allow-root;

WORKDIR /app

VOLUME ["/certs"]

EXPOSE 5000

CMD ["node", "/app/app.js"]

このファイルは、このアプリが使用するNode.jsのバージョンを指定します。次に、現在のフォルダーからappフォルダーにすべてのファイルをコピーし、すべてのアプリケーションの依存関係をインストールします。次に、ポート5000を公開し、アプリを起動します。 Dockerfileの詳細については、このチュートリアルを参照してください。

DockerfileはReviewNinjaアプリケーションコンテナーを記述しますが、 YAMLファイルであるdocker-compose.ymlというファイルを使用して、MongoDBやNginxプロキシなどのスタックのコンポーネントを記述できます。構成ファイルの一般的な形式。

複製したリポジトリにはdocker-compose-example.ymlというファイルがありますが、例ではニーズを満たしていないため、独自のファイルを最初から作成します。

まず、スタックのストレージを定義しましょう。ファイルdocker-compose.ymlを作成し、次の構成を入力します。

docker-compose.yml

version: "2"
services:
    db:
        image: mongo
        volumes:
            - /data:/data/db

dbサービスは、Dockerイメージの中央リポジトリであるDockerHub上の公式のMongoDBイメージを使用します。設計上、Dockerコンテナーは、停止および削除されると実行時の状態を失います。 webサービスはステートレスであるため、これで問題ありません。 dbサービスの場合、サービスを停止または再起動してもすべてのコードレビューデータが失われないように、データをディスクに保持する必要があります。これがvolumesの出番です。実行時に、Dockerデーモンは、コンテナー内のボリュームをホスト上のディレクトリーにマップするコンテナーを実行できます。

この構成では、次のように指定しました。

docker-compose.yml


        volumes:
            - /data:/data/db

これにより、ホストマシンの/dataフォルダーがコンテナー内の/data/dbにマップされます。これは、MongoDBがコンテナー内に書き込むように構成されているフォルダーです。このマッピングを作成することにより、アプリによって行われた変更は、コンテナーではなく/dataフォルダー内のホストマシンに保持されます。

次に、ReviewNinjaアプリケーションコンテナを定義します。既存の構成の後に、これをdocker-compose.ymlファイルに追加します。

docker-compose.yml

services:
    db:
    [...]

    web:
        build: .
        working_dir: /app/
        links:
            - db
        environment:
            MONGODB: mongodb://db/reviewninja
            GITHUB_CLIENT: YOUR_GITHUB_APP_ID
            GITHUB_SECRET: YOUR_GITHUB_APP_SECRET

注：webが以前にYAMLファイルとして定義したdbサービス定義と垂直に並んでいることを確認してください。

build .を使用して、docker-composeに、現在のフォルダーで探索したDockerfileからイメージを構築する必要があることを通知します。次に、dbイメージへのリンクを宣言します。したがって、webコンテナー内で、名前dbはdbコンテナーのIPアドレスに解決されます。これにより、基本的なサービス検出メカニズムが提供されます。 dbコンテナのIPアドレスを事前に知ってハードコーディングしたり、環境変数を介して渡したりする必要はありません。次に、そのリンクを使用して、mongodb://db/reviewninjaを値として使用し、MONGODB環境変数を定義します。

GITHUB_CLIENTとGITHUB_SECRETに、作成したGitHubアプリのクライアントIDとシークレットを入力します。 ReviewNinjaアプリケーションは、実行時にこれらの環境変数を読み取ります。

最後に、ポート80からNode.jsアプリが使用するポートにリクエストを転送する負荷分散サービスを定義しましょう。この構成をファイルに追加し、作成したwebサービス宣言と垂直に並べます。

docker-compose.yml

services:
    web:
    [...]
    nginx:
        image: nginx
        ports:
            - "80:80"
        volumes:
            - ./reviewninja.conf:/etc/nginx/conf.d/default
        command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
        links:
            - web

Docker Hubの公式Nginxイメージを使用し、80:80のポートマッピングを宣言します。これにより、ホストのポート80がポート80にバインドされます。容器。次に、コンテナーの外部にNginx構成ファイルを格納するボリュームマッピングを作成し、appコンテナーへのコンテナーリンクを宣言して、名前とプロキシ要求でコンテナーを見つけられるようにします。

command宣言はかなり長いので、分解してみましょう。実際には、1行で2つのコマンドを実行しています。最初のコマンドはecho -e ... > /etc/nginx/conf.d/default.confで、ReviewNinjaのNginx構成ファイルを次のように作成します。

default.conf

upstream backend {
    server web:5000;
}

server {
    listen       80;

    location / {
        proxy_pass http://backend;
    }
}

これは、backendアップストリームを定義し、web:5000を指します。値webは、linksセクションのdocker-compose.ymlファイルから取得され、ポート5000は、Node.jsサーバーがwebコンテナ。次に、Nginxサーバーがコンテナーのポート80で実行され、すべてのリクエストをアプリサーバーであるbackendにプロキシする必要があることを宣言します。

コマンドの2番目の部分であるnginx -g 'daemon off'は、コンテナー内でNginxサーバープロセスを実行するコマンドです。 Nginxはデフォルトでデーモンモードで実行され、実行中のプロセスから切り離されるため、daemon offを指定する必要があります。 Dockerは、コンテナーのエントリーポイントから切り離されたプログラムを「終了」と見なし、コンテナーを終了して、すべてのプロセスを取得します。経験則として、Dockerコンテナ内で実行されているプロセスはすべてフォアグラウンドで実行する必要があります。

先に進む前に構成を再確認したい場合に備えて、docker-compose.ymlファイル全体を次に示します。

docker-compose.yml

version: "2"
services:
    db:
        image: mongo
        volumes:
            - /data:/data/db
    web:
        build: .
        working_dir: /app/
        links:
            - db
        environment:
            MONGODB: mongodb://db/reviewninja
            GITHUB_CLIENT: YOUR_GITHUB_APP_ID
            GITHUB_SECRET: YOUR_GITHUB_APP_SECRET
    nginx:
        image: nginx
        ports:
            - "80:80"
        volumes:
            - ./reviewninja.conf:/etc/nginx/conf.d/default
        command: /bin/bash -c "echo -e 'upstream backend { server web:5000; }\nserver { listen 80; location / { proxy_pass http://backend; }}' > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"
        links:
            - web

docker-compose.ymlの構文とオプションについて詳しく知りたい場合は、docker-composeドキュメントを参照してください。

これで、このアプリケーションの構成が処理されます。 docker-compose.ymlファイルを保存します。このアプリをデプロイする時が来ました。

ステップ4—コンテナを構築してデプロイする

ReviewNinjaアプリ、データを保持するMongoDBインスタンス、およびNginxプロキシをデプロイするようにdocker-composeを構成しました。これらのコンテナーをデプロイする前に、reviewninjaDockerマシンがまだアクティブであることを確認しましょう。

docker-machine active

君は見るべきだ：

Outputreviewninja

その出力が表示されない場合は、必ず実行してください

eval $(docker-machine env reviewninja)

もう一度、環境設定が正しいことを確認してください。その後、再試行してください。

アクティブなマシンがあることを確認したら、docker-composeを使用してスタックを構築します。

docker-compose build

このプロセスは、Dockerホスト上のReviewNinjaアプリケーションのすべての依存関係をダウンロードして構成するため、非常に長い時間がかかる場合があります。次の出力が表示されます。

Outputdb uses an image, skipping
Building web
Step 1 : FROM node:0.12.2
0.12.2: Pulling from library/node
[...]
Successfully built 106a1992d538

ビルドプロセスが完了したら、イメージが正常であることを確認します。

docker images

イメージreviewninja_webが正常に作成されたことを示す次の出力が表示されます。

OutputREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
reviewninja_web     latest              106a1992d538        3 minutes ago       946.6 MB

これで、データベース、ReviewNinjaアプリケーション、およびNginxプロキシをリモートサーバー上で1つのコマンドで起動できます。

docker-compose up -d

これにより、docker-composeファイルで定義したすべてのコンテナーが表示されます。 -d（「デタッチ」用）を使用するため、すべてのコンテナーがバックグラウンドで実行され、ターミナルが制御に戻ります。

OutputCreating network "reviewninja_default" with the default driver
Pulling db (mongo:latest)...
latest: Pulling from library/mongo
[...]
Digest: sha256:d3f19457c816bb91c5639e3b1b50f67370e3b3a58b812d73446d7b966469c65e
Status: Downloaded newer image for mongo:latest
Creating reviewninja_db_1
Creating reviewninja_web_1
Creating reviewninja_nginx_1

コンテナが稼働していることを確認しましょう。次のコマンドを実行します。

docker ps

次のような出力が表示されます。

OutputCONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                         NAMES
29f8e6f770d3        nginx               "nginx -g 'daemon off"   43 seconds ago      Up 41 seconds       0.0.0.0:80->80/tcp, 443/tcp   reviewninja_nginx_1
164564dd450a        reviewninja_web     "node /app/app.js"       45 seconds ago      Up 43 seconds       5000/tcp                      reviewninja_web_1
7cd9d03eb3b9        mongo               "/entrypoint.sh mongo"   46 seconds ago      Up 44 seconds       27017/tcp                     reviewninja_db_1

また、サービスが正しく実行されていることを確認する必要があります。これを行うには、docker logsコマンドを使用してコンテナーの出力を確認します。 ReviewNinjaWebアプリケーションのログを確認してみましょう。コンテナは、前の出力のCONTAINER ID列にリストされているID、または名前のいずれかで参照できます。この場合、名前はreviewninja_web_1なので、そのコンテナのログを見てみましょう。

docker logs reviewninja_web_1

ReviewNinjaアプリからの出力が表示され、接続をリッスンしていることが示されます。

OutputIn server/app.js
checking configs
✓ configs seem ok
Host:        http://localhost:5000
GitHub:      https://GitHub.com
GitHub-Api:  https://api.GitHub.com
bootstrap certificates
bootstrap static files
apply migrations
[...]
bootstrap mongoose
[...]
bootstrap passport
[...]
bootstrap controller
[...]
bootstrap api
[...]
bootstrap webhooks
[...]
bootstrap monkey patch

✓ bootstrapped, app listening on localhost:5000

出力は、ReviewNinjaがポート5000でリッスンしていることを示しています。

Webからアクセスするには、CoreOSサーバーであるDockerホストのIPを使用する必要があります。サーバーのIPアドレスを忘れた場合は、docker-machineを使用して調べてください。

docker-machine ip reviewninja

ブラウザでhttp://your_server_ipを指定すると、忍者が出迎えてくれます。

ReviewNinja home page

これで、独自のコードでアプリケーションを使用する準備が整いました。

ステップ5—リポジトリでReviewNinjaを使用する

テストリポジトリでReviewNinjaの新しいインスタンスを試してみましょう。プルリクエストに関するフィードバックを提供し、問題に対処し、変更を受け入れ、プルリクエストをにマージします。

まず、ReviewNinjaアプリがGitHubアカウントにアクセスできるようにする必要があります。 サインインをクリックすると、GitHubにリダイレクトされてサインインします。 ReviewNinjaにGitHubアカウントへのアクセスを許可するかどうかを尋ねられます。

Grant app permissions through GitHub

アプリケーションを承認すると、ReviewNinjaのメインインターフェイスに移動します。 ReviewNinjaで使用するプライベートリポジトリがある場合は、プライベートリポジトリを有効にするリンクをクリックできます。

Enabling access to private repositories

次に、GitHubにリダイレクトされ、ReviewNinjaアプリの承認を修正して、プライベートリポジトリへのアクセスを含めます。

Authorizing private repositories

ReviewNinjaに必要なアクセス権を付与したら、リポジトリを追加して、プルリクエストワークフローにReviewNinjaを使用できるようにします。 ReviewNinjaを初めて使用する場合は、サンプルのReviewNinja-Welcomeリポジトリを追加する機会があります。

Adding a sample repository

そのサンプルリポジトリを作成して、いくつかの基本的なReviewNinja機能をウォークスルーできるようにします。これにより、アカウントの下のGithubにリポジトリが作成され、ReviewNinjaに追加されます。

サンプルリポジトリには、ReviewNinjaのコードレビューフローの機能の一部を概説することになっているReadMe.mdファイルが含まれています。 ReviewNinja-Welcomeリポジトリには、ReadMe.mdファイルの更新されたコピーがあるブランチyour_github_username-patch-1からのプルリクエストが既に開かれています。ブランチの名前は、ユーザー名によって異なります。

Pull Requests View

そのブランチをクリックすると、差分を参照してコメントを追加できるメインのコードレビューインターフェイスが表示されます。また、プルリクエストのステータスと未解決の問題の概要を示すプルリクエストステータスボックスも表示されます。

Pull Request status box

プルリクエストのマージボタンは、プルリクエストのステータスが「保留中」であるため、現在黄色になっています。ギアボタンをクリックして微調整できる状態に応じてステータスが変化します。デフォルトでは、ボタンが緑色に変わるには、少なくとも1つの忍者スターが必要です。

後で実際に動作することを確認しますが、とりあえず、コメントを追加しましょう。次のようなコード行をクリックします

+ convenience we also have a dropdown menu to add these comments

Add a line comment

ここで少し衒学者になって、dropdownという単語をdrop-downに変更することを提案しましょう。次の図に示すように、画面の右側にあるコメントボックスを使用してコメントを追加し、コメントに!fixを追加して、これをブロックの問題としてフラグを立てます。

Flag a line

フラグが立てられたコメントは、プルリクエストの作成者がReviewNinjaでマージを許可する前に対処する必要がある、プルリクエストの「問題」と見なされます。

ページを更新すると、プルリクエストのマージボタンの上に新しい問題が表示されます。

Our problem

その問題を修正しましょう。ローカルマシンで、Gitを使用してリポジトリのクローンを作成します。

git clone [email protected]:your_github_username/ReviewNinja-Welcome.git
cd ReviewNinja-Welcome

次に、作業が必要なブランチを確認します。

git checkout your_github_username-patch-1

お気に入りのテキストエディタでReadMe.mdを開き、行をdropdownではなくdrop-downに変更します。

label ReadMe.md
To add a flag simply leave a comment with your desired flag. For
convenience we also have a drop-down menu to add these comments
automatically.

ファイルをエディターに保存してから、変更を追加してコミットします。

git add ReadMe.md
git commit -m "Address code review feedback"

次に、変更をGithubへのブランチにプッシュします。

git push origin your_github_username-patch-1

次に、ブラウザのReviewNinjaインターフェイスを更新します。コードが更新されていることがわかります。この行をもう一度クリックすると、次の図に示すように、!fixedまたは!resolvedで既存のコメントに返信できます。

Mark a problem as resolved

最後に、プルリクエストに満足したので、正式なサインオフとして忍者スターを与えましょう。 忍者スターの追加ボタンをクリックします。

ninja star

次に、ブラウザを更新して、プルリクエストのステータスが「成功」に更新され、プルリクエストのマージボタンが緑色になっていることを確認します。

Ready for merge

歯車ボタンをクリックすると、プルリクエストの成功条件をカスタマイズできます。

Customize

先に進み、「プルリクエストのマージ」をクリックします。ページがリロードされると（手動で更新する必要がある場合があります）、プルリクエストのステータスが「マージ済み」に変更されていることがわかります。

Merged

覚えておくべき1つのこと：ReviewNinjaプルリクエストは GitHubプルリクエストであり、その逆も同様です。 ReviewNinjaで行われたコメントは、GitHubプルリクエストページに自動的に反映され、その逆も同様です。 ReviewNinjaを介してマージされたプルリクエストは、GitHubにも反映されます。

GitHub pull requests are synced

この双方向の同期は、コードレビューのためにReviewNinjaに徐々に移行したいチームにとって非常に便利です。

結論

このチュートリアルでは、Docker、docker-machine、およびdocker-composeを使用して、多層WebアプリケーションであるReviewNinjaをデプロイしました。既存のアプリからDockerイメージを作成する方法と、ローカル端末の快適さからインフラストラクチャ全体を定義してデプロイする方法を学びました。

また、ReviewNinjaのいくつかの強力な機能と、それらの機能を使用してGitHubプルリクエストプロセスにワークフローコントロールを追加する方法についても学びました。

ハッピーコードレビュー！

getdocs

13036