gcp | 伪架构师

关于 Anthos- Google 的混合多云平台

Tue, 16 Apr 2019 16:17:22 +0800

原文：Everything You Want To Know About Anthos - Google’s Hybrid And Multi-Cloud Platform

作者：Janakiram MSV

最近结束的 Cloud Next 会议上，Google 宣布企业级混合多云平台 Anthos 进入 GA 阶段。

虽说会上有超过一百个发布，Anthos 依旧醒目。它标志着 Google 官方开始涉足企业数据中心。这是主流公有云厂商第一次以官方身份踏入多云平台的市场。

从 Sundar Pichai 到 Thomas Kurian 再到 Urs Hölzle，Anthos 被描述为下一代技术。很明显，Google 的高层团队为该项目深感自豪。

Anthos 和其它公有云服务不同。它不仅是一个产品，而是一个覆盖应用程序现代化、云迁移、混合云和多云管理等主题的家族品牌。

虽然 Anthos 及其 GA 级别的成熟度被广泛报道，但是这一发布活动还是令人困惑的。文档非常稀少，相关服务并未完全集成到自助工作台之中。除了混合云的连接以及多云应用部署之外，Google 的这一新技术的更多细节并不为人所知。

基础构成

Anthos 的核心是目前最流行的开源项目：Kubernetes。GKE 是 Google 云提供的容器即服务技术，Anthos正是构建于 GKE 的坚实基础之上。当然还有一些其它的重要技术为 Kubernetes 提供了必要的补充。

镜头拉近，看看 Anthos 的核心组件：

GKE：Anthos 的命令和控制核心。用户通过 GKE 的控制平面来对分散在 Google 云、私有数据中心一级其它云平台上的基础设施进行管理。
GKE On-Prem：Google 推出了一个基于 Kubernetes 的和 GKE 一致的软件平台。用户能够在任何的兼容硬件上部署这一产品，而 Google 将会对其进行管理。从升级 Kubernetes 版本到应用最新补丁，Google 都视其为 GKE 的逻辑扩展。尤其需要注意的是 GKE On-Prem 运行在 VMWare vSphere 6.5 的虚拟化基础上，Hyper-V 和 KVM 等其它虚拟化技术的支持还在开发之中。
Istio：这一技术让跨平台的联邦网络管理成为可能。Anthos 需要为部署在不同数据中心、GCP 以及其它云上的多种应用程序的组件建立服务网格，Istio 自然是首选。它会和 VMWare NSX、Cisco ACI 以及 Google 自己的 Andromeda 等 SDN 进行无缝集成。已经在网络设施上（例如 F5）进行投资的客户，可以将 Istio 和负载均衡及防火墙集成起来。
Velostrata：Google 在 2018 年收购了这一云迁移技术，来增强 Kubernetes 的竞争力。Velostrata 的主要功能——在 GCE 实例中复制物理机/虚拟机，并把现有虚拟机转换为 Kubernetes 应用（Pod）。这是业界首个物理机到 Kubernetes 的迁移工具，由 Google 提供。这一技术以 Anthos Migrate 的面目出现，目前是 Beta 阶段。
Anthos 配置管理：Kubernetes 是一个可扩展的策略驱动的平台。Anthos 的客户必须面对运行在不同环境中的多个 Kubernetes，因此 Google 尝试利用 Anthos 来简化配置管理工作。从发布工件、配置项目、网络策略、密文和密码等类型的配置，Anthos 配置管理都能够进行管理并将配置应用到一或多个集群之中。
Stackdriver：Stackdriver 为 Anthos 基础设施和应用提供了可观察性的支持。客户能够使用这一组件跟踪运行在 Anthos集群状态，以及部署在各个托管集群上的应用的健康情况。该组件负责集中地提供监控、日志、跟踪以及观察的支持。
GCP Cloud Interconnect：在企业数据中心以及云基础设施之间的高速互联，是混合云平台的必要条件。Cloud Interconnect 能够在数据中心和云间交付高达 100Gbps 的高速网络。客户也可以使用 Equinix、NTT Communications、Softbanck 等电信厂商的网络将其数据中心延伸到 GCP。
GCP Marketplace：Google 为能够在 Kubernetes 上运行的（来自 ISV 和开源的）软件列表。用户能够在 Anthos 中一键部署 Cassandra 数据库或者 GitLab 等软件。最终 Google 可能还会为内部 IT 提供一个私有的 Catalog 服务。

