Docker Compose vs Kubernetes: Bila hendak menggunakan setiap satu, perbezaan dan migrasi

Informatec Digital » Sumber » Docker Compose vs Kubernetes: Bila hendak menggunakan setiap satu, perbezaan dan migrasi

Jika anda bekerja dengan kontena, lambat laun persoalan besar akan timbul: Docker Compose atau Kubernetes? Kedua-dua alat ini digunakan dalam kitaran hayat aplikasi kontena , tetapi ia tidak direka untuk menyelesaikan masalah yang sama atau dalam konteks yang sama. Dalam artikel ini, kami membandingkannya secara mendalam, dengan contoh praktikal, senario dunia sebenar dan petua untuk berhijrah dari satu ke yang lain dengan lancar.

Di luar postur teknologi, keputusan tersebut memberi kesan kepada operasi harian: masa penggunaan, kebolehskalaan , daya tahan, keselamatan dan kos . Ia juga mempengaruhi kes penggunaan kejuruteraan data yang biasa—saluran paip, pangkalan data, penstriman, pemprosesan kelompok, format data dan tadbir urus—yang mana orkestrasi membuat semua perbezaan dalam produktiviti.

Apakah Docker dan Docker Compose (dan untuk apa sebenarnya)?

Apabila kita bercakap tentang Docker, kita sebenarnya bercakap tentang ekosistem: Docker Engine, Docker Hub, Dockerfile, Docker Compose … Enjin mencipta dan menjalankan bekas daripada imej; Hub memudahkan untuk berkongsinya; dan Compose membolehkan anda menentukan beberapa bahagian tindanan dalam fail YAML untuk melancarkannya dengan satu arahan.

Compose dicipta untuk menyelamatkan kita daripada skrip yang tidak berkesudahan dan arahan terpencil. Dengan satu fail docker-compose.yml, anda menerangkan perkhidmatan, rangkaian dan volum , dan anda menyediakan dan menjalankan semuanya dengan satu "docker compose up" (atau "docker-compose up" dalam V1). Sesuai untuk pembangunan setempat, ujian bersepadu, demo atau persekitaran CI.

Satu contoh kanonik Compose mungkin seperti ini, dengan API dan pangkalan data Postgres. Perhatikan bagaimana kebergantungan, pembolehubah dan port diisytiharkan dalam blok yang boleh dibaca:

version: '3.8'
services:
  db:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - '5432:5432'
    volumes:
      - db:/var/lib/postgresql/data
    networks:
      - mynet

  my-api:
    container_name: my-api
    build:
      context: ./
    image: my-api
    depends_on:
      - db
    ports:
      - '8080:8080'
    environment:
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: postgres
      DB_PASSWORD: postgres
      DB_NAME: postgres
    networks:
      - mynet

networks:
  mynet:
    driver: bridge

volumes:
  db:
    driver: local

Untuk menskala secara manual dalam Compose, anda boleh menggunakan pilihan penskalaan perkhidmatan tersebut. Dalam Compose V2, perkara biasa untuk melakukan ini dengan `up --scale` (dalam V1 terdapat `docker-compose scale`):

docker compose up -d --scale my-api=3

Berhati-hati dengan batasannya: Compose direka untuk hos tunggal , ia tidak mengimbangi beban antara nod atau penskalaan automatik dan kemas kini biasanya merupakan penciptaan semula bekas secara manual dengan "build" dan "up -d".

Apakah itu Kubernetes dan apakah yang ditawarkannya berbanding Compose?

Kubernetes (K8s) ialah platform orkestrasi kontena teragih. Ia mengurus penggunaan pada skala merentasi kluster berbilang nod , dengan konsep seperti Pod, Penggunaan dan Perkhidmatan untuk mengendalikan beban kerja pengeluaran.

Dalam Kubernetes, anda tidak mengurus kontena individu; anda mengurus Pod (yang boleh mengandungi satu atau lebih kontena). Satah kawalan menjadualkan tempat setiap Pod dijalankan , mendedahkan perkhidmatan, mengagihkan trafik, menskala secara mendatar dan memantau kesihatan beban kerja.

