2019년 11월 22일 금요일
Microservice deployment to Kubernetes
https://hub.docker.com/r/karthequian/wishlist/
https://hub.docker.com/r/karthequian/wishlist-auth
https://hub.docker.com/r/karthequian/wishlist-catalog
2019년 11월 20일 수요일
Microservice deployment to Kubernetes
https://github.com/karthequian/wishlist
# Deploying our application to Kubernetes
We're ready to deploy our application to Kubernetes, but let's take a look at our assets.
## Goals:
1. View our sample application and containers
2. Take a look at our deployment file
3. Take a look at our alternate deployment file
4. Deploy our application into kubernetes and verify we can see our API's working.
## Goal 1
View the sample application here:
## Goal 2
To view the deployment file, take a look at wishlist-deployment.yaml
## Goal 3
To see another way to run the microservices, take a look at wishlist-deployment-alernate.yaml
## Goal 4
To run the microservice described in goal #1, from the current directory, run:
`kubectl create -f wishlist-deployment.yaml`
To verify that the deployment is online:
`kubectl get deployments`
To verify that the replica sets are running:
`kubectl get rs`
To verify that the pods are running:
`kubectl get pods`
To see the services:
`kubectl get services`
To interact with your API's in the minikube environment:
`minikube service wishlist-service`
# Deploying our application to Kubernetes
We're ready to deploy our application to Kubernetes, but let's take a look at our assets.
## Goals:
1. View our sample application and containers
2. Take a look at our deployment file
3. Take a look at our alternate deployment file
4. Deploy our application into kubernetes and verify we can see our API's working.
## Goal 1
View the sample application here:
## Goal 2
To view the deployment file, take a look at wishlist-deployment.yaml
## Goal 3
To see another way to run the microservices, take a look at wishlist-deployment-alernate.yaml
## Goal 4
To run the microservice described in goal #1, from the current directory, run:
`kubectl create -f wishlist-deployment.yaml`
To verify that the deployment is online:
`kubectl get deployments`
To verify that the replica sets are running:
`kubectl get rs`
To verify that the pods are running:
`kubectl get pods`
To see the services:
`kubectl get services`
To interact with your API's in the minikube environment:
`minikube service wishlist-service`
# Wishlist deployment yaml
kind: Deployment
apiVersion: apps/v1
metadata:
name: wishlist-deployment
labels:
app: wishlist
spec:
replicas: 3 #We always want more than 1 replica for HA
selector:
matchLabels:
app: wishlist
template:
metadata:
labels:
app: wishlist
spec:
containers:
- name: wishlist #1st container
image: karthequian/wishlist:1.0 #Dockerhub image
ports:
- containerPort: 8080 #Exposes the port 8080 of the container
env:
- name: PORT #Env variable key passed to container that is read by app
value: "8080" # Value of the env port.
- name: catalog #2nd container
image: karthequian/wishlist-catalog:1.0
ports:
- containerPort: 8081
env:
- name: PORT
value: "8081"
- name: auth #3rd container
image: karthequian/wishlist-auth:1.0
ports:
- containerPort: 8082
env:
- name: PORT
value: "8082"
---
kind: Service
apiVersion: v1
metadata:
name: wishlist-service
namespace: default
spec:
type: NodePort
selector:
app: wishlist
ports:
- name: wishlist-port
protocol: TCP
port: 8080
- name: wishlist-auth-port
protocol: TCP
port: 8081
- name: wishlist-catalog-port
protocol: TCP
port: 8082
2019년 11월 17일 일요일
Large Enterprise Application Experience
1. My Early Enterprise Experience
- Team built one big java WAR file
- Ops team deployed to the dev WebLogic Server
- Local development on WebLogic Servers run on own machines
- Environment set up to use the development database via data sources.
2. Ecommerce Catalog
- View the list of current products
- Understand their specifications
- Save into a with lisht that enables team collaboration
- Get a quote for the with list or go through the purchase process.
Three Modules
1) User Module
Responsible for user management, login, and profile management
2) Catalog Module
List of products in the company catalog
3) Wish List Module
API that the customers will user to create and view their wish lists
Our Monolith
- A single WAR file, and has one or more JAR files that provide all of the core functioinality
- Will likely have a common web tier to handle web requests and responses
Breaking This Up
Break the single application into three microservices.
- Auth
- Wish list functionality
- The catalog portion
Benefits of this Structure
- Each microservice has its own Rest APIs that can be userd by the other services
- Reorganize codebase in a more logical way
- Development team can split into smaller feature teams to work on th individual microservices.
- Code and API are more visible to business team
- Individual teams can develop, build, and test their applications locally-team is more productive up front
- Enables containuous integration pipeline
Containers allow you to user Kubernetes.
Transitioning to Microservices
- Addressed some of the microservice building block concrns
- Applied some of the basic principles from the twelve-factor pattern
Our microservices are running in Docker containers, so let's Kube this up.
- Team built one big java WAR file
- Ops team deployed to the dev WebLogic Server
- Local development on WebLogic Servers run on own machines
- Environment set up to use the development database via data sources.
2. Ecommerce Catalog
- View the list of current products
- Understand their specifications
- Save into a with lisht that enables team collaboration
- Get a quote for the with list or go through the purchase process.
Three Modules
1) User Module
Responsible for user management, login, and profile management
2) Catalog Module
List of products in the company catalog
3) Wish List Module
API that the customers will user to create and view their wish lists
Our Monolith
- A single WAR file, and has one or more JAR files that provide all of the core functioinality
- Will likely have a common web tier to handle web requests and responses
Breaking This Up
Break the single application into three microservices.
- Auth
- Wish list functionality
- The catalog portion
Benefits of this Structure
- Each microservice has its own Rest APIs that can be userd by the other services
- Reorganize codebase in a more logical way
- Development team can split into smaller feature teams to work on th individual microservices.
- Code and API are more visible to business team
- Individual teams can develop, build, and test their applications locally-team is more productive up front
- Enables containuous integration pipeline
Containers allow you to user Kubernetes.
Transitioning to Microservices
- Addressed some of the microservice building block concrns
- Applied some of the basic principles from the twelve-factor pattern
Our microservices are running in Docker containers, so let's Kube this up.
2019년 11월 16일 토요일
Microservice Patterns in Kubernnetes
1. Goal
1.1. Build reference architecture for microservices for Kubernetes
2. Architecture Groupings
2.1. Basic building block architectures
2.1.1. Deployment Patterns
2.1.2. Runtime patterns
3. Building Blocks
3.1. Covers the initial concerns
3.1.1. Codebase
3.1.1.1. Code stored in source control
- Example: Git, Perforce
3.1.1.2. Container images stored in an image repository
- Example: Docker Hub, Artifactory
3.1.1.3. Codebase Workflow
3.1.1.3.1. Push code to your source control.
3.1.1.3.2. Automated build is kicked off to build and run tests against code.
3.1.1.3.3. Bild container image; push to image repository.
3.1.1.4. Image Repository
3.1.1.4.1. Stores your code in an image
3.1.1.4.2. Need to decide early on
3.1.1.4.3. Follow your company guidelines
3.1.2. Dependencies
3.1.2.1. Applications modeled in Kubernetes as Deployments and pods
3.1.2.2. Single pod can have many containers inside
3.1.2.3. Commonly seen in Kubernetes: sidecar pattern
3.1.3. Dev/staging/production parity
3.1.3.1. Dev versus Prod in Kubernetes
3.1.3.1.1. Common Kubernetes deployment patterns
- Small footprint: different namespaces with different credentials for dev, staging, and production
- Large footprint: unique Kubernetes installation for dev, staging, and production
3.1.4. Admin processes.
3.1.4.1. Admin process containers tagged in a similar way to the running application
3.1.4.2. Containers run as Kubernetes jobs/chron job
3.1.4.3. Also run as a separate deployment
4. Deployment Patterns
4.1 Patterns around aplication deployment
4.1.1. Application configurations
4.1.1.1. Applications always have associated configuration to make the application work as expected
4.1.1.2. Application Configuration in Kubernetes
4.1.1.2.1. Two ways to store configs
- configMaps: for generic information(example: metadata, version)
- Secrets: for sensitive data(example:passwords)
4.1.1.2.2. Loaded into the pod via
- Environment variables
- Files
4.1.1.2.3. A Word on Secrets
- Secrets are a good start, but depending on the use case, might need something more like ashiCoprp Vault
4.1.2. Build, release, run
- Tag containers at build time with explicit version
- Don't use latest ta for production containers
4.1.2.1. Running in Kubernetes
- High-level constructs to run containers
- Deployments, DaemonSets, ReplicaSets
- Package management provided by Helm
- Adds revision control
4.1.3. Processes
4.1.3.1. Processes and Port Bindings
4.1.3.1.1. Processes
- Keep application stateless
- Goal: Alllow request to go to any container or server by default
4.1.3.1.2. Statelessness in Kubernetes
- Translated to Deployments and pods
- Deployments comprised of ReplicaSets, which are a collection of one or more pods
4.1.3.1.3. Word on StatefulSets
- Typically used to create persistent storage systems like a MySQK shard
4.1.3.2. Port Bindings
- Containers are implemented in pods
- Communicate to each other via well-defined ports
5. Runtime Patterns
Associating Resources in Kubernetes
- Everything is treated as a service, and configurations are stored in a ConfigMap or Secret
Scenario: Replace a Link to a Database
1) Create new database; ensure it's online and ready to accept connections.
2) Update configuration stored in the ConfigMaps or Secrets.
3) Kill the pods that were communicating with the old database.
When Kubernetes starts up the new pods, the new pods automatically pick up the new configuration, and you'll be using the new service.
If a pod is taking too much load or is receiving a lot of requests, it's easy to scale the number of pods in Kubernetes by adding more to the replica set.
Scaling Kubernetes to handle more traffic is one of the strengths of the platform.
5.1. Patterns for live running systems
5.1.1. Backing services
5.1.2. Features around concurreny
5.1.3. Disposability
The abliity to maximize robustness with fast startup and graceful shutdown
Containers
- Start up fast and run efficiently
- Have all required tooling built inside of the container image
Containers to Pods to Replicas
- Kubernetes manages your containers in pods, which are managed with ReplicaSets
- If one of the pods goes offline, the ReplicaSet will automatically start up a new pod to take its place
Advantages to Users
- From a user perspective, the application will still function, and the user won't see any downtime
5.1.4. Log management
5.1.4.1. Logging
- Treat logs as streams: execution environment handles the logs
- Common to user a log router (Beats/Fluentd) to save the logs to a service(Elasticsearch/ Splunk)
- Kubernetes makes this process easy
6. Some Assembly Required
6.1 Basic Knowledge of Kubernetes required
6.2. Watch the Learning Kubernetes course in the library if needed
1.1. Build reference architecture for microservices for Kubernetes
2. Architecture Groupings
2.1. Basic building block architectures
2.1.1. Deployment Patterns
2.1.2. Runtime patterns
3. Building Blocks
3.1. Covers the initial concerns
3.1.1. Codebase
3.1.1.1. Code stored in source control
- Example: Git, Perforce
3.1.1.2. Container images stored in an image repository
- Example: Docker Hub, Artifactory
3.1.1.3. Codebase Workflow
3.1.1.3.1. Push code to your source control.
3.1.1.3.2. Automated build is kicked off to build and run tests against code.
3.1.1.3.3. Bild container image; push to image repository.
3.1.1.4. Image Repository
3.1.1.4.1. Stores your code in an image
3.1.1.4.2. Need to decide early on
3.1.1.4.3. Follow your company guidelines
3.1.2. Dependencies
3.1.2.1. Applications modeled in Kubernetes as Deployments and pods
3.1.2.2. Single pod can have many containers inside
3.1.2.3. Commonly seen in Kubernetes: sidecar pattern
3.1.3. Dev/staging/production parity
3.1.3.1. Dev versus Prod in Kubernetes
3.1.3.1.1. Common Kubernetes deployment patterns
- Small footprint: different namespaces with different credentials for dev, staging, and production
- Large footprint: unique Kubernetes installation for dev, staging, and production
3.1.4. Admin processes.
3.1.4.1. Admin process containers tagged in a similar way to the running application
3.1.4.2. Containers run as Kubernetes jobs/chron job
3.1.4.3. Also run as a separate deployment
4. Deployment Patterns
4.1 Patterns around aplication deployment
4.1.1. Application configurations
4.1.1.1. Applications always have associated configuration to make the application work as expected
4.1.1.2. Application Configuration in Kubernetes
4.1.1.2.1. Two ways to store configs
- configMaps: for generic information(example: metadata, version)
- Secrets: for sensitive data(example:passwords)
4.1.1.2.2. Loaded into the pod via
- Environment variables
- Files
4.1.1.2.3. A Word on Secrets
- Secrets are a good start, but depending on the use case, might need something more like ashiCoprp Vault
4.1.2. Build, release, run
- Tag containers at build time with explicit version
- Don't use latest ta for production containers
4.1.2.1. Running in Kubernetes
- High-level constructs to run containers
- Deployments, DaemonSets, ReplicaSets
- Package management provided by Helm
- Adds revision control
4.1.3. Processes
4.1.3.1. Processes and Port Bindings
4.1.3.1.1. Processes
- Keep application stateless
- Goal: Alllow request to go to any container or server by default
4.1.3.1.2. Statelessness in Kubernetes
- Translated to Deployments and pods
- Deployments comprised of ReplicaSets, which are a collection of one or more pods
4.1.3.1.3. Word on StatefulSets
- Typically used to create persistent storage systems like a MySQK shard
4.1.3.2. Port Bindings
- Containers are implemented in pods
- Communicate to each other via well-defined ports
5. Runtime Patterns
Associating Resources in Kubernetes
- Everything is treated as a service, and configurations are stored in a ConfigMap or Secret
Scenario: Replace a Link to a Database
1) Create new database; ensure it's online and ready to accept connections.
2) Update configuration stored in the ConfigMaps or Secrets.
3) Kill the pods that were communicating with the old database.
When Kubernetes starts up the new pods, the new pods automatically pick up the new configuration, and you'll be using the new service.
If a pod is taking too much load or is receiving a lot of requests, it's easy to scale the number of pods in Kubernetes by adding more to the replica set.
Scaling Kubernetes to handle more traffic is one of the strengths of the platform.
5.1. Patterns for live running systems
5.1.1. Backing services
5.1.2. Features around concurreny
5.1.3. Disposability
The abliity to maximize robustness with fast startup and graceful shutdown
Containers
- Start up fast and run efficiently
- Have all required tooling built inside of the container image
Containers to Pods to Replicas
- Kubernetes manages your containers in pods, which are managed with ReplicaSets
- If one of the pods goes offline, the ReplicaSet will automatically start up a new pod to take its place
Advantages to Users
- From a user perspective, the application will still function, and the user won't see any downtime
5.1.4. Log management
5.1.4.1. Logging
- Treat logs as streams: execution environment handles the logs
- Common to user a log router (Beats/Fluentd) to save the logs to a service(Elasticsearch/ Splunk)
- Kubernetes makes this process easy
6. Some Assembly Required
6.1 Basic Knowledge of Kubernetes required
6.2. Watch the Learning Kubernetes course in the library if needed
피드 구독하기:
글 (Atom)