~~Goal saya sebenarnya cuma mau buat test keyboard baru dengan cara buat artikel~~ Ah, ini buat sharing saja, target yang ngebaca ini utamanya fresh graduate yang backgroundnya IT dan lagi ngga ngapa-ngapain, bisa dicoba saja praktekkan apa yang ada di thread ini di laptop masing-masing. Ngga menjamin tulisan ini bakalan fun dan ngga bisa janji saya bantu kalau ada kendala, tapi bebas silakan ditanyakan kalau ada minat ke topik ini.
Apa yang ditulis di sini cocoknya lebih ke manajemen infra suatu perusahaan (bukan bagian pasang2 kabel), tapi bagus untuk diketahui karena ada kemungkinan besar konsep ini bakalan nempel ke kerjaan software engineer lain terutama yang menyentuh backend. Kalau di data engineering perusahaan saya, mengetahui konsep yang ditulis di ini itu juga salah satu yang di-list di onboarding (semacam guideline pengenalan) karyawan baru. Saya perhatikan juga sepertinya banyak fresh graduate nongkrong di /indonesia dengan segala anxietynya. Asumsi saya, at least kalau udah di sini artinya udah punya pengetahuan cara make DoH atau VPN, punya kemampuan komprehensif untuk membaca guideline teknikal dan mengikutinya.
Isi artikel ini akan ditulis dalam Bahasa Indonesia, because creating English guideline about general thing in /indonesia doesn't sound right for me. Dan karena saya sempat lama bekerja di perusahaan logat Jaksel, mohon maaf kalau logat saya campur2 aneh.
Guide ini saat ditulis maunya beginner friendly jadi mungkin pemakaian katanya kurang akurat. Mostly serious, a bit joking here and there. Mohon maaf kalau tidak berkenan.
Di bagian paling bawah post ini saya taruh notes. Kalau ketemu {noteX} scroll ke paling bawah saja.

VM / virtualization, sama contoh kasus

Yang baru kenal biasanya menghubung2kan VM dengan dual-boot. Tapi hal ini cuma relevan kalau kita bicara bagaimana menjalankan dua OS berbeda dalam satu komputer yang sama. Dua konsep tsb benar2 beda btw. Yang sama cuma perasaan gengsi bisa jalanin dua OS berbeda di laptop yang sama + kalau VM, rasa "aduh imut" yang dirasakan ketika melihat OS lain berjalan di dalam satu window kecil non-fullscreen. ~~Ngga salah. Gengsi melakukan ini itu oke dan harus buat pemula.~~
Definisi formal VM/virtualization udah banyak kalau dicari di Google. Semua definisi kurang lebih sama: ini adalah satu cara untuk pengisolasian aplikasi ("running in a dedicated machine"), cara untuk menjalankan aplikasi yang hanya bisa berjalan mulus di lingkungan tertentu, atau cara membagi pemakaian satu mesin yang mempunyai resource (CPU/mem/disk) yang besar. Virtualization nyentuhnya sampai level hardware, yaitu OS yang ada di VMnya dikecoh bahwa memang ada hardware beneran di VM tsb padahal cuma virtual hardware.
Mainan VM ini dulu saya pake buat jalanin file exe yang saya download dari internet untuk cek itu file iseng apa bukan. Sekarang, VM-VMan ini saya pakai untuk kerjaan, utamanya untuk testing kodingan di platform (OS) berbeda. Selama ini kasusnya cuma Linux vs Windows, belum ketemu Linux vs Linux.
Contoh satu kasus, saya punya library Python yang saya develop untuk dijalankan di Debian-based OS (Debian atau Ubuntu). Kodingannya ngga gitu wah banget, bayangin cuma untuk menyederhanakan pengerjaan data analysis mengambil data database production{note1} baik yang tipenya MySQL, PostgreSQL, MongoDB, kemudian diolah (filter, agregat, dsb) dan disimpan ke Google Sheet. Pengen saya share tentang ini, projectnya lumayan fun jika bicara secara personal.
Install library ini cukup sederhana kalau di Debian/Ubuntu, tinggal "git clone" (ngga dimasukin ke PyPI lah, internal), terus jalanin "pip install -e reposaya" dijamin udah langsung bisa dipake (S&K berlaku: installnya di Python 3.7). Gampang kan? Nah... suatu hari datanglah 3rd party vendor yang mau memakai Python library ini supaya bisa satu tools dengan tim perusahaan kita. Kendalanya, mereka ini pakai Windows. Tim perusahaan kita mau ada guideline install Python library ini di laptop vendor.
Mintalah tim tsb ke saya. Sambil saya mengeluh dalam hati "Alamak, Windows?"... requirement dari tim perusahaan, guideline ini harus ilustratif install apa aja dan menjalankan command apa aja sampe librarynya bisa dipakai.
Saya follow guideline hasil Google search dan saya pakai VirtualBox + Windows 10 ISO di Ubuntu 20. Karena Windows 10 bisa jalan tanpa masukin activation key, ya udah ngga pake activation. Sudah selesai setup OS, install Miniconda (basically Anaconda, tapi lightweight) di dalam VMnya dan wah, library Python internal ini bisa bekerja. Intinya udah jadi guidenya setelah eksplorasi 2 hari penuh.
Untuk pembaca thread ini yang berminat, kalau mau mulai belajar, ambil installer ISO file yang official untuk OS pilihannya. Anda bisa coba Windows atau Ubuntu.
Terus coba install VMWare/VirtualBox. Saya pertama kali mengenal VM-VMan ini pakai VMWare di Windows, tapi sekarang lebih prefer pakai VirtualBox.
Setelah semuanya ready, coba buat VM di VMWare/VirtualBox menggunakan ISO file yang tadi didownload. Kalau di VirtualBox, pengalaman hanya tinggal New, ketik nama VM + set tipenya Windows 10 64-bit, kemudian sisanya default settings saja, terus saat VMnya dinyalakan dia akan keluar prompt minta ISO file. Nah kalau sudah sampai installation, input saja informasi yang diperlukan sama installernya termasuk pembuatan akun. Semua proses ini (untuk install Windows 10 di VM) memerlukan kira-kira 30 menit sampai 1 jam.
Test tadi pakai VirtualBox, tapi bisa juga pakai VMWare Workstation Player yang sama2 gratis.

