PIA Flashcards
kvalita SW se da merit
pocet stiznosti od uzivatelu
pocet chyb nalezenych v produkci
cena za udrzbu
naklady na dalsi vyvoj
validace
= aplikace dela to co si zakaznik preje
dosazeno pomoci komunikace se zakaznikem
verifikace
overeni ze aplikace dela co rika specifikace
- dosazeno pomoci testovani
- je dulezity s tim jak aplikace roste
- je nutne mit dobry vyvojovy cyklus a automatizaci
testovani - cíl
nalezt chyby, rozbit aplikaci
debuggovani
cil: nalezt priciny chyb
- jednoduche pri vyvoji
- tezke na produkci
- nemuzeme si jen tak pripojit debugger
- aplikace uz obsahuje realna data
specifičnost webové aplikace při testování
- muze se rychle menit (HTML, …)
- prirozene je to vicevlaknova aplikace
- potencialni muze celit vyssi zatezi nez je ocekavano (DoS utok)
=> nutne zotaveni
Unit Testy
- testuji malou cast kodu (vetsinou funkci nebo metodu)
- vytvareny programatory
- mely by byt na sobe nezavisly
- idealne jedna mnozina unit testu testuje jednu tridu/modul
Unit Testy - co testují
- korektni vstup
- krajni hodnoty
- nekorektni vstup (vyhozeni vyjimek, …)
= jedna metoda vetsinou vyzaduje vice testu
Pokrytí testy a důsledky
> 90% aplikacni logiky
pomahaji pri refaktoringu, pridavani funkcionalit, …
specialni pripad je kdyz se testy pisou jeste pred zacatkem programovani - kriticke systemy, nuti nas premyslet o navrhu aplikace
pri zajisteni nezavislosti testu mame dva pristupy
stubs
mocks
stubs
- specialni implementace zavislosti, ktere metoda vyzaduje
- napriklad vlastni implementace DAO rozhrani -> ulozeni dat do pameti
- nevyhoda je kdyz mame velkou aplikaci -> muze se stat ze budeme mit velky pocet stubu (musime se snazit je napsat co nejvic genericke)
mocks
frameworky dynamicky za behu vytvari obrazy rozhrani (ktere potrebujeme) s dynamicky definovanym chovanim
musime mit dobrou architekturu (SoC)
je jednodussi vytvaret objektu nez volat primo HTTP pozadavky -> nemusime mit aktivni HTTP server
levne
netestuji funkcionalitu celeho systemu
funkci testy
- testovani funkcionality aplikace jako celku
- typicky se definuji use-casy, scenare
- testovani proti bezici aplikaci
- v jednodussich pripadech plni funkci i integtacniho testu -> pri testovani testujeme i komunikaci s DB atd
Funkční testy - možnost
testovaci scenare
automatizovane funkci testy
testovaci scenare
krok po kroku co ma uzivatel delat
kam ma kliknout, jaky data kam zadat, jaky vystup ma ocekavat
vyvojari by nemeli psat funkci testy protoze vi jak se aplikace ma chovat a za jakych okolnosti pada
mely by je psat lidi co nejsou seznameni s tim jak aplikace vnitrne funguje
automazitované funkční testy
- scripty
- levne pri dlouhodobem pouzivani (SW nedela chyby)
- nakladnejsi na napsani a udrzbu (ID v HTML, XPATH, atd se meni pomerne casto)
- jednodusi pro testovani API webove sluzby
- postman, insomnia
- vyzva pri testovani Weboveho rozhrani
- moderni frameworky umi simulovat browser (i headless mode - nemusi se vytvaret okno)
Selenium
- sada nastroju pro testovani aplikace s pouzitim prohlizece
- muzeme je bud nahrat (manualne naklikat) nebo napsat pomoci IDE
- musime pri navrhu stranek mit v pameti ze se budou testovat -> napr definovat ID
Robot framework
- dovoluje definovat tetovaci scenare bez programovani
- “vygeneruje” kod (pomoci klicovych slov)
- naprvni pohled je videt co ten test dela
integracni testy
testovani ze pripojeni a posilani zprav mezi dvouma systemama funguje tak jak ma
vykonostni testy
- mely by se pouste proti production-like prostredi
- overeni ze aplikace zvladne zatez jako pri realnem provozu
- overeni ze nove verze aplikaci nemaji vykonostni dopad
- overeni jak se aplikace chova pri velke zatezi
smoke testy
- podmnozina nasi testovaci sady
- jejich ukolem je overi ze nasazeni aplikace probehlo v poradku, aplikace odpovida (zda se ze funguje)
- nesnazime se aplikaci zatizit
- nechceme po sobe nechat data v DB
- pouziva se na produkci (nechceme poustet celou testovaci sadu)
testy “nepouzitelnosti”
- testovani jak jednoduche je pouziti daneho UI - user experience
- zeptame se nekolik uzivatelu jak se jim aplikace pouziva
- zjistime jak uzivatele pouzivaji nasi aplikaci (nemusi byt tak jak jsme ocekavali)
- nedaji se automatizovat
typy logu
- aplikacni logy - zpravy popisujici co se v aplikaci deje (jaka trida, jaka metoda, …)
=> info, warn, error, debug, trace - pristupovy logy - vsechny volani funkci aplikace z vnejsi site (ip, date, response, POST, GET, …)
=> neobsahuje data (mohou byt citlive) - auditacni logy - sledovani co dany uzivatel dela
=> mohou obsahovat i citlive udaje
=> nejsou pristupne vsem lidem ve firme
=> kdo, kdy, co za akci, kontext (muze obsahovat data/udaji)
Moderni logovani
- logy se neukladaji primo na aplikacni server
- logy ukladame do cloud storage
- ma smysl napriklad pri skalovani aplikace
- mame jedno misto kam ukladat logy
- audit logy NESMIME ztratit (aplikacni logy ani tolik nevadi)
HTTP
- bezstavovy (server si nepamatuje kdo kdy poslal jakej pozadavek - nijak se neovlivnuji)
- textovy protokol
Verze:
verze 1 - nejvice pouzivana
nevyhoda: pro kazde stazeni souboru, poslani pozadavku => jedno TCP spojeni (desitek css, js souboru)
verze 2 - umoznuje posilat vice pozadavku pres jedno TCP spojeni
verze 3 - bezi ne pres TCP ale UDP
HTTP request
…
Example:
GET /index.html HTTP/1.1
Host: www.kiv.zcu.cz
typy HTTP metod
GET, OPTIONS, HEAD, TRACE - nemeni stav
OPTIONS vraci jake metody jsou k dispozici
POST, PUT, DELETE - meni stav
priklady hlavicek v HTTP requestu
host (povinna) - jmeno serveru
origin - jmeno serveru ze ktereho by request poslan
Content-Type - JSON, HTML, TEXT, …
Authorization - jmeno/heslo
HTTP response
<code></code>
…
Example: HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 14 ... Hello, world!</code>
typy kodu odpovedi:
200 - OK 204 - OK, ale neposilam ti zpet zadny obsah (napr u POST) 301 - redirect 401 - unauthorized (musis se prihlasit) 403 - forbidden (nemas prava) 404 - stranka nenalezena 500 - chyba na strane serveru
Cookies:
- zavadeji stavovost do jinak bezstavoveho protokolu
- klient odesila cookie spolu s requestem -> server vi ze se jedna o daneho klienta a nacte jeho session (napr z distribuovane cache v pripade horizontalniho skalovani)
- pouziva se napr i k sledovani uzivatelu - viz reklamy
- cookie obsahuje session ID
- muze vest k bezpecnostnim rizikum - ukradeni cookie
nastavení cookie přes http hlavičku
Set-Cookie: name=value [; EXPIRES=dateValue]
[;DOMAIN=domainName][;PATH=pathName][;SECURE][;…]
- secure: odesli pouze pokud se jedna o HTTPS
- expires: doba platnosti cookie
- domain: nastavene browserem, napr zcu.cz, kdyz pujdu na FB tak se cookie posilat nebude
- path: cesta pro kterou se ma cookie odesilat napr zcu.cz/admin
=> klient posle vsechny cookie pokud sedi domena, cesta, nevyprsela doba platnosti a pripadne se jedna o HTTPS (ne jen HTTP)
HTML WebStorage API
alternativa misto cookie
aplikace si mohou ukladat data v prohlizeni
nemusi se posilat na sever s kazdym requestem (narozdil od cookie)
pristupne z JS
data jsou ulozena dokud nezanikne session/nezavre se tab
Window.localStorage
sessionStorage.setItem('key', 'value');
let data = sessionStorage.getItem('key');
sessionStorage.removeItem('key');
sessionStorage.clear();
Forward proxy
requesty do externi site
nahrazuje IP addr zroje svoji IP
dovoluje restrikci kam se uzivatel pripojuje (napr z firemni site)
client → proxy → internet
Reverse proxy
requesty do externi site
nahrazuje IP addr zroje svoji IP
dovoluje restrikci kam se uzivatel pripojuje (napr z firemni site)
client → proxy → internet
Separation of Concerns
- kod ktery delat neco jinyho (jinou praci) by mel byt oddeleny (lepsi testovani, znovupouzitelnost, prehlednost)
- napr registrace uzivatele a validate stupnich dat by mely byt oddelene
Single Responsibility Principle
- kazda trida by mela zajistovat prave jednu cinnost
- mixovani funkcionalit vede ke spatnemu testovani, neprehlednosti, atd.
zapouzderni
- kazda instance ma svuj stav (dano hodnotamy atributu)
- zabranit prime zmene stavu instance tridy
- hodnoty atributu se maji menit vnitrne prostrednictvim definovaneho API
- automaticke generovani getteru/setteru porusuje princip zapouzdreni
- ve webovych applikacich komunikujeme pres rozhrani - nemusime znat implementaci
DRY
Don´t Repeat Yourself
- kopirovani kodu
- neustale prepisovani dokumentace
- prekreslovani schemat
- testovaci pripady
- po case nejsou synchronizovane s aktualnim stavem projektu
- > lepsi je puzit nastroj pro automaticke generovani
Dependency Inversion
trida A ma tesnou zavislost na tridu B:
- tezke nahradit tridu B za jinou
- lepsi mit zavislost pouze na rozhrani
- imlementaci pak muzeme zmenit
- velke urovne abstrakce by nemely zaviset na implementacnich detailech
Explicit Dependencies
- aplikace/moduly/tridy by mely specifikovat jake zavislosti potrebuji pro svuj beh
- napr Linux - balickovaci system, pip - requirements.txt, maven, …
- v pripade kodu je to konstruktor, parametry funkce
- funkce by mely mit jako parametr vsechny potrebne zavislosti pro sve vykonani
- tridy maji vsechny potrebne zavislosti definovane v konstruktoru - po jeji inicializaci je trida plne funkci - ma vsechny zavislosti; nepovinne zavislosti -> pres settery
Inversion of Control
- obecne nas kod neridi tok (beh) programu ale dela to napriklad nejaky framework
=> dependency injection - window GUI
- inversion of control != dependency injection
- dependency injection reprezentuje princip IoC a ne naopak
- priklad NEvyuziti IoC - platebni brana pozaduje unikatni ID kazde transakce - klient jej musi vygenerovat. Jak ma ale vedet ktere uz jsou zabrazene? -> generovani by mela dalat sama platebni brana
=> bylo by to v pohode v pripade jednoho zakaznika
=> mozne reseni: alokovat mnozinu ID pro daneho zakaznika ze kterych on bude => nahodne generovat unikatni ID
Dependency Injection
hlavni myslenka: oddeleni kodu pro vytvareni objektu a jejich nastavovani zavislosti od zbytku
- v kodu jsou nadefinovane zavislosti pomoci kontruktoru
- pak mame separatni konfiguracni tridu nebo soubor (napr xml nebo json) kde definujeme “naskladani” zavislosti jakych budeme potrebovat
- snadne nahraznovani zavislosti za jine (vime presne kam jit a kde to zmenit)
- napriklad pri testovani nahradime DB nejakou in-memory DB
- povinne zavilosti - pres konstruktor (@RequiredArgsContructor)
- dobrovolne zavislosti - settery (@Autowired)
- injectovani primo do atributu (nemusime vytvaret ani konstruktor ani setter) - ani-pattern (ve Springu @Autowired); spise nepouzivat
Service Lookup
- alternativa k DI
- existuje objekt ktery zna vsechny instance v danem projektu
- dao = applicationContext.getBean(“dao”) - vraci instance daneho rozhrani podle jmena ktery pak muzeme priradit jako hodnotu atributu v dane tride
Dependency Injection vs Service Lookup
- DI vyuziva princip IoC
- DI muze byt tezsi na debuggovani
- Service Lookup neni tak flexibilni ale je jednodussi na pouziti
kdybychom to implementovali sami - pouze mapa instanci - Service Lookup vyzaduje mit instanci na globalni objekt ktery drzi vsechny instance
=> v pripade knihoven vynutime uzivatele aby taky pouzival Service Locator
Web Application Architectures - dva pohledy
1) jak je aplikace nasazena - jeji repliky, skalovatelnost, atpd.
=> nasazeni + udrzba
2) jak je aplikace uvnitr organizovana - monolit, micro-services, …
Web Application Architectures - škálování
horizontalni skalovani - mame vice replik dane aplikace
vertikalni skalovani - tunime dany server - vic ram, vic CPU atd
Monoliticka aplikace
- aplikace je jeden funkci celek, ktery se sklada z vice modulu
- dela vice cinnosti napr registraci uzivatele, ucetnictvi, tisknuti dokumentu atd
- jednodussi na testovani, debuggovani, vyvoj - mame jen jedno IDE (repozitar), nasazeni
Monolitická aplikace - škálování
- v pripade skalovani musime skalovat celou aplikaci i kdyz jsou vytizenne napr jen nektere jeji casti
- horsi to zacne byt az se aplikace zacne zvetsovat
- neprehlednost kodu, prace vice programatoru
- vyzauje dobrou vnitrni architekturu a rozlozeni trid
- aplikace dlouho startuje
- cela aplikace musi byt napsana s pouzitim stejne technologie
- pri zmene frameworku musime celou app prepsat
SOA - popis
Service-Oriented Architecture
- pokus o vyreseni problemu s monolitickou aplikaci
- kazda service je black box
=> komunikujeme pouze pres rozhrani
SOA - typy komunikace, protokoly
Typy:
1) na primo
2) pres frontu zprav - odpoved je jen “jo dobry prijal jsem zpravu - nekdy ji zpracuju”
Protokoly:
HTTP, WebSocket, SOAP, AMQP, MQTT, Stomp
SOA - nevýhody (5x)
1) v pripade SOA komunikujeme pres sit
=> musime mit v pameti transakce (kdyz spadne pripojeni napr), bezpecnost (HTTPS)
- kazda service by mela byt bezstavova - bud vratime error nebo odpoved
2) tezsi debuggovani - danou sluzbu nemusime spravovat my
3) casto jedna aplikace = vice repozitaru, nestaci jedno IDE (ruzne technologie)
4) integracni testy jsou slozitejsi
=> NEJHORSI PRIPAD JE KDYZ DO TOHO INTEGRUJEME MONOLITICKOU APLIKACI - prinasi nevyhody obou reseni
5) pri nastartovani muze zalezet na poradi stupusteni jednotlivych sluzeb
Microservices - popis
- jedna aplikace rozdelena do vice malych sluzeb
- kazda sluzba je separatni proces ktery muze/nemusi bezet na stejnem stroji
- zalozeno na Unixove filozofii - deleje jednu vec a delej ji poradne
Mirkoservices - výhody (5x)
1) jednotlive mikro sluzby jsou jednoduche na vyvoj a udrzbu
2) mikro sluzby nemusi byt napsane ve stejne technologii
3) jednotlive mikrosluzby mohou spravovat jine tymy lidi
4) nemusime skalovat celou aplikaci ale jen dane vytizene mikro sluzby
5) pri aktualizaci nemusime vypinat celou aplikaci
Mikroservices - nevýhody (5x)
1) tezsi na nasezeni kvuli tomu jak je aplikace distribuovana
=> diky Dockeru mame testovaci prostredi (dost pomáhá)
2) vyzaduje intenzivni integracni testy
3) potencialne muze byt vice nakladna - vice serveru, pripojeni
4) kazda mikro sluzba by mela mit sve uloziste
5) use-casy mohou pokryvat vice mikrosluzeb -> nutna dobra komunikace jednotlivych tymu
Monolith vs Microservices
- zalezi jaky mame use-case
- monolit je lehci na vyvoj, nasazeni a udrzbu - dokud aplikace prilis nenaroste
- pro male aplikace se nevyplati komplexita mikro sluzeb
- pro velke aplikace uz ano
Common Web Application Design Principles
- kod aplikace je rozdelen do vrstev
- jednotlive vrstvy implementuje a zapouzdruji danou funkcionalitu
- komunikace mezi vrstvami probiha pres rozhrani -> jednodussi nahrazeni za jine implementace (napr jiny typ DB) a testovani
Application Layers – Clean Architecture
- hlavni pavidlo: zavislosti jdou vzdy ze shora dolu
- entities: data (objekty - napr objednavky) sdilene napric systemem
- Use Cases: co se da delat nad danyma objektama - aplikacni logika
- Controllers: pristup ven/dovnitr; rozhrani pro pristup k databazi; vytvareni DAO
- posledni vrstva: externi frameworky, drivery
bezne pouzite vrstvy architektury
1) prezentacni vrstva
2) aplikacni vrstva (aplikacni logika)
3) datova vrstva
dulezite mit na pameti
- bezpecnost
- transakce
- logovani
datova vrstva resi:
- format ukladani dat
- relacni schema v pripade relacnich DB, format v pripade souboru, …
- mapovani na aplikacni objekty (tridy - DTO, entity)
cteni/zapis
business logika resi:
- implementace aplikacni funkcionality
- zmena stavu entiti
- volani funkci datoveho uloziste (nizsi vrstvy)
prezentacni vrstva resi:
- vstup od uzivatele
- vola nizsi vrstvu (aplikacni logiku)
- prezentuje vysledky uzivateli
MVC
Model - data a aplikacni logika
View - zobrazuje data z modulu
Controller - zpracovava vstupy od uzivatele
User - uses -> Controller
Controller - manipulates -> Model
Model - updates -> View
View - sees -> User
Model-View-Presenter
- odebrani propojeni view a modelu
- Presenter je Controller ktery slouzi jako prostrednik mezi View a Modelem
View predstavuje jednotlive Widgety (tlacitka, input field, …)
=> kazdy widget ma vlastni presenter ktery obslouzi danou udalost a nastavi nova data na zobrazeni - napriklad kazdy formular mas svoji obsuznou funkce - Presenter, ktera se zavola pri odesilani formulare, data se odeslou na server a po prijeti odpovedi se zobrazi vysledek uzivateli
Model – View - ViewModel
dalsi zpusob oddeleni vazby mezi modelem a view (ASP.NET/WPF)
ViewModel poskytuje:
- data pro view
- formatuje data z interniho modelu na nejakou zobrazitelnou podobu
- Prikazy - reakce na vstup od uzivatele (prikazy jsou namapovane na tlacitka, input fieldy atd.)
- komunikace s View
- zmena view funguje pres DataBinding a Notifikace
- komunikace s Modelem
- ViewModel vola funkce module (aplikacni logika)
- ViewModel je zpusob implementace Clean Architecture na prezentacni vrstve
Cross-Cutting Concerns - architektura
jista funkcionalita je vyzadovana na vsech vrstvach
1) Bezpecnost - user authentication
=> nutnost implementovat jak na severu (operace nad daty)!! tak i na strane klienta (co vidi/nevidi)
2) Logování
=> vsude abychom vedeli co uzivatel a aplikace delaji
3) Trasnakce
=> aplikacni a datova vrstva musi zajistit atomicnost operaci
Naivni implementace techto veci ma za nasledek tezsi testovani, drahe zmeny, …
Cross-Cutting Concerns - přístupy
1) zavislost na rozhrani (API) + konfigurace
- aplikace je zavisla pouze na rozhrani loggeru a konkretni implementace je pote definovana v konfiguraci -> jednodussi testovani a vymena
- problem je napriklad kdybychom vyvijeli knihovnu -> nutili bychom uzivatele pouzivat konretni implementaci napr loggeru
2) Aspect-Oriented Programming (AOP)
AOP
Aspect-Oriented Programming
Co je to aspekt?
- module (typicky trida) co obsahuje kod ktery bychom museli rozkopirovavat do vsech trid (vsude kde ho chceme pouzit)
Frameworky zajustuji ze ten kod napiseme na jednom misto a on se pote dostane na vsechna mista kde ho chceme mit
- neco jako makra v C
- napriklad kdyz budeme logovat - cheme zalogovat casove razitko, nazev metody a logovaci zpravu => tenhle kod chceme napsat jenom jednou
- nebo napriklad bezpecnost - uzivatel musi mit urcitou roli kdyz chce volat konretni metodu - v jave se pouzivaji anotace
Terminologie AOP
1) Join Point: misto vykonani aspektu (typicky volani metody); misto napojeni
2) Pointcut: predikat ktery vyjadruje to kdy se ma ten aspekt provest - ktery vsechny metody to ma postihovat
3) Advice: kdy se ma provest aspekt v ramci volani - before, after, around, ..
around: napri pri logovani - metoda bere objekt jako parametr - zalogujeme (before), na konci zalogujeme i navratovou hodnotu (after)
Weaving
U AOP - způsob jakým zavoláme kód aspectu
1) pri kompilaci
- kompilator to musi dovolovat (napr kompilator javy to neumi)
- defakto jako makra v C
- problem pri debuggovani
- je rychlejsi nez ostatni zpusoby
2) pri nacitani
- zajistuje class loader (analyzuje binarky a hleda aspekty pro pointcut)
- nacte modivikovanou verzi class souboru
- vyzauje specialni class loader
- problem pri debuggovani
3) za runtime
- bez modifikace kodu
- casto pouzivano v Jave
- dela se to pres volani proxy trid (namisto puvodnich objektu), ktere obsahuji kod aspektu + zavolaji puvodni metodu
+ vyhoda: puvodni trida je nezmenena
- nevyhody:
1) vice pameti (vytvareni proxy trid)
2) volane metody musi byt public -> nemozne vytvorit pointcut pro private metody
3) nelze pouzit pokud volame metody v ramci jedne tridy (uvnitr) -> vzdycky musi volani probehnout z vnejsku
Vrstva persistence dat
Vrstva perzistence dat je v architektuře vícevrstvých aplikací zodpovědná za poskytování dat aplikační vrstvě a zajištění jejich perzistence. Nejčastěji bývá realizována pomocí relační databáze, může jít však i o jiný zdroj dat (např. CRM nebo ERP systém, či jiný informační systém).
Dopad vrstvy persistence dat na mimofunkční požadavky:
1) výkon (performance)
2) bezpečnost (security)
- nachází se vetšinou na jiném místě než aplikace
- nechceme aby je někdo získal (velká hodnota dat)
3) Trvanlivost
nutnost se zotavit i z HW nehod
Možnosti uložení dat
1) Relační databáze
2) NoSQL
3) Souborový systém
Další možnosti:
- Alfresco
- Elastic Search
- Amazon S3
- Object databases
Relační databáze
- MariaDB, MySQL, PostgreSQL, OracleSQL, Derby, H2, Microsoft SQL Server
- pro ukládání dat u kterých existuje vazba (tabulky - relace)
- Relace potřebujeme protože v aplikacích potřebujeme znát vazby mezi nimi
NoSQL
- databázové enginy se specifickým použitím
- lépe škálují než relační DB, dobře replikují
- špatná podpora transakcí
1) Document-based: MongoDB, CouchDB
struktura podobná JSON
- pro data s fixní nebo stromovou strukturou
- nehodí se pokud je potřeba znát vazba mezi daty
- naopak se hodí pokud jednotlivé záznamy nepotřebují odkazovat na jiný
2) Key-Value: Redis
- pro Cache
- rychlý (klíč - indexy)
3) Wide-Column: Cassandra, DynamoDb
- organizují data podle sloupců namísto řádků
- použití pro případy kde je více zápisu než čtení a nedělají se aktaulizace
4) Grahp: Neo4J, Giraph
- pro grafy (mapy, ontologie)
- rozpoznávání obrazu, medicínské softy (zadají se příznaky a výsledek je např. styl léčba)
Souborový systém
- tam kde běží aplikace
- při více instancí je problém se sdílení dat
- těžké škálování, přístup, zvětšení GB při runtime
- omezené indexování, cachování, dotazování
Další možnosti uložení dat (kromě SQL, NoSQL, souborů) (4x)
1) Alfresco
- souborové úložiště
- metadata k souborům, dotazování, škálování
2) Elastic Search
- storage engine pro vyhledávání dat, analýzy, skvělý pro indexaci logů nebo big dat
3) Amazon S3
- objektové úložiště, dobrý pro data ke kterým se moc často nepřistupuje (backupy)
4) Object databases
- ObjectDB, pro ukládání objektů, dědičnost, metody pro práci s objekty
Datový model
- Ovlivňuje výkon (rychlé čtení/zápis)
- požadavky na konzistenci a prostorové nároky
- návrh podle toho co budou běžné dotazy
1) Normalizovaný model
- žádné duplicity informace (méně místa na uložení, rychlejší aktualizace)
- čtení více dat vyžaduje JOIN nebo více dotazů (horší výkon)
2) Jedna tabulka navržena write-once, čti a analyzuj později (př. Warehouses)
- předem vypočítává data, duplikace
- pomalé aktualizace, těžké udržet konzistenci
- rychlé čtení
Bezpečnost dat - 2 problémy
1) může někdo zachytit komunikaci s úložištěm?
2) může někdo obelhat aplikaci aby vykonala nechtěný dotaz/zápis?
- SQL injection - dotaz rozdělí pomocí řetězce na dva
- ochrana - validace parametrů, nastavení přístupových práv, neopouštět složky s daty a neumožnit neprocházet filesystem
Výkon při práci s daty
- jak dlouho zabere jeden dotaz?
- nepoznám pokud mám málo dat a uživatelů
- nastane pokud mám složité dotazy
- NoSQL DBs rychlejší kvůli jednoduchým dotazům
- závisí na datovém modelu
Indexy
- rychlejší vyhledávání
- kolik? které položky budou indexy?
- naopak ještě zpomalím zápis
Důležitá optimalizace - změřit a zjistit kde je pomalá část aplikace a pokusit se zrychlit
Výkon při práci s daty
- kolik dotazů posílám?
- problém SELECT N+1 - jeden dotaz získá N záznamů a pro N záznamů získám dalších N pro detaily
- Počet dotazů by měl být konstantní nehledě na to jak velký seznam zobrazujeme (pro 1 objednávku nebo 100)
Konzistence dat
Při více akcí v úložišti nemusí všechny skončit úspěšně
- pokud nějaká akce selže musím provést rollback změn
Transakce + ACID
sekvence akcí která proběhne celá nebo vůbec
!!!Každá funkce aplikační logity by měla běžet jako samostatná transakce!!!
Atomicity - atomická operace - celá nebo vůbec
Consistency - změny transakce neporuší integritu
Isolation - Více paralelních transakcí se nemohou ovlivňovat souběžně
Durability - po (úspěšných) transakcích pád systému neovlivní změny způsobené transakcemi
Úrovně izolace transakcí (3x)
1) Dirty Reads
- T1 transakce může přečíst změny T2 transakce která ještě není commitnutá
2) Nonrepeatable Reads (U druhého dotazu můžeme vidět změny v řádkách)
- T1 čte data
- T2 commitne aktualizaci/odstranění těchto dat
- T1 zopakuje dotaz a získá jiná data
3) Phantoms (oproti nonrepeatable reads mohou při druhém dotazu přibýt i nové řádky)
- T1 čte data
- T2 commitne vložení/aktualizaci která modifikuje atributy pro vyhledávání
- T1 zopakuje dotaz a získá odlišné výsledky
Zámky v databázi
1) Čtení
více transakcí může číst paralelně stejná data
při zápisu musí transakce počkat až se záznam uvolní od všech čtenářů
2) Zápis
Při zápisu se záznam zamkne pro čtení i zápis ostatním dokud neskončí
Úrovně zámků
1) Read uncommitted
- ruší izolaci, umožňuje paralelizaci
- jen pokud budou jen paralelně čte
2) Read committed (většinou výchozí nastavení - kompromis)
- čtení jen committed dat
- transakce drží čtecí zámek pokud pracuje se záznamy
- transakce drží zápisový zámek dokud neudělá commit nebo rollback
méně paralelizace
3) Repeatable read
- transakce drží čtecí i zápis. zámky drží dokud nenastane commit nebo rollback
- update není možný dokud ho jiná transakce nepustí zámek
4) Serializable
- transakce zamkne záznamy které spadají do rozsahu dotazu
- nelze upravovat existující záznamy ale ani je přidávat
Správa spojení s databází
- Zabraňuje otevření vždy nového spojení do db pro každý požadavek
snižuje režii pro připojení - Vhodné pokud se atributy připojení nemění
- Connection pool - aplikace při startu otevře několik spojení
- Při připojení uživatele si vyžádá spojení z connection poolu přes který posílá dotazy
- Minimální počet: zaručený počet připojení
- Maximální počet: kolik připojení je max povoleno, pokud je aplikace zatížená
- Timeout: při nečinnosti je to doba po kterém se uvolní
- Check query: kontrola zda je je spojení otevřený
ORM vs SQL
JDBC priklad:
Statement psmt = new PreparedStatement(“SELECT * FROM Users”);
ResultSet set = psmt.execute(); List users = new ArrayList();
while(set.next()) {
String name = set.get(“name”);
String email = set.get(“email”);
User u = new User(name, email);
users.add(u);
}
ORM priklad:
List users = repository.findAll(User.class);
ORM definice
- premosteni mezi objektovym a relacnim svetem
tridy = tabulky
atributy = sloupce
nejsou stejne! (dedicnost, public/private)
ORM výhody a nevýhody
+ zjednodusseni - vyvojari se nemusi starat o to jak vypada SQL
+ jednoduche na pouziti
- past pokud nerozumime relacnim databazim nebo frameworkum - proste tomu jak to vnitrne funguje
ma to smysl?
pokud je aplikace mala - je pomalu i lepsi si SQL + mapovani psat sam
typy ORM
1) plne automatizovane - dela uplne vsechno
- jednoduche na pouziti
- slozite na SPRAVNE pouziti
2) manualni ORM
- programator si musi psat SQL
- ORM pomaha s mapovanim objektu
Výkonost ORM
ORM je obecne pomalejsi
- asociativni nacitani (napr Post ma Liky) -> pres ORM jeduche, defakto automaticke, ale na pozadi vyzaduje vice SQL dotazu -> jeste vetsi problem je to pri hirearchii trid -> velky pocet pristupu do DB
- reseni problemu SELECT N+1 = LAZY loading
= nacti mi jen zakladni atributy a nenacitej asociativni objekty (vzdy kdyz mame relaci *-to-many) - nevyhoda: kdyz pote zavolame getter -> vyusti v dodatecne SQL (donacteni)
v pripade relace *-to-one je lepsi pouzit LEFT JOIN nez vice selectu - mame pouze jeden SQL dotaz ale zas muzeme prenaset duplicitni data v pripade ze jeden uzivatel ma vice adres (obecne u *to-many)
problemy mezi relacnim a objektovym svetem (4x)
1) v relacni DB neexistuje koncept private atributu -> vsechno je public -> kdokoliv se k DB pripoji si muze precist jaky sloupecky chce
2) abychom mohli tridu ulozit do DB pouzijem gettery/settery -> poruseni OOP navrhu
- dalsi moznosti je napr pouzit DTO (data transfer object) -> ulozime jen cast tridy do DB, po nacteni namapujeme DTO na reaalny objekt -> casove pomalejsi
3) dědičnost
- samostatná otázka
4) prijdeme o typ vztahu (pompozice? agregace?)
- v pripade tridy je prochazeni jeho komponent jednodussi nez kdyz musime v DB “skakat” pres vice tabulek
-> vsechny tyto nedostatky = leaky abstraction
Problém dědičnosti v ORM + 3x řešení
= realcni DB neumi vyjadrit dedicnost
moznosti reseni:
1) kazda trida v dane hirearchii = 1 tabulka
- duplicitni atributy
- pri prochazeni hierarchii musime volat vice dotazu nad danou DB
2) jedna tabulka ktera obsahuje vsechny tridy z dane hirearchie
- hodne “blank” policek
- neefektivni zpusob uchovavani dat
- jednoduchy SQL query
3) jedna tabulka pro rodicovskou tridu
- samostatne tabulky pro potomky
- propojeni pres cizi klice
- nejsou duplicitni sloupce
- pri vyhledavani musime delat join
- efektivni ulozeni
proc resit bezpecnost z pohledu webovych stranek?
- muzeme byt pravne stihani
- vede ke ztrate duvody
- vede ke ztrate financi
zakladni koncepty bezpecnosti (5x)
1) sifrovani/hashovani dat
2) omezit pocet zpusobu interakce s danou aplikaci
3) pouzivat dobre otestovane a zname knihovny
=> lepsi nez se neco pokouset psat sam
4) cist bezpecnostni novinky ohledne danych knihoven
5) bezpecnost v podobe nahodne cesty kterou by utocnik musel uhodnout neni bezpecnost!
oblasti bezpecnosti (4x)
1) prihlaseni uzivatele
2) ochrana citlivych dat
3) bezpecnost kodu (XSS)
4) prenos dat
bezpecnosti prihlaseni uzivatele - charakteristik
- muze byt clovek/SW
- muze byt implementovani napr pomoci Aspektu
- zajisteni ze uzivatel ma vymezena prava na zaklade jeho role
level of assurance = LOA
ruzne stupne overeni ze se jedna o daneho uzivatele
1) high-level assurance
- banky napr vyzaduji prihlaseni uzivatele + kdyz chce uzivatel provest transakci -> jeste jednou zadat heslo; pri registraci musime do banky s obcankou, pasem atd.
2) low-level assurance
e-shopy, blogy, …
prihlaseni pomoci Google, GitHub, …
zpusoby autentikace
- jmeno & heslo
- certifikat
- HW klicenka (telefon, USB)
- pomoci tokenu (SMS, email)
- vice-faktorova autentizace = kombinace predchozich
mozne problemy pri prihlaseni uzivatele:
- uzivatel se muze prihlasis s nevadidnimi udaji (napr SQL injection = “password = ‘; OR 1 = 1”)
- uzivatel muze delat nepovolenou operaci nad datty
- uzivatel vidi neco co by videt nemel (ma pristup na urcitou stranku)
- ukradeni totoznosti (CSRF)
CSRF
Cross-Site Request Forgery
utocny kod ktery donuti prohlizet vykonat operaci (poslat pozadavek) na stranku, kde ma uzivatel otevrenou a prihlasenou session
autentizace je sdilena pro jeden proces daneho prohlizece
kdyz se prihlasim na portal a otevru 3 dalsi taby v prohlizeci -> ve vsech budu uz prihlaseny
same-origin policy
frontent muze poslat pozadavky pouze na tu stranku odkud jsme si stahli JS, CSS, HTML -> jeho puvod
cross-origin request
server muze dovolovat pristup (posilani pozadavku) i z jinych zdroju
- vycet toho odkud muze server prijmat pozadavky je definovan v hlavicce HTTP kterou prohlizec nedovoluje nijak zmenit
- soucasti muze byt i sezman povolenych operaci (metod)
zpusoby zabezpecni proti CSRF
1) overeni ze source origin odpovida target origin
2) posilani synchronizacniho tokenu (CSRF tokens)
3) Double Submit Cookie
4) nepouzivat ani session ani cookie
zpusoby zabezpecni CSRF:
overeni ze source origin odpovida target origin
- jine stranky nemohou na dany server pristupovat
- overeni pres HTTP hlavicky
- origin = kombinace protokolu, hostname a portu
=> napr https://mypage.com/index.html neni to same jako https://mypage.com:8080/index.html - target - zalezi jestli je cilovy server za nejakoy proxy
- kdyz neni proxy -> funguje jednoduse, neni s tim problem
- pokud je proxy
=> vyzaduje nastaveni serveru (aplikace)
=> hlavicka host bude obsahovat URL serveru, ktery tam vlozi proxy, puvodni URL bude v X-Forwarder-Host - funguje v pohode pokud mam omezenou domenu, co kdyz ale mame verne API a chceme povolit pristup komukoliv -> potrebujeme jiny zpusob zabezpeceni
- spolehame se na prohlizec ze same-origin policy implementuje bez chyby
zpusoby zabezpecni CSRF:
posilani synchronizacniho tokenu (CSRF tokens)
- nahodne vygenerovany token pro kazdy request/pri prihlaseni uzivatele
- musi byt dostatecne slozity aby ho nikdo nemohl uhodnout
- ulozen v session na strane serveru
- vlozen do HTML stranky ktera se posila uzivateli, HTTP hlavicek
- kazdy request musi obsahovat dany token
=> viz semestralka reset hesla - potencialne nebezpecne v pripade GET, DELETE pozadavku
=> token musi byt soucasti URL -> je viditelny, prohlizec si ho uklada do historie, uklada se do logu, …
zpusoby zabezpecni CSRF:
Double Submit Cookie
- nahodne vygenerovani token (dostatecne nahodny) pri prvni requestu
- ulozen prostrednictvim cookie na strane klienta
- vlozeny do HTTP hlavicek/HTML s kazdym odeslanym dotazem
- hodnoty v parametrech a odeslana cookie se musi shodovat (server tyto hodnoty pouze overuje -> nemusi si hodnotu tokenu ukladat do session)
- jina stranka nemuze prepsat cookie jine stranky
- musime mit dobre nakonfigurovany cely system
- v pripade vice aplikaci v jedne domene si cookie muzou menit navzahem (je sdilena) -> podvrzeni jedne stranky muze zpusobit potencialni CSRF utok
zpusoby zabezpecni proti CSRF:
nepouzivat ani session ani cookie
- token se vytvori pri prihlaseni uzivatele
- kazdy request obahuje zasifrovany token a server jej rozsifruje a zkontroluje validitu
Problém nezabezpečené komunikace
- vetsina aplikace vyzaduje posilani citlivych udaju mezi klientem a serverem (heslo, token, …)
- pokud mame nezabezpecnenou komunikaci, kokoliv na ceste od klienta k serveru si ji muze odposlechnout
- > komunikace musi byt zasifrovana
Man in the middle attack
1) Alice sends a message to Bob, which is intercepted by Mallory:
Alice “Hi Bob, it’s Alice. Give me your key.” → Mallory Bob
2) Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:
Alice Mallory “Hi Bob, it’s Alice. Give me your key.” → Bob
3) Bob responds with his encryption key:
Alice Mallory ← [Bob’s key] Bob
4) Mallory replaces Bob’s key with her own, and relays this to Alice, claiming that it is Bob’s key:
Alice ← [Mallory’s key] Mallory Bob
5) Alice encrypts a message with what she believes to be Bob’s key, thinking that only Bob can read it:
Alice “Meet me at the bus stop!” [encrypted with Mallory’s key] → Mallory Bob
6) However, because it was actually encrypted with Mallory’s key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob’s key, and forward it to Bob:
Alice Mallory “Meet me at the van down by the river!” [encrypted with Bob’s key] → Bob
7) Bob thinks that this message is a secure communication from Alice
sifrovani komunikace pomoci SSL/TLS
- asymetricka sifra se pouziva pro vymenu symtreckeho klice
- po vymene spolecneho klice chceme pouzivat symetricke sifrovani -> rychlejsi
- protokoly vyssich vrstev zustavaji nezmenene
- kazdy server muze pouzivat SSL/TLS -> to ale nenzamene ze je bezpecny -> potrebujeme overit jeho certifikat
- CA (certifikacni autorita) je zodpovedna za vydavani certifikatu
=> musi zjistit ze skutecne jsme to my vlastni ten server -> rekne neco jako “vystav mi tenhle soubor na tuhle adresu” -> tim dokazeme ze mame kontrolu nad danym serverem - sluzby si mohou vytvorit vlastni certifikat pro interni testovani v ramci vyvoje
- knihovny kolikrat odmitaji pripojeni kdyz neni verohodny certifikat -> da se to vypnout -> ale je to silne nedoporucovany
problém nevalidace uzivatelskeho vstupu
kazdy zpusob interakce s nasi aplikaci je potencialni bezpecnostni riziko
1) injection utoku (napr SQL)
- vetsina frameworku poskytuje funkce na validaci vstupu od uzvatele pred tim nez jsou poslany do SQL dotazy
2) Cross-Site Scripting (XSS)
- Client-side script injection attack
- neosetreni vstupu od uzivatele
- viz posty v semestralce -> po vlozeni kusu kodu ho prohlicec vykonna - utocnik muze tak nasi aplikaci donutit komunikovat se serverm jinak nez chceme
ochrany proti CSRF utokum nebudou funguovat protoze jsme donutili tu samotnou aplikaci vykonavat utocny kod
Webová služba - motivace
Jak propojit různé aplikace?
Napsanou různými programovacími jazyky
Nasazenými na různé platformy
Vytvořena různými lidmi
Webová služba - charakteristika
- SW navržený pro komunikaci mezi stroji po síti
- Je to rozhraní popsané ve strojově zpracovatelném formátem
- Systém komunikuje s web. službou
- Black box pro klienty
- Bezstavová - lehčí design a škálovatelnost
Možnosti připojení aplikace na web:
1) Standardizované otevřené protokoly (HTTP, SOAP)
2) Standardizované otevřené datové formáty (JSON, XML)
Výhody:
Nestarám se o to v jak a v jaké technologii jsou ostatní applikace napsané
Agent ve webových službách
- konkrétní implementace pro posílání a příjímání zpráv
- stejná web. služba může být realizována více agenty (v různých prog. jazycích)
- realizace web. služby/klienta
Užití webových služeb
- znovupoužití komponent (autentizace, počasí)
- propojení s jiným SW
=> nezávislý na programovacím jazyce (web. standardy)
=> nezávislý na platformě (Raspberry PI, Win, Linux)
Implementace WS API v MVC
- Controller definuje endpoint a zpracovává požadavky
- View je format který posílá data např. soubor JSON
SOAP - charakteristika
- komunikační protokol
- definuje formát kterým posílá data - XML-based
- definuje kodování pro datové typy
SOAP - složení
- Envelope (Obálka) obaluje SOAP zprávu
- Header (hlavička) poskytují další funkce pro zprávu
=> zabezpečení (podpisový certifikát)
=> metadata (jazyk zprávy) - Body (tělo) zprávy
- Fault chybové hlášky pokud nastala chyba
SOAP - výhody
1) flexibilní
2) rozšiřitelný
3) XML - definuje jak má vypadat takže definuje fixni strukturu, namespace, XSD
SOAP - nevýhody
1) nestandardizovaný API design (pro každá služba může mít jiné API - jmenné konvence)
2) XML
=> velikost zprávy a složitost roste rychleji s počtem dat
=> nepřehledný pro mnoho dat a mnoho zanoření
=> Výkonostní issue - parsování
WDSL - charakteristika
webservice description language
- xml schéma popisující web. služby
- Neomezuje se na SOAP ale běžně se s ním používá
- umožňuje generování kódu
WDSL - elementy
1)
=> (xml schéma) definuje datové typy používané web. službou
2)
=> obálka okolo dat. typů, definuje datové operaci
3)
=> možné operace, zprávy zahrnuté jako vstup, výstup a při chybě
4)
=> vazba na protokol (SOAP)
REST - charakteristika
Representional State Transfer
- architektonický vzor pro návrh web. služeb
- nejedná se o protokol
- sada pokynů pro návrh API rozhraní
- cíl: vytvořit API s jednoduchým použitím
zdrojově-orientovaný
=> endpoint pro Like: /posts, /users, /categories - použití HTTP metod (GET, PUT, DELETE, …)
- Bezstavový
- Podobný adresářové struktuře
REST - nevýhody
není to silver bullet…
- potřeba znát user-casy před návrhem API
- Potencionálně nadměrné/nedostatečné načítání (fetching)
PUT vs POST
POST
- známe přesné umístění resource: POST /posts/ HTTP/1.1 (generování id pro zdroj)
- při opakovaném volání POST server negarantuje že proběhne vždy stejně pro stejný požadavek
- PUT pokud nevíme kde přesně se nachází resource: PUT /posts/12 HTTP/1.1
- garance že probehně více požadavků stejným způsobem
- je indempotentní operace
HATEOAS
Hypertext As The Engine Of Application State
- možnost užití hypertext napříč API
- Dobré API definuje entry-pointy a množinu zdrojů (entit)
- Init volání entry-pointu vrátí seznam odkazů na zdroje (klienti nemusí znát strukturu předem)
GraphQL
API query language (i runtime)
= pokus vyřešit problémy RESTful API
- Silný typový systém
- over/under fetching
GraphQL - výhody a nevýhody
+ netřeba znát všechny use-case při návrhu
+ není over/under fetching
- špatné škálování
- formát jen JSON
- složité ukládání do cache - každé API se chová jinak
- těsná vazba mezi klientem a serverem
GraphQL vs REST
GrapgQL je obvykle lepší než REST
GraphQL:
- rychlý vývoj aplikací bez server-driven state
REST
- distribuovaný systém
- Se silnou potřebou řídit stav na serveru
- Vysoké požadavky na škálovatelnost a výkon
Webové sockety - motivace
- je potřeba často si posílat zprávy s klientem nebo je nutné notifikovat klienta o nové události
- server jinak posíla zprávu klientovi jen pokud od něj dostane požadavek
- klient se jinak musí periodicky ptát na nové info - při více uživatelů se může zahltit server
Polling
- klient často posílá požadavek na data a server hned odpoví zda má nebo ne
Long-Polling
- odpoví pokud bude mít co poslat klientovi nebo vyprší timeout a pošle že nic nemá co by poslal
- neýhoda že spojení drží než odpoví klientovi
Webové sockety - charakteristika
- zprávy se posílají v rámcích (obálkách)
- oboustranný komunikační protokol (založený na TCP)
- navázání spojení pomocí HTTP protokolu (ws:// nebo wss:// (secure))
- používá stejný port jako HTTP 80 a 443
DevOps - význam zkratky
Deployments, operations
= vývoj a provoz v těsném kontaktu
DevOps - ovlivňuje: (3x)
1) bezpečnost
2) výkon
3) downtime během aktualizace
DevOps - protředí (4x + 1)
1) Development
2) Testing
3) Před-produkční
4) Produkční
+ speciální testovací prostředí
Development prostředí
- používají developeři k testování na svém počítači
- požadavek na výkon: nízký
- požadavek na stabilitu: nízký (vývojáři si mohou kdykoliv aktualizovat)
- požadavek na bezpečnost: nízký (nereálná data)
Testing prostředí
- používají testeři, vlastníci produktu k validaci a verifikaci implementace
- požadavek na výkon: nízký-střední (potřeba odpověď v přiměřeném čase, málo uživatelů)
- požadavek na stabilitu: střední (potřeba čas na testování)
- požadavek na bezpečnost: střední (nereálná data, natavení podobné produkčnímu)
Před-produkční prostředí
- používají testeři, operátoři k testovacímu nasazení v prostředí podobném produkčnímu, testování výkonu a bezpočnosti
- požadavek na výkon: vysoké (prostředí co nejvíce podobné produkčnímu)
- požadavek na stabilitu: střední-vysoké (downtime issue je považován za hrozbu, nasazení podle nějakého plánu)
- požadavek na bezpečnost: vysoké (nereálná data, požadavky jako by bylo produkční prostředí)
Produkční prostředí
- nasadím novou instanci s novou verzí a začnu přesměrovávat uživatele x nějaký čas odstavení třeba brzo ráno, půlnoc
- používají zákazníci
- požadavek na výkon: vysoké (problém způsobí naštvaného zákazníka)
- požadavek na stabilitu: vysoké (nasazení v předem definovaném čase)
- požadavek na bezpečnost: vysoké (reálná data, zranitelnosti v zabezpečení je vážný problém)
Speciální testovací prostředí
- testování výkonu
- údržba produkčního nastavení je nákladná - zde se může otestovat
- testování pro velké funkce
- dlouho vyvíjené featury
Přístup k nasazení (5x)
1) Naivní vývoj
2) Nasazení skritpy
3) Automatický
4) CI (continous integration)
5) CD (continous delivery)
Naivní nasazení (1 z 5 přístupu k vývoji)
- všechno manuálně - sestavení, vývoj, configurace, nasazení
- není potřeba extra infrastruktura
- sklon k lidských chybám
- pomalý
Nasazení skripty
- pokus co nejvíce automatizovat pomocí skriptů
Postup:
- nasazení na server
- použití konfigurace
- restart služby
- testování
- potřeba spuštění těchto skriptů na serveru
Automatické nasazení
- Všechno plně automatizované od sestavení po testování
- navržený sestavovací server
- minimum lidské činnosti např. jedním tlačítkem
- celý nasazení vždy projde stejným procesem
CI
Continous Integration
- praktika co nejrychlejší integrace nových změn do kódové základny (master)
- potřeba vysoce kvalitního testovacího procesu pro zajištění stability kódu
- build server - nakonfigurován tak aby mergoval nové commity co nejrychleji do masteru
- chyby nalezeny velmi rychle
- vývojáři mohou dál pracovat než to server dokončí a otestuje
CD
Continous Delivery
-praktika zaměřená na nasazení změn v malých cyklech
změny by měli být menší
- flexibilní přístup pro poskytování nových funkcí, opravu kritických chyb
- celý tým potřebuje znát jak dopadl build, testy, reporty = snazší na reakce
- kvůli automatizaci je možné nasadit kteroukoliv verzi na jakékoliv prostředí kdykoliv
Sestavovací servery
1) Jenkins open-source, široce používaný, mnoho pluginů 2) Gitlab Pipeline pro projekty na gitlabu 3) TeamCity 4) Travis CI CI server pro github projekty
DevOps - charakteristika
- přístup zužující propast mezi vývojem a provozem
- vývojáři a správci systému musí spolupracovat
- týmy sestaveny tak aby každý mohl:
1) dodávat funkčnost
2) testovat
3) nasazovat
4) udržovat - prakticky
1) automatizace
2) kontejnery
3) bezpečnostní konfigurace
4) monitorování + škálování
5) zálohování + bezpečnost
DevOps - automazice
Je kritická:
- omezení manuální práce
- méně chyb (někdo zapomene něco nakonfigurovat, přepíše se)
- rychlé doručení
= Sestavení a nasazení je automatické
= Automatizace infrastuktury
- DevOps používá stejné principy pro instrastrukturu jako pro vývoj
- popis infrastruktury v konfiguračním souboru
=> verzuje se
Virtualizace (DevOps)
- Cloud dovoluje dobře škálovat
- virtualizační nástroje jednoduše vytvoří identickou instanci serveru (AWS, OpenStack, vagrant)
Kontejnery (DevOps)
(Docker, Kubernetes)
- jiná úroveň virtualizace
- dovoluje dodat aplikaci společně s runtime prostředí
- Build once, run anywhere
Monitoring (DevOps)
= Sběr infa
- dashboard a vidíme data na jednom místě
- Kolik RAM používám, místa na disku, odpovídá a jak rychle
- při problému dostat notifikaci (SMS, email, chat)
External:
- nemusí být na serveru
- monitoring odpovědí na požadavky
- response time
- validace HTTPS cetifikátů
In-place:
- musí být nainstalován na server
- monitoruje CPU, volné místo na disku, operační paměť RAM
Zálohy (DevOps)
= data jsou nejcennější věc
- V případě chyby lze obnovit data bez příliš velkých ztrát (např.):
=> útok
=> neúspěšný upgrade s nefunkční migrací dat
=> SW/HW chyba
=> chyba uživatele - Záloha nesmí trvat dlouho a nesmí sebrat moc prostředků (runtimu)
- uložena na odděleném místě
- Full x Incremental
- Kontrola záloh zda existují a jsou funkční Load-Balancer, který řeší:
1) výkon
2) stabilita
Prototyp (UX)
- návrh ve skutečném rozměru (grid)
- používat odstíny sedi pro zobrazení priorit
- nepoužívat černé pozadí
- jasné nadpisy
- reálná data, obrázky
- popisné placeholdery
- srozumitelné popisky
- propojení prototypu s poznámkami
Kontejnery
- abstrakce aplikace z produkcniho prostredi
- dovoluje vyvojarum si vytvorit testovaci prostredi, ktere odpovida realnemu nasazeni
=> v cloudu
=> na notebooku
=> na vlastnich serverech
=> relativne jednoduche na pouziti temer na jakekoliv plaforme (ale Linux je lepsi) - pripominaji hodne virtualni stroje ale jsou jinak implementovany
Rozdíl kontejnery - virtual machines
- VM maji vetsi rezii nez konterjnery
- kontejnery rychleji startuji
- kontejnery virtualizuji SW ne HW
Image X Kontejner
- image = binarni obraz behoveho prostredi
- kontejner = instance obrazu
- images jsou ulozeny v repozitari (lokalni, verjny) napr https://hub.docker.com/
LXC
implementace kontejneru - starsi nez Docker
- vyuziva funkce Linuxoveho jadra
- API pro vytareni Linuxovych kontejneru
- kontejnery = plne bezici OS
- stejny vysledek jako VM ale implementovano pomoci kontejneru
- ma flexibilitu jako VM
- ma rychlost startovani jako kontejner (min narocne na zdroje)
LXD
- image manager zalozen na LXC
- poskytuje image ve vzdalenem repozitari
- jednoduche, bezpecne
Docker
- novější než LXC
- jiny pristup: jedna aplikace = jeden kontejner
- docker neobsahuje kompeltni OS
- poskytuje izolovane prostredi
- vytvareni docker image
- textova specifikace = Dockerfile
- s kazdym prikazem se prida nova vrstva (kopie FS) -> navysuje se celkova velikost image
=> povazovano za hlavni nevyhodu Dockeru - vsechny jsou read only
- po sestaveni ma image pouze jednu RW vrstvu (ta posledni) -> muze slouzit k vytvoreni dalsiho image
Docker úložiště
FS v Dockeru se nema povazovat za permanentni
- v pripade updatu kompletne zrusime dany kontejner a spustime jiny -> jak uchovat data permanentne?
moznosti ulozist
1) Bind mounts
= namountovani slozky hostitelskeho OS do slozky v Docker kontejner
2) Volumes
- jsou vytvoreny ve FS hostitelskeho OS a namountovany do kontejneru
- rozdil oproti bind mounts: volumes jsou vytvoreny Dockerem v miste ktere spravuje Docker (typicky napr /var/lib/docker)
- volumes muzou byt vytvoreny nezavisle na kontejnerech
- mohou byt sdilene mezi vice kontejnery
Docker - síťování
Docker poskytuje vice moznosti toho jak resit sitovani
- vytvareni vnitrnich siti
- pripojovani kontejneru k internetu
Bridge networks
- vytvoreny v ramci dockerovskyho demona
- izolace kontejneru je realizovana na IP vrstve
- kontejnery ve stejne siti spolu mohou komunikovat
- defaultni bridge je vytvoren pri spusteni Dockeru
= jsou tam prirazeny vsechny kontejnery, pokud to neni specifiky jinak definovano
- ve vychozim stavu vsechny kontejnery vystavuji vsechny jejich porty (ale jen mezi sebou, ne do vnejsi site - host)
- abychom k nim mohli prisoupit musime explicitne specifikovat jake porty chceme nabindovat - 80:8080
Dockerizace aplikace
- aplikace se musi nakonfigurovat pres environment variables
- sila Dockeru se projevi pri nasazovani (testovani) aplikaci ktere vyuzivaji vice sluzeb
- moznosti konfiguraci:
1) Docker Compose
2) Kubernetes, Docker Swarm
3) AWS, Google Cloud, Azure…
Docker Compose
- obsahuje konfigurace jednotlivych kontejneru
=> vystaveni portu
=> image
=> sit
=> volumes
=> poradi v jakem skuzby spoustet - velice jednoduche
- nehodi se na nasazeni dal nez jen ve vyvoji
=> neresi load balancing
=> neresi automaticke nastartovani aplikaci kdyz spadnou
Docker Swarm
- nasazovani kontejneru v klastru
- jeden klaster se navenek tvari jako jeden spusteny proces
- propojeni vice Docker uzlu do jednoho klastru
=> manipulace pres jedno API - uzivatel porad vyuziva Docker-compose konfiguraci
- Swarn se pote postara o nasazeni jednotlivych kontejneru
- Swarm obsahuje interni DNS server
- kazda sluzba obsahuje zaznam v DNS
- Swarm resi load balancing
Kubernetes
- zalozeny na internich projektech Google
- poskytuje lepsi funkcionalitu nez Docker Swarm
=> automaticke skalovani
=> “health-check” on containers
Kubernetes vs Docker Swarm
nevyhody Kubernetes:
=> “do-it-yourself” (je slozity)
=> potreba dalsiho nastroje
vyhody Docker Swarm
=> jednodussi, stejne API jako Docker
Kubernetes je pouzivany a podporovany hlavnimi cloudovymi providery
Kde hostovat Docker klastry? (3x)
1) vlastni VM/servery
=> tezsi a slozitejsi
=> pokud to myslime vazne s daty a dostupnosti
2) Openshift (RedHat)
=> cela platforma postavena na Kubernetes
=> velmi dobra vizualizace
3) Google Cloud, AWS, Azure
=> bud si muzeme spusit vlastni Docker image
=> nebo poskytuji Kubernetes cluster
nevyhody vsech techto reseni je jejich cena
