Senarai Kandungan

1. Pengenalan

Taking a look at the infrastructure in my first few days of working at Xoxoday, I quickly realized that the infrastructure was relatively nascent. The multiple loose ends I noticed were potential indicators of technical debt, strictly speaking in terms of Infrastructure setup. The loose ends included the design, architecture, tooling, monitoring, and logging, along with various processes & practices.

Considering the nature of business, Xoxoday is a user-facing web service that could typically be categorized under Software as a Service (SaaS). That puts a lot of pressure on specific technical requirements such as availability, uptime, reliability, robustness & scalability.

A typical e-commerce website such as Xoxoday with high global traffic necessitates that we adapt to the latest and unique design patterns, architecture, tools & practices. This is to ensure that we keep up with the quality of service expected by the user base and ideally exceed the same.

Akhirnya, satu lagi keperluan kritikal yang timbul kerana sebab pematuhan privasi dan keselamatan adalah bahawa kebanyakan pelanggan mengambil berat tentang lokasi data. Jangkaan biasa ialah data tinggal dan tidak pernah meninggalkan negara atau rantau yang diminta.

Ini mewujudkan keperluan untuk mempertimbangkan penggunaan pelbagai persekitaran pengeluaran secara selari, penggunaan atom bebas antara satu sama lain. Kami memanggil ini policloud, walaupun istilah itu boleh dibahaskan. Keperluan ini memerlukan kita untuk mempunyai keadaan automasi seni kerana kita kini perlu meniru pengurusan & penyelenggaraan infrastruktur kami di pelbagai wilayah.

Oleh itu, selepas beberapa pertimbangan yang teliti, kami dengan cepat menyedari bahawa kami perlu mempunyai proses &amalan automasi infrastruktur yang terbaik bersama dengan portfolio teknologi berasaskan awan moden untuk menjadi asli awan dan memberikan perkhidmatan dan pengalaman terbaik kepada pengguna kami.

Lapisan perak untuk kami adalah bahawa pemaju telah membahagikan perkhidmatan mereka kepada perkhidmatan mikro. Ini membantu kami bergerak dengan cepat dari segi mengguna pakai trend &amalan infrastruktur terkini.

2. Perlu automasi

Automasi perkhidmatan di awan telah menjadi topik hangat dalam beberapa tahun kebelakangan ini, yang membawa kepada peningkatan banyak alat & teknologi yang sangat baik. Keperluan kami biasanya didorong oleh sifat perniagaan & tuntutannya. Bagi kami, faktor-faktor berikut adalah penting:

  • Ketersediaan Tinggi
  • Penskalaan automatik
  • Penyembuhan Diri

Selain itu, automasi membawa peluang untuk mencapai infrastruktur sebagai kod, membolehkan kami berinteraksi dengan infrastruktur sambil memanfaatkan faedah hebat Sistem Kawalan Versi.

Ini adalah anjakan paradigma yang besar kerana ia membolehkan kita melihat infrastruktur secara proaktif dan mengurangkan interaksi reaktif (penting). Ia menjadikan pengembalian lebih mudah dan membantu kami menjejaki perubahan di seluruh infrastruktur dengan cekap. Juga, automasi bermaksud bahawa pasukan DevOps kami dapat berehat dengan tenang pada waktu ganjil.

Satu lagi faedah tambahan automasi ialah ia membuka pelbagai saluran untuk memodenkan dan meningkatkan produktiviti pemaju. Kami akan melihat dengan lebih mendalam topik ini dalam bahagian berikut mengenai penghantaran berterusan.

3. Penyepaduan, Penghantaran & Penggunaan Berterusan

Pelepasan boleh menjadi mimpi ngeri yang menyakitkan jika saluran paip, alat, dan garis panduan yang betul tidak ada. Ini bermakna bahawa tulang belakang kritikal DevOps adalah saluran paip CI / CD yang membantu kami menguji, mengintegrasikan, membina & menggunakan kod kami ke dalam pengeluaran.

Kami berhasrat untuk dapat melakukan pelbagai penggunaan pengeluaran dalam sehari dan melakukan penggunaan ini dengan lancar. Sekiranya ia pecah, kami ingin melancarkan kemas kini dengan lancar dan cepat.

Seperti yang dinyatakan sebelum ini, pemaju kami telah melakukan kerja yang hebat untuk memecahkan perkhidmatan monolitik ke dalam perkhidmatan mikro yang membuka pintu kepada dunia awan asli. Namun, ia datang dengan set cabarannya sendiri. Cabaran terbesar yang kami hadapi ialah ujian integrasi.

Selain itu, seni bina kami dan beberapa alat asli awan yang sangat baik membolehkan kami mendekati pembangunan perisian secara inovatif. Kami mengganggu konvensyen tradisional untuk menyesuaikan diri dengan dunia perkhidmatan mikro yang baru dan menarik.

