Topik:
 

Skill untuk DevOps Developer: Panduan Lengkap tentang Infrastruktur, Otomatisas, dan Virtualisasi

Oleh: Hobon.id (19/09/2026)
Skill untuk DevOps Developer: Panduan Lengkap tentang Infrastruktur, Otomatisas, dan VirtualisasiCara software dibangun dan didistribusikan telah berubah secara dramatis selama dua dekade terakhir. Dalam model tradisional, tim pengembangan menulis kode dan menyerahkannya kepada tim operasi, yang bertanggung jawab untuk men-deploy dan memeliharanya. Pemisahan ini menciptakan gesekan — deployment jarang terjadi, merupakan peristiwa berisiko, lingkungan berbeda dari waktu ke waktu, dan kesenjangan antara bagaimana software bekerja dalam pengembangan dan bagaimana perilakunya di produksi merupakan sumber kegagalan yang konstan.

DevOps muncul sebagai respons terhadap disfungsi ini. Dengan menyatukan disiplin pengembangan dan operasi — alat bersama, tanggung jawab bersama, dan budaya peningkatan berkelanjutan — organisasi menemukan bahwa mereka dapat men-deploy software lebih sering, pulih dari kegagalan lebih cepat, dan meningkatkan skala sistem dengan lebih andal. Perusahaan seperti Amazon, Netflix, Google, dan Facebook menunjukkan bahwa praktik DevOps memungkinkan frekuensi deployment yang diukur dalam ribuan rilis per hari, dengan ketersediaan yang lebih tinggi dan pengalaman pelanggan yang lebih baik daripada model rilis yang jarang terjadi sebelumnya.

Pada tingkat teknis, transformasi ini dimungkinkan oleh konvergensi tiga area kemampuan, yaitu infrastruktur cloud yang tangguh, perangkat otomatisasi yang andal, dan teknologi virtualisasi yang fleksibel. Ketiga domain inilah yang dibahas di sini, dan bersama-sama membentuk fondasi teknis praktik DevOps modern.
Advertisement:

Infrastruktur: Membangun Fondasi untuk Sistem yang Dapat Diperluas


Dalam konteks DevOps, infrastruktur mengacu pada perangkat keras, jaringan, dan platform software tempat aplikasi berjalan. Infrastruktur modern mencakup pusat data fisik, platform cloud, dan server web serta sistem observabilitas yang berada di antaranya. Penguasaan alat infrastruktur adalah keterampilan dasar setiap developer DevOps.


NGINX: Server Web dan Reverse Proxy Berkinerja Tinggi


NGINX (diucapkan "engine-x") adalah salah satu software infrastruktur yang paling banyak digunakan di dunia. Awalnya dibuat oleh Igor Sysoev pada tahun 2004 untuk memecahkan masalah C10K —yaitu tantangan menangani sepuluh ribu koneksi simultan pada satu server — NGINX sejak itu telah berkembang menjadi platform serbaguna dan multifungsi yang berfungsi sebagai server web, reverse proxy, load balancer, cache HTTP, dan titik terminasi SSL/TLS.

Arsitektur NGINX adalah yang membedakannya dari server web lama seperti Apache. Apache menggunakan model proses per koneksi atau thread per koneksi yang kesulitan menangani konkurensi tinggi, sedangkan NGINX menggunakan arsitektur berbasis event, asinkron, dan non-blocking. Satu proses worker NGINX dapat menangani ribuan koneksi simultan tanpa membuat thread atau proses tambahan, sehingga mengonsumsi memori dan CPU jauh lebih sedikit daripada model berbasis koneksi. Efisiensi ini menjadikan NGINX pilihan utama untuk website, API, dan lapisan proxy dengan trafik tinggi yang harus menangani sejumlah besar pengguna bersamaan.

Sebagai reverse proxy, NGINX berada di antara klien dan server aplikasi backend. Permintaan masuk tiba di NGINX, yang kemudian mengarahkannya ke layanan backend yang sesuai berdasarkan aturan yang dapat dikonfigurasi — berdasarkan jalur URL, nama host, header permintaan, atau algoritma penyeimbangan beban. Arsitektur ini memisahkan lapisan jaringan publik dari lapisan aplikasi, memungkinkan backend untuk ditambahkan, dihapus, atau dimulai ulang tanpa mengganggu layanan ke klien. Round-robin, least-connections, IP hash, dan weighted distribution adalah semua strategi penyeimbangan beban yang didukung.

Bagi developer DevOps, konfigurasi NGINX adalah keterampilan sehari-hari. Memahami blok server (virtual host), arahan lokasi, grup upstream, konfigurasi proxy pass, instalasi sertifikat SSL, pengaktifan HTTP/2, kompresi gzip, header caching, dan pembatasan laju adalah kompetensi praktis yang berulang kali muncul di lingkungan produksi. NGINX Plus, edisi komersial, menambahkan pemeriksaan kesehatan aktif, pemantauan tingkat lanjut, konfigurasi ulang dinamis tanpa reload, dan dasbor bawaan untuk visibilitas lalu lintas.


Amazon Web Services (AWS): Platform Cloud yang Mendefinisikan Industri


