Zizi blogja

Nginx

Nos, az nginx is felkerült az "én sosem akartam ezzel a szoftverrel foglalkozni, de tényleg" listára. Történet:

2020. augusztus 10.

Elindítottam egy gépen egy nginx-et:

[ec2-user@ip-10-84-140-12 ~]$ ps aux |egrep "nginx\:\ master"
root      3713  0.0  0.0 125616 12124 ?        Ss   Aug10   0:00 nginx: master process /usr/sbin/nginx

2020. augusztus 17.

Írtam egy ilyen nginx konfigot:

[ec2-user@ip-10-84-140-12 ~]$ ls -l /etc/nginx/sites/revproxy.conf
-rw-r--r-- 1 root root 312 Aug 17 12:00 /etc/nginx/sites/revproxy.conf
[ec2-user@ip-10-84-140-12 ~]$ cat /etc/nginx/sites/revproxy.conf
server {
  listen 127.0.0.2:443 ssl;
  server_name egyik-tokmindegy.az;
  ssl_certificate_key /etc/nginx/certs/egyik-tokmindegy.az.key;
  ssl_certificate /etc/nginx/certs/egyik-tokmindegy.az.pem;

  location / {
    proxy_pass https://masik-tokmindegy.az;
    proxy_ssl_server_name on;
  }
}

Faék egyszerűségű reverse proxy. Nincs benne semmi extra látnivaló.

2020. augusztus 18.

Reload-oltam az nginx konfigját:

[ec2-user@ip-10-84-140-12 nginx]$ ps aux |egrep "nginx\:\ (master|worker)"
root      3713  0.0  0.0 125564 11988 ?        Ss   Aug10   0:00 nginx: master process /usr/sbin/nginx
ec2-user 16375  0.0  0.0 125632  9636 ?        S    Aug18  13:12 nginx: worker process
ec2-user 16376  0.0  0.0 125568  9260 ?        S    Aug18   0:13 nginx: worker process
ec2-user 16377  0.0  0.0 125568  7576 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16378  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16379  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16380  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16381  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process
ec2-user 16382  0.0  0.0 125568  5708 ?        S    Aug18   0:00 nginx: worker process

Innentől élt a reverse proxy, boldogan használta mindenki.

2020. szeptember 3.

(Mindegy, hogy miért, nincs köze a problémához) módosítottam a masik-tokmindegy.az DNS bejegyzéseit, töröltem a hozzá tartozó AAAA rekordokat (hogy ne lehessen IPv6-on elérni).

2020. szeptember 17.

Elmúlik a reverse proxy boldog használata, a következő hibaüzenettel:

2020/09/17 15:39:49 [error] 16375#0: *2899915 connect() to [3a03:26f0:fb::5e62:9958]:443 failed (101: Network is unreachable) while connecting to upstream, client: 127.0.0.1, server: egyik-tokmindegy.az, request: "GET /x.jpg HTTP/1.0", upstream: "https://[3a03:26f0:fb::5e62:9958]:443/x.jpg", host: "egyik-tokmindegy.az"

Na, mi lehet a hiba oka? (Átírtam pár karaktert az IPv6-os IP-címben a logüzenetben, de a hiba nem ez.)

 

Hát persze, hogy az nginx a teljes FQDN-ként megadott proxy_pass direktívát restartkor, illetve reloadkor pontosan egyszer megpróbálja feloldani, és onnantól a következő restarting/reloadig a feloldott IP-ket cache-eli. A DNS TTL meg smafu. Meg az IP-cím váltás a target hoston is.

Ez nagyon béna.

Ráadásul a workaroundok (legyen egy változóként megadva az FQDN a proxy_pass-nak) is bénák, ugyanis csak akkor működnek, ha expliciten megadok resolver-t a konfigban, akkor viszont a /etc/hosts-ot nem használja az nginx a névfeloldásra, nekem meg az is kellene.

Ez nagyon-nagyon béna.

 

Na mindegy, régen írtam ide, csak ki akartam próbálni igazából az új editor, de nem tetszik :-)

Szavazás helyett...

A HUP-on szavazáshoz nem lehet hosszú dolgokat írni, pedig kíváncsi lennék, hogy mit gondoltok egy konkrét témáról. Tessék hát a kommentekben szavazni, először egy darab 0 és 10 közötti egész számmal, aztán jöhetnek a "megjegyzések". :-)

Az alábbiak között hány igaz állítás van?

1. A megbízható rendszerek sok esetben olcsó, nem megbízható komponensekből épülnek fel.
2. Az igazán nagy rendszereknél használt skálázási megoldások felhasználhatóak kisebb rendszerek skálázásához is.
3. Minél kockázatosabb egy üzemeltetési eljárás, annál gyakrabban érdemes végrehajtani.
4. A programok felhasználók számára láthatatlan funkciói sokszor kiemelten fontosak.
5. Jó üzemeltetési gyakorlat véletlenszerűen választott szervergépeket kikapcsolni.
6. Egy rendszer napi többszöri frissítése kevés emberi erőforrást igényel.
7. Ügyeletesnek lenni nem feltétlenül stresszes és kimerítő.
8. Jó üzemeltetési gyakorlat a szervergépeket nem monitorozni.
9. Az IT üzemeltetés és az IT menedzsment is végezhető a kísérletezés és a bizonyítás tudományos eszközeivel.
10. A Google készített üzletmenet-folytonossági tervet zombitámadás esetére.

Java választás

Ha már mostanában olyan felkapott téma lett a Java 11 - egy másik nézet. Még augusztusban írtam, van benne pár frissítés most.

Kellene új projekthez JDK-t választani. Enterprise környezet, security update-ek kellenek, mert különben változatos megfelelőségi problémáink lesznek. Jó lenne ingyen. A lehetőségek:

1. OpenJDK 8

- a Red Hat által jelenleg támogatott megoldás
- legalább 2020. októberig biztosan támogatott
- referencia: https://access.redhat.com/articles/1299013

2. OpenJDK 9-10

- a Red Hat nem támogatja és soha nem is fogja támogatni
- referencia: https://access.redhat.com/solutions/3204781