应用程序：Greenfield vs Brownfield

Anthos 的核心场景就是应用的现代化进程。Google 所展望的未来世界中，所有企业都运行在 Kubernetes 上。为了达成这一目标，Google 在 Velostrata 这样的技术上进行投资，从而完成从虚拟机到容器的就地升级。

Google 为 VMware 的 vRealize 构建了一个插件，可以把现有虚拟机转换为 Kubernetes Pod。即使是 PostgreSQL 和 MySQL 这样的有状态应用，都能够转换为 StatefulSet 在 Kubernetes 中运行。

在从自有虚拟机向云端虚拟机的迁移问题上，Google 表现得轻描淡写。但是 Velostrata 的原始服务都是基于 VM 的。客户的业务线应用程序，例如 SAP、Oracle Finacials 以及 Peoplesoft 都可以持续的运行在自家数据中心的虚拟机中，或者也可以选择迁移到 GCE 的虚拟机上。Anthos 在技术上提供虚拟机和 Kubernetes 容器化应用之间的互操作性。

有了 Anthos，Google 想要拥有所有运行在 Kubernetes 之上现代微服务应用（Greenfield），同时也想将现有虚拟机（Brownfield）转换为容器。非 x86 架构中的存量应用会持续运行在物理或者虚拟机上。

广泛的行业合作

因为缺乏与业内其它厂商的合作和伙伴关系，Google 经常受到批评。为了对抗微软和 Amazon，Google 准备和行业中的其它老牌企业进行合作。毫无疑问，这一举措会帮助 Google 在企业市场获得一席之地。

为了让 Anthos 走向成功，Google 将不得不依靠现有的企业市场玩家进行推动。它要寻求的是和微软以及 Amazon 的合作伙伴，来一起推进混合云进程。

Cisco 将 HyperFlex、ACI、SD-WAN 以及 Stealthwatch Cloud 扩展到 Anthos 之上，为其提供 SDN 能力。VMware 正在为 Pivotal Kubernetes Service（PKS）加入 Anthos 支持，另外还有 VeloCloud 提供的 SD-WAN 能力；它还将它的流行 SDN 方案 NSX 集成到了 Istio 之中。

大量 ISV 正在启动对 Anthos 的支持。从 Citrix 到 NetApp 到 MongoDB，众多的平台供应商正在尝试将其软件集成到 Anthos 之中。

Google 的 Kubernetes 攻势

作为 Kubernetes 的创始人，毫无疑问的，Google 是很擅长管理容器的。在 Docker 开始展现出对开发者的吸引力之后，Google 意识到这是放养 Kubernetes 的绝佳机会。Google 也是业内第一个提供托管 Kubernetes 的公有云厂商。虽然有为数众多的竞争者，GKE 仍然是运行微服务的最佳平台。

基于对 Kubernetes 的深入理解，以及在这方面的持续投入，Google 希望在容器和微服务的新世界之中占据主导地位。它希望企业能够跳出虚拟机，在 Kubernetes 上运行他们的现代应用。

Anthos 是 Google 的重要一步。它正在冒险摆脱其对手用于吸引企业客户的混合云玩法。Anthos 对标的是微软的 Azure Stack 以及 AWS 提出的 VMware 结合 Outpost 的混合云方案。Google 和竞争对手的明显差别在于，它的方案根植于容器和 Kubernetes 技术。

Google 希望利用在 Kubernetes 和云原生领域的领先地位。它迅速地围绕 Kubernetes 构建了企业战略。Google 意图通过 Anthos 成为容器生态系统中的 VMware。VMware 在企业中推动其 hypervisor 以及软件定义的基础设施的手段，正是现在 Google 的行为方式。

但是微软同样在容器和 Kubernetes 方面下了重注。它通过将公有云中的旗舰级能力下放到私有云的方式，模糊了 Azure 和 Azure Stack 之间的界线。微软能够用 Azure Kubernetes 服务来复制 Anthos 的战术。Redmond 将如何使用 Azure Stack 玩转 Kubernetes，是个令人感兴趣的问题。

如果一切如 Google 所愿，Anthos 最终会成为运行企业负载的首选平台。

企业就绪

让来自 Cisco 和 VMware 的高管和 Thomas Kurian 一起登台，这是来自 Google 的声明：已经为企业市场做好准备。这一表现当然会增强企业客户在 Anthos 和 GCP 上进行投入的信心。