Amazon Web Services diluncurkan pada tahun 2006 dengan beberapa layanan dan sejak itu berkembang menjadi platform komputasi awan terbesar dan terlengkap di dunia. Dengan ratusan layanan yang mencakup komputasi, penyimpanan, jaringan, database, pembelajaran mesin, keamanan, dan alat bantu developer, AWS telah menjadi lingkungan cloud standar bagi perusahaan rintisan, perusahaan besar, dan organisasi pemerintah. Bagi developer DevOps, kemampuan menggunakan AWS bukan lagi spesialisasi, melainkan harapan dasar di pasar kerja modern.

Inti dari infrastruktur AWS adalah EC2 (Elastic Compute Cloud), yang menyediakan server virtual — yang disebut instance — yang dapat diprovisikan dalam hitungan detik, diskalakan secara horizontal dengan menambahkan lebih banyak instance, dan dihentikan ketika tidak lagi dibutuhkan. EC2 mendukung ratusan tipe instance yang dioptimalkan untuk berbagai beban kerja, yaitu seperti instance yang dioptimalkan untuk komputasi untuk tugas-tugas yang intensif CPU, instance yang dioptimalkan untuk memori untuk basis data dalam memori, instance yang dioptimalkan untuk penyimpanan untuk pemrosesan data berkinerja tinggi, dan instance GPU untuk pembelajaran mesin dan beban kerja grafis.

Jaringan di AWS berpusat pada VPC (Virtual Private Cloud), yang menyediakan lingkungan jaringan terisolasi tempat instance EC2, database, dan layanan lainnya berjalan. Developer DevOps harus memahami subnet, tabel rute, gateway internet, gateway NAT, grup keamanan (aturan firewall stateful pada tingkat instance), dan ACL jaringan (aturan stateless pada tingkat subnet) untuk merancang jaringan cloud yang aman dan tersegmentasi dengan benar. Peering VPC dan AWS Transit Gateway memperluas konektivitas ini di beberapa VPC atau akun AWS.

Di luar dasar-dasar ini, layanan AWS yang paling relevan bagi developer DevOps meliputi ECS dan EKS untuk orkestrasi kontainer, Lambda untuk eksekusi fungsi serverless, RDS untuk database relasional terkelola, ElastiCache untuk Redis dan Memcached terkelola, CloudFront untuk pengiriman konten, Route 53 untuk DNS, IAM untuk manajemen identitas dan akses, CloudWatch untuk pemantauan dan peringatan, CloudFormation untuk infrastruktur sebagai kode, dan CodePipeline/CodeBuild/CodeDeploy untuk pipeline CI/CD terkelola.


Microsoft Azure: Cloud Perusahaan dengan Integrasi Microsoft yang Mendalam


Microsoft Azure adalah platform cloud terbesar kedua di dunia, pesaing langsung AWS, dan cloud pilihan bagi banyak organisasi perusahaan yang telah berinvestasi dalam teknologi Microsoft. Integrasi mendalam Azure dengan Active Directory, Windows Server, Microsoft 365, dan ekosistem Microsoft yang lebih luas menjadikannya pilihan yang tepat bagi perusahaan yang menjalankan beban kerja Microsoft, dan kemampuan cloud hibridanya — menghubungkan infrastruktur lokal ke layanan Azure — membedakannya dalam skenario di mana migrasi cloud penuh tidak memungkinkan.

Azure membedakan dirinya dalam beberapa area. Azure Active Directory (sekarang disebut Microsoft Entra ID) adalah platform identitas yang paling banyak digunakan di dunia, mengelola autentikasi untuk ratusan juta pengguna di seluruh layanan konsumen dan perusahaan Microsoft. Bagi organisasi yang perlu mengintegrasikan infrastruktur cloud dengan identitas perusahaan yang ada, integrasi AAD asli Azure merupakan keuntungan yang signifikan. Azure DevOps (sebelumnya Visual Studio Team Services) menyediakan rangkaian lengkap alat manajemen proyek, kontrol sumber, pipeline CI/CD, manajemen artefak, dan manajemen pengujian yang bersaing langsung dengan ekosistem GitHub Actions dan Atlassian.

Azure Kubernetes Service (AKS) adalah salah satu penawaran Kubernetes terkelola yang paling matang, dan integrasinya dengan Azure Container Registry, Azure Monitor, dan Azure Policy membuat pembangunan infrastruktur Kubernetes kelas produksi di Azure jauh lebih mudah daripada merakit tumpukan yang setara dari komponen individual. Azure Arc memperluas bidang manajemen Azure ke infrastruktur non-Azure, termasuk server lokal dan klaster yang berjalan di penyedia cloud lain, memungkinkan pengalaman manajemen hibrida yang sesungguhnya.

Bagi developer DevOps, pemahaman tentang AWS dan Azure secara signifikan akan memperluas fleksibilitas karier, karena banyak perusahaan beroperasi di lingkungan multi-cloud atau sedang dalam proses migrasi antar platform. Konsep-konsep dasarnya — mesin virtual, penyimpanan objek, jaringan terkelola, IAM, pemantauan, dan CI/CD — dapat diterapkan di berbagai platform; nama layanan spesifik dan detail konfigurasinya berbeda.


ELK Stack: Observabilitas Melalui Manajemen Log Terpadu


ELK Stack — yang terdiri dari Elasticsearch, Logstash, dan Kibana, seringkali diperluas dengan Beats sebagai pengirim data ringan — adalah platform yang paling banyak digunakan untuk agregasi, pencarian, dan visualisasi log di dunia DevOps. Platform ini mengubah aliran data log mentah dan tidak terstruktur yang dihasilkan oleh aplikasi, server, kontainer, dan perangkat jaringan menjadi informasi yang dapat dicari, dianalisis, dan divisualisasikan yang memungkinkan pemecahan masalah yang cepat, analisis kinerja, dan pemantauan keamanan.