Pelaksanaan asas mungkin kelihatan seperti ini, dengan 3 replika perkhidmatan web. Takrifkan templat, label dan port yang terdedah :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Untuk mendedahkannya dengan pengimbangan beban, perkhidmatan LoadBalancer adalah tipikal di awan. Pemilih memadankan label Pod untuk menghalakan trafik.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8000
  type: LoadBalancer

Dalam pengeluaran, Kubernetes menyerlah dengan keupayaan seperti automasi berprestasi tinggi (HPA), kemas kini bergulir dan pemulihan kendiri. HPA melaraskan replika berdasarkan metrik (cth., penggunaan CPU) :

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deployment
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

Kesihatan kontena dipantau dengan prob; jika ia gagal, K8 akan memulakan semula kontena. Inilah asas "penyembuhan kendiri" :

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
    - name: web
      image: my-web-image
      ports:
        - containerPort: 8000
      livenessProbe:
        httpGet:
          path: /healthcheck
          port: 8000
        initialDelaySeconds: 15
        periodSeconds: 15

Persamaan dan perbezaan utama (yang penting tanpa perlu berbelit-belit)

Apa yang mereka ada persamaan: ia berfungsi dengan kontena dan menentukan penggunaan melalui YAML. Kedua-dua penyelesaian ini berguna untuk pembangun dan pengendali , dan saling melengkapi dengan baik dalam aliran kerja dev→prod.

Perbezaan penting terletak pada skopnya: Compose berpusatkan Docker dan hos tunggal ; Kubernetes menyokong berbilang masa jalan dan kluster berbilang nod, dengan penyepaduan langsung ke dalam awan dan perkhidmatan terurus.

Kontras yang lebih penting: Kubernetes menawarkan penskalaan automatik, kemas kini bergulir dan penyembuhan kendiri ; Compose tidak. Kubernetes mengabstrak dengan Pod; Compose berinteraksi secara langsung dengan bekas Docker.

Tambahan pula, Kubernetes menyertakan Jobs dan CronJobs untuk tugasan sekali sahaja atau berjadual. Ini mengelakkan kerja cron sistem dan proses kontena tambahan , menjadikan platform sebagai tempat semula jadi untuk menentukan automasi.

Di premis, Compose menang dari segi kelajuan dan kesederhanaan. Untuk penskalaan kepada ratusan nod atau persekitaran berbilang awan, Kubernetes adalah pilihan yang logik . Compose boleh memanfaatkan Docker Swarm untuk penggunaan berbilang hos, tetapi kadar penggunaan dan keupayaannya tidak sepadan dengan ekosistem dan kematangan Kubernetes.

Mengapa anda memerlukan orkestrasi (dan apabila setiap satu sesuai dengan yang terbaik)

Seorang orkestrator yang baik memberi anda: peruntukan dan penggunaan bersepadu, permulaan berjadual, komunikasi antara perkhidmatan , pengimbangan beban dan keselamatan tambahan melalui tadbir urus tambahan ke atas setiap perkhidmatan.

Compose merangkumi asas-asas dengan cara yang diperkemas dan mudah dibaca, menjadikannya alat yang hebat untuk pembangunan, pengujian dan demo. Walau bagaimanapun, batasannya menjadi jelas apabila anda memerlukan berbilang nod, pengimbangan beban asli dan penskalaan automatik atau penggunaan tambahan tanpa masa henti.

Kubernetes, sebaliknya, ialah "platform" apabila beban bertambah: berbilang nod, penskalaan automatik, ketersediaan tinggi dan ekosistem yang besar , dengan sokongan natif pada AWS, Azure, GCP dan pilihan terurus.

Kes penggunaan dunia sebenar (dev, data dan banyak lagi)

Compose menyerlah dalam: persekitaran setempat yang boleh dihasilkan semula, pengujian E2E, CI/CD dan latihan . Menentukan keseluruhan tindanan dalam YAML dan melancarkannya dengan satu arahan dapat menghapuskan banyak hingar.