Hypervisors

Software VMWare, VirtualBox yang dibahas sebelumnya tergolong satu keluarga software yang dinamakan "hypervisor".
Di level enterprise, hypervisor ini lebih luas pemakaiannya dari yang tadi digunakan dari laptop Anda di contoh sebelumnya.
Bayangkan perusahaan punya satu server fisik{note2} yang kekuatannya 8x laptop yang Anda pakai sekarang -- 32 CPU cores, 256 GB RAM {note3}{note4}.
Satu mesin ini umumnya dipakai sharing antar tim satu perusahaan, nah terlalu banyak service di satu node akan repot. Saat situasi heavy load, misal perusahaan ada kegiatan bagi-bagi voucher di aplikasi + buka event gacha karakter populer ke user-usernya (istilahnya "userbase"), dan service-service{note5} di node itu diperkirakan akan kerja keras.
Kalau dari sisi resources, jadinya nanti semua service di satu node itu akan berlomba-lomba siapa yang bisa mengambil 100% resource CPU/memory node tsb lebih dulu.
Kalau dari sisi networking, IP address cuma satu, terpaksa kalau service baru buatan tim lain harus bagi-bagi TCP port yang belum dipakai di node tsb. Berhubung TCP ports ngga punya banyak nomor cantik (1024-65536), bakalan ada beban ingatan buat developer untuk mengingat port mana digunakan service apa.
Banyak Linux distro juga punya keterbatasan yang namanya maximum open file, di mana satu OS harus bisa keep track file-file mana saja yang digunakan process yang sedang berjalan + network socket yang sedang dibuka https://unix.stackexchange.com/questions/36841/why-is-number-of-open-files-limited-in-linux. Menurut pengalaman sering kejadian di satu node seperti ini yang dishare banyak tim, beberapa aplikasi crash karena open file limit contohnya di sini (catatan lagi: di Linux, network socket yang dipakai suatu process untuk komunikasi ke luar nodenya juga akan "open" satu atau lebih "file")
Seandainya satu node tsb dibagi-bagi ke beberapa VM, setiap tim diberikan (di-"assign") VM masing-masing dan service mereka berjalan on top of VM, nah meskipun satu node tsb shared dengan banyak tim tapi service-service yang jalan ngga akan bisa makan lebih banyak dari yang sudah dialokasikan -- karena OS dan aplikasinya dikecoh bahwa "kamu hanya punya resource CPU x cores dan y memory".
Selain VirtualBox (sepertinya cuma dipakai level testing lokal cmiiw), VMWware, ada lagi contoh hypervisor yaitu Proxmox. Proxmox ini, kita install sebagai OSnya di bare metal yang kita tuju -- bisa diinstall on top of existing Debian installation tapi kelihatannya advanced banget dan ribet. Kemudian setelah selesai akan ada UI nya di mana kita bisa membuat VM (kegiatan ini biasa disebut "provision") dengan mengalokasikan resource yang sudah ada (jumlah CPU, memory, dan disk space yang mau dipakai).
Proxmox bisa menggabungkan banyak node baremetal jadi satu cluster, dan jadi lebih terorganisir supaya manajemen VM tinggal dari satu node saja instead of harus login ke node-node yang diinstall Proxmox dan manage VM nya dari sana. Cluster ini juga bisa spawn VM lebih berimbang -- misal VM berikutnya akan dispawn di node yang resourcenya lebih lowong. VM di satu node juga bisa dipindah ke node yang lain dalam satu cluster, dalam situasi di mana node tsb harus dimaintenance (contoh, ditambahkan memory). CMIIW kalau ada yang pakai Proxmox di /indonesia.
Btw, OS tempat hypervisor diinstall biasa disebut "Host OS", sedangkan OS di dalam VM-VM yang dispawn oleh hypervisor dinamakan "Guest OS"