Elasticsearch, inti dari stack ini, adalah mesin pencarian dan analitik terdistribusi yang dibangun di atas Apache Lucene. Elasticsearch menyimpan data log sebagai dokumen JSON dan memelihara indeks terbalik yang memungkinkan pencarian teks lengkap di antara miliaran entri log dalam hitungan milidetik. Arsitektur terdistribusi Elasticsearch memungkinkan penskalaan horizontal di banyak node, mendistribusikan penyimpanan dan beban kueri. Bagi developer DevOps, memahami manajemen indeks Elasticsearch — termasuk kebijakan siklus hidup indeks yang secara otomatis memindahkan data dari tingkatan penyimpanan panas ke hangat ke dingin dan akhirnya menghapusnya — sangat penting untuk menjaga infrastruktur log tetap mudah dikelola dan hemat biaya dalam skala besar.

Logstash adalah pipeline pemrosesan data yang menyerap log dari berbagai sumber, menerapkan transformasi, mengurai data terstruktur dari teks log yang tidak terstruktur menggunakan plugin filter yang dapat dikonfigurasi (pola Grok adalah yang paling umum digunakan), memperkaya peristiwa dengan konteks tambahan, dan mengarahkannya ke Elasticsearch atau tujuan output lainnya. Fleksibilitas Logstash membuatnya mampu menyerap log dari file, syslog, antrian pesan seperti Kafka dan RabbitMQ, database, endpoint HTTP, dan layanan cloud. Namun, konsumsi sumber dayanya telah menyebabkan banyak tim menggantinya dengan alternatif yang lebih ringan seperti Fluentd atau Fluent Bit untuk pengumpulan data, dan menggunakan Logstash untuk transformasi yang kompleks.

Kibana adalah frontend visualisasi dan eksplorasi untuk ELK Stack. Kibana menyediakan antarmuka kueri yang kuat untuk mencari dan memfilter data log, pembuat dasbor untuk membuat tampilan operasional yang dapat dibagikan dan dipantau oleh tim, dan alat untuk membuat aturan peringatan yang memberi tahu tim ketika pola log atau ambang batas metrik tertentu terdeteksi. Tampilan Discover memungkinkan eksplorasi log ad hoc yang sangat berharga selama respons insiden — memungkinkan para insinyur untuk mencari di seluruh log dari semua layanan dalam antarmuka terpadu daripada melakukan SSH ke server individual dan mencari melalui file.

Beats adalah pengirim data ringan yang diinstal pada sistem sumber yang mengumpulkan jenis data tertentu dan meneruskannya langsung ke Elasticsearch atau ke Logstash untuk diproses. Filebeat mengumpulkan file log, Metricbeat mengumpulkan metrik sistem dan layanan, Packetbeat menangkap lalu lintas jaringan, dan Heartbeat memantau waktu aktif layanan. Bersama-sama, ekosistem Beats memungkinkan pengumpulan telemetri komprehensif dari sistem apa pun tanpa beban menjalankan instance Logstash lengkap di setiap host.

Dalam lingkungan Kubernetes modern, ELK Stack — atau penerus komersialnya, Elastic Stack dengan fitur keamanan dan observabilitas X-Pack — umumnya digunakan sebagai backend logging untuk agregasi log di seluruh kluster, menjadikannya teknologi yang ditemui developer DevOps terlepas dari platform cloud utama mereka.


Otomatisasi: Menghilangkan Kerja Manual dan Menegakkan Konsistensi


Otomatisasi bukan sekadar kemudahan dalam DevOps — ini adalah komitmen filosofis. Setiap langkah manual dalam proses deployment berpotensi menjadi sumber kesalahan manusia, inkonsistensi antar lingkungan, dan hambatan terhadap kecepatan pengiriman. Alat otomatisasi DevOps memungkinkan infrastruktur didefinisikan sebagai kode, konfigurasi diterapkan secara konsisten di ratusan server secara bersamaan, dan pipeline pengiriman software dieksekusi tanpa intervensi manusia dari commit kode hingga deployment produksi.


Ansible: Manajemen Konfigurasi Tanpa Agen untuk Infrastruktur Modern


Ansible, yang dibuat oleh Michael DeHaan pada tahun 2012 dan diakuisisi oleh Red Hat pada tahun 2015, adalah salah satu alat manajemen konfigurasi dan otomatisasi yang paling banyak diadopsi dalam ekosistem DevOps. Karakteristik utamanya adalah kesederhanaan, yaitu Ansible tidak menggunakan agen, artinya tidak memerlukan software untuk diinstal pada node yang dikelola. Ia berkomunikasi dengan sistem target melalui SSH (atau WinRM untuk Windows) dan mengeksekusi tugas menggunakan Python, yang tersedia secara default di hampir setiap distribusi Linux. Pendekatan tanpa jejak (zero-footprint) ini menghilangkan masalah bootstrapping yang memengaruhi alat berbasis agen dan membuat Ansible mudah diakses oleh tim yang membutuhkan hasil segera tanpa pengaturan infrastruktur yang kompleks.

