Halaman ini diterjemahkan oleh Cloud Translation API.

Membuat struktur Deployment Manager untuk digunakan dalam skala besar

Jika sistem "Infrastruktur sebagai kode" Anda berkembang di luar contoh "Hello World" tanpa perencanaan, kode cenderung menjadi tidak terstruktur. Konfigurasi yang tidak direncanakan di-hardcode. Kemudahan pemeliharaan menurun drastis.

Gunakan dokumen ini, beserta contoh kode yang menyertainya, untuk menyusun deployment Anda secara lebih efisien dan berskala besar.

Selain itu, terapkan konvensi penamaan dan praktik terbaik internal di seluruh tim Anda. Dokumen ini ditujukan untuk audiens yang memiliki kemampuan teknis tingkat lanjut, dan mengasumsikan bahwa Anda memiliki pemahaman dasar tentang Python, infrastruktur Google Cloud, Deployment Manager, dan, secara umum, infrastruktur sebagai kode.

Sebelum memulai

Jika Anda ingin menggunakan contoh command line dalam panduan ini, instal alat command line`gcloud`.
Jika Anda ingin menggunakan contoh API dalam panduan ini, siapkan akses API.

Beberapa lingkungan dengan satu codebase

Untuk deployment besar dengan lebih dari selusin resource, praktik terbaik standar memerlukan Anda untuk menggunakan properti eksternal dalam jumlah yang signifikan (parameter konfigurasi), sehingga Anda dapat menghindari hardcode string dan logika ke template generik. Banyak properti ini diduplikasi sebagian karena lingkungan yang serupa, seperti lingkungan pengembangan, pengujian, atau produksi, dan layanan serupa. Misalnya, semua layanan standar berjalan di stack LAMP yang serupa. Mengikuti praktik terbaik ini akan menghasilkan kumpulan properti konfigurasi yang besar dengan duplikasi dalam jumlah tinggi yang dapat menjadi sulit dikelola, sehingga meningkatkan kemungkinan kesalahan manusia.

Tabel berikut adalah contoh kode untuk mengilustrasikan perbedaan antara konfigurasi hierarkis dan konfigurasi tunggal per deployment. Tabel ini menyoroti duplikasi umum dalam satu konfigurasi. Dengan menggunakan konfigurasi hierarkis, tabel menunjukkan cara memindahkan bagian berulang ke tingkat yang lebih tinggi dalam hierarki untuk menghindari pengulangan dan mengurangi kemungkinan kesalahan manusia.

Template	Konfigurasi hierarkis tanpa redundansi	Satu konfigurasi dengan redundansi
`project_config.py`	`config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP' }`	T/A
`frontend_config.py`	`config = {'ServiceName': 'frontend'}`	`config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'frontend' }`
`backend_config.py`	`config = {'ServiceName': 'backend'}`	`config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'backend' }`
`db_config.py`	`config = {'ServiceName': 'db'}`	`config = { 'ProjectId': 'qwerty123456', 'ProjectOwner': 'Bob', 'ProjectAbbrevation': 'SNP', 'ServiceName': 'db' }`

Untuk menangani codebase besar dengan lebih baik, gunakan tata letak hierarki terstruktur dengan penggabungan properti konfigurasi secara berurutan. Untuk melakukannya, Anda menggunakan beberapa file untuk konfigurasi, bukan hanya satu. Selain itu, Anda akan menggunakan fungsi helper dan membagikan sebagian codebase di seluruh organisasi.

Contoh kode yang menyertai dokumen ini, Organization_with_departments, berisi codebase dengan struktur yang telah ditentukan sebelumnya, tetapi dapat disesuaikan, skrip bantuan untuk menggabungkan konfigurasi, fungsi bantuan untuk penamaan, dan kumpulan lengkap contoh konfigurasi. Anda dapat menemukan contoh yang berfungsi ini di repositori GitHub contoh Deployment Manager.

Menyusun dan menyusun kode secara hierarkis menawarkan beberapa manfaat:

