• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    DANIELSOFT
    DANIELSOFT --- ---
    restartoval jsem fyzickou mašinu, na které to běží, a problém přetrvává
    DANIELSOFT
    DANIELSOFT --- ---
    logger=sqlstore.transactions t=2023-03-04T18:18:25.159761652Z level=info msg="Database locked, sleeping then retrying" error="database is locked" retry=4 code="database is locked"
    DANIELSOFT
    DANIELSOFT --- ---
    1 odpověď
    ahoj,

    mám chybu, které nerozumím

    v docker-compose mám grafanu, normálně z docker hubu grafana/grafana a vyskytuje se tam chyba "database is locked", kvůli níž se mi tam nepřidají dashboardy

    je to asi tato chyba
    Grafana Logs "database is locked" · Issue #16638 · grafana/grafana · GitHub
    https://github.com/grafana/grafana/issues/16638

    při docker-compose stop a docker-compose rm se kontejner zruší, ale když ho pustím znovu, databáze se znovu corruptne, což nechápu

    našel jsem nějaký shell skript který by měl pomoct

    #!/bin/sh
    docker exec -it -u 0 $1 sh -c 'apk add --no-cache sqlite && cd /var/lib/grafana && sqlite3 grafana.db ".clone grafana-new.db" && mv grafana.db grafana-old.db && mv grafana-new.db grafana.db'

    kde na $1 mu zadám jméno kontejneru s grafanou, ale on potom tu databázi zdrbe tak, že se tam nemůžu nalogovat, takže mě je to k ničemu

    nějaké nápady?
    JON
    JON --- ---
    +6
    MARTEN: <humor> cetl jsem rozjebe, a davalo to smysl </humor>
    MARTEN
    MARTEN --- ---
    1 odpověď
    Pripadne jeste ranher, ktery se svym rke2 rozjede jubernetes cluster skoro bez prace. Ale je potreba stale hodne znalosti kolem kubernetes, aby to fungovalo slusne.
    JON
    JON --- ---
    MLEKAR_STEIN: to ti fakt google moc nepomuze, tohle bude skoro jiste neco vaseho inhouse.
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    1 odpověď
    diky moc,
    ja prave nic moc nenasel, mame argo, ale moc mi google nepomohl.
    VELDRANE
    VELDRANE --- ---
    MLEKAR_STEIN: heh tipnul bych si ze to je nakej Vas custom template kterej zadavas z externiho zdroje (ansible, skript, pipeline, apod), kterej to prepise v tom chart.yaml. Ono totiz menit dynamicky verzi treba na zaklade gitu je dost oser. Nicmene pro sichr jeste pogooglim
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    1 odpověď+1
    dotaz k helmu.

    co znamenajni ty uhlove zavorky v Chart.yml

    apiVersion: v1
