RATTKIN: Tech moznosti je strasne moc. Za mne zalezi jestli je to self hosted, nebo nejaky cloud. Taky jak je to velka aplikace, jestli se pocita s balancingem/failoverem,...
Traefik je super na male veci. Pokud resit nejake skalovani, tak haproxy. Pripadne openshift, rancher, nebo jine self hosted. Casto si to pak resi sami.

RATTKIN: traefik

Let's Encrypt - Traefik
https://doc.traefik.io/traefik/https/acme/

RATTKIN: gitlab lze v klidu pouzivat i interne a obsahuje nativne i vlastni docker registry.
+ samozrejme vlastni CI implementace (obdoba jenkins)
mno a samozrejme hromady jinejch ficur...

my uz ho pouzivame 3. rokem a spokojenost ... plne zaintegrovanej mezi interni aplikace diky API, prihlasovani uzivatelu pres externi SSO, hodne vyuzivame prave i interni registry (kazdej projekt ma svuj napespace) a diky tomu prechod na kontejnery byl i jednodusi pro plno vyvojaru, admini se zas docela naucili ovladat git (mame par internich nastroju na principu gitops).

RATTKIN: za me zvitezila kombinace gitea+drone (CI) presne pro tenhle ucel - commit->container build+testy->push do registry..

Self Hosted CICD with Gitea and Drone CI - DEV
https://dev.to/ruanbekker/self-hosted-cicd-with-gitea-and-drone-ci-200l
Docker | Drone
http://plugins.drone.io/drone-plugins/drone-docker/

dalsi co muzes zkusit je self-hosted Gitlab, a pak treba Jenkins jako CI.. urcite je toho vic, bude zalezet asi na konkretnich pozadavcich

Ahoj, mám dotaz: jsme bezpečnostní firma, zaměřujeme se primárně na ochranu enterprise sítí (velký společnosti, telco, armáda, kritická infrastruktura) a jsme v tom myslím docela dobrý. Technologický partner, se kterým děláme a jehož řešení používáme, před rokem koupil společnost Twistlock, kterou přibral do portfolia a rozšiřuje tak služby i na oblast DevSecOps, ochranu kontejnerů a serverless. Hledáme někoho, koho zajímá oblast bepzečnosti v prostředí kontejnerů a kdo by byl ochotný poslechnout si jak tato oblast produktů funguje, případně dostal demo na vyzkoušení a probral s námi, zda je taková ochrana skutečně přidanou hodnotou a zda by něco takového používal.
Odměnou může být nějaká dlouhodobější spolupráce na projektech, možnost pořízení nástroje do firmy se zajímavou slevou, posun do oblasti DevSecOps atd. Případně se dá domluvit i na placeném otestování jako službě.

Elevator pitch:
Nástroj umožňuje zabezpečení celého životního DevOps cyklu, a to pro všechny běžně využívané platformy, aplikace i cloud prostředí (např. Docker, Kubernetes, GCP, Azure, AWS i Openshift). Mezi zásadní dostupné funkce patří mimo jiné:
1. Vulnerability Management – automatický nástroj pro zjišťování známých zranitelností napříč všemi hosty, kontejnery i funkcemi serverless computingu.
2. Cloud Native Firewall – integrovaný L4 a L7 firewall v prostředí Kubernetes, zajišťující vhled do síťové komunikace mezi kontejnery a mikroslužbami na úrovni aplikací, funkci IPS a mikrosegmentaci.
3. Runtime Defense – behaviorální analýza a automatizovaná detekce i prevence incidentů v prostředí kontejnerů.
4. Access Control – centrální monitoring Kubernetes, auditování hostů, inspekce logů a monitoring příkazů docker, sshd a sudo events.
5. CI/CD integrace – skenování vulnerabilit při zavádění nového kódu v CI/CD pipeline, např. prostřednictvím modulu do nástroje Jenkins.

Nesnažím se tu teď nic prodávat, jde mi vážně o možnost spolupráce a dostat od někoho z oboru reálný feedback. Kdyžtak pošta prosím.

Disclaimer: nikdo z nás není developer :-)

ONLINEQUE: disclaimer, jsem dlouho vyvojar a castecne uz fusuju i k adminum (protoze nasi admini se virtualizace boji) .. troufam si tvrdit, ze "developeri jsou lenivi" je hodne zjednodusene videni sveta, ktere Ti asi moc nepomaha, ne? dovedu si predstavit a zcela chapu, ze to bude platit v "nizsich urovnich" hierarchie, protoze jsou to juniori a maji uplne jine problemy a jinou perspektivu .. ale technicky dluh je problem stejne tak administratoru, jako vyvojaru, takze u nas treba tohle pada na hlavu seniornich programatoru ..

vize, kterou mame o tom, jak to adminum predame, je, ze si programatori reknou 'parametry', ktere ten image musi splnovat (aka musi tam byt napr JAVA_HOME, musi tam byt nahrane JDK 8+ na ktere JAVA_HOME ukazuje, a instalovane ssh + curl a verejne certifikacni autority, a uzivatel musi mit nahrany konkretni ssh klic) .. senior vyvojari pak vyjdou z takoveho image, nahraji si tam treba AS (tomcat, wildfly, nastavi ho aby se spoustel, atp) .. a tim vznikne "dev base image" ktery pouzivaji juniori, protoze tam maji to co potrebuji, jen si tam mountnou treba adresar se zdrojakama, rozsiri si ho o debug nastroje atp .. do produkce ale pujde ten baseimage od seniora s otestovanou a otagovanou verzi ..

Diky vsem za prinosnou debatu ;-), tim jsem asi tema vycerpal ;-}

ONLINEQUE: hele je to tak, zvlast pokud potrebujete veci ktery se blbe automatizujou. V my aktualni praci mame problem "podobnej" a realita je takova ze jsem na to tymu napsal sadu fire-and-forget utilitek, ale tu posledni mili s commitem do interniho repa proste musi udelat nakej clovek. Dulezity je mit na to dobrej proces a zbavit se veci co trvaji a jsou otravny, a pak to proste brat jako development effort.

ONLINEQUE: Budto na to mate automation (jakoze nightly upstream sync) a nebo na to mate cronjob co kazdou druhou nedeli udela ticket nahodny obeti a nezavre ho dokud obet nereleasne novej image :)