Saat memisahkan konfigurasi menjadi beberapa file, Anda akan meningkatkan struktur dan keterbacaan properti. Anda juga menghindari duplikasinya.
Anda mendesain penggabungan hierarkis untuk menyusun nilai secara logis, membuat file konfigurasi tingkat atas yang dapat digunakan kembali di seluruh project atau komponen.
Anda menentukan setiap properti hanya sekali (selain menimpa), sehingga tidak perlu menangani namespace dalam nama properti.
Template Anda tidak perlu mengetahui lingkungan yang sebenarnya, karena konfigurasi yang sesuai dimuat berdasarkan variabel yang sesuai.

Membuat struktur codebase secara hierarkis

Deployment Deployment Manager berisi konfigurasi YAML atau file skema, beserta beberapa file Python. Bersama-sama, file ini membentuk codebase deployment. File Python dapat digunakan untuk berbagai tujuan. Anda dapat menggunakan file Python sebagai template deployment, sebagai file kode umum (class helper), atau sebagai file kode yang menyimpan properti konfigurasi.

Untuk menyusun codebase secara hierarkis, Anda menggunakan beberapa file Python sebagai file konfigurasi, bukan file konfigurasi standar. Pendekatan ini memberi Anda fleksibilitas yang lebih besar daripada menautkan deployment ke satu file YAML.

Memperlakukan infrastruktur Anda sebagai kode nyata

Prinsip penting untuk kode yang bersih adalah Jangan Mengulangi Diri Sendiri (DRY)). Tentukan semuanya hanya sekali. Pendekatan ini membuat codebase lebih rapi, lebih mudah diulas dan divalidasi, serta lebih mudah dikelola. Jika properti hanya perlu diubah di satu tempat, risiko kesalahan manusia akan berkurang.

Untuk codebase yang lebih ringan dengan file konfigurasi yang lebih kecil dan duplikasi minimal, gunakan panduan ini untuk menyusun konfigurasi Anda agar mengikuti prinsip DRY.

Organisasi, departemen, lingkungan, dan modul

Prinsip dasar untuk menyusun codebase Anda dengan rapi dan hierarkis adalah menggunakan organisasi, departemen, lingkungan, dan modul. Prinsip ini bersifat opsional dan dapat diperluas. Untuk diagram hierarki contoh codebase, yang mengikuti prinsip-prinsip ini, lihat hierarki konfigurasi.

Dalam diagram berikut, modul di-deploy di lingkungan. Penggabung konfigurasi memilih file konfigurasi yang sesuai di setiap level berdasarkan konteks tempat file tersebut digunakan. Fitur ini juga otomatis menentukan sistem dan departemen.

Modul yang di-deploy di lingkungan

Dalam daftar berikut, angka mewakili urutan penggantian:

Properti organisasi

Ini adalah tingkat tertinggi dalam struktur Anda. Pada tingkat ini, Anda dapat menyimpan properti konfigurasi seperti organization_name, organization_abbreviation, yang Anda gunakan dalam konvensi penamaan, dan fungsi bantuan yang ingin Anda bagikan dan terapkan di semua tim.
Properti departemen

Organisasi berisi departemen, jika Anda memiliki departemen dalam struktur. Di setiap file konfigurasi departemen, bagikan properti yang tidak digunakan oleh departemen lain, misalnya, department_name atau cost_center.
Properti sistem (project)

Setiap departemen berisi sistem. Sistem adalah stack software yang ditentukan dengan baik, misalnya, platform e-commerce Anda. Ini bukan project Google Cloud, tetapi ekosistem layanan yang berfungsi.

Pada tingkat sistem, tim Anda memiliki otonomi yang jauh lebih besar daripada pada tingkat di atasnya. Di sini, Anda dapat menentukan fungsi helper (seperti project_name_generator(), instance_name_generator(), atau instance_label_generator()) untuk parameter tim dan seluruh sistem (misalnya, system_name, default_instance_size, atau naming_prefix).
Properti lingkungan

Sistem Anda kemungkinan memiliki beberapa lingkungan, seperti Dev, Test, atau Prod (dan, secara opsional, QA dan Staging), yang cukup mirip satu sama lain. Idealnya, keduanya menggunakan codebase yang sama, dan hanya berbeda pada tingkat konfigurasi. Di tingkat lingkungan, Anda dapat menimpa properti seperti default_instance_size untuk konfigurasi Prod dan QA.
Properti Modul

