Przedstawiamy jak tworzone jest oprogramowanie gotowe do uruchomienia w dynamicznej chmurze obliczeniowej. Wzorce budowy skalowalnych i wysoko dostępnych usług. A także w jaki sposób automatyzujemy zarządzanie chmurą mikroserwisów składających się na platformy software’owe Oberthur Technologies. W prezentacji skupiamy się na dwóch aspektach:
• jak tworzyć aplikację pod chmurę taką jak Kubernetes (zasady: http://12factor.net/)
• jak automatyzujemy zarządzanie takimi aplikacjami (m.in. na Kubernetes)
Hashtagi: #microservices #java #12factor #docker #kubernetes #cloud #oberthur
Atmosphere 2014: Scalable and under control - open cloud architecture conside...
Aplikacje w chmurze (prywatnej) z perspektywy Deva i Opsa
1. Aplikacje w chmurze (prywatnej)
z perspektywy Deva i Opsa
Michał Baliński
Architekt oprogramowania
Jakub Filipczak
Integrator systemów
2. Czym się zajmujemy?
16 July 2016
Oberthur
Software Platforms
DIGITAL
IDENTITY
TRANSPORT
& ACCESS CONTROL
MACHINE-
TO-MACHINE
MOBILE FINANCIAL
SERVICES
SMART
TRANSACTIONS
Oberthur
Software Platforms
Customer
Systems
Oberthur Cloud Customer Premises
OT Secure Elements
OT R&D Poland
Oprogramowanie:
- serwerowe
- wbudowane (UICC)
Podejście produktowe
Bezpieczeństwo
Skalowalność
Dostępność
3. Jak pracujemy?
16 July 2016 3
Francja
Polska
USA
Filipiny
Indonezja
Chiny
Korea
~700
Inżynierów R&D
100+
Osób w R&D Łódź
500+
Repozytoriów GIT
500+ VM
wspierających
rozwój
oprogramowania
2K+
kontenerów
Docker
1000+
zadań continouus integration
50+
Wspólnych bibliotek i komponentów
w modelu „internal open source”
>10 Multi-dyscyplinarnych
zespołów w R&D Łódź
Arch Dev QA Ops
Trochę statystyk
4. Architektura rozwiązań – „chmura mikroserwisów”
16 July 2016
Pod
„instancja mikroserwisu”
Replication controller
„mikroserwis”
Service
„endpoint”
Node
„host”
5. Kontenery - Docker
16 July 2016 5
App
Libs
OS
HW
Klasyczne
Środowisko
App#1
Libs
H-OS
HW
Środowisko
Wirtualizowane
G-OS G-OS
Libs
App#2 App#1
Libs
OS
HW
Środowisko
Wirtualizowane
Docker Engine
Libs
App#2
• Mechanizm lekkiej wirtualizacji
• Docker wykorzystuje wbudowane mechanizmy jądra Linux
(cgroups, namespaces)
• Tworzy pseudo izolowane środowiska uruchomieniowe
7. 16 July 2016 7
Aplikacje gotowe na chmurę
(ang. cloud native applications)
• Wykorzystują zalety chmury
• Elastycznie dostosowują się do
dynamicznej infrastruktury
• Bezstanowe usługi
• Skalowalne
• Zautomatyzowana, deklaratywna
konfiguracja
• Wysoko dostępne i odporne na awarie
I. Codebase
II. Dependencies
III. Config
IV. Backing Services
V. Build, Release, Run
VI. Processes
VII. Port Binding
VIII.Concurrency
IX. Disposability
X. Dev/Prod Parity
XI. Logs
XII. Admin Process
Cechy Praktyki 12-factor
8. I - Codebase
16 July 2016 8
Repozytoria z
kodem
źródłowym
aplikacji
Repozytoria
definiujące
obrazy
bazowe
(Dockerfiles)
Repozytoria z
konfiguracją
środowisk i
deploymentów
Rejestry
obrazów
i artefaktów
Git
Git
Git
Dev
Test
Staging
Produkcja
Codebase
Dependencies
Infrastructure as a Code
9. II - Dependencies
16 July 2016
9
Repozytoria z
kodem
źródłowym
aplikacji
Repozytoria
definiujące
obrazy
bazowe
(Dockerfiles)
Repozytoria z
konfiguracją
środowisk i
deploymentów
Rejestry
obrazów
Git
Docker
Registry
Dev
Test
Staging
Produkcja
Env Dependencies
Rejestry
artefaktów
Artifactory
Lib Dependencies
Immutable images
with
bundled deps
9
10. III - Config
16 July 2016 10
Repozytoria z
konfiguracją
środowisk
Git
Konfiguracja Produktu:
- wersjonowana
- prostsze projekty - zmienne środowiskowe
- złożone projekty - pakiet per środowisko
STAGE SerwerQA SerwerDEV Serwer
12. V – Build, Release, Run
16 July 2016 12
Repozytoria z
kodem
źródłowym
aplikacji
Jenkins
Artifactory
Docker
Registry
Artifactory
Repozytoria
konfigurcji
Repozytorium
obrazów
13. V – Build, Release, Run
16 July 2016 13
Repozytoria
konfiguracji
Rejestry
obrazów
i artefaktów
Jenkins
Green Junits
Stabilna
wersja
Salt Stack/
Puppet
QA Serwer #3QA Serwer #2QA Serwer #1
14. V – Build, Release, Run
16 July 2016 14
Jenkins/
Testy
Integracyjne
QA Serwer #1
Repozytoria
konfigurcji
Wersja
Promowana
15. VI - Processes
16 July 2016 15
Container
Pod
app
process
container
Container
Pod
app
process
container
Container
Pod
app
process
container
Container
Pod
app
process
container
statefull, highly available backing services
Procesy aplikacyjne:
- bezstanowe
- skalowalne
- luźno powiązane
- ulotne
- niezależne
- każdy w kontenerze
16. VII – Port Binding
16 July 2016 16
Kontener
Aplikacja
Biblioteka Serwerowa
Część Aplikacyjna
T
C
P
T
C
P
18. IX - Disposability
16 July 2016 18
App App App
• Instancje ulotne (ang. disposable)
• Instancje niezmienne (ang. immutable)
• Szybko startujące
• Wprowadzanie zmian poprzez zastąpienie instancji nową
• Polityka „crash only” (brak tzw. „gracefull shutdown”)
• Asynchroniczność poprzez kolejkowanie komunikatów
19. X – Dev/Prod parity
16 July 2016 19
HW
OS
Libs
App
HW
OS
Libs
HW
OS
Libs
HW
OS
Libs
AppApp App
DEV QA Stage PROD
?? ?
HW
OS
DEV
HW
OS
QA
HW
OS
Stage
HW
OS
PROD
Libs
App
Libs
App
Libs
App
Libs
App
Kontener Kontener Kontener Kontener
20. XI - Logs
16 July 2016 20
OT PSF
Platforms
OT PSF
PlatformsContainer
Pod
OT PSF
Platforms
OT PSF
PlatformsContainer
Pod
OT PSF
Platforms
OT PSF
PlatformsContainer
Pod
Host
Docker
Fluentd
Driver
stdout
Fluentd
Elastic
Search
Kibana
JSON
Kubernetes
Master
$kubectl logs POD
21. XII - Admin Process
16 July 2016 21
Procesy administracyjne:
- uruchamiane w tym samym środowisku co aplikacja
- korzystające z REPL udostępnianych przez język
- lub mechanizmów udostępnianych przez backend
Cassandra
Cass
andr
a
Docker Docker
CQLSH
App
BSH
App
Docker
T
C
P
T
C
P
22. Nasza droga
16 July 2016 22
Stare podejście
Kontenery
Orkiestracja I
Orkiestracja II
Chmura (HA)
Custom
Custom
docker compose
23. Wnioski (lessons learned)
• Duża ilość repozytoriów / mikroserwisów jest wyzwaniem
(chociażby świadomość jakie komponenty posiadamy)
• Postawienie, ustabilizowanie i utrzymanie chmury prywatnej – to
nietrywialny, kosztowny i długotrwały wysiłek
• Najnowsze technologie – potrafią przysporzyć trudności ;-)
• Aplikacje powinny być tworzone pod chmurę
• Dostęp do logów przez Kibanę – trzeba się nauczyć z tym żyć
• Wdrożenia u klienta (on-premises)
o nie zawsze się da tak jak byśmy chcieli (docker, k8s)
o klienci mają specyficzne ograniczenia i standardy IT
o brak kompetencji docker / kubernetes u klientów
o bezpieczeństwo kontenerów
• Wymuszanie najnowszych wersji poprzez usuwanie starych obrazów
bazowych Docker
16 July 2016 23
25. Dziękujemy za uwagę.
Michał Baliński
m.balinski@oberthur.com
twitter: @MichalBalinski
Jakub Filipczak
j.filipczak@oberthur.com
Editor's Notes
Michał – Architekt czuwający nad rozwojem projektu Common Components, tworzy zestaw bibliotek wykorzystywanych wewnętrznie w projektach OT
Kuba – Integrator w projekcie Host Card Emulation, zajmujący się procesem Continous Integration oraz wdrożeniami klienckimi
Będziemy opowiadać o:
Jak tworzymy oprogramowanie działającej w chmurach prywatnych w Oberthur RND
Jakich narzędzi używamy
Jakie wyzwania pojawiały się w trakcie jej tworzenia a później utrzymania
… I jak ta koncepcja wpisuje się w 12-factor
Co robimy jako OT (kontekst) – diagram z lotu ptaka (klienci, platformy serwerowe i device’y/secure elementy)
Wspomnieć
podejście produtkowe , przykładowe produkty (Android Pay, Samsung Pay, Mercedes)
security (HSA, brak dostępu do produkcji, …)
skalowalność
wymagania HA z jakimi się spotykamy 99,9 99,99 99,999
Wspomnieć o SE, co to jest, że ma OS i JVM w środku itd..
Architektura rozwiązań
„chmura mikroserwisów”
dynamiczna / elastyczna architektura – zmieniająca się w czasie
Komponowanie rozwiązań z mikroserwisów
Aplikacje (mikroserwisy) w kontenerach (Docker)
Co to docker
Dlaczego docker i co nam daje
Kontener docker’owy nie tylko jako jednostka deploymentu
ale przede wszystkim obraz kontenera jako wynik budowania aplikacji
Obraz zawiera wszystkie zależności (app level & environment level)
Obraz zawiera skrypt startujący aplikację
Spotify maven-docker-plugin
Kubernetes (architektura – diagram)
HA
dynamizm
Cloud native applications (aplikacje gotowe na chmurę)
cechy
uruchamiane w dynamicznym środowisku
HA / odporne na awarie (zawodnej infrastruktury w chmurze)
disposable
skalowalne (horizontal + vertical (NIO / asynchronicznie))
Michał: 12factor, każdy kmponent w osobnym repo, mamy dużo repozytoriów
Kuba: repozytoria z konfiguracjami (dockerfile i środowiska)
Mamy dużo repo
Każdy komponent w osobnym repo (mapowanie 1-1)
Dockerfile dla obrazów bazowych (np. Linux + JVM) w osobnych repo
Repozytorium z konfiguracjami rozwiązań do deploymentu (per środowisko across projects)
Michał: 12factor, wszystko explicite, zależności aplikacyjne
Kuba: zależności od środowiska w Dockerfile’ach, obrazy dockerowe immutable
everything explicit
dependencies inside docker images
docker images immutable
Kuba: 12factor, animacja
Michał: multiline env variables
Istotną kwestią w 12factor jest poprawne zarządzanie konfiguracją produktu – w naszych projektach konfiguracja jest utrzymywana w repozytorium GIT i wersjonowana równolegle z kodem produktu.
app config as env variables
or in HA backing services (etcd, DB, HA shared file system)
versioned in GIT
immutable
Michał: 12factor, z jakich korzystamy, wyzwania (persystencja, dynamizm)
Kuba: nawet te usługi stawiamy opakowane w kontenery dockerowe, nie zawsze w dynamicznym cloud
HA available backing services
All treated as 3rd party services
Często wykorzystywane aby zapewnić wysokodostępny sposób na przechowywanie stanu
Często NoSQL: Cassandra, Redis, etcd
Michał: 12factor
Kuba: flow na diagramie
1.Jenkins pulluje repozytorium kodu
2.W trakcie buildu Maven zaciaga zaleznosci z Artifactory – no bo w koncu mamy mikroserwisy;)
3.Wyjściem są wsady do Artifactory – nie wiadomo czy ktoś nie będzie potrzebował naszych jarków; do Docker Registry który będzie trzymał obrazy będące naszymi docelowymi artefaktami; do repozytorium konfiguracji aplikacji (opcjonalne).
Kolejnym krokiem jest uruchomienie w Jenkinsie testów jednostkowych, jeśli rezultat będzie pozytywny nastąpi kolejny krok w procesie czyli….
Kuba
Kolejnym krokiem jest uruchomienie w Jenkinsie testów jednostkowych, jeśli rezultat będzie pozytywny rozpoczynamy promocję danej wersji na środowisko Dev
Testy automatyczne
Konfiguracja deploymentu w GIT
Kuba
Testy Automatyczne
1.Sprawdzenie wersji na QA, potwierdzenie gotowości środowiska
2.URuchomienie testów
3.Wypromowanie obrazów poprzez modyfikację repozytorium konfiguracji
Jeśli obrazy zostały wypromowane powtarzany jest cykl Salt/Puppet z poprzedniego slajdu (warto to powtarzac?)
Michał: 12factor, osobne procesy każdy w osobnym konterze
Kuba: ulotne procesy
Stateless
Share nothing
Single proces (container)
Kuba: 12factor
Dlaczego jest istotny?
self contained app exposing its ports by itself
interface versioning
Michał: skalowanie horyzotnalne w górę i wertykalne w dół oraz optymalność (NIO)
horizontal scaling via processes/containers
vertical scaled down (as small as possible)
Asynchronous / non-blocking (NIO / Netty)
Kuba: 12factor + omówienie diagramu
Układ klasyczny, aplikacja jest przenoszona pomiędzy środowiskami, biblioteki I zależności już tam są.
Problemy:
Biblioteki, zaleźności, konfiguracja systemu I milion innyc
Docker,
operations automation (infra & config in repo),
DevOps methodology - multidisciplinary teams
Wspomnieć że w podejściu „bardzo starym” niektórzy budowali aplkację osobno na każde środowisko (z wgrzaną konfiguracją)
Michał: 12factor
stdout or TCP,
ELK/fluentD,
JSON/text format (logback / logstash format) / MDC
Kuba
side containers / processes
Przykłady:
Inicjalizacja danych cassandry przy pomocy innego kontenera cassandry
W środowiskach developerskich wystawiany beanshell wykorzystywany do podstawowych zadań administracyjnych i testów – z przyczyn bezpieczeństwa nie zawsze dostępny produkcyjnie