神话还是现实?Docker 和 Kubernetes 架构
虽然 Kubernetes 只要求在物理机器/云虚拟机上的少量组件(docker、kubelet、kube proxy、etcd 集群),但你仍然需要能够自动化完成添加新机器和对集群进行管理。以下是几个简单的方法:
就我个人而言,我更喜欢第 3 个选项(加上一个 Kubernetes 集成模块 ),因为它允许我同时使用服务器和 k8s 对象,并实现任何类型的自动化。然而,没有什么能阻止你使用 Teraform 及其 Kubernetes 模块 。KOPS 不能很好地使用“裸机”,但是它仍然是一个很好的使用 AWS/GCE 的工具! Git 代码库和任务跟踪器 不用说,要为开发人员和其他相关角色提供全面的工作环境,你需要有一个团队协作和代码存储的地方。我很难确定哪种服务是最合适的,但我个人最喜欢的任务跟踪工具是 redmine (免费)或 Jira (付费)。对代码库而言,有比较老牌的 gerrit (免费)或 bitbucket (付费)。 值得注意的是,企业环境中协作工作的两个最一致的工具(尽管是商业版本的)是: Atlassian 和 Jetbrains 。你可以使用它们中的任何一个作为独立的解决方案,或者将两者的各种组件结合起来。 要充分利用任务跟踪器和代码库的组合,请考虑它们的集成策略。例如,以下是一些确保代码和相关任务关联性的提示(当然,你也可以选择自己的方法):
Docker 注册表 应特别注意 Docker 镜像管理系统,因为它对于存储和交付服务至关重要。此外,该系统应该支持用户和用户组的访问,能够删除旧的和不必要的镜像,提供图形用户界面和 RESTful 应用编程接口。 你可以使用云解决方案(例如, hub.docker.com )或私有托管服务,甚至可以安装在你的 Kubernetes 集群中。作为 Docker 注册表的企业解决方案, Vmware Harbor 就是一个很好的例子。最坏的情况是,如果你只想存储镜像,而不需要复杂的系统,你就直接使用 Docker Registry 好了。 CI/CD 和服务交付系统 我们之前讨论过的组件(git 存储库、任务跟踪器、带有 Ansible 剧本的元项目、外部依赖项)都不能像悬浮在真空中一样彼此分开运行。将它们连接起来的是持续集成和交付服务。 CI — 持续集成 (Continuous Integration) CD — 持续交付(Continuous Delivery) 服务应该足够简单,并且没有任何与系统交付或配置相关的逻辑。CI/CD 服务应该做的就是对外部世界的事件(git 存储库中的变化,任务跟踪器中任务的移动)做出反应,并启动元项目中描述的操作。此外,CI/CD 服务是管理所有代码存储库的控制点和管理它们的工具(代码分支合并、来自上游/主分支的更新)。 我使用过一个来自 Jetbrains 的 工具 TeamCity ,这是一个相当强大但非常简单的工具。但是你也可以决定尝试其他东西,比如免费的 Jenkins 。 在我们上面描述的方案中,集成服务主要负责启动四个主要流程和一个辅助流程,如下所示:
(编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |