Pertama, sedikit teori. Apa yang terjadi ?
Sederhananya, dokumen ini dirancang untuk menyederhanakan pengembangan aplikasi SaaS, membantu dengan menginformasikan pengembang dan insinyur DevOps tentang masalah dan praktik yang paling sering ditemui dalam pengembangan aplikasi modern.
Dokumen tersebut dibuat oleh pengembang platform Heroku.
Aplikasi Dua Belas Faktor dapat diterapkan pada aplikasi yang ditulis dalam bahasa pemrograman apa pun dan menggunakan kombinasi layanan pendukung apa pun (database, antrian pesan, cache, dll.).
Secara singkat tentang faktor-faktor yang mendasari metodologi ini:
- Basis kode β Satu basis kode dilacak dalam kontrol versi β beberapa penerapan
- Ketergantungan β Deklarasikan dan isolasi dependensi secara eksplisit
- Konfigurasi β Simpan konfigurasi saat runtime
- Layanan Pendukung β Pertimbangkan layanan pendukung sebagai sumber daya plug-in
- Bangun, lepaskan, jalankan β Pisahkan secara ketat tahap perakitan dan pelaksanaan
- ΠΡΠΎΡΠ΅ΡΡΡ β Jalankan aplikasi sebagai satu atau lebih proses tanpa kewarganegaraan
- Pengikatan pelabuhan β Ekspor layanan melalui pengikatan port
- Konkurensi β Skalakan aplikasi Anda menggunakan proses
- Sekali pakai β Maksimalkan keandalan dengan pengaktifan cepat dan pematian bersih
- Keseimbangan pengembangan/operasi aplikasi β Jaga agar lingkungan pengembangan, pementasan, dan produksi Anda semirip mungkin
- Pencatatan β Lihat log sebagai aliran peristiwa
- Tugas administrasi β Melakukan tugas administrasi/manajemen menggunakan proses ad hoc
Anda dapat memperoleh informasi lebih lanjut tentang 12 faktor tersebut dari sumber berikut:
- - harus dibaca
- β terjemahan resmi
- - pandangan baru pada 12 faktor dengan tujuan memperbaikinya.
Apa yang dimaksud dengan penerapan Biru-Hijau?
Penyebaran Biru-Hijau adalah metode penyampaian aplikasi produksi sedemikian rupa sehingga klien akhir tidak melihat perubahan apa pun di pihaknya. Dengan kata lain, menyebarkan aplikasi dengan nol penghentian.
Skema BG Deploy klasik terlihat seperti yang ditunjukkan pada gambar di bawah.
- Pada awalnya ada 2 server fisik dengan kode, aplikasi, proyek yang sama persis, dan ada router (penyeimbang).
- Router awalnya mengarahkan semua permintaan ke salah satu server (hijau).
- Saat Anda perlu merilisnya lagi, seluruh proyek diperbarui di server lain (biru), yang saat ini tidak memproses permintaan apa pun.
- Setelah kode aktif biru server sepenuhnya diperbarui, router diberi perintah untuk beralih hijau pada biru server.
- Sekarang semua klien melihat hasil dari kode yang dijalankan biru server.
- Untuk beberapa waktu, hijau server berfungsi sebagai salinan cadangan jika penerapan tidak berhasil biru server dan jika terjadi kegagalan dan bug, router mengalihkan aliran pengguna kembali ke hijau server dengan versi stabil lama, dan kode baru dikirim untuk revisi dan pengujian.
- Dan di akhir proses, itu diperbarui dengan cara yang sama hijau server. Dan setelah memperbaruinya, router mengalihkan aliran permintaan kembali ke hijau server.
Semuanya terlihat sangat bagus dan pada pandangan pertama seharusnya tidak ada masalah dengan itu.
Namun karena kita hidup di dunia modern, opsi peralihan fisik seperti yang ditunjukkan dalam skema klasik tidak cocok untuk kita. Catat informasinya untuk saat ini, kami akan kembali lagi nanti.
Nasihat yang buruk dan bagus
Penolakan tanggung jawab: Contoh di bawah ini menunjukkan utilitas/metodologi yang saya gunakan, Anda benar-benar dapat menggunakan alternatif apa pun dengan fungsi serupa.
Sebagian besar contoh dalam satu atau lain cara akan bersinggungan dengan pengembangan web (ini mengejutkan), dengan PHP dan Docker.
Paragraf di bawah ini memberikan deskripsi praktis sederhana tentang penggunaan faktor dengan menggunakan contoh spesifik; jika Anda ingin mendapatkan lebih banyak teori tentang topik ini, ikuti tautan di atas ke sumber aslinya.
1. Basis Kode
Gunakan FTP dan FileZilla untuk mengunggah file ke server satu per satu, jangan simpan kode di mana pun selain di server produksi.
Proyek harus selalu memiliki basis kode tunggal, artinya semua kode berasal dari satu basis kode pergi gudang. Server (produksi, pementasan, test1, test2...) menggunakan kode dari cabang satu repositori umum. Dengan cara ini kami mencapai konsistensi kode.
2. Ketergantungan
Unduh semua perpustakaan di folder langsung ke root proyek. Lakukan pembaruan hanya dengan mentransfer kode baru ke folder dengan versi perpustakaan saat ini. Instal semua utilitas yang diperlukan langsung di server host tempat 20 layanan lainnya berjalan.
Sebuah proyek harus selalu memiliki daftar dependensi yang dapat dimengerti dengan jelas (yang saya maksud dengan dependensi adalah lingkungan). Semua dependensi harus didefinisikan dan diisolasi secara eksplisit.
Mari kita ambil contoh Menyusun ΠΈ Buruh pelabuhan.
Menyusun β manajer paket yang memungkinkan Anda menginstal perpustakaan di PHP. Komposer memungkinkan Anda menentukan versi secara ketat atau longgar, dan mendefinisikannya secara eksplisit. Mungkin ada 20 proyek berbeda di server dan masing-masing akan memiliki daftar paket dan perpustakaan pribadi yang independen satu sama lain.
Buruh pelabuhan β sebuah utilitas yang memungkinkan Anda menentukan dan mengisolasi lingkungan tempat aplikasi akan dijalankan. Oleh karena itu, sama seperti composer, namun secara lebih menyeluruh, kita dapat menentukan aplikasi mana yang bekerja. Pilih versi PHP tertentu, instal hanya paket yang diperlukan agar proyek dapat berjalan, tanpa menambahkan tambahan apa pun. Dan yang paling penting, tanpa mengganggu paket dan lingkungan mesin host dan proyek lainnya. Artinya, semua proyek di server yang berjalan melalui Docker benar-benar dapat menggunakan kumpulan paket apa pun dan lingkungan yang sama sekali berbeda.
3. Konfigurasi
Simpan konfigurasi sebagai konstanta langsung di dalam kode. Pisahkan konstanta untuk server pengujian, pisahkan untuk produksi. Ikat pengoperasian aplikasi tergantung pada lingkungan secara langsung dalam logika bisnis proyek menggunakan konstruksi if else.
Konfigurasi - ini adalah satu-satunya cara penerapan proyek berbeda. Idealnya, konfigurasi harus diteruskan melalui variabel lingkungan (env vars).
Artinya, meskipun Anda menyimpan beberapa file konfigurasi .config.prod .config.local dan mengganti namanya pada saat penerapan menjadi .config (konfigurasi utama tempat aplikasi membaca data) - ini bukan pendekatan yang tepat, karena dalam hal ini informasi dari konfigurasi akan tersedia untuk umum bagi semua pengembang aplikasi dan data dari server produksi akan dikompromikan. Semua konfigurasi harus disimpan langsung dalam sistem penerapan (CI/CD) dan dibuat untuk lingkungan berbeda dengan nilai berbeda yang diperlukan untuk lingkungan tertentu pada saat penerapan.
4. Layanan Pihak Ketiga
Terikat secara ketat dengan lingkungan, gunakan koneksi berbeda untuk layanan yang sama di lingkungan tertentu.
Faktanya, poin ini sangat tumpang tindih dengan poin tentang konfigurasi, karena tanpa poin ini, data konfigurasi normal tidak dapat dibuat dan, secara umum, kemampuan untuk mengkonfigurasi tidak akan ada artinya.
Semua koneksi ke layanan eksternal, seperti server antrian, database, layanan caching, harus sama baik untuk lingkungan lokal maupun lingkungan pihak ketiga/produksi. Dengan kata lain, kapan saja, dengan mengubah string koneksi, saya dapat mengganti panggilan ke basis #1 dengan basis #2 tanpa mengubah kode aplikasi. Atau, ke depan, misalnya, saat menskalakan layanan, Anda tidak perlu menentukan koneksi dengan cara khusus apa pun untuk server cache tambahan.
5. Bangun, rilis, jalankan
Hanya memiliki versi final kode di server, tanpa ada peluang untuk mengembalikan rilisnya. Tidak perlu mengisi ruang disk. Siapa pun yang berpikir bahwa mereka dapat merilis kode ke dalam produksi dengan kesalahan adalah programmer yang buruk!
Semua tahapan penerapan harus dipisahkan satu sama lain.
Memiliki kesempatan untuk memutar kembali. Buat rilis dengan salinan aplikasi lama (sudah dirakit dan siap digunakan) disimpan dalam akses cepat, sehingga jika terjadi kesalahan, Anda dapat memulihkan versi lama. Artinya, secara kondisional ada foldernya Pers dan map arus, dan setelah penerapan dan perakitan folder berhasil arus ditautkan dengan tautan simbolis ke rilis baru yang ada di dalamnya Pers dengan nama konvensional nomor rilis.
Di sinilah kita mengingat penerapan Biru-Hijau, yang memungkinkan Anda tidak hanya beralih antar kode, tetapi juga beralih di antara semua sumber daya dan bahkan lingkungan dengan kemampuan untuk mengembalikan semuanya.
6. Proses
Menyimpan data status aplikasi langsung di dalam aplikasi itu sendiri. Gunakan sesi di RAM aplikasi itu sendiri. Gunakan sebanyak mungkin berbagi antar layanan pihak ketiga. Mengandalkan fakta bahwa aplikasi hanya dapat memiliki satu proses dan tidak mengizinkan penskalaan.
Mengenai sesi, simpan data hanya dalam cache yang dikontrol oleh layanan pihak ketiga (memcached, redis), jadi meskipun Anda menjalankan 20 proses aplikasi, salah satu dari mereka, setelah mengakses cache, akan dapat terus bekerja dengan klien di keadaan yang sama di mana pengguna sedang bekerja dengan aplikasi dalam proses lain. Dengan pendekatan ini, ternyata tidak peduli berapa banyak salinan layanan pihak ketiga yang Anda gunakan, semuanya akan berfungsi normal dan tanpa masalah dengan akses data.
7. Pengikatan port
Hanya server web yang mengetahui cara bekerja dengan layanan pihak ketiga. Atau lebih baik lagi, instal layanan pihak ketiga langsung di dalam server web. Misalnya saja sebagai modul PHP di Apache.
Semua layanan Anda harus dapat diakses satu sama lain melalui akses ke beberapa alamat dan port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), yaitu dari nginx saya dapat mengakses php-fpm dan ke postgres, dan dari php-fpm ke postgres dan nginx dan sebenarnya dari setiap layanan saya dapat mengakses layanan lain. Dengan cara ini, kelangsungan suatu layanan tidak terikat dengan kelangsungan layanan lain.
8. Paralelisme
Bekerjalah dengan satu proses, jika tidak, beberapa proses tidak akan bisa berjalan bersama!
Berikan ruang untuk penskalaan. Kawanan Docker sangat bagus untuk ini.
Docker Swarm adalah alat untuk membuat dan mengelola cluster container baik antar mesin yang berbeda maupun sekumpulan container pada mesin yang sama.
Dengan menggunakan gerombolan, saya dapat menentukan berapa banyak sumber daya yang akan saya alokasikan untuk setiap proses dan berapa banyak proses dari layanan yang sama yang akan saya luncurkan, dan penyeimbang internal, yang menerima data pada port tertentu, akan secara otomatis mem-proxy-nya ke proses tersebut. Jadi, melihat beban di server meningkat, saya dapat menambahkan lebih banyak proses, sehingga mengurangi beban pada proses tertentu.
9. Sekali pakai
Jangan gunakan antrian untuk bekerja dengan proses dan data. Menghentikan satu proses akan mempengaruhi keseluruhan aplikasi. Jika satu layanan down, semuanya ikut down.
Setiap proses dan layanan dapat dimatikan kapan saja dan hal ini tidak akan mempengaruhi layanan lainnya (tentu saja, ini tidak berarti bahwa layanan tersebut tidak akan tersedia untuk layanan lain, tetapi layanan lain tidak akan mati setelah layanan ini). Semua proses harus dihentikan dengan baik, sehingga ketika dihentikan, tidak ada data yang rusak dan sistem akan bekerja dengan benar saat Anda menyalakannya lagi. Artinya, bahkan jika terjadi penghentian darurat, data tidak boleh rusak (mekanisme transaksi cocok di sini, kueri dalam database hanya berfungsi dalam grup, dan jika setidaknya satu kueri dari grup gagal atau dijalankan dengan kesalahan, maka tidak ada permintaan lain dari grup yang akhirnya gagal).
10. Keseimbangan pengembangan/operasi aplikasi
Produksi, staging, dan versi lokal aplikasi harus berbeda. Dalam produksi kami menggunakan framework Yii Lite, dan Yii secara lokal, sehingga bekerja lebih cepat dalam produksi!
Pada kenyataannya, semua penerapan dan pekerjaan dengan kode harus berada di lingkungan yang hampir sama (kita tidak berbicara tentang perangkat keras fisik). Selain itu, setiap karyawan pengembangan harus dapat menerapkan kode ke produksi jika diperlukan, dan bukan departemen pengembang yang terlatih khusus, yang hanya berkat kekuatan khusus yang dapat mengangkat aplikasi ke dalam produksi.
Docker juga membantu kami dalam hal ini. Jika semua poin sebelumnya dipatuhi, penggunaan buruh pelabuhan akan membawa proses penerapan lingkungan baik pada produksi maupun pada mesin lokal untuk memasukkan satu atau dua perintah.
11. Catatan
Kami menulis log ke file dan database! Kami tidak membersihkan file dan database dari log. Kita beli saja harddisk dengan 9000 Peta bytes dan itu tidak masalah.
Semua log harus dianggap sebagai aliran peristiwa. Aplikasi itu sendiri tidak boleh terlibat dalam pemrosesan log. Log harus dikeluarkan ke stdout atau dikirim melalui protokol seperti udp, sehingga bekerja dengan log tidak menimbulkan masalah apa pun pada aplikasi. greylog bagus untuk ini. Graylog menerima semua log melalui udp (protokol ini tidak perlu menunggu respons tentang keberhasilan penerimaan paket) tidak mengganggu aplikasi dengan cara apa pun dan hanya menangani penataan dan pemrosesan log. Logika aplikasi tidak berubah untuk bekerja dengan pendekatan seperti itu.
12. Tugas administrasi
Untuk memperbarui data, database, dll., gunakan titik akhir yang dibuat secara terpisah di API, menjalankannya 2 kali berturut-turut akan mengakibatkan semuanya terduplikasi. Tapi Anda tidak bodoh, Anda tidak akan mengklik dua kali, dan kami tidak memerlukan migrasi.
Semua tugas administrasi harus dilakukan di lingkungan yang sama dengan semua kode, pada tingkat rilis. Artinya, jika kita perlu mengubah struktur database, maka kita tidak akan melakukannya secara manual dengan mengubah nama kolom dan menambahkan yang baru melalui beberapa alat manajemen database visual. Untuk hal seperti itu, kami membuat skrip terpisah - migrasi, yang dijalankan di mana saja dan di semua lingkungan dengan cara yang sama dengan hasil yang umum dan dapat dimengerti. Untuk semua tugas lainnya, seperti mengisi proyek dengan data, metodologi serupa harus digunakan.
Contoh implementasi di PHP, Laravel, Laradock, Docker-Compose
PS Semua contoh dibuat di MacOS. Kebanyakan dari mereka juga cocok untuk Linux. Pengguna Windows, maafkan saya, tetapi saya sudah lama tidak bekerja dengan Windows.
Mari kita bayangkan situasi di mana kita tidak menginstal versi PHP apa pun di PC kita dan tidak menginstal apa pun.
Instal versi terbaru docker dan docker-compose. (ini dapat ditemukan di Internet)
docker -v &&
docker-compose -v
1. Taruh
git clone https://github.com/Laradock/laradock.git &&
ls
Mengenai Laradock, saya akan mengatakan bahwa ini adalah hal yang sangat keren, yang berisi banyak kontainer dan hal-hal tambahan. Namun saya tidak akan merekomendasikan penggunaan Laradock tanpa modifikasi dalam produksi karena redundansinya. Lebih baik membuat container sendiri berdasarkan contoh di Laradock, ini akan jauh lebih optimal, karena tidak ada yang membutuhkan semua yang ada di sana pada saat yang bersamaan.
2. Konfigurasikan Laradock untuk menjalankan aplikasi kita.
cd laradock &&
cp env-example .env
2.1. Buka direktori habr (folder induk tempat laradock dikloning) di beberapa editor. (Dalam kasus PHPStorm saya)
Pada tahap ini kami hanya memberi nama pada proyek tersebut.
2.2. Luncurkan gambar ruang kerja. (Dalam kasus Anda, pembuatan gambar akan memakan waktu lama)
Ruang Kerja adalah gambar yang disiapkan khusus untuk bekerja dengan kerangka kerja atas nama pengembang.
Kami masuk ke dalam wadah menggunakan
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Menginstal Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Setelah instalasi, kami memeriksa apakah direktori dengan proyek telah dibuat dan mematikan penulisan.
ls
exit
docker-compose down
2.5. Mari kembali ke PHPStorm dan atur jalur yang benar ke aplikasi laravel kita di file .env.
3. Tambahkan semua kode ke Git.
Untuk melakukan ini, kita akan membuat repositori di Github (atau di mana pun). Mari pergi ke direktori habr di terminal dan jalankan kode berikut.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # Π·Π΄Π΅ΡΡ Π±ΡΠ΄Π΅Ρ ΡΡΡΠ»ΠΊΠ° Π½Π° Π²Π°Ρ ΡΠ΅ΠΏΠΎ
git push -u origin master
git status
Mari kita periksa apakah semuanya beres.
Untuk kenyamanan, saya sarankan menggunakan beberapa antarmuka visual untuk Git, dalam kasus saya itu . (ini link referralnya)
4. Ayo luncurkan!
Sebelum memulai, pastikan tidak ada yang hang di port 80 dan 443.
docker-compose up -d nginx php-fpm
Jadi, proyek kami terdiri dari 3 layanan terpisah:
- nginx - server web
- php-fpm - php untuk menerima permintaan dari server web
- ruang kerja - php untuk pengembang
Saat ini kami telah mencapai bahwa kami telah membuat aplikasi yang memenuhi 4 poin dari 12, yaitu:
1. Basis kode β semua kode ada dalam satu repositori (catatan kecil: mungkin benar menambahkan buruh pelabuhan di dalam proyek laravel, tapi ini tidak penting).
2. Ketergantungan - Semua dependensi kami ditulis secara eksplisit di application/composer.json dan di setiap Dockerfile di setiap container.
3. Layanan Pendukung β Masing-masing layanan (php-fom, nignx, workspace) menjalani kehidupannya sendiri dan terhubung dari luar dan ketika bekerja dengan satu layanan, layanan lainnya tidak akan terpengaruh.
4. ΠΡΠΎΡΠ΅ΡΡΡ β setiap layanan adalah satu proses. Masing-masing layanan tidak mempertahankan status internal.
5. Pengikatan pelabuhan
docker ps
Seperti yang bisa kita lihat, setiap layanan berjalan pada portnya sendiri dan dapat diakses oleh semua layanan lainnya.
6. Konkurensi
Docker memungkinkan kita untuk menelurkan beberapa proses dari layanan yang sama dengan penyeimbangan beban otomatis di antara keduanya.
Mari kita hentikan kontainer dan jalankan melalui bendera --skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Seperti yang bisa kita lihat, salinan container php-fpm telah dibuat. Kami tidak perlu mengubah apa pun saat bekerja dengan container ini. Kami juga terus mengaksesnya di port 9000, dan Docker mengatur beban antar container untuk kami.
7. Sekali pakai - setiap kontainer dapat dibunuh tanpa merugikan yang lain. Menghentikan atau memulai ulang penampung tidak akan memengaruhi pengoperasian aplikasi selama peluncuran berikutnya. Setiap kontainer juga bisa diangkat kapan saja.
8. Keseimbangan pengembangan/operasi aplikasi - semua lingkungan kita sama. Dengan menjalankan sistem pada server dalam produksi, Anda tidak perlu mengubah apa pun dalam perintah Anda. Semuanya akan didasarkan pada Docker dengan cara yang sama.
9. Pencatatan β semua log dalam kontainer ini masuk ke streaming dan terlihat di konsol Docker. (dalam hal ini, sebenarnya, dengan wadah buatan sendiri lainnya, hal ini mungkin tidak akan terjadi jika Anda tidak merawatnya)
docker-compose logs -f
Namun ada kendala bahwa nilai Default di PHP dan Nginx juga menulis log ke file. Untuk memenuhi ke 12 faktor tersebut maka diperlukan nonaktifkan menulis log ke file dalam konfigurasi setiap wadah secara terpisah.
Docker juga menyediakan kemampuan untuk mengirim log tidak hanya ke stdout, tetapi juga ke hal-hal seperti greylog, yang saya sebutkan di atas. Dan di dalam greylog, kita dapat mengoperasikan log sesuka kita dan aplikasi kita tidak akan menyadarinya dengan cara apa pun.
10. Tugas administrasi β semua tugas administrasi diselesaikan oleh laravel berkat alat pengrajin persis seperti yang diinginkan pembuat aplikasi 12 faktor.
Sebagai contoh, saya akan menunjukkan bagaimana beberapa perintah dijalankan.
Kami masuk ke dalam wadah.
docker-compose exec workspace bash
php artisan list
Sekarang kita bisa menggunakan perintah apa pun. (harap dicatat bahwa kami tidak mengkonfigurasi database dan cache, jadi setengah dari perintah tidak akan dijalankan dengan benar, karena dirancang untuk bekerja dengan cache dan database).
11. Konfigurasi dan 12. Bangun, lepaskan, jalankan
Saya ingin mendedikasikan bagian ini untuk Penerapan Biru-Hijau, namun ternyata terlalu luas untuk artikel ini. Saya akan menulis artikel terpisah tentang ini.
Singkatnya, konsep ini didasarkan pada sistem CI/CD seperti Jenkins ΠΈ Gitlab CI. Di keduanya, Anda dapat mengatur variabel lingkungan yang terkait dengan lingkungan tertentu. Oleh karena itu, dalam situasi ini, poin c akan terpenuhi Konfigurasi.
Dan intinya tentang Bangun, lepaskan, jalankan diselesaikan dengan fungsi bawaan dengan nama Pipa saluran.
Pipa saluran memungkinkan Anda membagi proses penerapan menjadi banyak tahapan, menyoroti tahapan perakitan, rilis, dan eksekusi. Juga di Pipeline, Anda dapat membuat cadangan, dan apa saja. Ini adalah alat dengan potensi yang tidak terbatas.
Kode aplikasinya ada di .
Jangan lupa untuk menginisialisasi submodul saat mengkloning repositori ini.
PS: Semua pendekatan ini dapat digunakan dengan utilitas dan bahasa pemrograman lainnya. Yang penting esensinya tidak berbeda.
Sumber: www.habr.com