Logika otomatisasi Ansible diekspresikan dalam file YAML yang disebut playbook. Sebuah playbook menjelaskan serangkaian play, masing-masing menargetkan sekelompok host dan mengeksekusi serangkaian tugas. Tugas memanggil modul Ansible — unit otomatisasi yang dapat digunakan kembali yang merangkum operasi spesifik seperti menginstal paket, membuat file, memodifikasi konfigurasi, memulai layanan, atau melakukan panggilan API. Ansible dilengkapi dengan ribuan modul bawaan yang mencakup manajemen paket, operasi file, manajemen pengguna, API penyedia cloud, konfigurasi perangkat jaringan, manajemen database, dan banyak lagi.

Role Ansible menyediakan cara untuk mengatur playbook ke dalam komponen yang dapat digunakan kembali dan dibagikan. Sebuah role merangkum semua tugas, variabel, file, template, dan handler yang dibutuhkan untuk mengkonfigurasi bagian infrastruktur tertentu — instalasi Nginx, server PostgreSQL, runtime aplikasi Java — dan dapat dibagikan di seluruh proyek atau dipublikasikan ke Ansible Galaxy, pusat komunitas untuk konten Ansible. Ansible Collections, yang diperkenalkan di Ansible 2.9, memperluas model ini untuk menggabungkan role, modul, plugin, dan dokumentasi bersama-sama ke dalam paket yang dapat didistribusikan dan diberi versi.

Bagi developer DevOps, keterampilan Ansible praktis meliputi menulis playbook dan role untuk penyediaan dan konfigurasi infrastruktur, menggunakan templat Jinja2 untuk menghasilkan file konfigurasi dinamis, mengelola rahasia dengan Ansible Vault, mengatur inventaris untuk lingkungan besar atau berbasis cloud menggunakan plugin inventaris dinamis, dan mengintegrasikan eksekusi Ansible ke dalam pipeline CI/CD melalui AWX atau Red Hat Ansible Automation Platform.


Chef: Infrastruktur sebagai Kode dengan Kekuatan Ruby


Chef adalah salah satu platform manajemen konfigurasi tertua dan terkuat dalam ekosistem DevOps, pertama kali dirilis pada tahun 2009 oleh Opscode (sekarang Progress Chef). Jika Ansible menggunakan YAML untuk penulisan playbook, Chef menggunakan DSL (Domain Specific Language) berbasis Ruby untuk menulis logika konfigurasi, yang memberikan ekspresivitas dan fleksibilitas luar biasa dengan biaya kurva pembelajaran yang lebih curam bagi developer yang tidak terbiasa dengan Ruby.

Arsitektur Chef melibatkan tiga komponen utama, yaitu Chef Workstation, tempat developer menulis dan menguji kode konfigurasi; Chef Server, yang bertindak sebagai repositori pusat untuk data konfigurasi dan pusat komunikasi untuk node yang dikelola; dan Chef Client, agen yang berjalan di setiap node yang dikelola, secara berkala memeriksa Chef Server, mengambil konfigurasinya, dan mengonvergensi node ke keadaan yang diinginkan.

Dalam terminologi Chef, logika konfigurasi ditulis sebagai resep, yaitu file Ruby yang menjelaskan keadaan sistem yang diinginkan menggunakan sumber daya Chef seperti paket, layanan, file, template, dan pengguna. Resep dikelompokkan ke dalam buku masak (cookbook), yang menggabungkan resep terkait, file atribut, file templat, kode pustaka, dan metadata ke dalam unit yang dapat dibagikan dan memiliki versi. Chef Supermarket adalah pusat komunitas untuk berbagi dan menemukan buku masak, dengan ribuan buku masak yang dikontribusikan oleh komunitas tersedia untuk komponen infrastruktur umum.

Chef Infra (alat manajemen konfigurasi inti), Chef InSpec (untuk pengujian dan audit kepatuhan), Chef Habitat (untuk pengemasan aplikasi dan manajemen runtime), dan Chef Automate (untuk visibilitas, pelaporan kepatuhan, dan manajemen alur kerja) bersama-sama membentuk platform Chef — rangkaian lengkap untuk organisasi yang membutuhkan manajemen konfigurasi tingkat perusahaan dengan dukungan siklus hidup penuh.


Jenkins: Server Otomatisasi di Jantung CI/CD


Jenkins adalah server otomatisasi open source yang paling banyak digunakan di dunia, dan telah menjadi tulang punggung pipeline continuous integration dan continuous delivery (CI/CD) di berbagai organisasi selama lebih dari satu dekade. Awalnya dikembangkan dari Hudson pada tahun 2011, Jenkins telah berkembang menjadi platform yang sangat mudah diperluas dengan lebih dari 1.800 plugin kontribusi komunitas yang mencakup setiap aspek siklus hidup pengiriman perangkat lunak.

Pada intinya, Jenkins menjalankan alur kerja otomatis yang disebut job atau pipeline sebagai respons terhadap pemicu — sebuah commit ke repositori kode sumber, waktu yang dijadwalkan, job upstream yang selesai, atau panggilan API. Alur kerja ini dapat mencakup kombinasi langkah apa pun: mengambil kode, mengkompilasi dan menguji, menjalankan analisis statis, mengemas artefak, mendorong image kontainer, menerapkan ke lingkungan staging, menjalankan pengujian integrasi, dan mempromosikan ke produksi.

