Kubernetes - cluster orchiestration system
Katacoda - jakiś remote terminal
Minikube - jakiś mały predefiniowany kluster

Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit.

Trzeba najpierw tworzyć aplikacje tak by były niezależne od konkretnego hosta - konteneryzacja
- zmienne środowiskowe
- sieć lokalna
- adres bazy danych
- jndi

Klaster kubernetesowy definiuje 2 typy zasobów:
- master - coordinates the cluster
- node - is the worker

Odpowiedzialności mastera
- schedulling applications

Node
- maszyna wirtualna albo fizyczny komputer
- każdy Node posiada agenta - o nazwie Kubelet - jego zadaniem jest komunikacja z masterem.

Master wystawia restowe api, Kubelety gadają z nim po httpie. Możliwe jest też gadanie z masterem bezpośrednio - curlem, albo jakimś klientem httpa

Produkcyjny klaster powinien mieć najmniej 3 node'y - nie wiem czemu, tak napisane na stronce

kubectl
- command line interface do mastera kubernetesa
- stuka po httpie do kubernetes mastera
- najczęsciej polecenie wygląda: $kubectl <action> <resource>

$ minikube start # odpala kuburnetes master'a

$ kubectl cluster-info
Kubernetes master is running at https://172.17.0.25:8443

$ kubectl get nodes
NAME       STATUS    ROLES     AGE       VERSION
minikube   Ready     <none>    6m        v1.10.0

Status = ready - it is ready to accept applications for deployment

Kubernetes Deployment Controller
- monitoruje Node'y
- jeśli któryś Node się wywalił(np błąd sprzętowy) wymienia go (co to znaczy wymienia?)

Kubernetes Deployment
- obiekt, który się tworzy
- według niego tworzony jest klaster

Przed orchiestracją skrypty deployujące nie pozwalały na monitorowanie i reagowanie na błędy sprzętowe. Troche to ściema, ale tak jest w tutorialu napisane

kubectl run - tworzy nowy deployment
- trzeba podać nazwę deploymentu oraz lokalizację obrazu
- odpalenie komendy:
	- tworzy obiekt Deployment
	- wyszukuje Node'a 'odpowiedniego' do uruchomienia obrazu(co to znaczy odpowiedniego)
	- odpala obraz na danym Node'ie - tak naprawdę odpala Pod'a a w nim obraz(y)
	- zapamiętuje obraz i Node żeby wiedzieć gdzie go odpalić jak się wywali

$ kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080
deployment.apps "kubernetes-bootcamp" created

$ kubectl get deployments
NAME                  DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1         1         1            1           1m

Pody działają w prywatnej, odizolowanej sieci. Domyślnie są widoczne dla innych pod'ów i service'ów w danym klastrze.

$ kubectl proxy
Starting to serve on 127.0.0.1:8001
- połączenie ssh do kubernetes master'a
- dzięki temu możemy wejść w przeglądarce na localhost:8001
- np: curl localhost:8001/version zwraca json'a

Kubernetes nadaje sam nazwy pod'om

Pod := zdefiniowana przez kubernetesa abstrakcja oznaczająca 1 lub więcej kontenerów oraz zbiór zasobów, które współdzielą
te zasoby to przykładowo:
- https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/

Pod = adres IP + zbiór Volume's + zbiór kontenerów

Volume := A directory containing data, accessible to the containers in a pod.
A Kubernetes volume lives as long as the pod  that encloses it. Consequently, a volume outlives any containers  that run within the pod , and data is preserved across container  restarts.

The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

Each  Pod is tied to the Node where it is scheduled, and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.

Node(w znaczeniu workera) działa na VM albo na fizycznym komputerze.
Pod działa na jednym Node'ie. Pod zawiera n kontenerów.

Kontener
- należy do konkretnego Pod'a(z którego ciągnie IP i współdzieli zasoby)
- ma swoje id
- ma ścieżke na obraz
- ma identyfikator obrazu
- port
- status

$ kubectl get - list resources
$ kubectl describe - show detailed information about a resource
$ kubectl logs - print the logs from a container in a pod
$ kubectl exec - execute a command on a container in a pod

Pod ma coś co się nazywa Event.
Event
- type: warning, error
- reason, age, from, message

Pod'y (jak to było napisane wcześniej) działają w prywatnej, odizolowanej siecie - stądteż, aby się z nimi połączyć potrzebne jest proxy.

Sztuczka na poranie nazwy pod'a: (wykonać po zestawieniu proxy)
$ export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
$ echo Name of the Pod: $POD_NAME
Name of the Pod: kubernetes-bootcamp-5c69669756-7ljbx

Wszystko co aplikacja wypluje na stdout staje się logiem pod'a

$ kubectl logs $POD_NAME
- pokazuje logi, należy także podać nazwę kontenera, ale jak jest jeden kontener to nie trzeba

$ kubectl exec -ti $POD_NAME bash
- otwarcie bash'a(konsoli) dla danego pod'a(trzeba podać także nazwę kontenera, ale był jeden)

Pod'y kubernetesowe umierają. Pod'y mają zdefiniowany cykl życia. Kiedy zdechnie Node -> zdychają z nim wszystkie pod'y w nim zawarte.
ReplicationController może reagować na to zdechnięcie.

