Mengkonfigurasi ClickHouse untuk pengujian integrasi di gitlab-ci

Kami memiliki layanan di golang, topik terpisah kafka, clickhouse, gitlab-ci dan payline jatuh, kunci ssh busuk dan itu semua, bersama dengan musim liburan, hujan yang mengerikan di kota, laptop yang rusak, peringatan di malam hari, dan penjualan panas . Bukan berarti semua ini diperlukan untuk artikel ini, tetapi begitu Anda menunjukkan kehidupan sehari-hari khas penguji, maka pergilah niat Anda sampai akhir. Satu-satunya hal yang menggangguku adalah p0. Di dunia tidak ada yang lebih putus asa, suram, dan tertekan dibandingkan dengan penguji yang melewatkannya pada dorongan. Tetapi saya tahu bahwa tidak lama lagi saya akan terjun ke dalamnya.

Kenapa semua ini?

Ada sekumpulan layanan umum - layanan itu sendiri yang melakukan sesuatu - dan sebuah database di mana hasil ini ditulis. terkadang ini terjadi secara langsung, yaitu, "layanan - basis". Dalam kasus saya, perekaman terjadi melalui perantara, yaitu, "layanan - antrian - basis".

Secara total, ada beberapa elemen, dan perbatasan elemen-elemen ini - output dari satu dan input dari yang lain - ini adalah tempat di mana masalah muncul. Mereka tidak bisa muncul di sana.

Contoh nyata: dalam layanan, bidang harga diproses sebagai float32, dalam database yang dikonfigurasi sebagai desimal (18, 5), kami mengumpankan nilai maksimum float32 sebagai kasus uji dari output layanan ke database - oh, database tidak merespons. Atau contoh yang lebih menyedihkan - database tidak macet, tetapi tidak ada kesalahan dalam log data dalam database. hanya saja databasenya tidak lagi mengalir. Atau rekaman melewati, tetapi dengan kehilangan data atau dengan distorsi: bidang keluar dari layanan sebagai float64, dan dicatat sebagai float32.

Atau dalam proses siklus hidup layanan mereka memutuskan bahwa perlu untuk mengubah jenis bidang ini atau itu. Bidang ini telah lama diimplementasikan pada prod, tetapi di sini perlu untuk mengeditnya. Dan tentu saja kami mengubahnya hanya di satu tempat. Hoba, ada yang salah lagi.

Tantangan

Saya tidak ingin melacak semua perubahan ini. Saya ingin itu tidak jatuh. Saya ingin rekaman berjalan dengan benar.

Keluar: tes integrasi!

Implementasi dan kesulitan

Dimana harus istirahat?

Ada lingkungan dev: sangat tidak stabil dan biasanya digunakan oleh pengembang sebagai bak pasir. Ada kekacauan dan karakteristik anarki dari backend yang keras.

Ada lingkungan pengujian atau qa-stand: lebih baik disetel, bahkan devops menontonnya, tetapi sampai Anda menendang mereka, tidak ada yang akan terjadi. dan lingkungan ini sering diperbarui. dan bahkan lebih sering, ada sesuatu yang rusak di sana.

Dan ada dorongan - yang kudus: lebih baik tidak mengendarai sesuatu seperti itu di atasnya. tes integrasi menyarankan kemungkinan bug yang harus mereka temukan sebelum sampai ke prod.

Jadi apa yang harus dilakukan dengan lingkungan saat itu tidak stabil atau bertempur? Itu benar, buat sendiri!

Apa yang harus dilakukan dengan pangkalan?

Basis data dapat diluncurkan dengan beberapa cara.

Seperti yang kita diskusikan di atas, kita tidak akan terhubung ke basis nyata dari lingkungan ini atau itu.

Pertama, Anda dapat meningkatkan crab clickhouse-server dengan pengaturan yang diperlukan, meluncurkan sql yang diperlukan di dalamnya dan berkomunikasi dengannya melalui clickhouse-client. Pada upaya pertama yang berhasil untuk menempatkan basis yang sama, ci sedih. tes menyala, server tidak keluar dan terus bekerja. Katakan saja, masih tetap menjadi misteri bagi saya mengapa itu bahkan dimulai. (itu sendiri, saya tidak ada hubungannya dengan itu). Saya tidak merekomendasikan opsi ini.

Pilihan nyaman di luar kotak adalah penggunaan gambar buruh pelabuhan .
Unduh versi yang diinginkan ke mobil Anda. Clickhouse membutuhkan config.xml dengan pengaturan untuk memulai. Lebih detail di sini
Untuk gambar klik yang digunakan kembali, Anda harus membuat dockerfile yang benar. Kami mengindikasikan di dalamnya bahwa kami ingin menyalin config.xl ke folder, kami dock konfigurasi yang diperlukan lainnya. Pastikan untuk menyalin skrip untuk menggunakan basis Anda.

Karena kita akan mengakses gambar dari luar, kita perlu membuka porta tempat kita akan berkomunikasi dengan clickhouse. Klik berfungsi pada 8123 di http dan pada 9000 di tcp.

Kami mendapatkan dockerfile berikut:

From yandex/clickhouse-server Expose 8123 Expose 9000 Add config.xml /etc/clickhouse-server/config.xml Add my_init_script.sql /docker-entrypoint-initdb.d/ 

Bagaimana cara melempar gambar ke dalam ci?

Untuk entah bagaimana bekerja dengan gambar buruh pelabuhan di ci, Anda perlu menyebutnya entah bagaimana di sana.

