所谓现代化智慧 IT，所有工程师最希望的境界，莫过于只要轻松点几下设定，系统就会自动跑起来，管理者再也不用随时待命在机台旁边，从此工作悠哉又快乐！儘管这样情境还没到来，但随着敏捷式开发的流行，除了 DevOps 人员，有越来越多开发者将 CI/CD 概念融入到工作流程当中，例如从 build code、执行 unit test、到部署应用程式。


透过 AWS 增加云端技能 在组织发挥影响力


上述种种反复步骤自动化执行，也就能提昇服务品质、主动通知开发人员以减轻人力负担，让专案服务能持续运作。




其中，GitLab 是执行 CI/CD 常用的工具之一，也是开发者使用程式码储存库的地方。为了让 GitLab Runner 在云端快速实践 CI/CD，《AWS 开发者系列》透过影片分享，如何在 Amazon EKS（Elastic Kubernetes Services）上使用 GitLab 创建自动化部署。


以下节录工作坊影音内容，帮助开发者快速理解如何运用 Amazon EKS 的高可用性且安全的丛集，将修补、部署节点、更新等关键任务，全部做到自动化设定。同时影片也会示范 Amazon EKS 搭配 GitLab 如何展开自动部署，帮助工程团队实践 CI/CD 价值。


Amazon EKS 对容器管理轻松简单、维运省时省力
容器化服务越来越兴盛，当容器（Container）越来越多，在複杂的微服务（Microservice）系统环境之下，运维团队的管理成本可能相对会增加不少，为了有效调度容器部署， 导入Kubernetes 无疑是近年企业热门的话题之一。


建构 Kubernetes Cluster 流主要可区分两大块，一是安排容器调度的Control Plane、另一则是容器运行时需要用到的 Worker Node。




Control Plane 裡面涵盖有储存状态的 ETCD、CoController manager 、Scheduler 的调度管理、甚至是操作时进行互动的 APIServer，若是自己创建 的 Kubernetes Cluster ，需要自己安装这些元件，后续仍需要对 Control Plane 进行相关管理、维护、升级工作。为了减少上述 Components 的繁複维护，在透过 AWS EKS 代管的 Kubernete Control Plane 部可以获得以下三大好处。


Amazon EKS 一键式部署，展现三大优势
第一，Amazon EKS代管的 Control Plane实践了跨AZ的高可用部署，使用者不需要担心单一节点故障的风险。


第二，Amazon EKS 支持至少四个 Kubernetes版本，持续跟进每季 CNCF 的发佈，同时 EKS 也完全符合上游 CNCF 规范。


第三，部署 Amazon EKS 之后，可直接使用 AWS 平台上现成的服务工具，在安全性管理、网路设定方面，可以做到无缝整合。




最后 AWS 台湾解决方案架构师也提到，若想在容器环境进行 CI/CD 及应用程式的管理，可以进一步透过 IaC 整合部署 Amazon EKS 丛集，透过使用 Console、把 EKS 变成 Cloudformation 的模板、使用 AWS 所开发出来的 eksctl.io、或指令是採用 AWS CDK 可以让开发者用自身熟悉的语言，在 AWS 平台整合 CI/CD 工具进行维运及部署 EKS。


打造第一个在 AWS 上的应用程式


了解 Amazon EKS 整合 GitLab ，获得三面向价值
对开发者而言，想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上，可以看到那些实际的优势？


在 DevOps 开发者示范工作坊当中，GitLab 资深解决方案架构师指出，GitLab 使用到 Kubernetes 技术，主要有三种搭配方法，包含 GitLab Server、GitLab Runner、以及创建 Deployment Environment。


本次示范教学会主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式进行 Build、Test、Package Apps；以及在 Deployment Environment 运用 Kubernetes 技术，做到 Auto Deploy、Review App。


正因为 Amazon EKS 能够在 DevOps 过程提供所需要的弹性计算资源，帮助开发者在 GitLab 平台上面获得以下三个层次的优势：


在 GitLab 内建的部署工作流程当中，自动生成整套 CI/CD 最佳实践脚本。
Review App 过程，从 Merge Request 中可直接访问应用程式 /App 的 UI 介面，并且根据 Git branch 名称、专案名称，自动生成 Review App 的 URL，以及在 Merge 前的最后防线进行 Approval 检查。
加速 CI/CD 流水线，GitLab Runner 运行时候还可藉由 Amazon EKS Cluster 进行 Auto-scaled 的支援。
Amazon EKS 整合 GitLab ，需要两大流程
影片最后，GitLab 资深解决方案架构师示范如何把 Amazon EKS 整合至 GitLab 执行 Auto Deploy，主要可分为两大区块流程，第一部分聚焦在 Amazon EKS cluster 的设置，第二部分则执行 Auto Deploy 设置。