Bermula dengan amalan yang mantap untuk mempunyai pelbagai persekitaran membolehkan kami menguji dan meneliti portfolio ciri kami sebelum menggunakannya untuk pengeluaran. Setelah selesai mengusahakan ciri, pepijat, atau penambahbaikan tertentu mereka, pembangun kami membuka permintaan tarik ke cawangan "dev" di git.

Sebaik sahaja PR diluluskan, komitmen telah digabungkan ke cawangan dev. Kami telah menyediakan mekanisme pencetus manual untuk menggunakan cawangan dev kepada pemaju. ( yang akan kita terokai kemudian)

Pangkalan kod di cawangan ini dikerahkan ke persekitaran pemaju, persekitaran khusus bagi pemaju untuk menguji ciri-ciri pendarahan mereka. Terdapat dua persekitaran pemaju, satu untuk pemaju menguji ciri-ciri dan perkhidmatan mikro mereka dan satu lagi untuk ujian integrasi.

Sebaik sahaja pangkalan kod diuji, dan pasukan QA meluluskannya, komitmen itu terus digabungkan ke cawangan "pementasan atau uat". Dari sini, pangkalan kod telah digunakan (dicetuskan secara manual) ke persekitaran Pementasan, yang kami berusaha untuk mengekalkan sedekat mungkin pengeluaran.

Terdapat satu lagi mata pada Pementasan sebelum mempertimbangkan ciri-ciri dan perkhidmatan mikro yang akan dihantar ke pengeluaran. Kami mempunyai persekitaran yang berbeza, persekitaran demo, yang dikhaskan semata-mata untuk demo perkhidmatan kami kepada bakal pelanggan yang berminat untuk meneroka perkhidmatan kami.

Kami meninjau dan menganalisis alat terbaik untuk CI / CD, dan akhirnya, kami menetap dengan Tindakan Github. Ringkasnya, Tindakan Github memberi kami persekitaran bersepadu yang bermain dengan baik bersama-sama dengan aliran kerja GitHub dan mempunyai onboarding minimum untuk pasukan pemaju.

Bersama-sama dengan integrasi yang ketat, ia juga memberi kita keadaan mekanisme CI / CD seni. Ia sangat pantas, berpatutan, mudah dikonfigurasi dan disesuaikan. Dan ia mempunyai sintaks berasaskan YML yang sangat mudah untuk menentukan pekerjaan yang membolehkan kami melakukan definisi CI / CD dengan pangkalan kod dan menjejakinya dengan kehebatan git.

a. Integrasi Berterusan

Kami meneroka beberapa cara untuk mencetuskan binaan secara automatik tetapi dengan cepat menyedari bahawa lebih baik membiarkan pembangun mengawal masa untuk membina. Mungkin terdapat banyak sebab yang memihak kepada atau menentang penggunaan automatik dan penggunaan manual.

Adalah lebih baik untuk menyelaraskan jangkaan pasukan dan membungkus keputusan ini berdasarkan kemudahan, kerana terlalu banyak automasi mempunyai perangkap yang berpotensi.

Untuk persekitaran bukan pengeluaran kami, kami mempunyai pencetus manual untuk membina dan menggunakan binaan terkini ke dalam persekitaran masing-masing. Dalam persekitaran pengeluaran kami, binaan dicetuskan secara automatik pada tolakan tag git. Tag Git membolehkan kami berpegang pada skema versi dan memudahkan untuk melancarkan semula versi dalam pengeluaran jika diperlukan.

Mengetepikan ujian unit dan ujian fungsional yang dijalankan oleh pemaju pada komitmen mereka, mari kita fokus pada sisi infrastruktur perkara dalam CI / CD kami. Kerja binaan, sebaik sahaja dicetuskan, pada dasarnya mengesahkan dengan ECR, menguruskan cache imej, dan menjalankan arahan binaan docker untuk mencipta imej bekas.

Imej kontena ini ditolak ke repositori ECR masing-masing. Ia adalah persediaan yang mudah tetapi sangat berkuasa dan fleksibel kerana ia membolehkan kami menyerahkan pencetus kepada pemaju sambil mengautomasikan keseluruhan proses.

b. Penggunaan Berterusan

Kami mempunyai pencetus manual yang diberikan kepada pemaju untuk menggunakan binaan terkini ke persekitaran masing-masing. Kami menggunakan tag imej Docker untuk membezakan antara imej bekas untuk cawangan git individu dan alam sekitar.

