Future of Microservices - Jakub Hadvig
-
Upload
webtlak -
Category
Technology
-
view
221 -
download
1
Transcript of Future of Microservices - Jakub Hadvig
Microservice● Software architecture● Application composed from processes
○ small and independent ○ single purpose○ replaceable○ isolated
Microservice● Software architecture● Application composed from
processes○ small independent processes○ single purpose○ replaceable○ isolated
Linux Containers (LXC)● Virtualization on a operating-system level● Single Linux host = multiple isolated Linux system ● Containers run with host kernel (fast)● Microservices = Containers
Microservices redefine the “App”● Networked components wired together
○ Not just a “web frontend” anymore○ HTTP frontends are just one type of component○ Make it easy to build, manage, deploy components (tools)
● Critical: relationships between components○ If you can’t abstract the connection between components you
can’t evolve them independently
Docker● Containerization engine for building images● Go● Core functions
○ docker build = Docker images○ docker run = Docker containers
● Dockerfile○ DSL○ 16 instructions
Docker images● Immutable (read-only)● Sharable● 80k public Docker images (DockerHub)● Building blocks
○ Image based deployment○ Create once, use everywhere (Dev, QA, Prod)
Docker● What do we want?
○ Full access to the existing Docker ecosystem○ Be able to consume images from anywhere○ Work with upstream to improve security and reliability○ Need tools to manage the build process and security updates
● What do we expect?○ Manage 1M+ of running containers○ Manage containers across multiple nodes
Kubernetes● Container cluster manager● Manage containerized applications across a
cluster of Nodes○ Running containers at scale○ Provide runtime and operational tools for containers○ Provide resource management
● Google, Red Hat, CoreOS and others…● Go
Kubernetes architecture (basics)● Master(s)
○ (REST) API server○ Scheduler for allocation of “containers” onto hosts○ Manages replications and watches the system for changes
● Node(s)○ Agent that relays informations between Node and Master ○ Manages containers (using Docker)○ Proxy for local service routing and load-balancing
Kubernetes architecture● Etcd
○ Simple config key-value store distributed across hosts○ Highly reliable○ Used for service discovery○ Simple (CURL ball) & Secure (SSL)○ Provide high-performance operations
Kubernetes work units● Pod
○ Represents group of containers closely related together○ 1..N containers
Kubernetes work units● Service
○ Abstract set of Pods as a single IP and 1..N ports
○ Provides environment variable in other Pods and simple
TCP/UDP load balancing
Kubernetes work units (cont..)● Replication Controllers
○ Framework for Pods that are meant to be horizontally scaled○ Maintain number of replicas for given Pod○ Replicas are distributed across cluster
● Label(s)○ Common field in all Kubernetes resources
○ Represents a 'tags' you can use to couple the work units
together
So what is an new "Application"?Pods linked together by Services:● Edge router for www.myapp.com -> Rails frontend Pods● Rails frontend Pods -> "backend" API Service● "backend" API Service -> Python Pods● Python Pods -> "postgresql" database Service● "postgresql" Service -> PostgreSQL Pod with network
attached storage
OpenShift v3● Use Docker to containerize applications● Use Kubernetes to manage them
○ Allow for Service-oriented-Architecture (Mircoservices !!!)
● Go
Composition● Kubernetes is embeddable● Kubernetes offers us infrastructure● OpenShift embeds it and add PaaS pieces:
○ Builds○ ImageStreams○ Deployments○ Templates○ ... others...
Build● Allows to build “stuff”
○ S2I, Docker, or Custom build● Kubernetes schedule and execute the build inside Docker
container● Triggers
○ webhooks○ image change○ config change
● Built image are pushed into a single ImageStream.
ImageStream● Build upon Docker Registry● Abstraction for lack of functionality
○ base image○ notify changes○ track history
Deployment● Define the lifecycle for a single image
○ What happen when an update is pushed to Docker image?○ What happen when application configuration is updated?
○ What happen when updated application configuration fail to
deploy?
Templates● For consumption by end users of standard
patterns● Describes the whole application topology
S2I (Source to Image)● Don’t make developers write Dockerfile● Providing builder images is operational responsibility● Developers wants simple flows (From GIT repo to Docker image)
○ Push changes to Git○ Get all dependencies installed (bundler, npm, pip, maven, etc..)○ Commit Docker image○ Deploy
S2I (Source to Image)● Build process fundamental elements
○ source○ builder image○ s2i scripts
■ assamble■ run
● Current s2i builder images:○ ruby, php, python, nodejs, perl, jboss
● Incremental builds (kinda)
Source code● Consuming external source repos (no hosting)
○ github && generic webhooks● Support different SCM (bzr, mercurial, SVN, CVS, ...)
OpenShift and Images● Need tools for Docker image management
○ Think about millions of Docker containers○ Need good quota story - OpenShift v3 Online○ Pruning - remove old stuff○ Content tracking and auditing
● Security
Documentation, links, repos● OpenShift 3 Technical Architecture
○ Much deeper dive into the architecture● OpenShift 3 System Design (PEP)● Kubernetes Repo
○ https://github.com/GoogleCloudPlatform/kubernetes● OpenShift Repo
○ https://github.com/openshift/origin● Sample App+Guide
○ https://github.com/openshift/origin/tree/master/examples/sample-app● OpenShift Blog Series
○ https://blog.openshift.com/author/benparees/● Source-To-Image project
○ https://github.com/openshift/source-to-image