Pada artikel ini, saya ingin berbicara tentang bagaimana kami menggunakan Wayang dan Hiera untuk mengkonfigurasi server besi dan virtual. Pada dasarnya, ini tentang arsitektur dan hierarki yang kami temukan, yang memfasilitasi dan mensistematisasikan konfigurasi server.
Saya diminta untuk menulis artikel ini dengan fakta bahwa di internet saya tidak menemukan contoh yang baik dan benar-benar berfungsi tentang bagaimana Anda dapat bekerja dengan hiera dan untuk apa itu. Pada dasarnya, ini adalah tutorial dengan contoh untuk memasukkan topik. Tetapi aplikasi praktis sebenarnya dari hiera tidak ditulis di sana. Mungkin saya tidak terlihat baik, tetapi di sini ada contoh nyata yang mungkin akan membantu Anda meletakkan semua poin di atas saya, seperti yang pernah saya lakukan.
Untuk siapa artikel ini akan bermanfaat
Jika:
- Anda tahu apa itu Wayang dan Hiera, tetapi Anda tidak benar-benar menggunakannya bersama-sama, karena tidak jelas bagaimana melakukannya dan mengapa
- Anda memiliki banyak tim di perusahaan Anda dan Anda perlu membedakan konfigurasi server di tingkat perintah
- Anda menggunakan pappet, dan file simpul Anda telah berkembang ke ukuran luar biasa
- Apakah Anda suka membaca konfigurasi server dalam format divine yaml :)
- Anda pada dasarnya tertarik pada topik Manajemen Konfigurasi dan administrasi sistem.
Artikel ini untuk Anda.
Sebelum Anda mulai
Saya akan segera memperingatkan Anda, artikelnya ternyata panjang, tapi saya harap bermanfaat. Selain itu, dipahami bahwa Anda telah menghubungkan hiera ke boneka, dan Anda setidaknya entah bagaimana akrab dengan boneka. Jika hiera tidak terhubung, tidak sulit untuk melakukannya.
Masukkan data
- Kami memiliki sekitar 30 tim pengembangan di SEMrush, yang masing-masing memiliki server sendiri
- Setiap tim bekerja dengan set teknologinya sendiri (PL, DBMS, dll.)
- Tim dapat dan harus (idealnya) menggunakan konfigurasi umum untuk proyek tertentu (penggunaan kembali kode)
- Tim sendiri mengelola penyebaran aplikasi ke server mereka (ini tidak dilakukan melalui pappet)
Sedikit sejarah
Awalnya, kami memiliki semua yang ada di pappet versi 3, kemudian kami memutuskan untuk mengimplementasikan pappet ke-4, dan semua server baru mulai ditempatkan di dalamnya, dan yang lama perlahan-lahan dipindahkan ke porta ke-4.
Di pappet ketiga, kami biasa menggunakan sistem klasik file dan modul node. Modul-modul tersebut dibuat dalam kelompok proyek khusus di Gitlab, mereka dikloning ke server pappet (menggunakan r10k ), kemudian agen pappet datang ke wizard dan menerima direktori untuk menerapkannya ke server.
Kemudian mereka mulai berusaha untuk tidak melakukan ini dan tidak menggunakan modul lokal, tetapi menaruh tautan ke modul yang diperlukan dan repositori mereka di Puppetfile. Mengapa Karena modul-modul itu terus didukung dan ditingkatkan (baik, idealnya) oleh komunitas dan pengembang, dan yang lokal tidak. Kemudian mereka memperkenalkan hiera dan beralih sepenuhnya ke sana, dan file simpul (seperti nodes.pp) telah tenggelam terlupakan.
Pada pappet keempat, kami mencoba untuk sepenuhnya meninggalkan modul lokal dan hanya menggunakan modul jarak jauh. Sayangnya, reservasi harus dimasukkan di sini lagi, karena "tidak berhasil sepenuhnya", kadang-kadang Anda masih harus condong dan menyelesaikan sesuatu sendiri. Tentu saja, hanya ada hiera dan tidak ada file simpul.
Ketika Anda memiliki 30 tim dengan kebun binatang teknologi, masalah bagaimana menjaga server ini dengan> 1000 server menjadi sangat akut. Selanjutnya saya akan mengatakan bagaimana hiera membantu kita dalam hal ini.
Hierarki
Hiera (sebenarnya, dari mana ia mendapatkan namanya) mengatur hierarki. Bersama kami, terlihat seperti ini:
--- :hierarchy: - "nodes/%{::fqdn}" - "teams/%{::team}_team/nodes/%{::fqdn}" - "teams/%{::team}_team/projects/%{::project}/tiers/%{::tier}" - "teams/%{::team}_team/projects/%{::project}/%{::role}" - "teams/%{::team}_team/projects/%{::project}" - "teams/%{::team}_team/roles/%{::role}" - "teams/%{::team}_team/%{::team}" - "projects/%{::project}/tiers/%{::tier}/%{::role}" - "projects/%{::project}/tiers/%{::tier}" - "projects/%{::project}/%{::role}" - "projects/%{::project}" - "tiers/%{::tier}" - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common
Pertama, mari kita berurusan dengan variabel yang tidak jelas (fakta).
Setiap server di SEMrush idealnya memiliki 4 fakta terbuka yang menjelaskan afiliasinya:
- fakta
team - tim mana yang menjadi bagiannya project fakta - project mana yang berhubungan dengannya- fakta
role - peran apa yang dimiliki proyek ini tier fact - pementasan seperti apa yang dimilikinya (prod, test, dev)
Bagaimana cara kerjanya? Agen Pappet mendatangi master Pappet dan, berdasarkan fakta-fakta ini, mencari file untuk dirinya sendiri, menelusuri folder sesuai dengan hierarki kami. Tidak perlu menunjukkan file konfigurasi milik server. Sebaliknya, server sendiri tahu file mana yang menjadi milik mereka, hanya melihat jalur dan fakta mereka.
Selama pengaturan server, admin menghubungi pengembang dan menentukan parameter ini (seringkali, sebaliknya, orang-orang yang berpengetahuan menghubungi administrator sendiri) untuk membangun hierarki hiera di masa depan, atas dasar yang kemudian menggambarkan konfigurasi server. Sistem seperti ini membantu menggunakan kembali kode dan menjadi lebih fleksibel dalam hal konfigurasi server.
Sebagai contoh, kami memiliki proyek khusus . Dalam proyek ini, mungkin ada beberapa server frontend dengan nginx, server backend dengan python, cluster db dengan mysql, server redis untuk caching. Semua server ini harus ditempatkan dalam satu proyek yang disebut spesial , dan kemudian menetapkan peran ke server.
Dalam file proyek, kami menjelaskan parameter yang umum untuk seluruh proyek. Hal pertama yang terlintas dalam pikiran adalah penciptaan pada semua server pengguna untuk penyebaran dengan masalah hak yang diperlukan untuknya dan meluncurkan kunci ssh-nya.
Dalam peran untuk setiap server, layanan ini biasanya dijelaskan dan dikustomisasi - untuk apa server ini dimaksudkan (nginx, python, mysql, dll.) Tingkat dalam hal ini kita pasti perlu jika kita juga perlu menggunakan salinan lingkungan produksi pada platform dev, tetapi ubah sesuatu di dalamnya (kata sandi, misalnya). Dalam hal ini, dev-server dan prod-server hanya akan berbeda dalam kenyataan bahwa tier diatur ke "posisi" yang diinginkan (prod atau dev). Dan kemudian sedikit sihir dan hiera akan melakukan trik.
Jika kita perlu menggunakan dua server identik dalam peran yang sama, tetapi sesuatu di dalamnya harus berbeda, misalnya, beberapa baris dalam konfigurasi, maka bagian lain dari hierarki akan datang untuk menyelamatkan. Kami meletakkan file dengan nama format {fqdn }.yaml di tempat yang tepat (misalnya, nodes/myserver.domain.net ), mengatur nilai variabel yang diperlukan pada tingkat server tertentu, dan pappet akan menerapkan konfigurasi yang sama untuk kedua server untuk peran, dan unik untuk masing-masing dari server.
Contoh: dua backends dengan kode php berada dalam peran yang sama dan benar-benar identik. Jelas bahwa kami tidak ingin membuat cadangan kedua server - tidak masuk akal. Kita dapat membuat peran untuk mendeskripsikan konfigurasi yang sama untuk kedua server, dan kemudian membuat file nodes/backend1.semrush.net lain untuk menempatkan konfigurasi untuk cadangan.
File teams/team-name.yaml batch teams/team-name.yaml menunjukkan konfigurasi untuk semua server milik tim. Paling sering, ini menggambarkan pengguna yang dapat berinteraksi dengan server ini, serta hak akses mereka.
Berdasarkan variabel-variabel ini, kami telah membangun hierarki ini. Semakin tinggi file yang ditemukan dalam hierarki, semakin tinggi prioritas konfigurasi yang ditentukan di dalamnya.
Oleh karena itu variabel dapat menimpa berdasarkan hierarki ini. Yaitu, variabel dalam file peran " projects/%{::project}/%{::role} " lebih diutamakan daripada variabel dalam file projects/%{::project} " projects/%{::project} ". Variabel juga dapat bergabung di semua tingkatan hierarki jika Anda memiliki modul dan / atau profil / peran yang ditulis sedemikian rupa yang memungkinkan Anda untuk melakukan ini. Dengan menentukan bagian umum dari konfigurasi mysql untuk semua server proyek, Anda dapat menambahkan bagian-bagian khusus yang memiliki bobot untuk peran ini ke variabel yang sama di tingkat hierarki lain (akan ada bagian tambahan dalam konfigurasi untuk slave).
Ternyata file dari node spesifik yang terletak di sepanjang jalur " hieradata/nodes/%{::fqdn} " memiliki prioritas tertinggi. Berikutnya adalah file simpul, tetapi sudah di tingkat perintah. Di bawah ini adalah blok yang menggambarkan fakta lain yang lebih umum:
- "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common
Dengan demikian, dalam file common.yaml kami memiliki konfigurasi yang pasti harus datang ke semua server, di file users.yaml semua pengguna dijelaskan (tetapi tentu saja tidak semuanya dibuat di server,) di os/%{::operatingsystem} konfigurasi umum yang tipikal untuk server dengan OS tertentu (fakta ::operatingsystem ) dan sebagainya.
Saya pikir, melihat hierarki ini, semuanya menjadi jelas. Di bawah ini saya akan mempertimbangkan contoh penggunaan hierarki tersebut. Tetapi pertama-tama Anda perlu berbicara tentang profil.
Profil
Poin penting dalam mengkonfigurasi server menggunakan modul adalah penggunaan profil. Mereka terletak di jalur site/profiles dan merupakan titik masuk ke modul. Berkat mereka, Anda dapat lebih mengonfigurasi modul gantung di server dan membuat sumber daya yang diperlukan.
Pertimbangkan contoh sederhana. Ada modul yang menginstal dan mengkonfigurasi redis. Dan kami juga ingin mengatur parameter sysctl vm.overcommit_memory menjadi 1 saat menghubungkan modul ini, karena di sini . Kemudian kami menulis profil kecil yang menyediakan fungsi ini:
# standalone redis server class profiles::db::redis ( Hash $config = {}, String $output_buffer_limit_slave = '256mb 64mb 60', ) { # https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram sysctl { 'vm.overcommit_memory': ensure => present, value => '1', } class { '::redis': * => $config, } }
Seperti disebutkan di atas, profil adalah alat yang memungkinkan Anda untuk mengubah / meningkatkan perilaku modul, serta mengurangi jumlah konfigurasi di hiera. Jika Anda menggunakan modul jarak jauh, Anda dapat sering menghadapi masalah yang modul "disetujui" sering tidak memiliki fungsi yang Anda butuhkan, atau memiliki beberapa bug / kekurangan. Kemudian, pada prinsipnya, Anda dapat mengkloning modul ini dan memperbaiki / menambah fungsionalitas. Tetapi keputusan yang tepat adalah, jika mungkin, untuk menulis profil yang baik yang dapat "mempersiapkan" modul dengan cara yang Anda butuhkan. Berikut adalah beberapa contoh profil, dan Anda dapat lebih memahami mengapa itu diperlukan.
Menyembunyikan rahasia di hiera
Salah satu keuntungan penting hiera dibandingkan dengan bare pappet adalah kemampuannya untuk menyimpan data sensitif dalam file konfigurasi dalam bentuk terenkripsi dalam repositori. Kata sandi Anda akan aman.
Singkatnya, Anda menggunakan kunci publik untuk mengenkripsi informasi yang Anda butuhkan dan menempatkannya dengan garis seperti itu di file hiera. Bagian pribadi dari kunci disimpan pada master pappet, yang memungkinkan Anda untuk mendekripsi data ini. Rincian lebih lanjut dapat ditemukan di halaman proyek .
Pada klien (komputer yang bekerja), alat ini diinstal hanya dengan menggunakan gem install hiera-eyaml . Selanjutnya, dengan menggunakan perintah dari bentuk eyaml encrypt --pkcs7-public-key=/path/to/public_key.pkcs7.pem -s 'hello' Anda dapat mengenkripsi data dan menempelkannya ke file dengan ekstensi eyaml atau hanya yaml, tergantung pada bagaimana Anda konfigurasikan, dan kemudian pappet akan mengetahuinya. Anda mendapatkan sesuatu seperti:
roles::postrgresql::password: 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y+VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTewqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UMm6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkvKqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAMblkKgBCR/f9KGXUgLh3/Ok60OIT5]'
Atau string multi-line:
roles::postgresql::password: > ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw DQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y +VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF 2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTe wqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UM m6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkv KqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7 iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAM blkKgBCR/f9KGXUgLh3/Ok60OIT5]
Sepertinya kita sudah selesai dengan persiapan, sekarang kita dapat mempertimbangkan contoh.
Contoh jari
Spoiler : akan ada lebih banyak konfigurasi, sehingga mereka yang tertarik pada artikel ini yang murni kepentingan teoretis dapat melewati bagian ini dan pergi ke bagian akhir.
Sekarang mari kita lihat contoh cara mengkonfigurasi server menggunakan hiera di puppet4. Saya tidak akan mempublikasikan kode untuk semua profil, karena kalau tidak postingan akan menjadi cukup besar. Saya akan fokus pada hierarki dan konfigurasi hiera.
Tugasnya adalah ini: kita perlu menggunakan:
- Dua server db identik yang digunakan postgresql
- Dua server lagi - frontend dengan nginx
- Server kelima dan keenam - python backends di buruh pelabuhan
- Semuanya sama pada lingkungan dev, kecuali untuk beberapa konfigurasi server
Kami akan membuat hierarki kami secara berurutan dan kami akan mulai dengan file proyek.
Proyek
Buat proyek file projects/kicker.yaml . Kami memasukkan apa yang umum untuk semua server: kami membutuhkan beberapa repositori dan folder untuk penyebaran, serta pengguna yang menyebarkan sendiri.
--- classes: - apt::debian::semrush files: "/srv/data": ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0755' '/srv/data/shared_temp': ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0775' user_management::present: - deploy
Peran db
Buat file peran untuk server database projects/kicker/db.yaml . Sejauh ini, kami akan lakukan tanpa membagi server menjadi lingkungan:
--- classes: - profiles::db::postgresql profiles::db::postgresql::globals: manage_package_repo: true version: '10' profiles::db::postgresql::db_configs: 'listen_addresses': value: '*' profiles::db::postgresql::databases: kicker: {} profiles::db::postgresql::hba_rules: 'local connect to kicker': type: 'local' database: 'kicker' user: 'kicker' auth_method: 'md5' order: '001' 'allow connect from 192.168.1.100': type: 'host' database: 'kicker' user: 'kicker' auth_method: 'md5' address: '192.168.1.100/32' order: '002'
Di sini kami menghubungkan satu profil yang ditulis untuk penggunaan umum oleh semua orang yang ingin menginstal postgres di server mereka. Profil ini dapat dikonfigurasi dan memungkinkan Anda untuk mengkonfigurasi modul secara fleksibel sebelum menerapkannya.
Untuk yang paling ingin tahu, di bawah kode cat untuk profil ini:
Profile :: db :: postgresql class profiles::db::postgresql ( Hash $globals = {}, Hash $params = {}, Hash $recovery = {}, Hash[String, Hash[String, Variant[String, Boolean, Integer]]] $roles = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $db_configs = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $databases = {}, Hash[String, String] $db_grants = {}, Hash[String, Hash[String, String]] $extensions = {}, Hash[String, String] $table_grants = {}, Hash[String, Hash[String, String]] $hba_rules = {}, Hash[String, String] $indent_rules = {}, Optional[String] $role = undef, # 'master', 'slave' Optional[String] $master_host = undef, Optional[String] $replication_password = undef, Integer $master_port = 5432, String $replication_user = 'repl', String $trigger_file = '/tmp/pg_trigger.file', ){ case $role { 'slave': { $_params = { manage_recovery_conf => true, } if $globals['datadir'] { file { "${globals['datadir']}/recovery.done": ensure => absent, } } $_recovery = { 'recovery config' => { standby_mode => 'on', primary_conninfo => "host=${master_host} port=${master_port} user=${replication_user} password=${replication_password}", trigger_file => $trigger_file, } } $_conf = { 'hot_standby' => { value => 'on', }, } file { $trigger_file: ensure => absent, } } 'master': { $_conf = { 'wal_level' => { value => 'replica', }, 'max_wal_senders' => { value => 5, }, 'wal_keep_segments' => { value => 32, }, } file { $trigger_file: ensure => present, } } default: { $_params = {} $_recovery = {} $_conf = {} } } class { '::postgresql::globals': * => $globals, } class { '::postgresql::server': * => deep_merge($_params, $params), } create_resources('::postgresql::server::config_entry', deep_merge($_conf, $db_configs)) create_resources('::postgresql::server::role', $roles) create_resources('::postgresql::server::database', $databases) create_resources('::postgresql::server::database_grant', $db_grants) create_resources('::postgresql::server::extension', $extensions) create_resources('::postgresql::server::table_grant', $table_grants) create_resources('::postgresql::server::pg_hba_rule', $hba_rules) create_resources('::postgresql::server::pg_indent_rule', $indent_rules) create_resources('::postgresql::server::recovery', deep_merge($_recovery, $recovery)) }
Jadi, kita menginstal Postgresql 10 satu gerakan, mengkonfigurasi konfigurasi ( listen ), membuat database kicker , dan juga menulis dua aturan untuk akses ke database ini di pg_hba.conf . Keren!
Peran frontend
Kami mengambil frontend . Buat file projects/kicker/frontend.yaml dengan konten berikut:
--- classes: - profiles::webserver::nginx profiles::webserver::nginx::servers: 'kicker.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker.semrush.com' proxy: 'http://kicker-backend.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'
Semuanya sederhana di sini. Kami menghubungkan profiles::webserver::nginx profil profiles::webserver::nginx , yang menyiapkan entri ke modul nginx, dan juga menentukan variabel, khususnya server dan location untuk situs ini.
Pembaca yang penuh perhatian akan melihat bahwa akan lebih tepat untuk menempatkan deskripsi situs yang lebih tinggi dalam hierarki, karena kita masih akan memiliki lingkungan dev, dan variabel lain ( server_name , proxy ) akan digunakan di sana, tetapi ini tidak terlalu penting. Menggambarkan peran dengan cara ini, kita dapat melihat bagaimana variabel-variabel ini didefinisikan ulang hanya oleh hierarki.
Peran buruh pelabuhan
Peran projects/kicker/docker.yaml docker projects/kicker/docker.yaml :
--- classes: - profiles::docker profiles::docker::params: version: '17.05.0~ce-0~debian-stretch' packages: 'python3-pip': provider: apt 'Fabric3': provider: pip3 ensure: 1.12.post1 user_management::users: deploy: groups: - docker
profiles/docker.pp sangat sederhana dan elegan. Saya akan memberikan kode:
Profil :: buruh pelabuhan class profiles::docker ( Hash $params = {}, Boolean $install_kernel = false, ){ class { 'docker': * => $params, } if ($install_kernel) { include profiles::docker::kernel } }
Semuanya sudah siap. Ini sudah cukup untuk menyebarkan produk yang kita butuhkan di banyak server, cukup menugaskan mereka proyek dan peran tertentu (misalnya, meletakkan file dalam format yang diinginkan di direktori facts.d, lokasi yang tergantung pada metode pemasangan boneka).
Sekarang kita memiliki struktur file berikut:
. ├── kicker │ ├── db.yaml │ ├── docker.yaml │ └── frontend.yaml └── kicker.yaml 1 directory, 4 files
Sekarang kita akan berurusan dengan lingkungan dan definisi konfigurasi yang unik untuk peran di situs tertentu.
Lingkungan dan penggantian
Mari kita buat konfigurasi umum untuk semua penjualan. File projects/kicker/tiers/prod.yaml berisi indikasi bahwa kita perlu menghubungkan kelas dengan firewall ke lingkungan ini (well, prod all all same), serta kelas tertentu yang memberikan peningkatan tingkat keamanan:
Untuk lingkungan dev, jika kita perlu menjelaskan sesuatu yang spesifik, file yang sama dibuat dan konfigurasi yang diperlukan dimasukkan ke dalamnya.
Selanjutnya, Anda masih perlu mendefinisikan ulang variabel untuk konfigurasi nginx dari peran frontend di lingkungan dev. Untuk melakukan ini, Anda perlu membuat projects/kicker/tiers/dev/frontend.yaml file projects/kicker/tiers/dev/frontend.yaml . Perhatikan hierarki level baru.
--- profiles::webserver::nginx::servers: 'kicker-dev.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker-dev.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker-dev.semrush.com' proxy: 'http://kicker-backend-dev.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker-dev.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'
Anda tidak perlu lagi menentukan kelas, itu diwarisi dari tingkat hierarki sebelumnya. Di sini kami telah mengubah proxy_pass dan proxy_pass . Server yang memiliki peran fakta = frontend dan tier = dev pertama-tama akan menemukan file projects/kicker/frontend.yaml untuk dirinya sendiri, tetapi kemudian variabel dari file ini akan ditimpa oleh file projects/kicker/tiers/dev/frontend.yaml dengan prioritas yang lebih tinggi .
Bersembunyi kata sandi untuk PostgreSQL
Jadi kami memiliki item terakhir dalam agenda - setel kata sandi untuk PostgreSQL.
Kata sandi harus bervariasi di lingkungan. Kami akan menggunakan eyaml untuk menyimpan kata sandi dengan aman. Buat kata sandi:
eyaml encrypt -s 'verysecretpassword' eyaml encrypt -s 'testpassword'
Kami menempelkan baris yang dihasilkan ke file **projects/kicker/tiers/prod/db.yaml** dan **projects/kicker/tiers/dev/db.yaml** (atau Anda dapat menggunakan ekstensi eyaml, ini dapat disesuaikan), masing-masing. Berikut ini sebuah contoh:
--- profiles::db::postgresql::roles: 'kicker': password_hash: > 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAsdpb2P0axUJzyWr2duRKAjh0WooGYUmoQ5gw0nO9Ym5ftv6uZXv25DRMKh7vsbzrrOR5/lLesx/pAVmcs2qbhd/y0Vr1oc2ohHlZBBKtCSEYwem5VN+kTMhWPvlt93x/S9ERoBp8LrrsIvicSYZByNfpS2DXCFbogSXCfEPxTTmCOtlOnxdjidIc9Q1vfAXv7FRQanYIspr2UytScm56H/ueeAc/8RYK51/nXDMtdPOiAP5VARioUKyTDSk8FqNvdUZRqA3cl+hA+xD5PiBHn5T09pnH8HyE/39q09gE0pXRe5+mOnU/4qfqFPc/EvAgAq5mVawlCR6c/cCKln5wJTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDNKijGHBLPCth0sfwAjfl/gBAaPsfvzZQ/Umgjy1n+im0s]'
Selanjutnya, kata sandi untuk peran kicker akan datang, didekripsi dan diterapkan pada server database di PostgreSQL.
Faktanya, itu saja. Ya, contohnya ternyata sangat besar, tapi, saya harap, fungsional, tidak meninggalkan pertanyaan, jelas dan bermanfaat. Hierarki yang dihasilkan dalam hiera adalah ini:
. ├── db.yaml ├── docker.yaml ├── frontend.yaml └── tiers ├── dev │ ├── db.yaml │ └── frontend.yaml ├── prod │ └── db.yaml └── prod.yaml 3 directories, 7 files
Anda dapat menonton file-file ini secara langsung dengan mengkloning repositori yang dibuat khusus
Kesimpulan
Wayang bagus dan mudah digunakan dengan hiera. Saya tidak akan menyebutnya sebagai alat konfigurasi yang ideal di dunia modern, tidak sama sekali, tetapi layak mendapat perhatian. Dia mengatasi beberapa tugas dengan sangat baik, dan "filosofi" mempertahankan kondisi sumber daya dan konfigurasi yang selalu identik dapat memainkan peran penting dalam memastikan keamanan dan keseragaman konfigurasi.
Dunia modern secara bertahap bersinergi dan berkembang. Hanya sedikit orang yang sekarang hanya menggunakan satu sistem konfigurasi, sering kali di gudang para devops dan admin ada beberapa sistem sekaligus. Dan ini bagus, karena ada banyak pilihan. Hal utama adalah bahwa semuanya harus logis dan dapat dimengerti, bagaimana dan di mana itu dapat dikonfigurasi.
Akibatnya, tujuan kami sebagai administrator adalah mengkonfigurasi sendiri tidak ada. Semua ini idealnya dilakukan oleh tim sendiri. Dan kita harus memberi mereka alat atau produk yang memungkinkan kita melakukan ini dengan aman, mudah, dan yang paling penting, dengan hasil yang akurat. Nah, dan bantu selesaikan masalah arsitektural dan yang lebih serius daripada "Anda harus menginstal PostgreSQL di server dan membuat pengguna." Camon, 2018 ada di halaman! Jadi melempar boneka dan memungkinkan dan pindah ke masa depan tanpa server.
Dengan pengembangan cloud, containerisasi, dan sistem orkestrasi kontainer, sistem manajemen konfigurasi perlahan-lahan surut ke latar belakang untuk pengguna dan pelanggan. Anda juga dapat menaikkan sekelompok gagal-wadah yang aman di cloud dan menyimpan aplikasi Anda dalam wadah dengan skelling otomatis, cadangan, replikasi, penemuan otomatis, dll., Tanpa menulis satu baris pun untuk boneka, boneka, koki dll. Anda tidak perlu mengurus apa pun (well, hampir). Di sisi lain, ada lebih sedikit server besi karena awan. Hanya saja Anda tidak perlu lagi mengonfigurasinya, tindakan ini adalah tanggung jawab penyedia cloud. Tetapi mereka tidak mungkin menggunakan sistem yang sama dengan manusia biasa.
Kredit
Terima kasih:
- Dmitry Tupitsin, Dmitry Loginov, Stepan Fedorov dan seluruh tim administrator sistem atas bantuan mereka dalam mempersiapkan artikel ini
- Vladimir Legkostupov untuk gambar
- Yana Tabakova untuk mengatur semua ini dan membantu untuk melewati semua tahap pra-penerbitan
- Nikita Zakharov untuk bantuan dalam masalah perizinan