Blog | ShaR07ech

Google Compute Engine作為容器服務：部署Elasticsearch的新方法 (下)

2024年4月21日 · 閱讀時間約 8 分鐘

Software Engineer @ Ranking

前言

在先前的文章中，我們已經詳細介紹了如何在Google Compute Engine（GCE）上使用Container-Optimized OS和Terraform部署Elasticsearch 我們成功配置了虛擬機和相關資源，並探討了基本的設置過程然而，實際運營中經常會遇到一些技術挑戰，尤其是與外部硬碟掛載和權限管理相關的問題

在這篇文章中，我們將深入探討在使用Container-Optimized OS進行Elasticsearch部署時遇到的一個具體問題：磁碟權限被不當覆蓋

遇到的問題與初步解決嘗試

在將terraform 的設定 apply 到雲端環境後，Elasticsearch在啟動階段的最後會出現無法寫入數據的錯誤訊息導致 container 無法正確啟動
- 既然 disk 是額外掛載的方式掛到機器上，因此高機率可以從 /mnt 找到硬碟來排查錯誤
- 查看後知道 Container-Optmized OS 在指定外接硬碟作為 volume 的時候會將硬碟 mount 至 /mnt/disks/gce-containers-mounts/gce-persistent-disks/${disk_name}
空白磁碟被掛載到VM上時是root權限
- Elasticsearch的image已經寫死用戶是elasticsearch（UID為1000）
- 在Container-Optimized OS中，UID 1000已被其他用戶占用，且磁碟的預設權限為755，這讓Elasticsearch無法正常寫入數據
在思考解決辦法的途中，找到了GCE提供了撰寫啟動腳本的辦法
- 首先嘗試使用GCE的startup script來進行chown，但發現這個操作會在Elasticsearch容器啟動過程中被覆蓋。於是我採用了chmod a+w來嘗試賦予更廣泛的寫入權限，但這同樣被後續操作覆蓋
- 由於權限會被固定在 owner 為 root 且權限為 755 的情形下，無法透過將 UID 1000 的使用者加入 group 來解決

深入系統日誌與源碼分析

要解決Elasticsearch的部署問題，一個關鍵步驟是理解Volume掛載過程及其權限如何被設置
- 因此需要深入系統的日誌和相關服務的 source code，才能確認何處出了問題以及如何修復

日誌分析：確認Startup Script的執行者

透過journalctl檢視系統日誌
- 發現日誌中有名為 cloud-init 的 service unit，從名稱上來看就跟雲端系統啟動有關
- 推測startup script應該是由cloud-init這個service執行的
- 為進一步驗證這一點，我執行了以下命令以列出所有服務
  - sudo systemctl list-units --type="service"

cloud-config.service     loaded active exited  Apply the settings specified in cloud-config
cloud-final.service      loaded active exited  Execute cloud user/final scripts
cloud-init-local.service loaded active exited  Initial cloud-init job (pre-networking)
cloud-init.service       loaded active exited  Initial cloud-init job (metadata service crawler)
containerd.service       loaded active running containerd container runtime
dbus.service             loaded active running D-Bus System Message Bus

找到了cloud-final.service，其狀態顯示為loaded active exited，並且描述為Execute cloud user/final scripts 這確認了我的猜測：startup script是由此service負責執行的

從日誌追蹤到Konlet的行動

接著，我仔細查看了cloud-final執行完成後的日誌記錄：

Apr 21 09:19:44 shareclass-tw-elasticsearch-dev systemd[1]: Finished cloud-config.service.
Apr 21 09:19:44 shareclass-tw-elasticsearch-dev systemd[1]: Starting cloud-final.service...
Apr 21 09:19:45 shareclass-tw-elasticsearch-dev konlet-startup[694]: d2519f41f710: Pull complete
Apr 21 09:19:45 shareclass-tw-elasticsearch-dev cloud-init[742]: Cloud-init v. 23.2.1 running 'modules:final' at Sun, 21 Apr 2024 09:19:45 +0000. Up 14.74 seconds.
Apr 21 09:19:45 shareclass-tw-elasticsearch-dev cloud-init[742]: Cloud-init v. 23.2.1 finished at Sun, 21 Apr 2024 09:19:45 +0000. Datasource DataSourceGCE.  Up 15.05 seconds
# Skip...
Apr 21 09:20:23 shareclass-tw-elasticsearch-dev konlet-startup[694]: 2024/04/21 09:20:17 Creating directory /mnt/disks/gce-containers-mounts/gce-persistent-disks/volume-shareclass-tw-elasticsearc>
Apr 21 09:20:23 shareclass-tw-elasticsearch-dev konlet-startup[694]: 2024/04/21 09:20:17 Attempting to mount device /dev/disk/by-id/google-volume-shareclass-tw-elasticsearch-dev at /mnt/disks/gce>
Apr 21 09:20:23 shareclass-tw-elasticsearch-dev konlet-startup[694]: 2024/04/21 09:20:17 Created a container with name 'klt-shareclass-tw-elasticsearch-dev-bqub' and ID: c03e7f32d59e88148f0359580>
Apr 21 09:20:23 shareclass-tw-elasticsearch-dev konlet-startup[694]: 2024/04/21 09:20:17 Starting a container with ID: c03e7f32d59e88148f035958082beb25946b7c4d9a9c2c36cbdf9ff72f300902
Apr 21 09:20:23 shareclass-tw-elasticsearch-dev konlet-startup[694]: 2024/04/21 09:20:17 Saving welcome script to profile.d

