Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

12 Factor Apps in Docker

軟體技術在當代有兩大外在動力(App 和 Big Data),三大內在改變(Agile/DevOps、NoSQL、Cloud)。這也衍生出打造現代應用/App 的三種原則,分別是 Reactive System 設計、Microservices 架構、12 因子的 App 設計元素,這三大原則或多或少都有重複。而 Docker 技術的設計,則大量遵循了最後這 12 個因素的設計元素。 只要理解了這 12 個因素,就更容易了解 Docker 的運作思維。
by

William Yeh

on 21 March 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 12 Factor Apps in Docker


Business Forces & Challenges
App
Big Data
Source: http://pro.clubic.com/it-business/article-508407-1-big-data-analyse-donnees-interesse-entreprises.html
Source:
http://www.ithome.com.tw/node/74550
http://tedxtaipei.com/2012/04/tedxtaipeichange-thebigpictrue-session1-conten/
desktop-first era
web sites
desktop applications
mobile-first era
web applications
mobile apps
responsive web design
Source: http://www.slideshare.net/kleinerperkins/internet-trends-2014-05-28-14-pdf
On-Demand Self-Service
Broad Network Access
Resource Pooling
Rapid Elasticity
Measured Service

Emergent Technologies
NoSQL
Source: http://blogs.mulesoft.org/nosql-and-big-data-connectors-for-mule/
Microservices
Reactive Manifesto
http://www.reactivemanifesto.org/
Message Driven
Responsive
Resilient
Elastic
Reactive
System

Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Source: http://www.thoughtworks.com/insights/blog/microservices-nutshell
http://12factor.net/
evolving...
12 Factors
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
Codebase
Dependencies
Config
Backing Services
Build, release, run
Processes
Port binding
Concurrency
Disposability
Dev/prod parity
Logs
Admin processes
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
Treat backing services as attached resources
Strictly separate build and run stages
Execute the app as one or more stateless processes
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
Keep development, staging, and production as similar as possible
Treat logs as event streams
Run admin/management tasks as one-off processes
Common sense in this DevOps era...
Source: http://12factor.net/codebase
Codebase @ GitHub
Registry @ Docker Hub
Mary Meeker
Strict separation of config from code

Litmus test:
Whether the codebase could be made open source at any moment, without compromising any credentials.
Strong form
Weak form
inject
my.cnf
into container's
/etc/mysql/my.cnf
Source: http://12factor.net/backing-services
Ambassador
client 3
proxy
link via ambassador
Redis server
Ambassador
client 1
client 2
proxy
link by name
link via ambassador
HA key-value stores
etcd
ZooKeeper
Dynamic service discovery
Grand Ambassador
Orchestration
Docker Swarm
10.240.136.85
Microservices
Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Source: http://www.thoughtworks.com/insights/blog/microservices-nutshell
evolving...
Best practices:
stateless and share-nothing.
Horizontal scaling.
one app can become the backing service for another app, by providing the URL
Common practice in the REST world
Microservices
Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Source: http://www.thoughtworks.com/insights/blog/microservices-nutshell
evolving...
stateless and share-nothing
(again!)
They should never daemonize or write PID files. Instead,
rely on the OS’s process manager
systemd
Upstart
distributed orchestration
Restart policies
(Docker ≥ 1.2)
no
on-failure
always
Orchestration
Docker Swarm
Mesos + Marathon
Kubernetes
fleet
Reverse proxy + load balancer
HAProxy or Nginx
mailgun/vulcand + ehazlett/havok
Microservices
Message Driven
Responsive
Resilient
Elastic
Reactive
System
Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Source: http://www.thoughtworks.com/insights/blog/microservices-nutshell
1. codebase
2. dependencies
3. config
4. backing services
5. build, ship, run
6. processes
7. port binding
8. concurrency
9. disposability
10. dev/prod parity
11. logs
12. admin processes
“build once, run anywhere”
same app images across DevOps stages
emulated production environments
configuration management for server clusters
write its event stream, unbuffered, to
stdout
.
visible on console
Dev
captured by the execution environment for further processing
Ops
logs
stdout
stderr
Process injection
(Docker ≥ 1.3)
docker exec ...
Source: http://www.quora.com/Is-the-Twelve-Factor-App-methodology-correct
"dependencies"
"isolation"
Source: http://denigma.de/gallery/391
@ Code Conference, May 2014
Fluentd
(in
Ruby
)
log
Elasticsearch
(in
Java
)
9200
stdout
“All problems in computer science can be solved by another level of
indirection

Why?
... to be nice for technologies:
replication
containment
isolation
delegation
Agile & DevOps
Source: http://en.wikipedia.org/wiki/DevOps
write to or manage logfiles
Basic feature:
location transparency
Advanced features:
green/blue deployment
zero downtime deployment
DevOps
NoSQL
Cloud
e.g.,
SUT vs Test Double
Cloud
Cloud
Cloud
SOLID
principles, especially:
SRP
(single responsibility principle)
ISP
(interface segregation principle)
DIP
(dependency inversion principle)

... applied to cloud software architecture
Full transcript