TOC

So hosten Sie ReviewNinja auf DigitalOcean mithilfe von Docker und CoreOS

Einführung

Die Codeüberprüfung ist zu einem untrennbaren Bestandteil des modernen Softwareentwicklungsprozesses geworden. Mit dem Aufkommen verteilter Versionskontrollsysteme und insbesondere seit der Geburt von GitHub wurde das Pull-Request-Review-Merge-Modell in der Softwareentwickler-Community populär. Das in GitHub integrierte Überprüfungssystem für Pull-Requests lässt jedoch zu wünschen übrig. Infolgedessen gibt es viele Codeüberprüfungstools von Drittanbietern, die in GitHub integriert sind, um den Prozess zu verbessern. ReviewNinja ist ein solches Tool.

ReviewNinja fügt zusätzlich zur Überprüfung der Vanilla GitHub-Pull-Anfrage einige Funktionen hinzu. Es gibt uns die Möglichkeit, eine Pull-Anfrage explizit abzumelden, indem wir "Ninja-Sterne" vergeben, sodass Kommentare wie:shipit:,LGTM oder andere beliebte Konventionen nicht mehr erforderlich sind. Sie können Richtlinien festlegen, um das Zusammenführen zu blockieren, wenn die Pull-Anforderung nicht von mindestens 2 Teammitgliedern abgemeldet wurde oder wenn jemand Kommentare wie!fix zur Pull-Anforderung hinzufügt.

ReviewNinja wird von SAP entwickelt und als Open-Source-Lösung angeboten. Es hat einhosted version, aber wir können es auf unseren eigenen Servern bereitstellen und für unsere privaten GitHub-Repositorys verwenden.

In diesem Handbuch stellen Sie eine ReviewNinja-Instanz auf DigitalOcean mitDocker undCoreOS bereit. Eine ReviewNinja-Produktionsinstanz enthält einige bewegliche Teile. Daher verwenden wirdocker-machine, um einen Remote-Docker-Host zu erstellen und zu steuern, unddocker-compose, um unseren Stack zu beschreiben, zu erstellen und bereitzustellen. Für den Docker-Host verwenden wir CoreOS, eine minimale Linux-Distribution, die auf Cloud-Bereitstellungen zugeschnitten ist. Bei einer Neuinstallation von CoreOS werden nursystemd und der Docker-Daemon ausgeführt, sodass mehr Ressourcen für unsere Anwendungen verfügbar sind.

Voraussetzungen

Um dieses Tutorial abzuschließen, benötigen Sie:

  • Docker,docker-machine unddocker-compose sind auf Ihrem lokalen Computer installiert, sodass Sie das von uns bereitgestellte Anwendungsimage erstellen können. Sie könnenthe official installation documentation für Docker folgen, um diese Tools zu konfigurieren. Sowohldocker-machine als auchdocker-compose werden automatisch mit der Docker-App unter OSX und Windows installiert, oder Sie können sie manuell über die folgenden Links installieren:

  • Git ist auf Ihrem lokalen Computer installiert, sodass Sie das ReviewNinja-Repository klonen können, um den Container zu erstellen. Befolgen Sie dieofficial Git installation documentation, wenn Sie diese Voraussetzung erfüllen müssen.

  • Ein DigitalOcean-Zugriffstoken mit Lese- und Schreibzugriff, das Sie auf der SeiteApplications & APIgenerieren können. Kopieren Sie dieses Token, da Sie es mitdocker-machine verwenden müssen, um Hosts zu erstellen.

  • Ein 1 GB CoreOS-Droplet, das wir in diesem Lernprogramm mitdocker-machine konfigurieren.

  • AGitHub Konto.

[[Schritt-1 - Erstellen und Aktivieren eines Coreos-basierten Docker-Hosts]] == Schritt 1 - Erstellen und Aktivieren eines CoreOS-basierten Docker-Hosts