Jenkins Pipeline, yang diperkenalkan sebagai fitur utama di Jenkins 2.0, memungkinkan definisi pipeline ditulis sebagai kode dalam DSL berbasis Groovy dan disimpan bersama kode sumber aplikasi dalam kontrol versi. Pendekatan "pipeline sebagai kode" ini transformatif karena berarti proses deployment memiliki versi, dapat ditinjau, dan dapat diuji seperti halnya kode aplikasi. Sintaks Declarative Pipeline menyediakan format terstruktur dan terarah yang lebih mudah ditulis dan dibaca oleh sebagian besar tim, sementara Scripted Pipeline menawarkan kekuatan penuh Groovy untuk logika pipeline yang kompleks dan terprogram.

Ekosistem plugin Jenkins adalah kekuatan terbesarnya sekaligus sumber kompleksitas operasional. Plugin tersedia untuk berintegrasi dengan hampir setiap sistem kontrol sumber (Git, Subversion, Mercurial), alat build (Maven, Gradle, Make, npm), framework pengujian, repositori artefak (Nexus, Artifactory), penyedia cloud, platform kontainer, layanan notifikasi, dan target deployment yang dapat dibayangkan. Ekstensibilitas ini berarti Jenkins dapat diadaptasi ke hampir semua stack teknologi, tetapi juga berarti bahwa mengelola versi plugin, kompatibilitas, dan patch keamanan di seluruh instalasi Jenkins yang besar merupakan beban operasional yang tidak sepele.

Bagi developer DevOps, keterampilan Jenkins meliputi pembuatan definisi Pipeline Deklaratif, pengelolaan agen Jenkins (node ​​yang menjalankan langkah-langkah pipeline, baik sebagai agen permanen atau agen cloud sementara pada platform seperti Kubernetes), konfigurasi integrasi dengan GitHub atau GitLab untuk build yang dipicu oleh permintaan pull, pengelolaan kredensial secara aman melalui penyimpanan kredensial Jenkins, dan pemahaman tentang cara menyusun pipeline multi-cabang yang secara otomatis membuat dan menghapus instance pipeline saat cabang dibuat dan dihapus dari repositori.


Virtualisasi: Mengisolasi, Mengemas, dan Mengatur Beban Kerja


Virtualisasi adalah teknologi yang membuat infrastruktur modern menjadi elastis, portabel, dan efisien. Dengan mengabstraksikan software dari perangkat keras fisik tempatnya berjalan, virtualisasi memungkinkan beberapa beban kerja untuk berbagi sumber daya, aplikasi dikemas dengan dependensinya dan berjalan secara konsisten di berbagai lingkungan, dan infrastruktur dibuat dan dihancurkan sesuai permintaan. Teknologi dalam kategori ini mencakup virtualisasi tingkat perangkat keras hingga pengemasan kontainer ringan dan sistem orkestrasi yang mengelolanya dalam skala besar.


Docker: Revolusi Kontainer


Docker, yang diluncurkan pada tahun 2013 oleh Solomon Hykes di dotCloud (kemudian berganti nama menjadi Docker, Inc.), secara fundamental mengubah cara software dikemas dan didistribusikan. Sebelum Docker, menyebarkan aplikasi ke lingkungan baru berarti mereplikasi lingkungan runtime dengan hati-hati — menginstal versi bahasa yang tepat, menginstal pustaka yang tepat, mengkonfigurasi jalur dan variabel lingkungan yang tepat — dan berharap tidak ada yang terlewat. Keluhan developer yang terkenal "berjalan di mesin saya" menggambarkan frustrasi akibat inkonsistensi lingkungan yang menyebabkan kegagalan produksi.

Docker memecahkan masalah ini dengan kontainer — yaitu unit yang ringan, portabel, dan mandiri yang mengemas aplikasi bersama dengan seluruh lingkungan runtime-nya, seperti library sistem operasi yang bergantung padanya, runtime bahasa, file konfigurasi, dan kode aplikasi itu sendiri. Kontainer Docker berjalan identik terlepas dari apakah dijalankan di laptop developer, server CI/CD, lingkungan staging, atau klaster produksi. Masalah inkonsistensi lingkungan dihilangkan secara desain.

Kontainer Docker dibangun dari image, yang didefinisikan oleh instruksi Dockerfile. Dockerfile menjelaskan langkah-langkah untuk membangun image: dimulai dari image dasar (distribusi Linux resmi, runtime bahasa, atau basis yang disesuaikan), menyalin kode aplikasi, menginstal dependensi, mengatur variabel lingkungan, dan menentukan perintah yang akan dijalankan saat kontainer dimulai. Image adalah snapshot yang tidak dapat diubah — setelah dibangun, image tidak berubah — yang berarti bahwa image yang persis sama yang lolos pengujian di pipeline CI adalah yang akan di-deploy ke produksi.

Docker Hub dan registri kontainer pribadi seperti Amazon ECR, Google Container Registry, dan Azure Container Registry berfungsi sebagai repositori untuk citra Docker, memungkinkan citra untuk dibuat sekali dan ditarik di mana saja. Format citra berlapis Docker berarti bahwa citra berbagi lapisan yang sama — jika dua citra sama-sama menggunakan citra dasar Ubuntu yang sama, lapisan dasar tersebut hanya disimpan sekali, sehingga menghemat penyimpanan dan mempercepat transfer.

