Virtualizáció

Hasznal valaki PBS-t kazettas egyseggel? Sajna eleg keves info van rola (=csak a sajat doksija). Es van par dolog ami nem egyertelmu:

 - A media pool/mediaset mukodese nem egeszen tiszta
 - az inventory es "content" infokat is kiirja a kazira, vagy azokat kulon menteni kene, hogy meglegyen ha a baltasgyilkos elviszi a pbs gepet?

Olyat szertnek, hogy van ket kazetta, felvaltva lenne havonta berakva az egysegbe, es folyamatosan tovabbirva (tehat nem felulirva) kerulne ki ra a heti mentes. archiv jelleggel meglenne minden backup az osrobbanastol kezdve :)

Üdv,

Fc37-ben egy Dockerfile-ben megadtam:

VOLUME /app

Build megvan, futtatás:

podman run -it -p 8000:8000 --name myapp --hostname myapp fedora:myapp -v $(pwd)/app:/app

# vagy

podman run -it -p 8000:8000 --name myapp --hostname myapp fedora:myapp --mount='type=bind,source=$(pwd)/app,destination=/app'

 A $(pwd)/app nem mountolódik fel a konténer /app könyvtárába. Üres marad. Mit rontok el? Mi lenne a helyes megoldás? https://docs.podman.io/en/latest/markdown/options/mount.html

Sziasztok!

Eddig nem nagyon kellett az ipv6, de lassan megkerülhetetlen lesz. Gondoltam felhúzok pár ipv6-os címet és el is kezdhetjük használni.
Amibe rögtön beleszaladtam (7.2-11 és 7.0-13 alatt is):
Ha úgy veszem fel az ip címet, hogy az mögött nincs valós csatoló, akkor nem működik.
Magyarán:
Ha a vmbr0 úgy van beállítva, hogy

ipv4: 1.2.3.4/24
átjáró: 4.3.2.1
Bridge ports: eth0
ipv6: 1001:1001:0:1001::2/64
átjáró: 1001:1001:0:1001::1

Akkor ok, az 1.2.3.4 és az  1001:1001:0:1001::2 is pingelhető, elérhető

Ha viszont felveszek egy vmbr1-et így:

ipv4: 1.2.3.5/24
átjáró:
Bridge ports:
ipv6: 1001:1001:0:1001::3/64
átjáró:

Akkor az 1.2.3.5 működik, a 1001:1001:0:1001::3 viszont nem.

Mit baltázok el?

Köszi!

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.