Obwohl es lange gedauert hat, bis ich motiviert war, habe ich schließlich mehrere persönliche Linux-Dienste containerisiert. Ich habe das Projekt in dieser Serie dokumentiert. In diesem Artikel führen wir Sie durch ein letztes Beispiel, Request Tracker.
Zu Beginn haben wir uns einige allgemeine Prinzipien für die Migration von Anwendungen in Container angesehen. Dann haben wir uns die Containerisierung von WordPress angesehen und als Nächstes darüber gesprochen, MediaWiki in einen Container zu verschieben. Dieses Projekt war ein bisschen komplizierter als das erste, mit der Hinzufügung der Aufgabenplanung. In diesem letzten Artikel werden wir eine viel komplexere Migration betrachten. Insbesondere sehen wir uns Request Tracker an. Dieser Dienst ist möglicherweise der kniffligste, da sowohl der Build als auch der Betrieb ziemlich ausgeklügelt sind.
Anmerkung des Herausgebers:Für die Zwecke dieses Artikels gehen wir davon aus, dass Sie Ihre Container auf Red Hat Enterprise Linux 8 mit podman build erstellen werden. Möglicherweise können Sie die Anweisungen für andere Distributionen oder mit anderen Toolchains verwenden, es können jedoch einige Änderungen erforderlich sein.
Nachverfolgung von Umzugsanfragen
Bauen
Im Gegensatz zu WordPress und MediaWiki, die auf einem einschichtigen Bild über einem Basisbild ausgeführt werden, verwendet Request Tracker zwei Ebenen über einem Basisbild. Sehen wir uns jede Ebene an und sehen wir uns an, warum wir es so gemacht haben.
Die erste Schicht ist ganz ähnlich aufgebaut wie httpd-php Bild. Dieses Bild fügt die erforderlichen Dienste für eine Perl-basierte Webanwendung hinzu. Wir schließen Apache, das FastCGI-Modul, Perl, MariaDB, Cron und einige grundlegende Dienstprogramme zur Fehlerbehebung ein:
FROM registry.access.redhat.com/ubi8/ubi-init
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y httpd mod_fcgid perl mariadb-server mariadb crontabs cronie iputils net-tools; yum clean all
RUN systemctl enable mariadb
RUN systemctl enable httpd
RUN systemctl enable postfix
RUN systemctl disable systemd-update-utmp.service
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
Auf der zweiten Ebene werden die Dinge ziemlich anspruchsvoll. Request Tracker verwendet viele Perl-Module von CPAN. Viele dieser Module werden mit gcc kompiliert und die Installation dauert lange. Es hat auch viel Arbeit gekostet, all diese Abhängigkeiten festzunageln, damit Request Tracker erfolgreich installiert werden kann. Früher hätten wir das irgendwo in einem Skript festgehalten, aber mit Containern können wir alles in einer Containerdatei haben. Es ist sehr bequem.
[Das könnte Ihnen auch gefallen: 6 Leitfäden zum Sichern von Containern]
Das nächste, was Sie an dieser Datei bemerken sollten, ist, dass es sich um einen mehrstufigen Build handelt. Podman und Buildah können absolut mehrstufige Builds durchführen und sie können für Anwendungen wie Request Tracker äußerst nützlich sein. Wir hätten in Verzeichnissen bind-mounten können, wie wir es bei WordPress und MediaWiki getan haben, aber wir haben uns stattdessen für einen mehrstufigen Build entschieden. Dies gibt uns Portabilität und Geschwindigkeit, wenn wir die Anwendung woanders neu erstellen müssen.
Mehrstufige Builds können als Erfassung des Entwicklungsservers und des Produktionsservers in einer einzigen Build-Datei betrachtet werden. Entwicklungsserver waren in der Vergangenheit am schwierigsten zu automatisieren. Seit den Anfängen von CFEngine Mitte der 1990er Jahre weigerten sich Entwickler, die Versionskontrolle zu verwenden, und fügten Entwicklungsservern alles hinzu, was sie wollten, damit sie funktionieren. Oft wussten sie nicht einmal, was sie hinzugefügt hatten, um einen Build zu vervollständigen. Dies war eigentlich vernünftig, wenn Sie langlebige Server hatten, die gut gesichert waren, aber es verursachte immer Ärger, wenn Systemadministratoren „den Entwicklungsserver aktualisieren“ mussten. Es war ein Albtraum, Builds auf einem brandneuen Server mit einem frischen Betriebssystem zum Laufen zu bringen.
Bei mehrstufigen Builds erfassen wir alle Build-Anweisungen und sogar Cache-Layer, die erstellt werden. Wir können diesen virtuellen Entwicklungsserver an jedem beliebigen Ort neu aufbauen.
FROM registry.access.redhat.com/ubi8/ubi-init
FROM localhost/httpd-perl AS localhost/rt4-build
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y expat-devel gcc; yum clean all
RUN cpan -i CPAN
RUN cpan -i -f GnuPG::Interface
RUN cpan -i DBIx::SearchBuilder \
ExtUtils::Command::MM \
Text::WikiFormat \
Devel::StackTrace \
Apache::Session \
Module::Refresh \
HTML::TreeBuilder \
HTML::FormatText::WithLinks \
HTML::FormatText::WithLinks::AndTables \
Data::GUID \
CGI::Cookie \
DateTime::Format::Natural \
Text::Password::Pronounceable \
UNIVERSAL::require \
JSON \
DateTime \
Net::CIDR \
CSS::Minifier::XS \
CGI \
Devel::GlobalDestruction \
Text::Wrapper \
Net::IP \
HTML::RewriteAttributes \
Log::Dispatch \
Plack \
Regexp::Common::net::CIDR \
Scope::Upper \
CGI::Emulate::PSGI \
HTML::Mason::PSGIHandler \
HTML::Scrubber \
HTML::Entities \
HTML::Mason \
File::ShareDir \
Mail::Header \
XML::RSS \
List::MoreUtils \
Plack::Handler::Starlet \
IPC::Run3 \
Email::Address \
Role::Basic \
MIME::Entity \
Regexp::IPv6 \
Convert::Color \
Business::Hours \
Symbol::Global::Name \
MIME::Types \
Locale::Maketext::Fuzzy \
Tree::Simple \
Clone \
HTML::Quoted \
Data::Page::Pageset \
Text::Quoted \
DateTime::Locale \
HTTP::Message \
Crypt::Eksblowfish \
Data::ICal \
Locale::Maketext::Lexicon \
Time::ParseDate \
Mail::Mailer \
Email::Address::List \
Date::Extract \
CSS::Squish \
Class::Accessor::Fast \
LWP::Simple \
Module::Versions::Report \
Regexp::Common \
Date::Manip \
CGI::PSGI \
JavaScript::Minifier::XS \
FCGI \
PerlIO::eol \
GnuPG::Interface \
LWP::UserAgent >= 6.02 \
LWP::Protocol::https \
String::ShellQuote \
Crypt::X509
RUN cd /root/rt-4.4.4;make testdeps;make install
# Deploy
FROM localhost/httpd-perl AS localhost/rt:4.4.4
RUN yum install -y postfix mailx;yum clean all
COPY --from=localhost/rt4-build /opt/rt4 /opt/rt4
COPY --from=localhost/rt4-build /usr/lib64/perl5 /usr/lib64/perl5
COPY --from=localhost/rt4-build /usr/share/perl5 /usr/share/perl5
COPY --from=localhost/rt4-build /usr/local/share/perl5 /usr/local/share/perl5
COPY --from=localhost/rt4-build /usr/local/lib64/perl5/ /usr/local/lib64/perl5/
RUN chown -R root.bin /opt/rt4/lib;chown -R root.apache /opt/rt4/etc
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]
In der zweiten Phase dieses mehrstufigen Builds wird der virtuelle Produktionsserver erstellt. Indem wir dies in eine zweite Stufe aufteilen, müssen wir keine Entwicklungstools wie gcc installieren oder expat-devel im endgültigen Produktionsbild. Dies reduziert die Größe unseres Images und reduziert die Größe der Software-Lieferkette in netzwerkexponierten Diensten. Dies verringert möglicherweise auch die Wahrscheinlichkeit, dass jemand etwas Böses mit unserem Container anstellt, falls er sich einhacken sollte.
Wir installieren nur die E-Mail-Dienstprogramme in dieser zweiten Phase, die die zweite Schicht unseres Produktionsabbilds für Request Tracker definiert. Wir hätten diese Dienstprogramme auch in httpd-perl installieren können Layer, aber viele andere Perl-Anwendungen benötigen keine Mail-Dienstprogramme.
Ein weiterer Vorteil mehrstufiger Builds besteht darin, dass wir nicht jedes Mal all diese Perl-Module neu erstellen müssen, wenn wir den Perl-Interpreter, Apache oder MariaDB für Sicherheitspatches aktualisieren möchten.
Laufen
Schauen wir uns nun, wie bei WordPress und MediaWiki, einige der Tricks an, die wir zur Laufzeit verwenden:
[Unit]
Description=Podman container – rt.fatherlinux.com
Documentation=man:podman-generate-systemd(1)
[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --rm --read-only -p 8081:8081 --name rt.fatherlinux.com \
-v /srv/rt.fatherlinux.com/code/reminders:/root/reminders:ro \
-v /srv/rt.fatherlinux.com/config/rt.fatherlinux.com.conf:/etc/httpd/conf.d/rt.fatherlinux.com.conf:ro \
-v /srv/rt.fatherlinux.com/config/MyConfig.pm:/root/.cpan/CPAN/MyConfig.pm:ro \
-v /srv/rt.fatherlinux.com/config/RT_SiteConfig.pm:/opt/rt4/etc/RT_SiteConfig.pm:ro \
-v /srv/rt.fatherlinux.com/config/root-crontab:/var/spool/cron/root:ro \
-v /srv/rt.fatherlinux.com/config/aliases:/etc/aliases:ro \
-v /srv/rt.fatherlinux.com/config/main.cf:/etc/postfix/main.cf:ro \
-v /srv/rt.fatherlinux.com/data/mariadb:/var/lib/mysql:Z \
-v /srv/rt.fatherlinux.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/rt.fatherlinux.com/data/logs/rt4:/opt/rt4/var:Z \
-v /srv/rt.fatherlinux.com/data/backups:/root/.backups:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
--tmpfs /var/spool \
--tmpfs /var/lib \
localhost/rt:latest
ExecStop=/usr/bin/podman stop -t 3 rt.fatherlinux.com
ExecStopAfter=/usr/bin/podman rm -f rt.fatherlinux.com
Restart=always
[Install]
WantedBy=multi-user.target Wie bei MediaWiki sind alle Konfigurationsdateien schreibgeschützt eingebunden, was uns ein solides Sicherheits-Upgrade bietet. Schließlich sind die Datenverzeichnisse schreibgeschützt, genau wie unsere anderen Container. Eine einfache Beobachtung:Wir haben immer noch Code für Erinnerungen in das Bild eingebunden , bei dem es sich um einen kleinen, selbst entwickelten Satz von Skripten handelt, die E-Mails senden und Tickets für wöchentliche, monatliche und jährliche Einträge generieren.
Weitere Analyse
Lassen Sie uns ein paar letzte Themen angehen, die nicht spezifisch für einen unserer containerisierten Linux-Dienste sind.
Wiederherstellbarkeit
Die Wiederherstellbarkeit ist etwas, das wir sorgfältig prüfen müssen. Durch die Verwendung von systemd , erhalten wir eine solide Wiederherstellbarkeit, die mit regulären Linux-Diensten vergleichbar ist. Beachten Sie systemd startet meine Dienste neu, ohne mit der Wimper zu zucken:
podman kill -a
55299bdfebea23db81f0277d45ccd967e891ab939ae3530dde155f550c18bda9
87a34fb86f854ccb86d9be46b5fe94f6e0e15322f5301e5e66c396195480047a
C8092df3249e5b01dc11fa4372a8204c120d91ab5425eb1577eb5f786c64a34b Sieh dir das an! Dienste neu gestartet:
podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
33a8f9286cee localhost/httpd-php:latest /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:80->80/tcp wordpress.crunchtools.com
37dd6d4393af localhost/rt:4.4.4 /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:8081->8081/tcp rt.fatherlinux.com
e4cc410680b1 localhost/httpd-php:latest /sbin/init 1 second ago Up Less than a second ago 0.0.0.0:8080->80/tcp learn.fatherlinux.com Tipps und Tricks
Dies ist sehr nützlich, um Änderungen an der Konfigurationsdatei vorzunehmen. Wir können einfach die Konfigurationsdatei auf dem Containerhost bearbeiten oder etwas wie Ansible verwenden und alle Container mit podman kill -a beenden Befehl. Weil wir systemd verwenden , wird es den Neustart der Dienste problemlos handhaben. Das ist sehr praktisch.
Es kann schwierig sein, Software in einem Container auszuführen, insbesondere wenn Sie möchten, dass sie schreibgeschützt ausgeführt wird. Sie schränken den Prozess auf eine Weise ein, auf die er nicht unbedingt ausgelegt war. Daher hier einige Tipps und Tricks.
Zunächst ist es hilfreich, einige Standarddienstprogramme in Ihren Containern zu installieren. In dieser Anleitung haben wir ip-utils installiert und net-tools damit wir Fehler in unseren Containern beheben können. Zum Beispiel musste ich mit Request Tracker den folgenden Eintrag in /etc/aliases beheben , das Tickets aus E-Mails generiert:
professional: "|/opt/rt4/bin/rt-mailgate --queue 'Professional' --action correspond --url http://localhost:8081/"
Die Werkzeuge curl , ping und netstat waren alle äußerst nützlich, da wir auch externes DNS und Cloudflare verwenden.
Als nächstes kommt podman diff , die ich ausgiebig zum Ausführen von Containern als schreibgeschützt verwendet habe. Sie können den Container im Lese-Schreib-Modus ausführen und podman diff ständig überprüfen um zu sehen, welche Dateien sich geändert haben. Hier ist ein Beispiel:
podman diff learn.fatherlinux.com
C /var
C /var/spool
C /var/spool/cron
A /var/spool/cron/root
C /var/www
C /var/www/html
A /var/www/html/learn.fatherlinux.com
C /root
A /root/.backups Wechsel zu Kubernetes
Beachten Sie, dass Podman uns mitteilt, welche Dateien sich seit dem Start des Containers geändert haben. In diesem Fall befindet sich jede Datei, die uns wichtig ist, entweder auf einem tmpfs- oder einem Bind-Mount. Dadurch können wir diesen Container schreibgeschützt ausführen.
Ein genauer Blick auf Kubernetes ist ein natürlicher nächster Schritt. Verwenden Sie einen Befehl wie podman generate kube wird uns einen Teil des Weges dorthin bringen, aber wir müssen noch herausfinden, wie persistente Volumes und Backups auf diesen persistenten Volumes verwaltet werden. Für den Moment haben wir entschieden, dass Podman + systemd bietet eine schöne Grundlage. All die Arbeit, die wir mit der Aufteilung des Codes, der Konfiguration und der Daten geleistet haben, ist erforderlich, um uns zu Kubernetes zu bringen.
Hinweise zur Umwelt
Meine Umgebung ist eine einzelne virtuelle Maschine, die bei Linode.com mit 4 GB RAM, zwei CPUs und 80 GB Speicher läuft. Ich konnte mein eigenes benutzerdefiniertes Image von RHEL 8 hochladen, um als Container-Host zu dienen. Außer dem Festlegen des Hostnamens und dem Weiterleiten von DNS über Cloudflare musste ich wirklich keine weiteren Änderungen am Host vornehmen. Alle wichtigen Daten befinden sich in /srv , was den Austausch im Falle eines Ausfalls extrem einfach machen würde. Schließlich der /srv Verzeichnis auf dem Container-Host vollständig gesichert.
Wenn Sie daran interessiert sind, sich die Konfigurationsdateien und die Verzeichnisstruktur von /srv anzusehen , ich habe den Code hier in meinem GitHub gespeichert.
Vorurteile
Wie jeder habe ich Vorurteile, und ich denke, es ist fair, sie offenzulegen. Bevor ich zu Red Hat kam, war ich einen Großteil meiner Karriere als Linux-Systemadministrator tätig. Ich habe eine Vorliebe für Linux und insbesondere für Red Hat Enterprise Linux. Ich neige auch zur Automatisierung und der Psychologie, wie man diesen Automaten regelmäßigen Mitwirkenden zugänglich macht.
Eine meiner frühesten Frustrationen als Systemadministrator war die Arbeit in einem Team mit 1000 Linux-Webservern (die eCards in Web 1.0 machten), wo die Dokumentation darüber, wie man zur Automatisierung beitragen kann, völlig undurchsichtig war und keine Begründung dafür dokumentiert wurde, warum die Dinge so waren, wie sie waren . Wir hatten eine großartige Automatisierung, aber niemand hat sich Gedanken darüber gemacht, wie man neue Leute daran heranführt. Es war sinken oder schwimmen.
Dieser Blog soll den Menschen helfen, diesen Buckel zu überwinden, und ihn gleichzeitig fast selbstdokumentierend machen. Ich denke, es ist von entscheidender Bedeutung, die menschlichen Eingaben und Roboterausgaben der Automatisierung zu berücksichtigen. Siehe auch:Bootstrapping- und Rooting-Dokumentation:Teil 1
[Kostenloser Spickzettel:Kubernetes-Glossar]
Schlussfolgerung
Es scheint so einfach, einen gemeinsamen Dienst wie WordPress in Container zu verschieben, aber das ist es wirklich nicht. Die in diesem Artikel skizzierte flexible und sichere Architektur mobilisiert die Fähigkeiten eines erfahrenen Linux-Administrators oder -Architekten, um von einem regulären LAMP-Server zu OCI-kompatiblen Containern zu wechseln. In diesem Leitfaden wurde eine Container-Engine namens Podman genutzt und gleichzeitig Ihre Dienste für Kubernetes vorbereitet. Die Trennung von Code, Konfiguration und Daten ist ein erforderlicher Schritt für den Wechsel zu Kubernetes. Alles beginnt mit soliden, grundlegenden Linux-Kenntnissen.
Einige Entscheidungen, die in diesem Artikel hervorgehoben werden, stellen gezielt verschiedene Missverständnisse innerhalb der Container-Community in Frage – Dinge wie die Verwendung von systemd in einem Container oder die Konzentration auf das kleinste Basis-Image, das Sie finden können, ohne auf die gesamte Software-Lieferkette zu achten. Das Endprodukt ist jedoch einfach zu verwenden. Es bietet einen Arbeitsablauf, der einem herkömmlichen LAMP-Server ziemlich ähnlich ist, und erfordert eine minimale kognitive Belastung für herkömmliche Linux-Systemadministratoren.
Einige der in diesem Artikel getroffenen Designentscheidungen sind Kompromisse und unvollkommen. Trotzdem habe ich sie gemacht, weil ich sowohl den Druck einer modernen DevOps-Kultur als auch die Psychologie von Betriebs- und Entwicklungsteams verstehe. Ich wollte die Flexibilität bieten, um mehr Wert aus Containern zu ziehen. Dieser Satz von Diensten sollte als Modell für die Migration vieler Ihrer eigenen Dienste in Container nützlich sein. Dies vereinfacht ihre Verwaltung, Aktualisierung und Wiederherstellung. Dies hilft nicht nur bestehenden Linux-Administratoren, sondern auch zukünftigen Kohorten, die diese Dienste erben werden, einschließlich der zukünftigen Version von mir, die alle Details vergessen haben wird. Diese containerisierten Dienste sind im Wesentlichen selbstdokumentierend in einem Stil, der einer erfolgreichen DevOps-Kultur förderlich ist.
Diese Serie basiert auf "A Hacker's Guide to Moving Linux Services into Containers" auf CrunchTools.com und wird mit Genehmigung neu veröffentlicht.