Virtualizáció

Pod nem hajlandó felkapni az IAM jogait:

- van 1 IAM policy, szépen beállítva az objectekre (amúgy S3, DynamoDB és Kinesis),
- van hozzá 1 role ezekkel,
- van 1 K8S cluster, csomó más futó xarral,
- csinálok 1 deploy-t, ugat az app, h nincs joga ide meg oda,
- ugyanez a takony EC2-ben docker compose-zal simán működik, ugyanezen jogokkal, ha az EC2 instanc-ra ráteszem az említett IAM role-t.

Mondjuk amúgy Helm, nem sima kube, de ez most mind1. Helm megcsinálja a service account-ot, deploy-ban is meg van mondva. A nyüves annotation is megvan. Jól rendereli a Helm is, az megy ki, amit gondolok, h kimegy.

Mind3 értelmes howto-t, tutorial-t elolvastam, minden jó. 1 napom van a dologra. Valami ötlet? vmi triviális dolog? (nem tudok ilyenolyan konfigot idedobni, mert nem tudok, mondom: Helm, serviceaccount, IAM oldalon servicerole a mocskos kis policy-jaival, egész kerek.

??? Bármimás ???

Na ha már benne vagyok feldobom ezt a témát is, kíváncsi vagyok látott-e már valaki ilyet: Upgradeltem a szerverembe hálókártyát, jó áron sikerült hozzájutni egy Intel X710-DA4-hez, ami egy Intel X520-DA1 -et váltott. A host OS Win2022. Az új kártyán egyelőre csak egy port aktív, címe ugyanaz mint az előző kártyának. A kártyacserét leszámítva, és az új adapteren történő régi IP cím visszaállításon kívül semmiféle konfigurálás nem történt.
Legújabb Intel driver telepítve.

A host-on VMWare Workstation, benne fut jó néhány, de csak 4 aktívan használt Debian/Ubuntu VM. Amelyek bármelyikében ha kiadok egy ping parancsot mondjuk a google.com-ra akkor kérésenként 3 válasz érkezik. (A VM-ek network adapterei bridge-elve vannak host fizikai adapterével, tehát az X710 egyik portjával).  Előtte ilyen probléma nem volt. Ha a host-on engedélyezem a "Routing and Remote Access" szolgáltatást, majd letiltom, a probléma megszűnik (De csak így sikerül megszüntetni, nem számít hogy előtte engedélyezve volt-e a szolgáltatás vagy sem) Igen ám, de ezzel gyakorlatilag megszűnik a routing is a host alatt. Így a host alá telepített OpenVPN szerver is használhatatlan lesz. (Az OpenVPN-hez egyébként nem kell az említett szolgáltatás, ha a registry-ben engedélyezve van az IPEnableRouter már működik, viszont a routing szolgáltatás engedélyezése és letiltása ezt kikapcsolja).

A probléma egyébként ismert:
https://thedatamachine.wordpress.com/2019/12/26/vmware-workstation-dup-packet-issue-resolved-sort-of/
https://communities.vmware.com/t5/VMware-Workstation-Pro/Duplicate-packets-with-ping-on-guest-O-Linux/td-p/2029093

Valós megoldást nem sikerült találni. Tehát vagy van routing a host alatt és jönnek a tripla ICMP packetek a VM-ekben, vagy nincs routing (így VPN sem) és a VM-ekben is minden jó. Próbáltam a nem használt adaptereket letiltani, winsock resetet, az adapter összes portját, semmivel nem sikerült változást előidézni.

Üdv,

A Cloud Run-ban ha kérés érkezik, akkor indít egy konténert egy adott image-ből (Container Registry -> Images). Adott idő után megszünteti a konténert. (Gondolom: dokcer run -rm ....)

Teszt jelleggel használom, de jó volna hogy a konténer megtartsa az állapotát, pontosabban az adatbázis ne vesszen el (python django sqlite3).

Van erre elegáns megoldás? Vagy mit kellene beállítani?

Üdv,

Adott egy python/django teszt projekt, lokálisan minden működik, viszont a Github Actions nem. A .yml fájl:

name: cloudrun-deploy-production
on:
  push:
    branches:
      - main
jobs:
  build:
    name: 'Cloud Run Production Deployment'
    runs-on: ubuntu-latest
    steps:
      - name: 'Checkout'
        uses: actions/checkout@master

      - name: 'Setup GCP Service Account'
        # uses: google-github-actions/setup-gcloud@main
        uses: google-github-actions/setup-gcloud@v1
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_SERVICE_ACCOUNT_SECRET }}
          export_default_credentials: true

      - name: 'Configure Docker'
        run: make gcloud-docker-init

      - name: 'Build'
        env:
          GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
          ENVIRONMENT: 'production'
        run: make gcloud-docker-build

      - name: 'Push'
        env:
          GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
          ENVIRONMENT: 'production'
        run: make gcloud-docker-push

      - name: 'Deploy'
        env:
          GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
          ENVIRONMENT: 'production'
        run: make gcloud-run-deploy

