【译】助你成功搭建云应用的12条方法

原文作者:Rafael Benevides 原文地址:https://dzone.com/articles/12-factors-to-cloud-success-rhd-blog

原文

Hey, developers! Do you care about using the best practices to apply your application to the cloud? If so then you should be using The 12-factor App, which is a methodology for building Software-as-a-Service. Today, I’d like to talk about the 12-factor App, which I had presented to a group at the Red Hat Summit last month.

Every developer that is moving their application to the cloud will face a different environment than what they are used to, their datacenter or own premise and that’s why they should care about the 12-factor methodology. This 12 step methodology was created by Heroku, which is a cloud provider who found a common solution to most of what their customers were experiencing and decided to release these solutions as a methodology. These 12 factors are intended to solve problems related to applications running in the cloud. If there was one key takeaway from my session it was not the idea to have the audience memorize these 12 factors but to have an understanding of why each one is important.

Codebase – Use version control, one codebase tracked in revision control for many deployments.


Dependencies – Use a package manager and don’t commit dependencies in the codebase repository.


Config – Store the config in Environment Variable, if you have to repackage your application, you’re doing it wrong.


Backing Services – A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code.


Build, Release, Run – The twelve-factor app uses strict separation between the build, release, and run stages. Every release should always have a unique release ID and releases should allow rollback.


Processes – Execute the app as one or more stateless processes. The Twelve-factor processes are stateless and share-nothing.


Port Binding – Export services via port binding, The twelve-factor app is completely self-contained.


Concurrency – Scale out via the process model. Each process should be individually scaled, with Factor 6 (Stateless), it is easy to scale the services.


Disposability – Maximize robustness with fast startup and graceful shutdown, we can achieve this with containers.


Dev/Prod Parity – Keep development, staging, and production as similar as possible, the twelve-factor app is designed for continuous deployment by keeping the gap between development and production small.


Logs – Treat logs as event streams, a twelve-factor app never concerns itself with routing or storage of its output stream.


Admin Processes – run admin/management tasks as one-off processes.

The 12-factor App methodology is technology and language agnostic but satisfied by Containers, Microservices, and CI/CD Pipelines with a focus on DevOps. You can access more information on The 12-factor App here.

译文:

你好,开发者们!你是否想了解应用程序在云端的最佳应用体验?那么,你最好使用12-Factor App,将你的程序部署为Saas(Software-as-a-Service译:软件即服务)的云应用。今天,我想谈谈我上个月在Red Hat Summit上的关于12-Factor App的分享。

每一个正在将应用程序迁移到云端的开发人员都将面临一个与过去完全不同的环境,他们使用数据中心或自己的机房,这就是为什么他们应该关注12-Factor App的原因。这十二条是由Heroku这一个云提供商发布的一个通用的解决方案,大多数他们的客户决定放出这些解决方案作为一种方法论。这十二条特性旨在解决与云中运行的应用程序相关的问题。如果用一句话概括我的这个分享,并不是想法让大家记住这十二条特性,而是想让了解为什么每一个都是非常重要的。

  1. 基准代码 - 使用版本控制,一份基准代码,多份部署的版本控制。
  2. 依赖 – 使用包管理器且不要提交依赖关系到在代码库。
  3. 配置 – 将配置存储在环境变量中,如果你将其打包进你的应用中,你就大错特错了。
  4. 后端服务 — 一个12-Factor App部署应该支持切换到一个本地MySQL数据库,或由第三方管理(如Amazon RDS)的数据库,而无需对程序的代码进行任何更改。
  5. 构建、发布、运行 — 12-Factor App在构建、发布和运行阶段之间使用严格隔离。每个发行版都应该有唯一的发行ID,发行版应该支持回滚。
  6. 进程 — 将应用程序作为一个或多个无状态进程执行。12-Factor App的进程应该是无状态和无共享的。
  7. 端口绑定 — 通过端口绑定提供服务,一个符合这十二条特性的是完全自包含的。
  8. 并发性 — 通过过程模型扩展。每一个进程都应该按Factor 6(无状态)单独缩放,很容易扩展服务。
  9. 易处理 – 最大化快速启动和优雅终止可最大化健壮性,我们可以实现这个容器。
  10. 开发环境与线上环境等价 - 保持开发,分期,生产尽可能相似,12-Factor App是为了保持持续的开发和生产之间的差距小规模部署。
  11. 日志 — 将日志视为事件流,一个12-Factor App从不担心其输出流的路由或存储。
  12. 管理进程 - 后台管理任务当作一次性进程运行。

12-Factor App和技术或语言无关,但你可以在DevOps关注容器,微服务,CI / CD的管道相关的技术。更多关于12-Factor App的信息请点击这里.

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张戈的专栏

CVE-2015-0235:Linux glibc高危漏洞的检测及修复方法

这几天复习运维知识,也没怎么关注业界新闻,可等我一关注,又“捅娄子”了,Linux 继上次CVE-2014-6271漏洞爆发以来,再次爆发一个严重漏洞:CVE-...

2404
来自专栏FreeBuf

记一次Linux服务器被入侵后的检测过程

0x00 前言 故事是这样的,大年初一,客户反应他们服务器无法访问,查看路由,发现某oracle+tomcat服务器UDP流量超大,把带宽占完了,过年嘛,客户那...

3395
来自专栏IT派

美剧迷是如何使用Python的

一直有爱看美剧的习惯,一方面锻炼一下英语听力,一方面打发一下时间。之前是能在视频网站上面在线看的,可是自从广电总局的限制令之后,进口的美剧英剧等貌似就不在像以前...

952
来自专栏北京马哥教育

记一次Linux服务器被入侵后的检测过程

? 作者 | 哈兹本德 来源 | FreeBuf ? 豌豆贴心提醒,本文阅读时间5分钟,文末有秘密! 0×00 前言 故事是这样的,大年初一,客户反应...

3015
来自专栏静晴轩

大前端神器安利之 Puppeteer

Puppeteer(中文翻译”木偶”) 是 Google Chrome 团队官方的无界面(Headless)Chrome 工具,它是一个 Node 库,提供了一...

5176
来自专栏逸鹏说道

项目分布式部署那些事(1):ONS消息队列、基于Redis的Session共享,开源共享

因业务发展需要现在的系统不足以支撑现在的用户量,于是我们在一周之前着手项目的性能优化与分布式部署的相关动作。 概况 现在的系统是基于RabbitHub(一套开源...

2796
来自专栏WeTest质量开放平台团队的专栏

分布式系统设计的求生之路

分布式系统理念渐渐成为了后台架构技术的重要选择,本文介绍了作者在手游领域对分布式系统进行的种种尝试,并在尝试中制定了对服务的定义、整体框架的构建以及服务内部拆分...

742
来自专栏大数据和云计算技术

云存储产品浅析

云上存储产品主要有对象存储,块存储,网络文件系统(NAS),还有最赚钱的CDN,我们将针对这些主流产品,讲讲他们产品特点,有云上存储时候知道如何选型,当然我们是...

1142
来自专栏北京马哥教育

Python爬虫爬取美剧网站

一直有爱看美剧的习惯,一方面锻炼一下英语听力,一方面打发一下时间。之前是能在视频网站上面在线看的,可是自从广电总局的限制令之后,进口的美剧英剧等貌似就不在像以前...

1030
来自专栏杨建荣的学习笔记

远程协助解决异常宕库的问题(r11笔记第75天)

昨天帮助一个网友处理了一个数据库异常宕机的问题,简单记录一下。 说到这个问题,也是一位网友给我发邮件说有一个数据库环境,会突然出现宕机的情况,想让我帮忙...

3404

扫码关注云+社区