• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    URPUTNIK
    URPUTNIK --- ---
    QUIP: jj, rozumim, uz jsem se ptal i v php klubu .. a dospel jsem ke stejnym zaverum, takze diky za potvrzeni!
    QUIP
    QUIP --- ---
    1 odpověď+1
    URPUTNIK: S PHP 5.2 mas asi nejvetsi problem v tom, ze se malo kdo zabyval prechodem z 5.2 na 7.x Vetsina tech nekompatibilit zminuje rozdily mezi nejakou posledni vetvi 5.x, takze vetsinou 5.6 => 7.0
    Pokud se budete v te aplikaci stourat, aby fungovala na PHP 7.x, tak ji rovnou testujte na 7.3 (nebo aspon 7.2) 7.0 uz je EOL.
    Tudiz budes muset nejspis hledat nekompatibility mezi 5.2 - 5.6, 5.6 - 7.0 a pak 7.0 - 7.3
    https://www.php.net/manual/en/migration73.php
    https://www.php.net/manual/en/migration53.incompatible.php
    https://www.php.net/manual/en/migration54.incompatible.php
    https://www.php.net/manual/en/migration55.incompatible.php
    https://www.php.net/manual/en/migration56.incompatible.php
    https://www.php.net/manual/en/migration70.incompatible.php
    https://www.php.net/manual/en/migration71.incompatible.php
    https://www.php.net/manual/en/migration72.incompatible.php
    https://www.php.net/manual/en/migration73.incompatible.php

    ...ale tohle neni o Dockeru, to je proste o PHP

    https://github.com/sstalle/php7cc
    https://github.com/gisostallenberg/php-to-7-aid
    BLACKOUT
    BLACKOUT --- ---
    +1
    URPUTNIK: U nas to mame robene nasledovne :
    - echo $MTR_PASS | docker login -u="$MTR_USER" --password-stdin $MTR_URL
    - if ! docker pull $IMAGE_FQDN; then docker pull $MTR_URL/$MTR_NEA_GROUP/$CI_PROJECT_NAME:master || true; fi
    - docker build -t $IMAGE_FQDN-${CI_ENVIRONMENT_NAME} .
    - docker build -t $IMAGE_FQDN-${CI_PIPELINE_IID}-${CI_ENVIRONMENT_NAME} .
    - docker push $IMAGE_FQDN-${CI_ENVIRONMENT_NAME}
    - docker push $IMAGE_FQDN-${CI_PIPELINE_IID}-${CI_ENVIRONMENT_NAME}

    Treba to este poladit ale aktualne to postacuje, samotny image sa nahrava na private Quay, kde mame robene checky ci je image "OK". dalej nekonecny release management, helm, openshift.

    Dovod preco to cele take je, je poziadavka vediet hocikedy, hocijake, prostredie dostat do urciteho releasu (ci uz globalne na urovni "PI" alebo minor)

    Co sa tyka release managementu "muze se jich nekolik buildit paralelne atp, takze se neda spolehnout na latest"
    Mame nekonecne python / bash scripty ktore citaju z config suborov ktore vyplna samootna pipeline. (ofc je do toho zapojeny nexus,ansible pre nejake pripady, terraform ked sa jedna o nejake VPS/EPS) atd atd

    Jedina manualna vec ktoru clovek musi urobit, je v gitlabe v danom env. repo urcit aka verzia sa ma deployovat (napr ... pi4.1.1548)

    ale to uz asi zachadam :D
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    tak dalsi, predpokladam ze velmi obvykly dotaz .. mame nejakou aplikaci, ktera pouziva php, ale samozrejme 5.2 .. tak ted zjistuju, co by nas stal predchod na php7, ktery umi oficialni docker image ..
    nasel jsem tohle a tohle .. nejaky dalsi zdroje, co jste potkali?

    buildit si vlastni image od operacniho systemu nechci (kdo ho pak bude udrzovat) a pouzivat cizi privatni co nevypada aktualizovane taky ne ..
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: a jeste jsem nasel parametr --iidfile do buildu, to by mi taky stacilo ..

    diky za reakce!
    INDIAN
    INDIAN --- ---
    +1
    URPUTNIK: ja pouzivam job id z Gitlab CI, kde se mi image generujou. Jedinou vadu na krase to ma to, ze to id je unikatni napric vsema projektama, tudiz na sebe primo nenavazujou, ale ke spokojenosti nam staci to, ze je lze diky jednoduchy inkrementaci porovnavat
    ADM
    ADM --- ---
    +2
    URPUTNIK: pokud vis, jak ten image otagujes nasledne, udelej to rovnou v build stage, jinak budes mit po naslednym pretagovani v local images 2 image, coz uz budes muset zbytecne nejak resit treba pri mazani.
    pokud ti jde o to, jak unikatne tagovat image a je tam moznost ze se buildi zaroven stejny image na nejakym CI systemu, tak pouzij treba git commit hash, nebo vetsinou mas z CI nejaky unikatni build id, apod.
    tam kde se builduji image je vetsinou neschranujes, takze veskery mezikroky mezi build, push, a pak nejakyho naslednyho mazani local images (treba na zaklade stari) jsou vetsinou zbytecny
    URPUTNIK
    URPUTNIK --- ---
    4 odpovědi
    ahoj, mam dotaz, jak tagujete image? nemyslim tim vycet tagu, ale jak to provadite? jako parametry do docker build? nebo delate cely scenar, tzn 'docker build, docker images | grep, docker tag'?

    ten scenar mi prijde prehlednejsi (misto nekonecnyho docker build radku), ale resim, jak spravne identifikovat ten cerstve vyrobeny image .. ono to totiz muze byt soucast nejaky CI pipeline, takze tam tech imagu bude videt vic, muze se jich nekolik buildit paralelne atp, takze se neda spolehnout na latest .. a tak mne napadlo, ze si pred spustenim docker build vygeneruju unikatni hash, jim to otaguju zaroven s buildem, a pak tenhle hash pouziju pro filtrovani v 'docker images' .. je to nesmysl? da se to udelat jednoduseji? pac takhle mi to bude do privatni repo sypat i ten unikatni tag, ne?
    RAGNAROK
    RAGNAROK --- ---
    RAGNAROK:
    uz asi vim musim pouzit funkci:
    ips, err := net.LookupIP("receiver")
    RAGNAROK
    RAGNAROK --- ---
    1 odpověď
    ADM
    delam to v go:
    potrebuju nejak dostat adresu do funkce net.WriteToUDP(b []byte,addr *UDPAddr).
    Zkousel vsechno mozny porad mi to psalo write udp [::]:3000->%UDP:2000: sendto: cannot assign requested address"
    ADM
    ADM --- ---
    1 odpověď+1
    RAGNAROK: ano, stalo by za to hodit si tam explicitne networks (kdyz nepouzijes, melo by byt implicitni, ze se vytvori bridge network, kde jsou vsechny sluzby z konkretniho docker compose). na ty ip adresy z toho prikladu zapomen, staci ti pouzivat pro komunikaci mezi kontejnery dns servicename
    ADM
    ADM --- ---
    +1
    RAGNAROK: zajisti si, aby receiver poslouchal na wirldcard IP, pak se k nemu sender pripoji normalne na 'receiver:port'. links vyhod, ports vyhod taky, pokud teda nepotrebujes pristupovat na receiver odjinud nez ze sender.
    RAGNAROK
    RAGNAROK --- ---
    2 odpovědi
    ADMIX:
    tak jsem objevil toto a maka to :-D konecne:
    Alejandro Celaya | Blog — Software development, agile methodologies and open source projects
    https://blog.alejandrocelaya.com/...c-ip-addresses-to-docker-containers-created-with-docker-compose/
    ADMIX
    ADMIX --- ---
    1 odpověď+1
    RAGNAROK: na tohle je obecne nejlepsi mit nejakej MQ broker mimo, ale v tvym pripade bych rek ze potrebujes bridge a ne localhost, pac ty kontejnery localhost nesdili
    RAGNAROK
    RAGNAROK --- ---
    1 odpověď
    Zdravim nemuzu prijit na to jak nastavit sit pro 2 kontejnery ktere mezi sebou komunikuji pres UDP:
    Container sender posila UDP packety ktere by mely dojit k Receiver conteineru. Receiver by mel prijmout packet a odpovedet na adresu ze ktere prijmul UDP packet. Kdyz pustim obe apky bez dokru tak to funguje. Kdyz napisu apku, tak ze receiver a sender jsou v jedne apce tak to funguje. Kdyz je ale poustim zvlaste v dockeru s nasledujicim docker-compose tak sender posila UDP na adresu 127.0.0.1:3000 ale receiver nic neprijme. Nevedel by nekdo prosim?

    
