Belajar Elasticsearch - CI/CD Integration & Infrastructure as Code

#Pendahuluan

Kalian pernah "melakukan setup manual" yang berulang-ulang? Konfigurasi Elasticsearch yang dibuat dengan klik dan ketik di console tidak terdokumentasi, tidak bisa di-review, dan tidak bisa di-rollback. Di organisasi yang sehat, semua konfigurasi diperlakukan seperti kode: versioned, di-review, diuji, dan di-deploy lewat pipeline. Episode 28 membahas cara ini — index management as code, CI/CD untuk menguji dan men-deploy perubahan Elasticsearch, serta infrastructure as code dengan Terraform, Ansible, dan GitOps, ditutup dengan deteksi configuration drift.

#Index Management as Code

Semua yang kita bahas sebagai "request manual" di episode sebelumnya bisa disimpan sebagai file dalam repository:

• Index templates (episode 4, 11) — definisi mapping dan settings.
• ILM policies (episode 10) — siklus hidup index.
• Ingest pipelines (episode 12) — preprocessing data.
• Roles dan role mapping (episode 15) — keamanan.

File-file ini direview lewat pull request, dites di cluster staging, lalu diterapkan ke production. Contoh template sebagai file YAML:

---
index_patterns: ["logs-*"]
data_stream: {}
template:
  settings: { number_of_shards: 2, number_of_replicas: 1, index.lifecycle.name: logs-policy }
  mappings:
    properties:
      "@timestamp": { type: date }
      level: { type: keyword }
      message: { type: text }

#CI/CD Pipeline untuk Elasticsearch

#Automated Testing Query dan Schema

CI bisa menjalankan serangkaian test terhadap instance Elasticsearch sementara (misalnya memakai docker compose cluster lab, episode 27) — pastikan cluster sehat dulu dengan curl -s localhost:9200/_cluster/health:

steps:
  - name: Setup cluster test
    run: docker compose up -d
  - name: Terapkan template
    run: curl -sS -X PUT localhost:9200/_index_template/logs-template --data-binary @index-template-log.yaml
  - name: Jalankan integration test
    run: python3 -m pytest tests/test_search.py

Test yang masuk akal:

• Schema validation — pastikan mapping yang di-deploy sesuai yang diharapkan (field, tipe, kebijakan dynamic).
• Query tests — jalankan query DSL yang dipakai aplikasi; pastikan tidak error dan hasilnya masuk akal.
• Performance regression — bandingkan waktu eksekusi query sebelum/sesudah perubahan; deteksi query yang tiba-tiba lambat.

#Performance Regression Testing

Ukur baseline dengan dataset tetap, lalu bandingkan: jika query yang tadinya 50 ms menjadi 500 ms setelah perubahan mapping, pipeline harus gagal sebelum perubahan sampai ke production. Ini memerlukan cluster benchmark dengan data yang representatif — bukan hanya "bisa jalan".

#Strategi Deployment

Deployment perubahan Elasticsearch ke production mengikuti urutan aman:

1. Deploy ke staging, jalankan test dan benchmark.
2. Deploy template/ILM yang non-breaking lebih dulu.
3. Untuk perubahan breaking (mapping): buat index baru + reindex + pindah alias (episode 13).
4. Monitor metrik (episode 21) sebelum dan sesudah.
5. Rollback plan selalu siap — alias bisa dikembalikan seketika.

#Infrastructure as Code

#Terraform dengan Provider Elasticsearch

Terraform mendeklarasikan infrastruktur — termasuk Elasticsearch — sebagai code. Provider komunitas elastic/elasticsearch mendukung resource index, template, ILM, dan user/role:

terraform {
  required_providers {
    elasticsearch = { source = "elastic/elasticsearch", version = "~> 8.0" }
  }
}
 
provider "elasticsearch" {
  url         = "https://node1:9200"
  username    = "terraform"
  password    = var.es_password
  insecure    = false
}
 
resource "elasticsearch_index_template" "logs" {
  name = "logs-template"
  body = jsonencode({
    index_patterns = ["logs-*"]
    template = { settings = { number_of_shards = 2, number_of_replicas = 1 } }
  })
}

Dengan terraform plan, kalian melihat exactly apa yang akan berubah sebelum terraform apply — dan Terraform state mendeteksi kalau ada yang berbeda dari yang dideklarasikan (drift).

#Ansible Playbooks

Ansible bagus untuk konfigurasi mesin dan bootstrap — misalnya menyetel vm.max_map_count, memasang plugin, dan menerapkan elasticsearch.yml:

- name: Siapkan node Elasticsearch
  hosts: es_nodes
  become: yes
  tasks:
    - name: Set vm.max_map_count
      sysctl: { name: vm.max_map_count, value: "262144" }
    - name: Pasang repository Elastic
      yum_repository: { name: elastic, state: present }
    - name: Install elasticsearch
      dnf: { name: elasticsearch, state: present }
    - name: Terapkan elasticsearch.yml
      template: { src: elasticsearch.yml.j2, dest: /etc/elasticsearch/elasticsearch.yml }
      notify: restart elasticsearch

Pola templating elasticsearch.yml.j2 membuat satu playbook melayani banyak environment dengan nilai yang berbeda-beda.

#GitOps Workflows

GitOps memperlakukan git sebagai satu-satunya sumber kebenaran: perubahan dilakukan via pull request, dan tool (Argo CD, Flux, atau pipeline custom) menyinkronkan state git ke lingkungan hidup. Keuntungannya: semua perubahan tercatat di git, ada review, ada audit trail, dan drift langsung terdeteksi karena sinkronisasi otomatis.

Untuk Elasticsearch, GitOps berarti: repository berisi template, ILM, pipeline, role — dan pipeline menerapkannya ke cluster saat ada commit di main branch. Perubahan manual di cluster yang tidak ada di git akan di-revert oleh sinkronisasi berikutnya.

#Deteksi Configuration Drift

Configuration drift terjadi ketika cluster melenceng dari yang dideklarasikan — misalnya seseorang mengubah settings via console manual. Cara mendeteksinya:

GET /_index_template/logs-template?filter_path=*.index_patterns,*.template

Pola yang umum: pipeline rutin mengambil state cluster (template, ILM, roles) dan membandingkannya dengan file di git — jika berbeda, pipeline gagal atau mengembalikannya. Terraform (terraform plan) dan GitOps sync keduanya menyediakan mekanisme ini.

#Kesalahan Umum

1. Konfigurasi hanya di console. Tidak terdokumentasi dan tidak bisa di-review — perlakukan sebagai code.

2. Deploy breaking change langsung. Mapping baru harus lewat reindex + alias, bukan timpa langsung.

3. Tanpa performance regression test. Query yang melambat lolos ke production tanpa disadari.

4. Tanpa drift detection. Cluster melenceng dari git tanpa ada yang tahu.

5. Secret di repository. Password dan API keys di git = kebocoran — gunakan secret manager dan variable pipeline.

#Penutup

Di episode 28 kalian menguasai CI/CD dan infrastructure as code: index templates, ILM policies, dan ingest pipelines sebagai file yang di-version; automated testing (schema validation, query tests, performance regression) di pipeline; strategi deployment bertahap; serta Terraform, Ansible, GitOps, dan deteksi configuration drift.

Inti yang harus dibawa pulang:

• Semua konfigurasi adalah code — versioned, di-review, diuji.
• Schema change yang breaking butuh migration plan (reindex + alias).
• CI menguji query, schema, dan performa sebelum deployment.
• Terraform/GitOps mendeklarasikan state yang diinginkan dan mendeteksi drift.
• Jangan pernah menaruh secret di repository.

Konfigurasi yang terdokumentasi dan teruji membuat sistem lebih tangguh. Tapi ketangguhan sejati butuh satu lapisan lagi. Di episode 29 kita bahas high availability dan disaster recovery: desain multi-node dengan master quorum anti split-brain, redundansi data node, zone-aware replica allocation; strategi multi-region, perencanaan RPO dan RTO, prosedur failover, dan testing DR berkala. Sampai jumpa!