Jika sistem Anda besar, bagi menjadi beberapa modul, bukan mempertahankannya sebagai satu blok monolitik besar. Misalnya, Anda dapat memindahkan jaringan dan keamanan inti ke dalam blok terpisah. Anda juga dapat memisahkan lapisan backend, frontend, dan database menjadi modul terpisah. Modul adalah template yang dikembangkan oleh pihak ketiga, tempat Anda hanya menambahkan konfigurasi yang sesuai. Di tingkat modul, Anda dapat menentukan properti yang hanya relevan untuk modul tertentu, termasuk properti yang dirancang untuk menulis ulang properti tingkat sistem yang diwarisi. Tingkat lingkungan dan modul adalah pembagian paralel dalam sistem, tetapi modul mengikuti lingkungan dalam proses penggabungan.
Properti modul khusus lingkungan

Beberapa properti modul Anda mungkin juga bergantung pada lingkungan, misalnya, ukuran instance, gambar, endpoint. Properti modul khusus lingkungan adalah tingkat yang paling spesifik, dan titik terakhir dalam penggabungan bertingkat untuk menimpa nilai yang ditentukan sebelumnya.

Class helper untuk menggabungkan konfigurasi

Class config_merger adalah class helper yang otomatis memuat file konfigurasi yang sesuai dan menggabungkan kontennya ke dalam satu kamus.

Untuk menggunakan class config_merger, Anda harus memberikan informasi berikut:

Nama modul.
Konteks global, yang berisi nama lingkungan.

Memanggil fungsi statis ConfigContext akan menampilkan kamus konfigurasi gabungan.

Kode berikut menunjukkan cara menggunakan class ini:

module = "frontend" menentukan konteks, tempat file properti dimuat.
Lingkungan dipilih secara otomatis dari context.properties["envName"].

Konfigurasi global.

cc = config_merger.ConfigContext(context.properties, module)

print cc.configs['ServiceName']

Di balik layar, class helper ini harus selaras dengan struktur konfigurasi Anda, memuat semua level dalam urutan yang benar, dan menimpa nilai konfigurasi yang sesuai. Untuk mengubah level atau urutan penggantian, Anda harus mengubah class penggabungan konfigurasi.

Dalam penggunaan sehari-hari dan rutin, Anda biasanya tidak perlu menyentuh class ini. Biasanya, Anda mengedit template dan file konfigurasi yang sesuai, lalu menggunakan kamus output dengan semua konfigurasi di dalamnya.

Contoh codebase berisi tiga file konfigurasi hardcode berikut:

org_config.py
department_config.py
system_config.py

Anda dapat membuat file konfigurasi organisasi dan departemen sebagai link simbolis selama inisialisasi repositori. File ini dapat berada di repositori kode terpisah, karena secara logis file ini bukan bagian dari codebase tim project, tetapi dibagikan di seluruh organisasi dan departemen.

Penggabung konfigurasi juga mencari file yang cocok dengan level struktur Anda yang tersisa:

envs/[environment name].py
[environment name]/[module name].py
modules/[module name].py

File konfigurasi

Deployment Manager menggunakan satu file konfigurasi, yang merupakan satu file untuk deployment tertentu. Data ini tidak dapat dibagikan di seluruh deployment.

Saat Anda menggunakan class config-merger, properti konfigurasi akan sepenuhnya dilepaskan dari file konfigurasi ini karena Anda tidak menggunakannya. Sebagai gantinya, Anda menggunakan kumpulan file Python, yang memberi Anda lebih banyak fleksibilitas dalam deployment. File ini juga dapat dibagikan di seluruh deployment.

Setiap file Python dapat berisi variabel, yang memungkinkan Anda menyimpan konfigurasi dengan cara terstruktur, tetapi terdistribusi. Pendekatan terbaiknya adalah menggunakan kamus dengan struktur yang disepakati. Penggabung konfigurasi mencari kamus yang disebut configs di setiap file dalam rantai penggabungan. configs terpisah tersebut digabungkan menjadi satu.

Selama penggabungan, saat properti dengan jalur dan nama yang sama muncul di kamus beberapa kali, penggabungan konfigurasi akan menimpa properti tersebut. Dalam beberapa kasus, perilaku ini berguna, seperti saat nilai default ditimpa oleh nilai khusus konteks. Namun, ada banyak kasus lain saat Anda ingin menghindari menimpa properti. Untuk mencegah menimpa properti, tambahkan namespace terpisah ke properti tersebut agar unik. Dalam contoh berikut, Anda menambahkan namespace, dengan membuat tingkat tambahan dalam kamus konfigurasi, yang membuat subkamus.