Kubernetes sesuai untuk: aplikasi pengeluaran, IoT dan pengkomputeran pinggir, data raya dan pembelajaran mesin serta persekitaran awan berbilang/hibrid. Ia mengurus beban kerja teragih yang mana latensi, daya tahan dan kebolehcerapan penting.

Dalam kejuruteraan data, K8s sesuai untuk penstriman dan saluran paip kelompok, pangkalan data, barisan dan enjin analitikal , dengan kawalan sumber setiap pod dan penskalaan automatik pada puncak.

Jika projek anda kecil dan muat pada satu hos, Compose akan menyelesaikannya tanpa sebarang masalah. Tetapi apabila pangkalan pengguna anda berkembang dan anda memerlukan toleransi kesalahan dan pengimbangan beban yang serius , sudah tiba masanya untuk mempertimbangkan Kubernetes.

Rangkaian, penskalaan dan peningkatan: perbandingan praktikal

Compose mencipta rangkaian bagi setiap projek dan menyelesaikan nama bagi setiap perkhidmatan. Berkomunikasi dengan kontena adalah mudah dan selamat dalam projek , tetapi pengimbangan beban luaran dan berbilang pengehosan bukanlah ciri asli.

Dalam Kubernetes, Perkhidmatan menawarkan penemuan DNS dan pengimbangan beban dalam kluster; secara luaran anda boleh menggunakan LoadBalancer, NodePort atau Ingress untuk menghalakan trafik HTTP/S.

Penskalaan: Karang skala secara manual dan hanya pada satu hos. Kubernetes skala secara mendatar dengan HPA dan secara pengaturcaraan dengan metrik dan/atau peristiwa. Ia juga boleh berkembang kepada lebih banyak nod jika kluster membenarkannya.

Kemas Kini: Dalam Compose, ini biasanya merupakan rekreasi manual. K8s melakukan kemas kini bergulir dengan kawalan kemajuan (pelancaran kubectl) dan keupayaan untuk kembali jika ada masalah, meminimumkan impak.

Penyembuhan kendiri: Compose boleh memulakan semula kontena, tetapi ia tidak menyelesaikan ranap hos atau masa jalan. Kubernetes memindahkan Pod ke nod yang sihat , secara telus kepada pengguna.

Produktiviti pembangun dan pengalaman operasi

Compose ialah lapisan nipis di atas Docker. Ia cepat dipelajari dan gelung maklum balasnya serta-merta , sesuai untuk iterasi.

Kubernetes menambah konsep baharu (Pod, Deployments, Services, Ingress, ConfigMaps, PVC, dll.). Terdapat lengkung pembelajaran, tetapi sebagai balasannya anda memperoleh kawalan yang terperinci ke atas penggunaan, keselamatan, kebolehcerapan dan kebolehskalaan.

Dari segi keserasian, Compose adalah "Docker-first". Kubernetes menyokong pelbagai runtime dan berintegrasi dengan penyedia awan , yang merupakan kunci bagi syarikat yang mempunyai strategi berbilang awan atau hibrid.

Berhijrah daripada Docker Compose ke Kubernetes tanpa menjadi gila

Bilakah perlu berhijrah? Apabila aplikasi anda tidak lagi "kecil", anda memerlukan berbilang nod, kebolehcerapan, kebolehskalaan dan ketersediaan tinggi , atau anda diminta untuk penggunaan kenari dan biru/hijau.

Cabaran biasa: pemetaan rangkaian perkhidmatan, mereka bentuk Storan dengan PV/PVC , memisahkan konfigurasi kepada ConfigMaps/Secrets dan menyemak corak kesihatan dan kesediaan setiap kontena.

Seni bina juga perlu dipertimbangkan semula: Pod sebagai unit penggunaan , perkhidmatan untuk mendedahkan titik akhir dan sumber setiap kontena (CPU/Mem) supaya penjadual boleh menjalankan tugasnya.

Karang: daripada Karang kepada K8 dalam beberapa langkah