Richten wir die Infrastruktur für unsere Bereitstellung ein. Mit dem Tooldocker-machine können Sie Remotecomputer als Docker-Hosts bereitstellen und von Ihrem lokalen Computer aus steuern. Es bietet Treiber für viele beliebte Cloud-Anbieter, einschließlich DigitalOcean. Wir werdendocker-machine verwenden, um ein CoreOS-Droplet für unseren Docker-Host zu erstellen.

Wechseln Sie zu Ihrem Terminal und geben Sie mit Ihrem DigitalOcean-Zugriffstoken den folgenden Befehl ein: 

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

Wir weisendocker-machine an, ein Droplet mit dem Namenreviewninja im Rechenzentrum vonNYC3zu erstellen, indem das Bild voncoreos-stablemit1GB Speicher verwendet wird. Beachten Sie, dass wir--ssh-user=core angeben, da der Standardbenutzer in einer CoreOS-Installationcore ist.

Wenn Sie diesen Befehl ausführen, wird die folgende Ausgabe angezeigt: 

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

Mal sehen, ob dieses neue Tröpfchen vondocker-machine erkannt wird. Führen Sie den Befehl aus: 

docker-machine ls

Die folgende Ausgabe zeigt an, dass der Docker-Hostreviewminja mit dem Treiberdigitaloceanauf einer Remote-IP-Adresse ausgeführt wird: 

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

Beim Erstellen des Docker-Hosts wurde in der letzten Zeile der Ausgabe angegeben, was als Nächstes zu tun ist. Es sagte: 

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

Führen Sie den folgenden Befehl aus: 

docker-machine env reviewninja

Sie sehen diese Nachricht: 

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)

Was passiert hier? Die Docker-Architektur verwendet ein Client-Server-Modell. Ein Docker-Client kann über einen Unix-Socket oder über TCP kommunizieren. Normalerweise kommuniziert unser Docker-Client über einen Unix-Socket mit der lokal installierten Docker-Engine. Es gibt jedoch Umgebungsvariablen, mit denen Sie festlegen können, dass der Docker-Client über TCP mit einem Docker-Host kommunizieren soll. Die angezeigte Ausgabe besteht aus einer Reihe von Shell-Befehlen zum Einrichten von Umgebungsvariablen, die genau das tun.

Der letzte Teil sagt: 

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

Wenn Sie diesen Befehl ausführen, weisen Sie die Shell an, diese Befehle auszuführen, mit denen die Umgebungsvariablen eingerichtet werden, die für nachfolgendedocker-Befehle verwendet werden.

Führen Sie den folgenden Befehl in Ihrer Shell aus: 

eval $(docker-machine env reviewninja)

Wenn Sie nundocker info ausführen, werden Informationen zum Remote-Docker-Daemon angezeigt, nicht zum lokalen Docker-Daemon: 

docker info

Die Ausgabe dieses Befehls sieht folgendermaßen aus: 

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

[.Hinweis]##

Note: Beim Ausführen derdocker-Befehle wird möglicherweise der folgende Fehler angezeigt: 

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

Dies bedeutet, dass die von Ihnen verwendete Docker-Client-Version nicht mit der Serverversion kompatibel ist. Um dies zu beheben, setzen Sie die UmgebungsvariableDOCKER_API_VERSION auf dieselbe Version wie der Server. Wenn der Server beispielsweise Version 1.22 möchte, führen Sie den folgenden Befehl aus: 

export DOCKER_API_VERSION=1.22

Versuchen Sie dann erneut, die Docker-Befehle auszuführen.

Unser entfernter Docker-Host ist jetzt konfiguriert und über Docker erreichbar. Bevor wir einen ReviewNinja-Container erstellen können, müssen wir mit GitHub arbeiten.

[[Schritt-2 - Registrieren einer Github-Oauth-Anwendung]] == Schritt 2 - Registrieren einer GitHub-OAuth-Anwendung

ReviewNinja muss die GitHub-API verwenden, um auf Ihre Repositorys zuzugreifen. Daher registrieren wir unsere ReviewNinja-Installation als GitHub-OAuth-Anwendung.