VM snapshots

Satu fitur yang umum dipunyai hypervisor itu adalah snapshot. Biasanya yang di-snapshot ini kondisi disknya pada suatu waktu, namun ada hypervisor yang snapshot state VMnya secara keseluruhan (semua data di disk + data di memory + settingan VM). Snapshot ini bisa dianggap suatu bentuk backup tapi perasaan saya snapshot itu lebih dari cuma backup. Kegunaan snapshot ini kalau saya tidak salah itu saat situasi "eh waduh salah/kedelete/ngga bisa uninstall sesuatu" bisa coba restore kondisi disk VM nya ke situasi sebelumnya menggunakan snapshot, jadi ngga perlu reset dan install OSnya dari awal. Membuat snapshot ini biasanya manual, harus usernya sendiri yang pilih.
Seingat saya beberapa hypervisor kalau melakukan snapshot punya syarat, yaitu disk yang disnapshot harus dalam keadaan ngga dipakai (idle).

Shared directories

Fitur lain yang umum di hypervisor itu untuk men-link direktori di Host OS dengan direktori di Guest OS supaya bisa tukar-tukaran file. Tujuannya fitur ini supaya mempersimpel kerjaan dibandingkan kita harus setup network directory manual di kedua OS atau setup FTP server supaya bisa bertukar file via network.
Kalau di VirtualBox, udah ada menunya Devices > Shared Folders di window yang muncul saat VM dinyalakan.

Containers / containerization