Kompose menukar fail docker-compose.yml kepada manifes Kubernetes atau OpenShift. Ia merupakan cara paling langsung untuk memulakan migrasi tanpa menulis semula semua YAML secara manual.

Sebelum anda bermula, anda memerlukan kluster Kubectl dan kubectl yang dikonfigurasikan. Sekurang-kurangnya dua nod pekerja (bukan satah kawalan) disyorkan jika anda menguji apa-apa yang berstatus. Semak versi anda dengan `versi kubectl`.

Pemasangan: Kaedah yang disyorkan adalah untuk memuat turun binari daripada keluaran GitHub terkini. Anda juga boleh menggunakan tarball, Homebrew pada macOS atau "go get" (pilihan terakhir ini menggunakan master dengan perubahan dalam pembangunan).

Penukaran asas: navigasi ke direktori docker-compose.yml dan jalankan :

kompose convert
kubectl apply -f <archivos-generados>

Kompose menjana Pelaksanaan dan Perkhidmatan secara lalai. Log biasanya menyenaraikan setiap fail yang dicipta dan sebaik sahaja digunakan, anda akan melihat Pelaksanaan dan Perkhidmatan "dicipta" dalam kluster.

Akses: Jika anda menggunakan Minikube, anda boleh mendedahkan atau membuat pertanyaan tentang perkhidmatan dengan mudah. ​​Dalam awan, tandakan "LoadBalancer Ingress" untuk mendapatkan alamat IP awam perkhidmatan LoadBalancer; dengan NodePort, anda akan mempunyai port terbuka pada nod.

Pembersihan: Apabila anda selesai ujian, alih keluar sumber yang digunakan. Pastikan kluster anda bersih untuk mengelakkan konflik antara lelaran.

Susun pilihan lanjutan (penyedia, objek dan teg)

Kompose menyokong Kubernetes dan OpenShift. Jika anda tidak menyatakan "--provider", ia menggunakan Kubernetes secara lalai . Dengan OpenShift, ia boleh menjana DeploymentConfigs dan ImageStreams, malah BuildConfigs jika anda menggunakan arahan binaan.

Ia juga menyokong pelbagai output: JSON dengan "-j", ReplicationControllers, DaemonSets atau Helm Charts . Bendera "--replicas" membolehkan anda menukar bilangan replika dalam RC; untuk Helm, ia menjana struktur carta asas.

Tag khusus kompos dalam proses kompos mempengaruhi penukaran. Contohnya, anda boleh menentukan jenis Perkhidmatan atau sama ada untuk mendedahkan titik akhir melalui Ingress/Route.

Label	Nilai-nilai
kompose.service.type	nodeport/clusterip/loadbalancer
kompose.service.expose	benar / nama hos

Butiran yang perlu diingat: nama dengan "_" ditukar kepada "-" (K8 tidak membenarkan garis bawah) dan, jika perkhidmatan menggunakan volum, strategi penggunaan berubah kepada "Cipta Semula" untuk mengelakkan konflik dengan berbilang penulis.

Kompos menyokong berbilang versi dan fail

Kompose menyokong Compose V1, V2 dan V3 (dengan sokongan terhad untuk 2.1 dan 3.2 disebabkan sifat eksperimennya). Jika anda menghantar berbilang fail docker-compose sekaligus, ia akan digabungkan dan elemen biasa akan ditulis ganti oleh yang terkini, sama seperti yang anda lakukan dalam penggantian.

Semasa penukaran Kubernetes, anda akan melihat mesej seperti "AWAS Binaan kekunci yang tidak disokong – mengabaikan" jika terdapat kekunci yang tidak serasi. Jangan risau, alat ini akan meneruskan apa yang difahaminya dan membiarkan selebihnya untuk pelarasan manual kemudian.

Beyond Compose: Move2Kube dan pemindahan manual

Jika anda memerlukan lebih banyak kawalan, terdapat alat seperti Move2Kube yang menganalisis Compose anda dan menghasilkan lebih banyak artifak Kubernetes yang ditala dengan lebih teliti. Ia berguna apabila anda ingin menyesuaikan corak atau templat perniagaan daripada platform anda.