Zuerst müssen wir die IP-Adresse unseres Servers herausfinden. Wir können den Befehldocker-machine verwenden, um dies zu tun: 

docker-machine ip reviewninja

Notieren Sie die IP-Adresse, die dieser Befehl anzeigt. Melden Sie sich dann bei Ihrem GitHub-Konto an, gehen Sie zuSettings → OAuth applications → Developer applications und drücken Sie die TasteRegister a new application.

New GitHub OAuth application form

Geben Sie die folgenden Informationen ein, sobald Ihnen das Formular für die neue Bewerbung angezeigt wird:

  1. Setzen SieName aufreview-ninja.

  2. Setzen SieHomepage URL aufhttp://your_ip_address.

  3. Setzen SieAuthorization Callback URL aufhttp://your_ip_address/auth/GitHub/callback.

Drücken Sie dann die TasteRegister application, um die Änderungen zu speichern und die Anwendung zu erstellen. Dadurch wird die neu erstellte Anwendung auf dem Bildschirm angezeigt.

Speichern Sie die Werte fürClient ID undClient Secret an einem sicheren Ort. Sie werden sie in Kürze zur ReviewNinja-Anwendungskonfiguration hinzufügen.

GitHub app client id and secret

Jetzt, da Sie Ihre Schlüssel haben, können Sie unsere ReviewNinja-Instanz erstellen.

[[Schritt 3 - Erstellen des Reviewninja-Docker-Containers]] == Schritt 3 - Erstellen des ReviewNinja Docker-Containers

ReviewNinja ist eine Node.js-Anwendung, die auf einer von MongoDB unterstützten Speicherebene basiert. Da dies in einer Produktionsumgebung implementiert wird, wird die Node.js-App hinter einem Proxyserver platziert, sodass der App-Server nicht direkt dem Internet ausgesetzt ist. Zu diesem Zweck verwenden wir Nginx. Das ist viel zu konfigurieren, daher verwenden wirdocker-compose, um mehrere verwandte Container deklarativ bereitzustellen. Wir definieren die gewünschte Konfiguration und verwenden dann das Tooldocker-compose, um Container mit allen angegebenen Laufzeitumgebungen zu erstellen.

Zuerst müssen wir den ReviewNinja-Quellcode abrufen. Klonen Sie den Quellcode auf Ihrem lokalen Computer mit Git: 

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

Navigieren Sie dann in den Projektordner: 

cd review.ninja

Dieses Repository enthält einDockerfile, das Docker mitteilt, wie das ReviewNinja-Anwendungsimage erstellt wird. Wenn Sie diese Datei in Ihrem bevorzugten Texteditor öffnen, wird folgender Inhalt angezeigt:

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"]

Diese Datei gibt die Version von Node.js an, die von dieser App verwendet wird. Anschließend werden alle Dateien aus dem aktuellen Ordner in einenapp-Ordner kopiert und alle Anwendungsabhängigkeiten installiert. Anschließend wird Port5000 verfügbar gemacht und die App gestartet. Eine detailliertere Einführung in Dockerfiles finden Sie unterthis tutorial.

Die Docker-Datei beschreibt den ReviewNinja-Anwendungscontainer, aber wir können die Komponenten unseres Stacks, einschließlich MongoDB und des Nginx-Proxys, mithilfe einer Datei namensdocker-compose.yml beschreiben, bei der es sich um eineYAML-Datei handelt, ein beliebtes Format für Konfigurationsdateien.

Das von Ihnen geklonte Repository verfügt über eine Datei mit dem Namendocker-compose-example.yml. Wir werden jedoch unsere eigene Datei von Grund auf neu schreiben, da das Beispiel nicht unseren Anforderungen entspricht.

Definieren wir zunächst den Speicher für unseren Stapel. Erstellen Sie die Dateidocker-compose.yml und geben Sie die folgende Konfiguration ein:

docker-compose.yml

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