A make ... parancsok lokálisan mind lefutnak.

Valószínű régi GA "sablont" használok. Mit kellene korrigálni?

A GA logban ilyesmi látszódik:

Setup GCP Service Account:
--------------------------
Warning: Unexpected input(s) 'service_account_key', 'export_default_credentials', valid inputs are ['version', 'project_id', 'install_components']
Run google-github-actions/setup-gcloud@v1
  with:
    project_id: ***
    service_account_key: ***
  
    export_default_credentials: true
    version: latest

/usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C /home/ru..............

Warning: No authentication found for gcloud, authenticate with `google-github-actions/auth`.
Successfully set default project


...


Push:
-----
unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
make: *** [Makefile:51: gcloud-docker-push] Error 1
Error: Process completed with exit code 2.

Teszt jelleggel a service account-nek ilyen permissionjai vannak:

Cloud Build Editor, Cloud Build Service Account, Cloud Run Admin, Container Registry Service Agent, Service Account User

A "service_account_key" nem tetszik neki?

Üdv,

Adott egy podman konténer, amiben egy mariadb,apache,PHP fut.

Inditom a konténert, szépen működik is, de egy kis idő után timeout lesz. Pedig azt látom, hogy fut.

Igaz furcsa, hogy ránézve azt látom a konténeren, hogy "Up 3s ago...". Mintha újraindulna...?

Mi lehet a gond?

Sziasztok!

Proxmox 7-ben Container létrehozásakor a webes felületen alapértelmezésben be van pipálva a Nesting. Az Linux Container - Proxmox VE oldalon szereplő leírás szerint a nesting=0 alapértelmezett értékkel rendelkezik. Olvasgattam további leírásokat is de elbizonytalanodtam, hogy szükséges-e bejelölve hagyni a Nesting-et.

1. Ha a Proxmox-on létrehozandó Linux Container-ben nem akarok Docker-t és további (Linux) konténereket futtatni (csak egy standard Debian 11-es webszervert), akkor jól olvastam ki a leírásokból, hogy fölösleges engedélyeznem a nesting-et egy Proxmox Container-ben?
2. Ha mégis bekapcsolom a nesting-et a Proxmox Container-ben, és megtörik a benne futó webszervert, akkor hozzáférhetnek a Proxmox host-hoz is?

Került hozzám egy projekt aminek javítani szeretnék a költséghatékonyságán. Ebben lenne jó egy picit együtt gondolkodni, meg tippeket is szívesen vennék.

Az a felállás, hogy ügyfelenként van egy Windows IIS szerveren futó webszolgáltatás, amit egy Linuxon futó MariaDB szolgál ki.

Minden AWS-en fut, de alapvető AWS szolgáltatásokat sem használnak, csak EC2-kön fut minden, közvetlenül telepítve, még konténerek sincsenek.

