Příspěvky

Celkem zajimave reseni muze byt i pomoci Portable Services, ktere uz nejakou dobu podporuje systemd.

AWS IAM https://aws.amazon.com/iam/

Radeji bych se vyhybal resenim se silnym vendor lock-in na cloud. Prijde mi tu celkem rozumne podivat se po open-source resenich jako je  keycloak. Nejake hinty k pouziti s mikrosluzbama jsou treba tu: https://medium.com/@imyom25/microservices-and-security-part-2-f2b44eb98a21

rovnou bych se i podival na service mesh(istio, linkerd), a aplikaci vyvijel uz pripravene pro jejich adopci. Tim si usnadnim spravu infrastruktury v budoucnu a rovnou ziskam transaction monitoring, rozumny management certifikatu, routovani a service discovery atp.

Osobne bych se ESB patternu u microsluzeb spise vyhybal, je to spise relikt SOA architetkury podobne jako velke databaze v pozadi. Mikroservices vnimam spise jako krok k distribuovanym systemum, kde mit message brokery je slozite, protoze potrebuju je mit skalovatelne a v HA setupu.
Tohle se puvodne resilo ruznyma knihovnama ve sluzbach, kdy vsechny retries, circuit breakers, service discovery atp byly reseny v apliakci vecmi jako netflix zuul atp. Ve svete kontejnerizace a service meshes bych se uz spise dival po infrastrukture, ktera mi tohle vse zajisti. Myslim, ze orchestrace zalozena na Kuberentes/OpenShif ve spolupraci si istiem a solidini API GW je zajimavou platformou.
Pokud se tohle vse propoji s nejakym FaaS (Azure functions, OpenWhisk?) tak se muze jednat o velmi vyspelou infrastrukturu, ktera mi spolehlive ridi, zabezpecuje a standardizuje vyvoj a nasazeni mych mikrosluzeb.

Dle mého dává smysl u velkých monolitických oblud. Pokud máte microservices, už to žádné velké benefity nemá.
Zase to tam není složité, takže lze použít i tam. Pokud tu monolitickou zrůdu rozmlátíte na kousky, taky nemusí být objektová.

Preferuju všechno rozsekané na malé kousky pak je mi naprosto jedno v čem to je napsané.

Monolit neni antipattern A nejsou microservices vicemene OOP prevedene do distribuovaneho systemu service(object) a zasilani zprav?

MessagEase, umoznuje mi pouzivat terminal i s telefonem na vysku a jednou rukou. Snadno poslu vsechny klavesy co je treba vcetne gest pro Ctrl, Alt atp. Da se s ni celkem slusne ovladat i Emacs

Vlastnímu projektu se může věnovat i při práci, když prý nemusí hrábnout a nemusí mít stres z toho, že má na to jen čtyři měsíce. Jenže on je admin, ne vývojář. Takže jaký vlastní projekt mu poradíš ?

Pripravit nejake vyukove materialy? Napsat knihu? Naucit se jakykoliv chybejici skill aby mohl realizovat jakykoliv projekt, ktery ho bavi?

Tak to je to programování v 5 hodinách. Asi těžko budu 5 hodin programovat a pak si řeknu, že půjdu s kolegou rozebrat novou architekturu. Jestli tohle zvládáš, tak děláš něco špatně. Administrativou se myslí co? Zavřu ticket? To zase v těch 5 hodinách.

Ja nevim, ale ty administrativy je dost. Clovek musi zanalyzovat problem co resi, udelat si nejakou PoC implementaci, zvalidovat ji vuci pozadavkum, zjistit co a kde se oproti zadani rozchazi, jeslti opravdu resim ten problem, kde treba zadani muze byt nevhodne, udelat nejake feedback kolecko. Pak je  treba napsat nejakou dokumentaci, testy a nakonec finalne tu danou funkcionalitu.  Takze realne psani kodu je pro vyvojare relativne mala cast prace. Pokud samorejme je to nejaky bezmyslenkovity busic kodu tak to asi funguje jinak.

Toto nedela mc, ale jeho mc-wrapper.sh. Standardne je vytvoren alias pro mc na tento skript.  U me na fedore je to:

Kód [Vybrat] Rozbalit


alias mc='. /usr/libexec/mc/mc-wrapper.sh'


Zkus si ten alias zrusit pomoci:

Kód [Vybrat] Rozbalit


unalias mc


nebo spustit mc pomoci plne cesty /usr/bin/mc

Pokud to pomuze, projdi si sve profile/rc skripty ke svemu shellu a ten alias si zrus trvale.