config = {
    'Zip_code': '1234'
    'Count': '3'
    'project_module': {
        'admin': 'Joe',
    }
}

config = {
    'Zip_code': '5555'
    'Count': '5'
    'project_module_prod': {
        'admin': 'Steve',
    }
}

Class helper dan konvensi penamaan

Konvensi penamaan adalah cara terbaik untuk menjaga infrastruktur Deployment Manager Anda tetap terkontrol. Sebaiknya jangan gunakan nama yang samar atau generik, seperti my project atau test instance.

Contoh berikut adalah konvensi penamaan seluruh organisasi untuk instance:

def getInstanceName(self, name):
  return '-'.join(self.configs['Org_level_configs']['Org_Short_Name'],
                  self.configs['Department_level_configs']['Department_Short_Name'],
                  self.configs['System_short_name'],
                  name,
                  self.configs["envName"])

Menyediakan fungsi bantuan memudahkan penamaan setiap instance berdasarkan konvensi yang disepakati. Hal ini juga memudahkan peninjauan kode karena tidak ada nama instance yang berasal dari mana pun selain fungsi ini. Fungsi ini secara otomatis mengambil nama dari konfigurasi tingkat yang lebih tinggi. Pendekatan ini membantu menghindari input yang tidak perlu.

Anda dapat menerapkan konvensi penamaan ini ke sebagian besar resource Google Cloud dan untuk label. Fungsi yang lebih kompleks bahkan dapat menghasilkan kumpulan label default.

Struktur folder contoh codebase

Struktur folder codebase contoh fleksibel dan dapat disesuaikan. Namun, sebagian di-hardcode ke penggabungan konfigurasi dan file skema Deployment Manager, yang berarti jika Anda melakukan modifikasi, Anda harus mencerminkan perubahan tersebut dalam penggabungan konfigurasi dan file skema.

├── global
│   ├── configs
│   └── helper
└── systems
    └── my_ecom_system
        ├── configs
        │   ├── dev
        │   ├── envs
        │   ├── modules
        │   ├── prod
        │   └── test
        ├── helper
        └── templates

Folder global berisi file yang dibagikan di berbagai tim project. Untuk memudahkan, folder konfigurasi berisi konfigurasi organisasi dan semua file konfigurasi departemen. Dalam contoh ini, tidak ada class helper terpisah untuk departemen. Anda dapat menambahkan class helper apa pun di level organisasi atau sistem.

Folder global dapat berada di repositori Git terpisah. Anda dapat mereferensikan filenya dari setiap sistem. Anda juga dapat menggunakan link simbolis, tetapi link tersebut dapat menyebabkan kebingungan atau gangguan pada sistem operasi tertentu.

├── configs
│   ├── Department_Data_config.py
│   ├── Department_Finance_config.py
│   ├── Department_RandD_config.py
│   └── org_config.py
└── helper
    ├── config_merger.py
    └── naming_helper.py

Folder sistem berisi satu atau beberapa sistem yang berbeda. Sistem ini terpisah satu sama lain, dan tidak berbagi konfigurasi.

├── configs
│   ├── dev
│   ├── envs
│   ├── modules
│   ├── prod
│   └── test
├── helper
└── templates

Folder konfigurasi berisi semua file konfigurasi yang unik untuk sistem ini, yang juga mereferensikan konfigurasi global dengan link simbolik.

├── department_config.py -> ../../../global/configs/Department_Data_config.py
├── org_config.py -> ../../../global/configs/org_config.py
├── system_config.py
├── dev
│   ├── frontend.py
│   └── project.py
├── prod
│   ├── frontend.py
│   └── project.py
├── test
│   ├── frontend.py
│   └── project.py
├── envs
│   ├── dev.py
│   ├── prod.py
│   └── test.py
└── modules
    ├── frontend.py
    └── project.py

Org_config.py:

config = {
  'Org_level_configs': {
    'Org_Name': 'Sample Inc.',
    'Org_Short_Name': 'sampl',
    'HQ_Address': {
      'City': 'London',
      'Country': 'UK'
    }
  }
}