Az ügyfelek semmiféleképpen nem férhetnek hozzá egymás adataihoz, ezért minden ügyfélnek van egy külön Windows IIS és egy külön Linux EC2-je, bezárva a saját pici subnetjükbe. És ebből lassan 100 darab, ami ugye 200 EC2-t jelent.

Ez így szerintem nem jó hatékonyságú üzemeltetés. Sajnos az RDS nem opció momentán, mert a kereséshez fut egy indexelő szolgáltatás aminek a storage engine-e nem támogatott.

Arra gondoltam, hogy felhúznék a sok linuxos EC2 helyett egy EKS clustert. Arra felhúznék MariaDB konténereket, mellé az indexelő szolgáltatás konténerét, külön StatefulSettel és külön PVC-el mindegyik ügyfélnek. A Windowsos IIS-ek maradnának úgy ahogy, mert egyelőre nem konténerizálhatóak, csak átírnám a DB címét az új végpontokra. Ha jól sejtem NodePort-tal külön portra lehetne tenni mindegyik MariaDB konténert.

Van-e ebben a tervben valami nyilvánvalóan nagy buktató amire nem gondoltam?

Úgy gondolom, a Kubernetes segíthetne egy kicsit a hatékonyágon ebben a felállásban. Éjszaka, mikor nincs nagy terhelés, elég gondolom néhány node a ~100 DB konténerhez, nappal meg fel tudna húzni új nodeokat mikor nagyobb a forgalom. Másrészt meg a sok külön EC2-nek kezd elszállni az adminisztációs overheadje, mindet patchelni, monitorozni, backupolni, stb. külön-külön, nagyon szarul skálázódik.

Harmadrészt meg az IIS-függő webapp is átírás alatt van már multiplatform dotnetre, amit egyszer majd reményeim szerint szintén át lehetne tenni az EC2-kről Kubernetesre.

Sziasztok!

Van egy Proxmox 6.2-6.3 clusterem, 6 node-ból áll, évek óta működik hibátlanul. Most teljesen véletlenül vettem észre, hogy az egyik node a mentéseknél csak 1 példányt tart meg, holott a Storage beállításainál keep-last=2 szerepel. De teljesen mindegy, hogy ezt a számot hová állítom, mindig csak egy darab mentésem marad. A többi node szépen működik a beállításnak megfelelően, megtartja az előző mentést is, így azokon 2 példány marad.

Ha manuálisan ráindítok egy backupot, akkor a következő hibaüzenetet hazudja:

INFO: starting new backup job: vzdump 701 --compress zstd --storage ISZONAS-VZDUMP --mode snapshot --node px7 --remove 0
ERROR: Backup of VM 701 failed - There is a max backup limit of (1) enforced by the target storage or the vzdump parameters. Either increase the limit or delete old backup(s).

Van esetleg ötlete valakinek, hogy milye lehet beakadva annak az egy node-nak?

Köszönöm az ötleteket!

Üdv,

Éles környezetben is átirányítjatok a portokat? (NAT alapján lát ki a konténer a külső hálózatba.)

Vagy milyen hálózat beállításokat használtok?

Üdv,

Egy image buildelésekor szeretnék létrehozni egy mariadb adatbázist (van is rá egy dbscript.sh scriptem). Hogyan érdemes ezt a Dockerfile-be beírni?

Valahogy el kellene indítani a mariadbd-t, hogy a script lefuttatható legyen.

# Dockerfile
# ....

RUN mariadb-install-db
RUN /usr/sbin/mariadbd -u root               # <-- előtérben fut, nem megy tovább a következő lépésre
RUN /tmp/dbscript.sh mydbname username password

# ...
ENTRYPOINT /usr/bin/supervisord -c /etc/supervisord.conf

Háttérben kellene indítani a mariadbd-t, mert addig nem megy tovább. Az elegáns, helyes megoldást keresem.

Van ötletetek?