Perkhidmatan mikro kami dijalankan di Kubernetes. Kerja penggunaan biasa melakukan perkara berikut:

  1. Kemas kini fail konfigurasi & pemboleh ubah:Kami memadam configmaps sedia ada dan menciptanya semula kerana Kubernetes tidak mengemas kini konfigurasi sedia ada. Fail konfigurasi kami komited kepada repositori git peribadi, dan maklumat sensitif disimpan di Pengurus Rahsia AWS. Oleh itu, git membolehkan kami mengesan fail konfigurasi menjadikannya lebih mudah bagi kami untuk memadam dan membuat semula configmaps dalam kubernetes.
  2. Kemas kini penggunaan & perkhidmatan pada Kubernetes (sekiranya terdapat perubahan pada fail Yaml)
  3. Dan akhirnya, lakukan penggunaan rollout kubernetes kerana Kubernetes tidak mengemas kini penggunaan/pod secara automatik hanya untuk perubahan pada fail konfigurasi (configmaps).

Kami menggunakan sumber berikut dari komuniti tindakan GitHub untuk membantu kami menyambung, mengesahkan dan berkomunikasi dengan EKS / ECR & Docker dengan mudah.

4. Senibina

Kami menggunakan AWS untuk keperluan infrastruktur kami. AWS menyediakan kami dengan ekosistem perkhidmatan yang kaya yang cekap menjalankan dan menguruskan armada perkhidmatan mikro kami dan backend dan middleware yang berkaitan.

These microservices are running atop Kubernetes managed by AWS EKS. AWS EKS offering saves us a lot of time and effort that Xoxoday would otherwise spend on managing the lifecycle of the Kubernetes cluster itself. That allows us to take advantage of the cloud native ecosystem while focusing on our services and working on them.

Kubernetes membawa pengalaman bernilai kira-kira satu dekad daripada menjalankan infrastruktur global Google. Ia menyediakan kami dengan pelbagai ciri. Untuk menamakan beberapa: Penyembuhan diri, autoscaling, ketersediaan tinggi sambil menyatukan dan meningkatkan kecekapan di mana kita menggunakan infrastruktur asas kami. Kami menggunakan kemasukan untuk mendedahkan perkhidmatan kami kepada dunia luar melalui campuran Pengimbang Aplikasi dan Beban Klasik dan automasi kemasukan DNS53 laluan.

Perkhidmatan ini menyambung ke bahagian belakang kami, yang dihoskan dalam campuran perkhidmatan terurus AWS seperti kafka, RDS & EC2 yang dihoskan sendiri. Kami sangat memanfaatkan Terraform untuk persediaan automatik EKS, gabungan unik Terraform dan Templat Pelancaran AWS untuk melahirkan contoh EC2 dan menguruskannya secara automatik.

Selain itu, SaltStack digunakan untuk gerakan kompleks menguruskan persediaan automatik armada kejadian EC2. Ia membolehkan kami mengurus, mengemas kini & menyelenggara Sistem Operasi dan perkhidmatan yang berjalan di atas secara automatik. SaltStack mempunyai set ciri yang mantap dan seni bina yang direka dengan cemerlang, fleksibel & boleh dipasang. Kami kemudian secara automatik menyediakan perkhidmatan & mengambil tetapan backend yang baru dikonfigurasi (Alamat IP dll) dan mengisi fail konfigurasi kubernetes, mengemas kini configmaps dan menggunakannya ke dalam persekitaran.

Ini membolehkan kami mengkonfigurasi dan mengkonfigurasi semula perkhidmatan tanpa kerakyatan yang berjalan di persekitaran Kubernetes untuk diperuntukkan secara automatik & dikonfigurasikan dengan perubahan dinamik pada persediaan backend. Imej kontena kami disimpan di AWS ECR kerana ia memberikan kami satu lagi perkhidmatan hebat yang berintegrasi dengan lancar dengan set teknologi dan seni bina kami yang diberikan.

5. Pembalakan, Pemantauan, Pemakluman & APM

Kami akan menjadi buta jika kami tidak mempunyai mekanisme maklum balas yang sesuai untuk memahami apa yang berlaku dalam infrastruktur kami, terutamanya jika kita bercakap tentang senario Polycloud.

a. Elasticsearch/Fluentd/Kibana

Kami menggunakan timbunan EFK yang unik untuk kebimbangan berkaitan pembalakan kami. Ini membolehkan kami mencipta dan mengekalkan satu set perkhidmatan mikro dinamik yang berjalan merentasi bekas dan mesin maya sambil mengekalkan log dalam saluran paip berpusat.

Ini membolehkan kita mengakses balak untuk kejadian / bekas yang dimusnahkan atas pelbagai sebab. Dan itu memudahkan kita mengakses dan menangani pelbagai kebimbangan dalam pengeluaran. Berikut adalah alternatif elastik lain untuk anda pergi.

b. Grafana/Prometheus

Papan pemuka Grafana, bersama-sama dengan pangkalan data siri masa Prometheus, membolehkan kami mengekalkan pelbagai butiran mengenai infrastruktur kami seperti CPU / RAM / Penyimpanan, dll. dan memastikan kami dikemas kini dengan status semasa infrastruktur dalam masa nyata.

