지난 2 년 동안, 용기의 상승, 다른 기술,이 개념이 널리 언급 된 개발 운영하고 많이 사용는 Kubernetes. 이 기사는 독자 개발 운영 팀의 진정한 의미를 이해 할 수있는 길을 보여주기 위해 실험과 함께 다음과 같은 측면에서 진행됩니다.
- 생성 된 배경을 개발 운영
- 개발 운영과 용기 사이의 관계는 Kubernetes
- 일반적인 도구를 개발 운영
무엇 개발 운영팀입니다
개발 운영 데브는, 개발을 의미 본부가 운영을 언급 한 문장 개발 운영팀은 통합의 개발을 달성하기 위해 개발, 운영 및 유지 보수에 대한 장벽의 운영 및 유지 보수를 통해 얻을 수 있습니다.
애자일 개발에 폭포에서 개발
개발 운영 팀의 역사의 말하기, 우리는 애자일 개발에 대해 이야기 할 필요가있다.
첫째, 애자일 개발은 소프트웨어 지향, 컴퓨팅 하드웨어와 소프트웨어에 의존하고 있습니다. 우리는 세계 최초의 컴퓨터가 1946 년에 나타난 것을 알고있다. 따라서, 인간의 역사에서 소프트웨어 개발이 아니라 오랜 시간에 대한. 소프트웨어 개발 방법론을 습득에 대한, 사람들은 부과, 교량 건설 등으로, 엔지니어링 더 능숙하다. 소프트웨어 개발을 촉진하기 위해, 1968 년에, 그것은 소프트웨어 공학, 그 결과 소프트웨어 공학 분야에이 방법을 적용합니다.
소프트웨어 공학의 방법은 장점이 있지만 많은 문제를 가져왔다. 중요한 점은 다음과 같습니다 소프트웨어는 프로젝트 다르다. 완료 후 엔지니어링, 고층에 의해 만들어진 다리, 사람들은 일반적으로 많은 다리의 메인 타워에 대한 변경이 필요하지 않습니다하지만 소프트웨어는 다릅니다. 최종 사용자를위한 소프트웨어의 경우, 사람들은 끊임없이 변화한다 소프트웨어 기능을 요구한다. 수요의 변화가 폭포 모델, 클라이언트 응용 프로그램에서 소프트웨어 공급 업체는 소프트웨어를 다시 개발해야한다. 이 기업의 경쟁력에 상당한 감소를 만들 것입니다.
전통적인 소프트웨어 개발 프로세스는 다음과 같습니다 새로운 기능 요구 될 수있다 비즈니스 및 고객 요구 사항을 수집하는 최초의 온라인 제품 매니저, 그것은 기존 기능의 제품 요구 될 변화를 할 수 있습니다. 그리고 분석, 평가, 이러한 요구 사항은 제품 로드맵을 위해 개발되고 관련 작업에 대한 적절한 자원을 할당 할 수 있습니다. 다음으로, 제품 관리자는 개발 부문에 출력을 요구하는 것, 개발 엔지니어들은 코드를 작성합니다. 작성 후, 생산 부문에 마지막으로 다른 구조로되어 코드의 후속 부서, 품질 테스트, 통합 테스트, 사용자 수용 테스트에 의해 수행 될 것입니다. 이러한 문제는 개발주기가 긴, 발생 및 변경이있는 경우, 우리는 오늘과 같은 전장으로 쇼핑몰, 개발 과정을 통해 다시 수행해야 시장에 이미 출시를 게시 할 수있는 경우, 소프트웨어의 버전의 릴리스를 지연 오래된, 경쟁 인해 단계 빠른에서 새로운 소프트웨어에 출시 될 가능성이 신속하게 고객과 시장을 장악.
비즈니스 환경의 압력, 회사는 소프트웨어 개발 방법을 개선 할 필요가 있기 때문이다.
2001 년 초, 17 전문가 함께 미국의 스키 리조트의 피한 객은,보다 신속하게 작업을 할 수 있습니다 변화에 대응하는 용량 값의 원리를 소프트웨어 개발 팀의 일부를 설명했다. 그들은 "민첩한 얼라이언스."자신을 호출
다음과 같이 애자일 개발의 주요 값은 다음과 같습니다
애자일 개발의 표 1. 핵심 가치
민첩한 얼라이언스와 함께, 애자일 값 장르 개발을 할 것입니다. 애자일 개발의 주요 학교는 다음과 같습니다 익스트림 프로그래밍 (XP), 스크럼, 크리스탈 방법.
이 시점에서, 애자일 개발의 개념이, 방법이 실제로있다. 클라우드 컴퓨팅의 클라우드 컴퓨팅 개념의 상승이 도구의 애자일 개발을 달성하기 위해뿐만 아니라, 계속 하락으로도 승화되었다.
개발 운영 팀에 애자일 개발에서
애자일 개발, 애자일 개발 및 개발 운영 팀에 대해 이야기를 그래서 무슨 상관입니까?
민첩한 개발 도메인 개념, 애자일 개발의 기초, 다음 단계의 개발이다 :
민첩한 개발 -> 지속적인 통합 -> 연속 납품 -> 연속 배포 -> 개발 운영
개발 운영 팀에 애자일 개발의 기초에서, 이전 단계 이후 단계이며, 궁극적으로는 전체 개발과 운영 및 유지 보수 단계를 포함 개발 운영, 사전 단계로, 프로세스의 각 단계는 점점 더의 개념에 포함. 각 단계에 포함 된 공식의 범위에 따라, 그래서 제공하는 각각의 개념 도구입니다 것은 동일하지 않습니다. 자세한 사항은 우리는 다음 표를 참조하십시오
고급 개발 운영 팀에 애자일 개발에서 그림 1
지속적인 통합 (연속 통합) 의미 : 코드 트렁크에 통합되기 전에 모든 자동화 된 테스트를 통해해야 한 테스트 케이스가 실패로, 그것은 통합 할 수 없습니다. 달성 할 수있는 지속적인 통합의 목표는 다음과 같습니다 높은 품질을 유지하는 기초 제품을 신속하게 반복 할 수 있도록.
연속 배달 (연속 배달) 의미 : 개발자들에게 검토를 위해, 팀 또는 사용자의 품질에 제공되는 소프트웨어를 자주 새 버전을. 경우 코드에 의한 검토가 출시되었습니다. 검토가 통과하지 않는 경우, 변경을 개발 한 후 제출해야합니다.
연속 배포 (연속 배포) 자동으로 전달에 배포, 검토를 통해 코드를 게시 : 의미한다.
개발 운영 팀은 그들이 더 빠르고 안정적으로 구축, 테스트 및 소프트웨어를 해제 할 수 있도록 소프트웨어 개발과 프로세스 및 IT 팀을 자동화 할 수 있습니다 관행의 전체 집합입니다.
2. 도시하는 개략도 개발 운영.
기술의 개발 운영
표준 배달, 컨테이너 관리 플랫폼을 개발 운영 툴체인 : 기술의 개발 운영 팀은 세 가지 측면을 필요로한다. 다음으로, 우리는 세부 사항 세 가지 측면에서 이것 좀 봐.
기술 1의 개발 운영 : 표준 산출물
서로의 개발과 운영 및 유지 보수 사이의 통신을 원활하게, 빠르게, 기업은 시장의 변화에 적응 할 수 있도록 있도록 개발 운영 팀은, 개발, 운영 및 유지 보수의 통합을하는 것을 목표로하고있다.
물론, 통합 운영 및 유지 보수, 개발 및하지의 진정한 발전 단지 운영 및 사람들의 유지 보수가 함께 간단 앉아 보자. 기술적 인 관점에서 개발 운영 팀은 먼저 "운영 체제 + 런타임 + 응용 프로그램"인도를 포함하는 표준이 필요합니다. 또한, 우리는 또한 전체 개발 운영 프로세스를 통해 열어야합니다.
在 IT 早期，厂商硬件和系统平台的差异化过大，在不同硬件和系统平台进行应用的无缝迁移几乎是不可想象的。随着 X86 服务器以及 vSphere 等虚拟化技术的普及，操作系统（包括操作系统上的应用）可以在不同 X86 服务器厂商的硬件平台上在线无缝迁移。硬件差异化不断缩小甚至消失，软件的重要性不断提升，IT 界真正进入软件定义一切的时代。在这个背景下，业务提出了更高的要求，如何将应用在不同操作系统之间实现无缝迁移，将开发和生产统一，做到“构建一次，到处运行”。
容器技术的概念最初出现在 2000 年，当时称为 FreeBSD jail，这种技术可将 FreeBSD 系统分区为多个子系统。
但直到 Docker 的出现（2008 年），容器才真正具备了较好的可操作性和实用性。因为 Docker 提供了容器的镜像构建、打包等技术，使容器具备了一次打包，到处运行的能力。
对于客户而言，Docker 只能在一个 Linux 上运行，是“单机版”，很难符合企业对高可用的需求。此外，docker 也缺乏和持久存储、虚拟网络相关的功能。
DevOps 的技术实现 2：容器调度平台
2014 年 Kubernetes 的出现，奠定了今天容器调度平台的事实标准的基础。
因为通过 Kubernetes，我们不仅实现了容器在多个计算节点上的统一调度，还可以将容器对接持久存储、对接虚拟网络等。换句话说，Kubernetes 使容器具备企业级的功能。
图 3. Kubernetes 架构
DevOps 的技术实现 3：DevOps 工具链
在有了容器和 Kubernetes 以后，我们还需要相关的 DevOps 工具链。
目前在 IT 界，DevOps 相关的工具很多，其中大多数是开源的工具，如下图。
图 4. DevOps 工具链
总结：DevOps 与容器和 Kubernetes 的关系
PaaS、DevOps 的概念，在容器和 Kubernetes 普及之前就存在了。广义上的 PaaS、DevOps 的建设，会包含：人、流程、工具等多方面内容。IT 厂商提供的 PaaS、DevOps 以指工具层面的落地为主、以流程咨询为辅。
在 Kubernetes 和容器普及之前，我们通过虚拟机也可以实现 PaaS、CI/CD，只是相对速度较慢，因此普及性不高（想象一下通过 X86 虚拟化来实现中间件集群弹性伸缩的效率）。而正是容器的出现，为 PaaS、DevOps 工具层面的落地提供非常好的承载平台，使得这两年容器云风生水起。这就好比 4G（2014 年出现）和微信（2011 年出现）之间的关系：在手机网速 3G 时代，流量按照兆收费的时候，（即使有）大家对于微信语音聊天、微信视频也不会太感兴趣。
所以说， Docker 使容器具备了较好的可操作性、可移植性，Kubernetes 使容器具备企业级使用的条件。而 IT 界众多基于 Kubernetes 和 Docker 企业级的容器平台，又成为了 Devops 工具落地的新一代基础架构。
常用 DevOps 工具介绍
- Kubernetes 集群：包含 Docker 和 Kubernetes。
- Gogs: 通过 Go 编写的本地代码仓库，功能与 github 类似。
- Jenkins/Jenkins Slave Pods：持续集成工具。
- Nexus :工件管理器，能够解决本地缓存构建依赖项。
- SonarQube：开源代码分析工具，它可以分析常见编程错误的源代码。
以上的 DevOps 工具，都可以以容器方式部署到 Kubernetes 集群中。
其他工具类型及对应的不完全列举整理如下：
-
代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
-
构建工具：Ant、Gradle、maven
-
自动部署：Capistrano、CodeDeploy
-
持续集成（CI）：Bamboo、Hudson、Jenkins
-
配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
-
容器：Docker、LXC、第三方厂商如AWS
-
编排：Kubernetes、Core、Apache Mesos、DC/OS
-
服务注册与发现：Zookeeper、etcd、Consul
-
脚本语言：python、ruby、shell
-
日志管理：ELK、Logentries
-
系统监控：Datadog、Graphite、Icinga、Nagios
-
性能监控：AppDynamics、New Relic、Splunk
-
压力测试：JMeter、Blaze Meter、loader.io
-
预警：PagerDuty、pingdom、厂商自带如AWS SNS
-
HTTP加速器：Varnish
-
消息总线：ActiveMQ、SQS
-
应用服务器：Tomcat、JBoss
-
Web服务器：Apache、Nginx、IIS
-
数据库：MySQL、Oracle、PostgreSQL等关系型数据库；cassandra、mongoDB、redis等NoSQL数据库
-
项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker
在工具的选择上，需要结合公司业务需求和技术团队情况而定。（注：更多关于工具的详细介绍可以参见此文：51 Best DevOps Tools for #DevOps Engineers）
refer：