• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    píšu helm charty a potřebuju názory.

    v podstate porad se v helmu opakuje named list

    nejakeJmeno:
      - polozka
      - druha
    ...

    a je moznost to delat pres pojmenovanou template a include
    akorat to volani mi prijde zase takovy nesikovny v tom, ze tomu musim predat spoustu parametru a je to jak volani win32 api,

    vypada to nejakj takhle
    {{ include "common.printNamedList" ( dict "name" "dnsDomains" "items" .context.nameConstraints.permitted.dnsDomains "indent" "6" "quote" true ) }}

    protoze mu musim predat
    - jmeno listu,
    - jeho obsah,
    - indent a
    - jestli musi polozky dat do uvozovek

    a to uz je trochu neprehledny

    implementace je naopak docela v poho
    {{- define "common.printNamedList" }}
    {{- $items := .items }}
    {{- $name := .name }}
    {{- $indent := ( .indent | int ) }}
    {{- $quote := .quote }}
    {{ printf "%s:" $name | indent $indent }}
    {{- range $val := .items }}
    {{- if ( eq $quote true )  }}
    {{ printf "- \"%s\"" $val | indent $indent }}
    {{- else }}
    {{ printf "- %s" $val | indent $indent }}
    {{- end }}
    {{- end }}
    {{- end }}
    me na tom odrazuje to volani, protoze jsou to ctyri parametry a to je proste uz neprehledny a blbe zapamatovatelny
    a sice usporim par radek, ale ve vysledku vlastne mi prijde ze ten overhead s parametry a dict je docela nesikovnej

    a kdybyste nekdo meli nejaky lepsi napad, tak sem s nim
    VELDRANE
    VELDRANE --- ---
    VELDRANE: tak se pochvalim sam, nakonec ovn-kubernetes rozchozeno pres cisty kubeadm. Hodne casu sem vytuh na osklive, zle nepekne veci v novejsich k8s, kdy pri vytvoreni service accountu se jiz defaultne nevytvari prislusnej secret token (coz si tak rikam, k cemu to sa pak tedy vlastne je).
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    VELDRANE: bohužel. máme calico.
    VELDRANE
    VELDRANE --- ---
    Hola, je tu nejaky masochista kteremu se povedlo rozchodit ovn-kubernetes na vanilla k8s ? Potrejuju pro testovani a nechci instalovat plnotucne okd
    JFM
    JFM --- ---
    MLEKAR_STEIN: Děkuji velice za hint, pomohlo. Už jsem to vyřešil.
    K HTTPS webu v kontejneru je potřeba přistupovat jako k TCP službě a použít TCP router.
    Aby mohli uživatelé používat více takových služeb a rozlišovat je různými FQDN, musí se použít v routeru pravidlo HostSNI.
    Takové pravidlo lze použít pouze u routerů se zapnutým TLS, ale pak je klíčové použít parametr passthrough.
    Entrypoint mám v traefik.toml definovaný běžným způsobem:
    [entryPoints]
      [entryPoints.websecure]
        address = ":443"
    a kontejner pak spouštím takto:
    docker container run -dit \
      --name myapp \
      --label 'traefik.tcp.services.myapp.loadbalancer.server.port=443' \
      --label 'traefik.tcp.routers.myapp.rule=HostSNI(`myapp.my.domain`)' \
      --label 'traefik.tcp.routers.myapp.service=myapp' \
      --label 'traefik.tcp.routers.myapp.entrypoints=websecure' \
      --label 'traefik.tcp.routers.myapp.tls.passthrough=true' \
      myapp:latest
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    JFM:
    to co hledas je tcp proxy
    ja to mam v kubernetes konfigurovane takhle
    napred otevru v traefiku port
    tcpredir:
      port: 9443
      expose:
        default: true
      exposedPort: 9443
      protocol: TCP
    a pak jen udelam ingressroutetcp a reknu ji ze ma pouzit otevreny port, ktery se jmenuje `tcpredir`
    a pokud chces aby to delalo match podle nejake domeny, tak je to
    match HostSNI
    ` - match: HostSNI(`oneprovider.example.com`)`

    apiVersion: traefik.io/v1alpha1
    kind: IngressRouteTCP
    metadata:
      name: test-oneprovider-config
      namespace: test-onedata
    spec:
      entryPoints:
      - tcpredir
      routes:
      - match: HostSNI(`oneprovider.example.com`)
        services:
        - name: oneprovider-oneprovider
          port: 9443
    LUCIEN
    LUCIEN --- ---
    JFM: Mně běží většinou aplikace pro traefik přes docker-compose a tam prostě nadefinuju např. něco takovýho

    wordpress:
      container_name: ${PROJECT_NAME}__wordpress
      build:
        context: .
      env_file: .env.wordpress
      environment:
        - PROJECT_NAME=${PROJECT_NAME}
      restart: unless-stopped
      volumes:
        - "${VOLUME}:/var/www/html"
        - ./volumes/wordpress-uploads:/var/www/html/web/app/uploads
      depends_on:
        - mysql
      networks:
        - internal
        - web
      ports:
        - ${PORT_NGINX}:80
      labels:
        - traefik.http.routers.${PROJECT_NAME}__nginx.rule=Host(`${HOST_WORDPRESS}`)
        - traefik.http.routers.${PROJECT_NAME}__nginx.tls=true
        - traefik.http.routers.${PROJECT_NAME}__nginx.tls.certresolver=lets-encrypt
        - traefik.port=${PORT_NGINX}

    Pak by mělo stačit upravit ten port z 80 na 443, ne?
    JFM
    JFM --- ---
    Používám Traefik jako proxy pro přístup k frontend webovým rozhraním aplikací, které mi běží v kontejnerech v dockeru.
    Potřebuji uživatelům umožnit přístup k aplikaci, která má HTTPS zabezpečený web, běží na portu 443.
    Jestli to správně chápu, SSL/TLS se nastavuje přímo v Traefiku, ten ven poskytuje HTTPS, ale do kontejneru předává na nezabezpečený HTTP na port 80. Jde to nějak rozchodit, když HTTPS na 443 je přímo v kontejneru?
    VELDRANE
    VELDRANE --- ---
    JON: mno bez toho abys mu vyrobil roli na konkretni objekty to imho neudelas a abys mu vyrobil roli na konkretni objekty musi ten objekt uz existovat :). Proste musi Ti existovat nadrazena entita, ktera rozhodne zda muzes udelat operaci nad neexistujicim objektem ci nikoliv a je jedno zda to bude operator a nebo to poresis treba nejak v ramci tf.

    Jeste me napada to zkusit poresit treba v ramci oidc. Pokud mas uzivatele v nejakem idp a vydavas tokeny, pak muzes pred danou akci (spusteni pipeliny) chtit po uzivateli (proste zada jmeno heslo
    , aby se ti overil proti Tvemu idp a ziskal token s patricnymi claimy, kde bys mel informaci o rolich/pripadne povolnych ns a na zaklade toho bys kontroloval zda danou akci udelas a nebo ne. Teoreticky by to mohlo fungovat, nicmene mi to prijde zbytecne moc srani :). Samozrejme bys musel nejak patricne chranit servisni account do k8s ktere stejne musi mit prava na to udelat to zlo uvnitr => zalozit jakejkoliv ns nebo ho smazat. Coz by se dalo asi dalo osefovat nejakym mechanismem ala manage identity v azure.

    Jako jo tohle by bejt cesta ale prijde mi to zbytecne krkolomny a nevim jestli to za to stoji :)
    JON
    JON --- ---
    VELDRANE: no prave ze bych se tem predvytvorenejm ns chtel vyhnout - a prijde mi, ze skrz "o uroven niz kam nema pristup dev, nicmene muze nektere parametry ns ovlivnovat pres nejakej value file ale do logiky nesmi" se uz dostavas cca tam co ja puvodne.

    Jinak dev a prod byl zjednodusenej ilustracni priklad - jde mi o to zaroven dat devovi co nejvetsi kontrolu nad svym ns, ale nedat mu pristup jinam.
    VELDRANE
    VELDRANE --- ---
    ...jinak dev ns a prod ns by meli mit oddelene clustery a tedy bys mel mit jasny vydefinovany kdo kam muze - vcetne pipeline.
    VELDRANE
    VELDRANE --- ---
    JON: to uz je trochu o tom jak mate nastaveny pipeliny pripadne procesy ktery s tim souvisej. Bud muzes mit namespace predvytvoreni v ramci zakladani projektu takoveho (u par zakazniku sem to videl), takze pak jen mazes objekty v nich. Nebo resis vytvareni namespacu o uroven niz kam nema pristup dev, nicmene muze nektere parametry ns ovlivnovat pres nejakej value file ale do logiky nesmi. Ty v ramci logiky overujes zda dotycny muze tohle na tom ns udelat nebo ne. Pripadne muzes zkusit na to napsat nakej operator, ale to mi prijde zbytecnej overkill
    JON
    JON --- ---
    VELDRANE: to ze api uz existuje, mas urcite pravdu, ale ja resim trochu slepice-vejce problem: potrebuju nejak z pipeliny zavolat vytvoreni noveho namespacu, ale zaroven v ni nechci mit kubeconfig, kterej ji opravnuje libovolne manipulovat s namespacama - zjednodusene chci, aby si uzivatele mohli on-demand zakladat a mazat dev-* namespacy, ale aby nemohli hrabat na prod-* namespacy.

    Nejde tady teda primarne o ten kubeconfig (s tim jen operuju v ramci te pipeliny), ale o nejakou RBAC roli, ktera tohle bude delat.

    V resourceNames nejde pouzit wildcard, a navic se tam pise: You cannot restrict create or deletecollection requests by their resource name. For create, this limitation is because the name of the new object may not be known at authorization time. ... tak nevim jak.
    VELDRANE
    VELDRANE --- ---
    JON: mno me to prinde ze to je blbej napad. To api uz existuje a jmenuje se kubernetes api, role prirazujes pres cluster role a kde mas uzivatele zalezi na instalaci - pouze lokalni admin, oidc provider, 3rd party - entra treba). Kubeconfig imho vygenerujes i bez nejakejch spesl opravneni.

    long story short - je to jen imho o tom jak udelas cluster roli, komu ji pridelis a jak vygenerujes kubeconfig. Na to nepotrbujes nic specialniho
    JON
    JON --- ---
    Lepsi auditko jsem nenasel: V k8s clusteru bych potreboval on-demand zakladat namespace (pro testovaci prostredi). Ted to delam z CI/CD pipeliny, ale nelibi se mi, ze tam (v gitlab variables) musi byt kubeconfig s pristupem k celemu clusteru - chtel bych tam dat jen kubeceonfig omezeny na dany namespace, ale ten jde vytvorit az kdyz namespace existuje (mi teda prijde, muzu se plest).

    Tak me napadlo si na to udelat servicu, ktera pobezi v tom clusteru, a prostym zavolanim nejakyho API provede kontrolu opravneni, spravnosti jmena namespacu a namespace zalozi a vrati k nemu kubeconfig.
    Je to dobrej napad? Spatnej napad? Jakej je to vlastne napad?
    Neexistuje uz neco takovyho?
    RUDOLF
    RUDOLF --- ---
    VOJTAM: v enterprise jedem tohle. Umí to automaticky měnit cpu/mem konfiguraci definic v EKS podle vlastního sledování. Když máš scheduling přes Karpenter, tak je to super. Trabl je, že joby jsou created tak do toho moc nechceme developerům moc šahat, ale často spinují underutilized pody. Ale tím že provozujeme i non-prod prostředí, tak tam se to hodí.

    IBM Turbonomic
    https://www.ibm.com/products/turbonomic
    MRDAC_BEDEN
    MRDAC_BEDEN --- ---
    VOJTAM: Na produkci a develop serveru pouzivame Docker Swarm. Primarni administracni nastroj je prikazova radka, deploy z Gitlabu. Doplnkove pouzivame Portainer a Swarmpit
    Swarmpit - ma hezke grafy pouzitych zdroju (CPU / MEM) pro jednotlive kontejnery
    Portainer - ma lepsi ui a vice moznosti
    VOJTAM
    VOJTAM --- ---
    Ahoj, používáte nějaký "container management" ? našel jsem yacht.sh a portainer.io.
    Je něco dalšího na co se podívat ?
    RUDOLF
    RUDOLF --- ---
    HVJ3R: nope, zapsalo to na fs. koukal jsem na to i z venku kontejneru. Ale ještě jsem tem compose ne-předefinoval. Tak dám vědět, je to takovej hobby job ke kterému se vracím čas od času.
    HVJ3R
    HVJ3R --- ---
    RUDOLF: Ja bych si aj tipnul, ze te to tam necha zapsat, ale pises do overlaye pro dany kontejner, nepropisuje se ti to do underlyimg FS. Nebo jo?
    Kliknutím sem můžete změnit nastavení reklam