第一块可拆分为四个阶段，首先教学怎麽创建 EC2 节点的 EKS cluster，第二阶段示范把 EKS Cluster 连接到开发者的 GitLab Instance、Group 或 Project，下一步则使用 Cluster Management Project Template 创建一个 Cluster Management Project，以及最后一阶段透过 Cluster Management Project 自带的 Helm Chart，安装在 Cluster 所需要的内建 App。


第二块执行 Auto Deploy 设置，针对需要部署的 App 创建一个 GitLab Project，接着再把 gitlab-ci.yml 添加到 Project，并从 Web IDE 选择及导入 Auto Deploy 的 CI 模版，让 GitLab 自动生成最佳实践的整套流水线。


帮助开发者更了解 Amazon EKS 整合 GitLab 的 QA 系列
Q：使用 Amazon EKS 之后，如何更有效率或优化资源去配置 Worker Node 的机器数量，以及如何有效空管开发维运的成本？


A：Kubernetes 除了本身有 HPA（Horizontal Pod Autoscaling）可根据使用程度自动调整资源流量，另外也能延伸使用 AWS Auto Scaling 方案，针对可扩展资源去设定自动扩展管理。另外在成本管控，虽然 Amazon EKS 会收取额外管理费用，但可透过 AWS 平台的 Calculato r计算每个 EKS 的价格，你会发现自动化部署及管理的费用，相对工程师人力的成本更加便宜。


Q：越来越多客户考虑把现有 Application 变成容器部署，大多是爲了加快部署的效率，那麽变成容器模式之后，对 CI/CD 的工作流程有什么影响吗？


A：运用容器技术最直接的效果，可以让应用程式的环境更一致化，例如 testing 环节、stage production，让容器避开一些差异问题。至于 CD 部分要 delivery 一些 usage 不太一样的时候，容器会帮忙做配置，所以 CI/CD 对容器的效益是相辅相成的。


Q： 客户在开发流程渐渐会把 Infrastructure 变成代码或文档，是不是可以把程式码跟现有的应用程式的 CI/CD 流水线整合在一起，达到一套完整的 CI/CD 部署流程？


A：观察目前市场作法，主要分成两个阶段去做整体部署。如果规模比较小的团队，会把 Infrastructure 代码跟 App 代码分开，在管理上会比较灵活；如果企业规模比较大，会有另外一个 Infrastructure 团队来控制部署事情，这种情况之下，APP 的项目会生成一个 APP package，主要做到 delivery 这个阶段爲止。而 Infrastructure 的项目会指定把需要版本的文档，部署到他们的 Kubernetes Cluster。

所谓现代化智慧 IT，所有工程师最希望的境界，莫过于只要轻松点几下设定，系统就会自动跑起来，管理者再也不用随时待命在机台旁边，从此工作悠哉又快乐！儘管这样情境还没到来，但随着敏捷式开发的流行，除了 DevOps 人员，有越来越多开发者将 CI/CD 概念融入到工作流程当中，例如从 build code、执行 unit test、到部署应用程式。


透过 AWS 增加云端技能 在组织发挥影响力


上述种种反复步骤自动化执行，也就能提昇服务品质、主动通知开发人员以减轻人力负担，让专案服务能持续运作。




其中，GitLab 是执行 CI/CD 常用的工具之一，也是开发者使用程式码储存库的地方。为了让 GitLab Runner 在云端快速实践 CI/CD，《AWS 开发者系列》透过影片分享，如何在 Amazon EKS（Elastic Kubernetes Services）上使用 GitLab 创建自动化部署。


以下节录工作坊影音内容，帮助开发者快速理解如何运用 Amazon EKS 的高可用性且安全的丛集，将修补、部署节点、更新等关键任务，全部做到自动化设定。同时影片也会示范 Amazon EKS 搭配 GitLab 如何展开自动部署，帮助工程团队实践 CI/CD 价值。


Amazon EKS 对容器管理轻松简单、维运省时省力
容器化服务越来越兴盛，当容器（Container）越来越多，在複杂的微服务（Microservice）系统环境之下，运维团队的管理成本可能相对会增加不少，为了有效调度容器部署， 导入Kubernetes 无疑是近年企业热门的话题之一。


建构 Kubernetes Cluster 流主要可区分两大块，一是安排容器调度的Control Plane、另一则是容器运行时需要用到的 Worker Node。




Control Plane 裡面涵盖有储存状态的 ETCD、CoController manager 、Scheduler 的调度管理、甚至是操作时进行互动的 APIServer，若是自己创建 的 Kubernetes Cluster ，需要自己安装这些元件，后续仍需要对 Control Plane 进行相关管理、维护、升级工作。为了减少上述 Components 的繁複维护，在透过 AWS EKS 代管的 Kubernete Control Plane 部可以获得以下三大好处。


Amazon EKS 一键式部署，展现三大优势
第一，Amazon EKS代管的 Control Plane实践了跨AZ的高可用部署，使用者不需要担心单一节点故障的风险。


