KAL
Menu

Release dengan rebar3

Release OTP dengan rebar3: sistem target dan skrip boot.

Daftar isi

Topik ini mengemas seluruh jalur menjadi satu artefak yang bisa dijalankan di mesin tanpa alat pengembangan: release OTP yang dibangun rebar3, isinya, skrip boot yang menyusun urutan hidupnya, dan cara menjalankannya pada sistem target. Semua keluaran berasal dari build nyata pada OTP 29.

Mengapa release#

Menjalankan aplikasi dengan erl -pa folder/ebin meminta mesin target memenuhi banyak syarat: Erlang terpasang, kode path benar, dependensi terpasang, dan konfigurasi disetel manual. Release menutup seluruh celah itu dengan mengemas aplikasi, dependensi, bahkan ERTS itu sendiri ke dalam satu folder yang mandiri. Hasilnya adalah sistem target, yaitu folder yang dapat disalin ke mesin lain dan dijalankan tanpa menginstal apa pun, dengan urutan hidup yang telah diputuskan saat build.

Konfigurasi dan pembangunan#

Proyek rebar3 menambahkan bagian relx pada rebar.config untuk menyatakan release-nya:

erlang Bagian relx pada rebar.config 
{relx, [{release, {layanan_tiket, "0.1.0"}, [layanan_tiket]},
        {dev_mode, false},
        {include_erts, true}]}.

Kunci release menamai artefak, menetapkan versinya, dan mendaftar aplikasi yang ikut. dev_mode dengan nilai false menyalin berkas sungguhan alih-alih membuat tautan ke folder build, dan include_erts dengan true mengemas ERTS sehingga target tidak perlu memasang Erlang. Perintah rebar3 release merakit semuanya:

text Keluaran build release 
===> Analyzing applications...
===> Compiling layanan_tiket
===> Assembling release layanan_tiket-0.1.0...
===> Warnings generating release:
*WARNING* Missing application sasl. Can not upgrade with this release
===> Release successfully assembled: _build/default/rel/layanan_tiket

Peringatan sasl layak dibaca: tanpa aplikasi sasl, mekanisme pembaruan release dari hot code upgrade tidak tersedia, dan jalur ini sengaja tidak memasukkannya karena upgrade hot code adalah operasi yang hanya dijalankan bila memang dibutuhkan. Hasil build berada di _build/default/rel/layanan_tiket:

text Isi folder bin dan releases 
bin/  : install_upgrade.escript, layanan_tiket, layanan_tiket-0.1.0,
        no_dot_erlang.boot, nodetool
releases/0.1.0/  : layanan_tiket.rel, no_dot_erlang.boot, start.boot,
        start.script, start_clean.boot, sys.config

Skrip bin/layanan_tiket adalah pintu masuknya, dan folder releases/0.1.0/ menyimpan urutan hidupnya dalam bentuk berkas boot.

Skrip boot dan sistem target#

Berkas start.boot adalah skrip boot: daftar terurut aplikasi yang dimuat dan dimulai saat VM hidup, dibaca dalam mode embedded sehingga tidak ada pemuatan kode dari folder lib secara bebas. Berkas sys.config membawa konfigurasi aplikasi yang dibahas pada topik Application, sedangkan vm.args menyatakan argumen VM seperti nama node dan cookie. Menjalankan konsolnya memperlihatkan hasil akhirnya:

text Konsol release yang berjalan 
Erlang/OTP 29 [erts-17.1.1] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]
Eshell V17.1.1 (press Ctrl+G to abort, type help(). for help)
(layanan_tiket@c-6ae9b560-14127d0f-ff7b7b884eca)1> aplikasi: [{layanan_tiket,"An OTP library","0.1.0"},
           {stdlib,"ERTS  CXC 138 10","8.1.1"},
           {kernel,"ERTS  CXC 138 10","11.0.4"}]

VM dari release menyatakan namanya sendiri, yaitu layanan_tiket@host, dan seluruh aplikasi yang dinyatakan pada relx sudah hidup saat prompt terbuka. Folder yang sama dapat disalin ke mesin target dan dijalankan dengan skrip yang sama, dengan perintah bawaannya seperti foreground untuk mode layanan, console untuk sesi interaktif, dan pid atau stop untuk pengelolaannya. Untuk pembaruan antar versi, folder releases/ menampung beberapa versi boot dan berkas relup yang menuntaskan alur upgrade yang diperkenalkan pada topik hot code upgrade.

Perintah pengelolaan dan alur upgrade#

Skrip bin/layanan_tiket adalah antarmuka operasi harian: foreground menjalankan node sebagai layanan latar depan yang cocok dikelola sistem operasi atau kontainer, background melepaskannya ke latar belakang, pid dan stop mengelola hidup-matinya, sedangkan remote membuka shell ke node yang sudah berjalan. Seluruhnya bekerja tanpa alat pengembangan karena ERTS ikut dikemas.

Untuk pembaruan antar versi, jalur lengkapnya adalah membuat release versi kedua, menyusun berkas relup yang berisi urutan instruksi pergantian dari appup, lalu memasangnya lewat release_handler pada node yang berjalan. Rangkaian itu menuntut aplikasi sasl ikut dikemas, sebagaimana diperingatkan keluaran build di atas, dan inilah alasan pembaruan bergulir antar node menjadi pilihan yang lebih umum ketika pembaruan tanpa henti bukan kebutuhan mutlak.

Keputusan include_erts sendiri adalah keputusan operasi. Nilai true mengemas ERTS dari mesin build sehingga target tidak membutuhkan apa pun, dengan konsekuensi folder yang lebih besar dan kewajiban membangun di mesin yang arsitektur serta sistem operasinya sama dengan target. Nilai false membuat release bergantung pada instalasi Erlang di mesin target, lebih ringan untuk dikirim, dan tepat pada armada yang sudah seragam. Opsi {extended_start_script, true} menambah perintah pengelolaan yang lebih kaya pada skrip bin, dan keduanya bersama dev_mode membentuk tiga saklar yang menentukan bentuk artefak akhir lebih dari pengaturan apa pun yang lain.

Ringkasan#

  • Release mengemas aplikasi, dependensi, dan ERTS menjadi folder mandiri yang dijalankan tanpa instalasi Erlang.
  • Bagian relx pada rebar.config menyatakan nama, versi, isi, dan pilihan dev_mode serta include_erts.
  • Skrip boot start.boot menyatakan urutan aplikasi yang dimuat dalam mode embedded, bersama sys.config dan vm.args.
  • Skrip bin aplikasi menyediakan foreground, console, dan perintah pengelolaan, serta pangkalan untuk alur upgrade release.

Referensi#