Migrasi manual adalah sah sepenuhnya dan hampir sentiasa disyorkan selepas migrasi awal. Langkah-langkah biasa termasuk: menukar perkhidmatan kepada Deployments/StatefulSets , rangkaian kepada Services/Ingress dan volum kepada PV/PVC dengan kelas storan.

Contoh minimum untuk menukar perkhidmatan Compose kepada Deployment mungkin kelihatan seperti ini: pindahkan port, imej dan label ke templat Pod:

# docker-compose.yml
version: '3'
services:
  web:
    build: .
    ports:
      - '8000:8000'
    depends_on:
      - db

# Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: my-web-image
          ports:
            - containerPort: 8000

Untuk keadaan (pangkalan data, baris gilir), pertimbangkan StatefulSets dan PersistentVolumes. Tidak semua yang "bersama" dalam Compose harus berada dalam Pod yang sama ; tanggungjawab berasingan dan gunakan Perkhidmatan untuk berkomunikasi antara komponen.

Senario data: penstriman, kelompok dan tadbir urus

Dalam saluran data yang kompleks, K8 sangat sesuai: Pekerjaan untuk proses kelompok, CronJobs untuk tetingkap masa , Pelaksanaan untuk API dan pengendali untuk sistem seperti Kafka, Spark atau Flink.

Untuk penstriman dan pangkalan data, pengendali komuniti dan carta memudahkan pelancaran. Rangkaian dan kawalan sumber Service Mesh memastikan latensi dan SLO yang lebih boleh diramal berbanding penyelesaian hos tunggal.

Dalam tadbir urus dan keselamatan data, Kubernetes menawarkan ruang nama, dasar dan kawalan RBAC untuk mengaudit dan memisahkan persekitaran. Ini merupakan kelebihan praktikal berbanding pendekatan setempat Compose.

Amalan terbaik dan helah operasi kecil

Dalam Compose: pastikan YAML anda kecil dan modular ; gunakan pembolehubah persekitaran dan fail .env; port dokumen dan kebergantungan; dan tunjukkan dalam CI apa yang anda jalankan secara setempat.

Dalam Kubernetes: tentukan permintaan/had CPU dan memori , gunakan prob Kesediaan/Liveness, asingkan konfigurasi ke dalam ConfigMaps/Rahsia dan gunakan strategi penggunaan yang sesuai untuk setiap perkhidmatan.

Untuk kemas kini Kubeck: gunakan `kubectl set image` dan `kubectl rollout status` untuk memantau kemajuan dan membatalkannya jika berlaku masalah. Ini akan mengelakkan masa henti dalam pengeluaran.

Jika anda memerlukan kerja tertentu dalam Compose, anda boleh mensimulasikannya, tetapi dalam Kubernetes ia lebih bersih dengan CronJobs/Jobs ; anda tidak akan memenuhkan bekas dengan proses tambahan atau mengehoskan cron.

Soalan Lazim Pantas untuk mengelakkan kekeliruan

Adakah Compose menggantikan Kubernetes? Tidak. Compose memudahkan susunan berbilang bekas pada hos tunggal; Kubernetes mengatur pada skala kluster dengan ketersediaan yang tinggi.

Adakah Compose masih digunakan? Ya, sangat banyak. Ia merupakan alat pembangunan dan pengujian yang ideal untuk menyediakan persekitaran lengkap hanya dengan beberapa arahan.

Adakah Kubernetes "lebih baik" daripada Docker? Kedua-duanya berbeza: Docker ialah platform kontena ; Kubernetes mengaturnya dalam kluster dan menambah operasi lanjutan.

Bolehkah saya membawa Compose saya ke Kubernetes tanpa menulis semula secara manual? Ya, dengan integrasi Kompose atau Docker Desktop. Ia memberi anda langkah pertama yang pantas yang kemudiannya boleh anda perhalusi.

Butiran halus: pengaturcaraan, OpenShift dan penukaran alternatif

K8s bukan sekadar penggunaan berterusan: Jobs dan CronJobs merangkumi tugas sekali sahaja atau yang dirancang tanpa anda perlu mengurus cron sistem.

