One place for hosting & domains

      Einrichten und Konfigurieren einer Certificate Authority (CA) unter Debian 10


      Einführung

      Eine Zertifizierungsstelle (Certificate Authority, CA) ist eine Stelle, die für die Ausstellung digitaler Zertifikate zur Überprüfung von Identitäten im Internet verantwortlich ist. Obwohl öffentliche CAs eine beliebte Wahl für die Überprüfung der Identität von Websites und anderen Diensten sind, die der allgemeinen Öffentlichkeit zur Verfügung gestellt werden, werden private CAs normalerweise für geschlossene Gruppen und private Dienste verwendet.

      Die Erstellung einer privaten Zertifizierungsstelle ermöglicht es Ihnen, Programme zu konfigurieren, zu testen und auszuführen, die verschlüsselte Verbindungen zwischen einem Client und einem Server erfordern. Mit einer privaten CA können Sie Zertifikate für Benutzer, Server oder einzelne Programme und Dienste innerhalb Ihrer Infrastruktur ausstellen.

      Einige Beispiele für Programme unter Linux, die ihre eigene private CA verwenden, sind OpenVPN und Puppet. Sie können Ihren Webserver auch so konfigurieren, dass er Zertifikate verwendet, die von einer privaten CA ausgestellt wurden, um Entwicklungs- und Staging-Umgebungen an Produktionsserver anzupassen, die TLS zur Verschlüsselung von Verbindungen verwenden.

      In diesem Leitfaden lernen wir, wie eine private Zertifizierungsstelle auf einem Debian 10-Server eingerichtet wird und wie mit einer neuen CA ein Testzertifikat erzeugt und signiert wird. Außerdem erfahren Sie, wie Sie das öffentliche Zertifikat des CA-Servers in den Zertifikatsspeicher Ihres Betriebssystems importieren, damit Sie die Vertrauenskette zwischen der CA und entfernten Servern oder Benutzern überprüfen können. Schließlich werden Sie lernen, wie Sie Zertifikate widerrufen und eine Zertifikatswiderrufsliste verteilen, um sicherzustellen, dass nur autorisierte Benutzer und Systeme Dienste nutzen können, die auf Ihrer CA beruhen.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie Zugriff auf einen Debian 10-Server, der Ihren OpenVPN-Dienst hosten kann. Sie müssen einen non-root user mit sudo-Rechten konfigurieren, bevor Sie diesen Leitfaden starten können. Sie können unserem Leitfaden zur Ersteinrichtung eines Debian-10-Servers folgen, um einen Benutzer mit entsprechenden Berechtigungen einzurichten. Das verknüpfte Tutorial richtet auch eine Firewall ein, und in diesem Leitfaden wird davon ausgegangen, dass sie vorhanden ist.

      Dieser Server wird in diesem Tutorial als CA-Server bezeichnet.

      Stellen Sie sicher, dass der CA-Server ein eigenständiges System ist. Er wird nur zum Importieren, Signieren und Widerrufen von Zertifikatanforderungen verwendet. Auf ihm sollten keine anderen Dienste ausgeführt werden, und idealerweise ist er offline oder wird vollständig heruntergefahren, wenn Sie nicht aktiv mit Ihrer CA arbeiten.

      Anmerkung: Der letzte Abschnitt dieses Tutorials ist optional, wenn Sie über das Signieren und Widerrufen von Zertifikaten lernen möchten. Wenn Sie sich entscheiden, diese Übungsschritte durchzuführen, benötigen Sie einen zweiten Debian-10-Server oder Sie können Ihren eigenen lokalen Linux-Computer verwenden, auf dem Debian oder Ubuntu oder davon abgeleitete Distributionen ausgeführt werden.

      Schritt 1 — Installieren von Easy-RSA

      Die erste Aufgabe in diesem Tutorial besteht darin, den Skriptsatz easy-rsa auf Ihrem CA-Server zu installieren. easy-rsa ist ein Verwaltungswerkzeug für Zertifizierungsstellen, mit dem Sie einen privaten Schlüssel und ein öffentliches Stammzertifikat erzeugen, die Sie dann zum Signieren von Anfragen von Clients und Servern verwenden, die auf Ihre CA angewiesen sind.

      Melden Sie sich bei Ihrem CA-Server als der non-root sudo user an, den Sie während der anfänglichen Einrichtungsschritte erstellt haben, und führen Sie Folgendes aus:

      • sudo apt update
      • sudo apt install easy-rsa

      Sie werden aufgefordert, das Paket herunterzuladen und zu installieren. Drücken Sie y, um zu bestätigen, dass Sie das Paket installieren möchten.

      An dieser Stelle haben Sie alles Nötige eingerichtet und sind bereit, Easy-RSA zu verwenden. Im nächsten Schritt werden Sie eine Public-Key-Infrastruktur erstellen und dann mit dem Erstellen Ihrer Zertifizierungsstelle beginnen.

      Schritt 2 – Vorbereiten eines Public-Key-Infrastrukturverzeichnisses

      Nachdem Sie nun easy-rsa installiert haben, ist es an der Zeit, eine grundlegende Public-Key-Infrastruktur (PKI) auf dem CA-Server zu erstellen. Stellen Sie sicher, dass Sie immer noch als non-root user angemeldet sind und erstellen Sie ein easy-rsa-Verzeichnis. Stellen Sie sicher, dass Sie sudo nicht verwenden, um einen der folgenden Befehle auszuführen, da Ihr normaler Benutzer die CA ohne erhöhte Berechtigungen verwalten und mit ihr interagieren sollte.

      Dadurch wird ein neues Verzeichnis namens easy-rsa in Ihrem Home-Ordner erstellt. Wir werden dieses Verzeichnis verwenden, um symbolische Links zu erstellen, die auf die easy-rsa-Paketdateien verweisen, die wir im vorigen Schritt installiert haben. Diese Dateien befinden sich im Ordner /usr/share/easy-rsa auf dem CA-Server.

      Erstellen Sie die Symlinks mit dem Befehl ln:

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Anmerkung: Während andere Leitfäden Sie möglicherweise anweisen, die Dateien des easy-rsa-Pakets in Ihr PKI-Verzeichnis zu kopieren, verfolgt dieses Tutorial einen Symlink-Ansatz. Infolgedessen werden alle Aktualisierungen des easy-rsa-Pakets automatisch in den Skripten Ihrer PKI wiedergegeben.

      Um den Zugriff auf Ihr neues PKI-Verzeichnis einzuschränken, stellen Sie sicher, dass nur der Eigentümer mit dem Befehl chmod darauf zugreifen kann:

      • chmod 700 /home/sammy/easy-rsa

      Anschließend initialisieren Sie die PKI innerhalb des easy-rsa-Verzeichnisses:

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      Nachdem Sie diesen Abschnitt abgeschlossen haben, haben Sie ein Verzeichnis, das alle Dateien enthält, die zur Erstellung einer Zertifizierungsstelle benötigt werden. Im nächsten Abschnitt werden Sie den privaten Schlüssel und das öffentliche Zertifikat für Ihre CA erstellen.

      Schritt 3 – Erstellen einer Zertifizierungsstelle

      Bevor Sie den privaten Schlüssel und das Zertifikat Ihrer CA erstellen können, müssen Sie eine Datei namens vars erstellen und mit einigen Standardwerten füllen. Zuerst werden Sie cd in das Verzeichnis easy-rsa, dann werden Sie die Datei vars mit nano oder Ihrem bevorzugten Texteditor erstellen und bearbeiten:

      Sobald die Datei geöffnet ist, fügen Sie die folgenden Zeilen ein und bearbeiten Sie jeden hervorgehobenen Wert so, dass er Ihre eigenen Organisationsinformationen widerspiegelt. Wichtig dabei ist, dass Sie keinen der Werte leer lassen:

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "admin@example.com" set_var EASYRSA_REQ_OU "Community"

      Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun. Sie sind nun bereit, Ihre CA zu erstellen.

      Um das öffentliche und private Stammschlüsselpaar für Ihre Zertifizierungsstelle zu erstellen, führen Sie den Befehl ./easy-rsa erneut aus, diesmal mit der Option build-ca:

      In der Ausgabe sehen Sie einige Zeilen über die OpenSSL-Version und werden dazu aufgefordert, eine Passphrase für Ihr Schlüsselpaar einzugeben. Achten Sie darauf, eine starke Passphrase zu wählen, und notieren Sie sie an einem sicheren Ort. Sie müssen die Passphrase jedes Mal eingeben, wenn Sie mit Ihrer CA interagieren müssen, zum Beispiel zum Signieren oder Widerrufen eines Zertifikats.

      Sie werden auch gebeten, den Common Name (CN) für Ihre CA zu bestätigen. Der CN ist der Name, der verwendet wird, um im Kontext der Zertifizierungsstelle auf diesen Computer zu verweisen. Sie können eine beliebige Zeichenfolge für den Common Name der CA eingeben, aber drücken Sie der Einfachheit halber ENTER, um den Standardnamen zu akzeptieren.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Anmerkung: Wenn Sie nicht bei jeder Interaktion mit Ihrer CA zur Eingabe eines Passworts aufgefordert werden möchten, können Sie den Befehl build-ca mit der Option nopass wie folgt ausführen:

      • ./easyrsa build-ca nopass

      Sie haben nun zwei wichtige Dateien – ~/easy-rsa/pki/ca.crt und ~/easy-rsa/pki/private/ca.key – die die öffentlichen und privaten Komponenten einer Zertifizierungsstelle bilden.

      • ca.crt ist die öffentliche Zertifikatsdatei der CA. Benutzer, Server und Clients verwenden dieses Zertifikat, um zu überprüfen, ob sie Teil desselben vertrauenswürdigen Webs sind. Jeder Benutzer und Server, der Ihre CA verwendet, muss eine Kopie dieser Datei haben. Alle Parteien verlassen sich auf das öffentliche Zertifikat, um sicherzustellen, dass sich nicht jemand als System ausgibt und einen Man-in-the-middle-Angriff durchführt.

      • ca.key ist der private Schlüssel, den die CA zum Signieren von Zertifikaten für Server und Clients verwendet. Wenn ein Angreifer Zugriff auf Ihre CA und damit auf Ihre ca.key-Datei erhält, müssen Sie Ihre CA vernichten. Deshalb sollte sich Ihre Datei ca.key nur auf Ihrem CA-Computer befinden und Ihr CA-Computer im Idealfall als zusätzliche Sicherheitsmaßnahme offline bleiben, wenn keine Zertifikatanforderungen signiert werden.

      Damit ist Ihre CA vorhanden und bereit, zum Signieren von Zertifikatanforderungen und zum Widerrufen von Zertifikaten verwendet zu werden.

      Schritt 4 – Verteilen des öffentlichen Zertifikats Ihrer Zertifizierungsstelle

      Nun ist Ihre CA konfiguriert und bereit, als Vertrauensgrundlage für alle Systeme zu fungieren, die Sie für ihre Verwendung konfigurieren möchten. Sie können das Zertifikat der CA zu Ihren OpenVPN-Servern, Webservern, Mail-Servern usw. hinzufügen. Jeder Benutzer oder Server, der die Identität eines anderen Benutzers oder Servers in Ihrem Netzwerk überprüfen muss, sollte eine Kopie der Datei ca.crt haben, die in den Zertifikatsspeicher ihres Betriebssystems importiert ist.

      Um das öffentliche Zertifikat der CA in ein zweites Linux-System wie einen anderen Server oder einen lokalen Computer zu importieren, besorgen Sie sich zunächst eine Kopie der ca.crt-Datei von Ihrem CA-Server. Sie können den Befehl cat verwenden, um sie in einem Terminal auszugeben, und sie dann kopieren und in eine Datei auf dem zweiten Computer, der das Zertifikat importiert, einfügen. Sie können auch Tools wie scp, rsync verwenden, um die Datei zwischen Systemen zu übertragen. Wir werden in diesem Schritt jedoch Kopieren und Einfügen mit nano verwenden, da dies auf allen Systemen funktioniert.

      Führen Sie als non-root user auf dem CA-Server den folgenden Befehl aus:

      • cat ~/easy-rsa/pki/ca.crt

      Es wird eine Ausgabe in Ihrem Terminal geben, die der folgenden ähnelt:

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Kopieren Sie alles, einschließlich der Zeilen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- und der Bindestriche.

      Verwenden Sie auf Ihrem zweiten Linux-System nano oder Ihren bevorzugten Texteditor, um eine Datei namens /tmp/ca.crt zu öffnen:

      Fügen Sie den Inhalt, den Sie gerade vom CA-Server kopiert haben, in den Editor ein. Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun.

      Nachdem Sie nun eine Kopie der Datei ca.crt auf Ihrem zweiten Linux-System haben, ist es an der Zeit, das Zertifikat in den Zertifikatsspeicher des Betriebssystems zu importieren.

      Führen Sie auf Debian- und Ubuntu-basierten Systemen die folgenden Befehle aus, um das Zertifikat zu importieren:

      Debian and Ubuntu derived distributions

      • cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • update-ca-certificates

      Um das Zertifikat des CA-Servers auf einem CentOS-, Fedora- oder RedHat-basierten System zu importieren, kopieren Sie den Inhalt der Datei und fügen Sie ihn wie im vorherigen Beispiel in das System in eine Datei namens /tmp/ca.crt ein. Kopieren Sie als Nächstes das Zertifikat nach /etc/pki/ca-trust/source/anchors/ und führen Sie dann den Befehl update-ca-trust aus.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • update-ca-trust

      Nun wird Ihr zweites Linux-System auf jedes Zertifikat vertrauen, das vom CA-Server signiert wurde.

      Anmerkung: Wenn Sie Ihre CA mit Web-Servern verwenden und Firefox als Browser verwenden, müssen Sie das öffentliche Zertifikat ca.crt direkt in Firefox importieren. Firefox verwendet nicht den Zertifikatsspeicher des lokalen Betriebssystems. Einzelheiten dazu, wie Sie das Zertifikat Ihrer CA in Firefox hinzufügen können, finden Sie in diesem Support-Artikel von Mozilla über das Einrichten von Zertifizierungsstellen (CAs) in Firefox.

      Wenn Sie Ihre CA zur Integration in eine Windows-Umgebung oder in Desktop-Computer verwenden, lesen Sie bitte die Dokumentation über die Verwendung von certutil.exe zur Installation eines CA-Zertifikats.

      Wenn Sie dieses Tutorial als Voraussetzung für ein anderes Tutorial verwenden oder mit dem Signieren und Widerrufen von Zertifikaten vertraut sind, können Sie hier aufhören. Wenn Sie mehr zum Thema Signieren und Widerrufen von Zertifikaten erfahren möchten, dann wird im folgenden optionalen Abschnitt jeder Vorgang im Detail erklärt.

      (Optional) – Erstellen von Zertifikatsignieranforderungen und Widerrufen von Zertifikaten

      Die folgenden Abschnitte des Tutorials sind optional. Wenn Sie alle vorherigen Schritte abgeschlossen haben, verfügen Sie über eine vollständig konfigurierte und funktionierende Zertifizierungsstelle, die Sie als Voraussetzung für andere Tutorials verwenden können. Sie können die Datei ca.crt Ihrer CA importieren und Zertifikate in Ihrem Netzwerk überprüfen, die von Ihrer CA signiert wurde.

      Wenn Sie üben und mehr über das Signieren von Zertifikatanforderungen und das Widerrufen von Zertifikaten erfahren möchten, dann werden diese optionalen Abschnitte erklären, wie beide Prozesse funktionieren.

      (Optional) – Erstellen und Signieren einer Übungs-Zertifikatanforderung

      Nachdem Sie nun eine einsatzbereite CA haben, können Sie das Erzeugen eines privaten Schlüssels und einer Zertifikatanforderung üben, um sich mit dem Signier- und Verteilungsprozess vertraut zu machen.

      Eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) besteht aus drei Teilen: einem öffentlichen Schlüssel, dem Identifizieren von Informationen über das anfordernde System und einer Signatur der Anforderung selbst, die mit dem privaten Schlüssel der anfragenden Partei erstellt wird. Der private Schlüssel wird geheim gehalten und wird zum Verschlüsseln von Informationen verwendet, die jeder mit dem signierten öffentlichen Zertifikat dann entschlüsseln kann.

      Die folgenden Schritte werden auf Ihrem zweiten Linux-System Debian, Ubuntu oder einer Distribution, die von einem dieser Systeme abgeleitet ist, ausgeführt. Es kann sich um einen anderen Remote-Server oder einen lokalen Linux-Rechner wie einen Laptop oder einen Desktop-Rechner handeln. Da easy-rsa nicht standardmäßig auf allen Systemen verfügbar ist, verwenden wir das Tool openssl zum Erstellen eines privaten Übungsschlüssels und -zertifikats.

      openssl ist normalerweise standardmäßig auf den meisten Linux-Distributionen installiert, aber um sicherzugehen, führen Sie die folgenden Schritte auf Ihrem System aus:

      • sudo apt update
      • sudo apt install openssl

      Wenn Sie zur Installation von openssl aufgefordert werden, geben Sie y ein, um mit den Installationsschritten fortzufahren. Nun sind Sie bereit, eine Übungs-CSR mit openssl zu erstellen.

      Der erste Schritt, den Sie zum Erstellen einer CSR ausführen müssen, ist die Erzeugung eines privaten Schlüssels. Um einen privaten Schlüssel mit openssl zu erstellen, erstellen Sie ein Verzeichnis practice-csr und erzeugen Sie darin einen Schlüssel. Wir werden diese Anfrage für einen fiktiven Server namens sammy-server stellen, im Gegensatz zur Erstellung eines Zertifikats, das zur Identifizierung eines Benutzers oder einer anderen CA verwendet wird.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Da Sie nun über einen privaten Schlüssel verfügen, können Sie eine entsprechende CSR erstellen, wiederum mit dem Dienstprogramm openssl. Sie werden aufgefordert, eine Reihe von Feldern wie Land, Bundesland und Stadt auszufüllen. Wenn Sie ein Feld leer lassen möchten, können Sie einen . eingeben. Beachten Sie jedoch, dass es am besten ist, die richtigen Werte für Ihren Standort und Ihre Organisation zu verwenden, wenn es sich um eine reale CSR handelt:

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      Wenn Sie diese Werte automatisch als Teil des openssl-Aufrufs statt über die interaktive Eingabeaufforderung hinzufügen möchten, können Sie das Argument -subj an OpenSSL übergeben. Achten Sie darauf, die hervorgehobenen Werte so zu bearbeiten, dass sie mit dem Standort, der Organisation und dem Servernamen für die Übung übereinstimmen:

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      Zur Überprüfung des Inhalts einer CSR können Sie eine Anforderungsdatei mit openssl einlesen und die darin enthaltenen Felder untersuchen:

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Wenn Sie mit dem Thema Ihrer Übungs-Zertifikatanforderung zufrieden sind, kopieren Sie die Datei sammy-server.req mit scp auf Ihren CA-Server:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In diesem Schritt haben Sie eine Zertifikatsignieranforderung für einen fiktiven Server namens sammy-server erzeugt. In einem realen Szenario könnte die Anfrage z. B. von einem Staging- oder Entwicklungs-Webserver kommen, der ein TLS-Zertifikat zum Testen benötigt; oder sie könnte von einem OpenVPN-Server kommen, der ein Zertifikat anfordert, damit sich Benutzer mit einem VPN verbinden können. Im nächsten Schritt fahren wir mit dem Signieren der Zertifikatsignieranforderung unter Verwendung des privaten Schlüssels des CA-Servers fort.

      (Optional) – Signieren einer CSR

      Im vorherigen Schritt haben Sie eine Übungs-Zertifikatanforderung und einen Übungsschlüssel für einen fiktiven Server erstellt. Sie kopierten sie in das Verzeichnis /tmp auf Ihrem CA-Server und emulierten damit das Verfahren, das Sie verwenden würden, wenn Sie echte Clients oder Server hätten, die Ihnen CSR-Anfragen senden würden, die signiert werden müssen.

      Um mit dem fiktiven Szenario fortzufahren, muss der CA-Server nun das Übungszertifikat importieren und signieren. Sobald eine Zertifikatanforderung von der CA validiert und an einen Server zurückgesendet wird, können Clients, die der Zertifizierungsstelle vertrauen, auch dem neu ausgestellten Zertifikat vertrauen.

      Da wir innerhalb der PKI der CA arbeiten werden, in der das Dienstprogramm easy-rsa verfügbar ist, werden die Signierungsschritte das Dienstprogramm easy-rsa verwenden. Dies vereinfacht die Dinge im Gegensatz zur direkten Verwendung von openssl, wie wir es im vorherigen Beispiel getan haben.

      Der erste Schritt zum Signieren der fiktiven CSR besteht darin, die Zertifikatanforderung mithilfe des Skripts easy-rsa zu importieren:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Jetzt können Sie die Anfrage signieren, indem Sie das Skript easyrsa mit der Option sign-req ausführen, gefolgt vom Anfragetyp und dem Common Name, der in der CSR enthalten ist. Der Anfragetyp kann entweder Client, Server oder ca sein. Da wir mit einem Zertifikat für einen fiktiven Server üben, stellen Sie sicher, dass Sie den Anfragetyp Server verwenden:

      • ./easyrsa sign-req server sammy-server

      In der Ausgabe werden Sie zur Überprüfung aufgefordert, ob die Anfrage von einer vertrauenswürdigen Quelle stammt. Geben Sie yes ein, und drücken Sie dann zur Bestätigung ENTER:

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      Wenn Sie Ihren CA-Schlüssel verschlüsselt haben, werden Sie an dieser Stelle zur Eingabe Ihres Passworts aufgefordert.

      Nach Abschluss dieser Schritte haben Sie die CSR sammy-server.req mit dem privaten Schlüssel des CA-Servers in /home/sammy/easy-rsa/pki/private/ca.key signiert. Die resultierende Datei sammy-server.crt enthält den öffentlichen Verschlüsselungsschlüssel des Übungsservers sowie eine neue Signatur des CA-Servers. Der Sinn der Signatur besteht darin, jedem, der der CA vertraut, mitzuteilen, dass auch dem sammy-server-Zertifikat vertraut werden kann.

      Wenn es sich bei dieser Anfrage um einen echten Server wie einen Web- oder VPN-Server handelt, würde der letzte Schritt auf dem CA-Server darin bestehen, die neuen Dateien sammy-server.crt und ca.crt vom CA-Server an den Remote-Server zu verteilen, der die CSR-Anfrage gestellt hat:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      Zu diesem Zeitpunkt könnten Sie das ausgestellte Zertifikat mit beispielsweise einem Webserver, einem VPN, einem Konfigurationsmanagement-Tool, einem Datenbanksystem oder für die Client-Authentifizierung verwenden.

      (Optional) – Widerrufen eines Zertifikats

      Gelegentlich kann es erforderlich sein, ein Zertifikat zu widerrufen, um zu verhindern, dass ein Benutzer oder Server es verwendet. Vielleicht wurde ein Laptop gestohlen, ein Webserver kompromittiert, oder ein Mitarbeiter oder ein Auftragnehmer hat Ihr Unternehmen verlassen.

      Zum Widerrufen eines Zertifikats folgt der allgemeine Vorgang diesen Schritten:

      1. Widerrufen Sie das Zertifikat mit dem Befehl ./easyrsa revoke client_name.
      2. Erzeugen Sie eine neue CRL mit dem Befehl ./easyrsa gen-crl.
      3. Übertragen Sie die aktualisierte Datei crl.pem auf den oder die Server, die sich auf Ihre CA verlassen, und kopieren Sie sie auf diesen Systemen in das oder die erforderlichen Verzeichnisse für Programme, die auf sie verweisen.
      4. Starten Sie alle Dienste, die Ihre CA und die CRL-Datei verwenden, neu.

      Mit diesem Vorgang können Sie alle Zertifikate, die Sie zuvor ausgestellt haben, jederzeit widerrufen. In den folgenden Abschnitten gehen wir jeden Schritt im Detail durch, beginnend mit dem Befehl revoke.

      Widerrufen eines Zertifikats

      Um ein Zertifikat zu widerrufen, navigieren Sie zum Verzeichnis easy-rsa auf Ihrem CA-Server:

      Führen Sie als Nächstes das Skript easyrsa mit der Option revoke aus, gefolgt von dem Client-Namen, den Sie widerrufen möchten. Dem obigen Übungsbeispiel folgend lautet der Common Name des Zertifikats sammy-server:

      • ./easyrsa revoke sammy-server

      Sie werden dazu aufgefordert, das Sperren durch Eingabe von yes zu bestätigen:

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Beachten Sie den hervorgehobenen Wert in der Zeile Revoking Certificate. Dieser Wert ist die eindeutige Seriennummer des Zertifikats, das widerrufen wird. Sie benötigen diesen Wert, wenn Sie die Widerrufsliste im letzten Schritt dieses Abschnitts prüfen möchten, um zu verifizieren, dass das Zertifikat darin enthalten ist.

      Nach der Bestätigung der Aktion wird die CA das Zertifikat widerrufen. Entfernte Systeme, die sich auf die CA verlassen, haben jedoch keine Möglichkeit zur Überprüfung, ob Zertifikate widerrufen wurden. Benutzer und Server können das Zertifikat weiterhin verwenden, bis die Zertifikatswiderrufsliste (Certificate Revocation List, CRL) der CA an alle Systeme verteilt wird, die sich auf die CA verlassen.

      Im nächsten Schritt erzeugen Sie eine CRL oder aktualisieren eine bestehende crl.pem-Datei.

      Erzeugen einer Zertifikatswiderrufsliste

      Nachdem Sie ein Zertifikat widerrufen haben, ist es jetzt wichtig, die Liste der widerrufenen Zertifikate auf Ihrem CA-Server zu aktualisieren. Sobald Sie über eine aktualisierte Widerrufsliste verfügen, können Sie feststellen, welche Benutzer und Systeme in Ihrer CA über gültige Zertifikate verfügen.

      Um eine CRL zu erzeugen, führen Sie den Befehl easy-rsa mit der Option gen-crl aus, während Sie sich noch im Verzeichnis ~/easy-rsa befinden:

      Wenn Sie bei der Erstellung Ihrer Datei ca.key eine Passphrase verwendet haben, werden Sie aufgefordert, diese einzugeben. Der Befehl gen-crl erzeugt eine Datei namens crl.pem, die die aktualisierte Liste der widerrufenen Zertifikate für diese CA enthält.

      Als Nächstes müssen Sie jedes Mal, wenn Sie den Befehl gen-crl ausführen, die aktualisierte Datei crl.pem an alle Server und Clients übertragen, die auf diese CA angewiesen sind. Andernfalls können die Clients und Systeme weiterhin auf Dienste und Systeme zugreifen, die Ihre CA verwenden, da diese Dienste über den widerrufenen Status des Zertifikats informiert sein müssen.

      Übertragen einer Zertifikatswiderrufsliste

      Nachdem Sie nun eine CRL auf Ihrem CA-Server erzeugt haben, müssen Sie sie an Remote-Systeme übertragen, die sich auf Ihre CA verlassen. Um diese Datei auf Ihre Server zu übertragen, können Sie den Befehl scp verwenden.

      Anmerkung: In diesem Tutorial wird erklärt, wie eine CRL manuell erzeugt und verteilt wird. Es gibt zwar robustere und automatisierte Methoden zur Verteilung und Überprüfung von Widerrufslisten wie OCSP-Stapling, aber die Konfiguration dieser Methoden sprengt den Rahmen dieses Artikels.

      Stellen Sie sicher, dass Sie bei Ihrem CA-Server als non-root user angemeldet sind, und führen Sie die folgenden Schritte aus, wobei Sie an Stelle von your_server_ip Ihre eigene Server-IP oder Ihren eigenen DNS-Namen eingeben:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Da sich die Datei nun auf dem Remote-System befindet, besteht der letzte Schritt darin, alle Dienste mit der neuen Kopie der Widerrufsliste zu aktualisieren.

      Aktualisierung von Diensten, die eine CRL unterstützen

      Die Liste der Schritte, die Sie zur Aktualisierung von Diensten verwenden müssen, die die Datei crl.pem verwenden, geht über den Umfang dieses Tutorials hinaus. Im Allgemeinen müssen Sie die Datei crl.pem an den Speicherort kopieren, den der Dienst erwartet, und sie dann mit systemctl neu starten.

      Sobald Sie Ihre Dienste mit der neuen crl.pem-Datei aktualisiert haben, sind Ihre Dienste in der Lage, Verbindungen von Clients oder Servern abzulehnen, die ein widerrufenes Zertifikat verwenden.

      Überprüfen und Verifizieren der Inhalte einer CRL

      Wenn Sie eine CRL-Datei überprüfen möchten, z. B. um eine Liste widerrufener Zertifikate zu bestätigen, verwenden Sie den folgenden openssl-Befehl aus Ihrem easy-rsa-Verzeichnis auf Ihrem CA-Server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      Sie können diesen Befehl auch auf jedem Server oder System ausführen, auf dem das openssl-Tool mit einer Kopie der Datei crl.pem installiert ist. Wenn Sie beispielsweise die Datei crl.pem auf Ihr zweites System übertragen haben und überprüfen möchten, ob das Zertifikat sammy-server widerrufen wurde, können Sie einen openssl-Befehl wie den folgenden verwenden, wobei Sie die Seriennummer, die Sie zuvor beim Widerruf des Zertifikats notiert haben, an Stelle der hier markierten verwenden:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Beachten Sie, wie der Befehl grep verwendet wird, um die eindeutige Seriennummer zu überprüfen, die Sie im Widerrufsschritt notiert haben. Jetzt können Sie den Inhalt Ihrer Zertifikatswiderrufsliste auf jedem System überprüfen, das darauf angewiesen ist, den Zugriff auf Benutzer und Dienste einzuschränken.

      Zusammenfassung

      In diesem Tutorial haben Sie eine private Zertifizierungsstelle mit dem Easy-RSA-Paket auf einem eigenständigen Debian 10-Server erstellt. Sie haben gelernt, wie das Vertrauensmodell zwischen Parteien funktioniert, die sich auf die CA verlassen. Sie haben auch eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) für einen Übungsserver erstellt und signiert und dann gelernt, wie man ein Zertifikat widerruft. Abschließend haben Sie erfahren, wie Sie eine Zertifikatwiderrufsliste (Certificate Revocation List, CRL) für jedes System erstellen und verteilen, das auf Ihre CA angewiesen ist, um sicherzustellen, dass Benutzer oder Server, die nicht auf Dienste zugreifen sollen, daran gehindert werden.

      Jetzt können Sie Zertifikate für Benutzer ausgeben und sie mit Diensten wie OpenVPN verwenden. Sie können Ihre CA auch verwenden, um Entwicklungs- und Staging-Webserver mit Zertifikaten zu konfigurieren, um Ihre Nicht-Produktionsumgebungen zu sichern. Die Verwendung einer CA mit TLS-Zertifikaten während der Entwicklung kann dazu beitragen, sicherzustellen, dass Ihr Code und Ihre Umgebungen so gut wie möglich zu Ihrer Produktionsumgebung passen.

      Wenn Sie mehr über die Verwendung von OpenSSL erfahren möchten, bietet unser Tutorial OpenSSL-Grundlagen: Arbeiten mit SSL-Zertifikaten, privaten Schlüsseln und CSRs viele zusätzliche Informationen, die Ihnen helfen, sich mit den OpenSSL-Grundlagen vertraut zu machen.



      Source link

      Hosten einer Website mit Caddy unter Ubuntu 18.04


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Caddy ist ein auf Einfachheit und Sicherheit ausgelegter Webserver, der mit einer Reihe von Funktionen ausgestattet ist, die für das Hosting von Websites nützlich sind. Beispielsweise kann er automatisch TLS-Zertifikate von Let’s Encrypt beziehen und verwalten, um HTTPS zu aktivieren, und er bietet Unterstützung für HTTP/2. HTTPS ist ein System zur Sicherung des Datenverkehrs zwischen Ihren Benutzern und Ihrem Server und entwickelte sich schnell zu einer grundlegenden Erwartung für jede Website, die in Produktion ausgeführt wird – ohne HTTPS warnen Chrome und Firefox, dass Ihre Website „Nicht sicher“ ist, wenn Benutzer versuchen, Anmeldeinformationen einzugeben.

      Früher wurde als Methode zur Installation von Caddy empfohlen, vorgefertigte Binärdateien von der Caddy-Projekt-Website herunterzuladen. Änderungen in der Lizenzierungsweise von Caddy bedeuten jedoch, dass Sie diese vorgefertigten Binärdateien nicht mehr für kommerzielle Zwecke verwenden dürfen, es sei denn, Sie zahlen eine Lizenzgebühr, auch wenn Sie Caddy nur intern innerhalb eines Unternehmens verwenden. Glücklicherweise ist der Quellcode von Caddy immer noch vollständig Open-Source und Sie können Caddy selbst erstellen, um Lizenzprobleme zu vermeiden.

      In diesem Tutorial erstellen Sie Caddy aus dem Quellcode und verwenden ihn zum Hosten einer mit HTTPS gesicherten Website. Dazu müssen Sie ihn kompilieren, mit einer Caddyfile konfigurieren und Plugins installieren. Am Ende lernen Sie, wie Sie Ihre Installation aktualisieren, wenn eine neue Version verfügbar ist.

      Voraussetzungen

      Schritt 1 – Erstellen von Caddy

      In diesem Schritt erstellen Sie den Caddy aus dem Quellcode mit der Möglichkeit, später Plugins hinzuzufügen, ohne den Quellcode von Caddy zu ändern.

      Für die Zwecke dieses Tutorials werden Sie den Quellcode unter ~/caddy speichern. Erstellen Sie das Verzeichnis durch Ausführen des folgenden Befehls:

      Navigieren Sie dorthin:

      Speichern Sie den Quellcode zur Ausführung und Anpassung von Caddy in einer Datei namens caddy.go. Erstellen Sie diese mit dem folgenden Befehl:

      Fügen Sie die folgenden Zeilen hinzu:

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Dieser Code importiert Caddy direkt von Github (mit Git) und startet ihn von der Eingangsfunktion main. Wenn Sie die Telemetrie aktivieren möchten, entkommentieren Sie die Zeile caddymain.EnableTelemetry und setzen den Wert auf true. Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Damit caddy.go die importierten Abhängigkeiten verwenden kann, müssen Sie es als Modul initialisieren:

      Output

      go: creating new go.mod: module caddy

      An diesem Punkt sind Sie bereit, die Stock-Version von Caddy aus dem obigen Quellcode zu erstellen, indem Sie Folgendes ausführen:

      Es werden zahlreiche Ausgaben erscheinen, die detailliert aufführen, welche Bibliotheken von Go als Abhängigkeiten heruntergeladen werden, die zum Kompilieren notwendig sind. Die resultierende ausführbare Datei wird unter $GOPATH/bin gespeichert, wie in den Voraussetzungen erklärt.

      Führen Sie Caddy nach Abschluss aus:

      Sie werden eine Ausgabe ähnlich der folgenden sehen:

      Output

      Activating privacy features... done. Serving HTTP on port 2015 http://:2015 WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with `ulimit -n 8192`.

      Dies bedeutet, dass Caddy erfolgreich gestartet wurde und auf dem Port 2015 verfügbar ist. Sie können die Warnmeldung ignorieren, da diese Grenze in späteren Schritten ohne Ihr Zutun angepasst wird. Drücken Sie zum Beenden STRG + C.

      Sie haben Caddy nun erstellt und ausgeführt. Im nächsten Schritt installieren Sie Caddy als Dienst, damit er automatisch beim Booten startet, und passen dann seine Eigentums- und Berechtigungseinstellungen an, um die Sicherheit des Servers zu gewährleisten.

      Schritt 2 – Installieren von Caddy

      Nachdem Sie nun bestätigt haben, dass Sie Caddy erstellen und ausführen können, ist es an der Zeit, einen systemd-Dienst zu konfigurieren, damit Caddy automatisch beim Systemstart gestartet werden kann. Um mehr über systemd zu erfahren, besuchen Sie unser Tutorial Systemd-Grundlagen.

      Verschieben Sie zunächst die Caddy-Binärdatei nach /usr/local/bin, den Standardspeicherort für Binärdateien, die nicht vom Ubuntu-Paketmanager verwaltet werden und für den Systembetrieb nicht entscheidend sind:

      • sudo mv $GOPATH/bin/caddy /usr/local/bin/

      Übertragen Sie anschließend die Eigentümerschaft der Caddy-Binärdatei an den root user:

      • sudo chown root:root /usr/local/bin/caddy

      Dadurch wird verhindert, dass andere Konten die ausführbare Datei modifizieren. Aber selbst wenn der root user Eigentümer von Caddy ist, ist es ratsam, ihn nur mit anderen, Nicht-Root-Konten auszuführen, die auf dem System vorhanden sind. Dadurch wird sichergestellt, dass im Falle einer Kompromittierung von Caddy (oder eines anderen Programms) der Angreifer nicht in der Lage sein wird, die Binärdatei zu verändern oder Befehle als root auszuführen.

      Legen Sie anschließend die Berechtigungen der Binärdatei auf 755 fest – dies gibt root volle Lese-/Schreib-/Ausführungsberechtigungen für die Datei, während andere Benutzer nur in der Lage sind, sie zu lesen und auszuführen:

      • sudo chmod 755 /usr/local/bin/caddy

      Da der Caddy-Prozess nicht als root ausgeführt wird, verhindert Linux, dass er an die Ports 80 und 443 (die Standardports für HTTP bzw. HTTPS) gebunden wird, da es sich hierbei um mit Berechtigungen versehene Operationen handelt. Um in Ihrer Domäne leicht zugänglich zu sein, muss Caddy abhängig vom Protokoll an einen dieser Ports gebunden werden. Andernfalls müssten Sie der Domain-URL in Ihrem Browser eine bestimmte Port-Nummer hinzufügen, um die Inhalte anzuzeigen, die er bereitstellen wird.

      Damit Caddy an niedrige Ports gebunden werden kann, ohne als root ausgeführt zu werden, führen Sie den folgenden Befehl aus:

      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      Das Dienstprogramm setcap legt die Dateifähigkeiten fest. In diesem Befehl weist es der Caddy-Binärdatei die Fähigkeit CAP_NET_BIND_SERVICE zu, die es einer ausführbaren Datei ermöglicht, sich an einen niedrigeren Port als 1024 zu binden.

      Sie haben nun die Einrichtung der Caddy-Binärdatei abgeschlossen und können mit dem Schreiben der Caddy-Konfiguration beginnen. Erstellen Sie ein Verzeichnis, in dem Sie die Konfigurationsdateien von Caddy speichern, indem Sie den folgenden Befehl ausführen:

      Legen Sie dann die richtigen Benutzer- und Gruppenberechtigungen dafür fest:

      • sudo chown -R root:www-data /etc/caddy

      Die Einstellung des Benutzers als root und der Gruppe als www-data stellt sicher, dass Caddy Lese- und Schreibzugriff auf den Ordner hat (über die Gruppe www-data) und dass nur das Superuser-Konto die gleichen Rechte zum Lesen und Ändern hat. www-data ist der Standardbenutzer und die Standardgruppe für Webserver unter Ubuntu.

      In einem späteren Schritt werden Sie die automatische TLS-Zertifikatsbereitstellung von Let’s Encrypt aktivieren. Erstellen Sie in Vorbereitung darauf ein Verzeichnis, in dem alle TLS-Zertifikate gespeichert werden, die Caddy erhalten wird, und geben ihm die gleichen Eigentumsregeln wie das Verzeichnis /etc/caddy:

      • sudo mkdir /etc/ssl/caddy
      • sudo chown -R root:www-data /etc/ssl/caddy

      Caddy muss Zertifikate in dieses Verzeichnis schreiben und aus diesem Verzeichnis lesen können, um Anfragen zu verschlüsseln.  Aus diesem Grund sollten Sie die Berechtigungen für das Verzeichnis /etc/ssl/caddy so ändern, dass es nur für root und www-data zugänglich ist:

      • sudo chmod 0770 /etc/ssl/caddy

      Erstellen Sie anschließend ein Verzeichnis, um die Dateien zu speichern, die Caddy hosten wird:

      Setzten Sie dann den Eigentümer und die Gruppe des Verzeichnisses auf www-data:

      • sudo chown www-data:www-data /var/www

      Caddy liest seine Konfiguration aus einer Datei namens Caddyfile, die unter /etc/caddy gespeichert ist. Erstellen Sie die Datei auf der Festplatte, indem Sie Folgendes ausführen:

      • sudo touch /etc/caddy/Caddyfile

      Um den Caddy-Dienst zu installieren, laden Sie die Unit-Datei systemd aus dem Caddy Github-Repository in /etc/systemd/system herunter, indem Sie Folgendes ausführen:

      • sudo sh -c 'curl https://raw.githubusercontent.com/caddyserver/caddy/master/dist/init/linux-systemd/caddy.service > /etc/systemd/system/caddy.service'

      Ändern Sie die Berechtigungen der Dienstdatei, damit sie nur durch ihren Eigentümer root geändert werden kann:

      • sudo chmod 644 /etc/systemd/system/caddy.service

      Dann laden Sie systemd neu, um den Caddy-Dienst zu erkennen:

      • sudo systemctl daemon-reload

      Prüfen Sie, ob systemd den Caddy-Dienst erkannt hat, durch Ausführen von systemctl status:

      • sudo systemctl status caddy

      Sie sehen einen Output, der so ähnlich wie der nachfolgende aussieht:

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: e Active: inactive (dead) Docs: https://caddyserver.com/docs

      Wenn Sie die gleiche Ausgabe sehen, wurde der neue Dienst korrekt von systemd erkannt.

      Als Teil der anfänglichen Server-Einrichtungsvoraussetzung haben Sie ufw, die unkomplizierte Firewall, aktiviert und SSH-Verbindungen zugelassen. Damit Caddy HTTP- und HTTPS-Verkehr von Ihrem Server aus bereitstellen kann, müssen Sie diese in ufw zulassen, indem Sie den folgenden Befehl ausführen:

      • sudo ufw allow proto tcp from any to any port 80,443

      Der Output sieht wie folgt aus:

      Output

      Rule added Rule added (v6)

      Überprüfen Sie mit ufw status, ob Ihre Änderungen funktioniert haben:

      Sie sehen die folgende Ausgabe:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 80,443/tcp ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 80,443/tcp (v6) ALLOW Anywhere (v6)

      Ihre Installation von Caddy ist nun abgeschlossen, aber noch nicht konfiguriert, um etwas bereitzustellen. Im nächsten Schritt konfigurieren Sie Caddy, um Dateien aus dem Verzeichnis /var/www bereitzustellen.

      Schritt 3 – Konfigurieren von Caddy

      In diesem Abschnitt schreiben Sie die grundlegende Caddy-Konfiguration für die Bereitstellung von statischen Dateien von Ihrem Server aus.

      Beginnen Sie mit der Erstellung einer grundlegenden HTML-Datei in /var/www namens index.html:

      • sudo nano /var/www/index.html

      Fügen Sie die folgenden Zeilen hinzu:

      /var/www/index.html

      <!DOCTYPE html>
      <html>
      <head>
        <title>Hello from Caddy!</title>
      </head>
      <body>
        <h1 style="font-family: sans-serif">This page is being served via Caddy</h1>
      </body>
      </html>
      

      Wenn sie in einem Webbrowser angezeigt wird, zeigt sie eine Kopfzeile mit dem Text This page is being served via Caddy. Speichern und schließen Sie die Datei.

      Öffnen Sie die zuvor erstellte Konfigurationsdatei Caddyfile für die Bearbeitung:

      • sudo nano /etc/caddy/Caddyfile

      Fügen Sie die folgenden Zeilen hinzu:

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip
      }
      

      Hierbei handelt es sich um eine grundlegende Caddy-Konfiguration, die besagt, dass der Port 80 Ihres Servers mit Dateien aus /var/www bedient und mit gzip komprimiert werden soll, um die Seitenladezeiten auf der Client-Seite zu reduzieren.

      In den meisten Fällen können Sie die Konfigurationsanweisungen mit Caddy weiter anpassen. Beispielsweise können Sie die gzip-Komprimierung auf HTML- und PHP-Dateien beschränken und die Komprimierungsstufe auf 6 setzen (1 ist die niedrigste und 9 die höchste Komprimierungsstufe), indem Sie die Anweisung mit geschweiften Klammern erweitern und Unteranweisungen darunter auflisten:

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip {
            ext .html .htm .php
            level 6
        }
      }
      

      Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Caddy verfügt über eine große Anzahl verschiedener Richtlinien für viele Anwendungsfälle. Beispielsweise könnte die Anweisung fastcgi für das Aktivieren von PHP nützlich sein. Die Anweisung markdown könnte verwendet werden, um Markdown-Dateien vor der Bereitstellung automatisch in HTML zu konvertieren, was für die Erstellung eines einfachen Blogs nützlich sein könnte.

      Um zu testen, ob alles korrekt funktioniert, starten Sie den Caddy-Dienst:

      • sudo systemctl start caddy

      Führen Sie als Nächstes systemctl status aus, um Informationen über den Status des Caddy-Dienstes zu erhalten:

      • sudo systemctl status caddy

      Sie sehen dann Folgendes:

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 11:17:49 UTC; 11s ago Docs: https://caddyserver.com/docs Main PID: 3893 (caddy) Tasks: 7 (limit: 1152) CGroup: /system.slice/caddy.service └─3893 /usr/local/bin/caddy -log stdout -log-timestamps=false -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp Mar 12 11:17:49 caddy-article-update systemd[1]: Started Caddy HTTP/2 web server. Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO] Caddy version: v1.0.5 Mar 12 11:17:49 caddy-article-update caddy[3893]: Activating privacy features... done. Mar 12 11:17:49 caddy-article-update caddy[3893]: Serving HTTP on port 80 Mar 12 11:17:49 caddy-article-update caddy[3893]: http:// Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO] Serving http:// Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO][cache:0xc00007a7d0] Started certificate maintenance routine Mar 12 11:17:49 caddy-article-update caddy[3893]: [WARNING] Sending telemetry (attempt 1): Post "https://telemetry.caddyserver.com/v1/update/6a8159c4-3427-42 Mar 12 11:17:57 caddy-article-update caddy[3893]: [WARNING] Sending telemetry (attempt 2): Post "https://telemetry.caddyserver.com/v1/update/6a8159c4-3427-42 ...

      Sie können nun in einem Webbrowser zu der IP Ihres Servers browsen. Ihre Beispiel-Webseite zeigt an:

      Nachricht von Caddy

      Sie haben Caddy nun konfiguriert, um statische Dateien von Ihrem Server aus bereitzustellen. Im nächsten Schritt erweitern Sie die Funktionalität von Caddy durch die Verwendung von Plugins.

      Schritt 4 — Verwenden von Plugins

      Plugins bieten eine Möglichkeit, das Verhalten von Caddy zu ändern und zu erweitern. Sie bieten allgemein mehr Konfigurationsanweisungen, die Sie je nach Anwendungsfall verwenden können. In diesem Abschnitt fügen Sie Plugins hinzu und verwenden sie durch die Installation des Plugin minify, das überschüssige Leerzeichen entfernt und den Code, der an den Client gesendet wird, aufräumt, wodurch der Platzbedarf und die Ladezeiten weiter reduziert werden.

      Das GitHub-Repository des Plugins minify ist hacdias/caddy-minify.

      Navigieren Sie zum Verzeichnis mit dem Quellcode, den Sie in Schritt Eins erstellt haben:

      Um Caddy ein Plugin hinzuzufügen, müssen Sie es in die Datei caddy.go importieren, die Sie zum Erstellen von Caddy verwendet haben. Öffnen Sie caddy.go zum Bearbeiten:

      Importieren Sie das Plugin minify, indem Sie die hervorgehobene Zeile hinzufügen, wie hier beschrieben:

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      
          _ "github.com/hacdias/caddy-minify"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Speichern und schließen Sie die Datei.

      Einige Plugins erfordern möglicherweise einige geringfügige Konfigurationsanpassungen, lesen Sie also unbedingt die Dokumentation des Plugins, das Sie installieren. Eine Liste beliebter Plugins finden Sie im linken Fenster der Caddy-Dokumentation unter Plugins.

      Sie müssen Caddy bei jedem Hinzufügen eines neuen Plugins neu erstellen. Das liegt daran, dass Go eine kompilierte Programmiersprache ist, d. h. der Quellcode wird vor der Ausführung in Computercode umgewandelt.  Ihre Änderung an der Importdeklaration hat den Quellcode verändert, wirkt sich aber erst nach der Kompilierung auf die Binärdatei aus.

      Verwenden Sie den Befehl go install, um Caddy zu kompilieren:

      Verschieben Sie nach dem Abschluss die erzeugte Binärdatei nach /usr/local/bin und richten Sie Berechtigungen für die Binärdatei ein, wie Sie es zuvor getan haben. Sie müssen diese Schritte bei jeder Neuerstellung von Caddy durchführen, um dessen Funktionalität und Sicherheit zu gewährleisten:

      • sudo mv $GOPATH/bin/caddy /usr/local/bin/
      • sudo chown root:root /usr/local/bin/caddy
      • sudo chmod 755 /usr/local/bin/caddy
      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      Um das Plugin minify zu verwenden, müssen Sie die Anweisung minify zu Ihrer Caddyfile hinzufügen. Öffnen Sie sie zum Bearbeiten:

      • sudo nano /etc/caddy/Caddyfile

      Aktivieren Sie das Plugin, indem Sie die folgende Zeile zum Konfigurationsblock hinzufügen:

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip
        minify
      }
      

      Starten Sie nun Ihren Server mit systemctl neu:

      • sudo systemctl restart caddy

      Caddy wird nun ausgeführt und wird alle bereitgestellten Daten, einschließlich der zuvor erstellten Datei index.html, „minifizieren“. Sie können die „Minifizierung“ bei der Arbeit beobachten, indem Sie den Inhalt Ihrer Domäne mit curl abrufen:

      Sie werden die folgende Ausgabe sehen: Beachten Sie, dass alle unnötigen Leerzeichen entfernt wurden, was zeigt, dass das Plugin minify funktioniert.

      Output

      <!doctype html><title>Hello from Caddy!</title><h1 style=font-family:sans-serif>This page is being served via Caddy</h1>

      In diesem Schritt haben Sie gelernt, wie Sie Caddy mit Plugins erweitern können. Als Nächstes aktivieren Sie HTTPS, indem Sie das Plugin tls.dns.digitalocean installieren.

      Schritt 5 — Aktivieren von automatischem TLS mit Let’s Encrypt

      In diesem Abschnitt aktivieren Sie die automatische Bereitstellung und Erneuerung von Zertifikaten durch Let’s Encrypt, wobei TXT-DNS-Datensätze zur Verifizierung verwendet werden.

      Um die Verwendung von TXT-DNS-Datensätzen zu verifizieren, installieren Sie mit der DigitalOcean-API namens tls.dns.digitalocean ein Plugin für die Schnittstelle. Das Verfahren zur Installation dieses Plugins ist fast identisch mit der Installation des Plugins minify im vorherigen Schritt. Öffnen Sie zunächst caddy.go:

      Fügen Sie das Repository des Plugins zu imports hinzu:

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      
          _ "github.com/hacdias/caddy-minify"
      
          _ "github.com/caddyserver/dnsproviders/digitalocean"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Kompilieren Sie es durch Ausführen von:

      Stellen Sie sicher, dass Caddy über systemctl angehalten wird, und beenden Sie dann die Installation des Plugins, indem Sie die neu erstellte Caddy-Binärdatei kopieren und noch einmal die Eigentümerschaft und die Berechtigungen festlegen:

      • sudo systemctl stop caddy
      • sudo mv $GOPATH/bin/caddy /usr/local/bin/
      • sudo chown root:root /usr/local/bin/caddy
      • sudo chmod 755 /usr/local/bin/caddy
      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      Konfigurieren Sie anschließend Caddy, um mit der API von DigitalOcean zum Festlegen von DNS-Einträgen zu arbeiten. Caddy muss auf dieses Token als Umgebungsvariable zugreifen, um den DNS von DigitalOcean zu konfigurieren, damit Sie die Unit-Datei systemd bearbeiten können:

      • sudo nano /etc/systemd/system/caddy.service

      Suchen Sie die Zeile, die mit Environment= beginnt, im Abschnitt [Service]. Diese Zeile definiert die Umgebungsvariablen, die an den Caddy-Prozess übergeben werden sollen. Fügen Sie am Ende dieser Zeile ein Leerzeichen ein, fügen Sie dann eine Variable DO_AUTH_TOKEN hinzu, gefolgt von dem Token, das Sie gerade generiert haben:

      /etc/systemd/system/caddy.service

      [Service]
      Restart=on-abnormal
      
      ; User and group the process will run as.
      User=www-data
      Group=www-data
      
      ; Letsencrypt-issued certificates will be written to this directory.
      Environment=CADDYPATH=/etc/ssl/caddy DO_AUTH_TOKEN=your_token_here
      

      Speichern und schließen Sie diese Datei und laden Sie dann den Daemon systemd wie zuvor neu, um sicherzustellen, dass die Konfiguration aktualisiert wird:

      • sudo systemctl daemon-reload

      Führen Sie systemctl status aus, um zu überprüfen, ob Ihre Konfigurationsänderungen in Ordnung sind:

      • sudo systemctl status caddy

      Die Ausgabe sollte wie folgt aussehen:

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: https://caddyserver.com/docs ...

      Sie müssen einige geringfügige Änderungen an Ihrer Caddyfile vornehmen, also öffnen Sie diese zur Bearbeitung:

      • sudo nano /etc/caddy/Caddyfile

      Fügen Sie die hervorgehobenen Zeilen in die Caddyfile ein. Achten Sie darauf, dass Sie dabei your_domain durch Ihre Domäne ersetzen (statt nur Port :80) und gzip kommentieren:

      /etc/caddy/Caddyfile

      your_domain {
        root /var/www
        #gzip
        minify
        tls {
            dns digitalocean
        }
      }
      

      Die Verwendung einer Domäne statt nur eines Ports für den Hostnamen führt dazu, dass Caddy Anfragen über HTTP bedient. Die Anweisung tls konfiguriert das Verhalten von Caddy bei Verwendung von TLS, und die Unteranweisung dns gibt an, dass Caddy das DNS-01-System anstelle des HTTP-01 verwenden soll.

      Damit ist Ihre Website für die Bereitstellung bereit. Starten Sie Caddy mit systemctl und aktivieren Sie es dann mit enable, damit es beim Starten ausgeführt wird.

      • sudo systemctl start caddy
      • sudo systemctl enable caddy

      Wenn Sie zu Ihrer Domäne browsen, werden Sie automatisch zu HTTPS umgeleitet, wobei dieselbe Meldung angezeigt wird.

      Ihre Installation von Caddy ist nun abgeschlossen und gesichert und Sie können je nach Anwendungsfall weitere Anpassungen vornehmen.

      Wenn Sie Caddy aktualisieren möchten, wenn eine neue Version verfügbar ist, müssen Sie die Datei go.mod (im gleichen Verzeichnis gespeichert) aktualisieren, die wie folgt aussieht:

      ~/caddy/go.mod

      module caddy
      
      go 1.14
      
      require (
              github.com/caddyserver/caddy v1.0.5
              github.com/caddyserver/dnsproviders v0.4.0
              github.com/hacdias/caddy-minify v1.0.2
      )
      

      Der hervorgehobene Bereich ist die von Ihnen verwendete Version von Caddy. Wenn eine neue Version auf Github veröffentlicht wird (siehe die Seite mit den Versions-Tags), können Sie die bestehende Version in go.mod durch diese ersetzen und Caddy entsprechend der ersten beiden Schritte kompilieren. Sie können dasselbe für alle importierten Plugins tun.

      Zusammenfassung

      Sie haben Caddy nun auf Ihrem Server installiert und konfiguriert, sodass statische Seiten auf Ihrer gewünschten Domäne bereitgestellt werden, die mit kostenlosen Let’s Encrypt TLS-Zertifikaten gesichert sind.

      Ein guter nächster Schritt wäre, einen Weg für die Benachrichtigung zu finden, wenn neue Versionen von Caddy veröffentlicht werden. Sie können beispielsweise den Atom-Feed für Caddy-Veröffentlichungen oder den dedizierten Dienst dependencies.io verwenden.

      Weitere Informationen zur Konfiguration von Caddy finden Sie in der Dokumentation von Caddy.



      Source link

      Sidekiq und Redis einer Ruby-on-Rails-Anwendung hinzufügen


      Einführung

      Bei der Entwicklung einer Ruby-on-Rails-Anwendung stellen Sie möglicherweise fest, dass Sie Anwendungsaufgaben haben, die asynchron ausgeführt werden sollten. Die Verarbeitung von Daten, das Versenden von Batch-E-Mails oder die Interaktion mit externen APIs sind Beispiele für Arbeiten, die asynchron mit Hintergrundjobs durchgeführt werden können. Die Verwendung von Hintergrundjobs kann die Leistung Ihrer Anwendung verbessern, indem möglicherweise zeitintensive Aufgaben in eine Hintergrundverarbeitungs-Warteschlange ausgelagert werden, wodurch der ursprüngliche Anfrage-/Antwort-Zyklus entlastet wird.

      Sidekiq ist eines der am häufigsten verwendeten Hintergrundjob-Frameworks, das Sie in einer Rails-Anwendung implementieren können. Es wird von Redis unterstützt, einem In-Memory-Schlüsselwertspeicher, der für seine Flexibilität und Leistung bekannt ist. Sidekiq verwendet Redis als Aufgabenmanagementspeicher, um pro Sekunde Tausende von Aufgaben zu verarbeiten.

      In diesem Tutorial fügen Sie Redis und Sidekiq zu einer bestehenden Rails-Anwendung hinzu. Sie werden einen Satz von Sidekiq Worker-Klassen und -Verfahren erstellen, um Folgendes zu bewältigen:

      • Einen Batch-Upload von Informationen über bedrohte Haie in die Anwendungsdatenbank aus einer CSV-Datei im Projekt-Repository.
      • Die Entfernung dieser Daten.

      Wenn Sie fertig sind, haben Sie eine Demo-Anwendung, die Workers und Jobs verwendet, um Aufgaben asynchron zu verarbeiten. Dieses Tutorial ist ein guter Startpunkt, damit Sie später Worker und Jobs zu Ihrer eigenen Anwendung hinzufügen können.

      Voraussetzungen

      Um dieser Anleitung zu folgen, benötigen Sie:

      Schritt 1 – Klonen des Projekts und Installieren von Abhängigkeiten

      Unser erster Schritt besteht darin, das Repository rails-bootstrap aus dem DigitalOcean Community GitHub-Konto zu klonen. Dieses Repository enthält den Code aus dem Setup, das in „Hinzufügen von Sidekiq und Redis zu einer Ruby-on-Rails-Anwendung“ beschrieben wird. Dort wird erklärt, wie Bootstrap zu einem bestehenden Rails 5-Projekt hinzugefügt wird.

      Klonen Sie das Repository in ein Verzeichnis namens rails-sidekiq:

      • git clone https://github.com/do-community/rails-bootstrap.git rails-sidekiq

      Navigieren Sie zum Verzeichnis rails-sidekiq:

      Um mit dem Code arbeiten zu können, müssen Sie zunächst die Abhängigkeiten des Projekts installieren, die in seiner Gemfile aufgelistet sind. Um mit Sidekiq und Redis arbeiten zu können, müssen Sie dem Projekt auch das Gem sidekiq hinzufügen.

      Öffnen Sie das Gemfile des Projekts zur Bearbeitung mit nano oder Ihrem bevorzugten Editor:

      Fügen Sie das Gem an beliebiger Stelle in die Abhängigkeiten des Hauptprojekts ein (oberhalb der Entwicklungsabhängigkeiten):

      ~/rails-sidekiq/Gemfile

      . . .
      # Reduces boot times through caching; required in config/boot.rb
      gem 'bootsnap', '>= 1.1.0', require: false
      gem 'sidekiq', '~>6.0.0'
      
      group :development, :test do
      . . .
      

      Speichern und schließen Sie die Datei, wenn Sie mit dem Hinzufügen des Gems fertig sind.

      Verwenden Sie den folgenden Befehl, um die Gems zu installieren:

      Sie werden in der Ausgabe sehen, dass das Gem redis auch als Erfordernis für sidekiq installiert ist.

      Als Nächstes installieren Sie Ihre Yarn-Abhängigkeiten. Da dieses Rails 5-Projekt modifiziert wurde, um Assets mit webpack bereitzustellen, werden seine JavaScript-Abhängigkeiten nun von Yarn verwaltet. Das bedeutet es ist notwendig, die in der Datei package.json des Projekts aufgeführten Abhängigkeiten zu installieren und zu verifizieren.

      Führen Sie yarn install aus, um diese Abhängigkeiten zu installieren:

      Führen Sie als Nächstes Ihre Datenbankmigration durch:

      Sobald Ihre Migrationen abgeschlossen sind, können Sie die Anwendung testen, um sicherzustellen, dass sie wie erwartet funktioniert. Starten Sie Ihren Server im Kontext Ihres lokalen Bundles mit dem folgenden Befehl, wenn Sie lokal arbeiten:

      Wenn Sie auf einem Entwicklungsserver arbeiten, können Sie die Anwendung starten mit:

      • bundle exec rails s --binding=your_server_ip

      Navigieren Sie zu localhost:3000 oder http://your_server_ip:3000. Sie sehen die folgende Startseite:

      Anwendungs-Startseite

      Um einen neuen Hai zu erstellen, klicken Sie auf die Schaltfläche Get Shark Info, die Sie zu der Route sharks/index führt:

      Sharks Index-Route

      Um zu verifizieren, dass die Anwendung funktioniert, können wir ihr einige Demo-Informationen anhängen. Klicken Sie auf New Shark. Dank der Authentifizierungseinstellungen des Projekts werden Sie zur Eingabe des Benutzernamens (sammy) und Passworts (shark) aufgefordert.

      Geben Sie auf der Seite New Shark unter Name „Great White“ und unter Facts „Scary“ ein:

      Hai erstellen

      Klicken Sie auf die Schaltfläche Create Shark, um den Shark zu erstellen. Sobald Sie sehen, dass Ihr Hai erstellt wurde, können Sie den Server mit STRG+C beenden.

      Sie haben nun die notwendigen Abhängigkeiten für Ihr Projekt installiert und seine Funktionalität getestet. Als Nächstes können Sie einige Änderungen der Rails-Anwendung vornehmen, um mit Ihren Ressourcen für bedrohte Haie zu arbeiten.

      Schritt 2 — Generieren eines Controllers für Ressourcen für bedrohte Haie

      Um mit unseren Ressourcen für bedrohte Haie zu arbeiten, fügen wir der Anwendung ein neues Modell und einen Controller hinzu, der steuert, wie den Benutzern Informationen über bedrohte Haie präsentiert werden. Unser ultimatives Ziel ist, den Benutzern das Hochladen einer großen Menge von Informationen über bedrohte Haie zu ermöglichen, ohne die Gesamtfunktionalität unserer Anwendung zu blockieren, und diese Informationen zu löschen, wenn sie sie nicht mehr benötigen.

      Erstellen wir zunächst ein Modell Endangered für unsere bedrohten Haie. Wir werden ein Zeichenfolgenfeld für den Hainamen in unsere Datenbanktabelle aufnehmen und ein weiteres Zeichenfolgenfeld für die Kategorien der International Union for the Conservation of Nature (IUCN), die den Grad der Gefährdung der einzelnen Haie bestimmen.

      Letztendlich entspricht unsere Modellstruktur den Spalten in der CSV-Datei, die wir zur Erstellung unseres Batch-Uploads verwenden werden. Diese Datei befindet sich im Verzeichnis db und Sie können ihren Inhalt mit dem folgenden Befehl überprüfen:

      Die Datei enthält eine Liste von 73 bedrohten Haien und ihren IUCN-Status – vu für gefährdet, en für bedroht und cr für vom Aussterben bedroht.

      Unser Modell Endangered wird mit diesen Daten übereinstimmen, sodass wir neue Instanzen Endangered aus dieser CSV-Datei erstellen können. Erstellen Sie das Modell mit dem folgenden Befehl:

      • rails generate model Endangered name:string iucn:string

      Erstellen Sie als Nächstes einen Controller Endangered mit einer Aktion index:

      • rails generate controller endangered index

      Dadurch erhalten wir einen Ausgangspunkt, um die Funktionalität unserer Anwendung auszubauen, obwohl wir auch benutzerdefinierte Methoden zu der Controller-Datei hinzufügen müssen, die Rails für uns generiert hat.

      Öffnen Sie nun diese Datei:

      • nano app/controllers/endangered_controller.rb

      Rails hat uns ein Grundgerüst zur Verfügung gestellt, das wir nun ausfüllen können.

      Zunächst müssen wir bestimmen, welche Routen wir für die Arbeit mit unseren Daten benötigen. Dank dem Befehl generate controller haben wir eine Methode index, mit der wir beginnen können. Diese wird mit einer Ansicht index korrelieren, in der wir den Benutzern die Möglichkeit bieten werden, bedrohte Haie hochzuladen.

      Wir werden aber auch Fälle bearbeiten wollen, in denen Benutzer die Haie möglicherweise bereits hochgeladen haben. In diesem Fall benötigen sie keine Upload-Option. Wir werden irgendwie beurteilen müssen, wie viele Instanzen der Klasse Endangered bereits existieren, da mehr als eine darauf hinweist, dass der Batch-Upload bereits stattgefunden hat.

      Beginnen wir mit der Erstellung einer Methode private set_endangered, die jede Instanz unserer Klasse Endangered aus der Datenbank abrufen wird. Fügen Sie den folgenden Code zur Datei hinzu:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index
        end
      
        private
      
          def set_endangered
            @endangered = Endangered.all
          end
      
      end
      

      Beachten Sie, dass der Filter before_action sicherstellt, dass der Wert von @endangered nur für die Routen index und data festgelegt ist. Dort verarbeiten wir die Daten über bedrohte Haie.

      Fügen Sie als Nächstes den folgenden Code zu der Methode index hinzu, um den richtigen Pfad für Benutzer zu bestimmen, die diesen Teil der Anwendung besuchen:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      . . .
      

      Wenn mehr als 0 Instanzen unserer Klasse Endangered vorhanden sind, leiten wird die Benutzer auf die Route data um, wo sie Informationen über die von ihnen erstellten Haie einsehen können. Andernfalls sehen sie die Ansicht index.

      Fügen Sie als Nächstes unter die Methode index eine Methode data hinzu, die mit der Ansicht data korreliert:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      
        def data
        end
      . . .
      

      Als Nächstes fügen wir eine Methode hinzu, um den Daten-Upload selbst zu verarbeiten. Wir nennen diese Methode upload und sie wird eine Sidekiq Worker-Klasse und -methode aufrufen, um den Daten-Upload aus der CSV-Datei durchzuführen. Im nächsten Schritt erstellen wir die Definition für diese Worker-Klasse, AddEndangeredWorker.

      Für den Moment fügen Sie den folgenden Code zu der Datei hinzu, um den Sidekiq Worker aufzurufen, der den Upload ausführt:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def data
        end
      
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      . . .
      

      Durch den Aufruf der Methode perform_async in der Klasse AddEndangeredWorker mit der CSV-Datei als Argument, stellt dieser Code sicher, dass die Haidaten und der Upload-Job an Redis übergeben werden. Die Sidekiq Workers, die wir einrichten werden, überwachen die Job-Warteschlange und reagieren, wenn neue Jobs entstehen.

      Nach dem Aufruf von perform_async leitet unsere Methode upload zu dem Pfad data um, wo Benutzer die hochgeladenen Haie einsehen können.

      Als Nächstes fügen wir eine Methode destroy zur Zerstörung der Daten hinzu. Fügen Sie den folgenden Code unter die Methode upload hinzu:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      . . .
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      
        def destroy
          RemoveEndangeredWorker.perform_async
          redirect_to root_path
        end
      . . .
      

      Wie unsere Methode upload beinhaltet unsere Methode destroy einen Aufruf perform_async der Klasse RemoveEndangeredWorker – den anderen Sidekiq Worker, den wir erstellen werden. Nach dem Aufruf dieser Methode leitet sie die Benutzer zu dem Stammanwendungspfad um.

      Die fertige Datei sieht ungefähr so aus:

      ~/rails-sidekiq/app/controllers/endangered_controller.rb

      class EndangeredController < ApplicationController
        before_action :set_endangered, only: [:index, :data]
      
        def index          
          if @endangered.length > 0
            redirect_to endangered_data_path
          else
            render 'index'
          end
        end
      
        def data
        end
      
        def upload
          csv_file = File.join Rails.root, 'db', 'sharks.csv'   
          AddEndangeredWorker.perform_async(csv_file)
          redirect_to endangered_data_path, notice: 'Endangered sharks have been uploaded!'
        end
      
        def destroy
          RemoveEndangeredWorker.perform_async
          redirect_to root_path
        end
      
        private
      
          def set_endangered
            @endangered = Endangered.all
          end
      
      end
      

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Als letzten Schritt zur Verfestigung der Routen unserer Anwendung werden wir den Code config/routes.rb der Datei, in der sich unsere Routendeklarationen befinden, ändern.

      Öffnen Sie nun diese Datei:

      Die Datei sieht derzeit wie folgt aus:

      ~/rails-sidekiq/config/routes.rb

      Rails.application.routes.draw do
        get 'endangered/index'
        get 'home/index'
        resources :sharks do
                resources :posts
        end
        root 'home#index'
        # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
      end
      

      Wir müssen die Datei aktualisieren, um die in unserem Controller definierten Routen aufzunehmen: data, upload und destroy. Unsere Route data wird mit einer GET-Anforderung zum Abrufen der Haifischdaten übereinstimmen, während unsere Routen upload und destroy den POST-Anforderungen zugeordnet werden, die diese Daten hochladen und zerstören.

      Fügen Sie den folgenden Code zu der Datei hinzu, um diese Routen zu definieren:

      ~/rails-sidekiq/config/routes.rb

      Rails.application.routes.draw do
        get 'endangered/index'
        get 'endangered/data', to: 'endangered#data'
        post 'endangered/upload', to: 'endangered#upload'
        post 'endangered/destroy', to: 'endangered#destroy'
        get 'home/index'
        resources :sharks do
                resources :posts
        end
        root 'home#index'
        # For details on the DSL available within this file, see http://guides.rubyonrails.org/routing.html
      end
      

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Nachdem Sie Ihr Modell Endangered und Ihre Controller eingerichtet haben, können Sie nun mit der Definition Ihrer Sidekiq Worker-Klassen fortfahren.

      Schritt 3 – Definieren von Sidekiq Workers

      Wir haben die Methode perform_async für unsere Sidekiq Worker in unserem Controller aufgerufen, aber wir müssen noch die Worker selbst erstellen.

      Erstellen Sie zunächst ein Verzeichnis workers für die Worker:

      Öffnen Sie eine Datei für den Worker AddEndangeredWorker:

      • nano app/workers/add_endangered_worker.rb

      Wir fügen in dieser Datei Code ein, der uns die Arbeit mit den Daten in unserer CSV-Datei ermöglicht. Zunächst fügen wir der Datei Code hinzu, der die Klasse erstellt, die Ruby-CSV-Bibliothek einbezieht und sicherstellt, dass diese Klasse als Sidekiq Worker funktioniert:

      ~/rails-sidekiq/app/workers/add_endangered_worker.rb

      class AddEndangeredWorker
        require 'csv'
        include Sidekiq::Worker
        sidekiq_options retry: false
      
      end
      

      Wir fügen auch die Option retry: false ein, um sicherzustellen, dass Sidekiq den Upload im Falle eines Fehlschlags nicht erneut versucht.

      Fügen Sie als Nächstes den Code für die Funktion perform hinzu:

      ~/rails-sidekiq/app/workers/add_endangered_worker.rb

      class AddEndangeredWorker
        require 'csv'
        include Sidekiq::Worker
        sidekiq_options retry: false
      
        def perform(csv_file)
          CSV.foreach(csv_file, headers: true) do |shark|
          Endangered.create(name: shark[0], iucn: shark[1])
        end
       end
      
      end
      

      Die Methode perform empfängt Argumente von der im Controller definierten Methode perform_async. Daher ist es wichtig, dass die Argumentwerte abgeglichen sind. Hier übergeben wir in csv_file, die in dem Controller definierte Variable und verwenden die Methode foreach aus der CSV-Bibliothek, um die Werte in der Datei zu lesen. Das Setzen von headers: true für diese Schleife stellt sicher, dass die erste Zeile der Datei als eine Zeile von Headers behandelt wird.

      Der Block liest dann die Werte von der Datei in die Spalten, die wir für unser Modell Endangered festgelegt haben: name und iucn. Durch Ausführung dieser Schleife werden für jeden der Einträge in unserer CSV-Datei Instanzen Endangered erstellt.

      Wenn Sie die Bearbeitung abgeschlossen haben, speichern und schließen Sie die Datei.

      Als Nächstes erstellen wir einen Worker, der sich um das Löschen dieser Daten kümmert. Öffnen Sie eine Datei für die Klasse RemoveEndangeredWorker:

      • nano app/workers/remove_endangered_worker.rb

      Fügen Sie den Code zur Definition der Klasse hinzu und stellen Sie sicher, dass sie die CSV-Bibliothek verwendet und als Sidekiq Worker funktioniert:

      ~/rails-sidekiq/app/workers/remove_endangered_worker.rb

      class RemoveEndangeredWorker
        include Sidekiq::Worker
        sidekiq_options retry: false
      
      end
      

      Fügen Sie als Nächstes eine Methode perform hinzu, um die Zerstörung der Daten von bedrohten Haien zu handhaben:

      ~/rails-sidekiq/app/workers/remove_endangered_worker.rb

      class RemoveEndangeredWorker
        include Sidekiq::Worker
        sidekiq_options retry: false
      
        def perform
          Endangered.destroy_all
        end
      
      end
      

      Die Methode perform ruft destroy_all in der Klasse Endangered auf, wodurch alle Instanzen der Klasse aus der Datenbank entfernt werden.

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Nachdem Sie Ihre Worker eingerichtet haben, können Sie mit der Erstellung eines Layouts für Ihre Ansichten endangered und von Vorlagen für Ihre Ansichten index und data fortfahren, sodass Benutzer bedrohte Haie hochladen und ansehen können.

      Schritt 4 – Hinzufügen von Layouts und Ansichtsvorlagen

      Damit Benutzer in den Genuss ihrer Informationen über bedrohte Haie kommen, müssen wir uns mit zwei Dingen befassen: dem Layout für die in unserem Controller endangered definierten Ansichten und mit den Ansichtsvorlagen für die Ansichten index und data.

      Unsere Anwendung verwendet derzeit ein anwendungsweites Layout, das sich unter app/views/layouts/application.html.erb befindet, eine Navigations-Partiale und ein Layout für die Ansichten sharks. Das Anwendungslayout prüft, ob ein Inhaltsblock vorhanden ist, der das Laden verschiedener Layouts ermöglicht, je nachdem, mit welchem Teil der Anwendung sich unsere Benutzer beschäftigen: für die Seite home index sehen sie ein Layout und für alle Ansichten über individuelle Haie ein anderes.

      Wir können das Layout sharks für unsere Ansichten endangered neu verwenden, da dieses Format auch für die Darstellung von Haidaten in großen Mengen funktioniert.

      Kopieren Sie die Layoutdatei sharks, um ein Layout für endangered zu erstellen:

      • cp app/views/layouts/sharks.html.erb app/views/layouts/endangered.html.erb

      Als Nächstes werden wir an der Erstellung von Ansichtenvorlagen für unsere Ansichten index und data arbeiten.

      Öffnen Sie zuerst die Vorlage index:

      • nano app/views/endangered/index.html.erb

      Löschen Sie den Boilerplate-Code und fügen Sie stattdessen den folgenden Code hinzu, der den Benutzern einige allgemeine Informationen über die bedrohten Kategorien gibt und ihnen die Möglichkeit bietet, Informationen über bedrohte Haie hochzuladen:

      ~/rails-sidekiq/app/views/endangered/index.html.erb

      <p id="notice"><%= notice %></p>
      
      <h1>Endangered Sharks</h1>
      
      <p>International Union for Conservation of Nature (ICUN) statuses: <b>vu:</b> Vulnerable, <b>en:</b> Endangered, <b>cr:</b> Critically Endangered </p>
      
      <br>
      
        <%= form_tag endangered_upload_path do %>
        <%= submit_tag "Import Endangered Sharks" %>
        <% end %>
      
        <br>
      
      <%= link_to 'New Shark', new_shark_path, :class => "btn btn-primary btn-sm" %> <%= link_to 'Home', home_index_path, :class => "btn btn-primary btn-sm" %>
      

      Ein form_tag macht den Daten-Upload möglich, indem eine Post-Aktion auf den endangered_upload_path verweist – die Route, die wir für unsere Uploads definiert haben.  Eine Submit-Schaltfläche, die mit dem submit_tag erstellt wurde, fordert die Benutzer zum "Import Endangered Sharks" (Importieren bedrohter Haie) auf.

      Zusätzlich zu diesem Code haben wir einige allgemeine Informationen über ICUN-Codes eingefügt, damit die Benutzer die Daten, die sie sehen werden, interpretieren können.

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Öffnen Sie als Nächstes eine Datei für die Ansicht data:

      • nano app/views/endangered/data.html.erb

      Fügen Sie den folgenden Code hinzu, der eine Tabelle mit den Daten der bedrohten Haie hinzufügt:

      ~/rails-sidekiq/app/views/endangered/data.html.erb

      <p id="notice"><%= notice %></p>
      
      <h1>Endangered Sharks</h1>
      
      <p>International Union for Conservation of Nature (ICUN) statuses: <b>vu:</b> Vulnerable, <b>en:</b> Endangered, <b>cr:</b> Critically Endangered </p>
      
      <div class="table-responsive">
      <table class="table table-striped table-dark">
        <thead>
          <tr>
            <th>Name</th>
            <th>IUCN Status</th>
            <th colspan="3"></th>
          </tr>
        </thead>
      
        <tbody>
          <% @endangered.each do |shark| %>
            <tr>
              <td><%= shark.name %></td>
              <td><%= shark.iucn %></td>
            </tr>
          <% end %>
        </tbody>
      </table>
      </div>
      
      <br>
      
        <%= form_tag endangered_destroy_path do %>
        <%= submit_tag "Delete Endangered Sharks" %>
        <% end %>
      
        <br>
      
      <%= link_to 'New Shark', new_shark_path, :class => "btn btn-primary btn-sm" %> <%= link_to 'Home', home_index_path, :class => "btn btn-primary btn-sm" %>
      

      Dieser Code enthält noch einmal die ICUN-Statuscodes und eine Bootstrap-Tabelle für die ausgegebenen Daten. Indem wir unsere Variable @endangered durchschleifen, geben wir den Namen und den ICUN-Status jedes Hais in die Tabelle aus.

      Unterhalb der Tabelle haben wir einen weiteren Satz von form_tags und submit_tags, die auf den Pfad destroy verweisen, indem Benutzern die Option zum "Delete Endangered Sharks" (Löschen bedrohter Haie) angeboten wird.

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Die letzte Änderung, die wir für unsere Ansichten vornehmen, wird in der Ansicht index vorgenommen, die mit unserem Controller home verknüpft ist. Sie erinnern sich vielleicht daran, dass diese Ansicht als das Stammverzeichnis der Anwendung in config/routes.rb festgelegt ist.

      Öffnen Sie diese Datei zur Bearbeitung:

      • nano app/views/home/index.html.erb

      Finden Sie die Spalte in der Zeile, die besagt Sharks are ancient (Haie sind uralt):

      ~/rails-sidekiq/app/views/home/index.html.erb

      . . .
              <div class="col-lg-6">
                  <h3>Sharks are ancient</h3>
                  <p>There is evidence to suggest that sharks lived up to 400 million years ago.
                  </p>
              </div>
          </div>
      </div>
      

      Fügen Sie den folgenden Code zur Datei hinzu:

      ~/rails-sidekiq/app/views/home/index.html.erb

      . . .
              <div class="col-lg-6">
                  <h3>Sharks are ancient and SOME are in danger</h3>
                  <p>There is evidence to suggest that sharks lived up to 400 million years ago. Without our help, some could disappear soon.</p>
                  <p><%= button_to 'Which Sharks Are in Danger?', endangered_index_path, :method => :get,  :class => "btn btn-primary btn-sm"%>
                  </p>
              </div>
          </div>
      </div>
      

      Wir haben einen Handlungsaufruf für Benutzer aufgenommen, um mehr über bedrohte Haie zu erfahren, indem wir zuerst eine starke Botschaft weitergeben und dann einen Helfer button_to hinzufügen, der eine GET-Anfrage an die Route endangered index sendet und Benutzern Zugriff auf diesen Teil der Anwendung gewährt. Von dort aus können sie Informationen über bedrohte Haie hochladen und anzeigen.

      Wenn die Bearbeitung abgeschlossen wurde, speichern und schließen Sie die Datei.

      Nachdem Sie nun Ihren Code eingegeben haben, können Sie die Anwendung starten und einige Haie hochladen!

      Schritt 5 – Starten von Sidekiq und Testen der Anwendung

      Bevor wir die Anwendung starten, müssen wir Migrationen in unserer Datenbank durchführen und Sidekiq starten, um unsere Worker zu aktivieren. Redis sollte bereits auf dem Server ausgeführt werden, aber wir können das überprüfen, um sicherzugehen. Sobald all diese Dinge eingerichtet sind, sind wir bereit, die Anwendung zu testen.

      Überprüfen Sie zunächst, ob Redis ausgeführt wird:

      Sie sollten eine Ausgabe wie die folgende sehen:

      Output

      ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-11-12 20:37:13 UTC; 1 weeks 0 days ago

      Führen Sie als Nächstes Ihre Datenbankmigration durch:

      Sie können nun Sidekiq im Kontext Ihres aktuellen Projekt-Bundles starten, indem Sie den Befehl bundle exec sidekiq verwenden:

      Sie werden eine ähnliche Ausgabe wie diese sehen, die anzeigt, dass Sidekiq zur Bearbeitung von Jobs bereit ist:

      Output

      m, `$b .ss, $$: .,d$ `$$P,d$P' .,md$P"' ,$$$$$b/md$$$P^' .d$$$$$$/$$$P' $$^' `"/$$$' ____ _ _ _ _ $: ,$$: / ___|(_) __| | ___| | _(_) __ _ `b :$$ ___ | |/ _` |/ _ |/ / |/ _` | $$: ___) | | (_| | __/ <| | (_| | $$ |____/|_|__,_|___|_|__|__, | .d$$ |_| 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Running in ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: See LICENSE and the LGPL-3.0 for licensing details. 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org 2019-11-19T21:43:00.540Z pid=17621 tid=gpiqiesdl INFO: Booting Sidekiq 6.0.3 with redis options {:id=>"Sidekiq-server-PID-17621", :url=>nil} 2019-11-19T21:43:00.543Z pid=17621 tid=gpiqiesdl INFO: Starting processing, hit Ctrl-C to stop

      Öffnen Sie ein zweites Terminalfenster, navigieren Sie zum Verzeichnis rails-sidekiq und starten Sie Ihren Anwendungsserver.

      Wenn Sie die Anwendung lokal ausführen, verwenden Sie den folgenden Befehl:

      Wenn Sie mit einem Entwicklungsserver arbeiten, führen Sie den folgenden Befehl aus:

      • bundle exec rails s --binding=your_server_ip

      Navigieren Sie im Browser zu localhost:3000 oder http://your_server_ip:3000. Sie sehen die folgende Startseite:

      Sidekiq App Home

      Klicken Sie auf die Which Sharks Are in Danger? Schaltfläche. Da Sie keine gefährdeten Sharks hochgeladen haben, wird Ihnen die Ansicht des gefährdeten Index gezeigt:

      Ansicht des gefährdeten Index

      Klicken Sie auf Import Endangered Sharks, um die gefährdeten Sharks zu importieren. Eine Statusmeldung teilt Ihnen mit, dass die Sharks importiert wurden:

      Import beginnen

      Sie sehen auch den Beginn des Imports. Aktualisieren Sie die Seite, um die gesamte Tabelle zu sehen:

      Tabelle aktualisieren

      Dank Sidekiq ist unser umfangreiches Batch-Upload der gefährdeten Sharks gelungen, ohne den Browser zu blockieren oder die Funktionsweise anderer Anwendungen zu beeinträchtigen.

      Klicken Sie auf die Schaltfläche Home unten auf der Seite, die Sie zur Hauptseite der Anwendung zurückbringen wird:

      Sidekiq App Home

      Klicken Sie hier erneut auf Which Sharks Are in Danger? . Damit gelangen Sie nun direkt zu der Ansicht data, da Sie die Haie bereits hochgeladen haben.

      Um die Löschfunktionalität zu testen, klicken Sie auf die Schaltfläche Delete Endangered Sharks unterhalb der Tabelle. Sie sollten nun erneut zu der Hauptseite der Anwendung umgeleitet werden. Wenn Sie ein letztes Mal auf Which Sharks Are in Danger? klicken, gelangen Sie zu der Ansicht index zurück, in der Sie die Option haben, die Haie erneut hochzuladen:

      Ansicht des gefährdeten Index

      Ihre Anwendung wird nun mit Sidekiq Workers ausgeführt, die zur Bearbeitung von Jobs bereit sind und sicherstellen, dass die Benutzer eine gute Erfahrung mit Ihrer Anwendung haben.

      Zusammenfassung

      Sie haben nun eine funktionierende Rails-Anwendung mit aktiviertem Sidekiq, die es Ihnen ermöglicht, kostspielige Operationen in eine von Sidekiq verwaltete und von Redis unterstützte Job-Warteschlange auszulagern. Dadurch können Sie die Geschwindigkeit und Funktionalität Ihrer Website im Laufe der Entwicklung verbessern.

      Wenn Sie mehr über Sidekiq erfahren möchten, sind die Docs ein guter Ausgangspunkt.

      Weitere Informationen über Redis finden Sie in unserer Bibliothek der Redis Ressourcen. Sie können auch mehr über die Ausführung eines verwalteten Redis-Clusters auf DigitalOcean erfahren, indem Sie sich die Produktdokumentation ansehen.



      Source link