Der Dienstdbverwendet die offiziellenMongoDB image in Docker Hub, einem zentralen Repository für Docker-Images. Docker-Container verlieren standardmäßig ihren Laufzeitstatus, wenn sie angehalten und entfernt werden. Das ist in Ordnung für denweb-Dienst, da er zustandslos ist. Für unserendb-Dienst müssen wir die Daten auf einer Festplatte speichern, damit wir nicht alle Codeüberprüfungsdaten verlieren, wenn wir den Dienst beenden oder neu starten. Hier kommtvolumes ins Spiel. Zur Laufzeit kann der Docker-Daemon einen Container ausführen, der Volumes im Container Verzeichnissen auf dem Host zuordnet.

In unserer Konfiguration haben wir Folgendes angegeben:

docker-compose.yml

        volumes:
            - /data:/data/db

Dadurch wird der Ordner/datades Hostcomputers/data/db im Container zugeordnet. Dies ist zufällig der Ordner, in den MongoDB so konfiguriert ist, dass er in den Container schreibt. Durch das Erstellen dieser Zuordnung bleiben die von der App vorgenommenen Änderungen auf dem Hostcomputer im Ordner/datatatt im Container erhalten.

Als nächstes definieren wir den ReviewNinja-Anwendungscontainer. Fügen Sie dies nach der vorhandenen Konfiguration in die Dateidocker-compose.yml ein:

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

[.note] #Note: Stellen Sie sicher, dassweb vertikal mit der Service-Definition vondbübereinstimmt, die Sie zuvor als YAML-Dateien definiert haben.

Wir verwendenbuild ., dasdocker-compose mitteilt, dass das Bild aus denDockerfile erstellt werden soll, die wir gerade im aktuellen Ordner untersucht haben. Wir deklarieren dann einen Link zumdb-Image, sodass der Namedb innerhalb desweb-Containers in die IP-Adresse desdb-Containers aufgelöst wird. Dies bietet einen rudimentären Diensterkennungsmechanismus. Wir müssen die IP-Adresse desdb-Containers nicht im Voraus kennen und fest codieren oder über eine Umgebungsvariable übergeben. Dann verwenden wir diesen Link, um die UmgebungsvariableMONGODB zu definieren, wobeimongodb://db/reviewninja als Wert verwendet wird.

Füllen SieGITHUB_CLIENT undGITHUB_SECRET mit der Client-ID und dem Geheimnis für die von Ihnen erstellte GitHub-App aus. Die ReviewNinja-Anwendung liest diese Umgebungsvariablen zur Laufzeit.

Definieren wir abschließend den Lastausgleichsdienst, der Anforderungen von Port80an den Port weiterleitet, den unsere Node.js-App verwendet. Fügen Sie diese Konfiguration der Datei hinzu und richten Sie sie vertikal mit der soeben erstellten Service-Deklaration vonwebaus:

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

Wir verwenden dieofficial Nginx image von Docker Hub und deklarieren eine Portzuordnung von80:80, die Port80 auf dem Host an Port80 im Container bindet. Anschließend erstellen wir eine Datenträgerzuordnung, in der die Nginx-Konfigurationsdatei außerhalb des Containers gespeichert wird, und deklarieren eine Containerverknüpfung zum Containerapp, damit wir sie anhand von Namen und Proxy-Anforderungen suchen können.

Die Deklaration voncommandist ziemlich lang. Lassen Sie uns sie also aufschlüsseln. Tatsächlich werden zwei Befehle in einer einzigen Zeile ausgeführt. Der erste Befehl istecho -e ... > /etc/nginx/conf.d/default.conf, mit dem die Nginx-Konfigurationsdatei für ReviewNinja erstellt wird. Diese sieht folgendermaßen aus:

default.conf

upstream backend {
    server web:5000;
}