Bagi developer DevOps, keterampilan Docker jauh melampaui sekadar menulis Dockerfile. Memahami multi-stage build — yang menggunakan kontainer build perantara untuk mengkompilasi dan menguji kode sebelum hanya menyalin artefak yang telah dikompilasi ke dalam image produksi yang ramping — secara dramatis mengurangi ukuran image dan permukaan serangan. Jaringan Docker (driver jaringan bridge, host, overlay, dan macvlan) memungkinkan komunikasi antar layanan di dalam dan di seluruh host. Volume Docker dan bind mount menangani penyimpanan data persisten untuk kontainer stateful. Docker Compose mengatur lingkungan pengembangan lokal multi-kontainer, mendefinisikan semua layanan, jaringan, dan volume dalam satu file YAML yang dapat diluncurkan dengan satu perintah.


IBM BladeCenter: Virtualisasi Perangkat Keras pada Skala Perusahaan


IBM BladeCenter mewakili lapisan berbeda dari kisah virtualisasi — bukan virtualisasi software untuk isolasi aplikasi, tetapi konsolidasi perangkat keras yang memungkinkan model efisiensi pusat data modern yang kemudian diperluas oleh komputasi awan hingga mencapai kesimpulan logisnya. Memahami BladeCenter akan memberikan konteks penting bagi developer DevOps yang bekerja di atau dengan lingkungan perusahaan yang masih mengandalkan infrastruktur fisik atau hibrida.

BladeCenter adalah platform sasis server blade IBM, sebuah sistem di mana beberapa modul server mandiri — yang disebut blade — dipasang ke dalam sasis bersama yang menyediakan daya, pendinginan, jaringan, dan infrastruktur manajemen bersama. Satu sasis BladeCenter dapat menampung hingga empat belas server blade, masing-masing merupakan server lengkap dengan prosesor, memori, dan penyimpanan lokalnya sendiri, semuanya berbagi catu daya, modul switching, dan modul manajemen sasis.

Keunggulan operasional arsitektur blade adalah kepadatan dan konsolidasi. Di mana server yang dipasang di rak tradisional masing-masing membutuhkan koneksi daya individual, kabel jaringan individual, dan antarmuka manajemen individual, server blade berbagi sumber daya ini melalui backplane sasis. Hal ini secara dramatis mengurangi kompleksitas pengkabelan, konsumsi daya, kebutuhan pendinginan, dan jejak fisik dibandingkan dengan jumlah server mandiri yang setara. Pusat data yang sebelumnya menampung rak server tower atau 1U dapat mengkonsolidasikan kapasitas komputasi yang sama ke dalam sebagian kecil ruang menggunakan sasis blade.

Bagi developer DevOps, keahlian BladeCenter relevan dalam beberapa skenario. Banyak perusahaan besar — ​​bank, perusahaan asuransi, organisasi perawatan kesehatan, dan lembaga pemerintah — mengoperasikan infrastruktur BladeCenter on-premises yang substansial yang belum sepenuhnya dimigrasikan ke platform cloud. Developer DevOps di lingkungan ini harus memahami cara menyediakan, mengkonfigurasi, dan mengelola server blade, cara mengkonfigurasi chassis management module (CMM) untuk pemantauan kesehatan perangkat keras dan manajemen jarak jauh, dan cara mengintegrasikan infrastruktur BladeCenter dengan alat otomatisasi software seperti Ansible dan Chef untuk manajemen konfigurasi yang konsisten.


Kubernetes: Sistem Operasi untuk Era Cloud-Native


Kubernetes, yang biasa disingkat K8s, adalah platform dominan untuk orkestrasi kontainer, yaitu manajemen otomatis aplikasi berbasis kontainer dalam skala besar. Awalnya dikembangkan di Google berdasarkan sistem Borg internal dan dirilis sebagai open source pada tahun 2014, Kubernetes telah menjadi salah satu proyek open source paling berpengaruh dalam sejarah komputasi, yang secara fundamental membentuk kembali cara aplikasi diimplementasikan, diskalakan, dan dioperasikan dalam produksi.

Masalah yang dipecahkan Kubernetes menjadi jelas ketika adopsi kontainer berkembang melampaui satu host. Menjalankan kontainer Docker pada satu server dapat dikelola secara manual. Menjalankan ratusan atau ribuan kontainer di puluhan atau ratusan server — memastikan kontainer dijadwalkan ke node yang sesuai, dihidupkan ulang jika mengalami crash, diganti jika node gagal, diperbarui tanpa downtime, dan diekspos ke lalu lintas melalui load balancer — membutuhkan lapisan orkestrasi. Kubernetes menyediakan lapisan orkestrasi ini, dengan control plane berbasis API yang komprehensif yang mengelola siklus hidup penuh beban kerja berbasis kontainer.

Kubernetes mengatur beban kerja di sekitar serangkaian abstraksi inti. Pod adalah unit terkecil yang dapat di-deploy — satu atau lebih kontainer yang berbagi namespace jaringan dan volume penyimpanan, dijadwalkan bersama pada node yang sama. Deployment mengelola sejumlah replika Pod identik yang diinginkan, melakukan pembaruan bergulir dan rollback saat citra kontainer baru dirilis. Service menyediakan endpoint jaringan yang stabil untuk sekumpulan Pod, mengabstraksikan fakta bahwa Pod individual bersifat sementara dan alamat IP-nya berubah saat dibuat dan dihancurkan. ConfigMap dan Secret memisahkan konfigurasi dan data sensitif dari citra kontainer, memungkinkan citra yang sama untuk berjalan dengan konfigurasi berbeda di lingkungan yang berbeda.