第二，Amazon EKS 支持至少四个 Kubernetes版本，持续跟进每季 CNCF 的发佈，同时 EKS 也完全符合上游 CNCF 规范。


第三，部署 Amazon EKS 之后，可直接使用 AWS 平台上现成的服务工具，在安全性管理、网路设定方面，可以做到无缝整合。




最后 AWS 台湾解决方案架构师也提到，若想在容器环境进行 CI/CD 及应用程式的管理，可以进一步透过 IaC 整合部署 Amazon EKS 丛集，透过使用 Console、把 EKS 变成 Cloudformation 的模板、使用 AWS 所开发出来的 eksctl.io、或指令是採用 AWS CDK 可以让开发者用自身熟悉的语言，在 AWS 平台整合 CI/CD 工具进行维运及部署 EKS。


打造第一个在 AWS 上的应用程式


了解 Amazon EKS 整合 GitLab ，获得三面向价值
对开发者而言，想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上，可以看到那些实际的优势？


在 DevOps 开发者示范工作坊当中，GitLab 资深解决方案架构师指出，GitLab 使用到 Kubernetes 技术，主要有三种搭配方法，包含 GitLab Server、GitLab Runner、以及创建 Deployment Environment。


本次示范教学会主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式进行 Build、Test、Package Apps；以及在 Deployment Environment 运用 Kubernetes 技术，做到 Auto Deploy、Review App。


正因为 Amazon EKS 能够在 DevOps 过程提供所需要的弹性计算资源，帮助开发者在 GitLab 平台上面获得以下三个层次的优势：


在 GitLab 内建的部署工作流程当中，自动生成整套 CI/CD 最佳实践脚本。
Review App 过程，从 Merge Request 中可直接访问应用程式 /App 的 UI 介面，并且根据 Git branch 名称、专案名称，自动生成 Review App 的 URL，以及在 Merge 前的最后防线进行 Approval 检查。
加速 CI/CD 流水线，GitLab Runner 运行时候还可藉由 Amazon EKS Cluster 进行 Auto-scaled 的支援。
Amazon EKS 整合 GitLab ，需要两大流程
影片最后，GitLab 资深解决方案架构师示范如何把 Amazon EKS 整合至 GitLab 执行 Auto Deploy，主要可分为两大区块流程，第一部分聚焦在 Amazon EKS cluster 的设置，第二部分则执行 Auto Deploy 设置。


第一块可拆分为四个阶段，首先教学怎麽创建 EC2 节点的 EKS cluster，第二阶段示范把 EKS Cluster 连接到开发者的 GitLab Instance、Group 或 Project，下一步则使用 Cluster Management Project Template 创建一个 Cluster Management Project，以及最后一阶段透过 Cluster Management Project 自带的 Helm Chart，安装在 Cluster 所需要的内建 App。


第二块执行 Auto Deploy 设置，针对需要部署的 App 创建一个 GitLab Project，接着再把 gitlab-ci.yml 添加到 Project，并从 Web IDE 选择及导入 Auto Deploy 的 CI 模版，让 GitLab 自动生成最佳实践的整套流水线。


帮助开发者更了解 Amazon EKS 整合 GitLab 的 QA 系列
Q：使用 Amazon EKS 之后，如何更有效率或优化资源去配置 Worker Node 的机器数量，以及如何有效空管开发维运的成本？


A：Kubernetes 除了本身有 HPA（Horizontal Pod Autoscaling）可根据使用程度自动调整资源流量，另外也能延伸使用 AWS Auto Scaling 方案，针对可扩展资源去设定自动扩展管理。另外在成本管控，虽然 Amazon EKS 会收取额外管理费用，但可透过 AWS 平台的 Calculato r计算每个 EKS 的价格，你会发现自动化部署及管理的费用，相对工程师人力的成本更加便宜。


Q：越来越多客户考虑把现有 Application 变成容器部署，大多是爲了加快部署的效率，那麽变成容器模式之后，对 CI/CD 的工作流程有什么影响吗？


A：运用容器技术最直接的效果，可以让应用程式的环境更一致化，例如 testing 环节、stage production，让容器避开一些差异问题。至于 CD 部分要 delivery 一些 usage 不太一样的时候，容器会帮忙做配置，所以 CI/CD 对容器的效益是相辅相成的。


Q： 客户在开发流程渐渐会把 Infrastructure 变成代码或文档，是不是可以把程式码跟现有的应用程式的 CI/CD 流水线整合在一起，达到一套完整的 CI/CD 部署流程？


A：观察目前市场作法，主要分成两个阶段去做整体部署。如果规模比较小的团队，会把 Infrastructure 代码跟 App 代码分开，在管理上会比较灵活；如果企业规模比较大，会有另外一个 Infrastructure 团队来控制部署事情，这种情况之下，APP 的项目会生成一个 APP package，主要做到 delivery 这个阶段爲止。而 Infrastructure 的项目会指定把需要版本的文档，部署到他们的 Kubernetes Cluster。