Virtualization dirasa ribet karena pemakaian resource untuk hypervisor ngga sedikit, jadinya jatah resource untuk VM-VM yang menjalankan guest OS berkurang diambil hypervisor supaya dia bisa jalan. Ngga bisa dihindari memang. Untuk boot up VM juga kelamaan sampai bisa dipakai.
Maka berikutnya dikembangkanlah konsep containerization.
Anggapan kasar, "container" ini sama tujuannya dengan VM yaitu untuk membuat environment yang terisolasi untuk aplikasi user yang berjalan di dalamnya supaya aplikasi lain yang berjalan di node yang sama ngga kena impact, dan untuk manage resources yang gede dipecah ke yang kecil-kecil. Tapi dibandingkan dengan VM yang membuat guest OSnya hampir dari nol, containerization ini lebih banyak memakai apa yang sudah ada di Host OS yang sedang berjalan. Kalau pembuatan VM itu anggapannya kerja keras mulai dari initialize hardware (dibikin virtual hardware), initialize kernel di dalam VMnya supaya bisa digunakan. Sedangkan kalau containerization itu ngga mau repot, udah ada hardware interface segala macam di Host OSnya dia main pakai saja instead of buat virtual hardware, udah ada kernel di OSnya ya udah dipakai lagi saja sama dia.
Saya ketemu grafik di sini yang menurut saya membandingkan container vs VM lebih mendetail dibandingkan resource lain di internet.
Nah tapi berhubung container itu beda dengan VM di mana ngga ada yang namanya install2an OS dst, ada keterbatasannya. Oleh karena container bergantung pada kernel, system library, dan lain-lain di hostnya (saya juga belum 100% paham), kalau ada perbedaan hal2 ini di platform lain, maka container ngga bisa jalan di platform lain tsb. Pernyataan ini lebih untuk menjawab pertanyaan: Bisa ngga di Ubuntu jalanin Windows container (bukan Windows VM)? Ngga bisa :( untuk kenapanya, bisa baca secara mendetail di sini: https://stackoverflow.com/questions/42158596/can-windows-containers-be-hosted-on-linux

Membuat container

Platform containerization yang populer pada saat tulisan ini dibuat itu Docker. Ada platform lain, tapi personally saya belum pernah pengalaman pakai selain Docker.
Dalam topik containerization, kita mengenal istilah "image". Secara personal saya lihat ini mirip konsep snapshot di VM (tapi ada perbedaan signifikan, dijelaskan di bagian berikutnya). Salah satu perbedaannya, image ini dapat dibuat dari set instruksi yang didefine pembuat imagenya. Bandingkan dengan snapshot VM yang harus ada guest OS yang jalan dulu baru bisa dibuat.
Container sebenarnya adalah image yang di-run. Kalau image saja, itu yang orang sebut sesuatu yang "abstrak". Belum bisa dipakai langsung.
Untuk Docker, kita punya Docker container dan Docker image. Singkatnya, Docker image itu "snapshot" yang dapat dipakai untuk membuat Docker container, dan Docker image ini juga dapat di-import untuk membuat Docker image yang lain. Ini cara yang paling umum dilakukan oleh pengguna Docker, saya yakin 99.99% orang ya kerjaannya import image yang uda jadi terus buat image baru dari situ.
Umumnya, Docker image didownload dari Docker Hub https://hub.docker.com/
Di sana banyak yang official (dibuat perusahaan besar atau komunitas yang well-known) dan banyak juga yang community. Saya pribadi cuma pakai yang official/well-known. Contohnya image yang udah ada Google Cloud SDK di dalamnya jadi ngga perlu install lagi, tinggal authorize. Contoh lain, Docker image dengan Python yang lightweight dan bisa langsung kita install pip package macam2 di dalamnya, tinggal masukin script Python kita dan jalan.
Docker container itu manifestasi nyata dari Docker image, yang bisa mulai dipakai. Di dalam Docker container bisa kita install atau masukin apa2, dan bisa pakai selayaknya itu VM biasa. Btw untuk pemula, selama bertahun-tahun memakai Docker saya ngga pernah ketemu/jalanin Docker container yang punya desktop yang bisa diklik2. Semua container diakses melalui terminal dan mau ngapa2in ya make terminal.

Membuat image

Docker image dibuat dari set instruksi yang disebut "Dockerfile". Dockerfile itu cuma file teks biasa yang umumnya punya nama literally "Dockerfile", dengan contoh isinya seperti ini...
``` FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py ```
Contoh Dockerfile yang lain bisa dilihat di official docs sini: https://docs.docker.com/get-started/part2/#sample-dockerfile, di sana dijabarkan setiap steps ngapain.
Di Docker image, setiap step di Dockerfile (kalau di contoh singkat di atas itu ada 4 step) akan membuat "layer" baru di image tsb. Setiap layer di satu image bergantung pada layer sebelumnya yang telah dibuat.
Contoh, di bawah ini adalah isi Dockerfile yang saya buat di mana saya mengcopy file app.csv dari host saya yang besarnya 1 GB, ke dalam image ubuntu:18.04. Kemudian di step berikutnya saya ZIP file tersebut. Ukuran zip filenya menjadi 500 MB. Kemudian file asli di imagenya saya delete.
``` FROM ubuntu:18.04
COPY app.csv /app/app.csv # besarnya 1 GB
RUN zip /app/app.zip /app/app.csv # besar ZIP filenya 500 MB
RUN rm /app/app.csv ```
Image ubuntu:18.04 yang saya pakai besarnya 99 MB. Setelah step keempat, besar image hasil step 4 dibandingkan dengan image awal (ubuntu:18.04) bertambah 1.5 GB menjadi 1.6 GB.
Kalau mengikuti step-step di atas, berlogika harusnya besar image hanya bertambah 500 MB dan bukan 1.5 GB. Penambahan 1.5 GB ini karena konsep layer di Docker. State pada setiap step akan disimpan. State pada step berikutnya hanya akan menyimpan perubahan yang terjadi (di-append, tidak bisa remove) pada state sebelumnya.
Untuk lebih jelasnya seperti ini, pada akhir step paling awal contoh di atas state imagenya berukuran 99 MB.
akhir step 2 (COPY), imagenya berukuran 1.099 GB. Jadi layer step 2 ukurannya 1 GB.
akhir step 3 (RUN zip), imagenya berukuran 1.599 GB. Jadi layer step 3 ukurannya 500 MB.
Nah pada akhir step 4 (RUN rm), imagenya tetap berukuran 1.599 GB. Command "rm" ini meskipun menghapus file, tapi ngga punya efek apa2 ke image size. Layer yang pada step 4 sedang dibuat (yang menjalankan "RUN rm" ini) tidak bisa mempengaruhi layer sebelumnya (hasil step 3) -- karena layer step 4 bergantung pada state layer sebelumnya (step 3).
Kalau image ini dibuat containernya, file yang dihapus oleh command "rm" ini tidak akan ketemu. Itu saja efek step 4 tadi.
Detail alasannya bisa dibaca lebih lanjut di sini: https://stackoverflow.com/questions/29380738/why-the-virtual-size-still-the-same-after-delete-a-file-from-container-with-rm
Resource di internet kalau kita baca2 pasti mention kalau container itu lebih lightweight, lebih kecil ukurannya dibandingkan VM. Tapi menurut pengalaman, kalau Anda belum mahir membuat image container maka ukurannya bisa meledak sampai hitungan GB. Contohnya di atas, kita remove /app/app.csv tapi dalam satu step terpisah. Hasilnya tidak berpengaruh ke ukuran image dan ukurannya tetap besar.
Untuk kasus di atas ada workaroundnya supaya ukuran image besar bisa dihindari, yaitu memakai multi-stage builds:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
Nah, itulah pembahasan konsep "layer" di Docker. Cukup menarik pada saat saya pertama kali mempelajarinya, dan kadang termasuk interview question juga.

{note1} Yang belum tau istilah seperti "staging" "preproduction" "production" bisa lihat https://en.wikipedia.org/wiki/Deployment_environment
{note2} Sebutannya "bare metal", karena kita benar punya fisik servernya instead of nyewa mesinnya seperti semua Cloud providers - GCP, AWS, dsb. Kalau nyewa cloud provider, kita kan ngga tau kalau munculin VM, mesin fisiknya yang jalanin VM tsb ada di lokasi mana.
{note3} Kadang server dipasangin GPU buat keperluan machine learning (ML).
{note4} Satu server seperti ini dengar2 berkisar belasan sampai puluhan juta, dan umurnya akan lebih pendek kalau ~~sengaja dibanting atau disiram air~~ kelistrikannya ngga dihandle dengan benar. Btw, menyewa data center di Indo itu salah satu biaya utamanya dihitung dari pemakaian listrik kalau saya tidak salah. Bisa tolong dikoreksi kalau saya salah.
{note5} Yang disebut "service" di sini contohnya aplikasi yang didevelop suatu tim di perusahaan tersebut dan sudah dijalankan di node tsb, atau aplikasi open source yang diinstall misalnya Gitlab, Grafana, dsb

Pojok sharing IT: Virtualization/Containerization

VM / virtualization, sama contoh kasus

Yang baru kenal biasanya menghubung2kan VM (topik VM) dengan dual-boot. Tapi hal ini cuma relevan kalau kita bicara bagaimana menjalankan dua OS berbeda dalam satu komputer yang sama. Dua konsep tsb benar2 beda btw. Yang sama cuma perasaan gengsi bisa jalanin dua OS berbeda di laptop yang sama + kalau VM, rasa "aduh imut" yang dirasakan ketika melihat OS lain berjalan di dalam satu window kecil non-fullscreen. ~~Ngga salah. Gengsi melakukan ini itu oke dan harus buat pemula.~~
Definisi formal VM/virtualization udah banyak kalau dicari di Google. Semua definisi kurang lebih sama: ini adalah satu cara untuk pengisolasian aplikasi ("running in a dedicated machine"), cara untuk menjalankan aplikasi yang hanya bisa berjalan mulus di lingkungan tertentu, atau cara membagi pemakaian satu mesin yang mempunyai resource (CPU/mem/disk) yang besar. Virtualization nyentuhnya sampai level hardware, yaitu OS yang ada di VMnya dikecoh bahwa memang ada hardware beneran di VM tsb padahal cuma virtual hardware.
Mainan VM ini dulu saya pake buat jalanin file exe yang saya download dari internet untuk cek itu file iseng apa bukan. Sekarang, VM-VMan ini saya pakai untuk kerjaan, utamanya untuk testing kodingan di platform (OS) berbeda. Selama ini kasusnya cuma Linux vs Windows, belum ketemu Linux vs Linux.
Contoh satu kasus, saya punya library Python yang saya develop untuk dijalankan di Debian-based OS (Debian atau Ubuntu). Kodingannya ngga gitu wah banget, bayangin cuma untuk menyederhanakan pengerjaan data analysis mengambil data database production{note1} baik yang tipenya MySQL, PostgreSQL, MongoDB, kemudian diolah (filter, agregat, dsb) dan disimpan ke Google Sheet. Pengen saya share tentang ini, projectnya lumayan fun jika bicara secara personal.
Install library ini cukup sederhana kalau di Debian/Ubuntu, tinggal "git clone" (ngga dimasukin ke PyPI lah, internal), terus jalanin "pip install -e reposaya" dijamin udah langsung bisa dipake (S&K berlaku: installnya di Python 3.7). Gampang kan? Nah... suatu hari datanglah 3rd party vendor yang mau memakai Python library ini supaya bisa satu tools dengan tim perusahaan kita. Kendalanya, mereka ini pakai Windows. Tim perusahaan kita mau ada guideline install Python library ini di laptop vendor.
Mintalah tim tsb ke saya. Sambil saya mengeluh dalam hati "Alamak, Windows?"... requirement dari tim perusahaan, guideline ini harus ilustratif install apa aja dan menjalankan command apa aja sampe librarynya bisa dipakai.
Saya follow guideline hasil Google search dan saya pakai VirtualBox + Windows 10 ISO di Ubuntu 20. Karena Windows 10 bisa jalan tanpa masukin activation key, ya udah ngga pake activation. Sudah selesai setup OS, install Miniconda (basically Anaconda, tapi lightweight) di dalam VMnya dan wah, library Python internal ini bisa bekerja. Intinya udah jadi guidenya setelah eksplorasi 2 hari penuh.
Untuk pembaca thread ini yang berminat, kalau mau mulai belajar, ambil installer ISO file yang official untuk OS pilihannya. Anda bisa coba Windows atau Ubuntu.
Terus coba install VMWare/VirtualBox. Saya pertama kali mengenal VM-VMan ini pakai VMWare di Windows, tapi sekarang lebih prefer pakai VirtualBox.
Setelah semuanya ready, coba buat VM di VMWare/VirtualBox menggunakan ISO file yang tadi didownload. Kalau di VirtualBox, pengalaman hanya tinggal New, ketik nama VM + set tipenya Windows 10 64-bit, kemudian sisanya default settings saja, terus saat VMnya dinyalakan dia akan keluar prompt minta ISO file. Nah kalau sudah sampai installation, input saja informasi yang diperlukan sama installernya termasuk pembuatan akun. Semua proses ini (untuk install Windows 10 di VM) memerlukan kira-kira 30 menit sampai 1 jam.
Test tadi pakai VirtualBox, tapi bisa juga pakai VMWare Workstation Player yang sama2 gratis.

Hypervisors

Software VMWare, VirtualBox yang dibahas sebelumnya tergolong satu keluarga software yang dinamakan "hypervisor".
Di level enterprise, hypervisor ini lebih luas pemakaiannya dari yang tadi digunakan dari laptop Anda di contoh sebelumnya.
Bayangkan perusahaan punya satu server fisik{note2} yang kekuatannya 8x laptop yang Anda pakai sekarang -- 32 CPU cores, 256 GB RAM {note3}{note4}.
Satu mesin ini umumnya dipakai sharing antar tim satu perusahaan, nah terlalu banyak service di satu node akan repot. Saat situasi heavy load, misal perusahaan ada kegiatan bagi-bagi voucher di aplikasi + buka event gacha karakter populer ke user-usernya (istilahnya "userbase"), dan service-service{note5} di node itu diperkirakan akan kerja keras.
Kalau dari sisi resources, jadinya nanti semua service di satu node itu akan berlomba-lomba siapa yang bisa mengambil 100% resource CPU/memory node tsb lebih dulu.
Kalau dari sisi networking, IP address cuma satu, terpaksa kalau service baru buatan tim lain harus bagi-bagi TCP port yang belum dipakai di node tsb. Berhubung TCP ports ngga punya banyak nomor cantik (1024-65536), bakalan ada beban ingatan buat developer untuk mengingat port mana digunakan service apa.
Banyak Linux distro juga punya keterbatasan yang namanya maximum open file, di mana satu OS harus bisa keep track file-file mana saja yang digunakan process yang sedang berjalan + network socket yang sedang dibuka https://unix.stackexchange.com/questions/36841/why-is-number-of-open-files-limited-in-linux. Menurut pengalaman sering kejadian di satu node seperti ini yang dishare banyak tim, beberapa aplikasi crash karena open file limit contohnya di sini (catatan lagi: di Linux, network socket yang dipakai suatu process untuk komunikasi ke luar nodenya juga akan "open" satu atau lebih "file")
Seandainya satu node tsb dibagi-bagi ke beberapa VM, setiap tim diberikan (di-"assign") VM masing-masing dan service mereka berjalan on top of VM, nah meskipun satu node tsb shared dengan banyak tim tapi service-service yang jalan ngga akan bisa makan lebih banyak dari yang sudah dialokasikan -- karena OS dan aplikasinya dikecoh bahwa "kamu hanya punya resource CPU x cores dan y memory".
Selain VirtualBox (sepertinya cuma dipakai level testing lokal cmiiw), VMWware, ada lagi contoh hypervisor yaitu Proxmox. Proxmox ini, kita install sebagai OSnya di bare metal yang kita tuju -- bisa diinstall on top of existing Debian installation tapi kelihatannya advanced banget dan ribet. Kemudian setelah selesai akan ada UI nya di mana kita bisa membuat VM (kegiatan ini bisa disebut "provision") dengan mengalokasikan resource yang sudah ada (jumlah CPU, memory, dan disk space yang mau dipakai).
Proxmox bisa menggabungkan banyak node baremetal jadi satu cluster, dan jadi lebih terorganisir supaya manajemen VM tinggal dari satu node saja instead of harus login ke node-node yang diinstall Proxmox dan manage VM nya dari sana. Cluster ini juga bisa spawn VM lebih berimbang -- misal VM berikutnya akan dispawn di node yang resourcenya lebih lowong. VM di satu node juga bisa dipindah ke node yang lain dalam satu cluster, dalam situasi di mana node tsb harus dimaintenance (contoh, ditambahkan memory). CMIIW kalau ada yang pakai Proxmox di /indonesia.
Btw, OS tempat hypervisor diinstall biasa disebut "Host OS", sedangkan OS di dalam VM-VM yang dispawn oleh hypervisor dinamakan "Guest OS"

VM snapshots

Shared directories

Containers / containerization

Virtualization dirasa ribet karena pemakaian resource untuk hypervisor ngga sedikit, jadinya jatah resource untuk VM-VM yang menjalankan guest OS berkurang diambil hypervisor supaya dia bisa jalan. Ngga bisa dihindari memang. Untuk boot up VM juga kelamaan sampai bisa dipakai.
Maka berikutnya dikembangkan lah konsep containerization.
Anggapan kasar, "container" ini sama dengan VM yaitu untuk membuat environment yang terisolasi untuk aplikasi user yang berjalan di dalamnya supaya aplikasi lain yang berjalan di node yang sama ngga kena impact, dan untuk manage resources yang gede dipecah ke yang kecil-kecil. Tapi dibandingkan dengan VM yang membuat guest OSnya hampir dari nol, containerization ini lebih banyak memakai apa yang sudah ada di Host OS yang sedang berjalan. Kalau pembuatan VM itu anggapannya kerja keras mulai dari initialize hardware (dibikin virtual hardware), initialize kernel di dalam VMnya supaya bisa digunakan. Sedangkan kalau containerization itu ngga mau repot, udah ada hardware interface segala macam di Host OSnya dia main pakai saja instead of buat virutal hardware, udah ada kernel di OSnya ya udah dipakai lagi saja sama dia.
Saya ketemu grafik di sini yang menurut saya membandingkan container vs VM lebih mendetail dibandingkan resource lain di internet.
Nah tapi berhubung container itu beda dengan VM di mana ngga ada yang namanya install2an OS dst, ada keterbatasannya. Oleh karena container bergantung pada kernel, system library, dan lain-lain di hostnya (saya juga belum 100% paham), kalau ada perbedaan hal2 ini di platform lain, maka container ngga bisa jalan di platform lain tsb. Pernyataan ini lebih untuk menjawab pertanyaan: Bisa ngga di Ubuntu jalanin Windows container (bukan Windows VM)? Ngga bisa :( untuk kenapanya, bisa baca secara mendetail di sini: https://stackoverflow.com/questions/42158596/can-windows-containers-be-hosted-on-linux

Membuat container

Membuat image

Docker image dibuat dari set instruksi yang disebut "Dockerfile". Dockerfile itu cuma file teks biasa yang umumnya punya nama literally "Dockerfile", dengan contoh isinya seperti ini...
FROM ubuntu:18.04 COPY . /app RUN make /app CMD python /app/app.py
Contoh Dockerfile yang lain bisa dilihat di official docs sini: https://docs.docker.com/get-started/part2/#sample-dockerfile, di sana dijabarkan setiap steps ngapain.
Di Docker image, setiap step di Dockerfile (kalau di contoh singkat di atas itu ada 4 step) akan membuat "layer" baru di image tsb. Setiap layer di satu image bergantung pada layer sebelumnya yang telah dibuat.
Contoh, di bawah ini adalah isi Dockerfile yang saya buat di mana saya mengcopy file app.csv dari host saya yang besarnya 1 GB, ke dalam image ubuntu:18.04. Kemudian di step berikutnya saya ZIP file tersebut. Ukuran zip filenya menjadi 500 MB. Kemudian file asli di imagenya saya delete.
FROM ubuntu:18.04 COPY app.csv /app/app.csv # besarnya 1 GB RUN zip /app/app.zip /app/app.csv # besar ZIP filenya 500 MB RUN rm /app/app.csv
Image ubuntu:18.04 yang saya pakai besarnya 99 MB. Setelah step keempat, besar image hasil step 4 dibandingkan dengan image awal (ubuntu:18.04) bertambah 1.5 GB menjadi 1.6 GB.
Kalau mengikuti step-step di atas, berlogika harusnya besar image hanya bertambah 500 MB dan bukan 1.5 GB. Penambahan 1.5 GB ini karena konsep layer di Docker. State pada setiap step akan disimpan. State pada step berikutnya hanya akan menyimpan perubahan yang terjadi (di-append, tidak bisa remove) pada state sebelumnya.
Untuk lebih jelasnya seperti ini, pada akhir step paling awal contoh di atas state imagenya berukuran 99 MB.
akhir step 2 (COPY), imagenya berukuran 1.099 GB. Jadi layer step 2 ukurannya 1 GB.
akhir step 3 (RUN zip), imagenya berukuran 1.599 GB. Jadi layer step 3 ukurannya 500 MB.
Nah pada akhir step 4 (RUN rm), imagenya tetap berukuran 1.599 GB. Command "rm" ini meskipun menghapus file, tapi ngga punya efek apa2 ke image size. Layer yang pada step 4 sedang dibuat (yang menjalankan "RUN rm" ini) tidak bisa mempengaruhi layer sebelumnya (hasil step 3) -- karena layer step 4 bergantung pada state layer sebelumnya (step 3).
Kalau image ini dibuat containernya, file yang dihapus oleh command "rm" ini tidak akan ketemu. Itu saja efek step 4 tadi.
Detail alasannya bisa dibaca lebih lanjut di sini: https://stackoverflow.com/questions/29380738/why-the-virtual-size-still-the-same-after-delete-a-file-from-container-with-rm
Resource di internet kalau kita baca2 pasti mention kalau container itu lebih lightweight, lebih kecil ukurannya dibandingkan VM. Tapi menurut pengalaman, kalau Anda belum mahir membuat image container maka ukurannya bisa meledak sampai hitungan GB. Contohnya di atas, kita remove /app/app.csv tapi dalam satu step terpisah. Hasilnya tidak berpengaruh ke ukuran image dan ukurannya tetap besar.
Untuk kasus di atas ada workaroundnya supaya ukuran image besar bisa dihindari, yaitu memakai multi-stage builds:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds
Nah, itulah pembahasan konsep "layer" di Docker. Cukup menarik pada saat saya pertama kali mempelajarinya, dan kadang termasuk interview question juga.

{note1} Yang belum tau istilah seperti "staging" "preproduction" "production" bisa lihat https://en.wikipedia.org/wiki/Deployment_environment
{note2} Sebutannya "bare metal", karena kita benar punya fisik servernya instead of nyewa mesinnya seperti semua Cloud providers - GCP, AWS, dsb. Kalau nyewa cloud provider, kita kan ngga tau kalau munculin VM, mesin fisiknya yang jalanin VM tsb ada di lokasi mana.
{note3} Kadang server dipasangin GPU buat keperluan machine learning (ML).
{note4} Satu server seperti ini dengar2 berkisar belasan sampai puluhan juta, dan umurnya akan lebih pendek kalau ~~sengaja dibanting atau disiram air~~ kelistrikannya ngga dihandle dengan benar. Btw, menyewa data center di Indo itu salah satu biaya utamanya dihitung dari pemakaian listrik kalau saya tidak salah. Bisa tolong dikoreksi kalau saya salah.
{note5} Yang disebut "service" di sini contohnya aplikasi yang didevelop suatu tim di perusahaan tersebut dan sudah dijalankan di node tsb, atau aplikasi open source yang diinstall misalnya Gitlab, Grafana, dsb

apa artinya my best friend dalam bahasa indonesia video

Terjemahan frasa MY BEST FRIEND AND I LOVE YOU dari bahasa inggris ke bahasa indonesia dan contoh penggunaan "MY BEST FRIEND AND I LOVE YOU" dalam kalimat dengan terjemahannya: You're my best friend and i love you . Perbedaan Lengkap \'Friend, Mate, Buddy, Dude\' Dalam Bahasa Inggris Beserta Contoh Kalimat Hello sahabat SBI yang sedang berbahagia dan semangat belajar bahasa inggris, pada kesempatan kali ini, admin ingin Artinya kurang lebih: Ku harapkan yang terbaik bagi mu. My best friend. Artinya adalah “teman terbaik ku”, seperti she is my best friend (dia adalah teman terbaik ku). Atau searti dengan sahabat karib / teman dekat. Is the best. Merupakan potongan kalimat yang berarti “adalah yang terbaik”. Lihat contoh berikut: She is the best. A Friend Is A Treasure dalam bahasa inggris; A Friend is a Treasure A friend is someone we turn to, when our spirits need a lift. A friend is someone we treasure, for our friendship is a gift. A friend is someone who fills our lives, with beauty, joy and grace. And make the world we live in, a better and happier place. A Friend Is A Treasure dalam bahasa Indonesia Seorang teman adalah harta Jangan lupa untuk membeli atau mendengarkan karya-karya Rex Orange County di layanan musik digital seperti Spotify, JOOX, Resso, ataupun platform lainnya sebagai bentuk dukungan kita kepada musisi yang bersangkutan ya sob. Baiklah, langsung saja, berikut ini lirik lagu Best Friend dan terjemahan ke dalam Bahasa Indonesia. Layanan gratis Google secara instan menerjemahkan kata, frasa, dan halaman web antara bahasa Inggris dan lebih dari 100 bahasa lainnya.

MY BEST FRIEND AND I LOVE YOU Terjemahan Dalam Bahasa ...

apa artinya my best friend dalam bahasa indonesia

apa artinya my best friend dalam bahasa indonesia - win

Pojok sharing IT: Virtualization/Containerization

VM / virtualization, sama contoh kasus

Hypervisors

VM snapshots

Shared directories

Containers / containerization

Membuat container

Membuat image

Pojok sharing IT: Virtualization/Containerization

VM / virtualization, sama contoh kasus

Hypervisors

VM snapshots

Shared directories

Containers / containerization

Membuat container

Membuat image

apa artinya my best friend dalam bahasa indonesia video

apa artinya my best friend dalam bahasa indonesia top