version: '3'
services:
  receiver:
    image: receiver:latest
    environment:
      Laddr: "127.0.0.1:3000"
    ports:
      - "3000:3000/udp"
    links:
      - sender

  sender:
    image: sender:latest
    environment:
      Laddr: "127.0.0.1:2000"
      Raddr: "127.0.0.1:3000"
    ports:
      - "2000:2000/udp"
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    ADM: díky za postrčení, byl jsem unavenej a nedošlo mi, že jsou jednodušší cesty jako třeba bind portu... :-)
    ADM
    ADM --- ---
    1 odpověď
    MLEKAR_STEIN: o co presne ti jde? do kontejneru forwardujes z hosta port, to standardne zajistuje docker-proxy, ktery ten port binduje na hostovi a portforwarduje sluzbe v kontejneru, a muzes si urcit i na jakym IP rozhrani, a nebo si muzes sluzbu v kontejneru rovnou bindnout na host port a obejit docker-proxy, pokud pouzijes network host mode
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    1 odpověď
    dotaz k sítím v dockeru v compose.
    verzi dockeru mám poslední, compose taky.

    dostal jsem za úkol, jako nouzové řešení
    udělat aby kontejnery byly vidět na vnější adrese serveru v rozsahu, ve kerém ten vnější adaptér serveru je.
    není mi moc jasné, jak na to vytvořit "bridge síť" nebo jak jinak se s tím poprat.

    díky moc.
    RUDOLF
    RUDOLF --- ---
    ADM: jj, ve swarmu slouží healthcheck jen jako indikátor, zda má swarm kontejner restartovat. That's all. Žádnou cross container logiku bych tímhle neřešeil.
    ADM
    ADM --- ---
    1 odpověď
    RUDOLF: jasne, ja tam nakonec dam nejaky shell healthcheck renatomefi/php-fpm-healthcheck (pouziva fastcgi binarku), akorat me zarazilo ze v single docker-compose to funguje (a je to defakto lepsi healthcheck, protoze je to vlastne nadmnozina co do testovanych podminek), ale to je jen takovy vedlejsi efekt.

    bohuzel ve swarm mode je pokud to dobre chapu mozny healthcheck jen na localhost (dns name neni zaregistrovan dokud neprojde healthcheck), coz je takovy dost ... no .. ne uplne idealni, oproti kubernetes, kde jsou rovnou 2 typy healthchecku a hlavne jsou z hlediska containeru externi.
    Kliknutím sem můžete změnit nastavení reklam