Aplikacja frontendowa nie wie nic o pod'ach, ani w który kontener stuknie itp.
Pojawia się więc pytanie:
- skoro każdy pod ma inny adres IP, pod'y umierają i są wskrzeszane - jak zachować połączenie aplikacji frontendowej do backu(wraz z zachowaniem sesji),
  , tak aby nie obciążać dodatkowo aplikacji frontendowej
Odpowiedź:
-

A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them.

Service
- zdefiniowany przy użyciu yaml'a(preferowane), albo json'a. (na stronce też napisane: tak jak każdy obiekt kubernetesowy)
- Services enable a loose coupling between dependent Pods.
- The set of Pods targeted by a Service is usually determined by a LabelSelector

Tylko(chyba 'tylko') Service jest w stanie wystawić IP danego pod'a poza klaster.

Label
- jest to para klucz-wartość przypisana do obiektów
- za pomocą selektorów, można wyjąć obiekty z danymi labelami
- np: odróżnienie - produkcja/test, wersja aplikacji,

$ kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
service "kubernetes-bootcamp" exposed
- argument type:
	- NodePort, ClusterIp(domyślny), LoadBalancer, ExternalName







9:30 - Wejście w chmurę — perspektywa programisty Michał Kosmulski
10:35 - Micro-monolith anti-pattern Tomasz Fijałkowski - albo - Odzyskaj kontrolę nad aplikacją Bartek Zdanowski
11:40 - Jak być zarąbistym developerem w oczach szefa i ... klienta Wojciech Seliga - albo - Async, wszędzie async Arkadiusz Migała
12:45 - (Too) Smart UI? Jak projektować API REST-owe Szymon Janikowski
14:30 - Requirements & BDD: The lost art of analysis and acceptance scenarios Jakub Nabrdalik - albo - Zero-Downtime deployments of Java applications with Kubernetes Mateusz Dymiński
15:35 - Reactive programming with Flux in Java Łukasz Rekucki (lqc)(trochę lipa bo mało o tym wiem i mogę wiele nie wynieść) - albo - Jak rozwalić zespół w od 3 do 12 sprintów – 7 praktycznych porad Jakub Marchwicki Anna Wiosna Rogowska
16:40 - REST - know the rules Dominik Przybysz - albo - Data Lake w świecie Big Data - case study z wdrożenia Dawid Detko


TODO - programowanie reaktywne vs zdarzeniowe(event-driven)
- zdarzeniowe operuje na atomowych zdarzeniach
- reaktywne na bardziej generycznych danych
- dla programowania reaktywnego może istnieć pojęcie mapowania strumienia, agregowania strumienia, łączenie
- dla programowania zdarzeniowego pojęcie mapowania strumienia eventów nie ma sensu

Reactive programming is programming with asynchronous data streams.
- tymi asynchronicznymi strumianiami danych może być cokolwiek(nie tylko kliknięcia użytkownika jak w zdarzeniowym(chyba to jest prawda)) - ale cokolwiek.

Do tego dochodzą mechanizmy tworzenia, filtrowania, grupowania, mapowania itp tych strumieni - te dodatkowe mechanizmy to serce programowania reaktywnego.

Te strumienie można nasłuchiwać jedynie asynchronicznie.
Słuchanie na stream określa się jako subscribing.

W skład streama może wchodzić
- wartość
- błąd
- sygnał końca

The idea of event-driven programming is orthogonal to the idea of imperative vs. OO vs. functional.

Functional programming is the process of building software by composing pure functions, avoiding shared state, mutable data, and side-effects.
Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change.

https://www.reactivemanifesto.org/
Reactive systems are:
Responsive – systems should respond in a timely manner
Message Driven – systems should use async message-passing between components to ensure loose coupling
Elastic – systems should stay responsive under high load
Resilient – systems should stay responsive when some components fail

filter, map, reduce(kolekcja na jedną wartość, myArray.reduce(accumulator, (el) => el.someField, 0 /*start value of accumulator*/)


Tutorial programowania funkcyjnego by fun fun function
1) High Order functions:
- functions are value:
	- możne je przypisać do zmiennej, można je podać jako argument, funkcja może je zwrócić
- funckje które podaje się jako argument funkcji określa się jako 'callback function', ponieważ ta funkcja will callback to them
- funkcje, które jako argument przyjmują(albo zwracają) inne funkcje określa się jako 'High-order function'.
2)  Map - bez komentarza
3&4) reduce
5) closures - funkcja wraz z kontekstem zdefiniowanie tejże
6) currying - funkcja, której stopniowo nadajemy kontekst:
var dragon =>
  name =>
    size =>
      element =>
        return name + 'is a ' + size + ' dragon that breathes ' + element;
 - sporo bibliotek oferuje możliwość przemienienia dowolną funkcję na funkcję curryingowalną
7) rekurencja
8) promises
promise is not a value, it is a promise of a value
EcmaScript wspiera tworzenie promise'ów - nie wiem czy to zdanie nie jest jakiś krzywe
var loadSomething = new Promise((resolve, reject) => { // both resolve and reject are functions

});














https://www.reactivemanifesto.org/

https://gist.github.com/staltz/868e7e9bc2a7b8c1f754


Istnieje coś takiego jak Web Worker - jest to taki mechanizm, który pozwala pisać aplikacje wielowątkowe w JavaScriptcie. Główny wątek z workerem
porozumiewają się poprzez message, wiadomością są kopiowane i przesyłanie(nie - współdzielone).





Istotny koncept programowania reaktywnego: immutability