Zenn
Open9

consul と仲良くなる会

satoyasatoya

AWS ECS で動かす方法

  • HCP 上の Consul サーバーから ECS 上で Consul Service Mesh を動かす
  • EC2 で動いてる Consul サーバーから ECS 上での Consul Service Mesh を動かす
  • Consul サーバーも ECS Fargate で動かして同上

Consul サーバーをどこで動かす？かによってそれ以降としては共通っぽい
3 つ目の方法のサンプルが
https://registry.terraform.io/modules/hashicorp/consul-ecs/aws/latest/examples/dev-server-fargate

satoyasatoya

サンプル動かしたりコード読んだり

  • modules
    • acl-controller
    • dev-server
      • consul server ( image: public.ecr.aws/hashicorp/consul:1.10.4 ) を ECS Fargate で動かしてる
      • [For Development/Testing Only]: This module deploys a Consul server onto your ECS Cluster for development/testing purposes. The server does not have persistent storage and so is not suitable for production deployments.
      • bind vomule にしてる。本番運用ならやっぱり EFS ... ??
    • mesh task
      • 各々の application ( consul client )
      • sample では client, server を動かしてる
      • lb -> client, client -> server
      • This module creates an ECS Task Definition that adds additional containers to your application task, so it can be part of the Consul service mesh.
        • task definition に実際以下を配布する
        • consul-ecs-mesh-init
        • consul-client
        • sidecar-proxy
        • ( + mesh task 対象 container )
satoyasatoya

service mesh 復習

Service meshは以下の図のように全てのサービスと一緒にSidecarとしてProxyをデプロイし，サービス間のコミュニケーションをすべてこのProxy経由で実行するようにすることでmeshを構成する．そしてこのProxyレイヤーでTraffic controllやLB，ネットワークのResiliency、Observability，Securityなどを担保する．

https://deeeet.com/writing/2018/05/22/service-mesh/

istio 用語

  • Data plane - 全てのサービスの ingress / egress を管理
    • service proxy - リクエストのRetryやTimeout，Circuit breaking，Service discovery，Security を行う proxy. envoy を利用してる.
    • sidecar container - 同じ Pod に属する必ずセットで扱われる container
  • Control plane - Data plane の brain
    • Pilot
    • Mixer

Data plane = Consul Client = Mesh task ??
Control plane = Consul Server (on HCP, EC2, Fargate ... etc )

satoyasatoya

consul sample に戻って fake-service を見る

golang server から /ui/ に来たときに静的ファイルを http.FileServer でハンドルしてる
https://github.com/nicholasjackson/fake-service/blob/main/main.go#L296

ui は react
https://github.com/nicholasjackson/fake-service/tree/main/ui

example の方で設定してた環境変数

  upstreams = [
    {
      destination_name = "${var.name}-example-server-app"
      local_bind_port  = 1234
    }
  ]
...
...
    environment = [
      {
        name  = "NAME"
        value = "${var.name}-example-client-app"
      },
      {
        name  = "UPSTREAM_URIS"
        value = "http://localhost:1234"
      }
...
...
  family            = "${var.name}-example-server-app"

client からの upstream としては server の fmily name を指定してて、containr の環境変数としては localhost になってるのがよくわからない

  UPSTREAM_URIS  default: no default
       Comma separated URIs of the upstream services to call
satoyasatoya

これか、
local_bind_port = 1234

Upstream services this service will call. In the form [{destination_name = $name, local_bind_port = $port}] where destination_name is the name of the upstream service and local_bind_port is the local port that this application should use when calling the upstream service.

まさに↓の定義そのまんまで localhost:1234 で server app につながるようになっていたっぽい。

  upstreams = [
    {
      destination_name = "${var.name}-example-server-app"
      local_bind_port  = 1234
    }
satoyasatoya

architecture 読む

https://www.consul.io/docs/architecture

よくまとまってる用語集。マイクロサービス周辺の用語がまとめられていてお得。諸々のドキュメントの前提になってるっぽいので先に読んでおいた方が無難そう。
https://www.consul.io/docs/install/glossary#auto-scaling-groups

  • consul は複数の datacenter （のセット）をサポートしてる
  • 各データセンターには client と server が混在している
    • 内サーバーは 3~5 台想定
  • datacenter の中の全ての agent は gossip protocol に参加してる
    • datacenter の中に gossip pool が存在する
      • service discovery にアドレスが必要ない
      • 障害検出の作業が分散される
      • リーダー選出などの重要なイベントのメッセンジャーとしても働く

    • server は単一の Raft peer set の一部