Di folder helper, Anda dapat menambahkan class helper lebih lanjut dan mereferensikan class global.

├── config_merger.py -> ../../../global/helper/config_merger.py
└── naming_helper.py -> ../../../global/helper/naming_helper.py

Di folder template, Anda dapat menyimpan atau mereferensikan template Deployment Manager. Link simbolis juga berfungsi di sini.

├── project_creation -> ../../../../../../examples/v2/project_creation
└── simple_frontend.py

Menggunakan codebase contoh

Cara terbaik untuk mulai menerapkan praktik hierarkis ini sebagai dasar infrastruktur sebagai kode adalah dengan meng-clone codebase contoh dan menyalin konten folder hierarchical_configuration.

Lihat repositori contoh.

git clone https://github.com/GoogleCloudPlatform/deploymentmanager-samples.git
cd deploymentmanager-samples/community/hierarchical_configuration/Organization_with_departments/systems/my_ecom_system
gcloud config set deployment_manager/glob_imports True

Untuk menyiapkan sistem, gunakan link simbolis berikut untuk mereferensikan file global ke konteks lokal.

ln -sf ../../../global/helper/config_merger.py helper/config_merger.py
ln -sf ../../../global/helper/naming_helper.py helper/naming_helper.py
ln -sf ../../../global/configs/org_config.py configs/org_config.py

Pilih departemen yang sesuai dari daftar global.

ln -sf ../../../global/configs/Department_Data_config.py configs/department_config.py

Untuk menetapkan konteks lingkungan yang tepat, gunakan flag --properties untuk menentukan properti envName. Properti ini memungkinkan Anda menjalankan kode yang sama, yang menargetkan lingkungan yang berbeda, dengan perintah yang sama. [MY-PROJECT-ID] mewakili project ID project Google Cloud Anda sendiri.

[MY-PROJECT-ID]
gcloud deployment-manager deployments create hierarchy-org-example-dev
--template env_demo_project.py --properties=envName:dev
gcloud deployment-manager deployments create hierarchy-org-example-test
--template env_demo_project.py --properties=envName:test
gcloud deployment-manager deployments create hierarchy-org-example-prod
--template env_demo_project.py --properties=envName:prod

Praktik terbaik

Praktik terbaik berikut dapat membantu Anda menyusun kode secara hierarkis.

File skema

Dalam file skema, Deployment Manager mewajibkan Anda mencantumkan setiap file yang Anda gunakan dengan cara apa pun selama deployment. Menambahkan seluruh folder akan membuat kode Anda lebih pendek dan lebih umum.

Class helper:

- path: helper/*.py

File konfigurasi:

- path: configs/*.py
- path: configs/*/*.py

Impor massal (gaya glob)

gcloud config set deployment_manager/glob_imports True

Beberapa deployment

Praktik terbaik untuk sistem adalah berisi beberapa deployment, yang berarti sistem tersebut menggunakan kumpulan konfigurasi yang sama, meskipun modulnya berbeda, misalnya, jaringan, firewall, backend, frontend. Anda mungkin perlu mengakses output deployment ini dari deployment lain. Anda dapat membuat kueri output deployment setelah siap dan menyimpannya di folder konfigurasi. Anda dapat menambahkan file konfigurasi ini selama proses penggabungan.

Link simbolis

Link simbolis didukung oleh perintah gcloud deployment-manager, dan file tertaut dimuat dengan benar. Namun, link simbolis tidak didukung di setiap OS.

Hierarki konfigurasi

Diagram berikut adalah ringkasan berbagai tingkat dan hubungannya. Setiap persegi panjang mewakili file properti, seperti yang ditunjukkan oleh nama file dalam warna merah.

Hierarki konfigurasi dengan berbagai tingkat dan hubungannya yang disebutkan.

Urutan penggabungan kontekstual

Penggabung konfigurasi memilih file konfigurasi yang sesuai di setiap level berdasarkan konteks tempat setiap file digunakan. Konteks adalah modul yang Anda deploy di lingkungan. Konteks ini menentukan sistem dan departemen secara otomatis.

Dalam diagram berikut, angka mewakili urutan penggantian dalam hierarki:

Diagram urutan penggantian

Langkah selanjutnya

Lihat contoh deployment lainnya di repositori GitHub Deployment Manager.
Baca selengkapnya tentang template dan deployment.