Untuk aplikasi stateful — database, antrian pesan, dan layanan lain yang membutuhkan penyimpanan persisten — StatefulSets menyediakan identitas Pod yang teratur dan stabil serta manajemen volume persisten. PersistentVolumes dan PersistentVolumeClaims mengabstraksi penyediaan penyimpanan, memungkinkan Pod untuk meminta penyimpanan yang tahan lama tanpa mengetahui sistem penyimpanan yang mendasarinya. StorageClasses mendefinisikan jenis penyimpanan yang tersedia dan penyedia yang bertanggung jawab untuk membuat volume sesuai permintaan.

Jaringan Kubernetes adalah topik yang kompleks yang harus dipahami oleh developer DevOps dengan upaya yang signifikan. Setiap Pod dalam kluster Kubernetes memiliki alamat IP yang unik, dan lapisan jaringan kluster memastikan bahwa Pod dapat berkomunikasi satu sama lain di seluruh node tanpa NAT. Pengontrol ingress — umumnya NGINX, seperti yang dibahas sebelumnya, atau alternatif cloud-native seperti AWS ALB Ingress atau ingress yang dikelola GKE — mengarahkan lalu lintas HTTP eksternal ke Layanan yang sesuai berdasarkan nama host dan jalur URL. Kebijakan jaringan memberikan kontrol yang lebih rinci atas komunikasi antar-Pod, memungkinkan segmentasi jaringan zero-trust di dalam kluster.

Manajemen sumber daya Kubernetes — mendefinisikan permintaan dan batasan CPU dan memori untuk kontainer — sangat penting untuk stabilitas dan efisiensi klaster. Horizontal Pod Autoscaler secara otomatis menskalakan replika Deployment berdasarkan pemanfaatan CPU, penggunaan memori, atau metrik khusus. Cluster Autoscaler menambahkan atau menghapus node dari infrastruktur yang mendasarinya berdasarkan beban kerja yang tertunda dan pemanfaatan sumber daya. Bersama-sama, mekanisme penskalaan otomatis ini memungkinkan klaster Kubernetes untuk merespons secara dinamis terhadap perubahan beban tanpa intervensi manual.

Helm, manajer paket Kubernetes, adalah alat penting untuk menyebarkan aplikasi kompleks ke Kubernetes. Helm Chart menggabungkan semua manifest Kubernetes yang dibutuhkan untuk menyebarkan aplikasi — Deployment, Layanan, ConfigMap, aturan Ingress, dan banyak lagi — ke dalam paket yang dapat diparameterisasi dan memiliki versi. Repositori chart publik seperti Artifact Hub menyediakan chart untuk ribuan komponen infrastruktur umum, memungkinkan tim untuk menyebarkan basis data, tumpukan pemantauan, pengontrol ingress, dan manajer sertifikat dengan penulisan YAML kustom minimal.

Layanan Kubernetes terkelola — Amazon EKS, Google GKE, dan Azure AKS — menghilangkan beban operasional dalam menjalankan control plane Kubernetes, menangani peningkatan versi, manajemen etcd, dan ketersediaan control plane atas nama operator klaster. Bagi sebagian besar organisasi, Kubernetes terkelola adalah pilihan yang tepat; Kubernetes yang dikelola sendiri pada bare metal atau VM cloud diperuntukkan bagi skenario dengan persyaratan kustomisasi khusus atau mandat pengoptimalan biaya yang signifikan.


Vagrant: Lingkungan Pengembangan yang Dapat Direproduksi


Vagrant, yang diciptakan oleh Mitchell Hashimoto dan pertama kali dirilis pada tahun 2010 di bawah HashiCorp, memecahkan masalah spesifik namun penting, yaitu menciptakan lingkungan pengembangan yang konsisten dan dapat direproduksi yang sangat mirip dengan infrastruktur produksi. Sebelum Vagrant, developer sering menjalankan aplikasi langsung pada sistem operasi lokal mereka, yang menyebabkan masalah klasik "berjalan di mesin saya" ketika dependensi, versi pustaka sistem, atau konfigurasi berbeda antara laptop developer dan server produksi.

Vagrant memungkinkan developer untuk mendefinisikan konfigurasi mesin virtual dalam file teks sederhana yang dikontrol versinya yang disebut Vagrantfile — menentukan citra sistem operasi dasar (disebut box), jumlah CPU dan memori yang akan dialokasikan, konfigurasi jaringan, dan langkah-langkah penyediaan yang diperlukan untuk menginstal dan mengkonfigurasi perangkat lunak di dalam mesin virtual. Menjalankan satu perintah — vagrant up — akan mengunduh box dasar jika belum ada, membuat dan mengkonfigurasi mesin virtual, dan menjalankan skrip penyediaan, menghasilkan lingkungan pengembangan yang sepenuhnya dikonfigurasi yang identik dengan apa yang akan dibuat oleh anggota tim atau sistem CI lainnya dari Vagrantfile yang sama.

Dukungan provisioner Vagrant sangat komprehensif. Vagrant dapat menggunakan skrip shell, playbook Ansible, resep Chef, manifest Puppet, atau state Salt untuk mengkonfigurasi mesin virtual, yang berarti kode otomatisasi yang sama yang digunakan untuk mengkonfigurasi server produksi dapat digunakan kembali untuk mengkonfigurasi lingkungan pengembangan. Ini menghilangkan perbedaan konfigurasi antara pengembangan dan produksi dan memungkinkan pengembang untuk menguji perubahan infrastruktur secara lokal sebelum diterapkan ke lingkungan bersama.