Ja bych s tim uplne nesouhlasil, prijde mi, ze v IT se v me oblasti zas tak moc nedeje (resim primarne veci kolem kontejneru, cloudu, nejake devops atp). Mozna jsem uplne mimo, ale principy jsou vesmes velmi podobne, ty technologie jsou sice nove napsane, ale porad je to principielne nejaky timesharing a sprava transakci - mrk mrk z/OS + CICS.
Myslim, ze pokud clovek venuje nejaky cas tomu, aby pochopil jak funguje operacni system (idealne zacit necim jako knihou Principles of the operating systems), pohrat si s plan9 kernelem, podivat se do zdrojaku kubernetes, napsat si vlastni jadro take neni od veci, neni to tak tezke a v dobe KVM - mozna se klidne vykaslat na QEMU a rovnou sahnout po kvm-tool  ci clear containers a bavit se a clovek urcite nezastarava tak rychle.
Pokud chci vic programovat, je tu skvely racket-lang, kde si muzu napsat vlastni programovaci jazyk za par odpoledni a experimenotvat s paradigmatama, muzu se podivat jak nejaky jazyk napsali ostatni. Programovaci jazyky jsou si v mainstreamu taky velmi podobne a celkem snadne na pochopeni, obcas se objevi neco, co se vice inspiruje pomoci scheme (mrk mrk makra v rustu), ale zase na tom neni nic sloziteho.
Jedinej predpoklad je, ze clovek umi psat poznamky tak, aby se z nich i po par letech rychle neco znovu naucil/osvezil si to. A na to vsechno staci treba hodka az dve denne, kterou poctive neco delam Chapu, ze cist fora a flameovat a jinak palit cas je obcas potreba, take to rad delam a regeneruji se tak, jen je treba si hlidat abych se kazdy den neco maleho naucil.

Pokud chce HR me CV, muze si ho stahnout z linked.in, kde me vetsinou i oslovuji. Pokud pozaduji specificke CV, tak ta pozice musi byt necim vyjimecna, abych pro ne delal i specialni CV.

Mate nejaky realny priklad, ktorym sa da vase tvrdenie overit?
Kompilujem totiz binarne moduly pre rozne distribucie prave cez Docker kontajnery a ani raz som sa nestretol s popisovanym problem.

Nic, co bych mohl primo linkovat (Docker je relativne mladej, takze je to spis vzacnost). Ale staci se podivat na veci kolem kompilace glibc a --enable-kernel option, zaroven si muzete zkusit do glibc pridat nove volani a linkovat ho, pridat syscall a pouzit ho v aplikaci a tu pak spustit na starsi distribuci, zpusobu jak to nasimulovat je dost. To jsou veci, ktere se proste v realnem vyvoji postupne stavaji.

V čem je přínosnější docker na železe oproti např. lxc na železe se zfs? Nevím, jen se ptám, s dockerem jsem si svého času hrál, lxc používám a přijde mi vynikající.

V nicem a ve vsem. Z heldiska technologie jako kontejnery (ruzne namespaces, cgroups, seccomp, selinux). Rozdil je az v celem ekosystemu, kdy nastupuji veci jako kubernetes. Bachorkam o aplikacnim a systemovem kontejneru taky never, protoze z heldiska kernelu se to chova stejne.

Docker by vás mohl zbavit těch VM. Docker sám by jel přímo na železe a každý projekt by měl vlastní kontejner. Jádro systému je tedy sdíleno všemi kontejnery, v každém z nich může být jiná verze distribuce, knihoven, Apache, PHP i databáze.

Kernel sice ma pravidlo "dont break userspace", ale tohle tvrzeni plati jen pokud pouzivas starsi distribuci na novejsim kernelu, opacne nejde zarucit - obecne muzou nastat problemy mezi libc a kernelem, pokud mas starsi jadro a moc novou distribuci v dockeru. V podstate jsi v situaci ze si do nove distribuce rucne vrazis nejaky nepodporovany kernel - napadlo by nekoho instalovat Alpine kernel balicek na Debian? To je presne, co se s kontejnery deje. To znamena, ze bezite svou produkci v nejake totalne neotestovatelne kombinaci SW a modlite se aby to nejak fungovalo. Ne vse, co si muze vyvojar dovolit na dekstopu je dobry napad v produkci.

Podobně jako virtualizace. Můžeš mít x různých verzí PHP s různými verzemi Composeru, klidně i na starší verzi systému.

Kontejnery tu nejsou od toho abysis udelal v infrastrukture bordel - jak resis napriklad security updaty? Ani pro docker neni moc nastroju co ti reknou, jaka knihovna ma jake CVE, pokud neni instalovana z balicku a nepuzijes CVE databaze od distribuci. A kdyz upstream tu verzi nepodporuje, tak si fixy backportujes sam?

Asi vystupy tech nastroju nebudou dostatecne dobre Mam jen velmi starou zkusenost s necim podobnym a  vetsinou to fugnovalo tak, ze se jakztakz neco pouzitelneho vygenereovalo, ale uz to nikdy moc neslo menit, migrovat na novejsi verze, pridavat nove vlastnosti atp.