日誌中的Creating directory /mnt/disks/gce-containers-mounts/gce-persistent-disks/volume-shareclass-tw-elasticsearch可以看到，konlet-startup是處理掛載邏輯的主要元件
透過 sudo systemctl status konlet-startup.service，追查到 service 文件位置

○ konlet-startup.service - Containers on GCE Setup
     Loaded: loaded (/lib/systemd/system/konlet-startup.service; disabled; preset: disabled)
     Active: inactive (dead) since Sun 2024-04-21 09:20:17 UTC; 2 days ago
   Duration: 37.532s
    Process: 674 ExecStart=/usr/share/gce-containers/konlet-startup (code=exited, status=0/SUCCESS)
   Main PID: 674 (code=exited, status=0/SUCCESS)
        CPU: 151ms

由 /usr/share/gce-containers/konlet-startup
- 這個service會啟動 gcr.io/gce-containers/konlet 的 container
- 啟動參數 -v=/var/run/docker.sock:/var/run/docker.sock 代表這個 service 需要在 docker 環境內取得 docker 的控制權，推測這個 service 會負責啟動 container 的所有相關事宜

查看 source code：確定掛載和權限設置

在konlet的GitHub中，我找到了以下重要的代碼片段，這幫助我了解到Volume掛載點的創建和權限設置是如何進行的

func (env Env) createNewMountPath(volumeFamily string, volumeName string) (string, error) {
    path := fmt.Sprintf("%s/%ss/%s", *mountedVolumesPathPrefixFlag, volumeFamily, volumeName)
    log.Printf("Creating directory %s as a mount point for volume %s.", path, volumeName)
    if err := env.OsCommandRunner.MkdirAll(path, 0755); err != nil {
        return "", fmt.Errorf("Failed to create directory %s: %s", path, err)
    } else {
        return path, nil
    }
}

這段代碼揭示了Volume掛載點是如何被創建的
並且確認了每次掛載時都會設置0755的權限，這是我之前設置權限被覆蓋的原因

最終解決方案

為確保權限設置不被覆蓋，我設計了一個新的service

在startup script中實作
在 cloud-final 階段建立一個 service 的必要檔案，並啟動
這個service會等待 volume 成功掛載後，立即調整必要的權限

信息

由於 Container-Optimized OS，會將 /usr/local 設為 read-only，因此使用 /etc作為路徑

#!/bin/bash
# 創建執行腳本
mkdir -p /etc/bin
echo "#!/bin/bash

while ! findmnt -M \"$MOUNT_PATH\" >/dev/null; do
  echo \$(date) - Waiting for $MOUNT_PATH to be mounted...
  sleep 2
done

echo \$(date) - Mount detected, changing permissions...
chmod a+w \"$MOUNT_PATH\"
echo \$(date) - Permissions changed.

echo \$(date) - Script completed.
exit 0
" > /etc/bin/startup_script.sh
chmod +x /etc/bin/startup_script.sh

# 創建systemd service文件
echo "[Unit]
Description=Wait for disk mount and adjust permissions
After=network-online.target

[Service]
Type=simple
ExecStart=/etc/bin/startup_script.sh
Restart=on-failure
RestartSec=30
StandardOutput=journal+console

[Install]
WantedBy=multi-user.target
" > /etc/systemd/system/wait-and-chmod.service

# 啟動並啟用service
systemctl enable wait-and-chmod.service
systemctl start wait-and-chmod.service

這樣，當磁碟被掛載且Docker容器準備就緒時，權限會被正確設定，允許Elasticsearch順利啟動並運行

結語

透過這次經驗，不僅解決了具體的技術問題，也對GCE的運作機制有了更深的理解希望這篇分享能有所幫助，尤其是在處理雲端服務時遇到類似挑戰的情況

Google Compute Engine作為容器服務：部署Elasticsearch的新方法 (上)

2024年4月21日 · 閱讀時間約 5 分鐘

Justin Lin

Software Engineer @ Ranking

當需要在雲端快速部署可擴展的應用時，Google Compute Engine（GCE）配合Container-Optimized OS提供了一個高效的選擇下面將利用Terraform來部署一個Elasticsearch容器實例，並結合外接空白硬碟以優化數據遷移和存儲

配置Terraform