Vagrant berfungsi sebagai lapisan abstraksi di atas penyedia virtualisasi. VirtualBox adalah penyedia default dan yang paling umum digunakan, tetapi Vagrant juga mendukung VMware (melalui plugin komersial), Hyper-V, Docker, dan penyedia cloud seperti AWS dan Azure. Desain yang tidak bergantung pada penyedia ini berarti Vagrantfile seringkali dapat digunakan dengan berbagai teknologi virtualisasi yang mendasarinya tanpa modifikasi.

Di era kontainerisasi, Docker Compose telah menggantikan Vagrant untuk banyak kasus penggunaan yang melibatkan layanan aplikasi, tetapi Vagrant tetap mempertahankan keunggulan unik ketika lingkungan mesin virtual lengkap dibutuhkan — untuk pengembangan tingkat kernel, pengujian yang membutuhkan versi sistem operasi tertentu, atau alur kerja di mana overhead VM lengkap dapat diterima dan isolasi yang diberikannya diinginkan. Pengembang DevOps yang bekerja dengan tim yang memelihara Vagrantfile untuk konsistensi lingkungan pengembangan akan menemukan Vagrant sebagai alat yang praktis dan mudah dikuasai.


VMware: Virtualisasi Perusahaan dalam Skala Besar


VMware adalah perusahaan yang menjadikan virtualisasi server perusahaan sebagai praktik utama dan teknologinya tetap menjadi fondasi infrastruktur on-premises sebagian besar perusahaan besar di seluruh dunia. Didirikan pada tahun 1998 dan termasuk di antara perusahaan-perusahaan awal yang mengembangkan teknologi virtualisasi server x86 untuk penggunaan komersial, produk-produk VMware — khususnya VMware ESXi dan vSphere — mengubah cara pusat data beroperasi dengan memungkinkan beberapa mesin virtual berjalan pada perangkat keras fisik bersama dengan karakteristik kinerja yang mendekati bare metal.

VMware ESXi adalah hypervisor Tipe-1 — terkadang disebut hypervisor bare-metal — yang berjalan langsung pada perangkat keras server tanpa sistem operasi yang mendasarinya. Tidak seperti hypervisor Tipe-2 yang berjalan sebagai aplikasi di atas OS host (seperti VirtualBox atau VMware Workstation), akses perangkat keras langsung ESXi memungkinkan kinerja yang hampir setara dengan kinerja native untuk mesin virtual yang dihostingnya. Sumber daya CPU, memori, penyimpanan, dan jaringan divirtualisasi dan dialokasikan ke VM dengan kontrol yang terperinci, dan fitur perangkat keras seperti Intel VT-x dan AMD-V dimanfaatkan untuk virtualisasi yang dibantu perangkat keras yang meminimalkan overhead.

vSphere adalah platform manajemen virtualisasi komprehensif VMware, yang dibangun di atas host ESXi dan dikelola melalui vCenter Server. vSphere menyediakan antarmuka manajemen untuk seluruh armada host ESXi dan mesin virtualnya — menyediakan VM baru dari template, memigrasikan VM yang sedang berjalan antar host dengan vMotion (migrasi langsung tanpa downtime), mendistribusikan beban di seluruh host dengan Distributed Resource Scheduler (DRS), dan memastikan kontinuitas VM melalui High Availability (HA) yang secara otomatis memulai ulang VM pada host yang sehat ketika sebuah host gagal.

vSAN (VMware Virtual SAN) memperluas virtualisasi VMware ke penyimpanan, menciptakan lapisan penyimpanan yang ditentukan perangkat lunak yang menggabungkan drive disk lokal host ESXi ke dalam datastore terdistribusi bersama — menghilangkan kebutuhan akan perangkat keras SAN atau NAS khusus. NSX menyediakan jaringan dan keamanan yang ditentukan oleh perangkat lunak, memungkinkan topologi jaringan, aturan firewall, dan penyeimbangan beban untuk didefinisikan dan dikelola melalui perangkat lunak, bukan melalui konfigurasi perangkat jaringan fisik.

Bagi developer DevOps, keahlian VMware paling relevan di lingkungan perusahaan di mana infrastruktur VMware on-premises yang signifikan berdampingan dengan penerapan cloud. Mengelola template VM dan ekspor OVF, memahami konfigurasi resource pool dan cluster, bekerja dengan API VMware untuk manajemen VM terprogram (melalui alat seperti penyedia VMware Terraform atau modul VMware Ansible), dan memahami jaringan vSphere — termasuk switch virtual terdistribusi dan grup port — semuanya merupakan kompetensi praktis yang membedakan pengembang DevOps yang mampu beroperasi di lingkungan perusahaan.
Advertisement:
Jadi, DevOps adalah salah satu disiplin ilmu yang paling cepat berkembang dan paling dibutuhkan di industri teknologi, dan keterampilan teknis yang dibahas di sini — keahlian infrastruktur dengan NGINX, AWS, Azure, dan ELK; kemahiran otomatisasi dengan Ansible, Chef, dan Jenkins; dan penguasaan virtualisasi dan orkestrasi dengan Docker, BladeCenter, Kubernetes, Vagrant, dan VMware — mewakili inti dari apa yang dicari oleh organisasi perekrut dalam seorang developer DevOps yang cakap.
Artikel Terkait: