Agenda
• Omówienie• Microservices
• Docker
• Kubernetes
• SUSE CaaS Platform
• Prezentacja
• Pytania
2
Microservices
3
Czym jest Microservice?
4
Sposób realizacji architektury SOA w której aplikacja jest zbiorem luźno powiązanych usług.
Usługi powinny realizować drobne zadania i używać „lekkich” protokołów.
(Myślcie o nich jak o narzędziach z Uniksa/Linuksa – jest ich wiele, a każde z nich wykonuje tylko jedną czynność)
5
Zalety architektury monolitycznej?
6
• Jak już działa jest spora szansa, że będzie wydajniejsza.
7
The Scale Cube
8
Zalety Microservices?
9
• Zwiększa modułowość aplikacji
• Aplikacja jest łatwiejsza do zrozumienia, rozwoju i testowania
• Pozwala na zrównoleglenie rozwoju poprzez podział prac na wiele niewielkich, niezależnych zespołów z których każdy może zajmować się rozwojem własnej usługi niezależnie
• Upraszcza CI/CD
• Pozwala na dostarczenie produktu szybciej i lepszej jakości
• Elementy aplikacji nie muszą być uruchamiane na tym samym komputerze
How do I design a Microservice?
10
I. CodebaseOne codebase tracked in revision control, manydeploys
II. DependenciesExplicitly declare and isolate dependencies
III. ConfigStore config in the environment
IV. Backing servicesTreat backing services as attached resources
V. Build, release, runStrictly separate build and run stages
VI. ProcessesExecute the app as one or more statelessprocesses
VII. Port bindingExport services via port binding
VIII. ConcurrencyScale out via the process model
IX. DisposabilityMaximize robustness with fast startup andgraceful shutdown
X. Dev/prod parityKeep development, staging, and productionas similar as possible
XI. LogsTreat logs as event streams
XII. Admin processesRun admin/management tasks as one-offprocesses
Docker
11
Rewolucja w datacenter
12
Na początku były serwery…
Rewolucja w datacenter
13
Lecz był też problem… Dlaczego one nie są w pełni wykorzystywane?
Rewolucja w datacenter
14
Rozwiązanie! Wirtualizacja!
Rewolucja w datacenter
15
Ale czy nie można by zrobić coś więcej?
Virtualisation
Rewolucja w datacenter
16
…Przecież jest tyle wspólnych elementów…
We need to go deeper!
Virtualisation
Rewolucja w datacenter
17
…Hypervisor… System operacyjny gościa…
Virtualisation Containerisation
Rewolucja w datacenter
18
…pozbądźmy się ich! A binarki i biblioteki uwspólnijmy!
Virtualisation Containerisation
Key Benefits
19
A container engine coupled with an ecosystem of user/developer tools
Developers create a layered image of their application that contains everything their application requires to run
When done correctly container image will be able to be built once and run everywhere
Developers can focus on what they do best – development - opposed to dealing with packaging or library dependency management
Perfect for Microservices
RdC1RdC [2]1
Slajd 19
RdC1 Rob de Canha-Knight; 21.06.2017
RdC [2]1 Rob de Canha-Knight; 21.06.2017
Docker Features
RdC [3] [2]1RdC [2] [2] [2]1
Slajd 20
RdC [3] [2]1 Rob de Canha-Knight; 21.06.2017
RdC [2] [2] [2]1 Rob de Canha-Knight; 21.06.2017
Why should I care?
RdC [3]1RdC [2] [2]1
Slajd 21
RdC [3]1 Rob de Canha-Knight; 21.06.2017
RdC [2] [2]1 Rob de Canha-Knight; 21.06.2017
Kubernetes
22
Czym jest Kubernetes (k8s)?
Kompletne rozwiązanie do zarządzania zadaniami opartymi o kontenery• Deploy (rozmieszczenie)
• Manage (zarządzanie)
• Scale (skalowalność)
• Clustered (niezawodność)
Scheduling of containers
Critical for Micro Services and distributed applications
Pozwala na korzystanie z kontenerów w sposób przyjazny dla developerów• Dodaje warstwę abstrakcji nad „czystą” infrastrukturę. I jest to dostępne przez API
• Pozwala użytkownikom zarządzać aplikacjami, a nie maszynami23
24
Sposób na zawstydzenie Masłowa(gdyby nadal żył)
Kubernetes – słownictwo, pojęcia, architektura
25
Wszystko jest obiektem(a przynajmniej powinno być)
26
Podstawowe pojęcia
Container: Zamknięty pakiet aplikacji (Docker).
Pod: Mała grupa ściśle powiązanych kontenerów (containers).
Service: Zestaw „podów” (pods) które ze sobą współpracują i mają być osiągalne przez sieć z zewnątrz.
Controller: Komponent dbający o to aby bieżący stan dążył do stanu pożądanego
Labels: Identyfikują metadane powiązane z obiektem
Selector: Zapytanie do zestawu „labeli” (labels), w efekcie którego można podjąć określone akcje
27
Architektura Kubernetes
28
Hierarchia logiczna
29
Pod
C CC C
ReplicaSet
Service
Deployment
Namespace
Controller – zasada działania
Dąż do zmiany z bieżącego stanu
do stanu oczekiwanego
Działaj niezależnie
To co widzisz jest prawdą
Przykład: ReplicationController
30
Replica Set (formalnie ReplicationController)
31
Rodzaj controllera
Upewnij się, że N kopii poda zawsze jest uruchomiona
Pamiętaj, że zrepikowane pody są wymienialne
• Bez konkretnej kolejności lub rozróżniania
Pod: Grupowanie kontenerów
32
Easier/Faster to start
Focused package
Easier multi-tenancy
Many pods per node
Pods: Sieć
33
Each pod has own IP
No port brokering
Security benefits
Local service grouping
Pod – cykl życia
34
Raz wystartowany na węźle pod nie zostanie przeniesiony gdzie indziej.• Restart policy oznacza na tym samym węźle
Pod może osiągnąć stan pending, running, succeeded or failed• Failed oznacza naprawdę koniec – żadnych restartów więcej
• Ee – żadnej skomplikowanej logiki w tym nie ma
Pod jest restartowany przez controller nie przez schedulera, lub apiserver
• Nawet jeżeli węzeł padnie
• Scheduler nie temu służy aby restartować pody
Pods: Woluminy
35
Storage support
Choice of backend
Longer lifetime
Data for pod containers
Pods: Labels
36
Organise pods
Query pods
Organise objects
API abstraction
Pods: Labels
37
Role: Frontend
Version: 1.2
Environment: Dev
Environment: Staging
Stałe Woluminy
38
Administratorzy dostarczają. Użytkownicy podejmują
Niezależny czas życia, czy przeznaczenie
Mogą być rozdzielane między podami i istnieć dopóki są potrzebne
Dynamicznie przydzielane i zarządzane
Labels
39
Metadane identyfikujące
Dołączane do dowolnego obiektu API
Można o nie pytać za użyciem selektorów
To jedyny mechanizm grupujący w k8s
Są używane do określania których obiektów ma tyczyć podejmowana operacja
Selectors
40
Selectors
41
Selectors
42
Selectors
43
Selectors
44
Selectors
45
Services
46
“Exposed” “Hidden”
Services
47
Atomic Cluster Data Storage
Backing store for all the master state data• Vital for a distributed system
Hidden behind an abstract interface
Stateless and scalable• Distributed, reliable key-value store
Watchable• K8s doesn’t poll, it watches
Uses CoreOS etcd48
SuSE CAASP
49
Kiedy kontener to jednak za mało
50
Provision AutomateHost
ServicesManage
Container Lifecycle
OrchestrationContainer
Microservices
Scale
Czym jest SUSE Container as a Service Platform
51
SUSE Container as a Service Platform jest platformą dla kontenerów, która pozwala na aprowizację, zarządzanie i skalowanie aplikacji opartych o kontenery.
Cel:Dostarczenie rozwiązania do rozwoju aplikacji platformy, która zautomatyzuje nudne czynności administracyjne.
CaaS Platform skupia się na trzech obszarach
52
OS for Containers
OS for Containers
OrchestrationOrchestration ConfigurationConfiguration
Zarządzanie kontenerami Uruchamianie kontenerów Budowanie i zarządzanieinfrastrukturą
SUSE CaaS Platform składa się z trzech komponentów
53
SUSE MicroOSKubernetesSalt,
Container Engines
OS for Containers
OS for Containers
OrchestrationOrchestration ConfigurationConfiguration
SUSE MicroOS – Główne cechy
54
Transactional UpdatesAtomic updates
Automatic updates. Can be disabled.Maintenance Window/Policy defined updates
Scalability (up to 1000s of nodes)
Use core technologiesbtrfs, rpms, cloud-init
Three System RolesAdmin Dashboard
Worker (Kubernetes Admin OR Node)Plain System (No Kubernetes)
Easy to use Installer“1 Click” Install
*SUSE MicroOS not available as a standalone product
SUSE CaaS Platform Architektura
55
SUSE CaaS Platform
56
SL
ES
Automation (Salt + cloud-init)Configuration & Management of each node
Persistent Storage (local disk, NFS,
SES)Networking Registry Security Logging
Orchestration (Kubernetes) Services (e.g. Deployment Dashboard)
Container Container Container Container Container Container Container Container Container
Container Runtime & Packaging
SUSE Linux Enterprise MicroOS (Container Host OS)
(Physical) Infrastructure
57
1 x VM/Bare Metal Each
K8s Master
K8s Worker
K8s Worker
K8s Worker
K8s Worker
K8s Worker
1 x VM/Bare Metal
58
SUSE CaaS PlatformKubernetes Cluster
ClusterNode
ClusterNode
ClusterNode
ClusterNode
ClusterNode
ClusterNode
Dashboard
AdminNode
1 x Instance Each
ClusterNode
ClusterNode
ClusterNode
ClusterNode
ClusterNode
ClusterNode
Availability Zone 1 Availability Zone 2
*Built in k8s feature
59
SUSE CaaS Platform Deployment Scenario
60
IT Operations (Administrator)
DevOps & Developer End User
Setup IT Infrastructure for
Containers
DeveloperCreate Microservice Apps for
Containers
Access & Use LoanApplication
DevOpsManages the cluster. Run Loan App (High
Availability, Load Balancer, Orchestrate nodes).
A Financial Services company wants to launch a new Loan application.
PXE / DHCP / SMTPortus
External Logging System
Adminnode
IT Ops/DevOps
Admin Dashboard
node node node
node node node
node node node
Kubernetes
Master
SUSE CaaSP
SUSE RegistrySCC
SUSE CaaS Platform Deployment - Setup Infrastructure
61
1 Install Admin nodeMicroOS one step installationCreate AutoYaST profileSet up Admin Dashboard
2 Connect to Admin Dashboard
3 Deploy NodesUses AutoYaST profile
4 Configure ClusterSet up kubernetes, etcd, flannel,...
SUSE CaaS Platform Deployment – Run Containers
62
Dev/DevOps
node node node
node node node
node node node
Kubernetes
Master
Private RegistryCI
Git
KubernetesDashboard /
kubectl
HA Proxy
1 Push code to git 2 Build container image(s) 3 Run app on kubernetes cluster
4 Ready for production
SUSE RegistrySCC
CaaS Platform Deployment Scenario – End User view
63
Loan App
node node node
node node node
node node node
Kubernetes
Master
End user accesses application via HA-proxy
HA Proxy
Adminnode
IT Ops/DevOps
Admin Dashboard
node node node
node node node
node node node
Kubernetes
Master
SUSE CaaSP
SUSE CaaS Platform Deployment – Full Picture
64
Private Registry
CI
Git
HA Proxy
Loan App
Dev/DevOps
SUSE RegistrySCC
SUSE Linux Enterprise MicroOS
65
What is SUSE Linux Enterprise MicroOS
66
SLE MicroOS is a modern Linux Operating System, designed for containers and optimized for large deployments.
MicroOS inherits the SLE knowledge while redefining the operating system into a small, efficient and reliable distribution.
SUSE OpenStack
Cloud
MicroOS
SUSE Linux Enterprise MicroOS – Key Design Elements
67
OS Designed for
Containers
Designed for Cloud,
Kubernetes, PaaS
Transactional Updates
Minimal Images
Minimal Configuration
Large Deployments
Ready to Run
Transaction Update - Definition
68
Is AtomicThe update does not influence running system
Can be rolled backEasily restore original state
Transactional Update – Rollback is easy with btrfs
69
ro roro ro rw
ro roro rocurrrw
roNew rw
1 ro-Clone 3 Zypper up 5 rw-Clone = Rollback2 Change rw 4 Change ro
SUSE Linux Enterprise MicroOS – Key Features
70
Transactional UpdatesAtomic updates
Automatic updates. Can be disabled.Maintenance Window/Policy defined updates
Scalability (upto 1000s of nodes)
Use core technologies: btrfs
Three System RolesAdmin Dashboard
Worker (Kubernetes Admin + Node)Plain System (No Kubernetes)
Easy to use Installer
Demo
71
Pytania
72
73
Unpublished Work of SUSE LLC. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary and trade secret information of SUSE LLC. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for SUSE products remains at the sole discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.