Dalam OpenShift, Kompose boleh menjana DeploymentConfigs dan ImageStreams, malah BuildConfigs jika Compose mempunyai binaan yang dikaitkan dengan repositori Git. Bendera “--build-repo” dan “--build-branch” digunakan untuk melaraskan sumber.

Jika anda mahukan output yang berbeza, Kompose membenarkan DaemonSets, ReplicationControllers atau Helm Charts dan bukannya Deployments and Services lalai. Ia juga boleh menjana JSON, bukan sahaja YAML.

Keserasian, amaran dan isu kecil

Compose V1/V2/V3 disokong oleh Kompose (dengan batasan dalam 2.1 dan 3.2). Kekunci yang tidak disokong diabaikan dengan WARN , memberi ruang untuk pelarasan manual.

Jika perkhidmatan anda mempunyai volum, Kompose akan mengubah strategi kepada "Cipta Semula" untuk mengelakkan keserentakan pada volum yang sama . Ini adalah perkara biasa untuk perkhidmatan stateful.

Garis bawah dalam nama ditukar kepada tanda sempang. Ini merupakan sekatan Kubernetes terhadap nama objek , jadi pastikan anda menamakannya dengan betul dalam Compose untuk mengelakkan kejutan semasa penukaran.

Untuk mengakses dari luar, semak jenis Perkhidmatan: ClusterIP (dalaman), NodePort (port pada nod) atau LoadBalancer (IP awam di awan). Dengan Ingress, anda akan mempunyai laluan HTTP/S yang bersih dan TLS berpusat.

Jika anda menguji dalam Minikube, arahan seperti “minikube service <svc> –url” akan mengembalikan URL pantas . Dalam Cloud, lihat medan “LoadBalancer Ingress” semasa menerangkan Perkhidmatan.

Satu perkara yang menarik: dalam komuniti, anda akan menemui rujukan kepada gaji untuk profil Kubernetes dan kadar penggunaan hampir 88% dalam persekitaran pengeluaran. Tiada yang luar biasa: ia adalah standard de facto.

Untuk melengkapkan gambaran ini, terdapat lebih banyak lagi tentang Kubernetes selain daripada HTTP: Service Mesh, operator dan CRD meluaskan jangkauan Kubernetes. Jika anda datang dari Compose, adalah perkara biasa untuk berasa terbeban pada mulanya, tetapi kuasa tambahan itu diterjemahkan kepada operasi yang lebih mantap.

Tetapkan semula dasar: kesetaraan berguna

Compose membenarkan “mulakan semula: sentiasa/pada-kegagalan/tiada”. Dalam Kubernetes, bergantung pada kesnya, anda akan mempunyai Pod atau pengawal individu (Deployments atau RC) dengan dasar mulakan semula yang sesuai.

docker-compose mulakan semula	Objek dalam K8s	restartPolicy
«» / sentiasa	Pengawal (Pengerahan/RC)	Sentiasa
pada-kegagalan	Pod	OnFailure
tidak	Pod	Jangan sekali-kali

Jika dalam Compose anda mempunyai bekas "pengiraan" atau tugasan sementara (seperti "pi" pantas), cuma laksanakannya dalam K8 sebagai Kerja atau CronJob dengan dasar yang sesuai dan anda sudah bersedia.

Pilih Compose untuk penggunaan setempat dan Kubernetes yang pantas apabila persekitaran anda memerlukan lebih banyak kuasa: sokongan berbilang nod, penskalaan automatik, penggunaan yang lancar dan daya tahan sebenar . Dengan Compose, Move2Kube dan sedikit penjagaan, peralihan menjadi lancar.

Akhirnya, pilihan bergantung pada skala dan kerumitan: Compose sangat sesuai untuk pembangunan, pengujian dan susunan hos tunggal ; Kubernetes ialah pilihan terbaik untuk perusahaan, penggunaan berbilang awan dan pasukan yang memerlukan automasi lanjutan, ketersediaan tinggi dan ekosistem dengan beribu-ribu integrasi.