定義資源：靜態內部IP

首先，定義一個內部IP地址，這個地址將被用作我們虛擬機的網絡接口 (由於這邊使用情境為純內部 service，因此不設定外部IP)

resource "google_compute_address" "internal_ip" {
  name         = var.service_name
  address_type = "INTERNAL"
  purpose      = "GCE_ENDPOINT"
  project      = var.project_id
  region       = var.project_region
}

設置虛擬機實例

接下來，設定GCE虛擬機實例使用Container-Optimized OS作為啟動盤的映像，並將Docker容器的規格通過metadata傳遞給GCE，這裡使用的是類似於Kubernetes的配置方式也可以利用GCE的 UI 介面設定好之後畫面上會有等效的程式碼可以照搬

resource "google_compute_instance" "instance" {
  boot_disk {
    initialize_params {
	    /* 省略了部分初始化和配置代碼...*/
		image = "projects/cos-cloud/global/images/cos-stable-109-17800-66-78"
    }
  }
	/* 省略了部分初始化和配置代碼...*/

  metadata = merge(
    {
      gce-container-declaration = var.gce_container_declaration
    },
    var.startup_script != null ? {
      startup-script = var.startup_script
    } : {}
  )

  network_interface {
    network_ip  = google_compute_address.internal_ip.address
    subnetwork  = "projects/shareclass-tw/regions/asia-east1/subnetworks/default"
  }

  dynamic "attached_disk" {
    for_each = var.attached_disk
    content {
      source      = attached_disk.value.source
      device_name = attached_disk.value.device_name
      mode        = attached_disk.value.mode
    }
  }
  depends_on = [google_compute_address.internal_ip]
}

在這個google_compute_instance資源定義中，我們設置了一台虛擬機來運行Elasticsearch容器。關鍵配置包括

指定操作系統映像為Container-Optimized OS的最新穩定版本
通過metadata傳遞Docker容器的配置（這里用了gce-container-declaration）這種方法類似於Kubernetes的pod定義，允許細粒度地控制容器的運行環境

配置外接硬碟

resource "google_compute_disk" "elasticsearch" {
  name = "volume-${var.service_name}"
  type = "pd-balanced"
  zone = var.project_zone
  size = var.disk_size
}

這部分代碼創建了一個外接硬碟，將用於Elasticsearch數據的存儲

定義容器規格

data "template_file" "gce_container_declaration" {
  template = file("${path.module}/gce_container_declaration.tpl")

  vars = {
    service_name = local.service_name
    image        = local.image
    disk_name    = google_compute_disk.elasticsearch.name
  }
}

template_file數據源用於生成容器的配置
- 讀取一個模板文件，並替換模板中的變量以生成最終的容器配置
- 這個過程讓配置更加模塊化和可重用，便於管理大型部署
若使用GCE的等效程式碼，只能看到 spec:\n containers:\n - name: instance.... 這種單行設定，不利於以後維護

定義模組

將所有配置集成到一個模組中，方便管理和重用

module "elastic_search" {
  source         = "../compute_container"
  project_id     = var.project_id
  project_region = var.project_region
  project_zone   = var.project_zone
  service_name   = var.service_name
  environment    = var.environment
  machine_type   = var.machine_type
  attached_disk  = [
    {
      device_name = google_compute_disk.elasticsearch.name
      mode        = "READ_WRITE"
      source      = google_compute_disk.elasticsearch.self_link
    }
  ]
  gce_container_declaration = data.template_file.gce_container_declaration.rendered

  depends_on = [
    google_compute_disk.elasticsearch,
    data.template_file.gce_container_declaration
  ]
}

最後，所有這些資源和配置被封裝進一個模組。這使得整個Elasticsearch部署可以作為一個單元被重用和管理，無論是在當前項目還是跨項目都能輕鬆配置和更新

結語

通過上述步驟，我們已經成功配置了一個在Google Compute Engine上運行Elasticsearch的環境這個環境利用了Container-Optimized OS的穩定性和安全性，以及Terraform的自動化部署能力通過細致的配置和模組化的設計，我們確保了系統的可擴展性和易管理性

後半段將更深入地探討在此架構中運行時遇到的特定技術問題，特別是之前提及的磁碟權限問題，這是一個在使用外接硬碟和Container-Optimized OS時常見的挑戰將詳細討論問題的根源——如何在容器的啟動和運行過程中保護好磁碟的權限不被覆蓋，以及如何利用startup script中創建的專用service來動態調整和修正權限

前言​

遇到的問題與初步解決嘗試​

深入系統日誌與源碼分析​

日誌分析：確認Startup Script的執行者​

從日誌追蹤到Konlet的行動​

查看 source code：確定掛載和權限設置​

最終解決方案​

結語​

配置Terraform​

定義資源：靜態內部IP​

設置虛擬機實例​

配置外接硬碟​

定義容器規格​

定義模組​

結語​

前言