Kubernetes 被认为是一个高技术的、具有极客气息的平台，因此吸引了开发和运营人员。而有了 Anthos 的帮助，Google 将会改变客户对 Kubernetes 的刻板印象。它将 Kubernetes 变成一个可用的、可靠的企业级混合云平台。

Thomas Kurian 掌舵之后，Google 开始关注企业市场。如果它能够用好合作伙伴关系，并持续和关键的行业参与者进行合作，Google 和 Anthos 将会给企业基础设施市场带来巨大冲击。

云原生生态的巨大机会

Anthos 提振了对云原生生态系统的信心。前面提到过，Google 希望成为 Kubernetes 世界中的 VMware。但是和 VMware 登上企业宝座的时候相比，世界已经不同了。

最大的区别就是开源软件。Google 现在面临的环境中，软件已经不再是关键区别。

为了 Anthos 的成功，Google 必须依赖社区和生态系统。为云原生环境提供利基产品的创业公司（例如 Tigera、Portworx、Robin、Confluent、Cloudbees）将会得到更好的机会，Anthos 的推出，会让其受益匪浅。

从小型的本地供应商到埃森哲、高知特这样的全球 SI，供应商和集成商正在为 Anthos 做准备。Google 的混合云战略将转化为价值数百万没有的的服务机会。

随着 Google 向企业宣传和销售 Kubernetes 的举措，创业公司将借势将其触角伸向企业。

Google 在 Anthos 上的豪赌对行业大有裨益，开源社区和云原生生态系统将加速 Kubernetes 的采用过程。

Google Cloud Run 一瞥

Tue, 16 Apr 2019 03:38:07 +0800

原文：A First Look at Google Cloud Run

作者：Marko Anastasov

Google 在 Cloud Next’19 上发布了基于 Docker 容器的的 Serverless 新方案。目前可以肯定的是，这是 Serverless 的重要进步——在 Cloud Run 上进行部署比在 Kubernetes 上运行容器简单多了。而且和 Lambda 不同，这一方案没有语言绑定的问题。

什么是 Google Cloud Run

Google Cloud Run 是一个全托管平台，它以无状态、自动伸缩的 HTTP 服务的形式运行 Docker 容器镜像。

Cloud Run 和第一代 Serverless 平台（例如 AWS Lambda、Google Cloud functions 或 Azure Functions）不同，它允许你运行任意的应用，提供多个端点；而无需使用特定接口来运行小规模的函数。

Cloud Run 的基础来自于 Knative，因此这一方案有可能被移植到其它的托管 Kubernetes 平台。

我的项目能够在 Google Cloud Run 上运行么？

Google 发表了容器运行时契约，其中说明了对容器的要求：

容器是 64 位 Linux 平台；
在 8080 端口监听 HTTP 请求；
最多使用 2G 内存；
容器实例必须在收到请求之后的 4 分钟内启动 HTTP 服务器；
应用应该能够适应自动从 0 到多个运行实例的容器环境；
所有的运算都应该是无状态的，限制在一个请求之内。

只要你的项目能够符合上面的条件，不论使用什么语言开发，都能够在 Cloud Run 上面运行。

Cloud Run 目前还在 Beta 阶段，因此这些需求可能会发生变动。

上手流程

对于熟悉 Docker 或者 Heroku 传统 PaaS 解决方案的人来说，Cloud Run 应该很易上手。

应用打包成 Docker 之后，剩下的任务包括：

把镜像推送到 Google 镜像库。
运行 gcloud beta run deploy

只要几分钟，Cloud Run 就会使用一个可定制、可开放的域名启动新应用了。

示例：使用 Semaphore 进行持续部署

下面的例子中，我们使用 Semaphore 要为一个微服务配置 Serverless CI/CD Pipeline，其中包含如下环节：

运行自动测试；
构建 Docker 容器；
将容器镜像推入 Google 镜像库；
提供到 Cloud Run 预备环境的一键部署；
在对 Master 分支的构建成功之后；自动部署到 Cloud Run 生产环境。

可以在 Github 上找到相关的全部代码。

启用 Cloud Run

官方的快速启动指南提供了一个 Cloud Run 的上手教程。

第一步是：

在你的账号中启用 Cloud Run API；
安装 Google Cloud SDK；
使用 gcloud components install beta 安装 Beta 组件。

