過去2年間は、コンテナの上昇に伴って、他の技術、この概念は広く言及されているDevOpsチームと多用しKubernetes。この記事では、読者がDevOpsチームの本当の意味を理解するための方法を示すために、実験と組み合わせて次の側面から進めてまいります。
- DevOpsチーム生成された背景
- DevOpsチームと容器との間の関係、Kubernetes
- DevOpsチーム共通のツール
DevOpsチームは何ですか
DevOpsチームのDevは、開発を指しオプスオペレーションを参照すると、1つの文章DevOpsチームは、統合の発展を達成するために、開発、運用・保守への障壁の運用・保守を介して取得することです。
滝からアジャイル開発への展開
DevOpsチームの歴史といえば、私たちは、アジャイル開発について話をする必要があります。
まず、アジャイル開発は、ソフトウェア指向で、コンピューティング・ハードウェアとソフトウェアに依存しています。私たちは、世界初のコンピュータが1946年に登場していることを知っています。そのため、人間の歴史の中でのソフトウェア開発ではなく、長い時間に対して。ソフトウェア開発方法論を習得に関しては、人々は、このような課税、橋、建物などとして、エンジニアリングでより熟達しています。ソフトウェア開発を促進するために、1968年には、ソフトウェア・エンジニアリング、結果のソフトウェアエンジニアリングの分野に法を適用します。
ソフトウェア工学の方法は、その利点を持っていますが、それは多くの問題をもたらしました。重要な点は次のとおりです。ソフトウェアは、プロジェクトとは異なります。完了後、エンジニアリング、高層によって建てられた橋は、人々は通常、多くの橋の主塔のために変更する必要はありません。しかし、ソフトウェアが異なっています。エンドユーザーのためのソフトウェアの場合、人々は絶えず変化しますソフトウェア機能を求めています。需要の変化があるウォーターフォールモデル、クライアントアプリケーションでは、ソフトウェアベンダーは、ソフトウェアを再開発する必要があります。これは、企業の競争力の大幅な下落を行います。
伝統的なソフトウェア開発プロセスは、次のとおりです。最初の行のプロダクトマネージャーの新しい機能要件もあり、ビジネスや顧客の要件を収集するために、それは既存の機能のニーズが変更を行う物であってもよいです。そして、分析、評価され、これらの要件は、製品ロードマップのために開発され、関連する作業のための適切なリソースを割り当てます。次に、プロダクトマネージャーは、開発エンジニアがコードを書くために、開発部門への出力を要求します。書かれた後は、生産部門に最終的に異なる構造化されたコードのフォローアップの部門、品質テスト、統合テスト、ユーザー受け入れテストによって行われ、されるだろう。そのような問題は、開発サイクルが長くなり、引き起こされ、そして任意の変更がある場合、我々は、今日、このような戦場としてショッピングモールでは、開発プロセス上で再取る必要があり、既に市場にこのリリースを公開することができた場合、ソフトウェアのバージョンのリリースを遅らせます日付のうち、競合他社は、より高速なステップで新しいソフトウェアのリリースのために起因する可能性があり、かつ迅速に顧客や市場を押収しました。
ビジネス環境の圧力で、企業がソフトウェア開発の方法を改善する必要があるからです。
初期の2001年には、17人の専門家一緒に米国のスキー場のスノーバードは、より迅速に作業を行うことができます変更に対応する容量値の原則をソフトウェア開発チームのいくつかを概説しました。彼らは、「アジャイルアライアンス。」自分自身を呼び出します
次のようにアジャイル開発の主な値は次のとおりです。
アジャイル開発の表1のコアバリュー
アジャイルアライアンスによって、アジャイル値でジャンルの開発を持っているでしょう。アジャイル開発の主な学校がある：エクストリーム・プログラミング（XP）、スクラム、クリスタル・メソッド。
この時点では、アジャイル開発の概念があり、方法があり、練習があります。クラウドコンピューティングのクラウドコンピューティングの概念の上昇はツールのアジャイル開発を実現するためだけではなく、下がり続けば、さらに昇華されています。
DevOpsチームにアジャイル開発から
アジャイル開発、アジャイル開発、DevOpsチームについて話しましたので、それは何を問題ではありませんか？
アジャイル開発は、ドメインの概念、アジャイル開発の基礎、次の段階の開発です。
アジャイル開発 - >継続的インテグレーション - >連続配信 - >継続的デプロイ - > DevOpsチーム
DevOpsチームにアジャイル開発の基礎から、前のステージの後のステージであり、最終的には完全な開発・運用・保守フェーズをカバーしDevOpsチーム、事前の段階では、プロセスの各段階は、より多くの概念でカバー。各段階に関わる公式の範囲によっては、それが提供される各コンセプトのツールであることは同じではありません。詳細については、我々は以下の表を参照してください。
高度なDevOpsチームにアジャイル開発から、図1
継続的インテグレーション（継続的インテグレーション）は意味：コードはトランクに統合される前に、自動テストを介してすべての必要があります。限りがあるので、テストケースが失敗し、それが統合することはできません。達成すべき継続的インテグレーションの目標は以下のとおりです。高品質を維持することに基づいて、製品を迅速に繰り返すことができるように。
連続配信（連続配信が）意味：ソフトウェアの開発者が頻繁に新しいバージョン、レビューのために、チームの品質や利用者に配信。場合は、コードによるレビューがリリースされました。審査が通過しない場合は、その変更を開発し、その後、提出する必要があります。
継続的デプロイ（継続的デプロイは）意味：自動的に配信を展開し、コードレビューを経て公開し、。
DevOpsチームは 、彼らがより迅速かつ確実に、テストおよびリリースソフトウェアを構築することができるように、ソフトウェア開発とITチーム間のプロセスを自動化することができる実践の完全なセットです。
2.図の概略図をDevOpsチーム。
技術のDevOpsチーム
標準出荷、コンテナ管理プラットフォーム、DevOpsチームツールチェーン：技術のDevOpsチームは、三つの側面が必要です。次に、我々は詳細三つの側面にこれを見て。
技術1のDevOpsチーム：標準成果
互いの開発・運用・保守の間の通信よりスムーズに、高速で、企業は市場の変化に適応することができるようになるDevOpsチームは、開発・運用・保守の統合を行うことを目指しています。
もちろん、本物の統合運用・保守の開発、開発としない人だけの操作とメンテナンスが一緒にとてもシンプルに座ってみましょう。技術的な観点から、DevOpsチームは、最初の「オペレーティングシステム+ランタイム+アプリケーション」成果物が含まれている標準を持っている必要があります。また、我々はまた、全体DevOpsチームのプロセスを経て開く必要があります。
在 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：