fbpx

Elastic を運用する ～CI/CD の価値～ #Elastic #logstash #cicd #運用

Elastic

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

こんにちは、DiCoT(Digital Co-creation Team) 渡辺です。

弊社の社内システムでもElasticを活用することになり、データ分析基盤の本質について考える機会が増えました。
今回はElastic のコンポーネントの logstash を例にCI/CD について考えたいと思います。

お伝えしたいこと

昨今、何かの目的（ビジネスドメイン）を達成するためにはアプリケーションが必需品であると私は思います。
そして、当然ながらアプリケーションの開発、もしくはElastic 等のフレームワークの適用していきます。　　
忘れてはいけないのは、多くの場合チーム（2人以上）で開発とデプロイメントを進めいくと思います。

ビジネスドメインの発展のための議論や開発に意識が向いてしまうと、　　
開発及びデプロイそのもののプロセスがおろそかになってしまわないでしょうか？
結果的に、時が進むにつれチームが形を変えていく中で、プロセスの属人化を生み、ナレッジトランスファなどに時間を要するようになり、
更にはコミュニケーション不具合等も発生すると考えます 。e.g あの人に任せればいい、自分は知らなかった等

開発～デプロイを自動化もしくは、人手の介入が入ったとしても、誰でも一様に進められる仕組みを整えておくことで、
大切なことに時間を使えるようになるのではないでしょうか？

以降 TL; TR です。

logstashとは?

OSSのETLツールになります。Elastic社が中心となって開発が進んでいます。
https://www.elastic.co/logstash

github はこちら
https://github.com/elastic/logstash

logstash の使用用途

弊社では、logstash はelastic cloud にデータを送る役割を担っています。
Zoom から収集したデータをLambdaを得て、
Kafka にバッファしたデータをlogstash経由してElastic Cloud にデータを送ります。

開発のレポジトリの紹介

logstash の 開発レポジトリとして、gitlab service を使用しています。レポジトリの構造はこのような形です。　　
試行錯誤しながら進めています。

.
├── config
│   ├── log4j2.properties
│   ├── logstash-full.yml
│   ├── logstash-oss.yml
│   ├── logstash.yml
│   └── pipelines.yml
├── deployments
│   ├── services
│   │   └── logstash.json
│   └── tasks
│       └── logstash.json
├── Dockerfile
├── Makefile
├── pipeline
│   ├── default.conf
│   ├── kafka-to-es-cloud-meetings.conf
│   ├── kafka-to-es-cloud-participants.conf
│   └── output-es.conf
├── README.md
└── test_params.sh

5 directories, 15 files

CI Pipeline の活用

開発に関わっている人数が少ないこともあり(大体1人から2人) 、
Continous Integration/Continous Deployment はとてもシンプルにしています。
Unit test については、local で実行してから、Push をしています。
CI/CD の概念は Gitlab社の考え を私は参考にしています。

CIのポイントは、２点です。

  • 必ずMerge Request レビューを行ってから、デプロイを行っています。
  • ECR へのデプロイに必要な認証情報はSTS から取得します。 このため、gitlab runner を AWS上に構築して、CI Job を実行します。

.gitlab-ci.yaml の内容

image: docker:19.03.12

variables:
  # When using dind service, we need to instruct docker to talk with
  # the daemon started inside of the service. The daemon is available
  # with a network connection instead of the default
  # /var/run/docker.sock socket. Docker 19.03 does this automatically
  # by setting the DOCKER_HOST in
  # https://github.com/docker-library/docker/blob/d45051476babc297257df490d22cbd806f1b11e4/19.03/docker-entrypoint.sh#L23-L29
  #
  # The 'docker' hostname is the alias of the service container as described at
  # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services.
  #
  # Specify to Docker where to create the certificates, Docker will
  # create them automatically on boot, and will create
  # `/certs/client` that will be shared between the service and job
  # container, thanks to volume mount from config.toml
  DOCKER_TLS_CERTDIR: "/certs"
  AWS_DEFAULT_REGION: ap-northeast-1
  LOGSTASH_VERSION: 7.10.1
  AWS_ECR_REPOS: activityanywhere/${CI_PROJECT_NAME}

# Pre scripts before ALL jobs
before_script:
  - apk add -q aws-cli jq make
  - export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
  - export AWS_ECR_URL=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com

services:
  - docker:19.03.12-dind

stages:
- build
- deploy

build:
  stage: build
  script:
    - make build

  # Deploy only pushes to master
  only:
    - master
deploy:
  stage: deploy
  script:
    - make scale ASG_DESIRED_CAPACITY=0
    - >
      length=1 ;
      while [ $length -gt 0 ]; do
        length=`aws ecs list-tasks --cluster logstash | jq '.taskArns|length'` ;
        echo "Number of tasks runniing are $length" ;
        sleep 10 ;
      done
    - make deploy
    - make scale ASG_DESIRED_CAPACITY=1

  # Deploy only pushes to master
  only:
    - master

Pipeline が正常に終了すればデプロイ完了です!

最後に

logstash の CI/CD を準備しておくことで、以下の２点に注力することができています。
みなさんも一度開発プロセスを見直す機会を設けてみてはいかがでしょうか？

  • Pipeline を書く
  • MR で妥当性を議論する

以上です。

新規CTA