Ini membolehkan kami melaksanakan mekanisme amaran, memudahkan pasukan DevOps kami menangani insiden dalam infrastruktur kami. Walaupun semua persediaan dan yang terbaik dari seni bina & reka bentuk terbaik, perkara masih boleh pecah. Sistem Grafana Prometheus, bersama-sama dengan Alertmanager, membolehkan pengurangan insiden dalam pengeluaran.

Selain itu, timbunan ini mendapat manfaat daripada Pengurusan Pengaturcaraan Aplikasi, yang memberikan kami satu set metrik yang kaya yang memberi kita pandangan kritikal mengenai produk, penggunaannya, dan banyak lagi.

6. Mengganggu persekitaran pemaju

Since we were walking on the path of microservices, we had to manage over 40 microservices which when orchestrated together to form our web service www.xoxoday.com. This implies a lot of communication between these microservices, and the sheer number of them makes it impossible and impractical to run it locally on the developer’s machine.

Oleh itu, kami terpaksa kreatif dan kembali ke perairan dalam dunia awan asli untuk mencari penyelesaian yang mungkin. Kami melihat ramai, untuk menamakan beberapa:

- Telepresence

- Skaffold

- Kubefwd

Pada masa ini, kegemaran kami dan yang paling berguna memenuhi keperluan kami ialah Kubefwd, tetapi kami boleh meneroka alat lain pada masa akan datang. Kubefwd membolehkan kami membuat perkhidmatan Kubernetes boleh diakses di stesen kerja tempatan menggunakan DNS yang sama seolah-olah mesin pemaju tempatan terletak di dalam gugusan Kubernetes!

Ini bermakna rangsangan produktiviti yang luar biasa yang menjadikan pemaju lebih cekap sambil meningkatkan pengalaman keseluruhan dan mengurangkan sementara itu untuk mendapatkan ciri di luar sana ke dunia.

7. Kesimpulannya

Selepas berbulan-bulan meneliti keperluan infrastruktur kami dan menjadikannya sejajar dengan keperluan perniagaan, pertumbuhan masa depan, dan trend semasa dalam infrastruktur dan dunia asli awan, kami akhirnya sampai ke tahap di mana kami dengan yakin dapat menantikan beberapa hari yang menakjubkan di hadapan.

Bukan sahaja infrastruktur kami telah mengambil lonjakan evolusi selama satu dekad, tetapi ia juga berjaya mengurangkan tekanan pada pasukan DevOps sambil secara drastik meningkatkan produktiviti pemaju. Akhirnya, persediaan kami lebih murah dan melakukan lebih banyak lagi, dan melakukannya dengan lebih baik!

Persediaan ini membolehkan kami meniru keseluruhan set perkhidmatan, frontend, dan backend kami dengan mudah dan secara automatik menyediakan dirinya dalam masa beberapa minit. Ini akan membolehkan kami mewujudkan pelbagai persekitaran pengeluaran atom dan bebas, mengubahnya dengan saluran paip CI / CD kami dan secara automatik mengurus dan mengekalkan persediaan kompleks dengan mudah.

Selain itu, manfaat yang paling penting dari semua ini adalah bahawa pasukan DevOps kami boleh kekal kecil dan berskala linear sambil menyediakan skala global eksponen untuk perkhidmatan kami. Dan ceri di bahagian atas adalah bahawa pasukan DevOps dapat mengadakan malam yang damai & hujung minggu yang hebat tanpa perlu melawan masalah pengeluaran secara reaktif kerana reka bentuk dan seni bina kami membolehkan kami menangani cabaran ini secara proaktif.

Salah satu perkara hebat mengenai persediaan kami ialah sifat automatik membolehkan kami menggunakan contoh tempat untuk sistem bukan pengeluaran dan bukan kritikal kami. Ini membantu kami mengoptimumkan dan menyatukan kos lebih jauh sambil mempunyai kuasa pengkomputeran yang mencukupi. Ini bermakna persediaan yang sangat kos efektif, dan jika sekiranya AWS memutuskan untuk menutup keadaan tempat kami, tidak ada masalah, dalam masa beberapa minit, kami akan memberikan contoh khusus kami secara automatik dan membuat yang terbaik dari kedua-dua dunia!

Trend semasa dalam dunia infrastruktur, terutamanya melihat perkembangan Asli Awan, menjadikannya dekad yang menarik di hadapan untuk DevOps; Rasanya kita hampir mencapai Nirvana. Bilangan alat, penyelesaian, perkhidmatan & ekosistem yang muncul boleh menjadi luar biasa pada masa-masa tertentu. Namun, secara retrospektif, kami menuju ke arah era perkhidmatan web yang kukuh yang mantap dan sentiasa tersedia sambil memberikan pengalaman hebat kepada pengguna.

Pranav Salunke