appVersion: "1.0"
description: A Helm chart for deployment of <<chart-name>>
name: <<chart-name>>
version: <<version>>

    dostal jsem za ukol zvednout verzi chjartu, ale tady neni ani jaka tam je.
    AQUARIUS
    AQUARIUS --- ---
    Pak tu jeste mame middle ground, a to ze Podman umi pracovat s k8s yaml souborama.. Takze lze zacit zlehka a az (jestli) bude potreba prejit na plnotucnej kubernetes, bude to bolet min.
    VELDRANE
    VELDRANE --- ---
    WOJTISHEK: Ja myslim ze otazka je polozena spatne. Spis bych se ptal kolik mam nebo planuju microservice, jaka je architektura aplikace, jake jsou jeji komponenty a co s tou aplikaci nebo prostredim planuju dal, propadne zda tech aplikaci ma vedle sebe bezet vic
    KING
    KING --- ---
    +3
    JON: ja na jednom serveru nevidim jakoukoliv vyhodu k8s oproti treba compose a spousta nevyhod. Ano, mozna zvladneme vykonstruovat specialni jednu situaci ktera bude tou vyjimkou z toho pravidla, ale ani tam bych se do toho v zivote nepoustel pokud uz k8s neznam.
    JON
    JON --- ---
    1 odpověď+2
    WOJTISHEK:
    KING: ono taky zalezi co znamena "jen jeden server", zejo.

    Podle me kriteriem proc mit ci nemit k8s je asi hlavne kolik ruznejch sdielenejch devel/integracnich/staging/produkcnich prostredi potrebuju provozovat.
    Pokud mi staci lokalni vyvoj, nejaka "beta" a produkce, tak je to nesmysl (krome drive uvedenych duvodu - naucit se, je to muj denni chleba tak jako tak).
    Pokud jich je vic, zvlast pokud je potreba takova prostredi vytacet on-demand, tak je to nakonec jedina pricetna volba.
    A pak jsou ty varianty mezi tim, kde je potreba to zvazit - zere mi priprava a sprava tech prostredi fakt hodne casu, vypada to, ze dlouhodobe budou spis pribejvat, nebo ubejvat?

    Pak jsou situace, kdy jsou pocty tech prostredi limitovany nejakym fyzickym kusem hardwaru - tam ty k8s taky nejsou vsespasitelny.
    KING
    KING --- ---
    1 odpověď+5
    WOJTISHEK: rozhodne ne, komplexita ani runtime overhead se nevyplati resit.

    Jedina vyjimka samozrejme je, pokud je k8s tvoje domaci prostredi a/nebo se ho chces naucit.
    VELDRANE
    VELDRANE --- ---
    …tlT treba v docker swarmu. Nicmene proti gustu zadnej disputat :)


    Sorac, tlacim to z mobilu a odpalil sem ten post driv nez nez byl hotovej.
    VELDRANE
    VELDRANE --- ---
    Za me smysl k8s urcite ma a nemusi to bejt plnohodnotny k8s. Ty principy nejsou imho nijak slozity, cely tymy na k8s jsou hlavne z duvodu integraci ale ne samotneho k8s. Vyhoda je i to, ze kdyz uz to clovek jednou vytoci a pak se rozhodne ze prejde treba do cloudu nebo z cloudu do on-premu je to plus minus stejny. Kdyz uz clovek si da praci a ty jednotlivy aplikace hodi do kontejneru, pak mi prijde skoda to pa
    WOJTISHEK
    WOJTISHEK --- ---
    3 odpovědi
    Ma vubec smysl resit k8s, kdyz mam jen jeden server? Nebo vnimam nespravne to, ze je to vyhodnejsi az ve chvili, kdy mam aspon 2 ruzna zarizeni?
    URZA
    URZA --- ---
    +4
    Na pár domácích kontejnerů používat kubernetes (je jedno jestli k8s/k3s/minikube) má smysl asi jedině v případě že se to potřebuje/chce naučit kvůli práci. Jinak je to kravina. Nejde jen o to že se bude muset učit miliardu věcí a konceptů aby to vůbec všechno zprovoznil, ale i další údržbu, aktualizace atd. Na kubernetes jsou ve firmách buď celý týmy lidí nebo minimálně člověk na full-time. Jinak je to trápení.
    SAMGARR
    SAMGARR --- ---
    +3
    SUK: ad 1), k8s/k3s/Nomad/Swarm/... bych volil pokud tim ziskam nejakou featuru, kterou 100% potrebuju nebo pokud se danou technologii chci naucit, jinak docker-dompose.
    MRDAC_BEDEN
    MRDAC_BEDEN --- ---
    +3
    SUK: Nas stack (https://www.uxf.cz/ )/
    - Debian, pokud mozno co nejminimalnejsi instalace se zakladnimi nastroji (ssh, dig, ping...)
    - Docker instalujeme z docker repozitare, abychom to meli trochu aktualni
    - primo na serveru bezi jen ssh a Docker Swarm

    Bezi nam tyto Docker Swarm stacky:

    - Traefik - "centralni" reverse proxy, ktera "sama objevi" nove bezici sluzby, ma nastarost nasmerovat pozadavek do spravneho stacku

    - PostgreSQL - centralni, protoze
    a) muzu vyladit konfigurace, priradit vice RAM
    b) snazsi zalohovani

    - Minio - S3 storage - centralni, protoze
    a) konfigurace a data na jednom miste - mam minimum volumes v projektech
    b) snazsi zalohovani

    - Resizer - nas vlastni centralni resizer obrazku v nodejs

    - Sentry - centralni smer dat

    - Zabbix - centralni metriky

    a pak jednotlive projekty (stacky), ktere jsou obvykle tvoreny temito services:
    a) nginx - distribuuje pozadavky mezi backend a frontend
    b) api - php8.2+fpm
    c) web - frontend v NextJS
    d) admin - frontend v NextJS
    a dale dle projektu Redis, RabbitMQ...

    Nasazujeme z GitLabu, zaroven povazuji za zakladni znalost umet vse ovladat z prikazove radky. Krome toho mame Portainer a SwarmPit, ale ty pouzivame okrajove
    Kliknutím sem můžete změnit nastavení reklam