应用容器化

下面的 Dockerfile 将一个简单的 Sinatra 应用打包：

FROM ruby:2.5
RUN apt-get update -qq &amp;&amp; apt-get install -y build-essential
ENV APP_HOME /app
RUN mkdir $APP_HOME
WORKDIR $APP_HOME
ADD Gemfile* $APP_HOME/
RUN bundle install --without development test
ADD . $APP_HOME
EXPOSE 8080
CMD ["bundle", "exec", "rackup", "--host", "0.0.0.0", "-p", "8080"]

注意如果使用你自己的 Dockerfile，必须开放 8080 端口，否则可能会看到如下错误：

登录 Google Cloud 和 GCR

要在 CI/CD Pipeline 中自动地将镜像推送到 GCR，需要在 Semaphore 中登录到 Google Cloud。为了安全起见，需要在 Semaphore 中根据 Google Cloud Service account 的认证密钥创建一个 Secret。

获取认证密钥之后，在 Semaphore 中用 Secret 的形式上传到 Semaphore。假设文件名是 .secrets.gcp.json：

sem create secret google-cloud-stg --file ~/Downloads/account-name-27f3a5bcea2d.json:.secrets.gcp.json

定义分发管线

接下来就可以编写一个 Pipeline 来构建、标记并推送镜像到 GCR 了：

# .semaphore/docker-build.yml
# This pipeline runs after semaphore.yml
version: v1.0
name: Docker build
agent:
  machine:
    # Use a machine type with more RAM and CPU power for faster container
    # builds:
    type: e1-standard-4
    os_image: ubuntu1804
blocks:
  - name: Build
    task:
      # Mount a secret which defines an authentication key file.
      # For info on creating secrets, see:
      # - https://docs.semaphoreci.com/article/66-environment-variables-and-secrets
      # - https://docs.semaphoreci.com/article/72-google-container-registry-gcr
      secrets:
        - name: google-cloud-stg
      jobs:
      - name: Docker build
        commands:
          # Authenticate using the file injected from the secret
          - gcloud auth activate-service-account --key-file=.secrets.gcp.json
          # Configure access to container registry, silence confirmation prompts with -q
          - gcloud auth configure-docker -q

          - checkout

          # Tag your images with gcr.io/ACCOUNT_PROJECT_NAME/SERVICE_NAME pattern
          # Use Git SHA to produce unique artifacts
          - docker build -t "gcr.io/semaphore2-stg/semaphore-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7}" .
          - docker push "gcr.io/semaphore2-stg/semaphore-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7}"

promotions:
  # Deployment to staging can be trigger manually:
  - name: Deploy to staging
    pipeline_file: deploy-staging.yml

  # Automatically deploy to production on successful builds on master branch:
  - name: Deploy to production
    pipeline_file: deploy-production.yml
    auto_promote_on:
      - result: passed
        branch:
          - master

在 deploy-staging.yml 和 deploy-production.yml 中包含了同样的步骤，区别只是服务的名称。

# .semaphore/deploy-production.yml
# This pipeline runs after docker-build.yml
version: v1.0
name: Deploy to production
agent:
  machine:
    type: e1-standard-2
    os_image: ubuntu1804
blocks:
  - name: Deploy to production
    task:
      secrets:
        - name: google-cloud-stg
      jobs:
      - name: run deploy
        commands:
          - gcloud auth activate-service-account --key-file=.secrets.gcp.json
          - gcloud auth configure-docker -q
          
          # Deploy to Cloud Run, using flags to avoid interactive prompt
          # See https://cloud.google.com/sdk/gcloud/reference/beta/run/deploy
          - gcloud beta run deploy markoci-demo-cloud-run --project semaphore2-stg --image gcr.io/semaphore2-stg/markoci-demo-cloud-run:${SEMAPHORE_GIT_SHA:0:7} --region us-central1

上线运行

在本地终端或者 Semaphore 作业的日志中，最后一行会包含一个应用运行的网址：

https://semaphore-demo-cloud-run-ud2bmvsmda-uc.a.run.app.

用浏览器打开这个网址会看到：

这是因为还没有完成最后一步：在 Google Cloud Run 控制台中开放服务

完成之后的浏览页面：

整装待发

希望本文能够引起你使用 CI/CD Pipeline 在 Google Cloud Run 上构建和发布应用的兴趣。