topgate镜像_借助 GitHub Actions 将容器应用程序持续交付到 AWS Fargate

11 月 14 日，在 GitHub Universe 2019 大会的第二天主题演讲中，Amazon Web Services 宣布我们已将四个新的 适用于 Amazon ECS 和 ECR 的 GitHub Actions 开源化。 借助这些 GitHub Actions，开发人员和开发运营工程师可以在 GitHub 上的代码存储库中轻松设置持续交付管道，从而将容器工作负载部署到 Amazon Elastic Container Service (Amazon ECS) 和 AWS Fargate.

GitHub 与 Amazon Web Services 合作开发了最初的四个开源 GitHub Actions 以及一个入门工作流，其目的是为了让用户可以简单、安全、快速地部署来自 GitHub 存储库的容器化应用程序。团队、项目和组织不同，其 CI/CD 管道和发布流程也将各异。我们希望 GitHub Marketplace 中的这些开源 Actions 和入门工作流模板，能够成为一个起点，为软件工程师团队提供启发，帮助他们构建自己的组件，并根据他们的容器化应用程序自定义他们的 CI/CD 工作流。

随着客户提出更多的反馈、问题和 pull 请求，我们将继续改进这些开源组件，以更好地满足客户的需求。

在下文中，我们将讨论为何以及如何可以使用容器、ECR、ECS 和 GitHub Actions 来构建 CI/CD 管道，从而部署容器化的持续软件开发工作负载，帮助提高软件开发团队的效率。

为何要使用容器？

作为软件开发者，我们都希望使用尽可能与目标生产系统类似的开发和测试环境。 如果开发环境不能准确反映目标生产环境的配置和规模，在开发人员的笔记本电脑上测试代码时将很难预见按生产规模运行时将会出现的错误，这可能会拖累我们的工作。

Java 的著名设计目标是“一次编写，到处运行”，其实是开发一个统一的代码库，可以不加更改地在从智能手表到大型机在内的任何设备上运行，而非在开发人员的电脑上开发和测试将会在任何目标基础设施中运行的应用程序。它不是为了便携而便携，而是追求规模的便携性：如果我在较小规模的系统中开发和测试应用程序，当我根据真实生产需求扩展和缩减时，它不应出现崩溃。

虚拟机、JVM、SaaS 和容器等创新(在一定程度上)都是为了解决这种规模的便携性挑战而诞生。由于 AWS 等云平台为客户提供了极高的规模弹性，确保规模的便携性对于开发人员而言变得更加重要。

容器是将业务应用程序和相关的库都囊括在一个容器镜像中，这个容器镜像可以根据生产的需要复制到任意数量的实例中。对于应用程序代码而言，每个实例都与在开发人员工作站上开发和测试代码时使用的环境一模一样。规模的便携性降低了代