Anda dapat mengkomit dan menjalankan gambar dalam repositori Anda dan menjalankan docker run dengan parameter yang diperlukan sebagai bagian dari menjalankan tes. Hanya di sini gambar buruh pelabuhan dari klik berbobot di bawah 350mb. tidak pantas menyimpan file seperti itu di git.

Selain itu, jika gambar buruh pelabuhan yang sama diperlukan pada proyek yang berbeda (misalnya, layanan yang berbeda ditulis ke database yang sama), maka terlebih lagi Anda tidak boleh melakukan ini. Anda dapat menggunakan penyimpanan gambar registri buruh pelabuhan
Kami percaya bahwa dalam proyek kami sudah ada dan digunakan. Karenanya, masuk, kumpulkan gambar buruh pelabuhan dan dorong ke sana.

 docker build -t my_clickhouse_image . docker login my_registry_path.domain.com docker push my_clickhouse_image 

Turun dan gambar kami terbang ke registri. Pastikan untuk menentukan tag selama perakitan!

Basis sudah siap.

Baca lebih lanjut tentang pendaftaran di sini

Apa yang harus dilakukan dengan ci?

Bagaimana cara meluncurkan layanan dan basis data Anda dalam satu langkah?

Itu semua tergantung pada bagaimana kita memulai dan menggunakan layanan. Jika Anda bekerja dengan layanan seperti dengan gambar buruh pelabuhan, dan memang keseluruhan .gitlab-ci.yml hanya bekerja dengan mereka, maka semuanya sederhana.
Ada dind liar - buruh pelabuhan di dermaga . Ini diindikasikan sebagai layanan utama yang bekerja dengan, dan memungkinkan Anda untuk sepenuhnya menggunakan buruh pelabuhan dan tidak tegang sama sekali.

Kami memompa gambar terbaru, menambahkan langkah pengujian yang diperlukan ke tahapan, dan menjelaskan urutan tindakan kami.

 image: docker:stable services: - docker:dind stages: - build … - test-click ... - test - release … test-click: variables: VERY_IMPORTANT_VARIABLE: “its value” before_script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY script: - docker pull My_Service_Image - docker pull My_ClickHouse_Image - docker run -FLAGS My_ClickHouse_Image - docker run My_Service_Image /path/to/tests 

Docker docker resmi menyatakan bahwa tidak dianjurkan untuk menggunakan dind , tetapi jika Anda benar-benar perlu ...

Dalam proyek saya, layanan harus diuji melalui peluncuran biner. Di sinilah keajaiban dimulai.
Untuk melakukan ini, gunakan database sebagai layanan. Dokumentasi gitlab-ci resmi mengutip penggunaan wadah dengan basis sebagai contoh kasus penggunaan yang paling umum untuk wadah buruh pelabuhan di ci. Bahkan contoh pengaturan mysql, postress, dan redis disediakan. Tapi kami tidak mencari cara mudah, kami butuh clickhouse.

Hubungkan basis! Pastikan untuk menentukan alias. jika tidak ditentukan, maka basis akan diberi nama acak dan ip acak. Artinya, tidak akan jelas bagaimana cara mengaksesnya. Tidak akan ada masalah dengan alias - dalam kode uji, panggilan akan terlihat seperti, misalnya, dengan http://my_alias_name:8123 .

Untuk tes, gambar dari database masih diperlukan, yang kami hati-hati masukkan ke dalam registri. Untuk mengunduh gambar, Anda harus melakukan login buruh pelabuhan dan buruh pelabuhan, hanya saja ci tidak tahu apa itu buruh pelabuhan - Anda harus menginstalnya.

Kode yang dihasilkan untuk langkah di gitlab-ci.yml:

 Integration tests: Services: - name: my_clickhouse:latest alias: clicktest Stage: tests Variables: Variables_for_my_service: “value” Before_script: - curl -ssl https://get.docker.com/ | sh - docker login -u gitlab-ci-token -p $ci_build_token my_registry_path.domain.com Script: - ./bin/my_service & - go test -v ./tests -tags=integration Dependencies: - build 

Untung

• Saya memiliki banyak basis layanan.
• Sebagai bagian dari autotest, mudah untuk mengakses database - cukup dengan alias.
• Saya mereset catatan dan pengaturan database sebagai bagian dari tes pengaturan, memanggil layanan, menulis ke database, saya beralih ke database, saya melihat bahwa database belum jatuh, saya melihat apa yang telah tiba, saya memvalidasi. lempar lebih banyak tes.
• Anda tidak dapat menguji dengan pena!

Hasil

Tampaknya beberapa baris setup di gitlab-ci. Membangun citra buruh pelabuhan itu mudah. Menjalankan secara lokal itu sederhana. Saya mendapatkan integrasi dengan tes pertama yang menemukan masalah dalam sehari. Tetapi upaya untuk meluncurkannya di ci berubah menjadi minggu kesakitan dan keputusasaan. Dan sekarang, dalam minggu-minggu kesakitan dan keputusasaan para pengembang yang harus memperbaiki semua yang telah mereka programkan di sana.

Apa yang berhasil kami lakukan?

• Kami menyiapkan wadah dengan clickhouse.
• Kami memulai wadah di penyimpanan lokal.
• Kami belajar menggambar gambar ini ke langkah ci.
• Meluncurkannya di pelari.

Mudah mengirim data ke database dan mengaksesnya dari tes.

Otomasi adalah cara yang cukup sederhana untuk menghilangkan rutinitas penindikan secara manual.

Yang penting diperhatikan: pastikan bahwa tipe input dari basis sesuai dengan tipe output dari tautan sebelumnya. (dan dokumentasi , jika ada ).