Moin!
Dass Du selbst gerne redest, wusste ich ja. Dass Du bei Schulung -
MANCHMAL - ETWAS - ausschweifst auch... aber dass Du auch solche
Fragenlisten stellst 😁
On 27.06.20 13:50, Martin Steigerwald wrote:
> Danke Dir nochmal für den Vortrag, Sven!
Gerne!
> Sodele, das funktioniert ja alles schon recht fein:
>
> luna:~> lxc-ls -fF name,state,ipv4,ram
> NAME STATE IPV4 RAM
> interntestalpine RUNNING 10.0.0.200 1.97MB
> interntestdevuan RUNNING 10.0.0.201 16.98MB
> rproxy RUNNING 10.0.0.1, […] 352.42MB
>
> (keine Ahnung, warum die leeren Test-Container noch weniger RAM brauchen
> als bei Dir, Sven)
Ich hatte noch einen OpenSSH-Server installiert, vermutlich deswegen.
Soll es schmaler sein, dann nimm dropbear, gibt dann aber kein Ed25519.
> [...]
> Der Reverse Proxy mit nginx-light – mal sehen ob das reicht – ist noch
> nicht fertig. Dem muss ich ja TLS-Zertifikate verpassen und mir irgendwie
> überlegen, Let's Encrypt nicht zu verwirren, wenn ich übergangsweise von
> zwei Hosts aus die gleichen Zertifikate anfordere… hmmm, ich könnte die
> temporär in den Container mit Bind-Mount einhängen. Naja, so oder so…
> erst mal ein bisschen überlegen, wie ich das alles angehe.
Entweder bind-mount. Oder als Hook im dehydrated nach einem neuen Cert
per rsync kopieren. Oder Du nimmst auf einer Seite zum TESTEN die
STAGING-API von Let's Encrypt.
> [...]
> Was von den: Was von den empfohlenen Paketen arch-test bridge-utils
> busybox-static cgroupfs-mount cloud-image-utils debootstrap distro-info
> dnsmasq-base genisoimage libidn11 liblxc1 libpam-cgfs lxc lxc-templates
> lxcfs qemu-utils uidmap uuid-runtime ist tatsächlich erforderlich?
>
> Ich hab mal cloud-image-utils genisoimage qemu-utils uuid-runtime
> rausgeschmissen und vermisse bislang nichts.
Im Host oder im Container? Muss ehrlich sagen, hab mich da auch schon
länger nicht mehr drum gekümmert. Alpine ist soo klein 😎...
> [Netz mit "none", "macvlan", Reverse Proxy]
Lasso, wenn der Container als Netz "none" hat, hat er kompletten Zugriff
auf das Host-Netzwerk, das stimmt schon - mit allen Vor- und Nachteilen.
Allerdings MUSS er ja das Netz auch nicht dekonfigurieren beim
Runterfahren. Aber ja, das hätte ich erwähnen sollen. Tjanu, Du wirst es
nicht mehr vergessen 😁
"macvlan" ist im Prinzip der Modus, wie VMware Workstation, VirtualBox &
Co. das ganze für ihre virtuellen Maschinen veranstalten. Ohne dass es
im Host zu sehen ist, werden zusätzliche MAC-Adressen ins Netz geschoben
bzw. angenommen. Vorteil: Keine Bridge im Host (und funktioniert mit
VMware nach "außen"). Nachteil: Man "sieht" die Interfaces der Container
nicht wirklich.
> Oder…… hmmm, ich könnte mit Paketfilter mit HTTP/HTTPS einfach SNAT/DNAT
> auf einen internen Container machen. Das wäre möglicherweise am
> einfachsten, weil das ganze Geschwurbel mit $LINUX-NETZWERK-
> SUPERSPEZIAL-FEATURE weg fällt. Je weniger ich am Netzwerk des Hosts
> rumbasteln muss, desto lieber ist mir das. So hab ich mir auch schon das
> SPICE-Protokoll von einem Proxmox VE hinter einem Gateway-Host
> weitergegeben.
Das war der dritte Weg, den ich vorgeschlagen hatte, ja. RevProxy im
Containert (vs. im Host). Funktioniert auch, netzwerkt nur auf der
internen Bridge rum.
Oder man nimmt einen rinetd oder sowas...
> Zu veth extern mit VMware ESX fand ich:
>
> https://www.claudiokuenzler.com/blog/556/network-connectivity-problem-lxc-in-vmware-vm-veth
Jup. Und
https://www.claudiokuenzler.com/blog/792/lxc-container-in-network-reachable-cannot-ping-between-host-and-container-veth-macvlan
und ich dachte, es gibt sogar noch 'nen dritten Artikel dazu.
> Und nach dem Lesen des Blogs habe ich entschlossen, da definitiv die
> Finger von zu lassen. PS: Da habe ich auch die Vorlage für meine nicht
> funktioniert MacVLAN-Konfiguration her.
Grundsätzlich funktioniert der Ansatz (zwei NICs, eine für den Host, die
anderen für die "macvlan" der Container). Hab das bei Kunden
(inzwischen) so laufen. Aber da war eben die Voraussetzung, dass die
Container IPs aus dem LAN bekommen. Sonst würde ich auch auf die interne
Bridge gehen.
> IPv6: Damit vielleicht etwas verbunden. Wie machst Du es mit IPv6? Wenn
> der Reverse Proxy Zugriff auf die IPv6-Adressen hat, dann dürfte es doch
> reichen, die internen Container mit IPv4 laufen zu lassen? Ich will
> natürlich, dass die Webseiten weiterhin ebenfalls über IPv6 erreichbar
> sind. Meine Idee ist, den Nginx auf einen anderem Port zunächst parallel
> hochzuziehen und auf die Seiten des bestehenden Apache-Webserver auf dem
> Host verweisen zu lassen. Dann kann ich das Zeug Schritt für Schritt in
> eigene Container umziehen.
Kommt drauf an 😝 Meistens ist der Host per IPv6 erreichbar, der Rest
via RevProxy und IPv4. Ansonsten statische IPv6-Vergabe, und dann
einzelne IPs routen - das geht auch mit (offiziellen) IPv4.
> Syslog: Auf der Devuan-Vorlage ist kein rsyslog. Macht das Sinn keinen
> Syslog-Server im Container zu haben? Mit /proc/kmsg hat rsyslog im
> Container ja nix zu suchen. Hmmm, käme darauf an, inwiefern ich einen
> Dienst nutze, der auf Syslog zurückgreift. Aber OpenSSH, das dies
> standardmäßig tut, soll in die (meisten) Container ja eh nicht rein.
Ich hab 'nen syslogd drin (meistens rsyslogd) und konfiguriere mir dann
per Ansible 💪 die Kernel-Messages da raus.
> Mail-Setup: Wie machst Du es, dass die Container Mail versenden können?
> Ich würde Postfix mit TLS und SMTP AUTH einrichten, aber geht das auch
> einfacher? Braucht es das? Ich lasse mir von meinen Servern via
> apticron, debsecan usw. Mails schicken. Ich denke, das würde ich auch
> gerne mit produktiven Containern so haben
Meistens läuft da ein Nullmailer, der die Mails einfach an einen
(zentralen) MX, manchmal auf der selben Kiste, manchmal direkt wo anders
hin, abliefert. Oder ein OpenSMTPd.
> Eigene Vorlage bauen? Wie mache ich das… kann ich einfach einen
> Container als Vorlage erstellen und davon klonen? Hmmm, selbst
> beantwortet: wohl ja, lxc-clone. Das unterstützt vielleicht sogar BTRFS-
> Snapshots. Natürlich hab ich BTRFS auf der Server-VM :). Idealerweise
> möchte ich mit LXC eine Vorlage habe, wo ich direkt loslegen kann. Also
> alle Basis-Sachen wie Mail usw. fertig eingerichtet sind. Oder
> irgendwann mal Ansible :)
Ansible 💪 😁
Ich hatte mal damit angefangen, dass ich mir eigene Images gebaut hab.
Und dann ging's wieder mit Security-Updates & Co. los. Dann hab ich das
sein lassen und mach nun echt so ziemlich alles per Ansible. Und für die
Puristen unter Euch: Man KÖNNTE das auch mit einem Shell-Script machen.
> Updates: Wie hältst Du die Container aktuell? Ich hab derzeit kein
> Monitoring für meine zwei virtuellen Maschinen. Da meine komplette Mail
> über die Maschine geht, wo jetzt auch LXC läuft, merke ich das schnell,
> wenn da mal was ist – bislang war da so gut wie nie was. Der andere ist
> eine reine Backup-VM, wo nur SSH und Borgbackup drauf laufen.
Ansible 💪 - Ja, ernsthaft. Bei mir sind's inzwischen einfach ZU viele
(virtuelle) Maschinen und da alles von Hand zu machen wäre irrsinnig
aufwändig. Wird spätestens alle 2 Tage aufgerufen und wenn dann mal
wegen eines Updates was nicht (mehr) geht, weiß ich wenigstens, wann ich
es kaputt gemacht habe (ja, KEINE unattended upgrades der Distri selbst).
> Ort für Container: Ich hab die Container via Symlink auf /srv/containers
> verlegt, unter anderem da /var auf der virtuellen Disk für das Host-
> Betriebssystem liegt. Kann ich das Haupt-Verzeichnis auf das LXC
> zugreift, standardmäßig /var/lib/lxc auch irgendwo in der Konfiguration
> anpassen? In den Konfigurationsdateien einzelner Container habe ich das
> gefunden. Ich kann natürlich auch alles über den Symlink gehen lassen.
Uff, ich glaub, das ging irgendwie. Hab es aber auch wegen
Einheitlichkeit jetzt immer da gelassen, eben zumindest als Link oder
(Bind-)Mount.
> TLS-Zertifikate: Nimmst Du dehydrated, Sven, oder mittlerweile was
> Anderes? Wenn was anderes, warum?
Dehydrated. Weil's rennt. Weil's unproblematisch ist. Weil es mit den
Hooks steuerbar ist. Weil es FÜR MICH die sinnvollste Lösung ist. Weil
ich in einem ACME-Tool keinen Web-Server brauche, WEIL DER JA EH AUF DER
KISTE LÄUFT, WO ICH DAS CERT BRAUCHE. Ok, bis auf dem Mail-Server. Oh!
Wait! Web-Mailer... also... doch überall 😉
Zum Spielen hab ich auch ein Setup mit haproxy und acme.sh - das tut
auch. Finde es letztendlich aber komplizierter, als $HTTPD plus dehydrated.
> Die TLS-Zertifikate müssdten dann ja auf den Reverse Proxy. Verwendest Du
> von Reverse Proxy zu Backend-Webserver HTTPS oder belässt Du es bei
> HTTP?
Ja (siehe letzten Abschnitt). Teils, teils - je nach Applikation. Und
bevor die Frage kommt: RevProxy ist bei mir nach wie vor meistens ein
Apache (mit mpm_event) - weil ich ständig seine weitergehenden Features
verwende. Daneben hab ich (wegen Projekten) noch haproxy (mit acme.sh)
und træfik (im Docker-Universum; macht ACME selbst) am laufen.
Bye
Sven
--
Leukämie → http://de.wikipedia.org/wiki/Leuk%C3%A4mie
Heilung → http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende
Typisierung → https://akb.de/online-registrierung/
https://zkrd.de/de/adressen/
Fragen? → sven@???
--
Mailing-Liste der Linux User Schwabach (LUSC) e.V.
Vor und beim Posten bitte
=> http://lusc.de/List-Netiquette <= und
=> http://lusc.de/List-Howto <= beachten. Danke!
(text/plain)