Aplikacje w chmurze (prywatnej) z perspektywy Deva i Opsa
•Transferir como PPTX, PDF•
0 gostou•374 visualizações
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
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (14)
Semelhante a Aplikacje w chmurze (prywatnej) z perspektywy Deva i Opsa
Semelhante a Aplikacje w chmurze (prywatnej) z perspektywy Deva i Opsa (20)
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
- 6. Linux Docker Kubelet Host Linux Docker Kubelet Host Linux Docker Kubelet Host Linux Docker Kubelet Host Chmura kontenerów 16 July 2016 6 Linux Docker Kubelet Host OT PSF Platforms OT PSF PlatformsContainer Pod OT PSF Platforms OT PSF PlatformsContainer Pod OT PSF Platforms OT PSF PlatformsContainer Pod Replication Controller Service Container Pod Service Container Pod Kubernetes
- 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
- 11. IV – Backing services 16 July 2016 11 Container Container Cassandra Container Container MariaDB Container Container Redis Container Container etcd Container Container ActiveMQ App App App Usługi wspomagające: - stanowe - wysoko dostępne - klastrowane - persystentne - skalowalne
- 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
- 17. VIII - Concurency 16 July 2016 17 Container Container Apps Container Container App 1 Container Apps Container Container App 2 Container Container Apps Container Container App 3 Container Container Apps Container Container App 1 Container App 2 Container Container Apps Container Container App 3 Container Container Apps Container Container App 1 Apps Container Container App 3 Współbieżność skalowanie horyzontalne • ilość instacji • osobne procesy skalowanie wertykalne • małe instancje • optymalne wykorzystanie zasobów asynchroniczność • non-blocking I/O Container Container Apps Container Container App 1
- 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
- 24. Rekrutujemy 16 July 2016 24 Arch Dev QA Ops
- 25. Dziękujemy za uwagę. Michał Baliński m.balinski@oberthur.com twitter: @MichalBalinski Jakub Filipczak j.filipczak@oberthur.com
Notas do Editor
- 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..
- Michał: białe Kuba: niebieskie metodyka zwinna (lean, agile, DevOps) internal open source (commons)
- 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)
- Michał: 12factor – ulotność Kuba: crash only disposable apps, crash only, queueing ?
- 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
- Michał:
- Michał Kuba
- Michał