server {
    listen       80;

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

Dies definiert einbackend stromaufwärts und zeigt es aufweb:5000. Der Wertweb stammt aus der Dateidocker-compose.yml im Abschnittlinks, und Port5000 ist der Port, den der Node.js-Server im Containerweb verwendet. Dann erklären wir, dass unser Nginx-Server auf Port80 im Container ausgeführt wird und alle Anforderungen anbackend, unseren App-Server, weiterleiten soll.

Der zweite Teil des Befehls,nginx -g 'daemon off', ist der Befehl, der den Nginx-Serverprozess im Container ausführt. Wir müssendaemon off angeben, da Nginx standardmäßig im Daemon-Modus ausgeführt wird und sich vom laufenden Prozess löst. Docker betrachtet jedes Programm, das vom Container-Einstiegspunkt getrennt wurde, als "beendet" und beendet den Container, wobei alle Prozesse erneut ausgeführt werden. Als Faustregel gilt, dass jeder Prozess, der im Docker-Container ausgeführt wird, im Vordergrund ausgeführt werden muss.

Hier ist die gesamtedocker-compose.yml-Datei für den Fall, dass Sie Ihre Konfiguration überprüfen möchten, bevor Sie fortfahren:

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

Schauen Sie sich diedocker-compose documentation an, wenn Sie mehr über die Syntax und die Optionen fürdocker-compose.yml erfahren möchten.

Das kümmert sich um unsere Konfiguration für diese Anwendung. Speichern Sie die Dateidocker-compose.yml. Es ist Zeit, diese App bereitzustellen.

[[Schritt 4 - Erstellen und Bereitstellen der Container] == Schritt 4 - Erstellen und Bereitstellen der Container

Wir habendocker-compose für die Bereitstellung unserer ReviewNinja-App, einer MongoDB-Instanz zum Speichern der Daten und eines Nginx-Proxys konfiguriert. Bevor wir diese Container bereitstellen, überprüfen wir, ob der Docker-Computer vonreviewninjanoch aktiv ist: 

docker-machine active

Das solltest du sehen: 

Outputreviewninja

Wenn Sie diese Ausgabe nicht sehen, müssen Sie sie ausführen 

eval $(docker-machine env reviewninja)

erneut, um sicherzustellen, dass Ihre Umgebungseinstellungen korrekt sind. Dann versuche es nochmal.

Wenn Sie sicher sind, dass Sie eine aktive Maschine haben, verwenden Siedocker-compose, um Ihren Stapel aufzubauen: 

docker-compose build

Dieser Vorgang kann sehr lange dauern, da alle Abhängigkeiten für die ReviewNinja-Anwendung auf dem Docker-Host heruntergeladen und konfiguriert werden. Sie sehen die folgende Ausgabe: 

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

Überprüfen Sie nach Abschluss des Erstellungsprozesses, ob Sie ein erfolgreiches Image haben: 

docker images

Die folgende Ausgabe zeigt an, dass das Bildreviewninja_web erfolgreich erstellt wurde: 

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

Jetzt können wir unsere Datenbank, unsere ReviewNinja-Anwendung und unseren Nginx-Proxy auf unserem Remote-Server mit einem einzigen Befehl starten: 

docker-compose up -d

Dadurch werden alle Container angezeigt, die wir in der Dateidocker-composedefiniert haben. Wir verwenden-d (für "Trennen"), damit alle Container im Hintergrund ausgeführt werden und wir unser Terminal wieder unter Kontrolle haben. 

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

Vergewissern Sie sich, dass die Container in Betrieb sind. Führen Sie den folgenden Befehl aus: 

docker ps

Die Ausgabe sieht folgendermaßen aus: 

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

Wir möchten auch sicherstellen, dass die Dienste ordnungsgemäß ausgeführt werden. Dazu verwenden wir den Befehldocker logs, um die Ausgabe eines Containers anzuzeigen. Sehen wir uns die Protokolle für die ReviewNinja-Webanwendung an. Wir können den Container entweder anhand seiner ID, die in der SpalteCONTAINER ID in der vorhergehenden Ausgabe aufgeführt ist, oder anhand seines Namens referenzieren. In unserem Fall lautet der Namereviewninja_web_1. Sehen wir uns also die Protokolle für diesen Container an: 

docker logs reviewninja_web_1

Die Ausgabe der ReviewNinja-App zeigt an, dass sie auf Verbindungen wartet: 

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

Die Ausgabe zeigt an, dass ReviewNinja Port5000 überwacht.

Für den Zugriff über das Web müssen wir die IP-Adresse unseres Docker-Hosts verwenden, bei dem es sich um unseren CoreOS-Server handelt. Wenn Sie die IP-Adresse Ihres Servers vergessen haben, verwenden Siedocker-machine, um dies herauszufinden. 

docker-machine ip reviewninja

Zeigen Sie mit Ihrem Browser aufhttp://your_server_ip und Sie werden vom Ninja begrüßt:

ReviewNinja home page

Schließlich können wir die Anwendung mit unserem eigenen Code verwenden.

[[Schritt-5 -—- Verwenden von Reviewninja-mit-einem-Repository]] == Schritt 5 - Verwenden von ReviewNinja mit einem Repository

Probieren Sie unsere neue Instanz von ReviewNinja in einem Test-Repository aus. Wir geben Feedback zu einer Pull-Anfrage, beheben das Problem, akzeptieren die Änderungen und führen die Pull-Anfrage in zusammen.

Zuerst müssen wir der Review Ninja-App erlauben, auf Ihr GitHub-Konto zuzugreifen. Klicken Sie aufSign In und Sie werden zu GitHub weitergeleitet, um sich anzumelden. Sie werden gefragt, ob ReviewNinja auf Ihr GitHub-Konto zugreifen darf:

Grant app permissions through GitHub

Sobald Sie die Anwendung autorisiert haben, werden Sie zur Hauptoberfläche von ReviewNinja weitergeleitet. Wenn Sie private Repositorys haben, die ReviewNinja verwenden soll, können Sie auf den LinkEnable private reposklicken:

Enabling access to private repositories

Sie werden dann zu GitHub weitergeleitet, um Ihre Autorisierung der ReviewNinja-App zu ändern und den Zugriff auf Ihre privaten Repos einzuschließen:

Authorizing private repositories

Nachdem Sie ReviewNinja den gewünschten Zugriff gewährt haben, können Sie ein Repository hinzufügen, damit Sie ReviewNinja für Ihren Pull-Request-Workflow verwenden können. Wenn Sie ReviewNinja zum ersten Mal verwenden, haben Sie die Möglichkeit, das Repository eines BeispielsReviewNinja-Welcomehinzuzufügen:

Adding a sample repository

Erstellen Sie dieses Beispielrepository, damit wir einige grundlegende ReviewNinja-Funktionen durchgehen können. Dadurch wird das Repository auf Github unter Ihrem Konto erstellt und zu ReviewNinja hinzugefügt.

Das Beispiel-Repository enthält eineReadMe.md-Datei, die einige der Funktionen des Code-Überprüfungsflusses von ReviewNinja beschreiben soll. Im Repository vonReviewNinja-Welcome ist bereits eine Pull-Anforderung von einem Zweigyour_github_username-patch-1 geöffnet, der die aktualisierte Kopie der DateiReadMe.md enthält. Der Name der Filiale hängt von Ihrem Benutzernamen ab.

Pull Requests View

Klicken Sie auf diesen Zweig und Sie sehen die Hauptoberfläche für die Codeüberprüfung, in der Sie die Unterschiede durchsuchen und Kommentare hinzufügen können. Außerdem wird das Feld Pull Request Status angezeigt, in dem der Status der Pull-Anfrage und ausstehende Probleme aufgeführt sind.

Pull Request status box

Die SchaltflächeMerge pull request ist derzeit gelb, da der Status der Pull-Anforderung "ausstehend" ist. Der Status ändert sich je nach Zustand, den Sie durch Klicken auf den Gangschaltknopf ändern können. Standardmäßig ist mindestens 1 Ninja-Stern erforderlich, damit die Schaltfläche grün wird.

Wir werden das später in Aktion sehen, aber jetzt wollen wir einen Zeilenkommentar hinzufügen. Klicken Sie auf die Codezeile mit der Aufschrift 

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

Add a line comment

Seien wir hier etwas pedantisch und schlagen vor, das Wortdropdown indrop-down zu ändern. Fügen Sie über das Kommentarfeld auf der rechten Seite des Bildschirms einen Kommentar hinzu und kennzeichnen Sie dies als Blockierungsproblem, indem Sie Ihrem Kommentar!fix hinzufügen, wie in der folgenden Abbildung dargestellt:

Flag a line

Ein gekennzeichneter Kommentar wird als "Problem" in der Pull-Anfrage betrachtet, das der Autor der Pull-Anfrage beantworten muss, bevor ReviewNinja die Zusammenführung zulässt.

Aktualisieren Sie die Seite und Sie sehen nun das neue Problem, das über der SchaltflächeMerge pull request aufgeführt ist:

Our problem

Beheben wir das Problem. Verwenden Sie auf Ihrem lokalen Computer Git, um das Repository zu klonen: 

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

Dann schauen Sie sich den Zweig an, der Arbeit braucht: 

git checkout your_github_username-patch-1

Öffnen SieReadMe.md in Ihrem bevorzugten Texteditor und ändern Sie die Zeile indrop-down anstelle vondropdown: 

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.

Speichern Sie die Datei in Ihrem Editor, fügen Sie Ihre Änderungen hinzu und übernehmen Sie sie: 

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

Übertragen Sie als Nächstes die Änderungen an der Verzweigung nach Github: 

git push origin your_github_username-patch-1

Aktualisieren Sie jetzt die ReviewNinja-Oberfläche in Ihrem Browser. Sie werden sehen, dass der Code aktualisiert wird. Wenn Sie erneut auf die Zeile klicken, können Sie auf den vorhandenen Kommentar mit!fixed oder!resolved antworten, wie in der folgenden Abbildung dargestellt:

Mark a problem as resolved

Jetzt, da wir mit der Pull-Anfrage zufrieden sind, geben wir ihr einen Ninja-Stern als formelles Zeichen. Klicken Sie auf die SchaltflächeAdd ninja star:

ninja star

Aktualisieren Sie dann den Browser und stellen Sie fest, dass der Pull-Anforderungsstatus auf "erfolgreich" aktualisiert wird und die SchaltflächeMerge pull request grün ist:

Ready for merge

Sie können die Erfolgsbedingung einer Pull-Anfrage anpassen, indem Sie auf die Schaltfläche mit dem Zahnrad klicken:

Customize

Fahren Sie fort und klicken Sie auf "Pull-Anforderung zusammenführen". Nach dem erneuten Laden der Seite (möglicherweise müssen Sie sie manuell aktualisieren) wird der Status der Abrufanforderung in "Zusammengeführt" geändert.

Merged

Eines ist zu beachten: ReviewNinja-Pull-Anfragenare GitHub-Pull-Anfragen und umgekehrt. Kommentare zu ReviewNinja werden automatisch auf der GitHub-Pull-Anforderungsseite angezeigt und umgekehrt. Pull-Anfragen, die über ReviewNinja zusammengeführt wurden, werden auch auf GitHub wiedergegeben:

GitHub pull requests are synced

Diese bidirektionale Synchronisierung ist besonders praktisch für Teams, die zur Codeüberprüfung schrittweise auf ReviewNinja migrieren möchten.

Fazit

In diesem Lernprogramm haben Sie Docker,docker-machine unddocker-compose verwendet, um ReviewNinja, eine mehrschichtige Webanwendung, bereitzustellen. Sie haben gelernt, wie Sie ein Docker-Image aus einer vorhandenen App erstellen und Ihre gesamte Infrastruktur bequem von Ihrem lokalen Terminal aus definieren und bereitstellen.

Sie haben auch einige leistungsstarke Funktionen von ReviewNinja kennengelernt und erfahren, wie Sie mit diesen Funktionen dem GitHub-Pull-Request-Prozess Workflow-Steuerelemente hinzufügen.

Viel Spaß beim Code-Reviewen!

Related